探索性测试02-探索性测试实践

        在我了解了探索性测试的定义和基本方法之后，付诸实践成为了最重要的课题。在探索性测试的时间过程中，我遇到过一些问题，也有过一些思考，例如：

        1、何时开展探索性测试比较合适？

        2、如何设计探索性测试用例？

        3、探索性测试的意义？

一、何时开展探索性测试比较合适？

        探索性测试的用例设计和执行不需要太早。

        1、探索性测试用例设计

        应该在功能测试执行阶段进行。假设功能包含两轮，那么探索性测试用例设计至少安排在一轮功能测试完成之后，或者是二轮功能测试之中。

        2、探索性测试用例执行

        可以在二轮功能测试中穿插执行，或者在二轮功能测试之后执行。

        好处是功能测试之后，我会对模块的业务目标、使用场景、使用方式有更深入的了解，有助于我深入探索和挖掘已有用例中缺失的、可能仍然存在问题的测试场景。

        探索性测试用例数目一般不会太多，可以在整个过程中不断地进行补充和优化。

二、如何设计探索性测试用例？

        在设计探索性测试用例时，我会集中关注以下几个方面：

        1、bug清单中的复杂场景

        在设计探索性测试用例时，我会在bug库中检索所有的bug清单（不限于当前版本，也不限于正在测试的功能），从中筛选一些复杂场景。

        这里我提供一个快速筛选的小技巧：

                ① 重点查看名称较长的bug；

                ② 重点查看名称中包含“先……再……”句式的bug；

        接着讲这些bug的思路举一反三到自己正在测试的功能上（假设正在测试的功能为X），例如：

                ① 前提：任务A的创建依赖与资源B

                     原bug：已有资源B，创建任务A的过程中删除资源B，……

                     拓展用例：已有资源X，创建任务A的过程中删除资源X，……

                                       已有资源B，创建任务X的过程中删除资源B，……

                ② 原bug：系统管理员创建A，操作员1对其进行操作后，操作员2又对其进行其他操作

                     拓展用例：系统管理员创建X，操作员1对其进行操作后，操作员2又对其进行其他操作

                ③ 原bug：创建A时，第一次写错某个参数提交报错，修改正确后第二次提交，……

                     拓展用例：创建X时，第一次写错某个参数提交报错，修改正确后第二次提交，……

        2、与其他模块的交互

        在功能测试用例设计时，惯常的策略是以当前功能为主、交互功能为辅。即使考虑到了模块交互，也很有可能存在遗漏。

        所以，模块交互是探索性测试的一个重点方向。

        很常见的场景有，与告警模块的交互、与监控模块的交互等等。

        3、深入需求文档中的模糊点

        在功能测试用例设计时，不免会遇到这样的情况：

                ① 用例设计时间紧张，导致需求文档中的一些模糊点没有明确；

                ② 产品经理告知需求中的某个细节以开发实现的效果为准；

        基于这些模糊点，测试人员可以深入挖掘一些测试点，无论从产品的角度或是用户的角度。

三、探索性测试的意义？

        就如上一篇博客 《探索性测试01-什么是探索性测试》所说，探索性测试是一种测试理念，是一种基于"实践->反馈->实践"的思维方式。探索的意义在于思考不曾想过的、尝试不曾做过的，拓展产品的边界，同时也在拓展自己思维的边界。