很多朋友在开始接触接口测试时，都会通过各类工具进行抓包，分析接口请求并开展接口测试。这是个不错的尝试，从个人的角度而言也没什么问题。但是如果是在实际的业务团队中，测试人员仅仅依赖抓包来开展接口测试，其实是非常不友好的。

01

从局限性的角度来看，没有接口文档，只通过抓包来做接口测试，会存在以下几个问题。

接口的完整性：通过页面操作，进行抓包，获取到的接口信息会有遗漏，最典型的就是登录接口的 302 重定向跳转，出于保护的目的，一些重要的核心接口，通常都会做重定向，导致通过抓包是无法获取到有效的接口信息，从而遗漏到部分接口。

如果直接请求/oauth/login，是无法实现登录的。

动态参数的识别：由于接口抓包抓到的请求信息都是处理好的静态数据，无法有效分辨哪些是动态参数（根据业务动态生成，比如订单号、密码、价格等），哪些是静态参数（下拉项、用户名、产地等），会导致接口重复发起时，由于数据问题引起失败。

参数名的可阅读性：对于有同样业务意义的参数，参数名可能不一样，比如用户账号，有时用 userId，有时用 username，有时用 userName，有时用 nickName，有时用 userNo，甚至每一个接口内都没统一。或者用一些不是很好理解的方式来命名，会对接口测试产生严重的影响。可参考：你是这么写接口的么

解决方案：在开展接口自动化测试前，需要和研发约定好必要的接口文档输出（最常见的就是引入 Swagger 框架，对接口文档进行实时维护），并做好相关的参数命名规范，这样才有可能让接口测试落到实处并产生价值。

02

从可维护性的角度来看，没有接口文档，只通过抓包来做接口测试，会存在以下几个问题。

接口覆盖率的统计：没有相关的接口文档，通过抓包，无法有效地得知接口的覆盖范围，也就无法针对性地作补充，容易引发接口测试遗漏。

接口变更的维护：如果接口发生变更，仅从抓包是无法感知到的。这样会引发接口失败的误报，让排查问题的工作大大增加，也会让测试人员慢慢失去信心。

标准化内容的复用：通过抓包获取到的接口信息，导入到接口测试工具后（如此 PostMan 或者 Jmeter），修改参数直接回放，那么就无法抽取共性的接口，也无法根据业务场景重新编排接口，从而导致接口用例无法复用。

解决方案：在有了接口文档的前提下，我们需要从接口文档中提取有用的信息，从而更好的设计接口用例，比如哪些值需要参数化，哪些返回值可以用于断言的验证等，同时，通过接口文档的定期 Diff，可以尽早地发现接口变更，针对性地做验证。

03

在实际的团队落地中，接口测试要想做得好，标准化的接口文档是必备之物，只有标准化后，才有可能自动化，很多测试负责人仅从测试的角度发出，通过一些取巧的方式来实现接口自动化（比如通过 Curl 或者录制 har 文件，来实现接口测试），虽然能在短期内看似落地了接口自动化，但是缺乏对接口的理解，是无法长期执行并产生效果的。可参考：接口测试这么玩才明白

技术的落地都需要有前置条件，特别是测试作为研发链路的后期活动，不论是业务测试还是自动化测试，都需要依赖前面活动的规范化和标准化。才有可能事半功倍。尝试去推动上游的标准化，是测试负责人必备的能力，否则，很多测试活动都会受阻。

共勉。