自动化接口用例从 1 到 1000 过程中的实践和思考

引言

当一个新人刚加入公司的时候，我们通常告诉新人怎么去写一个自动化用例：从工程配置到如何添加接口、如何使用断言，最后到如何将一个用例运行起来。
而在实际工作和业务场景中，我们常常面临着需要编写和组织一堆用例的情况：我们需要编写一个业务下的一系列的自动化接口用例，再把用例放到持续集成中不断运行。面临的问题比单纯让一个用例运行起来复杂的多。
本人加入有赞不到一年，从写下第 1 个 case 开始，持续编写和运行了 1000 多个 case ，在这过程中有了一些思考。在本文中，和大家探论下如何编写大量自动化接口用例以及保持结果稳定。

一、执行效率

目前使用的测试框架是基于 spring ，被测接口是 dubbo 的服务。 dubbo 的架构如图（源自官网）

服务使用方的初始化需要经历以下这几个步骤： 
1. 监听注册中心 
2. 连接服务提供端 
3. 创建消费端服务代理
本地调试用例时，发现速度非常慢，运行一个用例需要 30s，而实际执行用例逻辑的时间大概在 1s 左右，主要时耗在服务消费者的初始化阶段。
测试工程中，各服务的 test 类继承了同一个基类，基类里面做了各服务的初始化的步骤。在对接的服务数目较少时，需要初始化的对象较少，对用例运行的影响并不大，但随着业务的增多，服务数目也增多，导致跑 A 服务接口的用例时把大量未用到的 B 服务、C 服务也一起初始化了，导致整体时耗大大增加。
解决办法：在运行用例时只初始化需要的服务使用方，减少不必要的初始化开销。

二、用例编写和维护

一个用例示例

以一个简单的业务场景为例：商家可以在后台创建会员卡给店铺的会员领取，商家可以对会员卡进行更新操作，这里需要有一个自动化用例去覆盖这个场景。

用例编写的基本步骤为：

• step 1 :准备数据构造新建会员卡和更新会员卡的对象
• step 2 :执行创建会员卡
• step 3 :执行更新会员卡
• step 4 :检查更新结果
• step 5 :清理创建的会员卡

转换成代码为:

@Test
    public void testUpdate() {
        try {
            /*
             * 创建新建和更新的卡对象
             */
            CardCreateDescriptionDTO descCreate = new CardCreateDescriptionDTO();
            descCreate.setName(xxxx);
            //此处省略若干参数设置过程....
            CardUpdateDescriptionDTO descUpdate = new CardUpdateDescriptionDT