目 录

    封面

    《Google软件测试之道》业界热

    评

    每日电子书

    致谢

    关于这本书

    译者序

    致中国读者

    内容提要

    版权

    扉页

    对本书的赞誉序

    序

    前言

    第1章 Google软件测试介绍

    1.1 质量不等于测试

    1.2 角色

    1.2.1 软件开发工程师

    (SWE)

    1.2.2 软件测试开发工

    程师(SET)

    1.2.3 测试工程师

    (TE)

    每日电子书

    1.3 组织结构

    2.1.9 SET的工作流程：

    每日电子书

    2.1.8 可测试性

    2.1.7 自动化计划

    2.1.6 接口与协议

    2.1.5 设计文档

    2.1.4 团队结构

    2.1.3 项目的早期阶段

    2.1.2 SET究竟是谁

    2.1.1 开发和测试流程

    2.1 SET的工作

    第2章 软件测试开发工程师

    1.5 测试类型

    1.4 爬、走、跑一个实例

    2.1.12 测试规模在共享

    测试平台中的使用

    2.4 与工具开发工程师Ted

    Mao的访谈

    2.5 与Web Driver的创建者

    Simon Stewart的对话

    每日电子书

    2.3 SET的招聘

    2.2 测试认证

    2.1.14 测试运行要求

    2.1.13 测试规模的益处

    2.1.11 测试大小的定义

    2.1.10 测试执行

    3.1 一种面向用户的测试角

    3.2.3 测试用例的生命

    周期

    3.2.6 Google的测试领导

    和管理工作

    3.2.7 维护模式的测试

    每日电子书

    3.2.5 TE的招聘

    3.2.4 bug的生命周期

    3.2.2 风险

    3.2.1 测试计划

    3.2 测试工程师的工作

    色

    第3章 测试工程师(Maintenance Mode

    Testing)

    3.2.8 质量机器人

    (Quality Bot)实验

    3.2.9 BITE实验

    3.2.10 Google Test

    Analytics

    3.2.11 零成本测试流程

    3.2.12 外部供应商

    3.3 与Google Docs测试工程

    师林赛·韦伯斯特(Lindsay

    Webster)的访谈

    3.4 与YouTube测试工程师安

    每日电子书普·周(Apple Chow)的访

    谈

    4.4 Gmail测试工程经理Ankit

    Mehta的访谈

    4.5 Android测试工程经理

    Hung Dang的访谈

    4.6 Chrome测试工程经理

    Joel Hynoski的访谈

    每日电子书

    4.7 测试总监

    4.3 影响力

    4.2 获得项目和人员

    4.1 测试工程经理的工作

    第4章 测试工程经理4.8 搜索和地理信息测试总

    监Shelton Mar的访谈

    4.9 工程工具总监Ashish

    Kumar的访谈

    4.10 印度Google测试总监

    SujaySahni访谈

    4.11 工程经理Brad Green访

    谈

    5.1 Google流程中的致命缺

    每日电子书

    5.2 SET的未来

    陷

    第5章 Google软件测试改进

    4.12 James Whittaker访谈

    A.3 每次构建版本的基线测

    试

    A.4 最新可测试版本(Last

    Known Good，LKG)的每

    每日电子书

    A.5 发布版本测试

    日测试

    A.2 风险分析

    A.1 测试主题概述

    附录A Chrome OS测试计划

    5.6 结论

    5.5 未来的测试基础设施

    5.4 测试总监和经理的未来

    5.3 TE的未来A.6 手工测试与自动化测试

    A.7 开发和测试的质量关注

    点

    A.8 发布通道

    A.9 用户输入

    A.10 测试用例库

    A.11 测试仪表盘

    A.12 虚拟化

    A.13 性能

    A.14 压力、长时运行和稳

    定性测试

    A.15 测试执行框架

    每日电子书

    (Autotest)

    A.18 端到端测试自动化集

    群

    A.19 测试浏览器的应用管

    理器

    每日电子书

    B.1 购物漫游

    附录B Chrome的漫游测试

    A.24 相关文档

    A.23 主要的测试驱动力

    A.22 时间线

    A.21 硬件

    A.20 浏览器的可测试性

    A.17 硬件实验田

    A.16 OEM厂商

    附录C 有关工具和代码的博客文

    C.1 使用BITE从bug和冗余

    的工作中解脱出来

    C.3 RPF：Google的录制回

    每日电子书

    C.2 发布QualityBot

    章

    B.8 个性化漫游

    B.7 危险地带漫游

    B.6 公务漫游测试

    B.5 通宵漫游

    B.4 地标漫游

    B.3 国际长途电话漫游

    B.2 学生漫游放框架

    C.4 Google测试分析系统

    (Google Test Analytics)

    ——现在开源了

    附录D 术语表

    每日电子书

    每日电子书

    “Google 一贯是测试领域的创新

    Visual Studio产品及战略负责人

    —— Sam Guckenheimer ，微软

    保持竞争力的必读书籍。”

    试人员来说，这本书都是紧跟时代、论对Google员工，还是对其他任何测

    这个云计算变革浪潮汹涌的时代，不

    能准确把握测试领域的发展脉搏，在

    “James Whittaker长期以来一直都

    对本书的赞誉

    每日电子书

    “这本书改变了游戏规则，从版

    及联合创始人

    —— Doron Reuveni ，uTest CEO

    试领域取得成功的。”

    了Google是如何在快速发展的软件测

    本书中，James Whittaker系统地描绘

    新问题，更好地发布了产品应用。这

    对创新的渴望帮助Google解决了很多

    试补充实验室场景测试等方面。这种

    合，还是近来开创性地用真实场景测

    试的结合、本地团队与外包资源的融

    者——无论是对手工测试与自动化测

    每日电子书

    和技术上的创新。对每个做软件开发

    趣味的语言风格描述了Google在流程

    软件企业的标准。本书以平实而饶有

    应用到软件测试领域，这将成为未来

    James Whittaker把计算机科学的方法

    指软件系统参数的集中显示面板)。

    信息，方便随时察看飞行参数。这里

    时看到叠加在外景上的字符、图像等

    电显示装置观察舱外景物时，可以同

    行员透过座舱正前方组合玻璃上的光

    平视显示器是一种飞行辅助仪器。飞

    本的每日发布到平视显示器(译注：

    每日电子书

    试建立一套保证产品质量和用户满意

    “如果你要在云端发布代码并尝

    程总监

    —— Alberto Savoia ，Google工

    经。”

    打造成了现代软件测试领域的圣

    中的大量奇思妙想，作者已经把本书

    “通过记录 Google 测试工程实践

    AdSenseDisplay部门高级工程经理

    —— Michael Bachman， Google 书。”

    的人来说，这都是一本不可多得的好

    TCL 每日电子书

    —— Stewart Noakes ，英国

    读。”

    的作品绝对值得每位IT行业的人阅

    他的魄力和激情。作为业界巨擘，他

    今天这样的人才和技术。我一直敬畏

    的贡献，我们在测试领域不可能拥有

    多人的导师和灵感源泉。如果没有他

    “James Whittaker在测试领域是很

    Salesforce.com

    —— Phil Waligora ，书中的方法。”

    度的策略，你必须仔细研究和思考本

    每日电子书

    《微软的软件测试之道》的作者

    —— Alan Page ，微软XBox， 的人，都能从这本书中有所收获。”

    的人，或有意发现一些崭新测试思路

    何对Google测试和质量技术稍感好奇

    及对Google测试体系的深刻洞察。任

    含了各种创新的测试理念、实践案例

    Google会从事伟大的工作。这本书包

    他一起在微软的日子，但我知道他在

    的时候我曾与他共事。虽然我怀念与

    “当 James Whittaker 在微软工作

    集团总裁PEARSON

    软件测试之道

    像Google一样进行软件测试

    【美】James Whittaker Jason

    Arbon Jeff Carollo 著

    黄利 李中杰 薛明 译

    每日电子书

    人民邮电出版社北京

    每日电子书

    每日电子书

    (2013)第209033号

    中国版本图书馆CIP数据核字 件一测试 Ⅳ.①TP311.5

    卡…④黄…⑤李…⑥薛… Ⅲ.①软

    Ⅰ.①G… Ⅱ.①惠…②阿…③

    ISBN 978-7-115-33024-6

    京：人民邮电出版社，2013.10

    著；黄利，李中杰，薛明译，--北

    (Arbon,J)，(美)卡罗洛(Carollo,J)

    特克(Whittaker,J.)，(美)阿尔邦

    Google软件测试之道(美)惠

    图书在版编目(CIP)数据

    每日电子书

    or mechanical,including

    in any form or by any means,electronic book may be reproduced or transmitted All rights reserved.No part of this Education,Inc.

    Education,Inc.,copyright?2012.Pearson Carollo,published by Pearson by James Whittaker,Jason Arbon,Jeff Google Tests Software,9780321803023 English language edition,entitled:How Authorized translation from the 版权声明

    每日电子书

    可，不得以任何方式复制或抄袭本

    版社独家出版。未经出版者书面许

    Education Asia Ltd.授权人民邮电出

    本书中文简体字版由Pearson TELECOM PRESS Copyright?2013.

    EDUCATION ASIA LTD.and POSTS ＆ edition published by PEARSON CHINESE SIMPLIFIED language Education,Inc.

    system,without permission from Pearson information storage retrieval photocopying,recording or by any

    每日电子书

    北京市崇文区夕照寺街14号

    ◆人民邮电出版社出版发行

    责任印制 程彦红 焦志炜

    责任编辑 张涛

    译 黄利 李中杰 薛明

    Jason Arbon Jeff Carollo

    ◆著 [美]James Whittaker 版权所有，侵权必究。

    光防伪标签，无标签者不得销售。

    Education(培生教育出版集团)激

    本书封面贴有Pearson 书内容。邮编 100061 电子邮件

    315@ptpress.com.cn

    网址 http:www.ptpress.com.cn

    北京鑫正大印刷有限公司印刷

    ◆开本：800×1000 116

    印张：18

    字数：335千字 2013年10月

    第1版

    印数：1-4000册 2013年10月

    北京第1次印刷

    每日电子书

    8860号

    著作权合同登记号 图字：01-2012-定价：59.00元

    读者服务热线：(010)67132692 印

    装质量热线：(010)67129223

    反盗版热线：(010)67171154

    每日电子书 每日电子书

    纪软件测试的独特挑战的。本书抓住

    上知名的互联网公司是如何应对21世

    本书从内部视角告诉你这个世界

    的任务，谷歌是如何测试的呢？

    例上执行。面对这些看似不可能完成

    动化测试，并在好几十万个浏览器实

    亿计的构建动作会触发几百万次的自

    百万个源文件、亿万行的代码。数以

    每天，Google都要测试和发布数

    内容提要 每日电子书

    或团队的人受益很大。最后，本书还

    那些试图建立类似Google的测试流程

    挥了重要作用的工程师的访谈，这对

    Google的测试历史或在主要产品上发

    周期中的职责；讲述了测试管理及在

    技能；阐述了测试工程师在产品生命

    讲解了技术测试人员应该具有的技术

    的，介绍了软件测试工程师的角色；

    了测试架构是如何设计、实现和运行

    华。本书描述了测试解决方案，揭示

    Google测试这个时代最复杂软件的精

    了Google做测试的本质，抓住了介绍了作者对于Google测试如何继续

    演进的见解、Google乃至整个业界的

    测试方向的一些预言，相信很多读者

    都会感受到其中的洞察力，甚至感到

    震惊。本书可以作为任何从事软件测

    试人员到达目标的指南。

    本书适合开发人员、测试人员、测试管理人员使用，也适合大中专院

    校相关专业师生的学习用书，以及培

    训学校的教材。

    每日电子书

    每日电子书

    and many adoring users!

    this country.May our code have few bugs millions of software professionals in some of my work is available to the software industry，and I am pleased that possible.China is a major player in the in China to make this translation demand for this book was strong enough It brings me great pleasure that the 致中国读者James Whittaker

    “看到这本书在中国的需求如此

    旺盛，以及它的中译版最终付梓，真

    让我喜出望外，难以言表。在整个软

    件产业版图中，中国占据着非常重要

    的位置，如果说我的一些工作能给中

    国的软件同仁带来些许帮助，幸甚至

    哉。祝愿你们的代码少一些bug，多

    一些挚爱的用户。”

    James Whittaker

    每日电子书 每日电子书

    地介绍Google内部产品的研发流程与

    之一。但迄今为止，没有一本书系统

    践更是技术分享大会中最热门的话题

    寐以求的技术殿堂，其内部的工程实

    程师文化氛围也成为了许多工程师梦

    术一直被外界所觊觎，其所宣扬的工

    属。很长一段时间以来，Google的技

    于浪潮之巅的伟大公司非Google莫

    毫无疑问，在当前这个时代，处

    译者序

    每日电子书

    端的情况下甚至会适得其反。我自己

    环境下，效率会大大下降，在一些极

    籍里提及的最佳测试实践，在当前的

    式。许多曾经红极一时的传统测试书

    网的出现改变了许多软件研发的模

    正如本书中所提及的那样，互联

    翻译这本书的第一个原因。

    解Google技术神秘之处。这也是我们

    现，才使得我们有机会管中窥豹，了

    《How Google Tests Software》的出

    成员如何分工协作等细节，直到

    模式，包括开发、测试、发布、团队

    每日电子书

    James Whittaker在正式撰写本书

    翻译这本书的第二个原因。

    到了更多感兴趣的知识。这也是我们

    试挑战的。通过翻译这本书，自己学

    司——Google，是如何应对互联网测

    上最成功、增长速度最快的互联网公

    发和借鉴，特别是想看一下这个世界

    主流互联网公司的测试模式中得到启

    间寻找平衡，所以，也特别想从一些

    常焦虑如何在制约质量和快速发布之

    面的测试工作，对此深有体会，也经

    就是一名测试工程师，从事互联网方

    每日电子书

    菜，它完全勾起了大家的食欲，仅仅

    认，这几篇文章就像正餐前的开胃小

    解的越多，疑惑也就越多。不得不承

    试实践也有了越来越多的了解，但了

    逐渐揭开了其神秘面纱，让我对其测

    这个系列文章的逐一公开，Google也

    团队居然是这样组织的!之后，随着

    第一感觉就是，太棒了!Google测试

    到第一篇时我就被深深地吸引住了，Google Test Software”系列文章。当看

    Testing Blog上尝试发表了“How 英文版之前，于2011年1月在Google

    每日电子书

    话，问我为什么不去翻译一下这本书

    到李中杰(本书的合译者之一)的电

    本书的英文版终于问世之后，突然接

    书快出版了。大约在2012年9月，这

    合不拢了，却卖起了关子来，只是说

    人在打探这本书的下落，乐呵得嘴都

    Software》这本书，James一听到又有

    本人，便聊起了《How Google Test Conference)大会上，我见到了James

    月的GTAC(Google Test Automation Google测试体系的需求。在2011年11

    依赖这几篇文章完全不能满足窥探 每日电子书

    生花，翻译他的书籍，让我诚惶诚

    颇具文学功底，语言诙谐幽默，妙笔

    不仅是测试领域的泰山北斗，而且他

    来完成这件事情。众所周知，James

    原因。我原本根本没有这么大的勇气

    最后要说的，也是最重要的一个

    吧。

    情，这也是翻译这本书的第三个原因

    辗，还是机缘巧合地去做了这件事

    比，还是有些微不足道的。但几经转

    篇文章的翻译，但与翻译一本书相

    呢。之前虽然是兴趣使然，做过那几 每日电子书

    开发测试模式。由于译者水平有限，书中有所借鉴，找到适合自己现状的

    最后祝愿国内的读者能够从这本

    日，能够也有机会讲讲自己的故事。

    在讲别人的故事，还是期待有朝一

    别人的书，像是在反刍，再精彩也是

    简单，更有许多惊喜深藏内心。翻译

    表，所收获的也不仅仅是长知识那么

    与他们两位的合作，幸福之感难以言

    乐观与自信让本书的翻译得以完成。

    合译者，李中杰博士和薛明，他们的

    恐，以至于焦虑得昼夜不安。但两位错漏之处在所难免，若有欠妥之处，欢迎指正。

    每日电子书《Google软件测试

    之道》业界热评

    每日电子书

    术、产品发布流程，以及测试团队的

    了Google的测试理念、自动化测试技

    变得没有那么神秘，本书系统地介绍

    之道》将Google的测试、产品的发布

    的秘密又是什么？《Google软件测试

    不同？Google的快速开发、快速发布

    “Google的测试理念有什么与众

    每日电子书

    种测试实践，自然又现实。感谢译者

    来困难重重，而在Google都已化作种

    言，是那么的理想化，以至于实施起

    人员技能等，对于很多测试团队而

    试、注重早期测试和评审、注重测试

    直倡导的诸多测试理念，如尽早测

    没错，我说的是‘完美’!测试领域一

    副完美的测试画卷展现在我的面前。

    “读完本书，Google 测试就像一

    —— 张南，Google中国测试经理

    心做技术分享的好书!”

    组成和测试工程师的招聘，是一本真

    每日电子书

    人期间，我也多次向外界介绍Google

    奋。在担任Google中国区的测试负责

    自动化测试实践，无一不让我觉得兴

    实践、内建质量的意识，以及优秀的

    深吸引。Google内将测试推到上游的

    时，就被这家企业具有的测试文化深

    “我2007年刚加入Google中国

    行主席

    训与咨询顾问、首届ChinaTest大会执

    —— 邰晓梅，独立软件测试培

    从中借鉴Google测试的优秀实践。”

    的工作，让更多中国的测试人员可以

    每日电子书

    力的好书值得每一位软件测试人员和

    “这本介绍 Google 软件工程生产

    曾任Google中国测试经理

    —— 段念，豆瓣工程副总裁，匪浅。”

    文，相信每位读者都能从本书中受益

    电出版社组织将这本好书翻译成中

    常‘接地气’的书。很高兴看到人民邮

    系与测试实践，是一本即系统又非

    这本书详尽地介绍了Google的测试体

    能够更好地帮助到更多人。James的

    的测试实践，希望Google的实践经验 每日电子书

    同的新观点，兼听则明会让你的工作

    但你依然可以找到十个理由去接受不

    找到十个拒绝了解不同观点的理由，是一切成功的源头，也许你能很容易

    家都能飞得更快、更高。正确的认知

    件工程人员提供了‘新的翅膀’，让大

    的借鉴意义，而且也为其他行业的软

    行业的软件测试从业人员有着非常好

    展和测试技术创新实践不仅对互联网

    中所描述的观点、测试人员的价值拓

    是软件行业十年难得一遇的好书，书

    研发管理者拥有，我个人甚至认为这

    每日电子书

    念，理解了Google的工程师文化，从

    本书让我们理解了Google的测试理

    IT企业Google是如何做测试的。通过

    休地争论，不如让我们看看世界级的

    我没有结论，但是我觉得与其喋喋不

    最近一年这样的话题被持续地讨论，变化吗？未来还需要测试工程师吗？

    “软件测试方法会产生颠覆性的

    有限公司测试架构师

    —— 董杰，百度在线网络技术

    实。”

    更高效，自己做得更开心，过得更充

    每日电子书

    究)

    捷测试、自动化测试方面有深入研

    —— 吴穹，敏捷咨询师(在敏

    观落地给出了非常具体的建议。”

    量观，同时还对如何将这种理性质量

    是，它传递了一种非常重要的理性质

    经验，而非理论空谈。更为重要的

    一。这本书的内容全部来自一线实际

    测试思想和技术的第一读物，没有之

    “这本书是我推荐读者了解敏捷

    —— 贺炘，领测国际创始人

    中你能发现更适合你的测试方法!”

    每日电子书

    的经典之作，让国内的测试团队能够

    “感谢译者翻译了这本测试业内

    —— 吴永强，去哪儿网CTO

    围的人们很多启发。”

    书可以给那些关注如何在此困境中突

    问题和实施中的难题没办法解决。本

    队的事情，但是，依然有太多的质量

    质量是所有人的事情而不只是测试团

    理都需要参加测试，以此来提醒——

    去哪儿网内部，开发工程师、产品经

    中保持高质量是一个永恒的难题，在

    “对于互联网公司，在快速前进

    每日电子书

    业务结合，促进集团内产品和业务的

    产力，我们还要将测试技术与产品和

    续集成，做好测试工具，做好研发生

    大，我们不仅要做好自动化，做好持

    同时，我们面临的挑战比Google更

    发团队不接受，测试团队也不买账。

    测试的开发人员更难；团队的变革开

    具备开发能力的测试人员难，找到懂

    测试变革的心路历程深有共鸣：招聘

    容，对Patrick Copeland在序中描述的

    节奏。我有幸先阅读了本书的部分内

    快速理解国际测试的发展并跟上国际

    每日电子书

    为测试行业的热点话题。Google无疑

    式，敏捷、持续构建和开发自测等成

    底颠覆了传统的软件开发和测试模

    “互联网快速响应变化的需求彻

    试总监

    —— 夏林娜，阿里巴巴集团测

    油!”

    值。做好工程，更要做好业务!加

    解业务所服务的客户需求及客户价

    思维，还要具备业务思维，能深刻理

    比，我们不仅要具备开发能力、测试

    发展。因此，与Google的测试人员相

    每日电子书

    的视角解读测试，这让他的观点全面

    了最正统测试理念的人，又从互联网

    者James Whittaker是一个在微软接受

    改变他们的观点。第一，本书第一作

    也可以有很好的测试吗？此书可能会

    “或许有人会质疑，互联网公司

    试总监

    —— 刘立川，阿里巴巴集团测

    形式非常值得国内的同行借鉴。”

    拥趸。Google的全新测试理念和组织

    联网领域产生广泛的影响并拥有大批

    走在测试变革的最前沿，并已经在互

    每日电子书

    外两位作者在Google工作的全面、详

    者、探索者和思考者。本书是他和另

    Whittaker 是软件测试界强有力的执行

    有很多交流，并曾经共事。James “我和本书的三位作者在西雅图

    说相声的

    —— 柴阿峰，测试圈儿里那个

    这本书是。”

    Google的测试不一定是最出色的，但

    数家珍。所以，我强烈推荐本书，翻译非常出色，读起来像测试行家如

    而具有说服力；第二，这本书的中文

    每日电子书

    Engineer in Test,Amazon

    —— Bill Liu，Software Design 思考。”

    件测试的职责、手段和未来发展有所

    同时开阔了我们的视野，让我们对软

    产品质量等方面提供了很好的参考。

    是互联网企业在如何测试、如何保证

    Google软件测试之道，给企业，特别

    理三个不同角色出发，详细阐述了

    工程师、软件测试工程师以及测试经

    细总结和提炼。他们从软件测试开发

    每日电子书

    一些书籍多数是给初学新手看的，此)。但更重要的是，我之前出版的

    书的撰写之中(后来也证实的确如

    疑过)。有着太多的人想参与到这本

    的最佳候选 Googler(他们也的确怀

    思考。人们会质疑我是否是写这本书

    理由后来也被逐一证实它们确实值得

    这本书的时候，我有些犹豫，犹豫的

    在Patrick Copeland最初建议我写

    关于这本书

    每日电子书

    更大。我憧憬着经验丰富的测试人

    的流程之间的区别，这样他们的收获

    并会比较Google的流程与他们所使用

    是一些初学者，他们会有一些基础，已经在公司从事测试工作的人，而不

    的参考书。我希望本书的读者是一些

    是如何完成大小规模不一的测试任务

    合作为一本参考书，一本介绍Google

    可能坐着一口气读完，但其实它更适

    整的故事。这本书并不是这样。读者

    Testing》，都是在从头到尾讲一个完

    像“How to Break”系列和《Exploratory 每日电子书

    工具和想法，都深受他的影响。我们

    书“测试工程师”这一章中出现的许多

    但他内心深处有着创业情怀，在本

    Arbon的职位是TE(测试工程师)，在Google的工作年限都比我长。Jason 力。这两位都是优秀的工程师，他们

    程师，为了这本书，加入进来共同努

    在此之前从没有写过书的两位工

    可真不是我惯用的写作风格。

    下在某些方面Google是如何做的。这

    这本书，找一些感兴趣的话题，看一

    员、测试经理、管理者能够随手拿起

    每日电子书

    有许多 Googler 提供了资料。当

    能地达成一致。

    横溢的人共同写作，并在风格上尽可

    行不需要任何干预。我与这两位才华

    的测试代码写得非常棒，可以独立运

    就不用再参与”的代码的人之一，他

    我认识的那种可以写出“自动化之后

    件测试开发工程师)，也是少数几个

    是我见过的最优秀的那一类SET(软

    员，但后来转做开发了。Jeff Carollo

    益良多。Jeff Carollo也是一名测试人

    有幸一起共事，并彼此从对方身上受 每日电子书

    或者专门找到这部分来阅读。我们同

    起止位置，以便选择跳过这一部分，在书中可以很清晰地找到这些访谈的

    所有的读者对这些访谈都感兴趣，但

    一本由30个人合著而成的书。不一定

    测试的人参与进来的方法，而不是搞

    的、让尽可能多的曾经定义了Google

    一些采访。这是我们能想到的最好

    深刻影响的人，我们针对这些人做了

    一下。还有许多对Google测试发挥了

    作时，我们会在标题中把这个人标记

    资料中的文字和标题是同一个人的工

    每日电子书

    给我启发的测试人员。

    献给Google、Microsoft和全世界

    Jeff Carollo

    Jason Arbon

    James Whittaker

    能发现(并修复)bug。

    快乐阅读，快乐测试，祝愿你总

    煌。

    描述出这些工作是多么地卓越和辉

    语实在是一门贫乏的语言，无法用它

    不到之处，也愿意接受任何批评。英

    样感谢为数众多的贡献者，但如果有——James Whittaker

    献给我的妻子Heather和我的孩子

    们Luca、Mateo、Dante和Odessa，他

    们一直认为这段时间我在星巴克工

    作。

    ——Jason Arbon

    献给我的妈妈、爸爸、Lauren和

    Alex。

    ——Jeff Carollo

    每日电子书 每日电子书

    力并勇于承担风险将测试推向云端的

    在这里要特别向那些投入巨大精

    维的存在。

    允许不断创新以及天马行空般自由思

    面与Google打造其他产品如出一辙，管理文化，在对待测试方法与实践方

    样，也非常感谢Google开放的工程和

    力于质量改进的Google工程师们。同

    我们想感谢那些不知疲倦地、致

    致谢人们致敬，他们是Alexis O.Torres,Joe

    Muharksy,Danielle Drew,Richard

    Bustamante,Po Hu,Jim Reardon,Tejas

    Shah,Julie Ralph,Eriel Thomas,Joe

    Mikhail,Ibrahim El Far。还要感谢我们

    的编辑，Chris Guzikowski和Chris

    Zahn，他们一直非常有礼貌地在容忍

    我们这些工程师的唠叨。感谢那些受

    访者在书中分享他们的观点与经验，他们是Ankit Mehta,Joel

    Hynoski,Lindsay Webster,Apple

    Chow,Mark Striebeck,Neal

    每日电子书

    每日电子书

    Copeland，是他将来自五湖四海且充

    诚的反馈。最后，要特别感谢Pat Bachman，他们为本书提供了率直坦

    Waligora,Alan Page,Michael 们提供了美味的餐饮。感谢Phil 化。感谢Google餐厅的工作人员，他

    灵感成就了今日Google快速发布的文

    Savoia，他在原型及快速迭代方面的

    Dang。特别要感谢一下Alberto

    Sahni,Brad Green,Simon Stewart,Hung Mao,Shelton Mar,Ashish Kumar,Sujay Norwitz,Tracy Bialik,Russ Rufer,Ted 满激情的各路精英汇集于此，并投身

    于质量方面的不断改进工作。

    每日电子书

    每日电子书

    之前，先请我吃了一顿我非常喜欢的

    伙，在他问我是否愿意为这本书写序

    James Whittaker却是一个聪明的家

    但新娘却是你曾经心爱的姑娘。但是

    觉有点像你被邀请去为好友做伴郎，去做序，是一种尴尬的荣誉，这种感

    为一本你曾经想自己去撰写的书

    谷歌工程总监

    Alberto Savoia

    序

    每日电子书

    让我继续写这篇序吧，为这本我

    家伙。

    正如我说过的，他是一个聪明的

    辞。

    我却不得不在这里为他们的婚礼做致

    娘”——这本书，一起站在一边，而

    的诡计“得逞”了，他和他的“新

    作欢颜并答应了他：“没有问题。”他

    请求，在当时那种气氛下，我只能强

    酱带来的愉悦时，他终于提出了这个

    Dos Equis啤酒。当我还沉浸在牛油果

    墨西哥晚餐，并让我喝了几杯墨西哥 每日电子书

    还少吗？是的，这样的书已经足够多

    学和宣扬一些可疑、过时的建议的书

    那种讲述陈旧得令人厌烦的测试方法

    还需要他的这么一本软件测试书吗？

    什么意思？Google一下你就知道)，不知道“八胞胎妈妈(Octomom)”是

    出版界高产的“八胞胎妈妈”(译注：

    曾经不止一次公开地称其为测试书籍

    Whittaker，这个高产的家伙，一个我

    关于软件测试的书吗？特别是James 这个世界上真的还需要另外一本

    曾想自己写的书。 每日电子书

    软件测试方面的书籍都已陈腐过时，迅速，以至于许多最近几年才出版的

    互联网和软件产业，一切变化都如此

    些情况下会事与愿违地起反作用。在

    大大下降，或者毫无效果，甚而在某

    佳测试实践，在当前的环境下效率会

    曾经红极一时的测试书籍里提及的最

    软件设计、开发和发布的方式。很多

    互联网的出现急剧地改变了许多

    很需要这样一本独特的测试书。

    是我想自己去写它的原因，这个世界

    了，但我认为这本书绝非如此。这也 每日电子书

    成功、增长速度最快的互联网公司之

    用地从内部视角告诉你这个世界上最

    潮来临之前，这本书可以既适时又适

    了，那一点儿也不奇怪。但在下次浪

    之快，如果说十年后这本书也过气

    考虑到软件产业的发展速度如此

    防止流落到容易上当受骗的人之手。

    如，循环再利用，做出纸尿裤来，以

    们扔掉，或者做些有益的事情，例

    付这种书，最好的办法就是直接把它

    开颅驱赶恶鬼的外科手术书一样。对

    打个比方，它们就像讲述水蛭吸血和

    每日电子书

    自己代码的测试了，但由于测试驱动

    员!那个时候，开发人员已经开始做

    名开发人员，但只有区区3位测试人

    入Google。当时，Google大概有200

    我于2001年以工程总监的身份加

    经历了这个伟大的转变。

    之所以了解这些，是因为我从头到尾

    个时代最复杂和流行软件的精华。我

    本质，抓住了Google如何测试我们这

    伙伴们，抓住了Google如何做测试的

    独特挑战的。James Whittaker和他的

    一，是如何应对 21 世纪软件测试的

    每日电子书

    户来说开始变得至关重要(例如，竞

    Google的一些产品对于最终用户和客

    然而，当Google逐渐成长变大，经非常强大的对手竞争。

    勇于冒险，否则就无法和那个时代已

    时正处在创业阶段，必须快速前进并

    即使那样也是可以接受的，因为，当

    决于编写代码的开发者的责任心。但

    机测试(ad-hoc testing)，其好坏取

    使用。当时的测试主要是在做一些随

    JUnit 这样的测试框架也没有大规模

    开发的模式才刚刚开始，而且像 每日电子书

    试做成自动化的。但是进展缓慢，并

    并建议使用一些工具，如JUnit，把测

    员把测试作为优先级较高的事去做，训、推行单元测试，我们鼓励开发人

    Google工程师)一起，我们介绍、培

    注：Google员工，本书中一般指

    的测试。与其他的几个Googler(译

    师，别无选择，只能让开发来做更多

    关注和投入。但只有3个测试工程

    我们清晰地认识到必须加大对测试的

    快变成许多网站的主要收入来源)，价广告产品，我曾经负责的产品，很

    每日电子书

    单就可以让开发做测试了？

    到测试上了。会如此幸运吗？如此简

    但这样至少还是把大家的注意力吸引

    狗完成某个动作后给一些奖励一样，觉不是很好，有点像杂技训兽师在小

    人员颁发奖品来激励大家。但这种感

    员聚会)，我们为一些做测试的开发

    Friday，Google在每周五下午举行全

    时(译注：TGIF，Thank God It’s

    势头，在每周五下午公司的啤酒狂欢

    做测试这件事情。为了继续保持这个

    非所有的人都接受、认同开发人员去 每日电子书

    求在很短的时间内完成测试，要

    大(且需要很多知识的学习)，并要

    的时候，会发现测试工作量变得非常

    方面的测试。当真正开始要去做测试

    要集成测试、系统测试、用户界面等

    到，仅做单元测试是不够的，仍然需

    着相同的出错概率。而且大家也意识

    码和功能代码一样都需要维护，且有

    行的单元测试代码，而且这些测试代

    得不针对每一行功能代码，写两到三

    发人员发现，为了测试充分，他们不

    很不幸的是这招根本不管用。开

    每日电子书

    的最大障碍。此时，我们需要正确的

    测试已经成为Google持续成功道路上

    Google当时正处于这样的紧要关头，的速度，让竞争对手有机可乘。

    的产品或公司，至少会拖慢这个产品

    不当，却会扼杀一个本来有机会成功

    成一个成功的产品。但如果测试方法

    品，即便再多的测试，也无法把它变

    为，对于一个坏点子或考虑欠周的产

    速地完成测试呢？ 我一直这么认

    我们为什么要在很短的时间内迅

    以“迅雷不及掩耳”之势完成。 每日电子书

    述的，正是这个过程中我们的所作所

    分意识到质量的重要性。本书将要讲

    持正常的开发速度的同时，让大家充

    非常有帮助的。我们学会了如何在保

    Google一样快速成长的公司来说也是

    宝贵的经验和教训，这对于其他像

    效了，但在这个过程中，我们得到了

    的工具。当然，并非所有的策略都生

    新性方法、非常规的解决方案和独特

    伐。这样的测试策略会涉及大量的创

    速增长的需要，不拖慢公司前进的步

    测试策略来满足产品、用户和员工快

    每日电子书

    化，参与了重要的项目，并发布了

    加入Google，深入了解了Google的文

    是James Whittaker造就了这本书。他

    关于这本书，最后要说明一点：

    髓。

    他们已经摸索出了Google测试的精

    Whittaker和他的伙伴却抢先了一步，己为大家讲述整个故事，但James 挑战的，读这本书就对了。我本想自

    网、移动和客户端应用等方面的测试

    Google是如何面对21世纪最新的互联

    为、所思所想。如果你想要理解

    每日电子书

    在Google由200人变成2万人的过

    归功于他自己。

    Whittaker很有可能会把所有的功劳都

    定要把这一点铭记于心，因为James 参与贡献者。在你阅读这本书时，一

    更像是一个描绘记录者，而不是一个

    人在Google测试演化过程中的角色，很多素材都不是来自于他个人。他本

    出版过的其他书籍略有不同，里面的

    试的代言人。但是，这本书与他曾经

    品。有一段时间，他变成了Google测

    Chrome、Chrome OS和其他许多产

    每日电子书

    自己的想象力创造了James Whittaker

    会汇报给Patrick。作为执行官，他以

    责人，所有Google的测试人员最终都

    架构师和Google工程生产力部门的负

    Copeland，他是我们今天组织结构的

    其他任何人的影响力，比得上Patrick James Whittaker，或者本书中提到的

    中。然而没有一个人，包括我、在本书中以访谈的形式将他们引入书

    James Whittaker肯定了他们的贡献，形成和实施中做出了杰出贡献。

    程中，有许多人在我们的测试战略的

    每日电子书

    一文化的主要缔造者。他还是《The

    时他也是Google“开发者单元测试”这

    候主要负责AdWords产品的发布，同

    Alberto于2001年加入Google，那个时

    总监，同时也是一位创新鼓动者。

    Alberto Savoia 是Google的工程

    我这么说的!

    且还在于，作为我的老板，是他命令

    说的原因不仅在于他是我的老板，而

    人，那这个人一定是Patrick。我这么

    要把Google今天的测试成就归功于某

    在本书中描述和贡献的一切。如果非Way of Testivus》的作者，以及

    O’Reilly出版的《Beautiful Code》一

    书中“Beautiful Tests”一章的作者。

    来自James Whittaker 的说明：

    我完全同意Alberto所说的一切。作为

    这一过程的描绘记录者，绝大多数的

    材料都归功于Patrick创建的这个测试

    团队。还有，我这么说并不仅是因为

    Patrick授权我写这本书。作为我的老

    板，是Patrick命令我写了这本书。

    每日电子书

    每日电子书

    来，而云计算也正在逐渐成为一种新

    际，Web世界正在迎接动态内容的到

    的烦恼。当时适逢快速的技术变革之

    还比较小，但已开始感受到成长带来

    些当时Google的状况：虽然公司规模

    月。Alberto在前面的序中也介绍了一

    我在Google的旅程始于2005年3

    谷歌测试和部署技术的架构师

    Patrick Copeland

    序

    每日电子书

    Google的速度和规模面前显得毫无价

    的交付周期可长达5年，这种经历在

    前10年的研发模式经历中，一个典型

    少，有些兴奋，也有些害怕。在我之

    略。我对彼时的工作情形还知之甚

    公司每周例会，听创始人介绍公司战

    色的螺旋桨帽，参加了称为 TGIF 的

    新加入Google的员工)一起，戴着三

    其他Nooglers(译注：New Googler，在加入Google的第一周里，我和

    户机-服务器架构。

    的选择，取代当时还占统治地位的客

    每日电子书

    团队。

    可以想象，这并不是Google最闪耀的

    上，随时响应不同项目的测试需求。

    是“测试服务”，工作重点在UI的验证

    一直没搞清楚。测试团队当时的称谓

    全职人员和一些临时工，具体数量我

    还不足1000人。测试团队大概有50名

    我加入Google的时候，工程团队

    的测试人员!

    人员。当然，其他地方一定还有更多

    戴着 Noogler 帽子的人中唯一的测试

    值。更糟糕的是，我觉得自己是所有 每日电子书

    杂性给测试服务团队带来了巨大的压

    在Google内部，规模和问题的复

    力变得至关重要和生死攸关。

    情况下，规模化和快速进入市场的能

    觉到势不可挡的成长和变化，在这种

    正在让位于应用化的Web。你可以感

    无前例地爆发性增长，文档化的Web

    然而，世界在变，Web点击量开始史

    测试足以发现绝大多数的质量问题。

    要比今天小得多，一次彻底的探索式

    当时的主要业务是搜索和广告，规模

    但这在当时已经足够了。Google 每日电子书

    我也很想说自己是借助于丰富的

    的变革。

    生的巨变，测试服务团队需要根本性

    游戏规则。为了适应业界和Google发

    流程增加更多的人手，要么改变整个

    个选择，要么沿用这种劳动密集型的

    坚持。是时候采取措施了，我面临两

    的是，Google在项目快速发布方面的

    急需救火的项目之间。更加火上浇油

    人员感到筋疲力尽，疲于奔命在多个

    一些可行做法，现在却让优秀的测试

    力。在之前小型的、类同的项目里的 每日电子书

    中有所收获的话，那就是经历了各种

    脆弱的产品。如果说我在以往的经历

    想法都会被遏制，以免不小心破坏了

    感受，在那种状态下，一切创新性的

    那种被技术质量债压得喘不过气来的

    差劲，团队也问题多多。我完全清楚

    常态，代码质量很糟糕，测试用例很

    织都有这样或那样的问题。有问题是

    法。我所工作或领导过的每个测试组

    中，学到的只不过是一些过时的做

    但实事求是地讲，我从过去的经历

    经验构思出了完美的测试组织模型， 每日电子书

    量重任的，每次我都会得到相同的结

    型，想象这样的团队是如何肩负起质

    过去经常在头脑中想象理想团队的模

    新定位身为测试人员的意义所在。我

    变革Google测试的首要问题是重

    好的计算机科学基础和编程能力。

    员想加入这个俱乐部，就必须具备良

    非常重视。从根本上说，如果测试人

    是Google对于计算机科学和编程能力

    解，有一件事情是确定无疑的，那就

    那个时候，以我对Google的了

    错误的测试实践。 每日电子书

    难，找到懂测试的开发人员就更难，招聘具备开发能力的测试人员很

    发人员需要具备的技能。

    能够实现测试功能的技能，也正是开

    任何其他功能同等重要。我所需要的

    试功能的地位应该与真实客户看到的

    试变成代码库的一个实际功能，而测

    的最好方式是使测试人员有能力将测

    人员等所有人。我认为，达到此目标

    责，包括产品经理、开发人员、测试

    唯一途径是全体成员共同对质量负

    论：一个团队能编写出高质量软件的 每日电子书

    销这种关于软件测试角色的地位平等

    少有人能分享我的激情。当我开始推

    性的变革在公司里极度缺乏认同，极

    不幸的是，这种如此深刻、根本

    了。

    Google，我相信在这家公司，时机到

    业界尚未实现，但我坚信它非常适合

    更大地投入。这种组织结构在当时的

    试工作的性质和从属，要求开发团队

    做更多的事情，同时，我希望演变测

    走。我希望测试人员能为他们的产品

    但是维持现状更要命，我只能往前 每日电子书

    长达5年的开发周期又会成为现实，和质量债的困境的恐惧，一旦如此，是出于对Google的研发过程深陷技术

    我毫不松懈地继续努力着，主要

    何变革都变得非常困难。

    当前的角色，维持现状的惯性导致任

    员也不买账，因为很多人已经习惯了

    出“这是测试人员的职责”。而测试人

    更大的作用这个想法吓着了，他们指

    程师们好像被他们将要在测试上发挥

    以找到一个人一起共享午餐!开发工

    而作用不同的愿景时，我发现竟然难

    每日电子书

    构的代码形成的技术债将会导致开发

    的用户群、不断累积的bug和糟糕结

    我们不再是一个初创公司，快速成长

    ，他们就会改变看法。他们就会理解

    重复的“技术工厂”的开发和测试实践 了这种旨在打造一个生产线式的、可

    斗，我说服自己，一旦这些天才理解

    是不相容的。这是一场值得打的战

    魂，这种企业文化与冗长的开发周期

    一家由天才组成的公司，以创新为灵

    户机-服务器的世界里了。Google 是

    而我本来已经很高兴地把它们留在客 每日电子书

    聘到有能力做功能开发的人，那么，开发人员的态度是，如果我们招

    作伙伴的渴望。

    同等贡献和同等薪酬的完全的工程合

    前，我激发他们对于成为同等技能、于创新的开发过程；在测试人员面

    图，一个行动敏捷、省下更多时间用

    描绘了一个持续构建、快速部署的蓝

    容易的切入点。在开发人员面前，我

    秀的案例，试图为我的立论找到比较

    我逐个接触各产品团队，寻找优

    过程的崩溃。 每日电子书

    话：“这里是Google，如果你有想

    我的主管对这些抱怨只有一句

    地位，但又不想去改变。

    的做事方式，抱怨自己在开发面前的

    竟然与开发人员类似。他们沉湎于老

    令我吃惊的是，测试人员的反应

    并没有采纳那些建议。

    的主管的邮箱。幸运的是，我的主管

    处理我的疯狂之举，这些信塞满了我

    给我的主管，非常直率地建议如何来

    些人对我的想法非常反感，甚至发信

    我们应当让他们做功能开发。其中一 每日电子书

    最初的几个季度进行得异常艰

    理解释。

    习惯了既有模式的招聘委员会做出合

    标准与流程做出一些调整，并向已经

    试自动化。我们必须对招聘和面试的

    必须会编程，能实现工具、平台和测

    人员的技能和测试人员的思维，他们

    比较艰难，我们寻找的人要兼具开发

    个面试团队，开始招聘。事情进行得

    一批志同道合的骨干分子，组成了一

    于是我开始付诸行动。我召集了

    法，尽管去做就是。”

    每日电子书

    在，我猜每次 Larry听到我的名字时

    人，我的团队开始稳步增长。直到现

    终批准者)。他批准了足够多的候选

    Larry Page手里(他一直是招聘的最

    辩词最终会到达Google联合创始人

    每周都要抽出大量时间写辩词。这些

    干)。我预料到了招聘过程的困难，而这些方面其实与测试技能毫不相

    认为很重要的方面表现得不够好(然

    一些奇怪的编程问题，或是在某些人

    利，也许是因为他们没能很快地解决

    难。好的候选人经常在面试过程中失 每日电子书

    开发人员留下的测试工作就越多。很

    了变化在发生。测试资源越稀缺，给

    了临时人员的数量时，我已经注意到

    是在我们艰难的招聘进行中同时减少

    言，期望显得如此之高。然而，即使

    外包人员和临时人员的小测试团队而

    的。对于一个混合了很多不断变化的

    我们，一旦失败，后果将是灾难性

    这是唯一的选择。整个公司都在看着

    大量的宣传和鼓动工作，来说服大家

    当然，到这个时候，我已经做了

    想到的一定是：“招聘测试的!” 每日电子书

    我们甚至还不太会手工测试这些应

    交给开发人员，这看上去是徒劳的。

    大的技术变革，在这个时候，把测试

    还要落后一年。开发人员正面临着巨

    器的自动化技术比已经迟缓的浏览器

    浏览器还在努力追赶之中，围绕浏览

    静态Web应用的时代已经成为过去，发和测试实践处于飞速的变化之中。

    然而，技术不是静止不动的，开

    候的状态已经在接近我们的目标了。

    觉，如果技术保持不变的话，这个时

    多团队都勇敢地接受了挑战。我感

    每日电子书

    环节，甚至是两类截然不同的问题，试和开发割裂开来，看成两个单独的

    对的测试问题无法孤立地解决。把测

    的问题一样，令人生畏!测试人员面

    与我们测试人员在测试过程中要面临

    能代码的过程中，要面临很多问题，内部的基础设施。开发团队在编写功

    Docs等后继产品的融入，延展了我们

    态Web应用的公司。YouTube、Google 大。当时Google 开始收购拥有富含动

    开发团队身上的压力也同样巨

    用，更不用提自动化测试了。

    每日电子书

    入的支持团队，局限于传统QA 模

    过我们仍然是在发布过程的后期才介

    我们为顺利上线的可靠合作伙伴。不

    布周期的最后环节。开发团队已经视

    更好的定位。我们能够很好地处理发

    的发生!到了2007年，测试团队有了

    件很有意思的事情，他们会推动进展

    进展在继续。雇佣优秀的人是一

    的其中一步而已。

    测试团队的问题，只是我们前进路上

    去意味着什么问题也解决不了。解决

    这种做法是错误的，沿着这条路走下 每日电子书

    品一直保持可测试的状态。我们进行

    工具并指导团队进行持续集成，使产

    质量并尽早进行单元测试。我们开发

    发团队提供咨询，帮助他们改善代码

    的事情上取得了不少进展。我们向开

    证”(本书后面的章节会详细介绍)

    我们在一个被称作“测试认

    介入太晚。

    向发展，但是我们还是在整个流程中

    聘方面的问题，测试也向着正确的方

    还没达到我设想的目标。我解决了招

    型。尽管有了优秀的执行能力，我们 每日电子书

    的工作的一部分。我们的工具团队开

    考，我意识到测试仅仅是我们所负责

    在不断壮大。基于对这个团队的思

    测试角色的开发人员以来，测试组织

    自从根据我的想法开始招聘担当

    需要一个催化剂把它们聚合成一体。

    变革的因素已经存在，但是，我们还

    发，测试依旧是测试。虽然很多文化

    是感觉缺乏整体感，开发依旧是开

    的很多方法。但是，在那个时候，还

    前的很多质疑，本书详细介绍了其中

    了无数的改进和调整，从而消除了之 每日电子书

    开始更多地谈论生产力而不是测试和

    变，随之而来的是文化的革新。人们

    Productivity)团队。伴随着称谓的改

    为工程生产力(Engineering 因此，我决定正式把团队名称改

    务，但是我们的职责已经远大于此。

    巨大的影响力。我们的名称是测试服

    非测试的工作对生产力的提升产生了

    和咨询师。触动我的是，我们所做的

    程师、发布工程师、工具开发工程师

    陷数据库的各种工具。我们是测试工

    发了从源代码库到编译框架，再到缺 每日电子书

    发人员扫清了一个又一个障碍，消除

    工具让开发的动作更快，我们帮助开

    努力，我们实现了这些诺言。我们的

    洞，但是，随着时间的推移和我们的

    Google加速”的口号听起来也很空

    种梦想和志向，我们提出的“给

    开始的时候，这个观点还只是一

    帮助开发团队搞定这两项任务。

    开发人员负责质量。生产力团队负责

    工作。这意味着开发人员负责测试，质量是开发过程里每个人都要承担的

    质量。生产力是我们的工作，测试和 每日电子书

    Google的创新能够更为顺畅，技术债

    力和测试的区别最终变成了现实—— 他们可以轻松地达到这些要求。生产

    测试和质量负责，我们还提供帮助让

    据。我们并不是仅仅要求开发人员对

    来，作为应用发布健康性的公开数

    表盘上显示，并把成功的版本积累下

    测试人员的机器上。测试结果会在仪

    测试用例不再只是隔离地运行在某些

    次构建时看到这些测试的结果反馈。

    开发人员能够编写测试用例，并在每

    了一个又一个瓶颈。我们的工具还使

    每日电子书

    经拥有1200名工程师，这个数量比我

    在我写这篇序的时候，生产力团队已

    再到开源一些非常新颖的测试工具。

    低，到“跑完即忘”式的测试自动化，面，从将构建次数以数量级式地降

    实践。但其实，我们的成功有很多方

    历，把我们的秘诀浓缩成了一套核心

    精力，根据自身和其他 Googler 的经

    讲述这个问题的。作者们花费了巨大

    早就交了底，因为这本书就是要详细

    最终结果如何呢？我可不愿这么

    也不会累积了。在2005年加入Google时整个工程部门

    的工程师的数量还要多。生产力品牌

    的影响力已经相当大，我们加速

    Google的使命已经作为工程文化的一

    部分，被广泛接受。从我困惑、迷茫

    地坐在 TGIF 会议上的第一天到现

    在，这个团队已经走过了漫长的征

    途。这期间唯一没变的是我那顶三色

    螺旋桨帽，我把它放在我的桌上，作

    为我们一路走来的见证。

    每日电子书

    工程生产力部门的高级总监，处

    Patrick Copeland 是Google于Google整个测试链的最顶端。

    公司里所有的测试人员都最终汇

    报给Patrick(而他恰好跨级汇报

    给Larry Page，Google的联合创

    始人和CEO)。Patrick加入

    Google之前是微软的测试总监，并在那里工作了近10年。他经常

    公开演讲，在Google内部被公认

    为Google软件快速开发、测试和

    部署技术的架构师。

    每日电子书 每日电子书

    的构建动作会触发几百万自动化测试

    个源文件、亿万行的代码。数以亿计

    每天，Google测试和发布数百万

    么这本书将非常适合你。

    行如此大规模的测试感兴趣的话，那

    家互联网上最有名气的公司是如何进

    试，一定会提到Google。如果你对这

    样。谈及整个Web规模的开发和测

    软件开发并不简单，测试也一

    前言 每日电子书

    的基础架构。

    重大作用的许多人士，解释使之成功

    的，介绍在概念和实现阶段都发挥了

    示这个架构是如何设计、实现和运行

    本书描述的测试解决方案。我们会揭

    ——正是Web本身的规模——这就是

    这就是Google规模和Google速度

    100天之内发布了100个功能。

    达到持续发布。2011年，Google+在

    的构建每天都在进行，Web应用基本

    系统按年构建、测试和发布，浏览器

    在几十万个浏览器实例上执行。操作 每日电子书

    义而轻视工程严谨性的公司文化。今

    试的偏见，以及那种推崇个人英雄主

    产力”部门的奠基者们必须克服对测

    力会更大。在Google被称为“工程生

    快就被开发拉走了，因为做开发影响

    手工的过程，那些善于自动化的人很

    受重视、加班加点，测试主要是一个

    测试是主流之外的领域，测试人员不

    我们之前工作的那些公司非常类似，趣。回到6年以前，Google的情况与

    今天的路线与我们的测试技术一样有

    但之前也并非如此。Google走到 每日电子书

    构可能会变得更加普及。果真如此的

    淘金，本书介绍的测试技术和组织结

    随着越来越多的公司在Web领域

    公司的管理层认可的。

    做正确的事情，是可以被产品团队和

    来说，是非常振奋人心的。测试是在

    验，对于那些跟随Google足迹的公司

    和营收)和结构重组带来的实际考

    够经受公司巨大成长(产品、多样性

    测试人员取得成功，以及这种文化能

    工同酬，奖金、晋升待遇完全一样。

    天，Google的测试人员与开发人员同

    每日电子书

    人员，该章内容有适度的技术性，但

    Google测试的起点。SET是技术测试

    程师)这个角色，因为这是现代化的

    Engineer in Test，即软件测试开发工

    读。首先介绍了SET(Software 本书前面几章可以按任何顺序阅

    细节，这一部分建议必读。

    质量流程的所有角色、概念、流程和

    的角色组织。第一部分介绍了Google

    这本Google测试指南按照所涉及

    指南。

    话，请考虑将这本书作为到达目标的

    每日电子书

    挥过重要作用的人士的访谈。那些试

    Google的测试历史或在主要产品上发

    本书还讲述了测试管理，以及与

    章，因为它的受众面最大。

    知，我们猜测这会是读者最多的一

    角色同样为许多传统的测试人员所熟

    在产品生命周期中的职责很广。这个

    为TE的工作非常宽泛，Google的TE

    即测试工程师)。该章内容较多，因

    的测试角色——TE(Test Engineer，概念。之后的一章涵盖了另一个主要

    抽象程度足够能让任何人理解其主要图建立类似Google的测试流程或团队

    的人，可能会对这些访谈感兴趣。

    任何一位读者都千万不要错过最

    后一章。James Whittaker介绍了他对

    于Google测试如何继续演进的见解，并对Google乃至整个业界的测试方向

    做了一些预言。我们相信很多读者会

    感受到其中的洞察力，甚至感到震

    惊。

    每日电子书第1章 Google软件

    测试介绍

    每日电子书

    回答过这个问题，以及给出了多少个

    虽然我已经不太确定曾经多少次

    题：“Google是如何测试的？”

    入公司的新员工也会问到同样的问

    外地被问及一个问题。甚至是刚刚加

    问还是出席会议期间，我总是毫无例

    在许多场合下，不管是在国外访

    每日电子书

    个理由，否则就应该被扔掉做成纸尿

    试相关的书籍都要为自己的存在找一

    Alberto部分)，这个一贯认为所有测

    监，详细介绍参见本书序言中的

    注：Alberto Savoia，Google的测试总

    理成书。直到有一天，Alberto(译

    里，并幻想着有朝一日能够将它们整

    化。这些测试实践总是浮现在脑海

    同之处也越来越多，答案也一直在变

    长，发现Google的各种测试实践的不

    随着我在Google工作的时间越来越

    不同版本的答案，但可以确定的是，每日电子书

    需要去了解很多其他Google产品的测

    所有测试实践中很小的一部分，我还

    担任着)，我看到的也只是 Google

    (现在这个职位被我之前的一个下属

    Chrome和Chrome OS产品的测试总监 把机会让给他们来写；第二，我只是

    在Google，有很多我的前辈，我想先

    我并非是写这样一本书的最佳人选。

    然而，我依旧还在等待。第一，时候开始考虑写这样一本书了。

    书的时候，我觉得时机已经成熟，是

    裤的人，当他建议我应该写这样一本

    每日电子书

    Apps、YouTube视频和其他我们在

    框架，服务于包括搜索、广告、对互联网产品的共享工具与测试基础

    索性级别的测试。Google拥有大量针

    级别的测试，从单元级别的测试到探

    员使用工具的研发、产品发布和各种

    门，这个部门的职责横跨开发测试人

    效率或工程生产率)的中心组织部

    Engineering Productivity，也译为工程

    一个被称为“工程生产力”(译注：

    在 Google，软件测试团队归属于

    试方法。

    每日电子书

    Chrome OS在2010年12月发布以

    织的部门。

    一个被称为工程生产力部门的中心组

    在 Google，软件测试团队归属于

    注意

    Google的测试团队功不可没。

    言中所说的那样，拥有如此的魔力，品。正如Patrick Copeland在本书的序

    却依然能以创业公司的速度来发布产

    问题，使得Google作为一个大公司，解决了许多有关速度和扩展性方面的

    Web上提供的产品。Google已经成功1how-

    每日电子书

    解到的Google测试实践比我过去两年

    的时间。在这六个月的时间里，我了

    后，本书终于完成，希望没有拖太长

    google-tests-software.html)。6个月之

    http:googletesting.blogspot.com20110 (注：参见

    篇“Google是如何测试的”的系列文章 方式做了一些尝试，发布了第一

    书刚开始准备的阶段，我使用博客的

    重点慢慢转移到其他产品上。在这本

    直接汇报者，然后开始把自己的工作

    后，我把团队顺利地交接给我的一个

    每日电子书

    一个测试精英云集的圣地。Microsoft

    Microsoft在测试领域独步全球，也是

    亲身经历了他们书中写的许多事情。

    Test Software at Microsoft)，我当时

    的软件测试之道》(译注：How We Rollison和Ken Johnston合著了《微软

    Microsoft 的时候，Alan Page,BJ 是如何做测试的书籍。当我还在

    这并不是第一本介绍关于大公司

    阅读此书来熟悉Google的环境。

    本书，Google的新员工们也可以通过

    在Google学到的都要多。现在有了这

    每日电子书

    幸得到这样的机会。我来Google的时

    试之道》的编写，但是在Google却有

    我没能赶上参与《微软的软件测

    来记录其发生的一切。

    因此，Microsoft写了这样一本书

    代。

    地)。那是一个软件测试的黄金时

    的雷德蒙德(译注：微软总部所在

    引了来自全球的测试精英加入华盛顿

    一任测试总监——Roger Sherman，吸

    广受欢迎的演讲嘉宾。Microsoft的第

    的测试工程师在各种技术大会中也是

    每日电子书

    Conference的缩写，即Google测试自

    GTAC是Google Test Automation 万的人来浏览阅读，GTAC(注：

    Google的测试博客每月吸引了成千上

    开始了前所未有的井喷式增长。

    也是他们最后的阵痛，此后这个组织

    种增速随之而来的是成长的烦恼，这

    Patrick在本书序言中所说的那样，这

    迅猛发展到今天的1200人。正如

    以火箭喷发般的速度增长，从几百人

    升期。工程生产力团队的员工数量正

    候，其测试正处于一个蓬勃发展的上

    每日电子书

    闻名于世，在于其实现软件的方法：

    是，我并不想这样做。Google之所以

    其实可以写成一本很厚的书。但问题

    这意味着Google背后的测试故事

    心的罗马。

    兴时期，那么Google一定就是位于中

    你认为软件测试又进入到新的文艺复

    总监和工程经理直接汇报给他。如果

    Patrick也得到了晋升，手下有十几个

    议。在我来到Google不久之后，大会也已经成了测试行业的旗帜性会

    动化大会，参见 http:www.gtac.biz) 每日电子书

    还有更多的信息，你只需要“Google

    Google是如何测试的需求，互联网上

    容还是不能满足你想要充分了解

    是你的最佳获取途径。如果书中的内

    问题。如果想知道这些，阅读本书将

    件在扩展性、复杂性和大并发方面的

    么，同时也包含Google是如何解决软

    个Google的测试人员究竟意味着什

    的核心内容包括：详细讲述了作为一

    《Google软件测试之道》这本书

    保持这样的风格。

    简单和直截了当。或许这本书也可以 每日电子书

    司的测试实践之外，这两本书中所描

    是三个人，且都是在讲述大型软件公

    找一些共同点。除了两本书的作者都

    道》，那么千万不要试图在这本书中

    样。如果你已经读了《微软测试之

    的方法也很有可能成为其他公司的榜

    应用转向网络应用，Google测试软件

    的。随着越来越多的软件公司从桌面

    准备来讲述Google是如何进行测试

    的大概就是这些了。我也终于做好了

    关于本书由来的故事，不得不说

    一下”。

    每日电子书

    抛进来熔炼。在前雇主公司使用的技

    熔炉，许多来自其他公司的工程师被

    地、有组织地进化着。Google是个大

    随着公司的不断成长，它也在不停

    解释了Google测试方法演变的历史，Patrick Copeland在本书的序言中

    应用的公司。

    样，特别是那些从桌面应用转向网络

    有可能成为其他公司竞相模仿的榜

    书中关于Google的测试方法，很

    注意

    述的测试方法可谓大相径庭。

    每日电子书

    Google是一家以创新和速度为基

    用，就会立刻被抛弃。

    术，但有些技术一旦被发现并不实

    Google的测试者很愿意去尝试新技

    证明是负担的，则会被抛弃掉。

    并成为Google的一部分；另外一些被

    有用的技术会被 Google 保留下来，实践的尝试，那些在实践中被证明很

    的不断膨胀，就有了许多新的想法和

    化再进行改良。随着测试工程师队伍

    么被遗弃，要么通过Google的创新文

    术，如果被证明效率低下，该技术要 每日电子书

    道测试在做些什么。

    又是完全分离，甚至开发人员都不知

    度，而在另外一些时候，测试和开发

    织在一起，达到了无法区分彼此的程

    解决问题。有时，测试和开发互相交

    划，只是不停地简单维护并不能真正

    活，并且在技能上要做许多前期的规

    样的环境下，测试不得不变的异常灵

    用的功能(最大化用户反馈)。在这

    失望)、迭代地增加早期用户希望使

    (如果失败，也只有少数早期用户会

    础的公司，快速地发布有用的代码

    每日电子书

    就发布像 Chrome 这样的客户端应

    年内就做出一个操作系统、在几周内

    是很久以前的历史，但还是可以在一

    慢了一点点而已。虽然Google创业已

    当前Google的发展速度只比创业初期

    贯穿Google的整个发展史来看，试在做些什么。

    全分离的，甚至开发人员都不知道测

    在另外一些时候，测试和开发又是完

    起，达到了无法区分彼此的程度，而

    有时，测试和开发互相交织在一

    注意 每日电子书

    单。Google软件应用的规模和复杂度

    单地归结为其被测系统规模小且简

    Google在测试上的成功，不能简

    况不能出现两次。

    开发过程变慢的阻碍。至少，这种情

    以确定的，测试不能成为导致创新和

    尝试解释测试是什么。有一件事是可

    是什么要简单的多，虽然本书一直在

    密集型、耗时的”——这比定义测试

    测试并非“教条式的、强流程、体力

    在这种环境下，很容易就可以说清楚

    用、每天都在更新其网络应用程序。 每日电子书

    家，使用不同的语言，但是用户其实

    审。Google的代码服务于上百个国

    码，使用常规的代码审核来做代码评

    界所觊觎。多数代码是历史遗留代

    是开源的，这些代码对外公开，被外

    攻击目标。绝大多数Google源代码都

    数以亿计的用户，也是黑客们喜爱的

    Google的软件庞大且复杂，拥有

    面，Google几乎无所不包。

    级应用、商业应用、社交等各个方

    操作系统到网络应用、移动端、企业

    与外面其他的公司一样。从客户端的

    每日电子书

    测试模式很有可能会逐渐成为测试行

    桌面应用迁移到网络云端，Google的

    方法有很大的不同。随着软件逐渐由

    试方法与其他我所了解的公司的测试

    情，但有一点是确定的，Google的测

    能是错误的)是一个值得商榷的事

    Google的做法是否正确(很有可

    都在面临不同的测试挑战。

    简单的问题，Google的测试人员每天

    人员每天完成的工作，并非只是解决

    且“能够工作”的服务。Google的测试

    只是期望 Google 能够提供简单易用 每日电子书

    们才能持续地改进。

    下，在经过外界的严格审查之后，我

    表露在业界和国际测试社区的眼皮之

    但我们也乐意去对外公开它们，使之

    Google的测试方法或许有它的不足，些讨论，达到抛砖引玉的目的。

    Google的测试实践，从而可以引起一

    作者就希望通过本书可以很好地阐述

    业值得争议的话题。我和本书的其他

    的、值得信赖的软件，一直是这个行

    何做测试，从而保证可以开发出可靠

    业的主流模式。在测试这个行业，如

    每日电子书

    正如 Larry Page 所说，“少则清晰”。

    得我们不得不去做好优先级的安排，展的根本原因。没有足够的人手，使

    缺乏，这也是我们向特种部队方向发

    出色的战术和高级武器。由于资源的

    是小而精的特种部队，我们依靠的是

    的测试团队并非雄兵百万，我们更像

    要少。在通往成功的道路上，Google

    争对手公司的单个产品的测试人员还

    常少的专职测试人员，甚至比我们竞

    背常理——在整个公司，我们只有非

    Google的测试方法看起来有点违 每日电子书

    注意

    员。

    个建议就是，不要招聘太多的测试人

    Google成功的关键是什么，我的第一

    和充沛的精力。当有人来问我，缺且聪明的测试员工保持昂扬的斗志

    贵，因此，我们的原则就是让这些稀

    员的稀缺会导致测试资源变得非常昂

    影响力、低阻力的实践活动。测试人

    经学会了如何运用这些技术，创建高

    面的技术，在追求质量方面，我们已

    不管是功能方面的技术，还是测试方

    每日电子书

    Google，谈论开发测试比(译注：这

    合共同承担，如图1.1所示。在

    质量在名义上也由这样的开发测试组

    个写代码的开发者本身就是测试者，一些测试人员的问题。在Google，每

    了质量的重任。质量从来就不仅仅是

    在Google，写代码的开发人员也承担

    况下，是如何应对的呢？简单地说，Google在测试人员如此缺乏的情

    要招聘太多的测试人员。

    键是什么，我的第一个建议就是，不

    当有人来问我，Google 成功的关 每日电子书

    在其他的公司组织中也能适用。当然

    方法值得学习。或许其中的一些经验

    件，这也足以证明其对待质量的独特

    Google可以打造出世界级的软

    测试。

    头衔上没有测试的人可以更好地去做

    试的字样，你的任务就是怎样使那些

    试人员。如果在你的职位头衔上有测

    一名工程师，那么你同时也是一名测

    样，这本身没有任何意义。如果你是

    率)就像讨论太阳表面的空气质量一

    里指在人员数量上，开发和测试的比里面也有需要改进的地方。接下来所

    述就是关于Google测试方法的概要介

    绍。在后面的章节里，我们会深入到

    细节中，以此来阐述在以开发为中心

    的文化中Google是如何做测试的。

    每日电子书▲图1.1 与功能相比Google工程师更看重质

    量

    每日电子书

    每日电子书

    然而，这句话也并不像听起来那

    确，否则将会陷入混乱的万丈深渊。

    因此，从最初的创建阶段就要做正

    量问题的产品，代价是多么的昂贵。

    车行业的公司，大量召回事实上有质

    它永远不会变成正确的。试问一下汽

    最开始设计创建的时候就是错的，那

    理。从汽车行业到软件行业，如果在

    看似陈词滥调的话却包含着一定的道

    质量不是被测试出来的——这句

    1.1 质量不等于测试 每日电子书

    活动，它本身就是开发过程的一部

    做更多的测试。测试不是独立隔离的

    段代码，当完成了更多的代码时就要

    需要在写完每一段代码后立刻测试这

    对立。开发和测试应该并肩齐趋。你

    难题，那就是停止开发与测试的隔离

    有一个简单的办法可以解决这个

    你的软件具有很高的质量呢？

    件。如果连测试都没有做，如何保证

    经测试也不可能开发出有质量的软

    出来的，但同样有证据可以表明，未

    样的简单和准确。虽然质量不是被测 每日电子书

    ——开发和测试必须同时开展。写一

    就是把开发过程和测试融合在一起

    在Google，这正是我们的目标，时候，你就得到了质量。

    混合搅拌那样，直到不能区分彼此的

    程和测试放到一起，就像在搅拌机里

    质量不等于测试。当你把开发过

    注意

    时候，你就得到了质量。

    混合搅拌那样，直到不能区分彼此的

    程和测试放到一起，就像在搅拌机里

    分。质量不等于测试，当你把开发过 每日电子书

    的专职测试人员的原因，就是开发对

    避免产生bug呢？Google能用如此少

    谁会为了避免受更大刺激而去想办法

    写代码的人更适合去寻找bug呢？是

    人更适合做测试呢？还有谁能比实际

    开发人员。还有谁能比实际写代码的

    例，唯一可能的去做这些的就只能是

    非常稀少，与开发相比根本不成比

    知，在Google，专职测试人员的数量

    关键是由谁来做这些测试呢？众所周

    多的代码就做更多的测试，但这里的

    段代码就立刻测试这段代码，完成更 每日电子书

    版本。在确保不出现回滚级别bug发

    是bug重重，它将会被回滚到之前的

    程。如果一些项目在线上被证实的确

    部分，并创建了一个增量上线的流

    功地将测试实践融入为开发过程的一

    问题，而不是测试问题。我们已经成

    为，而不是检测。质量是开发过程的

    这意味着质量更像是一种预防行

    个bug的测试人员。

    问题发生的开发人员，而不是遗漏这

    题，第一个跳出来的肯定是导致这个

    质量的负责。如果某个产品出了问1introducing-

    每日电子书

    过程中必不可少的一部分，当开发过

    testing-on-toilet.html)。测试是开发

    http:googletesting.blogspot.com20070 实践(注3：参见

    着的、用来提醒开发人员的最佳测试

    的测试在哪儿”，再到在卫生间张贴

    密不可分，从代码审核问询时的“你

    把开发过程和测试混合在一起，是来判断这种预防工作做的怎么样。

    员的数量。在Google，测试的目标就

    同时，也很大程度降低了专职测试人

    生的前提下，预防了许多客户问题的程和测试一起携手联姻时，既是质量

    达成之时。

    注意

    测试是开发过程中必不可少的一

    部分，当开发过程和测试一起携手联

    姻时，即是质量达成之时。

    每日电子书

    每日电子书

    测试工作。在传统的开发岗位之外我

    码负责，比专职的测试人员更适合做

    意思是开发人员自己要对自己写的代

    只有开发人员自己才能修复。这里的

    复构建失败(build break)的问题，验室(Build Lab)的人永远不会去修

    break it，you fix it”。原意指在构建实

    you break it”，摘自“you build it，you 名言成为事实(译注：“you build it，为了保证“解铃还需系铃人”这句

    1.2 角色 每日电子书

    量也是效率的一部分。在接下来的章

    因马虎粗心而导致的返工，因此，质

    有效率，并且很大一部分体现在避免

    员的存在是为了让开发人员的工作更

    上他们的使命是提高生产率。测试人

    常把他们自己看做是测试者，但实际

    程师更有效率和质量意识。这些角色

    样的角色，他的职责就是让其他的工

    测试。在Google，我们的确创建了这

    可以让开发人员更加有效且高效地做

    出了有一种工程师角色必须存在，他

    们又增加了几种角色。我们明确地提1.2.1 软件开发工程师

    每日电子书

    结构和整体架构，并且花费大量时间

    他们创建设计文档、选择最优的数据

    是实现最终用户所使用的功能代码。

    一个传统上的开发角色，他们的工作

    software engineer，后文简称SWE)是

    软件开发工程师(译注：

    (SWE)

    介绍。

    这些角色，所以在这里只进行简单的

    节里，会花费较多的内容来详细讲解 每日电子书

    时间都花费在了代码编写上。

    例的代码。开发工程师几乎将所有的

    试用例，他就必须去实现这个测试用

    运行失败，或者需要增加一个新的测

    数，如果这次修改导致已有测试用例

    假设一个开发者不得不修改一个函

    修复以及修改的代码承担质量责任。

    面做详细解释。SWE会对他们编写、模的测试等，这些测试会在本章的后

    计、单元测试、参与构建各种大小规

    编写与测试代码，包括测试驱动的设

    在代码实现与代码审核上。SWE需要1.2.2 软件测试开发工程师

    每日电子书

    试框架。SET是SWE在代码库上的合

    构，并编写单元测试框架和自动化测

    测试性，他们甚至会对代码进行重

    地观察代码质量与风险。为了增加可

    上。他们参与设计评审，非常近距离

    重心在可测试性和通用测试基础框架

    SET)也是一个开发角色，只是工作

    software engineer in test，后文简称

    软件测试开发工程师(译注：

    (SET) 每日电子书

    量的提升和测试覆盖率的增加。SET

    代码的SWE相比，SET更加关注于质

    伴，与增加功能性代码或提高性能的

    SET是SWE在代码库上的合作伙

    注意

    使用功能的开发实现上。

    是为质量服务，而SWE则更关注客户

    间在编写代码上，他们这样做的目的

    加。SET同样会花费近百分之百的时

    关注于质量提升和测试覆盖率的增

    代码或是提高性能的代码，SET更加

    作伙伴，相比较SWE是在增加功能性

    每日电子书

    上。同时，他们会把开发工程师和

    用场景和自动化脚本或代码的编写

    TE会花费大量时间在模拟用户的使

    考，代表用户的利益。一些Google的

    关注点——把用户放在第一位来思

    SET关系密切的角色，有自己不同的

    engineer，后文简称TE)是一个和

    测试工程师(译注：test

    1.2.3 测试工程师(TE)

    的功能。

    写代码的目的是可以让SWE测试自己

    每日电子书

    到端的自动化测试。

    试运行结果，驱动测试执行，构建端

    TE 组织整体质量实践，分析解释测

    TE 把用户放在第一位来思考。

    注意

    一些TE则只用编写少量的代码。

    些TE需要编写大量的代码，而另外

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

    段，推进产品发布。TE是真正的产

    动测试执行，特别是在项目的最后阶

    来，分析、解释、测试运行结果，驱

    SET编写的测试分门别类地组织起

    每日电子书

    交队列来管理代码的提交。换句话

    些内容会在后面详细讲到)和代码提

    stubs、mock、fake等方法的流程，这

    个真实的工作运行环境(一个包含

    以把新开发的代码隔离，通过模拟一

    试支持。有这样一个测试框架，它可

    SET 也是开发人员，负责提供测

    写测试代码。

    计、单元测试负责，并和SET一起编

    对容错设计、故障恢复、测试驱动设

    能实现和这些独立功能的质量。他们

    从质量的角度来看，SWE负责功

    每日电子书

    注于用户角度的测试则是 TE 的职

    而达到独立功能模块的质量要求。专

    发者可以很容易地编写测试代码，从

    是开发人员。SET的主要职责是让开

    很明显，SET的主要关注对象就

    去。

    可以积极地参与到测试代码的编写中

    块具有可测试性，并且相应的SWE还

    SET存在的目的就是保证这些功能模

    功能。多数测试代码是由SWE完成，供的功能让SWE能够自己测试他们的

    说，SET 编写代码，通过这些代码提 每日电子书

    场景中去，是否满足性能期望，在安

    TE会把注意力转移到常见用户使用

    较马虎。当这些明显的bug变少时，发人员所做的测试工作存在不足或比

    位，任何明显的bug都会表明早期开

    认开发人员在测试方面的工作是否到

    TE扮演着一个双重确认的角色，确

    可以满足最终用户的需求。在这里，的代码与数据集成在一起之后，是否

    一步要考虑的就是要验证这些可执行

    多的模块级别与功能级别的测试，下

    责。考虑到SWE和SET已经做了足够全性、国际化、访问权限等方面是否

    满足用户的要求。TE运行许多测试

    的同时，也负责和其他团队的TE、合同工编制的测试人员、以众包形式

    参与的测试者、内部尝鲜者、beta测

    试者以及早期用户进行合作交流，与

    各方讨论基本设计带来的风险、功能

    逻辑复杂性和错误避免的方法。一旦

    TE参与到项目之中，基本上就会没

    完没了。

    每日电子书

    每日电子书

    团队能真正做到这样。资深管理者一

    但不幸的是，我还从来没见过有

    等相处、患难与共。

    参与的人都在一起，应该可以做到平

    来，同一个产品、同一个团队、所有

    一个产品团队的管理者。这样看起

    上讲，开发人员和测试人员汇报给同

    于同一个工程产品团队。从组织架构

    中，开发人员和测试人员都一起隶属

    在我过去曾经工作过的多数组织

    1.3 组织结构 每日电子书

    或开发经理，而不是来自于测试团

    资深管理者一般都来自产品经理

    注意

    就再发布一个补丁包。

    品，或许这就是问题所在。质量不行

    是充斥着各种有缺陷的、早产的产

    为开发让路。为何我们这个行业里总

    问题。作为同一个团队，测试总是在

    方面是否足够简单，却很少考虑质量

    优先考虑的是功能的完备性和易用性

    是来自于测试团队。在产品发布时，般都来自产品经理或开发经理，而不

    每日电子书

    总裁。

    给这些专注领域的管理者、总监或副

    动，等等。所有的开发工程师都汇报

    Google Earth等)、广告、Apps、移

    Google工具栏等)、地理(地图、些专注领域包括客户端(Chrome、不同的专注领域(Focus Areas)。这

    Google的组织汇报关系被划分为

    队，测试总是在为开发让路。

    单，却很少考虑质量。作为同一个团

    能是否完整和易用性方面是否足够简

    队。在产品发布时，优先考虑的是功 每日电子书

    试。我们有自己选择决定的优先级，告之某个项目急需发布就可以通过测

    进行汇报，因此我们并不是简单地被

    由于测试人员并不是直接向产品团队

    者公开一些不可接受的缺陷率数据。

    事情，寻找一些测试不足的地方，或

    进入产品团队，去做提高质量相关的

    团队。测试人员基本上以租借的方式

    品专注领域)，我们称为工程生产力

    注领域部门平行的部门(横跨各个产

    式。测试是独立存在的部门，是与专

    但SET和TE并没有遵循这个模 每日电子书

    应是开发人员的工作，不能简单地扔

    活累活。这些功能相关的脏活累活本

    然后再让他们做一些简单和琐碎的脏

    术要求，从而雇佣更多的测试人员，团队不能任意降低测试人员招聘的技

    保持数量较少的测试人员。一个产品

    这样的组织结构也可以帮助我们

    般情况下也都会被拒绝。

    马，他们必须事先和我们协商，但一

    发团队想要我们在测试上放他们一

    协，除非碰到更重要的事情。如果开

    在可靠性、安全性等问题上都不会妥 每日电子书

    员。显然，有时候我们可能搞错，实

    品实际比较之后，再来分配测试人

    团队的优先级、复杂度，并与其他产

    工程生产力团队会根据不同产品

    注意

    不明确的需求之间的某种平衡。

    总体来说，这样会保持实际的需求与

    可能搞错，实际上也确实出过错，但

    来分配测试人员。显然，有时候我们

    度，并与其他产品实际比较之后，再

    会根据不同产品团队的优先级、复杂

    给倒霉的测试人员。工程生产力团队

    每日电子书

    把这个创新的发明者直接借调过来。

    试技术方面创新的最佳方式，莫过于

    Chrome 产品中也得到使用。推广测

    好的测试技术或工具，很有可能在

    内部蔓延。一个在Geo产品上运用很

    证一个好的测试想法可以快速在公司

    新鲜感并且总是很忙碌，另外还能保

    借调模式，可以让SET和TE时刻保持

    这种测试人员在不同项目之间的

    求之间的某种平衡。

    这样会保持实际的需求与不明确的需

    际上也确实出过错，但总体上来说，每日电子书

    同的语言和平台。由于Google的产品

    领域都有所涉猎，可以高效地使用不

    客户端、Web、浏览器、移动技术等

    人员的存在。Google 的测试工程师在

    保持对各个产品与技术都了解的测试

    痛，但从整个公司的角度来看，需要

    个产品失去优秀测试专家而带来的悲

    这个转岗并不是强制的。可以想象一

    无理由地自愿转岗到其他产品，当然

    个产品中工作满18个月之后，就可以

    做法：对于一个测试人员，如果在某

    在 Google 有一个广泛被接受的和服务很大程度上有比较强的集成关

    联关系，测试人员可以很容易地保持

    相关的专业技能，并在公司范围内的

    产品之间自由穿梭。

    每日电子书

    每日电子书

    着beta标签在线上运营了四年，这个

    我们在Gmail产品上的经验，Gmail带

    真实反馈，再进行迭代开发。这也是

    对外发布使用，然后从用户那里得到

    品的基本核心功能实现之后，就立刻

    上，我们的做法恰恰相反，在一个产

    产品发布中包含大量的功能。实际

    核心原因在于Google从来不会在一次

    下，Google 还可以取得不错的成果，在拥有如此少量测试人员的情况

    1.4 爬、走、跑

    每日电子书

    够的功能，早期版本并不意味着是一

    产品还处于早期版本就不为之提供足

    于初期版本的用户，并不是因为这个

    同的策略。有一点需要引起注意，对

    全面，之后的Nexus手机也采用了相

    的产品变得更棒了，功能也更加丰富

    法，让这个非常有用且经过良好设计

    这个产品上，我们再次使用了这个方

    才会把beta标签去掉。在Android G1

    该产品达到99.99%的可用性时，我们

    处于改良之中。对于最终用户，只有

    标签用以警示我们的用户，Gmail 仍

    每日电子书

    并不像想象中如牛仔一般的鲁莽与仓

    Google发布的过程虽然快，但也

    正式发布版本。

    版本、开发版本、测试版本、beta或

    用户使用之前，一般都要经历金丝雀

    都非常注重质量。一个产品在发布给

    户的反馈，而且在每次迭代的过程中

    快速迭代的过程中得到内部和外部用

    含最基本的可用功能，然后在后继的

    Google 经常在最初的版本里只包

    注意

    个不可用的烂版本。

    每日电子书

    (译注：17世纪，英国人将金丝雀放

    适宜的版本。就像煤矿井里的金丝雀 建的版本，用来排除过滤一些明显不

    金丝雀版本： 这是每日都要构

    使用了不同的版本，大致顺序如下。

    来自用户的反馈，我们在整个过程中

    个产品，根据我们对产品的信心以及

    入Google之后的两年都为之工作的一

    一定的质量。例如Chrome，这是我加

    部版本验证，用以证明它已经具备了

    的版本，一个产品要经历一系列的内

    促。实际上，为了发布我们称为beta 每日电子书

    版本。

    员)和管理人员才会安装使用金丝雀

    这个产品的工程师(开发或测试人

    用应有的基本功能。一般来说，只有

    忍度，而且在这个版本下可能无法使

    工作。使用金丝雀版本需要极强的容

    了严重问题，需要去复查一遍我们的

    话，意味着我们的流程可能在哪里出

    件事情的预警)，如果构建失败了的

    达到令人中毒的水平。此处意为对一

    金丝雀死了，则表示矿井中的空气已

    到煤矿井里检测井中空气质量。如果

    每日电子书

    列的测试(我们将会在随后的章节里

    该版本具有一定的功能并通过了一系

    使用的版本，一般是每周发布一个。

    开发版本： 这是开发人员日常

    家人通话。

    甚至都无法使用其基本功能，例如和

    的代码，一旦安装了错误代码，手机

    做是为了减少往代码库中提交有问题

    机上都安装有每日构建的版本。这样

    的尝试，所有核心开发团队成员的手

    Android团队在这方面有更勇敢

    注意

    每日电子书

    近一个月里的最佳版本了，也是工程

    续测试的版本。这个版本基本上是最

    测试版本： 这是一个通过了持

    新评估。

    程团队也需要再花费大量的时间去重

    本。发生这种情况不但令人郁闷，工

    求，那么它将会被打回为金丝雀版

    发版本不能够满足日常真实工作的需

    续对这个版本进行测试。如果一个开

    日常工作中真正使用它，这样可以持

    师都会被要求去安装这个版本，并在

    讨论这点)。所有这个产品下的工程

    每日电子书

    经历了内部使用和通过所有质量考核

    由非常稳定的测试版本演变而来，并

    beta或发布版本： 这个版本是

    个版本。

    这个产品的外部合作伙伴也会使用这

    部使用得足够稳定，一些想更早尝试

    一些情况下，如果测试版本在公司内

    现，也是作为beta 测试的候选版本。

    本，如果该版本有比较持续的优良表

    为内部尝鲜(译注：dog food)版

    的一个版本。测试版本可以被挑选作

    师在日常工作中使用的最稳定最信任的一个版本，也是对外发布的第一个

    版本。

    这种爬、走、跑的模式，给我们

    的应用程序尽早地提供了一个测试验

    证的良好机会。与从自动化测试那里

    得到的反馈一样，我们每天都能从内

    部用户那里得到关于这些版本的质量

    反馈。

    每日电子书

    每日电子书

    试，无论是自动化的还是手动的。测

    程师都会去执行其中的任何一种测

    测试类型以此类推。Google的三类工

    试意味着涵盖较少量的代码，其他的

    调测试的范畴规模而非形式。小型测

    的那些T恤型号混为一谈)，着重强

    测试这样的称谓(不要和敏捷社区发

    而是使用小型测试、中型测试、大型

    成测试、系统测试等这些命名方式，Google并没有使用代码测试、集

    1.5 测试类型

    每日电子书

    是否按照预期工作，着重于典型功能

    一个单独函数或独立功能模块的代码

    所有)都是自动化实现的，用于验证

    小型测试 一般来说(但也并非

    规模而非形式。

    试这样的称谓，着重强调测试的范畴

    是使用小型测试、中型测试、大型测

    成测试、系统测试这些命名方式，而

    Google 并没有使用代码测试、集

    提示

    为自动化的测试。

    试的规模越小，就越有可能被实现成

    每日电子书

    假设的需求提供期望的结果。fake 对

    赖系统的模拟，在运行时刻可以根据

    fake(译注：mock对象是指对外面依

    试。小型测试一般需要使用mock和

    量的SET参与，TE几乎不参与小型测

    小型测试是由SWE来实现，也会有少

    短的时间内就可以运行完毕。通常，时间一般比较短，通常是在几秒或更

    误)等方面的验证。小型测试的运行

    one)错误是一类常见的程序设计错

    差一错误(译注：大小差一(off-by- 性问题、数据损坏、错误条件和大小72whats-

    每日电子书

    现的。该测试一般会涉及两个或两个

    中型测试 通常也都是自动化实

    码是否按照预期的方式运行”。

    测试主要尝试解决的问题是“这些代

    些测试，来诊断一些特定错误。小型

    编写小型测试代码，但会参与运行这

    and-stubbing)才能运行。TE 几乎不

    the-difference-between-faking-mocking- http:stackoverflow.comquestions3463 果。更多参见

    定的数据或逻辑，只能返回特定的结

    象是一种虚假的实现，内部使用了固

    每日电子书

    通过手动的方式(如果比较难去实现

    析原因。在开发过程的后期，TE 会

    试运行失败，SWE会自觉地去查看分

    试和维护这些测试。如果一个中型测

    行，SWE会深度参与，一起编码、调

    后，SET会驱动这些测试的实现及运

    中，在独立模块功能被开发完毕之

    能近邻区”)。在产品早期开发过程

    否正确(我们称功能交互区域为“功

    间的交互，以及彼此调用时的功能是

    试重点在于验证这些“功能近邻区”之

    以上，甚至更多模块之间的交互。测

    每日电子书

    证软件是否满足最终用户的需求。所

    块的集成，但更倾向于结果驱动，验

    运行完成。大型测试关注的是所有模

    需要消耗数个小时或更长的时间才能

    使用场景和实际用户数据，一般可能

    常更多)的功能模块，使用真实用户

    大型测试 涵盖三个或以上(通

    的那样工作。

    块互相交互的时候，是否如我们预期

    试去解决的问题是，一系列临近的模

    自动化地执行这些用例。中型测试尝

    自动化或实现的代价较大时)，或者 每日电子书

    境里。中型测试涵盖多个模块且重点

    般运行在完全虚假实现(fake)的环

    小型测试涵盖单一的代码段，一

    注意

    是大型测试关注的重点。

    整体产品或服务之上的操作行为，即

    结果。这种端到端的使用场景以及在

    否和用户的期望相同，并产生预期的

    的问题是，这个产品操作运行方式是

    是探索式测试。大型测试尝试去解决

    测试之中，或是通过自动化测试，或

    有的三种工程师角色都会参与到大型 每日电子书

    勃的测试者有时会说到第四级别的测

    测试范围是如何划分的。一些雄心勃

    来谈论他们测试的是什么，以及这些

    是，在Google测试人员使用统一术语

    以，只要大家都一致认可。重要的

    什么并不重要，怎么称呼它们也都可

    小型、中型、大型等描述术语是

    的用户数据与资源。

    般运行在真实的环境中，并使用真正

    中。大型测试涵盖任意多个模块，一

    在虚假实现(fake)环境或真实环境

    关注在模块之间的交互上，一般运行 每日电子书

    产品的真实反馈，然后再迭代开发出

    发布，并快速地从外部用户那里得到

    区别也比较明显。Google喜欢频繁地

    大小是动态变化的，不同产品之间的

    我们的测试对象以及测试范围的

    的。

    面意思就可以理解，这样做是最好

    不需要用过多的文字去解释，按照字

    运行时间会非常长。对于一些术语，级别的系统测试，涵盖所有的功能且

    的其他测试同仁会认为这是一个超大

    试，即被称为“超大型测试”，公司里 每日电子书

    动化，并不需要人脑的智睿与直觉来

    试，当然更倾向于前者。如果能够自

    试的比例，对于所有的三种类型测

    最后，关于自动化测试和手动测

    的产品是否满足用户的真正需求。

    与，这样可以更有利于判断我们发布

    把用户和外部开发者一起拉进来参

    品特性，这就要求我们要非常及时地

    我们也在避免做一些用户不想要的产

    地提供一些功能给用户使用。另外，非常感兴趣的产品特性，并尽可能早

    新功能。Google积极努力地开发用户 每日电子书

    得重点关注的一点，Google也有大量

    正如上文中提到的，同时也是值

    就应该以自动化的方式实现。

    不需要人脑的智睿与直觉来判断，那

    更倾向于前者。如果能够自动化，并

    对于所有的三种类型测试，当然

    注意

    需要手动测试来完成。

    留的数据是否包含隐私等，这些还是

    判断，例如，用户界面是否漂亮、保

    现。但在一些情况下需要人类智慧的

    判断，那就应该以自动化的方式实

    每日电子书

    测试在每次建立之后都会重复地回归

    测试转变成自动化测试，这些自动化

    证方式、录制技术等可以把一些手动

    方式所替代。通过使用定位点击的验

    在被密切地关注，以后可能被自动化

    一些使用探索式的方法，这些测试都

    强调一种case的实现方式)，而另外

    过脚本实现的自动化用例，这里只是

    注意，这里scripted case，不是指通

    个步骤都记录下来的用例表示方式。

    记录(译注：scripted case，把每一

    的手动测试，有些使用脚本的方式在 每日电子书

    在构建之中的下一代测试工具的努力

    Google的设计理念与目标，也正是正

    服“人类智慧的最后一英寸”这也是

    录这个问题。将自动化做到，力争克

    发送一封邮件，并新开一个bug来记

    首。系统会自动给代码变更的提交者

    变更极有可能是造成失败的罪魁祸

    查到最后一次代码变更的内容，这些

    自动化用例运行失败，系统会自动检

    动工作都自动化实现了，例如，如果

    功能。我们甚至把开bug和日常的手

    运行，而手动测试更倾向于关注于新方向。

    每日电子书第2章 软件测试开

    发工程师

    每日电子书

    极小、导致循环语句超出限制范围的

    的测试用例，数据取值范围从极大到

    编写的代码。他会设计一些边界场景

    开发人员就会去思考如何测试他即将

    一行代码都没有真正编写之前，一个

    过程是怎样进行的呢？测试先行，在

    在理想情况下，一个完美的开发 每日电子书

    端)读取数据，这就需要存在一个真

    从远程数据源(一个数据库或者云

    设施服务。例如，一个测试用例需要

    品代码之外，通常都依赖于外部基础

    另外一些测试需要的知识在本产

    的人。

    格去做的人，其实就是编写功能代码

    于此种类型的测试，最合适且最有资

    码的形式与功能代码存储在一起。对

    的一部分，以自检代码或单元测试代

    情况。这些测试代码会作为产品代码

    情况，另外还会考虑很多其他的极端

    每日电子书

    在理想开发过程中首次需要测试

    里)。

    这是在一个真正理想的软件世界

    出现在你眼前，任由你使用(记住，时，如果需要，这些工具都应该及时

    的完美开发过程中，在你做功能测试

    infrastructure,mock and fake)。在假想

    (译注：test harnesses,test 测试通用设施、模拟设施和虚拟设施 描述这些辅助设施，包括测试框架、年中，工业界使用了各种特定术语来

    实数据库或模拟的数据库。在过去几

    每日电子书

    前提是在一个童话般的理想开发过程

    分离用户及其数据。由于我们假设的

    是去破坏，怎样写测试代码用以扰乱

    上；而对于测试代码来说，主要思路

    点在考虑用户、使用场景和数据流程

    功能代码而言，思维模式是创建，重

    developer and test developer)。对于

    试开发人员(译注：原文是feature 这也就需要去区分功能开发人员和测

    编写测试代码的时候是迥然不同的，方式而言，在编写功能代码的时候与

    人员的时刻即将来临。对于人的思维 每日电子书

    中所写的完全理性的共和国“乌托

    字由托马斯·摩尔的《乌托邦》一书

    是一个理想的群体和社会的构想，名

    在这样乌托邦式(译注：乌托邦

    思维方式上有着很大的不同。

    编写功能代码和编写测试代码在

    注意

    发人员和测试开发人员)。

    注：两种开发工程师，分别是功能开

    另一个思考如何破坏这些功能(译

    的开发工程师：一个写功能代码，而

    里，所以我们或许可以分别雇佣不同

    每日电子书

    题如果只是由功能开发人员独自完

    解决特定的单元测试问题，而这些问

    用测试工具与框架帮助功能开发人员

    测试开发人员。测试开发人员通过使

    发人员，整个产品则配备一定数量的

    下，产品的每一个功能都对应一个开

    而努力。在我们假想的完美理想情况

    要通力合作，共同为打造同一款产品

    开发人员(译注：test developer)需

    员(译注：feature developer)和测试

    理想开发过程中，众多的功能开发人

    邦”而来，意指理想完美的境界)的

    每日电子书

    包括用例(use case)、用户故事、解决的主要问题是面向用户的任务，(译注：user developer)。他们需要

    们把这个新角色称为用户开发人员

    开发人员，也不是测试开发人员。我

    由第三种工程师来完成，既不是功能

    的乌托邦测试世界里，这个工作应该

    真正用户的角色。显然在我们理想化

    但我们还需要第三种角色，一个关心

    时候，测试开发人员编写测试代码，功能开发人员在编写功能代码的

    成，则会消耗掉他们许多的精力。 每日电子书

    相互之间又可以平等地合作。

    美。每个角色专门处理重要的事情，用性和可靠性方面分工合作，达到完

    乌托邦理想模式，三种开发角色在可

    这就是我们眼中软件开发过程的

    值。

    在一起之后是否对最终用户产生价

    从用户角度出发，验证独立模块集成

    虑系统级别的问题，通常情况下都会

    起成为一个完整的整体，他们主要考

    人员关心这些功能模块如何集成在一

    用户场景、探索式测试等。用户开发 每日电子书

    端模式转变(注：一个有趣的事情需

    周、每天，甚至每小时都会发布的云

    期需要以年为单位的客户端模式向每

    件正经历一个巨大的转变，从发布周

    人那里吸取了很多经验教训。当前软

    为Google起步较晚，我们有机会从前

    力去尝试成为这样的公司。或许是因

    已。Google与其他公司一样，都在尽

    不存在，Google也只是比较接近而

    但不幸的是，这样的公司目前还

    作呢？大家全都要报名应聘!

    谁不想为这样的软件开发公司工

    每日电子书

    测试代码。

    他们编写功能代码及这些功能的单元

    员，负责客户使用的功能模块开发。

    Google 的 SWE 就是功能开发人

    几分相似。

    的软件开发流程与乌托邦模式也有了

    多。在这两种原因的促进下，Google

    Google 也从这次转换浪潮之中受益良

    客户端应用都有这个功能)，而

    一个“自动更新”的功能，几乎所有的

    Google也喜欢常去更新，客户端使用

    要说明一下，即使是客户端软件， 每日电子书

    测试覆盖度，并验证其他工程师角色

    码；从产品的角度看，他们评估整体

    写用户使用场景方面的自动化用例代

    种问题。从开发的角度来看，他们编

    负责从用户的角度来思考质量方面各

    Google的TE就是用户开发人员，相关的测试工作。

    编写中小型测试，用以进行更多质量

    开发人员提供测试框架，以方便他们

    开发人员支持，另外一部分职责是为

    员，部分职责是在单元测试方面给予

    Google的SET就是测试开发人 每日电子书

    述两种角色的补充。虽然SWE也重度

    会包含少量SWE的工作内容，作为上

    SET和TE这两个角色的工作内容，也

    在这本书里，我们将会着重介绍

    Google的TE是用户开发人员。

    Google的SET是测试开发人员；

    Google的SWE是功能开发人员；

    注意

    料且无路可退。

    的尝试，前进的道路上充满了不可预

    托邦，这就是Google实践之路上最好

    在测试方面合作的有效性。这不是乌参与测试工作，但一般情况下都是在

    头衔中包含“测试”的工程师的指导之

    下完成的。

    每日电子书

    每日电子书

    揭秘广告系统的工作原理)。当然那

    query是如何实现的，Life of a Dollar

    课程里，Life of a Query揭秘搜索

    语。针对Nooglers(新Google员工)的

    告是如何工作的)中使用的特定术”是Google内部系列课程(搜索和广

    文为The Life of an SET。“The Life of 注：本节标题“SET的工作”，因为原

    段，通常都没有专职的测试人员(译

    在任何软件公司创立的初期阶

    2.1 SET的工作

    每日电子书

    绍了SET的出现背景)。

    Patrick Copeland在本书的序中已经介

    量意识于一身的角色，即SET(注：

    大，出现了第一个融合开发角色和质

    试的样子。随着Google的不断成长壮

    如何思考用户使用场景和设计单元测

    Google的早期创始人之一)在早期是

    也经常想象Larry和Sergey(译注：

    每位员工都独自完成所有工作。我们

    布工程师、系统管理员等其他角色。

    时候也没有产品经理、计划人员、发

    每日电子书

    “测试”的工程师来负责。

    责，而不仅仅单独由那些头衔上带着

    认为测试工作是由整个工程团队负

    Google其实就是这样设计的，Google

    甚至一些实际工作也会有所重叠。

    是紧密合作的伙伴，他们达成一致，在新产品的开发过程中，SET和SWE

    这对理解整个开发过程将十分有益。

    我们先来了解一下SET的工作背景，在详细讲解SET工作流程之前，2.1.1 开发和测试流程 每日电子书

    的需求)。

    创建版本等任务(前提是角色有这样

    成新代码的入库、提交、执行测试、地熟练，团队成员可以毫不费力地完

    色，对如何使用这些工具环境都非常

    Google所有的工程师无论是什么角

    支撑着Google的构建和发布流程。

    用统一的一套工具。这些工具和代码

    数代码存放在同一个代码库中，并使

    程、维护是日常工作重点。Google多

    布的代码。代码的组织形式、开发过

    工程师团队的交付物就是即将发

    每日电子书

    指 Googler称为的“业余项目”。这并

    贡献”(译注：“百分之二十时间”是

    开始的第一天起，其“百分之二十的

    代码库模式让工程师从他们进入项目

    工程师提供了很大便利，这种单一的

    换而几乎不需要什么学习成本。这为

    程师可以很从容地在不同项目之间转

    这种单一的代码库模式，使得工

    过程、维护是日常的工作重点。

    发布的代码。代码的组织形式、开发

    工程师团队的交付物就是即将要

    注意

    每日电子书

    中，许多Goolers选择把“百分之二十

    是“百分之二十”项目的结晶。在现实

    目。实际上，本书提及的许多工具都

    们三个都参与过“百分之二十时间”项

    实经历，这个概念是真正存在的，我

    个想法只是一个传说。根据我们的真

    全强制的，之前有些 Googler 认为这

    下一天用以试验和创新。这并不是完

    上。每周四天工作用来赚取薪水，剩

    一天时间在他的日常工作之外的项目

    存在的，允许所有 Googler每周投入

    不是一个炒作的概念，而是官方真正

    每日电子书

    Google在代码库搜索方面也提供了非

    甚至是重用一些程序控制结构。

    用一些通用模块或详细的数据结构，似场景下如何编写代码，他们可以重

    们从有经验的工程师那里学习到在类

    以简化他们工作的浏览器端代码。他

    无须申请任何权限，就能查看所有可

    们都是开放的。Web 应用的开发人员

    有需求的工程师，所有的源代码对他

    作模式)极具效率。这也意味着对于

    些听起来很酷的产品，很享受这种工

    时间”投入到新产品之中，特别是一 每日电子书

    丰富的Google内部共享代码库与公共

    具、公司范围内的资源共享，成就了

    公开的代码库、和谐的工程工

    注意

    大作用。

    项目完成与减少项目失败上发挥了很

    Google的基础设施产品，它们在加速

    服务。这些共享的代码运行依赖于

    丰富的Google内部共享代码库与公共

    具、公司范围内的资源共享，成就了

    公开的代码库、和谐的工程工

    常便利的功能。 每日电子书

    有良好的可读性。代码必须存储在代

    虑的是能否可以容易地被找到，并具

    对于公共的共享代码，首先要考

    有很好的理由。

    的公共库，除非在项目特定需求方面

    所有的工程师必须复用已经存在

    规则。

    护修改这些代码的时候都要遵守这些

    却非常重要的实践规则，工程师在维

    做了特殊处理，形成了一套不成文但

    工程师们对这些共享的基础代码

    服务。 每日电子书

    忽视。如果一个项目依赖一些公用共

    所有依赖必须明确指出，不可被

    大。

    巧妙性相比，可复用性带来的价值更

    高的信誉。与功能的复杂性或设计的

    务被许多团队使用，这将为他带来很

    相对独立。如果一个工程师提供的服

    公共代码必须尽可能地被复用且

    考虑到未来会被其他人阅读或修改。

    代码应该容易理解。所有的代码都要

    享代码会被不同的工程师使用，这些

    码库的共享区域，以便查找。由于共 每日电子书

    工程师正面的影响，就可以送出“同

    bonus)”。任何工程师如果受到其他

    Google经常提及的“同僚奖金(peer 工作是值得鼓励的(译注：这是

    新的代码库上。这种乐善好施的社区

    个公用代码库之上的应用项目迁移到

    去重构已有的代码，并协助依赖在这

    某些地方有更好的解决方案，他需要

    如果一个工程师对共享代码库在

    的。

    下，这些共享代码是不允许被修改

    享代码，在项目工程师不知情的前提 每日电子书

    可读性”的证书。Google的四大主要

    员会会授予这名开发人员一个“良好

    风格编写出干净代码的记录之后，委

    读性审核。在开发人员拥有按照代码

    核。开发人员必须通过相关语言的可

    是公共通用模块的代码必须经过审

    Google非常重视代码审核，特别

    外还有同事之间私下里的感谢)。

    种良性循环，并持续下去。当然，另

    目的就是让这种正向团队合作形成一

    还有权使用其他奖励手段。这样做的

    僚奖金”作为感谢。除此之外，经理 每日电子书

    也十分谨慎，这样开发人员在自己工

    依赖，Google对Linux发行版本的管理

    作系统保持一致。为了减少对平台的

    统都尽可能地与Google生产环境的操

    师都有一台桌面工作机器，且操作系

    最小化对平台的依赖。所有工程

    论)。

    有更高的要求(在后面部分会做讨

    在共享代码库里的代码，对测试

    格指南。

    JavaScript都有可读性方面的代码风

    开发语言：C++、Java、Python和

    每日电子书

    强制要求使用公共的底层库。维护

    所有对平台有依赖的代码，都会

    现。

    和生产环境的机器上也都应该能够复

    测试机器上出现，那么在开发机器上

    须在手边进行测试)如果一个bug在

    Chrome OS。这些类目不同的硬件必

    里的本地测试实验室，是Android和

    (注：唯一不在Google通用测试平台

    据中心，CPU和OS的变化尽可能小

    的测试结果会保持一致。从桌面到数

    作机器上测试的结果，与生产系统里

    每日电子书

    持简单，也就相对会安全。

    人员的重心转移到新功能开发上。保

    境相关且难以调试的问题，能把开发

    游的测试工作，也可以避免许多与环

    处，但限制运行环境可以节省大量下

    这样做本身其实并没有什么神奇之

    Linux发行版本都会有持续的测试。

    编译器被很好地维护着，针对不同的

    言，都要求使用统一的编译器，这个

    点，对于 Google 使用的每个编程语

    这个底层平台相关的公共库。还有一

    Linux 发行版本的团队同时也在维护

    每日电子书

    码库，持续不断地在构建系统中打包

    使用统一的运行平台和相同的代

    护表示尊重且有激励。

    包规范；文化上对这些共享资源的维

    有一个编译器；与语言无关的通用打

    建和测试基础设施；每个核心语言只

    用核心库；一套统一的通用代码、构

    Linux发行版本；一套集中控制的通

    机和生产环境的机器都保持统一的

    标，就是保持简单且统一。开发工作

    Google 在平台方面有特定的目

    注意

    每日电子书

    构建目标，这个构建目标(可以是公

    一个版本在构建的时候需要指定

    件。

    样的“构建文件”来打包生成二进制文

    Python或Java也都无关。大家使用同

    程语言无关，与团队是否使用C++、规范，这个打包规范与项目特定的编

    工作。构建系统要求使用统一的打包

    里面)，这可以简化共享代码的维护

    进制文件统一封装在一个linux rpm包

    代码编译成二进制文件，然后再把二

    (译注：打包是一个过程，包括将源

    每日电子书

    赖通过 mock 模拟实现。对于需要关

    写一套单元测试用例，把外部重要依

    (3)通过调用这个库的方式编

    设定为公共库。

    (2)把这个新服务的构建目标

    通过。

    功能函数，并保证所有代码可以编译

    多个源代码文件中编写一类或一系列

    (1)针对某个服务，在一个或

    流程。

    多源文件编译链接产生。下面是整体

    共库、二进制文件或测试套件)由许 每日电子书

    (7)提交代码申请代码审核

    测。

    通过一系列常见问题的静态扫描检

    工具，确保遵守统一的代码风格，且

    (6)按要求运行静态代码分析

    运行成功。

    适当的修改调整，直到所有的测试都

    (5)构建并运行测试目标，做

    构建目标。

    (4)为单元测试创建一个测试

    数来验证。

    注的代码路径，使用最常见的输入参 每日电子书

    骤(2)之前进行。

    意味着步骤(3)会在步骤(1)和步

    人员使用“测试驱动开发”的模式，这

    满足需求。注意：在Google许多开发

    建目标用以验证新发布的公共库是否

    目标是需要新发布的公共库、测试构

    库构建目标和测试构建目标。库构建

    产出将是两个配套的构建目标：

    过。

    后运行所有的单元测试并保证顺利通

    明)，根据反馈再做适当的修改，然

    (后面对代码审核会做更多详细说 每日电子书

    的服务)、一套覆盖所有重要构建目

    另外一套支持库，可以用来创建其他

    的公共服务库(这个服务库中还包含

    一个在可读性与可复用性方面都不错

    组成：一个经过良好测试的独立库、完成了一个Google产品，它由三部分

    和服务库链接在一起构成。现在，你

    目标，其由包含主入口main函数文件

    成。在这个时候，会产生二进制构建

    逐渐变大，直到整个服务全部构建完

    编译持续新增的代码，构建目标也会

    对于规模更大的服务，通过链接 每日电子书

    需要开发的特定库上。为了不耽搁服

    赖在协商好的接口上，而不是依赖在

    早期就确定下来。这样，开发者会依

    开发，服务之间的接口需要在项目的

    成。为了保证单独的服务可以并行地

    会在一个最终的构建目标里一起集

    试，一旦所有的服务都完成了，他们

    个服务都可以并行地构建、打包和测

    SWE负责对应一个服务。这意味着每

    务组成，所有产品团队都希望一个

    一个典型的Google产品由许多服

    标的单元测试套件。

    每日电子书

    这个项目的SET都会给予帮助)。当

    的小型测试(由SWE编写，所有支持

    的库构建目标中，需要运行几乎所有

    些更大规模的集成测试。在一个单独

    SET需要加速他们的工作，开始做一

    成规模更大应用程序的构建目标时，试。在多个构建目标集成在一起，形

    建之中，并指出哪些地方需要小型测

    SET 会参与到许多测试目标的构

    假的实现。

    般都不会真正实现，而只是做一个虚

    务级别之间的早期测试，这些接口一

    每日电子书

    保证新增的功能不会把已有功能损坏

    bug，一定要得到修复。这样才可以

    一部分，问题较多的测试就是功能性

    bug没有任何区别。测试就是功能的

    个针对测试用例的bug和针对功能的

    败，也会报一个测试用例的 bug。这

    例，本应该运行通过，但如果运行失

    回归测试的一部分。如果一个测试用

    时，针对功能集成的小型测试会成为

    在构建目标的增长到一定规模

    到中大型测试的编写之中去。

    构建目标日益增大时，SET也会参与

    每日电子书

    SET首先是工程师角色，他使得

    2.1.2 SET究竟是谁

    作的时候了。

    测试。好了，现在是展开讨论SET工

    fake工具。他们甚至编写中大型集成

    明确指出。他们同时编写许多mock和

    道哪些地方需要单元测试的时候可以

    是核心参与者。他们在开发人员不知

    在所有的这些活动中，SET 始终

    本身的失败。

    掉，任何代码的修改都不会导致测试

    每日电子书

    开发工程师和测试的开发工程师处于

    和代码开发的方式。这会使得功能的

    试计划”的方式，而是通过参与设计

    中去，但不是通过“质量模型”和“测

    它使测试人员能尽早介入到开发流程

    角色。这种测试方式的有趣之处在于

    中所说的那样，是一个100%的编码

    如我们招聘宣传海报和内部晋升体系

    重要的一点，SET是软件工程师，正

    in test)是软件测试开发工程师。最

    发过程之中。SET(software engineer 测试存活于先前讨论的所有Google开

    每日电子书

    一种功能特性，而 SET 是这个产品

    能更公平一些，测试也是应用产品的

    是也是我们的设计目标)。这样讲可

    (实际上，让他们物理位置坐在一起

    SET 与功能开发人员坐在一起 能，而SET就是这个功能的负责人。

    测试是应用产品的另外一种功

    注意

    其他工程师负责。

    和探索式测试，而这些测试后期会由

    试，使测试富有效率，包括手动测试

    相同的地位，SET 积极参与各种测 每日电子书

    Google，SET的数量也相对比较少，此条件的人是非常困难的，在

    正如你想象的那样，找到满足如

    问题。

    码问题，而且SET还要求去解答测试

    换句话说，SWE和SET都需要回答代

    要了解如何去测试他们编写的代码。

    而且增加了一个额外考核——SET需

    标准上与SWE的招聘要求是一样的，在面试SET的时候，在代码要求

    代码评审，反之亦然。

    功能特性的负责人。SET参与SWE的

    每日电子书

    我们这些最优秀的工程师一起构成了

    SET学习，SET也在学习SWE，正是

    两大群体之间相互交流学习，SWE向

    做到这一点，或许永远也做不到。这

    可以写代码。Google其实还没有完全

    的开发人员可以做测试，而测试人员

    求也类似。假想这样的场景，公司里

    较相似，在招聘方面这两个群体的要

    在太难了。SWE和SET这两个角色比

    因为招聘到满足SET技能要求的人实

    有什么神奇的开发测试比要求，而是

    这并不是因为 Google 在生产率方面

    每日电子书

    测试成员的业余时间。事实上也正如

    源的投入，这些资源来源于团队开发

    来，初期也并没有任何Google官方资

    Chrome OS也是从一个想法演变而

    只会投入20%的时间。Gmail和

    Google的产品项目初期阶段，工程师

    是“真正”的项目。通常情况下，在

    目，同样也没有规定怎样的项目才算

    Google没有规定SET何时进入项

    2.1.3 项目的早期阶段

    我们最有效率的工程产品团队。

    每日电子书

    构建测试方面基础设施，这是一种资

    来可能失败的项目中投入测试资源来

    期，没有一个会得到测试资源。在未

    Google的官方产品。在这些产品的初

    模会越做越大，有的甚至会成为

    品有些慢慢地消失了，而另外一些规

    20%的业余时间。这些时间投入的产

    许多创新的产品都是来源于团队

    变的重要的时候质量才显得重要”。

    分)所说的那样，“只有在软件产品

    言的作者之一，详细介绍参见序部

    我们的朋友Alberto Savoia(本书的序 每日电子书

    当然，物极必反，风险总是相对

    事情。

    初期阶段强调测试是一件非常愚蠢的

    留的概率几乎为零。很明显，在试验

    时，还要经历重新设计，原始代码保

    在其以后的dogfood或beta版本发布

    Google百分之二十努力的产品原型，优先级混乱的表现。许多来源于

    全确定成型时就去关心质量，这就是

    一个产品如果在概念上还没有完

    些创建好的测试也会毫无价值。

    源浪费。如果项目被取消了，那么这 每日电子书

    试，当然也不是说早期产品的质量就

    作，而是去做开发。绝非有意忽视测

    早期参与进来，也不是从事测试工

    测试介入进来。实际上，即使SET在

    在项目早期，Google一般不会让

    慢产品的发布，甚至长达数年之久。

    名义来做重构。这样的质量“债”会拖

    定。在这种情况下，不得不以质量的

    致自动化难以实施且测试工具极不稳

    计在后期也很难去做改进，这样会导

    的介入，早期在可测试性上的槽糕设

    的。如果一个产品太长时间没有测试

    每日电子书

    伪件(fake)，这样他们可以拿着浏

    员做了原型，且多数实现都是脚本与

    我们正式加入之前，只有几个开发人

    个产品上工作过一年以上。但是，在

    的典型例子。本书的三个作者都在这

    Chrome OS是一个可以说明问题

    的诞生从来没有如此正式过。

    让一大群开发参与进来。Google项目

    划(包括质量与测试计划)，然后再

    项目创建初期就投入一大帮人来做计

    动产品的流程所约束。Google很少在

    不重要。这是受Google非正式创新驱

    每日电子书

    Google内部其实也并存着不同的

    程生产力团队，寻求测试资源。

    式批准立项，其开发总监就会找到工

    而使用脚本搭建的产品，一旦得到正

    其实没有太大的实用价值。为了演示

    投入大量测试和可测试性方面努力，会被 C++代码重写替换，如果在早期

    正式批准，且所有的演示脚本最终都

    想法的可行性上。考虑到项目还没有

    要精力都集中在如何试验并证明这些

    立项批准。在这些早期原型阶段，主

    览器应用模型做演示，并通过正式的 每日电子书

    进来，而项目一旦真正立项，我们就

    概念阶段的时候，测试人员不会参与

    过程中各自承担的责任。在项目还是

    元测试覆盖率水平、以及明确在发布

    提供当前已有的测试状态、期望的单

    目、进度和发布计划时，我们也要求

    OS的开发总监给我们介绍他们项

    人兴奋且并充满希望的。在Chrome 义务让测试人员相信他们的产品是令

    开发团队在寻求测试帮助的时候，有

    试资源，他们的产品就将不复存在。

    文化。没有项目会认为如果得不到测

    每日电子书

    分代码之中，通常这部分代码只是某

    SWE会深入他们自己编写的那部

    2.1.4 团队结构

    兴奋且并充满希望的。

    务让测试人员相信他们的产品是令人

    发团队在寻求测试帮助的时候，有义

    资源，他们的产品就将不复存在。开

    没有项目会认为如果得不到测试

    注意

    我们的影响力。

    要在这些测试是如何执行的方面发挥

    每日电子书

    像 Gmail 或 Chrome 这样的产品

    多。

    期比SWE待在产品里的时间要长久得

    穿梭于不同产品，但产品的生命存活

    功能特性做充分理解，许多SWE来往

    且在产品的整个生命周期里对产品及

    仅要具有更宽广的整体产品视野，而

    个好的SET正好可以弥补这一点，不

    角度来看，视野会显得略微狭窄。一

    提供最优方案，但如果从整个产品的

    码。SWE一般仅在自己的模块领域里

    个单一功能的模块甚至更小范围的代 每日电子书

    难说清楚什么时候项目结束或一个项

    改进而做的重构在不断地发生，你很

    实现、版本的发布、补丁的创建、为

    在整个项目生命周期里，功能的

    出色的SET在为之工作。

    这些现象都在说明这个产品早期已有

    自动化测试、清晰的代码提交流程，档、不错的可测试性、运行着稳定的

    加入，这时这个产品已经有良好的文

    SWE在某个产品的第三个版本研发时

    计的开发人员为之工作。如果一个

    注定要经历许多版本，并消耗数以百 每日电子书

    这个计划是值得花费更多精力去做

    做少量的计划，而到项目后期却发现

    来产品的信心。我们不想在项目初期

    文档，这部分工作量取决于我们对未

    我们在编码之前做计划、试验、期看来也是正确的。

    我们尝试去保证我们早期做的决定长

    尝试去文档化我们将要去做的事情。

    做计划，并尝试把东西做出来。我们

    段，我们常去改变我们的目标。我们

    目都有明确的开始时间。在早期阶

    目是否真的已经结束。但所有软件项

    每日电子书

    负责人这个非正式的岗位一般由工程

    的项目发起人组成。在Google，技术

    术负责人(tech lead)和一个或更多

    Google 产品团队最初是由一个技

    的工程师来做最终决定。

    多少和怎样做比较合适，由创建项目 ......