探索性测试方法

2024-07-11 10:54:19   0  举报





AI智能生成

探索性测试方法是一种软件测试方法，它强调测试人员在测试过程中主动寻找缺陷和问题，而不仅仅依赖于预先定义的测试用例。这种方法鼓励测试人员根据应用程序的功能和行为来设计新的测试用例，以发现潜在的问题和缺陷。在探索性测试过程中，测试人员可以使用各种测试技术，如手动测试、自动化测试和探索性测试工具，来提高测试覆盖率和有效性。这种测试方法对于发现和修复软件缺陷，提高软件质量和用户体验具有重要意义。

项目管理

作者其他创作

大纲/内容

探索性测试学习大纲

什么是探索性测试

什么时候做探索性测试

探索性测试的几个阶段

脚本测试跟探索性测试的区别

探索性测试的类型

敏捷探索性测试

探索性测试所需的技能

探索性测试工具

探索性测试的实践

探索性测试基础学习

1、起源

探索性测试，最早是由测试专家 Cem Kaner 博士在 1983 年提出的，并受到当时语境驱动的软件测试学派的支持。后来，Cem Kaner 博士在佛罗里达工学院的同事 James A. Whittaker，凭借着在微软和谷歌担任测试架构师和测试总监的经验积累，撰写了最早的探索式测试书籍《Exploratory Software Testing》，扩展了探索式测试的概念和方法。

2、基本概念

随着软件测试的发展，手工测试越来越倾向于精心策划。现代软件项目是庞大的人员成本是有限的，如何保证在有限的时间内做最正确的事，需要手工测试在开展之前，有明确的战略和方向，但又必须预留一定的发挥空间让每个人的大脑可以充分运转起来，在测试的过程中随机应变。我们把这种测试方式称作探索性测试：它鼓励测试人员一边测试、一边计划、他们使用在测试中收集到的信息，影响自己进行测试的实际方式；

4、探索性测试-基础思维模型（CIPE）

Collation（整理）

首先是测试相关学习，需要我们收集和整理被测产品的信息，并了解和理解它们。通常在这个阶段，会翻开需求文档、方案文档看看，或者搜索之前的bug清单寻找思路

Prioritization（排序）

进行测试设计，确定所有测试任务的优先级

Investigation（调查）

对即将执行的测试任务进行仔细的分析并确定测试输入和预期输出，也属于测试设计的一部分

Experimentation（实验）

重点在测试执行和对测试结果的验证，验证我们的预期是否正确，检查我们在整理阶段获取到的信息是否正确。根据实验结果，测试人员将收集更多的信息，并调整测试任务的优先级。以此不断达到收集反馈、调整测试、优化价值的效果。

5、局部探索性测试

概念

首先会对软件的单一功能进行比较细致的探索式测试，“探索”的过程主要是基于功能需求以及非功能性需求进行扩展和延伸。

举例：软件系统的用户登录功能

1、首先应该站在最终用户的角度去理解和使用登录功能。为此，探索式测试人员需要分析出用户登录功能的所有原子输入项。假定原子输入项只有用户名、密码和登录按钮。接着组合这些原子输入项构成最基本典型的测试场景。

2、用真实合法的用户名以及密码完成登录就是一个非常基本典型的场景，如果该场景能够成功登录，就可以切换到下一个；如果该场景不能够成功登录，就需要去“探索”为什么没能登录成功，比如你可能会怀疑是否是因为用户名或者密码是区分大小写的，又或者是不是因为你多次错误的尝试而导致的。

3、编写用例

分支主题

4、基于你的怀疑，进一步去设计新的测试用例来验证你的猜测。总之，通过以上这样的“探索”过程，你将测试学习、测试设计、测试执行和测试结果评估串联成了一个快速迭代的过程，并在你脑海中快速建立了登录功能的详细模型。

3、两个前提

第一，测试之前一定会有一个全局的方针战略，即整体的测试计划，它可以避免走错大方向，该测的部分没有覆盖到，计划之外的部分却投入了大量时间。

第二，测试一旦开始，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息，指导各自走不同的路径，最终目的就是发现潜藏的缺陷。

6、全局探索性测试

概念

以用户登录功能为例，在系统交互的探索式测试中，就不仅要考虑单一的登录功能了，而是要考虑用户登录与系统其他功能相结合的场景。

举例

比如尝试不登录直接访问登录后的路径去观察系统的行为；再比如，你可以尝试不登录就去查看订单状态的操作等等。这些组合场景的设计主要取决于你想要验证，或者说想要“探索”的系统功能。很多时候这些灵感来自于你之前对系统的探索而取得的系统认识，同时你的技术直觉也在此扮演了重要角色。

7、全局探索性测试方法策略

商业区

指南测试

概念

城市的题图通常都会标注一些热门的旅游景点，测试这些热门的区域是非常重要的。不管在任何一次发布的过程中，核心功能是肯定要覆盖到的。指南测试要求测试人员严格按照用户手册的建议执行操作，但手册描述不到位或者核心功能并不像宣传的那样好。

测试策略

1、严格按照用户手册的建议进行操作；

2、以完全不了解系统视角严格按照手册进行操作；

3、将多分指南（需求、概要设计、帮助手册）放在一起，边理解边测试

卖点测试

概念

此方法是鼓励测试人员观看销售给客户演示的Demo，理解销售的角度哪些功能对客户来说是最大的卖点，他们未必就是核心功能，但值得测试人员把它们当核心功能来对待。同时，也许刁钻的客户会提出各种质疑，这些质疑和稀奇古怪的问题也可以纳入测试人员的设计中。

测试策略

1、了解销售对客户的演示，从中挖掘用户关心的内容作为测试点

2、关注最吸引人的特性功能

地标测试

概念

在旅游的时候，如果我们设计了要到访的地方，通常会在地图上插上旗子，这就是地标。但是没有人规定我们应该按照何种顺序去到访这些地标。不同的测试人员可能会选择不同的顺序，有经验的测试人员会基于对软件产品架构和技术层面的理解，采取一些古怪的路径但更可能发现缺陷。

方法

1、将指南测试法及卖点测试法中的标记定义为一个路标

极限测试

概念

向软件提出难以回答的问题，比如最大可以发挥到什么程度，承受多少用户，承载多少数据。那个特性或功能会把软件逼到极限运作，哪些输入和数据会消耗软件最多的计算能力？哪些输入可能绕过它的错误检测？

方法

1、尽可能寻找软件边界；

2、在软件允许的范围内，找一些不一定有意义的测试，或者用户很少这样操作，但是软件并不禁止的操作

快递测试

概念

快递运送的货物，就好比软件里的数据，结果不同的地点转接，拆包装包最终到底目的地。所以快递测试专注的是数据，跟随它们走遍整个软件。

方法

1、通过消息流转或者类似于debug过程，来定点这条路径中的关键数据节点流转是否正确

2、确认哪些被存储起来的输入数据并”跟随“它们走遍整个软件

深夜测试

概念

城市灯火阑珊会在午夜过后逐渐安静下来，商场店铺纷纷打烊。但是软件不应该停止工作，软件测试人员有时应该刻意的关注在冷门时间段软件所做的附属工作，比如数据备份归档、维护监控任务的运行等等。

方法

1、关注数据备份归档、维护监控任务的运行等等

2、在拥挤的时刻加入功能测试

3、关注软件启动过程和脚本

遍历测试

概念

遍历测试通常包括对应用程序的每个窗口和控件进行操作，如点击按钮、输入文本等，以发现如应用崩溃、无响应或功能异常等问题。这种方法可以覆盖更多的功能点，比手工测试更高效，同时比传统的自动化测试成本更低

方法

1、将程序路径绘制出来，采用最短路径来访问这些目标对象，从而遍历所有的路径点

历史区

恶邻测试法

概念

随着测试的深入，发现和报告越来越多的缺陷后，就可以把缺陷数目同产品特性联系起来，从而可以跟踪究竟在哪些地方会出现产品缺陷。由于缺陷通常扎堆出现，因此产品缺陷多的地方值得反复测试。

方法

1、复杂的功能要多测，bug多的区域要多测

博物馆测试法

概念

这是针对软件的遗留代码，保留了些许年代的一些功能，找出它们来验证是否有出现失效。当初开发它们的时候，甚至可能缺乏文档，但这并不意味着它们应该被忽略。

方法

1、关注软件中的遗留代码是否有过改动，有改动就需要测试

上一版本测试法

概念

如果当前产品构造是对先前版本的更新，先运行先前版本上支持的所有场景和测试用例。

方法

1、如果当前产品是对原有产品的重构或更新，则需要验证所有场景

娱乐区

配角测试法

概念

其实这就是配角测试法的精髓:鼓励测试人员专注于某些特定的特性，它们虽然不是那种我们希望用户使用的主要特性，但和那些主要的特性一同出现在显示器上。它们越紧邻那些主要功能，越容易被人注意。

方法

1、关注某些辅助的特性，并将这些特性与主流业务特性放在一个视角来测试

深巷测试法

概念

在每个城市，都有些地方并不吸引游客意味着不吸引人群，但作为测试人员来说，反而是这种最不可能被用到或者最不吸引用户的特性，容易潜藏着难以发现的Bug。

方法

1、关注最不可能用到或者那些不吸引人的用户特性

通宵测试法

概念

繁华的都市总会有通宵热闹的地方，比如夜总会KTV之类的，它们从不中断。那么应用程序是否也能坚持到最后呢？当它面临持续不断的调用、输入、重读重写之类的操作，如果运行时间足够长，就很可能会出问题，内存会需要回收、数据需要清空，永远不要关闭它，保持不间断的运行。

方法

1、长期稳定性测试

旅游区

收藏家测试法

概念

要求测试人员也收集东西并努力做到能把东西都收集全。这里我们收藏的就是软件的输出，收集的越多越好。这个测试法背后的想法是测试人员到达所有那些可到达的地方并把观察到的输出结果记录下来，并确保能观察到软件能生成的任何一个输出。

方法

1、尽可能分析梳理出软件的每条测试路径，将输出结果记录下来，整理成checklist

长路径测试法

概念

把那个在应用程序埋藏最深的界面当做测试目标（离起始点最远的那个界面），观察经过的每一个界面

方法

1、寻找隐藏最深的的产品界面，并观察经过的每一个界面

超模测试法

概念

针对UI的表面测试，衡量软件的展现能力，像T型台的超模那样，不去关注她们幕后的辛酸痛苦劳累，跳出产品专家或测试的头衔，以普通观众的角度，去关注那些能看到的界面展现，元素是否被正确绘制、是否难看、颜色风格是否一致、界面的切换变化是否表意清晰？

方法

1、观察界面的设置、按钮是否好看、易用

2、元素是否被正确绘制、颜色风格是否一致、界面切换是否清晰

测一送一法

概念

在商场常见的一种促销活动叫"买一送一"，探索式测试也借鉴这种思想，测试同时运行同一应用程序多个拷贝的情况。

方法

1、不同程序同时打开一个文件，或者多个客户端同时操作一批数据

苏格兰酒吧测试法

概念

我的朋友亚当首斯泰克（Adam Shostack，《信息安全新学校》一书的作者）在阿姆斯特丹游览时遇到了一群苏格兰游客（他们的方格呢裙和口音泄露了他们的国籍），他们都是偏爱进口酒的一个泡吧旅行团的成员。我的朋友加入了他们在一个城市的泡吧之旅，他很快承认如果没有他们的带领，他永远也找不到这些地方。从矮小的餐馆到隐藏在邻里之间的仅仅偏离热闹大街一点点的社区聚集地，都有这类酒吧。

方法

1、找到用户组并参与讨论，从中获取测试灵感

2、阅读产业博客，深入了解待测应用程序，挖掘测试场景

旅馆区

取消测试法

概念

此方法的思想是启动了立即停止，特别是一些运行流程比较耗时的功能如备份还原或者搜索，在启动之后，立即取消。发散一点还可以变成，启动一个耗时操作，不停止立即启动另外一个耗时操作，以此来检测应用程序的自我清除能力。

方法

1、刚一启动就停止

2、启动一个耗时操作后，立即启动另一个耗时操作，以此来检测应用程序的自我清除能力

懒汉测试法

概念

选择尽可能少的输入，能不输入尽量不输入，能不修改尽量不修改，观察应用程序是否能响应得出正确结果。

方法

1、输入保持默认值、空白输入

破旧区

破坏测试法

概念

强迫软件做一些操作，并掌握软件成功完成操作必须使用的资源，在不同程度上移除那些资源或者限制使用那些资源

方法

1、读取文件数据时破坏、删除或改变此文件权限

2、传输之前或传输中拔掉网线、断开网络连接

3、在内存不够的情况下运行

反叛测试法

概念

你见过去酒吧不喝酒点果汁的么？反叛思想要求输入最不可能的数据，或者已知的而已输入，测试人员可以采用逆向思维、明知一些数据违反规则，却偏偏要采用这样的数据，或者不按照正确的顺序来输入

方法

1、利用反向思维，用一些违反规则的数据进行测试

强迫症测试法

概念

测试人员强迫软件一边又一边接受同样的数据，反复执行同样的操作，最重要的特点就是重复。此种思维方式，常常打破了开发人员设计代码的思路，他们预想着你会按步骤操作，却不曾考虑过你反复的执行第一步应该如何处理。

方法

1、重复、复制、粘贴一些数据并进行操作

8、混合探索性测试

概念

混合探索性测试就是将探索性测试与传统的基于场景的测试方法相结合，通过引入变化达到系统交互测试的目的

方法

删除步骤

使用递进的方式重复应用这个场景操作，每次只删除一个步骤，每减少一个步骤，场景都在被测软件上执行一次，直到获得一个最短的测试用例，然后循环结束。

替换步骤

当被测软件提供了两种选项，则可通过创建衍生场景的方式来测试第二种选择。

重复步骤

通过重复和重新安排步骤，可以测试新的代码路径，发现那些可能与数据初始化相关的缺陷。

替换数据

例如，如果测试可以使用真实的数据库则可代替默认是数据库；模拟数据源停止工作或者无法连接的情况；数据源的记录增加等情况。

插入步骤

1、增加更多数据：当场景要求增加10条数据库记录时，测试人员可以提高到20或30条甚至更多记录，或者当场景要求创建一个新账号，可给那个账号提供超过场景要求的信息。

2、使用附加输入：这里的想法是了解哪些附加功能和场景提到的功能有关联，然后增加输入来测试这些新的附加功能。

3、访问新的界面：当场景要求测试人员调用某些屏幕或对话框时，测试人员应该找到其他相关的一些屏幕或对话框，并把它们加入到场景中。

替换环境

1、替换硬件：使用用户可能用到的不同类型硬件。

2、替换容器：确保测试场景在用户可能使用的所有主要容器中正常运行。

3、替换版本：所有前面提到的容器都有过去的版本，测试版本兼容性。

4、修改本地设置：浏览器本地设置、本地注册表修改等。

探索性测试学习材料跟书籍

书籍推荐

《探索式测试实践之路》

《探索式软件测试》任命软件测试人员，OA专家、开发人员、程序经理和架构师阅读，对他们的工作具有重要的启发作用。探索式软件测试作为一种富有创新精神和现实意义的测试方法，引起越来越多软件测试人员、质量保证人员和项目经理的高度重视。《探索式软件测试》作者结合自己二十年的经验，从多个角度结合富的实例阐述了探索式软件测试的使用技巧、提示和相关技术。全书共8章，3个附录，为手工测试流程提供了重要的指导，技术和规划。

詹姆斯·惠特克(James Whittaker)的全部职业生涯都致力于软件测试，在该学科的许多方面都留下了他的印记。他是基于模型的测试领域的先驱，他在田纳西大学的博士学位论文是该主题的标准参考资料。他在错误注入(error injection)方面的工作，创造了备受欢迎的运行时错误注入工具Holodeck。他是软件安全和渗透测试(penetration testing)的早期创导者。作为教师和演讲者，他也为人们称道，他曾在国际会议上赢得过多个最佳论文和最佳演讲奖。

《探索它！：通过探索性测试降低风险并增加信心》

本书是软件测试领域的指南针，阐明了探索性测试的动态方法，强调好奇心、发现和适应性。

动态测试：从脚本测试转向充满好奇心、适应性和持续发现的世界。实时适应：每个测试阶段学习和发展的本质。风险管理：通过探索性方法识别和解决潜在的陷阱。

Hendrickson 是测试社区中一位经验丰富的人士，他深入研究了章程创建、时间盒以及使用启发式方法识别模糊场景中的问题等关键概念。在当今快节奏的软件开发世界中，她的方法提供了发现被忽视问题的灵活性。“探索它！” 是所有阶段测试人员的必备读物，倡导采取积极主动的方法来确保软件的卓越性。

《探索式测试实践之路》

《探索式测试实践之路》适合软件测试工程师和测试管理人员阅读，也适合大专院校计算机相关专业师生作为参考书使用

探索式测试是一种重要的软件测试思想。随着测试行业的发展，其高效性、机动性和实用性受到了广泛的关注、讨论和实证，但是仍有许多测试人员对探索式测试充满疑问，甚至误解。本书的目标就是回答疑问，澄清误解，分享作者们在探索式测试领域的实战经验和反思总结，并介绍业界专家的相关见解。

本书内容可分成4个部分。第1章介绍了探索式测试的定义和理论基础，并回答了测试人员感兴趣的常见问题。第2～7章介绍了探索式测试的具体技术，包括思维方法、测试设计、测试工具和测试自动化。第8～12章讨论了测试团队如何实施与管理探索式测试。第13章回顾全书内容，并分析了探索式测试获得成功的关键因素。

学习材料

探索性测试的概念及方法

https://blog.csdn.net/weixin_44079378/article/details/126119393

探索性测试