CODING DevOps 线下沙龙回顾二：SDK 测试最佳实践

讲师：潘志刚
声网质量效能部门负责人，超过 14 年服务器、移动终端、音视频编解码以及汽车电子等跨行业从业经历，负责创建测试基础架构和自动化测试方案，主持搭建持续集成测试生态体系。现任声网质量效能部门负责人，负责推动质量和效能持续优化，专一技术创新赋能团队软件保证，经过软件和硬件的高效结合，探索产品交付的最优解决方案。

前言

SDK 测试不一样于 APP 测试，不只要站在终端用户角度考虑问题，还须要站在 APP 开发者的角度考虑问题。面对不一样的行业需求，如何保证质量固若金汤，这是一条探索未知的赛道。本期推送将为你们带来声网研发效能负责人潘志刚的《SDK 测试最佳实践——打造质量保证的一体化应用平台》，分享一体化应用平台的演变以及如何整合基础能力，保证测试和交付的高效执行，提高质量效能。

1.0 GUI Driven Test

SDK（软件开发工具包）是声网对外主要的产品交付，是用于为特定软件包、软件框架、硬件平台以及操做系统等建立应用软件的开发应用的集合，跟传统意义上的 APP、外围应用或者最终客户感知到的产物是不同的，对于最终端用户来讲是无形的。

早期为了保障 SDK 测试的质量，测试人员须要根据 SDK 交付的 API 设置 GUI demo。好比在一个实时的互联网通信界面，须要用户加入到对应频道进行相应的音频和视频通信，在这样的界面里会设计对应 Button、下拉列表，或者小的图标，每个对应的元素体现对应接口实现能力。以下图所示，最下面 4 个 Button 分别是麦克风、摄像头、挂机按纽，对应 API 接口 enableLocalAudio、enableLocalVide、startScreenCapture 和 leaveChannel，右上角看到信号条图标是获取 onNetworkQuality 接口。经过这样简单的 Demo，测试人员设计相应的 test case，确保每个接口能够正常调用，基于此来保证初期迭代里交付的质量标准。

然而随着交付平台愈来愈多，交付须要基于桌面端、移动端、web 端，桌面端包括 Windows，macOS 和 Linux，移动端包括安卓和 ios，愈来愈多平台设计相应的 demo 势必须要测试人员投入更多资源，同时 API 在不断增加。所以自动化是必然趋势。

2.0 GUI Demo Test Automation

2.0 阶段是 GUI Demo Test Automation，开发人员将平台进行了分层。

如上图，上面的 iOS、OSX、Android 等是对外交付的平台，下面是对应平台用到的第三方开源工具，如 Appium 和 Selenium，中间这一层作相应分装，其目的在于提升测试效能，用一套 case 覆盖到全部交付的平台。实现 70% 的自动化程度已经可以让团队节约一半的时间，极大地提升了测试效率。

3.0 API Demo Test

3.0 阶段进入到 API Demo Test。声网的测试主体是 SDK，SDK 关注点在于 API 功能实现、平台适配、面向开发者、性能功耗包体积，集成构建打包；而 APP 关注业务功能、用户交互、终端用户、界面操做和程序安装。针对 SDK、APP 两种彻底不一样的测试重点，声网从新设计了一套针对 SDK 的自动化测试框架——Wayang Testframework。

Wayang 的原理来自印度尼西亚的一种木偶戏，前端是一个木偶，后台表演者经过线和灵巧的手控制前端木偶去作相应的动做。在这样的一个体系里有三个不一样的对象，左边的对象是 test client，中间是 test server，右边是对应的 test demo。Test client 至关于木偶戏幕后的表演者，须要明确本身的测试需求是什么，设计相应的 test case；test demo 至关于前端的木偶，会根据测试端发出持续请求作相应行为调用。全部的主动调用以及被动调用都是基于代码输出。在整个体系里面全部的接口调用和相应回调都是基于代码终端的输出，无需关心界面的实现。和自动化 2.0 与手工 1.0 相比，目前天天能够完成一百个以上 API 测试，自动化测试覆盖率可以超过 80%。

4.0 AIO

在完成 Wayang 实践后，声网仍在思考是否可以有进一步的优化实践。随着产品交付迭代周期愈来愈紧，以及更多的需求介入，从测试角度来讲，光考虑测试环节是不够的，须要把整个产品交付归入思考范围以内——包括前期构建、打包、测试、交付。所以，这里引入了 AIO 的理念。

AIO 是箱庭和沙盒的结合。那么，什么是箱庭和沙盒呢？箱庭可以提供基础设施，至关于游戏里提供相应的陷阱、敌人或者宝箱，如何去获取或者击败由本身决定。而沙盒意味着把最小的原子单位开放给用户，典型例子有个人世界、乐高，最小单位就是一个 cube。声网的测试单位是基于 API，那么在整个交付里面，箱庭对应着保证基础设施（e.g：网络、电源，测试环境）稳定运行，至于沙盒则会拆分构建、测试、上线发布三个版块。

在声网一体化 AIO 架构里面，包含了一系列相应的 module。

AIO 架构包括了设备集群。由于不一样平台交付必然覆盖各类各样的状况，须要考虑到不一样设备的兼容性。调度中心确保全部设备在预期设定中如期交付，所以须要服务网关的存在。数据中心会分析 SDK 产物明确的 log 输出；最后一块是构建发布，ACCS 平台包括编译、发布、崩溃上报、数据分析、自动化测试等功能模块。下面基础能力表明着更底层的元素，如链路模拟、物理链接控制、人机交互等。

回到刚才所说的 Wayang 的特性，须要有一个 client 对应一个 demo。Client 表演者知道须要作什么，而后让 demo 去作相应的事情。基于这个状况，声网作了进一步的提高。经过 API driven test，声网设立了一个独立的 soloWayang app，里面的 test iterator 生成器能够不停地把测试 API 持续调用。经过基于 test farm 并发测试，在全部设备上跑 soloWayang，全部相应的 API 都会被测试以确保发现和处理问题。

在测试环节里面，会有很是多数据产生，包括 SDK data、demo data、test data 和 server data。如何去将这些数据作合理有效的预先挖掘？

传统模式下，数据的价值在于出现问题后去分析数据。逆转一下思惟的话，若是可以对数据进行提早收集和预分析，就能够在问题暴露以前主动地去发现和解决风险。声网数据分析平台经过 Beats、Logstash 对不一样平台的数据进行清洗，将无效信息剔除。Kibana 经过相应的过滤，可以把相应问题列举出来。举个例子，某个晚上跑了四百台设备，发现某台设备出现对应的 log 异常，经过 Kibana 能够进行预警，及时发现这个问题是否真的只有一台设备存在，或者在数台机器里都存在共性。之前经过人工的方式去挖掘几台设备的数据是否有相应的问题，很难联想到是否是与某一个系统有关、与某一个芯片有关，仍是跟某一个特定的网络场景有关。经过数据分析平台的合理过滤，可以帮助咱们经过种种证据的汇总来有效发现问题，尽早解决问题。

Q：针对于手机 APP 去作测试，若是须要上百部手机同时连起来，作一个性能测试环境。但一台电脑的支持能力是有限的，可能同时链接十几台手机就达到极限了，怎么去作横向扩展作性能环境？
A：若是是针对安卓手机的话， 咱们有一台早期的节点同时链接了 30 台安卓设备证实是可行的，建议再肯定一下节点和外设的配置。更多的机器链接能够经过采用集群的方式来部署 test farm。另外，能够在相应的 test app 应用中设计独立的性能测试组件，有利于实现性能测试的横向扩展。

点击获取视频和 PPT 资料