接口用例规范与优化

前言

分层测试思想

1、表现层：业务主要入口和页面样式兼容性可以与业务逻辑分离，只做页面版本检查

2、中坚层：主要API测试、缓存服务、日志服务等

3、基石层：通过自动化单元测试，可以作为测试阶段的第一道关卡

分层测试思想，实现代码、服务、界面分层自动化的整体架构目标，满足金字塔式一体化分层管理，分层代码使各层测试目标清晰，资源统一管理，可以集成新测试工具和测试框架，提升管理效率。统一自动化测试入口，便于测试，开发自测统一管理。基于现状，从单元测试和接口测试层面都需要自动化，给到测试更多的质量反馈数据。接着，渐进式的改进测试流程的状态。最终实现平台化，统一测试平台入口。

交易属于中台服务，给业务方提供交易、支付方面能力，后端部分接口测试较多，所以我们主要测试部分是针对中坚层的测试。接下来介绍一下接口测试用例规范与优化部分。

用例规范

测试用例主要分为四个层面

用例层 ：根据不同的业务场景，调用多个接口，组成一条测试用例。代码实现上则是每一个test方法即为一条测试用例。比如：创建一条订单交易成功用例，则需要走的订单流程为创建商品—创建订单—订单支付—发货—确认收货

@Test(description = "单库存商品确认收货流程测试")
public void createInfo2ConfirmReceipt() throws Exception {
    //发布普通商品
    String infoId = Info.addNormalInfo(sellerId, "10", "5");
    //下单
    String orderId = Trade.createOrder(buyerId, infoId);
    //支付
    Trade.payOrder(orderId);
    //发货
    Trade.deliverGoodWithExpress(orderId);
    //确认收货
    Trade.confirmReceipt(orderId);

}

basic层：主要作用是根据传入值构造测试数据。比如创建订单 ，需要构造买家uid，商品id等数据 ，在basic层将这些数据进行封装，作为接口的请求参数，传入原子层

public static String createOrder(String buyerId, String infoId) throws Exception
 {
    CreateOrderParam createOrderParam = new CreateOrderBuilder().
        .withBuyerId(buyerId).withMultiProduct(true).withSupportCent(true)
        .withShoppingCart(false)
.build();
    CreateOrderResult result = createOrder(createOrderParam, errInfo);
    return result == null ? null:result.getOrderId();
}

原子层：与后端服务交互，接收第三方接口返回的数据，将返回数据进行上下文校验。原子层功能的主要作用是调取接口、获取数据

public static String auditInfo(AuditInfoParam auditInfoParam) throws Exception {
    HashMap<String, String> paramMap = Util.bean2Map(auditInfoParam);
    return ZZ***.get****Service().auditInfo(paramMap);
}

用例测试结构分三层的意义？

由于按层把系统分开，使得代码的可利用性升高，三个层各司其职，所以一旦哪一层的需求发生变化，就只需要更改相应层中的代码，而不影响到其他层中的代码。降低了层与层之间的依赖，有利于代码的标准化开发。

如何进行上下文校验？

在测试过程中为了保证高效准确校验接口，返回数据是否是所期望的数据，根据这一诉求，在接口用例实现上下文校验的功能，实现原理是构造期望数据与返回值进行对比，用断言方式校验返回数据与期望值是否一致，出现数据不一致情况则抛出错误。

用例优化

用例分类：随着业务不断扩大，用例越来越多，订单、红包、活动等测试场景越来越多，导致测试用例的分类划分不是很明确。需要定义一个维度来划分测试用例，调整用例结构。首先，根据系统进行划分，组成一个大的分类，比如红包系统、活动系统。在系统之下以订单类型，业务线的维度进行划分。在这些子分类之下，编写测试用例，更简单直观，会使思路清晰，减少用例编写重复，遗漏测试场景情况。

命名规范：随着测试用例接口不断完善，目前已被广泛运用，提出将用例平台化，针对这些情况我们需要提高代码可读性，减少使用接口用例的时间。需对包名、类名、方法名进行命名的优化。

• 工程名称、包名全部小写
• 类名首字母大写，如果类名由多个单词组成，每个单词的首字母都要大写
• 方法名、变量名首字母小写，如果名称由多个单词组成，每个单词的首字母都要大写
• 尽量不允许出现拼音，命名要有意义

测试回归：在测试一个需求，会根据此次需求进行评估，可能影响到范围，进行回归测试。接口用例测试目前这项能力支持还不算完善，在之后要总结出一套回归测试用例，在RD自测或QA测试都要执行一次回归测试用例，执行通过才可以上线。

异常校验：在接收接口返回的数据，有时会返回异常信息，比如：网络超时，库存不足等异常信息，针对这一情况，提出校验response内容的方法解决。下面是创建订单接口返回内容以及对返回信息校验。

{"successData":false,"code":"10018","success":false,"message":"该商品已被下单！"}

public static void checkResponsebackGroundCreateOrder(BuyResponse<BackGroundCreateOrderResponseDTO> response) throws Exception {

    if (!response.isSuccess()) {
        JSONObject respJson = new JSONObject();
        String respCode = response.getCode();
        String errMsg = response.getMessage();
        respJson.put("respCode", respCode);
        respJson.put("errMsg", errMsg);
        throw new ResponseCodeErrorException(JSONObject.toJSONString(respJson));
    }
}

构造数据优化：在basic层构造request参数方式上，之前采用set方法，但是由于参数太多并且很多参数类型相同，导致写出的函数冗余复杂，针对这个痛点，提出采用Builder模式解决，这样代码的可用性和可读性得到大大的提高。与此同时，构造request数据数量明显减少，调用起来非常直观。

总结

随着测试用例的不断完善，我们可以使用测试用例构造测试数据，缩短功能测试时间。RD也可以使用测试用例，自测上线，随着不断优化，最终形成稳定成熟的测试用例。欢迎各位同学针对用例优化提出宝贵意见。