软件测试理论基础教程¶
教程简介
本教程系统讲解软件测试的理论体系、流程方法、用例设计技巧，适合测试新人入门或在职人员系统梳理知识体系。
前置要求¶
无前置要求，零基础可直接学习。
新手导读¶
如果你是第一次学习软件测试，先不要急着背术语。第一遍重点掌握三件事：测试为什么存在、测试人员每天做什么、一个需求如何变成测试用例。
建议学习顺序：
- 先看测试目的、测试流程和测试分类。
- 再学等价类、边界值、场景法这几个最常用的用例设计方法。
- 最后看缺陷管理和测试报告，理解测试工作如何交付结果。
学完本教程后，你应该能独立写出一个简单功能的测试点、测试用例和缺陷报告。
一、软件测试概述¶
1.1 什么是软件测试¶
软件测试 是为了发现软件中的缺陷而执行程序的过程，目的是评估软件质量是否满足需求。
经典定义（IEEE）：
软件测试是使用人工或自动手段运行或测定某个系统的过程，目的是检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
1.2 测试的目的¶
| 目的 | 说明 |
|---|---|
| 发现缺陷 | 暴露软件中的问题 |
| 验证需求 | 确认软件做了该做的 |
| 评估质量 | 量化软件可发布程度 |
| 预防缺陷 | 早期介入，避免后期 Bug |
| 提供信息 | 给决策者发布与否的依据 |
1.3 测试的基本原则（七大原则）¶
- 测试显示存在缺陷，不能证明无缺陷 —— 测不出 Bug 不代表没 Bug
- 穷尽测试不可能 —— 输入组合无限多，需要选择性测试
- 测试尽早介入 —— 越早发现 Bug 修复成本越低
- 缺陷集群性 —— 80% 的缺陷集中在 20% 的模块（二八原则）
- 杀虫剂悖论 —— 同样的用例反复跑，发现 Bug 的能力会下降
- 测试活动依赖上下文 —— 不同行业（医疗 vs 游戏）测试侧重不同
- 无缺陷谬论 —— 没有 Bug 不等于产品成功（可能用户根本不要）
1.4 软件缺陷（Bug）的来源¶
总结
越早介入测试，性价比越高。
1.5 软件质量模型（ISO 25010）¶
ISO 25010 定义了软件产品质量的 8 个维度（2011 版）。2023 年修订版新增了 Safety（安全性/人身安全） 维度，共 9 个：
| 维度 | 子特性 |
|---|---|
| 功能性 | 完备性、正确性、适合性 |
| 性能效率 | 时间特性、资源利用、容量 |
| 兼容性 | 共存性、互操作性 |
| 易用性 | 可识别性、可学习性、可操作性 |
| 可靠性 | 成熟性、可用性、容错性、可恢复性 |
| 安全性 | 保密性、完整性、不可抵赖、可核查 |
| 可维护性 | 模块化、可重用、可分析、可修改、可测试 |
| 可移植性 | 适应性、可安装、可替换 |
| Safety（2023新增） | 运行安全、故障安全、风险可控 |
测试要覆盖以上所有维度（实际按业务侧重）。
二、测试分类体系¶
2.1 按测试阶段分类¶
单元测试（Unit Test）： - 对象：函数/方法/类 - 执行者：开发 - 工具：JUnit、PyTest、NUnit
集成测试（Integration Test）： - 对象：模块间接口 - 执行者：开发 + 测试 - 重点：接口数据流、调用链
系统测试（System Test）： - 对象：完整系统 - 执行者：测试 - 涵盖：功能、性能、安全、兼容等
验收测试（Acceptance Test）： - 对象：成品 - 执行者：客户 / 产品 - 类型：α 测试（公司内）、β 测试（外部用户）
2.2 按测试方法分类¶
| 类型 | 是否需要代码 | 关注 |
|---|---|---|
| 黑盒测试 | 否 | 输入输出，业务功能 |
| 白盒测试 | 是 | 代码内部逻辑 |
| 灰盒测试 | 部分 | 接口 + 部分内部 |
黑盒（功能测试）：
- 不关心代码实现
- 关注：功能、UI、业务
- 用例设计：等价类、边界值、场景法
白盒（结构测试）：
- 关注代码内部
- 覆盖率：语句、分支、路径
- 用例设计：基本路径法、条件覆盖
灰盒：
接口测试是典型灰盒：知道接口签名（输入输出），不深入代码实现。
2.3 按是否运行程序¶
| 类型 | 说明 |
|---|---|
| 静态测试 | 不运行代码，看文档、Review 代码 |
| 动态测试 | 运行程序，输入数据观察输出 |
2.4 按测试目的¶
| 类型 | 目的 |
|---|---|
| 功能测试 | 验证业务功能正确 |
| 性能测试 | 验证响应时间、并发能力 |
| 安全测试 | 验证安全漏洞 |
| 兼容性测试 | 多浏览器/系统/设备 |
| 易用性测试 | 用户体验 |
| 本地化测试 | 多语言、多地区 |
| 回归测试 | 验证修改未引入新 Bug |
| 冒烟测试 | 验证核心功能可用 |
| 可靠性测试 | 长时间运行无问题 |
| A/B 测试 | 两个版本对比 |
| 探索性测试 | 边测边设计用例 |
2.5 按是否自动化¶
| 类型 | 适合场景 |
|---|---|
| 手工测试 | 探索性、UI、新功能 |
| 自动化测试 | 回归、性能、接口 |
2.6 按可见性¶
| 类型 | 说明 |
|---|---|
| 冒烟测试 | 主流程能跑通（深度浅） |
| 回归测试 | 验证改动不影响老功能 |
| 全量测试 | 所有用例都跑（深度全） |
| 抽测 | 抽取部分代表性用例 |
三、软件开发与测试模型¶
3.1 V 模型（经典瀑布）¶
特点： - 测试与开发对应（左侧开发阶段对应右侧测试阶段） - 阶段清晰，便于管理
常见误区
V 模型并非"测试介入晚"——每个开发阶段（需求/设计/编码）都有对应的测试活动（验收测试设计/系统测试设计/单元测试设计），只是测试执行在编码完成后。真正的问题是测试执行晚，而非测试设计晚。W 模型在此基础上强调测试设计与开发同步执行。
3.2 W 模型¶
需求分析 ←→ 需求测试
↓ ↓
概要设计 ←→ 设计测试
↓ ↓
详细设计 ←→ 详细设计测试
↓ ↓
编码 ←→ 单元测试
↓ ↓
集成 ←→ 集成测试
↓ ↓
系统 ←→ 系统测试
↓ ↓
验收 ←→ 验收测试
特点： - 测试与开发并行 - 测试贯穿全生命周期 - 改进了 V 模型测试介入晚的问题
3.3 敏捷测试模型¶
敏捷下测试特点：
- 测试贯穿迭代全程
- 自动化是关键
- 持续集成、持续部署（CI/CD）
- 测试人员与开发紧密协作
敏捷测试象限：
│ 支持团队
│
自动化 Q1 单元/组件 │ Q2 功能测试 手工+自动
─────────────┼─────────────
自动化 Q4 性能/安全 │ Q3 探索/用户 手工
│
│ 评价产品
3.4 测试金字塔¶
╱╲
╱UI╲ 少量（约 5%）
╱────╲ 端到端，慢、贵
╱ 接口 ╲ 中量（约 20-25%）
╱──────╲ 稳定、性价比高
╱ 单元 ╲ 大量（约 70%+）
╱──────────╲ 快、便宜
参考说明
以上比例为参考值，Mike Cohn 在《Succeeding with Agile》中提出金字塔概念但未规定固定比例。实际应根据项目特点调整，如前端重的项目 UI 占比可能更高。
反模式（雪糕筒）：
四、测试流程¶
4.1 完整测试流程¶
4.2 各阶段产出物¶
| 阶段 | 主要产出 |
|---|---|
| 需求分析 | 需求理解文档、问题清单 |
| 测试计划 | 测试计划书 |
| 用例设计 | 测试用例文档 |
| 用例评审 | 评审记录、修订用例 |
| 环境准备 | 环境部署、数据准备 |
| 测试执行 | 执行记录、缺陷单 |
| 缺陷管理 | 缺陷跟踪、复测 |
| 测试报告 | 测试总结报告 |
4.3 需求分析阶段¶
测试人员要做：
- 评审需求文档（PRD）
- 提出疑问与建议
- 评估测试范围与难度
- 识别风险
关键问题：
- 这个需求要解决什么用户问题？
- 边界场景如何处理？
- 异常情况如何处理？
- 性能要求？
- 安全要求？
- 兼容性范围？
4.4 测试计划¶
测试计划包含：
# XX 项目测试计划
## 1. 项目背景
## 2. 测试目标
## 3. 测试范围（覆盖哪些功能、不覆盖哪些）
## 4. 测试策略（手工/自动化、测试类型）
## 5. 测试环境
## 6. 测试数据
## 7. 进度安排（甘特图）
## 8. 人员分工
## 9. 风险评估
## 10. 通过标准（达到什么程度可以发布）
## 11. 交付物
4.5 用例评审¶
评审目的： - 用例完整性 - 优先级合理性 - 与需求一致性 - 减少冗余
评审参与人： - 测试（主导） - 开发（确认实现细节） - 产品（确认需求理解）
4.6 测试执行¶
执行原则：
- 按优先级：P0 → P1 → P2
- 先冒烟后细测：主流程通畅再测细节
- 及时记录：边测边写缺陷单
- 保留证据：截图、日志
- 沟通同步：阻塞性问题立即通知
4.7 准入准出标准¶
准入标准（开测条件）：
- 开发自测完成
- 冒烟用例通过
- 测试环境就绪
- 测试数据准备完成
准出标准（停测条件）：
- 所有用例执行完
- P0/P1 缺陷全部修复
- 回归测试通过
- 性能/安全指标达标
- 通过评审
五、测试用例设计方法¶
5.1 等价类划分¶
思想： 把无限输入划分为有限组，每组取代表测试。
有效等价类： 符合需求的合理输入
无效等价类： 不符合需求的输入
示例：年龄字段（18-65 整数）
| 等价类 | 类型 | 测试值 |
|---|---|---|
| 18-65 整数 | 有效 | 30 |
| < 18 | 无效 | 10 |
| > 65 | 无效 | 80 |
| 小数 | 无效 | 25.5 |
| 负数 | 无效 | -5 |
| 字符 | 无效 | abc |
| 空 | 无效 | "" |
5.2 边界值分析¶
思想： 边界处最易出错。
规则： 取边界值、边界值 ±1。
示例：年龄 18-65
| 类型 | 测试值 |
|---|---|
| 下边界 | 18 |
| 下边界 -1 | 17 |
| 下边界 +1 | 19 |
| 上边界 | 65 |
| 上边界 -1 | 64 |
| 上边界 +1 | 66 |
常见边界：
- 数字：0、1、-1、最大值、最小值
- 字符串：空、1 字符、最大长度、超长 1 字符
- 数组：空、1 个、最大、超最大
- 时间：今天、昨天、明天、闰年、月末
5.3 判定表（决策表）¶
适合： 多个条件组合产生不同结果的场景。
示例：会员折扣
| 条件 | C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 |
|---|---|---|---|---|---|---|---|---|
| 是会员 | Y | Y | Y | Y | N | N | N | N |
| 金额≥100 | Y | Y | N | N | Y | Y | N | N |
| 首单 | Y | N | Y | N | Y | N | Y | N |
| 结果 | 7折 | 8折 | 9折 | 1.0 | 0.95 | 1.0 | 1.0 | 1.0 |
每一列就是一个测试用例。
5.4 因果图¶
适合： 输入条件与输出有复杂的因果关系。
通过画图分析条件组合，最终转化为判定表。
5.5 状态迁移图¶
适合： 有状态机的业务。
示例：订单状态
测试要覆盖： - 所有状态 - 所有合法迁移 - 非法迁移（如已完成 → 待支付，应拒绝）
5.6 场景法¶
适合： 业务流程测试。
基本流： 主流程
备选流： 异常分支
示例：用户登录
- 基本流：输入正确账密 → 登录成功
- 备选流 1：密码错误 → 提示错误
- 备选流 2：账号不存在 → 提示
- 备选流 3：账号锁定 → 提示
- 备选流 4：网络异常 → 重试
5.7 错误推测法¶
凭经验设计可能出错的场景：
- 空值、null、空格
- 超长、超大数字
- 特殊字符、SQL 注入、XSS
- 时间边界（跨年、闰年、月末）
- 并发场景
- 网络异常、断电
- 重复点击、快速操作
5.8 正交实验法¶
适合： 多因素多水平组合，要兼顾覆盖率和用例数。
原理： 用正交表（如 L9(3⁴)）减少组合数。
示例：测试浏览器兼容性
- 浏览器：Chrome、Firefox、Edge
- 操作系统：Win10、Win11、Mac
- 屏幕分辨率：1920、1366、2560
全组合 = 3 × 3 × 3 = 27 个用例
正交表 L9 = 9 个用例（覆盖率高）
5.9 各方法对比与组合使用¶
| 方法 | 适合场景 |
|---|---|
| 等价类 | 单字段输入 |
| 边界值 | 字段有范围 |
| 判定表 | 多条件组合 |
| 因果图 | 复杂因果关系 |
| 状态迁移 | 有状态机 |
| 场景法 | 业务流程 |
| 错误推测 | 异常场景 |
| 正交法 | 多因素组合 |
实际项目：组合使用
5.10 用例编写模板¶
用例编号：TC_LOGIN_001
所属模块：用户登录
用例标题：使用正确账号密码登录成功
优先级：P0
前置条件：
1. 账号 testuser 已注册
2. 密码为 123456
3. 账号状态正常
测试步骤：
1. 打开登录页
2. 输入账号：testuser
3. 输入密码：123456
4. 点击登录按钮
预期结果：
1. 跳转到首页
2. 顶部显示"欢迎，testuser"
3. 数据库 login_log 表新增登录记录
实际结果：（执行后填）
执行状态：（通过/失败/阻塞）
缺陷链接：（如有）
备注：
六、缺陷管理¶
6.1 缺陷生命周期¶
新建（New）
↓
打开（Open） ←──┐
↓ │
分配（Assigned） │
↓ │
处理中（In Progress）│
↓ │
已修复（Fixed） │
↓ │
验证（Verify） │
↓ │
关闭（Closed） / 重新打开（Reopen）─┘
其他状态： - 推迟（Deferred）：暂时不修 - 拒绝（Rejected）：不是 Bug - 重复（Duplicate）：和已有 Bug 重复
6.2 缺陷严重等级¶
| 等级 | 含义 |
|---|---|
| Blocker（致命） | 系统崩溃、数据丢失、阻塞主流程 |
| Critical（严重） | 主功能不可用 |
| Major（一般） | 次要功能问题、有变通方案 |
| Minor（轻微） | UI 小问题、文案错误 |
| Trivial（建议） | 优化建议 |
6.3 缺陷优先级¶
| 等级 | 含义 |
|---|---|
| P0 | 立即修，阻塞发布 |
| P1 | 高优，本次必修 |
| P2 | 中优，可选 |
| P3 | 低优，下个版本 |
严重等级 vs 优先级
一个文案错误（轻微）可能在首页（高优先级）；一个 OOM（致命）可能在低频功能（低优先级）。
6.4 缺陷报告模板¶
## 标题
[模块] 一句话描述
## 环境
- 系统：iOS 17.2
- App 版本：v1.2.3
- 网络：Wi-Fi
- 设备：iPhone 14
## 前置条件
1. 用户已登录
2. 购物车有 1 件商品
## 复现步骤
1. 打开 App
2. 点击购物车
3. 点击"去结算"
4. 选择支付宝支付
## 预期结果
跳转到支付宝支付页
## 实际结果
App 闪退，无任何提示
## 复现概率
3/3，100%
## 附件
- 视频：xxx
- 日志：xxx
- 截图：xxx
## 严重等级：Critical
## 优先级：P0
6.5 缺陷管理工具¶
| 工具 | 特点 |
|---|---|
| Jira | 国际主流，功能强 |
| TAPD | 腾讯，国内常用 |
| 禅道 | 国产，开源版免费 |
| GitHub Issues | 与代码集成 |
| Trello | 看板风格 |
| Worktile / 蓝湖 | 国内 SaaS |
6.6 缺陷描述要点¶
- 标题清晰：让人一眼知道问题
- 步骤明确：能复现
- 预期/实际清晰
- 附证据：截图、视频、日志
- 严重等级和优先级评估准确
七、测试度量¶
7.1 常见度量指标¶
质量指标：
| 指标 | 计算 |
|---|---|
| 用例通过率 | 通过用例 / 总用例 |
| 缺陷密度 | 缺陷数 / 千行代码（KLOC） |
| 缺陷遗漏率 | 线上 Bug / 总 Bug |
| 缺陷修复率 | 已修复 / 总缺陷 |
| 一次通过率 | 首轮通过用例 / 总用例 |
效率指标：
| 指标 | 含义 |
|---|---|
| 用例编写效率 | 用例数 / 工时 |
| 用例执行效率 | 执行数 / 工时 |
| 自动化覆盖率 | 自动化用例 / 总用例 |
| Bug 发现速度 | Bug 数 / 测试天数 |
过程指标：
| 指标 | 含义 |
|---|---|
| 需求覆盖率 | 已覆盖需求 / 总需求 |
| 测试覆盖率 | 已执行用例 / 计划用例 |
| 进度偏差 | 实际 vs 计划 |
7.2 缺陷分布分析¶
按模块、按严重度、按发现阶段统计，找出高发区。
7.3 缺陷收敛趋势¶
收敛说明软件趋于稳定，可以发布。
八、测试团队与角色¶
8.1 团队角色¶
| 角色 | 职责 |
|---|---|
| 测试经理 | 团队管理、流程制定 |
| 测试架构师 | 测试架构设计、工具选型 |
| 功能测试 | 手工执行用例、Bug 管理 |
| 接口测试 | 接口测试、自动化 |
| 自动化测试 | 框架开发、维护脚本 |
| 性能测试 | 性能压测、瓶颈分析 |
| 安全测试 | 安全扫描、渗透测试 |
| 测试开发（SDET） | 测试工具、平台开发 |
8.2 团队协作¶
测试与开发协作： - 早期参与设计评审 - 一起做技术方案讨论 - 缺陷沟通基于事实 - 协作而非对抗
测试与产品协作： - 一起评审需求 - 反馈用户体验 - 探索性测试发现的问题及时反馈
8.3 敏捷团队中的测试¶
- 全员对质量负责
- 测试不再是把关者，是质量教练
- 持续测试、持续反馈
- 自动化是关键
九、测试人员职业发展¶
9.1 能力模型¶
┌─ 业务理解力
│
基础：执行能力 ─→ ├─ 工具使用
│
└─ 用例设计
┌─ 自动化能力
│
进阶：技术能力 ─→ ├─ 性能/安全
│
└─ 框架开发
┌─ 团队管理
│
高阶：综合能力 ─→ ├─ 测试架构
│
└─ 质量战略
9.2 发展路径¶
路径 1：技术专家
路径 2：管理路线
路径 3：测试开发（SDET）
路径 4：转型
- 转产品经理（业务好的测试）
- 转开发（技术好的测试）
- 转项目管理（流程好的测试）
9.3 能力提升建议¶
基础（0-2 年）： - 掌握测试理论 - 熟练 Postman、Fiddler - 会用 Jira 等工具 - 学会 SQL 和 Linux 基础
进阶（2-5 年）： - 学一门编程（Python/Java） - 接口/UI 自动化 - 性能测试（JMeter） - 学会 CI/CD
高阶（5 年+）： - 测试平台/框架开发 - 多领域专长（性能 + 安全 + 自动化） - 团队管理与培养 - 测试体系建设
9.4 推荐学习资源¶
书籍： - 《软件测试的艺术》 - 《Google 软件测试之道》 - 《探索式软件测试》 - 《软件测试基础教程（ISTQB）》
网站/社区： - TesterHome（国内最大测试社区） - 51Testing - ISTQB 官方
认证： - ISTQB（国际软件测试认证） - CSTQB（中国软件测试认证）
十、常见面试题与答案¶
10.1 基础概念¶
Q：测试用例由哪几部分组成？
A：用例编号、标题、模块、优先级、前置条件、测试步骤、预期结果、实际结果、执行状态、备注。
Q：黑盒、白盒、灰盒区别？
A： - 黑盒：不看代码，关注输入输出 - 白盒：看代码，关注内部逻辑 - 灰盒：部分了解，如接口测试
Q：测试用例设计方法有哪些？
A：等价类、边界值、判定表、因果图、状态迁移、场景法、错误推测、正交法。
10.2 流程相关¶
Q：拿到需求后怎么做测试？
A： 1. 需求评审，确认理解 2. 制定测试计划 3. 设计用例并评审 4. 准备环境和数据 5. 执行测试，记录 Bug 6. 缺陷回归 7. 输出测试报告
Q：什么时候停止测试？
A：达到准出标准： - 用例执行完毕 - P0/P1 缺陷全修复 - 通过率达标（如 95%） - 性能指标达标 - 评审通过
10.3 缺陷管理¶
Q：开发说不是 Bug 怎么办？
A： 1. 重新阅读需求，确认是否符合 2. 找产品确认预期行为 3. 提供详细复现步骤和证据 4. 仍有分歧 → 三方会议讨论 5. 不情绪化，基于事实沟通
Q：上线后发现 Bug 怎么办？
A： 1. 评估影响范围和严重度 2. 紧急修复 or 回滚 3. 上线热修复 4. 复盘：为何漏测？流程/用例/技术？ 5. 补充用例，避免再次发生
10.4 思考题¶
Q：如何测试一个电梯？
A：从多维度切入：
- 功能：上下行、停止、开关门、楼层选择
- 性能：载重、响应速度、运行速度
- 安全：超载报警、停电应急、紧急按钮、防夹门
- 用户体验：按钮反馈、显示屏、语音
- 兼容性：不同身高、轮椅、行李
- 异常：钢丝断裂、火灾、地震
- 压力：高峰期持续运行
Q：如何测试一个 App 登录功能？
A：
- 功能正常：账号密码正确登录成功
- 异常：账号不存在、密码错、空字段
- 边界：账号/密码长度上下限
- 业务：连续错误锁定、验证码触发
- 安全：SQL 注入、暴力破解、明文传输
- 兼容性：不同机型、系统版本
- 性能：登录响应时间、并发
- 网络：弱网、断网、切换网络
- UI：按钮位置、错误提示
- 多端：同一账号多端登录
Q：测试一个杯子？
类似电梯，从功能、性能、安全、易用、外观、特殊场景全方位考虑。
10.5 自动化相关¶
Q：什么样的用例适合自动化？
A： - 稳定、重复执行（回归） - 频繁执行 - 手工成本高 - 数据量大 - 接口、性能场景
不适合： - UI 频繁变动 - 一次性 - 探索性 - 复杂主观判断（如美观）
附录：测试人员成长清单¶
入职第一年： - [ ] 熟悉公司业务和产品 - [ ] 掌握测试基础理论 - [ ] 熟练使用 Postman / Fiddler - [ ] 能独立设计和执行用例 - [ ] 学会 SQL 基础 - [ ] 学会 Linux 常用命令 - [ ] 了解 Git 基础
入职 2-3 年： - [ ] 掌握一门编程语言 - [ ] 能写接口自动化用例 - [ ] 了解性能测试 - [ ] 了解基础安全测试 - [ ] 能独立带小项目
入职 3-5 年： - [ ] 搭建自动化框架 - [ ] 主导性能测试 - [ ] 培养新人 - [ ] 推动流程改进 - [ ] 跨团队协作
测试是一门兼具技术与思维的学科
理论是地基，实战是楼层。本教程提供地基，需要在工作中持续实战，才能成为优秀的测试工程师。