1.4.3 度量数据应用
通过测度能够得到一系列的度量数据，通过对度量数据的分析可以获得需要的信息。测试经理可以利用这些信息调整后续的测试活动。下面通过一些案例分析测试经理如何通过获得的度量信息评估并调整相关测试活动。
1.4.3.1 案例分析：测试用例设计进度
（1）度量目的
监控测试用例设计的进度，确定实际测试设计进度和计划测试设计进度之间的差距，保证测试用例设计按时完成。通过测量计划的测试用例设计进度和实际的测试用例设计进度之间随着时间的演化过程，可以对测试用例设计的进度进行跟踪。
（2）选择的度量
选择的第一个指标是：测试用例设计进度随时间的变化情况。具体收集的数据包括每个时间点计划设计完成的测试用例总数和实际设计完成的测试用例总数，如图1-13所示。
图1-13 项目测试用例设计进度
另外还选择了一个指标：当前各个模块的测试用例设计进度。具体收集的数据包括各个模块当前计划设计完成的测试用例总数和实际设计完成的测试用例总数，如图1-14所示。
（3）度量数据
度量的数据如图1-14所示。
图1-14 第17周的测试用例设计完成情况（按模块分布）
（4）度量分析
从测试度量数据的结果来看（图1-13），当前（第17周）的测试用例设计比计划完成的测试用例还多一些，表明当前测试设计总体进度情况良好。而且从历史趋势来看，实际进度和计划的进度偏差不大，从侧面说明实际的测试设计进度比较稳定，当前总体的测试用例设计进度比较可控。
从项目经理的角度来看，图1-13已经能够满足他的需求，可以掌握总体的测试用例设计进度。但是从测试经理的角度，还必须要关注具体的各个模块的情况，所以还需要对当前的测试用例设计的情况进行进一步的观察。图1-14显示了当前的测试用例设计完成情况（按模块分布）。虽然当前总体进度很好，但是依然不能排除有个别模块的进度和计划存在较大的偏差。从图1-14可以看到各个模块的测试用例设计完成情况，发现其中模块6的进度并没有达到计划的要求。这个时候就需要测试经理与参与模块6测试用例设计的测试人员进行沟通，了解没有按时完成的原因，并采取相应的补救措施。
1.4.3.2 案例分析：测试用例执行进度
（1）度量目的
测试用例执行度的目的是保证测试用例执行的进度。通过计划执行的测试用例数、实际执行的测试用例数、执行通过的测试用例数、执行失败的测试用例数和被阻塞的测试用例数随着时间的演化信息，对测试用例执行的进度进行监控，保证测试用例执行按时完成。
（2）选择的度量
选择的度量是测试用例在各个状态的数目随着测试执行活动持续进行的变化情况。具体收集的数据包括：测试用例总数、计划执行的测试用例数、被阻塞的测试用例数、失败的测试用例数和通过的测试用例数，如图1-15所示。
图1-15 测试用例执行进度
（3）度量数据
度量的数据示例如图1-15所示。
（4）度量分析
图1-15显示了某项目的测试用例执行进度。从中可以看到整个测试用例状态的分布和变化的趋势。当前的测试用例执行进度明显落后于计划的进度。从图中可以看到，总共执行的测试用例的数目和计划执行的测试用例数目基本符合，但是由于部分测试用例执行失败或者被阻塞，导致测试用例执行进度落后。当发现这种情况时，需要对失败和被阻塞的测试用例进一步的调查。对于被阻塞的测试用例，需要调查是否是由于被测试模块质量较差，导致部分测试用例不能执行，还是因为缺少测试环境、工具或人力资源等。由于失败和被阻塞的测试用例较多，导致测试后期的测试执行和回归测试的工作量增加，测试经理需要考虑调整测试资源的分配。对于版本质量问题导致的测试失败或被阻塞，测试经理需要及时和开发团队进行沟通，调整开发团队的工作重点，保证测试执行的顺利进行，优先修复对测试进度影响较大的缺陷。
1.4.3.3 案例分析：测试的充分性
（1）度量目的
评估测试的充分性。产品发布后的遗留缺陷数目是一种常用的判断测试充分性或者有效性的方法。软件或者软件产品发布后发现的缺陷越少，说明测试的有效性越高。虽然产品质量最终是由用户来评价的，但是等到产品交付用户的时候才对测试工作进行评估，仅仅有助于后续产品的质量改进，而当前产品的质量已经无法改变。为了保证当前产品的质量，尽量在产品交付用户前发现缺陷，如果能够在产品发布前就对测试的充分性进行评估，那么可以在测试活动不充分的时候，及时调整测试活动，增加相应的测试投入，保证测试覆盖，减少产品发布后的遗留缺陷。由于这里的测试充分性是在产品发布前进行的评估，难度要更大。
（2）选择的度量
根据度量目的，选择的度量有：
● 测试用例执行率为100％。
● 测试执行的需求覆盖率为100％。
● 测试发现的缺陷密度：测试发现的缺陷总数/产品规模（如表1-1所示）。
表1-1 测试发现的缺陷密度
● 测试发现的缺陷按触发原因分类（如图1-16所示）。
图1-16 每周发现的缺陷数
● 缺陷发现数量的收敛情况（如图1-17所示）。
图1-17 缺陷按触发原因分类
（3）度量数据
度量的数据如表1-1、图1-16、图1-17所示。
（4）度量分析
从得到的度量数据来看，测试用例的执行率和测试执行对需求的覆盖率都达到了100％。测试用例的设计和执行情况比较好，基本满足了要求。同时随着测试的不断进行，发现的缺陷数目呈正态分布，在测试执行结束的时候，缺陷的发现数目趋于收敛，从一定程度上说明了版本的质量也在趋于稳定。图1-17进一步对发现缺陷的触发原因进行分析。由于该测试团队在缺陷发现原因的分布上并没有很多历史数据，所以不能对触发原因进行定量的分析。通过定性的分析可以发现，缺陷的触发类型呈现多样性，说明测试类型比较全面。但是同时还发现一个现象，在测试的末期仍然存在一些基本功能的问题，这个并不是一个好的现象。如果测试充分，产品质量比较稳定的情况下，在测试的后期不应该还存在基本功能方面的问题。
总体来看，本次测试比较充分。存在部分异常，在测试后期仍然存在基本功能的缺陷，测试经理需要进一步分析缺陷发现的根源，这些缺陷是原来就存在一直没有被发现，还是开发人员修改代码新引入的。根据调查结果，对测试活动进行改进。
1.4.3.4 案例分析：产品发布准则
（1）度量目的
在测试过程的后期，项目面临的一个重要的问题是：产品是否能够发布。产品是否发布取决于多方面的因素。本案例主要从测试的角度评估产品的发布，这里给出的发布准则有：
● 测试用例执行通过率达到98％。
● 未解决的缺陷中没有严重程度为1的缺陷（严重程度1为最严重的缺陷）。
● 未解决的缺陷权重小于55：（严重程度为2的缺陷数×3 + 严重程度为3的缺陷数×2 + 严重程度为4的缺陷数×1）＜ 55。
（2）选择的度量
从测试的角度，选择的度量有：
● 所有测试用例的执行结果（如图1-18和图1-119所示）。
图1-18 测试用例执行结果
图1-19 当前测试用例执行状态分布
● 没有修复的缺陷按严重程度分布（如图1-20所示）。
图1-20 当前缺陷状态分布
（3）度量数据
度量的数据见图1-18～图1-20所示。
（4）度量分析
从图1-18中可以看到，测试用例执行情况良好，已经执行了所有的测试用例，图1-19显示了其中98％的测试用例执行通过，失败的测试用例只有2％。从图1-20的缺陷状态分布来看，当前未修复的缺陷中严重程度1和严重程度4的数目都是0，未修复缺陷的总权重为42（即8×3 + 9×2 + 0×1 = 42）。
从测试的角度看，当前产品状态已经符合发布条件。当然产品的发布不仅仅需要从测试的角度考虑，还受到开发情况、市场推广等多方面的影响。有时候虽然产品当前状态没有满足测试的发布准则，但是整个产品为了能够及时占领市场，仍然有可能提前发布。但是这并不意味着从测试角度制定的准则没有起到作用，当产品没有达到发布准则的条件下提前发布，测试团队根据度量结果可以及时准确地阐明当前产品发布的风险，通过和市场团队、技术支持团队的及时沟通，可以尽量对已知的风险进行规避。