HRC拉动的大型软件测试

HRC拉动的大型软件测试 - 旧文重发，原文发表于行业测试杂志

一、前言

一款已近20年历史、服务全球数万家客户、拥有数千万行代码、由分布全球的近千人研发工程团队开发的产品，其测试活动如何组织？测试人员如何分工协作？

笔者将以产品为案例，介绍一个大型测试组织如何通过建立RC，以及通过HRC实现测试工作的拉动以及持续改进，供行业同仁参考。关于整个工程研发组织敏捷转型的案例故事，可以从“敏捷宣言”签署人之一的Ken Schwaber所著的《30天软件开发-告别瀑布拥抱敏捷》一书中找到。

二、RC和HRC

1.什么是RC?

RC 是Release Criteria的首字母简称。一般在制订测试流程时，都会编制一个一个测试完成准则。这个准则也可能被称为测试退出标准，或者在推行敏捷的公司被叫做完成标准(Definition of Done,DoD)。如果加上相关的版本或者产品发布的工作，也可能叫做软件发布准则。

2.RC包括什么内容？

作为一个完成准则，一般会包括度量项目以及各项目的度量值这两方面的内容。对于软件测试来说，可能就需要考虑以下2个方面的问题：

- 做哪几种类型的测试？即关注做什么工作。

- 各类型测试的质量指标是什么？ 即关注工作完成的质量。

1)类目（Category）

首先来回答第一个问题。通过多年实践，该公司将测试流程划分为SCRUM testing（敏捷测试） 以及System Testing（系统测试） 两个大的阶段，包括了FAT(Function Acceptance Testing，功能接受测试),SIT(System Integration Testing，系统集成测试),SAT(System Acceptance Testing，系统接受测试)这三个级别。其中FAT主要是在SCRUM团队中针对每个Sprint冲刺进行测试，主要围绕Sprint DoD(冲刺完成标准)展开。而SIT/SAT可以理解为通常意义上的W测试模型中的系统测试，包括了功能测试以及性能、压力、易用性等许多非功能测试。RC就主要应用于SIT,SAT这两个级别。因此，RC就主要由以下类目组成：

从上表中可以看出，RC的组成其实可以理解成为系统测试阶段所实施的各个测试类型，包括了功能、安全测试以及各种以英文"ility"结尾的非功能测试。针对这些类型的测试活动制订相关的完成标准，就形成了RC，从而实现了测试流程与测试结果度量的结合。可见类目并不是凭空设计出来的，而是针对日常工作的交付物所形成的。

2)度量项目（Item）

在确定类目之后，可以进一步针对各个类目来制订度量项目。如以下为某一个发布的“产品质量”类目下的度量项目：

表2

可以看出，例如针对“产品质量”这一类目，就主要关注于测试覆盖率、缺陷数量和密度等指标，涵盖了测试执行、缺陷修复、缺陷验证等各个方面。当然，也需要为各度量项目提供各自的计算公式，避免了统计口径的不一致。

3.HRC与RC

从表2的最后2列可以看出，在指定某个具体度量项目上，引入了时间的维度(Historical)。HRC是在RC的基础上，通过与之前的发布的类目和度量项目进行横向比较，来推动产品质量和测试能力的逐步提升。

这些提升，可以是在时间要求上的，如某些指标，之前在发布前一个冲刺，即RTM-1个Sprint时达到100%完成，在本次的发布中，则要求提高到RTM-2 个Sprint完成；也可以体现在具体指标值的优化改进上，如缺陷密度降低、性能指标提升等；也有些指标是体现测试活动的覆盖强度上，如安全扫描等，之前是整个发布中实施2次，现在则要求3次等等。这充分体现了持续改进的思想。

三、测试完成标准的度量

除了简单的按照各个类目下的指标项进行度量，如测算出覆盖率、缺陷数等，在实际的HRC运作中，也有些独特之处。

1.按照发布的规模制订不同的HRC

在实践中按照发布规模来设定不同的HRC，如年度发布版本与上一年度的发布版本进行比较；而某一年度发布的季度版本（MOR，补丁发布）则是与上一季度发布版本的指标进行比较。这种方式下，两者的规模、投入，包括发布指标更具有延续性，也更容易比较。

2.量化的百分计数方式消除指标间差异

因为各个类目和度量项目各不相同，如何来报告进度，告诉各个利益相关者目前的进展和偏差，是HRC的拥有者所需要解决的问题。例如如何判断-1%测试覆盖率偏差以及 2个"高”级别的缺陷等偏差对于测试完成指标的影响，为了解决类似这种问题，于是就采用了百分计数方式，具体方法如下：

第一步：通过将不同类型的指标统一化成100分为完成指标，如百分比、个数、次数、密度等等；

第二步：综合各项度量项目的得分，形成某个类目的得分

第三步：根据每个类目得分最终获取HRC整体百分制得分。

通过这种抽象，方便对外整体的汇报和沟通。

例如：对于个数类的指标，如“未解决的缺陷任务”或者是“未解决的阻塞级别缺陷”等指标，一般会先设定度量开始后，后续每个Sprint的目标，或者是可接受的个数。然后再换算成百分制下的得分。针对某一Sprint的计划得分，其计算公式为：

计划得分={1-计划的个数(当前Sprint)/MAX[计划的个数(开始Sprint): 计划的个数(结束Sprint)]}*100

实际得分的计算过程也类似，只是将上述公式中的分子部分“计划的个数(当前Sprint)”修改为“实际的个数(当前Sprint)”即可，分母部分不修改。

通常“计划的个数(结束Sprint)”的最终为0，因此这个百分制下的得分其实反应的是目前的个数与计划中最大个数和0之间的位置。

3.RC的考核度量是一个按计划推进的过程

在每个产品发布的初期，就制订了一个RC 达标计划。根据历史经验，规定了RTM时最终的目标，以及在每个sprint结束时应达到的量化目标。如下图所示，某个发布的可靠性目标从RTM的前5个Sprint开始度量，逐步提高，直至最后达到100。

通过这种目标设定和分步实现以及及早度量的方式，可以及早地让大家明确目标，并且逐步冲刺各阶段目标，出现偏差以后也容易及时发现和弥补,而不是目标制定之后就搁置一旁。

四、拉动的测试

1.将HRC作为沟通语言

在QA组织内部以及工程组织的沟通交流中，也逐步形成了HRC文化。管理者们通过对RC指标的考核，推动测试工作的有序开展、保障每个发布版本质量。从另一方面说，是由RC拉动或者牵引整个庞大团队不断向前迈进。测试团队向工程组织的管理层做有关某一发布的进展快报时，也是以RC指标数据为抓手。

2.跨部门指标共享

软件质量从来不仅仅是测试人员的事情，更是产品经理和开发人员的职责。体现在HRC上，就是各个类目下的指标，都有上述3个角色的负责人。表明了该项指标的制定、实施和达成的过程是各方共同努力和协作的结果。

3.指定专人作为牵头人(release champion)

牵头人负责推动该次发布的各项测试工作的推动和协调，以及HRC的度量工作。通常这个人选会是某个测试团队的技术主管或者经理。这为测试副总和总监们发现和培养潜在的管理者提供了很好的练兵机会，这也是HRC实施过程中的另一个收获。

五、小结

借助于CMMi的成熟度模型定义，笔者尝试形成了测试完成准则的成熟度模型及其相关的活动，详见下图4。

图 4 测试完成准则的成熟度模型

笔者认为，在这个大型研发工程组织中使用测试完成准则的实践过程就是成熟度不断提升的过程，从初期完成准则的订立，到类目和度量项目的横向扩充，再到纵向提升，最后成为整个组织的共享的行动目标，充分体现了持续改进的思想。当然，持续改进永远在路上，各个公司和单位的业务领域和组织形态也各不相同，本文抛砖引玉，欢迎读者交流。