测试层级与测试类型

一句话:"在哪一层测"(层级)与"测什么属性"(类型)是两个正交维度------把两者混着说,是测试计划里最常见的结构错误。

定位 :通用知识第 3 页,给出"四层级 × 类型"的二维矩阵与选格判据(不是所有格子都值得做)。类型维度对齐 软件质量模型ISO25010,本页不重复展开质量特性的定义。

上游 :测试过程模型与左移右移(活动在流程中的位置) · 下游:测试设计(把选中的格子变成用例)


一、为什么必须拆成两个维度

  • "集成测试"是层级(测试对象的范围)
  • "性能测试"是类型(被验证的质量属性)
  • 完整表述应是"集成层的性能测试",例如:单节点接口的并发吞吐与 P99

混合表述会导致两类典型错误:

  1. 把"做了系统测试"当成"已覆盖性能/安全"------层级替代类型
  2. 把"做了性能测试"当成"质量已达标"------类型替代层级与范围

二、四个测试层级

层级 测试对象 目标 典型缺陷 主要责任 自动化程度 本库实例
组件/单元测试 函数、类、模块 逻辑正确、边界与异常分支 算法错误、空值、越界、状态机遗漏 开发者 高 ---
集成测试 组件间交互、接口、数据流 协作正确、契约一致 接口不匹配、协议/字段误解、时序与事务问题 开发 + 测试 中高 SSD测试速查表(命令级验证)
系统测试 完整系统(端到端) 需求级功能与非功能达标 需求缺失、跨模块交互、环境相关问题 测试团队 中(E2E 少而精) SSD测试方法与体系(10 类测试)
验收测试 用户/客户视角的业务目标 能不能用、要不要收 业务理解错、性能不达预期、可运维性差 用户/客户 + 业务方 低(部分可自动化) AI芯片Benchmark与Roofline模型(客户口径基准)

系统集成测试 :部分标准在集成与系统测试之间还列出"系统集成测试"------验证本系统与外部系统之间的互操作与数据流(跨系统接口、联调环境)。它可视为集成测试向外的外延,也可视为系统测试的入口;在强依赖第三方的产品中,这一层不可省略。

2.1 集成策略(与"集成测试"不是一回事)

策略 做法 优点 缺点
大爆炸 全部组装后一次测 省事 失败定位极难
自顶向下 用桩(stub)模拟下层 早期验证主流程 底层缺陷发现晚
自底向上 用驱动(driver)模拟上层 底层稳 主流程验证晚
三明治 上下并行、中间收口 折中 需要更多脚手架
基于调用图 / 变更驱动 按依赖关系与变更影响选择 高效、与 CI 契合 需要依赖分析能力

2.2 验收测试的分支

分支 谁验收 关注点
UAT(用户验收) 业务用户 业务流程可用
OAT(运行验收) 运维/IT 可部署、可监控、可备份恢复
合同 / 合规验收 客户 / 审计方 合同条款、法规、标准符合性
Alpha / Beta 内部试点 / 外部用户 真实使用反馈
法规验收 监管部门 安全关键或受监管产品(医疗、汽车等)

三、测试类型(对齐 ISO 25010 的八大质量特性)

类型的选取依据是质量的坐标系,故本页只列"类型 → 特性 → 手段 → 出口判据";特性定义见 软件质量模型ISO25010。

# 类型 回答的问题 对应特性 典型手段 出口判据示例
1 功能测试 功能对不对、全不全 功能适合性 等价类/边界值/判定表/场景法 需求条目覆盖 + 关键路径全通过
2 性能测试 负载下快不快、稳不稳 性能效率 负载/压力/稳定性/容量测试;FIO、JMeter、k6 P95/P99 与吞吐达基线、稳态无漂移
3 兼容性测试 换环境还能不能用 兼容性 平台/版本/设备/数据格式矩阵 目标兼容矩阵全绿(矩阵标版本与时点)
4 易用性 / 交互测试 好不好学、好用、好恢复 交互能力 可用性走查、任务完成率、无障碍检查 关键任务完成率与错误恢复达约定
5 可靠性测试 长时间与异常下是否可靠 可靠性 长稳、故障注入、掉电/中断、恢复验证 长稳期零崩溃;故障后数据一致且可自恢复
6 安全性测试 会不会被攻破、会不会泄露 安全性 漏洞扫描、渗透、认证与加密校验、依赖扫描 无高危未修复项;敏感数据无明文暴露
7 可维护性测试 改起来贵不贵 可维护性 静态分析、变更影响度量、构建与回归耗时 变更后回归时长在预算内
8 可移植性 / 灵活性测试 搬迁与适配成本 可移植性 安装/升级/替换/迁移演练 迁移脚本可执行且数据一致

可维护性与可移植性不由测试团队"保证" :它们主要由架构与设计决定,测试只能度量 (构建耗时、回归耗时、变更后失败用例数)与暴露。把它们交给测试"负责"是职责错配。

3.1 另一组容易混进来的正交分类(务必分清)

正交维度 取值 依据
技术可见性(方法) 黑盒 / 白盒 / 灰盒 是否查看内部结构
是否执行 静态 / 动态 是否运行代码(→ 测试基础理论)
测试目的 确认测试 / 回归测试 验证新功能,还是验证没被改坏
触发方式 计划驱动 / 探索式 用例是否预先设计

"黑盒/白盒"是方法,常被误当作类型------"我们做了黑盒测试"≈"我们做了测试"。方法与类型可交叉:黑盒的性能测试、白盒的安全测试都成立。


四、四层级 × 类型 二维矩阵(选格,不是全做)

矩阵读法:格子描述的是**"这一层有没有该类型的有效测法"**(✅ 强 / ◐ 有条件 / ❌ 不宜),不是"要不要做"。

层级 \ 类型 功能 性能 兼容性 易用性 可靠性 安全性 可维护性 可移植性
组件/单元 ✅ 强 ◐ 微基准(函数级耗时、复杂度) ❌ ❌ ◐ 异常/超时分支 ◐ 输入校验、加密原语 ◐ 圈复杂度、静态检查 ❌
集成 ✅ 强(契约/接口) ◐ 单节点、单接口吞吐 ◐ 组件版本兼容 ❌ ◐ 依赖故障注入 ◐ 认证与鉴权链路 ❌ ◐ 适配器/接口适配
系统 ✅ 强 ✅ 强(全链路) ✅ 强(兼容矩阵) ◐ 走查为主 ✅ 强(长稳、掉电) ✅ 强 ◐ 构建/回归耗时 ✅ 强(安装/升级/迁移)
验收 ✅ 强(业务口径) ◐ 基线验收(Peak/SLA) ◐ 目标环境验收 ✅ 强(真实用户) ◐ 试运行期观测 ◐ 合规审计 ❌ ◐ 目标环境安装与迁移验收

四条选格判据:

  1. 风险驱动:失效后果 × 发生概率 → 高风险格子优先(缺陷聚集原则,→ 测试基础理论)
  2. 成本单调性 :越靠下层越便宜 → 能下沉就下沉(金字塔原则)
  3. 可行性约束 :部分类型在低层不可测(易用性只能在系统/验收层;全链路容量只能在系统层)
  4. 反馈速度:CI 队列中必须保留"分钟级能跑完"的格子,慢的移到夜间或发布前

五、选取判据:场景 → 建议组合

变更场景 建议层级 × 类型 理由
单函数 / 算法改动 单元(功能 + 边界 + 异常) 性价比最高,CI 必跑
接口 / 协议字段变更 集成(功能 + 契约 + 兼容) 契约不一致是集成层主要缺陷
依赖升级(库/OS/内核) 集成 + 系统(兼容 + 功能回归) 兼容矩阵是主战场
涉及存储 / 持久化 系统 + 可靠性(掉电、长稳、数据一致性) 数据损坏不可恢复 → 高后果,见 SSD测试方法与体系
涉及并发 / 异步 单元 + 集成(竞态、超时、重试)+ 系统长稳 时序类缺陷低层难覆盖
发布 / 上线前 系统(功能回归 + 性能基线 + 安全扫描)+ 验收(业务口径) 出口判据的整体校验
面向 AI / 非确定性系统 统计判定(分布、阈值、评测集) 传统断言不适用 → 大模型评测技术
硬件 / 固件 系统 + 可靠性 + 兼容(V 模型世界) 不可回滚 → 前置验证强度更高

六、出口判据(Exit Criteria)模板

不要写"测试完成",要写可判定的条件:

维度 示例判据
覆盖 需求条目覆盖 100%;高风险模块分支覆盖 ≥ 约定阈值
缺陷 无 S1/S2 未关闭缺陷;S3 未关闭数 ≤ N 且有处置结论
质量属性 性能 P95 不劣于上一版本基线;安全扫描无高危
回归 全量回归通过率 100%(排除已批准豁免)
可发布性 回滚方案演练通过;灰度计划与观测指标就绪

判据必须可判定(要么过要么不过);"测试充分"这类描述不是判据。出口判据的经济含义见 测试度量与质量成本。


相关推荐
韩振方1 小时前
容器已经能运行了,为什么 Kubernetes 还要用 Pod?
后端
会编程的吕洞宾1 小时前
AgentScope Java 实战:给 AI Agent 加上权限管控
后端
考研保研资料分享1 小时前
自动化控制保研经验合辑:上交夏令营、北工大预推免与跨专业面试复盘(2025)
运维·面试·自动化
Thneonl4 小时前
全集群钟差 300 毫秒会发生什么:证书悄悄过期,日志倒流
运维·后端
金銀銅鐵4 小时前
[Java] 借助GUI展示class文件的版本号
后端·python·ai编程
Ikalus19884 小时前
预注册的答案表把正控判成「通过」,盲测判成「不通过」——而两个都不对
测试
马剑威(威哥爱编程)4 小时前
【AI全栈后端12-12】Spring Boot 3.x 到 4.x 迁移实操:Jakarta 11、Jackson 3 与 AI 2.0
java·开发语言·spring boot·后端
136096757234 小时前
一台 4 核 8G 已经跑了 6 个站点,我是怎么把第 7 个塞进去的
后端