SDK 测试不同于 APP 测试，不仅要站在终端用户角度考虑问题，还需要站在 APP 开发者的角度考虑问题。面对不同的行业需求，如何保证质量固若金汤，这是一条探索未知的赛道。

在 Coding DevOps 线下沙龙上，声网质量效能部门负责人潘志刚分享了如何整合基础能力，保证测试和交付的高效执行，提升质量效能。

1. 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. GUI Demo Test Automation

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

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

3. 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. 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 可以进行预警，及时发现这个问题是否真的只有一台设备存在，或者在数台机器里都存在共性。以前通过人工的方式去挖掘几台设备的数据是否有相应的问题，很难联想到是不是与某一个系统有关、与某一个芯片有关，还是跟某一个特定的网络场景有关。通过数据分析平台的合理过滤，能够帮助我们通过种种证据的汇总来有效发现问题，尽早解决问题。

5. Q&A

Q：针对于手机 APP 去做测试，如果需要上百部手机同时连起来，做一个性能测试环境。但一台电脑的支持能力是有限的，可能同时连接十几台手机就达到极限了，怎么去做横向扩展做性能环境？

A：如果是针对安卓手机的话， 我们有一台早期的节点同时连接了 30 台安卓设备证明是可行的，建议再确定一下节点和外设的配置。更多的机器连接可以通过采用集群的方式来部署 test farm。另外，可以在相应的 test app 应用中设计独立的性能测试组件，有利于实现性能测试的横向扩展。