1、探索式测试的定义

如何理解探索式测试

是一种软件测试风格和思考方法，不拘泥于具体的测试技术；外延是这种思考方法下发展出来的测试技术，包括测试设计方法、测试管理方法、测试辅助工具等

测试人员在进行探索式测试时，可以调动团队所有力量，优化个人和团队产出；

探索式测试旨在将测试学习、测试设计和测试结果分析作为一个循环快速的迭代，以不断收集反馈、调整测试、优化价值。

语境驱动测试（context driven testing）7原则：

• 原则1：任何实践的价值都取决于其语境（Context）。
• 原则2：在特定语境下存在好的实践，但不存在最佳实践。
• 原则3：人，在一起工作的人，是项目语境中最重要的部分。
• 原则4：项目的发展往往难以预料。

显式规格说明（不完整、模糊、包含错误的项目文档）和隐式规格说明（包括竞争对手产品、相关产品、已发布版本、电子邮件讨论、口头讨论、论坛反馈、第三方评论、技术标准、法律法规、博客文章、领域专著、测试经验等）

• 原则5：产品是一种解决方案。如果问题没有被解决，它就是无用的（Doesn’t Work）。
• 原则6：好的软件测试是一个具有挑战性的智力过程。
• 原则7：只有通过判断和技能，并在整个项目过程中协同练习（Exercise Cooperatively）它们，我们才能在正确的时间做正确的事，以有效地测试我们的产品。

依据Smart原则，开展探索式测试步骤

(S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound),
确立mission 拆分 测试 调整 反思优化

探索式测试与即兴测试、脚本测试

脚本测试的优缺点

• 优点：被测对象可以被更仔细的思考/脚本可评审/脚本可复用/评估脚本是否完备/执行时可度量进度
• 缺点：资源被占用或浪费/压抑测试的灵活性/维护成本高/测试价值重心错位

探索式测试，编写的测试文档特点

• 测试计划的编写与改进贯穿整个测试过程
• 测试人员持续的收集对测试计划的意见，并将改进意见纳入测试实践
• 测试计划侧重测试规划和测试策略，而不是脚本化的测试用

软件测试，学习范围：

行业知识
用户角色
软件产品
计算平台
开发技能
程序缺陷
测试技术
开发团队

实践所学内容

测试输入数据、结果检查脚本、数据分析报告、业务流程图表

探索式测试适用于各类型的测试

测试记录包含的内容

• 测试目标
• 测试范围 （功能、模块、用户场景等）
• 测试策略（使用了何种测试方法）
• 缺陷列表
• 测试过程中发现的疑问，值得进一步探讨
• 可以复用的测试资源：被测试软件配置、测试数据和测试脚本等
• session的耗时
• session的时间分配，在测试设计与执行、缺陷调查与报告、session的启动与结束和非测试活动上个花费了多少时间

帮助新手成长，可以采用的方法：

安排工作导师、评审其测试文档、评审其测试记录、在session中安排测试专家与他结对测试、定期进行一对一的会谈等。

James A Whittaker 提出的测试工具构建方法：

1. 寻找缺陷：发现或手机软件的缺陷
2. 提炼模式：分析出缺陷的根本原因，编写一个模式，用它捕捉相似的缺陷。一个模式是一个结构化的攻击手段，他包括如下内容：
   • 何时实施该攻击
   • 该攻击会捕捉何种错误
   • 利用该攻击如何识别软件失败
   • 如何实施攻击
   • 样例和分析
3. 开发自动化工具：识别出攻击过程中机械的部分，编写一个工具去自动化模式的应用。（提供计算机辅助功能）

探索式测试在本质上是敏捷的，且可以很好的应用于敏捷项目

2、探索式测试设计概论

思维模型、测试先知、测试过程、测试覆盖等测试要素、启发式测试策略模型

探索式测试的思维模型：

整理、排序、调查和实验

测试人员拿到测试任务后，需要从两个大方向考虑：

• 测试人员：测试经验/被测产品的行业经验/对需求的了解程度
• 被测产品：产品开发目前所处的阶段/是否经过了测试，使用了哪些类型的测试，覆盖了哪些功能和属性/产品目前的风险或潜在问题有哪些？

参考HICCUPPS（F）启发式规则构造测试先知

• History历史
• image 愿景
• comparable products相似产品
• claims声明
• user’s expectation 用户期待
• product产品自身
• purpose 目的
• statutes 法规
• familiarity 常识

测试人员构造先知的单个可能的思路：

• 忽略
• 简化
• 转移

启发式方法产生更多更好的思路？？？：

引导词启发法
触发器启发法
副标题启发法
启发式模型

[

](#Ckl3S)

探索式测试要像对一个人面试，测试人员要提出高质量的问题，培养相应的能力技巧：

1. 提出有用的问题（目的驱动问题）
2. 观察什么事情正在发生
3. 描述自己能够感觉到或看到的东西
4. 对于自己的所知进行批判性的思考
5. 组织和管理业务上的规则
6. 能够提出假设和进行实验验证
7. 尽管已经了解，但仍然进行深入思考
8. 分析其他人的思考方式
9. 根据因果关系进行推导

类比足球传球
能够接到球？确认已经接到？几种处理方式？我的角色和任务？装备是否ready？队友在哪？球场形势如何？队友能帮我？情况是否严重？是否做好行动准备？······

根据以下的因素对产品、需求和模块进行分析

• 产品和项目因素
• 测试覆盖
• 测试先知
• 资源和限制
• 价值和成本
• 已存在的缺陷

测试人员试验步骤：

配置；操作；观察；评估

实验过程中探索的思路

测试学习通常包含的步骤

• 形成一个关于产品功能的模型
• 了解这个产品旨在完成什么任务
• 列出需要测试的产品元素
• 常识构建多个测试先知，参考HICCUPPS（F）启发式规则开发一批针对当前产品的测试先知
• 产生测试数据
• 考虑被测产品的可测性和尝试不同的测试工具
• 尝试用多种不同的方法去试验
• 报告所发现的产品缺陷

试验过程中，测试人员可以用来解除疑虑的方法：

• 简化自己的测试思路
• 保留测试现场并寻求帮助
• 不断重复执行自己的操作
• 返回到一个已确认过的状态
• 一次只考虑一个因素，一次只修改一个因素
• 作出精确的观察

plunge in and quit 陷入与退出原则

产品的主要功能、贡献性功能 可以从6个方面考虑测试覆盖

1. 结构（structure）覆盖。测试人员要分析产品是如何构成的，然后用测试去覆盖产品的重要组成部分。
2. 功能（function）覆盖。测试人员要分析包含哪些功能，然后用测试去覆盖功能点。
3. 数据（Data）覆盖。测试人员要分析产品会处理什么数据、传输什么数据、输出什么数据，并用测试覆盖这些内容。
4. 平台（platform）覆盖。测试人员要分析产品依赖什么平台及平台特性，并用测试覆盖这些平台和特性。
5. 操作（operation）覆盖。测试人员要分析用户是如何使用产品的，并用测试覆盖使用流程和操作。（稳定性、可用性、安全性、可扩展性、性能、可安装性、兼容性、可测性、可维护性和本地化等因素）
6. 时间（time）覆盖。测试人员要分析产品受什么时间因素的影响，并用测试覆盖有风险的因素。

可测试性主要包括：

• 可操作性
• 可控制性
• 可观察性
• 简单性
• 稳定性
• 易理解性

启发式测试策略模型HTSM（heuristic test strategy model）

测试人员利用质量标准（quality criteria）、项目环境（project environment）、产品元素（project elements）、指导测试技术（test techniques）的选择与应用，产生观察到的质量（perveived quality）

测试技术：生成测试的策略

• 可选的测试技术如下：
• 功能测试
• 域测试
• 压力测试
• 流测试
• 场景测试
• 声明测试
• 用户测试
• 风险测试
• 自动测试

项目环境：资源、约束和其他影响测试的项目因素包括：

• 用户
• 信息
• 开发者关系
• 测试团队
• 设备与工具
• 进度
• 测试条目
• 交付品

产品元素：需要测试的对象

• 包括：
• 结构
• 功能
• 数据
• 平台
• 操作
• 时间

质量标准之操作性标准；面向用户和运营团队，包括：

• 能力
• 可靠性
• 可用性
• 安全性
• 可伸缩性
• 性能
• 可安装性
• 兼容性

质量标准之开发标准：面向开发团队

• 可支持性
• 可测试性
• 可维护性
• 可移植性
• 本地化能力

micheal larsen www.xmind.net/share/mkltesthead

htsm，自问：

该元素与当前测试任务相关吗？
针对改元素，产品有什么风险？可能会有什么缺陷？
通过什么测试可以发现这些缺陷？
依据当前的进度和资源，如何实施这些测试？

3、单个特性测试方法

黑盒视角下的被测产品及相关因素

输入、需求、事件、输出

团队中评选测出的好的bug，缺陷模版

缺陷描述 
[缺陷场景]：·····
[缺陷动作]：1、·····      2、······
[预期结果]：
[实际结果]：
缺陷原因
·······
缺陷影响
·····缺陷发现过程·······
缺陷解决方法
测试技术或方法传承

发现的bug，质量是否高，评价的维度

• 缺陷发现阶段
• 缺陷根因分析（深度）
• 缺陷发现难度
• 测试技术/方法的创新性
• 测试技术/方法的复用性
• 业务维度
• 用户影响（基于产品线的用户）
• 用户体验

https://www.cnblogs.com/liangshi/archive/2010/09/23/1833374.html

优秀的测试人员能发现一些隐藏比较深的缺陷，主要有以下几个关键因素：

• 对于基本的测试设计技术的掌握达到炉火纯青的地步
• 对于错误猜测测试方法有一定的理解和应用
• 拥有开放思维
• 了解用户习惯，知晓不常见的用户操作和使用场景

作者将测试经验总结成测试模型，分成3个层次：

功能测试模型/线下缺陷模型/线上故障模型

功能测试模型之页面动作：

翻页动作/文件上传动作/文件下载动作/表单清空动作/表单提交动作/全选or反选动作/重置动作

功能测试模型之基本操作：

单个查询操作/级联查询操作/新增操作/修改操作/删除操作/数据导入操作

典型的互联网测试模型

模型1:多线程并发模型

（1）多线程创建、更新、删除某类数据，以多线程方式（同时打开多个页面或浏览器，或使用工具模拟）来操作数据并检查数据的完整性
（2）同时使用多个浏览器或一个浏览器的多个标签页（Tab）进行测试，考虑Cookie值的变化是否影响后续的操作，或使用场景探索模型多角度的检查页面和数据库数据的正确性

应用场景：
（1）在涉及管理操作的一些基础功能的时候考虑此测试模型，如新增一个会员、编辑一个会员信息、删除一个会员信息等。
（2）适用于多种形式的数据管理功能，测试对象不仅仅包括浏览器或客户端，还包括其他的数据访问形式。

模型2:时间边界模型

（1）在测试底层系统中，需要考虑时间对于产品的影响，特别是通信时间差，另外还要考虑再业务数据计算过程中年月日的边界情况、特殊年份等。
（2）通过修改客户端或服务器时间来校验带有时间和日期限制的功能，或考虑手机和后台服务器的时间差异。

应用场景：
（1）在涉及时长或时间差配置信息的功能时，先分析该时长或时间差的区间范围，然后设计边界情况和特殊值。
（2）在涉及独立时间存储或计算的功能时，考虑这些功能交互时它们的时间是否不一致，如果不一致发生，会不会导致严重的错误。
http://qa.taobao.com/?p=12432
Alibaba QA 阿里巴巴技术质量 (alibabatechqa.com)

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

（1）在功能测试过程中，需要考虑URL的安全问题和可能存在的XRR漏洞
（2）在测试页面中输入框的校验时，考虑该页面是否存在XRR漏洞，可以使用安全测试手段来做更多安全性测试
（3）在URL中加入一些JS代码从而实现页面URL跳转错误，考虑URl里面的参数名称和数据库中享用字段的对应关系，或修改URL参数尝试访问某些本不可操作的功能

应用场景：
（1）在测试页面链接或特性之间的跳转功能时
（2）当页面存在一些通用的输入控件时，特别是富文本框和一些会传送数据到后台数据库的页面控件。
<img src=# onerror="alert(1)">

相关书籍：《web安全测试》
Web安全测试 (豆瓣) (douban.com)

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

（1）编辑某类数据的时候，考虑编辑前和编辑后的数据变化，不仅检查页面上的变化，还需要查看数据库中字段值的变化。
（2）在进行新增、更新、发布等管理操作时，操作成功后考虑刷新页面或取消提交，或考虑Cookie失效，或使会话（Session）数据没有更新，或密切观察第一次提交时是否存在异常。
（3）在修改、删除、增加数据时，考虑更新后的数据是否影响其他功能在页面上的显示。
（4）操作功能，检查功能执行的响应速度（或消耗的内存空间）来判断该功能是否正确执行完成，或执行过程中是否存在异常等。

应用场景：
（1）在涉及创建、编辑、删除等管理操作的功能时。
（2）当存在多个功能交互时，需要考虑在时间和存储空间上存在细微差异。

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

（1）进行搜索或查询功能测试时，多考虑特殊字符查询，如空格、带字母、&、‘、“、\等特殊符号。
（2）由于数量小，在测试环境下搜索查询不会出现严重超时的问题，在预发布测试的时候，注意一些搜索条件可能导致在大量数据量情况下的超时问题。
（3）对于搜索功能，查看搜索查询传入的参数的正确性和完整性，以及和搜索结果的对应关系。
（4）在使用某些查询或搜索功能时，查询项中存在数据获取，在查询一个不存在的任何记录的情况下，再次查看该查询项的数据获取是否正确，考虑页面缓存，也同样需要考虑搜索结果中含有边界属性值的情况。

应用场景：
（1）在测试搜索或查询功能时
（2）当存在多个查询条件和搜索条件、或这些条件存在多个交互时

模型6:数据库校验模型

（1）对于数据库中的键（Key）或关键字段的数据类型进行最小、最大边界值的校验，对于业务计算中的浮点数和浮点数进位进行更精确的校验。针对键字段，多次插入或更新数据，来检验字段唯一性约束。
（2）在数据库设计中，对于同一个字段在不同的表中的属性是否相同进行校验，重点检查“是否为空”和“限制性”这两个属性
（3）在数据库设计中，测试分库分表策略的操作，重点测试同样的更新操作对所有的表是否可以成功执行，还要特别留意多线程并发的情况。

应用场景：
（1）在涉及数据库表设计和表的查询、更新、删除的操作时。
（2）当存在一些对于库和表进行优化的策略的时候，考虑该策略带来的潜在的影响

不同的模型可以记录相应的缺陷案例，格式参考：

（1）缺陷1:······
01发现过程：
a）···
b）···
02 缺陷暴露：（对后续使用的影响）·······
03 缺陷分析：
（2）缺陷2:···
····

漫游测试模型基础测试方法：

方法1: 卖点测试法（The Money Tour）

定义：测试人员找到本产品最吸引用户的功能或特性，按照产品演示步骤来测试特性。
好处：判断“卖点”是否解决了用户的问题：重点放在“卖点”，二八原则（测试资源投入在用户最常用的功能和操作上，有助于提高核心功能的稳定性。）

方法2:恶邻测试法（The Bad Neighborhad Tour）

定义：测试人员找到哪些缺陷数目较多的功能特性，并对邻近功能特性进行重点测试。
好处：了解产品适量上的大致情况；缺陷较多的地方反复测试，降低软件质量上的风险

方法3:配角测试法（The Supporting Actor Tour）

定义：测试人员找到哪些紧邻主要功能的特性，从而对这些特性进行额外的测试和关注
好处：紧邻主要功能的功能特性，支撑主要功能，能提高产品的稳定性和安全性。也给用户提供更多的选择空间。

方法4:超模测试法（The Super Model Tour）

定义：测试人员只关心产品的界面显示，测试用户界面上的各种因素，包括用户友好性、美观性、性能等。
（布局是否合理、是否符合用户习惯、注意按钮大小和位置、各个链接是否正确、提示信息是否合理和明确、是否有错别字、对话框内容是否正确、内容无歧义、）
好处：关注用户界面，提高产品可操作性、用户体验和易用性。

方法5:懒汉测试法（The Couch Potato Tour）

定义：测试人员做尽量少的输入或操作流程，如接受所有默认值、保持某些字段为空、不点击相关操作按钮等，以检查程序处理默认值的能力。
好处：测试系统默认值的处理能力，提高系统的健壮性和可靠性

方法6:反叛测试法（the Antisocial Tour）

定义：测试人员输入最不可能的数据，或已知的恶意数据，或没意义的数据，从而检查程序的健壮性和容错性
好处：关注异常输入、恶意输入，提高系统的健壮性和容错性

方法7:强迫症测试法（The Obsessive-Compulsive Tour）

定义：测试人员一遍又一遍地输入同样的数据，反复地执行相同的操作
好处：考虑系统如何处理重复输入，避免重复输入对程序造成破坏，提高系统的健壮性和容错性

漫游测试模型进阶测试方法

方法1:极限测试法（The Intellectual Tour）

定义：测试人员对于某个特性提出很多难以回答的问题，运行程序查看结果是否正确
好处：考虑系统的应变承受能力，发现系统处理困难问题的能力如何

方法2:麻烦测试法（Arrogant America Tour）

定义：测试人员对于某个特性故意设置各种障碍来看产品如何应对，思路就是采用一些非正常的使用方式。
好处：设置各种障碍查看系统程序是否考虑其异常性，关注产品的应变承受能力

方法3:通宵测试法（Clubbing Tour）

定义：测试人员连续不断地使用某个特性或将文件一直保持打开的状态，让某些特性的运行时长特别长。
好处：移动设备程序，持续运作多天是常见的场景；初始化数据没有被重置过，可能会发现一些潜在的问题。关注产品持续运作能力，有助于提高系统的可靠性和稳定性。

方法4:测一送一测试法（The Test One Get One Free Tour）

定义：测试人员同时运行一个应用程序的多个实例，多个用户使用同一个特性，类似于多线程测试模型。
好处：关注产品的并发处理能力，尽早发现访问冲突、数据损坏等严重问题；在某个实例上发现缺陷，在另外一个实例上也必然发现该缺陷。

方法5:取消测试法（the Rained_Out Tour）

定义：测试人员启动某些功能操作再停止它运行，对所有提供取消选项的功能或需要较长时间才能完成的功能执行取消操作，检查程序的自我清除能力。

方法6:破坏测试法（The Saboteur Tour）

定义：测试人员试图利用每个可能的机会暗中破坏产品，认为地创建恶劣的运行环境（内存少、无权限、断网、故障注入等）。

有效的测试方法不是一成不变，是需要所有测试同仁去完善、去创造的。

4、交互特性测试方法

有价值的场景包含的信息：

• 用户故事
• 描述的需求
• 集成场景
• 设置和安装
• 警告和出错

交互特性测试，场景操作模型

方法1:插入步骤——增加更多数据

定义：测试人员在执行测试场景的时候，让基础测试场景选择更多的数据进行操作

方法2:插入步骤——使用附加输入

定义：测试人员在测试测试场景的时候，关注是否能够给出一些没有被提到的额外输入值。

方法3:插入步骤——访问新的界面

定义：测试人员在执行测试场景的时候，关注能否访问和基础场景有关的其他功能的页面。

方法4:删除步骤——删除部分步骤

定义：测试人员在执行测试场景的时候，去掉基础场景中可选的步骤，使场景的步骤尽可能少。

方法5:替换步骤——替换部分步骤

定义：测试人员在执行测试场景的时候，可以替换某个操作步骤，使用新的操作步骤进行场景测试。

方法6:重复步骤——重复部分步骤

定义：测试人员执行测试场景的时候，可以通过重复单个步骤或一组步骤来改变这个场景。

方法7:替换数据——替换部分数据

定义：测试人员在执行测试场景的时候，可以修改或替换产品使用的数据来改变场景的条件。

方法8:替换环境——替换硬件（可以利用虚拟机技术）

定义：测试人员在执行测试场景的时候，可以考虑在不同的机器上运行该场景，如内存较小的机器、32位或64位操作系统，单核或多核CPU等。

方法9:替换环境——替换容器

定义：测试人员在执行测试场景的时候，需要测试产品在不同的操作系统、浏览器、运行平台或插件配置下的行为。

方法10:替换环境——替换（容器）版本

定义：测试人员在执行测试场景的时候，需要测试同一个容器的不同版本。

方法11：替换环境——修改本地设置

定义：测试人员在设计测试场景的时候，可以修改测试软件所依赖的一些本地设置，如Cookie、注册表或配置文件信息等。

交互特性测试，漫游探索模型

方法1:地标测试法（The Landmark tour）

定义：测试人员通过卖点测试法找到本产品的多个关键特性，确定前后顺序，然后探索多个特性的交互过程。

方法2:快递测试法（The FedEx Tour）

定义：测试人员需要找到和确认某个特性所使用的内部数据，并且通过操作软件使得该数据走遍其相关的特性。

方法3:遍历测试法（The Garbage Collector’s Tour）

定义：测试人员按顺序罗列出非常相似的功能特性，再对这些功能的相似程度进行分类，然后进行顺序访问。

方法4:博物馆测试法（The Museum Tour）

定义：测试人员查看代码库和程序集文件，找到遗留代码，针对最近被修改过的遗留代码进行测试。

方法5:上一版本测试法（The Prior Version Tour）

定义：测试人员找到先前版本支持的所有场景和用例，使用新版本的最新需求和数据进行测试。

方法6:深巷测试法：（The Back Alley Tour）

定义：测试人员应该关注产品特性使用情况列表排在最下面的几个特性，也就是最不可能被使用的或不吸引用户的特性和小功能。

方法7：长路径测试法（The Lonely Businessman Tour）

定义：测试人员在选择某个特性并进行长路径的漫游，例如测试经过多次操作或多个页面才能完成的任务、测试跨多个业务特性的长流程业务等。

5、系统交互测试方法

James Bach 通用功能性与稳定性测试过程：

1. 确定产品目的和功能（目的陈述 问题/争论点 功能列表 主要的功能 贡献性的功能）
2. 确定潜在的不稳定区域
3. 测试产品的功能性和稳定性

目的陈述常用的表达“目的”的动词：

• 创建、编辑；
• 查看、分析、报告；
• 打印；
• 解决、计算；
• 管理、控制；
• 通信、交互；
• 提供数据、提供介入、搜索；
• 支持、保护、维护；
• 清除、解决、使其完善；
• 读取、过滤、转移、转变；
• 娱乐

在目的陈述中对用户的能力的讨论：

• 特殊技能、知识、能力、无能；
• 解决问题的能努力；
• 期望、需要；
• 限制（谁不会是这个产品的使用者）

主要功能和贡献性功能

常见的不稳定交互：

• 与其他产品进行交互的功能
• 会消耗大量内存的功能
• 与操作系统特别紧密的功能
• 很复杂的功能
• 需要改变一些操作参数配置的功能
• 需要改变操作系统配置的功能
• 捕获错误和从错误中恢复的功能
• 替代了基本的操作系统功能的功能
• 涉及了多线程工作的功能
• 同时操作多个文件的功能
• 需要从网络上打开文件的功能
• ······

针对不稳定的功能，可以参考以下有挑战性的数据和测试想法：

• 文档：大的文档，同时打开许多文档或文档中包含许多不同的对象
• 记录：长的记录、很大数量的记录或复杂的记录
• 列表：长的列表、空的列表或多列的列表
• 字段：输入大量字符和非常大的值
• 变化：新增和删除一些东西、编辑但没有保存或编辑成功
• 负载：使用大量进程同时运行、大量进行批处理或很短时间内做很多操作。
• 无推断：在窗口中随意点击、随意输入字符或输入无期望的值
• 异常和恢复：多次破坏进程、取消操作、使用错误数据触发错误处理。

肥皂剧测试的特征：

源于真实生活、夸张、浓缩、充满乐趣
Based on real life
exaggerated
condensed
fun

6、探索式测试的工具

测试活动对工具的需求

支持自动执行编写好的脚本工具——AutoHotKey
文本编辑器——Notepad
源文件内容（差异）对比——WinMerge | | 软件监控 | 监控产品的业务指标
监控产品的技术指标 | 监控产品进程（包含内存、线程、模块等）
监控文件系统
监控Windows注册表
监控网络通线
监控与产品通信的其他程序（包含第三方程序和操作系统的服务进程等）
监控与产品通信的Web服务 | 调试器——wekndbg
超级版任务管理器，系统工具——Process Explorer
监视并记录进程对注册表、文件系统和网络的访问——Process Monitor
开发者工具——FireBug
Web调试代理——fiddler/WireShark | | 缺陷记录 | 提交缺陷报告 | 缺陷的生命周期管理 | | | 测试评估 | 提交测试报告
评估现阶段的测试进展
发现测试遗漏
调整项目和产品的风险列表
提出新测试策略
调整资源和进度
积累测试经验 | 为生成测试报告提供支持
为测试评估提供数据支持
分享测试报告
记录测试经验
分享测试经验
支持知识的发掘、存储、检索 | |

7、探索式测试与自动化测试

Set Up——Execution——Verification——Tear Down——Reporting

自动化测试用例编写优先级

核心功能、常见场景、高风险区域、辅助功能、罕见场景、低风险场景

自动化测试原则

• 自动化测试应该有助于提高质量（可执行、易读、完备、回归时可快速定位异常行为）
• 自动化测试用例应该迅速找出重要的程序问题。
• 自动化测试用例应该易于编写和维护
• 自动化测试开发应该具有较高的投资回报率

实施探索式的自动化测试用例开发的实践

• 实践1：选择或开发适合的测试框架
• 实践2: 收集并理解规格说明
• 实践3: 开发基本测试用例
• 实践4: 阅读被测软件的源代码 （识别高风险模块、找出潜在的程序缺陷）
• 实践5: 用探索去解决困惑
• 实践6: 增加测试用例来记录对软件的理解
• 实践7: 利用测试覆盖率来增强测试套件

• 实践8: 重构测试代码

  
  
  
  8、探索式测试的组织与实施

  脚本测试特点

• 文档（计划、设计、用例）必须非常详细和明确

• 测试设计和测试用例强烈依赖于开发的文档
• 测试执行强烈依赖于预先写好的测试用例
• 测试执行对于需求变更的应对力较差

用例一般包含的内容：

• 所属产品
• 所属模块
• 用例类型
• 使用阶段
• 相关需求
• 用例标题
• 优先级
• 前置条件
• 用例步骤
• 附件

纯粹脚本化（Pure Scripted）
简单脚本化 vague Scripted 可以包含操作步骤和简单的描述
片段测试用例 fragmentary Scripted 一句话或几个词语来记录测试用例
任务 charters 测试人员用一个任务列表指导探索式测试，一个任务指出了要测试什么、怎么测试（强调策略、不是详细测试步骤）、村砸后什么样的缺陷、有哪些风险、要去检查什么文档等。
角色 roles 测试人员扮演一个特定的（用户）角色，以该角色的身份和视角驱动探索式测试。测试人员自己掌握测试任务的进度和质量。
自由风格的探索式测试（Freestyle ET）

Q1，自由风格的探索式测试
Q2，ET主导与ST辅助
Q3，ST主导与ET辅助
Q4，协作型探索式测试 Bug Bash、Pair Testing、All Sharing

Session Based Test Management中Session的基本特点

• 任务Charter（描述测试对象，并建议可能的测试策略和潜在的产品缺陷）
• 时间盒Time Box（在一个固定的时间段内不受干扰的专注地测试）
• 可评审的报告Reviewable result（包括测试笔记和缺陷报告等，记录测试策略、分享测试思路、供他人检查）
• 任务报告Debriefing（汇报，作为测程的度量结果，获得指导和建议，并做一些必要的调整）

供评审的测程表包含：

• 概述测试任务
• 测试执行者
• 开始时间
• TBS（Test/Bug/Setup）度量。记录三类活动的耗时，即测试设计和执行、缺陷调查、报告、测程准备（安装被测软件、配置测试环境等）
• 测试数据、数据文件
• 测试笔记（测试过程中随时记录的一些信息，如测试速录、风险列表等）
• 问题（测试过程中的问题和疑惑）
• 缺陷

优秀的探索式测试人员应该具备以下能力

• 测试设计（细致的分析产品、评估产品风险、使用工具分析和记录问题，并熟练使用测试设计技术）
• 细心观察
• 批判性思考（快速的评审和解释他们的思考逻辑，并能在独立思考中寻找错误）
• 丰富的想法（产生更多更好的想法）
• 丰富的资源（构建一个资源网络，包括：测试工具、信息资源、测试数据和测试同仁，使用这些资源来提高测试的效率）

在进行探索式测试实践时，需要注意的因素：

• 有策略的确定风险，加强沟通
• 关注细节，多使用极限测试法
• 百分百投入和百分百变化
• 分析测程并给出质量反括
• 记录所有疑似问题，尤其是与用户体验相关的问题

9、自由风格的探索式测试

有助于测试人员相处针对性问题的科学思考技能：

• 提出有用的问题（目的驱动的问题）
• 观察什么事情正在发生
• 描述自己能够感觉到或看到的东西
• 对于自己的所知进行批判性的思考
• 组织和管理业务上的规则
• 能够设计假设和进行试验
• 尽管已经知道了基础信息仍然进行思考
• 分析其他人的思考方式
• 根据因果关系进行推导

James Bach认为自由式探索适用的情况：

• 需要对一个新的产品或功能特性提供快速的质量反馈。
• 想快速地学习某个产品。
• 已经使用脚本测试方式测试过产品，想使测试更多样化。
• 想在最短的时间内发现重要的缺陷。
• 想通过一个简单的独立的调查来检查其他测试人员的工作情况。
• 想调查和定位某个特定的缺陷。
• 想调查某个特定风险的状态，以评估风险域是否还需要脚本测试。

进行自由式探索时，需要满足的一些条件：

• 创造性和乐趣
• 产品比较稳定
• 熟悉掌握测试技术
• 对测试用例无强制要求

探索式测试的好处

• 缺陷检测
• 质量反馈
• 检查他人工作
• 检测测试技术
• 实践测试技术

在第二轮测试后（第一轮脚本测试，第二轮验证第一轮测试发现的bug）进行自由式探索的原因：

产品稳定，大部分以发现bug已修复
测试人员前两轮的脚本测试，单调，容易出现测试疲劳
产品修复了大量的bug，质量在提高，免疫力也在提高，此时实施有助于提高测试的差异性，发现隐藏的bug

在第一轮测试之前进行测试的原因：

快速检测产品的质量，屏住建立陈品的测试模型
发现潜在的风险和不稳定因素，快速调整测试计划、策略和重点，还可以为后期自动化测试脚本的编写提供策略上的参考

测试人员可以基于实际情况在任意时间进行探索式测试

自由式探索的流程

• 1～2小时，通过相关文档，了解产品目的和背景
• 1～2小时，确定主要功能模块和贡献性功能模块
• 与相关人员沟通，了解不同模块发现的缺陷数量，看看那些模块风险较大
• 结合了解的情况和可用测试时，指定计划（session、每个session的任务、每个session的用时等）
• 测试人员根据计划，边学习产品需求边测试，发现问题立即记录，每天发送缺陷报告
• 管理测试实践和session进度，还可以通过测试笔记来记录测试时的新思路和新发现
• 与项目测试人员沟通测试进展及该产品的风险，总结测试经验和教训并分享给团队

自由式探索实践中需要注意：

• 需求规格熟悉时间不宜过长
• 测试被阻碍，立即寻求帮助
• 记录所有疑似缺陷，尤其与用户体验相关的
• 利用优势资源，尤其是数据准备和复杂流程

（et主导探索式测试）测试报告模版

报告模版中可加上
测试任务个数—— 由测试分析和风险分析所得出的测试任务的个数
测试想法个数——对测程进行测试设计所得到的想法的个数

1. ET主导与ST辅导方式的探索式测试

ET主导与ST辅导方式的探索式测试，实践的条件：

了解探索式测试
拥有丰富的测试经验
（测试团队同意）压缩测试用例编写时间
熟练掌握测试技术
全身心地投入测试

有帮助的测试技术：

等价类划分、边界值分析、域测试、组合测试、状态测试、场景测试等

MM1: 需求规格说明书评审阶段，使用基于需求的测试方法编写的MM图，确定功能点，拟用例
MM2:用例评审阶段，使用基于需求的测试方法评审用例并完善MM图，补充用例
MM3:在系统设计评审阶段，通过评审接口说明文档、详细设计文档、数据库设计文档，补充每个功能点容易遗漏的异常场景

有足够的时间和能力，可以通过代码评审进一步完善测试设计MM图。

FTT Feature to Test 画出产品的思维架构图，描述每个功能或特性
FIL Test Idea List 对每个功能点进行测试设计和测试场景的构造

测试负责人在监控和指导探索式测试人员测试过程，测试实施上的一些要点：

• 测试负责人根据被测产品、测试实践和测试使命合理地制定出测试任务和测程。
• 测试负责人基于测程和资源制定测试计划和测试策略(包含对产品的攻击策略)。
• 测试设计阶段,测试人员使用单个特性和多个特性方法开发所负责的测程的测试思路。
• 测试设计阶段,测试人员还需要梳理测程的测试先知(识别产品缺陷的所有信息,包括文档、代码等),并不断地完善测试思路列表（TIL）
• 测试执行阶段,测试人员根据TIL进行探索式测试,同时记录产品行为的可疑处,并有针对性地探索更多的测试思路(有价值的测试思路可简单记入测试笔记)。
• 测试执行完成的时候,测试人员需要真实地填写测程表(Session Sheet)
• 测试负责人查看每个测试人员的测程报告,分析测程的执行情况和产品的质量趋势。
• 根据分析所得的测试进度和产品质量,积极调整测试策略。

测试专家Pual Carvalho 网站 测程辅助工具
http://sessiontester.openqa.org/
http://testing.gershon.info/reporter/
http://staqs.com/docs/sbtm
http://stags.com/docs/sbtm

测程表模版

et主导与st辅导方式的探索式测试，实践时注意点：

• 划分测试任务和测程的策略和原则
• 充分利用单个特性和交互特性的测试方法
• 控制每个测程的测试时间
• 汇报与总结测试情况

10、st主导与et辅导方式的探索式测试

不同的测试模型，均注重产品质量、进度控制和知识传承

第三轮测试的内容是重新执行所有的测试用例，主要是减少第二轮测试时开发人员修复带来的新问题。

第三轮测试呈现的现象：

• 第三轮测试发现的缺陷要比第一轮少很多
• 无法准确的知道第三轮测试的功能测试是否彻底完成
• 第三轮测试对可靠性和场景测试关注不够 （why？？暂时没想到）
• 整个测试执行阶段过于依赖测试用例的完成性和正确性

不同阶段采用不同策略的原因：

• 被测产品的免疫性会随着软件测试的进展而越来越强
• 遗漏的缺陷大部分出现在比较特殊的场景中
• 发现高质量的缺陷更能体现测试人员的价值
• 固定的测试用例集不能适应产品的变化，存在测试盲点

实践ST主导的探索式测试，需满足的基础条件：

• 产品比较稳定
• 探索式测试已有计划
• 第三轮发现缺陷较少
• 风格统一的测试用例
• 熟练掌握测试技术

确定不同模块的缺陷数量及风险
根据实际情况分配资源，制定探索式测试计划初稿。（如采用交叉测试方法等）
根据第三轮测试的时间来确定实施探索式测试的功能模块并制定测程
完善测试计划（测程名称、任务、测试时间、缓冲时间等）
边学习产品需求，边测试。也可以从已有的测试用例中寻找灵感
实时沟通测试结果及产品风险
总结和经验分享

ST主导测试时的注意点：

测试被阻碍，立即寻求帮助
跳脱已有的测试用例，按照自己的想法进行测试和学习
控制每个测程的测试时间

11、协作型探索式测试

协作型探索式测试包含缺陷大扫除（Bug Bash）、结对测试（Pair Testing）和全民分享（All Sharing）

缺陷大扫除

缺陷大扫除，可以组织不同的角色一起做，也可以组织所有测试人员一起做

确定一个可以集中精力的时间段
组织方提前准备（系统、数据、简单的测试确保业务系统处于“就位”状态）
开始前，组织方简单介绍相关信息（业务系统功能、测试范围、所使用的缺陷模版等）
所有人员在一个会议室聚集完成测试工作，不熟悉的地方可以询问其他人
测试领导也要参与，领导重视是团队建设的必要基础
领导不定期提示测试进度（已经发现的缺陷数、缺陷发现的冠军是谁），鼓舞团队并推动良性竞争
测试结束后，和相关人一起检查缺陷列表，处理这些缺陷
“缺陷检讨”会议，识别有代表性的缺陷，分析原因，枚举错误症状，总结并避免再犯的建议。
对活动中发现缺陷较多的人进行适当的奖励

结对测试

一个测试人员实际测试产品，另一个测试人员提出测试建议、留意产品表现、记录笔记和缺陷、查阅参考资料等。期间可以交换职责，并通过询问问题、解释策略、聆听解释来交换意见并相互启发。

结对测试好处：

互相启发，发现更多的缺陷
帮助测试人员熟悉更多的业务
结对测试避免疲劳现象
有利于工作量的平均分配

结对测试实践需满足的条件：

至少有一个测试人员能够在没有知道的情况下进行测试
另一个测试人员必须要有一起合作的心态和能力

实践者需要注意的关键因素

交换测试想法
关注个人和社会性因素
与测程相结合

测试人员完善自己的知识体系：

系统架构、开发技术、需求规格、测试技能、测试环境等。

在需求分析阶段，资深测试人员需要分享单个能特性和交互功能特性的分析方法，以及如何从静态测试的角度全面地评审需求规格说明书。测试人员还需要分享和学习如何做好一个测试计划、如何分析该项目的风险以及制定对应的测试策略等。

在测试设计阶段，资深测试人员需要分享如何架构整个项目的测试设计、如何对非功能质量特性进行测试设计、如何在特定的需求场景下关注易错的区域、如何可重用地设计和编写测试用例、如何从开发文档中获取信息来完善测试场景等

在测试执行阶段，资深测试人员需要分享如何进行测试执行和测试设计的互动、如何根据当前产品启发式地创造出更多更好的测试思路、如何精要地记录测试笔记、如何根据测试质量来调整测试策略和改善测试设计、如何严谨地提交缺陷和提出改进建议等。

TB网技术质量部的SAO文化：Share Accept Owner 分享/接纳/责任感（子排牛柳的“骚是一种境界”，天彤“解读SAO文化中的share”）

12、探索式测试回顾

Cem Kaner
软件测试是一种技术调查 （Technical Investigation），起目的是向关系人（Stakeholders）提供有关产品（软件、系统、服务）质量的实证信息（Empirical Information）。
软件测试是一种服务，服务的客户是产品和项目的关系人（客户、用户、程序员、项目经理、技术支持人员、市场开发人员、管理人员等）。
软件测试的服务内容是提供产品质量相关的实证信息。
软件测试的主要活动是技术调查，即以职业的态度、专业的技能对产品的未知领域进行探索。

Rikard Edgren：测试策略、分析、设计和执行是不可分割的有机体。
研究多个信息源 learn from multiple sources （黑盒测试等）
产生恰当的测试元素 generate relevant test elements （类比拼图，有大概的思路/动手要比一直想要强）
综合有价值的测试想法 synthesize testworthy test ideas （多调查/多样性测试/团队间互相分享）
拥抱新发现的测试执行 execute with serendipity