我的测试（七）

• 我的测试—入行

• 我的测试—持续集成实践引入

• 我的测试—第一个小产品iTest的发布

• 我的测试—转型测试开发团队

• 我的测试—安全技术团队的由来

• 我的测试—AI测试平台

• 我的测试—测试平台大建设

2016年到2018年是我们测试平台建设最关键的三年，在这三年里，我们集中开发了自动化测试平台4.0（改名AI引擎测试平台）、移动测试平台、Web自动化测试平台、AI资源管理平台、容器云DTCloud、Mock平台、接口测试平台。这些平台构成了整个集团公司测试执行的基础工具链。测试开发团队的整体作战能力在这个时期也得到了大幅的提升，我们是集团里最早开始研究、学习和使用容器技术的团队（docker1.0刚出来），也是集团里同时具备两种技术栈（java和python）且都能承担应用开发的团队之一。测试开发团队规模最高的时候一度达到16人。

一、AI测试平台与AI资源管理平台

AI测试平台的核心价值是在打通端到端AI效果集成测试的同时，提升资源利用率。前面针对它的规划和实现前面已经提过，不再赘述。

二、移动测试平台

移动测试平台MTP是我们基于XF输入法业务开发和沉淀的一个面向android和IOS的测试系统。主要实现了类似于云测的机器调度执行（使用的仍然是我们前面提到的自研的调度模块）、monkey、自研工具和测试脚本的执行管理、报表分析等功能，同时也跟集团的质效平台进行打通，支持了业务持续集成的推进。由于贴合业务进行开发，免不了带上一些业务上的强属性，比如多渠道下的功能和性能特性表现管理、渠道版本和测试结果的关联等。

MTP虽然基于业务开发，但是并不能让它具有持续的生存能力，因为我们很快发现MTP并不能很好适应我们公司业务战略的变化。随着移动互联网快速发展，早期的时候大量APP应用产品上线，对于移动方面的测试技术而言，无论是业界还是我们公司都取得了长足的发展。但是很快，越来越多的跨平台APP，软硬一体的产品开始规划和推出，打着智能化、物联网的旗号开始发展起来，测试技术和测试平台都需要在这种趋势下调整策略。移动测试平台由于封装了过多纯APP的测试场景和玩法，并不能很好的适配类似于XF录音笔、XF学习机等软硬一体的产品，很快走向了没落。在后来，公司从整体的角度出发，硬件中心承担了公司所有软硬一体产品的硬件设计、开发以及测试，在他们的努力下结合业界一些力量完成了新一代软硬一体产品的测试平台设计和开发，并且建立了对应的实验室，采购、自研了大量的测试设备、测试工具，又使得我们在移动终端方向上的测试能力更上一个台阶。

三、Web自动化测试平台

web自动化其实是业界一项非常通用的专项测试技术了，市面上也有很多商业和开源的测试平台解决方案。那么为什么我们还需要自研呢，而且web自动化这项技术虽然门槛不算高，但项目实施难度和投入也不小啊。当时业务发展战略下，我们很多业务走的是规模化这条路，很多Web产品批量销售批量交付。为了加快规模化的步伐，团队也快速发展，研发测试的人力成本大幅增加。在这个背景下，为了提升测试效率，降低规模化带来的人力成本，自动化被提出来。

第一个版本的web自动化测试平台是基于selenium2.0进行封装，支持原生对象定位方式外，也可以自定义对象定位方式，同时扩展了对一些特殊场景的支持，比如上传下载、模拟键盘输入等。web自动化测试平台具有几大核心功能，首先是执行机器的管理，可以选择云主机，也可以选择容器。支持测试用例的执行分发和结果收集。其次强大的执行管理，执行过程中对测试结果、瞬时截图进行管理，生成到测试报告中，并对历史报告进行对比分析。最后在自动化的基础上，允许统计每一步的性能数据，对前端性能进行分析。

web自动化测试平台后来在XF的几个重点产品中得到了深度应用，在20余个产品中被常态化应用于线上功能巡检，真实且比较有效地发现发布上线后运维过程中的问题，对运维监控能力进行了补充。

四、接口测试平台与Mock平台

2016年中台的概念兴起，XF的主营教育业务也开始规划和发展中台，微服务相关技术被广泛应用。为了支持彼此依赖服务开发过程中的调试和验证，一些开源的mock工具开始被使用。但是在试用过程中，我们也发现了几个方面的问题：首先几个主流开源的Mock工具（Mockjs、RAP2等）易用性并不高，不易集成，Mock数据不好管理，难以添加自定义的逻辑控制；其次免费版本或者开源Mock工具支持的协议有限，支持mock的颗粒度也比较粗；最后不能同时支持云和端两种形态下的调试。为了解决这些问题，我们决定自研mock平台。自研的mock平台具备以下几个特性：

1、核心支持了HTTP、socket、Dubbo三种协议，同时也支持扩展。

2、支持method级别的mock，颗粒度更细。

3、丰富的Mock逻辑控制，易于集成。

4、支持更多使用场景。开发人员可以共用云端平台进行mock，也可以从平台导出mock配置，在本地启动一个本地化的mock服务，同时支持在线和立项两种mock模式，灵活性更高。

Mock平台当时被应用于多个重点产品中，开发人员和测试人员都能将其运用到自己的工作场景中。我们在mock平台的开发过程中，对研发的工作流程也有了更深的了解，同时培养出了一名对底层原理掌握透彻的架构师。

与mock平台在同一背景下同时推出的还有接口测试平台，重点解决的也就是一些接口测试用例、数据和执行管理的问题。

五、dtcloud蛋疼云

dtcloud是一个基于docker技术开发的类似于rancher的自研系统，最初开发它的目的是，希望通过它来减少服务器冗余，提升资源利用率。我们做了一笔测算，发现在研测环境上投入的资源浪费非常严重，如果全部能够弹性地去利用，可以大幅减少服务器的采购数量，降低我们的资源成本。在当时公司层面虽然也通过搭建XF云来对服务器资源进行弹性管理，但因为跟业务相对割裂，从云的角度无法决定哪些服务器在什么时候应该回收利用，也没有对应的管理机制去要求，所以资源浪费的现象还是很多。我们研究docker技术最早追溯到docker1.0时期，主要是希望通过docker快速还原和构建一个不受干扰的测试环境，这是我们最初朴素的想法。在后来开发dtcloud的时候，我们是希望dtcloud这个平台，能够很好地承载我们的研发、测试环境，在dtcloud上通过界面按钮和简单的配置就能快速实现环境的搭建和版本的切换。

我们在研发dtcloud的过程中解决了很多关键性的问题，也培养的容器技术方面的专家，就是前面提到的后来去中国电科云的那位兄弟。dtcloud是测试技术团队最希望成功应用，也认为最有价值的平台，但是很可惜，当时没有得到充分的重视，也就没有在业务里面顺利得到应用。凭着测试技术团队对技术的一腔热血，我们还是在测试平台的开发过程中，通过dtcloud把我们的一些测试平台研发、测试以及部分生产环境通过dtcloud管理起来，也算是一种慰藉。值得骄傲的是，我们是XF最早学习和研究docker技术的团队，而且结合实际应用完成了一次技术探索闭环。

在2016年到2018年间，测试开发团队走向了成熟，具备了比较好的java开发能力、平台架构能力和技术攻关能力，我们也收获了一个集团十佳团队。回头去想那段历程，唯一感到遗憾的是我们当时对产品的理解太弱，产品能力没有培养起来，是我们平台研发过程中最大的不足。