How Google Test Software 之 软件测试开发工程师

本文是课程《软件测试》的项目之一：Project #1: Reading a book，来自小组：Developer is tester

成员：吴家荣 景 涛 陈兆鹏 郭路文 梁华淇 何金岳

展示PPT：http://slides.com/wujiarong/deck-1#/

Part 1: Summary of content

全书总分为三个部分，五个章节

第一部分：简单介绍了Google软件测试的概念，角色，组织机构，流程以及测试类型。

第一章：Google软件测试介绍

1. 在Google，软件测试团队属于“工程生产力”的中心组织部门，其测试方法很可能是其他公司的模仿榜样。测试与开发有时交织在一起有时又完全分离，这个Google有非常少的专职测试人员质量不仅仅是测试人员的问题，代码的开发者本身就是测试者。停止开发与测试的隔离，质量不等于测试。
2. 角色，Google将开发过程与测试结合起来，并且创建了这些角色，包括：软件开发工程师（SWE），软件测试开发工程师（SET），测试工程师（TE），并且简要的介绍了一下这些角色。
3. 组织机构，在Google，测试是独立存在的部门，以租借的方式加入产品团队。
4. 爬走跑，Google最初的版本只包括最基本的使用功能，然后不断收集用户反馈迭代升级的方式提高产品质量。分为金丝雀版本（最基本的，用来筛掉明显不适宜功能的版本）、开发版本（开发人员日常使用的版本）、测试版本（通过了持续测试的版本，可用作内部尝鲜）和beta或发布版本（对外发布的第一个版本），为我们提供了一个测试验证的良好机会。
5. 测试类型，分为：小型测试（能自动化实现）、中型测试（自动化实现，会涉及到模块间的交互）和大型测试（涉及更多的模块，使用真实用户使用场景和实际用户数据）。

第二部分：分别介绍软件测试中涉及的角色以及他们的主要作用

第二章：软件测试开发工程师（SET）

1. 软件测试开发工程师的相关工作内容，在单元测试方面给予开发人员支持，为开发人员提供测试框架等。详细介绍了SET的工作任务以及测试工作的流程，说明SET首先是工程师的角色，而且是软件工程师，测试是应用产品的另一种功能，SET是这个功能的负责人；项目早期，Google不会让测试过早介入；团队结构，设计文档，SET在推进项目的同时也简化相关项目成员的工作；接口与协议，为了尽早可以运行集成测试，SET提供了mock与fake；自动化计划；可测试性，Google把代码审查作为开发流程的中心，SET成为源码的拥有者之一；并且通过一个实例真正介绍了软件测试的流程；测试大小的定义，包括小型测试，中型测试和大型测试，介绍了不同规模的软件测试在共享测试平台的使用情况以及其优缺点。
2. 讲述了推行测试工作所采用的“测试认证”方法–通过完成测试任务获得“认证”标识，从而激励开发人员参与到测试工作中；与测试认证创始人的访谈。
3. 关于SET招聘的一些描述，面试重点在考察候选人如何思索问题的解决方案，一个优秀的SET会自然的去考虑测试代码。
4. 最后记录了与工具开发工程师Ted Maori和Web Driver的创建者Simon Stewart的访谈，他们方便开发出优秀的测试框架与测试工具。

第三章：测试工程师（TE）

1. 测试工程师（TE）的重点在于评估产品对用户的影响以及软件产品整体目标上的风险。TE的不仅有软件技术的开发能力，更重要的是TE还有以用户为中心检查软件质量而对开发者产生一定制约的能力。
2. 测试工程师是一种面向用户的测试角色，TE首先是以某种最合适的方式发现软件风险最大的地方并且尝试减少或者消除。
3. 测试工程师的工作，研发的早期阶段，TE的工作并没有多少，TE进入产品，SWE和SET已经在测试技术和质量方面做了大量的工作，可以作为TE的起点，TE会介入项目的各个阶段，TE通常是团队里面最出名的人，需要敏锐的洞察力和领导力。一般来说，TE的职责有测试计划和风险分析、评审需求,设计,代码和测试、探索式测试、用户场景、编写/执行测试用例和使用统计/用户反馈，TE更主要的工作是暴露风险.如果不能全测,就测试最重要的,这是一个原则。
   测试计划是最早出现最先被遗忘的测试产物，ACC（Attribute Component Capability，特质，组件，能力）是测试计划的替代方法。风险包括风险分析与风险缓解十分钟测试计划（The 10-Minute Test Plan by James Whittaker）和众包（Crowd-Sourcing）；测试用例以及bug 的生命周期，Google对bug的管理独一无二，bug的数据库完全开放，通过比作小孩介绍了bug的一生；介绍了TE的招聘以及Google测试领导和管理工作；通过Google Desktop的事例介绍了维护模式的测试还介绍了质量机器人实验与BITE实验，还有Google Test Analytic和零成本测试流程以及外部供应商。
4. 收录了与Google Docs测试工程师Lindsay Webster和YouTube测试工程师Apple Chow 谈话记录。

第四章：测试工程经理（TEM）

1. 测试工程经理的工作，TEM负责所有的支持团队之间的联络，把TE和SET联系起来，要拥有技术能力，领导能力以及协调能力，是相关项目中最强的产品专家。TEM要了解自己的产品并且知人善用，优化项目工程。
2. 获得项目和人员，管理着资源配置的流程，获得新的项目。
3. 影响力，测试工程经理要让团队具有影响力，要帮助工程师发挥自身相应的影响力，处理跨团队的沟通；
4. Gmail的测试经验和.Android测试经验还有Chrome的测试经理的访谈都告诉我们了测试工程经理的重要性以及开发测试中的捷径和开发测试的动力所在。还收录了与搜索地理信息测试总监，工程工具总监以及印度Google测试总监和工程经理等人的访谈

第三部分：简要介绍Google的测试缺陷以及改进的方向

第五章：Google软件测试改进

1. Google流程中的致命缺陷，测试成了开发的拐杖，开发与测试的组织结构分离测试人员崇拜测试产物胜过软件本身。最深刻的致命缺陷就是最严格的测试发布之后，用户还是必然会发现测试遗漏的问题。
2. SET这个角色最终会和软件开发工程师变为一个角色；TE这个角色的工作已经有了更为全面且低成本的替代形式；相应的测试总监和经理的数量将会大幅减少。
3. 未来Google的测试基础设施将会使用更加开放、基于云计算的方式进行测试更加经济。
4. 集中测试部门的工程师经理和总监分散到各个更加关注项目的团队和职责岗位之上，更少关注测试流程，更多关注产品本身，熟知和喜爱的测试方式即将终结。

附录

介绍了Chrome OS 的测试计划 和Chrome 的漫游测试以及相关工具和代码的博客文章还有术语表。

Part 2: Educational value of material

对我们来说，本书介绍的三种角色是最让人印象深刻的。
分别是：软件开发工程师（SWE，Software Engineer），软件测试开发工程师（SET，Software Engineer in Test）和测试工程师（TE，Test Engineer）。
在学习测试和阅读《How Google Test Software》以前，对我们来说，软件产业只有一种工程师，那就是开发工程师。
这种想法不免幼稚和无知，但我们确实存在过这样的想法。

从本书的组织来看，本书的主线就是分别介绍几种不同的角色：软件测试开发工程师、测试工程师、测试工程经理。

为了决定我们小组在这一部分要写什么内容。我们先看看这些角色都在负责那些内容的工作。

软件开发工程师（SWE）
《HGTS》：软件开发工程师是一个传统上的开发角色，他们的工作室实现最终用户所使用的功能代码。

软件测试开发工程师（SET）
《HGTS》：软件测试开发工程师，也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。

测试工程师（TE）
《HGTS》：测试工程师是一个和SET关系密切的角色，有自己不同的关注点—把用户放在第一位来思考，代表用户的利益。

测试工程经理（TEM，Test Engineering Manager）
《HGTS》：测试工程师和测试开发工程师分别致力于支持用户和开发工程师。另外还有一种角色可以把这两者联系起来，那就是测试工程经理（TEM）。测试工程经理是作为独立贡献者的一个技术岗位，负责所有的支持团队（开发、产品管理、产品发布、文档等）之间的联络。

介绍完这几种角色，要是粗暴地总结一下本书讲了什么内容，我可以说，就讲了上面的内容。
再次说明，本书的组织架构就是这几种不同的角色是如何在Google的代码生产上发挥作用的。

跨越多种角色的东西或人对我们来说吸引力是最大的，也很容易让人产生某些困惑。
就像本书所介绍的陌生的角色：SET，软件测试开发工程师。

为了让本部分的内容产生深度上的价值，而不是广度地泛泛而谈，我们打算围绕《HGTS》详细介绍一下软件测试开发工程师这个角色。

Google的开发发布模式
在了解Google是如何做测试之前，我觉得先要了解Google是如何做开发的。

《HGTS》介绍，Google有一种“爬、走、跑”的开发发布模式。

也就是说，Google从来不会再一次产品中发布大量的功能，实质上，在一个产品的基本核心功能实现之后，就立刻对外发布使用，然后从用户哪里得到真实反馈，再进行迭代开发。

实质上这个模式能加速迭代开发的流程，而且对于开发的新功能来说，很快能得到用户的反馈，如果受到用户的欢迎，就根据用户的反馈进行改进，如果用户觉得功能多于，就能马上抛弃掉，并且停止进行这个方向或者支路的开发。这实质上能使Google的开发效率得到很大的提高。

Google这样的开发模式，形成了Google风格的各种开发过程的版本。

金丝雀版本：这是每日都要构建的版本，用来排除过滤一些明显不适宜的版本。
开发版本：这是开发人员日常使用的版本，一般是每周发布一个。
测试版本：这是和次序测试的版本。
Beta或发布版本：这个版本是由非常稳定的测试版本演变而来，经历了内部使用和通过所有质量考核的一个版本，也是对外发布的第一个版本。

毫无疑问，软件开发工程师（SWE）在以上的版本构建和开发过程中，扮演的是一个功能开发者的角色。这是一个很重要的角色，因为用户需求的功能，都要由他们来实现。

那么，软件测试开发工程师在其中担任了什么任务呢？为什么他们和软件开发工程师的地位是一样的？为什么招聘SET比招聘SWE更难呢？

软件测试开发工程师（SET）

SET描述

先来引用《HGTS》一句关于SET的描述的话。

“SET首先是工程师的角色，他使得测试存活于先前讨论的所有Google开发过程之中。SET是软禁啊测试开发工程师。最重要的一点，SET是软件工程师，正如我们招聘宣传海报和内部晋升体系中所说的那样，是一个100%的编码角色。“
“测试时应用产品的另一种功能，而SET就是这个功能的负责人。”

既然把测试页归类为应用产品的一种功能特性，那毫无疑问，用一句话概括SET就是，懂开发的测试工程师，SET开发的是测试产品，是与产品本身息息相关的测试相关的功能产品。

项目的早期阶段

Google内部有一种文化氛围：公司鼓励内部员工利用自己的20%的工作时间来做一些富有创造性的工作。
实质上，Google的很多产品，都源于员工的20%的工作，它们很多是由是被证明了有价值，然后由业余产品转变成为公司的业务型产品。

但是，在这个转变的过程中，是否需要保证产品的质量呢？

《HGTS》说，在这个阶段，功能远比质量重要。

“一个产品如果在概念上还没有完全确定成型时就去关心质量，这是优先级混乱的表现。许多来源于Google20%努力的产品原型，在其以后的dogfood或beta版本发布时，还有经历重新设计，原始代码保留的概率几乎为零。很明显，在实验初期阶段强调测试是一件非常愚蠢的事情。”

这个思想很重要，因为在明确这样的产品是否有价值之前，投入大量的精力去关心质量问题，就浪费很多资源。

从主观的角度来看，则是，产品被证明有价值之前，难以吸引SET的关注。

自动化计划

SET需要做的东西很多，让项目进行自动化测试的计划是他们的目标。

有一个原则是，自动化计划必须合情合理且有影响力。

为了实现自动化测试，SET遵循的原则是：

首先，吧容易出错的接口做个里，并针对他们创建mock和fake（mock失职对外面依赖系统的模拟，在运行时刻可以根据假设的需求提供期望的结果；fake对象是一种虚假的实现，内部使用了固定的数据或逻辑，只能返回特定的结果）

其次，构建轻量级的自动化框架，控制mock系统的创建和执行。

可测试性

可测试性的构建是把SWE和SET紧密联系起来的任务。

可以这样简单地理解SWE和SET对项目的可测试性的贡献。SET的目标是，对于项目产品每一次修改，对代码的每一次提交，对于SWE的每一次努力和尝试，都能快速对更改进行检查，构建，验证更改是否存在问题，代码是否存在bug。然后以一种最高效的方式，把相应的反馈信息发送给代码的变更者。

测试大小的定义

为了测试方便，Google自己定义了一套测试命名规则。
小型测试：验证代码单元的功能，通常是单元测试。
中型测试：验证两个或者多个模块应用之间的交互。
大型测试：验证系统作为一个整体是如何工作的。

测试大小定义的应用

测试工程师的招聘

一言以蔽之：既要动开发，也要懂测试。

阅读最大的收获

做每一件事情，都应该是有一定的目的，否则便是毫无方向感。每一次经历，都应该能察觉经历给自己带来了什么。

对此书的阅读，我们觉得，给我们带来的有两点非常深刻的体会和收获。

其一，提交队列与持续集成

最近参与了一个项目。扮演的是一个web架构师和技术负责人的角色。

我们使用gitlab作为远程仓库，使用git进行版本管理，使用git的分支来实现协同开发。

项目刚开始不久，web服务部分我们还没有比较强烈的测试意识，都是功能导向性的开发，以完成一个具体的功能为开发阶段性标准。

我们控制代码质量和每次提交的功能完整性的方式就是，直接人工检查。

应该说，这样的开发流程是比较原始的。没有实现自动化构建和自动化测试。没有充分利用gitlab的自动化构建和持续集成的功能。

可能这次阅读带来的影响就是，让我们团队有一种倾向和意识，去实现这样的一种构建和集成。

其二，web自动化测试

作为一名web前端开发工程师，之前没有尝试过在前端方面的测试。按照之前的开发经历，觉得web前端好像没法进行自动化测试。因为基本上都是UI操作，很难确定输入和输出。只能进行人机交互，人工确定逻辑的正确性和流程的正确性。

直到阅读了本书的一个关于webdriver项目创始人的一个访谈。才知道原来web前端的自动化测试并不是不可能的，而是已经有了具体的尝试和实现了！

这个认知对于我来说确实是一个巨大的惊喜。

我将会尝试去学习webdriver并且努力把web自动化测试应用到具体的项目当中。

Part 3: Recommendation

《Google软件测试之道》是极有价值的一本书，因此我认为值得向大家推荐这本书。很久以来，软件测试的理论和实践的发展一直处于资源和人力相对不足，工作内容的边界也很模糊的状态。其他关于软件测试的书籍往往存在的的问题是，站的位置不是太高就是太低。以学术口吻写就、工程人员一看就感觉与己无关者有之；以自己的实际工作经验为基础，但是并未形成有效的理论者有之；泛泛而谈的理论家凭借相当的想象写就，但是既没有实例也没有工具者有之——一言以蔽之，光说了一堆测试这件事应该怎么做，但是并没有看到测得什么优秀的产品，也没有在这个过程中发展出工具、理论和文化来。

而《Google软件测试之道》的不同之处首先在于，IT巨头已经生产出来的软件产品，其成功是妇孺皆知的。那么，以这些产品的生产过程作为软件开发生命周期中的模范，应该是不仅比较正确，而且也是更有沟通基础的，因而也是更有价值的。软件测试作为软件开发生命周期中接触点最多的一环，通过这本书，可以看到这些IT巨头们是怎么做的——它们怎样设计配套的公司组织结构、怎样处理软件测试和其他生命周期环节的关系、基于怎样的思想来实施工程实务、开发了怎样的支撑环境和工程工具……这一系列的问题，看看微软和Google给出的答案，读者就可以知道，在目前的软件和硬件条件下，理想的，或者说是最高水平的软件测试已经达到了一种怎样的程度，从而在规划自己软件测试相关的团队配置和工程技术实务时，有了非常重要的参考。

读完《Google软件测试之道》又让我看到了一些新的东西，这主要是软件交付模式从盒装变为在线带来的，因而时间特性从离散变为持续、空间特性从单一变为多元，软件测试为了适应这些变化，必须一方面在概念上变得更灵活，另一方面却要在执行上却要变得更简单有效。这两个相互矛盾的要求，对软件测试的管理和执行人员都提出了极大的挑战。毫不意外地，我看到这本书在基础层面上与传统的盒装软件测试有着同样的测试目标：高可用性、高性能、优化的用户体验，但是在概念和技术上却发生了巨变，我诚挚地请读者们重点关注一下这本书对于测试规模的论述，以及性能测试工具的设计思想，信息量很大。另外，认真研习一下附录的两份测试计划，也会有不小的收获。

最后，真诚地向大家推荐《Google软件测试之道》，这绝对会使你受益匪浅。