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