Google软件测试之道惠特克 pdf下载

编辑推荐

　　软件测试泰斗传道解惑，Google软件测试精髓完美呈现。
　　淘宝测试技术专家翻译，测试界知名专家鼎力推荐。

内容简介

　　《Google软件测试之道》从内部视角告诉你这个世界上知名的互联网公司是如何应对□1世纪软件测试的独特挑战的。《Google软件测试之道》抓住了Google做测试的本质，抓住了Google测试这个时代复杂软件的精华。《Google软件测试之道》描述了测试解决方案，揭示了测试架构是如何设计、实现和运行的，介绍了软件测试工程师的角色；讲解了技术测试人员应该具有的技术技能；阐述了测试工程师在产品生命周期中的职责；讲述了测试管理及在Google的测试历史或在主要产品上发挥了重要作用的工程师的访谈，这对那些试图建立类似Google的测试流程或团队的人受益很大。
　　□后，《Google软件测试之道》还介绍了作者对于Google测试如何继续演进的见解、Google乃至整个业界的测试方向的一些预言，相信很多读者都会感受到其中的洞察力，甚至感到震惊。本书可以作为任何从事软件测试人员到达目标的指南。
　　《Google软件测试之道》适合开发人员、测试人员、测试管理人员使用，也适合大中专院校相关专业师生的学习用书，以及培训学校的教材。

前言序言

　　毫无疑问，在当前这个时代，处于浪潮之巅的伟大公司非Google莫属。很长一段时间以来，Google的技术一直被外界所觊觎，其所宣扬的工程师文化氛围也成为了许多工程师梦寐以求的技术殿堂，其内部的工程实践更是技术分享大会中□热门的话题之一。但迄今为止，没有一本书系统地介绍Google内部产品的研发流程与模式，包括开发、测试、发布、团队成员如何分工协作等细节，直到《How Googleests Software））的出现，才使得我们有机会管中窥豹，了解Google技术神秘之处。这也是我们翻译这本书的□□个原因。
　　正如本书中所提及的那样，互联网的出现改□了许多软件研发的模式。许多曾经红极一时的传统测试书籍里提及的□佳测试实践，在当前的环境下，效率会大大下降，在一些极端的情况下甚至会适得其反。我自己就是一名测试工程师，从事互联网方面的测试工作，对此深有体会，也经常焦虑如何在制约质量和快速发布之间寻找平衡，所以，也特别想从一些主流互联网公司的测试模式中得到启发和借鉴，特别是想看一下这个□□□□成功、增长速度□快的互联网公司——oogle，是如何应对互联网测试挑战的。通过翻译这本书，自己学到了更多感兴趣的知识。这也是我们翻译这本书的第二个原因。
　　JamesWhittaker在正式撰写本书英文版之前，于□011年1月在GoogleestingBlog上尝试发表了towGoogle．1estSoftware”系列文章。当看到□□篇时我就被深深地吸引住了，□□感觉就是，太棒了！Google测试团队居然是这样组织的！之后，随着这个系列文章的逐一公开，Google也逐渐揭开了其神秘面纱，让我对其测试实践也有了越来越多的了解，但了解的越多，疑惑也就越多。不得不承认，这几篇文章就像正餐前的开胃小菜，它完全勾起了大家的食欲，仅仅依赖这几篇文章完全不能满足窥探Google测试体系的需求。在□011年11月的G．TALCGoogleest Automation C0nference）大会上，我见到了James本人，便聊起了《Htow Goog leest Software》这本书，James一听到又有人在打探这本书的下落，乐呵得嘴都合不拢了，却卖起了关子来，只是说书快出版了。大约在□01□年9月，这本书的英文版终于问世之后，突然接到李中杰（本书的合译者之一）的电话，问我为什么不去翻译一下这本书呢。之前虽然是兴趣使然，做过那几篇文章的翻译，但与翻译一本书相比，还是有些微不足道的。但几经转辗，还是机缘巧合地去做了这件事情，这也是翻译这本书的第三个原因吧。
　　□后要说的，也是□重要的一个原因。我原本根本没有这么大的勇气来完成这件事情。众所周知，James不仅是测试领域的泰山北斗，而且他颇具文学功底，语言诙谐幽默，妙笔生花，翻译他的书籍，让我诚惶诚恐，以至于焦虑得昼夜不安。但两位合译者，李中杰博士和薛明，他们的乐观与自信让本书的翻译得以完成。与他们两位的合作，幸福之感难以言表，所收获的也不仅仅是长知识那么简单，更有许多惊喜深藏内心。翻译别人的书，像是在反刍，再精彩也是在讲别人的故事，还是期待有朝一日，能够也有机会讲讲自己的故事。
　　□后祝愿国内的读者能够从这本书中有所借鉴，找到适合自己现状的开发测试模式。由于译者水平有限，错漏之处在所难免，若有欠妥之处，欢迎指正。

目录

□□章 Google软件测试介绍
1.1 质量不等于测试
1.□ 角色
1.□.1 软件开发工程师（SWE）
1.□.□ 软件测试开发工程师（SET）
1.□.3 测试工程师（TE）
1.3 组织结构
1.4 爬、走、跑
1.5 测试类型

第□章 软件测试开发工程师
□.1 SET的工作
□.1.1 开发和测试流程
□.1.□ SET究竟是谁
□.1.3 项目的早期阶段
□.1.4 团队结构
□.1.5 设计文档
□.1.6 接口与协议
□.1.7 自动化计划
□.1.8 可测试性
□.1.9 SET的工作流程：一个实例
□.1.10 测试执行
□.1.11 测试大小的定义
□.1.1□ 测试规模在共享测试平台中的使用
□.1.13 测试规模的益处
□.1.14 测试运行要求
□.□ 测试认证
□.3 SET的招聘
□.4 与工具开发工程师Ted Mao的访谈
□.5 与Web Driver的创建者Simon Stewart的对话

第3章 测试工程师
3.1 一种面向用户的测试角色
3.□ 测试工程师的工作
3.□.1 测试计划
3.□.□ 风险
3.□.3 测试用例的生命周期
3.□.4 bug的生命周期
3.□.5 TE的招聘
3.□.6 Google的测试领导和管理工作
3.□.7 维护模式的测试（Maintenance Mode Testing）
3.□.8 质量机器人（Quality Bot）实验
3.□.9 BITE实验
3.□.10 Google Test Analytic□<□r />3.□.11 零成本测试流程
3.□.1□ 外部供应商
3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈
3.4 与YouTube测试工程师安普·周（Apple Chow）的访谈

第4章 测试工程经理
4.1 测试工程经理的工作
4.□ 获得项目和人员
4.3 影响力
4.4 Gmail测试工程经理Ankit Mehta的访谈
4.5 Android测试工程经理Hung Dang的访谈
4.6 Chrome测试工程经理Joel Hynoski的访谈
4.7 测试总监
4.8 搜索和地理信息测试总监Shelton Mar的访谈
4.9 工程工具总监Ashish Kumar的访谈
4.10 印度Google测试总监SujaySahni访谈
4.11 工程经理Brad Green访谈
4.1□ James Whittaker访谈

第5章 Google软件测试改进
5.1 Google流程中的致命缺陷
5.□ SET的未来
5.3 TE的未来
5.4 测试总监和经理的未来
5.5 未来的测试基础设施
5.6 结论

附录A Chrome OS测试计划
A.1 测试主题概述
A.□ 风险分析
A.3 每次构建版本的基线测试
A.4 □新可测试版本（Last Known Good，LKG）的每日测试
A.5 发布版本测试
A.6 手工测试与自动化测试
A.7 开发和测试的质量关注点
A.8 发布通道
A.9 用户输入
A.10 测试用例库
A.11 测试仪表盘
A.1□ 虚拟化
A.13 性能
A.14 压力、长时运行和稳定性测试
A.15 测试执行框架（Autotest）
A.16 OEM厂商
A.17 硬件实验田
A.18 端到端测试自动化集群
A.19 测试浏览器的应用管理器
A.□0 浏览器的可测试性
A.□1 硬件
A.□□ 时间线
A.□3 主要的测试驱动力
A.□4 相关文档

附录B Chrome的漫游测试
B.1 购物漫游
B.□ 学生漫游
B.3 国际长途电话漫游
B.4 地标漫游
B.5 通宵漫游
B.6 公务漫游测试
B.7 危险地带漫游
B.8 个性化漫游

附录C 有关工具和代码的博客文章
C.1 使用BITE从bug和冗余的工作中解脱出来
C.□ 发布QualityBot
C.3 RPF：Google的录制回放框架
C.4 Google测试分析系统（Google Test Analytics）——现在开源了
附录D 术语表

精彩书摘

　　□□章  Google软件测试介绍
　　在许多场合下，不管是在国外访问还是出席会议期间，我总是毫无例外地被问及一个问题。甚至是刚刚加入公司的新员工也会问到同样的问题：“Google是如何测试的？”
　　虽然我已经不太确定曾经多少次回答过这个问题，以及给出了多少个不同版本的答案，但可以确定的是，随着我在Google工作的时间越来越长，发现Google的各种测试实践的不同之处也越来越多，答案也一直在□化。这些测试实践总是浮现在脑海里，并幻想着有朝一日能够将它们整理成书。直到有一天，Alberto（译注：Albert0Savoia，（~oogle的测试总监，详细介绍参见本书序言中的A1berto部分），这个一贯认为所有测试相关的书籍都要为自己的存在找一个理由，否则就应该被扔掉做成纸尿裤的人，当他建议我应该写这样一本书的时候，我觉得时机已经成熟，是时候开始考虑写这样一本书了。
　　然而，我依旧还在等待。□□，我并非是写这样一本书的□佳人选。在Google，有很多我的前辈，我想先把机会让给他们宋写；第二，我只是Chrome和ChromeOS产品的测试总监（现在这个职位被我之前的一个下属担任着），我看到的也只是Google所有测试实践中很小的一部分，我还需要去了解很多其他Google产品的测试方法。
　　在Google，软件测试团队归属于一个被称为“工程生产力”（译注：EngineeringProductivity，也译为工程效率或工程生产率）的中心组织部门，这个部门的职责横跨开发测试人员使用工具的研发、产品发布和各种级别的测试，从单元级别的测试到探索性级别的测试。Google拥有大量针对互联网产品的共享工具与测试基础框架，服务于包括搜索、广告、Apps、YouT‘ube□□和其他我们在Web上提供的产品。Google已经成功解决了许多有关速度和扩展性方面的问题，使得Google作为一个大公司，却依然能以创业公司的速度来发布产品。正如Patrick（30peland在本书的序言中所说的那样，拥有如此的魔力，Google的测试团队功不可没。
　　ChromeOS在□010年1□月发布以后，我把团队顺利地交接给我的一个直接汇报者，然后开始把自己的工作重点慢慢转移到其他产品上。在这本书刚开始准备的阶段，我使用博客的方式做了一些尝试，发布了□□篇“Google是如何测试的”的系列文章（注：参见hup：／／googletesting．blogspot．com／□0〕I／01／how。google—tests．soffware．html）。6个月之后，本书终于完成，希望没有拖太长的时间。在这六个月的时间里，我了解到的Google测试实践比我过去两年在。Google学到的都要多。现在有了这本书，Google的新员工们也可以通过阅读此书来熟悉Google的环境。
　　这并不是□□本介绍关于大公司是如何做测试的书籍．当我还在Microsoft的时候，AlanPage．BTRollison和Ken．Johnston合著了《微软的软件测试之道》（译注：I-lowWe．TestSoftwareatMicrosoft），我当时亲身经历了他们书中写的许多事情。Microson在测试领域独步全球，也是一个测试精英云集的圣地。Microsoft的测试工程师在各种技术大会中也是广受欢迎的演讲嘉宾。Microsoft的第…任测试总监一一RogerSherman，吸引了来自全球的测试精英加入华盛顿的雷德蒙德（译注：微软总部所在地）。那是一个软件测试的黄金时代。
　　因此，Microsoft写了这样一本书来记录其发生的一切。
　　我没能赶上参与《微软的软件测试之道》的编写，但是在300gle却有幸得到这样的机会。我来Google的时候，其测试正处于一个蓬勃发展的上升期。工程生产力团队的员工数量正以火箭喷发般的速度增长，从几百人迅猛发展到今天的1．□00人。正如Patrick在本书序言中所说的那样，这种增速随之而宋的是成长的烦恼，这也是他们□后的阵痛，此后这个组织开始了□□□□的井喷式增长。Google的测试博客每月吸引了成千上万的人来浏览阅读，GI’AC（注：G．I‘AC：是GoogleTestAutomationConference的缩写，即Google测试自动化大会，参见大会也已经成了测试行业的旗帜性会议。在我来到Google不久之后，Patrick也得到了晋升，手下有十几个总监和工程经理直接汇报给他。如果你认为软件测试又进入到新的文艺复兴时期，那么Google一定就是位于中心的罗马。
　　这意味着Google背后的测试故事其实可以写成一本很厚的书。但问题是，我并不想这样做。Google之所以闻名于世，在于其实现软件的方法：简单和直截了当。或许这本书也可以保持这样的风格。
　　（（Google软件测试之道》这本书的核心内容包括：详细讲述了作为一个Google的测试人员究竟意味着什么，同时也包含Google是如何解决软件在扩展性、复杂性和大并发方面的问题。如果想知道这些，阅读本书将是你的□佳获取途径。如果书中的内容还是不能满足你想要充分了解GOOgle是如何测试的需求，互联网上还有更多的信息，你只需要“GOOle一下”。
　　关于本书由来的故事，不得不说的大概就是这些了。我也终于做好了准备来讲述GOogle是如何进行测试的。随着越来越多的软件公司从桌面应用转向网络应用，G00gle测试软件的方法也很有可能成为其他公司的榜样。如果你已经读了《微软测试之道》，那么千万不要试图在这本书中找一些共同点。除了两本书的作者都是三个人，且都是在讲述大型软件公司的测试实践之外，这两本书中所描述的测试方法可谓大相径庭。
　　PatickCOpeland在本书的序言中解释了G00gle测试方法演□的历史，随着公司的不断成长，它也在不停地、有组织地进化着。G00gle是个大熔炉，许多来自其他公司的工程师被抛进来熔炼。在前雇主公司使用的技术，如果被证明效率低下，该技术要么被遗弃，要么通过G00gle的创新文化再进行改良。随着测试工程师队伍的不断膨胀，就有了许多新的想法和实践的尝试，那些在实践中被证明很有用的技术会被GOogle保留下来，并成为GOOgle的一部分；另外一些被证明是负担的，则会被抛弃掉。G00gle的测试者很愿意去尝试新技术，但有些技术一旦被发现并不实用，就会立刻被抛弃。
　　G00gle是一家以创新和速度为基础的公司，快速地发布有用的代码（如果失败，也只有少数早期用户会失望）、迭代地增加早期用户希望使用的功能（□大化用户反馈）。在这样的环境下，测试不得不□的异常灵活，并且在技能上要做许多前期的规划，只是不停地简单维护并不能真正解决问题。有时，测试和开发互相交织在一起，达到了无法区分彼此的程度，而在另外一些时候，测试和开发又是完全分离，甚至开发人员都不知道测试在做些什么。
　　……

作者简介

　　惠特克（JamesWhittaker），Google的工程总监，负责Google部分产品的测试，包括Chrome、地图、GoogleWebApp。在加盟Google之前，James在Microsoft工作，再之前是一名大学教授。James在全球测试领域闻名遐迩。

　　阿尔邦（JasonArbon），Google的一名测试工程师（TE），曾参与负责Google桌面、Chrome和ChromeOS的测试。同时，Jason也是一系列开源测试工具和个性化实验的开发负责人。在加入Google之前，他在Microsoft工作。

　　卡罗洛（JeffCarollo），Google的一名测试开发工程师（SET），曾参与负责GoogleVoice、工具框、Chrome、ChromeOS产品的测试。Jeff为许多Google内部的开发团队提供咨询服务，帮助提升这些团队初期的代码质量。在□010年，Jeff转岗为软件开发工程师（SE），并领导负责Google+API的开发。在加入Google之前，Jeff在Microsoft工作。