【软件系统架构】系列十：软件工程—

目标：验证每个单元的功能正确性、边界条件处理以及异常处理能力。
范围：通常是代码级别的测试，不依赖外部系统或数据库（可通过 Mock 对象模拟依赖）。
依据：软件详细设计说明书（DDD）。
方法
- 静态测试：静态分析、代码审查（Code Review）
- 动态测试：黑盒测试（基本用例）、白盒测试（逻辑验证）
- 覆盖标准：语句覆盖、分支覆盖、路径覆盖、组合覆盖等（按模块质量要求确定）
关键点
- 先静态分析再动态验证
- 若黑盒用例覆盖率不足，用白盒补充
- 高可靠模块建议做到路径覆盖

1.2 特点

粒度小：测试单个函数、方法或类。
快速执行：测试覆盖率高，运行速度快。
可自动化：适合集成到 CI/CD 流程。
可复现：保证代码修改后仍然保持原功能正确性。

1.3 测试方法

正向测试：验证正常输入下的正确输出。
边界值测试：验证输入在临界值或极值下的表现。
异常处理测试：验证输入非法值或异常情况的处理能力。
依赖隔离：通过 Mock、Stub 或 Fake 隔离外部依赖（如数据库、网络接口）。

1.4 常用工具/框架

语言	测试框架
Java	JUnit, TestNG, Mockito
Python	pytest, unittest, mock
JavaScript	Jest, Mocha, Jasmine
C#	NUnit, MSTest
C/C++	Google Test (gtest)
Go	testing 包, testify

1.5 测试流程

确定测试单元：函数、方法或类。
编写测试用例：覆盖正常、边界和异常情况。
执行测试：运行单元测试框架。
检查结果：与预期输出比对。
修复缺陷：根据测试结果修正代码。
回归测试：保证修改未引入新问题。

1.6 最佳实践

每个单元只做一件事，便于测试。
尽量保证测试独立性，不依赖其他单元。
使用 Mock / Stub 来隔离外部依赖。
测试用例命名清晰，描述测试目的。
将单元测试集成到 CI/CD 流程，保证持续验证。

1.7 单元测试流程图

单元测试流程的 PlantUML 图示例，展示典型流程，包括被测单元、输入、输出、Mock 对象和测试执行。

下面是示例：

@startuml
title 单元测试流程示意图

actor "测试人员" as Tester
participant "测试框架\n(JUnit/pytest等)" as Framework
participant "被测单元\n(函数/类/方法)" as Unit
participant "依赖对象\n(Mock/Stub/Fake)" as Dependency

Tester -> Framework : 编写测试用例
Framework -> Dependency : 初始化 Mock / Stub
Framework -> Unit : 调用被测单元
Unit -> Dependency : 调用依赖（被 Mock/Stub 替代）
Unit --> Framework : 返回结果
Framework --> Tester : 输出测试结果
Tester -> Framework : 根据结果修复代码并回归测试

note right of Framework
  测试用例类型:
  - 正向测试
  - 边界值测试
  - 异常处理测试
end note

@enduml

单元测试的核心流程：

测试人员编写测试用例。
测试框架初始化 Mock / Stub 对象，隔离外部依赖。
调用被测单元执行逻辑。
单元调用依赖对象（被 Mock/Stub 替代）。
单元返回结果给测试框架。
测试结果反馈给测试人员，必要时修复代码并进行回归测试。

2. 集成测试（Integration Testing）

2.1 定义

集成测试是指将多个单元或模块组合在一起进行测试，验证它们之间的接口、数据传递和交互是否正确。

目标：发现模块集成后产生的问题，如接口不匹配、数据格式错误、调用顺序问题等。
范围：超出单元范围，关注模块间的协作，而不是单个模块内部逻辑。
依据：软件概要设计文档（SDD）。
方法
- 白盒 + 黑盒结合
- 接口调用、数据流、控制流验证
关键点
- 验证接口数据格式、调用顺序、异常处理
- 确保模块组装的正确性

2.2 特点

测试范围比单元大：覆盖多个模块间的交互。
发现接口和依赖问题：如 API 参数错误、数据类型不一致、模块调用异常。
依赖环境：通常需要部分或全部系统组件可用，可能使用 Mock 对象模拟部分依赖。
执行顺序重要：模块组合方式不同可能导致不同问题。

2. 测试策略

(1) 自底向上集成（Bottom-up）

先测试底层模块，再逐步向上测试组合模块。
优点：底层模块先稳定，上层模块测试更可靠。
缺点：需要开发临时驱动（Driver）来调用未完成的高层模块。

(2) 自顶向下集成（Top-down）

先测试高层模块，再逐步集成低层模块。
优点：早期可以测试系统主流程。
缺点：需要创建 Stub 模拟低层模块，增加工作量。

(3) 大爆炸集成（Big Bang）

一次性将所有模块集成，再整体测试。
优点：实现简单，适合小型系统。
缺点：难以定位缺陷来源，问题排查困难。

(4) 增量集成（Incremental Integration）

模块逐步集成，每次只增加少量模块，测试交互正确性。
优点：缺陷容易定位，可控制测试风险。
缺点：测试周期可能较长。

2.4 常用工具

类型	工具
自动化测试框架	JUnit, TestNG, pytest, NUnit
API 测试	Postman, RestAssured, SoapUI
Mock / Stub	Mockito, WireMock, EasyMock
持续集成	Jenkins, GitLab CI/CD, GitHub Actions