敏捷开发模式下的利刃：探索性测试（ET）--测试用例如何设计？

探索式软件测试是一种强大的黑盒测试思考方法，但却被广泛误解。在某些情况下，它可以比自动化测试更加有生产力。它是一种经过深思熟虑的测试方式，没有测试脚本，可以使你的测试超出各种明显已经测试过的场景。

什么是探索式测试

探索式测试（Exploratory Testing）是一种软件测试方法，也可以说是一种测试思维方法，最先是 Cem Kaner 在 1983 年提出的。这是一种强调个人自由与责任的测试方法，让独立测试人员可以借用不断的学习来改善测试的规划与测试的执行，而在测试的过程中也会同时改善测试案例达到相辅相成的效果。

它的本质是测试策略，边学习、边设计、边测试、边思考。换句话说，探索式测试是测试人员自发进行的测试工作，在执行测试的同时根据所获得的信息来设计测试策略的方法。它强调要根据当前的实际情况来选择最合适的测试技术，进行测试。测试人员使用探索式测试从客户的角度评估软件的实际工作方式。它更注重的是「思考」和「学习」，不断的发现新的问题。

一般在时间相对较紧张，且测试对象说明不完善，即我们常说的「敏捷开发模式」的情况下，探索式测试可以起到突出的效果（但并不是说探索式测试是敏捷模式下特有的软件测试方法）。

为什么探索式测试很重要

采用敏捷开发流程迫使测试团队在更短的时间周期内完成测试。以前需要数周或数月才能测试的团队，现在必须加速测试，以便在几小时或几天内提供更全面的测试结果。因此，必须在极大的时间压力下进行测试，不仅如此还需要减少资源和预算。

由于探索式测试不需要预先进行费时费力的计划，因此团队通常会在开发完成后立即开始测试新功能。这促进了在极短的开发周期内快速检测缺陷。

探索式测试是以用户的角度来测试，它为传统的结构化测试（即从底层开始测试）做了补充，以保护频繁迭代的用户体验。这意味着探索式测试不仅关注系统设计是否良好，还关注用户体验，因此它更容易发现比结构测试更严重的缺陷。

探索式测试正在被越来越多的被应用于用户体验测试。它通常与传统结构化测试形成对比，后者仅侧重于系统逻辑验证（即，是否满足要求/用户故事中概述的验收标准）。结构化测试保障已知风险，而探索式测试主要侧重于分析潜在风险。

虽然不用事先创建测试用例，但是测试人员通过发散性的思维去思考每个模块、每一步甚至每个按钮可能会出现的缺陷问题，可以让测试人员的时间和精力更多地集中在创造性地思维上，发现更多隐藏的缺陷。

比如:

我模拟成为一个用户做一些常用操作，一定可以发现传统测试测不到的 BUG

在发现 BUG 的地方，一定可以发现更多的 BUG

在了解开发的架构后，一定可以找到更隐蔽的更深层的 BUG

……

对于对产品质量有近乎完美的「偏执狂」来说，发散性的思维是一个完美测试人员的利器，一些隐藏的难以发现的缺陷，确实要求测试人员有发散性思维才能比普通的测试看的更多更广更犀利。

探索式测试准备

理解探索式测试有两个前提：

测试之前一定会有一个全局的方针战略，即整体的测试计划，它可以避免走错大方向、该测的部分没有覆盖到或者投入了大量时间到计划之外的部分。

测试一旦开始，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息，指导各自走不同的路径，最终目的就是发现潜藏的缺陷。

探索式测试的类型

探索式软件测试一共分为以下 4 种：

自由式探索式测试

基于场景的探索式测试

基于策略的探索式测试

基于反馈的探索式测试

如何进行探索式测试

从产品需求文档（PRD）和原型等文档中获取需要测试的范围和深度，识别软件的根本目的，确定需要测试的核心功能点。

与项目组产品、开发人员沟通，获取更多业务信息和系统架构信息，以确定更多的风险点。

与其他测试人员沟通，确定风险点最高的模块或功能点。

制定探索式测程（Session）：测程表（Session Sheet）、时间盒（Time Box）、主题（Charter）。（可参见 Session-Based Test Management）

执行探索式测试计划，在此过程中边测试、边学习、边设计、边思考，并根据具体情况随时更改测试策略。

测试的过程中记录软件逻辑，发现 BUG，给开发人员建立缺陷。

基于旅行者的全局探索性测试方法

我们可以将软件的测试比做是去一个城市的旅游。那么我们如何快速的去到我们想去的地方呢？一个办法就是我们对这个城市很熟悉。另外一个办法就是找一个导游或者一份地图，用来指导我们去在这个城市旅游。

对于软件测试来说，我们同样需要对被测软件很熟悉，同时也需要一份测试地图或者测试指南，来帮助我们更好的探索性测试。

拿到地图后，我们可以根据地图将城市按照功能分为各种区域，而每个区域对应软件相应的功能。比如：

商业区：销售特性，对应软件包装上面的对应特性，类似我们的需求。

历史区：继承特性，上一个版本遗留下来的代码、问题或则曾经出现多次 BUG 的功能或者特性。

旅游区：噱头特性，即对应产品的新特性，能够去更好的吸引新的用户。

娱乐区：辅助特性，对应软件的辅助特性和功能，可以做完补充测试。

旅馆区：平台或维护特性，对应软件内部的一些交互，不一定是由用户来触发的。

破旧区：问题高发区，对应软件的历史稳定的代码，一般很少人去接触。

每个区都有特定的测试方法，有兴趣的朋友可以去买『探索式软件测试』这本书详细了解。

这里我们拿「Web 应用升级部署」来实践该方法。

首先，我们先了解需要测试的模块、功能点以及相关的内部逻辑。

然后，我们根据项目的时间确定本次测试的主题和范围，创建一次探索式测试计划，如下图：

执行探索式测试计划，在测试的过程中按照旅行者测试方法的思路来创建用例：

按照旅行者测试方法的区域写出当前区域可能会发生的问题，然后套用每个区域的方法引申出更多的潜在问题，并依此进行测试。

记录用例的测试结果：

测试完毕

哪个测试点出了问题，那么我们就应该重视该问题，并在此基础上发散，比如：

「系统重启后应用无法启动」，我们知道了是因为磁盘没有挂载，导致启动失败，那么服务器防火墙被重置是否也会造成无法启动呢？那么这个问题将在下次测试的时候执行。

最后，来看下我们的探索式地图的设计：

可以看到通过探索性测试方法已经分析出来了一些测试点，探索性测试另外一个重要的地方就是边测试边写测试点，过程中不断分析、不断学习，然后行程新的探索性测试点，这样才能完成一次成功的探索性测试。

另外还有局部探索式测试和混合探索式测试方法，本文因篇幅问题将不展开论述。

结论

探索式测试试图把制定计划，进行测试，重新制定计划等多个过程有机地结合起来，每次只前进一小步，但这每一步都是由软件过去和当前的运行状况，软件在测试时表现出来的各种行为和软件运行时留下的种种蛛丝马迹来即时确定的。有效地利用探索式测试技术可以帮助我们发布一个高质量的软件产品。

原文转自：http://www.uml.org.cn/Test/201812113.asp