ARTICLE · 1166177
软件测试全梳理:从白盒到验收
你以为软件测试就是“点一点，看能不能用”？
那可就低估它了。软考中的软件测试，既考测试层次，也考测试方法，还喜欢把几个容易混淆的概念放在一起“挖坑”。
单元测试、集成测试、确认测试、系统测试、验收测试，到底有什么区别？
白盒测试、黑盒测试、灰盒测试，是按什么划分的？
静态测试不运行程序，那它测试的到底是什么？
这篇文章，我们把《软件测试》的核心知识点、常见考点和易错点一次讲清楚。看完之后，至少不会再把“集成测试”和“验收测试”混成一锅粥。
一、先建立整体框架：软件测试有三个分类维度
软件测试经常从三个不同角度进行分类。
1. 按测试层次分类
主要包括：
单元测试 集成测试 确认测试 系统测试 验收测试
它回答的是：
测试进行到了哪一层？测试对象有多大？
2. 按测试是否了解内部结构分类
主要包括：
白盒测试 黑盒测试 灰盒测试
它回答的是：
测试人员是否了解程序的内部逻辑和实现结构？
3. 按是否运行程序分类
主要包括：
静态测试 动态测试
它回答的是：
测试过程中，程序有没有真正运行？
这三个维度不能混为一谈。
例如：
一个系统测试，可以采用黑盒测试； 一个集成测试，也可以采用灰盒测试； 一个测试用例，可能属于动态黑盒测试； 一次代码审查，则属于静态测试。
简单来说：
测试层次看“测什么范围”，测试方法看“从什么角度测”，静态动态看“程序是否运行”。
二、软件测试基础：测试到底在测什么
1. 软件测试的基本定义
软件测试是为了发现软件中的错误，验证软件是否满足规定需求，并评价软件质量的过程。
注意，测试的目标不是证明软件“绝对没有错误”。
更准确地说：
测试能够证明软件存在缺陷，但很难证明软件不存在缺陷。
因为输入空间太大，运行环境也可能非常复杂。即使测试通过了 1000 个场景，也不代表第 1001 个场景不会出问题。
2. 错误、缺陷和失效
这三个词在考试中比较容易绕。
可以这样记：
人犯错，代码有缺陷，运行会失效。
3. 测试用例通常包括什么
一个完整的测试用例，通常包括：
测试用例编号 测试目标 前置条件 输入数据 操作步骤 预期结果 实际结果 测试结论 测试环境 关联需求
其中最重要的一组是：
输入数据、操作步骤、预期结果。
没有预期结果的测试，往往只是“随便点点看”。点出问题了也许算运气，没点出问题更不能说明软件没问题。
4. 测试的几个基本原则
原则一：测试显示缺陷存在，不能证明缺陷不存在
测试通过，只能说明当前测试场景下没有发现问题。
原则二：穷尽测试几乎不可能
输入组合、运行环境、用户操作路径非常多，全部测试通常不现实。
原则三：测试应尽早开始
需求和设计阶段也可以测试，例如：
评审需求是否完整； 检查需求是否存在歧义； 检查设计是否满足性能要求； 检查接口定义是否一致。
越早发现问题，修复成本通常越低。
原则四：缺陷具有集群性
少数模块往往聚集了大多数缺陷。
这意味着测试资源可以重点投入到：
复杂模块； 修改频繁的模块； 接口较多的模块； 历史缺陷较多的模块。
原则五：杀虫剂悖论
一套测试用例反复执行后，可能很难再发现新问题。
就像同一款杀虫剂用久了，虫子也会逐渐“适应”。所以测试用例要不断补充和调整。
原则六：没有发现错误，不代表软件有用
如果软件根本没有实现用户需要的功能，即使没有发现程序错误，它仍然是失败的。
这就是常说的：
不存在已知错误，不代表软件满足用户需求。
三、五种测试层次：从一个模块到客户验收
软件测试层次通常按照测试范围逐步扩大。
常见顺序是：
单元测试 → 集成测试 → 确认测试 → 系统测试 → 验收测试
实际项目中可能存在迭代、回归和交叉进行，但在软考答题时，通常按照这个逻辑理解。
四、单元测试：先把最小零件测明白
1. 什么是单元测试
单元测试是对软件中的最小可测试单元进行测试。
测试对象可能是：
一个函数； 一个方法； 一个过程； 一个类； 一个模块。
单元测试关注的是模块内部逻辑是否正确。
2. 单元测试的主要内容
常见测试内容包括：
模块接口； 局部数据结构； 独立路径； 边界条件； 错误处理； 循环结构； 异常处理； 模块内部逻辑。
单元测试通常由程序员完成，比较适合采用白盒测试方法。
但要注意：
单元测试不等于白盒测试。
单元测试是按“测试层次”划分的，白盒测试是按“测试方法”划分的。二者属于不同分类维度。
3. 驱动模块和桩模块
当被测模块不能独立运行时，常常需要辅助模块。
驱动模块 Driver
用于调用被测模块，模拟上层模块。
常见于：
自底向上的集成测试； 单元测试中模拟调用者。
桩模块 Stub
用于被被测模块调用，模拟下层模块。
常见于：
自顶向下的集成测试； 单元测试中模拟被调用模块。
记忆方法很简单：
驱动是“主动调用别人”，桩是“被别人调用”。
五、集成测试：模块接起来，问题才真正出现
1. 什么是集成测试
集成测试是将经过单元测试的模块组合起来，检查模块之间的接口、调用关系和数据传递是否正确。
它关注的不是单个模块内部，而是：
模块之间能不能正确调用； 参数传递是否正确； 数据格式是否一致； 接口协议是否匹配； 异常是否能够正确传递； 一个模块的修改是否影响其他模块。
很多问题单独测试时发现不了，模块一连接，马上就开始“互相甩锅”。
2. 常见集成策略
自顶向下集成
从顶层模块开始，逐步向下集成。
特点：
先测试系统主控流程； 需要使用桩模块模拟底层模块； 可以较早验证系统整体控制结构； 底层模块测试相对较晚。
自底向上集成
从最底层模块开始，逐步向上集成。
特点：
需要使用驱动模块； 底层基础功能可以较早验证； 顶层控制逻辑测试较晚。
三明治集成
结合自顶向下和自底向上两种方式，从上层和下层同时向中间集成。
一次性集成
先分别完成各个模块，再一次性全部组合。
这种方式看起来省事，实际上问题定位很困难。出了问题，往往不知道是哪个模块、哪个接口出了错，因此一般不推荐。
3. 集成测试的高频易错点
六、确认测试：软件是否符合需求规格
1. 什么是确认测试
确认测试也叫验证测试或有效性测试，主要检查软件是否实现了需求规格说明书中规定的内容。
它重点回答：
软件是不是按照需求做出来的？
确认测试通常关注：
功能是否满足需求； 性能是否达到要求； 接口是否符合约定； 数据处理是否正确； 安全性是否符合要求； 用户文档和配置文档是否完整。
确认测试通常以黑盒测试为主，因为测试人员主要根据需求规格设计测试用例，不一定关心程序内部是如何实现的。
2. 确认测试和系统测试的区别
两者确实容易混淆。
可以简单理解为：
确认测试：重点看软件是否符合需求规格； 系统测试：重点看完整系统在实际或接近实际环境中是否满足整体目标。
不过，不同教材和项目管理体系对二者的边界可能略有差异。考试时要根据题目中的关键词判断：
出现“需求规格说明书、功能规格、软件是否正确实现需求”，更偏向确认测试； 出现“完整系统、运行环境、性能、安全、可靠性、兼容性”，更偏向系统测试。
七、系统测试：把整个系统放到真实场景中
1. 什么是系统测试
系统测试是对完整的、集成后的软件系统进行测试。
它不仅检查功能，还会检查各种非功能需求。
常见内容包括：
功能测试； 性能测试； 压力测试； 负载测试； 安全性测试； 可靠性测试； 可用性测试； 兼容性测试； 恢复性测试； 安装测试； 配置测试； 文档测试。
2. 系统测试的特点
系统测试通常需要：
接近真实的运行环境； 完整的系统配置； 真实或接近真实的数据； 多种用户角色； 端到端的业务流程。
比如电商系统不能只测“加入购物车”这个按钮，还要测试：
登录、浏览商品、加入购物车、提交订单、支付、库存扣减、消息通知、售后查询，能不能完整跑通。
这就是系统级思维。
八、验收测试：客户愿不愿意接收
1. 什么是验收测试
验收测试是由客户、用户或授权代表参与的测试，用于判断软件是否达到合同、业务目标或验收标准。
它重点回答：
这个软件，客户愿不愿意正式接收？
验收测试通常依据：
合同； 项目任务书； 用户需求； 验收标准； 业务流程； 服务等级协议。
2. 验收测试的常见形式
用户验收测试
由实际用户或业务代表进行，重点检查系统是否满足日常业务需要。
α 测试
通常在开发方或受控环境中进行，由用户或客户代表参与。
β 测试
通常交给真实用户，在真实或接近真实的环境中使用，收集反馈。
简单记忆：
α 测试更受控，β 测试更接近真实用户环境。
3. 确认测试和验收测试的区别
不要简单认为：
确认测试就是验收测试。
在某些教材或项目流程中，二者可能存在包含或交叉关系，但在概念上，确认测试更强调“符合规格”，验收测试更强调“客户接收”。
九、白盒测试：打开程序内部看逻辑
1. 什么是白盒测试
白盒测试也称结构测试或逻辑驱动测试。
测试人员了解程序的内部结构、控制流程和逻辑路径，根据源代码或设计结构设计测试用例。
它重点关注：
语句是否执行； 分支是否覆盖； 条件是否取到真和假； 循环是否正确； 路径是否覆盖； 异常处理是否完整。
2. 常见白盒测试方法
语句覆盖
测试用例执行到的语句数量，占全部可执行语句数量的比例。
可以表示为：
语句覆盖率高，说明执行过的代码较多，但不能说明所有判断分支都被测试。
判定覆盖或分支覆盖
要求每个判定的真、假分支都至少执行一次。
例如：
if 条件 then 执行路径 Aelse 执行路径 B至少需要让条件分别取真和假。
分支覆盖通常比单纯语句覆盖更严格，但依然不能覆盖所有条件组合。
条件覆盖
要求判定中的每个基本条件都至少取一次真值和一次假值。
例如：
if A and B then需要分别考虑：
A 为真； A 为假； B 为真； B 为假。
注意：
条件覆盖和分支覆盖不能简单认为完全等价。
路径覆盖
要求测试程序中的执行路径。
路径覆盖比语句覆盖和分支覆盖更严格，但如果程序中包含循环，完整路径数量可能非常大，甚至趋于无限，因此实际项目中通常只能选择重要路径。
基本路径测试
基本路径测试根据程序控制流图，找出一组线性独立路径。
控制流图的圈复杂度可以用下面的公式计算：
其中：
表示控制流图中的边数； 表示控制流图中的节点数； 表示连通分量数； 对于单个连通程序，通常 。
圈复杂度通常可以帮助我们估算基本独立路径的数量。
但要注意：
圈复杂度不是程序质量分数，也不是缺陷数量。
它主要反映程序逻辑结构的复杂程度。
3. 白盒测试的常见陷阱
语句覆盖率 100%，不代表分支覆盖率 100%； 分支覆盖率 100%，不代表所有条件组合都测试过； 路径覆盖不一定能覆盖所有循环路径； 白盒测试也不能发现所有需求层面的错误； 测试代码结构，不代表测试业务目标。
十、黑盒测试：不看内部，只看输入和输出
1. 什么是黑盒测试
黑盒测试也称功能测试或数据驱动测试。
测试人员不关心程序内部如何实现，只根据：
需求规格； 功能说明； 输入输出关系； 业务规则； 用户场景；
来设计测试用例。
黑盒测试重点检查：
输入某个数据后，系统是否给出了正确的输出和行为。
2. 等价类划分
等价类划分是把输入数据划分为若干类，认为同一类中的数据具有相似的测试效果。
例如，系统规定年龄必须是 到 岁。
可以划分为：
无效等价类：年龄小于 ； 有效等价类：； 无效等价类：年龄大于 。
测试时不需要把每个年龄都测一遍，可以从每个等价类中选择代表值。
3. 边界值分析
很多错误都发生在边界附近，所以边界值分析特别重要。
对于年龄范围 到 ，可以重点测试：
也就是：
边界外一点、边界值、边界内一点。
这是软考中很常见的考点。
易错点
只测试 和 ，不够。
因为程序员可能把：
大于写成大于等于； 小于写成小于等于； 写成 ； 写成 。
边界外的数据同样重要。
4. 判定表
当系统有多个条件，并且不同条件组合会产生不同动作时，可以使用判定表。
例如，贷款审批可能同时考虑：
是否有稳定收入； 是否有信用记录； 贷款金额是否超限； 是否存在逾期记录。
这种场景如果只靠几个普通测试用例，很容易漏掉组合情况。判定表可以把条件、条件组合和动作对应起来。
5. 因果图
因果图用于描述输入条件和输出结果之间的逻辑关系。
它适合处理：
多条件组合； 与、或、非关系； 条件之间存在约束； 多个原因影响多个结果。
因果图常常可以转换为判定表，帮助生成测试用例。
6. 状态转换测试
如果系统行为与当前状态有关，可以使用状态转换测试。
常见场景包括：
订单状态； 用户登录状态； 设备运行状态； 工作流审批状态； ATM 取款流程； 网络连接状态。
测试时不仅要测“合法状态转换”，还要测：
非法状态转换； 重复操作； 异常中断； 状态恢复； 状态转换条件不满足的情况。
7. 用例测试
用例测试从用户操作场景出发，验证完整业务流程。
例如“用户购买商品”用例可能包含：
用户登录； 搜索商品； 加入购物车； 提交订单； 完成支付； 查询订单状态。
用例测试特别适合系统测试和验收测试。
8. 错误推测法
错误推测法依靠测试人员经验，猜测系统中容易出错的地方。
常见经验包括：
空值； 超长字符串； 特殊字符； 重复提交； 网络中断； 权限不足； 时间跨天； 金额精度； 并发操作； 文件上传格式异常。
它简单、灵活，但依赖测试人员经验，不能完全替代系统化测试方法。
十一、灰盒测试：知道一些内部信息，但不完全打开源码
1. 什么是灰盒测试
灰盒测试介于白盒测试和黑盒测试之间。
测试人员通常了解部分内部信息，例如：
系统架构； 数据库表结构； 接口协议； 模块调用关系； 数据流转方式； 权限设计； 缓存机制。
但测试主要仍然从外部行为和业务结果出发。
2. 灰盒测试的典型场景
灰盒测试常用于：
接口测试； 集成测试； 数据库测试； 安全测试； Web 系统测试； API 测试； 分布式系统测试； 权限和数据一致性测试。
举个例子：
测试人员知道订单系统中有订单表、库存表和支付表，也知道订单创建接口会调用库存服务。
于是测试时不仅看页面显示是否正确，还会检查：
订单表是否正确写入； 库存是否正确扣减； 支付失败后订单状态是否回滚； 接口重复调用是否产生重复订单。
这就很像灰盒测试。
3. 灰盒测试的易错点
灰盒测试不是“白盒测试和黑盒测试各做一半”。
它强调的是：
测试人员掌握部分内部结构信息，但不完全依赖源代码进行测试。
十二、静态测试：程序不运行，也能发现不少问题
1. 什么是静态测试
静态测试是在不执行程序的情况下，对软件产品进行检查和分析。
测试对象不只是源代码，还包括：
需求规格说明书； 概要设计； 详细设计； 测试计划； 测试用例； 用户手册； 配置文件； 源代码； 数据库设计； 接口文档。
2. 常见静态测试方法
代码审查
由开发人员或评审人员阅读代码，发现：
命名问题； 逻辑错误； 资源未释放； 空指针风险； 安全漏洞； 不符合编码规范的问题。
走查
由代码作者向其他人员讲解代码，参与者提出问题和建议。
正式审查
按照明确的流程、角色和检查表进行评审，通常比普通走查更加规范。
静态分析
借助工具分析代码或文档，例如：
语法检查； 类型检查； 数据流分析； 控制流分析； 死代码检查； 复杂度分析； 安全漏洞扫描； 编码规范检查。
3. 静态测试能发现什么
静态测试可以发现：
需求描述歧义； 文档前后不一致； 接口定义不一致； 变量未初始化； 不可达代码； 代码规范问题； 潜在空指针； 资源泄漏风险； 权限校验遗漏； 设计结构不合理。
4. 静态测试不能完全替代动态测试
静态测试可以发现很多潜在问题，但无法完全判断：
实际运行性能； 并发条件下的表现； 用户体验； 真实环境兼容性； 运行时资源消耗； 运行时数据是否正确。
所以更合理的做法是：
静态测试提前发现问题，动态测试验证运行行为。
十三、动态测试：让程序真正跑起来
1. 什么是动态测试
动态测试需要执行程序，通过输入数据观察实际输出和系统行为。
动态测试可以检查：
功能是否正确； 输出是否符合预期； 页面交互是否正常； 性能是否达标； 系统是否稳定； 异常处理是否正确； 数据库状态是否一致； 多用户并发是否正常。
2. 静态测试与动态测试对比
静态测试和动态测试是互补关系，不是二选一。
十四、测试覆盖率：数字很漂亮，不代表质量就高
覆盖率可以帮助我们了解测试执行程度，但不能把它当成软件质量的全部。
常见覆盖率包括：
语句覆盖率； 分支覆盖率； 条件覆盖率； 路径覆盖率； 接口覆盖率； 功能覆盖率； 需求覆盖率。
例如，语句覆盖率达到 100%，只说明所有可执行语句都执行过。
它仍然可能存在：
错误的预期结果； 未覆盖的输入组合； 未覆盖的异常场景； 未验证的业务规则； 未测试的性能问题； 未测试的安全问题。
所以不能简单地说：
覆盖率越高，软件一定越好。
更准确的说法是：
覆盖率是测试充分性的重要参考指标，但不是软件质量的唯一指标。
十五、测试过程：从计划到关闭缺陷
一个完整的测试过程通常包括以下活动：
1. 测试计划
明确：
测试目标； 测试范围； 测试策略； 测试资源； 测试环境； 时间安排； 风险； 进入和退出准则。
2. 测试设计
根据需求和设计文档编写：
测试场景； 测试用例； 测试数据； 预期结果； 覆盖策略。
3. 环境准备
包括：
软件安装； 数据库准备； 网络配置； 测试账号； 测试数据； 依赖服务； 日志和监控配置。
4. 测试执行
按照测试用例执行，并记录：
实际输入； 实际输出； 测试结果； 测试日志； 截图或附件； 异常现象。
5. 缺陷管理
缺陷报告通常包括：
缺陷编号； 缺陷标题； 发现版本； 发现环境； 重现步骤； 预期结果； 实际结果； 严重程度； 优先级； 附件； 当前状态。
6. 回归测试
修复缺陷后，重新验证缺陷是否解决，并检查修改是否影响其他功能。
这里要区分：
重新测试：确认原来的缺陷是否已经修复； 回归测试：确认修改没有破坏其他原有功能。
十六、软考高频易错点，一次整理
易错点一：测试层次和测试方法不是一回事
单元、集成、确认、系统、验收：属于测试层次； 白盒、黑盒、灰盒：属于测试方法； 静态、动态：属于是否运行程序的分类。
不要看到“单元测试”就自动选“白盒测试”。
虽然单元测试经常使用白盒方法，但二者不是同一个概念。
易错点二：自顶向下用桩，自底向上用驱动
记住：
上面还没准备好，用驱动模拟上层调用；下面还没准备好，用桩模拟下层响应。
更直接的考试记忆：
自顶向下：桩； 自底向上：驱动。
易错点三：边界值不能只测边界
以 到 为例，不要只测 和 。
更完整的边界测试通常包括：
； ； ； ； ； 。
易错点四：语句覆盖率高，不代表测试充分
语句都执行过，可能仍然没有覆盖：
错误分支； 异常路径； 特殊输入； 业务组合； 并发场景。
易错点五：静态测试不是“什么都不测”
静态测试不运行程序，但可以检查：
文档； 需求； 设计； 代码； 配置； 接口； 编码规范。
易错点六：灰盒测试不是简单折中
灰盒测试不是“黑盒做一半、白盒做一半”，而是：
测试人员掌握部分内部信息，并利用这些信息设计更有针对性的外部测试。
易错点七：确认测试不等于验收测试
确认测试：看是否符合需求规格； 验收测试：看客户是否愿意接收。
二者可能有交叉，但关注重点不同。
易错点八：测试通过不等于软件没有缺陷
测试结果只能说明：
在当前测试数据、测试环境和测试范围内，没有发现问题。
这句话虽然不够“爽”，但很专业。
十七、一张表快速复习
十八、考场速记口诀
可以用下面几句话快速回忆：
单元测零件，集成测接口；确认看需求，系统看整体；验收看客户，能不能接收；白盒看逻辑，黑盒看输入；灰盒懂部分，接口更精准；静态不运行，动态跑起来；覆盖率很高，也别急着说没问题。
结语
软件测试不是“找几个错误”这么简单，它更像是在有限时间和资源下，尽可能验证软件是否满足需求、是否能够稳定运行、是否值得交付。
如果你正在准备软考，可以重点掌握这三条主线：
测试层次：单元、集成、确认、系统、验收； 测试方法：白盒、黑盒、灰盒； 执行方式：静态、动态。