接口测试和功能测试的区别

刚接手测试任务的人常卡在同一件事上：需求里既有界面又有接口，到底该先测哪一层、测什么、留下什么证据。这篇不谈概念定义，只讲两者各自盯的目标、能覆盖到哪些问题、什么时候互相替代不了，最后给一张对照表和一份可照做的执行顺序。

刚接手测试任务的人常卡在同一件事上：需求里既有界面又有接口，到底该先测哪一层、该测什么、留下什么证据。这篇不谈概念定义，只讲两者各自盯的目标、能覆盖到哪些问题、什么时候互相替代不了。

判断自己该往哪边使劲，可以先问一句：这个验证点能不能脱离界面描述出来。能描述成「某个请求发出去、某个字段返回什么」的，更偏接口层；必须讲清用户点了哪里、看到什么的，更偏功能层。下面的对照和执行顺序都围绕这个判断展开。

先分清两者各自盯的是什么

功能测试盯的是用户可见行为：一条完整路径能不能走通、结果对不对、提示是否合理，判断依据来自需求文档与验收标准。接口测试盯的是系统之间的契约：入参出参、状态码、字段含义、边界与异常分支，判断依据来自接口文档与实际返回结果。目标不同，写用例时写的「预期」就完全不同。

功能层验证点

能描述用户操作顺序才能讲清楚的，比如提交后跳到哪一页、按钮是否置灰

接口层验证点

能脱离界面描述出来的，比如某个请求返回的状态码和字段取值

边界情况

两层判断标准不一样时，以需求里那条验收标准为准，不要拿接口文档当唯一依据

覆盖范围：谁能测出哪一类问题

功能测试能覆盖交互、跳转、文案、权限展示、跨页面状态这类只有走完整流程才暴露的问题。接口测试能覆盖参数校验、空值与超长值、重复提交、越权访问、返回字段缺失、错误码语义不一致这类界面层往往掩盖的问题。并发与顺序问题通常在接口层更容易复现，比如同一资源被连续请求、请求乱序返回导致覆盖。

两者的空白区要认下来：性能、兼容性、安全渗透都有自己的测试类型，别硬塞进这两类里，否则用例写得越多漏得越多。

方法差异：动手方式不一样

功能测试靠用例设计加手工或自动化回放，重点是步骤可复现、预期可判定，测试数据要准备到干净状态。接口测试更依赖构造请求：先拿到可用的地址与鉴权信息，再用工具或脚本批量跑参数组合，断言写在字段级别。动手顺序也不一样，接口测试得先把环境打通，再谈用例设计。

1. 打通环境先确认地址、请求头、鉴权方式都可用，跑通一条最简单的请求并看到预期返回，再去写正式用例
2. 量一遍基线用站内 工具测速页面 /tools/speed-test 先量当前延迟，异常慢时先怀疑环境而不是业务逻辑
3. 构造参数组合按正常值、边界值、异常值三类分别发请求，断言落在具体字段上，不要只看有没有返回
4. 区分失败原因失败的请求先判定是环境、鉴权还是业务逻辑问题，再决定是否提单，避免把配置问题误报成缺陷

什么时候用哪个，以及可以省掉哪个

需求早期接口已定、界面还没出，就先做接口测试，把契约锁住，后面界面改动不会牵连底层逻辑。涉及金额、权限、状态流转的功能，两层都要做：接口层保证规则正确，功能层保证用户看到的结果一致。纯展示型、无状态变化的页面，功能测试基本够用，接口层可以只做冒烟级验证。

• 接口先行的场景：接口已冻结、界面还在改，接口测试优先级高于功能测试
• 两层都做的场景：涉及权限、金额、状态流转，两边缺一不可
• 功能为主的场景：纯展示、没有状态变化，接口只跑关键路径
• 不适用的情况：需求频繁变更、界面还在推翻重做时，接口用例会大面积失效，此时以功能测试为主，接口只保关键路径

判断某条用例该不该留，可以问：如果这层不测，问题会从哪一层漏出去。漏不出去的就别重复写，把精力留给真正的风险点。

一份可照做的执行清单

1. 列清单并标归属拉出接口清单与功能用例清单，逐条标注属于哪一层，重复的合并，避免同一个点测两遍
2. 接口层先跑通基础确认地址、鉴权、返回结构无误，再补边界与异常用例，失败先排环境再提单
3. 功能层三段设计按主流程、分支流程、异常流程三段设计用例，主流程优先跑通，再补分支和异常
4. 缺陷归档写清层次写清是哪一层发现的、复现路径与预期结果，方便开发直接定位
5. 留回归基线用一两条最关键路径做回归基线，改动后先跑这两条，再决定要不要全量回归

想进一步安排手工与自动化的分工，可以对照站内 /manual-vs-automated-testing 的思路排出自己的节奏；需要先了解常用工具和目录，到 /tools 看一眼；接口选型和服务稳定性有疑问时，到 /sites 核对当时的实测记录，别拿写死的数字做判断。