Exploratory Testing(探索测试)

概念

Cem Kaner

一种自由测试风格，强调tester同时开展测试学习、测试设计、测试执行、测试结果评估等活动，以持续优化测试工作

特征：自由式，策略，场景，反馈

原则：

• 尽早发现软件中质量风险
• 来源用户行为模型和软件出错模式的抽象
• 基于用户场景，通过模拟用户环境用户操作，接近模拟复杂用户的启发式测试模式
• 是对传统测试的一个重要的补充

漫游模式：

为了降低ET的重叠区域/提高覆盖率，以旅游者视角进行功能划分

参考我买的那本《探索式测试》

历史区：

• 对于软件缺陷来说，历史常常会重演
• 非常有效的一种方法
• 针对老代码，一些已知的修复问题
• 方法
  • 恶邻测试法
    • 指那些缺陷横行的代码段，测试人员应该在这些区域尽量多花些时间
  • 博物馆测试法
    • 重视老的那些老的遗留代码，另外包含累计许久没有执行过的用例，确保他们同新代码部分同等待遇
  • 上一版本测试法
    • 检查新版本无法运行的测试用例，以确保产品没有遗漏必须的功能，也就是说当前产品是对以前产品的更新，必须运行前一版本的场景和用例

商业区

• 软件销售特性的，产品的重要功能和特性
• 方法：
  • 指南针测试法
    • 主要测试人员通过阅读用户手册、场景、产品需求进行的相关测试
  • 卖点测试法
    • 对于吸引用户的特征进行测试，可以向销售咨询
  • 地标测试法
    • 主要是寻找测试点，明确测试项，这里的测试点就是“地标”
  • 极限测试法
    • 向软件提出难以回答的问题，比如，如何使软件发挥最大效能？那些数据或输入会耗费软件的最大效能？
    • 边界之旅-- 文本框支持的最大字符或空字符？嵌套文件夹路径最大？邮寄存储空间沾满？系统负荷大的时候？，系统负载最大时启动
  • 快递测试法
    • 要求测试人员专注于数据，即数据从输入到输出展现给客户或界面过程中，数据执行的流程
  • 场景插入法
    • 从一个场景到另外一个场景，如看视频时来个电话并接听，接听完了继续看视频，听微信语音的时候来电话并接听
  • 遍历测试法
    • 选定一个目标，然后使用可以发现的最短路径来访问目标包含的所有对象。测试中不要求追求细节，只是检查那些明显的东西

娱乐区测试法：

• 是指针对辅助特性进行的测试
• 方法：
  • 配角测试法
    • 专注某些特定的特性，索然不是用户使用的主要特性，但是临近主要特性，容易被人注意和发现
  • 深巷测试法
    • 测试那些不太容易使用的功能，试着把最流行和最不流行的特性放在一起测试，因为开发人员没有想过他们在一起会出现什么后果。
  • 通宵测试法
    • 软件长时间与刑后，各个模块是否正常，有点像稳定性测试。

破旧区测试法

• 破旧的区域是指那些问题高发区域，破旧区测试就是继续“落井下石”，如输入恶意数据、搞破坏操作、修改配置文件等，你能想到的“有害”的事情都往这个区域想就对了。
• 方法：
  • 破坏测试法
    • 那些缺陷横行的代码段/功能，测试人与应该多花时间进行测试
  • 反叛测试法
    • 要求输入最不可能的输入和数据，或已知的恶意数据。去肯德基店非要跟对门麦当劳一样的巨无霸汉堡
    • 文件下载时候，下载一半就把临时文件删除
    • 故意删除数据库
  • 强迫症测试法
    • 强迫软件一遍又一遍的输入同一数据，反复同样的操作。此种会打破开发正常的流程，他设想一遍就是结束了，没想到你这是。。。

旅馆区测试法

• 针对平台或维护特性，软件休息时还运行的特性
• 方法：
  • 深夜测试法 当我们部队测试对象操作时，程序是否完成类似数据归档/自动记录发生的异常等等，程序自动处理的功能是否正确
  • 取消测试法 -- 启动操作，然后停止他，查看测试对象的处理机制，例如功能的取消，回退，关闭以及强制关闭
  • 懒汉测试法  -- 默认值运行

旅游区

噱头的功能

测试法：

• 收藏家测试法
  • tester通过手机软件的输出，将那些可以到达的"地方"都到达一遍，并把观察到的输出实际结果记录下来，收集的越多越好
• 长路径测试法
  • 访问离应用的某个开始点尽可能远的特性，哪个特性需要点击N次才能用到
• 超模测试法
  • 要求tester关系哪些表面的东西，只测试界面。注意观察界面的元素。界面变化。是否一致。颜色等。
• 测一送一测试法
  • 测试同一个应用多个复制的情况。测试程序同时处理多个功能要求时候，是否正常，多个功能是否同时处理，是否相互影响
  • 反复分享同一个图片操作10次以上
  • 反复下载删除，最后检查内存情况。

总体测试方法：

思路1： 进行全局场景探索

思路2：进行特性漫游探索

思路3：进行局部功能点探索

设计探索地图（mindmap）

管理

为了有效的管理，测试领导需要评估测试团队的生存力、当前测试的进度、测试覆盖的范围、已经暴露的风险、测试人员是否需要帮助等因素。一个好的测试流程可以帮助测试领导和测试团队了解这些因素，并实施积极的管理。为了使探索式测试满足软件开发团队对可管理性的要求，Jonathan Bach和James Bach提出了基于测程的测试管理（Session-Based Test Management，简称SBTM）[Bach2000]。

如幻灯片的标题和右侧的图画所示，SBTM的重要特征是将测试过程分解为一组测程，从而提高整个测试项目的可说明性（Accountability）。为此，一个测程包含四个要点：主题（Charter）、时间盒（Time Box）、可评审的结果（Reviewable Results）和简报（Debriefing）[Bach2004]。

主题（Charter）是一个测程需要完成的任务。该任务应该是清晰且具体的，可以在90分钟的时间内完成，并提供有价值的简报。主题通常用一段简练的文字描述，其内容可以是测试一个功能、检查一个风险、测试一组用户情景（User Scenario）等。以下是两个实例[Michael2007]：

• Create a test coverage outline and risk list for DecideRight. （为产品测试大纲（mindmap）和风险列表）
• Explore a decision created with QuickBuild – the wizard that guides the user through the options, criteria, and weights needed to calculate the best decision. （探索QuickBuild如何产生一个决策——用户向导应该引导用户使用选项、标准和权重来计算最佳决策）

时间盒（Time Box）是一段不受打扰的测试时间，其长度一般在60~120分钟，以90分钟较为常见。在此期间，测试人员不回答问题、不回复邮件、不应答即时消息，只专注地实施测试。从工程师的角度，时间盒使测试人员能排除干扰，全力应对测试的智力挑战。从测试团队的角度，固定且专属的时间盒使得测试规划和进度追踪变得更容易。

可评审的结果（Reviewable Results）是测程的产出，常见的形式是测程表（Session Sheet），其内容可以包括：

• 主题（Charter）
• 测试人员
• 测试所覆盖的区域
• 测试设计和测试发现
• 测试所发现的缺陷（Bugs）
• 测试所发现的问题（Issues）
• 测试所使用的数据文件
• 测试活动的时间统计：在产品安装、测试设计与执行、缺陷调查与报告、非测试活动中各花费了多少时间。