【译 者 序】
毫无疑问，在当前这个时代，处于浪潮之巅的伟大公司非Google莫属。很长一段时间以来，Google的技术一直被外界所觊觎，其所宣扬的工程师文化氛围也成为了许多工程师梦寐以求的技术殿堂，其内部的工程实践更是技术分享大会中最热门的话题之一。但迄今为止，没有一本书系统地介绍Google内部产品的研发流程与模式，包括开发、测试、发布、团队成员如何分工协作等细节，直到《How Google Tests Software》的出现，才使得我们有机会管中窥豹，了解Google技术神秘之处。这也是我们翻译这本书的第一个原因。
正如本书中所提及的那样，互联网的出现改变了许多软件研发的模式。许多曾经红极一时的传统测试书籍里提及的最佳测试实践，在当前的环境下，效率会大大下降，在一些极端的情况下甚至会适得其反。我自己就是一名测试工程师，从事互联网方面的测试工作，对此深有体会，也经常焦虑如何在制约质量和快速发布之间寻找平衡，所以，也特别想从一些主流互联网公司的测试模式中得到启发和借鉴，特别是想看一下这个世界上最成功、增长速度最快的互联网公司--Google，是如何应对互联网测试挑战的。通过翻译这本书，自己学到了更多感兴趣的知识。这也是我们翻译这本书的第二个原因。
James Whittaker在正式撰写本书英文版之前，于2011年1月在Google Testing Blog上尝试发表了"How Google Test Software"系列文章。当看到第一篇时我就被深深地吸引住了，第一感觉就是，太棒了！Google测试团队居然是这样组织的！之后，随着这个系列文章的逐一公开，Google也逐渐揭开了其神秘面纱，让我对其测试实践也有了越来越多的了解，但了解的越多，疑惑也就越多。不得不承认，这几篇文章就像正餐前的开胃小菜，它完全勾起了大家的食欲，仅仅依赖这几篇文章完全不能满足窥探Google测试体系的需求。在2011年11月的GTAC（Google Test Automation Conference）大会上，我见到了James本人，便聊起了《How Google Test Software》这本书，James一听到又有人在打探这本书的下落，乐呵得嘴都合不拢了，却卖起了关子来，只是说书快出版了。大约在2012年9月，这本书的英文版终于问世之后，突然接到李中杰（本书的合译者之一）的电话，问我为什么不去翻译一下这本书呢。之前虽然是兴趣使然，做过那几篇文章的翻译，但与翻译一本书相比，还是有些微不足道的。但几经转辗，还是机缘巧合地去做了这件事情，这也是翻译这本书的第三个原因吧。
最后要说的，也是最重要的一个原因。我原本根本没有这么大的勇气来完成这件事情。众所周知，James不仅是测试领域的泰山北斗，而且他颇具文学功底，语言诙谐幽默，妙笔生花，翻译他的书籍，让我诚惶诚恐，以至于焦虑得昼夜不安。但两位合译者，李中杰博士和薛明，他们的乐观与自信让本书的翻译得以完成。与他们两位的合作，幸福之感难以言表，所收获的也不仅仅是长知识那么简单，更有许多惊喜深藏内心。翻译别人的书，像是在反刍，再精彩也是在讲别人的故事，还是期待有朝一日，能够也有机会讲讲自己的故事。
最后祝愿国内的读者能够从这本书中有所借鉴，找到适合自己现状的开发测试模式。由于译者水平有限，错漏之处在所难免，若有欠妥之处，欢迎指正。
【推荐者的话】
Alberto Savoia
谷歌工程总监
为一本你曾经想自己去撰写的书去做序，是一种尴尬的荣誉，这种感觉有点像你被邀请去为好友做伴郎，但新娘却是你曾经心爱的姑娘。但是James Whittaker却是一个聪明的家伙，在他问我是否愿意为这本书写序之前，先请我吃了一顿我非常喜欢的墨西哥晚餐，并让我喝了几杯墨西哥Dos Equis啤酒。当我还沉浸在牛油果酱带来的愉悦时，他终于提出了这个请求，在当时那种气氛下，我只能强作欢颜并答应了他："没有问题。"他的诡计"得逞"了，他和他的"新娘"--这本书，一起站在一边，而我却不得不在这里为他们的婚礼做致辞。
正如我说过的，他是一个聪明的家伙。
让我继续写这篇序吧，为这本我曾想自己写的书。
这个世界上真的还需要另外一本关于软件测试的书吗？特别是James Whittaker，这个高产的家伙，一个我曾经不止一次公开地称其为测试书籍出版界高产的"八胞胎妈妈"（译注：不知道"八胞胎妈妈（Octomom）"是什么意思？Google一下你就知道），还需要他的这么一本软件测试书吗？那种讲述陈旧得令人厌烦的测试方法学和宣扬一些可疑、过时的建议的书还少吗？是的，这样的书已经足够多了，但我认为这本书绝非如此。这也是我想自己去写它的原因，这个世界很需要这样一本独特的测试书。
互联网的出现急剧地改变了许多软件设计、开发和发布的方式。很多曾经红极一时的测试书籍里提及的最佳测试实践，在当前的环境下效率会大大下降，或者毫无效果，甚而在某些情况下会事与愿违地起反作用。在互联网和软件产业，一切变化都如此迅速，以至于许多最近几年才出版的软件测试方面的书籍都已陈腐过时，打个比方，它们就像讲述水蛭吸血和开颅驱赶恶鬼的外科手术书一样。对付这种书，最好的办法就是直接把它们扔掉，或者做些有益的事情，例如，循环再利用，做出纸尿裤来，以防止流落到容易上当受骗的人之手。
考虑到软件产业的发展速度如此之快，如果说十年后这本书也过气了，那一点儿也不奇怪。但在下次浪潮来临之前，这本书可以既适时又适用地从内部视角告诉你这个世界上最成功、增长速度最快的互联网公司之一，是如何应对21世纪软件测试的独特挑战的。James Whittaker和他的伙伴们，抓住了Google如何做测试的本质，抓住了Google如何测试我们这个时代最复杂和流行软件的精华。我之所以了解这些，是因为我从头到尾经历了这个伟大的转变。
我于2001年以工程总监的身份加入Google。当时，Google大概有200名开发人员，但只有区区3位测试人员！那个时候，开发人员已经开始做自己代码的测试了，但由于测试驱动开发的模式才刚刚开始，而且像JUnit这样的测试框架也没有大规模使用。当时的测试主要是在做一些随机测试（ad-hoc testing），其好坏取决于编写代码的开发者的责任心。但即使那样也是可以接受的，因为，当时正处在创业阶段，必须快速前进并勇于冒险，否则就无法和那个时代已经非常强大的对手竞争。
然而，当Google逐渐成长变大，Google的一些产品对于最终用户和客户来说开始变得至关重要（例如，竞价广告产品，我曾经负责的产品，很快变成许多网站的主要收入来源），我们清晰地认识到必须加大对测试的关注和投入。但只有3个测试工程师，别无选择，只能让开发来做更多的测试。与其他的几个Googler（译注：Google员工，本书中一般指Google工程师）一起，我们介绍、培训、推行单元测试，我们鼓励开发人员把测试作为优先级较高的事去做，并建议使用一些工具，如JUnit，把测试做成自动化的。但是进展缓慢，并非所有的人都接受、认同开发人员去做测试这件事情。为了继续保持这个势头，在每周五下午公司的啤酒狂欢时（译注：TGIF，Thank God It's Friday，Google在每周五下午举行全员聚会），我们为一些做测试的开发人员颁发奖品来激励大家。但这种感觉不是很好，有点像杂技训兽师在小狗完成某个动作后给一些奖励一样，但这样至少还是把大家的注意力吸引到测试上了。会如此幸运吗？如此简单就可以让开发做测试了？
很不幸的是这招根本不管用。开发人员发现，为了测试充分，他们不得不针对每一行功能代码，写两到三行的单元测试代码，而且这些测试代码和功能代码一样都需要维护，且有着相同的出错概率。而且大家也意识到，仅做单元测试是不够的，仍然需要集成测试、系统测试、用户界面等方面的测试。当真正开始要去做测试的时候，会发现测试工作量变得非常大（且需要很多知识的学习），并要求在很短的时间内完成测试，要以"迅雷不及掩耳"之势完成。
