可能有人会说，写接口的自动化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"] == 0assert result["data"]["content"][-1]["id"] == 10087assert 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今天的分享就到此结束了！点赞关注不迷路！