软件测试

一、基本概念

1.1 软件质量基本概念

1.1.1 软件危机表现

（1）软件项目无法按期完成

（2）软件开发费用超出预算

（3）软件项目质量难以控制

（4）软件系统运行难以维护

1.2 软件质量

1.2.1 软件缺陷

定义：计算机系统或程序中存在的任何一种破坏运行能力的问题、错误或隐藏的功能缺陷

产生缺陷的原因：

• 技术问题
• 软件本身问题
• 团队协作问题

1.3 软件测试的基本知识

1.3.1 软件测试定义

狭义定义：

1.软件测试是为了发现错误而执行程序的过程

2.软件测试是根据软件开发各个阶段的规格说明和程序内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以发现错误的过程

广义定义：

（1）确认：提供证据，说明软件设计是否满足用户需求，并解决了相应问题

（2）验证：检查软件是否实现了产品规格说明上的功能和特性。提供证据，表明软件与所有生命周期活动的要求（正确性、完整性）相一致。

（3）测试：检查程序的缺陷。

第（3）步即为软件测试的狭义定义。

总结：

狭义的测试概念即局限于对程序的动态测试，而广义的测试概念将需求和设计的评审也纳入测试的范畴。

1.3.2 软件测试的辩证观点

1.正向思维：验证软件是“工作的”，逐个验证所有功能的正确性

2.反向思维：验证软件是“不工作”的，分析开发人员的理解误区、不良习惯，找出系统的弱点，想办法使系统功能失效

1.3.2 软件测试的分类

a.按照测试层次分：

• 底层测试：单元测试
• 接口层次：集成测试
• 系统层次：系统测试
• 用户层次：验收测试

b.按照被测试的对象分类

• 单元测试
• 程序测试
• 系统测试
• 文档测试
• Web应用测试、客户端测试
• 数据库测试、服务器测试

c.按照测试阶段划分

• 需求审查
• 设计审查
• 单元/集成测试
• 系统测试
• 验收测试
• 阿尔法测试
• 贝塔测试

d.按照测试目的分

• 可靠性测试、可用性测试
• 兼容性测试、安全性测试
• 安装测试、恢复测试
• 功能测试、性能测试

1.3.3 测试过程

传统测试过程：

• 需求评审、设计评审、单元测试、集成测试、系统测试、验收测试

• W模型： 测试与开发同步

敏捷测试：

• 核心：测试驱动开发、以单元测试为基础、持续交付

二、软测生命周期与测试用例

2.1 软件测试的生命周期

2.1.1 软件测试的生命周期

（1）测试内容

分析确定软件测试环境；划分和定义待测试的功能点；定义待测系统的性能参数和指标；确定安全性测试的范围和深度。

（2）测试顺序

功能测试；性能测试；可靠性测试；安全性测试。

2.2 测试用例

2.2.1 测试用例的概念

官方定义：为了特定的测试目的而设计的测试条件、测试数据和测试规程的特定的使用实例或场景。

通俗定义：将测试的输入数据定义和预期结果的描述称为测试用例(Test Case)

根据输入要求的测试用例分为：

（1）纯数据型测试用例

（2）文件测试用例

（3）操作序列型测试用例

（4）程序型测试用例

2.3 测试方法的划分

三、黑盒测试

黑盒测试也称为功能测试

特征： 把程序或测试对象看成一个黑盒，验证输入与输出之间的关系是否准确；不考虑程序的内部结构和特性

目标：测试程序的功能或接口，检查是否符合需求规格说明

3.2 等价类划分测试方法

定义：等价类划分法就是解决如何选择适当的数据子集来代表整个数据集的问题

3.2.1 有效等价类的概念

定义： 对于软件规格来说是合理的、有意义的输入数据所构成的集合。

目的： 检查软件是否实现了规定的功能和性能。

3.2.1 无效等价类的概念

定义： 对于软件规格来说是不合理的、没有意义的输入数据所构成的集合。

目的： 检查软件对于异常输入的反应，测试系统的容错性。

3.2.4 等价类的划分原则

（1）在输入条件规定了取值范围的情况下，则可以确立一个有效等价类和两个无效等价类

（2）在输入条件规定了输入值的集合或规定了“必须如何”的情况下，可以确立一个有效等价类和一个无效等价类

（3）在输入条件是一个布尔值的情况下，可确立一个有效等价类和一个无效等价类

（4）在规定输入数据的一组值(假定n个)，且程序要对每一个输入值分别处理的情况下，可确定n个有效等价类和一个无效等价类

四、白盒测试

白盒测试又叫结构测试或逻辑驱动测试，主要方法是逻辑覆盖和基本路径测试。

白盒测试是清楚软件的内部结构、内部特性和内部工作过程，可以对程序的每一行语句、每一个条件或分支进行测试，具有很强的针对性，可以知道测试的覆盖程度。

白盒测试是根据被测试程序内部结构设计测试用例的一种测试方法

（1）语句覆盖：程序每条语句都执行，逻辑覆盖最弱

（2）分支覆盖或判定覆盖：程序中所有判定的两个分支都被执行

（3）条件覆盖：每个条件的取值都被执行

（4）判定/条件覆盖：同时考虑条件与判定的组合，使各种情况都被执行

（5）路径覆盖：程序流程中的所有路径都被执行

1、2、3、4属于逻辑覆盖

5为路径覆盖

4.1 静态白盒测试和动态白盒测试

4.1.1 静态白盒测试

在不运行软件的条件下，审查软件的设计、结构和代码，以便发现软件缺陷的过程。

主要任务：

（1）对源代码进行工具扫描分析、代码评审等。

（2）检查数据组织、环境设置和软件配置项。

检查目标：

代码与设计文档的一致性、代码的规范性和可读性、代码的逻辑表达式正确性、代码结构的合理性。

4.1.2 动态白盒测试

在运行软件的条件下，检查代码功能和实现方法，以便确定测试内容、找出软件缺陷的过程。

主要任务：分析程序代码，设计测试用例，通过驱动程序和桩程序来驱动、调用被测程序的运行。动态白盒测试可以用于单元测试、集成测试和部分性能、可靠性、恢复性测试。

4.2 白盒测试的测试用例的设计方法

4.2.1 逻辑覆盖

2. 判定覆盖：每个判定的真和假都过一次
3. 条件覆盖：每个条件的真和假都有
4. 路径覆盖：《软件测试方法和技术(第三版)》p54-p55

五、单元测试

5.1 单元测试的概念

定义：单元测试是对软件基本组成单元进行的测试，且软件单元是在与程序的其他部分相隔离的情况下进行独立的测试。

测试对象： 一个函数、类的方法、功能模块或组件

单元测试分类：

• 静态测试：工具自动分析、人工评审
• 动态测试：基于代码的逻辑覆盖方法，设计测试用例进行测试

单元测试环境：

• 驱动程序/驱动模块： 模拟被测单元的上一层程序

• 桩程序/桩模块： 模拟被测单元调用的程序

为什么需要驱动模块和桩模块？

在进行单元测试时，为了隔离单元而设计驱动模块和桩模块

六、集成测试

6.1 集成测试的概念

定义： 集成测试是对已经通过测试的单元构成的模块或子系统进行测试。重点是测试接口部分，目标是检查多个单元能够协同工作的能力。

• 集成测试是单元测试之后的任务
• 集成测试是测试组合单元时出现的bug
• 集成测试是单元测试的一种逻辑扩展：多个单元构成模块，多个模块构成更大的部分

6.2 集成测试的方法

集成测试分为非渐增式和渐增式：

非渐增式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序

渐增式：把下一个要测试的模块同已经测试好的模块结合起来，逐步进行模块扩展。

6.2.1 一次性集成测试/非渐增式

适用场合：

（1）被测系统曾经是稳定运行的

（2）被测系统规模不大

（3）构件之间紧密联系，分开操作很困难

优点：用例少、测试快

缺点：错误定位难，调试难

6.2.2 自顶向下集成测试/渐增式

从主控模块开始，沿着软件层次向下移动，逐渐结合各个模块。

适用场合：

（1）自顶向下增量式开发

（2）并行式开发

特点：

（1）不需要开发驱动模块

（2）桩程序开发工作量较大

（3）对底层模块的测试不够充分

6.2.3 自底向上集成测试/渐增式

从软件最底层模块向上进行集成测试

测试步骤

（1）测试叶子节点的模块，编写叶子节点的驱动程序

（2）用实现的上一级模块替换叶子驱动程序，编写更上一级的驱动程序

（3）不断替换驱动程序，直到将根节点加入测试

6.2.4 协作集成测试

协作就是系统中多个模块共同完成一个特定的任务。可以理解为“按子功能进行的测试”

协作集成测试需要一个单独的与协作进行耦合的驱动程序。在具有GUI的应用中，驱动程序一般是界面。

七、系统测试

7.1 系统测试概念

系统测试内涵：

（1）系统测试是检查软件在整体运行环境中的表现

（2）系统测试除了软件本身外，还包含需求分析、该要设计、详细设计、用户使用说明等技术文档的审查。

集成测试后进行系统测试，系统测试主要是为了验证系统在运行环境下能否满足非功能需求。

系统测试在验收测试前

7.2 回归测试

定义： 回归测试就是保证程序在修改后，不会带来新的错误所进行的测试。

目的：程序在更新或修复bug后，可能引入了新的bug，而回归测试的目的就是检验是否因改动而引入新bug，此时无需进行全面测试，而是根据修改的情况进行有效测试。

7.3 功能测试

验证被测系统是否满足各方面功能的使用要求

包含：

• 安全性测试
• 系统环境的兼容性测试

八、性能测试

8.1 负载压力测试

也称为强度测试，

定义：压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试系统的性能、可靠性、稳定性。

负载测试是检查被测系统在“额定”负载条件下的性能。

压力测试是检查被测系统在“饱和”负载条件下的性能。

界限划分：CPU使用率达75%，内存占有率达70%

加载内容：并发用户数量、并发请求数量、多事务处理

压力测试可以分为稳定性测试和破坏性测试

8.1.1 负载压力测试指标

交易处理的负载压力指标：

（1）并发用户数量

（2）事务处理指标

• 平均事务响应时间
• 1秒内处理事务总数(TPS)

（3）Web请求指标

• 每秒点击数量
• 每秒HTTP响应数量
• 每秒下载页面数量
• 每秒重试次数
• 每秒SSL连接数量

8.1.2 并发性能测试

并发性能测试分为两个阶段：负载测试、压力

8.2 容量测试

定义： 确定被测系统能够处理的最大负载

目的： 确定系统能够保证正常工作的某项指标的极限值(例如最大用户并发数量)

九、兼容性测试

软件兼容性测试就是检查软件能否在不同组合的环境下正常运行，软件之间能否正常交互和共享信息。

9.1 兼容性测试的概念

兼容性测试需要解决的问题：

（1）被测对象需要与何种硬件、系统软件、支撑软件兼容

（2）被测对象需要与什么应用平台、其他软件交换和共享数据

（3）被测对象需要遵循哪一种信息交互标准或规范

十、易用性测试

易用性应当集中体现在界面美观、功能实用、处理有效几个方面。软件易用性测试主要从三方面进行：功能易用性测试、界面美观测试和辅助功能测试。

10.1 易用性测试的概念

易用性测试原则

（1）最具权威的易用性测试和评估不是软件技术人员，而是该软件的用户。

（2）软件易用性测试和评估应该在其设计初期就开始。

十一、验收测试/商业测试

定义： 在功能测试和系统测试之后，产品发布之前所进行的测试

测试主体由测试人员转变为实际用户。

一般分为阿尔法测试、贝塔测试

• 阿尔法测试： 软件开发公司组织内部人员模拟各类用户对即将面市软件产品进行测试，试图发现错误并修正。 关键在于尽可能逼真的模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。
• 贝塔测试： 经过阿尔法测试后的版本，软件开发公司组织各方面典型用户在日常工作中实际使用贝塔版本，并要求用户报告异常情况、提出批评意见。

十二、软件测试自动化

由手工测试的局限性而引入自动化测试

定义： 用机器模拟手工测试步骤，通过执行测试脚本，自动完成对系统的单元测试、功能测试、负载测试或性能测试等全部工作。

优点：

• 速度快、效率高
• 过程规范、结果精确
• 高可靠性、复用性
• 缩短测试开发周期