共计 5013 个字符，预计需要花费 13 分钟才能阅读完成。
前言
贾鹏博是声网的测试开发工程师，负责声网 SDK 的测试以及建立健全相干的测试工具。待过金融公司，看的了股票，算的了佣金，有内容散发、电商、小游戏相干测试经验。
本文基于贾鹏博在「声网开发者守业讲堂• 第三期丨守业初期如何保障产品质量 」流动中分享内容二次整顿。关注公众号「 声网开发者」，回复关键词「JT0611」即可下载流动相干 PPT 材料。
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 的调用获取新的数据。
对于埋点不准这个问题，其实埋点更多的是一个开发工作，因为开发是在代码中进行了相干工作的日志写入，我认为应该是开发去埋这些点，而后去它会有一系列它的一些调用链。咱们的工作就是通过了解开发的需要，而后拿到这些数据来验证它的埋点是否正确。
流动预报
7 月 16 日下午，声网开发者守业讲堂 • 第 4 期将以「守业团队如何保障产品业务的平安合规？」为题，邀请环信、游族、白山云三家优良企业的技术专家为大家带来精彩的分享。
心动不如口头，赶快扫描二维码报名吧！