什么是探索性测试？
探索性测试是一种软件测试，测试用例不是事先创建的，而是由测试人员检查系统。探索性测试的重点更多的是将测试作为一种“思考”活动。
探索性测试在敏捷模型中被广泛使用，并且都是关于发现、调查和学习的。它强调个体测试员的个人自由和责任。
在脚本化测试下，首先设计测试用例，然后继续执行测试。相反，探索性测试是同时完成测试设计和测试执行的过程。
脚本化测试执行通常是测试人员执行测试步骤，并将实际结果与预期结果进行比较的思考活动。这样的测试执行活动可以自动化，不需要太多的认知技能。
虽然当前软件测试的趋势是推动自动化，但探索性测试是一种新的思维方式。自动化有其局限性
脚本测试和探索性测试之间的区别
| 脚本化测试 | 探索性测试 |
|---|---|
| 根据需求进行指导 | 从需求出发，在测试过程中探索 |
| 提前很好地确定测试用例 | 测试过程中测试用例的确定 |
| 根据要求确认测试 | 系统或应用程序的调查 |
| 强调预测和决策 | 强调适应性和学习性 |
| 涉及确认测试 | 牵涉到调查 |
| 是关于控制测试的 | 是关于测试设计的改进 |
| 就像做演讲一样–从草稿中读出 | 就像交谈一样-这是自发的 |
| 脚本在控制之中 | 测试员的思想在控制之中 |
探索性测试-
- 不是随机测试，但它是专门用来查找错误的测试
- 有条不紊，严谨严谨
- 与脚本化测试的程序结构相比，它在认知(思维)上是结构化的。这一结构来源于宪章、时间拳击等。
- 具有高度的可教性和可管理性
- 这不是一种技术，而是一种方法。下一步执行的操作取决于当前正在执行的操作
如何进行探索性测试
以下是关于如何进行探索性测试(也称为基于会话的测试管理(SBTM周期))的逐步过程：
- 创建Bug分类(分类)
对过去项目中发现的常见故障类型进行分类
分析问题或故障的根本原因分析
找出风险并提出想法来测试应用程序。
- 测试约章
测试章程应建议
1. 要测试的内容
2. 如何对其进行测试
3. 需要查看的内容
测试思路是探索性测试的出发点
测试章程有助于确定最终用户如何使用系统
- 时间框
该方法包括一对测试仪一起工作不少于90分钟
在这90分钟的会话中不应该有任何中断时间
Timebox可以延长或缩短45分钟
本课程鼓励测试人员对来自系统的响应做出反应，并为正确的结果做好准备
- 审查结果：
* 缺陷评定
* 从测试中学习
* 覆盖范围分析
- 汇报情况：
输出结果的编译
将结果与章程进行比较
检查是否需要任何额外的测试
例如，在探索性执行过程中，需要做以下工作：
- 测试的任务应该非常明确
- 记录需要测试的内容、为什么需要测试以及对产品质量的评估
- 跟踪探索性测试期间提出的问题和问题
- 最好将测试员配对以进行有效的测试
- 测试的越多，就越有可能为所需的场景执行正确的测试用例
获取文档并监控以下内容非常重要
- 测试覆盖率–是否注意到测试用例的覆盖率，并提高软件的质量
- 风险-哪些风险需要承保，哪些都是重要的风险？
- 测试执行日志-记录测试执行
- 问题/查询-记录系统上的问题和问题
更智能的探索性测试可以在更短的时间内发现更多错误。
探索性测试的利弊
| 优势 | |
|---|---|
|
当需求文档不可用或部分可用时，此测试非常有用
它涉及调查过程，这有助于发现比正常测试更多的错误- 发现通常被其他测试技术忽略的错误 通过执行越来越多的测试用例来帮助扩展测试人员的想象力， 最终也提高了工作效率 此测试深入到应用程序的最小部分， 并涵盖所有要求 此测试涵盖所有类型的测试， 并涵盖各种场景和案例 鼓励创造力和直觉 在测试执行期间生成新想法 |
这项测试完全取决于测试员的技能。
受限于测试人员的领域知识 不适合长时间执行 |
探索性测试的挑战：
探索性测试有许多挑战，下面对这些挑战进行说明：
- 学习使用应用程序或软件系统是一项挑战
- 复制故障很困难
- 确定是否需要使用工具可能具有挑战性
- 确定要执行的最佳测试用例可能很困难
- 报告测试结果是一项挑战，因为报告没有计划的脚本或案例来与实际结果或结果进行比较
- 很难记录执行期间的所有事件的文档
- 不知道何时停止测试，因为探索性测试有明确的测试用例要执行。
何时使用探索性测试？
探索性测试可以在以下情况下广泛使用
- 测试团队拥有经验丰富的测试人员
- 需要早期迭代
- 有一个关键的应用程序
- 新的测试人员加入了团队
结论：
在软件工程中，探索性测试是为了克服脚本化测试的限制而执行的。它有助于改进测试用例套件。它对学习和适应能力有同情心。
