近期在做接口自动化过程中，有个问题困惑了好久，感觉对接口进行封装没有必要，直接用数据驱动接口就行了啊,为什么要封装一下？封装完毕之后，做测试case的时候，还是需要手动输入各种测试数据，那数据驱动的意义又在哪里呢？难道还要专门为case写个数据驱动文件吗？两个文件一个驱动接口，一个驱动测试，会不会有点繁琐呢？
希望各位大佬有时间看看帮忙解个惑
举几个场景
- 接口的多个地方调用，比如三个用例都要调用列表查询功能，你每个用例中都去写一遍requests.get就很费劲，使用封装好的 departmens.list 就可以避免冗余和重复
- 一单接口变动，比如从xml变成了json，或者同时支持xml和json，或者请求参数发生了变化，所有这些变化都会被约束在po的内部，不会被反应到接口测试用例中
1 个赞
谢谢老师回复，关于第一个场景：接口多个地方调用，是要对多个接口进行集成测试吗？那如果单个接口测试的话，接口已经封装好了的情况下，测试是不是不准确？比如我封装的接口就规定了必须要传递一个参数值，在调用的时候，如果不传值，接口请求都发不出去，直接就报错，获取不到服务器的错误响应数据，如果对封装的接口的传参不进行规定，直接默认为**kwargs，那么数据驱动文件中只需要传递url和method,具体的参数还是要接口调用的时候进行传递，，数据驱动文件也就没什么意义了吧？
比如有个删除部门的功能，你删除后不能只是断言删除操作是否OK，还要校验list接口里对应的部门已经删除。同样添加部门也不能只是断言添加操作是否OK，还要断言的确多出来了一个部门。多数的接口测试都是多接口配合校验的。
封装的本质是跟设计模式类似的，就是明确变与不变的边界。比如一个测试用例如下
- 创建部门，名字为demo
- 校验部门列表包含新部门demo
这个里面包含了2步，测试数据是demo。那么你的测试用例和封装就应该只包含这几个变量。其他的要全部隐藏。比如是发get还是post，其实对测试步骤来说，并不重要，只是底层的一种实现方式。不变的是业务流程与测试数据，可能变化的、与具体实现绑定的流程就需要通过封装隐藏细节。
1 个赞
谢谢老师，我再好好想想