案例综述 | Google和Facebook如何做质量保证
如果一个bug影响到一个小App的0.01%的用户群，那么它可能就不值得投入精力。如果它影响到谷歌和Facebook的0.01%，那就是成千上万的投诉，以及可能要处理的媒体丑闻。我们都知道那意味着什么。
测试覆盖率
关于代码覆盖率的欺骗之处在于，一旦您开始组合代码块并测试所有可能的路径和结果，即使是在中型项目上，你也会快速地进行接近无限数量的测试。
所以大型应用程序中代码的复杂性也决定了两点：一是自动化测试是必要的；二是你无法一个大型应用，达到100%的代码覆盖率。
谷歌代码的测试覆盖率
如果没有非常高的质量保证标准，谷歌的规模可能不会像今天这么大。幸运的是，谷歌在博客上写了很多关于他们的测试和质量保证的内容，所以我们可以洞察到一些他们所用的方法。
谷歌的办公室
上面两个图的数据来自于衡量谷歌代码覆盖率的文章。谷歌z_rich部门的Marko Ivankovi说明了不同的开发者或公司，对代码覆盖率指标的不同态度。明显就是两极分化的：
“有些人认为这是一个非常有用的度量标准，并且应该对所有代码强制执行一定比例的覆盖率。一些人认为它是一个有用的工具，可以识别需要更多测试的领域，但不一定相信覆盖的代码确实经过了很好的测试。还有人认为衡量覆盖率是积极有害的，因为它提供了一种错误的安全感。”
为了回答代码覆盖的重要性以及应该如何操作，Marko研究了在Google使用的两种类型测试的测试覆盖：每日构建和预提交构建。
每日构建会测试一天中的WIP代码，在走得快远之前及时提醒工程师，帮助他找到要修复的bug。预提交构建只聚焦于让提交更顺利的那些测试。
下面是谷歌用来标记代码是否被测试覆盖的内部工具截屏:
通过这种简单的工具实现，在10万次提交之后，Google将所有项目的代码覆盖率提高了10%。
同样需要注意的是，他们的质量控制过程的这一部分是纯粹的自动化测试。（稍后将详细介绍该过程的其余部分。）
Facebook的办公室
Facebook的代码覆盖率
Facebook通过代码覆盖工具获得的数据来通知他们的自动化测试结果。根据一位前Facebook工程师的说法，代码覆盖率保持在最高水平，根据代码语言的不同，有几种不同的方法：
PHPUnit 毫无疑问，它被用于对PHP进行单元测试。这是Facebook架构的重要组成部分。测试可以由开发人员、专职测试人员或者软件本身触发运行。
对于测试那些显示给用户的内容，Facebook工程师使用 Watir这个工具,测试包括手工和半自动化。
失败的测试会自动通知开发者，并被登记到开发者可以查看的数据库中。
Facebook也有大量的开发工程师，如果没有良好的测试文化和严格的代码覆盖指导方针，在6100万行代码上工作将开始导致严重的问题。
然而，关于Facebook的测试过程和对QA的态度，更有趣的事情之一是它接受自己产品可以有缺陷这一事实。
EvanPriestly，前Facebook工程师，说公司没有任何纯粹的质量控制角色，员工只负责为他们自己的代码编写测试。
这是因为社交媒体并不是交易型产品。缺陷不会导致火箭在进入大气层后爆炸。
“通过减少对质量的投入，Facebook能够专注于其他事情，比如让公司成为一个有趣的工作场所，这样可以吸引和留住有才华的工程师。如果Facebook非常注重质量，它可能就没那么有趣了。[…]社交网络对人们来说并不重要。这很重要，它不是银行、航天飞机或核反应堆。不是桥，也不是车。它甚至不是电子邮件（至少在大多数情况下）或电话。这也给了Facebook更多的工作空间。”
测试文化
传统上，开发人员写代码，QC人员去测试它，QA保证整个流程是高效的和无漏洞的。然而，谷哥和Facebook显示并没有用传统方式构建其组织结构。
两个公司都强调个人的责任（Facebook甚至有办法让提交烂代码的工程师感到羞愧)，将测试看成是文化的一部分，而不是一个跟在开发人员后面打扫垃圾的部门。
在谷歌对一个游戏相关API开发者(game-related API developer)的工作描述中，它具体要求是： “与产品工程团队工作，改进我们的产品，通过从开发者那里带来回API的反馈，reviewAPI的设计，测试新特性”，以及其它一些要求。
谷歌招聘工程师时，要求他不害怕做测试，这是整个招聘测试的起点。
Facebook也是一样。在工作描述中就让申请都知道，测试是自己工作的一部分。 如一个发布工程师（release engineer）要负责 “管理源代码管理系统， 自动化的构建和回归测试， 开发一些用于软件部署的构建和监控工具。
谷歌如何测试软件
在2011年的文章 ，InfoQ 说谷歌的测试部门相对于开发人员来说比较少，但运行的还不错，因为与Facebook一样，每个开发工程师负责他们自己代码的测试。
谷歌通过创建测试文化达成这一点，而不是通过一个抽离且无链接的独立部门达成的。对于20亿行代码库（2 billion lines of code ）来说，这个成就可以说是一个巨大的成功。
“质量是一个开发问题，不是测试问题。也就是说，我们能将测试实践嵌入到开发活动中，我们创建了一个流程，不只是增量开发，而且如果某个增量出现问题，那个增量可以单独回滚。我们不仅阻止了大量的客户问题，而且大量地减少那些用于提前发现召回类缺陷的测试人员。”
谷歌解释这个现象是因为产品团队负责质量，而不是测试人员。测试人员写自动化让开发人员用它们来做测试，不多也不少。
这样的好处是：
开发人员和测试人员是平等的。
多对一的开发测试比
开发人员只要写代码，不用非要花太多时间做测试
一个知名的大公司有能力自己制造任何东西。谷歌使用自己的工具跟踪测试-谷歌测试用例管理器（Google Test Case Manager），以及自动化测试。
Facebook如何测试软件
Facebook通过聚焦于代码ownership 来保证每个人都自己全面负责他们的工作质量。
这并不是说，没有他们没有peer-reviewed, 而是:
“编写的每一行代码都由不同于原始作者的工程师进行审查。这有多种用途：最初的工程师有动机确保代码的高质量，审查员有一个新的想法，可能会发现缺陷或建议替代方案，而且，一般来说，有关编码实践和代码本身的知识在整个公司传播。”
因为Facebook有大量的beta testers（例如对新特性没有预期的用户群就是指暗部署 dark launched），这意味着它可以将新的构建部署到其用户基础的一小部分，并测试新功能的功能，而不会给其余部分带来太多麻烦。
这种无自有测试人员的做法，以及代码责任制，就得得到一种公司的工程环境，它带来的主要好处是：
工程师可以快速地发布新特性，并不断迭代
在99.999%的用户知道之前，缺陷就被修复了
不需要专门的测试人员，通过强调代码质量得更好的公司文化
Facebook用于测试的工具包括PHPUnit, Watir, Boost, JUnit, and HipHop (internally developed software).
想要了解更多，请扫码参与4月20日下午，在北京举行的《持续交付2.0》研讨会~
本活动还有少量名额开放，机会有限，速速报名
我的新书《持续交付2.0》现在就可以在京东购买~