接口自动化的内容写了很多了，本来以为没什么东西再聊。这两天和两个不同团队的测试负责人交流，发现大家对于接口自动化的落地还是很多疑问，接口自动化到底能不能在短期内帮助到团队呢？
它不是救命稻草
自动化并不是提升效率的万能药。很多团队开展接口自动化的初衷或者说期待是降本增效，这是没错的，但都忽略了一件事，那就是接口自动化的前期投入。接口自动化的效率提升，是需要在更长时间维度上体现的（个人认为这个接口自动化要能真实地产生效益，至少要有 3 个月的前期投入）。
如果你的团队现状是时间紧、任务重，但是项目的周期只有几个月，或者半年，那就堆人吧，搞什么自动化。引入接口自动化，所产生的效益在前期基本上是看不到的。你还要花费额外的人力去做场景梳理和脚本维护。
所以，接口自动化并不是紧急项目的救命稻草，特别是没有规范化的接口管理之前。
接口自动化的前期投入
对于想要开展接口自动化的团队，在真正落地到工具上之前，至少需要完成以下几个步骤：场景梳理、接口核对、用例编写、执行验证、扩大范围。
场景梳理：首先要花时间和精力去梳理哪些场景适合做接口自动化，核心场景、高频场景还是利益相关的场景，需要有人去梳理出完整的业务流程。在存量系统中，做单接口的测试意义不大，必须以场景用例为主。
接口核对：根据梳理出来的场景，和开发确认涉及的接口和参数。这是工作量最大、难度最高的投入。如果有规范化的接口文档，还好些，如果没有这类规范化的基础，仅通过抓包来分析，那投入的时间就更大了。
用例编写：基于前面两步，选择合适的工具反而是最简单的事了，现在不论是工具还是平台，对于接口测试的支持都非常友好，可供选择的范围也很多。
执行验证：先选 1～2 个场景，把脚本写好（前期可以不考虑过多的封装和规范），然后 Run 起来，看看场景和数据是否能够跑顺，跑通，数据是否真实落到系统当中去，当系统异常时，是否能发现问题。最常见的做法是：收回某些用户权限，或者删除某些关键数据，用例要能正常发现这些问题（所谓的用例有效性验证，只有这样，用例才是有效的。没有合适断言的自动化用例，没有任何意义）。
扩大范围：当前面的步骤都完成并验证可行后（看看这些前期的投入），再分场景或者模块给不同的人，把量补上来。
这里面的核心，还是对接口本身的了解程度，哪些场景会涉及哪些接口？这些接口参数的意义和来源是什么，要梳理清楚。而大部分团队其实是没有这部分能力的。盲目地开展接口自动化，只会流于形式。
作为团队的管理者，需要对接口自动化的投入成本和效果有比较好的认知，知道开展接口自动化需要准备些什么，能有什么收益。如果只是跟风开展，盲目追求覆盖率，认为有了接口自动化就能在短期内提升效率，那么大概率是做不好的。
技术没有捷径，技术也有成本。
那么，在接口自动化的前期投入中，如何向上汇报成果呢？个人认为，最有价值的一点，就是通过梳理场景和接口，你会对业务和被测系统有更深入的了解，能够发现很多功能用例没有覆盖到的场景，以及，在分析接口的过程中，发现哪些不合理的接口设计，非常好玩，相信我。
共勉。
接口相关的文章，统一整理如下：
通过抓包能否做好接口测试
你是这么写接口的么
接口测试这么玩才明白
接口测试断言
你写的接口脚本合理么
接口测试平台演进思考