第2章 软件测试基础 笔记 25.03.18

2.1 软件测试的基本概念

2.1.1 什么是软件测试

软件测试的定义：

IEEE 使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求 或是 弄清预期结果与实际结果之间的差异。

软件测试应尽可能去发现更多的错误

软件测试的对象是软件，抱哈按程序、数据和文档

环境：软件的运行环境、测试环境

2.1.2 验证与确认

验证 Verification：通过提供客观证据来证实规定需求已经得到满足

确认 Validation ：通过提供客观证据来证实针对某一特定预期用途或应用需求已经得到满足

验证的依据是 产片要求（需求规格），生产者内部的要求

确认的依据是用户的应用需求，一种外部要求

2.1.3 软件缺陷

将软件的问题（Problem）、错误（Error）以及因软件而引起的异常（Anomaly）、故障（Fault）、失效（Failure）、偏差（Variance）等均称为软件缺陷

软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生；
软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差；
软件故障是指软件运行时出现的一种不希望或不可接受的内部状态；
软件失效是指软件运行时产生的一种不希望或不可接受的外部行为

在需求分析、设计、编码阶段都会引入软件缺陷

需求分析阶段 占比 超过40%

设计阶段 占比 超过30%

编码阶段 低于 30%

编码阶段的缺陷更容易被发现，需求分析和设计阶段产生的缺陷很隐蔽，不易被发现

软件缺陷 要尽快修复，从发现到修复 间隔时间越短，代价越小

缺陷的分类包括：缺陷的状态、优先级、严重性、发生概率、影响质量特性的范
围、引入的阶段、原因分析、解决方案、处置结果、处理风险等20余项。

优先级：紧急、高、中、低、无

严重性：阻塞、严重、一般、轻微、可忽略

2.1.4 测试与质量保证

质量保证（Quality Assurance，QA）：为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动

质量模型

包括：产品质量模型、使用质量模型

产品质量模型将质量属性划分为八个质量特性：功能性、性能效率、兼容性、易用性、
可靠性、信息安全性、维护性和可移植性，每一个特性由相关的若干子特性组成；

使用质量模型包含了与系统交互结果有关的五个特性：有效性、效率、满意度、抗风险和周境覆盖，其中满意度、抗风险和周境覆盖还各自包含一些子特性。

软件质量保证与软件测试是包含关系，

软件质量保证 涉及的活动更宽泛，侧重管理性活动

软件测试 是软件质量保证的一种手段，侧重技术性活动

2.1.5 测试用例

测试用例（Test Case）：为某个特定目标而开发的输入、执行条件以及预期结果的集合

要点：

第一，测试用例是测试人员针对具体目标设计或开发的，有非常强的目的性

第二，测试用例将体现软件的某一个具体运行实例或场景，包括输入的测试数据、执行条件、逻辑过程以及预期的逻辑结果等

第三，测试用例须提供准确的判定准则，即依照该用例实施测试获得实际结果时如何判定。

测试用例应该包含：用例的标识、名称、说明、环境配置、操作过程、各种条件、评价准则以及建立用例的人员和时间等信息，

其中 操作过程 要描述每一步操作的输入数据、过程说明、预期结果和通过准则等。

测试脚本通常指一个特定测试的 可以被自动化工具执行的一系命令，可以通过工具录制测试操作、使用脚本语言编写。

2.1.6 测试策略

软件测试需要在有限资源的约束下，尽可能发现软件缺陷的技术和管理活动，理想情况是实现测试代价和测试质量的最佳平衡。

软件测试策略是在一定的软件测试标准、测试规范的指导下，依据测试项目的特定
环境而规定的软件测试的原则、方法的集合。

软件测试策略的确定是基于测试需求的分析以及测试风险评估的结果，定义测试
的范围和要求，选择合适的测试方法，并制定测试启动、停止、完成的标准和条件。

软件测试策略 分类:

基于分析（如风险分析、需求规格分析）的策略、

基于模型（如业务模型、软件质量模型、系统性能演化模型）的策略、

基于标准规范（如GB/T25000.51标准、软件验收标准）的策略

以及基于自动化的回归测试策略等等。

测试策略的输入 包括：
·测试所需软硬件资源的详细说明。
·针对测试和进度约束，需要的人力资源的角色和职责。
·测试方法、测试标准和完成标准。
·目标系统的功能性和非功能性需求、技术指标。
·系统局限（即系统不能够满足的需求）等。

测试策略的输出 包括：
·已批准或审核的测试策略文档、测试用例、测试计划。
·需要解决方案的测试项目。

制定测试策略的过程为：

• 确定测试的需求。需要注意以下几点：
  ①测试需求必须是可观测、可测评的。
  ②软件需求与测试需求以及测试用例不是一对一关系。
  ③测试需求可能有许多来源。

• 评估风险并确定测试优先级。

• 确定测试策略

  一个好的测试策略应包括：实施的测试类型和测试目标、实施测试的阶段、技术、评估测试结果和测试是否完成的标准、对测试工作存在英雄的特殊事项等

2.2 软件测试的原则

遵循一些普遍性原则：

溯源性原则：测试应该溯源到原始需求

工程性原则：测试应观察软件开发的各个阶段，须尽早开展测试

独立性原则：避免开发者自己测试程序

合理性原则：测试成本与测试强度成正比，遗留缺陷与测试强度成反比，需要在质量要求和测试强度之间寻找合理的结合点，避免测试不足和过度测试，合理地设置测试终止条件

不完全性原则：测试只能尽可能多地发现错误，不能证明软件没有错误

相关性原则：软件中缺陷多的模块，应该加强测试

可接受性原则：根据修复代价决定是否修复缺陷

风险性原则：做好风险评估，明确风险化解的解决方案

2.3 软件测试模型

2.3.1 V模型

软件测试的V模型 - 开发的瀑布模型

2.3.2 W模型

W模型是V模型的改进，充分体现尽早开展测试的原则，

目标： 从 发现缺陷 上升到 确保软件质量

W模型是两个V的叠加，一个V描述开发过程，一个V描述测试过程

测试分布于软件开发过程中的各个阶段

2.3.3 H模型

W模型不适用：存者大量交叉活动、使用快速开发或敏捷开发的软件

H模型：把测试活动独立出来，软件开发过程中任意时间点，只要满足测试条件，就开展测试

测试流程可以与其他流程并行

H模型 能更好的兼顾测试的效率和灵活性，适用于各种规模及类型的软件项目。

2.3.4 敏捷测试模型

敏捷测试是敏捷开发的组成部分，需要与开发流程良好融合

需要与项目的其他人员以及用户保持紧密协作，时刻关注需求变化并实施测试，体现测试的时效性和适应性

2.4软件测试分类

2.4.1 按工程阶段划分的测试

主要阶段：单元测试、集成测试、系统测试、确认测试和验收测试

单元测试（模块测试）

最小单位的测试活动，寻找模块内部的各种错误

依据：模块的详细设计文档

方法：白盒测试、黑盒测试以及灰盒测试

集成测试

主要任务：发现模块间接口可能存在的问题，

目标：验证个模块组装之后是否满足软件的设计文档的要求

集成策略：一次性集成、增量式集成

系统测试

目标：确认软件的应用系统是否按预期工作并满足应用的需求

依据：需求规格说明书

方法：黑盒测试 + 测试工具

确认测试和验收测试 以 需求规格说明书为依据，使用 黑盒测试方法

确认测试（有效性测试）

开发方组织，针对需求规格进行局部或全部的确认测试

包括：α测试、β测试

验收测试

用户方组织，在生产环境下进行全面的确认测试，并输出验收测试报告

2.4.2 按是否执行代码划分的测试

分为：动态测试、静态测试

动态测试：

通过运行软件来发现错误或验证程序是否符合预期要求

静态测试：

不运行软件，只做检查和审核，

测试对象包括：需求文档、设计文档、产品规格说明书以及代码

文档类 使用 评审方式进行

代码 使用 走查、代码审查方式

静态评审 包括：内部评审、外部评审

内部评审：范围比较广泛，侧重技术层面

外部评审：更多的对需求和设计文档进行评审，用户代表、领域专家参加

静态测试做得比较好，能及时发现更多的错误，减少动态测试的压力，降低修复成本，更好地保证软件的质量。

2.4.3 按测试实施主体划分的测试

分为：开发方测试、用户方测试、第三方测试

开发方测试：

应该涵盖软件生产及交付的各个阶段，以满足用户需求为最终目的。

熟悉软件，测试效率高

用户方测试

只能开展验收测试，基于真实需求，确认软件是否符合需求

第三方测试

主要进行软件的确认测试、验收测试和符合性测试

优势：

1.公平公正 2.高度专业化的测试团队和管理团队

3.丰富的测试经验和完备的测试工具 4.严格的专业资质

2.4.4 按是否关联代码划分的测试

分为：白盒测试、黑盒测试、灰盒测试

白盒测试（结构化测试、逻辑驱动测试、基于代码的测试）

测试人员了解程序内部结构、语句及工作过程

主要工作：进行各类逻辑覆盖测试，如：语句覆盖、路径覆盖、判定覆盖、条件覆盖、条件组合覆盖等

对程序完全覆盖 不现实，需要设计恰当的测试用例，用尽可能少的用例覆盖尽可能多的情况

黑盒测试（功能测试、基于规格说明的测试、数据驱动的测试）

通过软件外部表现进行测试，不关心程序内部结构、实现，只关心程序的输入和输出。

依据 需求规格说明书，设计测试用例，分析在特定输入情况下预期的输出结果，根据软件实际运行结果来判定程序是否存在错误。

方法：等价类划分、边界值分析、判定表、因果图

白盒测试可以发现软件中的技术性错误，并准确定位错误位置，

黑盒测试可以判断用户需求的符合程度，测试效率更高，测试用例可复用

灰盒测试

介于白盒测试和灰盒测试之间，既关注黑盒测试中的输入输出，也在一定程度上关注程序的内部情况，

模块内黑盒测试，模块间白盒测试

2.4.5 按软件质量特性划分的测试

软件产品质量的八个质量特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性和可移植性，相应地可以针对这些特性或它们的子特性开展测试，从而形成系统的功能性测试、性能效率测试、兼容性测试、易用性测试、可靠性测试等等。

1.功能性测试

在指定条件下使用时，测试软件提供满足明确和隐含要求的功能的程度，包括软件功能的完备性、正确性和适合性。

2.性能效率测试

在指定条件下使用时，测试软件的性能及效率满足需求的程度，包括时间特性（如响应时间、处理时间、吞吐率）、资源利用性（如内存占用、CPU占用）、容量（如并发用户数、通信带宽、交易吞吐量、数据库规模）。

3.兼容性测试

在共享相同的硬件或软件环境的条件下，测试软件能够与其他软件交换信息和/或执行其所需的功能的程度，包括软件的共存性和互操作性。

4.易用性测试

在指定的使用周境中，测试软件在有效性、效率和满意度特性方面为了指定的目标可为指定用户使用的程度，包括软件的可辨识性、易学性、易操作性、用户差错防御性、用户界面舒适性、易访问性等。

5.可靠性测试

测试软件在指定条件下指定时间内执行指定功能的程度，包括软件的成熟性、可用性、容错性、易恢复性。

6.信息安全性测试

测试软件保护信息和数据的程度，包括保密性、完整性、抗抵赖性、可核查性、真实性。

7.维护性测试

测试软件能够被预期的维护人员修改的有效性和效率的程度，包括软件的模块化、可重用性、易分析性、易修改性、易测试性。

8.可移植性测试

测试软件能够从一种硬件、软件或其他运行（或使用）环境迁移到另一种环境的有效性和效率的程度，包括软件的适应性、易安装性、易替换性。

2.4.6 按符合性评价要求划分的测试

通过符合性测试，对软件进行符合性评价。

符合性测试的前提：符合性准则的文件，就绪的软件、软件的系统元素已存在

2.4.7 回归测试

只要软件发生了变化，都应该进行回归测试。

回归测试除了验证修改的部分，还要验证可能受到影响的功能。