可能有人会说，写接口的自动化CASE多简单了，写个参数发送请求完事了，还要注意啥？
没错，相比起UI自动化的case，你要去写各种定位器，接口自动化的case写起来确实容易多了。这也是接口自动化
的一个优点，开发效率更快。
但是写得快，不等于写得好，本章就聊聊接口自动化case的那些事。
一、case要易于阅读和维护
既然是写自动化case，那也是在写代码，那么，代码的可阅读性就不可以忽视。除了的代码规范，还要注意
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
这样写的话，是不是比较清晰呢？谁都能看懂你的代码，自己调试代码的时候读着也舒心。
二、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。
- 自己清楚表的逻辑关系最好，不清楚，请找对应的开发请教，并且记录下来。
- 通过页面或者接口手动创建数据，然后去数据库里追踪这条数据，通过数据库工具，复制出sql语句，然后针对性的改动即可。
