背景

随着中通科技业务的拓展，测试团队规模扩大，各种测试工具、平台也逐渐增多，资源分散、共享能力低；工具复用性差；没有统一的入口和标准；无法对工具使用统计等。基于以上背景，ZTO 测试工具平台（以下简称测试工具平台）应运而生。测试工具平台作为测试工具的集成平台，旨在资源整合、解决测试痛点、提高工具共享能力，持续赋能业务测试。

实现思路

首先来看一下整体实现架构如下图：

1.实现原理：

与中通开发技术栈保持一致，前端采用 ZUI（Vue 的封装），后端采用 Titans(SpringBoot 的封装)，依托于公司前后端两大框架，前端样式也保持与公司的管理系统风格一致，组件复用、以及后端相关 Titans 封装的模块的应用（比如数据库模块、消息模块、缓存模块等等）。

2.代码结构：

整体代码：主要包含 3 大模块，test-tool-admin 依赖其他两个模块，主要包括 Controller、Service、AOP 等；test-tool-common 主要包含工具类、枚举类、异常类等；test-tool-dal 主要包含 dto、mapper 等。如下图

服务接入及操作次数统计：

（1）在测试工具平台的 Controller 层，利用 AOP（面向切面编程）拦截相关方法，调用记录信息存入数据库。

（2）Service 层调用封装好的 Java 服务，Python 服务,如果想要统计功能调用次数，统一都要走 Controller 层。

（3）配置中心做相关默认参数维护以及配置管理。

Controller 层相关实现细节：

1．需要统计的功能点的方法名都已 Feature 结尾，方便 AOP 切面定位，拦截到相关方法并落库；

1. 对于一些动态参数化的配置的信息，比如第三方服务 url,默认入参等等，采用 Apollo 配置统一管理。

1. 其他服务封装在 OtherService，代码封装后统一返回，为前端提供调用。

实践成果

在日常测试工作中，测试痛点有差别，也有共性，基于这些共性，测试工具平台至少需要满足造数据 、集成整合其它平台这两个功能。

1.造数据：

在中通测试团队业务相对独立，但上下游数据依赖较强，造单、轨迹需求不一，造数据困难且耗时严重影响测试效率。数据准备无疑是最迫切需要解决的。

贯穿数据环节的有下单助手、运单助手、财经助手。比如财经的测试，需要一个运单，这个运单需要拥有收件扫描、发件扫描、到件扫描、派件扫描、签收扫描相关物流轨迹，还需要指定不同的扫描网点用于结算。要满足这样的运单，有两个方案：

a.通过下单、轨迹的相关系统，完成数据的准备，前提是测试同学了解业务逻辑及相关权限；

b.通过订单运单的接口，和维护自动化脚本来准备数据；

以上两种方式学习成本大、易用性低。造单工具需要解决的是用户脱离业务也能方便造出数据。下面是测试工具平台实际操作场景：

1) 下单，测试工具平台通过内置默认参数将订单、预约单、增值单进行分类，用户操作页面时调用后端提供的下单接口完成操作。

代码实现， 后端 Controller 层会将前端自定义参数，与后端默认的配置参数结合，配置参数从 Apollo 中读取，方便用户动态更新默认参数，再转换成下单的入参对象之后，调用 Service 层的下单服务。

下单服务，封装了下单的 Dubbo 服务，通过注解和启动变量，拿到环境的服务信息并调用。

2) 运单轨迹，测试工具平台支持常用的轨迹，如收件、发件、到件、派件、签收，用户可按需添加。

基于公司统一的前端框架，比如省市区，人员，网点组件，输入中文，即可带出相关 code 以及 id，无需记录省市区 code，人员 code，网点 id 等相关接口字段，通过运单号链接，可直接跟踪并验证造单结果，用户体验显著提升。

代码实现， 后端 Controller 层将前端自定义参数，与后端默认的配置参数结合，转换成下单的入参对象，调用 Service 层封装的不同轨迹服务。

最后，测试工具平台产生的运单轨迹流转到快件跟踪系统。

3）MQ 消息发送：测试工具平台支持 MQ 消息发送， 对依赖 MQ 消息进行上下游数据同步及传递的业务，通过模板快速配置 MQ 相关信息；通过函数助手实现参数化，如 UUID、当前时间、获取运单号等等。配置好模板后，用户可按需进行发送并且可跟踪到 MQ 消息状态。

代码实现，利用 Titans 框架的 MQ 模块，直接注入 ZmsTemplate 消息对象，发送到 MQ。

2．集成整合其它平台

1）因为业务的需要，测试同学经常会写一些定制化的工具服务，如消息中心签名计算的 Java 类，和一些特定功能的 Python 接口等。为了整合这些不同的小工具，测试工具平台提供便捷的方式用来集成 Python 服务、Java 服务、工具类等。并将它们统一放到工具箱的通用工具中，方便随时调用。

代码实现，对于这些定制化的服务，测试工具平台先将 Python 和 Java 服务的 http 接口进行封装，再统一向前端提供接口服务。

2）常用的一些 XML、Json、时间转换等三方开源工具，测试工具平台通过直接内嵌的方式完成对接，方便统一使用，如下图：

代码实现，前端使用 iframe 组件，利用修改路径方式集成到测试工具平台，如下图。

3．数据统计：

基于上文提到的测试工具平台要满足的两个基本点，作为测试工具平台本身来讲，除了关注为团队提供的帮助外，更多会关注工具使用的数据统计，及时对工具做优化，从而更好的服务团队。因此，测试工具平台提供最近一周、一个月、半年、一年的工具使用情况；功能、用户、部门点击排行统计数据等展示。并通过对数据进行分析，更精准定位用户群体，便于后续功能的针对性开发和改进。如下图

代码实现，对于数据统计的部分，在上文 “服务接入及操作次数统计” 已提到，主要利用 AOP（面向切面编程）拦截相关方法，调用记录信息存入数据库。

目前，测试工具平台有效的解决了最重要的数据依赖的问题，下单助手数据依赖调用量达到 3k+, 运单助手数据调用量约 8k， MQ 消息及工具箱等其它平台使用量约 1w+。并且，测试工具平台的用户角色不再局限于测试同学，更多的为研发、产品等部门服务。在集成测试、单元测试、验收测试等环节大大提高工作效率。

总结

提质增效一直是质量人永恒不变的主题。在日常测试工作中，难免会遇到很多测试痛点，每个小团队会基于自己遇到的痛点想解决方案，优化流程,开发小工具等。这些解决方案之间可能会存在重复造轮子的问题，测试工具平台作为测试工具的集成平台，可以很好的整合资源、提高工具共享能力，持续赋能业务测试从而达到提质增效。

未来，随着公司前端低代码组件的推广，测试工具平台将与低代码组件结合，在需求变更后，用户快速拖拽页面控件完成自定义工具页面编辑、灵活配置 Json 完成数据准备，一站式完成自动化代码的实时更新，快速高效地完成测试工作。