How Google Tests Software

出版者:Addison-Wesley Professional

作者:James A. Whittaker

页数:320

出版时间:2012-4-2

价格:USD 37.99

装帧:Paperback

isbn号码:9780321803023

作者简介

james whittaker 是google的工程总监 ，负责部分google产品的测试，包括chrome、地图、google web apps。在加盟google之前，james在microsoft工作，再之前是一名大学教授。james在全球测试领域闻名遐迩。

jason arbon 是google的一名测试工程师te ，曾参与负责google桌面、chrome和chrome os的测试。同时jason也是一系列开源测试工具和个性化实验的开发负责人。在加入google之前，他也曾在microsoft工作过。

jeff carollo 是google的一名测试开发工程师set，曾参与负责google voice、工具框、chrome、chrome os产品 的测试。jeff为许多google内部的开发团队提供咨询服务，帮助提升这些团队初期的代码质量。之后在2010年，jeff转岗为软件开发工程师（se），并领导负责google+ apis的开发。在加入google之前，jeff也曾经在microsoft工作过。

读后感

过节、带娃的间隙，看完了《Google软件测试之道》。全书其实就在讲“融合”：面向开发的测试向开发端融合，面向用户的测试向用户端融合。这种“融合”，需要“快速，有效率和效果”的工具，方法论和组织结构来完成。 其实，这也就是敏捷，DevOps运动所倡导的：快速的响应变化，...  

很多时候，人们总会说某些理念或做法太过“理想化”，其实只是低头走路太久，忘记了抬头看天而已。如果我们心中没有理想，又如何可以创造出伟大的成就呢？而当下在测试领域，谷歌就是坚持理想实现了书中理念的典范。 p12~13 小型测试、中型测试、大型测试……mock和fake……小...  

很多时候，人们总会说某些理念或做法太过“理想化”，其实只是低头走路太久，忘记了抬头看天而已。如果我们心中没有理想，又如何可以创造出伟大的成就呢？而当下在测试领域，谷歌就是坚持理想实现了书中理念的典范。 p12~13 小型测试、中型测试、大型测试……mock和fake……小...  

一 《Google 软件测试之道》这本书我已经读完好几天了，并且是读的第三遍了，本来一直想写下读后感，但是一直迟迟不敢下笔。 一个原因是这本书里面的信息太多，可以说 Google 这个测试模式已经是超越了国内大多数公司好几个层级，很多公司完全可以把这个模式作为模版来学习。 ...  

Google的软件测试之道，参考意义首先跟之前看的一篇文章一样，互联网并不缺前端，也不缺测试，我们真正缺少的是工程师思维，是创造性的提出和解决问题的想象力，站在用户角度思考的产品的能力。 我们学习Google软件测试，只能学其道而没有必要，也不可能去他们的术。如《看板...  

用户评价

从装帧和纸张的选择上来看，这本书显然是为经常翻阅和标注的专业人士准备的。它有一种“可以被使用”的质感，而不是仅仅“被阅读”的摆设。我最希望从这本书中获得的，是关于“测试环境管理”的真知灼见。在如今的云原生时代，维护一个与生产环境高度相似的测试环境本身就是一项巨大的开销和工程挑战。谷歌如何处理这些环境的一致性、数据脱敏、以及如何在不产生天价云费用的前提下，保证测试的有效性和隔离性，是所有大型企业都面临的痛点。我猜测书中可能会涉及某种形式的“环境即代码”的实践，但更深层次的问题在于，如何处理真实用户数据在测试中的合规性和隐私问题？如果书中能详细描绘出他们如何设计出既能高度模拟真实场景，又能严格遵守数据安全规范的测试沙箱，那么这本书的实战价值将无可估量。这不仅仅是技术问题，更是对工程责任感的体现。

这本书的行文风格给我一种“严谨的对话”感，它不像某些技术手册那样冷冰冰地罗列事实，而是带着一种引导你思考的节奏。我注意到，作者在解释某些复杂概念时，会不自觉地引入一些现实世界的比喻，这大大降低了晦涩概念的理解门槛。比如，当他们谈论持续集成/持续部署（CI/CD）流水线的优化时，那种对“反馈速度”的执着追求，让我联想到了精益生产中的“看板”概念，只是在这里，看板上流动的不是零件，而是代码的质量信号。真正让我眼前一亮的是，书中似乎探讨了测试人员在产品生命周期中的角色转变。在传统的模式里，测试往往是瀑布模型的末端，但在谷歌的文化中，测试是内嵌的、分布式的。我很好奇，他们是如何平衡开发人员编写的自动化测试与专门的质量工程师之间的职责划分，以及如何在不同层级的测试（从本地模拟到生产环境的灰度发布）之间建立起平滑的过渡机制，确保测试策略的整体性和一致性，而不是让各个环节各自为政，形成信息孤岛。

初翻开这本书的章节目录时，我立刻被其中对于“大规模系统测试的挑战”这一部分的详尽划分所吸引。这种条理清晰的组织方式，立刻让人感受到作者对主题的掌控力。很多关于测试的书籍往往会忽略分布式系统、微服务架构下的异步通信和状态管理带来的复杂性，而是将重点放在传统的单元测试或集成测试上。然而，在现代互联网应用中，延迟、分区容错性和数据一致性才是真正的噩梦来源。我特别留意了关于“故障注入与混沌工程”的描述，这部分内容如果能深入探讨谷歌如何系统性地、有组织地去主动破坏自己的系统以发现隐藏的弱点，那将是极其宝贵的经验。这不仅仅是技术层面的探讨，更是文化层面的体现——一种对不完美抱有积极态度的工程哲学。我设想，他们一定有一套成熟的框架来衡量引入故障的风险与获取的收益，而不是盲目地进行“破坏”。如果书中能提供一些关于如何量化测试覆盖率在面对复杂非功能性需求（如性能和可伸缩性）时的局限性，并给出替代性的衡量指标，那这本书的价值将大大提升。

这本书的封面设计有一种沉稳而现代的气息，那种墨黑与亮白为主色调的排版，给人的第一感觉就是“专业”。我一直对大型科技公司的内部运作，尤其是质量保证体系充满了好奇，但市面上大多书籍要么过于理论化，要么就是泛泛而谈，缺乏实操的深度。这本书的标题本身就带有强烈的吸引力，它不仅仅是关于“测试”，更是关于“Google”——这个全球技术风向标的实践哲学。我期待它能揭示那些在代码世界里至关重要的、看似不起眼却又极其精妙的工程决策是如何形成的。想象一下，面对一个每天处理数十亿次请求的系统，如何构建一个既能保持快速迭代又不会让bug横行的测试金字塔，这其中的权衡艺术和架构选择，才是真正考验工程智慧的地方。我希望这本书能像一把手术刀，精确地剖开谷歌在软件质量管理上的核心结构，展示那些被视为行业秘密的流程和工具链，而不是仅仅停留在抽象的原则层面，毕竟，在实际工作中，我们需要的不是教科书式的理想模型，而是能在我们自己的混乱代码库中借鉴和实用的“剧本”。

读完后给我的整体印象是，这本书更像是一部工程管理哲学而非单纯的技术手册。它成功地描绘了一个将“质量”视为核心竞争力的组织是如何运作的。我注意到，书中似乎花费了大量的篇幅来讨论测试的“文化”和“指标”，而非仅仅关注具体的测试框架或语言。这很关键，因为工具会过时，但文化是持久的。我尤其想知道，在面对那些难以被自动化捕获的“用户体验瑕疵”或“微妙的性能退化”时，谷歌的测试体系是如何吸纳和处理来自早期用户、Beta用户乃至生产环境的“软反馈”的。这种从海量数据中提炼出可操作的质量改进点的机制，往往是区分优秀团队和平庸团队的关键。如果这本书能提供一个关于如何建立这种闭环反馈系统，并将“测试失败”视为学习和改进机会的组织结构蓝图，那么它就超越了普通的技术书籍范畴，成为了一份珍贵的组织优化指南。

以前只是通过自己的观察总结的东西，现在更清晰了。原来他们也这么认为。 :)

可重用的部分不多。书的作者之前写过 How Microsoft Tests Software, 不知道几年后会不会写一本How Facebook Tests Software...

有空可以读读

还是得组织上开明，个人有能力，政策支持。

还是得组织上开明，个人有能力，政策支持。