#第7章01 软件测试概述

#3.1 本章定位

本章建立软件测试的总体框架：测试是什么、测试过程有哪些阶段、测试有哪些分类、测试为什么需要多种策略，以及软件测试的三大核心问题。后续黑盒、白盒、回归、性能测试都是本章框架下的具体方法。

#3.2 核心概念

#软件测试定义

广义上，软件测试是一种软件正确性、完整性、安全性和质量的检查过程。

​ 静态测试泛指其他的软件缺陷检测（V&V）技术，包括技术评审、程序分析、形式化验证、软件度量

​ 但动态测试才是真正意义上的软件测试。

狭义上，软件测试是为了发现错误或缺陷而执行某个程序或软件系统的过程。

重要判断：

• 测试的目的：证明程序有错，而不是证明程序无错误。
• 测试没有发现错误，不能说明程序中一定没有错误。

#测试用例

执行软件测试首先必须有测试用例，然后根据测试用例运行程序，以发现程序或软件可能存在的潜在错误。

测试用例可以基于需求文档/需求模型、设计文档/设计模型、程序代码，通过手工或自动方式生成。

测试用例是对一项特定软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。简单理解：

课件表述中，测试用例包括一组测试输入、执行条件以及预期结果。

一个完整测试用例通常不只包含输入和预期结果，还可以包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等内容，并最终形成测试文档。

#3.3 软件测试过程 STLC

软件测试过程又称软件测试生命周期（Software Test Life Cycle, STLC），从测试项目计划建立到所有测试结束，一般包括七个阶段。

一般来说包括测试需求分析、测试计划制定、测试设计、测试开发、测试执行、测试结果分析与评估、测试报告生成七个阶段

#软件测试过程（STLC）

测试计划制定补充：

• 测试策略/手段需要明确：基于代码覆盖策略的测试、基于规约的测试，还是基于状态的测试。
• 辅助工具包括：测试管理工具、测试设计工具、缺陷跟踪工具、数据库工具、性能测试工具等。
• 交付物一般包括：测试计划、测试环境、测试包、测试日志、缺陷报告等。

测试结果分析与评估补充：

• 覆盖情况：测试用例覆盖情况、代码覆盖率、语句覆盖率等。
• 缺陷情况：缺陷类型、缺陷分布、缺陷趋势、缺陷状态。
• 缺陷状态可按：记录、提交、修改、测试、关闭。
• 最后评估是否达到测试停止标准或成功标准，本质上属于测试充分性评估。

#3.4 软件测试分类

#按实施主体分类

软件测试根据由谁来测试分成

#开发者测试细化

开发者测试主要发生在软件开发过程中，包括单元测试、集成测试、系统测试、确认测试、回归测试。

1. 单元测试：单元测试在最低级别完成，测试软件的最基本单元。

软件单元是软件设计说明中一个可独立测试的元素，是程序中逻辑上独立的部分。

单元测试主要测试 5 个方面：模块接口测试；局部数据结构测试；路径测试；错误处理测试；边界测试。

单元测试充分性要求：

• 语句覆盖达到 100%；
• 分支覆盖达到 100%；
• 错误路径处理达到 100%；
• 单元的软件特性覆盖；
• 各种数据特性覆盖。

2. 集成测试：集成测试又称组装测试或联合测试，是单元测试的多级扩展。它将已经通过单元测试的模块按照设计要求逐步装配成高层功能模块，直到形成完整软件系统。

集成测试方法主要有两种：

• 一次性组装方式：先分别完成各模块单元测试，再把通过测试的模块一次性组装后测试。
• 渐增式测试：不是独立测试每个单元，而是把下一个待测单元与已经测试过的单元集合组装起来，边连接边测试。典型方式包括自顶向下和自底向上。

3. 系统测试：系统测试是为了判断系统是否符合规定而对集成的软硬件系统进行的测试活动。测试对象是完整的、集成的计算机系统，重点是新开发的软件配置项集合。

系统测试过程包括：制定系统测试计划、设计测试用例、实施系统测试、执行系统测试、评估系统测试。

系统测试的核心目的包括验证系统完整性、评估非功能性指标，为验收测试铺路。

4. 确认测试：确认测试是在完成集成测试之后，依据确认测试准则，针对软件需求规格说明进行的测试，用于确认软件系统是否满足规定的功能和性能需求。

5. 回归测试：回归测试是在软件维护或修改之后，为检测代码修改是否引入新错误而进行的测试。它用于确认修改是否达到预期目的，并检查修改是否破坏原有功能。

回归测试可以发生在任何一个阶段包括单元测试，集成测试和系统测试等

回归测试一般步骤：制定回归测试策略；确定需要回归测试的版本；按策略执行回归测试；测试通过则关闭缺陷跟踪单；测试不通过则返回开发人员修改，再次提交测试。

#用户测试补充

用户测试一般发生在验收测试阶段，与开发者在开发环境下测试不同，用户测试在实际使用环境或模拟使用环境下完成。

用户或志愿者通过使用软件来观察或体会：功能正确性；性能；可靠性；安全性等实际情况。

用户测试有时又称 Beta 测试，早期用户经验会反馈给开发者，帮助其在正式发布商业版本前进行最终修改。

#第三方测试补充

第三方测试的目的在于保证测试工作的客观性。

常见情况：

• 开发团队测试力量薄弱，委托测试公司完成全部或部分测试；
• 用户测试力量薄弱，在验收或安装使用过程中委托测试机构代测；
• 软件产品需要上市许可或面向广泛用户群体时，由权威机构进行测试。

第三方测试可能包括： 需求分析审查、设计审查、代码审查、单元测试、功能测试、性能测试、可恢复性测试、资源消耗测试、并发测试、健壮性测试、安全测试、安装配置测试、可移植性测试、文档测试、最终验收测试等。

#按内部结构可见程度分类

注意：灰盒测试结合内部结构信息和外部行为，但不能简单认为“灰盒测试 = 白盒测试 + 黑盒测试”。

#3.5 常见测试类型

课件按照需求类型引出多种测试：

• 功能性需求：结构测试、功能测试、安全性测试、容错测试等；
• 质量需求：性能测试、压力测试、兼容性测试、可维护性测试等；
• 其他需求：标准符合度测试、GUI 测试、字体大小和颜色测试等。

#常见的软件测试类型汇总

#安全性测试补充：

软件漏洞主要来源包括：

• 设计漏洞：如错误或缺失的访问控制机制、未保护的数据管道等；
• 代码漏洞：如 C/C++ 中使用 gets() 导致缓冲区溢出、进程间竞争条件等。

安全保障方法还包括：漏洞扫描、安全扫描、安全审计、风险评估、道德入侵、姿势评估等。

#可靠性测试补充：

软件可靠性测试就是根据软件结构可靠性、软件寿命以及可靠性试验信息，再利用概率统计方法，对软件可靠性做出的评估

可靠性测试方法：故障注入法，异常值输入法，压力测试法和稳定性测试法

可靠性测试步骤：制定测试计划；测试准备；测试实施；测试分析。

软件可靠性测试不同于一般功能测试：

• 按实际使用的概率分布随机选择输入数据；
• 需要准确记录软件运行时间；
• 输入覆盖要求通常高于普通功能测试；
• 对使用环境覆盖要求更高，尤其是容错软件、实时嵌入式软件等。

#可用性测试补充：

可用性测试不仅评价 GUI 设计，还包括用户对系统功能和信息架构的理解。 可用性问题可以分为：

• 概念层面：导航、用户定位、UI 一致性；
• 详细设计层面：GUI 标准、术语、具体交互问题。

#3.6 软件测试有效策略

课件强调单一测试技术难以满足所有测试需求，应组合使用：

• 静态测试与动态测试结合；
• 黑盒测试与白盒测试结合；
• 内部测试与外部测试结合；
• 整体测试与局部测试结合等。

#静态与动态测试结合策略

#静态测试补充：

静态测试一般不执行被测代码，而是利用软件项目信息、过程信息、制品信息以及相关人员信息来检测软件是否存在缺陷。

典型静态测试包括：技术评审；代码审计；静态分析；软件度量；形式化验证。

#动态测试补充：

动态测试通过运行被测程序，检查运行结果与预期结果是否存在差异，以判断是否存在缺陷。动态测试效率和自动化程度较高，但需要测试用例，并面临测试用例生成、测试预言、测试充分性三大难题。

#白盒与黑盒测试结合策略

黑盒与白盒结合的理由：

• 白盒测试检查内部结构，可针对代码逻辑；
• 黑盒测试观察外部行为，可发现需求实现问题；
• 二者结合可以更全面发现缺陷。
• 课件中还特别提到了一种结合了白盒与黑盒优点的 灰盒测试 (Grey-box test) 。它不仅关注输入输出的正确性，也关注程序内部的逻辑覆盖，在集成测试阶段非常适用，但不能简单地将其理解为“灰盒 = 白盒 + 黑盒” 。

#内部与外部测试结合策略

#内部测试 / 外部测试补充：

• 内部测试相当于 Alpha 测试，一般由开发部门内部组织。
• 外部测试也称公测，有时等同于 Beta 测试，由用户、第三方或独立机构参与。
• 内部测试强调充分性、专业性和可信性；外部测试强调真实用户体验和客观反馈。

#局部与整体测试结合策略

#3.7 软件测试典型方法

五类软件测试典型方法：

#3.7.1 组合测试

#1. 基本定义

组合测试是一种测试组合的功能性测试方法。

组合可以包括：硬件的组合；软件的组合；软件功能的组合；程序输入的组合。

组合测试的目的，是测试软件在不同组合环境下是否能够正常运行，是否存在与组合相关的问题。

需要注意：组合测试的测试对象不是单独的零散模块，而是那些已经通过单元测试的模块的组合。

#2. 为什么需要组合测试

在大规模软件系统中，影响系统运行的参数可能很多，每个参数的取值也可能很多。

组合测试的核心思想是：从庞大的参数组合空间中，选取尽量少的测试组合，也就是测试用例，以较低成本覆盖各种参数组合对系统的影响。

组合测试目标是：从待测软件的参数组合空间中，选取尽量少的测试组合（也就是测试用例），可以很好的覆盖各种参数组合对软件系统的影响，从而实现科学高效软件测试。

组合测试的核心问题是：如何选择测试组合，生成有效测试用例，实现高质量的测试覆盖和测试效果。

组合测试用例生成时，需要重点考虑以下几个问题：

1. 生成测试用例的规模：生成的测试用例越少，测试所需成本越低。
2. 生成测试用例所需时间
3. 算法结果是否可以重现
4. 是否支持约束与指定：算法是否能够在用户指定部分测试用例的基础上，继续添加约束，生成符合用户要求的新测试用例集。
5. 生成规模是否有明确上界

#3. 组合数量计算

假设待测软件系统有 $k$ 个待测参数，第 $i$ 个参数的取值个数为 $n(i)$，其中：$1 \leq i \leq k$

则所有可能的组合总数为：$\prod_{i=1}^{k} n(i)$

如果所有参数的取值个数都相同，即：$n(i)=n$

则组合总数为：$n^k$

这说明组合数量会随着参数个数和取值个数快速增长，形成组合爆炸问题。

#3.7.2 随机测试

#1. 基本定义

随机测试是一种黑盒测试。

随机测试是一种不要求有书面测试用例、记录期望结果、检查列表、脚本或指令的测试

随机测试主要是对被测软件的一些重要功能、性能等进行复测（retest）

随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试

在随机测试中，测试人员不查看软件产品内部代码，而是在被测系统中通过随机输入来查看结果。

理论上，每一个被测软件版本都需要执行随机测试，尤其是最后即将发布的版本，更应该重视随机测试。

#2. 随机测试人员需要具备的条件

随机测试对测试人员经验要求较高。测试人员应具备以下条件：

1. 熟悉产品的各项功能和产品逻辑；
2. 熟悉测试用例；
3. 完整执行过测试用例；
4. 熟悉用例测试阶段发现的缺陷及其分布；
5. 具备一定测试经验，善于发现细微缺陷。

随机测试越依赖经验，测试人员越熟悉被测软件，随机测试越容易发现问题。

#3. 随机测试点的选取准则

随机测试不是毫无目标地乱测，而是应重点选择高风险区域。

测试点选取准则包括：

1. 缺陷比较密集的功能板块：缺陷密集区域往往出现新缺陷的概率更高。
2. 一次性缺陷或重现率较低缺陷涉及的功能板块：低重现率缺陷通常隐藏较深，不易发现，但可能造成严重后果。
3. 通过与程序员沟通发现的薄弱模块：测试人员可以根据开发人员反馈，重点测试软件薄弱之处。

#3.7.3 蜕变测试

#1. 基本定义

蜕变测试是一种特殊的黑盒测试方法。

蜕变测试依据被测软件的领域知识和软件实现方法，建立蜕变关系：

然后利用蜕变关系生成新的测试用例，并通过验证蜕变关系是否被保持来判断测试是否通过。

蜕变关系指：多次执行目标程序时，输入与输出之间期望遵循的关系。

蜕变测试不一定直接判断某一次输出是否绝对正确，而是判断多组输入输出之间是否满足某种应有关系。

蜕变测试常用于解决测试预言困难的问题。当我们很难直接知道某个输入的准确预期输出时，可以通过构造输入输出之间的必要关系来间接判断程序是否正确。

#2. MR 的形式化理解

假设程序 $P$ 主要实现函数 $f$ 的功能。

设：$x_1, x_2, \ldots, x_n$

是函数 $f$ 的 $n$ 个自变量，对应的输出为：$f(x_1), f(x_2), \ldots, f(x_n)$

如果输入之间满足关系式 $r$，并且输出之间满足关系式 $R$，则：$(r, R)$

称为程序 $P$ 的一种蜕变关系。

通俗理解：输入之间满足某种关系时，输出之间也应该满足某种对应关系。

#3. 蜕变测试例子

假设被测程序 $P$ 用来计算指数函数：$f(x)=e^x$

根据指数函数性质，可以构造蜕变关系：$e^x \times e^{-x} = 1$

如果原始测试用例为：$t_i = 0.3$

则根据蜕变关系可以得到衍生测试用例：$t_i' = -0.3$

执行程序后，如果：$P(0.3) \times P(-0.3) = 1$

成立，则说明满足蜕变关系，测试通过。

如果不成立，则说明程序 $P$ 中可能存在错误。

#3.7.4 演化测试

#1. 基本定义

演化测试旨在利用遗传算法，在待测软件的输入空间中进行启发式搜索，以较高效率获得满足测试目标的测试用例。

它的特点是：高效性；自动化水平高；可以降低测试成本；可以提高测试质量。

演化测试将测试用例生成任务转化为一个优化问题。

转化的关键在于如何量化地表示测试目标，即根据指定测试目标，设置适应值函数，评估不同测试用例的质量，合理的指导搜索的进行

常见演化测试类型包括：结构性演化测试；功能性演化测试；性能演化测试。

#3.7.5 变异测试

#1. 基本定义

变异测试是一种评估软件测试质量的方法。

其核心思想是：通过故意向程序中植入错误，检验现有测试用例能否发现这些错误。

如果现有测试用例能够发现人为植入的小错误，说明测试用例集质量较高；如果发现不了，则说明测试用例集可能不充分，需要补充新的测试用例。

变异操作是其中主要任务之一。

变异操作主要是利用变异算子生成变异体。

变异算子 mutation operator：定义如何从原程序生成差异很小的新程序的转换规则

变异体 mutant / mutation：对原程序执行变异算子后生成的新程序

#2. 变异算子和变异体

变异体通常只与原程序有很小差异，例如：

• 将算术运算符替换；
• 将逻辑运算符替换；
• 将关系运算符替换；
• 删除语句；
• 替换变量；
• 替换常量。

#3. 传统变异测试基本过程

传统变异测试过程包括：

1. 给定被测程序 $P$ 和测试用例集 $T$；
2. 根据被测程序特征设定一系列变异算子；
3. 在原程序 $P$ 上执行变异算子，生成大量变异体；
4. 从大量变异体中识别并排除等价变异体；
5. 在剩余的非等价变异体上执行测试用例集 $T$；
6. 如果测试用例能够检测出所有非等价变异体，则变异测试分析结束；
7. 如果仍有未检测出的变异体，则需要额外设计新的测试用例，并添加到测试用例集 $T$ 中。

#4. 变异测试例子

原程序片段：

if (a && b) c = 1;
else c = 0;

如果将逻辑运算符 && 替换为 ||，会产生变异体：

if (a || b) c = 1;
else c = 0;

要杀死这个变异体，需要满足两个条件：

1. 测试数据必须使原程序和变异体产生不同的内部状态 例如：

a = 1, b = 0

原程序中：

a && b = 0

变异体中：

a || b = 1

两者会导致不同的 c 值。

1. 差异必须传播到程序输出，并且被测试检查到 也就是说，仅仅内部状态不同还不够，测试用例还要能观察并判断输出差异。

#3.7.6 五种典型方法对比

#3.7.7 易混淆点

组合测试解决“组合太多怎么选”，随机测试解决“计划测试之外怎么补”，蜕变测试解决“预期结果难确定怎么判”，演化测试解决“测试用例怎么自动优化生成”，变异测试解决“测试用例质量怎么评价”。

最重要的考试记忆点：

1. 组合测试：从参数组合空间中选择尽量少的测试组合。
2. 随机测试：黑盒测试，是基于测试计划测试的重要补充。
3. 蜕变测试：核心是蜕变关系 MR，用于缓解测试预言问题。
4. 演化测试：利用遗传算法和适应值函数生成测试用例。
5. 变异测试：通过变异算子生成变异体，用来评估测试用例集质量。

#软件测试典型方法汇总

#3.8 软件测试三个核心问题

• 测试用例生成（test case generation）
• 测试预言（test oracle）
• 测试充分性（test coverage）

这三个问题共同决定测试质量：

#3.8.1 测试用例生成问题

测试用例（test case）是对一项特定软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

一个完整测试用例通常包括：测试目标；测试环境；输入数据；测试步骤；预期结果；测试脚本等。最终，测试用例需要形成文档。

简单理解：$测试用例 = 测试输入 + 执行条件 + 预期结果$

也可以记为：

其中：

• 测试输入：用于执行程序的数据或条件；
• 测试预言：用于判断执行结果是否正确的预期结果或判定依据。

#常见测试用例生成方法

课件将常见测试用例生成方法分为黑盒测试、白盒测试两大类。

常见黑盒测试用例生成方法包括：等价类划分法；边界值法；功能图法；错误推测法；因果图法；场景法等。

白盒测试又可以分为基于控制流和基于数据流两类。

​ 基于控制流的测试用例生成：语句覆盖；分支覆盖；条件覆盖；分支条件覆盖；条件组合覆盖；路径覆盖等。

​ 基于数据流的测试用例生成：所有定义使用路径覆盖；所有定义使用清洁路径覆盖等。

测试用例生成还可以根据使用技术分为三类：手工生成，半自动生成，自动生成

#3.8.2 测试预言问题

测试预言（test oracle）是指测试的预期结果。

在软件测试中，关键步骤是比较：$实际测试结果 \quad vs. \quad 预期结果$如果二者不一致，就说明被测程序可能存在错误。

很多情况下，精确的预期结果并不容易获得。于是就产生了测试预言问题。

测试预言问题在自动化测试中普遍存在，因为自动化测试不仅要自动执行输入，还要自动判断输出是否正确。

测试预言不能来自待测试系统自身。

其中：

• 测试输入：用来执行程序；
• 测试预言：用来检查测试输入执行后产生结果的正确性。

因此，测试预言是测试用例的一部分。

蜕变测试和变异测试是为了解决测试语言问题的两种有效方法

蜕变测试基于蜕变关系，变异测试基于变异算子。

#3.8.3 测试充分性问题

测试充分性（test coverage）问题本质上就是测试覆盖率问题。测试覆盖率是测试可信性的重要指标。

实际测试中常见覆盖率主要包括两大类：

• 需求覆盖率；需求覆盖率（requirement coverage）用于评估测试对需求的覆盖程度。
• 代码覆盖率：至少被执行了一次的代码条目数占整个代码条目数的百分比。

虽常见的代码覆盖率指标有：语句覆盖率，分支覆盖率，条件覆盖率，路径覆盖率

代码覆盖率最好适度，在条件允许的情况下尽可能高（一味追求高覆盖率可能导致测试用例冗余）

#3.8.4 三个核心问题之间的关系

完整的软件测试过程可以理解为：

#3.8.5 易混淆点

1. 测试用例生成：黑盒、白盒、手工、半自动、自动。
2. 测试预言：预期结果；不能来自待测系统自身。
3. 测试充分性：测试覆盖率问题；常见为需求覆盖率和代码覆盖率。
4. 代码覆盖率：语句覆盖率、分支覆盖率、条件覆盖率、路径覆盖率。
5. 覆盖率不是越高越绝对好，也不是低覆盖率一定不可接受，要结合测试目标和资源限制判断。

#3.9 本章复习检查题

#填空题

1. 软件测试过程一般包括测试需求分析、测试计划制定、测试设计、测试开发、测试执行、________和________七个阶段。
2. 软件测试的三个核心问题是________、和。
3. 测试预言是测试的________。

#选择题

1. 黑盒测试主要基于：A. 代码结构 B. 需求规格 C. 机器码 D. 调试日志
2. 下列关于测试的说法正确的是：A. 测试没有发现错误说明程序无错 B. 测试的目的之一是发现错误 C. 测试预言来自被测系统自身 D. 灰盒测试等于白盒加黑盒

#判断题

1. 测试覆盖率低不一定意味着测试充分性一定不可接受。
2. 黑盒测试可以发现需求文档不完整导致的功能缺失问题。
3. 测试预言可以直接使用被测系统自身作为唯一依据。

#参考答案

1. 填空：测试结果分析与评估、测试报告生成；测试用例生成、测试预言、测试充分性；预期结果。
2. 选择：B；B。
3. 判断：对；对；错。

#3.10 第7章01 总复习框架

这一章可以概括为一句话：

软件测试是以测试用例为核心，通过静态/动态、黑盒/白盒、内部/外部、局部/整体等多种策略和方法，对软件全生命周期中的功能、性能、安全、可靠性、兼容性、健壮性、可用性等方面进行缺陷发现和质量评估的活动，其核心问题是测试用例生成、测试预言和测试充分性。

#3.11 第7章01 客观题必背清单

#A. 填空题重点

1. 狭义软件测试是为了发现错误或缺陷而执行某个程序或软件系统的过程。
2. 动态测试才是真正意义上的软件测试。
3. 软件测试的目的是证明程序有错，而不是证明程序无错误。
4. 软件测试生命周期 STLC 包括：测试需求分析、测试计划制定、测试设计、测试开发、测试执行、测试结果分析与评估、测试报告生成。
5. 开发者测试包括：单元测试、集成测试、系统测试、确认测试、回归测试。
6. 单元测试五方面：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试。
7. 集成测试又叫组装测试或联合测试。
8. 集成测试方法包括一次性组装方式和渐增式测试。
9. 渐增式测试典型方式包括自顶向下和自底向上。
10. 用户测试一般发生在验收测试阶段，有时称 Beta 测试。
11. 第三方测试的目的是保证测试工作的客观性。
12. 结构测试又称白盒测试。
13. 功能测试又称黑盒测试。
14. 白盒测试包括控制流测试和数据流测试。
15. 黑盒测试代表方法包括功能分解法、等价类划分法、因果图判定表法、边界值分析法。
16. 性能测试指标包括 TPS、QPS、RT、ART、并发用户数、资源利用率。
17. 安全测试关注漏洞或脆弱性。
18. 可靠性是在规定条件和规定时间区间完成规定功能的能力。
19. 兼容性测试是非功能性测试。
20. 健壮性测试有时等同容错测试。
21. 可用性标准包括容易学习、使用效率、可记忆性、错误频率和严重程度、主观满意度。
22. 软件测试三个核心问题：测试用例生成、测试预言、测试充分性。
23. 1 个测试用例 = 1 个测试输入 + 1 个测试预言。

#B. 选择题重点

#C. 判断题易错点

#3.12 第7章01 主观题可能考法

虽然这章是概述，但也可能出情景型主观题。

#情景1：给一个软件项目，让你设计测试过程

答题模板：

1. 进行测试需求分析，明确需求点和测试要点；
2. 制定测试计划，明确目标、范围、测试项、策略、工具、资源和交付物；
3. 进行测试设计，设计测试用例、测试脚本和覆盖准则；
4. 进行测试开发，搭建环境、编写脚本、准备驱动/桩和测试数据；
5. 执行测试，记录日志和缺陷；
6. 分析评估结果，包括覆盖率、缺陷分布、停止/成功标准；
7. 生成测试报告，总结风险和遗留问题。

#情景2：给一个系统需求，让你选择测试类型

答题模板：

1. 功能是否正确：功能测试 / 黑盒测试；
2. 内部逻辑是否覆盖：结构测试 / 白盒测试；
3. 高并发响应是否正常：性能测试；
4. 是否存在漏洞：安全性测试；
5. 是否能长期稳定运行：可靠性测试；
6. 是否适配不同平台：兼容性测试；
7. 是否能处理非法输入和异常：健壮性测试；
8. 用户是否容易使用：可用性测试。

#情景3：给一个测试资源有限的项目，让你制定测试策略

答题模板：

1. 静态测试与动态测试结合：早期用评审/静态分析，后期运行测试；
2. 黑盒测试与白盒测试结合：既看需求功能，也看代码结构；
3. 内部测试与外部测试结合：先内测保障充分性，再外测获得真实用户反馈；
4. 局部测试与整体测试结合：先测模块、接口，再测集成系统；
5. 根据风险优先级选择重点测试项，例如安全、性能、核心业务路径。

#情景4：给一个测试用例设计问题，让你分析三大核心难点

答题模板：

1. 测试用例生成：如何选择合适输入、路径、条件或需求覆盖；
2. 测试预言：如何确定预期输出，是否能获得可靠 oracle；
3. 测试充分性：如何评估覆盖程度，如需求覆盖率、代码覆盖率。

#3.13 第7章01 最终记忆主线

你可以用下面这条线记住本章：

软件测试首先要明确定义和目的，然后按照 STLC 七阶段执行；测试贯穿全生命周期，由开发者、用户和第三方共同参与；测试类型包括结构、功能、性能、安全、可靠性、兼容性、健壮性和可用性；有效测试需要组合静态/动态、白盒/黑盒、内部/外部、局部/整体策略；典型方法包括组合、随机、蜕变、演化和变异测试；最终围绕测试用例生成、测试预言和测试充分性三个核心问题展开。

第7章01最需要优先背的是：

1. 软件测试目的：证明程序有错，而不是证明无错；
2. STLC 七阶段；
3. 开发者测试、用户测试、第三方测试；
4. 单元、集成、系统、确认、回归测试的区别；
5. 白盒测试 = 结构测试，黑盒测试 = 功能测试；
6. 常见测试类型及适用场景；
7. 四种有效测试策略组合；
8. 组合测试、随机测试、蜕变测试、演化测试、变异测试的基本思想；
9. 测试用例生成、测试预言、测试充分性三个核心问题。