五分钟搞懂探索式测试

转载请注明出处❤️

作者:测试蔡坨坨

原文链接:caituotuo.top/c2c631b1.html


你好,我是测试蔡坨坨。

今天,我们来聊一聊探索式测试。

什么是探索式测试

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

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

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

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

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

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

探索式测试的核心思想

  • 探索式测试强调独立测试人员的自由责任。测试人员应该为个人和团队负责,调动所有能量,发挥人的灵活性,在整体上持续优化个人和团队的产出。
  • 探索式测试建议在整个项目过程中,将测试相关学习测试设计测试执行测试结果分析作为相互支持的活动,并行地执行。实际上,人脑难以并行地执行多项任务。探索式测试旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代,以不断收集反馈、调整测试、优化价值。

探索式测试分类

1. 自由式探索式测试

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

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

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

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

  • 传统的场景测试用例可能是:
    ① 输入“衬衫”,预期结果是搜索到衬衫相关的信息;
    ② 输入“风扇”,搜索到风扇相关的信息。
  • 而基于场景的探索式测试,测试场景可能是:
    ① 输入“衬衫”,探索搜索结果;
    ② 粘贴“123@”,搜索结果;
    ③ 输入一个乱码,搜索结果;
    ④ 输入“衬衫”,搜索结果后返回退到搜索首页再次搜索。

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

  • 传统的场景测试用例可能是:
    ① 点击“选中全部文件”按钮,批量下载;
    ② 手动选择要下载的文件,批量下载。
    ③ 测试是否支持跨页批量下载;
    ④ 批量下载的个数:1,2,499,500,501,999,1000,1001……
    ……
  • 而基于场景的探索式测试,测试场景可能是:
    ① 点击“选中全部文件”,再手动取消勾选任意个数的文件,批量下载;
    ② 点击“全选”按钮,选中当前页面的所有文件,再切换到另一页手动勾选任意个数文件,批量下载;
    ③ 点击“选中全部文件”,再取消,再手动勾选任意个数文件,批量下载;
    ……

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

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

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

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

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

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

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

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

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

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

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

  1. 团队对产品功能比较熟悉。(比如:做过同类型的软件)
  2. 已经可以运行的待测软件。(开发人员已经开发完成)

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

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

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

    模块 时间 测试人员
    注册登录模块 6.23 - 6.24 张三
    新增博客模块 6.23 - 6.25 李四
    博客浏览评论 6.23 - 6.25 王五
  3. 利用思维导图形式,列出有哪些模块,覆盖哪些场景,每个场景的注意事项,然后进行评审。

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

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

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

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