这是鼎叔的第五十二篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》，大量原创思考文章陆续推出。

探索式测试在敏捷测试象限中处于右上角，即面向业务且评价产品，这篇补充一下探索式测试在项目测试中体现出的敏捷价值观，分享国外专家在探索式测试实践的观点。

注：所谓评价产品，就是在测试中使用系统并尽量重现最终用户的实际体验，这也是探索式测试为什么对用户体验评测至关重要的原因。

客户的参与，场景的创建

要创建准确的用户场景，真实生活中的领域知识是关键，因此应该端到端地测试完整系统，这时，聊聊角色扮演探索式测试与肥皂剧模型 就非常适合。通过这些场景活动，能帮助成员理解更复杂的业务问题，并充分考虑用户使用产品的动机。

让客户尽可能多地参与迭代项目的效果演示，越能获得客户的即时反馈。有的团队会在演示后让利益干系人（包括客户）做一些探索式测试，可以帮助团队把功能考虑得更加细致，并基于刚发布的功能马上思考将来要做的用户故事。

大师对于探索式测试的定义

Cem Kaner 很早就给探索式测试下了个人定义，它是一种让所有测试人员全身心投入工作时使用的方法，即同时进行测试的设计、执行和学习；也是一种强调测试人员的自由和责任的测试，是持续贯穿项目的平行活动。

这个定义说明，探索式测试不是草率的，可能需要广泛而精细化的准备。其中最厉害的准备，就是测试人员多年积累的知识和技能。探索式测试不是一种技术，也不是指南，它让测试活动具备探索性的原因，是测试人员的认知投入，能够学习如何应对持续变化的情况。

探索式测试人员的不同

探索式测试人员记录产品预期行为的想法，并不会列出太多细节，不需要太多清楚的指示。他的注意力会转移到产品界面呈现的新问题或新风险上去。在测试执行过程中，他会快速考虑这个问题是否干扰用户工作流的顺畅，并评估其严重程度。

当探索式测试人员收到新的构建版本时，往往倾向于不再重复之前的测试，而是着重于变化，以图发现过时的旧测试遗漏了什么，这种方法很有成效（考虑到底层自动化回归测试已经覆盖了重复性的各种测试场景）。

探索式测试的特点，就是测试人员自己要掌控测试程度，基于上一步的测试结果，对自己下一步该做什么能自然地给出明智的选择。

没有一个有思想的人，执行活动时是完全照着原稿进行。人可以快速学习新的信息，并研究其根源和影响。但机器代码只认识它被编程的内容，当奇怪的测试结果发生时，代码就可能忽略、崩溃，甚至毁坏数据。

从客户角度出发的测试活动确实不会是完全探索型的，探索式测试人员也要从测试目标驱动，目标一定程度上由客户在项目早期设定。探索式测试的任务也会参考检查清单，模型，覆盖要求和风险清单，但是如果被这些观点控制（而不仅仅是被指导），那测试活动更有可能变成” 计划好的传统测试 “。应该通过变化来驱动对问题的积极搜索，而不是局限于计划好的用例，这些用例往往只证实我们已经知道的东西。

因此，优秀的探索式测试人员应该不断地研究产品，和其他角色合作，而不是遵循程序结构化的方式埋头执行。这也是和敏捷宣言-” 个人和交互，大于过程和工具 “，” 强调客户协作，而不是合同谈判 “，不谋而合。探索式测试包含了和敏捷研发同样的价值观。

测试中的好嗅觉

没有刻意练习的黑盒测试人员，可能并不知道如何进行探索式测试。来自探索过程中的记录，也可以帮助人员能重现问题，以便于进一步研究。

怎样修炼测试过程中的好嗅觉？

基于对系统的理解，结合批判性思维，定义好测程，可以在短时间内运行的实验性测试，最后给出过程中的反馈。
分析风险，即用户认为什么是错误的，让人不高兴的。
对应的，用户心里强烈希望功能行为是什么样子的，并测试它。
基于过去经验，思考相似系统是如何失败/成功的，并探索它。
和开发交谈，发现什么是对我们很重要的。

让自动化回归测试套件做它擅长的重复性任务，让敏捷的人类做擅长的思考和处理各种意料之外吧！

基于测程（会话）的测试管理

探索式测试是在 “上下文驱动测试流派” 出现后才流行起来的。基于 session 的测试管理才能保障探索式测试可监督，可度量，也让探索式测试变成一种可以高度训练的习得性能力，而不是一个低门槛的自由测试。

Session，有些书里翻译成测程，有些翻译成会话，鼎叔的专题里默认用第一种翻译。

在测程结束后，我们会分析测程中的三类任务的耗时，以便知道哪个环节花费了更多时间：测试设计&执行，缺陷分析报告，创建章程。

探索式测试和自动化测试的结合

一个理念（来自 Jonathan Kohl），是用交互式的自动化测试来辅助探索式测试，比如自动化地创建测试，产生数据，完成重复性任务，将工作流程自动推进到探索式测试想开始的地方。基于自动化防护的成果之上，再探索更多隐蔽的遗漏缺陷。

我们还可以不断修改自动化测试套件，观察它的执行结果会发生什么不同（这类似于变异测试）。

优秀探索式测试人员的品质

能系统地追踪软件的坏味道。
通过使用预言（基于问题的原则和机制）来认知问题。
善于在时间盒内经常支线漫游探索-side trip
思考专家用户和新手用户会如何使用产品
和业务领域专家，或者技术领域专家一起探索，还可以邀请可用性（用户交互）专家一起来探索
检查有竞争关系的软件，获得启发（竞品软件启发探索法）

角色扮演测试法的启发

从角色扮演测试高手那学到的一些高级做法：

想象用户的一天（这个方法也可以用于用户故事地图的脑爆会，这个将来会介绍）
使用虚构的历史名人或社会名人，想象他们如何使用我们的软件
想象一个想方设法作弊的角色，或者黑客角色
想象购买服务的公司老板角色

用户图形界面以外的探索

不要只依赖于用户界面测试，也可以在其他方向进行整个系统的探索测试，比如：

探索 API 测试：当多个参数一起发生作用时，提供许多可能的变化（模型），有时参数是可选的。另一种场景是改变 API 调用的顺序，从而可能导致结果的改变，暴露用户界面上无法发现的问题。还有一个好处，API 接口可以在软件生命周期的早期进行开发，这意味着对它的探索可以在早期进行。为此，我们可以和开发人员合作实现易用的 API 测试套件。

WEB 服务的探索：在测试计划中预留对用户的服务 SLA 的探索式测试（SLA 即服务水平协议），模仿用户在访问 Web 服务的各种可能方式。

文档质量的探索：从之前的缺陷大扫除活动来看，很多开发及测试人员对于要交付给用户的文档缺乏足够的检查，很容易探索出显而易见的问题。因为文档内容的主观成分很多，自动化完成相关测试是很困难的。我们鼓励结对合作探索其他人员负责的文档，也注意要检查帮助文字的链接结果。

最终文档的质量对于用户体验是很有价值的。

报告的探索：有一类特殊文档，就是报告，对于客户也许很重要。因为报告功能经常放到最后实现，往往质量糟糕。基于用户评价的视角，报告检查应该满足简单、可读、易于理解的质量要求。对于报告的测试，最大的难点不是格式，而是获取正确的数据，有时建议使用生产数据来测试不同的报告版本结果。

探索式测试的辅助工具

短迭代意味着很难有时间进行充分的探索式测试，我们看看有哪些辅助工具能简化探索式测试步骤，并为其他重要的视觉测试留出宝贵时间。

测试设置工具：我们通常发现最耗时间的测试任务就是各种设置，以及正确的初始化。这种操作要进行多次，是使用自动化的好机会。这种工具要能接受不同的输入，一遍遍运行测试场景。通过模仿终端用户的使用方式驱动界面的工具，能让测试结果更有信心。

生成测试数据：这个也不用说，我们探索各种类型的输入数据测试时，这种工具太重要了，可以节约大量成本。

监控工具：把探索式测试中无法在屏幕上展示的错误信息，能够单独告警展示出来，并能够分析具体错误来源，让开发也能直接快速处理。

模拟器：为系统生成具有关键特征行为/类似真实数据的工具，还可以不停得往系统中输入数据，用于探索正常情况下难以出现的极端错误条件，同时缩短这种边界测试的人工准备时间。

仿真器：即复制一个与被测系统的行为完全一致的虚拟新系统，主要用在被测系统和外部系统有大量接口联调的项目，有过这种经历的人都懂。

仿真器可以保持测试和编码一致性，让测试和开发保持进度的一致，避免互相频繁等待对方的更新。仿真器还可以帮助客户深入了解要交付的系统，以便更好地合作，持续改进项目。

最后一句总结：

即使在测试驱动开发实践上非常先进的团队，也无法避免期望的软件行为和其他系统交互时的测试遗漏，强大的面向业务的探索式测试活动能够更好地评价产品，为产品注入价值。