【接口自动化】写接口自动化case要注意的点!

发布时间:2024年01月04日

可能有人会说,写接口的自动化CASE多简单了,写个参数发送请求完事了,还要注意啥?

没错,相比起UI自动化的case,你要去写各种定位器,接口自动化的case写起来确实容易多了。这也是接口自动化的一个优点,开发效率更快。

但是写得快,不等于写得好,本章就聊聊接口自动化case的那些事。

一、case要易于阅读和维护

既然是写自动化case,那也是在写代码,那么,代码的可阅读性就不可以忽视。除了python的代码规范,还要注意case的结构,能让人一目了然。

其实跟我们手动用postman测试接口差不多,把每一步的事情写写清楚就好。
那测试接口通常有三个步骤:

  1. 传入请求参数
  2. 发送请求到接口
  3. 判断接口返回的结果是否符合预期

这样一来,我们在接口的自动化case中也分三步走。

def test_query_activity_manual(init_activitiy_manual, del_activity):
    '''查询可参与的活动-手动开奖'''
    payload = {
        "winWay":0
    }

    r = requests.get(activity_url, params=payload, headers=HEADER)
    result = r.json()

    assert result["status"] == 0
    assert result["data"]["content"][-1]["id"] == 10087
    assert result["data"]["content"][-1]["winWay"] == 0

这样写的话,是不是比较清晰呢?谁都能看懂你的代码,自己调试代码的时候读着也舒心。

现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:691998057【暗号:csdn999】

二、case的稳定性

1、为什么有人写的case经常报错

比起上面说的易于阅读维护,自动化case的稳定性才是最重要的。如果写的测试case跑起来总是不稳定,容易报错,那么接口自动化这个事情就做的没什么意义了,使用的人也会对你的框架失去信任。

我相信,大家在写完一个case的时候一定是调试通过的,那么为什么这个case当时能跑,过几天就跑不了呢?在我观察下来,很多时间都是由于“测试数据”引起的。

自动化case依赖的测试数据不稳定,或许你的测试数据被别人无意中删掉了,又或者你别的case产生的测试数据影响到了你这条case的测试数据等等,都是比较常见的原因。

我在工作中发现有的人喜欢调用接口来生成自己想要的测试数据,就是说依赖另一个接口来产生测试数据。这种方式有着一个很吸引人的优点,那就是你不用去深入了解被测接口的上下游数据关系,反正调用接口后,系统逻辑会去生成对应的数据。没错,这一点很诱人,但是当这个产生数据的接口挂了,或者返回了错误数据时,你的case必然就会受到影响了。

另外,还有的人喜欢用上一个case产生的数据来给下一个case用,这同样的道理,上一个接口要是报错了,下一个也必然收到影响,但是你能说受到影响的case没跑成功是因为接口本身有bug吗?很显然不能。

2、釜底抽薪,sql生成测试数据

说白了,上述2种情况都是由于生成测试数据的方式不稳定,会产生误伤。那么我是怎么应对的呢?

思路很简单,我直接用sql在测试环境里生成我要的测试数据,用完再删掉不就好了。在工作中,我也确实是这样做的,效果很稳。

另外,最近在解读pytest官方文档中的fixture模块,深深感受到了fixture功能的强大,设计的巧妙。而且人家也强调了,要保持测试case所处环境的干净。

所以,我的case编写原则就是:任意一个case,任何时候都可以运行,不受其他case的影响。

我通常把单个接口的case放在一个模块里。比如说,有6个接口,我就会写6个模块,每个模块里有着对于这个接口的所有场景的测试,像参数校验、不同传参导致不同结果的场景(数据驱动)等。

对于这个6个接口的业务流测试,我会单独的放一个模块里,在这个模块里,就只测业务流,证明他们几个的业务逻辑是没问题的,不会再去关注其中单个接口的其他场景的测试。在业务流测试里,case之间的测试数据是要传递使用的。

3、上述2种方式的优缺点

姑且按照顺序,把上面2种方式称为方式1、方式2吧,其中方式2是我喜欢的方式。

先说方式1的优缺点:

  • 优点:测试人员不需要关注数据库层相关的逻辑关系,简单省事。
  • 缺点:过于依赖其他创建数据的接口,只要依赖接口有问题,case必然受影响。

再说方式2的:

  • 优点:不受其他接口的影响,直接在数据库插入测试数据,用完即删,保证测试环境的干净,测试数据不会影响到其他case。
  • 缺点:测试人员需要清楚业务逻辑背后涉及到的表关系,因为很多接口涉及到的不止一张表,比较麻烦。

其实方式2的缺点比起方式1 ,我觉得也不能算严格意义的缺点吧,虽然你了解表之间关系以及写sql麻烦了点,但是也是加深了你对业务的理解,最重要的是case稳定了,这样的接口自动化才有意义。

三、个人的一点实操分享

或许有人会认同我的方式了,但是又担心自己写sql写不好,万一出错咋整?

对此,没啥好办法,只能保证都是正确的了。这里有2个建议,可以帮助你去写好sql。

  1. 自己清楚表的逻辑关系最好,不清楚,请找对应的开发请教,并且记录下来。
  2. 通过页面或者接口手动创建数据,然后去数据库里追踪这条数据,通过数据库工具,复制出sql语句,然后针对性的改动即可。

END今天的分享就到此结束了!点赞关注不迷路!

文章来源:https://blog.csdn.net/qq_43371695/article/details/135386366
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。