接口测试 各位大佬，接口测试是否要尽量覆盖所有业务呢？
我们目前做的接口基本都是单接口测试，没有根据业务场景来做，因为如果那样接口测试就会变的复杂，维护成本也会变的很高。在很多公司做接口测试的基本就 1 个人，大批量的业务用例转换成接口用例显得有些吃力。但一直单接口的话也显得有些单薄。不知各位大佬平时都是怎么做接口测试的。希望可以指点一二。
目前有将近 100 个接口，我把接口和接口需要的数据（如：参数或 body）都写在 excel 里了，执行的时候依次读取执行，当然这 excel 中也有先后顺序之分并且后一条也会用到前一条返回的数据。
我是写成自动化脚本
可以找一些 T0 级别的场景做一些冒烟 和 CI 挂钩，每次版本构建直接跑一次作为版本构建是否成功的标准
单接口测试说实话意义不大 1.无法覆盖真实业务 2.数据 hardcode，如果数据要动态，其实就是已经实现业务场景了
1、单接口测试，很难发现上下游关联问题，覆盖业务流程很有必要
2、重复性工作，考虑自动化，现在不掌握点接口自动化，很容易被汰换
换个角度，各种业务场景，还是由各种接口、异步消息、定时 worker 等组成的，最终还是会落到某个具体的方法上，那么你接口覆盖的情况足够多，场景还怕没覆盖完么～（当然异步消息你的自动化需要自己来生成这个消息来验证）
看哪种接口，原子化接口其实没啥业务可言。
可以通过集成测试来覆盖业务。
接口测试一般来说会有以下几个针对性的目的，要看题主的目的是什么了。
1.接口通，一般指的是 http 请求返回 200，可以代表系统已经正常运行了
2.接口的要求字段填写了正确/错误数据，返回了期望的结果，代表接口实现了预期的业务功能
3.接口的字段增加或缺失，程序正常响应了 (比如返回错误代码和错误信息，内容为 xxx 字段必填等)，并且不影响下次请求，代表接口的数据检查&校验是生效的
等等
主要看测试的目的了，不同的目的有不同的测试策略和方法。
接口测试可以尝试一下 fit2cloud 的 metersphere https://www.fit2cloud.com/metersphere/index.html