读书笔记：Google软件测试之道【一】

目录

前言

1、Google软件测试介绍

2、角色

3、分工

4、组织架构

5、版本

---

前言

       在职业生涯的头6年，我对所谓的测试策略、测试组织架构了解甚少，也不知道谁对谁错。我知道的事情只有一个：我是一名程序员，我的日常工作除了做需求分析和代码开发以外，我还需要做单元测试（数据准备、案例编写和测试报告撰写）、SIT测试（数据准备、案例编写和报告撰写）及UAT测试支持（数据准备）。简而言之，就是我们一个小团队，就是一帮开发工程师相互配合，组长负责进度质量把控与需求分析，下面的开发人员负责各自模块的开发与测试，团队成员之间会进行互测和代码审查以保证质量。但是，我认为正是这种貌似不严谨实则更科学合理的分工恰恰让我们培养起做事严谨、设计全面（特别是非功能性，如可测试性、可运维性等）的态度。

        今天，回顾在前司的工作跟《Google软件测试之道》这本书在某种程度上是不谋而合的。

 

1、Google软件测试介绍

- Google成功的关键是什么？作者的第一个建议就是不要招聘太多的测试人员。

- Google的测试团队更像小而精的特种部队，我们依靠的是出色的战术和高级武器。

- 在Google，写代码的开发人员也承担了质量的重任，开发者本身就是测试者。

- 质量不等于测试。当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。

2、角色

You build it , you break it , you fix it.离故障和缺陷最近的人绝对是开发人员，因此只有或者应该由开发人员才能修复。在Google分为三种角色：

1、软件开发工程师（SWE, Software Engineer），传统意义上的开发人员，负责所有业务功能的实现，创建设计文档、数据字典、接口文档，并花大量时间在代码实现及审查这两方面；同时他也要负责单元测试工作，及参与各种各样的测试工作（如类似的集成测试等）；

2、软件测试开发工程师（SET, Software Engineer in Test），他也是一个开发角色，只是工作重心会在代码的可测试性和基础的通用测试框架上。他们会参与项目的设计评审，更有甚者对负责对代码进行重构以便增加代码可测试性。SET是SWE在代码库层面的合作伙伴，只是SET会更关注整体质量提升及测试覆盖率的提高，而SWE会更关注业务功能的实现，这就是这两者的区别。

3、测试工程师（TE, Test Engineer），TE把用户放在第一位来思考；他们会组织整体质量实践，分析解释试运行结果，驱动测试执行，构建端到端的自动化测试。他们是真正的产品专家、质量顾问和风险分析师。

3、分工

从上述三种岗位职责基本可以看出来他们是如何配合：

首先，SWE会根据业务需求编写代码实现业务功能；但是做过很多年开发的同学也知道，代码中含有的功能（这里称“代码功能”）应该是业务功能和非业务功能（如容错性代码、运维辅助性代码、测试辅助性等）的总和。因此，需要SET提供测试支持，如建立测试框架保证通用测试能力，参与项目的设计评审，在测试角度(非开发角度)去审核代码与设计方案以确保方案或者代码的可测试性，这样即可实现真正意义上的独立功能模块的要求（因为测试案例也是基于独立功能模块的边界去设计的），后面的模块迁移可以做到功能代码和测试代码的共同迁移；

接着，在我看来，TE的工作主要分为两个阶段，即集成测试后期与用户测试（虽然Google里面没有SIT和UAT一说）。在SIT后期阶段，TE会通过SWE和SET在前面阶段产生的测试数据进行统计分析，并根据分析结果要求团队进行相应改进，这一阶段他负责整体的交付质量；在UAT阶段，TE会作为其中的用户测试人员参与，过程中除了考虑用于体验和使用场景外，TE也会考虑性能、安全、国际化等问题。

另外在分工方面，Google的很多项目中，其实测试人员多样化实践也确实做得不错，诸如合同编制的测试人员、众包形式参与的测试者、内部尝鲜者、beta测试者及早期用户，正因为测试用户群体广泛性带来的观念、目的、使用习惯等因素的多样性，才保证了测试的有效性，而这个有效性不是纯在于对功能需求的100%匹配，而是更在于尽早发现不符合用户期望的东西并剔除掉。

4、组织架构

Google的测试是作为独立的部门而存在的，与各个专注于各领域的业务条线部门平行，测试组织被称为工程生产力团队。在每个项目中，测试人员是以租借的形式进入产品团队，去做提高质量相关的事情。因为测试人员并不是直接向产品团队汇报，因此在发布流程中测试并不是一个被通知的角色。他们有自己的优先级，在安全性、可靠性等问题上不会妥协，除非碰到更重要的事情，但是该事情必须得与测试部门提前沟通。

正因为上述的组织架构，才保证了测试团队的人员数量控制在数量较少规模。同时，测试团队会要求产品团队不能降低要求来招聘更多的测试人员，从而让他们做一些简单重复琐碎的脏活累活，这样则反向要求开发人员对自己的交付有一定的要求，而不是随便写完代码就丢给测试人员去测，这样对开发人员反而是一种测试能力和开发素养上的培养。

5、版本

Google的发布过程虽然快，但是实际上在正式发布前还是经历了一系列的内部版本验证过程以证明它已经具备一定的质量。主要分为以下的顺序：

1、金丝雀版本：

这是每天构建的版本，用于排除一些有明显不适宜的版本。一般来说，只有该产品的工程师和管理人员使用。

2、开发版本：

这是开发人员日常使用的版本，每周发布一个。该版本相比金丝雀版本较为稳定并且要求该产品下面的工程师在日常真实工作中强制使用。

3、测试版本：

该版本应该是最近一个月的最佳版本，也是最稳定最合适的一个版本。同时也作为内部尝鲜版给内部尝鲜者使用，如果该版本有持续的良好表现即可能被作为beta测试的候选版本。

4、beta或发布版本：

该版本由非常稳定的测试版本演变而来，并且经理内部使用和通过所有质量考核，因此也是对外发布的第一个版本。

Google里面的这种爬、走、跑的模式，能够为应用程序尽早提供一个测试验证的机会，与从自动化测试反馈一样，每天都能从用户那里得到有用的反馈。