docs: impl 'Unit Test'

Author: chiichen

src/notes/Software-Testing-and-Maintenance/Chapter3-Software-Testing-Process.md

@@ -0,0 +1,148 @@
+---
+title: 第3章 软件测试过程
+# cover: /assets/images/cover1.jpg
+icon: page
+# This control sidebar order
+order: 1
+author: ChiChen
+date: 2024-05-11
+category:
+  - 课程笔记
+tag:
+  - 软件测试与维护
+# this page is sticky in article list
+sticky: false
+# this page will appear in starred articles
+star: false
+footer:
+isOriginal: true
+copyright: 转载请注明出处
+---
+
+## 单元测试(Unit Test)
+
+- “单元”：明确的功能、规格定义，与其他部分明确的接口定义。
+  - 结构化程序设计：函数或子过程；
+  - 面向对象：类或类的方法；
+  - 一个菜单、屏幕显示界面或对话框等。
+- 单元测试也称模块测试，这是针对最小的可测试软件元素-模块进行测试工作。单元测试目的在于发现各模块内部可能存在的各种差错。
+- 在单元测试时，如果模块不是独立的程序，需要辅助测试模块。有两种辅助模块：
+  - 驱动模块（Driver）：所测模块的主程序：它接收测试数据，把这些数据传递给所测试模块，最后再输出实测结果。当被测试模块能完成一定功能时，也可以不要驱动模块。
+  - 桩模块（Stub）：用来代替所测模块调用的子模块。
+![Unit test environment](images/Chapter3-Software-Testing-Process/image.png)
+
+### 单元测试的内容
+
+![Content of unit test](images/Chapter3-Software-Testing-Process/image-1.png)
+
+### 单元测试用例的设计
+
+- 测试用例的设计是根据设计文档进行的
+- 为系统运行设计用例，用最简单的方法执行被测单元。
+- 为正向测试设计用例，测试设计说明书所对应的功能项或性能指标是否达到。
+- 为逆向测试设计用例，测试被测单元有没有做它不应该做的事情。
+
+## 集成测试(Integration Test)
+
+- 软件在系统集成时会经常有这样的情况发生：即每个模块都能单独工作 ，但这些模块集成在一起之后却有可能不能正常工作。
+- `集成测试`又称组装测试，是在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动。
+- 确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，所测试的内容包括`单元间的接口`以及`集成后的功能`。
+- 集成测试通常需要考虑以下方面：
+    1. 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
+    2. 各个子功能组合起来，能否达到预期要求的父功能；
+    3. 一个模块的功能是否会对另一个模块的功能产生不利的影响；
+    4. 全局数据结构是否有问题
+    5. 单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
+
+### 集成测试的等级
+
+- 由集成的力度不同，一般可以把集成测试划分为三个级别：
+    1. 模块内集成测试。
+    2. 子系统内集成测试：先测试子系统内的功能模块，然后将各个功能模块组合起来确认子系统的功能是否达到预期要求。
+    3. 子系统间集成测试：测试的单元是子系统之间的接口。子系统是可单独运行的程序或进程。
+
+### 集成测试方法
+
+- 静态测试技术——针对概要设计的测试
+- 动态测试技术——灰盒测试：与白盒和黑盒测试相比，灰盒测试只需要了解程序的部分内部结构，例如程序内部结构文档或者部分算法
+
+### 集成测试策略
+
+- 集成的基本策略比较多，分类比较复杂，但是都可以归结为以下两类：
+  - 非增量式集成策略——一步到位
+  - 增量式集成策略——逐步实现
+
+#### 非增量式集成策略(Non-increasing integration strategy)
+
+- 非增量式测试是采用一步到位的方法来构造测试：
+  - 对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。
+  - 又叫大爆炸式集成（Big Bang）
+![Non-increasing integration strategy](images/Chapter3-Software-Testing-Process/image-2.png)
+- 优点：
+  - 方法简单
+  - 允许多测试人员同时并行工作，人力物力资源利用率较高
+- 缺点
+  - 必须为每个模块准备相应的驱动模块和桩模块，测试成本较高
+  - 一旦集成后包含多种错误，难以纠正。
+
+#### 增量式集成策略(Increasing integration strategy)
+
+- 增量式测试的集成是逐步实现的：逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。
+- 按照不同的实施次序，增量式集成测试又可以分为三种不同的方法：
+    1. 自顶向下增量式测试
+    2. 自底向上增量式测试
+    3. 三明治增量式测试（混合增量式测试）
+
+##### 自顶向下
+
+- 自顶向下集成测试的整个过程由3个步骤完成：
+  1. 主控模块作为测试驱动器。
+  2. 根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块。
+  3. 在每个模块被集成时，都必须进行单元测试。
+    重复第2步，直到整个系统被测试完成。
+- 优点：
+  - 较早地验证了主要控制和判断点；
+  - 按深度优先可以首先实现和验证一个完整的软件功能；
+  - 功能较早证实，带来信心；
+  - 只需一个驱动，减少驱动器开发的费用；
+  - 支持故障隔离。
+- 缺点：
+  - 桩的开发量大；
+  - 底层验证被推迟；
+  - 底层组件测试不充分。
+
+##### 自底向上
+
+- 从具有最小依赖性的底层组件开始，按照依赖关系树的结构，逐层向上集成，以检验系统的稳定性。
+- 最常用的集成策略，其他方法都或多或少应用此种方法。
+    1. 起始于模块依赖关系树的底层叶子模块，也可以把两个或多个叶子模块合并到一起进行测试
+    2. 使用驱动模块对步骤１选定的模块（或模块组）进行测试
+    3. 用实际模块代替驱动模块，与它已测试的直属子模块组装成一个更大的模块进行测试
+    4. 重复上面的行为，直到系统最顶层模块被加入到已测系统中
+![Bottom-up incremental integration test](images/Chapter3-Software-Testing-Process/image-3.png)
+- 优点：
+  - 对底层组件行为较早验证；
+  - 工作最初可以并行集成，比自顶向下效率高；
+  - 减少了桩的工作量；
+  - 能较好锁定软件故障所在位置。
+- 缺点：
+  - 驱动的开发工作量大；
+  - 对高层的验证被推迟，设计上的错误不能被及时发现。
+
+##### 三明治
+
+-混合式集成，把系统划分成三层，中间一层为目标层，目标层之上采用自顶向下集成，之下采用自底向上集成
+![Sandwich](images/Chapter3-Software-Testing-Process/image-4.png)
+
+- 优点：
+  - 集合了自顶向下和自底向上两种策略的优点
+- 缺点：
+  - 中间层测试不充分
+- 适用范围：
+  - 适应于大部分软件开发项目
+
+### 集成策略框架
+
+xUnit/JUnit
+
+略