#第7章02 开发者测试

#4.1 本章定位

本章说明开发者在软件交付前如何组织测试活动。重点是 V 模型、各测试阶段的目标和对应开发阶段、集成测试策略、桩模块与驱动模块。

#4.2 开发者测试

开发者测试（Developer Testing, DT）是开发者所做的测试，有别于专职测试人员或测评机构进行的测试。目标是在软件交付或验收测试前发现并解决绝大多数代码缺陷。

理论依据是：前端发现问题的代价远小于后端。

#4.3 V 模型

客观题重点，第二次小测已考详细设计对应单元测试。

#V 模型中的测试阶段信息流

测试阶段不仅依赖测试用例本身，开发阶段产生的信息也是测试输入。

不同测试阶段的信息流大致如下：

记忆点：

测试不是孤立进行的，开发阶段的设计信息、体系结构信息、系统元素和客户参与都会成为测试输入。

#4.4 测试阶段对比表

#4.5 单元测试

单元测试验证代码中最小可独立测试单元，确保测试关注当前单元逻辑。若依赖其他模块，可使用桩技术模拟依赖。

#单元测试核心概念补充

单元测试的核心概念包括：

1. 测试对象 针对代码中的“单元”，通常是函数、方法或类。

2. 独立性 测试时要隔离外部依赖，例如数据库、网络服务等。可以使用 Mock 或 Stub 技术，确保测试只关注当前单元的逻辑。

3. 自动化 通常通过测试框架自动执行，便于集成到开发流程中。

#单元测试实施步骤

单元测试一般包括三个步骤：

1. 编写测试用例 覆盖正常输入、异常输入、边界条件等。

2. 运行测试 使用测试框架命令执行测试，例如 pytest、npm test 等。

3. 验证结果 使用断言 Assert 比较预期结果和实际结果。测试失败时，框架会报告具体错误位置。

#单元测试 FIRST 原则

记忆：FIRST = 快、独立、可重复、自验证、及时。

常见检查内容：

• 接口；
• 局部数据结构；
• 边界条件；
• 独立路径；
• 错误处理路径。

可以利用工具统计代码覆盖率，但要避免盲目追求 100%，应注重关键逻辑覆盖。

单元测试可以是黑盒测试，也可以是白盒测试。

#单元测试主要内容汇总

#4.6 集成测试

集成测试是软件测试的关键阶段，旨在验证多个模块、组件或服务在协同工作时的交互是否符合预期。

集成测试验证多个模块协作，位于单元测试和系统测试之间。

为什么需要集成测试：

• 一个模块可能对另一个模块产生不利影响；
• 子功能合成时不一定产生期望的主功能；
• 单个模块中可接受的误差，在组装后可能超过可接受限度；
• 可能发现单元测试中未发现的接口错误；
• 单元测试无法发现某些时序问题，尤其是实时系统；
• 单元测试无法发现某些资源竞争问题。

测试对象

• 模块间接口，例如函数调用、API 通信；
• 子系统或微服务之间的交互，例如数据库连接、网络请求；
• 第三方服务集成，例如支付网关、短信服务。

测试范围

• 介于单元测试和系统测试之间；
• 可以是小规模的两个模块，也可以是中规模的多个组件。

依赖管理

• 部分依赖可以使用真实服务，例如真实数据库；
• 部分依赖可以使用模拟工具 Mock；
• 例如测试订单服务时，可以使用真实数据库，但模拟支付接口。

集成测试核心目的

1. 暴露接口问题：发现参数格式不符、返回值丢失；检测资源竞争、死锁或并发问题；
2. 验证协作逻辑：确保模块组合后的功能符合设计，发现未处理的异常或边界条件；
3. 支持持续集成 CI，在代码合并时自动运行，快速反馈问题。

#集成测试方法

#非增式集成与增式集成比较

非增式集成简单但问题发现晚、定位难；增式集成逐步加入模块，接口错误发现早、定位较容易，但并行性较差。

#自顶向下集成

步骤：

1. 主控模块作为测试驱动，与主控模块直接相连的模块先用桩模块替代。
2. 按深度或广度逐步用真实模块替换桩模块。
3. 每个模块被集成前应已完成单元测试。
4. 集成新模块后进行回归测试，确认未引入错误。

桩模块（Stub）：模拟被测模块所调用的下级模块，解决依赖模块未完成或不可用的问题。

#自底向上集成

步骤：

1. 编制驱动模块，协调测试用例的输入与输出。
2. 从底层构件开始测试。
3. 按程序结构向上集成，同时移除驱动模块。

驱动模块（Driver）：模拟被测模块的上一级模块，用于调用被测模块、传递数据并输出结果。

#两种增式集成测试的补充比较

自顶向下集成优点：

• 可以自然地做到逐步求精；
• 一开始就能看到系统框架。

自顶向下集成缺点：

• 需要提供桩模块；
• 在输入/输出模块接入系统前，在桩模块中表示测试数据有一定困难；
• 桩模块往往不能完全模拟真实数据流；
• 观察和解释测试输出有时比较困难。

自底向上集成优点：

• 驱动模块模拟了所有调用参数，测试数据生成相对容易；
• 特别适合关键模块位于结构图底部的情况。

自底向上集成缺点：

• 直到最后一个模块加入后才能看到整个系统框架；
• 时序问题和资源竞争问题往往到测试后期才能发现。

#4.7 系统测试

系统测试在所有集成测试完成后、用户验收测试前执行，旨在验证完整的软件系统是否符合需求规格说明书（SRS）中的功能和非功能要求

系统测试的一般情况：

• 所有集成测试已经完成；
• 进行软件系统之间的联合测试；
• 进行软件与硬件之间的联合测试；
• 尽量模拟真实运行环境。

核心目的包括：

• 验证系统完整性；发现集成测试未覆盖的全局场景；
• 评估非功能性指标：性能，安全性，兼容性
• 为验收测试铺路。

系统测试核心目的包括验证系统完整性、评估非功能性指标

系统测试核心概念：

端到端测试 E2E：端到端测试是一种从头到尾测试整个软件产品的方法，用于验证应用流程是否按预期运行。它模拟真实用户场景，验证被测系统及其组件的集成和数据完整性，主要从最终用户体验角度进行测试。

系统测试实施步骤：

1. 测试需求分析：基于需求文档明确测试范围和优先级；
2. 设计测试用例：覆盖正常场景、异常场景和边界条件；
3. 准备测试环境：搭建接近真实环境的硬件、网络、数据库和测试数据；
4. 执行测试：可结合手动测试和自动化测试；
5. 缺陷管理与回归：记录缺陷、跟踪修复，修复后重新运行相关测试用例。

#4.8 验收测试、Alpha 与 Beta

Beta 测试是一种验收测试，是软件发布之前的测试。

#验收测试补充

验收测试是软件测试的最后阶段，目标是验证系统是否满足：用户需求；业务目标；合同条款；决定软件是否可以交付给客户或上线使用。

验收测试从最终用户或业务方视角出发，确保软件真正解决了实际问题，而非仅通过技术验证

课件强调：

• 验收测试是 V 模型中测试的最后一道工序；
• 用户在场或直接进行测试；
• 用户可能自定义测试用例。

#Alpha 测试补充

Alpha 测试通常在开发即将完成时进行，此时仍允许对设计做微小改动。

特点：

• 由用户在开发环境下进行；
• 也可以由开发机构内部用户在模拟实际操作环境下进行；

#Beta 测试补充

Beta 测试是一种验收测试，是软件发布之前的测试。

特点：

• 由多个用户在一个或多个真实使用环境下进行；
• 开发者通常不在测试现场；
• 不能由程序员或测试员完成；
• 用于发现真实用户环境中的问题。

#4.9 回归测试

回归测试是软件开发过程中确保代码修改不会破坏现有功能的一种测试方法。

例如修复登录 Bug 后，需要确认注册、支付等相关功能没有被破坏。

核心目的是验证在添加新功能，修复缺陷或优化代码后，系统中已有的功能仍能正常工作

回归测试核心目标：

1. 修改的或增加的部分是正确的；
2. 没有引起其他部分产生错误。

回归测试应用场景：增量开发；版本控制；软件维护。

回归测试方法举例：

典型回归测试过程：

1. 识别软件中被修改的部分，确定原基线测试用例库 T；
2. 根据一定策略从 T 中选择测试用例 T0，测试被修改的软件；
3. 如果 T0 无法充分测试相关部分，则生成新的测试用例集 T1；
4. 使用 T1 执行修改后的软件；
5. 第 2、3 步用于验证修改是否破坏了现有功能；
6. 第 3、4 步用于验证修改工作本身。

#4.10 测试过程：面向测试任务

课件将面向测试任务的测试过程概括为 8 个环节：

1. 测试需求描述；
2. 测试计划；
3. 测试设计；
4. 测试开发；
5. 测试执行；
6. 测试结果与预期结果比较；
7. 测试充分性评估；
8. 测试报告生成。

#4.10.1 测试过程总览

#4.10.2 测试需求描述

#1. 测试需求的含义

软件测试需求是测试活动的基础，它定义了“测什么”的问题。

测试需求是从软件需求中提炼出来的、可测试的、明确的验证要求。这里的软件需求既包括功能需求，也包括非功能需求。

测试需求来源主要包括：用户需求；系统需求；设计文档。

它明确了测试范围和测试目标

测试需求解决“测什么”的问题，是测试计划和测试用例设计的基础。

#4.10.3 测试计划

#1. 测试计划的定位

测试计划是一份详细描述测试目标，范围，方法，资源，进度和交付物的文档

测试过程的蓝图，用于规划和组织整个测试活动。

#2. 测试计划的主要内容

测试计划一般包括以下 7 类内容：

#3. 测试目标

不同测试类型的测试目标不同。

#4. 测试范围

例如：

• 接口测试需要明确哪些子系统接口需要测试；
• 功能测试那些模块需要做功能测试
• 性能测试需要明确哪些功能要做性能测试；
• 安全测试需要明确哪些模块或入口需要重点检查。

#5. 测试项目

测试项目指本次测试中具体要执行的测试类别。

常见测试项目包括：功能测试；GUI 测试；性能测试；安全测试；压力测试；负载测试；容量测试；失效 / 恢复测试；安装测试；配置测试；数据库集成测试等。

并不是每次测试都要做所有测试项目，测试项目要根据本次测试任务选择。

#6. 测试策略 / 手段

测试策略需要说明本次测试主要采用什么方法。

常见策略包括：基于代码覆盖的测试；基于规约的测试；基于状态的测试；基于数据流的测试；基于风险优先级的测试。

#7. 测试工具、资源与交付物

测试计划中还需要明确工具、资源和交付物。

测试计划解决“如何组织测试”的问题，核心是目标、范围、项目、策略、工具、资源和交付物。

#4.10.4 测试设计

测试设计是把测试计划转化为可执行测试内容的过程。

1. 测试用例设计；
2. 测试脚本设计；
3. 测试覆盖准则设计。

测试用例设计可以基于不同方法：

测试脚本是用于自动化执行测试的一组指令或代码。

它的作用包括：

• 自动执行重复操作；
• 精准验证结果
• 支持持续集成和持续交付

测试脚本的核心是断言：

assertEquals(expected, actual);
assertTrue(condition);

断言用于自动判断实际结果是否符合预期结果。

覆盖准则用于判断测试是否覆盖了足够多的程序结构或需求内容。

覆盖率越高不一定代表测试一定充分，但覆盖率过低通常说明测试风险较大。

#4.10.5 测试开发

测试开发是为了让测试能够顺利执行而进行的准备工作。

主要包括：

• 搭建测试环境；
• 录制或编写测试脚本；
• 开发测试驱动模块；
• 开发桩模块；
• 建立外部测试数据集。

#1. 测试环境搭建

测试环境应尽量模拟真实运行环境，使测试结果具有可信性。

目的是模拟真实运行场景，确保测试结果的准确性和可靠性。

在测试环境搭建之前需要明确测试环境的目标

#2. 测试脚本开发

根据测试设计阶段确定的测试脚本方案，编写或录制自动化脚本。

脚本开发需要关注：

• 是否能自动执行；
• 是否有明确断言；
• 是否能重复运行；
• 是否便于维护；
• 是否能集成到自动化流程中。

#3. 驱动模块与桩模块

在测试中，如果某些依赖模块尚未完成或不方便调用，就需要使用辅助模块。

#4. 外部测试数据集

外部测试数据集用于支持测试执行。

常见数据类型包括：

• 正常输入数据；
• 异常输入数据；
• 边界数据；
• 大规模数据；
• 历史缺陷相关数据；
• 回归测试数据。

测试开发解决“测试前准备什么”的问题，核心是环境、脚本、驱动/桩和数据。

#4.10.6 测试执行

测试执行就是按照测试设计和测试计划实际运行测试用例。

#4.10.7 测试结果与预期结果比较

软件测试结果验证是确保测试结果准确、可靠的核心环节，其目标是确认测试结果真实反映软件质量，避免误判或遗漏关键问题。例如，在软件测试中，比较测试结果和预期结果是验证软件功能是否正确的

核心步骤。测试执行后，必须将实际结果与预期结果进行比较。如果只运行程序而不判断结果，就不能称为有效测试。

#1. 手动测试中的比较

手动测试通常采用逐项检查法：业务流程简单，结果可直观观察的测试

1. 执行测试用例；
2. 记录实际结果；
3. 对照预期结果；
4. 判断通过或失败；
5. 对失败项进行缺陷记录。

#2. 自动化测试中的比较

自动化测试通常使用断言进行自动比较。

常见断言包括：

测试结果比较解决“结果对不对”的问题，核心是实际结果 vs 预期结果。

#4.10.8 测试充分性评估

测试充分性评估用于判断当前测试是否已经足够。

它主要从三个角度进行：

1. 测试用例覆盖；
2. 代码覆盖；
3. 缺陷分析。

#1. 测试用例覆盖

测试用例覆盖关注：已执行测试用例比例；成功测试用例比例；未执行测试用例原因；失败测试用例数量和原因。

常见统计方式：$测试用例执行率 = \frac{已执行测试用例数}{测试用例总数}$ $测试用例成功率 = \frac{成功测试用例数}{已执行测试用例数}$

#2. 代码覆盖

代码覆盖关注程序中有多少代码被测试执行过。

常见指标包括：语句覆盖；分支覆盖；条件覆盖；路径覆盖；代码行覆盖。

常见统计方式：$代码覆盖率 = \frac{已执行代码条目数}{总代码条目数}$

#3. 缺陷分析

缺陷分析用于判断软件质量和测试效果。

常见分析维度包括：

缺陷状态流程可简单记为：

发现并记录 → 提交 → 修改 → 回归测试 → 关闭。

#4. 测试停止与成功标准

测试充分性评估还要判断是否达到测试停止标准或成功标准。

常见判断依据：

• 关键测试用例是否全部执行；
• 严重缺陷是否全部修复；
• 缺陷数量是否下降到可接受范围；
• 覆盖率是否达到计划要求；
• 核心功能是否通过测试；
• 遗留风险是否可接受。

#5. 记忆点

测试充分性评估解决“测得够不够”的问题，不能只看覆盖率，还要结合缺陷情况和测试目标判断。

#4.10.9 测试报告生成

测试报告是测试阶段的最终交付物，用于总结测试过程、测试结果和质量结论。

清晰展示测试活动的执行情况和产品质量

#1. 测试报告核心内容

#4.10.10 Bug 跟踪

Bug 跟踪贯穿测试执行、缺陷修复和回归测试过程。

Bug 跟踪的核心不是“发现 bug 就结束”，而是要保证缺陷被记录、修复、验证和关闭。

#4.10.11 本部分记忆主线

测试过程可以压缩成一句话：

测试过程是从测试需求出发，制定测试计划，完成测试设计与测试开发，执行测试并比较结果，再通过覆盖率和缺陷情况评估测试充分性，最后形成测试报告和 Bug 跟踪闭环。

最重要的考试记忆点：

1. 测试需求：定义“测什么”。
2. 测试计划：目标、范围、项目、策略、工具、资源、交付物。
3. 测试设计：测试用例、测试脚本、覆盖准则。
4. 测试开发：测试环境、脚本、驱动模块、桩模块、测试数据。
5. 测试执行：执行用例，记录日志和实际结果。
6. 结果比较：实际结果与预期结果比较。
7. 测试充分性评估：覆盖率、缺陷分析、停止/成功标准。
8. 测试报告：总结测试过程、质量结论和遗留风险。
9. Bug 跟踪：记录、提交、修改、验证、关闭。

#4.11 测试方法分类

1. 静态测试和动态测试；
2. 黑盒测试和白盒测试；
3. 开发者测试、第三方测试、用户测试等。

#4.12 易混淆点

#4.13 小测关联

第二次小测已考：

• 软件测试按实施者分类；
• 系统测试核心目的；
• V 模型中详细设计对应单元测试；
• 自顶向下集成测试需要桩模块；
• 集成测试包含非增式和增式，增式又包括自顶向下和自底向上。

#4.14 本章复习检查题

#填空题

1. 集成测试包含________和________两类方法，其中增式集成又包含________和________。
2. 自顶向下集成测试通常需要________模块，自底向上集成测试通常需要________模块。
3. V 模型中，详细设计阶段对应________测试。

#选择题

1. 用于模拟被测模块下级依赖的是：A. 驱动模块 B. 桩模块 C. 主控模块 D. 配置模块
2. Beta 测试通常发生在：A. 开发方环境 B. 真实用户环境 C. 编译阶段 D. 代码审查阶段

#判断题

1. 系统测试通常在集成测试之前执行。
2. 自底向上集成测试需要驱动模块。
3. 回归测试只在软件首次开发时执行一次。

#参考答案

1. 填空：非增式集成、增式集成；自顶向下增式集成、自底向上增式集成；桩、驱动；单元。
2. 选择：B；B。
3. 判断：错；对；错。

#4.15 第7章02 客观题必背清单

#A. 填空题重点

1. 开发者测试 DT 是开发者所做的测试。
2. DT 目标是在软件交付前发现和解决绝大多数代码缺陷。
3. V模型中的测试包括单元测试、集成测试、系统测试、验收测试、Alpha/Beta测试、回归测试。
4. 单元测试验证最小可独立测试单元，如函数、方法、类。
5. 单元测试 FIRST 原则：Fast、Isolated、Repeatable、Self-Validating、Timely。
6. 单元测试内容：单元接口、数据结构、边界条件、独立执行路径、错误处理。
7. 集成测试关注模块接口、数据传递、依赖关系和整体功能逻辑。
8. 非增式集成也叫大爆炸集成。
9. 增式集成包括自顶向下和自底向上。
10. 自顶向下集成需要桩模块。
11. 自底向上集成需要驱动模块。
12. 系统测试通常在集成测试之后、验收测试之前执行。
13. 验收测试是 V 模型中测试的最后一道工序。
14. Alpha 测试在开发环境或模拟实际环境中进行，开发者通常在场。
15. Beta 测试在实际使用环境中进行，开发者通常不在现场。
16. 回归测试目标是验证修改部分正确，并且未引起其他部分错误。
17. 测试需求定义“测什么”。
18. 测试需求表达方式包括测试需求列表和 RTM。
19. 测试计划是测试过程的蓝图。
20. 测试报告是测试阶段的最终交付物。
21. 静态测试不运行被测程序。
22. 动态测试需要运行被测程序。
23. 黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试。
24. 白盒测试又称结构测试、逻辑驱动测试或基于程序的测试。
25. 语句覆盖是最弱的逻辑覆盖准则。
26. 程序插装可用于取得测试覆盖。
27. JUnit 是 Java 语言单元测试框架。

#B. 选择题重点

#C. 判断题易错点

#4.16 第7章02 主观题可能考法

#情景1：给一个开发项目，让你安排开发者测试流程

答题模板：

1. 根据 V 模型，将测试活动与开发阶段对应；
2. 详细设计后进行单元测试；
3. 体系结构设计对应集成测试；
4. 软件需求对应系统测试；
5. 用户需求对应验收测试；
6. 修改后进行回归测试；
7. 对发布前版本进行 Alpha/Beta 测试；
8. 强调越早发现缺陷，修复代价越低。

#情景2：给模块结构图，让你选择集成测试策略

答题模板：

1. 若希望早期看到系统框架，可选自顶向下集成；
2. 自顶向下需要为未完成下层模块编写桩模块；
3. 若底层关键模块较多，可选自底向上集成；
4. 自底向上需要编写驱动模块；
5. 若模块很多，不建议大爆炸集成，因为错误发现晚、定位难；
6. 每集成一个模块后都应进行回归测试。

#情景3：给一次代码修改，让你设计回归测试

答题模板：

1. 识别被修改部分；
2. 确定原基线测试用例库 T；
3. 根据策略选择测试用例 T0；
4. 策略可选全部再测试、按风险再测试、按修改再测试、按依赖再测试；
5. 如果 T0 不充分，则生成新用例 T1；
6. 执行测试，验证修改本身正确；
7. 验证没有破坏既有功能。

#情景4：给测试任务，让你写测试过程

答题模板：

1. 测试需求：明确测什么；
2. 测试计划：明确目标、范围、项目、方法、工具、资源、交付物；
3. 测试设计：设计测试用例、脚本、覆盖准则；
4. 测试开发：搭环境、写脚本、开发驱动/桩、准备数据；
5. 测试执行：执行脚本并记录情况；
6. 结果比较：实际结果与预期结果比较；
7. 测试评估：分析覆盖率、缺陷、是否达到停止/成功标准；
8. 测试报告：输出结论和建议。

#4.17 第7章02 最终记忆主线

本章可以用一句话记住：

开发者测试是开发者在交付前发现代码缺陷的测试活动，以 V 模型为主线，包括单元、集成、系统、验收、Alpha/Beta 和回归测试；具体执行时按照测试需求、计划、设计、开发、执行、结果确认、评估和报告生成的任务流程推进，并结合静态/动态、黑盒/白盒等测试方法和多种测试工具完成质量保障。

本章最需要优先背的是：

1. 开发者测试 DT 的定义和目标；
2. V模型中开发阶段和测试阶段的对应关系；
3. 单元测试定义、FIRST原则、五类测试内容；
4. 集成测试必要性；
5. 非增式集成 vs 增式集成；
6. 自顶向下用桩模块，自底向上用驱动模块；
7. 系统测试、验收测试、Alpha/Beta测试区别；
8. 回归测试目标、方法和典型过程；
9. 面向测试任务的八步测试过程；
10. 静态测试/动态测试、黑盒/白盒测试对比。