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

news2024/11/26 12:13:44

接口测试三要素：

  • 参数构造

  • 发起请求，获取响应

  • 校验结果

一、原始状态

当我们的用例没有进行分层设计的时候，只能算是一个“苗条式”的脚本。以一个后台创建商品活动的场景为例，大概流程是这样的(默认已经是登录状态下)：

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

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

 # 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

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！ 

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1186344.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Python--快速入门三

Python--快速入门三

Python--快速入门三 1.Python列表 列表是Python用于储存一系列数据的容器(特点是可以存放不同类型的数据) python_list ["键盘",True,66,88.8] 列表是可变数据类型，可以直接对列表中的元素进行更改而不需要赋值给本身 列表方法： 1.appen…
阅读更多...
纯干货：赝势的选择 | VASP计算入门教程，真的超级有用

纯干货：赝势的选择 | VASP计算入门教程，真的超级有用

VASP软件是基于贋势和平面波基组的第一性原理密度泛函计算程序。VASP使用的是平面波基组，电子与原子核之间的相互作用使用投影缀加波贋势（Projector Augmented Wave，PAW）方法描述，从而进行量子力学计算。VASP采用PAW贋…
阅读更多...
成绩公布方式，这样操作更方便

成绩公布方式，这样操作更方便

老师们！又到了期中，是不是又在为如何安全、高效的公布学生成绩而烦恼呢？别担心，今天我就给大家分享几种超实用的成绩公布方式，不仅减轻了你的工作负担，还能让学生和家长们也方便！ 1 Excel表格&a…
阅读更多...
【Android Studio】Android Studio修改代码编辑区（工作区）背景色

【Android Studio】Android Studio修改代码编辑区（工作区）背景色

Android Studio 字体大小及背景色的设置 1、 打开File—>Settings 或者 Android Studio—>CtrlAlts 2、 在setting对话框中选中“Editor->Colors&Fonts->Font ， 点击Save as,自定义一个主题,选择字体，size和行间距，保存。 3…
阅读更多...
Flink -- 状态与容错

Flink -- 状态与容错

1、Stateful Operations 有状态算子： 有状态计算，使用到前面的数据，常见的有状态的算子：例如sum、reduce，因为它们在计算的时候都是用到了前面的计算的结果 总结来说，有状态计算并不是独立存在的&#xf…
阅读更多...
C++学习---异常处理机制

C++学习---异常处理机制

文章目录 前言abort()函数 and 返回错误码的异常方式C异常处理机制异常的类别what()函数 前言 abort()函数 and 返回错误码的异常方式 在说C异常处理机制之前，了解一下abort()函数和返回错误码的异常处理。 Abort( )函数的原型位于头文件cstdlib（或std…
阅读更多...
CSS关于默认宽度

CSS关于默认宽度

所谓的默认宽度&#xff0c;就是不设置width属性时&#xff0c;元素所呈现出来的宽度 <!DOCTYPE html> <html lang"en"> <head><meta charset"UTF-8"><title></title><style>* {margin: 0;padding: 0;}.box {/…
阅读更多...
git 生成公钥

git 生成公钥

1、通过命令 ssh-keygen 生成 SSH Key&#xff1a; ssh-keygen -t ed25519 -C "Gitee SSH Key" 三次回车 2、查看生成的 SSH 公钥和私钥&#xff1a; ls ~/.ssh/ 3、把公钥设置到git id_ed25519.pub 4、测试 ssh -T gitgitee.com 成功&#xff01;&#xff01;&…
阅读更多...
基于减法平均算法的无人机航迹规划-附代码

基于减法平均算法的无人机航迹规划-附代码

基于减法平均算法的无人机航迹规划 文章目录 基于减法平均算法的无人机航迹规划1.减法平均搜索算法2.无人机飞行环境建模3.无人机航迹规划建模4.实验结果4.1地图创建4.2 航迹规划 5.参考文献6.Matlab代码 摘要&#xff1a;本文主要介绍利用减法平均算法来优化无人机航迹规划。 …
阅读更多...
朋友圈延迟评论，你用过吗？

朋友圈延迟评论，你用过吗？

在社交媒体时代&#xff0c;朋友圈已经成为人们交流和互动的重要平台。然而&#xff0c;在发表评论时&#xff0c;我们往往会被情绪冲昏头脑&#xff0c;或者因为时间紧迫而没有充分思考。这可能会导致一些不恰当的言论&#xff0c;或者错过一些更精准的表达方式。朋友圈延迟评…
阅读更多...
摄像头内参准确性验证方法

摄像头内参准确性验证方法

前言 摄像头内参标定出来后&#xff0c;标定结果是否准确&#xff1f;有些内参准确性的验证方案需要很大的场地&#xff0c;且有很多误差源不好控制&#xff08;特别是对视野比较大的摄像头&#xff09;&#xff0c;惠州市华阳数码特电子有限公司发明了一种占用场地小测试精度…
阅读更多...
uniapp u-tabs表单如何默认选中

uniapp u-tabs表单如何默认选中

首先先了解该组件&#xff1b;该组件&#xff0c;是一个tabs标签组件&#xff0c;在标签多的时候&#xff0c;可以配置为左右滑动&#xff0c;标签少的时候&#xff0c;可以禁止滑动。 该组件的一个特点是配置为滚动模式时&#xff0c;激活的tab会自动移动到组件的中间位置。 …
阅读更多...
【Java初阶习题】 -- 类和对象

【Java初阶习题】 -- 类和对象

目录 1.局部变量必须先初始化才能使用2. this的两种用法3. import语句不能导入一个指定的包4.代码块的执行顺序5.静态变量的调用6 . 现有一个Data类&#xff0c;内部定义了属性x和y&#xff0c;在main方法中实例化了Data类&#xff0c;并计算了data对象中x和y的和。 1.局部变量…
阅读更多...
11月第1周榜单丨飞瓜数据B站UP主排行榜榜单（B站平台）发布！

11月第1周榜单丨飞瓜数据B站UP主排行榜榜单（B站平台）发布！

飞瓜轻数发布2023年10月30日-11月5日飞瓜数据UP主排行榜&#xff08;B站平台&#xff09;&#xff0c;通过充电数、涨粉数、成长指数、带货数据等维度来体现UP主账号成长的情况&#xff0c;为用户提供B站号综合价值的数据参考&#xff0c;根据UP主成长情况用户能够快速找到运营…
阅读更多...
【分布式事务】深入探索 Seata 的四种分布式事务解决方案的原理，优缺点以及在微服务中的实现

【分布式事务】深入探索 Seata 的四种分布式事务解决方案的原理，优缺点以及在微服务中的实现

文章目录 前言一、XA 模式1.1 XA 模式原理1.2 XA 模式的优缺点及应用场景1.3 Seata XA 模式在微服务中的实现 二、AT 模式2.1 Seata AT 模式原理2.2 AT 模式的脏写问题和写隔离3.3 AT 模式的优缺点3.4 Seata AT 模式在微服务中的实现 三、TCC 模式3.1 TCC 模式原理3.2 Seata 的…
阅读更多...
洛谷 P1020 [NOIP1999 普及组] 导弹拦截【一题掌握三种方法：动态规划+贪心+二分】最长上升子序列LIS解法详解

洛谷 P1020 [NOIP1999 普及组] 导弹拦截【一题掌握三种方法：动态规划+贪心+二分】最长上升子序列LIS解法详解

P1020 [NOIP1999 普及组] 导弹拦截 前言题目题目描述输入格式输出格式样例 #1样例输入 #1样例输出 #1 提示题目分析注意事项 代码动态规划&#xff08;NOIP要求&#xff1a;时间复杂度O(n^2^)&#xff09;贪心二分&#xff08;O(nlgn)&#xff09; 后话额外测试用例样例输入 #1…
阅读更多...
数据结构：Map和Set（2）：相关OJ题目

数据结构：Map和Set（2）：相关OJ题目

目录 136. 只出现一次的数字 - 力扣&#xff08;LeetCode&#xff09; 771. 宝石与石头 - 力扣&#xff08;LeetCode&#xff09; 旧键盘 (20)__牛客网 (nowcoder.com) 138. 随机链表的复制 - 力扣&#xff08;LeetCode&#xff09; 692. 前K个高频单词 - 力扣&#xff08…
阅读更多...
“百人专家团”背书 袋鼠妈妈“双十一”蓄势待发

“百人专家团”背书 袋鼠妈妈“双十一”蓄势待发

从万千商家的角度来看,“双十一”实际上就是一场没有硝烟的“战争”,只有用心做产品的品牌才能成为常胜将军,要想在双十一脱颖而出在同品类榜单上占据有利位置,品牌力和产品力二者缺一不可。而专注母婴护肤10年的袋鼠妈妈品牌便是如此,从品牌诞生以来,始终专注母婴用户需求,打造…
阅读更多...
STM32MPU6050角度的读取（STM32驱动MPU6050）

STM32MPU6050角度的读取（STM32驱动MPU6050）

注&#xff1a;文末附STM32驱动MPU6050代码工程链接&#xff0c;需要的读者请自取。 一、MPU6050介绍 MPU6050是一款集成了三轴陀螺仪和三轴加速度计的传感器芯片&#xff0c;由英国飞利浦半导体&#xff08;现为恩智浦半导体&#xff09;公司生产。它通过电子接口&#xff08…
阅读更多...
面包屑实现

面包屑实现

背景&#xff1a;面包屑根据菜单内容显示不同内容。首页永远存在&#xff0c;后面的活动管理及多级菜单的面包屑展示。 实现原理&#xff1a; 通过this.$route.matched获取所有匹配路由&#xff0c;将处理首页外的其他路由设置到一个数组中&#xff0c;再通过数组循环方式显示…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023