​传统认知中的软件测试是一个使用测试用例设计技术设计用例并执行测试用例的过程。

测试用例技术的目的是确保能够更多地覆盖、检测软/硬件错误，减少冗余测试。自动化测试或多或少地被认为是机械地执行测试脚本，将预定义的测试用例输入被测系统，对比系统输出和预期结果。

然而，在实际的工程实践中我们会发现，现实世界的测试很少是基于严格、系统、以及完成记录去运行预定义的测试用例。

相较于传统的测试方法，探索性测试（ET）方法更具创造性。

测试设计、执行和学习并行，不断地学习、反馈、优化测试方法并在实践中应用。但是ET通常被认为是一种经验类方法或错误猜测法，更多地依赖隐性的经验知识，我们不否认ET的这个特点。

容易理解的是：累积的经验知识可以帮助我们更好地进行测试设计，可以帮助我们更好地辨认测试过程中的异常或故障（例如，从日志中观察到某个WARNNING输出，如何确定它是否是软件故障导致的异常输出）。

这也是本篇文章讨论ET围绕的核心问题：如何辨认故障。问题关键是：如何利用经验知识拓展ET测试技能辨认故障。

那么，我们需要哪些经验知识呢？在这里，总结出了三大类经验，是我们提高ET测试技能时需要的，分别是：领域知识、系统知识、通用软件技术知识。

一、领域知识

领域知识又可以分为用户视角和应用领域视角。

什么是用户视角？在测试设计过程中我们经常提倡的一个理念是：从用户角度使用我们的产品。

1. 用户视角

用户视角要求了我们需要学习和了解真实用户的使用习惯、方式，和在真实场景中我们产品的交互方式和内部运行情况。

因此，用户视角又可以分为：产品使用过程关联的上下文情景，上下文中的信息内容和表示形式，以及用户真实使用案例。

(1) 产品使用过程关联的上下文情景

测试人员通常是系统本身的常用用户，具有丰富的使用经验。

当测试人员意识到他们使用程序方式与实际用户使用方式相冲突的时候他们会很快地改变测试策略或测试方法，而所有的测试失败都与测试情景和测试上下文关联。

因此，基于此我们在进行ET测试的时候可以使用“产品使用过程关联的上下文情景“经验知识提高我们的测试技能。

详细来说，主要就是两点：模拟用户真实使用场景，准备尽量真实的测试数据进行测试。

(2) 上下文中的信息内容和表现形式

当测试人员模拟真实场景进行测试的时候，需要理解和观察情景中展现的上下文信息内容和表现形式。

当软件系统以一种“不尽人意”的方式呈现数据、展现结果，或者展现错误的、有缺陷的数据时，那么可能会提醒测试人员，选择更多测试数据样本进行测试，观察软件系统的表现方式。

例如：某个web系统页面按钮点击无反应，或者某个输入框输入特殊字符导致页面布局错乱。这些案例都可以成为激发测试人员发散性思考的闪光点。

(3) 客户真实案例中披露的问题

当测试人员进行探索性测试时，了解具体的真实案例、客户所在，按照客户的使用习惯测试软件系统，能够提高识别软件系统风险的能力。

例如：当测试人员测试一个新特性的向前兼容性时，导入了一个历史的复杂数据导致软件系统异常。这样的案例在客户真实情境中不乏多见，利用客户真实案例评估或测试改变的特性有助于披露隐藏在软件设计或开发中的风险问题。

2. 应用领域视角

应用程序域视角代表的是应用领域的相关知识，包括测试人员掌握的自然知识和应用程序的理论、规则和技术细节域，而不是使用上下文。

我们把这透视分为两种：概念性知识学科内容，以及学科的实用知识物质和工具。

(1) 概念性知识和学科内容

概念性知识和学科内容在此可以通俗理解为测试人员掌握的一些逻辑推理知识、测试经验等。

例如：测试人员根据某个web系统的页面提示，推理、筛选得知是应用前端问题还是应用后台程序问题。

(2) 对工具的实用性知识

工具可以帮助测试人员提高测试效率，对工具的熟悉和操作的熟稔度直接影响测试效率和测试结果分析。使用工具进行测试，测试结果可以作为测试人员的参考。

总的来说，训练测试人员的探索性测试思维需要测试人员了解相关的领域知识。图表总结，该部分知识如下：

二、系统知识

应用系统知识的两个主要视角：交互特性和系统视角，以及单个特性和功能视角。

测试人员的对系统及其相关知识和理解特征可以进一步分为知识的系统的工作机制、逻辑和交互相关知识。

1. 交互功能和系统内视角

测试人员对系统及其相关知识和理解特征可以进一步分为知识系统的工作机制、逻辑和交互，以及历史版本故障。测试人员知道特性是如何一起工作的以及系统的基本工作逻辑。

测试人员了解系统应该如何对某些事物做出反应，输入数据或配置的各种变化和可以基于这种理解来认识失败。

重点是不一定是细节的准确性，而是系统应该如何反应、系统是否有反应、反应是否正确。

例如：一个测试人员正在测试一个模拟现实生活的系统基于工程模型的情况。在这种情况下，通过观察系统的响应测试人员意识到系统未能正确反应以变化的仿真参数和性能该模型。系统要么完全没有反应，要么只反应了一部分。

值得注意的是：了解工作机制、逻辑和互动是通过观察整体反应来应用的，使系统的配置、状态或数据发生变化或者通过模拟现实的使用场景。这方面的知识也被应用于识别发生在不是直接在测试焦点中的区域，例如无意的变化。

最后，当系统知识作为测试人员一个新特性时，将一致性启发式以相似的特征和故障识别为基础，同一系统的新特性与类似特性不一致。

2. 单个特性和功能视角

单个特性和功能视角几乎是每个测试人员经常测试的类别，针对单个特性设计测试用例进行测试。

在此，我们说明探索性测试技能的时候给大家建议的是：锻炼测试人员分析日志的能力，要有敏感的“嗅觉”，能够及时发现日志中的异常打印和错误信息，并逆向追踪导致系统异常的场景、代码等。

总结一下，本部分系统知识的分类和知识类型及使用方式如下表所示：

三、通用软件工程知识

通用软件工程知识指的是能够明显发掘的错误，不需要经过深层分析。

例如：GUI层面的功能错误、布局错误，很容易让测试人员一目了然判断它是否是故障。

又例如：功能层面的可用性，可以让测试人员参考用户手册很容易判定它是否满足用户需求，是否简单可用。

它又可以分为通用正确性视角、可用性视角和直接错误视角。具体如下表所示：

总结

探索性测试是一种自由、灵活的测试风格，近年来被许多测试人员推崇，相应地也诞生了一些测试技巧，如局部探索性测试方法和全局探索性测试方法。

虽然我们不断强调探索性测试不是单纯的经验性测试，但却也不能否认丰富的经验为探索性测试带来的好处。

本文从三个角度简单阐述了如何丰富探索性测试经验，加强探索性测试技能，希望能对大家有所帮助。​