软件测试和质量分析报告¶
第 14 章¶
软件测试和质量分析报告¶
当测试执行快要结束时，就要考虑对测试工作进行总结，编制测试报告。借助测试报告，公司管理人员和用户就能够了解该项目的测试是如何进行的，确定软件产品是否得到足够的测试以及对测试结果是否满意等。测试报告的写作是一项关键的工作，需要对整个测试过程进行检查、评估和分析，并对当前的软件产品质量也要进行评估，从而针对产品是否达到发布的质量给出结论。在对软件产品及其测试进行评估的过程中，经常通过询问下列问题以彻底地了解测试所执行的情况。
类似这些问题都得到肯定的答案之后，说明测试比较充分，测试工作基本完成。只有确认系统得到了充分的测试之后，针对测试结果所做出的分析才有很好的可靠性和准确性，测试人员对自己所得出的结论才有足够的信心。要写好测试报告，问题就归结为 —— 如何对测试过程和结果进行科学的、恰当的评估？
14.1 软件产品的质量度量¶
在讨论软件产品质量度量之前，先简单了解一下软件度量的基本概念、内容和方法。软件度量是根据一定的规则，将数字或符号赋予系统、构件、过程等实体的特定属性，从而能清晰地理解该软件实体及其属性的量化表示。简而言之，软件度量就是对软件所包含的各种属性的量化表示。软件度量可以提供深入了解软件过程和产品的衡量指标，使组织能够更好地做出决策以达成目标，软件度量具有如下作用。
所以说，软件度量是用来衡量软件过程质量和进行软件过程改进的重要手段。但是，为了保持数据的可靠性、客观性和准确性，必须保证度量结果不用于评价数据提供者的个人工作绩效或素质。
14.1.1 软件度量及其过程¶
软件度量一般可分为软件过程度量、项目度量和产品质量度量，本节主要讨论产品质量度量。针对软件产品的质量度量，会建立在软件产品的规模度量、复杂度度量和缺陷度量的基础上。
根据度量目标、内容和要求的不同，度量活动可能涉及一个项目的所有人员，也可能会包括各种活动的数据的收集与分析。软件度量的根本目的是通过量化的分析和总结，提高软件开发效率，降低软件缺陷和开发成本，提高软件产品质量。为了说明软件度量的过程，这里以目标驱动的度量活动为例。目标驱动的软件度量过程主要包括以下 5 个阶段。
①要素：定义收集活动和分析活动所需要的数据要素与收集表格。
② 过程：定义数据收集活动的形式、角色及数据的存储。
③ 分析反馈过程：定义对数据的分析方法和分析报告的反馈形式。
④ IT 支持体系：定义 IT 支持设备和工具，以协助数据收集和存储、分析。
（3）搜集数据。根据度量过程的定义，借助 IT 基础设施（或支持工具）进行数据收集工作，并按指定的方式审查和存储。在规定的度量活动完成（或阶段性的度量活动完成）后，度量小组获得数据收集的结果。
（4）数据分析与反馈。根据数据收集结果，度量小组按照已定义的分析方法进行数据分析，完成规定格式的图表，向相关的管理者和数据提供者进行反馈。
(5) 过程改进。根据度量的分析报告，管理者确定软件开发活动与计划之间是否有偏差，以便控制其执行；或者基于度量数据做出其他决策，这些决策可能包括滚动计划、纠正活动等。
其中，“识别目标” 和 “定义度量过程” 是保证成功搜集数据和分析数据的先决条件，是度量过程最重要的阶段；“过程改进” 是度量的最终目的。
对于软件度量过程而言，在改进过程中也评估度量过程自身的完备性。度量核心小组根据本次度量活动所发现的问题，将对度量过程做出变革，以提高度量活动的效率，或者更加符合组织的商业目标。
有效软件度量的属性¶
（1）简单的和可计算的。学习如何导出度量值应该是相对简单的，并且其计算不应该要求过多的工作量和时间。
（2）经验和直觉上有说服力。度量应该符合软件工程师对于软件过程和产品的直觉概念，如测度模块内聚性的度量值应该随着内聚度的提高而提高。
（3）一致的和客观的。度量不会产生二义性的结果，任何独立的第三方使用该软件的相同信息能够得到相同的度量值。
（4）在其单位和维度的使用上是一致的。度量的数学计算应该使用不会导致奇异单位组合的测度。例如，把项目队伍的人员乘以程序中的编程语言的变量会引起一个直觉上没有说服力的单位组合。
（5）编程语言独立的。度量应该基于分析模型、设计模型或程序本身的结构，而不依赖于编程语言的句法和语法。
(6) 质量反馈的有效机制。度量会为软件开发效率、产品质量等提供积极的信息。
14.1.2 软件质量的度量¶
客户需求是软件质量度量的基础，不符合客户需求的软件就没有质量。定量的软件评估就是基于这样的原则来通过数学模型来实现，也就是尺度度量 (Metrics Measurement) 的方法，这种定量度量适用于一些能够直接度量的特性，包括软件可靠性度量、复杂度度量、缺陷度量和规模度量，如程序出错率可定义为每千行代码 (Kilometer Lines of Code,KLOC) 所含有的 Bug 数。为了进行质量度量，需要根据质量模型 (McCall 模型、Boehm 模型或 ISO 9126 模型，如 2.1.1 节描述) 来准备足够的数据，然后进行产品质量的量化评估分析。
（1）明确性、正确性、可理解性、完全性、可验证性、一致性、简洁性、可追踪性、可修改性、精确性和可复用性的数据。这些数据可以用来评价分析模型和相应的质量表现特征。
(2) 公开的可能缺陷数与报告总缺陷数的对比则可以用来评价测试精确度和测试覆盖度，同时也可以预测项目发布时间。
(3) 产品发布前清除的缺陷数在总缺陷数中所占的百分比，有助于评估产品的质量。
（4）按严重缺陷、子系统缺陷来划分，分类统计出平均修复时间，这样将有助于规划纠正缺陷的工作。
（5）利用测试的统计数据，估算可维护性、可靠性、可用性和原有故障总数等数据。这些数据将有助于评估应用软件的稳定程度和可能产生的失败。
根据质量模型和上述观点，就可以用下列带加权因子的回归公式来度量质量:
\(M_{i}\) 是一个软件质量因素（如 SQRC 层各项待计算值）， \(f_{n}\) 是影响质量因素的度量值（如 SQDC 层各项估计值）， \(c_{n}\) 是加权因子。部分度量值可以获得统计数据结果，还有部分的度量值较难得到准确的量化值，要靠经验估算，如通过检查表的形式，让专家给这些特定属性打分。
14.1.3 质量度量的统计方法¶
质量度量的统计方法，是对质量评估量化的一种比较常用的方法，主要包含以下步骤。
为了说明这一过程，假定软件开发组织收集了为期一年的缺陷信息。有些错误是在软件开发过程中发现的，其他缺陷则是在软件交付给最终用户之后发现的。尽管发现了数以百计的不同类型的错误，但是所有错误都可以追溯到下述原因中的一个或几个。
为了使用质量度量的统计方法，需要收集上述各项数据，如表 14-1 所示，表中显示 IES、MCC、EDR 和 IET 占所有错误的近 62%, 是影响质量的几个主要原因。但如果只考虑那些严重影响产品质量的因素时，少数的主要原因就变为 IES、EDR、PLT 和 EDL。一旦确定了什么是少数的主要原因 (IES、EDR 等), 软件开发组织就可以集中在这些领域采取改进措施，质量改善的效果会非常明显。例如，为了减少与客户交流不够所产生的误解 (改正 MCC), 在产品规格设计说明书中尽量不用专业术语，即使用了专业术语，也要定义清楚，以提高文档的质量和沟通的效率。再比如，为了改正 EDR (数据表示有错), 不仅采用 CASE 工具进行数据建模，而且对数据字典、数据设计要实施严格的复审制度。
表 14-1 质量度量的统计数据收集
| 总计( $E_i$ ) | 严重( $S_i$ ) | 一般( $M_i$ ) | 微小( $T_i$ ) | |||||
| 错误 | 数量 | 百分比 | 数量 | 百分比 | 数量 | 百分比 | 数量 | 百分比 |
| IES | 296 | 22.3% | 55 | 28.2% | 95 | 18.6% | 146 | 23.4% |
| MCC | 204 | 15.3% | 18 | 9.2% | 87 | 17.0% | 99 | 15.9% |
| IDS | 64 | 4.8% | 2 | 1.0% | 31 | 6.1% | 31 | 5.0% |
| VPS | 34 | 2.6% | 1 | 0.5% | 19 | 3.7% | 14 | 2.2% |
| EDR | 182 | 13.7% | 38 | 19.5% | 90 | 17.6% | 54 | 8.7% |
| IMI | 82 | 6.2% | 14 | 7.2% | 21 | 4.1% | 47 | 7.5% |
| EDL | 64 | 4.8% | 20 | 10.3% | 17 | 3.3% | 27 | 4.3% |
| IET | 140 | 10.5% | 17 | 8.7% | 51 | 10.0% | 72 | 11.6% |
| IID | 54 | 4.1% | 3 | 1.5% | 28 | 5.5% | 23 | 3.7% |
| PLT | 87 | 6.5% | 22 | 11.3% | 26 | 5.1% | 39 | 6.3% |
| HCI | 42 | 3.2% | 4 | 2.1% | 27 | 5.3% | 11 | 1.8% |
| MIS | 81 | 6.1% | 1 | 0.5% | 20 | 3.9% | 60 | 9.6% |
| 总计 | 1330 | 100% | 195 | 100% | 512 | 100% | 623 | 100% |
当与缺陷跟踪数据库结合使用时，可以为软件开发周期的每个阶段计算其 “错误指标”。针对需求分析、设计、编码、测试和发布各个阶段，收集到以下数据。
\(E_{i}=\) 在软件工程过程中的第 i 步中发现的错误总数
\(S_{i}=\) 严重错误数
\(M_{i}=\) 一般错误数
\(T_{i}=\) 微小错误数
\(P_{i}=\) 第 i 步的产品规模 (LOC、设计说明、文档页数)
\(W_{s}\) 、 \(W_{m}\) 、 \(W_{t}\) 分别是严重、一般、微小错误的加权因子，一般建议取值为 \(W_{s}=10\) 、 \(W_{m}=3\) 和 \(W_{t}=1\) ，作者建议取值为 \(W_{s}=0.6\) 、 \(W_{m}=0.3\) 和 \(W_{t}=0.1\) （构成 100%）。所以每个阶段的错误度量值可以表示为 \(PI_{i}\) ：
最终的错误指标 \(E_{P}\) 通过计算各个 \(PI_{i}\) 的加权效果得到，考虑到软件测试过程中越到后面发现的错误其权值越高，简单用 1,2,3,… 序列表示，则 \(E_{P}\) 为：
错误指标与表 14-1 中收集的信息相结合，可以得出软件质量的整体改进指标。
质量度量的统计方法告诉我们：将时间集中用于主要的问题解决之上，首先就必须知道哪些是主要因素，而这些主要因素可以通过数据收集、统计方法等分离出来，从而可以更快地提高产品质量。实际上，大多数严重的缺陷都可以追溯到少数的根本原因之上，常常和人们的直觉也是比较接近的，但是很少有人花时间收集数据以验证他们的直觉。
14.2 评估系统测试的覆盖程度¶
为什么要做软件测试评估呢？如果没有测试评估，就没有测试覆盖率的结果，就没有报告测试进程的根据。软件测试评估主要有以下两个目的。
测试评估是软件测试的一个阶段性的结论，以确定测试是否达到完全和成功的标准。测试评估可以说贯穿整个软件测试过程，可以在测试的每个阶段结束前进行，也可以在测试过程中的某一个时间进行。
系统的测试活动建立在至少一个测试覆盖策略基础上，而覆盖策略试图描述测试的一般目的，指导测试用例的设计。如果测试需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度评测的量化指标。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 90% 的性能测试需求。测试评估工作主要是对测试覆盖率的评估，测试覆盖率是衡量测试完成多少的一种量化的标准。
测试的覆盖率，可以用测试项目的数量和内容进行度量。除此之外，如果测试软件的数量较大，还要考虑数据量。测试的覆盖率，可以根据如表 14-2 所示测试指标进行评价。通过检查这些指标达到的程度，就可以度量出测试内容的覆盖程度。
表 14-2 测试覆盖程度表
| 测试覆盖项 | 测试覆盖率指标测试描述 | 测试结果 |
| 界面覆盖 | 符合需求(所有界面图标、信息区、状态区) | |
| 静态功能覆盖 | 功能满足需求 | |
| 动态功能覆盖 | 所有功能的转换功能正确 | |
| 正常测试覆盖 | 所有硬件软件正常时处理 | |
| 异常测试覆盖 | 硬件或软件异常时处理(不允许的操作) | 测试结束判断 |
对测试覆盖率的评估就是要确定测试执行的完全程度，其基本方法有基于需求的测试覆盖评估和基于代码的测试覆盖评估。
14.2.1 对软件需求的估算¶
在讨论基于需求的测试覆盖评估之前，首先讨论对软件需求的估算。软件需求的估算有利于对测试需求的把握，进一步有利于测试覆盖率的估算。
假设在一个规格设计说明书中有 R 个需求，其功能需求的数目为 F, 非功能需求数 (如性能) 为 N, 则: \(R = F + N\) 。为了确定需求的确定性，一种基于复审者对每个需求解释的一致性的度量方法为:
其中， \(Q_{1}\) 表示需求的确定性，M 是所有复审者都有相同解释的需求数目。当需求的模糊性越低时， \(Q_{1}\) 的值越接近 1。而功能需求的完整性 \(Q_{2}\) 则可以通过计算以下比率获得：
其中， \(F_{u}\) 是唯一功能需求的数目， \(N_{i}\) 是由规格设计说明书定义的输入个数， \(N_{s}\) 是被表示的状态的个数。 \(Q_{2}\) 只是测度了一个系统所表示的必需的功能百分比，但是它并没有考虑非功能需求。为了把这些非功能需求结合到整体度量中以求完整，必须考虑已有需求已经被确认的程度。这可以用 \(Q_{3}\) 来表示：
其中， \(F_{c}\) 是已经确认为正确的需求的个数， \(F_{nv}\) 是尚未被确认的需求的个数。
14.2.2 基于需求的测试覆盖评估¶
基于需求的测试覆盖评估是依赖于对已执行 / 运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率：测试的目标是确保 100% 的测试用例全部成功地执行。如果这个目标不可行或不可能达到，则要根据不同的情况制定不同的测试覆盖标准。主要考虑风险和严重性、可接受的覆盖百分比。
在执行测试活动中，评估测试用例覆盖率又可以分为以下两类测试用例覆盖率估算。
（1）确定已经执行的测试用例覆盖率，即在所有测试用例中有多少测试用例已被执行。假定 \(T_{x}\) 为已执行的测试过程数或测试用例数， \(R_{ft}\) 是测试需求的总数：
（2）确定成功的测试覆盖，即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试，假定 \(T_{s}\) 是已执行的完全成功、没有缺陷的测试过程数或测试用例数。
在实际过程中，很难确定 \(R_{\mathrm{ft}}\) 的值，可以根据需求点、以往经验来估算。
14.2.3 基于代码的测试覆盖评估¶
基于代码的测试覆盖评测是对被测试的程序代码语句、路径或条件的覆盖率分析，它对于安全至上的系统来说非常重要。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已经定义。
基于代码的测试覆盖通过以下公式计算：
其中， \(T_{c}\) 是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数， \(T_{nc}\) 是代码中的项目总数。
基于代码的测试覆盖评测一般都是通过相应的工具来完成的，即根据测试运行时所走过的程序路径来计算测试的代码覆盖率，程序能识别哪些代码行、哪些分支或条件、哪些程序路径等被测试过，从而根据整个程序的相应值计算代码行、分支 / 条件和路径等测试覆盖率。如使用 Rational PureCoverage 能自动找出代码中未经测试的代码，获得代码测试覆盖率，还可针对每次测试生成全面的覆盖率报告，可以归并程序多次运行所生成的覆盖数据，并自动比较测试结果，以评估测试进度。还有很多测试覆盖率分析工具，如:
14.3 基于缺陷分析的产品质量评估¶
质量是反映软件与需求相符程度的指标，而缺陷被认为是软件与需求不一致的某种表现，所以通过对测试过程中所有已发现的缺陷进行评估，可以了解软件的质量状况。也就是说，软件缺陷评估是评估软件质量的重要途径之一，软件缺陷评估指标可以看作是量度软件质量的重要指标，而且缺陷分析也可以用来评估当前软件的可靠性，并且预测软件产品的可靠性变化，缺陷分析在软件可靠性评估中也起到相当大的作用。
软件缺陷评估的方法相对比较多，从简单的缺陷计数到严格的统计建模，质量度量的统计方法就是一个例子。通常，软件缺陷评估模型假设缺陷的发现是呈泊松分布的，则有关缺陷率的实际数据可以适用于这一模型，但更严格的缺陷评估要考察在测试过程中发现缺陷的实际间隔时间。基于缺陷分析的产品质量评估方法有以下几种。
14.3.1 缺陷评测的基线¶
软件评估首先要建立基线，为软件产品的质量设置起点，在基线的基础上再设置新的目标，作为对系统评估是否通过的标准。
缺陷评测的基线是对某一类或某一组织的结果的一种度量，这种结果可能是常见的或典型的，如 10 000 行源程序是程序规模的一个基准，每一千行代码有三个错误是测试中错误发现率的基准。基准对期望值的管理有很大帮助，目标就是相对基准而存在的，也就是定义可接受行为的基准，如表 14-3 所示。
表 14-3 某个软件项目基准和目标
| 条目 | 目标 | 低水平 |
| 缺陷清除效率 | >95% | <70% |
| 原有缺陷密度 | 每个功能点<4 | 每个功能点>7 |
| 超出风险之外的成本 | 0% | ≥10% |
| 全部需求功能点 | <1%每个月平均值 | ≥50% |
| 全部程序文档 | 每个功能点页数<3 | 每个功能点页数>6 |
| 员工离职率 | 每年1%~3% | 每年>5% |
14.3.2 经典的种子公式¶
Mills 研究出如何通过已知缺陷 (称为种子 Bug) 来估计程序当中潜在的、未知的缺陷数量。其基本前提是将测试队伍分为两个小组，一个小组事先将已知的共 S 个 Bug (种子) 安插在程序里，然后，让另一个测试小组尽可能发现程序的 Bug, 假如他们发现了 s 个种子 Bug, 则认为存在这样一个等式:
则可以推出程序的总 Bug 数为：
其中， \(n\) 是所进行实际测试时发现的 Bug 总数。如果 \(n = N\) ，说明所有的 Bug 已找出来，做的测试足够充分。这种测试是否充分，可以用一个信心指数来表示，即用一个百分比表示，值越大，说明对产品质量的信心越高，最大值为 1。
但是这种假定本身的可能性就比较小，因为种子 Bug 很难具有完全的代表性，根据相似系统确定的 Bug 其结果可能差别很大。另外，人为设置程序的 Bug, 这工作本身就比较困难，要将正确的程序改为错误的程序，会引起其他的一些问题，即插入一个缺陷可能会引起两三个缺陷，而且缺陷相互之间可能存在相互影响或有关联关系，虽然事先设定插入 20 个种子 Bug, 可能在程序中插入了 26、27 个种子 Bug, 所以按照上述计算的公式就不准确了。
14.3.3 基于缺陷清除率的估算方法¶
首先引入几个变量， \(F\) 为描述软件规模用的功能点； \(D_{1}\) 为在软件开发过程中发现的所有缺陷数； \(D_{2}\) 为软件发布后发现的缺陷数； \(D\) 为发现的总缺陷数。因此， \(D = D_{1} + D_{2}\) 。
对于一个应用软件项目，则有如下计算方程式 (从不同的角度估算软件的质量):
假如有 100 个功能点，即 F=100, 而在开发过程中发现了 20 个错误，提交后又发现了三个错误，则: \(D_{1}=20, D_{2}=3, D=D_{1}+D_{2}=23\) 。
有资料统计，美国的平均整体缺陷清除率目前只达到大约 85%, 而对一些具有良好的管理和流程等著名的软件公司，其主流软件产品的缺陷清除率可以超过 98%。
众所周知，清除软件缺陷的难易程度在各个阶段也是不同的。需求错误、规格说明、设计问题及错误修改是最难清除的，如表 14-4 所示。
表 14-4 不同缺陷源的清除效率
| 缺陷源 | 潜在缺陷 | 清除效率/% | 被交付的缺陷 |
| 需求报告 | 1.00 | 77 | 0.23 |
| 设计 | 1.25 | 85 | 0.19 |
| 编码 | 1.75 | 95 | 0.09 |
| 文档 | 0.60 | 80 | 0.12 |
| 错误修改 | 0.40 | 70 | 0.12 |
| 合计 | 5.00 | 85 | 0.75 |
表 14-5 反映的是 CMM 的 5 个等级是如何影响软件质量的，其数据来源于美国空军 1994 年委托 SPR (美国一家著名的调查公司) 进行的一项研究。从表中可以看出，CMM 级别越高，缺陷清除率也越高。
表 14-5 SEI CMM 级别潜在缺陷与清除
| SEI CMM 级别 | 潜在缺陷 | 清除效率/% | 被交付的缺陷 |
| 1 | 5.00 | 85 | 0.75 |
| 2 | 4.00 | 89 | 0.44 |
| 3 | 3.00 | 91 | 0.27 |
| 4 | 2.00 | 93 | 0.14 |
| 5 | 1.00 | 95 | 0.05 |
14.3.4 软件产品性能评估¶
软件产品性能评估的技术性相对比较强，方法的基础是获取与性能表现相关的数据，如响应时间、数据吞吐量、数据流速率、操作可靠性等。性能评测一般和测试的执行结合起来做，或者是在执行测试时记录、保存各种数据，然后在评估测试活动中进行计算结果。主要的性能评测包括以下内容。
14.4 测试报告的具体内容¶
在国家标准 GB/T 17544-1998 中对测试报告有了具体要求，也就是对测试对象 (软件程序、系统、产品等) 有一个清楚的描述，对测试记录、测试结果如实汇总分析，报告出来。测试报告应具有如下结构。
主要内容集中在第 4 项内容，即产品描述、用户文档、程序和数据的测试结果。在产品描述中提供关于用户文档、程序以及数据 (如果有) 的信息，其信息描述应该是正确的、清楚的、前后一致的、容易理解的、完整的并且易于浏览的。更重要的是，在测试报告中，产品的描述和测试的内容有着相对应的关系，也就是说产品描述还要包含功能说明、可靠性说明、易用性说明和效率、可维护性、可移植性说明，特别在功能说明中，不仅需要概述产品的用户可调用功能、需要的数据等，而且将系统相应的边界值、安全性要求描述清楚。对易用性说明中要包括对用户界面、所要求的知识、适应用户的需要、防止侵权行为、使用效率和用户满意度等的要求。
对于用户文档，测试的标准比较清楚，就是完整性、正确性、一致性、易理解性和易浏览性。对于程序和数据的测试，需要从功能、可靠性、易用性和效率、可维护性、可移植性等方面进行测试，并在报告中反映出来。对前三项测试结果，要求更高些，即:
小结¶
代码和相应的文档是开发人员的主要工作成果，作为软件测试人员，其主要成果就是提交一份数据准确、信息充分、分析透彻的测试报告或质量报告。为了提交这样一份报告，需要对测试进行全面的评估，就是要对已做过的测试和测试结果等方面进行评估。概括起来，就是软件测试覆盖评估和测试结果的质量分析。
（1）测试覆盖是对测试完全程度的评测，它建立在测试覆盖的基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。
（2）质量分析是对测试对象（被测系统或软件产品）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中变更请求分析的基础上。
从广义上说，测试覆盖不仅对测试的量化分析，而且对已经完成的测试过程进行审查、评估，包含审查测试计划、测试用例、测试环境和测试用例的执行情况，看是否有漏洞、疏忽的地方，如果有，需要及时补救。
软件测试和质量分析报告的依据就是产品规格说明书、系统设计文档、测试计划书和对实际系统的测试数据，重点集中在缺陷历史数据的分析之上。通过缺陷分析，了解测试的进程、产品质量的当前状况，可以判断软件主要问题在哪些模块或什么主要原因引起相应的问题。软件质量度量和分析，不仅可以帮助写出高质量的测试报告，同时可以帮助开发人员解决问题，帮助产品管理人员做出是否发布产品的决定。
思考题¶
参考文献¶
[35] W3AF 官方网站：http://w3af.org.
[36] OWASP 官方网站：https://www.owasp.org.
[37] Unicode 联盟：http://www.unicode.org/.
[38] Linux 国际化标准：http://www.li18nux.org/.
[39] OpenI18N 全球化规格说明书 http://www.openi18n.org/docs/pdf/OpenI18N1.3.pdf.
[40] 测试模板：http://www.testingexcellence.com/downloads/templates/.
[41] 开源测试资源：www.opensourcetesting.org.
[42] Metasploit 官方网站，www.metasploit.com.
[43] 软件测试资源网站：http://testingfaqs.org/.
[44] 开源测试工具社区 http://www.openqa.org.
[45] 开源项目社区：http://www.sourceforge.net/.
[46] Apache 官方网站 http://www.apache.org.
[47] JUnit 官方网站 http://www.junit.org.
[48] TestNG 官方网站 http://testng.org.
[49] Selenium 官方网站 http://seleniumhq.org/.
[50] Eclipse 官方网站：http://www.eclipse.org.
[51] Robot 自动化测试框架：robotframework.org/.
[52] 软件测试专栏：http://blog.csdn.net/KerryZhu.
[53] 淘测试：http://www.taobaotest.com.
[54] Google 开发者：https://code.google.com.
[55] CSDN 官方网站 http://www.csdn.net.
[56] 微软开发人员网络 (MSDN): http://msdn.microsoft.com/zh-cn/.
[57] IBM 开发社区：http://www.ibm.com/developerworks/cn/.
[58] Sun Java 网站：http://www.sun.com/java/.