重构:发现测试的价值

回到起点,测试要解决什么问题,为什么要做API自动化测试平台?做这个平台,不是为了满足老板的提倡全民自动化的口号,也不是为了浮夸的KPI,更不是宣传自动化可以解决一切问题,发现所有bug。叔本华说过一句话:由于频繁地重复,许多起初在我们看来重要的事情逐渐变得毫无价值。如果API测试仅仅依靠纯手工的执行,很快将会面临瓶颈,因为每一个功能几乎都不能是第一次提交测试后就测试通过的,所以就需要反复bug修复、验证,以及回归的过程。另外,很多的API测试工作手工做起来非常的繁琐,甚至不便,比如针对接口协议的验证、针对返回数据格式的验证,这些都依赖于测试自动化的开展。因此,真正的目的是解放测试人员重复的手工生产力,加速回归测试效率,同时让研发人员在开发过程及早参与测试(自测、冒烟测试),驱动编码质量的提升。

回顾以往,重新梳理头绪,更加清晰的展现:

(点击放大图像)

图-8-HTTP API自动化测试图解

  • HTTP API传统手工测试
  • 重复请求参数基础校验、正确参数查询返回数据校验,测试工程师没有新的创造价值,不断重复工作,甚至可能压缩其中的测试环节,勉强交付;
  • HTTP API自动化测试
  • 重复步骤(请求接口是否有效、参数校验可以作为冒烟测试,研发参与自测)用自动化解决,关键业务步骤数据对比人工参与和schema自动化校验;

最大的收益,重复步骤自动化后,不管是研发人员自测,还是执行功能回归测试,成本可以很快收回(前提是你这个项目周期长,构建频繁;如果仅仅是跑几个月的项目,真没那个必要凑热闹去自动化,当然有平台的另当别论),测试的关注点会落实到更加关键的业务环节去;

总体规划如下:

(点击放大图像)

图-9-HTTP API重构规划

  • 技术选型

    由于原来的测试平台使用Python编写,为了保持风格一致,从界面录入到文件生成处理依然采用Python、Django,去掉了全对偶组合算法,改为根据测试人员思维去产生用例;去掉了后台RobotFramework框架,采用Python的HTTP类库封装请求。

  • HTTP API项目管理Web前台

    使用Python+Django+MySQL进行开发,分为项目首页、项目配置、API配置、全局配置四大部分

    (点击放大图像)

    图-10-管理Web

    > 项目首页

    介绍:列出API规范、API测试用例、定时任务数量,以及某段时间内的测试结果趋势图形。

    (点击放大图像)

    图-11-项目首页

  • 项目配置

    重点介绍:全局变量、常用方法、验证器。

    >全局变量

    设计思路:在API测试过程中,可以切换生产、测试环境进行对比校验,如果写两套测试用例是冗余,全局变量功能,是一种在执行测试用例时动态改变用例属性的方法。

    作用范围:当前项目内

    使用方法:{变量名}

    能在以下测试用例属性中使用:URL、请求头、请求参数

    (点击放大图像)

    图-12-全局变量配置页

    在API用例库的URL可以直接填写:{host}/reportdata/monitor/getChannelIDsByUserName;当运行测试用例的时候,可以选择不同的参数套件,后台代码执行会直接替换,这样子可以分别快速验证生产环境和测试环境的API接口执行结果的差异。

    (点击放大图像)

    图-13-用例执行页

    >常用方法

    (点击放大图像)

    图-14-常用方法列表页

    √ 设计思路:常用方法是一个Python函数,对入参进行处理并且返回结果,例如:

    gen_md5 作用是生成MD5,对应代码直接填写:

    import hashlib
    def gen_md5(raw_str):
        m = hashlib.md5()
        m.update(raw_str)
        md5_str = m.hexdigest()
        return md5_str

    √ 应用场景:

    在API请求中,有些参数例如pass需要加密处理,可以通过引入[常用方法]来解决。

    在参数pass的值中直接填写:

    {{get_apipwd("{123456}","ChinaCache")}}

    (点击放大图像)

    图-15-接口配置页

    > 验证器

    (点击放大图像)

    图-16-验证器配置页

    √ 设计思路

    验证器是一个Python函数,如果函数返回True,则测试通过;返回False,则测试失败。平台默认提供一个默认验证器。

    默认验证器是验证期望结果与实际结果(response body)是否完全一致。如果结果不一致则判断为失败,默认验证器只适用于静态的响应结果对比。

    自义定验证器,如果默认验证器不能满足某些特殊的测试需求,用户可以在“项目配置-验证器”中添加自定义的验证器。

    √ 应用场景:在API测试的返回结果中,可以添加自定义验证器对数据进行校验,判断测试是否通过。

    (点击放大图像)

    图-17-测试用例验证展示页

  • API配置

    重点介绍:通用响应配置、API依赖库、API用例库、定时任务、测试报告

    > 通用响应配置

    (点击放大图像)

    图-18-通用响应配置列表页

    √ 设计思路

    在合理的API设计中,存在通用的错误响应码,[用户名错误,返回期望响应内容],如果所有API的响应结果中都需要重复写是相当繁琐的,作为共同配置调用即可。

    (点击放大图像)

    √ 应用场景

    查询接口遇到用户名密码为空,可以自定义写返回内容,以及选择[通用响应配置]下的相关错误类型,例如:用户名密码为空(计费单元),自动填充期望的返回值:

    <BillingIDs>
      <Result>fail</Result>
      <DetailInfo>invalid userName or password</DetailInfo>
    </BillingIDs>

    (点击放大图像)

    图-19-期望返回值校验页

    > API依赖库

    √ 设计思路&应用场景

    API-A的参数r_id依赖与API-B返回结果的某个参数(多个参数同样道理),这里登记API-B,并且提取返回参数。除了特有的变量提取器,基本信息与请求,与后面提到的API接口一致的

    填写方式 :

    (点击放大图像)

    图-20-变量提取器展示页

    该接口返回数据如下;

    {
      "r_id": "567bbc3f2b8a683f7e2e9436"
    }

    通过[变量提取器],可以获取r_id的值,以供依赖API-A作为参数使用。

    (点击放大图像)

    图-21-用例中参数包含r_id变量展示页

    其中请求参数的获取如下:

    (点击放大图像)

    图-22-请求参数变量提取设置

    测试结果:

    1-显示依赖接口;2-显示为需要测试的接口,依赖接口返回的r_id会传入作为测试接口的参数;

    (点击放大图像)

    图-23-测试结果中展示运行时变量提取结果

  • API用例库

    (点击放大图像)

    图-24-用例库设计脑图

    √ 设计思路

    通过自助配置:请求头、请求参数,响应头、响应结果校验,来聚合测试人员日常思考产生的测试用例。

    √ 应用场景

    支持HTTP1.1协议的7种请求方法:GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。最常用的方法是GET和POST:

    1. 支持query(问号后)带参数、path的GET|POST请求

      Query:http://192.168.1.11/internal/refresh?username=ChinaCache&password=123456

      Path:http://192.168.1.11/internal/refresh/username/password

    2. POST请求支持application/json、text/xml

      示例如下:

      请求头设置:Content-Type:application/json
                 请求体设置:保存为JSON格式
      {
          "username": "ChinaCache", 
          "password": "123456", 
          "task": {
              "dirs": [
                  ""
              ], 
              "callback": {
                  "url": "", 
                  "email": []
              }, 
              "urls": [
                  "http://www.chinacache.com/news/test.html"
              ]
          }
      }

      结果如下:

      (点击放大图像)

      图-25-body参数展示页

    3. 支持返回结果的schema验证

      在返回大量数据的场景下,把数据格式的正确性交给程序去判断,通过之后进行人工干预的数据对比,假如返回几百K的数据,你不知道格式是否正确,就开始去做数据对比,这个方向是不对的。

      {
        "r_id": "567cfce22b8a683f802e944b"
      }
            Schema验证如下:
      {
          "$schema": "http://json-schema.org/draft-04/schema#", 
          "required": [
              "r_id"
          ], 
          "type": "object", 
          "id": "http://jsonschema.net", 
          "properties": {
              "r_id": {
                  "type": "string", 
                  "id": "http://jsonschema.net/r_id"
              }
          }
      }
  • 定时任务

    √ 设计思路&应用场景

    定时任务是在计划好的时间点自动执行指定的测试用例。一个项目支持多个定时任务,如果同一时间点有多个测试任务,将依次执行。定时任务有两种类型:定时、循环(间隔:秒,

    分钟,小时,天,周)。通过定时任务,可以做到晚上运行,早上查看结果报告分析。

    (点击放大图像)

    图-26-添加定时任务

  • 测试报告&邮件通知

    √ 设计思路&应用场景

    每次执行测试用例(包括手动执行和定时任务)之后,都会生成一份测试报告。

    报告会详细列出每个接口的基本信息(名称,请求方法,验证器等),请求信息(URL和body参数),响应信息包括headers, body, schema, content type, status code 5部分的测试结果,每一部分都有实际结果、期望结果(失败时显示)以及DIFF对比(失败时显示),当在

    执行测试时出现错误,也会把错误信息显示出来 。

    (点击放大图像)

    图-27-测试报告列表页

    (点击放大图像)

    图-28-邮件通知

    API实战:324个用例(包括GET|POST请求,参数有加密、依赖场景,返回结果有简单验证数据、错误码验证、schema验证),运行耗时:8min,猜想下,如果人工去跑,需要多久呢?

提速:研发测试流程改进

(点击放大图像)

图-29-使用HTTP API平台改进API研发测试过程

  • 改进前:传统手工测试

    测试用例掌握在测试人员手里,研发人员无法运行,修复bug之后,只能等待测试人员验证,交付过程繁琐、效率低;

  • 改进后:HTTP API自动化测试

    研发、测试协作同步,研发人员可以及早通过平台执行用例,验证功能可用性、正确性,测试人员可以释放部分劳动力,重点关注业务数据正确性;修复bug之后,研发人员无需等待,可以自助配置用例执行、查看结果,驱动过程质量的提升,同时做到夜间构建、邮件通知,工作时间review、bug fix。

  • 问题:何时收回投入成本?

    API项目周期不超过半年的,不建议做自动化,有自动化平台基础的另当别论,因为在最初API测试用例编写需要投入大量的时间;这种投入,只有不断进行回归验证、多次运行,成本才可以回收,往后都是收益,这个道理浅显易懂。

总结

“由于频繁地重复,许多起初在我们看来重要的事情逐渐变得毫无价值”,在提测过程有个重要环节:冒烟测试,但是频繁的去做的话,就是重复性的工作了。

那HTTP API接口测试痛点是什么?研发人员提测之后,需要等待测试人员进行验证;测试人员发现bug,需要等待研发人员bug fix;这里就产生大量的等待成本(当然,测试人员可以切换到其他项目中去,但是这种上下文的切换成本很高)。通过HTTP API自动化测试平台,研发人员在提测之前,首先进行一轮冒烟测试,根据自动化测试用例检查结果,提升提测之前的功能质量;一旦提测之后,测试人员的关注重点落到返回结果对比上,这种研发测试过程的效率会得到很大的提升,或许有人要问,到底提升多少呢?这个每个团队的痛点不同,研发、测试人员磨合程度不同,不能一概而论,大胆迈出一步去尝试,就会发现价值;当然,往深处去想,下一步可以接入性能的自动化测试,喝杯咖啡的时间,等到自动化运行结果报告产出,是有可能的场景。

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐