【期末复习】软件测试期末复习 参考教材：软件测试与质量保证 作者：Kshirasagar NaikPriyadarshi Tripathy

第一章

！！ 什么是软件质量：

​ 1.五个角度 抽象、用户、制造、产品、基于价值

​ 2.软件质量=质量因素+质量标准

软件测试的方法及方法

​ 两种划分方法：动态和静态 黑盒和白盒

验证和确认

​ 验证：正确的构建产品 确认：构建了正确的产品

测试目标

​ 不同的受众有不同的目标
​ 比如 程序员-->能工作 测试工程师-->不能工作 客户-->减少失败风险 项目经理-->减少测试成本

！！！测试用例的概念 会举例子

• 无状态系统：<输入，期望结果>的一对数据
  例如：计算非负平方根的程序的测试用例：<0,0>或者<25,5>
• 面向状态系统：<输入，期望结果>构成的序列
  例如：ATM取钱过程的测试用例：<检察余额，100w>+<按下取钱按钮，"amount?>+<输入20，20>

期望的结果

​ 程序执行的结果是一个复合体：程序产生的数值+状态变化+数值序列或集合

测试的核心问题

​ 以一种系统谨慎的方式选择输入域的子集

测试活动的步骤

​ 识别并确定测试目标-->选择输入-->计算期望结果-->设定程序执行环境-->执行程序观察结果-->分析结果：通过/失败-->撰写测试报告

v模型

​ 测试的四个阶段：单元测试-->集成测试-->系统测试-->验收测试
前三个阶段伴随着回归测试。

!!!测试用例的来源（5）

• 需求和功能规范
• 源代码
• 输入和输出域（尤其考虑特殊的）
• 操作特性
• 故障模型

黑白盒概念

​ 白盒-->结构（控制流 数据流） 黑盒-->功能（输入域 输出域）

单元测试（静态 动态 变异）

概念

​ 独立的测试程序单元 一个程序单元可以看成是实现低层次函数的一段代码

为什么要独立测试

​ 一个特定单元的错误更容易修复 通过直接访问单元的输入向量能更容易进行多路径测试 多单元同时测试很困难容易出问题

两个种类

​ 静态单元测试-->基于非执行的
​ 动态单元测试-->基于执行的

​ 两个都要被执行，先静后动

！！！静态 代码评审的基本步骤

​ 预备-->准备-->检查-->重做-->验证-->退出

！！！如何构建动态单元的测试环境（上下文）

• 单元测试的上下文：单元的调用者+其调用的所有单元
• 模拟环境必须简单 以便发现错误仅是单元自身的原因
• 测试驱动-->调用者单元 桩-->被测单元调用的单元 脚手架-->测试驱动+桩
• 被测单元：测试驱动：桩 = 1：1：n
  他们一起构成一个单元测试套件，三者紧密耦合

变异测试概念

• 程序的一次变异：对源程序代码一次单一、微小、符合语法的更改
• 被杀死：测试用例引起变异体失败
• 等价：变异体总是和原始程序输出相同
• 可杀死的/顽强的：有测试用例没有杀死一个变异体
• 变异分数：100*D/(N-E) 如果100%称变异充分

使用变异测试获取健壮测试套件的步骤

• 1.为程序P建议一组正确的测试用例集合T
• 2.在P上执行T的每一个用例，如果失败修改程序，知道程序不失败
• 3.生成一组变异体
• 4.在每个Pi执行T中的用例
  a.Pi被杀死
  b.Pi没有被杀死 可能Pi与P等价-->不用处理 可能Pi顽强-->添加心得测试用例
• 5.计算变异分数100*D/(N-E) D杀死的 N变异体总数 E等价变异体
• 6.如果T的变异分数不够高，重新设计新的用例添加到T中，回到第二步 知道分数超过某个阈值

控制流测试（控制流图 路径选择标准 生成测试输入）

其检查路径是否达到预期

例子：

注意圈圈 不带标号

路径选择标准：

​ 执行所有路径不可能

​ 1.全路径覆盖原则 简单可以
​ 2.语句覆盖原则(节点) •最弱的覆盖标准
​ 3.分支覆盖原则（线）
​ 4.谓词覆盖原则（条件组合覆盖） 所有可能的条件都被执行，并且影响选定的路径所有可能的真值条件的组合全都执行一次

一些概念(也基本就是流程)：

​ 输入向量：是所有读入例程的数据实体的集合，数据的值在进入例程前必须固定。
​ 谓词：决策点的逻辑函数 （就是if括号里的）
​ 路径谓词： 与一条路径相关的谓词集（包含谓词的真值）。三个杠：
​

​ 谓词解释：用符号替换一个路径上的操作的过程，以便只用输入向量和常量来表达谓词。 比如：
​

​ 路径谓词表达式：由输入向量及可能的常量向量构成的约束集。比如：
​

​ •从路径谓词表达式生成输入数据：
​

数据流测试（静态数据流测试【数据流异常】 动态单元测试【数据流图】 路径选择标准 一堆定义）

数据流异常

​ 三种：二次定义定义 定义未被引用 未定义被引用

程序变量状态

​ 未定义U 定义未被引用D 已定义已引用R 非正常A

三种动作

​ 定义d 引用r 取消定义u

画法：

术语

全局C-use：
如果在节点 i 之前定义变量 x，那么节点 i 中的变量 x 的c-use称为全局****c-use。
例：图5.4中节点9中的tv是一个全局c-use。

定义清纯路径（无定义路径）：
如果变量 x 在节点 n1...nm 中既不被定义，也没有被取消定义，则路径（i-n1-...-nm-j）（m≥0）称为对于变量 x 的“定义清纯路径”（****def-clear path）：从节点 i 到节点 j；或者从节点 i 到边（nm，j）。
例：图5.4中路径2-3-4-5、2-3-4-6和2-3-4-6-3-4-6-3-4-5均是tv的定义清纯路径

全局定义：
节点 i 是变量 x 的全局定义，当满足如下条件时：
节点 i 包含变量 x 的定义，从节点 i 到以下某处对于变量 x 有“定义清纯路径”。
包含一个全局c-use的节点；或者包含变量 x 的p-use的边。

简单路径：

​ 是除了第一个和最后一个节点没有要求以外，所有节点都是截然不同的节点。
​ 例：图5.4中，路径2-3-4-5和3-4-6-3均是简单路径

无循环路径：
路径上所有节点都是截然不同的节点。

完全路径：
起始于入口节点，并从出口节点退出的路径。

定义-使用路径（du-path):

​ 如果节点n1含有x的一个全局定义且满足以下任一条件，则路径（n1-n2-...-nj-nk）是相对于变量x的定义****-使用路径。条件如下：
​ 节点nk含有节点x的一个全局c-use，并且（n1-n2-...-nj-nk）相对于变量x是一条定义清纯简单路径。
​ 边（nj，nk）含有x的p-use，并且（n1-n2-...-nj）相对于变量x是一条定义清纯无循环路径。

​ 示例：考虑节点2和节点5分别含有变量tv的全局定义和c-use。因此2-3-4-5是一条相对于变量tv的定义-使用路径。
​ 示例：考虑节点2和边（7,9）分别含有变量tv的全局定义和p-use。因此2-3-7-9是一条相对于变量tv的定义-使用路径。

数据流测试标准

所有定义：

​ 对于每个变量x和有x的全局定义的节点i，选择包含一条定义清纯完全路径，从节点i到(1)含有x的全局c-use的节点j或者到(2)含有x的p-use的边（j，k）。

​ 示例：对于变量tv，符合all-defs标准的路径就有(1-2-3-4-5-6-3-7-9-10)、(1-2-3-7-8-10)、(1-2-3-4-5-6-3-7-9-10)。（为了满足all-defs标准，关于变量i，ti，sum****的相似路径也要找到）

所有计算使用：

​ 对于每个变量x和每个节点i，如果x在节点i有全局变量定义，选择从节点i到所有节点j包含一条定义清纯路径的完全路径，使得在节点j有变量x的全局c-use。

​ 示例：对于变量ti，符合all-c-uses标准的路径就有(1-2-3-4-5-6-3-7-8-10)、(1-2-3-4-5-6-3-7-9-10)、(1-2-3-4-6-3-7-8-10)、(1-2-3-4-6-3-7-9-10)。

所有谓词使用（all-p-uses）：

​ 对于每个变量x和每个节点i，如果x在节点i有全局变量定义，选择从节点i到所有边（j，k）包含一条定义清纯路径的完全路径，使得在边（j，k）有变量x的p-use。

​ 示例：对于变量tv，符合all-p-uses标准的路径就有(1-2-3-7-8-10)、(1-2-3-7-9-10)、(1-2-3-4-5-6-3-7-8-10)、(1-2-3-4-5-6-3-7-9-10)。

所有谓词使用/部分计算使用（all-p-uses/some-c-uses）：

​ 如果变量x无p-use，则等同于部分计算使用（some-c-uses）：对于每个变量x和每个节点i，如果x在节点i有全局变量定义，选择从节点i到某些节点j包含一条定义清纯路径的完全路径，使得在节点j有变量x的全局c-use。

​ 示例：对于变量i，符合all-p-uses/some-c-uses标准的路径就有(1-2-3-4-5-6-3-7-9-10)

所有计算使用/部分谓词使用（all-c-uses/some-p-uses）:

​ 如变量无全局c-use，则等同于部分谓词使用（some-p-uses）：对于每个变量x和每个节点i，如果x在节点i有全局变量定义，选择从节点i到某些边（j，k）包含一条定义清纯路径的完全路径，使得在边（j，k）有变量x的p-use。

​ 示例：对于变量AS，符合标准的路径就有(1-2-3-4-5-6-3-7-9-10)

所有使用（all-uses）:

​ =所有计算使用（all-c-uses）+所有谓词使用（all-p-uses）

所有定义-使用路径（all-du-path）:

•对于每个变量x和每个节点i，如果x在节点i有全局变量定义，选择包含all-du-path的完全路径，从节点i出发(1)到所有节点j，使得节点j有变量x的全局c-use；或者(2)到所有边（j，k），使得边（j，k）有变量x的p-use。

域测试（on off）

域错误

​ 计算错误：路径正确但赋值语句错误

​ 域错误：输入了一个数据后，执行的路径是错的。一般是谓词错误。

！！！输入分类器

​ 程序中的一个概念上的内置机制来决定选择一条具体路径所需要的计算方法。
​ 实际上指的是程序中的有序谓词集合。

域错误测试

​ 基于流图的测试是无目标的测试 域测试是有目标的测试

三个方面讨论域测试

​ 域的源 域错误类型 选择测试数据来发现域错误

从程序源代码识别域的方法

​ 画程序控制流图 找出谓词所有可能的解释 分析被解释的谓词从而识别域

！！！域错误的类型（重要）

​ 一个域可以定义成一组边界不等式的约束集

​ 封闭边界： 有等号 开放边界 ：无等号
​ 封闭域： 所有边界都封闭 开放域： 有一个开放边界就是开放域
​ 极点： 边界的交点
​ 邻域： 两个域有一个相同的边界不等式

​ 封闭错误： 对于等号的运算包含错误
​ 边界移动错误： 边界不等式的常量错误
​ 边界倾斜错误： 边界的判定中变量的系数取错误的值

！！！ON点OFF点

​ 最敏感的数据点 落在边界或是靠近边界的数据点

​ ON点：边界上的点或者非常靠近边界上的点 只要是封闭域一定选择内部点 开放域选择外部点

​ OFF点：远离边界的点 开放的选内部点 封闭的选外部点

！！！测试选择标准

​ ON-OFF-ON

系统集成测试（接口的不同类型和接口错误 系统集成技术）

测试过程：

​ 单元测试-->集成测试-->系统测试-->构建可交付系统

​ 集成测试与接口相关

！！接口类型：

​ 过程调用接口
​ 共享内存接口
​ 消息传递接口

接口错误：

​ 是一些和结构相关的错误，这些结构位于模块的局部环境之外但为该模块所用。

​ 类型：

​ 构造 功能缺乏 功能位置 功能改变 功能增加 接口误用 接口误解 数据结构变更 不充分的错误处理 错误处理的附加项 不充分的后处理 不充分的接口支持 初始化/值错误 违反数据约束 时效性/性能问题 变更协同 硬件/软件接口

目标 开始时间

​ 集成测试的目标：在实验室环境中组装出一个相对稳定的系统，使其能够承受现实环境中严格、全方位的系统测试。

​ 集成测试从什么时候开始？一旦相关模块可用（通过单元测试），就可以开始集成测试。

！！！常用的集成测试方法

​ 增量法（基本方法） ：循环迭代的方法：从一个核心模块开始构建，然后进入循环的过程。每一个测试周期需要修复所有已知的错误，然后加入更多模块和已有测试构件（独立完备且稳定）进行下一个周期的测试，如此循环进行下去直到整个系统成为可操作的，能进行系统级测试为止。

​ 增量法集成测试的结果是形成一个过渡的软件镜像供系统测试使用。

​ 自顶向下（不断地替代桩） 自底向上（不断地替代测试驱动） 三明治 大爆炸（适合小系统）

​ 自顶向下方式和大爆炸方式（应用难度和成本高）最可靠，自底向上效率最差，三明治方式拥有中等可靠性。

系统测试分类

十二类

​ 基础测试
​ 压力测试
​ 功能性测试
​ 负载和稳定性测试
​ 健壮性测试
​ 可靠性测试
​ 互操作性测试
​ 回归测试
​ 性能测试
​ 文档测试
​ 可扩展性测试
​ 规章测试

功能测试（等价类划分 边界值分析 判定表） 大题

系统测试设计

做好计划

！！！图 需求识别模型的状态转移图

需求数据库系统 追溯矩阵

​ 客户可以从需求数据库系统产生一个追溯矩阵，追溯矩阵可以允许我们发现在需求和测试用例之间的二路双向映射：
​ · 从需求到一个功能规范到执行他们的特定的测试用例
​ · 从每个测试用例返回到需求和功能规范

​ 追溯矩阵的作用：
​ · 识别和追溯测试的功能覆盖
​ · 当一个系统改进时识别哪一个测试用例必须执行或更新

识别测试目标的步骤

​ 1.阅读理解、分析功能规范
​ 2.推断需求（期望系统能支持但没有被明确定义的需求）
​ 3.形成测试组，最终形成测试套件

！！！图 测试用例生命周期的状态转移图

！！！图 测试用例结果状态转移图

系统测试的执行

缺陷建模

​ 模型的十二种状态：
​ N新建 A已分配 O打开 R已解决 C关闭 W等待 F功能设计 H阻塞 S被搁置 D重复 I无法实现 P延期

缺陷建模中涉及到的两个概念 优先级和严重性

​ 优先级：用于缺陷修复时间的度量 分为 关键 高 中 低

​ 严重性等级：度量缺陷对于影响产品运行的危害程度 也是分为 关键 高 中 低

图 缺陷生命周期的状态转移图

跟踪系统测试的度量指标（两个角度 三个内容）

​ 两个角度：

​ 监督测试执行的指标：关注执行测试用例的过程
​ 监督缺陷的指标：关注作为测试执行结果所发现的缺陷以确定产品的质量等级。
​ 这些度量指标需要进行周期性的跟踪和分析

​ ！！！监测测试用例执行的三个指标：

​ 测试用例逃逸：在测试过程中需要设计新的测试用例。这东西快速增长说明在测试设计阶段准备不充分
​ 计划执行率对实际执行率：每周实际执行的测试用例数和计划执行的测试用例数进行比较，体现测试用例执行的生产率
​ 测试用例的执行状态：检测不同执行状态的测试用例（失败、通过、阻塞、无效、未测试）

​ ！！！检测缺陷报告的八个指标：

​ 处于FAD（功能设计）状态的缺陷的数量：越低表示测试工程师对系统给的理解程度越高
​ 无法重现的缺陷数量：不可靠性的度量
​ 缺陷到达率DAR的计数：不同功能组的缺陷百分比
​ 缺陷拒绝率DRR的计数：对原本要修复但没有被真正修复的缺陷的计数。代表开发组修复缺陷的生产率和成功修复缺陷的程度。
​ 缺陷关闭率DCR的计数：验证缺陷修复生命的有效性
​ 显著缺陷OD的数量：如果一个缺陷持续存在，则称OD。这个指标体现了系统的质量水平
​ 造成崩溃的缺陷CD的数量：系统稳定性度量指标
​ 缺陷的到达和消除ARD的计数：对缺陷消除的成本进行度量，以估算修复所有缺陷用的时间。

验收测试

类型（两种）：

​ 用户验收测试：由客户组织进行 一般来源于合同 可以由第三方完成
​ 业务验收测试：开发组织内部进行 一般是对用户验收测试的演习

验收标准：（20条 了解）

软件可靠性

什么时软件可靠性：

​ 定义一:指一个软件系统在一个特定的环境和特定的时间段中无故障运转的概率。
​ 定义二:故障密度是在给定环境里运行的软件系统可靠性的一个度量。

​ 两个定义的比较:
​ ·第一个强调系统无故障运行的重要性
​ ·第二个强调系统尽可能少的故障

故障密度：

​ 计算到目前为所观察到的故障的总数，并将数据描绘成一个时间函数，可以观察到系统可靠性的变化。