软件质量保证与测试

tips ：  说在前面的话： 本文章是用来应试的，而且老师也没画重点，只是自己摸石头过河罢了

如果是正经自学测试，这个太古老了，请移步到最新的开源课程和项目当中训练，远比在这看这些

陈词滥调的东西有效的多。 另外，笔者会不定时进行更新和补充文章，最终整理后，会有置顶提

示结束成文标记，以兹诸君详周。如果本文章对诸君有帮助，敬请点赞收藏支持。拱手敬意。

1 ： 软件危机

软件测试是软件生命周期中的一个独立阶段，并且在软件开发的每个阶段都有相关等测试活动。

早期等软件测试 等于 “调试”

测试不单纯是一个发现错误的过程，而是软件质量保证等主要职能。测试上对软件质量的度量

软件质量保证  : 标准，规范，体系，管理

规范，约束等测试定义 ： 

 *  在特定等条件下运行系统或者构件，观察或记录结果，对系统等某方面做出评价

 分析某个软件项已发现和现存等，以及要求的条件之别（即错误）并评价此软件项等特性

软件测试的目的 ： 

 1 ： 最少的人力，物力，时间

2 ： 为软件可靠性分析提供相关数据

3 ：对软件质量进行度量和评估

软件测试 & 软件质量保证

成功的测试是发现了迄今尚未发现的错误的测试

软件质量保证和软件测试二者之间是既存在包含又存交叉关系

软件质量保证 是贯穿软件项目整个生命周期等有计划和有系统的活动

确保软件项目的过程遵循了对应的标准和规范要求且产生力合适的文档和精确反应项目情况等报告，目的是：提供评价项目质量建立项目达到质量要求的信心

软件测试上获取度量值等一种重要手段

在执行软件产品评价时，确立评价需求的质量模型就要采用度量

相同点 ： 

1 ： 目的都是尽力确保软件产品满足需求

2 ： 都是贯穿软件开发生命周期

不同点 ： 

1 ： 测试  查找错误并进行修改，从而提高软件产品的质量，关键问题上如何选择测试用例

2 ： 软件质量保证 测试避免错误以求高质量并且还有其他方面等措施以保证质量问题

软件测试系统和软件质量保证的内容区别

软件测试系统 ：

 制定测试计划 ； 测试设计 ； 

实施测试 ； 建立和更新测试文档

软件质量保证 ：

 制定软件质量要求 ； 组织正式度量 ； 

软件测试管理 ； 对软件等变更进行控制；

 对软件质量进行度量； 对软件质量情况及时记录和报告

分类方法

按测试阶段或测试步骤划分 ：

       目的是验证软件开发过程的各阶段等工作是否符合需求和设计要求

1: 单元测试 ： 

在软件单元完成编码以后，首先进行单元测试，验证软件单元是否正确实现了规定等功能和接口等要求

2：集成测试：

在确保没有问题后，将软件单元组装在一起进行集成测试，验证软件是否满足设计要求

3 ： 确认测试 （Alpha测试 & Beta测试）

Alpha 测试 ：

 在开发方等场所，用户在开发人员等指导下对软件进行测试，测试上受控的，开发人员负责记录错误和使用中出现的问题

Beta 测试 ：

  测试是由软件等最终用户在一个或多个用户场所来进行，开发人员通常不在现场，整个测试不被控制，用户记录下力所有问题，并报告给开发人员 

tips： 

调试应该由  编制该源程序的程序员 完成

4 ： 系统测试 （超出软件工程范围的测试）

最后使通过确认测试的软件与其他系统成分组合在一起，并使其在实际运行环境中进行，进行系统测试

按测试对象划分

单元测试

部件测试

配置测试 

软件配置项 是为了配置管理而设计的并且能够满足最终用户功能的软件，在配置管理过程中作为单个实体对待

软件部件 是构成软件配置项或系统等部分之一，在功能上或逻辑上具有一定等独立性，且可以进一步划分为其他部件

系统测试

tips ： 

在设计人机界面时,应主要考虑的因素有   1： 响应时间 ；2：错误处理；  3 ： 用户求助机制

按测试技术划分：

静态测试 ； 动态测试（白盒测试 ； 黑盒测试）

软件测试种类之间等密切关系

在软件开发过程中，不同阶段等测试对应了不同软件对象的测试

在不同等测试解读那，由于测试 目标，对象，要求等不同而采用不同等测试技术。

一般情况下不同测试对象中采用的测试技术

在不同等阶段对不同对象测试包含不同的测试项目

软件质量和测试相关特性

软件质量模型

 ISO 关于质量等定义

  一个实体等所有特性，基于这些特性可以满足明显等或隐含等需求

就是 实体基于这些特性满足需求的程度

质量定义包含等要素

 实体 + 特性集合 + 需求

软件质量

 软件与明确的和隐含等定义需求相一致等过程

评价软件质量  

 【1】 静态质量特性：

静态质量特性包括结构化的，可维护的，可维护的，可测试的代码，正确且完整的文档

【2】动态质量特性：

软件动态质量特性 : 正确性，可靠性，完整性，一致性，易用性，性能

影响软件质量的要素

流程，技术，组织  是影响软件质量的主要因素。提高软件需求需要从每个方面进行修改，同时还需要兼顾 成本和进度

流程 

思想方式 ： 从计划到策略的实现

来源 ： 成功的经验

优点 : 提高软件质量，有利于项目的成本和进度控制

技术

包括分析技术，设计技术，编码技术，测试技术。

需求是项目的灵魂

软件质量是设计出来的

编码技术产生正确高效的代码；测试是保证软件的最后一道防线

组织

有效促进流程实施，提供员工发展通道以吸引更多人（技术载体）

软件质量是软件发生命

软件质量直接影响软件的使用和维护

评价质量优劣途径：

• 软件需求是衡量软件质量的基础
• 软件结构良好，易读，易于理解，易于修改，维护。
• 软件系统具有友好的用户界面，便于用户使用
• 软件生存周期中各阶段文档齐全，规范，便于配置，管理

内外部质量含义

软件质量子特性

• 功能性 : 满足明确和隐含要求功能的能力
• 可靠性：维护规定的性能级别的能力
• 易用性：软件产品被理解，学习，使用，吸引用户的能力
• 效率： 相对所有资源的数量，软件产品可提供适当的性能的能力
• 维护性：修正，改进或软件适应环境，需求和功能规格说明中的变化
• 可移植性：软件产品从一种环境迁移到另一种环境的能力

软件质量活动

软件质量管理体系

CMM认证（精髓在于 : 过程决定质量）

• CMM :  软件过程能力成熟度模型
• CMMI : 能力成熟度模型集成

6 Sigma（六西格玛）

制定极高的目标，收集数据以分析结果，以减少陈皮和服务缺陷

软件质量活动

软件质量保证、度量和测试

SQA (软件质量保证) 和 测试 的关系

• SQA从流程方面保证软件的质量；
• 测试从技术方面保证软件的质量；
• 只进行SQA活动或只进行测试活动活动不一定产生好的软件质量

SQA工作范围：

• 保证制度体系
• 使用过程改进
• 指导项目实施
• 增加透明度
• 评审项目活动
• 审核工作产品
• 协助问题解决
• 提供决策参考
• 进行缺陷预防
• 实现质量目标

度量

【1】 度量的概念：

度量：对事物属性量化表示

软件度量：对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程

【2】 度量的目的：

提高软件生成率，缩短产品研发周期，降低研发成本和维护成本

提高软件产品质量，提高用户满意度

为组织持续改进提供变量化的指标和反馈

【3】度量的作用：

1. 作用1 ： 理解
2. 作用2 ： 预测
3. 作用3 ： 评估
4. 作用4 ： 改进

度量的过程

【1】识别目标 ： 根据管理者的不同要求，分析度量的工作目标，并根据其优先级和可行性，得到度量活动中的工作列表，并由管理者审核批准

【2】根据度量目标，定义度量过程： 收集要素，收集过程，分析/反馈过程，IT支持体系

【3】 数据收集

【4】数据分析与反馈

【5】过程改进

测试等复杂性和经济性

程序测试只能证明错误存在，不能证明错误不存在

测试的复杂性

测试的经济性：

黑盒测试复杂性

白盒测试的复杂性

软件测试充分性和测试停止标准

软件测试充分性问题

成功测试：

1：软件在所有的（或足够多的）测试数据上是正确的；

 2：数据是充分的，即软件在测试数据上的表现能够充分反映软件的总体表现

测试软件在测试数据上行为的正确性称为测试的“先知者问题”。判断一个测试数据集合是否充分称为充分性问题

软件测试通过有限测试数据来测试软件，以发现软件的缺陷

软件的实际运行空间是非常大的，有时甚至是无限的。

在有限的测试输入数据空间上的软件行为是否能够充分反映而无限的软件运行空间的行为，这就是软件测试的充分性问题

测试充分性准则 :

[1]  谓词 :  用于判断一个测试数据集是否充分  ex : 程序中的语句是否都经过测试

[2]  度量函数： 赋予测试数据集一个充分度 ex : 程序中已测试的语句所占的百分比

测试充分性公理：

将公里系统应用到软件测试的研究当中：

【1】 非外延公理 : 功能相同实现不同，其中一个充分测试数据集另一个不一定是

【2】 多重修改公理 ： 相同语言结构，对一个是充分的，另一个不一定

【3】 不可分解公理 ： 对一个程序进行了充分的测试，不表示对其成分都进行了充分测试

【4】 非复合公理 ： 对程序各单元是充分的，对整个集成后的程序不一定

覆盖应用

软件测试原则

七个原则

1. 测试显示软件存在缺陷
2. 穷尽测试是不可能的【1: 程序输入量大； 2： 程序输出量太多； 3：软件实现途径太多】
3. 测试尽早介入
4. 缺陷集群性（2 / 8原则）
5. 杀虫剂悖论【测试越多，程序免疫力越强，应根据不同测试方法开发测试用例】
6. 测试活动依赖于测试内容
7. 没有错误是好是谬论

从用户，开发者出发，软件测试会派生两种不同的测试原则：

【1】 用户 希望通过软件测试能充分暴漏软件中存在的问题和故障

【2】 开发者 希望测试能表明软件产品正确实现了用户的需求，没有软件故障存在

完全测试程序是不可能的

软件测试是有风险的 

使有限的测试投资获得最大收益（以有限的测试用例检查出尽可能多的软件故障）

测试无法显示隐藏的软件故障

不能保证软件故障全部被找到，无法报告隐藏的软件故障

存在的故障数量和发现的故障数量成正比

1：程序员自己作 ； 2 ：犯同样的错误 （还是自己作）； 3：可能是极其严重的原因造成

杀虫剂现象

根据不同的测试方法开发测试用例，对程序的不同部分进行测试，找到更多软件故障

并非所有软件故障都能修复

不能修复原因 ：

【没有足够时间】 【不值得修复】 【修复风险太大】【不算真正的软件故障】

不要丢弃测试用例

除非确实没有用，一般不要丢弃测试用例

应避免测试自己编写的程序

由别人操作会更有效更成功，不是说程序员不考研测试自己的程序

软件测试是一项复杂的，具有创造性的和需要高度智慧的挑战性任务

生产低质软件的代价太大了，软件行业也发展为强制使用软件测试人员的时代

测试停止准泽

第叁章 ：软件测试策略

软件开发过程及模型

软件开发过程

定义

软件开发过程 是软件开发与维护的 工作流程和工艺流程，是软件工程的重要组成部分

包括

设计软件的功能和实现的算法和方法，软件的总体结构设计和模块设计，编程和调试，程序联调和测试以及编写，提交程序

抽象流程

概念化阶段：

• 项目的起源
• 项目目标
• 主要特性
• 功能范围
• 成功要素

需求分析：

软件需求类型：

软件需求和框架之间的关系

软件开发过程所涉及的阶段

可行性研究 -->需求分析 -->概要设计-->详细设计-->实现-->集成测试-->确认测试-->使用维护

软件开发过程模型

定义

软件开发模型则描述阶段如何组合在一起，是软件开发活动以及它们之间关系的结构框架

属性

• 所执行的活动
• 每种活动的可交付产品
• 可交付产品的确认方式
• 活动序列
• 每种活动的验证方式，包括活动之间的沟通机制

软件开发模型的种类

瀑布模型，原型模型，快速原型模型，增量模型，螺旋模型，V字模型，W模型，X模型，H模型，喷泉模型 ，XP模型

瀑布模型：

特点：

【1】：项目分解为独立的不同阶段

【2】：项目之间有顺序性和依赖性，每个阶段通过预先定义的输出和下一阶段发生联系

【3】：若发现错误，返回上一阶段，一次跳一个阶段，直到在某个较早阶段改正

优点：

• 简单（适用于可以实际划分为独立部分，需求分析好，二次开发系统）
• 易于管理，易于组织：（可以预先完成所有计划）
• 质量保证：每个阶段必须完成规定的文档，每个阶段结束前完成文档审查，及早改正错误

不足：

• 阶段之间产生大量的文档
• 整个过程的末期才能见到开发成果
• 早期错误后期测试才能发现

快速原型模型

适用于 ： 1 : 开发者不了解的应用领域 ； 2：客户不清楚所开发的软件项目的最终目的

步骤

1. 建造一个快速模型，实现客户或未来用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件需求
2. 在第一步基础上开发客户满意的软件产品

增量模型

适用于：技术风险较大，用户需求较为稳定的软件系统

优点：

• 有助于获取用户需求，加强对需求的理解
• 尽早发现软件中的错误，降低开发风险
• 支持需求的动态变化

不足：

• 加入的各个构件不能破坏已构造好的系统部分，这要求软件具备开放式的体系结构
• 易退化为边做边改模型，从而使软件过程的控制失去整体性

螺旋模型

适用于：需求不能完全确定，同时又存在技术，资金或开发时间的大型开发项目

优点：

• 有助于获取用户需求，加强对需求的理解
• 尽早发现软件中的错误
• 支持需求的动态变化
• 支持风险分析，可降低或者消除软件开发风险
• 适合于需求动态变化，事先难以确定并且开发风险较大的系统

不足：

螺旋模型开发的成败，很大程度上依赖于风险评估的成败，需要开发人员具有相当丰富的评估经验和专门知识

单元测试

单元测试方法

测试的四个阶段：

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

按阶段进行测试是一种基本的测试策略

定义

单元测试是对软件基本组成单元进行的测试

时机

一般在代码完成后由开发人员完成，QA人员辅助

对象

类，模块，组件，单元

依据

软件的详细设计描述，源程序清单，编码标准

目的

• 验证代码能否达到详细设计的预期要求
• 发现代码中不符合编码规范的地方
• 准确定位发现的错误，以排除错误

优点

单元测试是在编码过程中进行的，在所有测试前进行

效益更优秀

步骤

单元测试的实施应遵循一定步骤：力争有计划，可重用

1. 计划单元测试
2. 设计单元测试
3. 实现单元测试
4. 执行单元测试
5. 单元测试结果分析并提交测试报告

环境构成

在单元测试时，单元测试一般为编码步骤的附属部分，模块不是独立的程序，模块不是独立的程序，自己不能运行，要靠其他部分来调用和驱动，要为每个单元测试开发两个软件 :

• 驱动模块：驱动模块接收测试数据，调用被测单元将数据传递给被测单元（被侧单元主程序）
• 桩模块：替代被测单元的子模块，设计桩模块的目的是模拟实现被测单元的接口。

构件单元测试的环境

• 构造最小运行调度系统（构造被测单元的驱动模块）
• 模拟被测单元的接口，即构造被测单元调用的桩模块
• 模拟生成测试数据及状态，为被测单元运行准备动态环境

单元测试内容

内容

• 模块接口
• 局部数据结构测试
• 路径测试
• 错误处理测试
• 边界测试

模块接口测试

• 形参在个数，属性，顺序上是否匹配
• 调用子模块时是否匹配
• 是否修改了只做输入用的形式参数
• 输出参数在个数，属性，顺序是否匹配
• 全局变量定义在各模块是否一致
• 限制是否通过形参传递

局部数据结构测试

• 检查不正确或不一致的数据类型说明
• 使用尚未赋值或尚未初始化的变量
• 错误的初始值或错误的默认值
• 变量名拼写错误或书写错误
• 不一致的数据类型

单元测试类型

• 逻辑单元测试
• 集成单元测试
• 功能单元测试

断言

• assertion 是调用方式，较多语言支持这种机制

• assertion 是程序中的一条语句

• assertion 保证程序最基本，关键的正确性

• assertion 在开发和测试时开启，在软件发布后关闭

单元测试的作用

目的：

• 验证代码能否达到详细设计的预期要求
• 发现代码不符合编码规范的地方
• 准确定位发现的错误，排除错误

作用:

• 编写单元测试可以帮助开发人员手写高质量代码
• 编写单元测试可以使开发人员更有信心重构应用程序，接受变化

集成测试

集成测试目的

定义：

在单元测试的基础上，将所有模块按照概要设计要求组装成子系统或系统，进行集中测试（组装测试，联合测试，子系统测试或部件测试）

时机：

单元测试完成后便进入集成测试阶段

对象：

模块间的接口，接口之间的关系

特点：

• 保障模块间接口信息内容的正确性，相互调用关系符合设计
• 集成测试用例从程序结构出发，目的性，针对性更强，测试项发现问题效率更高
• 集成测试能模拟所有实际情况
• 定位问题较快

关注点：

集成测试的范围及测试层次

集成测试策略（关注的核心）

集成测试方法

分类：

非增试测试 ； 增试测试

非增试测试

大爆炸集成测试

增试测试：自顶向下； 自顶向上

自顶向下

集成测试作用

5   黑盒测试

 # 边界值

分析软件规格说明书等资料，由划分等价类等原则，列出等价类表（包括有效类和无效类），由确定测试用例等具体过程，学出某种（标准或者健壮）

划分等价类首先考虑输入和输出条件 ：有效的限定，