lsekfe 发表于 2022-8-2 10:18:29

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

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

利用思维导图形式,列出有哪些模块,覆盖哪些场景,每个场景的注意事项,然后进行评审。
  探索过程:按照思维导图,执行探索的过程中,根据情况,逐步深挖(也是边执行边学习的过程)每条 Path,更新并记录(做出√或者 × 的标识)执行探索过程中走过的 Path(带着反思去执行测试)。

提交缺陷:把探索式测试过程中发现的缺陷提交到缺陷管理系统中,修复后回归。
  报告总结:以简单的表格,对 BUG 的分布,数量,级别,进行统计和报告。(测试报告)

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



页: [1]
查看完整版本: 快速搞懂什么是探索式测试