软件测试

BraumAce2025年12月20日约 5191 字大约 17 分钟

软件测试

1. 概念

定义：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
目的：
1. 确保软件的质量
2. 确认软件以正确的方式做了用户所期望的事情
主要工作：
1. 发现软件的错误
2. 有效定义和实现软件成分由底层至高层的组装过程
3. 验证软件是否满足任务书和系统定义文档所规定的技术要求
4. 为软件质量模型的建立提供依据
基本原则：
1. 测试能发现缺陷，但无法证明软件 “无缺陷” 或绝对正确
2. 每个测试用例都必须定义预期的输出或结果
3. 测试用例中不仅要说明合法有效的输入条件，还应该描述那些不期望的、非法的输入条件
4. 缺陷的群集效应：80% 的软件错误都可以在大概 20% 的模块中找到根源（也称为二八原则）

2. 测试方法

2.1 以测试过程中程序执行状态分类

2.1.1 静态测试

概念：程序静止时，通过人工或自动方式对代码和文档进行审查和分析。
目的：在早期发现语法错误、逻辑缺陷和设计问题。
测试方法：
1. 桌面检查：程序员检查自己编写的程序，在程序编译后，单元测试前。
2. 代码审查：由若干个程序员和测试人员组成评审小组，通过召开程序评审会来进行审查。
3. 代码走查：也是采用开会来对代码进行审查，但并非简单的检查代码，而是由测试人员提供测试用例，让程序员扮演计算机的角色，手动运行测试用例，检查代码逻辑。

2.1.2 动态测试

概念：通过运行被测试程序，对得到的运行结果与预期的结果进行比较分析，同时分析运行效率和健壮性能等。
测试方法：
1. 黑盒测试方法：边界值分析、等价类划分、错误推测法
2. 白盒测试方法：逻辑覆盖、基本路径测试
分为 3 个步骤：
1. 构造测试实例；
2. 执行程序；
3. 分析结果。

2.2 以具体实现算法细节和系统内部结构的相关情况分类

2.2.1 黑盒测试

概念：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。
黑盒测试法：
1. 功能测试：
2. 边界值分析：基于错误通常出现在输入边界的经验来设计测试用例
3. 等价类划分：将输入域划分为有效和无效等价类，并从每类中选取代表值进行测试
4. 判定表：用于分析多个逻辑条件取值组合及其对应的执行动作，尤其在条件与动作组合复杂时最有效
5. 错误推测法：
6. 因果图：通过建立输入与输出之间的逻辑因果关系图，生成测试用例

2.2.2 白盒测试

概念：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。
白盒测试法：
1. 控制流分析：主要检查程序控制结构及执行路径是否正确，例如死循环、无效路径等，不涉及数据异常
2. 数据流分析：用于分析数据在程序中的生命周期，包括定义、初始化、赋值、引用等。它能够发现典型的数据异常（如未初始化变量的使用、无效赋值、未使用的数据等）
3. 路径分析：
4. 程序变异：通过对代码做微小变更生成变异程序，并用测试用例检测变异体是否能被识别，评估测试用例集的强度。
根据测试用例的覆盖程度，分为：
1. 语句覆盖：要求测试用例设计要确保每条语句在程序中至少执行一次，目的是测试程序的基本功能是否正常。覆盖强度较低。
2. 判定覆盖：判定覆盖要求测试用例至少覆盖 每个判定表达式 的所有可能结果，类似于分支覆盖，但着眼于判定条件的每个可能的结果。覆盖强度比语句覆盖稍高。
3. 条件覆盖：条件覆盖要求判断表达式中的 每个子条件（如 if 语句中的布尔表达式）在测试用例中至少为真一次，为假一次。覆盖强度比判定覆盖高。
4. 判定/条件覆盖：
5. 组合条件覆盖：组合覆盖要求设计足够多的测试用例，使得 每个条件 的所有可能组合至少出现一次。即每个条件的所有可能组合应被覆盖。覆盖强度仅次于路径覆盖。
6. 路径覆盖：要求测试用例执行程序中的每一条可能的路径，即程序中每个判断和条件组合的不同路径都被执行到。覆盖强度最高。

2.2.3 灰盒测试

概念：即既有黑盒，也有白盒。
不仅关注程序的输入输出，也对系统的内部逻辑有所了解。

2.3 以程序执行的方式分类

2.3.1 人工测试

2.3.2 自动化测试（自动化执行测试脚本）

数据驱动测试：
1. 核心思想：将测试逻辑与测试数据分离，即测试脚本保持不变，测试数据通过外部数据源进行管理。
2. 过程：测试脚本通过读取 外部数据文件，动态获取输入数据，从而对不同的测试场景进行验证。
根据实现方式的不同，对脚本分类：
1. 线性脚本：直接通过录制手工执行的测试过程得到脚本，包含所有击键、鼠标动作和输入数据，可以完整回放
2. 结构化脚本：类似结构化程序设计，具有逻辑结构和函数调用，不一定来源于录制过程
3. 共享脚本：可供多个测试用例调用
4. 数据驱动脚本：测试数据存储在外部文件
5. 关键字驱动脚本：

3. 测试阶段

3.1 单元测试（模块测试）

概念：对软件中的最小单元（如函数或方法）进行测试，以验证其是否按照预期工作。
测试对象：可独立编译或汇编的程序模块、软件构件或 OO软件中的类（统称为模块）
测试依据：软件详细设计说明书
在进行单元测试时，被测模块的上下游依赖可能尚未完成或不可用，因此常常使用 驱动模块（Driver）和 桩模块（Stub）来模拟这些依赖，以便隔离测试。
1. 驱动模块：用来调用被测模块
2. 桩模块：用来模拟被测模块所调用的子模块
代码覆盖率 是用来衡量单元测试对功能代码的测试情况，通过统计代码中各行、分支、类等的执行情况，量化测试的充分度。

3.2 集成测试

测试目的：检查模块之间，以及模块和已集成的软件之间的 接口关系，并验证已集成的软件是否符合设计要求
测试依据：软件概要设计说明书
测试方法：一般采用黑盒测试方法
组装策略：
1. 一次性组装：一次性完成所有模块集成
2. 增量组装：逐步进行模块集成

3.3 确认测试（有效性测试）

作用：用于验证软件的功能、性能、和其他特性是否与 用户需求 一致
目的：在真实的用户工作环境下，检验软件系统是否满足开发技术合同或 SRS。验收测试的结论是用户确定是否接收该软件的主要依据。
根据用户的参与程度不同，可分为：
1. 内部确认测试：主要由软件开发组织内部按照 SRS 进行测试
2. Alpha 测试：用户在开发环境下进行测试
3. Beta 测试：用户在实际使用环境下进行测试，通过改测试后，产品才能交付用户
4. 验收测试：针对 SRS，在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。
除了应该满足一般测试的准入条件外，在进行验收测试之前，应确认被测软件系统已通过系统测试。

3.4 系统测试

测试对象：完整的、集成的计算机系统
测试目的：在真实系统工作环境下，验证完成的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求
测试依据：软件需求规格说明书
测试内容：
1. 功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等
2. 最重要的工作是进行功能测试与性能测试。
3. **功能测试**主要采用黑盒测试方法
4. **性能测试**主要指标有响应时间、吞吐量、并发用户数和资源利用率等

3.5 性能测试

概念：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
分类：
1. 强度测试：模拟极端恶劣的环境（如环境不稳定、低内存等）来测试系统在资源受限条件下的稳定性。
2. 负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。关注系统在逐步增加负载下的性能变化。
3. 压力测试：通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。主要关注系统的崩溃点。
容量测试：测试系统能同时处理的在线最大用户数。

3.6 配置项测试

测试对象：软件配置项
测试目的：检验软件配置项与 SRS 的一致性
测试依据：SRS
在此之间，应确认被测软件配置项已通过单元测试和集成测试。

3.7 回归测试

测试目的：测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

3.8 其他测试

AB 测试：
1. 是为 Web 或 App 界面或流程制作两个或多个版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。
2. 核心目的：比较不同版本的效果差异，前提是控制变量一致，因此应在相同时间段内，将成分相似的用户群体（如地域、设备、访问渠道等）随机分配到不同版本，以确保测试的公平性和结果的可比性。
Web 测试：是软件测试的一部分，是针对 Web 应用的一类测试。由于 Web 应用与用户直接相关，又通常需要承受长时间的大量操作，因此 Web 项目的功能和性能都必须经过可靠的验证。
链接测试：链接是 Web 应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址页面的主要手段。链接测试可分为 3 个方面。首先，测试所有链接是否按指示那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web 应用系统上没有孤立的页面。
表单测试：当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让用户收到信息。

4. 测试模型

4.1 W 模型

概念：W 模型是对 V 模型 的一个重要改进，充分体现了尽早开展测试的原则，并将 V 模型中以发现缺陷为目标上升为保证软件质量为目标。
特点：W 模型实际上是两个 V 的叠加，一个 V 描述 开发过程，另外一个 V 描述 测试过程。但测试的起始时机不再是编码结束之后，而是从需求分析时开始，且与开发的每一个阶段活动同步进行。
特征图：

4.2 H 模型

概念：H 模型把测试活动从软件开发过程中独立出来，在软件过程的任何一个时间点上，只要测试条件满足即开展测试。
特点：
1. 改进了 W 和 V 模型高度依赖于开发的瀑布模型的缺陷
2. 测试的流程与其他流程是并行的
3. H 模型比 W 模型更好的地方是：能够兼顾测试的效率和灵活性，适合于各种规模及类型的软件项目。
特征图：

4.3 敏捷测试模型

概念：敏捷测试源于 敏捷开发。敏捷测试 是敏捷开发的组成部分，需要与开发流程良好融合
特点：敏捷测试在整个敏捷开发过程中，需要与项目的其他人员甚至用户保持紧密协作，时刻关注需求变化并实施测试，以体现测试的时效性和适应性，这对测试人员有比较高的能力要求。
特征图：

5. 测试用例设计

5.1 黑盒测试用例

场景：将程序看做一个黑盒子，只知道输入输出，不知道内部代码。

等价类划分：
1. 把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。
2. 设计原则：
  1. 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；
  2. 计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止）。
边界值分析：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值。
错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。
因果图：通过图形化方式，由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。常与判定表结合使用。
判定表驱动法：用于分析多个逻辑条件取值组合及其对应的执行动作，尤其在条件与动作组合复杂时最有效。

5.2 白盒测试用例

场景：知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例。

覆盖级别从低到高分为：

语句覆盖（SC）：逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。
判定覆盖（DC）：逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。
条件覆盖（CC）：针对每一个判断条件内的每一个独立条件都要执行一遍真和假。
条件判定组合覆盖（CDC）：同时满足判定覆盖和条件覆盖。
路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高。

6. 调试

6.1 概念

测试是发现错误；调试是找出错误的代码和原因。
调试需要：
1. 确定错误的准确位置；
2. 确定问题的原因并设法改正；
3. 改正后要进行回归测试。

6.2 调试方法

蛮力法：又称为穷举法或枚举法，穷举出所有可能的方法一一尝试。
回溯法：又称为试探法，按选优条件向前搜索，以达到目标，当发现原先选择并不优或达不到目标，就退回一步重新选择，这种走不通就退回再走的技术为回溯法。
演绎法：是由一般到特殊的推理方法，与 “归纳法” 相反，从一般性的前提出发。得出具体陈述或个别结论的过程。
归纳法：是由特殊到一般的推理方法，从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。

6.3 软件度量中软件的两种属性

外部属性：指面向管理者和用户的属性，可直接测量，一般为性能指标。
内部属性：指软件产品本身的的属性，如可靠性等，只能间接测量。

6.4 环路复杂度

McCabe 度量法：又称为 环路复杂度，假设有向图中有向边数为 $m$ $m$ ，节点数为 $n$ $n$ ，则此有向图的环路复杂度为 $m - n + 2$ $m - n + 2$ 。
1. 注意 $m$ 和 $n$ 代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式
2. 另外，针对一个程序流程图，每一个分支边（连线）就是一条有向边，每一条语句（语句框）就是一个顶点。
另一种简单的计算公式：环路复杂度 = 判定节点个数 + 1。
1. 解释：判定节点即分支结构，常表示为菱形