问：如果探索式测试是硬币的正面，那么硬币的反面是什么？

　　答：探索式测试的对立面是脚本测试（Scripted Testing）。脚本测试要求预先编写好测试脚本（Script），脚本规定了如何配置被测试软件、如何输入、如何判断软件输出了正确的结果。编写详细的脚本往往需要大量的测试资源。

　　如果运用得当，脚本测试可能有如下收益：

　　测试人员可以仔细地思考被测试软件。

　　测试脚本可以被项目关系人（Stakeholder）评审。

　　测试脚本可以被复用。

　　测试团队可以评估测试脚本集的完备性。

　　测试团队可以度量测试脚本的执行情况，以评估测试进度。

　　问：本书为什么反对脚本测试？

　　答：笔者不反对任何测试思想或方法，但是反对不分语境地滥用某一种测试思想或方法。例如，苛刻地要求编写详细的测试脚本可能会导致如下测试风险。

　　在测试执行前，大量的测试资源被用于测试设计。但是，产品的发展往往难以预料，早期的预先设计不能有效地处理动态变化的情况。有可能花费了大量的时间，却获得了一批充满缺点的测试脚本。

　　过于详细的测试脚本压抑了测试执行的灵活性，使得测试执行变成单调的过程。这可能导致测试人员对一些明显的错误视而不见，因为它们不在测试脚本的检查范围之内。此外，运行测试是观察软件行为、获得测试灵感、设计新测试用例的时刻，这要求测试人员在测试执行时全神贯注、头脑灵活、反应敏捷。但是，枯燥的测试执行将使这些目标难以实现。

　　大量的详细测试脚本导致了沉重的维护代价。在进度压力下，测试人员可能没有时间更新测试脚本，这使得测试脚本不能随需求和产品一同演化。随着时间的推移，大量的测试脚本成为过时的、无人问津的“摆设”，原先投入大量资源所获得的测试资产几乎消耗殆尽。

　　要求测试人员编写求全责备的测试脚本，很可能带来不良的心理暗示：测试人员在不知不觉中将编写脚本看做测试的目的，而不是辅助测试的工具。他们会盲目追求脚本的数量，而很少关注产品和项目的风险，用看似“完备”的脚本集提供虚假的安全感。更糟糕的是，醉心于脚本数量的测试领导很可能会鼓励这种以“文案工作”为核心的测试流程，使测试的价值进一步流失。

　　相比“硬币”的比喻，笔者更喜欢Cem Kaner的观点：“纯粹的探索式测试和纯粹的脚本测试好似区间的两个端点。在实践中，大多数测试者位于这两者之间。然而，大多数好的测试非常接近探索式测试的一端。”

　　此外，根据语境驱动测试的基本原则，测试人员需要经常反思：根据当前语境，测试策略是应该偏向探索式测试，还是脚本测试？如何综合它们的优势，以获得更好的测试结果？

　　问：探索式测试编写测试文档吗？

　　答：探索式测试者创建任何有助于实现其目标的文档，他会撰写并维护符合语境的测试文档。这里提出一种可能的测试计划编写方法，供读者参考。

　　在不同的开发组织，测试计划有不同的名称：测试计划、测试规格说明和测试设计文档等。但是，大多数测试计划会涵盖产品概述、测试范围、测试风险、测试策略、部分详细测试用例、资源分配和日程安排。

　　与脚本测试在测试执行前编写大量文档不同，探索式测试在整个测试过程中持续编写、修改、优化测试计划。测试计划的内容、格式、详略是由项目语境决定的。

　　在项目计划阶段，测试计划可以包含产品概述、测试范围、测试风险、测试策略、资源分配和进度安排。编写文档的目的是建立对产品的整体认知，根据风险提出相应的测试策略，并安排测试任务和日程。测试计划不必面面俱到，用精简的格式记录必要的内容即可。此时项目的不确定性较大，未知因素较多，很可能不适合做出详细的测试决策。