第34讲：一个应用SBTM的真实案例

上一讲讲解了什么是 SBTM，以及如何根据测试计划分解测试任务和测试会话。今天这一讲我将介绍一个应用 SBTM 进行任务分解并汇报结果的案例。为了方便你的理解，案例中的被测系统还是采用移动端的在线教育 App。先介绍一下案例背景。

案例背景

一个采用 Scrum 模式的敏捷团队有 3 名测试人员，负责手机端的在线教育 App 测试，之前分解了 3 个版本，第 1 批功能特性已经交付，相应的软件版本已经上线了。

总体测试策略是探索式测试加自动化测试。现在需要针对第 2 批交付的软件版本进行测试。这次交付定义了为期 4 周的一个 Sprint，需要实现订单管理、拼团购买、收益详情、收益提现、课程留言、课程评分和课程分类等 7 个用户故事。如图 1 所示，这是在第 22 讲中给出的以 App 客户角色开发的用户故事地图。

团队采用自动化测试对用户故事进行验收测试。但是，对于新的用户故事还是先用探索式测试快速发现缺陷，随后开发自动化测试脚本。

回归测试的自动化测试集（test suite）包括功能测试、性能测试、兼容性测试和安全扫描等。

在实际的项目中，移动端需要覆盖 Android 手机和平板、Apple 手机和平板，以及微信小程序的测试。本案例以 Android 手机 App 为例介绍测试任务 （Mission）和会话（Session）的分解。

挑战在哪里

目前团队内的测试人员人数比较少，需要手工测试的部分比较多，如何提高测试效率，在有限的时间内提高测试效率是一个很大的挑战，主要影响因素有以下几点。

相比 1.0，这个新的软件版本 UI 界面设计改动比较大，回归自动化测试脚本集维护工作量不小，而且手工测试需要覆盖 UI 界面的易用性和用户体验需求。

兼容性测试：需要支持的手机品牌、型号、分辨率，以及 Android 操作系统的版本比较多，兼容性测试的自动化测试覆盖了智能遍历的兼容性需求，在探索式测试中，还需要覆盖和具体功能相结合的深度兼容性需求。需要支持 4 种主流机型（Huawei、OPPO、VIVO、小米），主要的操作系统型号（Android 10、Android 9、Android 8），以及各种网络环境（Wifi、3G、4G、5G），测试组合比较多，任务比较重。

安全性测试也需要计划一些手工的回归测试对安装包、信息加密、手机权限限制等方面进行测试。

一些功能性的专项测试没有实现测试自动化，包括边界测试、弱网络测试、交叉事件测试，需要计划相关的回归测试。

Mission 分解的结果

本次迭代中采用 SBTM 一共分解出 4 项测试子目标，并按照优先级和执行的先后顺序进行了排序，如图 2 所示。

• 新功能测试子目标：验证当前版本新的用户故事是否符合验收标准，并包含深度兼容性的验证。
• 功能交互性测试子目标：重点是验证新的功能特性之间，以及新的功能特性和其他功能特性交互时工作正常，测试过程中需要兼顾深度兼容性的验证。
• 易用性测试子目标： 验证新的 UI 界面的易用性和用户体验，以及快速验证界面实现与设计是否一致。这部分需要依靠测试人员的主观判断，因此计划进行探索式测试。在测试过程中主要侧重不同分辨率手机上的界面美观性与操作性，兼顾兼容性测试。
• 专项回归测试子目标，包括交叉事件测试、弱网络测试、边界测试和安全测试。

几个典型的 Session

每个测试子目标都包含若干个 Session，分解结果如图 2 所示，由于篇幅有限，每项子任务中只给出部分 Session 做为示例。

下面是分解说明。

1）新功能测试子目标，每个用户故事定义了按照不同用户场景划分的几个 Session。这部分测试会话需要在本次迭代中对用户故事进行持续测试，如图 3 所示，是为课程留言这个会话定义的章程。

2）功能交互测试子目标，列出了 5 个分解出来的会话覆盖功能交互的场景，并且从不同的角色角度进行了场景组合。比如 Session 212：一个新用户购买、学习课程，并对课程评分，会覆盖用户注册、登录、课程搜索、支付、课程学习、评分等多个场景；再比如 Session 213，在用户故事测试中，只覆盖了作为用户对课程进行留言的相关场景。在系统功能测试中，增加了课程编辑和讲师的角色，和用户一起完成从添加留言、将留言选为精品留言、页面显示等整个留言管理过程，并且有的操作是在 PC 上完成的，测试章程如图 4 所示。

3）易用性专项测试子目标，针对 UI 界面的易用性给出两个 Session 示例，分别对"选课界面"和"我的界面"进行测试。针对拉勾教育 App ，你可以想想是否需要增加新的 Session？比如不同的用户角色。

4）专项回归测试子目标，前面已经说过需要对 3 项专项测试进行手工的回归测试。图 5 是交叉事件测试中的 Session 411 的会话章程，在这个会话里，需要考虑多个 App 同时运行，交替切换，共用视频、音频设备等场景。

Session Sheet

Session Sheet（会话表）是在一个会话结束后测试人员需要记录的测试任务报告，只需要遵循简单的格式，比如"#"标记各项内容，就可以产生易于自动分析的Session Sheet，通过特定工具进行汇总，生成总的测试报告。图 6 是 Session 113 测试结束后的 Session Sheet，要填写的内容还是比较简单的。

下面是对各项内容的简单说明。

• #Area：测试的范围，做了哪些功能点或平台的测试。
• #Duration：测试总的时间。
• #Test、#Bug、#Setup：实际测试/缺陷分析与报告/环境设置各自花的时间，可以用来估算测试速度、评估测试效率。比如能够了解到平均花在测试执行的时间有多少、是否需要提醒某个测试人员分析缺陷的时间太长了。
• #Charter/Opportunity：规定的测试任务/新发现的测试区域。比如 80/20 是指 80% 的时间花在规定的测试任务上面，20% 的时间用来测试新发现的区域。一方面尽量完成章程规定的任务，另一方面，如果发现更具有风险的区域，可以跳出事先定义的任务进行测试，目的是发现更多的缺陷，降低质量风险。
• #Notes：测试人员的感想，怎么测的，为什么这样测，哪些地方质量不够好？哪些地方需要加强测试？
• #Bugs：确认是缺陷的记录。
• #Issues：问题或疑问，但不能确定是不是缺陷的记录。

Debriefing

只有文字报告还不够，测试人员最好及时向测试负责人当面汇报（Debriefing）测试情况。有人觉得既然有文字报告了，为什么还需要口头汇报呢？这其实可以类比一下简历和面试的关系，我们都知道再好的简历也不能取代面试的作用。认真的面试官事先会仔细阅读简历，发现并准备几个问题，以便在面试中对候选人进行更深入的了解。不仅如此，Debriefing 也是一次共同反思的过程，测试负责人通过提问发现测试计划的问题、测试执行的问题，思考下一步如何改进。测试人员也利用交流的机会提出自己的担心、建议。

好的任务汇报，可以用"PROOF"来描述。

• Past（过去）：这个 Session 已经做了哪些测试？
• Results（结果）：在这个 Session 中达到了哪些具体的测试目标？
• Obstacles（障碍）：测试没有做好或做得不够充分的问题或障碍是什么？
• Outlook（展望）：还需要做哪些测试、加强哪些测试？
• Feeling（感觉）：整体测试或这部分质量感觉如何？

下面就用 Session113（用户对已购课程进行留言的操作）为例模拟一次 Deriefing 的对话。测试人员 David 带着已经写好的 Session Sheet 和测试负责人 Tom 就上午的测试会话进行了交流。

Tom：Charter 里面定义的测试任务完成的怎么样？

David：对于已购课程的留言功能各种场景都做了测试，而且我在两部手机上都分别测试了这些场景。

Tom：覆盖了哪些具体测试目标？

David：功能性和兼容性的测试目标都覆盖了，除了 Session Sheet 里记录的那个缺陷和疑问，没发现其他问题。

Tom：你记录的那个问题为什么不能确认是不是缺陷？

David：没找到相应的测试依据。用户故事里的验收标准没有明确是不是可以添加图片，我建议找业务人员和开发一起确认，补充进去。

Tom：好的。小程序的课程管理功能也在开发中，由 Gavin 团队负责测试，留言同步属于功能交互的测试目标，你有什么建议？

David：我建议我们这边增加一个会话任务专门测试一下 App 和微信小程序的功能交互，不仅是留言。

Tom：好的，我们找 Gavin 商量一下，然后更新我们的测试计划和 Session 计划。

通过这次对话，Tom 和 David 发现了移动 App 和微信公众号功能交互方面需要增加测试，测试计划和 Session 计划都要做相应的修改。

今天这一讲到这里就结束了，主要讲解了采用 SBTM 在一次迭代中如何定义测试任务和会话的案例。另外，还补充了 Session Sheet 和 Debriefing 的概念和应用。相信你对 SBTM 已经有了一个全面的了解。

有个学员跟我说："朱老师，我以前一直觉得探索式测试很高大上，现在我才知道，原来我们一直都在做探索式测试！由于我们的测试用例粒度比较粗，没有具体的测试步骤，一个用例需要执行 1~2 小时。"是呀，也许你一直在探索中，只是你没有意识到而已。

同时，他又告诉我，他们团队一直沿用测试用例通过率做为衡量软件质量的一个指标，但是项目前期基本上没有测试用例能标成 Pass。领导想了解进度，就看缺陷报告，并且找每个测试人员具体了解测试情况，然后编写测试报告。

我很期待，等他学完这一讲，是不是他会说："原来我们也一直在做 SBTM 呀，只是没有这么正规。"接下来这位同学需要思考的是怎么把 SBTM 的理论和实践相结合，把探索式测试做得更好。这也是今天留给你的思考题。