落地和实践
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已经开源（github.com/AgoraIO-Com…）了，它是一个SDK，用于自动化性能数据的采集，感兴趣的同学可以查看相关代码。对它进行的一些性能测试显示，它能以较低的资源消耗获取到非常准确的CPU、memory等系统信息。
体系图
从为什么做质量体系，再到五个时期可能会采取的不同的策略，以及在策略过程中可能诞生的各种的小工具都是服务于我们提供的高质量的产品，这是最后的唯一指标。所有的测试任务，包括质量体系的建设都是为了维护当前的业务发展。因此不管使用哪些策略，不管是文档派、工具流，还是二次开发，所有的节点或者任务事件，都是服务于自己的业务体系。
图14展示了一个质量体系，包括需求阶段、开发阶段、代码融入、测试阶段、上线前、交付、质量追踪，这是从0到1的里程碑，因为你能看到需求管理开发过程中的规范代码准入原则、测试的各种测试指标项、上线前的各种对齐、交付之后的报告总结复盘，一直到最终上线之后对于整个数据的监控，完成了一个基本的质量体系图。
■图14
问答环节
1、怎么做覆盖率检查？
覆盖率检查是使用了工具bullseye，这个工具在CI编辑过程中会生成一个Cov文件，运行相关case的Cov文件中对应模块的开发的代码的覆盖率会发生改变，最后所有模块运行以后根据标准去进行对应和比对就可以。
2、在创业公司中CI/CD主要是放到哪一个阶段呢？
对创业可能要放到提测阶段，我们主要负责CI的出包，因为SDK编译出包之后，会直接生成相关的zip包并触发编译相关的App，这些都是我们的测试工具。因为声网主要是做SDK测试，所以我们会把我们的SDK嵌入到自研开发的测试App中用于测试任务。当然我们公司将其分为两套，开发部门有相关的UT，在提交代码之后会有相关的代码检查，如果UT不过是无法提交的，这是开发部分；测试部分主要用于工具出包，因为我们公司SDK测试的特殊性，如果是市面上大多数工不需要内嵌sdk都是自己功能开发的app，一般分成两部分。在开发的提交代码之后，有的人可能会进行testcase，在测试环境之前可能还有备份测试环境，在这个环境中会有相关的测试任务。把相关的测试testcase跑通，达到一定的通过率，然后才会提交成功，进行下一步测试。当然，要看你是否有精力去维护两套环境，因为这个环境是在代码提测之前，而且相关的要求也会高一点。如果说开发的代码UT过了，然后发布到测试环境运行testcase，case可能会分两种，一个是新增的功能，这个是过不了的，因为根本就没有新增功能。另一个是已有的旧功能，可能需要打tag来判断是否要进行测试用例的覆盖，如果是旧功能，可以通过设定通用率来判断是否要打回，所以需要根据不同的业务类型进行调整。
3、端到端性能测试时怎么测？有工具吗？埋点数据不准怎么办？
端到端的性能测试工具有很多，testhome中好像有人分享了安卓方面的工具，大家可以去看一下。那个工具是开源的，安装之后在运行相关的App时，它会将相关的数据进行展示。另一个是开源工具使tidevice，它是通过Python调取的Apple的API来获取数据。如果是iOS或Mac可以用moonlight，Windows本身也有一些性能工具能直接监控。如果想尝试二次开发，iOS就自己调私有api，安卓就是adb调用。苹果官方还有instrument，iOS和Mac都是通过instrument的调用获取新的数据。
对于埋点不准这个问题，其实埋点更多的是一个开发任务，因为开发是在代码中进行了相关任务的日志写入，我认为应该是开发去埋这些点，然后去它会有一系列它的一些调用链。我们的任务就是通过理解开发的需求，然后拿到这些数据来验证它的埋点是否正确。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
