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

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

• 有无数的惊喜和奇遇在等着你(好比发现惊天大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领导让加的定制化需求。

若是看到代码中有相似的注释，那么说不定这就是值得咱们探索的点。

用户反馈

无论咱们再怎么努力的测试，软件到用户手上，仍是会出现各类各样的问题，缘由不少：软件安装的环境不一样、用户的操做和使用习惯千差万别、软件运行的环境（好比网络情况）不一样。因此多查看用户反馈的平台，也能够帮咱们挖掘出探索测试的点，将他们记录下来。

目标一致性

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

因此在需求评审时、或者常规的用例评审时，能够将制定的探索性测试策略拿出来，和你们同步下，从而让你们对测试策略的认知达成一致，同时你也能够丰富本身的探索性测试策略。

总结

本文主要介绍了探索性测试的基础内容，能够帮你初步的了解到探索性测试是怎么设计的。其实我以为在平时的测试工做中，你们已经有意无心的在用探索性测试的理论了，只是目前仍是以常规的测试为主，尚未达到和探索性测试相辅相成的效果。但愿我能经过【如何作好探索性测试】的这三篇文章，帮助你们优化本身的测试知识体系，同时对我本身来讲也是个升级。下一篇文章会更深刻的来认识探索性测试。