探索式软件测试学习笔记

在读了几篇《探索式测试》笔记类文章，发现对于书中的诸如“旅馆区测试类型”比喻，由于不理解前因后果，找不到关联性，有点云里雾里，遂重读原书，在原文章的基础上进行了自己的重新梳理，以及典型BUG举例，便于自己理解记忆。
个人觉得第3、4、5章是重点需要理解的地方，文后附 "软件戒律"也可以学习下。
参考文章：
【1】探索式测试整理 https://blog.csdn.net/zimingzim/article/details/82466413#comments_18326875
【2】书籍点评 James Whittaker – 探索式软件测试 (Exploratory Software Testing) https://testerhome.com/topics/11709

一、软件质量

1.1 软件的魔力

• 未来50年，软件必将推动更多的发明创造软件的魔力

• 在人类创造的所有产品中，软件出问题的可能性是其他所有产品无可匹敌的

• 人类迫切需要软件来实现未来的梦想，但是在现实生活中，软件却又是最不可靠的一种产品

• 软件对我们的未来至关重要，但目前软件故障率已达到让人触目惊心的程度

1.2 软件失效

• 有些软件缺陷会使用户工作效率降低，软件缺陷还会给用户带来各种各样的不便，或者会让用户暗暗摇头

• 软件缺陷是软件魔力上的瑕疵

• 理解软件缺陷是如何产生的，熟悉查找软件缺陷的各种方法，从而充分兑现软件魔力的诺言

1.3 小结

• 科学孕育了软件，给予它非凡的魔力，现在是通过软件魔力来创造新科学的时代了，我们需要这种魔力来解决世界上亟待解决的各类问题

• 软件在其中都扮演着重要的角色，这就迫切需要尽可能地提高软件质量，过去的失败再也无法忍受

二、手工测试

2.1 软件缺陷的根源

• 软件缺陷的根源来自于软件开发本身

• 软件现在不是毫无缺陷的，将来多半也不会是

我们会讨论两种缺陷：程序员引入的缺陷和运行环境导致的缺陷

2.2 权限预防和检测

缺陷预防

缺陷检测

测试人员该怎么办呢？如果测试人员不能依靠开发人员的缺陷预防工具和自动化手段，他们还能希望于什么呢？唯一的答案就是手工测试

2.3 手工测试

2.3.1 概要

• 手工测试，就是需要人来动手进行测试

• 由人来进行手工测试，可以最大程度地发挥人的主观能动积极性，设计出真实的用户情况，在真实的用户环境中使用真实的用户数据，同时可以识别出那些显而易见的缺陷和那些比较难以觉察的缺陷

• 如果想发现与应用程序业务逻辑相关的缺陷，手工测试是最理想的选择

• 一直以来，软件产业在手工测试都没有很好地发展

2.3.2 手工测试中使用脚本

2.3.3 探索式测试

• 局部探索式测试法

• 全局探索式测试法

• 同时使用探索式测试和脚本测试

2.4 小结

• 从事手工探索式测试算得上是最有挑战性和最让人称心的一份工作

• 长久以来，对探索式测试一直没有比较好的参考指南，只有那些摸索探索式测试法多年并从实践中掌握了经验教训的老手才真正地在使用它

• 本模型关于探索式测试法的大量经验教训和真知灼见，希望可以更快更多地培养出精通该技术的人才，为软件产业提供高质量的软件测试，为开发高质量软件做一份贡献

• 在测试软件时，必须全神贯注，决不能心不在焉。本模型帮助我们集中精力，全力以赴，使测试更彻底、更完整

三、局部探索式测试法★

3.1 用户输入

需要先了解用户输入的基本知识、合法输入和非法输入

1. 输入筛选器（输入限制）

   第一，开发是否正确的实现了该功能？

   第二，是否可以绕过屏蔽器？或者当输入值进入系统后还可以修改？

2. 输入检查

   测试必须仔细阅读每一条错误信息，检查该信息是否写错了，错误信息还可以透漏开发编程时的一些想法。

   输入检查和异常处理的区别：输入值检查提示的错误信息很精准，异常处理提示的错误信息比较笼统。

3. 使用异常处理

   如果测试看到一个空乏的通用出错信息，建议测试再反复测试同一段函数，继续很用刚才引发异常的输入数据，或稍微修改一下，看看会不会导致出错。尝试运行其他一些要调用该函数的测试用例，看看会发生什么情况。

4. 常规输入还是非常规输入

   所有和Ctrl、Alt、Esc按键组合的字符都算的上是特殊字符，需要在应用程序中测试；

   操作系统、编程语言、浏览器和运行时环境的特定保留词，如windows的COM1，输入保留此可能会崩溃。

5. 默认输入或用户提供的输入

   输入空或者默认值

6. 使用输出来指导输入选择

   把输出分为合法输出和非法输出，这里主要测合法输出。

   测试先确定用户希望程序什么输出结果，然后考察所有的用户场景，看看如何去生成期望的结果。

   举例：测试接口时，需要测试record_not_exists返回，可以通过删除本地文件、修改本地文件名称2种方式。

输入选择的复杂性只是测试人员在软件测试中最先遭遇的技术难题。不断地对软件进行输入后，就出现了软件状态的问题

3.2 状态

应用程序和其运行环境进行交互和接收到的所有输入导致软件状态发生变化。测试人员就是测试这些状态变化的情况。测试其是否正确更新了

自身的当前状态？是不是进入了一些它不应该进入的状态？

输入和状态之间的关系相当关键，在局部探索式测试法建议如下方式：

1）使用状态信息来帮助寻找相关的输入

​ 举例：录音暂停状态，什么输入可能会导致录音暂停，手动按下暂停，应用退至后台，来电、其他程序抢占麦克风等。

2）使用状态信息来辨识重要的输入序列

3.3 代码路径

测试人员必须明确知道程序里可能有哪些分支，并理解哪些输入会导致软件走这条分支而不另一条。

举例：在if else的地方设计测试用例，覆盖多种条件分支

3.4 用户数据

如果预期软件需要存取海量的数据存储，比如一个数据库或大批量的用户文件，就需要在测试环境中设置一个数据存储。且该数据应该和软件真实用户使用的数据尽量一致。

需要考虑：如何模仿真实的用户数据，使用用户真实数据时，如何解决“隐私问题”。

3.5 运行环境

当软件被安装到一个崭新的却它从来没见过的环境中时，还可能会失效，这是因为环境本身就算是一种输入源，所以测试人员在产品发布之前必须尽量尝试各种各样地用户环境。

任何可以影响被测试软件行为的因素都是运行环境的一部分，在测试中都必须考虑到

运行环境包括：

• 使用的操作系统 （如安卓的系统版本）

• 系统当前配置 （如用户配置，权限通知管理等）

• 和被测试软件进行交互的其他一些应用程序 （如OCR调用系统相机）

• 间接或直接影响被测软件本身 或影响被测软件运行 的任何驱动程序、代码、文件、设置等 （如PC的硬件驱动、依赖开发环境、体验产品的注册表等）

• 软件当前连接的网络情况、网络的可用带宽、性能等 （如手机代理、移动网络/wifi、限速）

3.6 小结

输入、代码路径、状态、被存储的数据和运行环境等，这里有太多太多的因素，而每种因素又 有太多的变化可能，这一切使得软件测试变得极其复杂，最终无论做了哪些测试，软件测试的复杂性都决定了我们所作的总是远远不够的。

探索式测试试图把制定计划、进行测试、重新制定计划等多个过程有机地结合起来，每次只前进一小步，但这 每一步都是由软件过去和当前的运行状况、软件在测试时表现出来的各种行为和软件运行时留下的种种蛛丝马迹来即时确定的。

测试本身很复杂，但是有效地利用探索式测试技术可以帮助我们驯服这匹桀骜不驯的烈马，从而发布一个高质量的软件产品

四、全局探索式测试法★

4.1 摘要

此方法用于帮助测试人员设计整体测试计划 和 测试策略。

帮助测试人员在全局方面所必须做出的各种决定，比如在考虑特性交互、数据流以及在应用程序的用户界面上如何选择不同路径完成某些实际功能时。不再考察在单个输入面板上充当中间用途的原子输入，转而讨论那些可以帮助测试达到更重要目的的输入。

实际上需要我们在开始就做出一个全局目标，用于指导以后的测试过程。使用全局探索式测试法，做出的决定一仅仅影响单个的对话框或者单个用户界面，它的范围涉及到软件的全局。不仅仅是确定如何测试某个单一功能，而是确定了如何对软件进行探索式测试的整体方向。

4.2 目标

漫游测试法为测试提供了一个构架，

它可以帮助测试人员创建出比使用自由发挥的方式更有趣、也更有针对性的用户场景；

它也为测试人员设定了一个目标，引导他们尝试更有趣和复杂的使用路径；

漫游测试既能帮助测试人员思考如何测试应用程序，又能帮助他们组织实际的测试。

当然这一系列的测试法可以编成一张测试核对表，这样可以避免测试人员遗漏某种测试类型，也可以帮助测试人员把应用程序的功能和适合这些功能的测试技术相匹配。

此外，这些测试法还可以帮助测试人员做出无数的决定，如何决定测试路径，如何选择输入值，使用哪些参数进行测试。在无数