《Google软件测试之道》这本书2013年就已经出版了(英文版出版于2012年)。以前幼稚地以为,开发人员对于测试方法论没必要系统的学习,只要知道怎么与测试人员一起工作就好了,所以一直没有读。最近由于一些机缘巧合,拜读了一下,大有收获。
注意,本文并非《Google软件测试知道》的读书笔记,里面有一些笔者个人思考的结果,如果想了解原书观点,还请阅读原书。

测试之道

“道”即是世界观。每次听到新的道,都是一次对世界观的颠覆。这种打通任督二脉的爽快,正是笔者每次阅读的动力。《Google软件测试之道》书名中的“道”字其实是意译的结果(英文原版书名为《Google是如何测试软件的》,用来致敬《微软是如何测试软件的》),但是却非常贴切。
让我们开始毁三观吧。
如果对于测试只能问一个问题,然后围绕这个问题的答案来安排所有测试活动,笔者认为,这个问题应该是“测试的目标是什么?”。回答了这个问题,也就理解了测试之道。
有人说测试是为了发现产品中的问题,更有经验的人说测试是为了保证产品的质量。笔者认为,这两者都不贴切。测试的目标,跟任何企业活动的目标一样,是减少企业的成本、增加企业的收入,从而提高企业的利润,简而言之,就是 让企业赚钱。换句话说, 不能帮企业赚钱的测试就是耍流氓(注,这里的钱指广义的企业价值,而非狭义的货币资本)。
有人说,这不是废话吗?还真不是废话。因为只有这个目标,才能真正指导决策者在两难的环境下做出正确的抉择。举个例子,自动测试用例该不该写?看起来这似乎是一个绝对政治正确的说法,实则不然。我们套用前面提出的测试的目标,就很容易发现自动测试用例不见得是一件好事。如果一个项目还在原型阶段,存在很大被终止(出于市场、用户习惯等原因)的可能,这时编写自动测试用例就是完全没有必要的。
在《Google软件测试之道》中有着大量的例子和指导方针。这些解决方案的思路都是围绕着“减少成本、提高收入”来展开的。

测试之术

了解了“道”,也就有了行动纲领。那么,在测试的工作中,该如何应用呢?《Google软件测试之道》一书中,给出了大量的指导方针和示例。笔者在此摘录其中几个笔者曾经有所疑惑的问题。

测试应该由谁进行?

有人说测试就是测试人员的事;有人说开发人员就应该保证自己代码的正确性,因此开发就应该进行测试。原作者给出的答案是:以上都不对。前者太狭隘,后者太理想主义。在实践中,绝大多数开发人员是不能站在用户的角度看问题的。这是一个思维模式的问题,并不是喊喊口号就能解决的。更具可操作性的办法是,专门招聘能够站在用户角度看问题的人。Google的做法是三权分立:开发辅助团队(测试开发工程师)负责搭建测试的基础架构,开发人员负责编写测试代码,而由测试工程师负责站在用户的角度进行自动化或手动测试。

怎么决定测试什么?

由于人的精力有限,在从事每一个行动前,找出行动目标,比展开行动更重要。即使是同一款产品,不同特性所分配的精力也是不同的。那么,如何决定怎么分配精力呢?答案是,根据测试之道,最能让企业赚钱的产品特性,就应该分配最多的精力。
Google在实践中,为了发现哪些产品特性更重要,采用了列举ACC的方式。A指产品的属性(attribute),表示产品对用户的核心价值;第一个C是组件(component),表示产品系统所组成的模块;第二个C是能力(capability),表示系统能完成的动作,通常是一个产品属性和组件的组合。如果一个能力没有对应的产品属性,那么这个能力是没什么用的。利用这一点可以验证产品特性是否重要。
了解了产品的能力之后,根据产品能力来安排精力,这种做法最有效率。

测试什么时候开始?

系统的质量是内建的,不是外加的。外部的测试只能发现问题,不能改变系统质量,就像温度计不能帮人解暑一样。因此,测试的效能主要体现在两点:一是保证早期决策的正确性以影响后面的决策,这是因为,后面决策往往依赖于前面的决策,前面决策失误所造成的影响要远大于后面决策;二是保证系统质量不会明显下降。无论是哪一种,都要求测试必须尽早加入到产品当中。一旦测试对于产品出现意义(见前文是否应该编写自动测试一例),需要编写测试,那么测试的关键节点(提交,运行)就应该跟开发的关键节点同时进行,而不是滞后。

如何让开发人员编写测试代码?

作为一名开发人员(曾经是,现在也是),深切地能够体会到当有人强制让你编写测试时的那种痛苦。开发人员不愿意编写测试代码主要有两个原因:投入高、效果差。这并不是开发人员“玻璃心”或者性格问题造成的:如果编写测试代码要占掉比编写代码多很多的时间,而且还要经常花精力来改正一些失败的测试,又看不到对产品质量的提升,任谁都不会喜欢去做这样的事情的。
要解决这个问题,要多从流程上下功夫:

  1. 不盲目追求代码覆盖率。要认识到代码的变动机会是不同的。变动机会大的代码代码覆盖率越高,维护成本越高。如果维护成本高于收益(不能帮企业赚钱的测试就是耍流氓)的时候,就应该停下来反思一下了。在Google测试能力评级的最高级标准中,整体覆盖也仅有60%而已。
  2. 根据产品能力(见“怎么决定测试什么”一条),删掉不重要的测试代码。如果认为测试代码留在产品里所带来的维护成本,大于所带来质量提高的收益,大胆地删掉他们吧。
  3. 即时加入重要功能的测试代码并修正失败的测试。这样开发人员可以知道,测试代码真的在保护着他们正在开发的应用的质量,而不是做做样子的面子工程。

如何分配各种自动化测试的比例?

我们平常说的单元测试、集成测试与端到端测试,在Google被分为小型测试、中型测试和大型测试。简单来说,小型测试不依赖外部系统,全靠mock,用于验证代码单元功能;中型测试会依赖外部系统,但是并不涉及多UI或者网络服务的对接,用于验证多模块之间的交互;大型测试包含多个系统,通常用于验证系统作为一个整体的工作。小/中/大测试的分配比例为70%/20%/10%。

以上只是笔者的几点心得。原书提供了大量可操作的流程和工具,实在是不可多得的一本好书。