扒一扒搞定7个亿用户的语音云自动化测试

飞测说：首先介绍美女测试主管：郑丹，高级软件测试工程师，语音云测试负责人,就职于拥有国际领先语音技术的科大...



飞测说：首先介绍美女测试主管：郑丹 ，高级软件测试工程师，语音云测试负责人,就职于拥有国际领先语音技术的科大讯飞股份有限公司；在语音服务组件测试、语音交互接口客户端测试、性能测试有着丰富的业务知识积累和测试经验；

擅长线上大数据性能数据统计分析及性能优化改进；Jenkins持续集成、自动化测试及部署的优秀实践者；现网自动化轮训测试改进牵头人；参与线上服务组件告警策略制定及组件健康度改进；



以下是正文（有点长，但都是干货）：今天分享的是讯飞语音云测试的一些内容，现在云的说法越来越多，大家应该早已经不陌生了，之前也听过一些相关的分享，其中也学习到了很好的经验，现在也想把自己的一些经验分享出来，希望可以给大家的工作带来一些帮助。

这次分享，总共分为三个部分:

第一部分大概介绍一下讯飞语音云的架构，因为必须了解被测对象，才能知道如果开展测试工作。需要什么样的测试，如何做出有效的改进。

第二部分，本次分享的重点部分，针对目前的讯飞语音云，我们是如何进行测试的，需要关注到哪些方面，做出哪些改进，如何更有效又更全面的进行测试

第三部分，针对语音云特殊性，如何进行现网的监控，优化，让测试不止局限在线下，更要关注线上，从而让测试-优化形成闭环，努力让测试做到最好。

1.      语音云的逻辑架构





图上画的比较详细，它主要可以看做是4个部分。从上到下，应用层--服务层-核心引擎层，最后一个是云计算，数据收集分析系统。我们重点看一下前三个。

第一层是语音应用层，相当于语音应用的一个客户端，开放了所有业务的接口，兼容很多平台（Android、IOS、pc、linux等），主要面对开发者提供了一套接口，其实测试也是开发者中的一个，也是一个应用者。应用层集成了很多前端功能，vad的前后端点检测，噪声消除，音频编解码等，还有很重要的，与服务端的交互协议约定，还有日志上传策略，还有现在现在比较火的麦克风阵列，消噪等，这些功能也都是测试的重点。

第二层是服务层，主要是解析客户端的协议，面对接入的多种业务，亿级交互量进行调度分发，当然还有负载均衡，数据的加密，音频的解码，用户的管理入库等。面对这块的功能，就是最重要的功能测试，并发测试，性能稳定性测试。

第三层是语音核心引擎层，这块是语音交互最核心的部分，就是业务引擎，比如识别引擎，合成引擎，人脸识别引擎等，涉及到真正的算法，这次的分享主要面对是整个语音云的测试，具体的引擎测试就不作详细介绍了，里面非常复杂，且每个引擎测试也都不一样，扩展开来就比较多了。且借鉴性不大。

2.      语音云的网络架构




为什么还要分享网络架构，因为它里面涉及到很重要的一个部分，就是性能测试，可以这么说，逻辑架构是保障能不能用，而网络适配是保障好不好用的一个重要条件，所以网络处理上非常重要，也是测试必须要兼顾到的一个部分。那么我们来看下讯飞语音云的网络架构，首先它覆盖很多平台的客户端，刚才也讲到了，通过有线网络，无线网络，还有三大运营商等，接入语音云入口，然后负载均衡等一系列策略，分发到目前北京、广州、合肥的服务机房中，上海目前已经没有部署服务器。里面涉及到的测试点，非常多且很难模拟，用户的网络场景是最难模拟的，只能是尽量覆盖。针对每个网络的不同点，性能表现如何，服务如何优化，都是很重要的部分。

3.      测试框架



发展到现在，整个语音系统已经很庞大了，先看下所提供业务种类，大概有十几种，主要的就是识别、合成、唤醒、身份识别（人脸、声纹），还有手写等，光识别就可以分为普通话、英文、粤语、四川话等等几十种识别引擎。用户量也全部是亿级，数十亿级别，每天，服务器的也是数千台，非常的庞大。13多万的合作伙伴,覆盖终端8亿,日请求数达到13亿之多,服务稳定性客户端为97%,服务端为99.99%,响应时间500ms。三地的服务器设备也已经达到数千台之多。

那么，最重要的问题就来了，面对如此复杂庞大的系统，测试需要做的有哪些，又要如何高效的保障服务质量呢？那么接下来和大家讲一下我们整个的测试情况

4.      测试框架



根据上面所分享的语音云架构来看，首先必须进行功能测试，检查语音云的逻辑实现，功能是否完备，所有的参数是否支持，异常处理是否合理，且必须覆盖所有的业务。

还有就是性能测试，每个版本成功率，响应时间数据，多并发测试，其实还要对比现网上的指标，这个后续就讲到。

稳定性，作为一个实时服务的语音交互系统，稳定性绝对是重中之重，当然里面绝对不仅仅是CPU，内存占用这么简单，他可以通过这些指标作为参考，还必须配合监控，异常拉起服务等各种措施。这个可能就不仅仅是测试的工作了。

网络测试，这个可以和性能测试结合在一起，作为互联网服务，肯定适配各种各样的网络环境，有好的，也有不好的，不过现在4G网络的普及，为服务的可用性提升了很多，可以不必像之前2G做那么的保障工作，什么重传、续传啊之类的。测试肯定是要覆盖所有的网络类型，另外我们还有做一个比较好的点，就是有专门的网络仿真仪设备，它可以模拟网络丢包，带宽，延迟等组合场景，测试各个网络下的服务兼容性与稳定性。

当然还有很多单点测试，就是可能要单拎出来测试的功能模块，比如：编解码、vad、还有效果测试等

5.      自动化测试改进：

面对上面那么多的功能，那么多的测试方向，如果只是靠人工执行，显然太落后了，那么势必会用到自动化，接下来就重点介绍下，我们自动化测试这边如何开展的。

4.1测试工具

它首先通过xml的配置文件，可以进行你的一些配置，连的地址，被测对象的路径，数据入库的地址等等，除此之外，还支持命令行，cmd等外部参数配置，设计的很灵活，基本上想传什么参数都可以实现。然后通过你的用例，当然是覆盖了所有的业务，通过调用不同的业务接口，实现基本功能测试。

通过数据驱动模块，调用被测对象，像dllso文件或者是http协议的api接口，或者是thrift协议接口等。

然后就是到公共模块，包括测试控制，用例解析等，最终形成测试日志和结果日志，包含工具本身的日志，还有被测对象的日志，都会存储到对应的路径。

最终，他形成了很全面的结果日志，并且进行分类，共有三大块，接口结果，功能结果，场景结果。

接口结果：就是一条用例里面，所有的接口返回的值，一般成功就是0，错误就是错误码。

功能结果：相当于一条用例的成功与否，一条用例里肯定是包含了很多接口的，如果这个接口所有的返回值都是0 ，那么功能结果才为0，否则算作失败。

场景结果：就是所有一次可能加载了很多条用例，当所有的用例都成功之后，场景结果才为零，否则就失败了。

最后，所有的结果都会入到数据库，方便之后分析，可以做每个版本的结果对比分析，也可以统计每个功能业务的成功率等等，总之很方面，而且很直观。

4.2自动化测试平台



自动化工具做的很详细，但是必须要依赖于测试平台，当然也可以不集成到平台上，不过这样的话很多功能就没有办法凸显，像结果，没有平台就没有展示，一次测试那么多用例，如果一条条去看，那就太麻烦了，而且也不直观。

讯飞语音云的自动化测试平台，主要构成大概是6个部分，文件-测试--调度---执行---结果--报表：

文件：肯定是web式的文件管理，包括测试用例的在线编辑啊，配置文件，依赖的测试音频，文本等的存放等

测试：选择你所要执行的用例，可以选一条，或者是多条等随意组合，而且支持被测对象属性的描述，像版本号啊，哪个业务啊，开发者是谁啊等等，但是最好每个测试人员版本号什么的大致约束一下格式，因为数据入库统计分析的时候，会依赖到这些属性

调度：这个功能支持测试的一些调度配置，如果说每天几点去测试，或者半夜才执行等等，而且还可以选择测试的机器，比如说做稳定性测试，可以同时选择配置好一点的机器，还可以选择配置差一点的机器，进行对比。让测试工作覆盖更多，而且也不会浪费时间。

执行：就可以查看整个测试的执行状态，是正在进行呢，还是测试完毕了，如果需要取消执行，也可以点击取消。

结果：就是我刚才在工具方面讲到的各个结果，接口结果，功能结果、场景结果的查看，平台会形成表格，哪条用例报什么错，错在哪个接口，都很容易的看到，非常的直观简便。

报表：最后这个报表管理，就是通过入库的一些数据，包括每个版本，每台测试机器上的功能测试数据，还有各种性能测试数据等。只要入库，都可以自动形成报表，当然这个报表可以选择配置，横坐标是哪个数据，竖坐标是哪个数据，统计几个版本，几个数据，还有图表是柱状图还是饼图或者折现等等，都可以自由配置，让测试人员还是开发人员，都可以很清楚直观的了解到目前的质量情况，而且随时可以查看。

5.3   自动化测试平台扩展功能



当然了，测试平台的功能还不仅仅是这样，前面也说到了，它是一个开放接口的web管理平台，也是说非常支持灵活集成，利用它可以打造一整套的自动化测试生态圈，首先它可以通过接口调用，集成构建集成平台，把构建出来的组件还有脚本之类放到平台上，自动化进行测试、分析、展示等，然后把测试完毕的版本通过自动化部署部署到现网的机器上，最终，通过调用现网网段的自动化平台，进行上线后验证，现网轮训测试，因为之前也提到了，语音云的机器很多，上千台，如果还是手动去配置一台台的验证，那效率就很低下了。而且还可以集成主动测试，配合现网监控和告警系统，这个后面一部分会讲到。

6.      现网优化

如果说，测试人员测试完毕一个版本，发布出去，或者是上到现网上，觉得松了一口气，终于测试完了，如果这么想，一定是不行的，其实发布出去或者上到现网上面，那真的只是开始。我相信没有任何测试人员可以说，他测试的版本一点问题都没有，因为用户真实的场景太多了，你可能都想不到，更别说测试到了。不过，没有关系，只要线上分析做的好，用户会帮助你测试。 


现网优化可以分为三大块，第一块最重要的就是线上数据收集分析，另外一个就是告警监控，最后一个，就是可以做很多主动监控。

5.1  线上数据收集

可以收集哪些数据，如何分析，又如何对测试工作产生优化呢，我也罗列了一些。比如说可用性指标，也就是我们通常所说的成功率。但是成功率如何定义这个需要好好思考一下，并不是说报错了就是服务不可用了，他可能是网络的原因，或者是说用户自己取消的，又或者是用户被别人打断，只是开启并未实际使用，这些都需要进行错误的细分，那么得到这个成功率的指标才比较让人信服。可以去分析，每个网络，地域，应用等等维度，了解线上的服务情况，加入说某个地域或者某个业务成功率低了，那么就要去深入分析，为什么低，肯定是有原因的，是哪个服务组件导致，从而帮助测试人员寻找BUG。而且，通过这个分析，可以形成一个组件健康度的规划，如果某些组件经常报错，就被列入不合格组件，需要下线整改。

除了可用性，还有响应时间，里面涉及到很多网络维度，比如说wifi，到底是移动，还是电信，还是联通，都不可以统一去规划，肯定是不一样的。更深入的话，可以做时间的拟合分析，分析到客户端耗时，网络耗时，服务组件耗时，引擎耗时，哪块时间耗时长，让开发去优化他的代码，不过随着现在4G网络的普遍，对于服务的快慢要求可以降低，一般情况下都是可以接受的。

另外还可以提取每个业务的用户量，没个业务再去细分，对于现网的负载能力，及并发路数都可以进行优化。

5.2主动监控测试

可以做每个业务的主动监控，模拟应用的主动监控，还有效果的主动监控测试，当然还可以做竞品对比分析的。

5.3告警系统

每个云服务肯定都有他的监控告警系统，那么从这个监控系统中，测试可以推动优化的有哪些呢。比如服务组件的监控告警，之前也说了可以制定一个组件健康度指标，对服务组件进行排名，差的就可以下线整改。

还有容量监控，高峰时段一些用户使用量激增，那么授权数肯定要随之调整，那势必要再可用性及服务快慢之间做出选择，如果找到一个平衡点

另外结合应用监控，通过服务分级，重要的用户优先保证，都可以做很多优化。

最后，既然有告警，那么虚警不可避免，虚警优化，减少处理成本，也是很重要的一个优化点。

那么到这里，整个要分享的部分就全部讲完了，涉及的方面挺多，希望可以为大家的工作提供一些想法和经验，谢谢~~

如果你想现场来听，就点击原文链接吧！

    关注 飞测