探索性测试
作者：互联网
一、什么是探索性测试？
定义：
探索式测试（Exploratory testing）是一种自由的软件测试风格，强调测试人员同时开展测试学习、设计、执行和结果评估等活动，以持续优化测试工作。
首先， 探索式测试是一种软件测试风格，而不是一种具体的软件测试技术（等价类、边界值）。作为一种思维方法，探索式测试强调依据当前的情景选择合适的测试技术，而不是局限于特定的测试技术。
其次，探索式测试强调独立的测试人员的测试自有和责任，其目的是为了持续优化其工作的价值。测试人员应该为个人和团队负责， 调动能动性，发挥个人灵活性，在整体式持续优化个人和团队的产出。
最后，探索性测试建议在整个项目过程中，将测试学习、设计、执行、和结果分析评估作为相关支持的活动，并行的执行。
旨在将测试学习、审计、执行和记过分析作为一个循环快速的迭代，在较短的视角内快速多次的循环，以不断的收集反馈，调整测试。这种思想和敏捷的理念相通的。
探索性测试不是自由测试或即兴测试，而是需要有一定的方法来指导。 自由测试更加强调测试的自由和随意性。
相同点是： 探索性测试和自由测试都是有即兴发挥的特点，利用直觉和经验，快速的验证被测应用，并不停的调整测试策略。
不同点是： 探索出测试更偏重带着反思的学习和优化过程， 测试人员不断的提出假设，用测试去验证假设，通过分析测试结果来证实或推翻假设。在这个过程中测试人员不断的完善头脑中被测应用的模型， 然后利用模型、技能、经验去驱动进一步的测试。
探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
这里并不是说探索式测试不要测试计划和测试设计，探索性测试也是要先作测试计划，根据对测试应用的分析以及模型的建立， 确定待实施的测试任务，每个测试任务明确测试时长。
探索式测试每个任务一定要明确测试时长，这也是测试计划的一个重要方面。 如果没有确定时长，很可能一个任务会执行很久，而却没有明显的收益， 投入和产出失衡，效率太低。
对每个测试任务，实施测试设计和执行，探索式测试设计是在头脑建立测试模型和假设的时进行的， 和测试执行切换的非常快，所以容易被误解为没有测试设计。
提问：
1、探索性测试的测试设计是在进行探索式测试的过程中进行的， 如前面所言， 测试设计、执行、结果分析是基本上并行的， 这个过程中的测试设计很多也很快，并不是每个测试设计都有价值的， 所言不需要把过程中的用例都进行后面补充。 只对已经发现了问题或故障或前面明显的测试设计遗漏部分进行用例补充。
2、每种测试方法或技术都有其适用的场景或范围， 探索性测试的定位并不是完整覆盖测试。
3、探索性测试一般是在回归测试完成的时候进行， 可以简单的理解为我把已知的该测试的都已经测试了， 去进一步的挖掘深入的bug的活动。
二、探索性测试的主要类型
探索式软件测试一共分为自由式探索式测试、基于场景的探索式测试、基于策略的探索式测试和基于反馈的探索式测试。下面将详细介绍4种类型的应用场景。
自由式探索式测试指的是对一个应用程序的所有功能，以任意次序、使用任何如数进行随机探测，而不考虑哪些功能是否必须包括在内。
一个自由测试用例可能会被选中成为一个快速的冒烟测试，用它来检查是否会找到重大的崩溃或者严重的软件缺陷，或是在采用先进的技术之前通过它来熟悉一个应用程序。
显然，自由式探索式测试无需也不应该进行大量的准备规则。事实上，它更像是“探索”而不是“测试”，所以我们应当相应的调整对它的期望值。
基于场景的探索式测试和传统的基于场景的测试有类似之处。两者都涉及到一个开始点，就是用户故事或者是文档化的端到端场景的开始之处，那也是我们所期望的最终用户开始执行应用程序的地方。
这些场景可以来自用户研究、应用程序、以前版本的数据等，并作为脚本用于测试软件。探索式测试是对传统场景测试的补充，把脚本的应用范围扩大到了更改、调整和改变用户执行路径的范畴
使用场景作为指导的探索式测试人员经常会修改他感兴趣的输入或者是追寻一些并没有包括在脚本中的潜在副作用。不过，由于最终的目标是完成给出的场景，这些测试上的弯路、最终总是会回到脚本文件记载的用户主要执行路径。
将自由式测试探索式与具有测试老手的经验、技能和感知融合在一起，就成为基于策略的探索式测试。
它属于自由式的探索，只是他是在现有的错误搜索技术下引导完成的。基于策略的探索式测试应用所有的已知技术(如边界值分析或组合测试)和未知的本能(如异常处理往往容易出现软件缺陷)，来指导测试人员进行测试。
这些已知的策略是基于策略的探索式测试成功的关键，存储的测试知识越丰富，测试就会更有效率。这些策略缘于积累下来的知识，它们指导软件缺陷隐藏在哪里，如何综合人工输入数据，那些代码路径常常出现故障。
基于策略的探索式测试结合了测试老手的经验和探索型测试人员的随机性。
基于反馈的探索式测试可以适应于以上的其他测试类型，测试人员们就会利用反馈来指导今后的探索。
“测试覆盖”就是一个典型的例子。测试人员通过覆盖率指标(代码覆盖、用户界面覆盖、特性覆盖、输入覆盖或者其中的某一些组合)来选中新的测试用例，以使这些覆盖指标得以提高。
基于反馈的探索式测试时一种“上一次测试”：在上一次我根据应用程序的最后状态选了每某一个输入之后、下一次我就会选中另外一个输入。或者是，在上一次遇到这个界面时我用A属性，这一次我就会用B属性。
基于反馈的探索式测试工具是非常有价值的，它可以是测试人员保存、搜索测试历史并据此采取实时行动。
三、探索性测试方法/思路
探索性测试方法和我们传统的测试方法很多都是相通的， 看起来并没有什么高明之处，主要是一种测试思路
极限测试法：向软件提出很多难以回答的问题，即找麻烦测试法，让软件性能达到最大极限、输入或者计算量达到设计的最大能力，此时可能会出现一些crash等异常情况。
极限测试法借助测试工具、脚本更容易达到效果。 值得说明的是， 不是通过手工进行测试才是探索性测试，探索性测试是一种方法和思路，具体的实现要尽量的采用更有效或更能达到目的的手段。
破坏测试法：测试者要掌握某些操作成功需要的资源，从破坏应用程序的角度，如强制软件做一些操作，在不同程度上删除或者限制程序正常使用所需的资源。
恶邻测试法：需求和功能特性耦合的地方最容易出现bug，找到那些缺陷数目较多的功能特性，把这些产品特性连接起来，最好能形成文档，后续对邻近功能特性进行重点测试。
反叛测试法：输入最不可能的数据或已知的恶意输入或程序
麻烦测试法：只要软件允许这么做，就去做而不管有什么实际意义。因为现实中用户确实也可能也会在允许的范围内这么做
强迫症测试法：反复进行同样的操作或者反复输入同样的数据，由于性能不足、恶意使用或者用户重复提交同一请求等。
取消测试法：启动一个业务操作，操作过程或业务流程中停止或取消， 看系统是否支持流程终止、取消或回退。
出租车测试法：测试人员需要和出租车司机一样熟悉到达指定位置的每条可能的路径。那一些路径不常用，哪一些路径没有覆盖，那么就是我们探索的重点。
懒汉测试法：测试人员没有做很多事情不意味着软件也不做事情。接受默认值、保持输入字段继续为空，在表单中尽可能少填数据，在进入下一个界面不点击任何按钮或输入数据。
keira_lu
发布了8 篇原创文章 · 获赞 14 · 访问量 1203
私信
关注
标签：场景,探索,探索性,测试法,测试人员,测试 来源： https://blog.csdn.net/qq_34516733/article/details/104157875