探索性测试如何实现落地？

探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

一、探索性测试的定义

探索性测试（Exploratory Testing，简称ET）是一种自由的软件测试风格，强调测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。

探索性测试的核心是：

探索性测试是一种软件测试风格，而不是一种具体的软件测试技术（如等价类划分、边界值分析、组合测试等）。测试人员可以在探索式测试中使用任何一种测试技术，也可以将探索式测试应用于任何测试阶段。

探索性测试强调独立测试人员的个人自由和责任。测试人员应该为个人和团队负责，调动所有能量，发挥人的灵活性，在整体上持续优化个人和团队的产出。

探索性测试建议在整个项目过程中，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，并行地执行。

二、探索性测试的设计理念

2.1. 思维模型

探索性测试的思维模型CPIE（Collation，Prioritization，Investigation，Experimentation），包含迭代的4个阶段：整理、排序、调查和实验。

图2.1探索式测试的思维模型

s整理（Collation）：尽最大可能收集关于被测产品的信息，去了解和理解它们。

s排序（Prioritization）：确定所有测试任务的优先级。

s调查（Investigation）：对即将执行的测试任务进行仔细的分析并确定测试输入和预期输出

s实验（Experimentation）：实际地去测试，验证我们的预测是否正确，检查我们在整理阶段获取到的信息是否正确。根据实验结果，测试人员将收集更多的信息，并调整测试任务的优先级。

2.2. 思维过程

探索性测试的思维过程，包含一组启发式问题，以推动测试人员在知识（Knowledge）、分析（Analysis）、实验（Experiment）和测试故事（Testing Story）上深入探究。

图2.2探索式测试的思维过程

s知识（Knowledge）：掌握产品特性、开发技术、测试技术和领域规则等测试需要的知识。

s分析（Analysis）：分析产品风险、测试覆盖、测试方法、测试先知和产品缺陷等测试相关因素。

s实验（Experiment）：配置、操作、观察和评估被测产品。

s测试故事（Testing Story）：用测试计划、测试报告和可工作的产品等组成测试报告，以准确地反映测试状态和产品质量。

从图2.1和图2.2可以看出两个观点都强调通过实验（Experiment）来持续改进测试设计。

三、 探索性测试的典型技术

在项目测试过程中，根据不同产品的特性，将产品功能测试分成三个层次，下面分别关注探索性测试在各层次上的测试设计，并介绍能够快速对不同特性进行测试和分析的方法。

图3.1功能测试基本层次

3.1.单个特性测试方法

3.1.1联想输入（Legend Input）模型

联想输入模型的基本方法是，先在所有输入的全集中生成分类子集，然后根据测试对象选择一个子集进行测试，接着评估测试输入是否提供了足够的测试覆盖。如果测试覆盖有待提高，则继续选择测试子集进行测试。

图3.2联想输入模型的基本方法

联想输入的基础分类，测试输入划分为原子输入和抽象输入。

原子输入：对系统而言是简单到不能再简单的输入，属于单个事件。如单击按钮和输入密码等。

抽象输入：将有相互关联的原子输入合并在一起，则构成抽象输入。如提交用户注册表单，它包含输入用户名、密码等原子输入。

先将原子输入进行合法和非法输入的基础分类，进一步分析原子输入的非法输入部分，总结为以下三种常见模式：

s输入筛选器：用于防止非法的输入值被传递给应用软件的功能代码，其产生的错误信息通常不返回给用户。

s输入检查：属于功能代码的一部分，通常用if–else语句来实现，产生特定的错误信息。

s异常处理代码：把整个例程作为一个整体进行异常处理并产生通用的出错信息。

图3.3原子输入的非法处理

执行合法输入的测试时需要考虑非常规的输入，特别是可接受输入的特殊字符。

图3.4合法输入的分解

对于常规输入，也需要进一步细化。对于默认值的测试需要充分考虑，不但要测试输入界面的默认值，还要测试清除默认值后，输入流程能否继续。如果可以继续，空值（NULL）会不会导致软件缺陷。

图3.5常规输入的分解

系统输出也需要进一步细化，需要逆向思维，能够从系统输出中推算出该使用什么测试输入，从而保证系统所有的输出都是经过检查和测试的。

图3.6系统输出的分解

3.1.2互联网测试模型

将业界非常好的测试经验总结成测试模型，并将测试模型分成三个层次。

图3.7互联网测试模型的三个层次

下面描述一些比较经典的互联网测试模型。

模型1：多线程并发模型

图3.8多线程并发模型图

模型解释：

（1）多线程创建、更新、删除某类数据，以多线程方式（同时打开多个页面或浏览器，或使用工具模拟）来操作数据并检查数据的完整性。

（2）同时使用多个浏览器或一个浏览器的多个标签页进行测试，考虑Cookie值的变化是否影响后续的操作，或使用后续描述的场景探索模型多角度地检查页面信息和数据库数据的正确性。

应用场景：

（1）在涉及管理操作的一些基础功能的时候考虑此测试模型，如新增、编辑、删除一个信息等。

（2）适用于多种形式的数据管理功能，测试对象不仅仅包括浏览器或客户端，还包括其他的数据访问形式。

模型2：时间边界模型

图3.9时间边界模型图

模型解释：

（1）在测试底层系统时，需考虑时间对于产品的影响，特别是通信时间差，另外还要考虑在业务数据计算过程中年月日的边界情况、特殊年份等。

（2）通过修改客户端或服务器时间来校验带有时间和日期限制的功能，或考虑手机和后台服务器的时间差异。

应用场景：

（1）在涉及时长或时间差配置信息的功能时，先分析该时长或时间差的区间范围，然后设计边界情况和特殊值。

（2）在涉及独立时间存储或计算的功能时，考虑这些功能交互时它们的时间是否会不一致，如果不一致发生，会不会导致严重的错误。

模型3：页面安全测试模型

图3.10页面安全测试模型图

模型解释：

（1）在功能测试过程中，需考虑URL的安全问题和可能存在的XSS漏洞。

（2）在测试页面中输入框的校验时，考虑该页面是否存在XSS漏洞，可以使用安全测试手段来做更多安全性测试。

（3）在URL中加入一些JS代码从而实现页面URL跳转错误。考虑URL里面的参数名称和数据库中相应字段的对应关系，或修改URL参数以尝试访问某些本应不可操作的功能。

应用场景：

（1）在测试页面链接或特性之间的跳转功能时。

（2）当页面存在一些通用的输入控件时，特别是富文本框和一些会传达数据到后台数据库的页面控件。

模型4：功能操作异常模型

图3.11功能操作异常模型图

模型解释：

（1）编辑某类数据的时候，考虑编辑前后的数据变化，不仅检查页面上的变化，还需要查看数据库中字段值的变化。

（2）在进行新增、更新、发布等管理操作时，操作成功后考虑刷新页面或取消提交，或考虑使Cookie失效，或使会话（Session）数据没有更新，或密切观察第一次提交时是否存在异常。

（3）在增删改数据时，考虑更新后的数据是否影响其他功能在页面上的显示。

（4）操作功能，检查功能执行的响应速度（或消耗的内存空间）来判断该功能是否正确执行完成，或执行过程中是否存在异常等。

应用场景：

（1）在涉及增删改等管理操作的功能时。

（2）当存在多个功能交互时，需要考虑在时间和存储空间上存在细微差异。

模型5：搜索查询异常模型

图3.12搜索查询异常模型图

模型解释：

（1）进行搜索或查询功能测试时，多考虑特殊字符查询，如空格、带字母、&、‘、“、\等特殊符号。

（2）由于数据量小，在测试环境下搜索查询不会出现严重超时的问题，在预发布测试的时候，注意一些搜索条件可能导致在大数据量情况下的超时问题。

（3）对于搜索功能，查看搜索查询传入的参数的正确性和完整性，以及和搜索结果的对应关系。

（4）在使用某些查询或搜索功能时，查询项中存在数据获取，在查询一个不存在的任务记录的情况后，再次查看该查询项的数据获取是否正确，考虑页面缓存，同样也需考虑搜索结果中含有边界属性值的情况。

应用场景：

（1）在测试搜索或查询功能时。

（2）当存在多个查询条件和搜索条件、或这些条件存在多个交互时。

模型6：数据库校验模型

图3.13数据库校验模型图

模型解释：

（1）对于数据中的键（Key）或关键字段的数据类型进行最小、最大边界值的校验，对于业务计算中的浮点数和浮点数进位进行更精确的校验。针对键字段，多次插入或更新数据，来检验字段唯一性约束。

（2）在数据库设计中，对于同一个字段在不同的表中的属性是否相同进行校验重点检查“是否为空”和“限制性”。

（3）在数据库设计中，测试分库分表策略的操作，重点测试同样的更新操作对所有表是否可以成功执行，还要特别留意多线程并发的情况。

应用场景：

（1）在涉及数据库设计和表的查询、更新、删除的操作时。

（2）当存在多一些对于库和表进行优化的策略的时候，考虑该策略带来的潜在的影响。

3.1.3漫游测试模型

漫游测试方法总共包括二十多种测试方法，分为两种，一种是适用于单个特性的测试方法，另一种是适用于交互特性的测试方法。以下是针对单个特性的测试方法。

图3.14适用于单个特性的漫游测试方法

3.1.4相关案例

接下来介绍单个特性测试方法发现的缺陷案例，主要以自有生产平台三期为例。

案例：任务查询列表，修改过产品广告位后就无法显示社区（BugID 6483）

步骤1：在产品管理-产品类型管理、城市管理、社区管理、产品管理中依次建立所需的报刊模板、城市信息（北京）、社区信息（西城、朝阳）、北京报刊。

步骤2：正确新建订单，完成投放，并上传任务。在任务管理-任务查询及上传中可以查看到任务信息。

步骤3：修改产品信息的广告位名称，产品页面正确显示。

结果：当重新新建订单，完成投放，并上传任务。在任务管理-任务查询及上传查看任务信息时社区信息无法显示。

讨论：本案例使用“互联网测试模型”的“功能操作异常模型”方法来发现该缺陷。在增删改数据时，考虑更新后的数据是否影响其他功能在页面上的显示。

3.2. 交互特性测试方法

图3.15适用于交互特性的场景探索模型

3.3. 系统交互测试方法

1. 通用功能性与稳定性测试过程（GeneralFunctionality and Stability Test Procedure）

该测试流程以探索式测试为核心方法，专注于软件的功能和稳定性，分为三部分：

s确定产品目的和功能

s确定潜在的不稳定区域

s测试产品的功能性和稳定性

2. 漫游地图模型

图3.5漫游地图模型

3. 肥皂剧测试（Soap OperaTesting）模型

遵循如下步骤来构造肥皂剧测试用例：

s分析产品，确定产品的功能点，并拟定测试目标。

s设计一条或多条肥皂剧测试用例，以满足测试目标。

s如果发现新的测试目标，延展已有的测试用例或增加新测试用例，以确保测试覆盖率。

拥有独立的测试设计与评审阶段，是肥皂剧测试的一个优点。用一句话归纳其特征：源于真实生活、夸张、浓缩，同时要充满乐趣。

四、敏捷测试与探索性测试

在探索性测试中，测试人员不断地提出假设，用测试去检验假设，通过解读测试结果来证实或推翻假设。在这个过程中，测试人员不断完善头脑中被测试应用的模型，然后利用模型、技能、经验去驱动进一步的测试。

探索性测试是带着“反思”的学习和优化过程，其目的是为了持续优化其工作的价值，这和精益生产、敏捷软件开发的理念高度一致，这也是探索性测试受到敏捷团队欢迎的原因之一。

探索性测试旨在将测试学习、测试设计、测试执行和测试分析做为一个循环快速地迭代，在较短的时间内（如1个小时）完成多次循环，以不断收集反馈、调整测试、优化价值。该思路更是与敏捷软件开发小步快跑、持续反馈的理念不谋而合。

探索性测试，无论它是否应用于敏捷项目，其本质是敏捷的。通过测试逐渐学习产品，并让所学信息指导测试实践，这无疑符合敏捷价值观：工作的软件和响应变化。