快速搞懂什么是探索式测试

什么是探索式测试
　　

探索式测试（ET，Exploratory Testing）是一种软件测试风格，而不是一种具体的软件测试技术，与敏捷模式相比，敏捷模式有敏捷开发和敏捷测试，而探索式测试是测试专属。

探索式测试强调依据当前待测项目实际情况，选择合适的测试技术，而不局限于特定的测试技术

强调测试者的主观能动性，以及测试设计和测试执行的同时性。

传统的测试流程 “先设计，再测试”，通常是先进行需求分析，再制定测试计划，接着梳理测试点，然后针对测试点设计好测试用例，最后执行测试。这种模式也带来一些问题，比如测试目标不明确的情况、需求变换频繁、输出范围过大等，可能出现测试遗漏，而且在一定程度上也限制了测试思维的发散。　　

而探索式测试的出现，正好弥补了传统测试中出现的这些情况。
目的是探索开发更多不同形态的测试方法，以便改善测试流程。
探索式测试的核心思想
　　探索式测试强调独立测试人员的自由和责任。测试人员应该为个人和团队负责，调动所有能量，发挥人的灵活性，在整体上持续优化个人和团队的产出。
　　探索式测试建议在整个项目过程中，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，并行地执行。实际上，人脑难以并行地执行多项任务。探索式测试旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代，以不断收集反馈、调整测试、优化价值。
　　

探索式测试分类
　　1. 自由式探索式测试
　　自由式，顾名思义就是没有约束，纯粹从使用的角度出发，抛开规则、模式，测试人员可以任意顺序和方式对软件进行使用测试。这种测试通常会被选做冒烟测试用例。
　　2. 基于场景的探索式测试
　　这种测试跟传统的基于场景的测试（场景法）比较像，不同的是，在这种测试中测试人员会扩大测试范围。
　　栗子 1，对某搜索框的测试：
　　传统的场景测试用例可能是：
　　① 输入 “衬衫”，预期结果是搜索到衬衫相关的信息；
　　② 输入 “风扇”，搜索到风扇相关的信息。
　　而基于场景的探索式测试，测试场景可能是：
　　① 输入 “衬衫”，探索搜索结果；
　　② 粘贴 “123@”，搜索结果；
　　③ 输入一个乱码，搜索结果；
　　④ 输入 “衬衫”，搜索结果后返回退到搜索首页再次搜索。
　　栗子 2，批量下载功能测试：
　　传统的场景测试用例可能是：
　　① 点击 “选中全部文件” 按钮，批量下载；
　　② 手动选择要下载的文件，批量下载。
　　③ 测试是否支持跨页批量下载；
　　④ 批量下载的个数：1，2，499，500，501，999，1000，1001……
　　……
　　而基于场景的探索式测试，测试场景可能是：
　　① 点击 “选中全部文件”，再手动取消勾选任意个数的文件，批量下载；
　　② 点击 “全选” 按钮，选中当前页面的所有文件，再切换到另一页手动勾选任意个数文件，批量下载；
　　③ 点击 “选中全部文件”，再取消，再手动勾选任意个数文件，批量下载；
　　……
　　

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

4. 基于反馈的探索式测试
　　反馈指的是当测试人员对被测程序做出指令后得到的响应结果。
　　基于这个结果，测试人员可以调整自己的输入，以期望得到不同的结果。
　　例如：在基于场景的探索式测试的描述中，输入衬衫和风扇会得到不同的搜索结果，而衬衫的搜索结果就是对衬衫这个输入的反馈，风扇的结果就是对风扇这个输入的反馈。
　　

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

进行探索式测试的前提条件
　　团队对产品功能比较熟悉。（比如：做过同类型的软件）
　　已经可以运行的待测软件。（开发人员已经开发完成）
　　

探索式测试在项目中如何落地
　　快速学习需求：基于对软件历史版本的熟悉，对新版本功能快速学习，提出问题并进行澄清。
　　作出测试计划：时间，范围，团队分工等。（以简单表格形式列出）：

利用思维导图形式，列出有哪些模块，覆盖哪些场景，每个场景的注意事项，然后进行评审。
　　探索过程：按照思维导图，执行探索的过程中，根据情况，逐步深挖（也是边执行边学习的过程）每条 Path，更新并记录（做出√或者 × 的标识）执行探索过程中走过的 Path（带着反思去执行测试）。

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

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

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

??视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。??