软件工程导论——6软件质量保证

软件质量

什么是软件质量

软件与明确的和隐含的定义的需求相一致的程度
①与需求一致
②与指定的开发标准一致
③与隐含需求一致

什么是软件缺陷

至少满足下列一个条件，称发生了一个软件缺陷
– 软件未实现产品说明书要求的功能
– 软件实现了产品说明书未提到的功能
– 软件出现了产品说明书指明不能出现的错误
– 软件未实现产品说明书虽未明确提及但应该实现的目标
– 软件难以理解、不易使用、运行缓慢、用户认为不好等

软件质量属性

• 正确性：满足需求规格和用户目标的程度
• 可靠性：一定时间内无故障运行的能力
• 有效性：用户完成特定任务和达到特定目标时所具有的正确和完整程度
• 可用性：用户能否用软件完成他的任务，效率如何，主观感受怎样
• 可维护性 ：为修改Bug、增加功能、提高质量而诊断并修改软件的难易程度
• 可测试性 ：对软件进行测试的难易程度
• 灵活性：反映软件适应变化的能力，修改或 改进一个已投入运行的软件所需的工作量
• 可移植性：软件不经修改或稍加修改就可以 运行于不同软硬件环境的难易程度
• 可重用性：重用软件或构件的难易程度
• 互操作性：本软件与其它系统交换数据和相互调用服务用以协同运作的难易程度
• 安全性：向合法用户提供服务，阻止非授权使用服务
• 健壮性：异常情况下软件能够正常运行的能力
• 易用性：用户使用软件的容易程度

软件质量保证的常用方法

评审（静态分析方法）

评审是软件开发早期查错最有效的机制

等级划分

• 非正式评审
– 简单桌面检查、临时会议、结对编程评审
• 走查
– 开发组内部进行，采用讲解、讨论和模拟运行的方式查找错误
• 审查
– 开发组、测试组和相关人员联合进行，采用讲解、提问 、以及Checklist方式进行错误查找，以会议的形式进行，制定目标、流程、规则和结果报告

审查内容

检查需求

• 正确性：对系统功能性能等的描述正确反应用户真正需求
• 无二义性：每项需求对任何人都只有一种解释
• 一致性：任何一项需求不能和其它需求矛盾
• 完整性：包括用户需要的每一项功能、性能、外部接口、 约束等
• 可行性：每项需求都是可以实施的
• 必要性：每项需求都是客户需要的
• 可验证性：每项需求都能写出测试用例或其它检验方法
• 可跟踪性：每项需求能与它的根源和设计、代码、测试用例之间建立链接
• 可修改性：格式和组织方式应保证后续的修改容易进行

检查设计

在设计完成、编码开始前进行，检查软件设计说明书，如：接口的定义，功能的设计等。

检查代码

数据声明错误，数据引用错误等。

软件测试

软件测试只是软件质量保证的一部分，不能将两者画等号。
• 静态测试：不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
• 动态测试：为发现程序中的错误而运行程序的过程。
• 测试用例：输入和预期结果
• 测试与调试的区别
– 两者都包含有处理软件缺陷和查看代码的过程
– 测试的目标是发现软件缺陷的存在
– 调试的目标是定位与修复缺陷

形式化建模与验证

运用形式化语法和语义描述需求和设计，采用基于数学的方法建模，能够形式化证明程序的正确性 创建具有极低故障率的软件 。
缺点：不易掌握，没有广泛使用

软件测试技术

白盒

• 利用程序内部的逻辑结构及有关信息，设计测试用例
• 对程序的所有独立执行路径进行测试
• 对所有的逻辑判定的“真”和“假”的情况进行测试
• 在循环的边界测试
• 测试内部数据结构的有效性

白盒测试技术——逻辑覆盖

1、逻辑覆盖

|

（1）语句覆盖

为了暴露程序中的错误，至少每个语句应该执行一次。

程序应该执行的路径为sacbed.
所有语句覆盖，但是实际上，只执行了判断为真的路径。

（2）判定覆盖（分支覆盖）

不仅每个语句必须执行一次，而且每个判定的每种可能的结果都应该执行一次，也就是每个判定的每个分支都至少执行一次。
程序应该执行的路径为sacbd，sabed.
所有判断结果都执行了，但是实际上，只执行了一半的路径。

（3）条件覆盖

不仅每个语句必须至少执行一次，而且使判定表表达式中的每个条件都读取到各种可能的结果。

程序在a点应该有下述结果：
A>1;A<=1;B=0;B!=0
程序在b点应该有下述结果：
A=2;A!=2;X>1;X<=1

虽然每个条件都取到了两个不同的结果，但是判定表达式可能只取一个值。例如：
A=2,B=0,X=1
(A>1,B=0,A=2,X<=1)sacbed
A=1,B=1,X=2
(A<=1,B!=0,A!=2,X>1)sabed

（4）判定/条件覆盖

选取足够多的值，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种不同的结果。

（5）条件组合覆盖

选取足够多的值，使得每个判定表达式中条件的各种可能组合都至少出现过一次。
在程序中，共有八种可能性：

1. A>1,B=0
2. A>1,B!=0
3. A<=1,B=0
4. A<=1,B!=0
5. A=2,X>1
6. A=2,X<=1
7. A!=2,X>1
8. A!=2,X<=1
   尽管如此，还是可能有没有检测到的路径存在。

（6）路径覆盖

选取足够多的值，使得程序的每条可能路径都至少执行一次。
路径覆盖不一定满足条件组合覆盖。

白盒测试技术——循环测试

黑盒

黑盒测试技术——等价类划分

等价类划分可有两种不同的情况:有效等价类和无效等价类。
有效等价类:是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
对于有效等价类的测试用例，一个用例可以覆盖多个条件
对于无效等价类的测试用例，一个用例只能覆盖一个条件

例1：

等价类划分

测试用例：

例2

等价类划分：

测试用例：

黑盒测试技术——边界值分析

健壮性测试(6n+1)

边界值分析的扩展：除了五个边界值分析取值外，加上略超过最大值、略小于最小值的取值。
目的：测试系统物理量超过其最大值时出现的情况，关注测试的预期输出。

软件测试策略

软件测试的基本步骤

单元测试、集成测试和系统测试的基本步骤：
• 计划与准备阶段
制定计划，编写与评审测试用例，编写测试脚本和准备测试环境
• 执行阶段
搭建环境、构造测试数据，执行测试并记录问题，和开发人员一起确认问题，撰写测试报告
• 返工与回归测试阶段

单元测试

单元测试是对软件基本组成单元进行的测试，而且软件单元是在与程序的其它部分相隔离的情况下进行的独立的测试。
• 以白盒测试为主，辅以黑盒测试

单元测试的内容

模块接口测试
局部数据结构测试
单元独立执行路径的测试
单元容错性测试
单元边界条件的测试
内存分析
单元测试的环境

集成测试

集成测试是将已分别通过测试的单元按设计要求集成起来进行的测试，以检查这些单元之间的接口是否存在问题。
– 穿越模块接口是否有数据丢失
– 一个模块的功能是否对另一个模块产生不利影响
– 各子功能组合起来，是否达到预期的父功能
– 全局数据结构是否有问题
– 单个模块的误差累积起来是否会放大达到不可接受的程度

一次性集成

先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。

渐增式集成

自顶向下

从主控模块开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。在集成过程中，可以使用深度优先或者广度优先的策略。

优点：
– 自顶向下的集成方式在测试过程中较早地验证了主要的控制和判断点 。
– 选用按深度方向集成的方式，可以首先实现和验证 一个完整的软件功能
缺点：
–桩模块的开发量较大

自底向上

自底向上测试从“原子”模块（即在软件结构最底层的模块）开始集成以进行测试。

优点：
– 不需要使用桩模块进行辅助测试
– 由于是从最底层开始集成，对于一个给定层次的模块， 它的子模块及子模块的所有下属模块已经集成并测试完成
– 在模块的测试过程中需要从子模块得到的信息可以直接 运行子模块得到
缺点：
– 每个模块都必须编写驱动模块

混合集成

• 在实际工作中，常常是综合使用自底向上和自顶向下的混合集成方法
• 例如，按进度优先测试已经完成的模块
– 如果已完成的模块所调用的模块没有完成，就采用自顶向下的方法，打桩进行测试
– 如果已经完成模块的上层模块没有完成，可以采用自底向上集成方式
缺点是：在真正集成之前，每一个独立的模块都没有被完整的测试过。

确认测试

• 确认测试集中于用户可见的动作和用户可识别的输出，基于软件需求规格说明书，确认通过一系列表明与软件需求相符合的测试获得

系统测试

将经过集成测试后的软件，作为计算机系统的一部分，与计算机硬件、某些支持软件、数据和平台等系统元素结合起来，在真实运行环境下对计算机系统进行一系列的严格有效的测试来发现软件的潜在问题，保证系统的正常运行。

功能测试

在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无错误

性能测试

检查系统是否满足在需求说明书中规定的性能,特别是对 于实时嵌入式系统，包括响应时间、吞吐量、缓冲区大小、处理精度等

压力测试

检查系统在运行环境不正常乃至发生故障的情况下，系 统可以运行到何种程度的测试

恢复测试

测试在解决硬件故障(掉电、硬件或网络出错等)后，系统能 否正常地继续进行工作，并不对系统造成任何损害

验收测试

验收测试在软件产品完成了系统功能和非功能测试之后、产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段，也称为交付测试。验证系统是否达到了用户需求规格说明书中的要求，测试尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、安装测试、文档（如用户手册）测试等几个方面的内容。

α测试

用户在开发环境下，在模拟实际操作环境下进行的测试
– 受控环境，开发者场所，开发者在场
– 可以从软件产品编码结束之时开始，或在模块测试完成之后开始， 也可以在系统测试过程中产品达到一定的稳定和可靠程度之后再开始

β测试

由软件的多个用户在实际使用环境下进行的测试， 这些用户返回有关错误信息给开发者。
– 用户场所，开发者不在现场
– 在开发者无法控制的环境下进行的软件现场应用

回归测试

为什么要做回归测试：

在进行测试的时候，当发现一些严重的缺陷而需要修正的时候，会构造一个新的补丁包，然后进行测试

回归测试的目的 :

1、所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；
2、不影响软件原有功能的正确性。

考纲

质量保证
重点是软件测试策略和技术。掌握质量保证的概念、软件测试的概念及常用方法；理解质量保证活动在软件工程中的重要作用和意义。主要知识点：

1. 质量保证的概念
2. 测试策略V模型概念，测试与开发的各阶段对应关系。
3. 单元测试的内容、集成测试的分类、系统测试的分类、验收测试的分类。
4. 回归测试的概念
5. 测试技术常见术语的概念：软件缺陷、验证和确认、测试与质量保证、质量与可靠性、调试与测试、测试用例
6. 白盒测试、黑盒测试、静态分析各有哪些方法？
7. 掌握逻辑覆盖与等价类划分测试方法。