测试分类详解
测试分类
一、按测试对象分类
1. 界面测试
1.1 测试内容介绍
界面测试验证用户界面(UI)的视觉呈现和交互逻辑，确保符合设计规范并提供良好的用户体验。测试内容包括：
- 页面布局和元素对齐
- 字体、颜色和图标一致性
- 交互反馈（悬停、点击状态）
- 导航逻辑和流程
- 响应式设计（不同设备适配）
1.2 关键指标
- 设计规范符合度 ≥ 95%
- 操作路径深度 ≤ 3步（核心功能）
- 元素响应时间 ≤ 300ms
- 无障碍标准（WCAG 2.1 AA级）
1.3 常见界面错误
- 文字重叠
- 截断显示
- 不合理换行
- 错位元素
- 焦点丢失
- 状态不一致
- 未对齐元素
2. 可靠性测试
2.1 可靠性概念
可靠性指系统在规定条件下和时间内，无故障执行所需功能的能力。反映软件的健壮性和持续服务能力。
2.2 关键指标
| 可靠性等级 | 年故障时间 | 适用场景 |
|---|---|---|
| 99.9%（三个9） | ≤8.76小时 | 普通应用 |
| 99.99%（四个9） | ≤52.6分钟 | 企业系统 |
| 99.999%（五个9） | ≤5.26分钟 | 金融/医疗 |
2.3 常见可靠性问题
- 服务不可用（HTTP 503）
- 数据损坏或丢失
- 事务处理中断
- 资源耗尽导致的崩溃
- 级联故障（一个组件故障引发系统崩溃）
3. 容错性测试
验证系统在异常输入或故障环境下的自我恢复能力：
- 输入容错：非法字符、超长文本、空值提交
- 环境容错：
- 硬件故障（磁盘满、内存不足）
- 网络中断（丢包率>50%）
- 依赖服务不可用
- 恢复机制：
- 自动重试策略（如指数退避）
- 事务回滚能力
- 优雅降级方案
4. 文档测试
国家有关计算机软件产品开发文件编制指南中共有14 种文件，可分为3 大类。
- 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
- 用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
- 管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。
测试要点：
- 步骤可执行性（按文档操作能否达成目标）
- 术语一致性（与UI和代码保持一致）
- 截图与版本匹配
- 多语言翻译准确性
- 搜索功能有效性（PDF/在线文档）
5. 兼容性测试
跨维度兼容验证矩阵：
| 维度 | 测试范围 | 工具推荐 |
|---|---|---|
| 操作系统 | Windows/macOS/Linux/iOS/Android | VirtualBox, Docker |
| 浏览器 | Chrome/Firefox/Safari/Edge | BrowserStack |
| 分辨率 | 720P/1080P/4K/折叠屏 | Viewport Resizer |
| 外设 | 打印机/扫描仪/特殊输入设备 | Device Farmer |
| API版本 | 向后兼容3个历史版本 | Postman, Swagger |
6. 易用性测试
基于尼尔森十大原则的验证：
- 系统状态可见性 → 进度指示器
- 系统与现实匹配 → 符合领域术语
- 用户控制与自由 → 可撤销操作
- 一致性与标准 → 统一交互模式
- 防错设计 → 危险操作确认
- 识别优于回忆 → 可视化操作路径
- 灵活高效 → 支持快捷键
- 美学与简约 → 信息层级清晰
- 容错与恢复 → 错误指导方案
- 帮助文档 → 上下文敏感帮助
7. 安装卸载测试
关键测试场景矩阵：
| 阶段 | Windows | macOS | Linux | Mobile |
|---|---|---|---|---|
| 安装 | 管理员/普通权限安装 | 应用商店/直接安装 | 源码编译/包管理器 | 应用商店/侧载 |
| 升级 | 增量更新/覆盖安装 | 版本兼容升级 | 依赖冲突解决 | 热更新/强更 |
| 卸载 | 控制面板卸载残留检测 | AppCleaner验证 | 包管理器卸载验证 | 清除用户数据 |
| 回滚 | 版本回退功能 | TimeMachine恢复 | 快照还原 | 历史版本安装 |
8. 安全测试
OWASP Top 10 2023核心测试点：
- 注入攻击
- 认证失效
- 敏感数据泄露
- XXE漏洞
- 访问控制缺陷
- 安全配置错误
- XSS攻击
- 反序列化漏洞
- 组件已知漏洞
- 日志监控缺失
渗透测试工具链：
- 侦察阶段：Nmap, Shodan
- 漏洞扫描：OWASP ZAP, Nessus
- 渗透利用：Burp Suite, Metasploit
- 后渗透：Cobalt Strike, Mimikatz
9. 性能测试
分层性能指标：
| 层级 | 关键指标 | 测试工具 |
|---|---|---|
| 前端 | FCP/LCP/FID/CLS | Lighthouse |
| 接口 | TPS/响应时间P99/错误率 | JMeter, Locust |
| 服务器 | CPU/内存/磁盘IO/网络吞吐 | Prometheus, Grafana |
| 数据库 | 查询耗时/锁等待/连接池 | SQL Profiler |
| 全链路 | 端到端延迟/事务成功率 | SkyWalking |
性能反模式检测：
- 循环内数据库查询
- 未分页的大数据加载
- 同步阻塞调用
- 缓存穿透/雪崩
- 线程死锁
10. 内存泄漏测试
内存泄漏检测方法论：
内存泄漏典型场景：
- 未释放资源：数据库连接、文件句柄
- 监听器未注销：事件总线订阅
- 静态集合膨胀：缓存无淘汰策略
- 线程局部变量：未清理的ThreadLocal
- 第三方库缺陷：Native代码泄漏
排查黄金法则：
- 监控内存趋势（持续增长即泄漏）
- 对比GC前后内存快照
- 定位支配树(Dominator Tree)中的异常对象
- 检查引用链(Reference Chain)中的非预期持有者
二、按是否查看代码分类
1. 黑盒测试
1.1 测试方法概览
- 等价类划分
- 边界值分析
- 因果图/正交判定表
- 正交测试法
- 场景设计法
- 错误猜测法
1.2 黑盒测试优缺点总结
| 优点 | 缺点 |
|---|---|
| ✅ 无需了解内部实现细节 | ❌ 无法覆盖所有代码路径 |
| ✅ 贴近用户实际使用场景 | ❌ 可能遗漏边界条件组合 |
| ✅ 早期即可开展测试 | ❌ 测试用例设计依赖需求质量 |
| ✅ 适合功能验证 | ❌ 难以检测深层次逻辑错误 |
2. 白盒测试
2.1 语句覆盖（Statement Coverage）
定义：确保程序中的每条可执行语句至少被执行一次
测试用例设计：
# 示例函数
def login(username, password):if username == "admin": # 语句1print("管理员登录") # 语句2else:print("普通用户登录") # 语句3return True # 语句4# 满足语句覆盖的用例
test_case1 = ("admin", "123456") # 覆盖语句1,2,4
test_case2 = ("user", "password") # 覆盖语句1,3,4
覆盖能力：⭐
缺陷检测：无法发现条件分支中的逻辑错误
2.2 判定覆盖（Decision Coverage）
定义：每个逻辑判断的真假分支至少执行一次
测试用例设计：
# 示例函数
def check_discount(amount, is_vip):if amount > 100 and is_vip: # 判定点return 0.8return 1.0# 满足判定覆盖的用例
test_case1 = (150, True) # 真分支
test_case2 = (50, False) # 假分支
覆盖能力：⭐⭐
局限：无法检测条件内部的错误（如 amount > 100 写成 amount >= 100）
2.3 条件覆盖（Condition Coverage）
定义：每个子条件的真假取值至少出现一次
测试用例设计：
# 示例函数
def grant_access(age, has_permission):if age >= 18 and has_permission: # 条件1: age>=18, 条件2: has_permissionreturn Truereturn False# 条件覆盖用例
test_case1 = (20, True) # 条件1真, 条件2真
test_case2 = (15, False) # 条件1假, 条件2假
覆盖能力：⭐⭐⭐
特点：比判定覆盖更细致，但可能遗漏判定组合
2.4 判定-条件覆盖（Condition/Decision Coverage）
定义：同时满足判定覆盖和条件覆盖
测试用例设计：
# 接上例
test_case1 = (20, True) # 真分支, 条件1真, 条件2真
test_case2 = (15, True) # 假分支, 条件1假, 条件2真 → 覆盖假分支
test_case3 = (20, False) # 假分支, 条件1真, 条件2假 → 覆盖假分支
覆盖能力：⭐⭐⭐⭐
价值：平衡了判定和条件的验证深度
2.5 条件组合覆盖（Multiple Condition Coverage）
定义：所有条件取值的可能组合都被覆盖
测试用例设计：
# 两个条件，需4种组合
test_case1 = (20, True) # 条件1真, 条件2真 → 真分支
test_case2 = (20, False) # 条件1真, 条件2假 → 假分支
test_case3 = (15, True) # 条件1假, 条件2真 → 假分支
test_case4 = (15, False) # 条件1假, 条件2假 → 假分支
覆盖能力：⭐⭐⭐⭐⭐
代价：条件数n → 组合数2^n（指数级增长）
2.6 路径覆盖（Path Coverage）
定义：覆盖程序中所有可能的执行路径
测试用例设计：
def process_order(status, amount):if status == "PAID": # 分支1if amount > 1000: # 分支2print("大额订单审核")else:print("订单直接发货")else:print("等待付款")# 路径覆盖用例
test_case1 = ("PAID", 1500) # 路径：分支1真→分支2真
test_case2 = ("PAID", 500) # 路径：分支1真→分支2假
test_case3 = ("UNPAID", 0) # 路径：分支1假
覆盖能力：⭐⭐⭐⭐⭐
挑战：循环结构可能导致路径无限（需设置最大迭代）
2.7 白盒测试优缺点总结
| 优点 | 缺点 |
|---|---|
| ✅ 高代码覆盖率（可达100%） | ❌ 需要编程能力和源码访问权限 |
| ✅ 发现深层次逻辑错误 | ❌ 测试成本高（设计/维护） |
| ✅ 适合关键模块测试 | ❌ 可能产生"过度测试" |
| ✅ 支持自动化测试 | ❌ 无法检测遗漏功能 |
3. 灰盒测试
3.1 典型应用场景
- API测试：基于接口文档设计用例 + 监控代码执行路径
- 性能优化：负载测试（黑盒） + 代码热点分析（白盒）
- 渗透测试：模拟攻击（黑盒） + 漏洞源码定位（白盒）
3.2 灰盒测试优缺点总结
| 优势 | 挑战 |
|---|---|
| ✅ 兼顾内外视角 | ❌ 需要跨领域技能 |
| ✅ 高效定位缺陷根源 | ❌ 测试设计复杂度高 |
| ✅ 适合微服务架构 | ❌ 工具链整合成本 |
| ✅ 优化测试资源分配 | ❌ 可能遗漏纯黑盒场景 |
三、按开发阶段分类
1. 单元测试
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。
- 测试阶段：编码后或者编码前（TDD）
- 测试对象：最小模块
- 测试人员：白盒测试工程师或开发工程师
- 测试依据：代码和注释+详细设计文档
- 测试方法：白盒测试
- 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
2. 集成测试
集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
- 测试阶段：一般单元测试之后进行
- 测试对象：模块间的接口
- 测试人员：白盒测试工程师或开发工程师
- 测试依据：单元测试的模块+概要设计文档
- 测试方法：黑盒测试与白盒测试相结合
- 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
3. 系统测试
将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。
- 测试阶段：集成测试通过后
- 测试对象：完整可交付系统
- 测试人员：专业测试团队
- 测试依据：需求规格说明书(SRS)
- 测试方法：黑盒测试为主
- 环境要求：功能、界面、可靠性、易用性、性能、兼容性、安全性等
4. 回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
5. 冒烟测试
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。
回归测试和冒烟测试都属于系统测试
6. 验收测试
验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
- 测试阶段：系统测试通过之后
- 测试对象：整个系统（包括软硬件）。
- 测试人员：主要是最终用户或者需求方。
- 测试依据：用户需求、验收标准
- 测试方法：黑盒测试
- 测试内容：同系统测试(功能…各类文档等)
四、按实施组织分类
1. Alpha测试
2. Beta测试
| 类型 | 执行者 | 典型活动 |
|---|---|---|
| Alpha测试 | 内部用户 | 受控环境模拟操作 |
| Beta测试 | 外部公测用户 | 真实环境收集反馈 |
| UAT(用户验收测试) | 真实客户 | 生产环境验证业务流程 |
| 合同验收测试 | 客户+供应商 | SLA(服务等级协议)验证 |
五、按是否运行代码分类
1. 静态测试
谓静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。不以测试数据的执行而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性。
2. 动态测试
动态测试（dynamic testing），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。
六、按是否手工进行测试分类
1. 手工测试
手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。
优点：自动化无法替代探索性测试、发散思维结果的测试。
缺点：执行效率慢，量大易错。
2. 自动化测试
在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
七、按地域分类
国际化测试、本地化测试