【测试理论】如何做好探索性测试—基础篇

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

• 有无数的惊喜和奇遇在等着你(比如发现惊天大bug)


• 探索中，你可以借助于工具。


• 探索有时候是欢乐之旅，有时候却艰苦跋涉，有时候你则是如履薄冰（很多时候，惊喜的bug总是在上线后才暴露出来）。


• 若手上的地图和探索的未知区域不符时，应该相信未知地域（要相信自己发现的问题）。

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

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

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

• 选择的文件路径没有权限。


• 选择的文件路径下有相同的文件。


• 文件路径所在磁盘空间，是否够用。

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

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

探索性测试策略

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

• 目标：你要探索何处？它可能是一个特性，一个需求或一个模板。


• 资源：有什么资源是你可以用的？某个工具、数据集、技术、配置等。


• 信息：你希望找到什么有用的信息/结果？可以说明系统的安全性、性能、稳定性等。

优质的探索性测试策略

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

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

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

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

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

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

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

需求评审

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

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

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

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

隐性期待

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

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

有意义的变量

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

• 可计数的东西：这个很好理解，比如：用户登录次数、操作次数、存储文件的数量等，通常可以用一些特别的数字作为探索点：0，1，多，过多，过少。


• 相对位置：位置有“开头—中间—结尾”的纬度，比如：在一个列表中，操作最后一条可能有问题、操作中间某一条和操作第一条都不会有问题。


• 文件和存储：文件存储牵扯到了路径，比如：将你的某个文件保存到不同的目录（权限问题等）就可能会出现问题。


• 地理位置：地理位置包含一些逻辑上的位置，比如：时区、海拔、邮政编码等。


• 格式：在程序中的很多东西都有格式，比如：日期、邮寄地址、文件路径、URL、文件内容、信息等等。而这些格式都可以被改变，来进行探索。


• 大小：在程序中文件是有大小的，比如：图片、配置文件、上传的各种文件。


• 深度：在程序中任何带有层级的东西都有深度，比较常见的有XML配置文件、带括号的运算操作、程序中的循环。


• 时间点、频率和持续时间：在程序中频率和持续时间，是比较容易发现问题的变量因素，比如：你用monkey对某个app做稳定性压力测试、快速的滑动某个页面有可能造成crash，或者你可以试试，让你的程序运行一晚上或者更长时间来验证问题。


• 输入和导航: 比如：你在输入的时候可以复制粘贴，也可以直接输入；在关闭弹窗时，你可以点击屏幕上的按钮，也可以使用快捷键，这些都是变量。

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

源代码

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

• 我也不知道为什么这么做行得通，但是它就是可以了，千万别动它。


• 也不知道哪个龟儿子写的代码，看不懂，修改了下，先用着吧。


• 这是xxx领导让加的定制化需求。

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

用户反馈

不管我们再怎么努力的测试，软件到用户手上，还是会出现各种各样的问题，原因很多：软件安装的环境不同、用户的操作和使用习惯千差万别、软件运行的环境（比如网络状况）不同。所以多查看用户反馈的平台，也可以帮我们挖掘出探索测试的点，将他们记录下来。

目标一致性

上面提到了几种探索性测试策略的发现的点，但是也需要注意，你找到的可探索测试的点，需要和开发工程师、产品经理保持目标一致，否则会浪费你的时间。举个例子：你将切换程序所在的时区作为一个探索点，花费大量时间在验证切换时区之后的影响，但是最后产品经理告诉你，我们的程序只可能在中国使用。

所以在需求评审时、或者常规的用例评审时，可以将制定的探索性测试策略拿出来，和大家同步下，从而让大家对测试策略的认知达成一致，同时你也可以丰富自己的探索性测试策略。

总结

本文主要介绍了探索性测试的基础内容，可以帮你初步的了解到探索性测试是怎么设计的。其实我觉得在平时的测试工作中，大家已经有意无意的在用探索性测试的理论了，只是目前还是以常规的测试为主，还没有达到和探索性测试相辅相成的效果。希望我能通过【如何做好探索性测试】的这三篇文章，帮助大家优化自己的测试知识体系，同时对我自己来说也是个升级。下一篇文章会更深入的来认识探索性测试。