敏捷测试转型 聊聊产品的局部探索和全局探索

作者

鼎叔

---

敏捷测试转型

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷，到敏捷测试技术的丰富实践，从一线团队的视角来聊聊我们是怎么做的。面向未来，拥抱敏捷原则，走向高效能组织

32 文章

1 精华

116 粉丝

---

这是鼎叔的第三十一篇原创文章。

行业大牛和刚毕业的小白，都可以进来聊聊。文章源自玩技e族-https://www.playezu.com/239654.html

欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出。文章源自玩技e族-https://www.playezu.com/239654.html

经典的探索式测试理论给我们带来了如何探索产品的思路，包括探索局部功能和探索产品整体，用隐喻的方式给我们提供发挥创意的思考角度。
《探索式软件测试》是最有影响力的探索式测试书籍，作者 James Whittaker 在其中重点阐述了两个层次的探索式测试方法：局部探索和全局探索。
我们简单回顾一下对经典理论的理解，再注入鼎叔在实践中的一些思考。文章源自玩技e族-https://www.playezu.com/239654.html

本文是探索式测试第二篇文章。
第一篇回顾：聊聊什么是探索式测试 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483943&idx=1&sn=18546dc32de6ba632462b9e66d5a5e34&chksm=c24fb745f5383e5396d83da0cd9f7be004ed9471aa35302e8ba0ba9993189dfb133f03a95606&token=653382881&lang=zh_CN#rd文章源自玩技e族-https://www.playezu.com/239654.html

局部探索
即不知道很多背景信息就可以完成的局部探索简单任务，举例如下。
一个输入框，如何测试？
特定的用户数据，如何测试？
一个软件（模块）的特定状态，如何测试？
一个特定的运行环境下，如何测试？文章源自玩技e族-https://www.playezu.com/239654.html

以输入框测试为例，通常有三个子阶段可以探索逻辑是否正常。
输入筛选器是否正常，错误输入是否根本就输不进去？
输入检查，刚输入的错误数据，一回车就提示错误，要求重新输入。
输入成功了，在运行的时候抛出错误。文章源自玩技e族-https://www.playezu.com/239654.html

那是不是涵盖了这三个子阶段的测试覆盖，就高枕无忧了呢？
非也，还需考虑：不同的输入值，是否会互相影响，导致新问题？不同输入值的不同输入顺序，是否会带来错误？
通过深入探索不同维度的输入可能性，找到完整覆盖集合的思路可以不断扩展！
这就是探索的魅力。文章源自玩技e族-https://www.playezu.com/239654.html

再举一个典型的局部探索的例子：被测产品的内部状态。
在不同的前提条件和触发事件下，产品会被内部定义或者改变为不同的状态，而测试人员应该覆盖的，就是不同状态的迁移过程是否正确，我们可以探索遍历每两个状态能够切换的场景和触发条件，查看新状态表现是否正常，也可以单纯的在某个状态中等待超时发生。为了强调这种遍历测试的价值，我们可以把这个局部探索方法命名为 “状态遍历探索法” ，如图所示。

全局探索
全局探索，James Whittaker 用了一个让所有人感同身受的隐喻——“旅行者漫游一个城市”，来形容测试人员对产品的整体探索模型。
对于旅行者，根据不同的职能，可以把城市划分为多个不同的区域，我们可以用不同的颜色来指代，旅行者在每个区域的探索策略是不同的。

与此类似，测试人员在探索产品功能时，也可以把整个产品划分为不同的职能区域，采用不同的测试方法来探索。文章源自玩技e族-https://www.playezu.com/239654.html

比如
首次来到一个城市旅行，通常要到热门景点打卡，这些区域就是城市的 “商业区”。而软件产品的各种卖点功能，即所谓的商业价值，也是商业区，这里的测试重点是卖点特性功能。
城市里没有热门景点的传统老区，游客可能也会偶然光顾，我们把它划分为 “历史区”。对应的，产品的老版本功能，如今已经不产生吸引力了，但仍然能在用户触达时发挥作用，这就是历史区，我们测试的是遗留代码。
旅行者也会有自己的喜好和特征，可以针对不同类型的旅行者进行分区。
继续举例：
针对第一次来的游客，他们往往对各种新鲜功能感兴趣，因此可以把这些功能纳入 “旅游区”。
而老居民，以及随意型的新游客，也许只是想在城市中找找娱乐设施，好好地放松下，我们可以把相关探索区域划为 “娱乐区”。
此外，还可以把 “旅馆区” 暗喻成并没有实际操作的场景（如后台长时间挂起），把 “破旧区” 暗喻成针对漏洞重灾区的挖掘，如图所示。

James Whittaker 提供了让人眼前一亮的启发思路，还可以这么划分测试策略！
但是这个分区到底是指产品功能分区，还是指一个细化的测试风格，并没有严格定义。也许探索式测试就是鼓励混搭，传递的是轻松交流的观念，而非制定规范。
同理，我们也可以自定义更多的分区来做探索的策略指南。
每个分区，也会衍生出一系列的更有指导性的具体探索操作法，甚至可以把探索方法衍生出不同场景的变种，类似游戏中的技能组合，乐趣油然而生，如图所示。

具体的探索法可以多达二十种以上，就不一一解释了，但是我们更关注如何选取和衍生适合自己业务的探索法。

探索式测试方法的选取和衍生
在为自己团队挑选最合适的探索方法时，特别关注以下几点。
1 选择你们团队喜欢的名字
不同文化，不同经历，不同业务的人，可以针对探索式测试方法的名称做一定的修改，最终目的还是起一个易于团队内部交流的名称。
比如 “苏格兰酒吧测试法”，经典意思是深入了解用户的抱怨，或者阅读产业博客，找到针对性的探测路径。但是我们可以把名称改为 “微博测试法”“差评测试法”，更容易在国内团队传播。

1. 以人为本 探索式测试也是一个以人为本的测试风格（这也是本书的主旨之一，很多章节都有体现），测试工程师的传统技能考察的是逻辑严密，心细如丝。 但人就是多种多样的，不管是用户，还是测试人员，都有不同的脾气和爱好，为什么不用来在测试中任性一把呢？ 测试的要义是以挖掘出失败为价值，而非以完成测试为价值。

下面介绍几种常用的基于不同角色性格的测试方法。
反叛测试法，作为一个天生叛逆者，产品越不让我做啥，我就做啥。软件升级警告不能断网，我偏把网断了。
懒汉测试法，作为一个超级宅男，能不动我就不动，什么都不填写，直接提交。（还真的经常发现空输入导致 crash 的 Bug，汗）
强迫症测试法，每个人都可以是强迫症，习惯均不同，我就喜欢反复的按开关，按排序，而且速度贼快！
超模测试法，作为一个眼里容不得沙子的人，拿着放大镜看美女……呃，图片，以及各个 banner 边界细节，找到瑕疵。
质疑测试法，作为一个喜欢质疑别人的人，在卖点功能的演示中，我故意挑毛病，打断正常操作，引入别的功能演示。

你是什么样的性格，适合什么样的探索法？图片图片图片

3.** 衍生新的探索方法 **
很多探索测试方法虽然名称不同，但是都是从同一个理念中衍生或变异出来的，衍生新的探索方法主要基于以下原理，我们可以细心领会。
1) 举一反三，既然有出租车测试法（测试到达指定目的地的所有路线），那相对，就可以有出租车禁区测试法（验证用户所有路径都无法到达该目的地 - 禁区）。

2) 本地化，上述苏格兰酒吧测试法就是很好地适应本地文化的例子。

3) 递进，超模测试法，看很仔细还不够，我们递进为 “放大缩小测试法”，刻意把屏幕字体调到最大，把画面拉伸到最大，看看会不会发生扭曲，甚至显示失败？

4) 从业务特征中提炼，比如你负责的业务是海外业务，那你最常遇到的可能是区域语言设置问题，那就可以衍生出 “区域设置测试法”，养成大家经常修改区域的测试习惯。如果你负责的是智能语音业务，你可以衍生出 “变声测试法”，模拟不同人的发声来进行语音识别测试：性别、年龄、方言、语速、尖细或粗旷，等等。

5) 从业务常见缺陷中提炼，正如之前章节提到，我们定期对遗漏缺陷作根因分析和聚类，从最常见的缺陷场景中寻找克敌的探索方法。比如手机的暗色模式，经常会引发各个产品的页面适配问题，我们就可以衍生出 “暗色模式测试法”，作为专项探索测程即可，但又不至于把所有场景都加上暗色模式的测试用例，以免导致用例太繁多。

在探索过程中引入变化
如果按照定义的探索测试方法去执行，随着时间的推移，能发现的缺陷数量是否急剧减少？
不同的测试人员，用同样的探索方法，找到的问题数量和质量可能完全不同！
如果执行中缺乏细致的思考，灵活的变通，可能就与旅程中的缺陷擦肩而过。反之，掌握场景中的丰富变化手段，可以帮助我们持续地高效挖掘缺陷或体验问题。

如何更好地引入过程中的变化？
借鉴数据库基本操作 CRUD（创建、移动、更新、删除），我们是不是可以对测试过程中的各个要素进行 CRUD？这些关键要素，我们可以称之为 “变化因子”。
测试环境，包括硬件，OS 版本，软件版本，网络配置，依赖组件等，是不是都可以替换，或者故意被设置故障？
操作步骤，是否可以重复，跳过，插入新步骤？从一个测试场景，跳到另一个测试场景，再回来继续步骤？
测试数据：是否可以增加、删减、更新？在升级/失败后是否还正常保留？

有时我们会发现，一点点地改变现状，可以挖掘出意想不到的问题，如图所示。

另一方面，针对被测对象的特征，可以在引入变化中加以挖掘。借鉴另一本探索式测试经典作品《探索吧！深入理解探索式软件测试》（Elisabeth Hendrickson 著），我们可以引入下列启发变化的方法。
0、1、多启发法：对于可计算的测试对象，测试数量为 0，1，极多的时候。
部分，全无，全有启发法：对于可勾选的测试对象，如配置选项测试，选择部分勾选，全不勾选或全部勾选。
开始，中间，结束启发法：对于有相对位置概念的测试对象进行位置操作探索，如音乐歌单列表。
格式规范启发法：对于有具体格式要求的字段，是否涉及格式转换或前后端数据传递，是否有强制转换导致数值误差或者处理异常，是否涉及特殊规范要求（如日期样式，邮编样式，邮件地址样式，IP 地址样式，等等）。
空，部分，超大启发法：对于有大小概念的测试对象进行选择，如安装包，音视频文件等。
层级深度启发法：对于有层级嵌套深度，改变层级的测试对象和场景，尤其要观察深度嵌套是否导致响应慢的性能问题。
文件存储启发法：涉及文件的存储位置，存储方式的测试对象。
频率时间启发法：针对操作频率和持续时间进行改变，注意软件状态，以及长时间运行后是否出现缓存内容丢失，内存泄露等情况。
输入方式启发法：不同的输入方式可以带来潜在的问题，如通过复制/粘贴，拖动，快捷键等不同操作完成同一件事。
导航启发法：不同的导航风格，如随机导航，逐级导航，直接回到主界面等。

甚至，我们可以进一步开脑洞，用名词和动词做排列组合（动名词组合法），看看能启发出多少可行的测试用例？
以邮箱 App 的功能为例，我们可以看到的名词有主题、草稿、附件、邮件、文件夹、联系人、收件人等；我们可以观察到的动词有删除、转发、回复、保存、移动、编辑、接收、发送、导出等。
读者自己想一想，从以上名词和动词，可以组合出哪些有意义的测试用例？

变化无处不在，执行人员始终追求的 “求变” 技巧，可以让探索式测试源源不断地输出价值。