浏览 AI 知识库
单元测试和接口测试有什么区别：各自应该覆盖什么
单元测试擅长验证局部规则，接口测试负责穿过路由、认证和真实边界。两者覆盖的问题不同，不能用测试数量代替分层设计。
先比较关键条件，再作选择
把自己的条件代入判断项；没有证据的维度保留未知，不用印象替代结论。
800 个单元测试都通过，为什么权限漏洞还在
项目有 800 个单元测试却没发现鉴权接口把别人的订单返回给当前用户；因为所有测试都 mock 了数据层，从未经过真实路由和权限组合。
- 每类风险有对应测试层
- 权限和失败路径未只靠 mock
- 失败时能快速定位到层级
同一个结算 Bug，分别放到能最快定位的层
| 失败 | 首选层 | 测试输入 | 为什么 |
|---|---|---|---|
| 折扣边界算错 | 单元 | 订单 99/100 元、不同折扣 | 快速定位规则和边界 |
| API 返回错误字段 | 接口 | 真实 JSON、认证和数据库夹具 | 验证服务契约和序列化 |
| 用户点击确认后状态没更新 | 浏览器 | 测试账号、表单和可见状态 | 覆盖导航、请求和 UI 反馈 |
| 首次使用流程难以理解 | 人工探索 | 新用户路径和不同屏幕 | 补自动化难以预设的体验问题 |
用例和金额为演示；真实分层按风险、稳定性和定位成本决定。
先把本例的条件、限制和目标摆出来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 订单服务包含金额计算、权限中间件和 REST 接口；主要风险为计算边界、角色访问和数据库约束。 |
| 不能越过的边界 | 按风险分层，不追求单一测试数量；单元测试验证纯逻辑，接口测试覆盖组件协作和契约。 |
| 要交付的结果 | 分层测试计划 |
单元测试和接口测试区别，哪些条件会改变最后选择
| 判断条件 | 本例怎么核对 | 本例归类 |
|---|---|---|
| 单元测试 | 纯函数、业务规则、边界计算和错误分支，依赖尽量可控。 | 快速定位逻辑 |
| 接口测试 | 路由、认证、校验、数据库、序列化和错误契约，可使用隔离测试数据。 | 验证服务协作 |
| 浏览器测试 | 登录、表单、导航、支付前确认等关键用户流程和可见状态。 | 验证真实体验 |
| 人工探索 | 视觉、易用性、新功能和难以预设的组合问题。 | 补自动化盲区 |
| 回归分配 | 每个已发现 Bug 放到最便宜且能稳定复现它的层级。 | 防止同类问题复发 |
单元测试和接口测试区别：按本例条件得到的结论
分层测试计划
计划把金额舍入放单元测试；成员/管理员访问、404/403 区分和事务回滚放接口测试；一条购买主流程进入浏览器测试。每个风险只在最合适层重点覆盖，避免相同 happy path 重复十次。
边界变化后需要重新判断
外部支付沙盒不稳定时需要契约测试和有限集成测试结合，不能用全 mock 宣称真实接口通过。
为什么“测试层次齐全，执行仍很慢”还不能交付
测试层次齐全，执行仍很慢
- 原因
- 大量低价值场景重复跨层运行
- 怎么改
- 按风险与失败定位价值删重，保留少量端到端关键路径