前言
分层测试思想
1、表现层：业务主要入口和页面样式兼容性可以与业务逻辑分离，只做页面版本检查
2、中坚层：主要API测试、缓存服务、日志服务等
3、基石层：通过自动化单元测试，可以作为测试阶段的第一道关卡
分层测试思想，实现代码、服务、界面分层自动化的整体架构目标，满足金字塔式一体化分层管理，分层代码使各层测试目标清晰，资源统一管理，可以集成新测试工具和测试框架，提升管理效率。统一自动化测试入口，便于测试，开发自测统一管理。基于现状，从单元测试和接口测试层面都需要自动化，给到测试更多的质量反馈数据。接着，渐进式的改进测试流程的状态。最终实现平台化，统一测试平台入口。
交易属于中台服务，给业务方提供交易、支付方面能力，后端部分接口测试较多，所以我们主要测试部分是针对中坚层的测试。接下来介绍一下接口测试用例规范与优化部分。
用例规范
测试用例主要分为四个层面
pt_case | 用例层，在该层面编写用例并执行测试用例 |
|---|---|
basic | 将接口需要的参数进行封装 |
actomic | 原子层面，调用接口,获取返回值，进行上下文校验 |
zzcommon | 工具包 Http Client 客户端请求处理 |
用例层 ：根据不同的业务场景，调用多个接口，组成一条测试用例。代码实现上则是每一个test方法即为一条测试用例。比如：创建一条订单交易成功用例，则需要走的订单流程为创建商品—创建订单—订单支付—发货—确认收货
代码语言：javascript复制@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层将这些数据进行封装，作为接口的请求参数，传入原子层
代码语言：javascript复制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();
}原子层：与后端服务交互，接收第三方接口返回的数据，将返回数据进行上下文校验。原子层功能的主要作用是调取接口、获取数据
代码语言：javascript复制public static String auditInfo(AuditInfoParam auditInfoParam) throws Exception {
HashMap<String, String> paramMap = Util.bean2Map(auditInfoParam);
return ZZ***.get****Service().auditInfo(paramMap);
}用例测试结构分三层的意义？
由于按层把系统分开，使得代码的可利用性升高，三个层各司其职，所以一旦哪一层的需求发生变化，就只需要更改相应层中的代码，而不影响到其他层中的代码。降低了层与层之间的依赖，有利于代码的标准化开发。
如何进行上下文校验？
在测试过程中为了保证高效准确校验接口，返回数据是否是所期望的数据，根据这一诉求，在接口用例实现上下文校验的功能，实现原理是构造期望数据与返回值进行对比，用断言方式校验返回数据与期望值是否一致，出现数据不一致情况则抛出错误。
用例优化
用例分类：随着业务不断扩大，用例越来越多，订单、红包、活动等测试场景越来越多，导致测试用例的分类划分不是很明确。需要定义一个维度来划分测试用例，调整用例结构。首先，根据系统进行划分，组成一个大的分类，比如红包系统、活动系统。在系统之下以订单类型，业务线的维度进行划分。在这些子分类之下，编写测试用例，更简单直观，会使思路清晰，减少用例编写重复，遗漏测试场景情况。
命名规范：随着测试用例接口不断完善，目前已被广泛运用，提出将用例平台化，针对这些情况我们需要提高代码可读性，减少使用接口用例的时间。需对包名、类名、方法名进行命名的优化。
- 工程名称、包名全部小写
- 类名首字母大写，如果类名由多个单词组成，每个单词的首字母都要大写
- 方法名、变量名首字母小写，如果名称由多个单词组成，每个单词的首字母都要大写
- 尽量不允许出现拼音，命名要有意义
测试回归：在测试一个需求，会根据此次需求进行评估，可能影响到范围，进行回归测试。接口用例测试目前这项能力支持还不算完善，在之后要总结出一套回归测试用例，在RD自测或QA测试都要执行一次回归测试用例，执行通过才可以上线。
异常校验：在接收接口返回的数据，有时会返回异常信息，比如：网络超时，库存不足等异常信息，针对这一情况，提出校验response内容的方法解决。下面是创建订单接口返回内容以及对返回信息校验。
代码语言：javascript复制{"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也可以使用测试用例，自测上线，随着不断优化，最终形成稳定成熟的测试用例。欢迎各位同学针对用例优化提出宝贵意见。
