接口自动化测试分层设计与实践总结
本文以笔者当前使用的自动化测试项目为例，浅谈分层设计的思路，不涉及到具体的代码细节和某个框架的实现原理，重点关注在分层前后的使用对比，可能会以一些伪代码为例来说明举例。接口测试三要素：
·参数构造
· 发起请求，获取响应
· 校验结果
一、原始状态
当我们的用例没有进行分层设计的时候，只能算是一个“苗条式”的脚本。以一个后台创建商品活动的场景为例，大概流程是这样的(默认已经是登录状态下)：
创建商品-创建分类-创建优惠券-创建活动
要进行接口测试的话，按照接口测试的三要素来进行，具体的效果如下：
1、参数构造
createCommodityParams = {
"input": {
"title": "活动商品",
"subtitle": "",
"brand": "",
"categoryLevel1Code": "12",
"categoryLevel2Code": "1312",
"categoryLevel3Code": "131211",
"detail": [
{
"uri": "ecommerce/1118d9.jpg",
"type": 0
}
],
"installInfo": {
"installType": 1,
"installFee": null
},
"pictureList": [
{
"uri": "ecommerce/222.jpg",
"main": true
}
],
"postageInfo": {
"postageType": 2,
"postageFee": 1,
"postageId": null
},
"sellerDefinedCode": "",
"publish": 1,
"skuList": [
{
"skuCode": "",
"externalSkuCode": "",
"price": 1,
"retailPrice": 6,
"stock": 100,
"weight": 0,
"suggestPrice": 0,
"skuAttrValueList": [
{
"attrCode": "COLOR",
"attrName": "颜色",
"attrValue": "绿色",
"attrValueId": "1001"
}
]
}
],
"jumpSwitch":false,
"recommendCommodityCodeList": [],
"recommendFittingCodeList": [],
"mallCode": "8h4xxx"
}
}
createCategoryParams = {......}
createCouponParams = {......}
createPublicityParams = {......}
publishCommodityParams = {......}
publishPublicityParams = {......}
createCommodityParams["input"]["title"] = "autoTest" + str(time.time())
createCommodityParams["input"]["mallCode"] = self.mallCode
createCommodityParams["input"]["skuList"]["price"] = random.randint(1,10)
createCategoryParams["input"]["categoryName"] = "autoTestCategory" + str(time.time())
createCouponParams。。。
createPublicityParams。。。
publishCommodityParams。。。
publishPublicityParams。。。
# 2、发起请求，获取响应
# 创建商品并获取商品code
createCommodityRes = api.getUrl("testApi.create.commodity").post.params(createCommodityParams)
commodityCode = createCommodityRes["commodityCode"]
# 创建分类并获取分类code
createCategoryRes = api.getUrl("testApi.create.category").post.params(createCategoryParams)
categoryCode = createCategoryRes["categoryCode"]
# 创建优惠券并获取优惠券code
createCouponRes = api.getUrl("testApi.create.coupon").post.params(createCouponParams)
couponCode = createCouponRes["couponCode"]
# 创建活动并关联商品,绑定优惠券,设置分类
createPublicityParams["input"]["commodityCode"] = commodityCode
createPublicityParams["input"]["categoryCode"] = categoryCode
createPublicityParams["input"]["couponCode"] = couponCode
createPublicityRes = api.getUrl("testApi.create.publicity").post.params(createPublicityParams)
# 结果校验(断言)
assert.equal(createPublicityRes["code"], 0)
assert.equal(createPublicityRes["publicityName"], createPublicityParams["publicityName"])
。。。按照上面的写法，对于单个脚本的调式来说或许可以，但是一旦用例的数量和复杂程度积累起来后，其维护成本将是巨大的，或者可以说不具备可维护性。
弊端说明：
·可读性差，所有的处理都放在一起，代码量大，不简洁直观
· 灵活性差，参数写死在脚本，适用用例范围小
· 复用性差，如果其他用例需要同样或类似的步骤，需要重新写一份
· 维护性差，如果接口有任何改动，那么所有涉及到此接口的脚本都需要一一修改
例如：随着用例场景的增加，就可能会出现下面这种情况。
按照原始的模式，我们就需要些3个脚本文件分别来描述着3个场景，并且创建商品_API、创建分类_API、创建优惠券_API在场景1，2，3中均出现了；上架商品_API在场景2，3中均出现。由此我们完全可以预见到，当几百上千的用例场景出现后，这种形式是没有维护性可言的。
二、进化历程
因此我们依照着痛点，以最开始的原始状态为例，对用例进行分层改造，来看看进化后的状态。
1、API 定义层
我们编程的时候会将一些重复的代码进行封装使用，那么这里依然可以借用这种思想，我们将 API 的定义单独抽离，单独定义。
我们期望的效果是这样的：
提前将API的定义放在一层，供用例场景引用，这样当接口有任何修改时，我们只需要修改API definition层即可。
实例演示
对应着上面的demo，我们就是需要做如下抽离：
class APIDefinition:'''创建商品API定义 createCommodityParams： 创建商品接口入参 return：创建商品接口响应结果 ''' def createCommodityRequest(createCommodityParams): return api.getUrl("testApi.create.commodity").post.params(createCommodityParams) '''
创建分类API定义
createCategoryParams： 创建分类接口入参
return：创建分类接口响应结果
'''
def createCategoryRequest(createCategoryParams)
return api.getUrl("testApi.create.category").post.params(createCategoryParams)
# 创建优惠券接口定义
def createCouponRequest(createCouponParams)
return api.getUrl("testApi.create.coupon").post.params(createCouponParams)
# 创建活动接口定义
def createPublicityRequest(createPublicityParams)
return api.getUrl("testApi.create.publicity").post.params(createPublicityParams)
# ...其余省略2、Service 层
上面我们已经将接口的定义抽离出来，解决了 API 重复定义的问题，但是再继续分析会发现有一个问题依然没有解决，就是场景的复用性.
再看刚才的图：
3个场景中都有重复的步骤，类似创建商品、创建分类、创建优惠券这些,并且这些步骤都是一个个API的组合，一个步骤对应一个API，在各个步骤之间还会有数据的处理与传递，为了解决这些问题，将对场景再次做抽离，这里我称之为 service层。
这一层之所以叫做?service(服务)层，是因为它的作用是用来提供测试用例所需要的各种“服务”，好比参数构建、接口请求、数据处理、测试步骤。
用下图先来看分层的目标：
我们希望将常用的测试场景步骤封装至service层中，供用例场景调用，增加复用性，也可以理解为测试用例的前置处理；
但是这里还是有一点小问题，就是service层的东西太多太杂，有些场景步骤可能只适用于我当前的项目用例，在实际的工作中，各个系统间是相互依赖的，前台APP的测试很大可能就依赖后台创建作为前置条件
好比我在APP端只要商品和分类，可能只想创建商品和分类，并不想创建优惠券，这个时候service层就没有适用的场景步骤供调用，那么我就需要根据自己的需要重新封装；可是对于很多单接口的前置数据处理又是一致的，比如：
["input"]["title"] = "autoTest" + str(time.time())
createCommodityParams["input"]["mallCode"] = self.mallCode
createCommodityParams["input"]["skuList"]["price"] = random.randint(1,10)
createCategoryParams["input"]["categoryName"] = "autoTestCategory" + str(time.time())
createCouponParams。。。
createPublicityParams。。。
publishCommodityParams。。。
publishPublicityParams。。。重新封装的话还要再处理这一步，就有点麻烦且不符合我们的复用性设计了，因此我们对service层再细化为3层，分别为：
apiObject：
单接口的预处理层，这一层主要作用是单接口入参的构造，接口的请求与响应值返回
每个接口请求不依赖与业务步骤，都是单接口的请求；
此外一些简单固定的入参构建也直接放在这里处理，比如随机的商品名，title等，和具体业务流程无关，针对所有调用此接口的场景均适用。
caseService：
多接口的预处理层，这一层主要是??测试步骤（teststep）??或场景的有序集合。
用例所需要的步骤，通过每一个请求进行组合，每一个步骤都对应着一个API请求，这些步骤会组成一个个场景，各个场景之间可以互相调用组成新的场景，以适应不同的测试用例需求。
场景封装好以后可以供不同的测试用例调用，除了当前项目的用例，其他业务线需要的话也可从此??caseService??中选择调用，提高复用性的同时也避免了用例相互依赖的问题。
util：
这一层主要放置针对当前业务的接口需要处理的数据。
在实际编写测试步骤时，可能部分接口的参数是通过其他接口获取后经过处理才可以使用，或是修改数据格式，或是修改字段名称，亦或是某些 value 的加解密处理等。
细化分层后，各层的职责便更加清晰明确，具体如下图：
页:
[1]
