五分钟搞懂探索式测试

“阅读本文大概需要5分钟。

你好，我是测试蔡坨坨。

今天，我们来聊一聊探索式测试。

什么是探索式测试

• 探索式测试（ET，Exploratory Testing）是一种软件测试风格，而不是一种具体的软件测试技术，与敏捷模式相比，敏捷模式有敏捷开发和敏捷测试，而探索式测试是测试专属。
• 探索式测试强调依据当前待测项目实际情况，选择合适的测试技术，而不局限于特定的测试技术。
• 强调测试者的主观能动性，以及测试设计和测试执行的同时性。 传统的测试流程“先设计，再测试”，通常是先进行需求分析，再制定测试计划，接着梳理测试点，然后针对测试点设计好测试用例，最后执行测试。这种模式也带来一些问题，比如测试目标不明确的情况、需求变换频繁、输出范围过大等，可能出现测试遗漏，而且在一定程度上也限制了测试思维的发散。 而探索式测试的出现，正好弥补了传统测试中出现的这些情况。
• 目的是探索开发更多不同形态的测试方法，以便改善测试流程。

探索式测试的核心思想

• 探索式测试强调独立测试人员的自由和责任。测试人员应该为个人和团队负责，调动所有能量，发挥人的灵活性，在整体上持续优化个人和团队的产出。
• 探索式测试建议在整个项目过程中，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，并行地执行。实际上，人脑难以并行地执行多项任务。探索式测试旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代，以不断收集反馈、调整测试、优化价值。

探索式测试分类

1. 自由式探索式测试

自由式，顾名思义就是没有约束，纯粹从使用的角度出发，抛开规则、模式，测试人员可以任意顺序和方式对软件进行使用测试。这种测试通常会被选做冒烟测试用例。

2. 基于场景的探索式测试

这种测试跟传统的基于场景的测试（场景法）比较像，不同的是，在这种测试中测试人员会扩大测试范围。

栗子1，对某搜索框的测试：

• 传统的场景测试用例可能是：① 输入“衬衫”，预期结果是搜索到衬衫相关的信息；② 输入“风扇”，搜索到风扇相关的信息。
• 而基于场景的探索式测试，测试场景可能是：① 输入“衬衫”，探索搜索结果；② 粘贴“123@”，搜索结果；③ 输入一个乱码，搜索结果；④ 输入“衬衫”，搜索结果后返回退到搜索首页再次搜索。

栗子2，批量下载功能测试：

• 传统的场景测试用例可能是：① 点击“选中全部文件”按钮，批量下载；② 手动选择要下载的文件，批量下载。③ 测试是否支持跨页批量下载；④ 批量下载的个数：1，2，499，500，501，999，1000，1001…… ……
• 而基于场景的探索式测试，测试场景可能是：① 点击“选中全部文件”，再手动取消勾选任意个数的文件，批量下载；② 点击“全选”按钮，选中当前页面的所有文件，再切换到另一页手动勾选任意个数文件，批量下载；③ 点击“选中全部文件”，再取消，再手动勾选任意个数文件，批量下载；……

3. 基于策略的探索式测试

这是一种比较依靠经验的测试方法，简单来说就是测试老手，融合自己的经验、技能、感知等条件，结合自由式探索式测试，用自己积累下来的知识来指导测试，是一种经验结合随机性的测试。（类似于编写测试用例时用到的错误推断法，基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例。）

4. 基于反馈的探索式测试

反馈指的是当测试人员对被测程序做出指令后得到的响应结果。

基于这个结果，测试人员可以调整自己的输入，以期望得到不同的结果。

例如：在基于场景的探索式测试的描述中，输入衬衫和风扇会得到不同的搜索结果，而衬衫的搜索结果就是对衬衫这个输入的反馈，风扇的结果就是对风扇这个输入的反馈。

什么样的项目适合进行探索式测试

1. 软件需求说明书SRS（Software Requirements Specification）不完善，时间紧迫，没有测试用例的情况下，以ET快速完成版本新功能的测试。 作用：更快设计，更快执行，更低成本。
2. 系统测试完成之后，还有剩余时间的情况下，以探索式测试作为补充，尝试系统测试覆盖不到的场景，从而减少漏测，提高测试覆盖率。

进行探索式测试的前提条件

1. 团队对产品功能比较熟悉。（比如：做过同类型的软件）
2. 已经可以运行的待测软件。（开发人员已经开发完成）

探索式测试在项目中如何落地

1. 快速学习需求：基于对软件历史版本的熟悉，对新版本功能快速学习，提出问题并进行澄清。
2. 作出测试计划：时间，范围，团队分工等。（以简单表格形式列出） 模块时间测试人员注册登录模块6.23 - 6.24张三新增博客模块6.23 - 6.25李四博客浏览评论6.23 - 6.25王五
3. 利用思维导图形式，列出有哪些模块，覆盖哪些场景，每个场景的注意事项，然后进行评审。
4. 探索过程：按照思维导图，执行探索的过程中，根据情况，逐步深挖（也是边执行边学习的过程）每条Path，更新并记录（做出√或者×的标识）执行探索过程中走过的Path（带着反思去执行测试）。

1. 提交缺陷：把探索式测试过程中发现的缺陷提交到缺陷管理系统中，修复后回归。
2. 报告总结：以简单的表格，对BUG的分布，数量，级别，进行统计和报告。（测试报告）

PS：探索式测试主要还是依赖对领域的认知，需要有一定的经验积累，这个其实大部分初学者，或者经验不够老道的很难掌握好。

以上，完。

脚踏实地，仰望星空，和坨坨一起学习软件测试，升职加薪！