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

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

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

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

一、case要易于阅读和维护

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

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

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

这样一来，我们在接口的自动化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吗？很显然不能。