接口测试 RobotFramework 接口测试实战落地

不声不响 · 2022年11月15日 · 最后由 空空 回复于 2022年11月18日 · 6020 次阅读

引言

目前我在负责一个 APP 的测试工作。在项目中使用 RobotFramework 作为工具搭建接口自动化框架,进行接口自动化的工作。
本文将从我个人对接口测试和自动化框架的理解以及RobotFramework 在实际项目中落地两个大方面进行讲解。

对接口测试的理解

浅谈接口自动化框架

可以实现接口测试的框架有很多,比如 Pytest,TestNG,RobotFramework 等等,今天就不过多展开对框架的对比了。但是想从公共的角度聊一聊,当你想使用一个工具搭建一套属于自己项目的框架,都应该包括一下几个组成部分

原创整理

这是一个大致通用的结构,想明白、设计好这几个组件之间的关系,那么不管咱们使用任何自动化框架都会很快上手。

浅谈接口测试用例设计思路

在做接口测试时,应该关注的角度有:功能,边界,性能。在设计接口测试用例时,可以从下方图示中根据项目的实际情况设计用例

原创整理

实战中接口用例编写

但是在项目的实际运行当中,把接口测试用例设计完备是我们的目标,但是项目中,是否有时间,是否有必要对每个接口都进行完备的编写,还需要根据实际情况酌情设计测试策略,根据我平时的工作经验,我把接口测试分为三个层面:

  • 1. 连通性验证层次:对接口能否调用通的验证,验证状态码(比如 200,500 等),对入参出参进行验证(如格式,边界等)
  • 2. 业务逻辑验证层次:在校验入参和出差的同时,结合实际的业务进行验证,会引入前提条件,从业务角度校验入参出参的正确性
  • 3. 场景验证层次:在验证逻辑层次的基础上,结合具体的业务场景,此时单个接口测试已经不够,需要多个接口进行配合,有逻辑的前后顺序

自动化测试的核心目的之一就是节省人力,从 2 和 3 的层面测试上,就已经可以覆盖功能测试点,节省人力测试的时间了。

RobotFramework 项目中的落地

在这一部分中,主要以几个关键环节做一个简单的扩展,希望对你能有些启发

文件目录设计

根据项目的实际情况,参考框架的组成部分,设计自动化框架的项目的目录结构

公共类库设计

根据项目的实际情况,设计一些公共方法。在我这个项目中,我着重处理的是对 Python Requests 类的封装。之所以封装 Requests,是为了实现我测试用例中想实现的一些公共的功能,举例说明一些想实现的能力:

登录后可以在后续的请求中复用 token

class CommonRequest:
    # 创建静态类,封装Requests
    def __init__(self):
        """基类初始化
        """
        self.headers = {
            "Content-Type": "application/json;charset=utf-8",
        }
        self.token = None        # 在后续新建的方法中获取token赋值
        self.username = None
        self.password = None

在其他封装的方法中,完善自己想要的功能,为了在用例中多角度去断言

以封装 Get 请求为例,将响应码和请求的响应时间封装到 body 里,用于断言

def get_request(self, url, params=None, headers=None, **kwargs):
    """封装get操作
    """
    try:
        response = requests.get(url=url, headers=self.headers, verify=False, **kwargs)
        content = json.loads(response.text)
        response_d = dict()
        response_d["code"] = response.status_code  # 将响应码返回到body中
        response_d["response_time"] = response.elapsed.total_seconds()  # 将响应时间返回到body中
    except Exception as e:
        raise Exception("Exception: {}".format(e))
    response_d["body"] = content

    return response_d

梳理配置文件关系

设计好配置文件的上下引用关系,可以大大提高接口项目的健壮性,拿接口地址为例,将环境信息不断抽层,最终实现只改动一个变量来匹配不同的环境

&{uat}        app_base_url=https://demo-api.com        app_h5_url=https://demo-h5.com
${app_url}        ${uat}[app_base_url]
${api_url}        ${app_url}/v1/demo/test

编写测试用例

上面的工作准备差不多后,就可以开始真正的测试用例编写了。你会发现,当你设计一个框架的时候,用例是最后编写的,准备工作就绪后,编写用例就变成了体力活。

Class_01_Demo用例
    #定义测试接口
    ${url}    Set Variable    ${api_url}
    #发送请求(此时的Get Request已经是封装后的了)
    ${response}    Get Request    ${url}
    #断言
    Should Be Equal As Strings    ${response["code"]}    200    #断言响应码应该是200
    Should Be True    ${response["response_time"]}<1             #断言响应时间小于1s

以上是一个很粗的落地过程,省略了很多通用步骤,将一些重要的环节拿出来做了阐述。如果是 RobotFramework 初学者可能看不懂上面的内容,上面的流程比较适用于在 RobotFramework 上摸爬滚打了一段时间的小伙伴,希望可以对你有些启发,也欢迎随时与我交流,共同进步!

本文原创,禁止转载!

本文参与了「TesterHome 技术征文」,欢迎正在阅读的你也加入

共收到 11 条回复 时间 点赞

mark 一下

tangoliver 回复

相互学习😊

homin 回复

是的,RobotFramework 是可以照顾到编码能力欠缺的同学,我的总结就是,这个框架适合水平有高有低的测试团队使用,这个角度挺好的

Jerry li 回复

对,可以照顾到编码能力欠缺的同学,在 ride 中把方法和类当作控件来使用,不然还是用 unittest、pytest 啥的舒服多

学习下落地实战,有点启发

homin 回复

你说的 gui 是指 ride 的吗? 我们是直接用代码的方式管理用例,没有用 ride.

homin 回复

看来兄台是真的被伤过,哈哈
确实,RobotFramework 的界面 RIDE 不是很好用,用例多了还有性能问题,所以我这平时都是直接使用 IDE pycharm 了。第二个兼容问题,确实也是一个问题,Python 版本,还有用到的类库的版本,需要有一个组合匹配,不能全用最新的,用起来会出问题。我这好在之前花过一些时间调试过,有一套相对稳定的版本对应关系,团队成员就都用一样的了

Jerry li 回复

嗯,RobotFramework 它是关键字驱动,可读性还是相对好一些。处理数据和根据实际业务测试,还是需要自定义 Python 类。其实,团队能力平均的话,使用 pytest 还是比较好的,脚本语言还是会更加灵活。我这团队不同人的能力是阶梯类型的,所以选择了 RobotFramework,懂代码多一些的人负责框架和类库的创建和维护,基础能力一般的,就写用例。

我们现在的 UI 自动化就是用的 robot framework,当时在调研做 api 自动化的时候也考虑过 robot framework,也做过一些 demo。
当时的考虑是我们的 api 测试涉及到大部分都是数据的处理,和 robot framework 擅长的 bdd 关系不大,反而各种数据处理是 robot framework 不擅长的。所以后来我们改用了 pytest 。

建议早点脱 RF 的坑,很多适配兼容问题,gui 界面可读性也差,脚本交接就会发现很多问题。

--------------------被 rf 伤害过的男人

不声不响 TesterHome 技术征文丨浅谈 接口测试 中提及了此贴 11月16日 08:36
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册