软件测试 · 考点笔记

📅 日期:2026-05-15

📚 科目:软件设计师 · 软件工程

🏷️ 标签: 软件测试白盒测试黑盒测试 覆盖标准测试阶段

⭐ 重要度:高频考点(选择题 + 案例分析必考)

📋 目录导航

一、测试概述与分类

1.1 软件测试的目的

📝 经典考题

问:软件测试的目的是什么?

答:发现程序中的错误。(不是证明程序没有错误!)

陷阱:"证明软件正确"是错误说法,测试只能证明软件有错,不能证明无错。

1.2 测试分类总览

静态测试

不运行程序,通过人工审查或计算机辅助分析

方法检查内容
控制流分析没有使用的语句、无法到达的语句
数据流分析引用未定义的变量
接口分析接口一致性、函数参数一致性

包括:代码审查、走查、静态分析工具

动态测试

运行程序,检查实际输出与预期结果的差异

类型特点
白盒测试关注内部结构(结构测试)
黑盒测试关注输入输出(功能测试)
灰盒测试介于两者之间

包括:单元测试、集成测试、系统测试中执行的测试

📌 补充:静态测试 vs 动态测试对比
维度静态测试动态测试
是否运行程序不运行运行
发现错误阶段早期(编码阶段即可开始)后期(需要可执行程序)
成本低(越早发现越便宜)较高
覆盖率可覆盖所有代码受测试用例限制
典型方法代码审查、走查、静态分析白盒、黑盒、灰盒测试

1.3 测试V模型(重要补充)

📌 补充:V模型——测试阶段与开发阶段的对应关系

V模型是软件测试的经典模型,体现了测试与开发的对应关系:

开发阶段↕ 对应测试阶段测试依据
需求分析验收测试用户需求
概要设计系统测试需求规格说明书
详细设计集成测试概要设计文档
编码单元测试详细设计文档
💡 记忆要点

V模型的核心思想:每个开发阶段都有对应的测试阶段,测试计划应在对应的开发阶段就开始编写。

验收测试对应需求分析 → 系统测试对应概要设计 → 集成测试对应详细设计 → 单元测试对应编码。

二、白盒测试(结构测试)★★★

📝 考试重点

白盒测试是选择题和案例分析的必考内容,必须掌握:覆盖标准的强弱关系、测试用例设计、各标准的优缺点。

核心思想:关注程序内部结构和逻辑,基于代码结构设计测试用例。

2.1 六大覆盖标准(从弱到强)

🎯 强弱排序(必背!)

语句覆盖 < 判定覆盖 < 条件覆盖 < 判定-条件覆盖 < 条件组合覆盖 < 路径覆盖

口诀:"语句判定条判条路"

覆盖强度可视化
语句覆盖
最弱
判定覆盖
条件覆盖
判定-条件覆盖
条件组合覆盖
路径覆盖
最强

2.2 语句覆盖(Statement Coverage)

项目内容
定义设计测试用例使程序中每条可执行语句至少被执行一次
强度最弱
缺点无法发现逻辑运算中的错误(如 && 写成 ||
覆盖目标每条语句至少执行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 的情况!

2.3 判定覆盖(Decision Coverage)/ 分支覆盖

项目内容
定义设计测试用例使程序中每个判定的真假分支至少执行一次
强度比语句覆盖强
缺点忽略了判定中条件的组合(如 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 的组合

2.4 条件覆盖(Condition Coverage)

项目内容
定义设计测试用例使每个判定中每个条件的可能取值至少执行一次
强度比判定覆盖强(某些情况下)
缺点不一定满足判定覆盖!(条件覆盖 ≠ 判定覆盖)
覆盖目标每个简单条件的 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。

2.5 判定-条件覆盖(Decision-Condition Coverage)

项目内容
定义同时满足判定覆盖条件覆盖
强度比单独的判定覆盖和条件覆盖强
缺点忽略了条件的组合情况(如 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.6 条件组合覆盖(Condition Combination Coverage)

项目内容
定义设计测试用例使每个判定中条件的所有可能组合至少执行一次
强度比判定-条件覆盖强
缺点测试用例数量增长快(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个测试用例覆盖所有组合
// 注意:条件组合覆盖不一定是路径覆盖!

2.7 路径覆盖(Path Coverage)

项目内容
定义设计测试用例使程序中所有可能的路径至少执行一次
强度最强
缺点测试用例数量可能很大,循环结构路径无限
覆盖目标每条独立路径至少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个测试用例

2.8 覆盖标准综合对比

覆盖标准覆盖目标强度优点缺点
语句覆盖 每条语句至少1次 最弱 简单,容易实现 无法发现逻辑错误
判定覆盖 每个判定真假各1次 较弱 覆盖了分支 忽略条件组合
条件覆盖 每个条件真假各1次 中等 覆盖了每个条件 不一定满足判定覆盖
判定-条件覆盖 判定覆盖+条件覆盖 较强 同时满足判定和条件 忽略条件组合
条件组合覆盖 所有条件组合各1次 覆盖所有组合 用例数增长快(2^n)
路径覆盖 所有路径各1次 最强 全面覆盖逻辑 循环路径无限
📌 补充:MC/DC覆盖(修正条件判定覆盖)

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)
汇合节点有多条入边的节点

圈复杂度(Cyclomatic Complexity)计算

圈复杂度用于衡量程序的复杂程度,也等于基本路径数(即路径覆盖至少需要的测试用例数)。

公式说明
V(G) = E - N + 2E=边数,N=节点数
V(G) = P + 1P=判定节点数(有两条出边的节点数)
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. 覆盖标准强弱排序:语句 < 判定 < 条件 < 判定-条件 < 条件组合 < 路径
  2. 条件覆盖不一定满足判定覆盖:这是最常见的陷阱
  3. 路径覆盖不适用于循环:循环结构导致路径无限
  4. 圈复杂度 = 基本路径数 = 最少测试用例数
  5. 条件组合覆盖用例数 = 2^n(n为条件数)

三、黑盒测试(功能测试)★★★

核心思想:关注输入输出,不关心内部结构,基于需求规格设计测试用例。

🎯 黑盒方法速记

"等边因判场错" = 等价类、边界值、因果图、判定表、场景法、错误推测

3.1 等价类划分

原理与方法

将输入数据划分为若干等价类,从每个类中选取代表值作为测试用例。同一等价类中的数据发现错误的能力相同。

类型定义示例(输入范围1-100)
有效等价类合理的、有意义的输入数据1-100之间的整数
无效等价类不合理的、无意义的输入数据<1的数、>100的数、非数字
📌 补充:等价类划分原则
输入条件有效等价类无效等价类
取值范围(如1-100)范围内值(如50)范围外值(如0, 101)
枚举值(如男/女)枚举范围内(男、女)枚举范围外(其他)
布尔值(是/否)True / False无(布尔只有两个值)
规定个数(如1-5个)规定范围内(如3个)范围外(如0个、6个)
必须满足条件满足条件的值不满足条件的值

3.2 边界值分析

原理与方法

选取边界值作为测试用例。经验表明,错误往往发生在输入范围的边界上。

概念定义示例(范围 [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个典型值)

等价类 + 边界值 组合使用效果最佳!

3.3 错误推测

原理与方法

基于经验和直觉推测程序中可能存在的错误,列举容易发生错误的特殊情况。

常见错误场景测试输入
空值处理输入为空、null
零值处理输入为0
负数处理输入为负数
类型转换输入类型不匹配
特殊字符输入包含特殊字符(如SQL注入字符)
超长输入输入超过最大长度
重复操作重复提交、重复点击

3.4 因果图

原理与步骤

分析输入条件()和输出结果()之间的关系,将自然语言描述转化为逻辑表达式。

  1. 分析所有输入条件和输出结果
  2. 画出因果图(用逻辑符号连接因和果)
  3. 将因果图转换为判定表
  4. 根据判定表设计测试用例
📌 补充:因果图的逻辑符号
符号名称含义示例
E (互斥)Exclusive原因中最多一个为真单选按钮(只能选一个)
I (包含)Inclusive原因中至少一个为真复选框(至少选一个)
O (唯一)One and only原因中恰好一个为真必选单选按钮
R (要求)Require若A为真则B也必须为真选了VIP就必须选会员
M (屏蔽)Mask若A为真则B必须为假选了现金支付就不能选信用卡

3.5 判定表

原理与组成

分析多个输入条件的组合对输出的影响,用表格形式列出所有条件组合。

组成部分说明
条件桩列出所有输入条件
动作桩列出所有输出结果/操作
条件项输入条件的取值组合(T/F)
动作项每种组合对应的输出结果
📌 补充:判定表构造示例

需求:用户登录系统,输入用户名和密码。用户名正确且密码正确→登录成功;用户名正确但密码错误→提示密码错误;用户名错误→提示用户不存在。

判定表
条件\规则规则1规则2规则3规则4
用户名正确TTFF
密码正确TFTF
登录成功
提示密码错误
提示用户不存在

规则4可与规则3合并(用户名错误时密码是否正确不影响结果)→ 判定表化简

3.6 场景法

原理与步骤

模拟用户操作场景,通过分析基本流备选流来设计测试用例。

概念定义示例(电商下单)
基本流从开始到结束的正常流程选商品→加入购物车→结算→支付→成功
备选流偏离基本流的异常/分支流程库存不足、支付失败、地址无效等
📌 补充:场景法设计示例
场景描述测试用例
场景1(基本流)正常下单成功选有库存商品→正确地址→支付成功
场景2(备选流1)商品无库存选无库存商品→提示库存不足
场景3(备选流2)支付失败选有库存商品→正确地址→支付失败→重试
场景4(备选流3)地址无效选有库存商品→无效地址→提示错误

3.7 黑盒方法综合对比

方法适用场景优点缺点
等价类划分输入数据有明确范围或类型减少测试用例数可能遗漏边界错误
边界值分析输入数据有数值边界发现边界错误高效只关注边界,不关注内部
错误推测经验丰富时发现特殊错误依赖经验,不够系统
因果图输入条件有逻辑关系考虑条件组合复杂条件时图很大
判定表输入条件组合影响输出系统全面条件多时表很大
场景法有明确业务流程贴近实际使用难以覆盖所有路径

四、测试阶段 ★★

4.1 四大测试阶段对比

阶段依据文档测试对象主要方法执行者
单元测试 详细设计文档 模块(函数、类) 白盒测试为主 开发人员
集成测试 概要设计文档 模块间接口 灰盒测试 开发/测试人员
系统测试 需求规格说明书 整个系统 黑盒测试 独立测试团队
确认测试(验收测试) 需求规格说明书 / 用户需求 软件产品 黑盒测试 用户/客户
🎯 记忆口诀

"单详集概系需确需"

单元→详细设计,集成→概要设计,系统→需求规格,确认→需求规格/用户需求

4.2 单元测试详解

单元测试五要素
测试内容说明示例
模块接口参数传递、返回值传入null是否报错
局部数据结构变量初始化、数据类型数组越界、溢出
边界条件循环边界、数组边界空数组、单元素数组
独立路径程序中的执行路径覆盖所有分支
错误处理异常捕获和处理除零异常、文件不存在
📌 补充:桩模块与驱动模块(常考概念)

单元测试时,被测模块可能依赖其他模块,需要用桩模块驱动模块来模拟。

驱动模块(Driver)

模拟调用者,用来调用被测模块

相当于"测试主程序"

例:测试函数B时,写一个main()调用B

桩模块(Stub)

模拟被调用者,代替被测模块依赖的模块

相当于"替身"

例:函数B调用函数C,用桩模块代替C

💡 记忆技巧

驱动模块 = 调用被测模块的"上级"(模拟调用者)

桩模块 = 被测模块调用的"下级"(模拟被调用者)

口诀:"上驱下桩"(上面驱动,下面打桩)

4.3 集成测试策略详解

三种集成策略

自顶向下集成

项目内容
顺序从主控模块开始,沿控制层次向下,逐层集成
方式深度优先 或 广度优先
需要桩模块(代替未集成的下层模块)
优点早期验证主要控制逻辑,故障隔离容易
缺点需要大量桩模块,底层模块测试不充分

自底向上集成

项目内容
顺序从最底层模块开始,逐层向上集成
方式先测试叶子模块,再测试上层模块
需要驱动模块(代替未集成的上层模块)
优点不需要桩模块,底层模块测试充分
缺点需要大量驱动模块,主控逻辑测试较晚

三明治集成(混合集成)

项目内容
方式结合自顶向下和自底向上,从中间层开始集成
需要同时使用桩模块和驱动模块
优点兼顾两者的优点,效率最高
缺点需要同时开发桩和驱动,工作量大
📌 补充:三种集成策略对比
策略需要桩需要驱动测试顺序适用场景
自顶向下从顶层到底层主控逻辑重要
自底向上从底层到顶层底层逻辑重要
三明治从中间向两端综合考虑

4.4 系统测试详解

系统测试类型
类型内容示例
功能测试验证系统功能是否符合需求登录、注册、下单等
性能测试验证系统性能指标响应时间、吞吐量、并发数
安全测试验证系统安全性渗透测试、漏洞扫描
兼容性测试验证系统兼容性浏览器兼容、OS兼容
压力测试验证系统极限承载能力100万并发用户
恢复测试验证系统故障恢复能力断电恢复、数据库恢复

4.5 确认测试(验收测试)

📌 补充:验收测试的类型
类型说明参与者
α测试用户在开发方场所进行测试用户 + 开发人员
β测试用户在自己场所进行测试用户(开发人员不在场)
正式验收测试按验收标准严格测试用户 + 第三方
💡 α vs β 区别

α测试:在开发方场地,开发人员在旁(可控)

β测试:在用户场地,开发人员不在(真实环境)

记忆:"α在厂,β在外"

4.6 灰盒测试

项目内容
定义介于白盒和黑盒测试之间
特点关注输入输出,也关注内部结构
应用主要用于集成测试和系统测试
方法结合白盒的结构分析和黑盒的功能验证

五、补充考点

5.1 回归测试

📌 补充:回归测试(高频考点)
项目内容
定义修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
目的确保修改不会影响原有功能
触发时机代码修改、缺陷修复、环境变更
策略全部重新测试 / 选择性重新测试(基于影响分析)
自动化通常使用自动化测试工具提高效率

5.2 测试用例设计

📌 补充:测试用例的基本要素
要素说明示例
用例编号唯一标识TC-LOGIN-001
用例标题简要描述测试目的验证正确用户名密码登录成功
前置条件执行用例前的准备用户已注册
输入数据测试输入用户名:admin, 密码:123456
执行步骤操作步骤1.打开登录页 2.输入用户名密码 3.点击登录
预期结果期望的输出登录成功,跳转首页
实际结果实际执行后的输出(执行后填写)
优先级用例重要程度P0(最高)/ P1 / P2

5.3 软件调试

📌 补充:调试方法(常考)
方法说明特点
蛮力法利用"计算机找错",打印内存、设置断点效率低,但常用
回溯法从错误点出发,沿控制流回溯追踪错误原因适合小程序
原因排除法演绎和归纳,缩小错误原因范围效率最高
💡 测试 vs 调试

测试:发现错误(找Bug)

调试:定位和修复错误(修Bug)

先测试发现错误,再调试定位和修复错误。

5.4 面向对象测试

📌 补充:面向对象测试的层次
层次测试对象对应传统测试说明
算法层类中的方法单元测试测试单个方法的正确性
类层类(封装)单元测试测试类的方法交互、状态变化
模板层/类族层继承、多态集成测试测试继承层次和多态行为
系统层整个系统系统测试测试系统整体功能

5.5 测试相关度量

📌 补充:缺陷相关度量指标
指标公式说明
缺陷密度缺陷数 / 代码行数(或功能点数)衡量代码质量
缺陷发现率发现缺陷数 / 测试用例数衡量测试效率
缺陷修复率已修复缺陷数 / 总缺陷数衡量开发效率
测试覆盖率已覆盖代码 / 总代码衡量测试充分性

六、案例分析答题模板

6.1 白盒测试用例设计

答题模板:根据代码设计测试用例

步骤:

  1. 分析代码结构:画出控制流图,确定判定节点和路径
  2. 确定覆盖标准:根据题目要求选择覆盖标准
  3. 设计测试用例
    • 语句覆盖:确保每条语句至少执行1次
    • 判定覆盖:确保每个判定的True和False各执行1次
    • 条件覆盖:确保每个简单条件的True和False各执行1次
    • 路径覆盖:确保每条独立路径各执行1次
  4. 列表展示:用表格列出测试用例编号、输入值、预期输出、覆盖路径

答题格式示例:

用例编号输入(A,B,X)预期输出覆盖路径/分支
TC1A=1, B=1, X=1X=1判定True分支
TC2A=-1, B=1, X=1X=2判定False分支

6.2 黑盒测试用例设计

答题模板:根据需求设计测试用例

步骤:

  1. 分析输入条件:列出所有输入参数及其取值范围
  2. 划分等价类:为每个输入参数划分有效等价类和无效等价类
  3. 确定边界值:找出每个输入参数的边界值
  4. 设计测试用例
    • 覆盖所有有效等价类
    • 覆盖所有无效等价类
    • 覆盖所有边界值
  5. 列表展示:用表格列出测试用例

6.3 McCabe圈复杂度计算

答题模板:计算圈复杂度并设计基本路径测试

步骤:

  1. 画控制流图:将代码转化为控制流图
  2. 计算圈复杂度
    • 方法一:V(G) = E - N + 2(E=边数,N=节点数)
    • 方法二:V(G) = P + 1(P=判定节点数)
  3. 确定基本路径数:V(G) = 基本路径数 = 最少测试用例数
  4. 设计测试用例:为每条基本路径设计一个测试用例

6.4 集成测试策略选择

答题模板:选择集成测试策略

情况推荐策略理由
主控逻辑风险高自顶向下优先验证顶层控制逻辑
底层模块风险高自底向上优先验证底层模块
需要快速验证三明治中间层开始,双向集成
模块依赖简单大爆炸所有模块一起集成(简单但风险高)

七、高频考点速记 & 口诀

7.1 选择题高频考点

#考点答案
1软件测试的目的是什么?发现程序中的错误(不是证明正确)
2覆盖标准从弱到强排序?语句<判定<条件<判定-条件<条件组合<路径
3条件覆盖是否一定满足判定覆盖?不一定!(最常见陷阱)
4路径覆盖的局限性?循环结构路径无限
5单元测试的依据文档?详细设计文档
6集成测试的依据文档?概要设计文档
7系统测试的依据文档?需求规格说明书
8单元测试主要用什么方法?白盒测试
9系统测试主要用什么方法?黑盒测试
10α测试和β测试的区别?α在开发方场所,β在用户场所
11圈复杂度公式?V(G)=E-N+2 或 V(G)=P+1
12条件组合覆盖的用例数?2^n(n为条件数)

7.2 案例分析高频考点

#考点答题要点
1根据代码设计白盒测试用例分析代码结构→确定覆盖标准→设计用例→列表展示
2根据需求设计黑盒测试用例划分等价类→确定边界值→设计用例→列表展示
3计算McCabe圈复杂度画控制流图→用公式计算→确定基本路径数
4选择集成测试策略分析风险→选择自顶向下/自底向上/三明治→说明理由
5判断覆盖标准类型根据测试用例覆盖情况判断满足哪个标准

7.3 口诀汇总

考点口诀解释
覆盖标准排序"语句判定条判条路"语句→判定→条件→判定-条件→条件组合→路径
黑盒方法"等边因判场错"等价类、边界值、因果图、判定表、场景法、错误推测
测试阶段依据"单详集概系需确需"单元→详细,集成→概要,系统→需求,确认→需求
桩和驱动"上驱下桩"上面的用驱动模块,下面的用桩模块
α和β测试"α在厂,β在外"α在开发方场地,β在用户场地
测试vs调试"测找Bug,调修Bug"测试发现错误,调试修复错误
条件覆盖陷阱"条件覆盖不一定判定"条件覆盖不一定满足判定覆盖

7.4 易错点总结

⚠️ 考试易错点
  1. 条件覆盖 ≠ 判定覆盖:条件覆盖不一定满足判定覆盖,这是最常见的陷阱。
  2. 语句覆盖最弱,路径覆盖最强:排序题必考,必须牢记。
  3. 路径覆盖不适用于循环:循环结构导致路径无限,无法完全覆盖。
  4. 测试不能证明软件正确:测试只能发现错误,不能证明没有错误。
  5. 单元测试用白盒,系统测试用黑盒:不要搞反。
  6. 集成测试用灰盒:不是白盒也不是黑盒,是灰盒。
  7. α测试在开发方,β测试在用户方:不要搞反。
  8. 回归测试不是重新测试:回归测试是修改后确认不影响原有功能。
  9. 圈复杂度 = 最少测试用例数:V(G)表示基本路径覆盖所需的最少用例数。
  10. 条件组合覆盖用例数 = 2^n:条件多时用例数增长很快,这是它的缺点。

7.5 白盒 vs 黑盒综合对比

白盒测试

维度内容
关注点程序内部结构
依据代码结构
方法6种覆盖标准
阶段主要用于单元测试
优点覆盖全面,发现深层错误
缺点需要代码,工作量大

黑盒测试

维度内容
关注点输入输出功能
依据需求规格
方法6种黑盒方法
阶段主要用于系统/验收测试
优点不需代码,贴近用户
缺点覆盖可能不充分

📚 相关笔记链接

[[需求工程总结]] [[UML图总结]] [[软件过程模型]] [[架构描述与评估总结]]

📅 生成日期:2026-05-15 | 📝 基于软件测试总结.md补充整理