软件质量保证与测试基础知识小计

写在前面：

        这是我再期末考试阶段根据老师的重点进行的知识总结（只涉及概念等基础内容，不涉及具体技术操作流程），现分享出来，欢迎大家批评指正。

目录

第一章 概述

第二章 软件质量工程体系

第三章 软件质量度量和配置管理

第四章 软件可靠性度量与测试

第五章 软件质量标准

第六章 软件评审

第七章 软件全面质量管理

第八章 高质量编程

第九章 软件测试

第十章 黑盒测试

第十一章 白盒测试

第十二章 基于缺陷模式的软件测试

第十三章 集成测试

第十四章 系统测试

第十五章 测试管理

---

第一章 概述

·软件定义

       软件包含4个部分，即计算机程序、规程、文档和软件系统运行所需要的数据。

·软件特征（软硬件差异）

1. 软件是由开发产生，不是用传统方法制造的。
2. 软件不会像硬件那样有磨损。
3. 软件不能通过已有构件组装，只能由自己定义。

·软件分类

       系统软件       应用软件       Web应用软件      工程和科学软件

       嵌入式软件   产品线软件   人工智能软件

·软件质量概念

IEEE：

       软件质量是：1.系统、部件或者过程满足规定需求的程度。2.系统、部件或者过程满足顾客或者用户需要期望的程度。

（强调产品或服务和客户/社会需求的一致性）

ANSI：

       与软件产品满足规定的和隐含的需求的能力有关的特征和特性的全体。具体包括：1.软件产品种能满足用户给定需求的全部特性的集合；2.软件具有所期望的各种属性组合的程度。3.用户主观得出的软件是否满足起综合期望的程度。4。决定所用软件在使用中将满足其综合期望程度的软件合成特性。

（强调软件的特性或特征与需求的温和程度，以及这些特性的综合评价值）

·全面质量管理概念

       全面质量管理（Total Quality Management，TQM）是一种全员、全过程、全企业的品质经营，指一个组织以质量为中心，以全员参与为基础，目的在于通过让顾客满意和本组织所有成员及社会受益，达到持续经营的管理途径。

·软件的6个主要特征

1. 功能性：软件实现的功能达到要求的和隐含的用户需求以及设计规范的程度。
2. 可靠性：软件在指定条件下和特定时间段内维持性能的能力程度。
3. 易使用性：用户使用该软件所付出的学习精力。
4. 效率：在指定条件下软件功能与所占用的学习精力。
5. 可维护性：当发现错误、运行环境改变或客户需求改变时程序能修改的容易程度。
6. 可移植性：将软件从一种环境移入另一种环境的容易程度。

！软件质量保证（SQA）定义

IEEE定义：

       一种有计划的、系统化的行动模式，是指为项目或者产品符合已有技术需求提供充分信任所必需的；用来评价开发或制造产品的过程的一组活动，与质量控制有区别。

扩展定义：

       软件质量保证是一个有系统的、有计划的行动集合，是为提供软件产品的软件开发过程与维护过程符合已经建立的技术需求，以及跟上计划安排与在预算限制之内进行的管理上的充分信任的必需。

！测试的根本目标

       尽可能多地发现软件中隐藏的错误，最终把一个高质量的软件系统交给用户使用。

！测试的定义

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

！测试的分类方法

1.

功能确认与接口测试：包括各个单元功能的正确执行、单元间的接口，如单元接口、局部数据结构、重要的执行路径、错误处理的路径以及边界条件等内容。

覆盖率分析：主要对代码的执行路径覆盖范围进行评估，如语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、修正条件/判定覆盖、基本路径覆盖等，都是从不同要求出发来设计测试用例的。

性能分析：代码运行缓慢是开发过程中的重要问题，查找和修改性能瓶颈是调整整个代码性能的关键。

2.

3.按阶段进行分类

需求测试       单元测试       集成测试       性能测试       压力测试       容量测试

配置测试       回归测试       安装测试       安全性测试

！对软件人才的4点需求

1. 基础和创新
2. 主人翁精神
3. 团队的精神
4. 从错误中学习                                                                                                                                                                                                                                                                                                   

第二章 软件质量工程体系

！软件质量控制

概念

       对开发进程中软件产品（包括阶段性产品）的质量进行连续的收集、反馈。

基本方法：

       目标问题度量法、风险管理法、PDCA质量控制法

2个方面的度量：

1. 度量与计划和定义开发过程的一致性
2. 度量产品活阶段性产品是否达到了质量要求

！风险控制

方面：

1. 风险估计和风险控制
2. 选择用来进行风险估计和风险控制的技术

分类：

       风险避免       风险弱化       风险承担       风险转移

步骤：

       风险识别       风险分析       风险计划       风险控制       风险跟踪

！TSQC

全称：

       全面统计质量控制（Total Statistical Quality Control）

影响参数：

       产品（所有可交付物）     

过程(所有活动的集合)

资源（活动的物质基础：人力、技术、设备、时间、资金等）

过程：

       （即PDCA的活动的循环）

       计划（Plan）-实施（Do）-检查（Check）-改进（Action）

！软件质量保证

含义：

       建立一套有计划、有系统的方法向管理层保证拟定出的标准、步骤、时间、方法能够被所有项目采用。

目的：

       使软件过程对于管理人员来说是可见的，通过对软件产品和活动进行评审和审计来验证软件是符合标准的。

目标：

       以独立审查的方式监控软件生产任务的执行，给开发人员和管理层提供反映产品质量的信息和数据，辅助软件工程组得到高质量的软件产品。

第三章 软件质量度量和配置管理

！软件质量度量根本目的

       为了管理的需求利用度量来改进软件过程。

！软件度量

含义：

       对软件开发项目、过程、产品进行数据定义、收集、分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制、改善。

作用：

1. 通过软件度量增加理解
2. 通过软件度量管理软件项目，主要是计划和估算、跟踪和确认。
3. 通过软件度量指导软件过程改善，主要是理解、评估、包装。

度量取向：

       软件开发的诸多事项的横断面，包括顾客满意度度量、质量度量、项目度量，以及品牌资产度量、知识产权价值度量，等等。

依据：事实、数据、原理、法则

方法：测试、审核、调查

工具：统计、图表、数字、模型

标准：量化的指标

！软件质量

CMM定义：

       一个系统、组件、过程符合特定需求的程度；

       一个系统2、组件、过程符合客户或用户的要求或期望的程度。

影响因素：

       人、过程、技术

软件过程分类：

       软件工程过程、软件管理过程、软件支持过程

！质量保证模型列举

       McCall模型

       Boehm模型

       FURPS模型

       ISO 9126

FURPS五因素：

       功能性   可用性   可靠性   性能       支持度

ISO六方面：

       功能性   可用性   可靠性   效率       可维护性       可移植性

！缺陷排除效率计算

       DRE = E / (E + D)

E=软件交付给最终用户之前所发现的错误数，D=软件交付之后所发现的缺陷数

！软件过程度量

概念：

       对软件过程进行度量的定义、方法、活动、结果的集合。

对象：

       工作产品（规模、质量两方面）、软件项目、过程

方法：

       采集方法（在不同的项目阶段针对不同类型的内容的数据采集）

       数据分析方法（多种数据表示方法和分析方法）

！基于目标的软件过程度量方法（GQM）概念

       GQM，基于目标的软件过程度量方法，是一种面向目标的、自上而下由目标逐步细化到度量的定义方法。

！软件配置管理（SCM）

概念：

       SCM，软件配置管理，是一种表示、组织、控制修改的技术。

（应用于整个软件工程过程）

目标：

       标识变更、控制变更、确保变更的正确实现

过程—3个阶段：

软件研发形目划分3阶段： 计划阶段       开发阶段       维护阶段

配置管理角度后两阶段工作一致，因此划分：      计划阶段       项目开发和维护阶段

计划阶段：

1. CCB（配置控制委员会）根据项目的开发计划确定各里程碑和开发策略
2. CMO（配置管理员）根据CCB的规划制定详细的配置管理计划，交CCB审核
3. CCB通过配置管理计划后交项目经理批准，发布实施

项目开发和维护阶段：

1. 由CMO完成的管理和维护工作
2. 由SIO（系统集成员）和DEV（开发人员）具体执行软件配置管理策略
3. 变更流程

6个关键活动：

1. 配置项识别
2. 工作空间管理
3. 版本管理
4. 变更控制
5. 状态报告
6. 配置审计

第四章 软件可靠性度量与测试

！软件可靠性

定义：

       在规定条件下，在规定时间内，软件不会引起系统失效的概率，该概率是系统输入和系统使用的函数，也是软件中存在的错误的函数，系统输入将确定是否会遇到已存在的错误；在规定时间周期内，在所述条件下，程序执行所要求的功能的能力。

输入向量：程序运行一次所需的输入数据构成一个输入向量

输入空间：全体输入向量的集合构成程序的输入空间

输出向量：输出数据构成一个输出向量

输出空间：全体输出向量的集合构成程序的输出空间

运行剖面：

       程序输入控件元素数量非常庞大，程序运行中每个元素被选用的概率互不相同，构成一定的概率分布，我么五年成这个概率分布为程序的运行剖面。

！软件差错、故障和失效

异常：偏离期望的状态（或期望值）的任何情形都称为异常。

缺陷：不符合使用要求，或与技术规格说明不一致的任何状态都称为缺陷。

差错：计算的、观测的或测量的值与真实的、规定的活理论上正确的值或者条件之间的差别；一个不正确的步骤、过程、数据定义；一个不正确的结果；一次产生不正确的结果的人的劳动。

故障：一个计算机程序中出现的不正确的步骤、过程、数据定义。

失效：一个程序运行的外部结果与软件产品的要求出现不一致时称为失效。

差错分类：

       （1）需求分析定义错误

       （2）设计错误

       （3）编码错误

       （4）测试错误

       （5）文档错误

错误引入软件的方式可归纳为两种特性：程序代码特性和开发过程特性

！软件可靠性模型列举

Musa模型（包括基本模型和对数模型）

       Shooman模型

       Goel-Okumoto模型

       测试成功模型

       威布尔模型

！软件可靠性评测

概念

       可靠性评测指运用统计技术对软件可靠性测试和系统运行期间采集的软件失效数据进行处理并评估软件可靠性的过程。

软件可靠性测试目的：

1. 正确的完成规定的功能
2. 满足性能要求
3. 不完成没有规定的功能
4. 提供运行中的故障数据

！软件质量分类

从构成因素上划分：

       产品质量（软件成品的质量）

       过程质量（开发过程环境的质量）

从是否考察运行状况进行划分：

       动态质量（考察运行状况来确认的质量）

       静态质量（审查各开发阶段的成果来确认的状况）

从开发过程进行划分:

       需求分析质量度量

       设计结果质量度量

       测试结果质量度量

       验收结果质量度量

！软件重用内容

       开发过程重用（指开发规范、各种开发方法、工具和标准等）

       软件构件重用（指文档、程序和数据等）

       知识重用（如相关领域专业知识的重用）

第五章 软件质量标准

！软件质量标准的顺序与层次

       国际标准       国家标准       行业标准       企业规范       项目规范

！能力成熟度模型5个级别

       初始级   可重复级       已定义级       已管理级       优化级

！PSP和TSP

PSP：个体软件过程：

       一种可用于控制、管理、改进个人工作方式的自我持续性改进过程，是一个包括软件开发表格、指南和规程的结构化框架。

TSP：团队软件过程：

       指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍。TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最短的时间内以预计的费用生产出高质量的软件产品。

！CMMI

含义：软件能力成熟度集成模型是CMM模型的最新版本。

中文全称：软件能力成熟度集成模型

第六章 软件评审

！软件评审的内容

管理评审（组织的最高管理者就管理体系的现状、适宜性、充分性、有效性以及方针和目标的贯彻落实与实现情况进行正式的评价）

技术评审（是一种同行审查技术，主要特点是由一组评审者按照规范的步骤对软件需求、设计、代码或其它技术文档进行仔细的检查，以找出和消除其中的缺陷）

文档评审（在软件开发的每个阶段，对该阶段形成的文档进行评审）

过程评审（通过对流程的监控保证SQA组织定义的软件过程在项目中得到了遵循，同时保证质量保证防战能得到更快、更好的执行）

！评审的方法（从随意到正式）

       特别检查

       轮查

       走查

       团队评审

       检视

！评审的技术

1. 缺陷检查表
2. 规则集
3. 评审工具的使用
4. 从不同角度理解产品
5. 场景分析技术

第七章 软件全面质量管理

！全面质量管理

       全面质量管理是一种由顾客的需要和期望驱动的管理哲学，是以质量为中心，建立在全员参与基础上的一种管理方法。

目的：长期获得顾客满意、组织成员和社会利益。

！戴明循环阶段及含义

       P(Plan)计划->D(Do)实施->C(Check)检查->A(Action)处理

！6σ项目管理

6σ含义：

         获得和保持企业在经营上的成功，并将其经营业绩最大化的综合管理体系和发展战略是使企业获得快速增长的经营方式；寻求同时增加顾客满意和企业经济增长的经营模式。

核心：

         追求零缺陷生产，防范产品责任风险，降低成本，提高生产率和市场占有率，提高顾客满意度和忠诚度。

！质量功能展开(6σ的先导步骤)

概念：

         在制造过程中用系统配置需求和特征关系的方法将顾客需求转变为“质量特性”，并展开质量设计，最终得到满足质量要求的产品。

核心组成部分：质量屋

第八章 高质量编程

！代码风格内容

         程序的版式、标识符命名、函数接口定义、文档等内容

！面向对象的设计规则（6种）

开-闭原则

里氏代换原则

依赖倒转原则

合成/聚合复用原则

迪米特原则

接口隔离原则

第九章 软件测试

！软件测试

目的：

1. 测试是程序的执行过程，目的在于发现错误
2. 一个好的测试用例在于能发现至今未发现的错误
3. 一个成功的测试是发现了至今未发现的错误的测试

原则：

1. 在整个开发过程中要尽早地和不断地进行软件测试
2. 在开始测试时不应默认程序中不存在错误
3. 在设计测试用例时要给出测试的预期结果
4. 测试工作应避免由系统开发人员或开发机构本身来承担
5. 对合理的和不合理的输入数据都要进行测试
6. 重点测试错误集群的程序区段
7. 除检查程序功能是否完备外还要检查程序功能是否有多余
8. 用穷举测试是不可能的
9. 长期完整地保留所有的测试用例和测试文件，直至该软件产品被废弃为止

要素：

       质量       人员       技术       资源       流程

阶段：

       单元测试       集成测试       系统测试       验收测试

V模型：

3种以上自动化测试工具：

黑盒测试工具：WinRunner

白盒测试工具：Jtest

性能测试工具：Silk

第十章 黑盒测试

！黑盒测试技术

等价类划分、边界值分析、因果图法

第十一章 白盒测试

！白盒测试

含义：按照程序内部的逻辑测试程序，检测程序种的主要执行通路是否能按预定要求正确工作。

分类：

静态分析：不通过执行程序而进行测试的技术

动态分析：当软件系统在模拟的或真实的环境中执行之前、之中、之后对软件系统行为的分析。

依据：软件设计说明书

！控制流测试

语句覆盖：程序中每条语句至少被执行一次。

判定覆盖：程序每个判定至少有一次为真值，有一次为假值，即每个分支至少执行一次。

条件覆盖：判定中的每个条件至少有一次为真值，有一次为假值

判定-条件覆盖：判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次

路径覆盖：每条可能路径都至少执行一次。若流程图有环，则每个环至少经过一次。

强度关系：

语句覆盖<判定覆盖<条件覆盖<判定-条件覆盖<路径覆盖

独立路径—基本路径

！程序插装

       在程序中特定位置插入记录动态特性的语句，把程序执行过程中发生的一些重要的历史事件记录下来。

作用：

1. 语句覆盖统计
2. 分支覆盖统计
3. 记录变量动态特性

！软件缺陷构成（5大类）

1. 功能缺陷
2. 系统缺陷
3. 加工缺陷
4. 数据缺陷
5. 代码缺陷

第十二章 基于缺陷模式的软件测试

！软件缺陷

产生原因：

1. 程序编写错误
2. 编写程序未按照规定
3. 软件越来越复杂
4. 开发人员的态度
5. 沟通上的问题
6. 需求变更太频繁
7. 进度上的压力
8. 管理上的失误

严重性：

       软件缺陷对软件质量的破坏程度，反映其对产品、用户的影响，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

优先级：

       表示修复缺陷的重要程度和应该何时修复，它是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

严重性和优先级是表征软件缺陷的两个重要因素，影响软件缺陷的统计结果和修正缺陷的优先顺序，特别是在软件测试的后期将影响软件是否能够按期发布。

！报告软件缺陷

基本原则：

1. 尽快报告
2. 有效地描述软件缺陷

有效描述规则：

       单一准确       可以再现       短小简练       特定条件

       补充完整       不做评价

IEEE软件缺陷报告模板的大致内容：

1. 软件缺陷报告标识符
2. 软件缺陷总结
3. 软件缺陷描述
   3.1输入
   3.2期望得到的结果
   3.3实际结果
   3.4异常情况
   3.5日期和时间
   3.6软件缺陷发生的步骤
   3.7测试环境
   3.8再现测试
   3.9测试人员
   3.10见证人
4. 影响

！软件缺陷管理

目标：

1. 及时了解并跟踪每个被发现的缺陷
2. 确保每个被发现的缺陷都能够被处理
3. 收集缺陷数据，并根据缺陷趋势曲线来识别测试过程是否结束
4. 收集缺陷数据并在其上进行数据分析，作为组织的过程财富

缺陷生命周期：

       发现缺陷—分配缺陷—修复缺陷—验证缺陷—解决缺陷

工具：

       Bugzilla  ClearQuest

分析指标（4个）：

       缺陷发现率（发现的缺陷数量与时间之间的函数关系）

       缺陷潜伏期

       软件缺陷密度（=软件缺陷数量/代码行或功能点的数量）

       缺陷清除率

                     （质量=发布后发现的缺陷数/描述软件规模用的功能点）

                     （软件缺陷注入率=发现的总软件缺陷数/描述软件规模用的功能点）

                     （软件缺陷清除率=开发过程中发现的缺陷数/发现的总软件缺陷数）

第十三章 集成测试

！集成测试

定义：

       集成测试是在单元测试的基础上将多个模块组合在一起进行测试的过程，主要检查各个软件单元之间的相互接口是否正确。

原则：

1. 所有公共接口都要被测试到
2. 关键模块必须进行充分的测试
3. 集成测试应当按一定层次进行
4. 集成测试的策略选择应当综合考量质量、成本和进度之间的关系
5. 集成测试应当尽早开始，并以总体设计为基础
6. 在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通
7. 当接口发生修改时，涉及的相关接口必须进行再测试
8. 测试的执行结果应当如实记录

策略：

第十四章 系统测试

！系统测试

含义：

       系统测试是指将通过集成测试的软件系统作为计算机的一个重要组成部分与计算机硬件、外设、某些支撑软件的系统等其它系统元素组合在一起所进行的测试。

主要方法：（12）

       性能测试       强度测试       安全性测试   兼容性测试   恢复测试

       用户图形界面测试      安装测试       可靠性测试   配置测试

       可用性测试   文档资料测试      网站测试

系统测试工具分类：

1. 负载压力测试工具--LoadRunner
2. 功能测试工具--WinRunner
3. 白盒测试工具--JText
4. 测试管理工具--TestManager

第十五章 测试管理

！测试人员与程序人员的基本关系

       开发经理的目标是推进其小组开发软件。测试员报告软件缺陷会妨碍该过程，测试员这边工作得好，就会显示程序员工作得不好。如果开发经理为测试员提供更多的资源、经费，测试员就会找出更多软件缺陷。找出的软件缺陷越多，就越会妨碍经理开发软件的目标。

！测试管理过程—基本过程

代码会审

单元测试

集成测试

验收测试

！测试计划的主要内容

       概要（测试应该做什么）

       目标和发布标准

       测试的领域

       测试方法描述

       测试进度表

       测试资源

       配置范围

测试工具

！调试与测试的区别

1、目的：测试的目的是找问题，调试的目的是找到并解决问题。

2、人员：测试由专门的测试人员完成，调试由开发人员完成。

3、结果：测试从已知条件开始，使用预定义的过程，并且有预期结果；而调试条件未知，结果不可 预知。

4、过程：测试可以预先计划，可以制订测试用例和计划，进度可以度量；调试没有计划，进度也不可以度量。

5、阶段：测试贯穿于软件生命周期的整个阶段；调试只在编码阶段进行。

！软件测试自动化

引入条件：

1. 从项目规模上来说没有严格限制
2. 从公司的产品特征来讲，一般开发产品的项目实施自动化测试要比纯项目开发优越
3. 从测试人员个人素质和角色分配来讲，处理有高层中室外，还应该有个具有良好的自动化测试背景和丰富自动化测试经验的测试主管，不仅在技术方面，更重要的是在今后的自动化测试管理位置起着领导作用。

使用条件：

1. 具有良好定义的测试策略和测试计划
2. 对于自动化测试拥有能够被识别的测试框架
3. 能够确保多个测试运行的构建策略
4. 多平台环境需要测试
5. 拥有运行测试的硬件
6. 拥有关注在自动化过程上的资源