NEFU软件质量保证与测试阶段复习

前言

复习速成笔记

课程评价：软件工程为什么不好好讲这门课啊 ？？？纯文科、

正经自学，请移步到最新的开源课程和博客

补充由于本校ppt太烂，部分参考华中科技大学PPT，西北工业大学PPT

一、软件测试基础 

1.1测试定义

• 测试不单纯是一个发现错误的过程，而且是软件质量保证的主要职能
• 测试是程序的执行过程，目的在于发现问题。
• 测试是为了证明程序有错，而不是证明程序无错误。
• 一个成功的测试是发现了至今没有发现的错误的测试

软件测试的目的 ： 

•  最少的人力，物力，时间
• 为软件可靠性分析提供相关数据
• 对软件质量进行度量和评估

1.2软件质量保证和软件测试异同

 软件测试能够找出软件缺陷，确保软件产品满足需求。但测试不是质量保证，二者并不等同。测试可以查找错误并进行修改，从而提高软件产品的质量。软件质量保证则是避免错误以求高质量并且还有其他方面的措施以保证质量问题。

1.3测试的分类

单元测试：

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

集成测试：

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

 系统测试：

糸统测试：检验软件产品能否与糸统的其他部分(此如，硬件、数据库及操作人员)协调工作。用于评估整个系统的行为并确保糸统行为待合用户需求，并评估系统与硬件设备、运行环境和应用程序等之间的接口。

验收测试(有效性、合格性)：

其目的是验证软件的功能和性能及其特性是否与客户的要求一致，是否满足软件需求规格说明书中的规定。

在验收测试中，按照测试的方式又有Alpha测试和Beta测试。

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

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

 按测试对象划分：

配置测试 

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

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

按测试技术划分

1.4软件测试这些种类之间密切的关系：

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

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

1.5软件缺陷的概念

定义

• 软件未达到产品说明书中标明的功能。
• 软件出现了产品说明书中指明的不会出现的功能。
• 软件功能超出了产品说明书中指明的范围。
• 软件未达到产品说明书中指明应达到的日。
• 软件难以理解和使用、运行速度慢，或最终用户认为不好。

软件缺陷的等级分类：

• 致命错误
  • 不能执行正常工作或重要功能、导致系统崩溃或资源严重不足、造成数据丢失。
• 严重错误（如功能未实现或实现错误）
  • 严重影响系统要求或基本功能实现、且不存在可替代的解决方法或方式
• 一般错误（打印内容、格式错误）
  • 影响系统要求或基本功能实现，但存在可替代的解决方法或方式。  
• 轻微错误（如界面不规范）
  • 操作不便或遇到麻烦，但不影响执行工作或使用重要功能。属于该级别的缺陷

软件缺陷的属性 

一般地发现缺陷后，需要提交缺陷单，通常情况下，缺陷单需要包含以下的内容：

1.6软件测试充分性问题

软件测试是使用经过设计获得的有限测试数据来测试软件，以发现软件的缺陷。

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

软件测试原则

• 完全测试程序是不可能的
• 软件测试是有风险的，以有限的测试用例检查出尽可能多的软件故障
• 通过测试可以查找并报告发现软件故障，但是不能保证软件故障全部被找到，也无法报告隐藏的软件故障。
• 存在的故障数量与发现的故障数成正比
• 软件测试进行的越多，其程序免疫力越强的现象（杀虫剂现象）
  • 应该根据不同的测试方法开发测试用例
• 并非所有软件故障都能修复

1.7软件质量和测试相关特性

软件质量

 质量定义包含的要素：实体+特性集合+需求；

软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”

评价软件质量  

 【1】 静态质量特性：

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

【2】动态质量特性： 

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

影响软件质量的要素

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

软件质量活动

• ISO9000:2000版标准
• CMM认证（精髓在于：过程决定质量）
• 6 Sigma（六西格玛）

软件质量活动有：软件质量保证SQA、度量和测试

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

测试的复杂性和经济性

软件测试Vs软件质量

1.8软件质量保证

软件质量保证就是通过对软件产品有计划地进行检查和审计来验证软件是否合乎标准，找出改进的方法，以达到防止产生软件缺陷的目的。

它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。

• 质量控制
• 质量保证

软件质量标准

• ISO9000标准
• CMM

1.9软件测试过程

主要的测试工作是随着糸统实现阶段的展开而开始的，并一直持续到产品发布之后。

1.10测试用例的定义

测试用例就是为了达到测试效率的要求而精心设计的数据。其核心内容包括：输入（数
据+步骤)、预期输出、测试环境。

二、单元测试

2.1单元测试的定义

单元测试又称模块测试，是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。

测试依据是详细设计描述

测试对象：

• 结构化编程一函数、过程
• 面向对象编程一类

2.2单元测试的原则

• 应该依据《软件详细设计规格说明》进行；
• 当测试用例的测试结果与设计规格说明上的预期结果不一致时，测试人员应该记录实际结果；
• 应该包含正面测试和负面测试；

2.3单元测试一测试内容 

• 功能测试
• 语句和分支覆盖率
• 模块设计是否合理
• 输入和输出接口测试
• 内部数据流测斌
• 其它要特定要求的测试

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

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

 2.4单元测试策略

• 自顶向下的单元测试
  • 在集成测试前提供早期的集成途径。在执行上和详细设计的顺序一致。不需要开发驱动模块。
• 自底向上的单元测试
  • 在集成测试前提供系统早期的集成途径。不需要开发桩模块
• 孤立单元测试
  • 不考虑每个单元与其它单元之间的关系，为每个单元设计桩模块或驱动模块。每个模块进行独立的单元测试。

单元测试需要输入

• 《软件需求规格说明书》
• 《软件详细设计说明书》

 2.5单元测试自动化（了解）

单元测试必须自动化

三、集成测试

3.1集成测试的定义

集成测试（Integration Testing）是在假定各个软件单元已经通过了单元测试的前提下，检查各个软件单元之间的相互接口是否正确。

集成测试与系统测试的区别

1. 范围不同：集成测试主要关注各个模块之间的接口和交互，系统测试则关注整个系统的功能和性能（站在用户的角度）。
2. 目的不同：集成测试旨在验证各个模块的正确性和协同工作，系统测试旨在验证整个系统是否符合需求规格和用户需求。
3. 测试对象不同：集成测试主要测试模块间的接口和交互（概要设计），系统测试则测试整个系统的功能、性能、安全性等方面（据来自用户的需求规格说明书）。

3.2集成测试的原则

• 所有公共接口必须被测试到；
• 集成测试策略选择应当综合考虑质量、成本和进度三者之间的关系；
• 并以概要设计为基础；
• 集成测试应根据集成测试计划和方案进行，不能随意测试；

集成测试的依据是需求规格说明书、概要设计及详细设计说明书。 

3.3集成测试过程

• 计划阶段
• 设计阶段
  • 为高覆盖设计用例：指功能覆盖和接口覆盖
• 实施阶段
• 执行阶段
  • 测试执行的前提条件就是单元测试已经通过评审。
  • 测试执行结束后,填写集成测试报告，最后提交给相关人员评审
• 评估阶段

 3.4集成测试策略

非渐增式集成

 非渐增式集成方法首先对每个子模块进行测试（即单元测试），然后将所有模块全部集成起来一次性进行集成测试。

渐增式集成

自顶向下集成

使用深度优先的策略，或者使用宽度优先的策略。

• 产品的底层接口未定义或经常可能被修改。
• 产品的控制模块具有较大的技术风险，需要尽早被验证。

自底向上集成

不需要桩模块。

• 能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误。
• 低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力。

 三明治集成

桩模块和驱动模块的开发工作都比较小，不过代价是在一定程度上增加了定位缺陷的难度。

三明治集成就是要把系统划分成3层，即顶层、中间层和底层，中间层为目标层。测试时，对目标层上面的一层使用自顶向下的集成测试策略，对目标层下面的一层使用自底向上的集成测试策略，最后测试在目标层汇合。

四、系统测试

4.1系统测试的定义

系统测试（system testing）是指测试整个系统以确定其是否能够提供应用的所有需求行为。 包括多种测试活动，分为功能性测试和非功能性测试。

• 一般使用黑盒测试技术
• 一般由独立的测试人员完成

4.2功能测试

功能测试是系统测试最基本的测试。

功能测试的方法：

• 链接或界面切换测试（补充）
• 业务流程测试
  • 基于用例场景设计测试用例。
  • 用例场景是通过描述流经用例的路径来确定的过程

4.3性能测试

性能测试主要检验软件是否达到需求规格说明书中规定的各类性能指标，并满足一些性能相关的约束和限制条件。

性能测试基准

• 响应时间 
• 并发用户数
• 吞吐量
  • 单位时间内系统处理的客户请求数量。

性能测试策略

性能测试概括为三个方面

• 应用在客户端性能的测试
  • 并发性能测试
  • 疲劳强度测试（确定系统处理最大工作量的性能）
  • 大数据量测试和速度测试等
• 应用在网络上性能的测试
• 应用在服务器端性能的测试

4.4压力测试

压力测试（Stress Testing）是指模拟巨大的工作负荷，以查看系统在峰值使用情况下是否可以正常运行。逐步增加系统负载

压力测试一般用于测试系统的稳定性。

压力测试与性能测试的联系与区别：

• 压力测试是通过确定一个系统的瓶颈，来获得系统能提供的最大服务级别的测试。
• 性能测试是检测系统在一定负荷下的表现，是正常能力的表现；而压力测试是极端情况下的系统能力的表现。

压力测试手段：

• 重复（Repetition）测试：
• 并发（Concurrency）测试
• 量级（Magnitude）增加
  • 测试人员可以通过模拟输入超长消息来使操作进行高强度的使用，即增加这个操作的量级
• 随机变化
  • 指对上述测试手段进行随机组合，以便获得最佳的测试效果。

压力测试用例选取： 磁盘空间、极端的网络负载、系统溢出

4.5容量测试

容量测试是系统测试的一种类型，主要用于评估系统在不同负载条件下的性能表现和容量限制。容量测试旨在确定系统在处理大量用户、数据或交易时的性能瓶颈，以及系统能够承受的最大负载。

容量测试与压力测试的区别

• 压力测试主要是使系统承受速度方面的超额负载，例如一个短时间之内的吞吐量。
• 容量测试关注的是数据方面的承受能力，并且它的目的是显示系统可以处理的数据容量。

进行容量测试的首要任务就是确定被测系统数据量的极限，即容量极限。

系统出现问题，通常是发生在极限数据量产生或临界产生的情况下，这时容易造成磁盘数据的丢失、缓冲区溢出等一些问题。

饱和点是指所有性能指标都不满足，随后应用发生恐慌的时间点。

4.6安全性测试

软件安全性测试包括程序、数据库安全性测试。

目的：发现软件系统中是否存在安全漏洞

• 用户认证安全
• 系统网络安全
• 数据库安全
• SQL注入攻击
• 缓冲区溢出

4.7用户界面测试

五、变异测试

5.1变异测试的定义

变异测试是一种先进的软件测试方法，旨在通过错误注入来验证测试用例的有效性。

变异测试的主要目的是检验测试用例集的质量。它通过在被测代码中人为地引入错误（变异），然后运行现有测试用例，观察这些测试用例是否能发现这些故意引入的错误。如果测试用例能够检测到变异造成的错误，则认为该测试用例是有效的；如果不能，那么需要改进或新增测试用例。

变异测试方法可用于度量测试用例缺陷检测能力。

5.2相关概念

• 程序变异：指基于预先定义的变异操作对程序进行修改，进而得到源程序变异体（变异程序）的过程。
• 变异是一种变更程序的行为，即使只是轻微的变更也可以被称为变异。用P表示原始被测程序，M表示轻微变更P后得到的程序，则可以把M称为P的变体(mutation)
• 变异算子定义了从原有程序生成差别极小程序（即变异体）的转换规则
  • CRP常量替代

5.3变异类型

• 强变异：它要求测试用例不仅能够发现代码中的错误，而且这些错误必须能够传播到程序的输出并被测试检查。这意味着强变异能够更有效地保证测试用例真正捕捉到错误。
• 弱变异：只要求测试用例能够发现代码中的错误，而不要求这些错误传播到程序的输出。这种变异近似于代码覆盖方法，它更多地关注测试用例是否能够覆盖到代码的不同部分。
  • 弱变异检测方式的优点是不需要完整执行整个变异体

传统变异测试分析一般采用的是强变异检测方式。

主要观察的是程序返回值以及相关影响，包括全局变量值和数据文件的变化等。

变异得分（Mutation Score）是一种评价测试用例集错误检测有效性的度量指标；其值介于0与1之间，数值越高，表明被杀死的变异程序越多，测试用例集的错误检测能力越强，反之则越低

六、回归测试

6.1回归测试定义

回归测试是软件测试过程中的一个重要环节，主要目的是验证代码修改后是否影响了软件的现有功能和性能。

回归测试的原因

• 在任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。
• 软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。

6.2回归测试类型

• 单元回归测试 [URT]
• 区域回归测试[RRT]
• 全面或完整的回归测试 [FRT]

单元回归测试

单元回归测试是指在软件开发过程中，对单独的软件模块或单元进行的回归测试。它的目的是确保这些模块在经过修改、更新或修复后，其功能仍然正常且没有引入新的错误。

区域回归测试

区域回归测试的主要目的是验证在软件的某个特定区域或功能模块中所做的更改是否影响了该区域或模块的功能，并且没有引入新的错误。

全面回归测试

全面回归测试是一种测试方法，它涉及对软件的所有功能进行再次测试，以确保最近的更改没有引入新的错误或对现有功能产生负面影响。

回归测试用例的来源

当得到一个软件基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。

在需要进行回归测试的时候，可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试

软件基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。

6.3测试用例库的维护

回归测试的价值在于它是一个能够检测到回归错误的受控实验。

6.4回归测试策略

• 再测试全部用例
• 基于风险的选择测试
  • 基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例
• 基于操作剖面选择测试
• 再测试修改部分
  • 通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

6.5冒烟测试

冒烟测试是一种基础的软件测试方法，用于快速验证软件的基本功能是否正常工作。

冒烟测试的主要目的是确认软件的基本功能是否已经实现，并确定是否需要进行更多的测试。如果冒烟测试失败，软件将不会进入更深入的测试阶段，而是直接返回给开发人员进行修复。这种测试通常在软件开发过程中的新软件版本发布前进行，以确保软件能够正常启动和运行其最基本功能。

冒烟测试与回归测试的区别

七、测试用例开发

7.1相关概念

测试场景

测试场景是软件测试中的一个术语，指的是对特定功能或系统行为进行测试的具体情境或条件。

场景的准备是最关键的部分，需要从客户、利益相关者或开发人员那里寻求建议或帮助来准备场景。（用户的角度）

测试用例

测试用例是软件测试中的一个基本概念，用于描述特定条件下对软件进行测试的具体步骤和预期结果。

极简版：测试用例 = 输入 +测试环境+输出

测试用例的主要目的是验证软件是否满足特定的需求或功能，并确保其在不同情况下的行为符合预期。通过执行测试用例，测试人员可以发现软件中的错误、漏洞或其他问题，从而帮助开发团队改进软件的质量。

7.2测试用例评审

为什么要进行测试用例评审？

• 当测试工程师编写测试用例时，可能会跳过一些场景、输入并编写错误的导航步骤，这可能会影响整个测试执行过程。
• 如果不进行审查，就会错过一些场景，准确性就不会存在，测试工程师也不会认真对待

测试执行报告： 这是最后的文档，由测试主管在整个测试过程完成后准备的文件。

7.3需求跟踪矩阵

需求跟踪矩阵是一种在整个项目生命周期中跟踪需求状态的有效工具，它有助于确保所有原始需求都得到处理，并且所有低层需求都能追溯到一个有效的源头。它也被称为需求追踪矩阵（RTM）或交叉引用矩阵（CRM）。

需求跟踪矩阵类型

• 正向追踪，Forward traceability
  • 用于确保在应用程序中正确执行每个业务需求，并进行严格的测试。
• 反向追踪，Backward or reverse traceability
  • 反向追踪确保所有在产品开发过程中添加的代码、设计元素、测试和其他工作产品都能够追溯到相应的原始需求。
  • 它的主要目的是验证项目范围没有被无意中扩展，即确保所有工作产品都是为了实现已批准的需求。
• 双向追踪，Bi-directional traceability
  • 用于确保在测试用例中执行所有业务需求。它还评估由于应用程序中的错误而发生的需求修改。

优势

• 可以确认 100% 的测试覆盖率
• 显示以业务需求为重点的总体缺陷或执行状态

八、验收测试

8.1验收测试的定义

验收测试是软件或系统开发生命周期的最后阶段之一，目的是确保产品满足既定的业务需求和使用标准。

也称为交付测试

验收测试分为用户验收测试和操作验收测试。

验收测试应该是使用黑盒方法来验证高级的系统业务需求和操作需求。

验收测试的人员及职责：

一般在测试组的协助下由用户代表执行。验收测试由测试组组长监督，他负责保证在质量控下和监督下使用适当的测试技术执行充分的测试。

8.2常用策略

• 正式验收测试
• Alpha测试（非正式）
• Beta测试

正式验收测试

是系统测试的延续。

计划和设计的周密和详细程度不亚于系统测试 选择系统测试中所执行测试用例的子集

方式：

• 开发组织或其独立的测试组织与最终用户代表一起执行验收测试。
• 完全由最终用户组织执行，或选择人员组成客观公正的小组来执行。

必须在实际用户运行环境中进行

要给出测试报告，以文档的形式提供“验收测试报告”作为验收测试结果的书面说明

Alpha测试（非正式）

软件开发公司组织内部人员模拟各类用户行为，对即将面市的软件产品（α版本）进行的测试，试图发现错误并修正。

Beta测试

把产品有计划地分发到目标市场，从市场收集反馈信息，把反馈信息整理成易处理的数据表，再把这些数据分发给所涉及的各个部门。

测试时间及人员：测试通常在产品发布到市场之前，邀请公司的客户参与产品的测试工作。

文档评审是一个必需的步骤，但是这项工作却非常耗时，很少有公司愿意在文档评审上花费时间。测试参与者就是最有效地文档评审员。

九、黑盒测试-等价类

9.1 等价类划分法

 等价类划分法是把所有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

等价类的特点：完备性、无冗余性、等价性

9.2等价类的划分原则

• 有效等价类   ——对软件规格说明而言，是有意义的、合理的输入数据所组成的集合。检验程序是否实现了规格说明中预先规定的功能和性能。
• 无效等价类   ——是无意义的、不合理的输入数据所构成的集合。可以鉴别程序异常处理的情况，检查被测对象的功能和性能的实现是否有不符合规格说明要求的地方。

通常从三个方面考虑程序的输入： 正常输入 边界输入 非法输入

习题

10. (单选题)软件测试充分性理论是由(    )最先提出的

• A.Deutsch和Willis
• B.McCall et al
• C.Goodenough和Gerhart 
• D.Evansh和Marciniak

1. (单选题)软件测试中白盒法是通过分析程序的（   ）来设计测试用例的。

• A. 应用范围
• B. 内部逻辑
• C. 功能
• D. 输入数据

4. (单选题)黑盒法是根据程序的（    ）来设计测试用例的。

• A. 应用范围
• B. 内部结构
• C. 功能
• D. 输入数据

1. (单选题)将基于功能的和基于实现的测试方法结合在一起的动态测试类型，我们称这种测试为（　）。

• A. 白盒测试
• B. 灰盒测试
• C. 黑盒测试
• D. 基于故障的测试

6. (单选题)软件测试过程中的集成测试主要是为了发现（    ）阶段的错误。

• A. 需求分析
• B. 概要设计
• C. 详细设计
• D. 编码

4. (单选题)超出软件工程范围的测试是(     )

• A.单元测试
• B.集成测试
• C.确认测试
• D.系统测试

(   D )1、通常，(    )是在编码阶段进行的测试，它是整个测试工作的基础。

A、系统测试     B、确认测试 C、集成测试 D、单元测试