软件质量保障——五、六、七

五、回归测试

1.回归测试定义

回归测试是一种测试技术，它提供一种快速的、方便的方 法来确定软件代码修改是否改变了或破坏了现有的功能。

回归测试与一般测试比较，有六个方面不同：

• 测试计划，测试范围，资源分配，开发信息，完成时间和执行频率。

2.回归测试的步骤

回归测试过程主要有七个步骤： 提出修改需求，修改软 件工件，选择测试用例，执行测试，识别失败结果，确 认错误，和排除错误。

3.回归测试的主要方法

（ 1 ） 全部重新测试 , 即将之前所有的测试用例全部重新执行；（2 ） 有选择的重新

测试 ，即选择和使用已存在的测试用例的一个子测试用例集。

4.波及效应

波及效应是研究改变给软件所带来的 直接波及 和 诱发波及 ，以保证软件发生改变后仍然保持 一致性 与 完整性 。

• 波及效应分析是一个迭代过程。 有的步骤可以自动化执行 ，而有的步骤必须手工进行。

• 程序切片 能自动化帮助进行识别潜在波及影响

六、面向对象软件的测试

1.面向对象测试基础

1.1面向对象概念

对象：

• 是一个可操作的实体，既包括了特定的数据，又包含了操作这些数据的代码。如：某个银行帐户的数据和 操纵这些数据的代码； 对象是软件开发期间测试的直接目标：对象的行为是否符合它的说明规定？该对象与它相关的对象能否协 同工作？
• 对象的生命周期：一个对象被创建时生命周期开始，这个过程贯穿于对象的一系列状态，当一个对象被销毁/删除时生命周期就结束。

消息

• 消息是对象的操作将要执行的一种请求，包含：名字、实参、类型等
• 面向对象的程序是通过一系列对象的协同工作来实现功能/服务的，这一协作是通过对象之间的互相传递消
• 息来完成的。

接口

• 接口是对象行为声明的集合。行为被集中在一起，并通过单个的概念定义一些相关动作；
• 接口由一些规范组成。规范定义了类的一套完整的公共行为

封装

• 定义类结构
• 接口由公用方法定义
• 行为由在其实例数据上操作的方法定义
• 有助于强制信息隐藏

1.2 传统 vs 面向对象方法语境下的测试

传统开发方法与测试

需求规约 → 系统测试

    验证软件满足需求

设计规约 → 集成测试

    基于结构设计

    自顶向下或自底向上

编码 → 单元测试

     封装功能

面向对象开发与测试

      面向对象特点：

1. 责任驱动（职责分配 Responsibility Assignment）
2. 对象协作（collaboration）
3. 迭代、增量方法

导致传统的测试层次在面向对象语境下发生变化：

系统测试

      仍然基于需求规约

单元测试

      两个常用的基本元素： method 、 class

集成测试

• 主程序最小化
• 集成测试是 OO 测试最复杂的部分
• 基于合成（composition）
• 使用类簇（class cluster），含继承
• 对象关系图 (ORD: object relation diagram) – 类间依赖和方法依赖关系的有向图

2 面向对象软件的特点对软件测试的影响

2.1 类的使用对测试的影响

• 基本可测单元不再是子程序，而是类或对象；
• 在对每个类进行了单元测试后还要对类簇进行测试，这样逐步完成整个系统的测试。

2.2 封装对测试的影响

• 信息隐藏使对象的部分不可访问，减少了波动影响
• 修改封装会导致大量的回归测试：CIA
• 测试顺序相当重要（可以减少工作量）：集成测试序
• 要测试一个对象的方法，测试人员在激活一个方法前后必须检查这个对象的状态（Pre-Condition and Post-Condition，前后置条件），就需要访问对象的内部状态，而这些信息正是信息隐藏所不让测试人员知 道的。

2.3 继承对测试的影响

• 继承允许子类（衍类）重用父类（基类）的实现，要确定衍类中从基类继承的已测试的功能是否需要再测 试，衍类的测试受对基类重新测试的量的影响，
• 有时依赖于具体的面向对象语言

2.4 多态和动态绑定对测试的影响

• 引入了不可判定性问题，很难甚至不可能静态地确定在一给定的测试用例中哪个方法被激活（在做一个对 多态方法的调用或一个方法有多态参数时就会出现这个问题）。
• 对象中没有状态报告机制，状态的控制分布在整个系统中，使得难以对每个状态进行单一的测试。
• 一个多态组件的每一个可能的绑定都需要一个独立的测试，而实际上又难以找到所有的这样的绑定，特别 是非预期的绑定，这也使得集成计划复杂化。

2.5 抽象对测试的影响

• 本意是降低复杂性，把对象的本质行为与实现分开。
• 使测试变得困难，特别是要执行内部的结构测试时，降低了软件的可测试性。

3 测试与面向对象软件开发过程集成

3.1 面向对象的软件开发过程模型

• 面向对象的开发模型突破了传统的瀑布模型，采用迭代式增量开发过程模型，每次迭代又包含面向对象分 析（OOA）、面向对象设计（OOD）、和面向对象编程（OOP）三个阶段。
• OOA 阶段产生整个问题空间的抽象描述，OOD 阶段进一步设计成适用于面向对象编程语言的类和类结 构，OOP 阶段形成代码。
• 由于面向对象的特点，采用这种开发模型能有效的将分析设计的文本或图表代码化，不断适应用户需求的 变动。

3.2 测试过程与面向对象软件开发过程集成

• 针对面向对象的软件开发过程模型，结合传统的测试步骤的划分，在整个软件开发生命周期全过程中不断 测试，使开发阶段的测试与编码完成后的单元测试、集成测试、系统测试成为一个整体。
• 分析一点、测试一点，设计一点、测试一点，编码一点、测试一点。这样一来，不仅能在软件开发早期发 现错误，也避免由已有的错误产生新的错误，在开发过程中每一步都迭代式增量方法，软件就在不断精化 中开发。

3.3 面向对象测试模型 (OOTM)

4 面向对象单元测试

OO 软件功能是由类通过消息传递来完成的，因此 OO 单元测试实际就是对类的测试。

类的测试策略包括：基于服务的测试、基于状态的测试、基于响应状态的测试。

4.1 基于服务的类测试策略

主要考察封装在类中的一个方法对数据进行的操作是否存在问题，可以采用传统的白盒测试方法。

为克服软件测试的盲目性和局限性，保证测试的质量，提高软件的可靠性， Kung 提出了块分支图法

（ BBD ），从基于基本路径测试的结构测试出发对类中服务进行测试。

4.2 基于状态的类测试策略

考察类的实例在生命周期各个状态下的情况，采用从外界向对象发送特定消息序列的方法来测试对象（类

的实例）的响应状态。

【前后置条件】执行前对象状态的变化，可能会使同样的一个成员方法执行完全不同的功能，另外用户对

对象方法的调用又具有不确定性，所以这部分的测试变得非常复杂，超出了传统测试所覆盖的范围。因此

构造 OSD （ object state diagram ）模型来进行类的状态测试。

5 面向对象集成测试和系统测试

5.1 集成测试

1 ．面向对象软件的集成测试策略

1. 基于线程的测试

集成对响应系统的一个输入或事件所需的一组类，每个线程分别进行集成和测试，应用回归测试以保

证没有产生副作用。

2. 基于使用的测试

按分层来组装系统，可以先进行独立类的测试，然后用测试过的独立类对从属类进行测试，直到整个

系统构造完成。

2 ．面向对象软件的集成测试过程

1. 静态测试

针对程序结构进行，检测程序结构是否符合设计要求。通过使用测试软件的逆向工程功能，得出源程

序的类系统图和函数功能调用关系图，与 OOD 结果相比较，检测程序结构和实现上是否有缺陷，检

测 OOP 是否达到了设计要求。

2. 动态测试

根据静态测试得出的函数调用关系图或类关系图作为参考，设计测试用例，使其达到一定的测试覆盖

标准。

3 ．设计集成测试用例的步骤

1. 选定检测的类，参考 OOD 分析结果，确定出类的状态和相应的行为；

2. 确定覆盖标准，利用结构关系图确定待测类的所有关联；

3. 根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态，使用类的服务和期望产生什么行为

等，还要设计一些类禁止的例子，确认类是否有不合法的行为产生。

5.2 系统测试

测试软件与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能进行工作。不仅是确认

系统在实际运行时是否满足用户的需要，也是对软件开发设计的再确认。应该参考 OOA 的结果，对应描述的

对象、属性和各种服务。

1. 功能测试

以软件分析文档为标准，测试系统的功能是否达到要求，是否满足用户的需求。

2. 强度测试

测试系统的负载情况和功能实现情况，比如信息系统能容纳多少人同时在线操作。

3. 性能测试

与强度测试相结合，测试软件系统的运行性能。

4. 安全测试

验证安装在系统内的保护机构确实能够对系统进行保护。

5. 恢复测试

采用人工的干扰使软件出错，中断使用，检测系统的恢复能力。

6. 可用性测试

测试用户是否能够满意使用，主要是指操作是否简便，操作界面是否符合使用习惯。

7. 安装 / 卸载测试

测试用户是否能方便地安装和卸载。

总的来说，面向对象的集成测试和系统测试都是基于面向对象的分析和设计进行的，在分析阶段总结出的用例

图、状态图、顺序图、协作图和活动图都可以作为集成测试和系统测试的依据。

七、软件性能测试

1. 软件性能

• 软件性能（Software Performance）是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功 能，而是在完成该功能时展示出来的及时性。【属于用户的非功能需求】
• 不同的人对同样软件有不同主观感受，对软件性能关心视角也不同。

性能指标

• 响应时间：系统对请求作出响应的时间。
• 系统响应时间和应用延迟时间：
• 系统响应时间：计算机对用户的输入或请求作出反应的时间。
• 应用延迟时间（latency）：应用接到指令后的处理时间。
• 吞吐量：系统在单位时间内处理请求的数量。
• 并发用户数：系统可以同时承载的正常使用系统功能的用户的数量。
• 资源利用率：反映一段时间内资源平均被占用情况。
• 广义上系统的性能包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。

性能视角

2. 性能测试概述

性能测试的目的

• 评估系统的能力：测试中得到的负荷和响应时间数据可以被用于验证系统模型的能力，并帮助作出决策。
• 识别系统中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复系统的瓶颈或薄弱的地方。
• 系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
• 检测系统的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
• 验证系统稳定性（stability）和可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

3. 性能测试的步骤

3.1 熟悉应用

3.2 测试需求

3.3 测试准备

3.4 测试执行

3.5 测试结果分析

4. 性能测试的指标

响应时间

• 对请求作出响应所需要的时间。

吞吐量

• 单位时间内系统处理用户的请求数。
• 对于交互式应用，反映服务器承受的压力，能够说明系统的负载能力。

并发用户数

• 系统用户数：系统额定的用户数量，如一个 OA 系统，可能使用该系统的用户总数是 5000 个。
• 同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。

资源利用率

• 系统各种资源的使用情况，如 cpu 占用率为 68%，内存占用率为 55%。
• 内存（Memory）
• 磁盘（Physical Disk）
• 处理器（Processor）
• 网络

5. 软件性能测试方法

负载测试（ load testing ） 是检测在各种工作负载下 系统的性能，也就是测试 当负载逐渐增加时 ， 系统 各项性能指标的变化情况 ；

压力测试（ stress testing ） 是检测一个 系统的瓶颈或 者不能接受的性能点。 测试系统能提供的最大级别 服务是什么[ 最大并发用户数、最大用户访问量、最 大吞吐量…] 。

容量测试（ volume testing ） 是检测系统在给定时间 内能够持续处理的 最大负载或工作量 。

配置测试

是通过被测系统软 / 硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资源的最优分配原则。

并发测试

模拟用户并发访问，测试多用户并发访问同一应用、同一模块或数据记录时是否存在死锁或者其他性 能问题。 并发用户数和并发数不同。

可靠性测试

给系统加载一定的业务压力，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运 行。

失效恢复测试

针对有备份和负载均衡的系统，可用来检验如果系统局部发生故障， 用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。

大数据量测试 ：

独立的数据量测试： 针对某些系统存储、传输、统计、查询等业务进行大数据量测试。 综合数据量测试：压力测试、负载测试、并发测试、可靠性测试相结合。