导读：今天让我们聊聊到底探索式测试应该怎么来执行呢？
01
基于测程的测试管理
对于探索式测试的具体执行层面，我们会采用一种称之为Session-Based Testing management（简称SBTM）的方法来进行测试。关于SBTM术语的中文翻译，史亮、高翔两位老师在他们的著作《探索式测试实践之路》中把它翻译成“基于测程的测试管理”。至于为什么不把它翻译成“基于会话的测试管理”的原因在书上也特别做了注释，有兴趣的朋友可以去查阅。
SBTM把整个测试工作分成了多个Session来完成，每个Session包含了下面几个要点：
- Charter（章程）：一个Session所要完成的使命和目标；
- Time Box：一段固定的不被打扰的时间段，一般为45-90分钟；
- Reviewable Results：汇总的关于Session的结果测试报告，常见的是Session Sheet，比如下面的一个SessionSheet的例子是来自国外期刊《软件测试与质量工程》杂志：
- Debriefing：测试人员与产品负责人和开发团队的汇报交流，就本次测试的发现进行检查，并且看看优化改进的地方。
下图是关于SBTM的一个简单的测试流程，供各位读者参考：
02
实例介绍探索式测试SBTM如何开展
接下来我们以一个酒店入住登记的场景作为例子来看看SBTM是怎么进行的，场景如下：
某酒店针对其酒店APP系统的旅客入住自助登记模块进行优化更新，针对不同级别的会员，在办理入住登记的时候会有相应的福利。例如：针对金卡会员预定了普通房，当豪华房型有空房的时候，可以自动升级到豪华房型；而要是金卡权益过期的会员，则不会有升级的福利。
我们来看看如何开展SBTM进行探索式测试。
1. 计划步骤
在计划的过程中，我们需要确定测试的目标，分解测试的Session，准备安排相关的测试资源等。
那么什么时候开始创建Session呢？可以在Sprint计划时、也可以在开发过程中或用户故事准备好测试时。具体的时间没有明确的规定，但是我们建议尽可能早地进行一些初始计划。
可以尽早创建和准备进行探索性测试的Session，然后在测试开始之前对现有测试Session进行重新review——是否需要额外增加的Session？指定的Session仍然和测试目标相关吗?
一个Session包括:
- 说明本次Session范围/目标的Charter。
- Session的固定时间段，这应该在45分钟到90分钟之间。
- 一个简短的标题来描述Session和它的Charter。当在讨论中提到一个Session时，这是很方便的。
您可以马上将新的Session分配给测试人员，但是建议在故事进入测试阶段时再分配测试人员，这样可以保证团队成员分配的灵活性。
关于Charter
一个好的Session Charter并不用那么精确，它本质上是一个单一的测试场景，但它也不应该太宽泛和模糊，以至于Session没办法在我们指定的时间盒内完成。
当你刚接触SBTM时，你可能很难知道要计划什么Session，试试这个简单的技巧——识别对用户故事和被测应用中重要且相关的风险，并分别为这些风险创建Session：
- 某个变更或特性对性能特别敏感吗？如果是，则创建一个关于性能测试的Session。
- 可用性是产品成功的关键吗？如果是，则创建一个关于可用性的Session。
- 是否对现有的高价值功能进行了更改？如果是，需要创建一个或多个专注于回归测试的Session。
需要考虑的基本风险列表包括：性能、可靠性、可用性、安全性、可伸缩性、可安装性(软件安装过程)和兼容性等。请记住，这个列表只是Session Charter思考的一部分。
所以针对上面的场景，我们定义一个Session Charter的例子如下：
“通过APP入住自助登记功能探索住客在自动办理入住过程中的用户体验和接收到相关的房间升级福利，自助办理入住过程的体验需要和前台办理入住的体验一样好。”
2. 执行步骤
开始一个Session
计划和跟踪你在执行Session过程中的测试工作非常重要，因此一个Session可以分为三个状态：开始、处理中和结束。这三个状态是不是让您联想到了看板的泳道？是的，我们建议使用Jira和看板进行Session状态的监控，使得session状态透明可见。
我们可以在Jira中把Session当成是一个issue type，把Charter和Time Box等设置成属性字段，并可以设置“开始”、“处理中”和“结束”三个流程状态。
我们规定在Session是“开始”状态时编辑Charter，但是不能记录任何Notes或缺陷。只有在“处理中”的状态时才可以。“开始”状态是确保我们去思考测试想法的过程。
如果发现了缺陷，我们需要在Jira中报告缺陷。登记缺陷一般有两个入口：一个在Session流程中登记；一个是在Jira的主菜单登记。从Session中报告缺陷比在Jira中创建一个常规缺陷有很多优势:
- 在Session中报告缺陷时可以为用户自动关联相关的问题类型
- 记录关于在一个Session中发现的缺陷数量的度量
- 记录报告的缺陷的可跟踪性信息，显示它的父问题和找到它的Session。
- 如果配置了问题链接，那么被测试的Session可以显示所发现的缺陷列表
- 在Session活动中添加一个Notes可以自动链接到所报告的缺陷
Taking Notes（记笔记）
很多测试可能会在几个小时内进行，所以在Session期间做笔记是很重要的。特别是在Session结束时，您需要编写简短的Session结果摘要，并向产品所有者或团队简要说明。
有了笔记，写一份准确的总结就容易多了，也意味着你不会忘记重要的事项。在必须提交证据的监管环境中，Session记录和附件也可以作为证据。
如果在Session中有各种不同的笔记类型需要记录，我们可以为每个笔记打上不同的Lable标签:
- 想法（Idea）——用于在执行之前记录您的测试想法，并记录您所进行的测试的类型
- 问题（Question）——有些东西不是很清楚，你可能会留在Debriefing期间询问，它可能是一个缺陷，也可能是一个新功能。
- 惊讶（Surprise）——在测试过程中让您感到惊讶的事情，需要在稍后的测试过程中进行进一步的调查，因为一个缺陷可能隐藏在惊讶背后。
- 问题（issue）和关注（Concern）——一些不需要提出缺陷但需要在Debriefing期间讨论或在Session期间进一步调查的事情
- 积极（Positives）——测试不一定是消极的，为什么不记录和分享团队的优点。
在这个场景中，比如我们增加一条Notes，并且打上”Idea“标签：
- 关注酒店住客自助办理的事务时间
- 关注页面的加载时间
- 关注手机屏幕点击后APP响应时间
小技巧：
如果你发现自己花了很多时间在charter上，想要回到正轨，那么记录当前这个转移，并创建一个新的Charter。Session期间的观察和发现常常为今后的Session提供很好的Charter。
停止一个Session
当您完成测试后，剩下要做的就是选择“结束”状态以结束该Session。完成此操作后，设置jira将提示用户编写Session的简短摘要、对已测试的工作质量和会话覆盖率进行评级，并可选地记录他们的时间是如何使用的。参照如下图所示：
Summary只是Session结果的一个高级视图，应该进行一个完整的汇报以最大化探索式测试的价值。
3. Debriefing步骤
在测试过程中会捕获大量的信息，这些信息需要在一个紧凑且简洁的节奏中传递给团队才能发挥作用，这就是汇报的作用所在。汇报不只是与团队共享信息，还使Session和测试工作对团队负责，并提供一个机会来评审和改进Session的执行方式。
Debrief由包括负责总结会议进展情况、发现关键信息以及其它人对质量看法的测试人员、以及产品负责人、Scrum Master(如果你使用Scrum)和其他团队成员组成。
汇报期间讨论的主要领域如下:
- 检查在Session期间发现的缺陷——这些需要进行分类
- 在Session内的覆盖范围——是否由于时间限制而遗漏了任何领域?
- 在Session中发现的任何风险或问题——讨论这些问题常常会产生新的缺陷/缺陷报告
- 关于应用程序、系统或软件测试的积极信息——测试不只是报告消极的
请注意，所有这些信息都是在Session中通过记录Notes而捕获的，这些Notes使执行汇报变得更容易。
Debriefing输出
在Session Debriefing结束时，通常会决定一系列的行动。这可能需要开发人员在Story或缺陷上做更多的工作，特别是在发现缺陷或之前未知的风险被识别的情况下。如果产品所有者或团队发现仍然存在风险或者Session覆盖率很低，那么Session Debriefing的一个结果可能是创建另一个Session。
Session改进
让测试人员参与Debriefing通常是一个好主意，她或他可以从会议中回顾执行的测试想法，并为备选的测试想法和技术提供建议，以供将来考虑。您可以将此视为对测试Session进行回顾。
