实践中的质量度量

　 　在马良（花名）的简单开场之后，活动便进入正题，由来自支付宝SQA团队的西剑（花名）为大家分享了一些持续集成中的代码度量模型与实际应用。首先，西 剑做了一个现场调查，在场多少人的公司在实施持续集成，结果现场几十名同学约有10人举手，而当问及有多少公司在做代码度量时，就只有一位爱立信的同学依 然举手。由此可见，经过一段时间的推广，持续集成这一实践已开始为大家所认识，并开始尝试，而代码度量的实施情况不容乐观。51Testing软件测试网fCV8f,x ean

　　统一配置管理（UCM） 就指出对代码变更的范围是可以进行精细化管控的。说起代码质量管控，目前面临三大挑战――精准、快速、协同。那代码质量到底是什么？现场有人提出稳定性、 健壮性、可维护性，其实有很多衡量代码质量的模型，比如圈复杂度。这么多模型，该如何在实践中加以用？西剑提出有效的代码度量模型应具备以下特征：51Testing软件测试网5O.RkYgI

-\-PGm&b P0　　● 与组织的目标一致：代码度量模型的底线要与组织的要求一致，和业务相关的东西会体现在规范里。在支付宝，代码安全规范、敏感信息处理规范被作为代码质量最基本的要求。51Testing软件测试网?i.`BQC/O
n

　　● 有针对性：要做针对性分析，比如对线上故障的研发原因进行分析，分析的规则会有周期性变动的，但不要太频繁，而且规则会随着组织的成熟度而改变。

2ZH:G7tD$VR-h!A0　　● 可操作性：要对度量维度做进一步分解，比如测试要有明确的检查点，覆盖要完整，可重复运行。支付宝就制定了具体的度量维度，从多个维度对系统加以度量。51Testing软件测试网8]G'HtjA.n$k

{s%y4_F1zB0　　● 有工具支持：这不是必要条件，工具不能解决所有问题！能用工具最好，不行的话就人工检查。工具检测维度要按照优先级和操作性，逐步增加精细化维度。这一点上，支付宝将一些编码规则的检查放入了持续集成工具之中，以求尽早检查、频繁检查。51Testing软件测试网1Dl#U_Ll"}o

0H;pX}5u c0　　西剑介绍了支付宝正在构建的一套持续集成平台，自上而下分为DashBoard、服务管理层与服务层，其中最为基础的服务层中就提供了单元测试（构建服务、静态扫描、单元测试、CodeReview）、集成测试（API测试）、系统测试（SIT、UI测试）等众多服务。51Testing软件测试网C%a t F?6d+[

tSZ
PH[ aI"r0　 　当被问及人工CodeReview是靠资深的工程师来做，还是质量部门自己来做时，西剑认为最佳的方式是项目成员进行交叉CodeReview。如果靠 资深的架构师来进行CodeReview，他可能只会关注代码规范或者一些上层的东西，无法深入细节，因为他本身的视角太高，不清楚业务实现的具体细节， 而项目的成员或者开发Owner可能更清楚这些东西。

4R!D&@iC"wX1rDz
`0　　代码度量模型又该如何应用？首先，要有度量模型作为代码质量标准，引导团队代码质 量意识和方向；其次，辅以持续集成，实时监测代码复合模型中客观质量度量的情况，再配合人工CodeReview保证业务一致性。持续集成相对客观，而人 工的CodeReview则较为主观。产品在发布之前，必须满足组织的代码度量模型，否则不予上线。

　　在进行了度量之后，系统代码质量可 以在多个系统间进行横向比较，其中服务型系统与应用型系统质量要求会有所区别，新老系统会有区别，检查系统量目标是否达成，以此确定部门改进的系统范围和 目标。单个系统也可进行纵向比较，了解系统质量的变化趋势，分析原因，确定单个系统质量改进月度目标。

,E qRI;@nF8U0　　质量度量并不是一个人，或者几个人就能轻松实现的，需要建立有效的执行体系，西剑建议可以从以下几个方面着手：51Testing软件测试网0Vu6a b BaNya-L

　　● 获得管理层认同：让管理层能看得见目标，看得到做法，往往有技术背景的管理层更容易说服。

　　● 流程保障：把要求放入日常流程之中。

　　● 组织保障：要有人专门负责制定、维护、解释标准，并将标准落地，因此可以成立专门的组织（可以是一个虚拟组织），在支付宝就有一个名为SQPG的组织。

　　目前的质量度量主要还是集中在开发阶段，今后可能会将部署阶段也囊括进来，部署的度量主要包括系统依赖性检查、配置一致性检测、应用部署验证、 DB部署验证、性能极限验证和业务验证。此外还要寻求更科学的度量指标，在实践中圈复杂度也会有这样那样的问题，需要寻找一些更合适的度量指标。51Testing软件测试网 s ~|*I2nUH

]3]|*s;C;M0　　在简短的休息之后，来自51Testing的宋光照为大家介绍了如何构建可维护的自动化测试。首先，他分享了他对软件质量特性中的可维护性的理 解，可维护性包含易测试性（降低发现缺陷的成本）、易分析性（降低定位缺陷的成本）、易改变性（降低修改缺陷的成本）和稳定性（减少频繁修改而导致的不稳 定），其中易测试性是最为重要的。测试自动化和自动化测试常被混为一谈，宋光照解释到自动化测试偏重于测试的执行，而测试自动化则包含自动化测试管理、自 动化测试执行和工具支撑三个部分。自动化测试目前面临了很多挑战，比如软件测试的时间越来越短，变更越来越多越来越频繁，回归测试成本压力越来越大。业界 对自动化测试的需求大致可以归纳为：

　　● 要求是执行快、效率高、可重复的自动化测试资产

　　● 自动化测试工具成本要低

G f9L"W!|9H0　　● 要有易学易用的自动化测试方法

~*x0a(W*D.~*FE X0　　● 对提高软件质量有评价或质量度量指标

　　而开发对自动化测试也有自己的需求：51Testing软件测试网g/L/g}t+W#J0YH

　　● 能尽早快速发现软件缺陷

　　● 工具要有自我检查和任务闭环管理功能51Testing软件测试网9NQ+Z7}M#m d6m

Y6i$ccz4yF0　　● 对提高编程质量有指导性意义

b7EcR
E0　　● 自动化测试工具链支撑能适应自身开发模式51Testing软件测试网(so-O"o-H(ud4j

　　从自动化的角度来看，底层从单元测试开始时比较现实的，只要提供了框架，传递了合适的方法即可。面向函数级别，请考虑单元测试；面向API层 面，构建功能测试，快速做验收；面向GUI层面，开展录制回放；从使用者角度来关注质量，做一些手工测试。宋光照强调了测试自动化开发也是软件开发，要多 考虑可测试性设计。随后，他为大家演示了两套自动化测试工具，介绍了一些实际使用案例。

　　在成本方面，自动化测试也要有投资回报考虑，至少要回归3次才会有收益，随着版本迭代次数增加，收益会明显提高，如果考虑其他平台兼容性问题， 收益还会成倍增加。在实施前期，需要投入自动化测试管理、人员和研发过程管理，做到人员清楚定位、合理分层。自动化测试在起步阶段，重在用例转化，将手动 测试转为自动化测试；在成熟阶段则重在效率，提高用例重用度，提高持续集成和每日构建效率。

5|3V,~a!xY0　　关于质量度量与自动化测试，还有很多值得深入讨论的内容，如何把控软件质量，各位读者，您是怎么做的？51Testing软件测试网aAAzvtOXt