1.4.1 测度的意义和要求

1.4.1.1 测度的意义

在测试过程中，测度能够帮助测试经理掌握项目和团队当前所处的状态，为计划后续的测试活动提供基础。若要对测试活动乃至项目活动进行控制，就必须进行测度。大家经常谈论的测度的意义，随着测度的不断深入进行，以及大家对测度认识不断加深，测度的意义越来越多，其作用也越来越大。对于软件测试而言，其测度的意义主要表现在以下六个方面。

（1）测试过程监控

测度的一个重要作用就是对测试过程进行监控。无论是静态测试还是动态测试，都可以通过测度进行测试过程的监控。

评审是一种静态测试技术，评审的对象可以是开发相关的文档，例如：系统需求规格说明、系统设计规格说明、模块设计规格说明、代码等；也可以是测试相关的文档，例如：测试计划、测试设计规格说明、测试用例规格说明、测试规程规格说明、测试报告等；还可以是客户文档，例如：软件系统操作手册、软件版本升级使用说明等。文档评审相关的度量可以是文档评审速率的度量，也可以是对评审中发现缺陷的度量，从而对评审的效率、有效性以及评审对象的质量进行评价；对于测试用例设计规格说明，可以对测试用例中包含的不同测试类型进行度量，判断测试用例设计的分布是否合理，例如：发现测试用例设计的绝大部分都是功能测试，而忽略了非功能测试，这样就需要进一步设计更多的非功能测试用例。

☆示例：测试过程监控：测试执行进度

在动态测试中，可以通过对测试用例的执行情况进行度量，了解测试执行的进度。图1-8显示了某项目的测试用例执行进度。从图中可以看出，实际执行的测试用例进度和计划的进度基本吻合。但是已经执行的测试用例中有一定数量的测试用例执行结果是被阻塞或失败状态，图中的测试用例执行进度很明显地提示了按时完成测试的风险很大。对于被阻塞的测试用例，测试经理应该进一步调查原因，例如：测试环境未及时到位、被测试软件的版本质量有问题等，测试经理应该根据调查结果采取相应的措施。

通过测度，测试过程的监控变得更加清晰。通过一些量化的指标，明确了测试过程中的各项活动，同时项目成员可以更加清晰地了解测试过程，并及时进行调整。

（2）为决策提供数据支持

测度另一个重要的作用是帮助相关人员评估测试的入口和出口准则。在实施了测度以后，测试的入口和出口变得更加清晰，例如：集成测试入口准则的条目之一是组件测试的代码覆盖率达到100％。通过对组件测试中的代码覆盖率的度量，可以更加清晰地定义和评估集成测试的入口准则。

根据具体的度量数据，还可以判断是否能够发布被测系统。作为判断依据的度量数据包括：状态为未关闭的缺陷在不同严重程度级别的分布情况；测试用例执行的通过率等（详细的出口准则的例子，参见1.4.3节）。

（3）测试过程改进

测度本身并不能改进测试过程，但是测试过程中收集的度量数据可以作为测试过程改进的输入，以帮助实施测试过程改进。

☆示例：测试过程改进

图1-9显示了某项目发现的按测试阶段收集的缺陷分布。通过缺陷在不同阶段的分布，能够看到大量的缺陷都在集成测试和系统测试阶段发现，而评审、组件测试中发现的缺陷相对很少。大家都知道，缺陷发现得越晚，修复缺陷的成本越高。为了改变这种情况，可能需要加强前期的测试人力投入，对现有的评审过程进行规范和改进。再进一步分析，系统测试仍然发现了一些设计不一致的问题，而这种类型的问题其实在前面的单元和集成测试，或者在代码走读、文档评审的时候都可能被发现。这说明整个团队没有对这类问题引起重视，可以通过在各个活动的检查表中明确指出应该关注这类缺陷，从而在后续项目中尽量避免重复此类现象。

图1-10显示了某项目的测试用例执行进度。通过分析测试用例执行进度的度量，发现有大量的测试用例处于被阻塞的状态。经过分析，这些被阻塞的测试用例是由个别模块的基本功能存在缺陷而导致的。由于在测试执行的前期，大量测试用例由于测试对象模块基本功能方面的原因无法得到执行，使得测试任务集中到测试的后期，导致测试进度延迟。这就突出了一个被测试版本的质量问题。在实际的测试过程中，这种现象经常出现。开发团队提交的版本质量不能满足测试的要求，从而对测试工作造成很大的影响。发现这个情况后，测试经理可以对测试过程进行改进，在进行全面测试之前，先对提交测试的版本进行“预测试”（用于决定组件/系统是否能够进行更深入的测试，通常在测试执行的初始阶段实施）。

（4）测试团队激励

测度还可以达到激励测试团队的目的。测度能够以直观和量化的方式反映测试团队的绩效，使得测试团队的工作能够得到项目团队中其他成员的认可。

☆示例：测试团队激励

图1-11显示了不同的项目中发现的缺陷的变化情况。项目1、2、3中的测试任务都是由同一个测试团队来完成的。随着测试团队从项目1到项目2，再到项目3，测试团队在项目前期的投入不断增加，静态测试发现的缺陷数目明显增加，系统测试发现的缺陷比例明显降低。这个数据肯定了测试人员在项目前期介入的工作，将会鼓舞测试团队持续地进行测试过程改进。

其他能够激励测试团队的测度还有：随着测试过程在组织内的不断改进，通过对版本发布后发现的缺陷的度量，发现千行代码遗留缺陷数变得越来越少，这个数据在很大程度上表示了对测试团队工作和过程改进的肯定，将激励测试团队不断地努力工作。

（5）组织能力数据

测试活动中碰到的很多问题都依赖于测度。无论是测试团队的生产率还是被测试对象的质量，都需要通过测度来具体说明。测度无论是在发现问题还是在诊断问题上，都有着不可替代的作用。它必然成为整个问题解决过程的重要组成。有时分析度量数据可以发现测试过程中的问题，有时分析度量数据可以对测试团队遇到的问题进行诊断。

随着度量数据的不断积累，将逐步形成组织的度量数据库，在以后项目的测试活动中可以作为输入，例如：在进行测试工作量估算的时候，组织的测试生产率就会起到很大的作用；在整个软件开发生命周期，如何安排各个阶段测试人员数量，也可以根据组织能力数据库来获得；在进行评审的时候，一旦被评审对象发现的缺陷明显和组织能力数据不符的时候，就需要进行进一步分析，保证评审的质量。

（6）霍桑效应

霍桑效应（Hawthorne Effect），也叫做霍索恩效应。从1924年开始到1932年结束，在将近8年的时间内，前后共进行过两个回合：第一个回合是从1924年11月至1927年5月，在美国国家科学委员会赞助下进行的；第二个回合是从1927年至1932年，由乔治埃尔顿梅奥（George Elton Mayo）主持进行。霍桑实验最初的研究是探讨一系列控制条件（薪水、车间照明度、湿度、休息间隔等）对员工工作表现的影响。研究中发现，各种试验处理对生产效率都有促进作用，甚至控制条件回归初始状态时，促进作用仍然存在。这一现象发生在每一名试验者身上，对于试验者整体而言，促进作用的结论亦为真。很显然，实验假设的各项条件并非是唯一的或决定性的生产效率影响因素。对此，乔治埃尔顿梅奥（George Elton Mayo）以及他的助手们所作的解释是，试验者对于新的实验处理会产生正向反应，即由于环境改变（试验者的出现）而改变行为。所以，绩效的提高，并非由实验操控造成。

测度的实施过程中也存在“霍桑效应”。经常出现被度量的活动或任务的效率都有明显的改进。这个是和心理学直接相关的一个现象。当整个团队对某个事件高度重视的时候，大家都会投入更多的精力，潜意识的在日常工作中对此予以更多的优化。这在一定程度上也体现了态度的重要性，例如：测试团队开始对静态测试中发现的缺陷进行度量，那么很快就能发现，测试团队在静态测试中发现的问题显著增加，测试团队在静态测试中的作用不断增强。

这是一个很有意思的现象，也从侧面说明测度只是一个工具，它到底能发挥什么样的作用，取决于使用这个工具的人。

1.4.1.2 测度的要求

测试和测试的过程是可以测量的，尽管存在各种困难。测度的正确应用（例如通过图表、数据等方式）可以提供足够的信息来帮助测试过程的监控，以及项目开发过程和测试过程的改进。针对测试过程的测度也可以为项目的其他活动提供信息。同时，通过定期对测度的信息进行积累、更新和总结，测度可以帮助判断相关活动的趋势。为了更好地利用测度提高测试过程的效率和有效性，测度的应用需要注意以下几个方面。

（1）简单易收集

测度尽量采用简单和易收集的度量数据。简单指的是需要收集的数据简单易懂，并且容易理解，例如：测试过程中设计的测试用例数目、测试执行过程中每个测试用例的状态（测试通过、测试失败、被阻塞等）、各个测试活动花费的时间等。测试团队中的每个成员都应该对这些简单的数据和度量进行跟踪和监控。而建立的测度容易理解，要求相关的数据客观，并且要求度量的定义和解释是明确的、没有歧义的。

度量相关的数据易于收集，要求信息收集的过程不应该花费相关人员太多的时间和工作量，同时要求的度量尽量少，并且是有效的。为了提高效率，度量相关的数据最好能够通过相关的工具进行收集。

（2）可测量

为了保证对测试结果和测试过程比较的一致性，要求测量的方式是标准的、准确的、可计量的。为了确定测试中得到的缺陷密度，需要确定哪个度量来提供这些信息，以及测量的标准是什么，例如：针对缺陷密度，某测试团队采用的度量是每千行代码发现的缺陷数目（从测试的角度而言，缺陷密度也可以定义为发现的缺陷数目和执行的测试用例数目之间的比值）。

度量的定义必须是清楚和准确的。针对缺陷的定义，必须明确哪些缺陷是需要统计的（例如：有的组织在定义缺陷密度的时候，缺陷数目不包括严重程度级别最低的缺陷，而有的组织是需要包括在内的）。代码行数的统计也应该有明确的定义，例如：总的代码行数是否包括代码中注释的行数。在组织和项目内必须对这些度量的定义保持一致。

（3）目的明确

整个测度活动应该是目标驱动的。在现实的测度活动中，经常能够看到度量指标驱动的例子。有些测试团队为了度量而度量，收集了很多度量数据，而在做度量报告的时候只是简单地罗列这些度量数据，根本不知道度量数据能够得到什么样的信息。所以，也经常出现度量人员面对一堆度量指标而不知所措的情况。在测度过程中，必须要根据具体项目和团队的实际情况来制定度量目标，进而指导整个测度活动。如果一个度量指标就能满足目标，为什么还要其他的指标呢？所以测度内容不在多少，而在于是否能够满足度量目标。测度收集的信息和数据必须有特定的目的，例如：收集的信息和数据可以是用于确定在每个测试阶段发现的缺陷数目和修复缺陷所花费的时间，从而用来确定如何采取更加有效的方法降低成本，并提高发现和修复缺陷的效率。

（4）不针对个人

度量数据主要是用来对项目进行分析，并指导下一步的测试活动。所有的度量数据都不能用来对单个测试人员进行评估。经常会发现有些组织利用缺陷数目对开发人员和测试人员进行绩效评估。这种方法存在很大的副作用，可能会导致收集度量数据的工作很困难，即使收集到数据，数据的提供者也可能由于绩效评估方面的顾虑而提供并不准确的数据，最终影响整个度量的结果。没有人喜欢把自己完全暴露在大家的目光之下，任人评头论足。测度的时候也是一样的，在制定度量目标的时候，不应该把单个测试人员的度量纳入进来。而且要通过各种沟通渠道，让数据提供者了解测度的意义，以及这些数据的用途，这样才能保证测度活动的顺利进行。避免将测度应用于对测试人员的评估。假如测试人员将度量数据的收集看成可能对他的工作造成威胁，那么他可能经常会报告一些不正确或者不完全的测试数据和信息，从而导致测度的不正确和不完全，使得测度失去原来的意义。

（5）完善的测度过程

完善的测度过程能够保证采用该过程输出的工作产品能够符合团队的需要。完善的测度过程能够保证：

● 正确性：度量数据的正确性是获得正确的信息产品的基础，通过对度量数据提供者的培训以及必要的数据验证工作，可以提高度量数据的正确性。

● 及时性：度量信息的发布一定要及时，度量结果一方面是对过去活动的解析，另一方面也用来指导下一步的测试活动，例如：遗留缺陷密度（产品发布后发现的缺陷数/产品规模），这个指标可以用来对产品质量或测试活动的有效性进行评估，但是这个信息的获得是在产品发布一段时间后才能获得，及时性比较差。对于正在进行测试的项目来说，需要一些更及时的指标来指导测试工作。

● 经济性：整个测度活动要考虑成本，尽量简化测度的内容，如果一条信息就能够满足测度的目标，就决不要再关注第二条。

● 集成性：测度过程并不是单独存在的，它应该贯穿于整个项目活动中，例如：监控测试用例的执行进度而进行的度量，需要测试人员在测试执行过程中提供相关的数据；评审数据的收集也是要集成到整个评审过程中去。这就要求测度的过程要简单，易于整合到项目过程中去。

● 灵活性：整个测度过程不是一成不变的，随着项目环境的变化，可以进行裁减和修改，同时要避免整个测度过程的机械化。从实践经验来看，测度设计和分析人员的个人能力在整个度量过程仍然起到重要的作用。