【软件质量保障笔记】软件质量保障

Introduction

1. what is testing

   1. software testing is a set of processes aimed at investigating, evaluating and ascertaining the completeness and quality of computer software. Software testing ensures the compliance of a software product in relation with regulatory, business, technical, functional and requirements
   2. test process:

2. Basic problems of testing

   1. Adequancy of test suite
   2. Oracle:
      1. expert knowledge
      2. metamorphic relation

Classic Testing

V model

单元测试

1. 概念
   1. 侧重软件的最小可测试元素
   2. 应用于实现模型中的模块
   3. 主要是功能正确前提下的控制流和数据流的覆盖测试
   4. 主要针对单元的内部结构
   5. 更注重白盒测试
2. 测试内容
   1. 算法和逻辑 无法直接测试
   2. 单元接口
   3. 数据结构
   4. 边界条件
   5. 独立执行
   6. 错误处理

集成测试

1. 原因
   1. 一个模块可能对另一个模块产生不利影响
   2. 将子功能合成时不一定产生所期望功能
   3. 独立可接受误差，在集成后不一定可接受
   4. 可能会发现单元测试中未发现的接口方面的错误
   5. 发现单元测试中无法发现的时序问题
   6. 发现单元测试中无法发现的资源竞争问题
2. 概念
   1. 前提是集成的单元能够正确执行用例
   2. 测试对象是实现模型中的一个或一组包
   3. 集成的包通常来自于不同的开发组织
   4. 继承测试将揭示包接口规约中不完全或错误的地方
3. 测试方法
   1. 非增式测试：一步到位构造测试
   2. 增式测试：将要测试的模块同已测试好的模块组合起来进行测试，一次增加一个人测试模块
4. 增式集成
   1. 自顶向下的结合：
      1. 集成步骤
         1. 主控模块作为测试驱动，所有与主空间模块直接相连的模块作为桩模块
         2. 根据集成的方式深度或广度，每次用一个替换从属的桩模块
         3. 在每个模块被集成时，都必需完成单元测试
         4. 进行回归测试以确定集成新模块后没有引入错误
   2. 自底向上的结合
      1. 集成步骤
         1. 从最低层的模块开始，组合成一个构建，用以完成指定的软件子功能
         2. 编制驱动程序，协调测试用例的输入和输出
         3. 测试集成后的构件
         4. 按程序结构向上组装测试后的构件，同时除掉驱动程序
   3. 比较：

系统测试

1. 概念
   1. 前提：所有集成测试完成
   2. 软件系统之间的联合测试
   3. 软件、硬件等之间的联合测试
   4. 模拟真实运行环境的测试

验收测试

1. 用户在场或者直接测试
2. 用户可能自定义测试用例

$\alpha$测试和$\beta$测试

1. $\alpha$测试：在开发即将完成时，对应用进行测试，此时仍然允许对设计做微小的变动
2. $\beta$测试：在开发基本完成时运行，用于正式发布之前寻找程序中的错误

测试流程

测试目标

• 单元测试：
  • 目标
    • 检验程序最小单元有无错误：接口、数据结构、边界、覆盖、逻辑
    • 检验单元编码与设计是否吻合
• 集成测试
  • 目标：
    • 代码组组成系统的模块接口有无错误
    • 代码实现的系统设计与需求定义是否符合
• 系统测试
  • 目标
    • 检验组成整个系统的代码、以及系统的软硬件配合是否有误
    • 代码实现的系统与用户需求是否吻合
    • 检验系统的各种文档是否完整有效
    • 模拟验收测试的要求，检查系统是否符合用户的验收标准
• 验收测试
  • 目标
    • 使客户是否验收签字
    • 系统是否符合事先约定的验收标准
• 回归测试
  • 目标
    • 验证程序修改或版本更新有，以前正确的功能和其他的指标仍旧正确

测试范围

• 接口测试
  • 那些子系统的接口需要测试
• 性能测试，负载测试等
  • 那些功能需要做性能测试

测试项目

• 数据和数据库集成测试
• 功能测试
• GUI测试
• 性能测试
• 安全测试
• 压力测试
• 负载测试
• 容量测试
• 失效/恢复测试
• 安装测试
• 配置测试

测试策略

• Code coverage stragegies
  • Decision coverage
  • data flow testing (define -> use)
• Specification based testing
  • Equivalence partitioning
  • Boundary value analysis
  • Combinaiton strategies
• State based testing

测试工具

• 测试管理
• 测试设计
• 缺陷跟踪
• 数据库工具
• 性能测试工具
• 其他工具

测试资源

• 角色：经理、设计人、测试人等
• 系统资源：硬件、软件

产出

• 测试计划
• 测试环境
• 测试包
• 测试日志
• 缺陷报告

设计

• 确认和详细描述测试用例
• 确认和设计测试成本
• 评测测试覆盖

测试用例的设计

测试脚本设计

• 测试脚本：一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行
• 测试脚本可以被创建，或使用测试自动化工具自动生成，或用编程语言来完成，也可以综合前三种方法来完成
• 测试脚本语言

测试覆盖准则设计

• 覆盖率
• 控制流覆盖率
• 数据流覆盖率
• 分支覆盖率
• 路径覆盖率

开发

• 建立测试环境
• 录制或编写测试脚本
• 开发测试驱动器和桩模块
• 建立外部数据集

执行

• 执行测试脚本
• 测试执行情况分析
• 结果验证
• 研究未预期的结果
• 写日志
• Bug报告、追踪

评估

• 分析测试用例覆盖
• 分析代码覆盖
• 分析缺陷
• 分析是否达到测试停止、成功的标准
• 写测试分析报告

测试方法分类

按照执行情况分类

• 静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性
  • 方法：
    • 走查：开发组内部进行的，采用讲解、讨论和模拟运行的开发方式进行的查找错误的活动
    • 审查：开发组内部进行的，采用讲解、提问并使用CheckList方式进行的查找错误的活动。一般有正式的计划、流程和结果报告
    • 评审：开发组、测试组和相关人员联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告
    • 审计
• 动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标
• 异同点
  • 被测部分不同：静态测试是指测试不运行的部分，只是检查和审阅，如规范测试、软件模型测试、文档测试；而动态测试是通常意义上的测试，也就是运行和使用软件
  • 测试方法不同：静态测试通过文档评审、代码阅读等方式测试软件；动态测试通过运行程序测试软件

按照是否关心内部结构分类

从是否关心内部结构来看：

• 白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法
  • 特点：要求对某些程序的结构特性做到一定程度的覆盖
    • 语句覆盖：要求被测程序的每一个可执行语句在测试中尽可能地都检验过，是最弱的逻辑覆盖准则
    • 分支或判定覆盖：要求程序中所有判定的分支尽可能得到检验
    • 判定/条件覆盖：同时考虑条件的组合值以及判定结果的检验
    • 路径覆盖：只考虑对程序路径的全面检验
• 黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅根据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试
• 灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术

按照开发过程分类

• 单元测试：又称模块测试，是针对软件设计的最小单位——程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求
• 集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件
• 系统测试：是为判断系统是否符合要求而对继承的软硬件进行的测试活动，它是将已经继承好的软件系统作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试
• 验收测试：检查交付的软件是否满足用户的需求

从执行过程是否需要人工干预来看

• 手工测试：测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输入执行，包括与被测软件进行交互，然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有异常发生，属于比较原始但是必须执行的一个步骤
• 自动化测试：将大量的重复性的测试工作交给计算机完成，通常是使用自动化测试工具来模拟手动测试步骤，执行某种程序设计语言编写的过程

从测试实施组织看

• 开发者测试：开发人员进行测试
• 用户测试：用户方进行测试
• 第三方测试：专业的第三方承担测试

从所处的环境看

• $\alpha$测试：一个用户在开发环境下进行的测试，也可以是公司内部的哟农户在模拟实际操作下进行的测试
• $\beta$测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用$\beta$版本，并要求用户报告

模拟用户操作测试

• 基于对用户如何使用被测试软件的了解来进行测试的方法
• 经验告诉我们：复杂的软件产品有许多错误，但用户一般只能找出这些错误中很少的一部分
• 为给用户带来最大利益，要着重对那些用户可能发现的错误进行测试和修改工作

软件测试用例设计

黑盒测试用例设计

基本概念

• 定义
  • 一种基于规格说明，不要求考察代码，以用户视角进行的测试
• 意义
  • 有助于软件产品的总体功能验证
  • 检查明确需求和隐含需求
  • 采用有效输入和无效输入
  • 包含用户视角
• 实施者
  • 软件测试部门，有经验的测试人员
• 步骤
  • 熟悉规格说明书，理解测试需求
  • 生成测试用例
  • 执行测试
  • 判定测试结果

特点

• 一种基于需求的测试
• 目的
  • 确认软件需求规格说明书列出的需求是否都正确实现
• 前提
  • 软件需求规格说明书已经过仔细评审
  • 隐含需求已经明确化
• 优点
  • 黑盒测试与软件具体实现无关，所以如果软件实现发生了变化，测试用例仍然可以使用
  • 设计黑盒测试用例可以和软件实现同时进行，因此可以压缩项目总的开发时间

黑盒测试的实施

• 正面测试
  • 通过正面测试用例产生一组预期输出验证产品需求
  • 目的：证明软件对于每条规格说明和期望都能通过
• 负面测试：
  • 展示输入为非预期输入时，产品没有失败
  • 目的：产品没有设计、没有预想到的场景，尝试使系统垮掉
    

黑盒测试用例生成方法

等价类划分

• 定义：等价类是
  • 测试相同目标或暴露相同软件缺陷的一组测试
  • 等价类是指输入域的某个自己，该子集中的每个输入数据对介入软件中的错误都是等效的，
• 原理
  • 将程序的输入域划分为等价类，以便导出测试用例
  • 它视图通过设计一个测试用例来尽可能发现多个错误，从而减少测试用例数目，降低测试工作量
• 等价类划分
  • 如果软件行为对一组值来说是相同的，则称这组值为等价类
  • 产生相同预期输出的一组输出值叫一个划分
• 有效等价类和无效等价类
  • 有效等价类：完全满足产品规格说明的输入数据，即有效的、有意义的输入数据构成的集合
  • 无效等价类：不满足程序输入要求或者无效的输入数据构成的集合
• 等价划分准则
  • 输入条件是布尔表达，则可以定义一真一假的有效等价类和无效等价类
  • 输入条件为一个范围，则可以定义一个有效等价类和两个无效等价类
  • 输入数据个数有规定，则可以定义一个有效等价类和两个无效等价类
  • 输入条件代表集合的某个自己，则可以定义一个有效等价类和一个或多个无效等价类
  • 输入条件代表一组列表形式的数据，则可以定义N个有效等价类和无效等价类
  • 输入条件代表符合某几个规则，则可以定义多个有效等价类和若干个无效等价类
    

因果图

基础

• 原理

  • 软件的输入和输出之间存在因果逻辑关系，可以用因果图刻画
  • 因果图可以从规格说明书中获得

• 过程

因果图表示

• **$C_i$表示原因，$E_i$**表示结果

  • 恒等：

  • 非：

  • 或：

  • 与：

因果图输入

• 互斥(E)：多个原因不能同时成立，最多有一个能成立 即Ci不能同时为1：

• 包含(I):多个原因中至少有一个必须成立 即Ci不能同时为0:

• 唯一(O):多个原因中必须有一个且只有一个成立 Ci只有一个为1：

• 要求®:当C1成立，C2也必须成立:

输出约束

• 屏蔽(M):当E1是1时，E2必须是0，当E1是0，E2的值不定：

决策表

• 组成
  • 条件桩：列出所有可能问题
  • 条件项：列出条件所有可能取值
  • 动作桩：列出可能采取的操作
  • 动作项：指出在条件项的各种取值情况下应采取的动作
• 决策表化简

边界值分析

什么是边界

• 略

什么是边界值分析法

• 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是对等价划分发的补充，这种情况下，其测试用例来自于等价类边界

为什么需要进行边界值分析

• 软件的主要缺陷源：条件、边界
  • 条件：变量取值需要满足各种约束
  • 边界：变量的各种极限取值
• 边界值分析
  • 能够有效补货出现在边界处缺陷的一种测试方法，利用并扩展了缺陷更容易出现在边界处的理念
• 缺陷容易出现在边界的原因
  • 使用比较操作符未仔细分析
  • 等等等等

如何使用边界值设计测试用例

• 使用边界值分析方法设计测试用例吗
  1. 确定边界情况，通常是输入和输出的等价类的边界
  2. 应当选取正好等于、恰好大于、恰好小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据

测试用例确认方法

• Paul Jorgensen公式
  • $n$：存在边界值的参数个数
  • $m$：边界值条件数
  • $4n+1$：基本边界测试
    • Min, min+1, max, max-1 nom 其他参数典型值
  • $6n+1$：健壮性边界测试
    • min,min+1,min-1,max,max+1,max-1,nom
  • $3m$：边界条件测试
    • 条件本身、条件$\pm 1$

总结

• 边界值需要彻底测试
• 考虑资源极限，如有限缓存
• 需求规格中对硬件资源的限制
• 输出值和边界也需要考虑

白盒测试及测试用例分析

基本概念

• 特点

  • 基于代码
  • 尽可能覆盖实现的行为

• 原因

  • 确保每段代码都被执行，避免对应的缺陷
  • 某些白盒测试技术可以实现自动化测试
  • 是黑盒测试/功能测试的补充
  • 能够覆盖高层规范说明中忽视的底层细节

• 定义

  • 一种基于源程序或代码的测试方法
  • 根据源程序或代码结构与逻辑，生成测试用例以尽可能地多发现并修改源程序错误
  • 白盒测试分为静态和动态两种类型

• 实施者

  • 单元测试阶段：开发人员
  • 集成测试阶段：测试人员和开发人员

• 步骤

  • 程序图
  • 生成测试用例
  • 执行测试
  • 分析覆盖标准
  • 判定测试结果

• 进入和退出条件

  • 进入条件：
    • 编码开始阶段
  • 退出条件：
    • 完成测试计划
    • 发现并修正了错误
    • 预算和开发时间

静态白盒测试

1. 定义：在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有事也成为了结构化分析
2. 理由
   1. 尽早发现软件缺陷
   2. 为后继测试中设计测试用例提供思路
3. 优点
   1. 可能发现某些机器发现不了的错误
   2. 利用不同人对代码的不同观点
   3. 对照设计，确保程序能完成预期功能
   4. 不但能检测出错误，还可以尝试确定错误的根源
   5. 以增加人工成本为代价，节约计算机资源
   6. 尽早发现缺陷，避免后期缺陷修复造成的巨大压力

动态白盒测试

基本概念

1. 不但要提供软件源代码，还要提供可执行程序，测试过程需要在计算机上执行程序

2. 测试流程：

3. 覆盖准则：

   1. 意义：定义“测试执行到何时才算充分”
   2. 作用：软件测试的一种度量标准，描述程序源代码被测试的程度
   3. 一种测试技术通常有一种对应的覆盖准则

测试方法

1. 基于控制流的方法
   1. 语句覆盖测试：
      1. 语句覆盖：保证程序中的每条语句都执行一遍
   2. 条件测试：
      1. 判定覆盖：表征判断取True False都执行一遍
      2. 条件覆盖：保证每个条件取值都执行一遍
   3. 路径测试：
      1. 路径覆盖：覆盖程序中所有的可能路径
2. 基于数据流的方法
   1. 数据流测试

基于控制流的方法

语句覆盖

==思想：==语句覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每条可执行语句都至少执行一次

判定覆盖

==思想：==判定覆盖，是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定的所有可能结果都至少执行一次

1. 保证每个判断至少获得一次True和False
2. 优点：简单，包含语句覆盖，并避免了语句覆盖的问题
3. 缺点：忽略了表达式内的条件，不能发现每个条件的错误 表达式内某个条件是一个复杂函数

条件覆盖

==思想：==保证每个判断中的每个条件的取值至少满足一次 条件覆盖不能保证程序所有分支都被执行

判定条件覆盖

==思想：==保证每个条件和由条件组成的判断的取值

条件组合覆盖

==思想：==选择足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次

路径覆盖

==思想：==选择足够的测试用例，保证每条可执行到的路径都至少经过一次，若程序中包含环路，则要求每条环路至少经过一次

基于控制流的测试-基本路径测试方法

==思想：==寻找基本路径，根据基本路径构造测试用例，保证每条路径至少执行一次

1. 测试用例设计流程：

2. 控制流图

   1. 解释：控制流图用于描述程序中的逻辑控制流
   2. 组成
      1. 节点：表示一个或多个过程语句
      2. 边：表示控制流
      3. 域：由边和节点限定的区间
      4. 基本结构：

3. 基本路径测试

   1. 定义：基本路径测试又称独立程序路径，是指任何一条贯穿程序的路径，该路径至少包含一条不同于其他路径的边 基本路径集合并不唯一，但路径数是确定的
   2. 核心问题：
      1. 如何确定基本路径的条数：McCable复杂度度量
      2. 基本路径特性
         1. 基本路径集合中路径条数唯一，基本路径可以不一样
         2. 其他路径可以通过基本路径运算得到
   3. 基本路径的度量——圈复杂度：圈复杂度度量基本路径数，是所有语句被执行一次所需测试用例数的上限
   4. 圈复杂度的计算：
      1. 法1：等于域的数量
      2. 法2：$V(G)=E-N+2$ $E$为边，$N$为节点数
      3. 法3：$V(G)=P+1$，$P$为判定节点数
   5. 基本路径的特性：每一条路径都可以表示为边的向量
      1. 维：若路径经过边$n$次，向量值对应的维就是$n$
      2. 任何路径对应的向量都可以通过基本路径的线性运算组合出来
      3. 基本路径集合并不唯一，但路径数是确定的

基于控制流的测试-循环处理方法

1. 分类：

2. 简单循环测试用例构造

   1. 跳过整个循环
   2. 只执行一次循环
   3. 执行两次循环
   4. 执行m次循环
   5. 执行n-1,n,n+1次循环

3. 嵌套循环测试用例构造：

   1. 先测试最内层嵌套循环
      1. 所有最外层的循环变量置为最小值
      2. 最外层按简单循环测试
   2. 有里向外，测试上层循环
      1. 此层之外的所有外层循环的循环变量取最小值
      2. 此层以内的所有嵌套内层循环的循环变量取“典型值”
      3. 该层按简单循环测试
   3. 重复上一条规则，直到所有层循环测试完毕
   4. 对全部各层循环同事去最小循环次数或最大循环次数

4. 串接循环测试用例构造

   1. 若串接的各个循环相互独立，则分别用简单循环的方法进行测试
   2. 若两个循环不独立，则将第一个循环看做内循环，第二个看做外循环，然后用嵌套循环的办法来处理

5. 非结构循环

   1. 先将其结构化，然后进行测试
   2. 重复编码法：

基于数据流的测试

1. 数据流测试是一种面向变量定义-使用位置覆盖的基于程序结构的测试方法。

   1. 该测试方法重点关注变量的定义与使用
   2. 在选定的一组代码中搜索某个变量所有的定义位置和使用位置，并检查在程序运行时该变量的值将会如何变化，从而分析是否是Bug的产生原因

2. 数据流测试与路径测试的区别在于

   1. 路径测试基本上是从控制流角度来分析
   2. 数据流测试则是从数据流的角度来分析，利用变量之间的关系，通过定义-使用路径设置一系列的覆盖标准用于衡量测试的覆盖率

3. 数据流

   1. 数据流是变量的定义或使用顺序和变量可能状态的一种抽象表示
   2. 变量的状态可以使：创建/定义、使用、清除/销毁
   3. 变量存在从创建、使用到销毁的一个完整状态变化过程
   4. 变量复制错误检查是发现代码缺陷或错误的一种有效方法
   5. 实际上该方法是路径测试的“真实性”检查，是对基于路径测试的一种改良

4. 数据流覆盖

   1. 程序是对数据的加工处理过程，对程序的测试可从数据处理流程的角度进行考虑
   2. 数据的处理过程对应数据流图
      1. 数据流图类似控制流图，描述了测试对象代码的处理过程。同时也详细描述了代码中变量的创建、使用和撤销的状态。通过检查数据流图来验证测试对象代码中每个变量的状态组合是否正确
   3. 受debugging过程的启发：寻找关于某变量的定义和使用位置，思考程序在运行时该变量的值会如何变化，从而分析Bug产生的原因。

5. 作用：

   1. 用来测试变量定义点和使用点之间的路径。这些路径也称为”定义-使用对”。通过数据流分析而生成的测试集可用来获得针对每个变量的定义使用对的100%覆盖
   2. 要追踪整个程序代码中的每个变量的定义和使用时，并不需要在测试中考虑被测对象的控制流

6. 原理：根据程序中的变量定义和其后变量使用的位置来选择程序的测试路径

   1. 基本定义：
      1. P：程序
      2. G§：程序数据流图
      3. V：变量集合
      4. PATH§：P的所有路径集合

7. 数据流覆盖基础

   1. 定义节点DEF(v,n)：在节点n定义了变量v
   2. 使用节点USE(v,n)：在节点n使用了变量v
   3. 为此使用P-Use：USE(v,n)位于一个谓词中
   4. 计算使用C-USE：USE(v,n)位于一个计算中
   5. 输出使用O-use：变量值被输出到屏幕/打印机
   6. 定位使用L-use：变量值用于定位数组位置
   7. 迭代使用I-use：变量值用于控制循环次数
   8. 定义-使用路径(du-path)：给定PATH§中的某条路径，如果定义节点DEF(v,m)为该路径的起始节点，使用节点USE(v,n)为该路径的终止节点，则该路径是v的一条du-path
   9. 定义-清洁路径(dc-path)：如果变量v的某个定义-使用路径，除起始节点以外没有其他定义节点，则该路径是变量v的定义-清洁路径

8. 优点

   1. 揭示隐藏在代码变量定义和使用中的各种错误
   2. 可以覆盖所有语句、所有分支、所有路径
   3. 对代码的测试比较彻底

9. 缺点

   1. 无法检测代码中的不可达路径
   2. 不验证需求规格

数据流覆盖测试

1. 步骤

   1. 对于给定的程序，构造相应的程序数据流图
   2. 找出所有变量的du路径
   3. 考察测试用例对这些路径的覆盖程度，即可作为衡量测试效果的度量值

2. 覆盖标准

   1. Rapps和Weynker标准

      1. 目标
         1. 保证所选路径数目总是有限的可被实际处理的
         2. 寻找一种系统化的测试路径选择方案，以帮助发现位置缺陷
      2. 度量标准
         1. All-Paths：等价于路径覆盖
         2. All-Edges：等价于分支覆盖
         3. All-Nodes：等价于语句覆盖
         4. All-Defs：每个变量的定义节点都有一条dc-path到达该定义的某个使用节点
         5. All-P-Uses：路径中的每个变量的定义节点都有一条dc-path到达改定义的每个P-use节点
         6. All-P-Uses/Some C-Uses：
         7. 路径中的每个变量的每个定义节点都有一条dcpath到达该定义的每个P-use节点;但如果没有可达P-use节点，dc-path应到达至少一个C-use节点
         8. All-C-Uses/Some P-Uses：路径中的每个变量的每个定义节点都有一条dcpath到达该定义的每个C-use节点;但如果没有可达C-use节点，dc-path应到达至少一个P-use节点
         9. All-Uses：路径中的每个变量的每个定义节点都有一条dcpath到达该变量的每个使用节点, 若存在定义节点和使用节点间存在多条dc-path,仅选取其中一条。
         10. All-DU-Paths：所有的DU-Path集合。路径中的每个变量的每个定义节点到达该变量的每个使用节点的所有dcpath。若存在循环，仅取一个简单循环或者无循环。

   2. 

   3. 

   4.

面向对象的测试

基本概念

​ 面向对象技术是一种全新的软件开发技术，正逐渐代替被广发使用的面向过程的开发方法，被看成是解决软件危机的新兴技术。面向对象基础产生了更好的系统结构，更规范的编程风格，极大地优化了数据使用的安全性，提高了程序代码的重用

• 对象
  • 一个操作的实体，既包含了特定的数据，又包含了操作这些数据的代码
  • 对象是软件开发期间测试的直接目标，对象的行为是否符合它的说明规定，该对象是否与其他对象是否能够协同工作
  • 对象的生命周期：一个对象被创建时生命周期喀什，这个过程贯穿于对象的一系列状态，当一个对象被销毁时这个对象的声明周期结束
• 消息
  • 消息是对象的操作将要执行的一种请求
  • 包含：名字、实参、类型
  • 协作：面向对象的程序是通过一系列对象的协同工作来实现功能、服务的，这一些做是通过消息之间的相互传递来完成的
• 接口
  • 接口是对象行为声明的集合
  • 接口由一些规范组成
• 类
  • 类是具有共性的对象的集合
  • 面向对象程序运行的基本元素是对象，类则是用来定义对象这一基本元素的
  • 创建对象的过程称为“实例化”，创建的结果称为”实例“
  • 类声明：定义了类的每个对象能做什么
  • 类实现：定义列的每个对象如何做他们能做的事
• 封装
  • 定义类结构
  • 接口由公共方法定义
  • 行为由在其实例数据上操作的方法定义
  • 有助于强制信息隐藏
• 继承
  • 继承是类的一种联系，允许新类在一个已有类的基础上进行定义。一个类对另一个类的以来，使得已有类的说明和实现可以被复用
  • 优势：已有类不会被改变
• 继承修改
  • 只继承父类属性不增加新的属性
  • 增加新的属性
  • 重新定义父类的属性
• 多态
  • 一个属性可能不止一组值
  • 一个操作可能有不止一个方法实现
  • 重载
  • 动态绑定
  • 多态提供了将对象看做是一种或多种类型的能力，类型机制可以支持许多不同的类型适应策略
  • 类型的完全匹配非常安全，多态支持灵活的设计，又易于维护

面向对象的测试

• 系统测试
  • 与传统测试类似
  • 仍然基于需求规约
• 单元
  • Method*
  • Class
• 集成测试
  • 主程序最小化
  • 集成测试是OO测试最复杂的部分
  • 基于合成（composition）
  • 基于类簇（class cluster）
  • 对象关系图：类间以来和方法依赖关系的有向图

面向对象软件的测试和面向对象开发过程的集成

面向对象的软件开发过程模型

• 面向对象的开发模型突破了传统的瀑布模型，采用迭代式增量开发过程模型，每次迭代又包含面向对象分析，面向对象设计，和面向对象编程三个阶段
• OOA阶段产生整个问题空间的抽象描述，在此基础上，OOD阶段进一步设计成适用于面向对象编程语言的类和类的结构，OOP阶段形成代码
• 由于面向对象的特点，采用这种开发模型能有效的将分析设计的文本或图标代码化，不断适应用户需求的变动

Spiral life cycle

• antithesis of waterfall
• Iterative: many refinements
• Incremental: moving forward: functions, features, quality
• intefrative: continual intefration of work products
• Non-linear, evolving prototypes
• more time spent in analysis and design
• less time spent in development

测试过程与软件开发过程集成

面向对象测试模型

1. OOA Test和OOD Test是对分析结果和设计结果的测试，主要是对分析、设计产生的模型图和文档资料进行复审，验证每个模型元素的正确性，由建模专家审查语法正确性，领域专家审查语义正确性，软件专家审查每个类的结构、方法的算法、行为与需求的一致性，是软件开发前期的关键测试
2. OOP Test主要针对编程风格和程序代码实现进行测试，其主要的测试内容在面向对象单元测试和面向对象集成测试中提现
3. OO Unit Test是对程序内部具体单一的功能模块的测试，若果程序是用C++语言实现，主要就是对类成员函数的测试。面向对象 的单元测试是进行面向对象的集成测试的基础
   1. 在面向对象的软件的设计和开发中，说到底就是类的设计和开发。面向对象的软件功能是通过消息传递完成的，因此面向单元测试就是对类的测试。测试策略包括：基于服务的测试，基于状态的测试，基于响应状态的测试
   2. 基于服务的测试：主要考察封装在类中的一个方法对数据进行操作是否存在问题。可以采用传统的白盒测试方法，也可以使用块分支图

      1. 

      2. 绘制服务的控制流图

      3. 确定基本路径集

      4. 生成测试用例

   3. 基于状态的类测试策略：考察类的实例在生命周期各个状态下的情况，采用外界向对象发送特定消息序列的方法来测试对象的响应状态
      1. OSD(Object State Diagram)：OSD模型即对象状态模型，是用于测试对象的一种测试模型，描述了对象在其声明周期中的所有状态及状态之间的相互转移
      2. OSD模型由若干个AOSD模型组成，AOSD为一个四元素$AOSD=(S,D,T,s_0)$，其中S表示一个对象的状态集合，D表示字符集，T表示由对象状态可能产生的转移的集合，s0表示该对象的初始状态。
      3. 步骤
         1. 扫描源程序并得出执行分析表
         2. 确定对象状态表
         3. 构造状态转移
         4. 构造测试消息序列
         5. 生成测试用例
4. OO Integrate Test主要对系统内部的相互服务进行测试，如成员函数间的相互作用，类间的消息传递等。面向对象集成测试不但要基于面向对象的单元测试，更要参见OOD或OOD Test结果
5. 面向对象的系统测试 OO System Test是基于面向对象的集成测试的最后阶段的测试，主要以用户需求为测试标准，需要借鉴OOA或OOA Test结果

面向对象的集成测试

1. 策略
   1. 基于线程的测试：集成对相应系统的一个输入或事件所需的一组类，每个线程分别进行集成和测试，应用回归测试以保证没有产生副作用
   2. 基于使用的测试：按分层来组装系统，可以先进行独立类的测试，然后用测试过的独立类对从属类济宁测试，知道整个系统构造完成
2. 面向对象软件的集成测试过程
   1. 静态测试：针对程序的结构进行，检测程序的结构是否符合设计要求。通过使用测试软件的逆向工程功能，得出源程序的类系统图和函数调用关系图，与OOD结果相比较，检测程序结构和是线上是否有缺陷，检测OOP是否达到了设计要求
   2. 动态测试：根据静态测试得出的函数功能调用关系图或类关系图作为参考，设计测试用例，使其达到一定的测试覆盖标准
3. 设计集成测试用例的步骤
   1. 选定检测的类，确定出类的状态和相应的行为
   2. 确定覆盖标准，利用结构关系图确定待测类的所有关联
   3. 根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态，使用类的服务和期望产生什么行为等。同时还要设计一些类禁止的例子，确认类是否有不合法的行为产生。

面向对象的系统测试

面向对象的系统测试就是测试软件与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能进行工作。系统测试不仅是确认系统在实际运行时，它是否满足用户的需要，也是对软件开发设计的再确认。

包括：

1. 功能测试：以软件分析文档为标准，测试系统的功能是否达到要求，是否满足用户的需求
2. 强度测试：测试系统的负载情况和功能实现情况，比如信息系统能容纳多少人同时在线操作
3. 性能测试：与强度测试相结合，测试软件系统的运行性能。
4. 安全测试：验证安装在系统内的保护机构确实能够对系统进行保护
5. 恢复测试：采用人工的干扰是软件出错，中断使用，检测系统的恢复能力
6. 可用性测试：测试用户是否能够满意使用，主要是指操作是否简便，操作界面是否符合使用习惯
7. 安装/卸载测试：测试用户是否能够方便的安装和卸载。

性能测试

什么是性能测试

1. 什么是软件性能
   1. 软件性能是软件的一种非功能特性，它关注的不是软件是否能够给完成特定功能，而是在完成该功能时所战术出来的及时性
   2. 软件性能是软件在运行的过程中表现出来的时间和空间效率与用户需求之间的吻合程度
   3. 软件性能是软件在运行的过程中表现出来的时间使用情况、空间使用情况、服务能力等
2. 什么是性能（指标）
   1. 响应时间：系统对请求做出响应的时间
      1. 系统相应时间：计算机对用户的输入或请求做出反应的时间
      2. 应用延迟时间：应用接到指令后的处理时间
   2. 吞吐量：是系统在单位时间内处理请求的数量
   3. 并发用户数：是指系统可以同时承载的正常使用系统功能的用户数量
   4. 资源利用率：反映的是在一段时间内平均资源被占用的情况
3. 什么是性能（视角）
   1. 用户视角：对用户而言，性能就是响应时间
   2. 管理员视角：管理员需要使用软件提供的管理功能来方便普通用户使用。管理员首先关注普通用户感受到的软件性能，其次进一步关注如何利用管理功能进行性能调优
   3. 开发人员视角：开发人员视角几乎与管理人员视角一直，但开发人员更加深入地关注软件性能。

性能测试概述

1. 性能测试是通过自动化的测试工具模拟多种正常、峰值、异常负载条件，来对系统的各项性能指标进行测试 响应时间、吞吐量、资源负载率
2. 负载测试和压力测试是两种典型的性能测试方法
   1. 负载测试：测试在各种工作负载的下的系统性能，也就是测试当负载逐渐增加时，系统各项性能指标的变化情况
   2. 压力测试：是检测一个系统的瓶颈或者不能接受的性能点，测试系统能提供的最大级别服务是什么 最大并发用户数，最大用户访问量，最大吞吐量
3. 定义
   1. 从广义上讲，系统的性能是一个很大的概念，覆盖面非常广泛，对一个软件系统而言包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等
   2. 性能测试用来保证产品发布后系统的性能满足用户需求
4. 目的
   1. 验证软件系统是否能够达到用户提出的性能指标
   2. 发现软件系统中是否存在性能瓶颈，最后起到优化系统的目的
   3. 例如：评估系统的能力、识别系统中的弱点、系统调优、检测系统的问题、验证系统的稳定性和可靠性

性能测试的步骤

熟悉应用

1. 了解应用的架构
2. 了解应用的功能逻辑

熟悉需求

1. 获取测试需求
2. 将测试需求转化为性能指标

测试准备

1. 客户机准备：准备客户机，并确保网络带宽大于服务其吞吐量
2. 测试数据准备：设计测试用例，原则是受最小的影响提供最多的测试信息。
3. 测试脚本准备

执行测试

1. 监控客户端和服务端的性能
2. 检测系统资源
3. JVM的监控
4. 响应时间、吞吐量监控

测试结果分析

测试分析一般跟测试监控息息相关，在测试执行的过程中，用各种监控工具能看到系统的运行状态，并及时发现问题

常见的问题有

1. 内存问题：使用内存分析工具，查看堆内存的详细信息
2. 共享资源竞争问题：使用jprofiler等工具，得到线程快照，并分析改进方法

性能测试指标

响应时间

1. 对请求做出相应所需要的时间
2. 网络传输时间$N_1,N_2,N_3,N_4$
3. 应用服务器处理时间：$A_1,A_3$
4. 数据库服务器处理时间：$A_2$
5. 响应时间=$N_1+N_2+N_3+N_4+A_1+A_3+A_2)$

并发用户数

1. 系统用户数：系统额定的用户数量
2. 同时在线用户数：在一定时间范围内，最大的可同时在线的用户数量
3. 平均并发用户数：$C=\frac{n_{平均每天访问用户数}{L}_{平均在线时间}}{T_{用户使用时间}}$
4. 并发数峰值计算：$C\approx C+3\sqrt{C}$

吞吐量

1. 指单位时间内系统处理用户的请求数
2. 从业务角度来看，吞吐量可以用：请求数/s,页面数/s等单位来衡量
3. 从网络角度来看，吞吐量可以用字节/s来衡量

资源利用率

1. 指系统各种资源的使用情况
2. CPU
3. Load Average：CPU使用队列的长度统计信息
4. Memory用量
5. 队列：队列长度
6. IO：磁盘IO
7. 网络：网络流量

软件性能测试方法

1. 基准测试
   1. 有基础标准，能通过对比发现系统的不同点与变化
   2. 应用场景：可以在指定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试即可看出变化对性能的影响
   3. 系统进行基准测试可以在较早的阶段发现性能问题
2. 负载测试
   1. 负载测试：不限制软件的运行资源，测试软件的数据吞吐量上限，以发现设计上的错误或验证系统的负载能力
   2. 目标：负载测试的目标是确定并确保系统在超出最大预期工作量仍能正常运行。同时负载测试还要评估性能。例如响应时间、事务处理速率与其他时间相关的方面
3. 压力测试：
   1. 目的：找出高负载下的系统该问题，例如资源竞争、同步问题、内存泄漏等
4. 容量测试：
   1. 目的：通过测试预先分析出反应软件系统应用特征的某项指标的极限值，系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量
5. 配置测试
   1. 通过被测软硬件的调整，了解各种不同环境对系统性能的影响程度，从而遭到各项资源的队友分配原则
6. 并发测试
   1. 通过模拟用户并发访问，测试多用户并发访问同一应用，同一模块或数据记录时是否存在死锁或其他性能问题。并发用户数 $\ne$并发
7. 可靠性测试
   1. 通过给系统加载一定的业务压力的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行
8. 失效恢复测试
   1. 失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检测如果系统局部发生故障用户能否继续使用系统，以及如果这种情况发生，用户将受到多程度的影响。

常用性能测试工具

1. LoadRunner：

2. PR:

压力测试

1. 压力

   1. 在同一时间或某一时间内，想系统发送预期数量的交易请求
   2. 并发交易请求
   3. 递增交易请求
   4. 并发递增交易请求

2. 压力测试

   1. 测试系统在不同压力情况下的效率情况，以及系统可以承受的压力情况

3. 目的

   1. 发现影响系统性能的瓶颈
   2. 评价系统性能
   3. 对系统资源进行优化
   4. 提高响应时间与吞吐量

4. 测试计划：

5. 测试准备：压力测试用例

   1. 明确测试目的
   2. 准备测试华景
   3. 确定测试数据
   4. 确定测试运行程序
   5. 明确预期结果

6. 设计测试脚本

   1. 捕捉用户操作
   2. 解释为运行脚本语言
   3. 编辑脚本语言
   4. 自动运行模拟用户操作
   5. 直接调用API，避免延迟

7. 测试执行：模拟多用户

   1. 方法
      1. 通过多进程运行相同或不同的测试脚本来模拟多用户执行相同或不同的任务
      2. 通过发包程序发送数据包
   2. 测试数据参数化
      1. 找到需要参数化的域
      2. 合理的设置输入数据

8. 设置并发点

   1. 原因：被测事务不能通知运行
   2. 实现原理：等待、唤醒、释放

9. 执行测试用例

   1. 运行测试脚本
   2. 根据情况调整并发的进程数
   3. 结果自动记录

10. 监测系统资源

    1. 网络阻塞情况
    2. 主机CPU使用情况
    3. 内存使用情况
    4. 缓存使用情况
    5. 数据库系统的数据锁

11. 测试结果分析

    1. 分析对象
       1. 测试使用的时间
       2. 被测事务的响应时间、并发
       3. 进程数，成功数，失败数
       4. 进程失败的原因
       5. 事务相应时间随用户增加的变化图
       6. 资源限制
    2. 分析内容
       1. 测试是否成功、失败原因
       2. 响应时间是否满足要求
       3. 事务相应时间随用户变化图有误剧烈变化

12. 优化调整设置

    1. CPU问题
    2. 内存与高速缓存问题
    3. 磁盘资源问题
    4. 调整配置参数
    5. 优化应用系统网络设置

13. 测试报告

    1. 结果数据
    2. 图形说明

性能仿真实验

软件安全保障

什么是软件安全

1. Security： 指软件受到恶意攻击的情形下依然能够继续正确运行及确保软件被在授权范围内合法使用的思想
2. Safety：是指软件所控制的系统始终处于不危机人的生命财产和生态环境的安全状态的性质
3. 软件安全的范围：
   1. 软件全生命周期的各种阶段的安全问题
   2. 软件开发和运维环境存在的安全问题
   3. 软件自身的各种安全问题 如反编译等
   4. 危害软件安全的各种因素：外因、内因

软件安全包含的内容

1. 内存安全
   1. 缓冲区溢出
   2. 栈溢出
   3. 堆溢出
   4. 整数溢出
   5. 数组下标越界
   6. 字符串格式化
2. 线程/进程安全
   1. 线程同步安全
   2. 线程协作安全
   3. 线程死锁安全
   4. 线程控制安全
   5. 进程安全
3. 异常/错误处理中的安全
   1. 出现异常即崩溃
   2. 异常捕获安全
   3. 异常处理安全
   4. Error处理
4. 输入安全
   1. ”一切输入都是有害的“
   2. 用户输入安全
   3. 数字输入安全
   4. 字符串输入安全
   5. 环境变量输入安全
   6. 文件名输入安全
   7. 数据库输入安全
5. 国际化安全
   1. 国际化
   2. 本地化
   3. 全球化
   4. 字符集转换
6. 面向对象中的安全
   1. 对象内存分配与释放
   2. 对象线程安全
   3. 对象序列化安全
   4. 静态成员安全
7. Web安全
   1. URL操作攻击
   2. 页面状态值安全
   3. Web跨站脚本攻击
   4. SQL注入
8. 不适当的访问控制设置
   1. Access Control List
   2. 应用程序抵御攻击的最后屏障
   3. Administrator（完全控制）+Everyone（读取）
   4. 特权提升
9. 远程调用安全
   1. 远程调用安全
   2. DCOM安全
   3. Active X组件安全
10. 拒绝服务攻击
    1. DOS
       1. 应用程序失败攻击
       2. 资源不足攻击
          1. CPU不足攻击
          2. 内存不足攻击
          3. 资源不足攻击
          4. io带宽攻击
    2. 攻击原理
       1. 基于漏洞的攻击（逻辑攻击）
       2. 基于流量的攻击（洪水攻击）
    3. 分布式拒绝服务攻击（DDoS）
11. 数据的加密保护
    1. 糟糕的密码保存处理
    2. 加密算法中使用不良的随机数
12. 代码注入
    1. SQL注入
    2. DLL注入
       1. Windows消息钩子
       2. 远程线程注入
       3. 注册表修改

软件安全的产生原因

软件安全问题解决之道

1. 先验方法
   1. 安全设计
   2. 安全风险预防、转移、回避策略
2. 后验方法
   1. 安全测试、渗透测试
   2. 安全分析、安全验证
   3. 安全严重等级评估

先验方法：软件安全开发

1. 让每个软都参与进来
2. 主动的安全开发过程：在各个阶段保持安全开发，包括设计阶段、开发阶段、测试阶段、发行和维护阶段
3. 安全设计核心原则：
   1. 攻击面最小化
   2. 基本隐私
   3. 权限最小化
   4. 默认安全
   5. 纵深防御
   6. 威胁建模

后验方法：软件安全测试

安全测试概述

软件安全测试是在软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行验证以验证产品符合安全需求定义和产品质量标准的过程

安全测试方法：

1. 模式匹配方法：将程序看做字符串
2. 状态机模型：将程序看做状态机
3. 黑盒模型：将程序看做黑盒子
4. 白盒模型

与通常测试区别

1. 目标不同：测试以发现bug为目标，安全测试以发现安全隐患为目标
2. 假设条件不同：测试假设导致问题的数据是用户不小心造成的，接口一般只考虑用户界面。安全测试假设导致问题的数据是攻击者处心积虑构造的，需要考虑所有可能的攻击途径
3. 思考域不同：测试以系统所具有的功能为思考域，安全测试的思考域不但包括系统的功能，还有系统的机制、外部环境、y9ingyogn与数据自身安全风险与安全属性等
4. 问题发现模式不同：测试以违反功能定义为判断依据。安全测试以违反权限与能力的约束为判断依据。

安全测试过程

系统必须同时承受正面攻击和侧面、背后攻击

正向测试过程：

反向测试过程

典型测试技术

渗透测试

1. 定义
   1. 渗透测试是通过模拟恶意黑客的攻击方法，来评估计算机网络系统安全的一种评估方法
   2. 包括对系统的任何弱点、技术缺陷或漏洞的主动分析
   3. 分析可以从一个攻击者可能存在的位置来进行，并从这个位置有条件主动利用安全漏洞
   4. 简单来说：渗透测试是指渗透人员在不同位置利用各种手段，对某个特定网络进行测试（模拟攻击），以期发现和挖掘系统中存在的漏洞，然后输出渗透测试报告，并提交给网络所有者
2. 步骤
   1. 规划和准备
   2. 手机相关信息
   3. 初步操作 如连接网络、主机等
   4. 对信息系统进行分析评估，结合前期收集的信息，叠彩区各种方法攻击系统
   5. 关键的攻击入侵环节，发现安全漏洞

模糊测试

1. 定义：模糊测试，是一种通过目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法
2. 核心思想：通过自动或半自动生成的随机数据或经过变异的数据，输入到一个软件中，以期望触发错误条件或引起程序故障。并通过监视软件是否有异常出现。

软件回归测试

概述

1. 为什么要回归测试
   1. 保证软件在演化和维护时，未更改的代码功能不会收到影响
   2. 软件升级换代的需要。
   3. 软件测试体系的必要组成
2. 与传统测试的不同
   1. 测试计划：回归测试面临的可能是修改过的规格说明书、修改过的程序和一个需要更新的旧的测试计划
   2. 测试范围：一般测试是要测试整个程序，而回归测试只要测试被修改的相关部分
   3. 资源分配：回归测试所需的时间、资源需要根据开发具体情况进行
   4. 开发信息：回归测试可能会在不同的地点和时间上进行，及时记录开发信息以保证回归测试的正确性
   5. 测试时间：比一般测试所用的时间少，因为只需要执行测试程序的一部分
   6. 执行频率：一个系统的生命周期内往往要多次进行，一旦系统经过修改就要进行回归测试

回归测试

1. 提出修改需求
2. 修改软件工件
3. 选择和生成测试用例
4. 执行测试
5. 识别失败结果
6. 确认错误
7. 排除错误

回归测试策略

1. 全部重新测试

   1. 优点：
      1. 不需要话太多经去选择要执行的测试用例
   2. 缺点
      1. 测试用例的数目很多，若一个系统的改动微小，则全部重新测试则浪费成本

2. 有选择的重新测试方法

   1. 优点：
      1. 若系统改动微小，则只需要执行小部分测试用例
   2. 缺点：
      1. 需要耗费精力进行测试用例的选择
      2. 若测试用例数目不大，或是系统修改很多，那么该方法就不合适
   3. 过程
      1. 对测试用例进行选择
         1. 例如选择某个特性模块的所有相关测试用例，及所有集成测试用例
         2. 固定的特征，保持他们不变
      2. 根据可追溯性原理，从需求到代码、再到测试用例，都要可追溯

   波及效用分析

   1. 修改对象
      1. 软件被修改
      2. 软件相关的东西被修改 需求、设计、文档、代码、测试用例、文档
      3. 任何时候，修改都可能发生 如开发阶段和维护阶段
   2. 修改中遇到的问题
      1. 需要定位改变的部位
      2. 改变的完全性问题
      3. 改变有效重确认问题
      4. 完整性问题
      5. 追踪问题
   3. 波及效应分析：波及效应分析是为了发现所有受影响部分包括潜在受影响部分，以保证软件发生改变后仍然保持一致性与完整性
      1. 需求的波及效应分析
      2. 设计的波及效应分析
      3. 代码的波及效应分析
      4. 测试用例的波及效应分析
   4. 波及效用分析步骤
      1. 实施初始的改变
      2. 识别潜在的受影响的组件
      3. 决定这些受到潜在影响的组件中那些需要改变
      4. 决定如何进行这些改变，对于每一个改变都要从第一步开始重复。如果没有要进行的改变，就结束。
   5. 分析方法
      1. 字符串匹配或者交叉引用
         1. 字符串匹配不考虑程序执行，而是要人类智慧进行REA操作。绝大多数的再工程工具都是基于字符串匹配 如重新选择若干语句构造新函数
      2. 程序切片
         1. 程序切片方法能够确认直接和间接的波及，可以设计测试工具自动地产生程序切片 目前仅限于思想知道，尚未见成熟的商用工具
   6. 分类
      1. 直接波及：那些被初始的更改影响的
      2. 诱发波及：由直接波及和其他波及诱发引起的

回归测试开销

1. 为了测试那些新改变的代码，要生成新的测试用例T1
2. 对原有的测试用例进行有效性选择、确认T2
3. 执行测试用例：T1+T2
4. 比较测试用例的执行结果与预期执行结果
5. 回溯失败，查明导致失败的模块或修改

软件质量相关标准规范

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NT5uiYaX-1657547482183)(figures/软件质量保障/image-20220620142139209.png)]

概述

标准层次

1. 国际标准
2. 国家标准
3. 行业标准
4. 企业规范
5. 项目规范

典型的软件质量模型和框架

1. ISO 9126

2. FURPS+模型：Function, Usability, Reliability, Performance, Supportability的缩写

IEEE软件工程标准