1. 接口测试用例设计的整体思路与价值定位

1.1 为什么接口层测试优先级最高

做了这么多年测试，我一直有一个很朴素的观点：如果团队只能保留一种自动化测试，我一定会保留接口测试。原因很简单，服务端接口测试直接对着业务逻辑打，它的反馈速度、稳定性和定位效率，都远胜于UI层面的黑盒点击。你在页面上折腾半天发现的问题，大概率在接口层用几个请求就能复现；而接口层暴露的问题，往往也是下游页面报错的根源。

接口测试用例设计这件事，说白了就是回答三个问题：这个接口正常工作时应该怎么表现？它被恶意或异常输入攻击时会不会崩？它跟其他接口联动时会不会因为数据状态不对而出错？把这三点想清楚了，用例基本就覆盖到位了。很多新手一上来就拿着Postman或Apifox对着接口文档逐个请求，能通就认为通过了，这其实只是“冒烟测试”的水平，根本谈不上“用例设计”。

真正的用例设计，要求测试人员对接口的输入、输出、状态变化、依赖关系都有清晰预期，然后把这些预期拆成可执行、可断言、可追踪的测试点。这里面既有工程方法，也有行业经验。我接下来的内容，会结合服务端接口测试的实际场景，把从读文档到写用例、从造数据到跑测试、从看结果到定位问题的完整链路都过一遍，争取让刚入行的同学能直接照着做，也让有一定经验的同行能补上一些容易忽略的盲区。

1.2 用例设计前必须搞清楚的三件事

我在带新人时，发现大家在接口测试上踩坑，大概率不是因为不会用工具，而是因为没想清楚就开始写用例。所以在动手之前，有三件事必须先搞清楚。

第一，被测接口的业务定位。这个接口是查询、新增、修改还是删除？它属于哪个业务域？上游是谁在调用它，下游它又依赖谁？比如一个“创建订单”接口，它不只是接收参数然后插一条记录那么简单，它可能还要调用库存服务、优惠券服务、支付网关。你对业务理解得越深，越能在用例里设计出有业务含义的边界条件，而不是单纯地测“参数传错了会报什么错”。

第二，接口的契约定义。请求方法、URL、请求头、参数名、参数类型、是否必填、默认值、枚举范围、返回结构、错误码约定，这些内容全部来自接口文档。没有文档的接口，我会建议先通过抓包或让开发帮忙生成Swagger/OpenAPI文档，把契约固定下来再设计用例。契约不清的情况下写的用例，很容易随着代码调整而批量失效。

第三，测试环境的可用性和数据现状。你设计的用例再好，环境里没有对应的测试数据，一样白搭。比如要测“订单已支付状态下再次支付应该被拒绝”，你就得先有一条已支付状态的订单。环境里有没有？能不能通过接口或数据库脚本快速造出来？这些问题在用例设计阶段就要评估，否则执行阶段会卡壳。

这三件事想明白了，才开始写第一条用例。否则写出来的用例要么是重复劳动，要么是自嗨，根本覆盖不到真实风险。

2. 接口测试用例设计的核心步骤拆解

2.1 第一步：接口文档解读与信息梳理

接口文档是测试用例的“需求规格说明书”，读文档的能力直接决定用例质量。我通常会把文档信息拆成几个维度逐个确认，并且整理成一张接口信息卡片，方便后续引用。

首先是协议层面的信息：接口的路径、请求方法（GET/POST/PUT/DELETE等）、请求协议（HTTP/HTTPS）、是否需要鉴权。这些看似基础，但经常有人忽略。比如一个接口在文档里声称是HTTPS，结果测试环境部署的是HTTP网关，你拿HTTPS去请求，直接连接失败，这时候不是用例的问题，是环境梳理不到位。

其次是参数层面的信息，这是用例设计的重头戏。每一个参数，都要确认四类属性：

最后是响应层面的信息：成功时返回什么结构、失败时返回什么错误码和提示信息、有没有分页结构、有没有嵌套对象。如果文档里没有明确错误码列表，我会直接找开发要，或者在测试环境里故意触发错误观察返回。错误码的梳理对断言设计至关重要，很多初学者只会断言“HTTP 200”，完全不看业务码，结果漏掉了大量逻辑错误。

2.2 第二步：正常场景用例先行，先把主流程跑通

很多人写接口用例喜欢先从异常场景写起，觉得“能想到什么错就测什么错”，这样其实容易把主流程漏掉。我的习惯是先写正常场景，也就是“用户按预期使用这个接口”的用例，目的是确认接口的核心功能是通的。

正常场景用例至少要覆盖三层：

第一层，最简正例。用最少且合法的参数调用接口，验证接口能成功返回预期结果。比如一个创建用户的接口，只传username和password，看能否返回创建成功。这个用例的价值是验证接口的“最小可用路径”，一旦失败说明接口本身存在阻断性问题。

第二层，完整正例。补齐所有必填参数和合理的可选参数，验证接口在接收到完整数据时能正确处理。比如创建用户时，除了必填项，再加上email、phone、avatar等可选字段，确认这些字段能被正确保存和返回。这一层验证的是接口对完整业务数据的处理能力。

第三层，业务分支正例。如果接口内部有状态或分支逻辑，逐一覆盖这些分支的正常走向。比如支付接口有“余额支付成功”“优惠券抵扣成功”“组合支付成功”等多个正常分支，每个分支都要有对应的正例。这个层次最考验业务理解，也是用例价值跃升的关键。

正常场景写完后，应该形成一条可以反复回归的“冒烟集”。在每次版本迭代后，先用这个集合快速验证接口没被改坏，再深挖其余用例。我在实际工作中，冒烟集跑完大约只需要一两分钟，但能拦截掉七八成的低级回归问题。

2.3 第三步：异常与边界场景，接口测试的含金量所在

正常场景只能证明“接口在正常情况下能用”，而异常和边界用例才是接口测试最能体现价值的地方。因为线上生产事故，绝大多数不是正常路径出错，而是在边界条件、异常输入、非法操作下暴露的。

异常场景我习惯分成三类来设计：

第一类，参数异常。包括缺参、多参、参数类型错误、参数格式非法、参数超过长度上限、枚举值不在范围内。每一类都可以为每个关键参数组合出一条用例。比如一个“查询订单列表”的接口，pageSize参数限制是1到100，那就要分别测pageSize=0、pageSize=101、pageSize=-1、pageSize="abc"、pageSize不传这几种情况。很多后端框架对参数校验不严格，传负数可能直接导致SQL层异常，这类问题只有用例设计到才能发现。

第二类，数据状态异常。接口处理数据时依赖前置状态，状态不对就会出错。比如“取消订单”接口，订单可能处于待支付、已支付、已发货、已完成、已取消等状态，取消逻辑对每种状态的处理可能完全不同。你至少要设计“对已取消订单再次取消”“对已完成订单取消”“对已发货订单取消”这几种用例，验证接口是否给出了合理的提示或处理，而不是直接报500。

第三类，依赖服务异常。接口依赖的外部服务，比如数据库、缓存、消息队列、第三方接口，发生超时或不可用时，被测接口应该表现为优雅降级。这类用例做起来成本较高，通常需要配合故障注入或Mock工具，但至少要有意识地覆盖。比如把下游服务停掉，看接口是返回“服务繁忙”还是直接抛出一个连用户都看不懂的堆栈。

边界用例则要结合具体的约束条件来设计。数学上的边界就是最小值、最小值相邻值、正常值、最大值相邻值、最大值。比如一个参数限定长度1到32，那就要测长度为0、1、2、31、32、33这几种情况。别小看这些细节，我曾经就因为一个长度限制的边界没测，导致用户在输入32个字符的昵称时数据库报错，线上case炸了一晚上。

2.4 从需求出发梳理业务场景用例

除了接口本身的输入输出，我还会专门花时间梳理业务场景用例。什么叫业务场景用例？就是站在用户真实操作链路的角度，把多个接口串起来，验证整条业务链路的数据流转是否正确。

最典型的就是“下单支付”链路：创建订单 → 支付订单 → 查询订单 → 取消订单。单看每个接口可能都没问题，但串起来后经常暴露两类问题：一是数据传递不一致，比如创建订单返回的orderId，在支付时被透传或者被截断；二是在特定状态下调用不该调的接口，比如订单已经关闭了还要支付。这类问题不设计串联用例，几乎无法靠单接口测试发现。

设计业务场景用例时，我会画一张简单的状态流转图（用文字列出来即可），把每个业务对象的关键状态列清楚，再针对状态之间的合法跳转和非法跳转分别设计用例。比如订单状态机可能是：待支付 → 已支付 → 已发货 → 已完成，同时待支付可以跳转到已取消。那么“已取消 → 已支付”就是非法跳转，必须设计用例验证接口能拦住。

业务场景用例还有一个额外的好处：它是后续做端到端测试和自动化回归的基础。把这些场景用脚本固化下来，每次发版跑一遍，比UI自动化稳定得多，维护成本也低得多。

3. 关键维度与经典用例设计技巧

3.1 参数维度：必填、类型、长度、枚举一个都不能少

参数维度是接口用例设计最基本也最容易量化的部分。我把参数相关的检查点总结成这样几个方向，大家可以直接照着套。

必填项检查：文档标注为必填的参数，用例里要覆盖“不传”“传null”“传空字符串”三种情况。这里要特别提醒，很多后端框架对“不传”和“传null”是区分处理的，一个是参数缺失，一个是参数存在但值为空，业务代码的校验逻辑可能完全不同。所以这三类输入要分别设计用例，不要合并成一条。

类型检查：参数声明的类型是number，就传字符串"123"试试；声明是boolean，就传"true"或1试试。很多弱类型语言的后端接口，前端传JSON时经常出现类型漂移，后端如果做宽松转换可能没事，但严谨的接口应该能识别非法类型并给出明确错误码。

长度检查：字符串类型参数要覆盖最小长度、最大长度、超长、包含中英文混合字符等情况。数字类型参数要覆盖最小值、最大值、负数、小数、科学计数法等情况。数组类型参数则要看接口是支持单个元素还是多个元素，传空数组、超大数组、嵌套数组分别是什么结果。

枚举检查：参数定义了枚举值（如status: open/closed/pending），就分别测每个合法枚举值，再测一个不在枚举范围内的值。合法的枚举值之间往往对应不同的业务分支，跑一遍等于把分支逻辑也覆盖了。

格式检查：参数要求是邮箱、手机号、IP、日期等特定格式时，要测格式完全正确的值、格式部分错误的值、格式完全错误的值。比如日期参数，你是"2024-06-01"传，还是"2024/06/01"传，还是时间戳传，接口识不识别？这些细节非常容易踩雷。

组合参数检查：有些参数的合法性是依赖其他参数的。比如分页接口，page和pageSize单独都对，但page=9999且pageSize=100时，可能触发深分页性能问题。再比如经纬度参数，经度范围-180到180，纬度范围-90到90，必须同时校验，只校验其中一个就会出现“经纬度不合法但接口返回成功”的尴尬。

3.2 业务规则维度：状态机、依赖关系与并发控制

参数维度解决的是“接口会不会报错”的问题，业务规则维度解决的是“接口的逻辑对不对”的问题。后者更难设计，也更容易暴露严重缺陷。

状态机校验是最经典的一种。一个业务对象在生命周期内有多个状态，状态的流转往往有严格限制。设计用例时，要把每个状态的合法来源和非法来源都覆盖到。

依赖关系校验是另一重点。接口之间经常有数据依赖，比如先创建用户才能登录，先创建商品才能下单。设计用例时要考虑：前置数据不存在时调用后续接口，会得到什么结果？前置数据处于中间状态时调用后续接口，会被正确处理吗？我曾经测过一个“获取用户钱包余额”的接口，用户不存在时它返回的是一个空账号信息而不是404，这在业务上可能没问题，但如果调用方拿这个空数据继续做金额运算，就会产生脏数据。

并发与幂等校验同样不能忽略。支付、转账、库存扣减这类涉及资金和数量的接口，并发场景下容易出现重复扣款、超卖等问题。测试时可以借助JMeter或自写脚本并发请求接口，观察结果是否出现异常。幂等性测试则要关注：同一个orderId在支付接口上重复提交两次，第二次是被幂等拦截还是又扣了一次款？请求中带了幂等键（如Idempotency-Key）时，重复提交是否会返回第一次的结果？这些用例对业务的价值极高，但很多人因为“要搭并发环境太麻烦”就跳过了。

3.3 安全与权限维度：鉴权、越权与敏感信息

接口测试如果不涉及安全和权限，那覆盖度一定是有缺失的。尤其是管理后台类的服务端接口，越权问题是最常见的高危缺陷。

鉴权用例主要覆盖三类情况。一是未携带任何鉴权信息（无token、无cookie、无签名）调用接口，预期应返回401或明确提示。二是携带无效或过期的鉴权信息调用接口，预期应被拒绝。三是鉴权信息正确时才能访问，这其实在上面的正例里已经覆盖了。

越权用例是重点中的重点。垂直越权指低权限用户尝试访问高权限功能，比如普通用户调用了只有管理员才能用的“删除用户”接口。水平越权指同权限用户尝试访问其他用户的数据，比如通过修改URL中的userId参数，查看不属于自己的订单详情。这类用例的设计方法是：准备两个不同用户（A和B）的数据，用A的token去操作B的资源，看接口是否校验了资源归属。

除了越权，敏感信息泄露也要测。比如登录接口返回的响应里是否包含明文密码、查询接口是否返回了不该返回的字段（如身份证号、银行卡号）、日志层面是否打印了敏感参数。这些问题自动化用例不一定能全查出来，但至少要在返回结构断言里加上关键字检查，比如用正则去匹配是否有"password"、"idcard"这类字段名。

签名与加密校验也要考虑。有些接口带了时间戳签名（如sign = md5(params + secret)），用例要覆盖签名缺失、签名错误、签名正确但时间戳过期等情况。这是很多金融类、支付类接口的高频风险点，设计用例时提前规划好，后面执行会顺很多。

3.4 用“测试金字塔”调整用例投入比例

谈完了各种维度，我发现很多人容易犯一个毛病：恨不得每个接口都写几百条用例，结果时间全耗在测试本身了。这里分享一个投入比例的经验供参考。

我一般把用例按优先级分为三层：P0级是核心主流程和关键异常，占到用例总量的15%左右，必须在每次回归中全量执行；P1级是重要业务规则、边界值和权限用例，占到35%左右，在版本变更涉及相关模块时必须执行；P2级是低频场景、极端边界和性能相关的用例，占到50%左右，在发版前的大回归里执行。

这个比例的思路就是：把有限的测试资源优先投到最容易出大事的地方。接口测试不是用例数量越多越好，而是覆盖风险密度越高越好。一条精心设计的P0用例，价值可能超过一百条流水账式P2用例。所以我的建议是，先把P0和P1的用例设计扎实，再有余力时逐步扩充P2，而不是一上来就把所有方向都平摊精力。

4. 从用例到执行：工具链与数据准备

4.1 用例表达形式：表格、代码还是平台

用例设计完了，总要有个落地的载体。目前业界常见的表达形式有三种：表格、代码脚本、测试平台，各有各的适用场景。

表格形式是传统测试用例管理的标准做法，字段一般包含用例编号、所属模块、用例标题、前置条件、测试步骤、测试数据、预期结果、实际结果、优先级。它的优点是可读性强，方便评审和归档；缺点是执行效率低，需要人工一步步操作。适合项目早期、用例量小、团队还没建设自动化能力的阶段。

代码脚本形式是把用例直接用编程语言写出来，比如Python + Requests + Pytest。每条用例就是一个测试函数，断言语义清晰，可以和CI流水线集成，实现提交代码后自动跑接口测试。它的优点是执行效率高、回归方便；缺点是对编写者有技术要求，前期开发成本高。适合用例量已经稳定、团队有自动化建设需求的阶段。

测试平台形式是使用Apifox、Postman、JMeter这类工具或自建的测试平台来管理和执行用例。以Apifox为例，它把接口文档、调试、用例、断言、环境管理集中在一起，还支持“一键导入接口文档生成基础用例”，这对快速起步非常友好。Postman的优势是生态成熟、社区教程多、Collection Runner和Newman可以做简单的命令行回归。JMeter则强在并发和性能测试，如果你的接口测试需要兼顾压力场景，JMeter是绕不开的选择。

我的实际经验是：项目早期用表格厘清思路，中期用Apifox或Postman先跑起来，后期沉淀代码脚本进持续集成。表格是思考工具，工具是执行手段，代码是最终沉淀，三者并不是非此即彼。

4.2 测试数据准备技巧：环境隔离与造数策略

接口测试数据准备是执行环节最容易卡壳的地方。很多用例写得好好的，执行时发现“没有满足前置条件的数据”，只能临时去库里改，或者让开发帮忙造数，效率极低。

我的建议是建立一套“造数即服务”的机制。具体来说：

第一，明确测试环境的初始化规则。每个环境（dev、test、staging）的数据要保持相对独立，避免互相污染。我在实际工作中见过最惨痛的教训是，测试环境的订单数据被自动化脚本反复修改，导致其他同事手工测试时看到的永远是一堆脏数据。后来我们定了规矩：自动化执行前先跑一遍环境初始化脚本，把关键业务数据重置到基线状态。

第二，对于复杂的前置数据，优先通过接口来造。比如测“取消订单”的异常场景，需要一条已支付状态的订单，那就先调用创建订单接口，再调用支付接口，把状态推进到已支付。这种造数方式能顺带验证前置接口的可用性，一举两得。如果接口链路太长、太重，再考虑直接在数据库里插入或修改记录。直接操作数据库要格外小心，尤其是外键关系和业务状态字段，改坏了会影响后续整条链路。

第三，参数化数据要固化下来。把常用的用户、商品、订单、优惠券等测试数据整理成数据字典，在用例文档里注明ID和用途。比如“TEST_USER_A：用于水平越权用例，密码为Test@123”。这样团队里的任何一个人拿到用例集，都能快速定位数据，不会重复造车。

第四，注意数据的时序性和隔离性。例如测试并发扣库存时，要确保每次用例执行前库存量是可预期的；测试用户登录时，要避免因为上一次用例修改了密码而引发“账号被锁定”之类的前置错误。我一般在自动化脚本的setup和teardown阶段会做数据清理或重置，保证每条用例之间的独立性。

4.3 环境与依赖管理：别让环境问题淹没用例问题

执行接口测试时，最让人头疼的往往不是用例本身，而是环境问题。“服务没起”“数据库连不上”“依赖接口超时”“配置项不对”，这些环境问题会直接导致用例执行失败，而且失败信息里你根本看不出是代码的bug还是环境的问题。

为了区分这两类失败，我会做三件事。第一，在用例执行前跑一遍“环境预检脚本”，检查被测服务是否可用、依赖的数据库和Redis是否正常、关键配置项是否符合预期。预检通过后再执行用例集，这样一旦有失败，大概率是代码或数据问题。第二，在断言里区分“请求失败”和“响应不符合预期”。前者通常是网络或环境问题，后者才是真正的用例失败。我在代码里会专门封装这两个分支，日志分开打印，统计也分开统计。第三，环境配置统一管理。比如Apifox里的环境变量、Postman的Environment、JMeter的配置文件，把host、端口、账号、密钥这些信息集中管理，避免每个用例里写死，否则环境切换时改起来会想哭。

还有一个很容易被忽略的点：缓存和状态共享。有些服务端接口的结果会被缓存，比如查询类接口配了Redis缓存，第一次请求和后端交互，第二次直接返回缓存。这种情况下，你连续跑同一条用例可能得到不同结果，容易误判。设计用例时如果知道接口有缓存，要么在setup阶段清理缓存，要么把断言设计成能容忍“缓存与实时数据一致”。

4.4 断言设计：只断言HTTP状态码等于没测

我在看很多团队的接口用例时，发现断言写得极其单薄，最常见的就是“断言HTTP 200”。这几乎等于没测。一个接口就算返回200，body里可能是一段错误提示、一个空对象、一条业务异常信息，甚至是一段HTML错误页。所以断言设计至少要覆盖三层。

第一层是协议层断言：HTTP状态码是否符合预期（200表示成功，4xx表示客户端错误，5xx表示服务端错误）。注意不是所有成功都是200，有些接口用201表示创建成功，204表示无内容返回，你要跟文档对齐。

第二层是业务层断言：响应JSON里的业务码、提示信息、关键字段是否符合预期。业务码是接口自定义的，比如code=0表示成功，code=10001表示参数错误。断言业务码比断言HTTP状态码精确得多，能直接定位到业务逻辑是否正确。关键字段的断言也很重要，比如创建用户接口的响应里要有userId，查询订单接口的响应里订单金额要与参数计算一致。

第三层是数据层断言：响应数据与数据库里的值是否一致、数据之间的关联关系是否正确。这一层需要连接数据库查询，做交叉校验。比如充值接口成功后，去数据库里查余额，确认是否真的加上了充值的金额。数据层断言成本高，但它是验证“接口是否真的做了正确的事”的最可靠手段。我在重要的资金、库存、状态类接口上一定会加这一层。

这里分享一个心得：断言不光是“验证预期”，更是“捕获意外”。除了断言期望值，我还会用反向断言，比如检查响应里不包含某个错误关键字、不包含敏感字段、不是空数据。这些反向断言常常能抓到一些意料之外的bug。

5. 常见问题与排查技巧实录

5.1 用例遗漏的典型场景盘点

接口测试用例设计最常见的失败模式不是用例写错了，而是用例漏了。我结合自己的踩坑经历，把几个高频遗漏场景整理成一张速查表，供大家自查。

这里要特别说一句，很多人只测了“文档里能看到的参数”，忽略了隐藏参数，比如请求头里的Content-Type、Accept、Authorization，或者POST body里的嵌套对象、数组元素。这些隐藏参数往往才是接口出错的根源。

5.2 断言陷阱与误判案例

执行接口测试时，最怕的不是失败，而是“假成功”——用例执行通过，但实际功能是错的。下面几个断言陷阱，我都在实际工作中碰到过。

第一个陷阱是“只看状态码不看响应体”。有一次我测一个删除接口，返回200，用例通过。后来偶然看了一眼响应体，发现里面是一段“系统繁忙”的错误提示。原因是网关层做了统一包装，即使业务处理失败，HTTP层还是返回200。从那以后，我所有用例的断言都以业务码为准。

第二个陷阱是“响应体里的字段名看错”。JSON里有个status字段，一个是业务状态，一个是HTTP对应的字段，混在一起就容易把"1"当成成功。建议做断言前，先抓一个真实响应，把字段结构彻底看清楚。

第三个陷阱是“断言写死在测试数据上”。比如断言返回的金额等于100元，但数据库里实际下了一个折扣或税后金额，导致结果漂移。正确做法是把预期值做成动态计算，而不是写死。

第四个陷阱是“把环境错误当成用例失败”。服务没启动、数据库连接超时、依赖接口无响应，这些情况用例执行会失败，但不是被测接口的问题。我现在养成了一个习惯：看到一条用例失败，先看日志判断是请求层失败还是断言失败，然后再决定要不要提单给开发。

5.3 定位bug的几条实战经验

接口测试的价值不只是“发现bug”，更是“快速定位bug”。下面几条经验是我自己反复用到的。

第一，善用抓包工具或代理。客户端请求发送后，先在代理层（比如Charles或Fiddler）看实际发出的请求报文，确认参数是否与设计一致。很多接口问题实际上是客户端传参错误，这点在前后端联调时尤其常见。

第二，把日志当作第一现场。服务端日志里记录了请求参数、业务处理过程、异常堆栈，出问题时第一时间让开发拉日志，你提供请求编号或时间点，开发就能很快定位到对应日志。在用例里主动打印请求流水号（如requestId、traceId），会让沟通效率高很多。

第三，复现问题要保留现场。用Postman或Apifox把失败的请求完整保存下来，包括headers、body、参数、时间戳，然后重新发一遍，确认是否稳定复现。能稳定复现的bug，开发排查起来非常快；偶发性bug则需要多跑几遍，记录出现的频次和条件。

第四，区分前端问题还是后端问题。这一点在联调阶段非常常见：一个接口的返回结果不对，前端说是后端出了问题，后端说是前端传参有问题。这时候最直接的方法就是绕过前端，直接用接口工具构造请求。如果接口工具构造的请求返回正确，说明是前端代码的问题；如果返回错误，说明是后端问题。这比两边争执扯皮高效得多。

5.4 接口测试用例设计的维护与演进

用例集不是一次性产物，随着接口迭代，用例也需要持续维护。否则用例就会跟代码脱节，跑起来一片红，最后大家干脆不看结果了，自动化测试形同虚设。

我的维护策略有三点。第一，用例与接口文档联动。接口文档更新时，同步检查受影响用例，能自动化的就通过脚本或平台关联，比如Apifox可以先同步文档再逐一标注受影响用例。第二，用例分级管理，定期清理。P0和P1用例重点维护，保证它们永远和当前版本的功能对齐；P2用例如果长期没有触发过失败，可以考虑合并或剔除。第三，把用例纳入评审流程。每次提测前，建议测试和开发一起过一遍新增用例，开发能从实现角度提示一些“容易被漏掉的边界”，测试则从用户角度补充“业务上常见的使用方式”。

关于后续扩展，我多说一句。接口自动化最适合演进的下一站，是把它和持续集成流水线绑起来，让每次代码合并后自动触发接口回归，并把结果推送到群里。再往后，可以结合流量录制和回放，把线上的真实请求转化为测试用例库，覆盖面会更贴近真实用户行为。这些进阶玩法我都尝试过，等以后有机会再单独开一篇讲。