执行篇3

第28回 软件测试过程和质量的度量

<script type="text/javascript"></script><script class="blogstory"></script>

        测试阶段的过程度量内容或项目比较多，包括软件测试进度、测试覆盖度、测试缺陷出现/到达曲线、测试缺陷累积曲线、测试效率等。在进行测试过程度量时，要基于软件规模度量（如功能点、对象点等）、复杂性度量、项目度量等方法，从三个不同的测度来完整度量测试的过程状态：

1.  测试广度的测量提供了多少需求(在所有需求的数目中)在某一时刻已经被测试，来度量测试计划的执行、测试进度等状态；
2.  测试深度是对被测试覆盖的独立基本路径占在程序中的基本路径的总数的百分比的测度，基本路径数目的度量可以用McCabe环形计算复杂度方法来计算。
3.  过程中收集的缺陷数度量，发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等，为过程质量、开发资源额外投入、软件发布预测提供重要依据。

如前所述，测试过程的度量可以将过程状态度量和过程结果度量结合起来分析，是测试过程度量更有效。

在测试阶段，主要的过程质量度量有：

• 缺陷度量或缺陷分布度量
• 测试用例的深度、质量和有效性
• 测试执行的效率和质量
• 缺陷报告的质量
• 测试覆盖度（测试整体的质量）
• 测试环境的稳定性或有效性

       缺陷度量是测试阶段的主要度量内容，包括产品缺陷度量和缺陷过程度量。产品缺陷度量将在下一回做详细介绍，而测试环境的稳定性或有效性度量，就像软件有效性一样，用MTTF来测量。所以下面将简单介绍其他度量内容，如软件缺陷到达模式、PTR出现/积压模型、测试用例的度量、基于需求的测试覆盖评估、基于代码的测试覆盖评估等等。

1. 基于时间的缺陷到达模式
      产品的缺陷密度、或者测试阶段的缺陷率是一个概括性指标，缺陷到达模式可以提供更多的过程信息，有时即使得到的整体缺陷率是一样的，但其质量差异可能较大，原因就是缺陷到达的模式不一样。越多的缺陷到达越早，则测试过程质量就越好。无论是从测试进展的观点，还是从用户重新发现(customer rediscoveries)的观点来看，缺陷的过程跟踪是非常重要的，开发周期里大量的严重缺陷将有可能阻止测试的进展，也必然直接影响软件产品的质量和性能。
       相对产品发布时间、上一个版本的缺陷水平来说，经常会被项目经理或开发经历问的就是：

•  缺陷何时到达峰值？这个峰值有时多少？
•  在到达峰值后又要化多少时间趋于（降低）到一个低而稳定的水平？
• 低而稳定的水平持续多少时间，当前版本可以发布？

       回答这些问题，正是缺陷达到模式要实现的目标。定性的分析比较容易，测试团队越成熟，峰值到达得越早，有时可以在第一周末或第二周就达到峰值。这个峰值的数值取决于代码质量、测试用例的设计质量和测试执行的策略、水平等，多数情况下，可以根据基线（或历史数据）推得。从一个峰值达到一个低而稳定的水平，需要长得多的时间，至少是达到峰值所用的时间的4-5倍。这个时间取决于峰值、缺陷移除效率等等。

2. PTR累积模型
       测试的目标在于尽早地发现软件缺陷，通过测试用例可以更有效、更快地发现软件中缺陷，而软件缺陷通过PTR（问题跟踪报告，Problem Tracking Report）来描述。因此，PTR的数量一定程度上代表了软件的质量。每个缺陷/PTR都有一个生命周期，从测试人员发现问题并形成报告（称为PTR出现，也称缺陷到达），开发/设计人员要重现、修正这个PTR/缺陷，并构建、提交包含已修正PTR/缺陷的新软件包(New Build)给测试组，所修正的问题得到验证直到该问题通过测试为止（称为PTR关闭），测试过程中特定时间PTR保持的数量（所有新发现的PTR和关闭的PTR的差值）——PTR累积/积压值。PTR出现／累积模型就是根据问题跟踪报告的两种数据——某个时间单位内的PTR出现值和某个时间PTR累积值来度量测试中所发现的缺陷变化过程，即软件产品质量状态的变化过程。

3．测试用例的深度、质量和有效性
      测试用例是测试执行的基础，其质量的好坏直接关系到测试的质量，也就影响着软件质量的保证过程。测试用例的度量将包含测试用例的深度、质量和有效性，而且包含自动化程度的度量，即多少比例的测试用例已被自动化了。
      测试用例的深度（TCD, Test Case Depth）度量可以表示为每KLOC的测试用例数或每个功能点/对象点的测试用例数，而测试用例的效率可以用每100或1000个测试用例所发现的缺陷数来衡量，不同的测试阶段是不一样，应该对同一阶段的不同版本进行比较，而不宜对同一版本的不同阶段进行比较。而测试用例的质量（TCQ, Test Case Quality）可以用由测试用例发现的缺陷数量来度量，即

TCQ = 测试用例发现的缺陷数量/总的缺陷数量

      因为还有一部分缺陷可以通过ad-hoc 测试（随机、自由的测试）、集体走查(Work-through)和Fire-drill测试(类似消防训练的用户压力/验收测试)等其他手段发现缺陷

4．测试执行的效率和质量
        测试执行的质量一般可以用软件发布后所遗留的软件缺陷和总缺陷数的比值来衡量，一般要求低于0.5%，也可以通过种子公式或交叉测试等方法衡量。测试执行的效率可以用下列几种方法来综合度量：

• 每个人日所执行的测试用例数
• 每个人日所发现的缺陷数
• 每修改的KLOC所运行的测试用例数

5．缺陷报告的质量
      缺陷报告质量可以评估测试人员工作质量的方法之一，如可测量的指标有：

•  缺陷报告有效性，所有修正/关闭的（等级高的）缺陷和测试人员所报的所有（等级高的）缺陷的比值，这个值越接近1，有效性就越高，如果考察等级高的缺陷，其正常值大约在0.92 – 0.96
• 缺陷报告质量，可以用一些中间状态为“需要补充信息”、“不是缺陷”的缺陷数量来衡量，一般占总缺陷数的3%-5%为正常，高于或低于这个值都可能不正常，高于5%，可能说明缺陷报告质量低；低于3%，可能说明测试人员缺少怀疑精神。

6．基于需求的测试覆盖评估
       基于需求的测试覆盖评估是依赖于对已执行/运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率：测试的目标是确保100%的测试用例全部成功地执行。一般在测试计划中，就定义了测试的工作量、测试用例数量和测试用例覆盖率（98%-100%），我们根据事先确定的测试日程安排，可以将测试计划值做成曲线，然后根据实际执行结果，定期（每天或每周）去画实际值曲线，从而可以进行测试全过程监控和预测。
    在执行测试活动中，评估测试用例覆盖率又可分为两类测试用例覆盖率估算：

• 确定已经执行的测试用例覆盖率，即在所有测试用例中有多少测试用例已被执行。假定Tx已执行的测试过程数或测试用例数，Rft是测试需求的总数：
• 已执行的测试覆盖 ＝ Tx／Rft
• 确定成功的测试覆盖，即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试，假定Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数。
• 成功的测试覆盖 ＝ Ts／Rft

7．基于代码的测试覆盖评估

        基于代码的测试覆盖评测是对被测试的程序代码语句、路径或条件的覆盖率分析。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。
        评估代码覆盖率，需要断定测试目标期望的、总的测试代码行数，在测试中真正执行的代码行数及其百分比，将此结果记录在测试评估报告中。测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已经定义。
    基于代码的测试覆盖通过以下公式计算：
已执行的测试覆盖 ＝ Tc／Tnc
    其中Tc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数，Tnc（Total number of items in the code）是代码中的项目总数。

 

第30回 总结

<script type="text/javascript"></script><script class="blogstory"></script>        
         软件测试演义——中高级系列（序）要结束了，但我认为这仅仅是开始，有许多东西要学，有许多东西要深入下去，不断探讨，才能完成在软件测试上的使命......

       如果要对 “软件测试演义“ 有一个总结的话，可以用一句话来概括，

软件测试是一门地地道道的学问，同时也是一门艺术。

测试的学习，也是从厚到薄，再从薄到厚。但我们真正进入了软件测试领域后，我们才会发现、或真正感到有许多东西要学。

      说起软件测试学问，在 软件测试全貌 里可以略见一斑，如静下心来看看：

•   基于有限状态机
•   基于形式化规格说明
•   基于控制流的准则
•   分布式系统的测试
•   变异测试

同时，要了解软件测试的一些新的技术和新的平台，例如有不少新的开源测试工具需要了解，如Selenium/EMMA等，还有更多的自动化测试框架，如:

• STAF: Software Testing Automation Framework
• SAFT: Software Automation Framework Support

自动化脚本技术也是在不断发展，如从数据驱动(data-driven)向关键字驱动（Keyword-driven），使测试脚本中业务逻辑、操作（action）和数据得到分离，不仅仅是数据和脚本代码的分离。

     更让我们始终感到有压力的是，软件本身发展很快，软件测试要不断适应软件的发展。不仅涉及语言（ASP/PHP/Java, C++/C＃, Ruby.. .) 、平台（OS + .NET, J2EE, ...) 等变化，还涉及模式、方法和技术的变化。如从面向对象（OO, Object-Oriented）软件的测试，到面向构件(CO, Component-Oriented)、面向方面(AO, Aspect-Oriented)、面向服务架构（SOA，Service-oriented architecture）、面向SaaS(Software as a service, 软件即服务) 软件开发等的测试，不断创新，无一不要求我们学习、再学习。

     软件测试作为艺术，充满了很多的辨证统一的矛盾体：

• 白盒测试方法和黑盒测试方法
• 静态测试 (static test) 和 动态测试( Dynamic test)
• 手工测试（Manual test）和自动化测试(Automated Test)
• 有计划测试（Planned Test）和随机测试（Ad-hoc test 或Random test）
• 新功能测试（new feature test）和回归测试 (Regression testing)

        更具有挑战的是，在效率和质量风险中获得平衡，在不断和风险、巨大的环境组合、无穷的测试用例数等进行搏斗。需要辨证地从多个视角去看待它，不断的思考以获得适宜的测试方法和策略，并最终依赖TA的实现、有效的管理，达到我们的质量目标。

      从测试人员个人讲，要不断地实践，上前线打仗是锻炼士兵的最好办法，测试也是一样，测试方法、测试用例设计、测试脚本开发、测试工具使用和执行等，都需要和实际项目结合起来，也是最基本的要求。

      从测试团队讲，可能要不断进行 测试的革命，依据”测试成熟度模型“，推进团队的成熟、发展，使团队不仅拥有测试各个领域的技术和经验，更重要形成一套开放的、自我改进的、相对完善的测试体系，包括思想、方法、工具和基础设施等。

      要对大家有一个交待，一个真正的总结，就是再将薄变厚，写成一本系统的、实用的、手把手教大家做测试的、高水平的软件测试指导书。目前，正在和电子工业出版社的博文视点（BroadView）合作，今年8-9月份有望和大家见面。

      最后，谢谢大家捧场！！