您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

快速搞懂什么是探索式测试

发表于:2022-09-09 作者:测试蔡坨坨 来源:博客园

什么是探索式测试

探索式测试(ET,Exploratory Testing)是一种软件测试风格,而不是一种具体的软件测试技术,与敏捷模式相比,敏捷模式有敏捷开发和敏捷测试,而探索式测试是测试专属。

探索式测试强调依据当前待测项目实际情况,选择合适的测试技术,而不局限于特定的测试技术。

强调测试者的主观能动性,以及测试设计和测试执行的同时性。

传统的测试流程 “先设计,再测试”,通常是先进行需求分析,再制定测试计划,接着梳理测试点,然后针对测试点设计好测试用例,最后执行测试。这种模式也带来一些问题,比如测试目标不明确的情况、需求变换频繁、输出范围过大等,可能出现测试遗漏,而且在一定程度上也限制了测试思维的发散。

而探索式测试的出现,正好弥补了传统测试中出现的这些情况。

目的是探索开发更多不同形态的测试方法,以便改善测试流程。

探索式测试的核心思想

探索式测试强调独立测试人员的自由和责任。测试人员应该为个人和团队负责,调动所有能量,发挥人的灵活性,在整体上持续优化个人和团队的产出。

探索式测试建议在整个项目过程中,将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动,并行地执行。实际上,人脑难以并行地执行多项任务。探索式测试旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代,以不断收集反馈、调整测试、优化价值。

探索式测试分类

1. 自由式探索式测试

自由式,顾名思义就是没有约束,纯粹从使用的角度出发,抛开规则、模式,测试人员可以任意顺序和方式对软件进行使用测试。这种测试通常会被选做冒烟测试用例。

2. 基于场景的探索式测试

这种测试跟传统的基于场景的测试(场景法)比较像,不同的是,在这种测试中测试人员会扩大测试范围。

栗子 1,对某搜索框的测试:

传统的场景测试用例可能是:

① 输入 “衬衫”,预期结果是搜索到衬衫相关的信息;

② 输入 “风扇”,搜索到风扇相关的信息。

而基于场景的探索式测试,测试场景可能是:

① 输入 “衬衫”,探索搜索结果;

② 粘贴 “123@”,搜索结果;

③ 输入一个乱码,搜索结果;

④ 输入 “衬衫”,搜索结果后返回退到搜索首页再次搜索。

栗子 2,批量下载功能测试:

传统的场景测试用例可能是:

① 点击 “选中全部文件” 按钮,批量下载;

② 手动选择要下载的文件,批量下载。

③ 测试是否支持跨页批量下载;

④ 批量下载的个数:1,2,499,500,501,999,1000,1001……

……

而基于场景的探索式测试,测试场景可能是:

① 点击 “选中全部文件”,再手动取消勾选任意个数的文件,批量下载;

② 点击 “全选” 按钮,选中当前页面的所有文件,再切换到另一页手动勾选任意个数文件,批量下载;

③ 点击 “选中全部文件”,再取消,再手动勾选任意个数文件,批量下载;

……

3. 基于策略的探索式测试

这是一种比较依靠经验的测试方法,简单来说就是测试老手,融合自己的经验、技能、感知等条件,结合自由式探索式测试,用自己积累下来的知识来指导测试,是一种经验结合随机性的测试。(类似于编写测试用例时用到的错误推断法,基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例。)

4. 基于反馈的探索式测试

反馈指的是当测试人员对被测程序做出指令后得到的响应结果。

基于这个结果,测试人员可以调整自己的输入,以期望得到不同的结果。

例如:在基于场景的探索式测试的描述中,输入衬衫和风扇会得到不同的搜索结果,而衬衫的搜索结果就是对衬衫这个输入的反馈,风扇的结果就是对风扇这个输入的反馈。

什么样的项目适合进行探索式测试v

软件需求说明书SRS(Software Requirements Specification)不完善,时间紧迫,没有测试用例的情况下,以 ET 快速完成版本新功能的测试。

作用:更快设计,更快执行,更低成本。

系统测试完成之后,还有剩余时间的情况下,以探索式测试作为补充,尝试系统测试覆盖不到的场景,从而减少漏测,提高测试覆盖率。

进行探索式测试的前提条件

团队对产品功能比较熟悉。(比如:做过同类型的软件)

已经可以运行的待测软件。(开发人员已经开发完成)

探索式测试在项目中如何落地

快速学习需求:基于对软件历史版本的熟悉,对新版本功能快速学习,提出问题并进行澄清。

作出测试计划:时间,范围,团队分工等。(以简单表格形式列出):

模块 时间 测试人员
注册登录模块 6.23 - 6.24 张三
新增博客模块 6.23 - 6.25 李四
博客浏览评论 6.23 - 6.25 王五

利用思维导图形式,列出有哪些模块,覆盖哪些场景,每个场景的注意事项,然后进行评审。

探索过程:按照思维导图,执行探索的过程中,根据情况,逐步深挖(也是边执行边学习的过程)每条 Path,更新并记录(做出√或者 × 的标识)执行探索过程中走过的 Path(带着反思去执行测试)。

提交缺陷:把探索式测试过程中发现的缺陷提交到缺陷管理系统中,修复后回归。

报告总结:以简单的表格,对 BUG 的分布,数量,级别,进行统计和报告。(测试报告)

PS:探索式测试主要还是依赖对领域的认知,需要有一定的经验积累,这个其实大部分初学者,或者经验不够老道的很难掌握好。