有启发的 7 句话：1. 质量不等于测试 2. 经验法则，即 70/20/10 原则：70% 是小型测试，20% 是中型测试，10% 是大型测试 3. 如果你不能在几分钟内列举出特质，说明你还没有足够的理解你的产品，还不能有效地测试它 4. 资源越少，目标越明了 5. 晋升取决于员工对项目产生的影响力 6. 探索式测试是深入学习理解一个产品的最佳途径 7. 测试的价值是在于测试的动作，而不是测试产物重点整理 :1. 质量不等于测试。当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量 2. 测试是开发过程中必不可少的一部分，当开发过程和测试一起携手联姻时，即是质量达成之时 3. 软件测试开发工程师（SET）：SET 是 SWE 在代码库上的合作伙伴，与增加功能性代码或提高性能的代码的 SWE 相比，SET 更加关注于质量的提升和测试覆盖率的增加。SET 写代码的目的是可以让 SWE 测试自己的功能 4. 测试工程师（TE）：TE 把用户放在第一位来思考。TE 组织整体质量实践，分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试 5. 资深管理者一般都来自产品经理或开发经理，而不是来自于测试团队。在产品发布时，优先考虑的是功能是否完整和易用性方面是否足够简单，却很少考虑质量。作为同一个团队，测试总是在为开发让路 6.Google 经常在最初的版本里只包含最基本的可用功能，然后在后继的快速迭代的过程中得到内部和外部用户的反馈，而且在每次迭代的过程中都非常注重质量。一个产品在发布给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta 或正式发布版本 7. 在理想情况下，一个完美的开发过程是怎样进行的呢？测试先行，在一行代码都没有真正编写之前，一个开发人员就会去思考如何测试他即将编写的代码。他会设计一些边界场景的测试用例，数据取值范围从极大到极小、导致循环语句超出限制范围的情况，另外还会考虑很多其他的极端情况。这些测试代码会作为产品代码的一部分，以自检代码或单元测试代码的形式与功能代码存储在一起。对于此种类型的测试，最合适且最有资格去做的人，其实就是编写功能代码的人 8. 编写功能代码和编写测试代码在思维方式上有着很大的不同 9."百分之二十的贡献"（译注："百分之二十时间" 是指 Googler 称为的 "业余项目"。这并不是一个炒作的概念，而是官方真正存在的，允许所有 Googler 每周投入一天时间在他的日常工作之外的项目上。每周四天工作用来赚取薪水，剩下一天用以试验和创新 10. Google 的四大主要开发语言：C++JavaPythonJavaScript11. Google 在平台方面有特定的目标，就是保持简单且统一开发工作机和生产环境的机器都保持统一的 Linux 发行版一套集中控制的通用核心库一套统一的通用代码、构建和测试基础设施；每个核心语言只有一个编译器与语言无关的通用打包规范文化上对这些共享资源的维护表示尊重且有激励 12. 小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试会带来整体产品质量和数据验证 13. 经验法则，即 70/20/10 原则：70% 是小型测试，20% 是中型测试，10% 是大型测试。如果一个项目是面向用户的，拥有较高的集成度，或者用户接口比较复杂，他们就应该有更多的中型和大型测试；如果是基础平台或者面向数据的项目，例如索引或网络爬虫，则最好有大量的小型测试，中型测试和大型测试的数量要求会少很多 14.SET 的面试重点在考察候选人如何思索问题的解决方案，而不是解决方案本身的实现上有多么高雅 15.TE 在进入产品时，需要考虑问题：当前软件的薄弱点在哪里？有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？主要用户场景是否功能正常？对于全世界不同国家的用户都是这样吗？这个产品能与其他产品（软件和硬件）互操作吗？当发生问题的时候，是否容易诊断问题所在？16. 如果你不能在几分钟内列举出特质，说明你还没有足够的理解你的产品，还不能有效地测试它 17. 在软件测试中，按照一个常识性的过程来理解风险，参考的因素：哪些事件需要担心？这些事件发生的可能性有多大？一旦发生，对公司产生多大影响？一旦发生，对客户产生多大影响？产品具备什么缓解措施？这些缓解措施有多大可能会失败？处理这些失败的成本有哪些？恢复过程有多困难？事件是一次性问题，还是会再次发生？18. 测试完整的页面并把错误定位到元素的级别，而非页面级别 19. Google 名言：资源越少，目标越明了 20. Google 允许工程师尝试新鲜的想法，只要他们知道如何衡量成功 21. 想成为优秀的测试工程经理：了解你的产品知人善用 22. 晋升取决于员工对项目产生的影响力 23. 团队打算做太多的东西的时候，就好像你要同时做五件事情，但是每件只能完成 80% 的时候，我就会要求他们退回来重新安排优先级。把你需要做的事情减少到两到三件，但都能完成到 100% 24. 保持技术敏锐度并像工程师一样：在与开发工程师和测试开发工程师团队沟通的过程中，想做一些技术工作，就必须尽量排除管理方面带来的干扰 25. 探索式测试是深入学习理解一个产品的最佳途径 26. 收纳一个工具到中央工具库里的标准：必须对生产力有极大的提升作用对大部分 Google 工程师来说都是适用的 27. 测试人员往往崇拜测试产物（test artifact）胜过软件本身。测试的价值是在于测试的动作，而不是测试产物

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

读完这本书让我受益非浅，对测试领域有了更深的认识，我们最终服务的是产品，而不是局限于自己目前所做的一部分，从开始产品的需求分析，制定各个部门的产品的计划，测试初期是完全吃透产品需求说明书以至于后续制定测试计划，提取要点，编写测试用例，提交缺陷，回归等一系列流程，中途不断跟研发、产品确认需求等，以及模拟用户场景进行测试。最终将产品交付于客户，后续的敏捷迭代等需要亲力亲为。而读完此书我深刻体会到测试行业必不缺少，敢于挑战敢于创新，一定会有回报 ，这本书讲究如何做好测试的思维以及做好测试软件开发的思维

虽然书的出版时间较早，但还是看到了 Google 的前瞻性研究个创新，以及优秀的工程师文化