我爱编程自动化测试

转载：HTTP API自动化测试从手工到平台的演变

2017-08-03  本文已影响0人  Kewings

转载自infoQ：HTTP API自动化测试从手工到平台的演变
文章的思考以及演化方式值得借鉴，保留一份做参考。

不管是Web系统，还是移动APP，前后端逻辑的分离设计已经是常态化，相互之间通过API调用进行数据交互。在基于API约定的开发模式下，如何加速请求/响应的API测试，让研发人员及早参与到调试中来呢？既然API是基于约定开发，为何不按照这个规范编写测试用例，直接进入待测试状态，使用自动化的方式来推进研发过程的质量改进呢？遵循：测试->重构->测试->重构，这样的闭环，过程产出的质量会更加可控，在重构的同时进行快速的功能回归验证，大大提高效率。本文主要讲解基于HTTP协议的API测试，从手工测试到平台的演变过程。
手工测试带来的困惑
测试团队采用《敏捷脑图用例实践之路》的方式编写测试用例：
(点击放大图像)


图-1-分计费单元查询带宽
优点（文中已有详细介绍，这里简单列举）：
要点清晰简洁展现

所有测试故事点经过用例评审，产生质量高，研发参与感强；

版本同步保持一份

API测试脑图带来的问题：
脑图用例对测试人员的素质要求相当高

完善的脑图用例编写，需要有资深的测试人员，对业务精通、对测试技能精通，很强的思维能力；如果研发人员仅仅参考这个脑图用例进行测试，往往很多时候需要花费大量的沟通时间，其中有很多测试API的过程、措施，在脑图里面没有具体体现，造成一些信息丢失。

重复执行不变的是规则，变的只是参数，要消灭重复部分

还可以深度优化脑图用例，API接口规范，再怎么天马行空，也得有个度，应当把重复思考的部分交给工具去做，需要发挥创造力、值得关注部分，交给人工完成；按照这个测试流程，，测试人员编写完用例，去验证API接口，如果失败了，打回给研发人员重新修改，但是下一次研发人员提交测试，测试人员又得重新验证一遍，这一遍中实际没有多少有价值的思考，是重复工作，要去挖掘测试价值。另外，如果测试人员请假了，那是不是测试就需要延期了呢？消除等待、消除单点作业，改变是唯一出路，尝试过如下方式：

(点击放大图像)


图-2-Chrome DHC组件
组员通过使用Chrome DHC（是一款使用chrome模拟REST客户端向服务器发送测试数据的谷歌浏览器插件），进行API自动化测试，用例文件保存到本地并且同步到svn，简单粗暴解决重复请求问题，注意强调的是解决重复请求，并没有包括参数和结果的自动化验证的过程，还是需要人工参与，至少前进了一步，当然我们也解决了单点问题，其他组员可以更新用例本地运行，还差参数校验，数据校验等等一堆关键业务点要用自动化去突破。
俗话说：术业有专攻，DHC只是玩玩而已，并不擅长做那么多活，也做不好，更期望的是平台化。
平台雏形：没有经验，多么痛的领悟
经历了手工测试的繁琐操作，丢弃了简单的DHC，决定另寻新路，API测试最简单的场景请求参数组合产生各类别的测试用例。思路很简单，做一个WEB平台，登记API接口，填写请求参数，对响应结果进行校验，初期进行了技术选型，使用Django做Python Web开发，后台脚本执行使用开源框架RobotFramework，RF优点如下：
是一个通用的关键词驱动自动测试框架；

易于使用的表格数据展现形式，采用关键字驱动的测试方法，使用在测试库中实现的关键词来在测试中运行程序。

是灵活和可扩展的，适合用于测试用户接口；

在这个平台中，RobotFramework主要用于后台执行Robot关键字脚本，而关键字脚本，是平台通过读取YAML文件生成，该文件是通过笛卡尔乘积产生的用例，工作原理如图所示：
(点击放大图像)


图-3-工作原理
那话说回来，YAML干什么呢？为什么不是XML呢？
YAML的可读性好

YAML和脚本语言的交互性好

YAML使用实现语言的数据类型

YAML有一个一致的信息模型

YAML易于实现

听起来YAML试图用一种比XML更敏捷的方式，来完成XML所完成的任务。下面通过一段实际例子说明配置生成的YAML代码段：
被测接口通过web界面配置
主接口配置界面：
(点击放大图像)


图-4-接口配置页面
设置API参数：
(点击放大图像)

图-5-设置API参数
配置文件byChannelsDaily.yaml（列举一个参数示例）：

败了，就是败了，没什么好找借口，关键问题是：
有效的测试用例占比例很低，无效的占了大部分；
没有化繁为简，前端隐藏了配置，复杂的配置还是需要在后端处理；
没有实际测试参与动脑过程，测试人员不会穷举，会根据业务编写实际用例；
平台易用性很重要：需要测试人员直接在上面编写，合理的逻辑步骤，有利于引导测试参与；

重构：发现测试的价值
回到起点，测试要解决什么问题，为什么要做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接口执行结果的差异。

(点击放大图像)

image

图-13-用例执行页

常用方法

(点击放大图像)

image

图-14-常用方法列表页

√ 设计思路：常用方法是一个Python函数，对入参进行处理并且返回结果，例如：
gen_md5 作用是生成MD5，对应代码直接填写：
import hashlibdef 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用例库、定时任务、测试报告

通用响应配置

(点击放大图像)

image

图-18-通用响应配置列表页
√ 设计思路
在合理的API设计中，存在通用的错误响应码，[用户名错误，返回期望响应内容]，如果所有API的响应结果中都需要重复写是相当繁琐的，作为共同配置调用即可。
(点击放大图像)


√ 应用场景

提速：研发测试流程改进

(点击放大图像)

image

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

总结

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

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

上一篇 下一篇

猜你喜欢

热点阅读