实操接口自动化测试项目之项分层设计

最新推荐文章于 2024-04-10 20:00:00 发布
最新推荐文章于 2024-04-10 20:00:00 发布
阅读量287 收藏 1
点赞数 1
分类专栏： 软件测试 文章标签： linux 数据库 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiao1542/article/details/131480433
版权

本文以笔者当前使用的自动化测试项目为例，浅谈分层设计的思路，不涉及到具体的代码细节和某个框架的实现原理，重点关注在分层前后的使用对比，可能会以一些伪代码为例来说明举例。

接口测试三要素：

  • 参数构造
  • 发起请求，获取响应
  • 校验结果一、原始状态当我们的用例没有进行分层设计的时候，只能算是一个“苗条式”的脚本。以一个后台创建商品活动的场景为例，大概流程是这样的(默认已经是登录状态下)：

创建商品-创建分类-创建优惠券-创建活动

要进行接口测试的话，按照接口测试的三要素来进行，具体的效果如下：

# 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层就没有适用的场景步骤供调用，那么我就需要根据自己的需要重新封装；可是对于很多单接口的前置数据处理又是一致的，比如：

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。。。

重新封装的话还要再处理这一步，就有点麻烦且不符合我们的复用性设计了，因此我们对service层再细化为3层，分别为：

apiObject：

单接口的预处理层，这一层主要作用是单接口入参的构造，接口的请求与响应值返回

  • 每个接口请求不依赖与业务步骤，都是单接口的请求；
  • 此外一些简单固定的入参构建也直接放在这里处理，比如随机的商品名，title等，和具体业务流程无关，针对所有调用此接口的场景均适用

caseService：

多接口的预处理层，这一层主要是测试步骤（teststep）或场景的有序集合。

  • 用例所需要的步骤，通过每一个请求进行组合，每一个步骤都对应着一个API请求，这些步骤会组成一个个场景，各个场景之间可以互相调用组成新的场景，以适应不同的测试用例需求。
  • 场景封装好以后可以供不同的测试用例调用，除了当前项目的用例，其他业务线需要的话也可从此caseService中选择调用，提高复用性的同时也避免了用例相互依赖的问题。

util：

这一层主要放置针对当前业务的接口需要处理的数据

  • 在实际编写测试步骤时，可能部分接口的参数是通过其他接口获取后经过处理才可以使用，或是修改数据格式，或是修改字段名称，亦或是某些 value 的加解密处理等。

细化分层后，各层的职责便更加清晰明确，具体如下图：

实例演示

apiObject:

class ApiObject:
 def createCommodity(createCommodityParams):
  inputParams = ApiParamsBuild().createCommodityParamsBuild(createCommodityParams)
  response = APIDefinition().createCommodityRequest(inputParams)
  return response

 def createCategory(createCategoryParams):
  ...

 def createCoupon(createCouponParams):
  ...

 ......
  
class ApiParamsBuild:
 def createCommodityParamsBuild(createCommodityParams):
  createCommodityParams["input"]["title"] = "autoTest" + str(time.time())
  createCommodityParams["input"]["mallCode"] = self.mallCode
  createCommodityParams["input"]["skuList"][0]["price"] = random.randint(1,10)
  return createCommodityParams

 def createCategoryParamsBuild(createCategoryParams):
  ...

 def createCouponParamsBuild(createCouponParams):
  ...

 ......

到此，我们来看看原始的用例经过目前封装后的模样：

# 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 = {......}

# 2、发起请求，获取响应
 # 创建商品并获取商品code
createCommodityRes = ApiObject().createCommodity(createCommodityParams)
commodityCode = createCommodityRes["commodityCode"]
 # 创建分类并获取分类code
createCategoryRes = ApiObject().createCategory(createCategoryParams)
categoryCode = createCategoryRes["categoryCode"]
 # 创建优惠券并获取优惠券code
createCouponRes = ApiObject().createCoupon(createCouponParams)
couponCode = createCouponRes["couponCode"]
 # 创建活动并关联商品,绑定优惠券,设置分类
createPublicityParams["input"]["commodityCode"] = commodityCode
createPublicityParams["input"]["categoryCode"] = categoryCode
createPublicityParams["input"]["couponCode"] = couponCode
createPublicityRes = ApiObject().createPublicity(createPublicityParams)

# 结果校验(断言)
assert.equal(createPublicityRes["code"], 0)
assert.equal(createPublicityRes["publicityName"], createPublicityParams["publicityName"])
。。。

可以看到，现在接口请求的url、method、通用入参处理等已经不会在用例中体现了，接下来继续封装caseService层。

caseService:

我们将多接口的场景步骤进行封装

class CaseService:
 def createPublicityByCategory(params):
   # 创建商品并获取商品code
  createCommodityRes = ApiObject().createCommodity(createCommodityParams)
  commodityCode = createCommodityRes["commodityCode"]
   # 创建分类并获取分类code
  createCategoryRes = ApiObject().createCategory(createCategoryParams)
  categoryCode = createCategoryRes["categoryCode"]
   # 创建优惠券并获取优惠券code
  createCouponRes = ApiObject().createCoupon(createCouponParams)
  couponCode = createCouponRes["couponCode"]
   # 创建活动并关联商品,绑定优惠券,设置分类
  createPublicityParams["input"]["commodityCode"] = commodityCode
  createPublicityParams["input"]["categoryCode"] = categoryCode
  createPublicityParams["input"]["couponCode"] = couponCode
  createPublicityRes = ApiObject().createPublicity(createPublicityParams)
  return createPublicityRes

 ......

这时体现在用例中的表现就如下层testcase层所示.

3、testcase 层

我们想要的是一个清晰明了，“一劳永逸”的自动化测试用例，就像我们的手工测试用例一样，我们的前置条件可以复用，我们入参可以任意修改，但测试步骤都是固定不变的(前提可能是产品没有偷偷改需求~)。

这一层其实是对应的testsuite(测试用例集)，是测试用例的无序集合。其中各个用例之间应该是相互独立，互不干扰，不存在依赖关系，每个用例都可以单独运行。

最终我们期望自动化用例的维护过程中达到的效果如下：

testcase 层：

# 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 = {......}
 
 # 2、发起请求，获取响应
 createPublicityRes = CaseService().createPublicityByCategory(createCommodityParams,createCategoryParams,createCouponParams...)
 
 # 结果校验(断言)
 assert.equal(createPublicityRes["code"], 0)
 assert.equal(createPublicityRes["publicityName"], createPublicityParams["publicityName"])
 。。。

可以看到，这时涉及到用例场景步骤的代码已经非常少了，并且完全独立，与框架、其他用例等均无耦合。

到这里我们再看用例，会发现一点，测试数据依然冗长，那么下面就开始对测试数据进行参数化和数据驱动的处理。

4、testdata

此层用来管理测试数据，作为参数化场景的数据驱动。

参数化： 所谓参数化，简单来说就是将入参利用变量的形式传入，不要将参数写死，增加灵活性，好比搜索商品的接口，不同的关键字和搜索范围作为入参，就会得到不同的搜索结果。上面的例子中其实已经是参数化了。

数据驱动：对于参数，我们可以将其放入一个文件中，可以存放多个入参，形成一个参数列表的形式，然后从中读取参数传入接口即可。常见做数据驱动的有 JSON、CSV、YAML 等。

实例演示

我们以CSV为例，不特别依照某个框架，通常测试框架都具备参数化的功能。

将所需要的入参放入test.csv文件中：

createCommodityParams,createCategoryParams,...
{
     "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"
     }
 },
 ...

然后再回到用例层，利用框架参数化的功能对数据进行读取

# 1、参数构造
@parametrize(params = readCsv("test.csv"))
# 2、发起请求，获取响应
createPublicityRes = CaseService().createPublicityByCategory(params)
# 结果校验(断言)
assert.equal(createPublicityRes["code"], 0)
assert.equal(createPublicityRes["publicityName"], createPublicityParams["publicityName"])
。。。

注：这里的测试数据，不仅仅局限于接口的请求参数，既然做数据驱动，那么断言也可以维护在此，以减少用例层的代码冗余。

5、rawData

这一层是存放接口原始入参的地方。

某些接口的入参可能很多，其中很多参数值又可能是固定不变的，构建入参的时候我们只想对"变"的值进行动态的维护，而不维护的值就使用原始参数中的默认值，以此减少工作量(emmm…可能也就是CV大法的量吧~)

再者就是数据驱动的数据文件中只维护需要修改的参数，使数据文件更简洁，可阅读性更强。

实例演示：

这种利用原始参数(rawData)的方法我们称之为模板化，实际工作中有多种方式可实现，例如jsonpath、Mustache或者自己根据需求实现方法,本文重点在介绍分层设计，所以就不具体演示模板化技术的细节了，仅说明设计此层的作用。

以实例中的入参createCommodityParams为例，未用模板化技术前，我们要在CSV里面维护完整的入参：

createCommodityParams,createCategoryParams,...
 {
      "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"
      }
  },
  ...

但是实际上，我们可能仅仅需要修改维护其中某个或某几个字段（例如只想维护商品价格），其余的使用默认值即可，使用模板化技术后可能在CSV中就是这样的表现：

createCommodityParams,createCategoryParams,...
 {
      "input": {
          "skuList": [
              {
                  "price": 1,
                  "retailPrice": 6
      }
  },
  ...

或者这样

- keyPath: $.input.skuList[0].price
	value: 1
- keyPath: $.input.skuList[0].retailPrice
	value: 6

亦或使用Mustache，将需要修改的value进行参数化{{value}}。

我们可以看到，这样处理后的数据驱动的文件就变得简洁清晰的许多，当一个文件中维护了多个用例且入参字段很多时，这样维护起来就可以清晰的看出每个数据对应的用例的作用了；

price就是为了测试价格的，stock就是为了测试库存的，publish就是为了测试上下架的等等。

注： 当然，此层的使用视实际情况而定，有可能这个接口的参数本身就没多少，那么直接全量使用就行，或者你就是觉得数据量哪怕再大我都能分得清楚，看的明白，不用也rawData是可以的~

6、Base

此层主要放置我们需要处理的公共前置条件和一些自动化公共方法，也可以理解为公共的config和util。

在我们实际的自动化开发过程中，有很多前置条件或公共方法，比如登录处理，log 处理，断言方法或一些数据处理；

使用过程中所有的service和testcase层都会继承此类，这样这些公共方法和前置条件便可直接通用；在各个业务线之间也可保持一致性。

三、完结

最后，我们来看下整体分层后的目录结构总览：

└─apiautotest
  └─project
   └─rawData（原始参数）
    ├─testRawData.json
   └─service（用例服务）
    └─apiObject（单接口预处理，单接口入参的构造，接口的请求与响应值返回）
     ├─testApiObject.py
          └─caseService（多接口预处理，测试步骤（teststep）或场景的有序集合）
           ├─testCaseService.py
          └─util（工具类）
           ├─util.py
      └─testcase（测试用例）
          └─testDataDriven（测试数据驱动）
           ├─testData.csv
          ├─testcase.py（测试用例集）
     └─testBase.py（测试基类，初始化和公共方法） 
  └─platformapi（Api定义）
   ├─testApiDefinition.py

以上，期待与各位同学一起交流探讨。

程序员木江
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Python接口自动化测试框架（方案篇）-- 框架设计和测试分层
我先测了
03-28 773
小朋友,你是否有很多问号？为什么这篇才写方案？不写在实战前面呢？而是在前面一阵捣鼓之后才点题，整个代码框架甚至都已经封装好了，或者已经有了自动化测试思想的雏形了，现在才来科普教学，会不会有点晚？说实话，只要是干货，什么时候都不晚！这也是题主自己想补充的，其实这部分的内容也在其他篇幅中有拆散了讲，只是没有串联起来、觉得有点不够完整，暂且没在其中总结归纳，故而此时拿出来讲一个整体框架是如何设计的，也可用于指导接口自动化测试方案文档输出及落地实施。
全网最新最全的自动化测试：python+pytest接口自动化-接口测试基础
测试-八戒
12-04 142
就当前软件测试招聘的市场需求以及趋势而言，接口测试是测试人员必须掌握的技能，而接口自动化测试则是加薪利器。工作过程中更多的是对HTTP协议的接口做接口测试，后续博客针对的也是HTTP类型的接口。也方便你下次能够快速查找。如有不懂还要咨询下方小卡片，博主也希望和志同道合的测试人员一起学习进步在适当的年龄，选择适当的岗位，尽量去发挥好自己的优势。我的自动化测试开发之路，一路走来都离不每个阶段的计划，因为自己喜欢规划和总结，测试开发视频教程、学习笔记领取传送门！！
从0到1实现接口自动化测试平台【1700字保姆级教程】
05-09 1275
实现方式 后端：java 前端：vue+element-ui mock：mock-server 其它：redis 01、数据构建 我们在测试过程中发现测试数据的构建非常重要。如测试数据需要有真实性、唯一性、A 接口依赖 B 接口的返回值。目前通过提供环境变量、方法反射、接口依赖、SQL 依赖等方式提供数据，通过 ${}表达式引用。 1、环境变量 最简单的一种方式，key-value 方式。 2、预置方法 通过反射的方式，动态调用预置的数据构造方法。
干货 | 接口自动化测试分层设计与实践总结
最新发布
qq_48811377的博客
04-10 1561
我们编程的时候会将一些重复的代码进行封装使用，那么这里依然可以借用这种思想，我们将 API 的定义单独抽离，单独定义。我们期望的效果是这样的：提前将API的定义放在一层，供用例场景引用，这样当接口有任何修改时，我们只需要修改层即可。实例演示对应着上面的demo，我们就是需要做如下抽离：‘’’创建商品API定义createCommodityParams： 创建商品接口入参return：创建商品接口响应结果‘’’'''创建分类API定义。
8年测试老鸟，Python Selenium自动化测试-POM分层封装框架（超全整理）
分享测试知识
10-25 1004
1、POM模式是什么页面对象模型（POM）是一种设计模式，用来管理维护一组web元素集的对象库在POM模式下，应用程序的每一个页面都有一个对的page class每一个page class维护着该web页的元素集合操作这些元素的方法page class中的方法名最好根据业务场景进行2、 POM的优势POM提供了一种在UI层操作、业务流程与验证分离的模式，这使得测试代码变得更加清晰和高可读性对象库与用例分离，使得我们更好的复用对象，甚至能与不同的工具进行深度结合应用。
四招打造完美分层自动化测试框架，让测试更高效！
m0_58026506的博客
12-08 166
我们刚开始做自动化测试，可能写的代码都是基于原生写的代码，看起来特别不美观，而且感觉特别生硬。来看下面一段代码：具体表现如下：driver对象在测试类中显示定位元素的value值在测试类中显示定位元素的方式在测试类中显示线程方式硬等待sleep几秒代码一报错，还要去测试类里面找是哪段代码报错，当代吗行数好多时，不好定位好多测试脚本组装批量执行后，报错后，定位问题，很吃力有命中的小伙伴嘛，有的话，请在文末下方留言，其他现象就不一一列举了。
接口自动化框架搭建
weixin_40611700的博客
10-25 3715
1.自动化测试流程 --需求分析。需求文档，接口文档，抓包接口 --测试计划。通常包含项目的进度，是否自动化，优先级 --测试用例（是从手工测试提取出来的） --用例评审 --执行测试。（写代码） --测试报告 接到项目之后，如何去进行需求分析： 1.需要文档，功能展示以及交互 2.接口文档，后端数据是怎么传输的 3.数据库账号，数据库地址，结构帮大家熟悉整个项目的轮廓，字段 4.测试环境，环境怎么搭建 5.原型图 测试计划： 通常是由测试经理或者项目经理来编写的 ...
接口自动化测试分层设计与实践总结
hogwarts_beibei的博客
05-07 334
本文以笔者当前使用的自动化测试项目为例，浅谈分层设计的思路，不涉及到具体的代码细节和某个框架的实现原理，重点关注在分层前后的使用对比，可能会以一些伪代码为例来说明举例。 接口测试三要素： 参数构造 发起请求，获取响应 校验结果 一、原始状态 当我们的用例没有进行分层设计的时候，只能算是一个“苗条式”的脚本。以一个后台创建商品活动的场景为例，大概流程是这样的(默认已经是登录状态下)： 创建商品-创建分类-创建优惠券-创建活动 要进行接口测试的话，按照接口测试的三要素来
自动化测试的分层结构
03-02
本文会介绍如何用分层结构来解决测试自动化中遇到的这些问题。在这个分层结构中，测试自动化代码会被分成三层：(1)测试用例层，表达应用程序的测试逻辑。(2)领域层，用业务领域术语来给待测系统建模，封装HTTP请求、...
有赞分层自动化测试实践
01-27
先理一下自动化测试的概念，从广义上来...所以初期我们测试自动化切入的思路非常简单：从实际用户的角度出发，模拟真实的操作，替代现有的手工测试用例的执行。这样一来，每次重复的工作就可以用自动化来替代，测试人员
分层自动化测试
12-07
该文档了讲述了自动化测试的分层，讲述每一层自动化测试优缺点。
Selenium分层框架
08-15
Selenium分层框架源码，XML，testng
Python接口自动化——自动化测试分层（1）
成都汇智动力的博客
01-14 2368
从本期开始，我们会围绕“Python接口自动化”做专题连载，今天开始做第一讲——自动化测试分层。 目录： 1. 1.1.1 单元自动化测试 2. 1.1.2 接口自动化测试 3. 1.1.3 UI自动化测试 现在流行的是金字塔状的分层测试，将测试从上到下分为UI测试层、接口测试层、单元测试层三层。 在传统的UI自动化的基础之上更多实施基于代码的低级别自动化测试，而不仅仅通过用户界面进行端到端的测试。 按照测试方法中黑盒、白盒、灰盒的观点来看： 单纯的UI自动...
接口自动化测试的分层的浅显理解
TesterAllen的博客
02-22 3581
本文以当前使用的自动化项目为例，浅谈分层设计的思路，不涉及到具体的代码细节和某个框架的实现原理，重点关注在分层前后的使用对比，可能会以一些伪代码为例来说明举例 接口测试三要素 参数构造 发起请求，获取响应 校验结果 一、原始状态 在我们用例没有进行分层的时候，只能算是一个“苗条式”的脚本，以一个后台创建商品活动的场景为例，大概流程是这样的(默认已经是登录状态下)： 创建商品-创建分类-创建优惠券-创建活动 要进行接口测试的话，按照接口测试的三要素来进行，具体的效果如下： # 1、参数构造 cr.
软件测试 | UI自动化中的分层设计
慕漓的博客
03-01 171
比如我在之前讲大数据的时候介绍过， 一个大数据平台的产品中做什么事都需要先把外部数据源中的数据同步到本系统里对吧， 所以数据中心的测试人员就的把自己模块的业务逻辑封装一下给其他模块的人用。并且这些元素的定位都是通过组件层的方法来完成的。原则上，我们所有的页面元素的交互都需要通过调用组件层的函数来完成， 一个是加快元素定位的速度 – 调用者不再需要自己定位了， 只需要调用组件层的方法，传递参数即可。组件层封装基本控件，应对前端组件库的变化， 而页面层就是对产品界面进行封装， 应对的是页面逻辑发生的变动。
自动化框架分层
guiyin1150的博客
05-17 1551
框架的分层： 代码运行层：run_test.py作用：代码的入口，运行代码，收集测试用例，生成测试报告 测试逻辑层：test_case包，各个模块的测试用例方法，便于管理，便于维护 数据管理层： data，excel数据，csv数据，数据列表的保存 业务逻辑层：common 通用（request_handler,excel_handler）,通用的，*logger日志的封装，访问数据库 配置文件：config 和项目相关联的，项目地址，数据库地址，logger级别 测试报告（输出）report 如下图所示
python 接口自动化测试框架分层设计
06-08
好的，针对这个问题，我可以给你一个简单的分层设计方案，具体如下： 1. 接口层：实现接口请求的封装和发送，一般使用 Python 的 requests 库等。 2. 数据层：将测试数据与测试用例分离，可以使用 Excel、CSV 等...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值