前言：中文期刊网精心挑选了软件测试报告范文供你参考和学习，希望我们的参考范文能激发你的文章创作灵感，欢迎阅读。
软件测试报告范文1
1 引言
软件测试是软件开发过程的重要组成部分，是用来确认一个产品的品质或性能是否符合开发之前所提出的要求。对软件需求分析、设计规格说明和编码的最终复审，某种程度上测试工作的好坏直接影响了软件产品的交付和用户的满意度。因此，如何做好测试工作，使测试在软件工程中顺利进行，辅助软件开发工作是我们每个软件人员应该考虑的问题。
2 软件测试的目的
（1）确认软件的质量，确认软件做了你所期望的事情，确认软件以正确的方式来做了这个事件。
（2）提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。
（3）软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。软件测试的第三个目的是保证整个软件开发过程是高质量的。
3 软件测试的对象
软件测试并不等于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。
4 软件测试流程
软件测试工作并不是在软件代码开发完毕后才开始的，这一点是很多软件人员的误区，需要明确一下，它其实是在项目进入软件实现阶段就开始了，项目进入软件实现阶段的时候，就应该启动软件测试工作了。
下面根据笔者的测试经验，详细阐述一下软件测试的流程、每个阶段需要做的工作及整个测试过程产生的文档。
4.1 计划与设计阶段
4.1.1 召开测试启动会议
当项目进入软件实现阶段（编码），测试经理召集项目经理、开发经理开会确定测试交接时间，开发团队与测试团队交接测试内容，对测试目标达成一致，商讨测试计划的可行性，统一项目组的目标和测试的工作重点。进行规模预估并成立测试团队，完成《测试计划》和《测试方案》。
4.1.2 设计测试用例
明确了测试需求和测试计划，在需求分析文档确立基线以后，测试组需要针对测试需求编写全部测试用例，在实际的测试中，测试用例将是唯一实施标准。
4.2 实施测试阶段
4.2.1 实施测试用例
实施测试用例将花费测试组绝大部分时间，这些工作都是建立在前期很多计划工作的基础上。当测试用例全部编写完成后，测试工程师根据测试计划中分配给自己的测试任务，实施相应的测试用例，并记录测试结果。
4.2.2 填写测试记录
测试人员在进行具体的测试工作时，需要将测试内容填写在测试记录表中，直到所有的测试执行工作结束。
4.2.3 提交BUG清单
在具体的测试过程中，测试人员发现BUG后，需要将BUG记录在清单里，并及时提交给测试经理。
4.2.4 提交测试报告
在约定的测试周期完成之后，测试工程师需要总结此测试的结果，编写测试报告。测试工程师根据此轮测试的结果，编写测试报告，主要应包含以下内容：
（1）测试报告的版本。
（2）测试的人员和时间。
（3）测试所覆盖的缺陷――测试组在这轮测试中所有处理的缺陷， 不仅要写出覆盖缺陷的总数，还要写明这些缺陷的去向。
（4）上一版本活动缺陷的数量。
（5）经过此轮测试，所有活动缺陷的数量及其状态分类。
（6）测试评估――写明在这一版本中，哪些功能被实现了，哪些还没有实现，这里只需写明和上一版本不同之处即可。
（7）急待解决的问题――写明当前项目组中面临的最优先的问题，可以重复提出。
在每轮测试结束之后应尽快将符合标准的测试报告发给测试经理。
4.3 总结阶段
测试工作结束或即将结束时，测试组就要开始着手准备进行总结的工作。
4.3.1 编写测试总结报告
在测试结束之后，测试经理编写测试报告，对测试进行总结，并且提交给项目经理，为产品的后续工作提供重要的信息支持。
测试经理根据测试的结果及测试工程师提交的测试报告编写测试总结报告，测试总结报告必须包含以下重要内容：
（1）测试资源概述―多少人、多长时间。
（2）测试结果摘要―分别描述各个测试需求的测试结果，产品实 现了哪些功能点，哪些还没有实现。
（3）缺陷分析―按照缺陷的属性分类进行分析。
（4）测试需求覆盖率―原先列举的测试需求的测试覆盖率，可能 一部分测试需求因为资源和优先级的因素没有进行测试，那么 在这里要进行说明。
（5）测试评估―从总体对项目质量进行评估。
（6）测试组建议―从测试组的角度为项目组提出工作建议。
4.3.2 测试验收
测试验收工作是在以上工作全部结束后，测试经理对测试的过程、效果进行验收，签发测试验收报告，宣布测试结束。由测试经理进行测试验收，验收内容包括：
（1）测试效果验收―测试是否达到预期目的。
（2）测试文档验收―测试过程文档是否齐全，符合标准。
（3）测试评估―从总体对测试的质量进行评估。
（4）测试建议―对本次测试工作指出不足，需要在以后工作中改 进的地方。
（5）宣布测试结束―测试组成员签字宣布本次测试结束。
4.3.3 测试归档
测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归档，主要包括测试计划、测试用例、测试报告、验收报告等。这些文档的编写保障了测试的顺利进行，同时作为整个测试项目的痕迹，被保留下来，供查阅。
参考文献
[1]佟伟光.软件测试[M].北京：人民邮电出版，2008.
[2]Rex Black.测试流程管理[M].北京：北京大学出版社，2001.
[3]Robert V.Binder著，华庆一等译.面向对象系统的测试[M].北京：人民邮电出版社，2001.
[4]Mark Fewster， Dorothy Graham著，舒智勇等译.软件测试自动化技术与实例详解[M].北京：电子工业出版社，2000.
[5]Karl E.Wiegers著，陆丽娜，王忠民，王志敏译.软件需求[M].北京：机械工业出版社，2000.
软件测试报告范文2
一、 测试组组成测试组由测试组长和测试工程师组成。
二、 测试组工作职责负责理解软件产品的功能要求，搭建配套的测试环境，然后 对其进行系统测试，检查软件有没有错误 (Bug)，决定软件是否 具有稳定性 (Robustness)，并写出相应的测试用例、各阶段测试 报告。
（一） 测试组长工作职责：
1、 协调测试组与各个项目组之间的流程及工作关系；
2、 对各个项目的测试工作进行统筹安排，并对各个项目的 测试工作进行计划、分工和管理；
3、 定期或不定期与各个项目负责人沟通项目进度，随时了 解项目进展情况；
4、 对测试组成员的日常工作进行评审考核；
5、 定期或不定期向部门总监汇报工作情况；
6、 参与日常的软件测试工作。
（二） 测试工程师工作职责：
1、 仔细阅读项目规格说明、设计文档、使用说明书等，充 分掌握软件的性能、特点、使用方法、业务流程等，协 助测试组长制定项目的测试计划；
2、 依据项目要求，搭建相应的测试环境，维护测试设备；
3、按照测试计划编写测试用例，保证测试用例合理有效；
4、 根据测试计划及测试案例，执行测试，并根据产品特点 及测试要求，实施集成测试、系统测试等，及时发现软 件缺陷，评估软件的特性与缺陷；
5、 详细记录测试过程，编写测试报告和对测试结果进行分 析，通过测试，掌握软件具有的能力、缺陷、局限等， 对软件质量给出评价性的结论与意见，整理测试文档， 填写软件测试报告,编写测试总结，为软件开发成果提供 总结性意见；
6、 配合研发部门各项软件产品，并详细编写产品 通知单；
7、 完成上级及部门其他领导交办的临时任务。
三、 测试组工作流程测试组的工作与项目开发进度紧密相关，所以测试的工作流 程依据开发进度分阶段进行大致分为以下几个阶段：
（一） 计划和设计阶段
1、 项目组成立时，确定项目需求及项目设计方案，了解软 件产品的主体功能及实现目的；
2、 项目经理下发测试预通知，通知内容包括：正式交接测 试时间、测试规模预计估算等信息；
3、 召开测试启动会议，会议内容包括：开发团队与测试组 交接测试内容，对测试目标达成一致，商讨测试计划，
统一项目组的目标和测试的工作重点；
4、 编写测试计划及相关文档，依据测试启动会议中确定的 目标和重点，结合项目经理下发的《测试任务书》，编写
《测试计划书》（见附件一）。计划书的内容应该包括：
l测试需求：需要测试组测试的范围，估算出测试所花 费的人力资源和各个测试需求的测试优先级；
l测试方案：整体测试的测试方法和每个测试需求的测 试方法；
l测试资源：本次测试所需要的人力、软件、硬件及技 术资源；
l 测试组角色：明确测试组人员的工作内容及相关职责；
l里程碑：明确项目进行过程中的测试组应该关注的里 程碑；
l文档报告：确定在项目测试过程中需要提交的测试计 划，测试报告等；
l测试计划编写完毕后，需提交给全体项目组成员，由 项目成员综合评审后，确定最终《测试计划书》（见 附件二）。项目经理要以此为依据，跟踪监控项目测 试进度，评估测试计划的可行性，完整性，并且在项 目结束后评估测试质量。
5、 设计测试用例，依据《测试计划书》相关内容，根据每 一步测试计划编写全部的测试用例，测试用例必须能满
足全部的测试需求。
（二） 测试实施阶段
1、 实施测试用例，测试工程师依据《测试计划书》中分配 的测试任务和测试用例，实施相应的测试工作，并详细 记录测试过程及结果。
2、 提交测试报告，在实施测试用例的过程中，依据记录的 测试过程和结果，填写《测试报告书》，并由测试组长审 批后，上报项目经理。项目经理安排开发组修改相应的 软件产品。测试报告内容包括：测试产品版本、测试人 员、测试时间、测试过程、产品运行BUG、产品缺陷状态、 急待解决的问题。
3、 回归测试，接到开发组的回归测试通知后，测试组重新 拷贝修改后的最新版本，进行回归测试。回归测试的用 例属于测试用例的一部分或者全部测试用例，但不能超 出测试用例的范围。
（三） 测试总结阶段
1、 编写测试总结报告：回归测试全部通过完成后，由测试 组长整理填写《测试总结报告》，报告主要内容包括： 测试资源描述——参与测试人数，耗用测试时间； 测试结果摘要——描述各个测试需求的测试结果和功能 实现情况； 缺陷分析——按照缺陷的属性分类进行分析；
测试需求覆盖率——如果在测试过程中未覆盖到的测试 需求，在此应详细说明原因； 测试评估——对此次项目质量进行评估； 测试组建议——从测试组角度为项目组提出工作建议。
2、 测试验收：项目经理收到测试组长提交的测试总结报告 后，对此次测试工作进行验收。验收内容包括：测试效 果验收、测试文档验收、测试工作评估、测试工作建议， 签字验收后，宣布此次测试结束。
3、 测试文档归档：测试验收结束后，对测试过程中涉及到 的各种标准文档进行归类、存档。相关文档包括：测试 任务书、测试计划书、测试用例、测试报告书、测试总 结报告、测试验收报告等。
（四） 产品阶段
软件测试报告范文3
关键词： 软件测试； 自动化； 自动化测试； 测试工具； 可扩展标记语言技术
中图分类号： TP 31文献标识码： Adoi： 10.3969/j.issn.10055630.2013.02.004
引言随着计算机应用日益普及和深化，用户对软件的需求越来越多，对软件要求也总是在不断变化[1]。AutoCAD产品在软件国际化的过程中，每次修改都需要对大量的测试用例进行反复测试，还要在不同语言版本的操作系统平台上测试，这就使得该项目的测试工作极为繁琐。软件自动化测试作为保证软件质量和可靠性的关键技术手段，正日益受到广泛的重视。但如何进行测试，如何提高测试的质量和效率，仍然是许多人深感困扰的问题[2]。根据对AutoCAD软件测试项目研究与实践的体会，介绍软件自动化测试技术的概述、基本过程和实现。结合实用的Silk Test工具以及可扩展标记语言技术（extensible markup language，XML），给出整个自动化测试框架。1自动化测试概述整个自动化测试平台包含两部分：测试平台和服务器平台。测试平台包含不同语言版本或者不同操作系统的平台；服务器平台主要含有源代码版本管理库和测试结果的关系数据库[3]。一个规范化的软件自动化测试过程通常包括以下几个基本的测试活动：（1）自动化测试用例选择对于Silk Test工具而言，它对Java的支持很好，所以如果是多模块、多软件测试，首先要尽量选择和Java相关的部分来设计用例[4]。（2）自动化测试环境准备开启windows远程控制，设置文件的扩展名可见，安装待测试AutoCAD系列产品，安装测试过程所需的自动化测试软件（Silk Test软件）等等一系列配置。光学仪器第35卷
第2期商林霞，等：基于XML的软件自动化测试
（3）自动化测试脚本开发Silk Test自动化测试工具支持简单的捕获同放功能，但是这并不是自动化测试。测试工具直接录制产生的脚本是不能直接使用的，所以对于利用Silk Test工具编写的脚本来说，通常是通过捕获对话框图形，抓到测试对象。然后利用Silk Test所提供的4Test语言来添加函数、控制结构等[5]。 （4）自动化测试报告生成分析脚本运行的结果是否符合要求，决定每个用例自动化测试是否通过。对测试结果进行分类整理，生成测试报告。对于不能通过的测试结果要进行分析、记录和通报，方便相关的测试人员和开发人员了解测试结果。2自动化测试系统过程为了取得自动化测试效率和效益的最大化，现选取当前最适合自动化的测试用例。例如自动化测试脚本编写异常复杂的用例、运行自动化测试脚本很难发现软件缺陷的用例等等，都可以不运用自图1自动化测试系统实现框图
Fig.1Automation testing system
realization block diagram动化测试，而运用手动测试代替。同时在两个测试版本的间歇进行新的脚本的开发，当有了一定数量的脚本之后，就让脚本运行起来，发挥作用[6]。现只要保证自动化运行的环境足够充足，那么每个测试版本所需的时间就会足够短，节省了大量的人力。软件自动化测试是一个极为复杂的过程。在不同的测试环境下，测试的流程也会有所不同。一般都要根据实际情况，制定相应的测试流程。从软件测试对象出发，软件自动化测试系统实现框图，如图1所示。对于不同语言版本的本地化测试，测试过程大体是相似的。首先根据AutoCAD软件的功能特征选择和设计测试用例，然后就是由测试用例编写测试脚本，接着就是将这些测试脚本作为输入运行程序，将通过测试得到的结果与先得到的英语版本的结果进行比较，最后就是将两者的比较结果写成测试报告，软件开发者根据测试报告再决定对软件如何处理[7]。3系统实现
3.1脚本生成根据测试设计中的每个测试用例，利用 Silk Test软件进行编程，完成自动化测试脚本。脚本编写完成，进行不断地调试，直至完成的脚本符合测试用例验证的要求。编程语言是4Test语言，整个脚本的思路是基于AutoCAD软件对话框对象来实现的。函数中执行图像录像功能的语句，把整个自动化测试的windows平台界面上的执行过程录制下来，方便判断软件是否存在缺陷。针对每个自动化测试的测试用例，编写测试脚本。每个测试用例都有数个测试确认点，测试脚本要保证每个测试确认点都能被执行自动化测试，生成测试结果。测试脚本程序示例如下：
3.2结果信息读取软件本地化测试的对象是本地化的软件，需要在本地语言的操作系统上进行。以Windows中文语言操作平台为例，用Silk Test工具运行该对话框对应的测试脚本，生成XML的结果信息文件，该XML记录了该对话框上的所有信息：文字信息、控件位置信息、控件属性信息。图2中所示的AutoCAD软件对话框的XML部分信息示例如下：
在获取对话框信息之后，接着就要进行XML结果的分析。读取XML文件信息的程序片段为：
其中，利用XPath的路径表达式来选取XML文档中的节点或者节点集[8]。如要读取出对话框的标题信息“选择样板”，则正确的XPath语句是“/DIALOG/CONTROL[1]/Texts_LIST/@Texts_00000”。类似地，对话框上各控件的位置、大小、属性等信息都可获取到。如图2中的截断错误，都用红色线框标示出来，提升了后期错误分析的效率。
3.3结果对比国际化软件自动化测试包括软件国际化测试和软件本地化测试。软件的国际化测试一般是英语版本的测试，必须在本地化测试之前进行。首先进行国际化软件测试有助于判断软件国际化的设计程度，确定软件支持的国家区域，以及本地化是否容易[9]。本地化测试过程中，以源程序软件结果（标准英语版本）作为本地化软件的主要参考。运行英语版本和本地化版本的结果比较程序，本地化版本对话框都将与标准英语版本对话框的各项信息进行对比。经对比本地化软件存在缺陷时有三大类情况：（1）本地化软件对话框的某项XML信息（控件的位置、大小、属性等）是空值；（2）本地化软件对话框的某项信息值的长度和标准英语版本的不一致；（3）本地化软件对话框的某项信息内容（控件的位置、大小、属性等）和标准英语版本的不一致。结果比较程序的部分示例：
3.4结果分析在实际的项目测试过程中，每一步都有很具体的内容。例如在报告测试结果的同时，实际上还包含了对测试结果的统计和分析，测试工程师通过对结果进行分析来判断是否存在缺陷，将缺陷上传至Test Desk网站进行管理。表1对话框界面的典型错误类型
Tab.1Typical error type of dialog user interface
软件测试报告范文4
关键词 计量自动化系统；性能测试；优化
中图分类号 TP311 文献标识码 A 文章编号 1673-9671-(2012)072-0112-01
随着科学技术的不断进步，电力自动化程度越来越高，特别现场电能量数据终端、大客户负荷控制终端、配变计量监测终端和集抄终端抄表系统的运行，更是让远程控制变成了现实，但是，这些远程系统是不是存在漏洞，各模块能不能协同作用，是不是存在冲突，能不能传输完整的数据、能不能对数据进行系统的分析等问题也向系统提出了要求，在这种情况下，认真进行电力行业各种自动化系统软件性能测试解析与优化，确保四分线损、供电质量、停电统计、预购电管理、错峰管理、负荷控制、拉合闸管理等功能模块之间能够协调有序进行，对于维护电力系统的正常运行，提高电力行业的综合竞争能力具有非常重要的现实意义。
1 计量自动化系统性能测试的目的
通过对计量自动化系统性能的测试不但可以发现软件存在的漏洞和缺陷，而且还可以验证系统软件在各种情况下的运行能力。电力用户的不断增加也给系统软件运行提出了要求，系统所能够承受的最大用户量也是电力行业必须充分了解的问题，通过计量自动化系统性能测试就可以解决这个问题。同时，通过针对性的系统软件测试还可以实现系统软件的性能优化，使系统软件能够在不同的条件下都能够稳定运行。
2 计量自动化系统性能测试的内容
在计量自动化系统运行过程中，软件的运行环境、软件的响应时间、软件长期运行的稳定性、软件所能支持的最大并发数以及系统在一定时间内所能够处理的信息量等内容都会给系统运行造成一定的影响，因此在进行计量自动化系统性能测试的过程中，就必须针对上面容易给系统造成影响的内容进行精确的性能测试，以避免软件的不启动、误操作或者非正常运行等状况发生。在测试过程中，我们主要是通过现场模拟，使用自动化测试工具对电力系统负载正常、负载异常以及峰值等阶段进行测试，从而判断计量自动化系统的各项性能指标是不是能够达到标准。
3 计量自动化系统性能测试解析与优化
作为一款系统软件行为与性能的测试产品，Load Runner主要包括VuGen（虚拟用户发生器）、Pressure regulation（压力调度）、Controller（监控中心）、Load Generator（压力生成器）、Analysis（结果分析工具）等。通过Load Runner就能够完成对计量自动化系统性能进行测试。其常规测试步骤如下：
1）对计量自动化系统性能进行测试，针对软件的运行环境、软件的响应时间、软件长期运行的稳定性、软件所能支持的最大并发数以及系统在一定时间内所能够处理的信息量等内容对系统运行造成的影响进行测试。
2）在操作计量自动化系统的前提条件下，通过VuGen记录生成相关虚拟用户脚本。
3）对脚本进行修改，确保脚本能够实现我完整回放。
4）在Controller内根据测试内容进行测试场景配制。其内容主要包括，电力虚拟用户数目、运行参数、电力用户的增长方式、软件测试的循环方式、安全退出、软件监视指标等。
5）执行测试。Controller通过Load Generator对被测试的系统软件产生一定的压力，施加一定的行为，然后对系统在测试过程中的数据进行收集，然后将数据传递到Controller，并让Controller进行数据汇总。
6）通过Analysis对汇总的数据进行分析，并在数据分析的基础上进行优化方案设计。
7）进行优化测试。尽管计量自动化系统模块众多，并且各模块执行的动作不同，但是进行软件测试和优化的程序大致相同，现在以采集模块的优化和测试进行说明。
4 制定采集模块作性能测试方案
4.1 确定采集模块作测试场景
采集模块作测试场景主要是模拟系统软件的实际运行场景，其主要内容包括运行参数、软件测试的循环方式、安全退出、软件监视指标等。在测试场景确定的过程中，要尽可能选择和采集模块作在实际运行过程中比较相似的接受四个数据终端数据的任务并发测试场景，从而充分了解采集模块作极限运行状态下的运行状况。
4.2 确定监视指标
在测试过程中，必须认真监视和服务器相对应的软件性能计数器，其监视的结果就是监视指标，通过监视指标不但能够进行结果分析，而且还可以寻找导致发生性能问题的根源。
5 执行采集模块性能测试方案
5.1 搭建采集模块性能测试环境
首先，要按照测试方案搭建一个独立、无病毒、相似性强的采集模块运行环境，然后安装调试采集模块，安装Load Runner；其次，准备测试数据。为了保证测试数据的合理性，测试数据通常从电力部门获取，如果是自己准备的数据，要分析数据的合理性，避免出现大量的垃圾信息，其数据必须确保软件能够按照流程正常运行。再次，在测试数据准备完成后，要及时进行数据库的备份。
5.2 编写或者录制测试脚本
测试脚本的生成既能够通过编写完成，又能够通过测试工具进行录制。不管是上述两种方式中的哪一种，所生成的测试脚本必须有效，这也就是说测试脚本能够充分反映系统软件的实际运行状况。
5.3 测试场景的布置
按照测定方案进行测试场景的布置。
5.4 执行测试
要想准确判断软件的实际运行能力，必须通过一定强度的测试，准确测定EAC（即电能量数据遥测终端）、集抄终端、负控终端和配变终端的使用效率，运行速度、稳定性。
在测试过程中，要认真测试不同压力下采集程序的定时采集数据的能力，以及负控、配变、集抄终端的主动连接和采集数据的能力；来自于每一个终端上报信息的时间、数据量以及数据的质量；任务调度程序和采集传输服务程序任务调度分发能力和负载均衡能力。
认真比对不同压力下信息采集的工作效率，进而对整个模块做出准确的判断，然后在测定系统各个模块的基础上实现对系统的测试。在测试过程中，不管是哪一个环节，都必须采用统一的标准，纠正任何一点偏差，否则就会导致测试失败。同时，还要注意外部环境对测试结果在成的影响。
6 生成并分析测试报告
测试报告是整个测试的结论性文件。系统开发人员要对测试报告中的相关数据进行分析，认真查找模块中存在的问题以及缺陷。在这个过程中，首先必须认真筛选出测试数据中的典型数据，然后认真分析数据，查找隐含在数据中的模块问题；其次，要认真分析问题发生的原因，在找出原因的基础上提出合理的解决或者优化方案。
7 小结
总之，通过软件性能测试，可以发现存在于计量自动化系统中的缺陷和漏洞，并进行纠正，这样就可以确保电力系统的远程控制的正常进行，真正实现电力计量自动化。
参考文献
[1]李军锋,任世鹤.软件可靠性及其测试分析[J].软件导刊,2010,09(08).
软件测试报告范文5
关键词:软件测试;案例教学;教学内容
中图分类号:TP311 文献标识码:A文章编号:1009-3044(2010)09-2275-02
Teaching Methods of Software Testing Technology
GAO Zhi-sheng
(School of Mathematic and Computer, Xihua University, Chengdu 610039, China)
Abstract: Software testing is a course that teaches the software testing methods and means. Case teaching methods that runs through the whole software testing process with a single case is proposed. The corresponding teaching contents and experiment requirements are also introduced. Through the teaching methods, the studying interesting, the initiative and the capability of finishing the practical software testing projects are really improved.
Key words: software testing; case teaching; teaching contents
软件开发过程中的质量问题是关系到软件和软件组织生存的重大问题,得到了越来越多的重视。目前在高校的软件工程专业普遍开设有软件测试相关课程。但是在具体教学实践中,教师普遍感觉到有许多不如意的地方[1],具体表现在教学内容与具体应用脱节,学生对软件测试认识有误区,学生学习积极性不强、认为软件测试是文字性课程,软件测试过程如何展开,如何选择测试工具,如何在教学中贯彻软件测试管理思想等。
近年来关于怎样进行软件测试教学,引起了相关专家的重视和讨论[1-4]。本文在总结前人的经验基础上,结合作者近几年在软件测试技术课程教学中的实践提出了以一个具体项目案例贯穿整个教学过程,理论与实践紧密结合的教学方法。
1 教学的目的和教学方法
软件测试技术课程是本校软件工程专业的一门专业必修课程,通过软件知识体系的学习,使学生了解软件测试的发展现状,认识软件测试的重要性,掌握软件测试的方法和技术,熟悉软件测试过程管理,从而具有独立承担软件测试项目的实施能力,具有测试计划、管理、实现和软件质量保障的能力[3]。
针对以上教学目的,我们在软件测试技术教学过程中引入一个具体测试项目案例贯穿整个教学过程的教学方法。第一课时,我们组织学生自由进行分组,每组5个人左右,每组确定一个名称。要求每个小组在课程的前几周完成同一个模拟题目“大学图书馆管理系统”的软件开发。系统完成后,然后各个小组交叉进行测试对方开发的软件系统。随着课程的进度,主要要求学生完成软件系统的单元测试,集成测试,功能测试和系统测试。单一的案例贯穿整个软件项目测试过程的案例教学方法的优点是:
1)软件测试的前期课程有“Java EE编程技术”,同时我们选择图书馆管理系统作为开发对象,学生从技术上和业务需求上都具备快速完成该系统的能力。
2)相同的开发对象,互相测试对方开发的系统,有利于形成竞争,有利于调动学生的学习积极性。同时也有利于教师对学生完成的结果进行点评和组织课堂讨论。
3)整个软件测试课程,学生能够完成对一个具体项目的全部测试过程,有利于促进学生系统地掌握软件测试的技术方法,组织和过程。
2 教学过程
我们的教学过程主要包括以下5个阶段,最初的几周主要讲解软件测试原理,同时这个阶段学生主要完成指定项目,然后是4个主要的软件测试技术:单元测试,集成测试,功能测试和性能测试。软件测试课程也会讲解其他如回归,压力等其它测试技术,下面是我们课程重点讲授的内容和要求。
2.1 软件测试原理
本阶段主要讲授软件测试技术的基本概念,使学生掌握基本的软件测试原理。包括软件测试的重要性,软件评测师的职业规划,软件质量的概念等基本概念,重点讲授的内容是白盒测试及用例的设计和黑盒测试及用例的设计两个章节。白盒测试主要包括逻辑覆盖和基本路径覆盖两种用例设计方法,逻辑覆盖又分为语句、判定、条件、判定/条件、组合、路径覆盖等。黑盒测试的重点内容是等价类划分,边界值分析,因果图,决策表和场景法。
本阶段对学生的实践要求是开发“大学图书馆管理系统”,由上课老师为学生统一提供系统的需求规格说明书,该系统的主要功能如图1所示。要求学生结合对本校图书借阅系统的使用和需求规格说明书,采用Java EE技术进行开发,系统采用典型的4层结构进行设计,如图2所示,即运行在客户端计算机上的客户层组件、运行在Java EE服务器上的Web层组件、业务层组件和运行在EIS服务器上的企业信息系统(EIS)层软件[4]。系统开发采用JSF+EJB3.0的架构,Glassfish为应用服务器,MySql提供数据库服务。
2.2 单元测试
单元测试是对软件最小组成单元的测试,是软件开发过程中进行的最基本的测试。单元测试主要按照程序内部的结构测试程序,检验程序中的每条通路是否都能按预定要求正确工作。单元测试主要考虑各个模块接口的输入和输出,模块内部的数据结构,模块的边界条件,模块的基本路径和模块的出错处理。单元测试阶段还讲授代码规范性检查,代码覆盖率的检查,代码复杂度的计算和内存泄漏的检查等。
完成单元测试的基本原理的学习后,要求学生交叉完成图书馆管理系统的单元测试,主要抽取系统中的核心函数进行测试。完成测试后要求每个小组提供单元测试计划,单元测试用例和单元测试报告3个报告文档。得到所有报告后,组织一次课堂讨论,展示优秀小组的成果,分析原因总结经验。单元测试工具要求采用JUnit,代码规范和代码质量分析采用Logitscope, Pruify用于分析代码的内存问题。
2.3 集成测试
软件各个单元通过单元测试之后,需要检查各个单元之间的相互接口是否正确,就是集成测试。软件集成测试主要考虑的问题是模块间的数据传递是否正确,一个模块的功能是否会对另一个模块的功能产生错误的影响,全局数据结构是否有问题,块组合起来的功能是否能满足要求,集成后累积误差是否被放大等[5]。关于软件集成测试的原则、策略和用例设计等相关原理可参考其它相关文献。
教授完集成测试相关原理后,我们要求每个小组负责人组织完成系统的集成测试。集成测试以一个EJB、Servlet或者JSF为基本单元,工具选择Cactus和HttpUnit。完成集成测试后要求每个小组提交集成测试计划、集成测试设计文档和集成测试分析报告。收齐所有小组成果,组织学生进行讨论。
2.4 功能测试
功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。主要考虑系统的各个功能,一般从软件产品的界面、架构出发,按照需求编写测试用例,测试产品时是否达到用户使用的需求。本阶段主要让学生采用WinRunner完成系统的功能测试,进行功能测试之前首先完成测试计划和测试用例的设计。然后完成WinRunner的6个步骤:识别程序的GUI,建立测试脚本,完善测试脚本,在新版应用程序执行测试脚本,分析测试结果和回报缺陷。
2.5 性能测试
典型的性能测试主要是从系统的响应时间、吞吐量、系统资源利用率、并发用户数、HTTP事务处理数/秒、会话数/秒和连接建立时间等方面衡量系统的性能。性能测试主要有压力测试,容量测试和强度测试等。针对图书馆管理系统的特点,我们要求学生理解性能测试的重要性和困难性,掌握性能测试的基本概念和技术。在此技术上,我们要求学生使用LoadRunner完成系统的压力测试。主要步骤是测试需求分析,制定测试策略和方案(重点是设计测试场景),使用VuGen创建脚本,在Controller中创建场景,运行场景,分析结果。完成后提交测试策略和方案报告,脚本和图书馆管理系统压力测试报告。
3 结论
一个合格的软件评测师要求具有编程能力、开发能力、沟通能力、管理能力、逆向思维能力等多种能力。怎样在大学软件测试技术教学中培养既有理论又能实践的软件测试从业人员是本文研究的动机。我们提出的基于同一案例贯穿整个软件测试技术教学过程的教学方法,通过学生互测对方开发的软件系统,相互对比,相互促进同时组织课堂讨论,有效营造了主动学习的气氛,增强了学生的学习积极性,培养了学生主动思考问题的能力。该方法是一个值得借鉴的软件测试技术教学方法。
参考文献:
[1] 李绘卓,唐峻,范勇.基于案例的软件测试实验教学[J].电脑知识与技术,2009,27(5):7820-7821.
[2] 屠红蕾.软件测试教学的点滴体会[J].计算机教育,2008(10):124-125.
[3] 李亚.“软件测试”教学探索与实践[J].计算机教育,2008(6):14-15.
软件测试报告范文6
关键词：软件测试；性能测试；LoadRunner
中图分类号：TP306 文献标识码：A 文章编号：1672-3198(2009)12-0296-02
1 软件性能测试
根据测试的目的和内容的不同，性能测试主要包括以下方面：
(1)负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
(2)强度测试：确定在系统资源特别低的条件下软件系统运行情况。
(3)容量测试：在用户可接受的响应范围内，确定系统可处理同时在线的最大用户数。
(4)压力测试：通过确定一个系统的瓶颈或者最大使用极限的测试。
(5)疲劳强度测试：以系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作强度性能的过程。
(6)大数据量测试：大数据量测试侧重点在于数据的量上，包括独立的数据量测试和综合数据量测试。独立的数据量测试针对某些系统存储，传输、统计、查询等业务进行大数据量测试，而综合数据量测试一般和压力性能测试、负载性能测试、疲劳性能测试相结合。
2 软件性能测试流程
2.1 测试方案设计
在软件性能测试的初始阶段，首先应对业务模型和系统架构进行调研，收集测试需求。然后生戚性能测试计划。业务调研和系统调研，需要性能测试团队提前了解被测试项目的业务功能和系统架构。其间。开发部门应协助提供被测系统相关的文档和说明，如系统总体介绍、系统规格书、用户使用手册、网络拓扑结构图和系统配置说明、关键服务器及应用部署与配置等文档。通过和业务部门协商明确本次测试针对哪些业务行为，制定此次测试的目标，细化测试的关注点和性能指标要求。通过以上内容制定详细的测试方案，并制定详细测试计划和各阶段目标。
2.2 测试环境的搭建
测试环境的搭建分为软硬测试系统的环境搭建和测试相关的数据准备工作。环境搭建包括被测试系统的硬件环境建立和软件应用系统建立及基础数据环境建立。保障被测试系统的业务可用性和功能的正确性，包括测试系统(如被测试项目的操作系统、中间件、数据库、压力测试控制台、压力测试发起工具等)的环境搭建、软件的安装；测试环境的网络环境建立(如开放防火墙和网关等)；最后进行测试环境可用性验证。测试数据准备包括测试应用系统基础数据准备，即需要按性能测试规模要求，准备足够的、一定规模的基础数据，通常采用全量恢复生产数据的方式以达到和生产环境数据一致性的要求。
2.3 测试场景开发
测试场景开发指测试程序(脚本)的开发。测试程序(脚本)的开发是对被测系统的用户业务行为进行模拟、录制、编程、参数化、脚本定制和调式等一系列工作，以使测试程序(脚本)可以真实模拟实际生产中的业务交易行为，并通过对程序中参数的配置实现对并发数、思考时间等属性的准确控制。
2.4 测试执行
测试执行是在测试方案的制定、测试环境准备、测试场景开发工作正确完成的基础上进行的。
2.5 测试报告和分析
性能测试报告和结果分析是在测试执行完成以后，对性能数据进行采集结果收集工作和针对性能测试过程中暴露的问题进行分析的阶段。性能测试报告是对性能测试过程中的监控结果以及报表进行汇总，按照一定的模板整理出的一份结论性文档。开发团队和性能测试团队应依据对性能测试实施过程中监控和记录的数据和表格，分析系统中存在的性能问题和程序缺陷。并有针对性的在报告中阐述问题、分析原因、提出解决或优化方案。
2.6 回归测试
回归测试是开发部门在性能测试报告的基础上针对软件的性能或者效率缺陷进行优化或者修复，为了验证优化的效果而进行的再测试。
3 软件性能测试工具LoadRunner
作为软件质量控制中的重要一环，性能测试已经越来越受到软件开发商和用户的重视，成为软件测试的重中之重。性能测试通常在系统测试阶段执行，常常与强度测试结合起来，一般需要使用测试工具。一个优秀的软件测试工具，不仅可以辅助测试工作，满足科学测试的基本要求；而且可以自动化测试过程，节约大量的时间、成本、人员和资源，提高软件产品的质量。目前市场上主要使用的测试工具有微软公司的WAS(Web Application Stress Tool)、Compuware公司的QALoad、RadView公司的WebRunner、HP(Mercury)公司的LoadRunner。下面以LoadRunner为例。介绍软件测试工具的工作流程。
LoadRunner是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能检测来确认和查找问题，能够对整个企业架构进行测试。通过使用LoadRunner，企业能够最大限度的缩短测试时间，优化性能和加速应用系统的周期。LoadRunner能支持广泛的协议和技术，功能比较强大，可以为特殊环境提供特殊的解决方案。LoadRunner由下面三部分组成：Virtual UserGenerator用来录制脚本、编辑脚本Controller用来布置测试场景、执行测试场景；Analysis用来对测试结果进行分析。
用LoadRunner进行负载测试的流程通常由五个阶段组成：计划、脚本创建、场景定义、场景执行、监视执行和结果分析。
(1)计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所响应时间；根据软件项目相关需求，定义相关测试的细节，撰写性能测试报告。
(2)创建Vuser脚本：将最终用户活动捕获到自动脚本中LoadRunner的脚本是C语言代码，LoadRunner有自己的一整套函数接口，可以供外部调用。脚本可分INIT、ACTION、END三部分，其中：INIT部分可以理解为初始部分。ACTION可以理解为事务部分，也是测试的主体，END是退出结束。
当录制完一个基本的用户脚本后，在正式使用前我们还需要完善测试脚本，增强脚本的灵活性。一般情况下，我们通过以下几种方法来完善测试脚本。插人事务、插入结合点、插入注解、参数化输入。
(3)定义场景：使用LoadRunner Controller设置测试环境；录制好脚本之后，就可以把脚本加入到场景里面去了，这里首先介绍一下LR的场景类型，LR有2种大的场景类
型。
①Manual Scenario：该项要完全手动的设置场景，这项下面还可以设置为每一个脚本分配要运行的虚拟用户的百分比，可在Controller的Scenario菜单下设置。
②Goal―Oriented Scenario,如果你的测试计划是要达到某个性能指标，比如：每秒多少点击。每秒多少transae，tions，能到达多少VU，某个Transaction在某个范围VU(5D。一1000)内的反应时间等等，那么就可以使用面向目标的场景。
(4)设置场景：
Design：设计测试场景的静态部分，设置模拟用户生成器、模拟用户数量、模拟用户组等。
Run：设计测试的动态部分，主要指添加性能计数器，在脚本运行的过程中可以通过这些计数器反馈的数据。
建立了测试场景后，我们可以对Edit_Schedule进行设置，设置测试开始执行的时问，对于手动设计的测试还可以设定它的持续时间，以及何时起用或禁止调用模拟用户。
(5)运行场景：通过LoadRunner Controller驱动、管理和监控负载测试。
设置完毕后，点击“开始方案”运行场景。在运行过程中，可以监视各个服务器的运行情况(DataBase Server、WebServer等)。监视场景通过添加性能计数器来实现，下列数据需要特别关注：
①Memory：Available Mbytes物理内存的可用数(单位Mbytes)至少要有10％的物理内存值。
⑦Processor：Processor Time CPU使用率。这是查看处理器饱和状况的最佳计数器。显示所有CPU的线程处理时间。如果一个或多个处理器的该数值持续超过90％，则表示此测试的负载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的O到x个实例。
③Processor Queue Length：是指处理列队中的线程数，小于2。处理器瓶颈时会导致该值持续大于2。
④Context Switches/sec；如果切换次数到5000*CPU个数和i0000*CPU个数中，说明它忙于切换线程。
⑤Network Interface：Bytes Total/sec为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。
