软件测试期末整理

软件

软件是计算机程序、程序所用的数据以及有关文档资料的集合。
软件 = 程序 + 数据 + 文档 + 服务
（软件分为系统软件、应用软件和介于这两者之间的中间件）

• 程序：完成预定功能和性能的指令的集合。
• 数据：依照某种数据模型组织起来并存在在二级存储器中的数据集合。
• 文档：软件在开发、使用和维护过程中产生的文字与图像的集合。
• 服务：通过提供必要的手段和方法，满足接受服务的对象需求的过程。

软件测试

定义：使用人工和自动手段来运行或测试某个系统的过程，目的在于检测被测软件系统是否满足规定的需要，或是弄清楚预期结果与实际结果之间的差别。

• 确保软件产品满足用户需求；
• 衡量软件产品是否符合预期；
• 软件测试以需求为中心，开发过程需要：定义需求、分析需求、实现需求和校验需求；
• 只要拿到需求规格说明，逐项检验，看看被测系统是否符合需求规格说明就可以了。

软件测试的手段

测试执行的方式：【手动、自动化】

人工测试：人工执行测试。根据测试用例中描述的规程，不借助特殊的软件工具、人工来运行被测系统，观察系统实际输出是否符合测试用例的预期输出。
自动化测试：将以人为驱动的测试行为转化为机器执行的过程。目的是节省人力、时间或硬件资源，并提高测试效率。

测试的策略：【动态、静态】

根据被测对象是否执行：动态测试和静态测试

• 动态测试：使用和执行被测系统。主要是对测试用例的执行来完成对系统的测试。动态测试的对象必须是能够由计算机真正运行的被测试的程序。【黑盒+白盒】
• 静态测试：通过对被测对象的静态审查，发现代码中潜在的错误。通过手工检查或借助静态分析器在机器上以自动化方式进行检查，但不要求程序本身在机器上运行。
• 涉及的工作：9-6
  1. 提供被测对象
  2. 准备相关预期
  3. 搭建测试环境
  4. 设计测试用例
  5. 运行测试用例
  6. 检查测试结果
  7. 记录测试过程
  8. 报告发现的缺陷
  9. 执行回归测试(重新)

基本原则

非穷尽、早期、聚集、追溯用户需求

测试流程

计划、设计、实施、评估

测试用例

测试用例是一组测试输入、执行条件和预期结果，目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求。

测试用例的组成

• 输入：测试数据和操作步骤【包括正常数据、错误数据、边界数据】
• 输出：系统预期执行结果
• 测试环境

测试用例的基本属性

1. 典型性
2. 可测试性
3. 可重现性
4. 独立性

软件质量

• 一般指软件满足：客户明确的需求、用户的期望、软件运行要求的程度

• 软件产品满足明确和隐含需求的能力有关的特征和特征总和

软件质量的特征

1. 功能性
2. 可靠性
3. 可用性
4. 效率
5. 可维护性
6. 可移植性

软件质量 VS 软件测试

软件测试是软件质量保证的关键步骤，但提高软件质量的途径是改进软件开发过程的质量，而非提高软件测试。

软件测试不能提高软件的质量

软件测试的分类

• 测试技术/方法【软件内部结构或用户需求】：黑盒、白盒、灰盒
• 执行方式：手工、自动化
• 测试的策略/手段【被测软件是否被执行】：动态、静态
• 目标：很多
• 阶段/进程：单元(编码)、集成(详细设计)、系统(概要设计)、验收(需求分析)

黑盒

不考虑被测对象的内部结构或运行逻辑，只通过被测对象的输入和预期输出展开测试。

白盒

基于软件的源代码，已知被测对象的内部工作过程，主要是对程序内部结构展开测试，关注程序实现的细节。

生命周期

软件产生直到报废或停止使用的生命周期

瀑布模型(软件开发模型)

可行性分析与开发项目计划、编码、测试、维护

V模型

• 测试阶段和开发过程期间各阶段的对应关系
• 把测试作为编码后一个阶段。

W模型

• 测试伴随整个开发周期

控制流分析

• 判定节点固有的复杂度：逻辑覆盖测试
• 判定结构与循环结构对执行路径的影响：独立路径测试
• 循环结构本身的复杂性：基于数据的静态分析

逻辑覆盖

• 通过对程序逻辑结构的遍历，来实现程序的覆盖

语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖

语句覆盖

• 可执行语句至少执行一次(带分号的语句)
• 最弱的覆盖标准

判定覆盖

• 对判定节点，真假执行一次
• 判定覆盖100%则语句覆盖100%
• 仅关注整体，没有关系细节

条件覆盖

• 子表达式真假一次
• 条件覆盖100%不等于判定100%
• 关注细节忘记整体

判定条件覆盖

• 判定节点和子条件真假至少执行一次

条件组合

• 条件全组合
• 冗余太多，覆盖完

独立路径测试

• 在程序的控制流程及执行路径的基础上，分析控制流程的环路复杂性，导出独立可执行路径的集合，从而设计测试用例。

• 数据声明语句忽略，赋值语句可以有A，串行语句

环复杂度

• 直接观察：封闭
• 公式：边数-点数+2
• 判定节点+1

方法：

1. 根据源程序导出控制流图，生成路径地图
2. 确定规模（环复杂度）
3. 主路径（更多判定节点、更多判定表达式、执行概率、语句），并以此为基础构建其他独立路径
4. 剔除不可达：改（补）其他路径
5. 根据得到的路径集合设计测试用例

静态测试

• 静态测试存在软件整个生命周期
• 检查与分析：找bug
• 早期进入

代码检查 - 代码走读 - 代码质量度量

代码检查

• 主要通过同行评审来发现缺陷；

• 以评审会议的方式进行，通过多人对**软件交付物（源代码、设计规格书）**进行检查，目的是发现和修复软件开发初期未发现的缺陷，获得改进优化的机会。

• 静态测试的主要活动：检查软件工作产品

• 目标（结果）：优化开发过程，并且达到缺陷预防的目的

同行评审

• 由软件工作产品生产者的同行遵循已定义的规程对产品进行的技术评审。
• 同行评审的核心：缺陷预防
• 目的：发现缺陷，改进开发过程
• 对象：所有软件开发的中间和最终工作产品

1. 计划评审会议
2. 召开评审预备会议
3. 准备评审会议
4. 召开评审会议
5. 召开第三小时会议：TBD
6. 修复缺陷
7. 确认修复

代码走查

开发人员与系统架构师集中讨论代码的过程。以发现书面文档中缺陷、含糊表达和问题为目的的非正式评审。

• 代码检查、走查比动态测试更有效率，能快速找到缺陷
• 看到的是问题的本身而非征兆
• 应在编译和动态测试之前进行

函数调用关系图：

1. 函数调用层次：树深度；
2. 函数调用关系；
3. 查看是否存在递归调用；
4. 查看是否存在孤立节点

单入口和单出口有好处 16 20211026 回收

函数控制流图

1. 是否存在孤立节点
2. 出口节点（单入口、单出口）
3. 环复杂度
4. 是否存在非结构化的设计

黑盒测试

黑盒测试又称功能测试、数据驱动的测试或基于规格说明书的功能测试

从输入域到输出域的映射

测试方法的评价标准

1. 精准的：测试针对性强
2. 完备的：测试覆盖全面，无漏洞
3. 无冗余：测试用例所关联的风险有所区别
4. 简单的：测试方法简单易行
5. 易于调试：缺陷定位难度小

等价类

• 等价类划分法：把程序所有可能的输入数据划成若干份，从每部分选取少数代表性数据作为测试用例。
• 有效等价类：对程序的规格说明来说是合理的，有意义的输入数据构成的集合；功能性能
• 无效等价类：不合理，无意义；容错性
• 等价类测试的陷阱

等价类测试的基本原则

1. 分而不交 - 测试无冗余
2. 合而不变 - 测试无漏洞
3. 类内等价 - 以一代全

常见的等价类划分方法

1. 连续有效范围：[80,90]——一个有效等价类和两个无效等价类
2. 特定取值：a开头(不以a开头)——一个有效一个无效
3. 布尔值：1/1或者2/0
4. 一组值：n个有效；1个无效
5. n个无效，1个有效
6. 更小的等价类

等价类测试的流程

1. 确定有几个输入条件——改变原始输入域
2. 划分每个输入条件的等价类——强覆盖+单缺陷
3. 选择合适的覆盖标准
4. 设计测试用例

边界

• 边界值测试：是对输入输出变量范围的边界值上进行测试的一种黑盒测试方法。

• 结合等价类，来自等价类边界

• 离点

• 边界点：可能导致被测系统内部处理机制发生变化的点

• 每一个输入的边界并不一定都可以唯一对应到一个输出的边界。输入输出都测试

• 基本：4n+1

• 健壮：6n+1（三点法）

组织测试数据改进

1. 穷尽

2. 多边界【四个角】—— 数量和冗余改进，缺陷定位困难

3. 穷尽有效域 —— 都不行

4. 单边界 —— 易定位，冗余规模大

   

选择测试用例的原则

1. 如果输入条件规定了值的范围：2刚
2. 规定了值的个数：min、min-1、max、max+1、
3. 有序集合：第一个和最后一个
4. 闭外开内原则
5. 特殊的边界值
6. 内部数据结构
7. 规格说明

场景法

• 基本流：基本事件流，它从系统的某个初始态开始，经一系列状态后，到达终止状态的一个业务流程。【业务输入正确，能达到目标的流程】**【only one】**业务流程输入正确，能达到目标的流程。
• 场景法：适用于业务逻辑强、业务流程多【业务流程 VS 单功能(边界等价)】
• 确认基本流时，往往考虑将容易出错的，或者出错后导致损失严重的高风险事件流作为基本流。
• 备选流：是备选事件流，它是以基本流为基础，在基本流经过的每个判定节点处满足不同的触发条件而导致的其他事件流。
• 备选流的起始节点和终止节点
• 场景：基本流和备选流的有序结合

步骤

1. 理解软件的业务需求，分析用户的使用场景和使用习惯，确定业务流程；【定义基本流和备选流】
2. 根据业务流程绘制流程图，获取测试场景。【场景事件图】要求每一条必须包含一个未走过的路。
3. 将测试场景中的各种输入条件和场景对应起来，形成场景条件表。
4. 细化测试场景，利用等价类边界值等方法，确认具体的测试数据值，形成测试用例。

场景爆炸问题

1. 基于独立路径：场景独立，无漏洞——不可达
2. 基于事件流个数：易于缺陷定位——不可达，不保证独立和完备
3. 需求构建：场景可行——不保证独立和完备

• 事件流相互独立：独立路径
• 存在关联：独立+需求

缺陷管理

• 缺陷管理是在软件的生命周期中识别和管理缺陷的过程，确保缺陷被跟踪管理而不丢失
• 一般的，需要跟踪管理工具来帮助进行缺陷的全流程管理
• 属性：可重现性、严重性、优先级、可修复性【前三需要在报告中明确体现，可修复性不用】
• 无法重现的bug是无法修复的
• 只要发现程序执行中出错，意味着程序中一定有缺陷

5级严重性

生命周期

缺陷的生命周期：一个缺陷被发现到这个缺陷被关闭

过程：

1. 测试人员找到软件缺陷并将缺陷提交给开发人员；
2. 开发人员再现、修复缺陷，然后交给测试人员验证；
3. 测试人员执行回归测试，验证缺陷未正确修复。重新打开缺陷；
4. 测试人员执行回归测试，验证缺陷正确修复，关闭缺陷。