第7讲回归测试绪论.ppt

上海大学计算机学院 回归测试 软件变化无处不在 在软件生命周期中，存在各种变化 需求、设计、实现、技术、软硬件平台等 变化带来风险 变化传播效应（change propagations）可能会引人新错误，有时甚至是致命的错误 回归测试 回归测试是对之前已测试过、经过修改了的程序进行重新测试，以发现修改带来的新错误或者由于更改而发现之前未发现的错误 测试目标 测试变化部分 检测受影响部分 测试级别 单元回归、集成回归、系统回归 回归测试 主要问题 标识变化 变化影响 受影响的测试用例 从已有测试包中选择回归测试用例 回归测试包约简 回归测试 软件变化类型 需求规格说明书 功能的增、删、改 软件体系结构 增加组件交互，组件的增、删、改 高级设计 变化状态行为，变化组件交互 变化数据库、GUI和功能设计 回归测试 低级设计 变化算法逻辑，变化组件结构 组件 内部数据，控制结构/数据流，内部函数 组件接口 调用参数，消息，协议消息和格式 技术/语言 回归测试 变化影响 需求变化影响设计、编码、测试和文档 设计变化影响编码、测试、关联组件、体系结构和组件交互 实现变化影响测试用例、测试数据、测试脚本、测试规约、代码等 测试变化影响其它测试和测试文档 文档变化影响其它文档 回归测试 回归测试与一般测试的比较 一般测试 回归测试 测试计划 开发测试计划和测试用例 修改测试计划，选择、补充测试用例 测试范围 检测整个程序 检测被修改的相关部分 时间分配 产品开发前预算 没有预算 完成时间 较多 较少 执行频率 频率高 多次 回归测试 软件变化分析 变化影响分析 定义回归测试策略 建立回归测试包 报告测试结果 运行回归测试 回归测试过程 回归测试 回归测试 策略 （1）全部重新测试 重新执行之前的所有测试用例 测试用例数不多或系统大部分被改变时适用 当测试用例很多而系统改动很微小时，很浪费 （2）有选择的重新测试 选择已有测试包的一个子集 测试用例很多而系统改动很微小时，很有用 测试用例数目不多或系统更改很多时，不适合 回归测试 重新确认测试用例 输入不再有效，丢弃或作为负测试用例 输入有效，预期结果不再有效，产生新的预期结果 对黑盒测试，如果在功能性需求和测试用例间维护一种可回溯性，有效性确认效率会高得多 对白盒测试，因为变化会导致设计、编码上的修改，需要生成新的测试用例，或者更改已存在的测试用例以达到一定的覆盖率标准 回归测试 识别错误 组测试（Group Testing） 一组模块单独运行正常，集成时可能失败 利用软件不同版本来帮助发现错误的部分 回归测试 组测试示例 回归测试 测试用例选择 常用选择算法 选择所有与某个特定模块相关的所有测试用例，及所有集成测试用例 依据可追溯性原理，从需求到代码，然后再到测试用例，都要可追溯 回归测试 波漪效应分析(Ripple Effect Analysis, REA) 发现所有受影响部分和潜在的受影响部分，以保证软件改变后仍然保持一致性与完整性 波漪效应分析类型 （1）需求的波漪效应分析 （2）设计的波漪效应分析 （3）代码的波漪效应分析 （4）测试用例的波漪效应分析 （5）阶段间的波漪效应分析 回归测试 波漪效应分析 自动化识别 回归测试 基于图的波漪效应分析 模块防火墙 变化的模块，以及所有可能受影响的模块闭包以及相关的集成链 数据防火墙、类防火墙、状态/迁移防火墙等 回归测试 模块防火墙示例 Main M1 M3 M2 M7 M6 M5 M4 M8 模块防火墙： M5, M1 和 Main 重测试单元： M5, 重集成测试：2, 3, 4 1 2 3 4 变化的模块 回归测试 代码波漪效应分析 （1）字符串匹配或者交叉引用 不考虑程序执行—需要人类智慧来进行REA操作。大多再工程工具都是基于字符串匹配 （2）程序切片 确认直接和间接的波及，自动地产生巨大的程序切片 回归测试 波漪效应 直接波漪(Direct Ripples ) 直接被初始的更改影响的元素，它们与更改点有直接的数据或控制依赖 诱发波漪（Induced Ripples） 由直接波漪和其他诱发波及引起 如果直接波漪后不需要进一步的更改，那么诱发波漪就不需要分析。如图（b） 回归测试 波漪效应分析示例 回归测试 控制依赖性 由if-then-else，while，for, 顺序型语句和OO的消息传递所引起 if-then-else语句的条件改变了，then部分和else部分都因条件改变而被影响 数据的依赖性 数据操作：数据使用、定义和空间释放 在确认数据流前需要确认执行路径，然后查找每一个“定义-使用”对 控制依赖性确认前无法进行数据依赖的确认，可能会发现没必要的数据依赖性 回归测试