📅 日期:2026-05-15
📚 科目:软件设计师 · 软件工程
🏷️ 标签: 软件测试白盒测试黑盒测试 覆盖标准测试阶段
⭐ 重要度:高频考点(选择题 + 案例分析必考)
问:软件测试的目的是什么?
答:发现程序中的错误。(不是证明程序没有错误!)
陷阱:"证明软件正确"是错误说法,测试只能证明软件有错,不能证明无错。
不运行程序,通过人工审查或计算机辅助分析
| 方法 | 检查内容 |
|---|---|
| 控制流分析 | 没有使用的语句、无法到达的语句 |
| 数据流分析 | 引用未定义的变量 |
| 接口分析 | 接口一致性、函数参数一致性 |
包括:代码审查、走查、静态分析工具
运行程序,检查实际输出与预期结果的差异
| 类型 | 特点 |
|---|---|
| 白盒测试 | 关注内部结构(结构测试) |
| 黑盒测试 | 关注输入输出(功能测试) |
| 灰盒测试 | 介于两者之间 |
包括:单元测试、集成测试、系统测试中执行的测试
| 维度 | 静态测试 | 动态测试 |
|---|---|---|
| 是否运行程序 | 不运行 | 运行 |
| 发现错误阶段 | 早期(编码阶段即可开始) | 后期(需要可执行程序) |
| 成本 | 低(越早发现越便宜) | 较高 |
| 覆盖率 | 可覆盖所有代码 | 受测试用例限制 |
| 典型方法 | 代码审查、走查、静态分析 | 白盒、黑盒、灰盒测试 |
V模型是软件测试的经典模型,体现了测试与开发的对应关系:
| 开发阶段 | ↕ 对应 | 测试阶段 | 测试依据 |
|---|---|---|---|
| 需求分析 | ↕ | 验收测试 | 用户需求 |
| 概要设计 | ↕ | 系统测试 | 需求规格说明书 |
| 详细设计 | ↕ | 集成测试 | 概要设计文档 |
| 编码 | ↕ | 单元测试 | 详细设计文档 |
V模型的核心思想:每个开发阶段都有对应的测试阶段,测试计划应在对应的开发阶段就开始编写。
验收测试对应需求分析 → 系统测试对应概要设计 → 集成测试对应详细设计 → 单元测试对应编码。
白盒测试是选择题和案例分析的必考内容,必须掌握:覆盖标准的强弱关系、测试用例设计、各标准的优缺点。
核心思想:关注程序内部结构和逻辑,基于代码结构设计测试用例。
语句覆盖 < 判定覆盖 < 条件覆盖 < 判定-条件覆盖 < 条件组合覆盖 < 路径覆盖
口诀:"语句判定条判条路"
| 项目 | 内容 |
|---|---|
| 定义 | 设计测试用例使程序中每条可执行语句至少被执行一次 |
| 强度 | 最弱 |
| 缺点 | 无法发现逻辑运算中的错误(如 && 写成 ||) |
| 覆盖目标 | 每条语句至少执行1次 |
// 示例代码
if (A > 0 && B > 0) {
X = X / A; // 语句1
}
X = X + 1; // 语句2
// 测试用例:A=1, B=1, X=1
// 覆盖:语句1 ✓ 语句2 ✓
// 问题:未测试 A<=0 或 B<=0 的情况!
| 项目 | 内容 |
|---|---|
| 定义 | 设计测试用例使程序中每个判定的真假分支至少执行一次 |
| 强度 | 比语句覆盖强 |
| 缺点 | 忽略了判定中条件的组合(如 A真B假 的情况) |
| 覆盖目标 | 每个判定的 True 和 False 分支各至少1次 |
// 示例代码
if (A > 0 && B > 0) {
X = 1; // 分支True
} else {
X = 2; // 分支False
}
// 测试用例1:A=1, B=1 → X=1(True分支)
// 测试用例2:A=-1, B=1 → X=2(False分支)
// 判定覆盖 ✓ 但未测试 A>0,B<=0 的组合
| 项目 | 内容 |
|---|---|
| 定义 | 设计测试用例使每个判定中每个条件的可能取值至少执行一次 |
| 强度 | 比判定覆盖强(某些情况下) |
| 缺点 | 不一定满足判定覆盖!(条件覆盖 ≠ 判定覆盖) |
| 覆盖目标 | 每个简单条件的 True 和 False 各至少1次 |
// 示例代码
if (A > 0 && B > 0) {
X = 1;
} else {
X = 2;
}
// 条件A:true, false;条件B:true, false
// 测试用例1:A=1, B=-1 → A真B假 → 判定结果为False → X=2
// 测试用例2:A=-1, B=1 → A假B真 → 判定结果为False → X=2
// 条件覆盖 ✓(A真假、B真假都覆盖了)
// 但判定覆盖 ✗(True分支从未执行!)
条件覆盖不一定满足判定覆盖!这是考试最常见的陷阱。
上面的例子中,所有条件的真假值都覆盖了,但整个判定的结果始终为False。
| 项目 | 内容 |
|---|---|
| 定义 | 同时满足判定覆盖和条件覆盖 |
| 强度 | 比单独的判定覆盖和条件覆盖强 |
| 缺点 | 忽略了条件的组合情况(如 A真B假) |
| 覆盖目标 | 每个判定真假各1次 + 每个条件真假各1次 |
// 测试用例1:A=1, B=1 → True分支,A真B真
// 测试用例2:A=-1, B=-1 → False分支,A假B假
// 判定覆盖 ✓ 条件覆盖 ✓
// 但未覆盖 A真B假 和 A假B真 的组合!
| 项目 | 内容 |
|---|---|
| 定义 | 设计测试用例使每个判定中条件的所有可能组合至少执行一次 |
| 强度 | 比判定-条件覆盖强 |
| 缺点 | 测试用例数量增长快(2^n),覆盖路径有限 |
| 覆盖目标 | 每个条件组合至少1次 |
// 对于 if (A && B),有4种条件组合:
// A=true, B=true → 判定为True
// A=true, B=false → 判定为False
// A=false, B=true → 判定为False
// A=false, B=false → 判定为False
// 需要4个测试用例覆盖所有组合
// 注意:条件组合覆盖不一定是路径覆盖!
| 项目 | 内容 |
|---|---|
| 定义 | 设计测试用例使程序中所有可能的路径至少执行一次 |
| 强度 | 最强 |
| 缺点 | 测试用例数量可能很大,循环结构路径无限 |
| 覆盖目标 | 每条独立路径至少1次 |
// 示例:两个独立的if语句
if (A) { 语句1; }
if (B) { 语句2; }
// 路径数 = 2 × 2 = 4条路径
// 路径1:A真, B真 → 语句1 + 语句2
// 路径2:A真, B假 → 语句1
// 路径3:A假, B真 → 语句2
// 路径4:A假, B假 → 无语句
// 需要4个测试用例
| 覆盖标准 | 覆盖目标 | 强度 | 优点 | 缺点 |
|---|---|---|---|---|
| 语句覆盖 | 每条语句至少1次 | 最弱 | 简单,容易实现 | 无法发现逻辑错误 |
| 判定覆盖 | 每个判定真假各1次 | 较弱 | 覆盖了分支 | 忽略条件组合 |
| 条件覆盖 | 每个条件真假各1次 | 中等 | 覆盖了每个条件 | 不一定满足判定覆盖 |
| 判定-条件覆盖 | 判定覆盖+条件覆盖 | 较强 | 同时满足判定和条件 | 忽略条件组合 |
| 条件组合覆盖 | 所有条件组合各1次 | 强 | 覆盖所有组合 | 用例数增长快(2^n) |
| 路径覆盖 | 所有路径各1次 | 最强 | 全面覆盖逻辑 | 循环路径无限 |
MC/DC(Modified Condition/Decision Coverage)是航空等安全关键领域的标准覆盖要求,介于判定-条件覆盖和条件组合覆盖之间。
| 项目 | 内容 |
|---|---|
| 定义 | 每个条件独立影响判定结果至少一次 |
| 核心思想 | 固定其他条件不变,只改变一个条件,看判定结果是否变化 |
| 用例数 | n个条件 → n+1个测试用例(比条件组合的2^n少得多) |
| 应用场景 | 航空电子(DO-178B/C)、汽车安全(ISO 26262) |
// if (A && B && C),3个条件
// MC/DC需要 3+1=4 个测试用例:
// 1. A=T, B=T, C=T → True (基准)
// 2. A=F, B=T, C=T → False (A独立影响)
// 3. A=T, B=F, C=T → False (B独立影响)
// 4. A=T, B=T, C=F → False (C独立影响)
// 比条件组合覆盖的8个用例少一半!
控制流图(CFG)是白盒测试的基础工具,用于表示程序的执行路径。
| 图形元素 | 含义 |
|---|---|
| 节点(圆/椭圆) | 一个或多个顺序执行的语句(基本块) |
| 边(箭头) | 控制流方向 |
| 判定节点 | 有两条出边的节点(如 if、while) |
| 汇合节点 | 有多条入边的节点 |
圈复杂度用于衡量程序的复杂程度,也等于基本路径数(即路径覆盖至少需要的测试用例数)。
| 公式 | 说明 |
|---|---|
V(G) = E - N + 2 | E=边数,N=节点数 |
V(G) = P + 1 | P=判定节点数(有两条出边的节点数) |
V(G) = 区域数 | 控制流图中的封闭区域数 + 1个外部区域 |
// 示例:计算圈复杂度
// 代码:
if (A) { B; }
if (C) { D; } else { E; }
// 控制流图:
// 节点数N=6(入口、ifA、B、ifC、D/E、出口)
// 边数E=7
// 判定节点P=2(ifA和ifC)
// V(G) = E - N + 2 = 7 - 6 + 2 = 3
// V(G) = P + 1 = 2 + 1 = 3
// 至少需要3个测试用例覆盖所有基本路径
核心思想:关注输入输出,不关心内部结构,基于需求规格设计测试用例。
"等边因判场错" = 等价类、边界值、因果图、判定表、场景法、错误推测
将输入数据划分为若干等价类,从每个类中选取代表值作为测试用例。同一等价类中的数据发现错误的能力相同。
| 类型 | 定义 | 示例(输入范围1-100) |
|---|---|---|
| 有效等价类 | 合理的、有意义的输入数据 | 1-100之间的整数 |
| 无效等价类 | 不合理的、无意义的输入数据 | <1的数、>100的数、非数字 |
| 输入条件 | 有效等价类 | 无效等价类 |
|---|---|---|
| 取值范围(如1-100) | 范围内值(如50) | 范围外值(如0, 101) |
| 枚举值(如男/女) | 枚举范围内(男、女) | 枚举范围外(其他) |
| 布尔值(是/否) | True / False | 无(布尔只有两个值) |
| 规定个数(如1-5个) | 规定范围内(如3个) | 范围外(如0个、6个) |
| 必须满足条件 | 满足条件的值 | 不满足条件的值 |
选取边界值作为测试用例。经验表明,错误往往发生在输入范围的边界上。
| 概念 | 定义 | 示例(范围 [1, 100]) |
|---|---|---|
| 上点 | 边界上的点 | 1, 100 |
| 离点 | 离边界最近的点 | 0, 2, 99, 101 |
| 内点 | 范围内的点 | 50 |
对于输入范围 [min, max],标准测试用例:
| 测试用例 | 取值 | 说明 |
|---|---|---|
| 刚好小于最小值 | min - 1 | 无效输入(下界外) |
| 刚好等于最小值 | min | 有效输入(下界) |
| 刚好大于最小值 | min + 1 | 有效输入(下界内) |
| 正常值 | (min + max) / 2 | 有效输入(内点) |
| 刚好小于最大值 | max - 1 | 有效输入(上界内) |
| 刚好等于最大值 | max | 有效输入(上界) |
| 刚好大于最大值 | max + 1 | 无效输入(上界外) |
边界值 = min-1, min, min+1, 正常值, max-1, max, max+1(共7个典型值)
等价类 + 边界值 组合使用效果最佳!
基于经验和直觉推测程序中可能存在的错误,列举容易发生错误的特殊情况。
| 常见错误场景 | 测试输入 |
|---|---|
| 空值处理 | 输入为空、null |
| 零值处理 | 输入为0 |
| 负数处理 | 输入为负数 |
| 类型转换 | 输入类型不匹配 |
| 特殊字符 | 输入包含特殊字符(如SQL注入字符) |
| 超长输入 | 输入超过最大长度 |
| 重复操作 | 重复提交、重复点击 |
分析输入条件(因)和输出结果(果)之间的关系,将自然语言描述转化为逻辑表达式。
| 符号 | 名称 | 含义 | 示例 |
|---|---|---|---|
E (互斥) | Exclusive | 原因中最多一个为真 | 单选按钮(只能选一个) |
I (包含) | Inclusive | 原因中至少一个为真 | 复选框(至少选一个) |
O (唯一) | One and only | 原因中恰好一个为真 | 必选单选按钮 |
R (要求) | Require | 若A为真则B也必须为真 | 选了VIP就必须选会员 |
M (屏蔽) | Mask | 若A为真则B必须为假 | 选了现金支付就不能选信用卡 |
分析多个输入条件的组合对输出的影响,用表格形式列出所有条件组合。
| 组成部分 | 说明 |
|---|---|
| 条件桩 | 列出所有输入条件 |
| 动作桩 | 列出所有输出结果/操作 |
| 条件项 | 输入条件的取值组合(T/F) |
| 动作项 | 每种组合对应的输出结果 |
需求:用户登录系统,输入用户名和密码。用户名正确且密码正确→登录成功;用户名正确但密码错误→提示密码错误;用户名错误→提示用户不存在。
| 判定表 | ||||
|---|---|---|---|---|
| 条件\规则 | 规则1 | 规则2 | 规则3 | 规则4 |
| 用户名正确 | T | T | F | F |
| 密码正确 | T | F | T | F |
| 登录成功 | ✓ | |||
| 提示密码错误 | ✓ | |||
| 提示用户不存在 | ✓ | ✓ | ||
规则4可与规则3合并(用户名错误时密码是否正确不影响结果)→ 判定表化简。
模拟用户操作场景,通过分析基本流和备选流来设计测试用例。
| 概念 | 定义 | 示例(电商下单) |
|---|---|---|
| 基本流 | 从开始到结束的正常流程 | 选商品→加入购物车→结算→支付→成功 |
| 备选流 | 偏离基本流的异常/分支流程 | 库存不足、支付失败、地址无效等 |
| 场景 | 描述 | 测试用例 |
|---|---|---|
| 场景1(基本流) | 正常下单成功 | 选有库存商品→正确地址→支付成功 |
| 场景2(备选流1) | 商品无库存 | 选无库存商品→提示库存不足 |
| 场景3(备选流2) | 支付失败 | 选有库存商品→正确地址→支付失败→重试 |
| 场景4(备选流3) | 地址无效 | 选有库存商品→无效地址→提示错误 |
| 方法 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 等价类划分 | 输入数据有明确范围或类型 | 减少测试用例数 | 可能遗漏边界错误 |
| 边界值分析 | 输入数据有数值边界 | 发现边界错误高效 | 只关注边界,不关注内部 |
| 错误推测 | 经验丰富时 | 发现特殊错误 | 依赖经验,不够系统 |
| 因果图 | 输入条件有逻辑关系 | 考虑条件组合 | 复杂条件时图很大 |
| 判定表 | 输入条件组合影响输出 | 系统全面 | 条件多时表很大 |
| 场景法 | 有明确业务流程 | 贴近实际使用 | 难以覆盖所有路径 |
| 阶段 | 依据文档 | 测试对象 | 主要方法 | 执行者 |
|---|---|---|---|---|
| 单元测试 | 详细设计文档 | 模块(函数、类) | 白盒测试为主 | 开发人员 |
| 集成测试 | 概要设计文档 | 模块间接口 | 灰盒测试 | 开发/测试人员 |
| 系统测试 | 需求规格说明书 | 整个系统 | 黑盒测试 | 独立测试团队 |
| 确认测试(验收测试) | 需求规格说明书 / 用户需求 | 软件产品 | 黑盒测试 | 用户/客户 |
"单详集概系需确需"
单元→详细设计,集成→概要设计,系统→需求规格,确认→需求规格/用户需求
| 测试内容 | 说明 | 示例 |
|---|---|---|
| 模块接口 | 参数传递、返回值 | 传入null是否报错 |
| 局部数据结构 | 变量初始化、数据类型 | 数组越界、溢出 |
| 边界条件 | 循环边界、数组边界 | 空数组、单元素数组 |
| 独立路径 | 程序中的执行路径 | 覆盖所有分支 |
| 错误处理 | 异常捕获和处理 | 除零异常、文件不存在 |
单元测试时,被测模块可能依赖其他模块,需要用桩模块和驱动模块来模拟。
模拟调用者,用来调用被测模块
相当于"测试主程序"
例:测试函数B时,写一个main()调用B
模拟被调用者,代替被测模块依赖的模块
相当于"替身"
例:函数B调用函数C,用桩模块代替C
驱动模块 = 调用被测模块的"上级"(模拟调用者)
桩模块 = 被测模块调用的"下级"(模拟被调用者)
口诀:"上驱下桩"(上面驱动,下面打桩)
| 项目 | 内容 |
|---|---|
| 顺序 | 从主控模块开始,沿控制层次向下,逐层集成 |
| 方式 | 深度优先 或 广度优先 |
| 需要 | 桩模块(代替未集成的下层模块) |
| 优点 | 早期验证主要控制逻辑,故障隔离容易 |
| 缺点 | 需要大量桩模块,底层模块测试不充分 |
| 项目 | 内容 |
|---|---|
| 顺序 | 从最底层模块开始,逐层向上集成 |
| 方式 | 先测试叶子模块,再测试上层模块 |
| 需要 | 驱动模块(代替未集成的上层模块) |
| 优点 | 不需要桩模块,底层模块测试充分 |
| 缺点 | 需要大量驱动模块,主控逻辑测试较晚 |
| 项目 | 内容 |
|---|---|
| 方式 | 结合自顶向下和自底向上,从中间层开始集成 |
| 需要 | 同时使用桩模块和驱动模块 |
| 优点 | 兼顾两者的优点,效率最高 |
| 缺点 | 需要同时开发桩和驱动,工作量大 |
| 策略 | 需要桩 | 需要驱动 | 测试顺序 | 适用场景 |
|---|---|---|---|---|
| 自顶向下 | 是 | 否 | 从顶层到底层 | 主控逻辑重要 |
| 自底向上 | 否 | 是 | 从底层到顶层 | 底层逻辑重要 |
| 三明治 | 是 | 是 | 从中间向两端 | 综合考虑 |
| 类型 | 内容 | 示例 |
|---|---|---|
| 功能测试 | 验证系统功能是否符合需求 | 登录、注册、下单等 |
| 性能测试 | 验证系统性能指标 | 响应时间、吞吐量、并发数 |
| 安全测试 | 验证系统安全性 | 渗透测试、漏洞扫描 |
| 兼容性测试 | 验证系统兼容性 | 浏览器兼容、OS兼容 |
| 压力测试 | 验证系统极限承载能力 | 100万并发用户 |
| 恢复测试 | 验证系统故障恢复能力 | 断电恢复、数据库恢复 |
| 类型 | 说明 | 参与者 |
|---|---|---|
| α测试 | 用户在开发方场所进行测试 | 用户 + 开发人员 |
| β测试 | 用户在自己场所进行测试 | 用户(开发人员不在场) |
| 正式验收测试 | 按验收标准严格测试 | 用户 + 第三方 |
α测试:在开发方场地,开发人员在旁(可控)
β测试:在用户场地,开发人员不在(真实环境)
记忆:"α在厂,β在外"
| 项目 | 内容 |
|---|---|
| 定义 | 介于白盒和黑盒测试之间 |
| 特点 | 关注输入输出,也关注内部结构 |
| 应用 | 主要用于集成测试和系统测试 |
| 方法 | 结合白盒的结构分析和黑盒的功能验证 |
| 项目 | 内容 |
|---|---|
| 定义 | 修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误 |
| 目的 | 确保修改不会影响原有功能 |
| 触发时机 | 代码修改、缺陷修复、环境变更 |
| 策略 | 全部重新测试 / 选择性重新测试(基于影响分析) |
| 自动化 | 通常使用自动化测试工具提高效率 |
| 要素 | 说明 | 示例 |
|---|---|---|
| 用例编号 | 唯一标识 | TC-LOGIN-001 |
| 用例标题 | 简要描述测试目的 | 验证正确用户名密码登录成功 |
| 前置条件 | 执行用例前的准备 | 用户已注册 |
| 输入数据 | 测试输入 | 用户名:admin, 密码:123456 |
| 执行步骤 | 操作步骤 | 1.打开登录页 2.输入用户名密码 3.点击登录 |
| 预期结果 | 期望的输出 | 登录成功,跳转首页 |
| 实际结果 | 实际执行后的输出 | (执行后填写) |
| 优先级 | 用例重要程度 | P0(最高)/ P1 / P2 |
| 方法 | 说明 | 特点 |
|---|---|---|
| 蛮力法 | 利用"计算机找错",打印内存、设置断点 | 效率低,但常用 |
| 回溯法 | 从错误点出发,沿控制流回溯追踪错误原因 | 适合小程序 |
| 原因排除法 | 演绎和归纳,缩小错误原因范围 | 效率最高 |
测试:发现错误(找Bug)
调试:定位和修复错误(修Bug)
先测试发现错误,再调试定位和修复错误。
| 层次 | 测试对象 | 对应传统测试 | 说明 |
|---|---|---|---|
| 算法层 | 类中的方法 | 单元测试 | 测试单个方法的正确性 |
| 类层 | 类(封装) | 单元测试 | 测试类的方法交互、状态变化 |
| 模板层/类族层 | 继承、多态 | 集成测试 | 测试继承层次和多态行为 |
| 系统层 | 整个系统 | 系统测试 | 测试系统整体功能 |
| 指标 | 公式 | 说明 |
|---|---|---|
| 缺陷密度 | 缺陷数 / 代码行数(或功能点数) | 衡量代码质量 |
| 缺陷发现率 | 发现缺陷数 / 测试用例数 | 衡量测试效率 |
| 缺陷修复率 | 已修复缺陷数 / 总缺陷数 | 衡量开发效率 |
| 测试覆盖率 | 已覆盖代码 / 总代码 | 衡量测试充分性 |
步骤:
答题格式示例:
| 用例编号 | 输入(A,B,X) | 预期输出 | 覆盖路径/分支 |
|---|---|---|---|
| TC1 | A=1, B=1, X=1 | X=1 | 判定True分支 |
| TC2 | A=-1, B=1, X=1 | X=2 | 判定False分支 |
步骤:
步骤:
V(G) = E - N + 2(E=边数,N=节点数)V(G) = P + 1(P=判定节点数)| 情况 | 推荐策略 | 理由 |
|---|---|---|
| 主控逻辑风险高 | 自顶向下 | 优先验证顶层控制逻辑 |
| 底层模块风险高 | 自底向上 | 优先验证底层模块 |
| 需要快速验证 | 三明治 | 中间层开始,双向集成 |
| 模块依赖简单 | 大爆炸 | 所有模块一起集成(简单但风险高) |
| # | 考点 | 答案 |
|---|---|---|
| 1 | 软件测试的目的是什么? | 发现程序中的错误(不是证明正确) |
| 2 | 覆盖标准从弱到强排序? | 语句<判定<条件<判定-条件<条件组合<路径 |
| 3 | 条件覆盖是否一定满足判定覆盖? | 不一定!(最常见陷阱) |
| 4 | 路径覆盖的局限性? | 循环结构路径无限 |
| 5 | 单元测试的依据文档? | 详细设计文档 |
| 6 | 集成测试的依据文档? | 概要设计文档 |
| 7 | 系统测试的依据文档? | 需求规格说明书 |
| 8 | 单元测试主要用什么方法? | 白盒测试 |
| 9 | 系统测试主要用什么方法? | 黑盒测试 |
| 10 | α测试和β测试的区别? | α在开发方场所,β在用户场所 |
| 11 | 圈复杂度公式? | V(G)=E-N+2 或 V(G)=P+1 |
| 12 | 条件组合覆盖的用例数? | 2^n(n为条件数) |
| # | 考点 | 答题要点 |
|---|---|---|
| 1 | 根据代码设计白盒测试用例 | 分析代码结构→确定覆盖标准→设计用例→列表展示 |
| 2 | 根据需求设计黑盒测试用例 | 划分等价类→确定边界值→设计用例→列表展示 |
| 3 | 计算McCabe圈复杂度 | 画控制流图→用公式计算→确定基本路径数 |
| 4 | 选择集成测试策略 | 分析风险→选择自顶向下/自底向上/三明治→说明理由 |
| 5 | 判断覆盖标准类型 | 根据测试用例覆盖情况判断满足哪个标准 |
| 考点 | 口诀 | 解释 |
|---|---|---|
| 覆盖标准排序 | "语句判定条判条路" | 语句→判定→条件→判定-条件→条件组合→路径 |
| 黑盒方法 | "等边因判场错" | 等价类、边界值、因果图、判定表、场景法、错误推测 |
| 测试阶段依据 | "单详集概系需确需" | 单元→详细,集成→概要,系统→需求,确认→需求 |
| 桩和驱动 | "上驱下桩" | 上面的用驱动模块,下面的用桩模块 |
| α和β测试 | "α在厂,β在外" | α在开发方场地,β在用户场地 |
| 测试vs调试 | "测找Bug,调修Bug" | 测试发现错误,调试修复错误 |
| 条件覆盖陷阱 | "条件覆盖不一定判定" | 条件覆盖不一定满足判定覆盖 |
| 维度 | 内容 |
|---|---|
| 关注点 | 程序内部结构 |
| 依据 | 代码结构 |
| 方法 | 6种覆盖标准 |
| 阶段 | 主要用于单元测试 |
| 优点 | 覆盖全面,发现深层错误 |
| 缺点 | 需要代码,工作量大 |
| 维度 | 内容 |
|---|---|
| 关注点 | 输入输出功能 |
| 依据 | 需求规格 |
| 方法 | 6种黑盒方法 |
| 阶段 | 主要用于系统/验收测试 |
| 优点 | 不需代码,贴近用户 |
| 缺点 | 覆盖可能不充分 |
📚 相关笔记链接
[[需求工程总结]] [[UML图总结]] [[软件过程模型]] [[架构描述与评估总结]]
📅 生成日期:2026-05-15 | 📝 基于软件测试总结.md补充整理