什么是探索性测试？
托马斯·汉密尔顿
什么是探索性测试？
探索性测试 是一种软件测试，其中测试用例不是预先创建的，而是测试人员实时检查系统。他们可能会在测试执行之前记下要测试的内容的想法。探索性测试的重点更多地在于将测试视为一种“思考”活动。
探索性测试在敏捷模型中得到广泛应用，其核心内容是发现、调查和学习。它强调测试人员的个人自由和责任。
为什么要进行探索性测试？
在脚本化测试中，您首先设计测试用例，然后进行测试执行。相反，探索性测试是测试设计和测试执行同时进行的过程。
脚本化测试执行通常是一种无需思考的活动，测试人员只需执行测试步骤并将实际结果与预期结果进行比较即可。由于这种测试执行活动不需要太多的认知技能，因此可以实现自动化。
尽管软件测试的当前趋势是推动 自动化，探索性测试是一种新的思维方式。 自动化有其局限性
脚本测试和探索性测试之间的差异
| 脚本测试 | 探索性测试 |
|---|---|
| 以需求为导向 | 从需求出发，在测试过程中探索 |
| 提前确定测试用例 | 测试过程中测试用例的确定 |
| 确认测试符合要求 | 系统或应用调查 |
| 强调预测和决策 | 强调适应性和学习 |
| 涉及确认检测 | 涉及调查 |
| 关于控制测试 | 关于测试设计的改进 |
| 就像发表演讲一样——你照着草稿读 | 就像进行对话一样——它是自发的 |
| 脚本掌控一切 | 测试人员的思想在控制之中 |
探索性测试技术
- 这不是随机测试，而是为了发现错误而进行的临时测试
- 结构严谨
- 与脚本测试的程序结构相比，它具有认知（思维）结构。这种结构来自宪章、时间限制等。
- 易于教学和管理
- 它不是一种技巧，而是一种方法。你接下来要做什么取决于你当前正在做的事情
如何执行探索性测试
以下是如何执行探索性测试的逐步过程，也称为基于会话的测试管理（SBTM 循环）：
步骤 1）创建 Bug 分类法
- 对过去项目中发现的常见故障类型进行分类
- 分析问题或故障的根本原因
- 发现风险并提出测试应用程序的想法。
步骤 2）测试章程
- 测试章程应该建议
- 测试什么
- 如何测试
- 需要看什么
- 测试思路是探索测试的起点
- 测试章程有助于确定最终用户如何使用系统
步骤3）时间 Box
- 该方法需要一对测试人员一起工作不少于 90 分钟
- 90 分钟的会议期间不应有任何中断时间
- 时间可以延长或减少 45 分钟
- 本次会议鼓励测试人员对系统的响应做出反应，并为正确的结果做好准备
步骤4） Rev查看结果
- 缺陷评估
- 从测试中学习
- 覆盖区域分析
步骤 5）汇报
- 输出结果的汇编
- 将结果与章程进行比较
- 检查是否需要任何额外测试
最佳实践探索性测试
在探索性执行过程中，需要做以下工作：
- 测试的任务应该非常明确
- 记录需要测试的内容、测试原因以及产品质量的评估
- Tracking 探索性测试过程中提出的问题和争议
- 最好将测试人员配对，以进行有效的测试
- 我们测试得越多，就越有可能针对所需的场景执行正确的测试用例
记录并监控以下内容非常重要
- 测试覆盖率——我们是否记录了测试用例的覆盖率并提高了软件质量
- 风险——需要承保哪些风险？哪些风险都是重要的？
- 测试执行日志——测试执行的记录
- 问题/疑问——记录系统上的问题和问题
更智能的探索性测试可以在更短的时间内发现更多错误。
探索性测试的优缺点
优势
- 当需求文档不可用或部分可用时，此测试很有用
- 它涉及调查过程，有助于发现比正常测试更多的错误-
- 发现通常被其他测试技术忽略的错误
- 通过执行越来越多的测试用例，帮助扩展测试人员的想象力，最终提高生产率
- 该测试深入到应用程序的最小部分并涵盖所有要求
- 该测试涵盖所有类型的测试，并涵盖各种场景和案例
- 鼓励创造力和直觉
- 测试执行期间产生新想法
缺点
- 这种测试完全取决于测试人员的技能
- 受限于测试人员的领域知识
- 不适合执行时间较长
探索性测试的挑战
探索性测试面临许多挑战，如下所述：
- 学习使用应用程序或软件系统是一项挑战
- 失败很难复制
- 确定是否需要使用工具可能具有挑战性
- 确定要执行的最佳测试用例可能很困难
- 报告测试结果是一项挑战，因为报告中没有计划的脚本或案例来与实际结果进行比较
- 执行过程中所有事件的记录很困难
- 探索性测试没有明确的测试用例要执行，因此很难决定何时停止。
何时使用探索性测试？
探索性测试可广泛应用于以下情况
- 测试团队拥有经验丰富的测试人员
- 需要早期迭代
- 有一个关键的应用程序
- 新的测试人员加入团队
