学习探索式测试的问与答

　　本文摘录自《探索式测试实践之路》第1.3节，用对话的形式讨论探索式测试的概念与实践。提问者是本书的一位虚拟读者，回答者是本书的作者们。

　　问：探索式测试中的“探索”该如何理解?

　　答：所谓探索是指有目的的漫游，即带着使命在某个空间中漫游，但没有预先确定的路线 [Kaner01]。探索包括对产品与技术的深入研究和基于研究成果的实践应用。

　　问：如何实施探索式测试?

　　答：本书第3部分将专门讨论该问题。这里先介绍一种可行的探索式测试实施方法，其灵感来源是基于测程的测试管理(Session-Based Test Management)[Bach2000]。(在Session-Based Test Management中，Session是一段专门用于探索式测试的时间，其常用的中文术语“会话”并不适合该语境。经过慎重考虑，笔者将Session翻译为“测程”，以表达它是一段专注于测试的过程。)

　　探索式测试鼓励测试人员依据当前语境选择合适的测试流程与技术。在测试过程中，SMART原则为测试者提供了很好的指导。

　　Specific(具体的)：测试需要一个具体的目标。

　　Measurable(可度量的)：有明确的指标可以评估目标是否达成。

　　Achievable(可实现的)：目标应该是可实现的。这潜在地要求将一个大目标分解为多个小目标，且每个小目标也是具体的、可度量的、可实现的。而且，追踪小目标的完成情况提供了整体进度的可度量性。

　　Relevant(相关的)：目标要切合当前语境，符合团队利益，且不忘企业愿景。

　　Time-boxed(有时间限制的)：为每个目标设定一个合理的最后期限。这可以帮助测试人员在固定的时间窗口(Time Window)中排除不相关干扰，专注地工作。

　　依据SMART原则，测试人员可按如下描述展开探索式测试。

　　测试人员制订测试计划。分析被测试应用，确立若干个具体的测试使命(Mission)，每个使命针对一个可能的产品风险。

　　测试人员将测试使命分解为一系列测试任务(Charter)，每个任务都有明确的退出条件和时间限制。

　　在短暂的测试计划之后，测试人员根据优先级选择一个任务，在一个固定的时间窗口中执行探索式测试(窗口的长度是60~120分钟，以90分钟为宜)。这样一个时间窗口被称为一个测程(Session)。在该测程中，测试人员设计测试、执行测试、评估测试结果。他会根据获得的知识和发现的疑问再设计测试用例，以拓展测试的广度和深度。

　　在测程结束后，测试人员适当休息，放松思维。

　　随后，他会反思当前的测试进展，并优化测试计划。也许他会为当前任务追加一个测程;也许他会再增加一个新的任务以弥补先前测试计划的不足;也许他会删除一些任务以反映他对测试对象的最新认知。

　　这时，他会更有自信地开始新一轮探索式测试。

　　以上只是一种可能的探索式测试实施方法。负责任的测试人员一定会选择他自己的方式展开测试，因为只有作为领域专家的他，才能做出最符合语境的决策。此外，集合整个团队的力量，进行同行评审、头脑风暴、结对测试等活动，有助于产生更好的测试结果。

　　问：探索式测试与即兴测试(Ad-hoc Testing)有何区别?

　　答：探索式测试与即兴测试都强调“即兴发挥”，即利用直觉和经验，快速地测试软件，并不停地调整测试策略。软件专家Andrew Hunt指出，直觉是非显性知识的代名词，是大脑富(Rich)模式的杰出能力。如果人类只使用大脑的线性模式(包括语言可表达的显性知识、抽象能力、逻辑能力等)，而漠视富模式的能量，我们将浪费自身的巨大潜力[Hunt08]。

　　然而人是不完美的，某些直觉可能是认知偏见或错误。这就引出了探索式测试与即兴测试的关键不同：探索式测试是带着“反思”的测试。在探索式测试中，测试人员不断地提出假设，用测试去检验假设，并分析测试结果来证实或推翻假设。在此过程中，测试人员持续完善头脑中的产品模型和测试模型，然后利用模型、技能、经验去驱动进一步的测试。通过将测试学习、设计、执行和结果分析作为相互支持的活动并行展开，探索式测试总是在不停地优化测试模型、测试设计和测试价值。因为测试设计和测试执行的切换速度很快，许多人误以为探索式测试没有计划和设计。实际上，这些活动被划分到细微的时间片中，被反复执行。

　　即兴测试往往利用错误猜测、典型风险和常见攻击来快速地试探软件，可以在短时间内发现许多软件错误。但是即兴测试不强调测试的系统性和完整性，测试遗漏的风险很高，也难以发现一些需要深入研究才能发现缺陷。探索性测试通过测试来透彻地理解被测试产品，从而拓展测试的广度与深度，以持续优化测试的价值。

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

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

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

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

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

　　测试脚本可以被复用。

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

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

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

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

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

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

原文转自：http://www.ltesting.net