1、系统测试报告1 系统测试报告写作的目的1、软件测试人员对整个系统测试工作进行总结，对被测试对象进行评估，并对以后的测试工作给出建议2、测试经理通过测试报告了解被测试产品的质量情况、测试过程的质量3、软件开发项目经理通过软件测试报告了解开发产品的质量情况，并在下阶段的开发工作中采取应对措施4、在软件测试报告中，软件测试人员作出的软件产品质量评估，可以作为软件产品是否对外发布的重要参考依据。2 系统测试报告写作的要点2.1 概述简单介绍被测对象、测试特性及其版本/修订级别情况指明本次系统测试活动所依据的测试计划、测试方案、测试用例及测试过程，对测试内容也要进行简要说明2.2 测试时间、地点、人员描
2、述本次测试的时间，地点和测试人员，以及人员分工。例如：测试时间版本名称起始时间 结束时间 测试人员 测试地点2.3 环境描述描述本次测试的环境，包括软硬件、测试仪器、组网图等。例如：硬件环境 软件环境名称 型号 大小 个数 名称 版本号CPU 操作系统内存 应用软件硬盘 数据库2.4 总结和评价2.4.1 测试过程质量统计评估1、工作量数据统计例如：模块/特性 规模 投入人时 投入人时/KLOC合计分析：1）可以根据不同模块每千行代码投入的工作量来查看哪些模块测试比较充分；哪些模块测试不够充分。2）结合模块的实际情况，对关键模块或者复杂模块投入的测试人时比例应相对较高；对非关键或者简单的模块投
3、入的测试人时比例可以相对较低，根据该指标可以用来衡量测试过程中测试资源的分布是否合理。2、用例数统计例如：模块 规模(KLOC) 用例数 用例数/KLOC%合计分析：1）可以根据用例数/KLOC 来查看哪些模块用例设计的比较充分；哪些模块用例设计的相对比较少，结合模块的具体特点，需要进行分析，避免关键模块用例设计不充分的情况。2）可以根据不同模块用例数来了解不同测试人员的工作量；结合时间方面的数据，对工作量少而花费时间较多的情况进行调查分析，对其中存在的问题采取相关策略进行有效的规避。3、用例对需求的覆盖率例如：需求 id 用例数合计分析：从需求的覆盖率来查看不同的需求对应的用例数，可以考量不
4、同需求测试的程度：1）对于重要的关键的需求，应该设计比较充分的用例；2）对于功能比较简单的需求，可以设计相对少的用例；3）对于没有用例对应的需求，一定要调查相关负责人员的工作情况，避免工作中的不认真导致的测试的不全面性。4、用例的稳定性 例如：模块/特性 用例数 变更用例数 变更用例数/用例数合计分析：根据每个模块设计的用例的稳定性来判断：对个别变更比例比较高的模块要进行调查分析，看变更的原因在哪里？是开发的文档发生了变更，还是由于测试方面理解发生了偏差导致的变更。1）如果是开发方面变更频繁，需要反馈给开发方面；2）如果是后者，测试方面需要分析导致这个偏差产生的原因是客观的还是主观的；要采取相
5、应的措施进行规避。5、用例的有效性例如：模块/特性 用例数 发现的缺陷数 缺陷数/用例数合计分析：根据每个模块对应的平均用例缺陷数来判断用例设计的水准：1）如果模块对应的该值比较高，可以认为：该模块质量比较差用例设计的质量比较高2）如果模块对应的该值比较低，可以认为：该模块的质量比较好用例设计的质量一般总之，对于上面的各种情况，必须调查验证，对有问题的情况进行改善控制。6、测试执行的效率： 例如：模块特性 执行用例数 发现缺陷数 人时 执行用例数/人时 发现缺陷数/人时合计分析：根据不同的模块查看不同测试人员的执行效率：1）个别模块执行效率很高，考虑测试人员对工作比较负责，积极，或者使用了比较
6、好的测试技术；测试人员测试的比较马虎，用例执行可能存在应付现象。2）个别模块执行效率不高，考虑测试人员测试方法存在问题，或者能力有限，考虑是否需要帮助对应的模块测试难度较大，属客观因素。总之，对于上面的各种情况，必须调查验证，对有问题的情况进行改善控制。2.4.2 软件产品质量统计评估1、版本缺陷统计例如：模块/特性 版本 1(缺陷个数) 版本 2(缺陷个数) 版本 3(缺陷个数) 合计(缺陷个数)合计分析：根据不同版本缺陷的收敛状态来观察软件的质量如果缺陷收敛的比较快，可以考虑系统中的缺陷主要在模块或者函数内部生成，接口方面的缺陷相对较少，一个模块的修改不会引发其他模块的问题；可以认为软件产
7、品质量相对比较容易控制；如果缺陷收敛的比较慢，可以考虑系统中的缺陷主要在模块的接口处产生，一个 bug的修改，可能对多个模块产生影响，从而引入新的 bug；可以认为软件产品的质量控制相对困难。另外，通过这个指标，也可以考核测试组对每个版本测试的充分性，但在前面测试过程控制的前提下，这个指标主要用来衡量软件的质量水平。2、缺陷等级统计例如：模块/特性 致命 严重 一般 提示 合计合计分析：根据不同的模块来查看缺陷的严重性。对于等级相对比较严重的问题要进行分析，了解问题产生的原因，并考虑有没有比较好的方式进行规避。对于严重问题比较多的模块，要结合开发人员的能力，工作态度和模块的难度考虑，考虑任务安
8、排的合理性。3、测试用例的通过率例如：模块/特性 Passed Failed BLOCK No Run N/A 合计 用例通过率合计分析：假设测试过程质量得到有效控制的前提下：在最后一个回归测试版本中，对用例的通过率的衡量可以考核软件产品质量的等级1）对于未通过的用例点需要分析，看对软件产品质量的影响达到什么级别2）对于遗留的问题，需要分析遗留的主观和客观原因，考虑在以后的版本中是否可以进行规避。4、缺陷原因分布：例如：缺陷/原因 致命 严重 一般 提示 合计需求设计编码合计分析：根据缺陷的分布来分析研发过程的规范性如果在需求及设计阶段发现的缺陷较多，需要考虑相关过程的质量控制是否严格如果在需
9、求及设计阶段发现的缺陷很少，可以认为过程的质量控制比较有效2.4.3 系统测试综合评价1、对测试过程综合评价：从测试的充分性，效率，质量，协作等多个方面进行评价，重点在于暴露测试过程中的问题，并提出相应的改进策略。2、对被测模块/特性综合评价：从软件产品的系统功能、业务正确性、安全性，可用性，可维护性，性能，可靠性等多个方面作出客观评价。测试对象的整体质量：A：质量稳定，适合大规模应用；B：存在少数严重问题，但有规避措施，可以使用；C：基本功能可用，但问题较多 D：基本功能不可用2.5 系统测试遗留问题报告遗留问题是指测试过程中发生的并且在测试报告时仍没有得到解决的测试问题。测试报告时已经得到解决，并已经过回归验证的测试问题不记入其中。可对遗留问题数和级别进行统计。要列出每个遗留问题的详细情况，包括问题单号、问题级别、详细描述、问题分析与处理措施等。例如：问题总数 致命问题 严重问题 一般问题 提示问题 其他统计项数目百分比遗留问题详细信息参见TurboShop Defect Report2.6 附件交付的系统测试工作产品可以包括但不限于以下部分：测试计划测试方案测试用例测试规程测试日志缺陷报告测试输入及输出数据测试工具 测试代码及设计文档系统测试项目通过情况清单（测试记录）修改、添加的系统测试方案或测试用例
