自动拦截 50% crash，字节自研 Fastbot 如何助力今日头条稳定性测试

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

• Touch target size：控件交互大小；

• Accessibility label-trait overlap；

• Accessibility label：检查所有可访问元素必须具有 Accessibility 标签；

• Supports Dynamic Type：文本的 adjustsFontForContentSizeCategory 属性为 YES，进行自动缩放；

• Contrast ratio (Label)：对比度；

• Accessibility traits：无障碍特性，用来告知辅助应用一个无障碍元素怎样行为或者应该怎样被对待。

OBJECTIVE-C

UIAccessibilityTraits UIAccessibilityTraitNone;//该无障碍元素无特性

UIAccessibilityTraits UIAccessibilityTraitButton;//该无障碍元素应该被当作一个按钮

UIAccessibilityTraits UIAccessibilityTraitLink;//该无障碍元素应该被当作一个链接

UIAccessibilityTraits UIAccessibilityTraitSearchField;//该无障碍元素应该被当作一个搜索框

UIAccessibilityTraits UIAccessibilityTraitImage;//该无障碍元素当前已被选定

UIAccessibilityTraits UIAccessibilityTraitSelected; //该无障碍元素当前已被选定

UIAccessibilityTraits UIAccessibilityTraitPlaysSound; //该无障碍元素被激活时播放自己的声音

UIAccessibilityTraits UIAccessibilityTraitKeyboardKey; //该无障碍元素的行为像键盘键

UIAccessibilityTraits UIAccessibilityTraitStaticText; //该无障碍元素应该被当作不能改变的静态文本

UIAccessibilityTraits UIAccessibilityTraitSummaryElement; //当应用启动时，该无障碍元素提供摘要信息

UIAccessibilityTraits UIAccessibilityTraitNotEnabled; //该无障碍元素不可用且不能响应用户交互

UIAccessibilityTraits UIAccessibilityTraitUpdatesFrequently; //该无障碍元素频繁更新其标签或值。

UIAccessibilityTraits UIAccessibilityTraitStartsMediaSession; //当该无障碍元素被激活时，启动一个媒体对话

UIAccessibilityTraits UIAccessibilityTraitAdjustable; //该无障碍元素的值在一定范围内允许持续调整

UIAccessibilityTraits UIAccessibilityTraitAllowsDirectInteraction; //该无障碍元素允许VoiceOver用户直接触摸交互

UIAccessibilityTraits UIAccessibilityTraitCausesPageTurn;//该无障碍元素应该引起自动翻页，当VoiceOver阅读完成当页的文本时

UIAccessibilityTraits UIAccessibilityTraitHeader;//该无障碍元素是一个将内容划分为章节的标题，例如导航栏的标题

在每次用户 touchBegin 屏幕的时候进行检测，GTXLib 会对所有 Window 进行遍历，将所有不符合无障碍规则的 case 封装到 GTXResult 结构中，并上报到服务器。

目前头条已经建立了 Fastbot 无障碍测试任务，旨在帮助 QA 和 RD 快速发现当前 App 内未满足无障碍要求的 case 并进行修改，其检测效果如图所示：

三、任务异常恢复

在分析 Daily 任务中我们发现有 2 类常见问题会影响到 Fastbot 的遍历能力：被测 App 长时间卡住和键盘场景不退出。为解决这两类异常问题，我们设计了卡屏检测和键盘聚合限频方案。

3.1 Fastbot 卡屏检测

在 Fastbot 测试过程中，经常遇到被测 App 进入某些场景出不来的情况。一个 10 小时的 Fastbot 任务可能后面 7-8 个小时都处于下面这种卡屏状态，这对 ByTest 测试机时是一种很大的浪费。如下图，进入视频页后卡住。

之前解决这种卡屏的问题，一般是找到对应的场景，再去分析卡住的原因，针对性地进行处理，但是这样的处理周期会比较长，不能及时止损。这里我们在 Fastbot 内部实现了卡屏检测逻辑，如果识别到页面卡住超过一段时间，则会触发 Fastbot 的卡屏检测逻辑。

卡屏检测是基于 sid 来做的，Fastbot 会对每一次的页面树做一次类似 md5 的计算，生成一个场景的唯一标志， 这就是 sid。在一次操作结束之后比对历史的 sid 值，从而判断是否卡屏，最简单的方式是，比如连续十次的 sid 都是一样的，则认为页面卡住了，但是有时可能是两个页面反复横跳，sid 在变了，这种其实也是卡住的。针对这个问题我们的解决方案是，统计最近 30 次的 sid，如果其中占比最高的 sid 超过 87.5%（经验值），则认为此时需要触发卡屏处理流程。

Fastbot 内部的卡屏处理流程依次是：强制返回、处理系统弹窗、处理被测 App 内部弹窗、强制重启被测 App。

该逻辑上线后，整体减少 10% 的测试机时浪费，同时为了后续能去分析卡屏的具体原因，当触发强制重启 App 时，会同步记录相应日志，到任务结束时，会触发一个任务分析程序，结合日志列出具体的卡屏页面供 RD 分析排查。

3.2 键盘场景优化

在实际测试中，通过分析测试任务，发现当 Fastbot 进入到键盘后，会在较长的一段时间内停留在键盘输入，同时一次任务中又会存在多次调起键盘操作，这会导致测试中键盘时长占比过高，影响了 Fastbot 的遍历效率，减弱问题前置发现的能力。

针对该类问题，分析键盘场景下的 UI 视图树结构，优化键盘控件，从 UI 视图树可以分析出键盘中每个键都是一个独立的控件，而算法侧的策略是尽可能地遍历每一个控件，这会极大地增加键盘点击的次数。因此在 Fastbot 获取页面元素树时对键盘上的控件进行聚类，在获取到页面结构数据时，根据节点信息中的 “KBKey” 或者 “UIKeyboardEmoji” 等标识，对这些控件的 resource_id 等属性做聚类处理，将键盘上所有控件聚合成一个控件进行操作，降低点击键盘的几率。

此外在头条 Feed 评论场景，点击全屏后，键盘及输入框占满整个屏幕，如下图所示。该场景中，虽然将键盘聚合为一个控件，但是点出键盘的操作路径较深，难以完全解决。针对此类 case，我们从客户端视角进一步的优化键盘场景，对键盘出现的次数和使用时长都进行限制，在一次生命周期内最多运行出现 5 次键盘，并且每次键盘使用时长不超过 3 分钟，如果超时未销毁键盘时，直接销毁键盘，同时根据右上角坐标获取 keyWindow 的第一响应者，如果第一响应者存在 Tap 手势, 则触发 Tap 的响应逻辑，模拟实际用户操作来跳出该场景。

该项优化上线后，一次 10 小时的单机测试任务，键盘出现的时长占比从 20% 优化至 5% 以内，有效解决了测试任务中键盘对整体测试任务的影响，提高了非键盘场景的测试时长。

Fastbot 结果消费

---

前面我们主要阐述了在提升 Fastbot 测试能力方向探索和实践的一些方案，对于拦截到的问题，我们同样做了一些探索，用于快速消费稳定性问题，并给准出标准和判断依据，整体来辅助 RD 进行准出决策，优化准出效率。

前期围绕 Fastbot，我们建立了很多指标，如召回率、覆盖率、 线下 crash 异常率、机时完成率等等，每个指标都有各自的适用范围， 但是这些指标过于分散，也没有主次，不能直观反映某个版本的质量水平，为版本准出提供依据。比如线下 crash 率低，说明版本质量好，但是如果是因为 Fastbot 本身出了问题，没有测出 crash 呢，所以还要综合考虑 Fastbot 的 VC 覆盖率才能得出结论。因此我们做了一套线下准出流程来解决指标判断困难的问题。

现在线下准出流程由三部分组成：

• 第一部分是质量评估，也是最核心的部分，用于反映 App 的质量；

• 第二部分是异常消费，就是发现并解决问题；

• 第三部分是准出卡口，用于发版时确认产品质量。

整体流程如下：

该流程整体上线后，共辅助了 GIP 侧 10 个版本的准出上线，整体优化 2 人日。

落地效果

---

以头条的稳定性测试结果和业务收益为目标，从测试策略、研发流程等层面进行建设相关的线下测试流程。目前我们每天自动构建主干分支包并用于测试，异常问题召回率从最初的 19.1% 提升到了现在的 45.76%（双月 Fastbot 发现的已修复问题数/双月已修复问题总数），当前可达 VC 覆盖率（Fastbot 测试覆盖 VC 数/线上用户触达 VC 数）为 80% 左右。

因 Fastbot 精准定向测试在 GIP 侧仅测试 Feature 类 MR 中有 VC 变更的需求，其在 2021.12.15 至 2021.12.22 一周内的执行率为 53.03%（执行测试 MR 数量/变更 MR 数量），受测试时长和 VC 是否关联 scheme 的影响，定向测试的平均关联 VC 覆盖率（测试中覆盖 VC 数量/ MR 关联 VC 数量）为 42.95%，其中已覆盖的关联 VC 停留时长占比 46.69%，双月修复率 15.38%（双月定向测试发现的已修复问题/双月定向发现的总问题）。从当前修复率可以看出，精准定向已经可以在 MR 阶段提前拦截一部分稳定性问题，但还有着较大的提升空间。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！