《软件质量保证》复习摘要

一、概述

软件定义

IEEE 定义对软件的定义如下：

• 软件是计算机程序、规程以及可能的相关文档和运行计算机系统需要的数据。

• 软件包含计算机程序、规程、文档和软件系统运行所必需的数据四个部分。

软件特征

• 软件是逻辑产品，而不是物理产品
• 软件不会像硬件一样有磨损。

软件工程

全面的质量管理，促进了不断的过程改进，带来了成熟的软件工程方法

软件工程的根基，在于对质量的关注

三个阶段

• 定义阶段针对“做什么”

• 开发阶段针对“如何做”

• 维护阶段针对“改变”

典型活动

• 软件项目追踪和控制
• 正式的技术复审
• 软件质量保证
• 软件配置管理
• 文档的准备和产生
• 可复用管理
• 测试
• 风险管理

软件质量

软件系统规模和复杂性的增加，使得软件开发成本和软件故障而造成的经济损失也在增加，软件质量问题，正成为制约计算机发展的关键因素。

定义

软件质量保证（Software Quality Assurance，SQA）

质量保证并不能保证质量

它是一种应用于整个软件过程的保护性活动，包括：

• 一种质量管理方法
• 有效的软件工程技术（方法和工具）
• 在整个软件过程中采用的正式技术复审
• 一种多层次的测试策略
• 对软件文档及其修改的控制
• 保证软件遵从软件开发标准的规程
• 度量和报告机制

考虑方面

• 软件结构方面
• 功能与性能方面
• 开发标准与文档方面

软件测试

定义

方法

二、软件质量工程体系

软件质量控制是一组由开发组织使用的程序和方法，使用它可在规定的资金投入和时间限制的条件下，提供满足客户质量要求的软件产品，并持续不断地改善开发过程和开发组织本身，以提高将来生产高质量软件产品的能力。

软件质量控制的基本方法

1. 目标问题度量法：目标定量化
2. 风险管理法：风险识别、风险分析、风险计划、风险控制和风险跟踪

软件质量控制模型和技术

控制模型

参数：产品，资源，过程：预开发阶段，开发阶段，维护阶段

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6EyJIrgB-1610263864858)(C:%5CUsers%5C37889%5CPictures%5CCamera%20Roll%5Cimage-20210110132010262.png)]

技术

质量控制技术	预防性特征	检测性特征
因果分析	分析原因，提出改进建议，预防出错
配置管理	控制软件配置，防止引入新的错误
独立的确认与验证IV&V		及时发现和纠正需求、设计、编码的错误
检查	在测试之前检查并纠正设计和编码的缺陷	检查和纠正设计、编码缺陷
管理度量	检查早期问题并调整质量控制参数
性能工程	提供某种方法避免潜在的性能问题	度量实际性能，确认是否满足需求
初样	对早期需求和问题的确认，用户界面设计确认
可靠性建模		度量软件的可靠性，并预测附加测试
软件审计	识别关键风险并提出规避方法	检测超时、超支和质量缺陷
SEI软件能力评估	评估组织的开发过程，确定成熟度等级

软件质量保证体系

SQA 的目的是向管理者提供对软件过程进行全面监控的手段，包括评审和审计软件产品和活动，验证它们是否符合相应的规程和标准，同时给项目管理者提供这些评审和审计的结果。

CMM的核心

是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。

能力成熟度模型集成(CMMI)

第1级：初始级

不做任何计划，直接开始

第2级：受管理级

做了项目计划，需求管理，质量保证等实现了整个项目的管理跟踪，但未进行风险管理以及项目计划制定时的各项指导说明。

第3级：已定义级

定义了相关文档，也做了风险管理。但没有对各项情况进行定量数据的预估。

第4级：定量管理级

做了定量分析，比如针对历史数据算了性能基线。

第5级：持续优化级

又加了原因分析，新技术以及未来目标等为持续优化作准备。

三、软件配置管理

概念

软件配置管理（Software Configuration Management, SCM）是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。

优势

• 工作成果的所有版本都被保留着，不会丢失也不会被覆盖

• 良好的配置管理可以解决版本错乱问题

管理规范

配置项

配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。

凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI）。配置项主要有两大类：

• 属于产品组成部分的工作成果，例如源代码、需求文档、设计文档、测试用例等等。

• 在管理过程中产生的文档例如各种计划、监控报告等等，这些文档虽然不是产品的组成部分，但是值得保存。

状态迁移

基线

基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。

基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。

通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。

角色

为了提高配置管理的效率和安全性，项目应当设有配置管理员这个角色。配置管理员的主要工作是为项目制定配置管理计划，创建和维护配置库等。

流程

四、软件评审

内容

• 管理评审：管理体系
• 技术评审：技术功能
• 文档评审：文档审核
• 过程评审：质量保证流程是否合理

作用

• 提高项目生产率
• 标志着软件开发的一个阶段的完成
• 软件更易维护（迫使开发者产生更多有用的文档）

方法和技术

特别检查、轮查、走查、团队评审、检视

缺陷检查表

规则集

评审工具的使用

• Gerrit

• Jupiter

• SourceMonitor

从不同角度理解产品

场景分析技术

流程

五、软件测试过程

软件测试的目的和原则

**软件测试就是在软件投入运行前，**对软件的需求分析、设计、实现编码进行最终审查。

软件测试就是为了发现缺陷而运行程序的过程。

它的最终目的是建立一个高可靠性的软件系统的一部分

软件测试过程

软件测试与开发的关系

软件测试贯穿于整个软件开发生命周期

测试工具的选择

黑盒工具

划分等价类

边界值分析

因果图法

因果图

决策表

		1	2	3	4	5	6	7	8	9	10	11
输 入	投入1元5角硬币	1	1	1	1	0	0	0	0	0	0	0
投入2元硬币	0	0	0	0	1	1	1	1	0	0	0
按“可乐”按钮	1	0	0	0	1	0	0	0	1	0	0
按“雪碧”按钮	0	1	0	0	0	1	0	0	0	1	0
按“红茶”按钮	0	0	1	0	0	0	1	0	0	0	1
中间 结点	已投币	1	1	1	1	1	1	1	1	0	0	0
已按钮	1	1	1	0	1	1	1	0	1	1	1
输 出	退还5角硬币	0	0	0	0	1	1	1	0	0	0	0
送出“可乐”饮料	1	0	0	0	1	0	0	0	0	0	0
送出“雪碧”饮料	0	1	0	0	0	1	0	0	0	0	0
送出“红茶”饮料	0	0	1	0	0	0	1	0	0	0	0

功能图法

白盒工具

控制流测试

控制流图：

逻辑覆盖方法有以下6种：

选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多的程序错误

1. 语句覆盖

   设置用例使每个语句块都执行

2. 判定覆盖

   设置用例使每个判断块的可能都覆盖一遍

3. 条件覆盖

   设置用例使每个判断框中的各个条件都覆盖一遍

4. 判定－条件覆盖

   条件+判定覆盖都要满足

5. 条件组合覆盖

   所有条件的可能组合都要覆盖(条件覆盖的加强版)

6. 路径覆盖

   将所有会发生的条件路径都走一遍

基本路径测试

有了黑盒测试为什么还要白盒测试？

• 黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。

• 白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。

在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?

不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。

既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？

• 首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。

• 不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。