系统测试报告参考文档.docVIP

. . . . 整理 系统测试报告 1 系统测试报告写作的目的 1、软件测试人员对整个系统测试工作进行总结，对被测试对象进行评估，并对以后的测试工作给出建议 2、测试经理通过测试报告了解被测试产品的质量情况、测试过程的质量 3、软件开发项目经理通过软件测试报告了解开发产品的质量情况，并在下阶段的开发工作中采取应对措施 4、在软件测试报告中，软件测试人员作出的软件产品质量评估，可以作为软件产品是否对外发布的重要参考依据。 2 系统测试报告写作的要点 2.1 概述 简单介绍被测对象、测试特性及其版本/修订级别情况 指明本次系统测试活动所依据的测试计划、测试方案、测试用例及测试过程，对测试内容也要进行简要说明 2.2 测试时间、地点、人员 描述本次测试的时间，地点和测试人员，以及人员分工。 例如： 版本名称 测试时间 测试人员 测试地点 起始时间 结束时间 2.3 环境描述 描述本次测试的环境，包括软硬件、测试仪器、组网图等。 例如： 硬件环境 软件环境 名称 型号 大小 个数 名称 版本号 CPU 操作系统 内存 应用软件 硬盘 数据库 2.4 总结和评价 2.4.1 测试过程质量统计评估 1、工作量数据统计 例如： 模块/特性 规模 投入人时 投入人时/KLOC 合计 分析： 1）可以根据不同模块每千行代码投入的工作量来查看哪些模块测试比较充分；哪些模块测试不够充分。 2）结合模块的实际情况，对关键模块或者复杂模块投入的测试人时比例应相对较高；对非关键或者简单的模块投入的测试人时比例可以相对较低，根据该指标可以用来衡量测试过程中测试资源的分布是否合理。 2、用例数统计 例如： 模块 规模(KLOC) 用例数 用例数/KLOC% 合计 分析： 1）可以根据用例数/KLOC来查看哪些模块用例设计的比较充分；哪些模块用例设计的相对比较少，结合模块的具体特点，需要进行分析，避免关键模块用例设计不充分的情况。 2）可以根据不同模块用例数来了解不同测试人员的工作量；结合时间方面的数据，对工作量少而花费时间较多的情况进行调查分析，对其中存在的问题采取相关策略进行有效的规避。 3、用例对需求的覆盖率 例如： 需求id 用例数 合计 分析： 从需求的覆盖率来查看不同的需求对应的用例数，可以考量不同需求测试的程度： 1）对于重要的关键的需求，应该设计比较充分的用例； 2）对于功能比较简单的需求，可以设计相对少的用例； 3）对于没有用例对应的需求，一定要调查相关负责人员的工作情况，避免工作中的不认真导致的测试的不全面性。 4、用例的稳定性 例如： 模块/特性 用例数 变更用例数 变更用例数/用例数％ …… 合计 分析： 根据每个模块设计的用例的稳定性来判断： 对个别变更比例比较高的模块要进行调查分析，看变更的原因在哪里？是开发的文档发生了变更，还是由于测试方面理解发生了偏差导致的变更。 1）如果是开发方面变更频繁，需要反馈给开发方面； 2）如果是后者，测试方面需要分析导致这个偏差产生的原因是客观的还是主观的；要采取相应的措施进行规避。 5、用例的有效性 例如： 模块/特性 用例数 发现的缺陷数 缺陷数/用例数 合计 分析： 根据每个模块对应的平均用例缺陷数来判断用例设计的水准： 1）如果模块对应的该值比较高，可以认为： 该模块质量比较差 用例设计的质量比较高 2）如果模块对应的该值比较低，可以认为： 该模块的质量比较好 用例设计的质量一般 总之，对于上面的各种情况，必须调查验证，对有问题的情况进行改善控制。 6、测试执行的效率： 例如： 模块特性 执行用例数 发现缺陷数 人时 执行用例数/人时 发现缺陷数/人时 …… 合计 分析：根据不同的模块查看不同测试人员的执行效率： 1）个别模块执行效率很高，考虑 测试人员对工作比较负责，积极，或者使用了比较好的测试技术； 测试人员测试的比较马虎，用例执行可能存在应付现象。 2）个别模块执行效率不高，考虑 测试人员测试方法存在问题，或者能力有限，考虑是否需要帮助 对应的模块测试难度较大，属客观因素。 总之，对于上面的各种情况，必须调查验证，对有问题的情况进行改善控制。 2.4.2 1、版本缺陷统计 例如： 模块/特性 版本1(缺陷个数) 版本2(缺陷个数) 版本3(缺陷个数) 合计(缺陷个数) …… 合计 分析： 根据不同版本缺陷的收敛状态来观察软件的质量 如果缺陷收敛的比较快，可以考虑系统中的缺陷主要在模块或者函数内部生成，接口方面的缺陷相对较少，一个模块的修改不会引发其他模块的问题；可以认为软件产品质量相对比较容易控制； 如果缺陷收敛的比较慢，可以考虑系统中的