什么是探索性测试？（带你探索这个问题）

软件开发面临着快速交付的压力，一些企业开始尝试实践敏捷开发方法，有些测试人员开始接触探索性测试，以适应于敏捷开发过程。什么是探索性测试？它能够给测试工作带来哪些好处？通常在开始实践探索性测试又易于陷入哪种误区？本文将带你一起探讨这些问题。

探索性测试不是具体的某种测试技术或测试方法，而是一种测试风格或测试思维，它貌似即兴的漫游测试，但是又有着本质的不同。探索性测试是有目的的漫游测试，即带着使命在某个空间中漫游，但没有预先确定的路线，探索包括对产品与技术的深入研究和基于成果的应用实践。换句话讲，在探索性测试思维中，没有把测试用例的设计和执行完全分离开，而是强调了两者在一定程度上的并行，二者相辅相成，测试用例设计指导测试执行，同时基于对测试执行结果的分析同时要改进和补充测试用例的设计。

先来看一下探索性测试产生的由来，即测试工作中的哪些问题导致了人们最终提供并实践了探索性测试。很多企业软件测试工作都面临类似这样的问题：测试人员严格地按照测试过程，进行测试用例设计、测试用例的评审，测试执行时又百分百地全覆盖，可是产品到了用户那里依然问题不少。要寻找”罪魁祸首”，好像大家都很无辜，测试用例设计人员说了，我可是按照测试策略和计划要求对各测试项进行了设计，并且还经过了专家的有效评审；测试执行人员更是理直气壮，所有测试用例都执行了，而且有完整的测试记录和测试报告。问题到底出在哪里呢？传统的测试思维其实是建立在一种假设上，即在测试执行前是可以设计出全面的、无误测试用例，自然按照这样的用例执行完测试是可以放心地把产品交给客户。然而，这样的假设真的成立吗？非也。正是大量的测试实践告诉我们，在没有执行测试前，通常这时也没有看到实际的产品是什么样子，仅仅根据软件需求规格说明书很难设计出全面、有效的用例，如果测试执行过程中，不对测试用例进行动态的调整，仅仅以跑完之前所设计的用例作为测试执行的目标，产品的质量根本无法保证。因此，有人提出了探索性测试的思维，这种思维是建立在另一种假设之上，即我们无法在一开始就设计出完美的测试用例，在测试执行过程中，随着测试人员在测试执行过程中对产品不断深入理解，而不断地调整或重新设计测试用例，从而更加有效地发现产品缺陷，保证产品质量。

不少测试人员在刚开始接触了探索性测试之后兴奋不已，认为终于可以摆脱了测试相关的各种文档编写之苦了。这种想法正是很多人对探索性测试认识上的普遍误区，探索性测试不是即兴测试（ad hoc testing），更不是给你混乱的测试工作过程起一个好听的名字。首先，探索性测试同样需要一份经过精心设计的测试策略和测试计划，测试策略告诉我们测试的目标在哪里，哪些是测试的重点，准备应用哪些测试的方法和工具，等等；测试计划为后续工作有效的组织提供输入，也是不可少的。那么测试用例文档就不必写了吧？非也，测试用例文档一点都不少，只不过写的过程有所不同。传统的风格下，测试用例一蹴而就，后面改动很小，而采用探索性测试思维，测试用例编写与测试执行交叠在一起。首先在测试没有执行前，要根据当前对产品的认识设计出部分用例，这时不要尝试设计出所有的用例，因为由于当前对产品认识不够，你所设计的很多用例有可能到执行时没有丝毫用途，浪费了宝贵的时间。在测试执行过程，要不断地对测试结果进行思考和总结，加深对产品的应用和操作场景的理解，再设计用例以发现之前用例无法发现的问题。或许你还是在纠结为何要把测试用例写出来，难道不写不可以吗？可以，但是承担不写的代价。众所周知，同一个测试点要被多次重复测试的，如回归测试会导致重复测试，版本升级后也会导致大量的重复测试，如果测试用例没有文档化，如何保证下次测试时不遗漏？如何保证测试人员变换后仍然执行了你在头脑中所设计用例？

探索性测试是一种新生的测试思维，在不误用和滥用探索性测试的前提下，在某些情况下它不失为更合适的一种工作风格，它消除了过去”官僚式”的作为，下达命令（设计测试用例），然后执行，而是给测试执行人员更大的权力，当然能力要求也更高，并且把过去枯燥被动的执行测试活动变成了有趣的、充满创意的工作。