京东购买链接：https://item.jd.com/10205955087769.html
在我们的咨询业务中，经常会遇到这样一个现象：从未开展过测试自动化的团队，都会说自己对测试自动化非常了解。同时，在我们主持过数百次播客访谈后，也认识到测试自动化对他们来说，往往只是一个概念，一种基于信念的概念。我们在一年、两年，甚至五年后，再次回访这些团队，发现那些曾被指导过的团队要么终于领悟了我们给出的建议、经验和教训（但当时未能践行），要么由于某些原因最终失败了。
事实证明，使用测试工具的一些思路，只能通过实践经验来学习。如果没有前辈、文档、视频教程等资料的引导，团队成员可能会重复犯同样的错误，甚至周而复始。就像一些团队，没有地基便建造桥梁，桥梁最终会垮塌。因此，建议不要重蹈覆辙，而是从实践经验中学习。故本章以笔者多年经验为框架，将讨论以下内容：
● 没有银弹：没有任何一种技术或方法可以从根本上缩短测试 / 修复周期。
● 雷区回归问题：传统的自动化测试只在第二次及之后的运行中才有价值，且价值非常有限。
● 海战棋问题：当发现 bug 时，无法改变策略的自动化工具是有局限性的。
● 测试维护成本问题：只关注特定变更（可能会遗漏一些隐藏变更）与每次变更后脚本报错之间如何把握平衡。最后，针对这些挑战，我们将给出一些解决方案。
2.1 技术要求
本章主要包含一系列概念，如此设计的目的是使任何受过高中教育、了解互联网、有抽象思维能力的人都能够理解。本节通过比喻的方式展开论述，并从网格坐标和游戏等概念中汲取测试灵感。读者可以打印表格，并与其他人员一起用铅笔和纸张进行实际操作，如此有助于理解本章讨论的概念。例如海战棋（Battleships）游戏，读者可以通过谷歌、百度等搜索引擎搜索海战棋相关文档，了解海战棋棋盘和规则，以便在阅读本章时能够容易理解。
提示：海战棋（Battleships）是一款模拟海战的棋类游戏，它包括布阵和对战两个过程。玩家必须在规则范围内布阵，通过分析和判断来确定对方战舰的准确位置并将其摧毁。首先将对方所有战舰全部摧毁的玩家获胜。游戏采用回合制，每回合玩家有一次点击格子的机会，如果未能点中敌方战舰，将轮到对手回合；如果点中了敌方战舰，将继续点击。
2.2 没有银弹
Fred Brooks 在 1975 年出版了一本《人月神话》，这可能是最早面向大众，且至今仍在印刷的一本软件工程书籍。其内容可能有些过时，但书中的三个观点至今仍具现实意义。观点一：增人不能增效，向已经延期的项目投入更多的人力会使项目进一步延期。随着项目的扩展，团队成员之间的沟通成本会呈指数级增长，从而导致成本重心从实际工作转向沟通与协调。下一节将会讨论如何保持有效沟通，降低沟通成本；观点二：Brooks 提出了“第二系统效应”，可以理解为只有从客户需求的角度做出尝试，才能真正了解什么对客户有益。这一观点也促进了快速原型设计和其他应对措施的发展；观点三：没有银弹，没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。正如 Brooks 所说：“做好舍弃第一个原型的准备，你往往需要这么做”（Plan to throw one away – you willanyway）。并且，本节的核心内容也来源于 1995 年他在第二版增加的一篇名为《没有银弹》的文章。
Brooks 博士在《没有银弹》这篇文章中指出，软件开发由一系列明确的阶段组成，例如规划、需求分析、设计、编码、测试和运维等，每个阶段可能只占总工作量的六分之一。因此，即使通过一些人工智能技术使编程变得简单，甚至完全靠它生成，从而压缩这一阶段工作量，理论上，时间和成本最多也只能减少六分之一，约 16%。但在实践中，任何阶段的工作量都不可能完全压缩为 0，即使依靠一些技术减少 75%，放置于整个软件开发中，体量依然很小。故 Brooks 博士提出，没有任何一个“银弹”可以解决失控软件的开发问题，而建议采用多个“铜质子弹”—尝试多种方式逐步减少工作量，产生累积效应。本书正是我们尝试打造多个“铜质子弹”的一次实践。
接下来，让我们尝试通过自动化测试来缩短测试周期。
大多数团队执行自动化测试后，都需要对结果进行检查，确保测试报告都是系统功能问题，而非是受脚本、网络等其他因素影响而出现的问题。对于一个测试人员来说，每个结果都需要依据数据或逻辑进行判断。但对于自动化测试来说，是按照一定的顺序直接执行操作并检查结果的，更多的是检测变化而非测试。因此，运行自动化测试就会出现失败或错误，但这也可能意味着自动化工具正在按照预期的方式运行。测试人员除了检查结果外，对一些失败的用例可能还需要深入研究。借助自动化工具测试复杂场景发现的问题，往往比手工测试发现的问题更难复现和定位。一旦可以稳定复现后，就需要提交 bug，然后等待开发人员修复，接着对程序重新构建和发版，最后执行自动化测试脚本，用例通过。
所有上述讨论都基于一个假设，即自动化测试不需要成本，并且能够立即完成。然而自动化测试的实施和运行都需要投入成本，包括编写、调试、执行以及维护等。
在我们合作过的团队中，多数情况下，自动化测试工具能减少的测试工作量也不到 50%，何况自动化测试工具并非免费和无限快的。即使是在每年耗资数千万美元的测试项目中，仍非常重视手工测试，因为其比工具更能快速地给出有意义的反馈，即对于程序变更的地方，手工测试可以迅速开展并提交 bug，当开发人员开始修复问题时，依靠工具测试的项目可能报告都还没有出来。我们并不是反对自动化测试，自动化测试也有自身的价值，例如持续交付的实现就需要工具辅助测试。本书所要表达的是：在没有找到一个普适的解决方案（涵盖产品研发的整个过程）前，不能盲目地“一切皆可自动化”。
如果你执意践行一切皆可自动化的理念，当你在搜索引擎中输入“软件测试自动化如何实现”时，很可能会踏上一条艰辛的道路。虽然通过自己的钻研，也能有所收获。但这并不是本书所希望的，本书的目的是加速读者的学习过程，即不必花费数年时间在黑暗中摸索笔者曾经蹚过的泥坑，而直接掌握这些经验教训。本章剩余部分就将引导读者摆脱宗教式的一切皆可自动化理念，提供更健康、更实际的选择。
