在项目计划阶段，应该邀请项目关系人对测试计划进行评审。评审的形式可以多种多样，会议评审、桌面走查、邮件评审、在线文档批注、头脑风暴皆可。评审的目的是发现“大图景”上的缺陷，并丰富测试策略。眼界开阔的项目经理、负责任的开发人员、经验丰富的测试同事能够提供很好的建议。

　　在测试阶段，测试人员需要根据测试进展持续更新测试计划，内容可能包括产品模型、检查列表、测试策略、覆盖大纲和风险列表等。测试计划应该是“活”的文档，能够反映测试人员对产品和项目的最新认识。对测试范围、测试风险、测试策略和进度安排的重大变化应该写入测试计划，重要的测试用例（如发现严重缺陷的测试用例）也应该及时融入测试策略。测试计划应该尽可能地精简，这有助于文档的持续更新，而冗长的文档将不利于阅读、增删和修订。

　　当测试人员认为测试计划相对完整之后，他还应该邀请项目关系人对测试计划进行评审。评审的目的是发现测试遗漏，补充测试策略，提高测试覆盖率。

　　以上方法有三个重要的特点。

　　测试计划的编写与改进贯穿整个测试过程。在测试执行之前，对测试计划不必求全责备。在测试执行中，测试人员根据测试反馈，动态地调整测试范围、项目风险和测试策略，生成新的测试用例，并对测试计划做必要的更新。

　　测试人员持续地收集对测试计划的意见，并将改进意见纳入测试实践。正式和非正式的测试计划评审可以识别潜在风险，丰富测试策略。在一些测试流程中，测试计划评审只发生在测试开始之前。但是，笔者建议在测试流程的中期再次评审测试计划，目的是进一步丰富测试策略的多样性，并发掘可能的测试遗漏。这时，测试团队对产品与风险拥有更深刻的理解，能够提出更具针对性和多样性的测试策略，也可以帮助测试人员发现测试盲点，从而提高测试覆盖率。

　　测试计划侧重测试规划（一组指导测试过程的想法）和测试策略（一组指导测试设计的想法）[Kaner01]，而不是脚本化（Scripted）的测试用例，即测试计划用精简的格式表达测试人员的测试想法，而不必详细记录测试用例的设置、步骤和预期结果。测试人员可以用文字、列表、表格、思维导图等任何合适的方式表达想法，目的是激发测试灵感，并促进测试思想的交流。此外，他会利用发现缺陷的测试用例来完善测试策略，而不是让过去的测试用例控制未来的测试。

　　关于其他形式和内容的测试文档，测试专家Michael Bolton的文章What Exploratory Testing Is Not：Undocumented Testing提出了很好的建议。

　　问：探索式测试的核心优势是什么？

　　答：探索式测试的核心优势是有助于“学习”。此处的学习是指学（获取知识）与习（应用知识）的持续过程。

　　对于测试人员，软件测试是一个持续学习并实践的过程。他的学习范围如下。

　　行业知识：为什么需要这个软件？软件如何帮助使用它的人和团体去获得成功？

　　用户角色：目标用户是谁？他们有什么特点，有什么期望？软件如何帮助他们去获得个人成就？

　　软件产品：产品是一种解决方案，它解决了行业和用户所面临的问题吗？

　　计算平台：只有深刻理解软件所依赖的计算平台（如操作系统、中间件和网络协议等），才能更好地进行测试。

　　开发技能：理解项目所使用的具体技术，知晓典型的技术缺陷，具备测试开发的能力。

　　测试技术：针对当前项目，选择合适的测试技术，并能够熟练地应用。

　　程序缺陷：研究已知的软件缺陷，提炼错误模式，制订缓解或预防方案。

　　开发团队：语境决定策略和实践。在一起工作的人，是所有项目语境中最重要的组成部分。

　　测试人员不需要在项目之初就掌握所有知识，他可以通过每天的工作去逐步理解用户、项目、技术和团队。更重要的是，他需要在每天的工作中实践所学的内容：规划测试方案、创建并执行测试用例、分析测试结果和编写测试报告。实践是练习，是“学”的自然延伸。知行合一才构成“学习”的完整内核。

　　学习的一个重要成果是成为更优秀的测试人员。他们可以根据项目语境，选择合适的流程、技术和工具来高效地测试，以推动软件质量的提高。