摘要：如同代码是程序员的成果之，软件测试报告是测试人员的丰要成果之一。一个好的软件测试报告建立在测试结果的基础之上，不仅要提供必要测试结果的实际数据，同时要对结果进行分析，发现产品中问题的本质，对产品质量进行准确的评估。本文详细说明一个软件测试报告究竟需要什么样的测试结果，需要对哪些结果进行归纳分析。
1
软件测试结果的内容
软件测试评估的目的是统计和分析测试结果，确定是否达到软件要求的指标。一般来说，首先需要分析实际测试执行的有效性和充分性，分析测试执行是否完全，软件问题的产生是否因为不符合测试的前提和约束；其次，统计测试过程中的所有软件缺陷，并将缺陷的各种属性进行归纳分析；最后，根据用例的执行情况对软件进行宏观的横向分析，确定软件缺陷的错误来源。
2
测试的有效性和充分性
评价软件测试有效性的主要目的是评价测试人员的工作和使用评价后的结果改进测试过程。在软件测试中，往往会存在一些无效的方面, 评价的目标就是识别这些无效和问题以便可以采取修复措施。
在测试的有效性评价工作中，存在两个关键的因素: 一是评估的目标，目标是对度量过程的恰当指导。无效的目标会使整个评价过程无效； 二是实现度量目标所需的信息类别, 信息的收集需要建立专门的小组，整个评价过程也应指派专门的人员负责，因为如果没有专人负责评价过程。那么就无法确保进行正确的数据收集和评估过程。
当所有的软件测试过程结束后，软件测试有效性评价工作就可以开始了，测试阶段的最终执行结果是它的入口条件，表1 列出了输入所需的一部分信息类型，根据具体项目的不同，也会产生其它的输入。
表
1测试有效性评价的输入信息
序号
输入的信息类型
1
执行的测试的数量
2
测试中消耗的资源
3
所使用的测试工具
4
发现的缺陷
5
被测试软件的规模
6
修复缺陷的天数
7
没有修复的缺陷
8
在操作中所发现的那些本该在测试中发现的缺陷
9
发现缺陷的阶段
10
所发现的缺陷的名称
我们可以通过一个实际的例子来看看有效性是如何实现的，表2列出了软件需求规格说明中常见的几个章节。针对每个需求首先验证是否包含了相应的测试类型，比如在容量和时间要求章节中，是否包含性能测试、强度测试和余量测试等。接下来，列出每个测试类型有多少个测试项进行支撑，通过这一点可以看出各个测试类型在本次测试中的优先级状态。最后，列出每个测试类型包含的测试用例数量，可以反映出需求的覆盖情况。
表
2 软件需求有效性和充分性说明
需求文档章节号
需求名称
测试类型
实际的测试项
设计的用例数
软件缺陷数
3.1
CSCI外部接口需求
接口测试
X
X
X
3.2
CSCI功能需求
功能测试
X
X
X
人机交互界面测试
X
X
X
3.3
CSCI内部接口
接口测试
X
X
X
3.4
CSCI数据元素要求
边界测试
X
X
X
3.5
适应性要求
/
/
/
/
3.6
容量和时间要求
性能测试
X
X
X
3.7
安全要求
安全性测试
X
X
X
3.8
保密要求
安全性测试
X
X
X
3.9
设计约束
代码走查
X
X
X
静态分析
X
X
X
3.10
软件质量因素
/
/
/
/
3.11
人的特性/人的工程需求
易用性测试
X
X
X
3.12
需求可追踪性
/
/
/
/
3
软件缺陷统计与分析
软件缺陷数是最直观反应软件质量好坏的标准，也是最难以分析的标准。由于测试人员的个体差异，测试环境的不可预知和诸多因素的存在，导致测试结果的不准确。正因为如此，所以不能单凭数量上的多少来衡量软件质量的好坏，而需要进行系统的归纳和分析。那么影响缺陷的指标有哪些呢？一般来说，包括缺陷发现的轮次、缺陷的严重级别、缺陷所属的测试类型和每千行代码所含的缺陷数等，如果是系统测试，还应包括缺陷所属的配置项等。简单的说，每个因素都决定了缺陷数一方面，但不完全决定缺陷的有效性。
根据多轮测试发现的缺陷数，可以了解测试的效率。
根据缺陷的严重级别，可以了解测试的深度。
根据缺陷所属的测试类型，可以了解测试的广度。
根据缺陷的缺陷类型，可以了解缺陷的来源。
通过对每千行代码所含的缺陷数分析，可以了解程序代码质量。
由于每个因素片面性的存在，下面就为读者介绍三种综合利用多种因素，全面考核软件质量的方法。
1.
软件测试缺陷按轮次和级别统计
根据轮次和级别进行分析，可以清晰地看出每轮测试时缺陷的严重程度，与其他配置项对比分析时，可以轻而易举的判断出在同一时刻下，各个配置项的质量好坏程度。
表
3 缺陷按轮次和级别统计
测试阶段
缺陷级别
首轮测试
第一轮回归测试
第二轮回归测试
总计
致命缺陷
2
1
0
3
严重缺陷
8
3
0
11
一般缺陷
25
12
0
37
建议缺陷
6
2
0
8
小计
41
18
0
59
图
1 缺陷按轮次和级别统计
1.
软件测试缺陷按所属测试类型和级别统计
根据缺陷所属的测试类型和级别进行分析，可以精确的将缺陷定位到每个测试类型中，从而反应出软件在哪些方面存在的较大质量问题。
表
4 软件测试缺陷按所属测试类型和级别统计
测试结果
测试类型
首轮测试
第一轮回归测试
第二轮回归测试
致命
严重
一般
建议
致命
严重
一般
建议
致命
严重
一般
建议
1
文档审查
0
0
2
0
0
0
0
0
0
0
0
0
2
功能测试
1
5
15
1
1
3
9
0
0
0
0
0
3
性能测试
0
1
1
0
0
0
0
0
0
0
0
0
4
边界测试
0
1
2
1
0
0
1
0
0
0
0
0
5
接口测试
1
0
2
0
0
0
1
0
0
0
0
0
6
人机交互
界面测试
0
1
3
4
0
0
1
2
0
0
0
0
7
安装性测试
0
0
0
0
0
0
0
0
0
0
0
0
8
总计
2
8
25
6
1
3
12
2
0
0
0
0
图
2 软件测试缺陷按所属测试类型和级别统计
1.
软件测试缺陷按缺陷类型和轮次统计
根据缺陷类型和轮次进行分析，可以将软件缺陷定位到代码层面，通过多轮的对比，从而可以看出软件修改过程中的修改趋势，可以有效避免错误的发生。
表
5 软件测试缺陷按缺陷类型和轮次统计
测试阶段
缺陷类型
首轮测试
第一轮回归测试
第二轮回归测试
总计
程序缺陷
20
12
0
32
文档缺陷
1
0
0
1
设计缺陷
19
6
0
25
其它缺陷
1
0
0
1
小计
41
18
0
59
4
测试用例执行情况
测试用例的执行情况能够反应测试人员在执行测试的过程中，软件质量对软件在实际应用中产生的效果。与软件缺陷不同的是，缺陷反应的是一种现象和问题，而用例的执行情况则反应的是软件实际操作的使用难度。一个缺陷影响一个用例和一个缺陷影响多个用例，是两个完全不同的概念，所以用例的通过率是用户真正关心的数据。
在用例执行情况中，根据每轮测试的结果，可以分别对用例总数、执行用例总数、未执行用例数、通过数、未通过数和通过率等指标进行考核。用例总数代表了本次测试设计的用例总数，执行用例总数代表了本轮测试需要执行的用例总数，未执行用例数则是前两者的差数。而通过数、未通过数和通过率则反应了本轮测试用例的通过情况。
表
6 用例执行结果统计
5
总结
传统的软件测试，只针对软件产品开展，找到缺陷之后再加以改正和修补，这是一种“亡羊补牢”的质量管理方式。而针对开发全过程所开展的软件测试和过程度量，则注重事先分析，通过对已发生的数据对比、统计、时间序列等分析，来判断软件产品质量的未来趋势，并提前予以控制和预防，属于一种“防忠于未然”的质量管理方式。对测试的结果进行整理、归纳和分析，可以借助于Excel文件、数据库和一些直方图、圆饼图、趋势图来进行分析和表示，并通过对比分析、根本原因查找、问题分类、趋势分析和其他统计分析等来实现。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
