五分钟搞懂探索式测试
五分钟搞懂探索式测试
蔡坨坨转载请注明出处❤️
作者:测试蔡坨坨
原文链接:caituotuo.top/c2c631b1.html
你好,我是测试蔡坨坨。
今天,我们来聊一聊探索式测试。
什么是探索式测试
探索式测试(ET,Exploratory Testing)是一种软件测试风格,而不是一种具体的软件测试技术,与敏捷模式相比,敏捷模式有敏捷开发和敏捷测试,而探索式测试是测试专属。
探索式测试强调依据当前待测项目实际情况,选择合适的测试技术,而不局限于特定的测试技术。
强调测试者的
主观能动性
,以及测试设计
和测试执行
的同时性
。传统的测试流程“先设计,再测试”,通常是先进行需求分析,再制定测试计划,接着梳理测试点,然后针对测试点设计好测试用例,最后执行测试。这种模式也带来一些问题,比如测试目标不明确的情况、需求变换频繁、输出范围过大等,可能出现测试遗漏,而且在一定程度上也限制了测试思维的发散。
而探索式测试的出现,正好弥补了传统测试中出现的这些情况。
目的是探索开发更多不同形态的测试方法,以便改善测试流程。
探索式测试的核心思想
- 探索式测试强调独立测试人员的
自由
和责任
。测试人员应该为个人和团队负责,调动所有能量,发挥人的灵活性,在整体上持续优化个人和团队的产出。 - 探索式测试建议在整个项目过程中,将
测试相关学习
、测试设计
、测试执行
和测试结果分析
作为相互支持的活动,并行地执行。实际上,人脑难以并行地执行多项任务。探索式测试旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代,以不断收集反馈、调整测试、优化价值。
探索式测试分类
1. 自由式探索式测试
自由式,顾名思义就是没有约束,纯粹从使用的角度出发,抛开规则、模式,测试人员可以任意顺序和方式对软件进行使用测试。这种测试通常会被选做冒烟测试用例。
2. 基于场景的探索式测试
这种测试跟传统的基于场景的测试(场景法)比较像,不同的是,在这种测试中测试人员会扩大测试范围
。
栗子1,对某搜索框的测试:
- 传统的场景测试用例可能是:
① 输入“衬衫”,预期结果是搜索到衬衫相关的信息;
② 输入“风扇”,搜索到风扇相关的信息。 - 而基于场景的探索式测试,测试场景可能是:
① 输入“衬衫”,探索搜索结果;
② 粘贴“123@”,搜索结果;
③ 输入一个乱码,搜索结果;
④ 输入“衬衫”,搜索结果后返回退到搜索首页再次搜索。
栗子2,批量下载功能测试:
- 传统的场景测试用例可能是:
① 点击“选中全部文件”按钮,批量下载;
② 手动选择要下载的文件,批量下载。
③ 测试是否支持跨页批量下载;
④ 批量下载的个数:1,2,499,500,501,999,1000,1001……
…… - 而基于场景的探索式测试,测试场景可能是:
① 点击“选中全部文件”,再手动取消勾选任意个数的文件,批量下载;
② 点击“全选”按钮,选中当前页面的所有文件,再切换到另一页手动勾选任意个数文件,批量下载;
③ 点击“选中全部文件”,再取消,再手动勾选任意个数文件,批量下载;
……
3. 基于策略的探索式测试
这是一种比较依靠经验的测试方法,简单来说就是测试老手,融合自己的经验、技能、感知等条件,结合自由式探索式测试,用自己积累下来的知识来指导测试,是一种经验结合随机性的测试。(类似于编写测试用例时用到的错误推断法
,基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例。)
4. 基于反馈的探索式测试
反馈指的是当测试人员对被测程序做出指令后得到的响应结果。
基于这个结果,测试人员可以调整自己的输入
,以期望得到不同的结果
。
例如:在基于场景的探索式测试的描述中,输入衬衫和风扇会得到不同的搜索结果,而衬衫的搜索结果就是对衬衫这个输入的反馈,风扇的结果就是对风扇这个输入的反馈。
什么样的项目适合进行探索式测试
软件需求说明书SRS(Software Requirements Specification)不完善
,时间紧迫
,没有测试用例
的情况下,以ET快速完成版本新功能的测试。作用:更快设计,更快执行,更低成本。
系统测试完成之后,还有剩余时间的情况下,以探索式测试作为补充,尝试系统测试覆盖不到的场景,从而减少漏测,提高测试覆盖率。
进行探索式测试的前提条件
- 团队对产品功能比较熟悉。(比如:做过同类型的软件)
- 已经可以运行的待测软件。(开发人员已经开发完成)
探索式测试在项目中如何落地
快速学习需求:基于对软件历史版本的熟悉,对新版本功能快速学习,提出问题并进行澄清。
作出
测试计划
:时间,范围,团队分工等。(以简单表格形式列出)模块 时间 测试人员 注册登录模块 6.23 - 6.24 张三 新增博客模块 6.23 - 6.25 李四 博客浏览评论 6.23 - 6.25 王五 利用
思维导图
形式,列出有哪些模块,覆盖哪些场景,每个场景的注意事项,然后进行评审。探索过程:按照思维导图,执行探索的过程中,根据情况,逐步深挖(也是边执行边学习的过程)每条Path,更新并记录(做出√或者×的标识)执行探索过程中走过的Path(带着反思去执行测试)。
提交缺陷:把探索式测试过程中发现的缺陷提交到缺陷管理系统中,修复后回归。
报告总结:以简单的表格,对BUG的分布,数量,级别,进行统计和报告。(
测试报告
)
PS:探索式测试主要还是依赖对领域的认知,需要有一定的经验积累,这个其实大部分初学者,或者经验不够老道的很难掌握好。