质量体系建设之路的分分合合

Posted 2022-07-08 声网

前言

贾鹏博是声网的测试开发工程师，负责声网 SDK 的测试以及建立健全相关的测试工具。待过金融公司，看的了股票，算的了佣金，有内容分发、电商、小游戏相关测试经历。

本文基于贾鹏博在「声网开发者创业讲堂• 第三期丨创业初期如何保障产品质量」活动中分享内容二次整理。

01 质量体系建设的背景

首先，由图 1 可知，从需求创建，到评估、建立、需求的提测分发，再到最后的测试，需求的工作流是非常长的，我们需要建设和跟踪工作流，以便更好地保障业务运行。其次，数据记录用于复盘、改进和增效。因为质量体系建设涵盖了方方面面，其中也包括一些文档的落地，随着发版以及测试任务的增加，各种各样的版本以及测试数据都会有相应的积累，在这个过程中要进行数据分析，获取数据并分析复盘、改进，以促进质量体系的建设。

最后，建设质量体系是为了得到高质量的产品。从研发自测、提测阶段的推进、需求标准对齐、制定测试规范、Jira 信息可视化与追踪，以及其他方方面面的跟进。我们所做的一切服务都是为了版本的上线，给用户提供高质量、高可靠的产品和服务。

■图 1

图 2 综合展示了建立质量体系之前和现在，质量程度、线上问题、测试问题的闭环、过程的改进、用例增加以及如何协调手工 case 和自动化 case 。通过“以前”的图，很难得出相关的结论，只有建立体系进行不断的分析，才会得相应的结论或者指标来改进。由图 2 可知“以前”是如何做的，现在通过建立体系能达到哪些效果，以及实现体系需要做的举措。这些举措是方方面面的，不仅需要落地，有的可能还要不断对齐和复盘。

■图 2

02 方法论

1、小步快跑

小步快跑用来快速上线，有时需求可能会非常紧急，只是简单地了解目的，与开发或者产品经理对接后就要开始工作了，测试用例可能都来不及维护和更新。而且因为是快速增长阶段，可能还需要通过并行。

所谓的并行如图 3 所示，多个人有 N 个需求，这 N 个需求由不同的人跟踪，但是这些需求都是新增的，只需要添加并快速上线就可以了。这一时期的特点是，需求是新增的，只测试自己负责的这一部分即可，其他的需求跟自己无关，也不需要回归，直接补充上线就可以。需要注意的是，因为只注重快速上线，所以只要保证一定的质量即可，对于细节的把控是不到位的。

■图 3

2、稳中求“胜”的高质量

当公司处于平和期时注重质量，需要多方面的考量。一个需求在初步建立时可能要拆分成个 N 个子需求，这些子需求由不同的人负责测试。另外，在测试的过程中需要不断地交互，通过不同的测试点以及覆盖不同的测试内容来实现交付，整个测试过程可能是比较长的，因为需要多方面验证，包括手工测试、自动化测试、性能测试、实验室测试等，用综合测试结果判定该版本有没有回退或者质量问题等。如果整体是良好的状态，就可以发布。

这种稳中求“胜”的方法更多适用于质量要求严格的公司，比如银行，因为其对于钱财的把控严格，所以它的持续周期是非常长的，对测试过程中的质量问题非常关注，需要不同的人交叉以及通过交换测试内容和测试用例来完成相关的测试任务，是该时期的特点。

3、规范流程的文档派

此时公司仍处于平和期，在经历小步快跑以及长时间的测试需求迭代的过程中，已经积累了各种各样的经验，这些经验需要转化成流程的提升以及功能的改进，如何发现更多的问题是对于需求梳理以及数据记录能力的考验，具体如图 4 所示：

■图4

从需求开始设计测试用例，测试用例可能包括 Xmind 和 Excel，接下来开发 review 相关的 case，此时可能要站在代码的设计角度以及产品使用和 QA 的角度改善 case，修改以达到上线要求。当然，在上线过程中可能会遇到各种问题，这些问题需要覆盖住功能、性能，并且要求在不断迭代的过程中（不管是测试环境，还是预发布环境、线上环境等），功能都是正常的，没有回退问题产生。这个阶段的主要特点就是从需求开始到结束都需要追踪、归纳和总结。同时，需要对文档进行梳理并注意其中的规范，避免重复的文档等。

■图 5

图 5 记录了当前版本的 bug 数以及占比，不同团队的 bug 数能够一定程度反映其解决问题的时间，有助于归纳测试进度，以及把控住 highlight 任务，从而推动功能的如期上线。图 6 记录了问题解决时长以及解决问题解决时长方差。其实文档派记录的文档数据都是为了更好地推进测试进度，保证及时或实时上线。

■图 6

4、百花争艳的工具流

目前已经推出各种测试工具，可根据不同的业务来使用对应的测试工具以提高效能，及时地交付测试任务。图 7 所示为测试工具的八个分类，这只是简单的列举，市面上的测试工具远远不止这些。

■图 7

5、精益求精的开发流

此时公司可能已经处于成熟期了，当前的工具流已经完全不能支撑测试任务，需要针对业务借助工具流进行开发，比如 STF（Smartphone Test Farm）以及腾讯的 Bugly，都是为了贴合自身的业务而进行的二次开发。当然，现在也有很多的工具流，包括 sonic、httprunner 等，它们涉及方方面面，包括接口自动化性能、性能测试等，这些都可以贴合业务进行二次开发。这个时期的主要特点是，对代码要求比较高，需要充分理解业务，并通过代码能力满足业务的需求。

图 8 所示为我们公司对于当前工具进行的二次开发以及相关的实践，我会在后面进行简单的阐述。

■图 8

03 落地和实践

1、SDK 崩溃数据的实时高效闭环处理

我们公司主要测试的是 SDK，相对于各大市场上的 App 可能一些差别，它的落地实践主要是 SDK 崩溃数据的实时高效闭环处理。市面上有一些这样的工具的，比如 Bugly，但是我们发现 Bugly 在处理 SDK 上报崩溃的过程中还有一些不足，比如 SDK 发生崩溃了，但是 Bugly 并没有监控到。所以我们对于这方面进行了一些改进，整体的过程如图 9 所示，我们的 SDK 是为客户服务的，嵌在客户的 App 中，它的整个闭环为，程序正常执行来监控是否发生 crash，然后通过监控 crash 状态找到守护进程感知捕获，接下来生成 dmp 文件并提交到崩溃搜集器，以解析相关的系统，此时会有一些相关信息入库，最后对信息进行整合并发给用户。

■图 9

图 10 展示了对 SDK 崩溃数据的实时高效闭环处理，首先提取到堆栈关键信息，然后根据哈希值进行判断，若相同版本 Hash 值存在，则关联相关 JIRA。这部分的处理逻辑就是在取得崩溃日志后将其提供给相关的开发人员及时进行处理。

■图 10

图 11 展示了在收集日志并通过解析系统编译获取 crash 之后，在 JIRA 中展示和指派。首先获取崩溃信息，然后上报给 JIRA 并附带一些关键信息，同时通知相关的开发人员，使其进行修复。简单来说，SDK 崩溃数据的实时高效闭环处理就是在 SDK 嵌入 App 之后，判断是否是由我们的 SDK 发生的 crash，因为有一些可能是客户 App 本身的crash，我们会对这一部分进行判断，若是 SDK 的 crash 会直接上报然后通过编译系统解析并上报给 JIRA，在这个过程中会提交给相关的开发人员进行处理，完成整个链路。

■图 11

2、电路插拔

这部分主要介绍耳机插拔的试验，因为我们的 SDK 可能在测试过程中需要不断地插拔耳机。图 12 是对电路图的简化，简单来说就是在主板线路，把耳机中的线跟电路图中的线进行了焊接。

原电路图很复杂，学过集成电路的同学应该知道，其中有各种各样的节点，对这些点进行试验，结合电路图的原理，通过程序控制电路就能达到插拔耳机的作用。我们在以前测试插拔耳机的过程中耗费的人力很长，保守估计一个人 3 天全部 online 在上面才可以完成所有的 case。但是在完成这个电路图之后，只需要一个小时就能完成相关所有的 case。在电路图上我们会对相关的数据展示（包括网页数据的分析，以及性能指标的裁剪等）进行整合，相当于对于耳机插拔的产品化。

■图 12

3、HENGE测试平台

图 13 是基于 STF 二次开发的云平台，它的主要链路就是动态获取测试包得到其信息，然后动态下发给云真机进行测试，接着把相关的测试结果提交给相关的测试人员，方便他们获得测试报告以便得出测试结论。图中主要展示了我们测试的 App 下发流程后装包运行，运行完成之后查看报告，当然其中包括 crash 日志以及相关的功能。

■图 13

4、Moonlight

我们公司的产品 Moonlight 已经开源（https://github.com/AgoraIO-Community/MoonLight）了，它是一个 SDK，用于自动化性能数据的采集，感兴趣的同学可以查看相关代码。对它进行的一些性能测试显示，它能以较低的资源消耗获取到非常准确的 CPU、memory 等系统信息。

04 体系图

从为什么做质量体系，再到五个时期可能会采取的不同的策略，以及在策略过程中可能诞生的各种的小工具都是服务于我们提供的高质量的产品，这是最后的唯一指标。所有的测试任务，包括质量体系的建设都是为了维护当前的业务发展。因此不管使用哪些策略，不管是文档派、工具流，还是二次开发，所有的节点或者任务事件，都是服务于自己的业务体系。

图 14 展示了一个质量体系，包括需求阶段、开发阶段、代码融入、测试阶段、上线前、交付、质量追踪，这是从 0 到 1 的里程碑，因为你能看到需求管理开发过程中的规范代码准入原则、测试的各种测试指标项、上线前的各种对齐、交付之后的报告总结复盘，一直到最终上线之后对于整个数据的监控，完成了一个基本的质量体系图。

■图 14

06 问答环节

1、怎么做覆盖率检查？

覆盖率检查是使用了工具 bullseye，这个工具在 CI 编辑过程中会生成一个 Cov 文件，运行相关 case 的 Cov 文件中对应模块的开发的代码的覆盖率会发生改变，最后所有模块运行以后根据标准去进行对应和比对就可以。

2、在创业公司中 CI/CD 主要是放到哪一个阶段呢？

对创业可能要放到提测阶段，我们主要负责 CI 的出包，因为 SDK 编译出包之后，会直接生成相关的 zip 包并触发编译相关的 App，这些都是我们的测试工具。因为声网主要是做 SDK 测试，所以我们会把我们的 SDK 嵌入到自研开发的测试 App 中用于测试任务。当然我们公司将其分为两套，开发部门有相关的 UT，在提交代码之后会有相关的代码检查，如果 UT 不过是无法提交的，这是开发部分；测试部分主要用于 工具出包，因为我们公司 SDK 测试的特殊性，如果是市面上大多数工不需要内嵌sdk都是自己功能开发的 app，一般分成两部分。在开发的提交代码之后，有的人可能会进行 test case，在测试环境之前可能还有备份测试环境，在这个环境中会有相关的测试任务。把相关的测试 test case 跑通，达到一定的通过率，然后才会提交成功，进行下一步测试。当然，要看你是否有精力去维护两套环境，因为这个环境是在代码提测之前，而且相关的要求也会高一点。如果说开发的代码 UT 过了，然后发布到测试环境运行 test case，case 可能会分两种，一个是新增的功能，这个是过不了的，因为根本就没有新增功能。另一个是已有的旧功能，可能需要打 tag 来判断是否要进行测试用例的覆盖，如果是旧功能，可以通过设定通用率来判断是否要打回，所以需要根据不同的业务类型进行调整。

3、端到端性能测试时怎么测？有工具吗？埋点数据不准怎么办？

端到端的性能测试工具有很多，test home 中好像有人分享了安卓方面的工具，大家可以去看一下。那个工具是开源的，安装之后在运行相关的 App 时，它会将相关的数据进行展示。另一个是开源工具使 tidevice，它是通过 Python 调取的 Apple 的 API 来获取数据。如果是 ios 或 Mac 可以用 moonlight，Windows 本身也有一些性能工具能直接监控。如果想尝试二次开发，iOS 就自己调私有 api，安卓就是 adb 调用。苹果官方还有 instrument，iOS 和 Mac 都是通过 instrument 的调用获取新的数据。

对于埋点不准这个问题，其实埋点更多的是一个开发任务，因为开发是在代码中进行了相关任务的日志写入，我认为应该是开发去埋这些点，然后去它会有一系列它的一些调用链。我们的任务就是通过理解开发的需求，然后拿到这些数据来验证它的埋点是否正确。