这是鼎叔的第三十三篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。
经历了完整的理论学习之后，一个新手团队如何从探索式测试小白，走向实践高手的水平？
新手团队，对探索式测试要测哪些地方，何时测，如何测，通常会感到茫然。
测试前要准备什么？如何分析探索对象和探索范围？如何设定预期目标和达成效果？什么时候开始测试？
让我们真正开始探索式测试的实践吧。
本文是关于探索式测试第三篇文章。相关文章：
第一篇 聊聊什么是探索式测试
第二篇 聊聊产品的局部探索和全局探索
Part 1 探索前期准备我们已经明确了探索式测试的价值，并把愿意尝试和承诺投入的同学聚焦到了一起，然后，怎么做？
1. 明确试点项目严格来说，探索式测试不是原有计划测试的加法，它是有益的互补，可以带来更高效的产出，值得占据一定的人力投入比例。我们并不需要为探索式测试单独增加专职人力。
那我们在选取试点项目时，首先需要测试负责人的认同，他有拥抱变化的心态。我们也会给出收益考察指标。
找到一段交付压力没有特别大的时期，开始第一次试点，可以以1-2个发布版本为周期。
给出试点计划：谁（导师和执行者），在什么测试阶段（时间），完成整个产品（或者产品的某个特性）探索测试，从全局探索还是局部特性探索开始。
2. 产品整体分析以全局探索为例，我们给产品的不同功能模块进行划区分析： 这个模块，更适合作为哪个区来展开探索。 是商业区，破旧区，还是数个区兼而有之？
可以在测试模块的覆盖思维导图上标注。
3. 测试点方法分析针对每一个主要的测试功能点（不是一个个具体测试用例，一个测试点可以包括多个用例，比如“成功添加好友”），都可以在思维导图中标注出你认为最合适的探索方法，即最容易找到缺陷的方法。建议整个测试团队共同来标注吧！
到此，思维导图就是开始探索测试的最佳指南。
当然，我们也可以不提供探索思维导图，而是给出匹配表格，把具体探索测试法和合适功能点进行最佳匹配。下面以手机管家APP的探索式测试为例。
测程，session，定义为一次连续的探索式测试执行的时间长度。而对探索式测试的管理，就是基于测程的管理（Session-based Test Management，SBTM）。
我曾看到有团队在分配执行时间时，随意地给某个功能模块2-3天的探索测试时间，但是没有任何约束或明确目标。盲目的安排，不会带来高效的实践结果。
通过对测程的计划，我们可以度量探索式测试的效果，并与以前的计划测试执行效果作对比。
另外，通过测程的产出不断灵活调整后面的分工安排，改进选用的探索策略和方法。
从人的专注度来说，一个测程最佳是1-4小时之前，强度适中，中间可以短时间休息，也可以根据人员状态调整。
测程结束时，可以对本次测试做一个小结，看是否调整下一个测程的覆盖范围，策略和使用方法。推荐可以找项目负责人面对面进行测程小结交流，也便于负责人了解探索式测试发现的成果。
章程，是指探索测试的方向、目的和依赖资源，可以针对每一个测程定一个或数个待完成的探测章程。章程也可以独立于测程，连续进行多次有焦点的探索。我们可以认为，测程是对时间盒内探索任务的管理，章程是对测试焦点的管理。
引用《探索吧！深入理解探索式软件测试》中的一个生动例子。
美国第三任总统托马斯·杰斐逊，在1803年给探险军团刘易斯和克拉克的信里，提到一个重要的探险任务，从圣路易斯市出发，找到一条可横穿大陆抵达太平洋的通道。信中指明了以下几点：
- 探索何处：密苏里河及其主要支流
- 可用资源：船只，帐篷，勘探工具，武器等装备，可以赠送给当地土著的礼物。
- 所寻信息：商路
三年又三个月后，刘易斯和克拉克胜利归来，成为国家英雄，通过7000英里路程，将横穿内陆的路线绘制成一张探险地图。
从上面的例子，可以看出探索章程的三段式模板：探索何处、可用资源和所寻信息。
遵循探测章程，可以让你的测程更加有针对性，更加高效。
要设计一个好的探测章程，需要具备以下特征：
- 在需求评审阶段，用心关注可以用来探测的核心能力项；
- 测试前和干系人充分沟通，听取其意见（尤其是他们怎么看待价值）；
- 但是不一定要完全认可干系人的看法（可以有自己的主见）；
- 范围要聚焦，但不要过于细致，一句话描述才会有更自由的探索空间。这一点类似用户故事的“可交谈性”。
下面我们举一个实战例子，如何通过和开发人员深入沟通，得到设计章程的启发。
Part 3 章程设计实战：云盘上传下载功能探索式测试的思考，就是从提问开始，如对开发提问，对产品提问，等等。在围绕用户故事的交谈中，测试人员就可以通过对开发的批判性提问，敏锐找到对方担心的可能存在不稳定因素的地方，或者盲目自信的地方。如果出现问题的影响力大，那就值得作为章程来指引本次测试活动。
通过对产品经理提问，找到产品在市场上被看重的功能，找到用户对我们产品的关注和抱怨，我们也可以此制定探测的章程。
实例： 针对云盘的上传下载功能，进行局部探索式测试，以下是与开发人员的对话。
测试人员：云盘上传下载核心功能确实是我们测试的重点也是难点，有几个问题想确认下。
开发人员：什么问题？
测试人员：除了一些正常上传的状态，上传失败的场景有做判断吗？比如过程中切换网络，切换页面等。
开发人员：切换网络，中断网络是有做判断的，也会有相应的提示，切换页面对上传功能没有影响的，清掉后台进程到是可以测测。
测试人员：OK，那这些场景我们都要测试下，还有如果在上传过程中退出账号后上传进程怎么处理？再登录进来上传记录会保留吗？
开发人员：退出账号上传肯定就中断结束了，再登录进来需要重新上传，上传记录也不会保存。你们重点挖掘下有哪些情况会上传失败以及恢复之后上传是否能正常进行，数据有没有丢失或损坏。
测试人员：嗯，这块干扰上传状态的情况有很多，我们都测试下。
沟通完毕，明确了要探测的具体目标，制定好本次探测的章程。
然后开始具体的探索准备。
1）被测对象有一定复杂的状态变化，简单绘制一下状态转换的模型图。
2） 思考有哪些方法可以干扰上传状态，例如杀掉进程、切换网络、断开网络、退出/切换账号、删除本地文件、切换画面等。
3）思考干扰状态以后会发生什么，是否合理：
- 响应干扰的方式是否符合预期，还是进入一个意外状态？
- 从干扰中恢复后，行为是否也恢复正常？
- 有没有丢失或损坏数据？
通过以上充分的分析，一个深入细致的探索准备工作就完成了，在后面的执行中，确实发现了几个深层次的缺陷，让开发同学深受触动，这种缺陷仅从产品需求文档中是难以捕捉的。
Part 4 开始执行探索通常在研发的什么阶段开始探索式测试最合适？
探索式测试可以在整个软件研发生命周期中随时进行，不同时期的关注点可以不同，根据质量关注点和人力投入来灵活制定。
早期版本测试时，探索式测试可以作为系统测试的准入，快速发现是否有低级问题，如果有，可以立刻打回开发去解决，而不用等到如火如荼的集成测试开始后再陆续反馈问题。解决低级问题后的版本，会明显提升产品的基础质量，降低测试耗时。
系统测试中期的探索，如果产品复杂度很高，人员较多，可以对参与探索式测试的人员进行分工，可以按端到端的完整特性来分配给不同人员去探索，也可以按特定的探索式方法分配不同的人员。不建议按照功能模块划分来分工，因为很多问题是发生在模块调用或切换之时的，而探索测试的敏锐自主风格鼓励了人员对价值挖掘负责。
系统测试后期的探索，此时基本功能和路径都有充分的测试，应该是一个查漏补缺的状态。探索式测试可以作有效的补充：1 针对目前容易出问题的区域，或者频繁发生问题的一类缺陷，做一轮聚焦目标的专项探索。2 针对待发布（灰度发布）版本，尝试更多的探索方法找到剩余的遗漏缺陷，最终冲刺一把。
探索式测试的过程笔记与结果报告
探索式测试并非无文档测试，探索旅途中的脑洞大开，就可以像作家一样随时记下来，给后继测程以更多的启发，毕竟好记性不如烂笔头。而测试报告也不要万年不变，我们需要在报告中突出体现：探索的最终成果（收益是否足够高），所挑选探索方法的有效性，预感到的未暴露质量风险，下一轮的探索测试该如何发力，等等。
