前不久国庆档上映的一部电影《登山者》，相信大家都已经看过了，在剧中，中国登山队那种不畏困难，勇于探索未知领域的精神着实让人敬佩，特别是最后一刻吴京饰演的方五洲带领队员，终于再次登顶。如果单纯的从事务的本质来看，探索未知区域（比如登山探险）和探索软件有非常多的共通点：

顺着这个思路，计划写三篇关于探索性测试的文章（理论篇、深入篇、情景实践篇），在写文章的过程中，参考Elisabeth Hendrickson的一本书《探索吧，深入理解探索式软件测试》。文章理论知识偏多，所以看上去会比较枯燥，不过我会在文中加一些小案例，方便大家理解，现在让我们一起进入探索测试的世界吧。

常规测试和探索性测试的关系

所谓的常规测试，指的是我们常规思路的测试：尽可能的写测试用例、依照测试用例执行测试。而探索性测试指的是针对要测试的产品，选定一个模块/方面，选择很多可能变化的点（变量），然后深入进去，挖掘潜在的问题，举个例子：很多产品都有保存图片或文件的需求，这就牵扯到保存文件的路径，这里文件路径就是个变量，我们基于文件路径这一因素，可以提出很多可探索的点：

我觉得所有的软件测试工程师，都有这样的经历，无论自己的测试用例写的多么完善，只要产品上线，就会有大大的惊喜在等待你。那是不是常规测试就不重要呢？换句话说，我们是不是应该更多的进行探索性测试来替代常规测试。其实不然，常规测试和探索性测试是相辅相成的关系，如下图所示：

常规测试就如同上图中的网，而探索性测试则要覆盖网无法覆盖的区域（也就是网格），两者只有全部兼顾到，才能保证产品的质量。一个完善的测试策略应该能融合两种方式做到兼容并包：已测试=已检查+已探索。

探索性测试策略

与写测试用例一样，探索性测试也有对应的设计模板（姑且称之为探索性测试用例模板吧），其实写测试用例的思想（比如边界值、等价类）完全适用于探索性测试。但是需要注意的是，探索性测试的用例不会像一般测试用例那样具体，我们下面通过例子再来详细说明，通常来讲探索性测试的设计包含下面三要素：

优质的探索性测试策略

先来看一个比较差的探索性测试策略：

目标：探索编辑姓名
资源：使用输入值 “xuan‘ke”
信息：为了发现【编辑姓名的功能】是否能处理名称里包含’的情况

大家对上面的策略熟悉吗？其实这就是一个比较具体的测试用例，只不过换了一种形式。接下来我们再来看一个比较正常的探索性测试策略：

目标：探索浏览器输入的地址
资源：使用javascript和sql注入式攻击
信息：为了发现系统的安全弱点信息

可以看到上面的测试策略并没有说明，需要具体使用什么javascript脚本或者什么sql语句注入，而是提供了某一个方向或者灵感，剩下的工作需要你自己去探索和尝试。

工作中应该如何挖掘探索性测试的点

为了大家能找到有价值的探索性测试点，这里帮大家归纳几个可以寻找测试点的思路。

需求评审

需求评审是挖掘探索性测试点的理想时机，下面举个例子（例子中人员角色：Alex是软件测试工程师、Pat是开发工程师、Binh是业务分析师）：

Alex针对上面的对话情况，制定了如下的测试策略：

目标：探索编辑档案
资源：使用非法用户名
信息：为了发现用户名限制规则未被触发的情况

所以之后的需求评审中，我们又多了一件可以做的事情，可以尝试去发现针对产品可探索性测试的点。

隐性期待

产品经理和开发工程师思考问题的角度是不一样的，所以必然会存在这样的状况：每个人从自己的角度考虑，觉得某些事情或需求点太简单了，不需要再提。但往往是这些隐性期待，造成了沟通障碍，等到最终产品将要上线时，才发现大家对需求的理解都不一样。

举个例子，比如：在开发某一款app时，产品经理期望能打开app就使用某个特别高大上的功能，它的隐性期待是加这个功能不会影响app的启动速度、包的大小等。但是等到开发完成时发现加上这个功能后，app启动速度慢了将近10s，这显然是不能够接受的。虽然产品经理需求文档中并未提及对app的启动速度影响，但是你得尝试发现这些值得探索的隐性期待，将它们加入我们探索测试的策略中。

有意义的变量

在一个软件/系统中，会存在很多变量，而这些变量是可以作为我们探索的点，下面列出需要注意的变量：

上面提到的这么多变量，你可以结合自己的产品特性来选择变量作为自己探索测试的策略。

源代码

如果你还没有源代码的权限，一定要问开发要一个“测试”的代码权限。看代码的注释是特别欢乐的事情，而这些注释也能帮我们发现探索测试点，比如以下注释：

如果看到代码中有类似的注释，那么说不定这就是值得我们探索的点。