nonocast/me

Google 软件测试之道 读书笔记

Opened this issue · 0 comments

nonocast commented

Publisher: Addison-Wesley Professional; 1 edition (April 2, 2012)

序 -- 谷歌工程总监 Alberto Savoia

2001年，Google大概有200名开发人员，但只有区区3位测试人员! 那个时候，开发人员已经开始做自己代码的测试了，但由于测试驱动才刚刚开始，而且像JUnit还没有大规模使用。当时的测试主要是在做一些随机测试 (ad-hoc testing)，其好坏取决于编写代码开发者的责任心。但即使那样也是可以接受的，因为，当时正处在创业阶段，必须快速前进并勇于创新，否则就无法和那个时代已经非常强大的对手竞争。

开发人员发现，为了测试充分，他们不得不针对每一行功能代码，写两到三行的单元测试代码，而且这些测试代码和功能代码一样都需要维护，且有着相同的出错概率。而且大家也意识到，仅做单元测试是不够的，仍然需要集成测试、系统测试、用户界面等方面的测试。当真正开始要去做测试的时候，会发现测试工作量变得非常大（且需要很多知识的学习），并要求在很短的时间内完成测试，要以“迅雷不及掩耳”之势完成。

我们为什么要在很短的时间内迅速地完成测试? 我一直这么认为，对于一个坏点子或考虑欠周的产品，即使再多的测试，也无法把它变成一个成功的产品。但如果测试方法不当，却会扼杀一个本来有机会成功的产品或公司，至少会拖慢这个产品的速度，让竞争对手有机可乘。

序 -- Patrick Copeland

2005年，工程团队还不足1000人，测试团队大概有50名全职人员和一些临时工，测试团队当时的称谓是"测试服务"， 工作重点在UI的验证傻姑娘，随时响应不同项目的测试需求。

第1章 Google 软件测试介绍

Google 是如何测试的?

在Google，软件测试团队归属于"工程生产力"（Engineering Productive）的中心组织部门，这个部门的职责横跨开发测试人员使用工具的研发，产品发布和各种级别的测试，从单元级别的测试到探索性级别的测试。

当有人来问我，Google 成功的关键是什么，我的第一个建议就是，不要招聘太多的测试人员。正如Larry Page所说，“少则清晰”。在通往成功的道路上，Google的测试团队并非雄兵百万，我们更像是小而精的特种部队，我们依靠的是出色的战术和高级武器。

Google在测试人员如此缺乏的情况下，是如何应对的呢？简单地说，在Google，写代码的开发人员也承担了质量的重任。质量从来就不仅仅是一些测试人员的问题。在Google，每个写代码的开发者本身就是测试者。

1.1 质量不等于测试

质量不是被测试出来的。如果在最开始的设计创建的时候就是错的，那它永远不会变成正确的。从另外一方面来说，虽然质量不是被测出来的，但同样有证据表明，未经测试也不可能开发出有质量的软件。如果连测试都没有做，如何保证你的软件具有很高的质量呢?

角色

  • 软件开发工程师 (SWE, Software Engineer)，传统上的开发角色，实现最终用户所使用的功能代码，创建设计文档，选择最优的数据结构和整体架构，并且花费大量时间在代码实现和代码审核上。SWE还需要编写和测试代码，包括测试驱动的设计、单元测试、参与构建各种大小规模的测试等。

  • 软件测试开发工程师 (SET, Software Engineer in Test)，也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。他们参与设计评审，非常近距离观察代码质量和风险。为了增加可测试性，他们甚至会对代码进行重构，并编写单元测试框架和自动化测试框架。SET是SWE在代码库上的合作伙伴，相比较SWE是在增加功能性代码或是提高性能的代码，SET更加关注质量提升和测试覆盖率的增加。SET同样会花费几乎所有时间在编写代码上。他们这样做的目的是为了质量服务，而SWE则更加关注客户使用功能的开发实现上。

  • 测试工程师 (TE, Test Engineer)，是一个和SET关系密切的角色，有自己不同的关注点--把用户放在第一位来思考，代表用户利益。TE直至整体质量实践，分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试。TE扮演双重确认的角色，一方面确认开发人员在测试方面的工作是否到位，任何明显的bug都会表明早起开发人员所做的测试工作存在不足或比较马虎。当这些明显的bug变少时，TE会把注意力转移到常见用户使用场景中去，是否满足性能期望，在安全性、国际化、访问权限等方面是否满足用户的要求。

组织结构

Google的测试团队不隶属于项目团队，而是独立存在的部门，是与专注领域部门平行的部门（横跨各个产品专注领域），我们称为工程生产力团队。测试人员基本是以租借的方式进入产品团队，去做提高质量相关的事情，寻找一些测试不足的地方，或者公开一些不可接受的缺陷率数据。

这种借调模式可以让SET和TE时刻保持新鲜感并且总是很忙绿，另外还能保证一个好的测试方法可以快速在公司内部蔓延。

爬、走、跑

Google从来不会在一次产品发布种包含大量的功能。实际上，我们的做法恰恰嫌犯，在一个产品的基本核心功能实现之后，就立刻对外发布使用，然后从用户那里得到真实的反馈，在进行迭代开发。

一个产品在发布给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta或正式发布版本。

  • 金丝雀版本 (Canary Channel)：即每日构建版本，用来排出过滤一些明显不适宜的版本。使用金丝雀版本需要极度的容忍度，而且在这个版本下可能无法使用应有的基本功能。一般来说，只有这个产品的工程师（开发或测试人员）和管理人员才会安装使用金丝雀版本。

  • 开发版本 (Dev Channel): 这是开发人员日常使用的版本，一般是每周发布一个。该版本具有一定的功能并通过了一系列的测试。所有这个产品下的工程师都会被要求安装这个版本，并在日常工作中真正使用它，这样可以持续对这个版本进行测试。如果一个开发版本不能够满足日常真实工作的需求，那么它将会被打回为金丝雀版本。发生这种情况不但令人郁闷，工程团队也需要在花费大量的时间去重新评估。

  • 测试版本 (Test Channel): 这是一个通过了持续测试的版本。这个版本基本上是最近一个月里的最佳版本了，也是工程师日常工作中使用的最稳定最信任的一个版本。测试版本可以被挑选作为内部尝鲜 (dog food) 版本，如果该版本有比较持续良好表现，也是作为beta测试的候选版本。

  • beta或发布版本 (Release Channel): 这个版本是由非常稳定的测试版本演变而来，并经历了内部使用和通过所有质量考核的一个版本，也是对外发布的第一个版本。

注: 这里不是Web项目，而是Chrome，所以才会说每个人都要装Dev。

测试类型

Google并没有使用代码测试、集成测试、系统测试这些命名方式，而是使用了小型测试、中型测试、大型测试这样的叫法，这种强调测试的范畴(Test Size)而非形式。

  • 小型测试 (Small Test): 单元测试，快速执行，由SWE负责，主要解决“这些代码是否按照预期的方式运行”。
  • 中型测试 (Medium Test): 通常都是自动化实现的，该测试一般会涉及两个或两个以上，或更多的模块之间的交互。测试重点在于验证这些“功能近邻区”之间的交互是否正确。主要有SWE和SET负责。
  • 大型测试 (Large Test): 涵盖三个或更多的功能模块，使用真实用户使用场景和实际用户数据，一般可能需要消耗数个小时或更长的时间才能运行完成。更倾向于结果驱动，验证软件是否满足最终用户的需求。主要由TE和SET负责。

后面的内容就是展开来说每种角色的具体工作，值得一读。