京东购买链接：https://item.jd.com/10205955087769.html
2.4 海战棋问题：测试 VS 检查
海战棋游戏是一款网格游戏，我们可以将输入空间看作二维平面，有 X 轴（左右方向）和 Y 轴（上下方向）两个维度。为了方便理解，我们可以将 X 轴视为软件中的各项活动，比如搜索功能、产品信息展示、购物车、创建 / 编辑账号等，Y 轴则代表在这些活动内部的具体输入空间。这种比喻可能不是很贴切，因为二维平面毕竟只是一个模型，不可能非常完美地适用于任何情况。在童年时期玩的海战棋游戏中，X 轴由数字（1 ～ 10）表示，Y 轴由字母（A ～ J）表示，左上角的坐标就是（1,A），如图 2-4 所示。
图 2-4 海战棋游戏
海战棋游戏已有近 100 年的历史，比版权法出现得还早。在游戏中，两位玩家首先会在棋盘上按照以下规则布置各自的舰队：
● 一艘航空母舰（占 5 个格子）
● 一艘战列舰（占 4 个格子）
● 一艘巡洋舰（占 3 个格子）
● 两艘驱逐舰（每艘占 2 个格子）
● 两艘潜艇（每艘占 2 个格子）
玩家可以将这些战舰纵向或横向布置在棋盘上，但是不能斜向布置。
2.4.1 将战舰看作 bug
我们将海战棋游戏中的战舰看作软件中的 bug，此游戏映射出了一种现象—bug 倾向于在模块中聚集，虽然没有数据来佐证，但这一现象确实符合我们的日常工作体验。
不同版本的海战棋，战舰类型、战舰数量、棋盘大小等可能有所不同，但玩法是相通的。玩家在小表格上标记好（隐藏）己方战舰的位置，然后双方轮流出击（交替猜测对方战舰的坐标），防守方宣布“未命中”或“命中”。但是，在使用海战棋游戏教授软件测试时，笔者会要求一半学员（玩家）提前规划他们的行动。这也是传统自动化测试所做的事情，提前定义好软件运行的步骤，这些步骤既可以作为可执行的规范在编写代码前预先设定，也可以作为测试过程的一部分在代码完成后编写。同样地，人工编写的脚本化测试（包含测试用例、步骤和预期结果），本质上也是如此。
故在此教学中，我们会要求一支队伍模仿自动化测试的方式，将他们的行动计划详细列出，而另一支队伍则无需事先规划，可以随意行动。
如此一来，原本简单的游戏将会变得十分有趣。高度配合的小组至少会尝试玩一下，以观察整个游戏的变化。那些喜欢规划的人，尤其是有后续步骤测试经验的人，非常乐意参与其中，他们会制订大的 X 形、星形或对角线策略来寻找对方的战舰。然而，那些个性较强、智商较高的人，特别是对“计划型”测试不太熟悉的人，可能会表现出对规划的抵触。因为他们认为，一旦被锁定在某一策略上，就无法在命中目标后灵活调整，无法围绕已命中的位置快速判断并找出剩余船只的确切位置，进而将其击沉。
从结果来看，不受既定行动计划约束的团队往往会击败那些严格按照计划行事的团队。在开展了数百场双人团队的对抗模拟实验后，我们发现按照计划行事的团队仅有寥寥几次首先击沉对方舰队并赢得比赛。而且即使是在他们获胜的比赛中，也多数是因为对方玩家来自不同的文化背景或不熟悉基本的游戏规则，甚至没有意识到当他们击中目标时，应该及时调整策略。
将此模拟实验对应到软件测试，我们可以看到的是：首先，测试受文化差异的影响，就像回文问题一样，有些人虽然写了测试用例，但受自身文化、工作等属性的影响，一些场景不能充分考虑到；其次是覆盖率，本书第 9 章会重点讨论；最后，也是本节最重要的教训，计算机（自动化测试）无法自行调整测试策略，相反，它们往往只会对要求检测的内容进行检查。此行为带来的局限性，将会在“2.5 维护问题”中进行探讨。
2.4.2 自动化 VS 人工
在海战棋模拟实验中，许多人会对完全遵守计划行事的规定提出意见，他们希望借助人工智能（AI）改进测试代码，以在发现 bug（战舰）时进行自我调整。第2章 工具与自动化的基本问题 041笔者并不反对这一点，如果有团队成员可以在他们的项目中实现这一技术，或知道某个团队拥有的测试软件能够做到这一点，笔者还是很乐意看到他们使用此项技术的。但这并不完全属于模型驱动测试的范畴，模型驱动测试更倾向于全面检查所有可能的情况。迄今为止，笔者还没有发现有人在测试工具中应用这项技术，以在发现 bug 时可以像人一样进行灵活调整和响应。
概要总结一下，人类探索与计算机测试自动化存在着根本区别，因为人类可以根据上一个测试结果来规划下一次测试。在 2009 年敏捷大会上，迈克尔 · 博尔顿（Michael Bolton）做了一场闪电演讲，他试图区分“人类能做什么”（带着发现意图去调查产品）和“计算机能做什么”（检查预先定义的场景）。为了突出两者区别，他选择了“testing”和“checking”两个英语单词。根据迈克尔 · 博尔顿的观点：“测试（testing）是通过体验、探索和实验来了解产品，从而评估产品的一个过程，在一定程度上包括提问、研究、建模、观察、推断等活动。”( 引用自迈克尔 · 博尔顿的文章 Testing and Checking Refined，链接 2-2）。迈克尔 · 博尔顿对测试的定义与本书引用 Kaner 博士的观点是一致的。博尔顿将检查（checking）定义为“……通过将算法决策规则应用于对产品的具体观察来进行评估的过程。”
用博尔顿的话来说，检查是测试的一部分，是我们测试过程中的一项活动，并且在降低风险方面具有一定价值。理论上，让一台计算机在角落里独自执行检查是完全可以实现的，但其价值却很有限。本书的重点是帮助读者强化风险意识，以及如何通过测试降低风险，毕竟检查只是完整风险管理策略的一个组成部分。对于动态机制（人类发现 bug 的方式与计算机所能完成的任务之间）的误解，往往是软件交付过程中许多问题的根源。所以，不妨邀请一位朋友一起玩海战棋，然后，思考自己正在开发或想要开发的工具是否能够发现边缘场景下的 bug。