读Google是如何作软件测试的

网上有《What Test Engineers do at Google》的原文翻译，以及相关中文书籍《google软件测试之道》。今天不会在这里搬内容，写一些读书笔记和感悟。

测试组织架构

测试团队成败，组织架构也是影响因素之一。Google的组织汇报关系被划分为不一样的专一领域，包括：客户端、地理、广告、Apps、移动等等，全部工程师都汇报给这些专一领域的管理者、总监或副总裁。而测试是独立存在的部门，测试依托在各个产品领域部门内，称之为工程生产力团队。

• 软件测试开发工程师

职责：负责可测试性和测试自动化体系的长期有效性。

扮演质量顾问的角色

在单元测试方面给予开发人员支持

为开发人员提供测试框架，方便开发提升测试效率

参与设计评审、重构代码增长可测试性，编写单元测试框架和自动化测试框架

更加关注于质量提高和测试覆盖率的增长，SET写代码的目的是可让SWE测试本身的功能

• 测试工程师

职责：评估对用户的影响以及软件产品总体目标上的风险

从用户的角度来思考质量方面各类问题

从开发角度来看，他们编写用户使用场景方面的自动化用例代码

从产品角度来看，他们评估总体测试覆盖度，并验证其余工程师角色在测试方面合做的有效性

产品专家、质量顾问和风险分析师

其中，几个重要信息：

开发能够作测试，测试能够写代码，Google其实尚未彻底作到这一点

SET须要编码，熟悉系统设计，我的以为更像测试架构师的角色

没有测试开发比例，开发同时也兼顾测试，专职测试让开发更加有效且高效地作测试

测试开发同工同酬

有外包测试人员

曾经介绍过传统软件测试人员以黑盒测试为主，在团队转型中，咱们已经作出了改变，优先解决单一端的全栈测试，而且把单元测试做为一个关注点分水岭。

测试质量理念

质量不是被测试出来的，这句看似陈词滥调的话却包含着必定的道理。

从汽车行业到软件行业，若是在最开始设计建立的时候就是错的，那它永远不会变成正确的。试问一下汽车行业的公司，大量召回事实上有质量问题的产品，代价是多么的昂贵。所以，从最初的建立阶段就要作正确，不然即使质检发现了质量问题，也将会陷入混乱的万劫深渊。

然而，这句话也并不像听起来那样的简单和准确。虽然质量不是被测出来的，但一样有证据能够代表，未经测试也不可能开发出有质量的软件。若是连测试都没有作，如何保证你的软件具备很高的质量呢？

有一个简单的办法能够解决这个难题，那就是中止开发与测试的隔离对立。开发和测试应该并肩齐趋。你的每一段代码写完后都要马上测试这段代码，当完成了更多的代码时就作更多的测试。测试不是独立隔离的活动，它自己就是开发过程的一部分。质量不等于测试，当你把开发过程和测试放到一块儿，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就获得了质量。

质量不等于测试，测试不能保证质量，质量是内建的，不是外加的

质量是开发过程的问题，而不是测试问题

开发对质量负责

开发、测试相融合

写一段代码就马上测试这段代码，完成更多的代码就作更多的测试，开发完成。

简单统一

测试类型

测试类型划分：小型测试（70%）、中型测试（20%）、大型测试（10%），其实就是分层理念。弃用使人疑惑的测试类型术语：单元测试、代码级别测试、白盒测试、集成测试、系统测试、端到端测试。

其中一个亮点， Google在2007年，15个试点团队在不一样级别运行：测试认证。开发人员遵循一些特定的测试实践，拿到指望结果，则经过认证。

测试成熟度等级

测试成熟度，就是刚刚提到的：测试认证。我的见解：在敏捷团队，若是研发小组获得成熟度认证，能够区分不一样程度测试资源投入。

• Level 1

Set up test coverage bundles.

Set up a continuous build.

Classify your tests as Small, Medium, and Large.

Identify nondeterministic tests.

Create a smoke test suite.

• Level 2

No releases with red tests.

Require a smoke test suite to pass before a submit.

Incremental coverage by all tests >= 50%.

Incremental coverage by small tests >= 10%.

At least one feature tested by an integration test.

• Level 3

Require tests for all nontrivial changes.

Incremental coverage by small tests >= 50%.

New significant features are tested by integration tests.

• Level 4

Automate running of smoke tests before submitting new code.

Smoke tests should take less than 30 minutes to run.

No nondeterministic tests.

Total test coverage should be at least 40%.

Test coverage from small tests alone should be at least 25%.

All significant features are tested by integration tests.

• Level 5

Add a test for each nontrivial bug fix.

Actively use available analysis tools.

Total test coverage should be at least 60%.

测试流程

• 测试尽早参与，各个环节参与，多Review文档，代码，架构。Code Review 是专门有一套Submit的流程；

• 高度自动化，强调持续集成；

• 测试分大中小测试，大中小范围、执行人、时间和要求不同；

及早参与测试，毕竟质量不是测试出来的，整个研发过程的第一行编码已经决定了质量的高低，过程当中反馈风险，利用有效测试策略消除质量障碍，确保检验处有问题的地方及时修改，避免遗漏上线。

版本划分

先会爬，再会走，最后跑起来，版本划分短频快三个要点。

金丝雀版本（Canary Channel），不太可靠的版本，并不适用于发布。就像一只金丝雀在煤堆里同样，若是不幸身亡，那说明还有工做要去作。只有超强容忍能力的用户才有可能使用金丝雀版原本试验运行，你不能依赖这样的应用能把实际工做完成。

开发版本（Dev Channel)，是开发工程师们平常工做中使用的版本。全部的同一产品组的工程师都须要去安装这个版本，并在真正的工做中使用他们。

测试版本（Test Channel），是给内部的狗食，若是可以有持续不错的性能表现的话，也可能会是 beta 版本的候选。【译者注，dog food，通常指本身团队的产品，给本身或者公司内部的人尝试使用的中间产品】

Beta 版本或发布版本(The Beta Channel or Release Channel)，是给外部用户使用的第一个版本。只有在以前的各类版本历程中经过了测试和真实用户的枪林弹雨般的验证后，才会成为 beta 版。

上述的这种从爬到走、走到跑的模式，让咱们在运行一些测试同时又能够对咱们的应用系统作一些试验调整，并从真实用户和每一个版本的每日自动化测试那里获得及时的反馈。

对于这样的过程，还有一些分析角度的益处。例如，发现了一个 bug，测试人员能够根据这个 bug 建立一个测试用例，并针对全部的每个版本都运行这个测试用例，从而能够验证这个 bug fix 是否在全部的版本中都真正获得了修复。

Google流程中的致命缺陷

• 测试成了开发的拐杖

质量须要每个人的贡献，而不专属于“测试”工程师。咱们越不让开发考虑测试的事情，把测试变得越简单，开发就愈来愈不会去作测试。测试在Google是一个独立的部门，让这个问题更严重。保证质量不可是别人的问题，它甚至还属于另外一个部门。责任方很容易肯定，出问题的时候也很容易就把责任推卸给质量部门。

• 开发和测试的组织结构分离有关

测试人员更关注本身的角色，而不是他们的产品，每个工程师的角色都是为整体产品服务的，而角色自己是次要的。 若是产品不被关注，它就好不了。毕竟，软件开发的最终目的不是编码，不是测试，不是文档，而是完成一个产品。每个工程师的角色都是为整体产品服务的，而角色自己是次要的。健康的组织一个标志是，人们会说“我在为Chrome工做”，而不是“我是测试”。

任何角色都不该被过度强调。团队的每一个人都是在为产品工做，而不是为了开发过程当中的某个部分。开发过程自己就是为产品服务的。用户爱上的是产品，而不是开发产品的流程。

在Google，开发与测试的分离形成了基于角色的关联，阻碍了测试人员对产品的关注。

• 测试人员每每崇拜测试产物赛过软件自己

测试的价值是在于测试的动做，而不是测试产物。相对于被测代码来讲，测试工程师生成的测试产物都是次要的：测试用例是次要的；测试计划是次要的；bug报告是次要的。这些产物都须要经过测试活动才能体现价值。全部测试产物的价值，在于他们对代码的影响，进而经过产品来体现。

独立的测试团队，倾向于把重点放在建设和维护测试产物上。若是把测试的目标定位在产品的源码上，整个产品都将受益。所以，测试人员必须把产品方在第一位。

• 产品通过最严格的测试发布之后，用户几乎必然发现测试中遗漏的问题

产品通过最严格的测试发布之后，用户有多大可能仍然能发现测试中的遗漏的问题？答案是：几乎必然发现。是谁在作测试不重要，关键是进行了测试。内部试用者、可信赖的测试者、众包测试者，以及早期用户均可能比测试工程师更容易发现bug。实际上，TE作的测试越少，支持其余人作的测试越多，效果就越好。

Google软件测试成长历程

软件测试团队的发展，也是围绕着质量闭环活动而壮大的，不一样的质量活动环节，须要不一样的人。刚开始创业的时候，可能一人多职能，到了后面多是专人专职，分工喜欢，无论怎么分，都离不开质量闭环活动。

移动互联网APP团队测试技术栈

随着团队不断壮大，技能集合也在扩大，下图是整理的测试技术栈，经过分层来展现每一个方面的覆盖策略和工具，能够在此基础上创建梯队能力。