探索式测试

什么是探索式测试？

探索性测试，最早是由测试专家 Cem Kaner 博士在 1983 年提出的，并把它定义为一种软件测试风格，而不是一个具体的测试技术，如边界值分析方法，因果图等。探索式测试是一种强调测试人员的自由和责任以不断优化其工作价值的测试方法，它强调将测试相关学习、测试设计、测试执行和测试结果解读作为相互支持的活动，在整个项目过程中并行执行。

所以与其说探索性测试是一种测试方法，不如说它是一种基于”实践->反馈->实践“的思维方式。

探索式测试与传统测试

探索式测试天然适合周期短的敏捷研发，它与敏捷原则更加契合。这是计划式测试所不具备的。其次探索式测试还有其它一些体现敏捷思想的地方，比如和敏捷轻文档一样，探索式测试不再要求详细的测试用例文档。

传统的计划式测试一般会分为两个阶段：第一阶段根据需求、标准、测试规范等文档先输出测试计划、测试用例等测试交付件；第二阶段则根据之前准备好的测试用例由本人或者他人对被测系统进行操作来执行测试，最终输出测试报告、缺陷报告等。如下图：

而探索式测试只有一个阶段，测试人员根据一切可能掌握的信息和资料，针对被测系统进行学习，在学习的同时一边设计测试要点一边进行测试，最终得到相关测试结果。如下图：

除了测试过程不同以外，在测试原则和测试重点方面也有一些差异，如下：

1、测试人员的作用：

• 探索式测试：强调测试人员在测试过程中的主观能动性，要求测试人员具备较强的问题发现和解决能力、分析和评估能力、沟通和协作能力等。
• 传统测试：测试人员主要负责执行测试脚本，对测试过程的创造性和主观判断较少。

1. 适应性和反应速度：

• 探索式测试：具有较强的适应性和反应速度，能够针对不断变化的软件需求、功能、性能以及测试环境，快速调整测试策略和用例。
• 传统测试：适应性和反应速度相对较弱，因为测试脚本的修改和更新需要时间和成本。

2. 测试覆盖面和全面性：

• 探索式测试：由于测试过程的自由和灵活性，探索式测试可以更全面地覆盖软件的各个方面，从而发现更多的潜在问题。
• 传统测试：测试覆盖面和全面性受限于预先定义的测试脚本。如果测试脚本没有涵盖到某些方面，可能会遗漏一些问题。

3. 测试效率和成本：

• 探索式测试：测试效率和成本因测试人员的技能、经验和直观感觉而异。探索式测试可能在短时间内发现较多问题，也可能需要较长时间才能发现问题。
• 传统测试：测试效率和成本相对较稳定，因为测试过程由预先定义的测试脚本指导。

探索式测试方法

探索式测试方法分为局部测试法和全局测试法

１、局部测试法

我们首先会对软件的单一功能进行比较细致的探索式测试。“探索”的过程主要是基于功能需求以及非功能性需求进行扩展和延伸。

比如以软件系统的用户登录功能为例，作为探索式测试人员，首先应该站在最终用户的角度去理解和使用登录功能。为此，探索式测试人员需要分析出用户登录功能的所有原子输入项。假定原子输入项只有用户名、密码和登录按钮。接着组合这些原子输入项构成最基本典型的测试场景。

再比如，用真实合法的用户名以及密码完成登录就是一个非常基本典型的场景，如果该场景能够成功登录，就可以切换到下一个；如果该场景不能够成功登录，就需要去“探索”为什么没能登录成功，比如你可能会怀疑是否是因为用户名或者密码是区分大小写的，又或者是不是因为你多次错误的尝试而导致的。

基于你的怀疑，进一步去设计新的测试用例来验证你的猜测。总之，通过以上这样的“探索”过程，你将测试学习、测试设计、测试执行和测试结果评估串联成了一个快速迭代的过程，并在你脑海中快速建立了登录功能的详细模型。

２、全局测试法

《探索式软件测试》一书中提出了一个让所有人感同身受的隐喻——“旅行者漫游一个城市”，来形容测试人员对产品的整体探索模型。

对于旅行者，根据不同的职能，可以把城市划分为多个不同的区域，我们可以用不同的颜色来指代，旅行者在每个区域的探索策略是不同的。

与此类似，测试人员在探索产品功能时，也可以把整个产品划分为不同的职能区域，采用不同的测试方法来探索。

商业区	商业活动地：程序展示的特性功能
历史区	探秘历史古迹：遗留代码测试
旅游区	只有旅游者才感兴趣：新用户喜欢
娱乐区	消磨时间的休闲：辅助特性，补充计划
旅馆区	晚上休息：软件“休息”是仍在忙碌
破旧区	令人讨厌的治安风险地区：挖掘漏洞

同理，我们也可以自定义更多的分区来做探索的策略指南。

每个分区，也会衍生出一系列的更有指导性的具体探索操作法，甚至可以把探索方法衍生出不同场景的变种，类似游戏中的技能组合，乐趣油然而生，如图所示。

探索式测试衍生

如果按照定义的探索测试方法去执行，随着时间的推移，能发现的缺陷数量会急剧减少。不同的测试人员，用同样的探索方法，找到的问题数量和质量可能完全不同！

如果执行中缺乏细致的思考，灵活的变通，可能就与旅程中的缺陷擦肩而过。反之，掌握场景中的丰富变化手段，可以帮助我们持续地高效挖掘缺陷或体验问题。

如何更好地引入过程中的变化？

借鉴数据库基本操作CRUD（创建、移动、更新、删除），我们可以对测试过程中的各个要素进行CRUD。这些关键要素，我们可以称之为“变化因子”。

• 测试环境，包括硬件，OS版本，软件版本，网络配置，依赖组件等，是不是都可以替换，或者故意被设置故障？
• 操作步骤，是否可以重复，跳过，插入新步骤？从一个测试场景，跳到另一个测试场景，再回来继续步骤？
• 测试数据：是否可以增加、删减、更新？在升级/失败后是否还正常保留？

如图所示：

总结

在探索性测试中，测试人员不断地提出假设，用测试去检验假设，通过解读测试结果来证实或推翻假设。在这个过程中，测试人员不断完善头脑中被测试应用的模型，然后利用模型、技能、经验去驱动进一步的测试。

探索性测试是带着“反思”的学习和优化过程，其目的是为了持续优化其工作的价值，这和精益生产、敏捷软件开发的理念高度一致，这也是探索性测试受到敏捷团队欢迎的原因之一。

探索性测试旨在将测试学习、测试设计、测试执行和测试分析做为一个循环快速地迭代，在较短的时间内（如1个小时）完成多次循环，以不断收集反馈、调整测试、优化价值。该思路更是与敏捷软件开发小步快跑、持续反馈的理念不谋而合。

探索性测试，无论它是否应用于敏捷项目，其本质是敏捷的。通过测试逐渐学习产品，并让所学信息指导测试实践，这无疑符合敏捷价值观：工作的软件和响应变化。