第33讲：如何采用SBTM：从Miion到Seion？

SBTM（Session-Based Test Management，基于会话的测试管理）是在探索式测试的基础上提出来的，虽然已经有 20 年的历史了，但目前国内测试人员真正了解它的并不多。这也是值得大家思考的一个问题：软件测试不缺好的技术和方法，但为什么没有把它们应用到工作中去呢？是你所在的团队对测试的要求低，还是你自己就认为测试不需要技术和方法呢？

这一讲我主要介绍 SBTM 的由来，以及如何采用 SBTM 进行测试计划到具体的测试任务分解。

SBTM 由来

在敏捷测试中提倡以探索式测试为主要方式的手工测试，探索式测试事先不写测试用例，充分发挥测试人员做为个体的技能和思维能力。但这并不意味着探索式测试活动不需要计划、组织和管理，相反，我们会基于风险的测试策略完成整个软件产品的测试，测试任务也需要分解并按照优先级和工作量分配到个人，测试结果需要汇总，并根据测试结果安排和调整下一步的测试任务。

SBTM 是 Jonathan Bach 和 James Bach 兄弟俩在 2000 年提出来的。Jonathan 在"Session-Based Test Management"这篇文章里谈到，在采用探索式测试的过程中，他做为测试负责人需要每天和团队中的测试人员沟通了解测试情况，然后向关心测试进度的人进行汇报。但是他发现通过口头交流得到的反馈内容因人而异：有人喜欢讨论细节，有人喜欢谈论 bug，还有人惜字如金。这对他了解测试进度并进一步安排测试任务带来了困难。

所以，他和他的哥哥 James Bach 就希望设计出一套方法，既能更好地组织和管理探索式测试，又不影响测试人员在测试活动中的自由度和灵活性。另外，他们还注意到，测试人员在一天之内不仅要做测试，还包括许多其他的任务，为了让测试人员在测试中更专注于"探索"，不受其他事情的干扰，Session（会话）的概念------只用来做测试的最小工作单元，随之产生。SBTM 就是用来有效管理这一工作单元的系列方法。

真正理解 Session

SBTM 需要结合探索式测试的特点来理解。探索式测试可以看做"不断地问系统或质疑系统"的过程，因此，一个 Session 可以理解为"测试人员和被测试系统的一次对话 "，而不只是一个"时间盒"。在 SBTM 方法中，一次完整的会话过程是这样的：

测试人员在一个不受打扰的时间段内 （Time Box），针对一项清晰、具体的测试任务进行探索式测试 ，这个时间段通常是 90 分钟左右。测试结束后测试人员提交形式简单的文字报告 (Session Sheet)，并且尽快向测试责任人进行口头汇报 （Debriefing）。会话要执行的具体测试任务需要书面描述，在 SBTM 中被称为章程（Charter），这里的测试责任人可以是敏捷团队的Test Owner、传统测试团队的负责人，也可以是指定的资深测试人员。

另外，你还需要把 SBTM 和测试计划结合起来理解它的整体框架，如图 1 所示。从图中可以看出，SBTM 是在一次迭代中测试计划之后进行的，并且"监控和测试完成"这些环节没有变化。该怎么做测试计划就怎么做，测试过程依旧需要监控，衡量测试能否结束的定性/定量标准也是一样的，最终要实现测试计划所定义的测试目标。

首先，把测试计划中的测试目标分解为一系列清晰的、具体的测试子目标（Mission），每个子目标代表一个负有使命的测试任务。为了完成一个特定的测试子目标，需要通过一个或几个具体会话来完成。每个会话中要执行的具体任务需要一个指导书来描述，那就是测试章程。测试计划、子目标、会话和测试章程的关系可以描述成如图 2 所示。

Plan 分解成多个子目标------Mission

在第 31 讲，我已经讲解了测试计划。敏捷测试中为每一次迭代制定一个简单的测试计划。SBTM 根据测试计划把测试目标分解成若干个子目标，这里的子目标可以看成是对测试会话进行一个分类。那么探索式测试可以承担哪些测试子目标呢？

简单回顾一下第 4 讲的敏捷测试流程，在一次迭代中主要的测试活动包括持续测试和版本验收测试。前半段持续测试，主要目的是发现缺陷，包括单元测试、集成测试、新的用户故事的测试等功能性的测试，也包括性能测试、安全性测试、兼容性测试等非功能性测试。后半段是版本验收测试，既包括用户故事的验收，也包括系统端到端的验证。至于测试方式，总体原则是新功能用探索式测试，回归测试采用自动化。至于验收测试，如果团队采用 ATDD、BDD，并且有人手编写自动化测试脚本，可以用测试自动化进行验收测试。否则，探索式测试也可以用来对用户故事进行验收并且进行系统端到端的验证。

探索式测试侧重功能测试，既包括单个用户故事的验证，也包括端到端的功能交互的验证，同时在测试中兼顾兼容性、安全性、易用性等。也可以根据产品特点和项目风险计划一些专项测试，比如从易用性和用户体验的角度对 UI 界面进行探索式测试；或者专门针对各种外接设备进行的兼容性测试。有时，还需要计划一些功能性的专项测试，比如系统临界状态下的边界测试，以及和操作系统本身、第三方应用的交叉事件测试。这类测试对有些产品比较重要，比如移动端 App，但是又难以实现测试自动化。

这样说起来，从测试计划到测试子目标并没有一个严格的划分标准，而是根据项目所处的上下文分解成合适的子目标。不过这本来就符合基于上下文驱动的测试思维：没有最佳实践，只有优秀实践。

因此，这里提供一些分解测试子目标的思路供你参考，具体还需要根据项目的上下文具体分析。

• 新功能特性的测试子目标：验证新的用户故事符合验收标准。
• 功能交互性的测试子目标：验证新的功能特性之间，以及和其他功能特性的交互是否正常。
• 各类专项测试子目标，包括非功能性的，验证被测系统的易用性、安全性、兼容性等；还包括功能性的，验证被测系统在临界状态、复杂网络环境等条件下的系统功能是否正常。

Mission 进一步分解为 Session

测试子目标需要进一步分解为 Session，就是在 90 分钟左右可以完成具体的测试任务，实际上，对于时间也没有严格的要求，比如 1~2 小时都可以。每个会话管理一个特定的测试目标或任务，一系列会话相互支持，有机地组合在一起，周密地完成整个产品的各项测试子目标。

对于新功能特性的测试子目标，一个 Session 可以针对一个用户故事的几个应用场景开展测试。有的用户故事比较小，几个小时就可以完成；有的用户故事比较大，可能需要 几天，对应的场景也会比较多，需要根据用户故事的场景复杂度分解成 若干个 Session 共同完成对用户故事的场景覆盖，如图 4所示。

从时间安排上来说，一个测试会话是 90 分钟左右，那么可以为测试人员一天计划 3~4 个测试会话，在每个测试会话结束后，测试人员填写 Session Sheet，并及时向测试负责人进行口头汇报，也可以上午集中进行一次，下午集中进行一次，但最好当天完成测试任务的口头汇报。这里体现SBTM增加了面对面沟通，又一次显示探索式测试和敏捷的价值观是一致的。

对于每个 Session，需要事先定义清楚具体的测试任务、目标以及需要准备的数据、环境等，在章程里进行描述，侧重描述测什么（哪些测试点）、如何测试和测试目标，但和测试用例比，层次是不一样的，章程站在更高层次上指导一次 90 分钟左右的测试，而一个测试用例执行时间往往是 5~10 分钟。因此章程的粒度更大，不需要具体描述测试步骤，只要列出需要执行的测试场景或要点等。如图 5 所示是一个测试章程的格式，可以用清单（checklist）格式，也可以用思维导图方式。

在探索式测试中，每个会话相对独立，这时采用角色扮演来模拟客户的业务处理或操作思路，这样会比较好。例如，对于拉勾教育 App 的测试，你可以扮演：新用户、已经购买过课程的用户、课程编辑、专栏讲师、或者参加课程分享的用户等。每个会话一般由单人独立完成，或者根据需要两个人一起结对测试。比如，有经验的测试人员带着新手一起完成一个会话；再比如，两个人需要配合进行测试，比如视频会议 App 的会议场景，需要至少两人入会。关于角色扮演、场景挖掘，将会在下一部分详细介绍。

在采用 SBTM 进行管理的过程中，经常会发现原来的 Session 分解需要调整，有的 Session 太大，一次做不完，需要后续拆解成 2 个。或者有的 Session 已经对某个功能及其交互功能都做了测试，有的 Session 可以减掉。这也是对于测试计划进行动态调整的过程。

关于采用 SBTM 来管理探索式测试就介绍到这里。我重点讲解了 SBTM 的由来，以及如何用它进行探索式测试活动前的计划：从测试计划到测试子目标、会话的分解。分解过程需要根据项目的上下文来制定并在执行过程中进行动态调整。

最后，给你留一个思考题：这里讨论的背景是敏捷测试，如果是在传统的软件开发模式下，SBTM可以应用吗？如果可以，会有什么不同？