接口自动化测试分层设计与实践总结

发表于:2022-7-29 09:12

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:CeshirenTester    来源:51CTO博客

  本文以笔者当前使用的自动化测试项目为例,浅谈分层设计的思路,不涉及到具体的代码细节和某个框架的实现原理,重点关注在分层前后的使用对比,可能会以一些伪代码为例来说明举例。
  接口测试三要素:
  ·参数构造
  · 发起请求,获取响应
  · 校验结果
  一、原始状态
  当我们的用例没有进行分层设计的时候,只能算是一个“苗条式”的脚本。以一个后台创建商品活动的场景为例,大概流程是这样的(默认已经是登录状态下):
  创建商品-创建分类-创建优惠券-创建活动
  要进行接口测试的话,按照接口测试的三要素来进行,具体的效果如下:
  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"][0]["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"][0]["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 的加解密处理等。
  细化分层后,各层的职责便更加清晰明确,具体如下图:
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
  干货 | 接口自动化测试分层设计与实践总结
  https://blog.51cto.com/u_15649298/5479383
价值398元的测试课程免费赠送,填问卷领取吧!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计

法律顾问:上海漕溪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2022
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号