前言
换工作后，还是接手了接口自动化的项目，比之前用的更加深入，同时也学习到了很多新的知识。对此想记录下，自己的思考。
接口自动化要做什么?
简而言之就是，对接口做一些测试，把接口当做黑盒进行输出、输出。当然接口内部的逻辑处理也需要考虑到。整体还是以功能测试为主。
接口自动化的用例设计
之前我使用的是HttpRunner框架，作者对用例结构有很清晰的定义。具体可以参考：HttpRunner 的测试用例分层机制 (适用于 2.X)
我目前的项目，接口是对外提供的，耦合性较高，并且安全性有比较高的需求，对此接口测试用例，我分为几个模块。
单接口正常
对接口第一步调试并且正常，这样的接口就属于单接口正常了，如果是一个模块并且具有以下接口，登入——》查询——》修改——》删除，这么一个系列组合就可以封装为一条测试用例，如果有几个这样的模块，那么可以把这些模块封装为一整个测试用例集，作为基础的冒烟测试，这样的冒烟，也可以算是一个小场景了。
通用断言
在很多大型系统中，因为有鉴权相关功能，很多接口都不会直接到达业务层，会在collect层中在封装一个通用鉴权模块来进行处理。
任何请求都会经过它的逻辑处理，只有它通过了才会下流到业务层，因此我们的接口也需要验证这个功能点，由于所有的接口都要处理这样的逻辑，索性对此进行封装，通过循环读取csv中的数据，根据附带的参数不一样，做不同的预期结果断言。例如sign，sign_time,appid等等，若接口无此参数，会直接跳过业务层，返回对应错误码。
单接口异常
接口异常场景比较多，对此进行细化，主要验证，输入和输出，考量参数的限制，边界，等价，默认，特殊，敏感，对此又可以在细分是数组，还是字符串
场景用例
场景的根本是依赖于用例的原子性，小场景就是小用例，应该单独可以存在并且运行，多个用例可以组成测试用例集，互补干扰，可以运行。
场景用例会有较多依赖情况，一般如果自动化做的好，建议通过接口来创造需要的数据，如果需要数据量特别大，通过接口创建不友好并且繁琐，也可以通过数据库批量生成。
目前的疑惑
接口自动化用例的管理，随着项目接口的增多，相关用例也同步增多，这就会让我想到，规模庞大RF用例的历史，那基本上维护不了了。
还有就是，接口用例，需要写多细，单接口异常情况的覆盖度需要达到多少，很多接口可能在设计之初就不完善，对输入没有定义好，或者说，当前框架流行，Spring的很多的注解，可能也会对参数做很多限制。而接口测试人员，看不到代码，设计了很多用例，其实是无用功。所有，异常的考虑面在什么点。
场景接口测试用例，怎么编写，期望是手工业务人员来进行编写，问题，手工业务人员，对接口是否了解，是否有时间来完成。编写完成后的维护工作怎么展开。如果又接口人员编写，那么业务熟悉度，可能不够。
我的想法
建议从大局观，考虑，不再区分，手工测试和接口测试人员，组成一个整体。
手工人员提供业务场景，接口测试人员，提供对应的接口测试用例，共同维护。
若接口测试用例，可以提高手工业务人员效率，那么手工业务人员会有兴趣学习对自己有用的东西。进而提升用例的维护性。
同时接口测试人员，学习到了业务，并且等到认可，会更有冲劲。方便设计更加完善的用例，对整体的覆盖度会有较大的提升。
异常场景的细分，根据真实项目情况而定，时间短就覆盖关键点。有足够时间，可以再细化。异常的用例，要保证，编写后，尽量不需要改动。可以持续稳定的跑。目前只关注输入/输出就可以了。
