软件工程第7章：实现2基于过程测试讲述.ppt

V模型 软件测试应该贯穿于整个软件开发过程中 需求分析 概要设计 详细设计 代码实现 验收测试 系统测试 集成测试 单元测试 7.3 单元测试 对软件基本组成单元的测试（隔离、独立） 强调被测对象的独立性的原因 避免其他单元对测试单元的影响 缩小问题分析范围，便于缺陷定位 单元：函数、类、功能模块、组件 （实现一个特定功能，与其他单元有明确的接口定义） 单元的理解 1. 单元测试的必要性 测试效果直接影响后续的集成测试、验收测试； 缺陷发现越早，越容易纠正，费用也越低； 开发人员在单元测试阶段对测试工作比较默然甚至抵触，所以单元测试流程亟需完整和规范。 12小时 6小时 3小时 单元测试 集成测试 系统测试 2.单元测试的任务 对逻辑、功能、数据和安全性等方面的测试。 独立执行路径测试 局部数据结构测试 单元接口测试 单元边界条件测试 错误处理通路测试 误解、误用运算符优先级 混合类型运算 变量初始化取值错误 精度不够 表达式符号错误 不同数据类型对象间的比较 循环终止条件不可能出现、迭代发散 错误的修改循环变量 （1）独立路径测试 （2）局部数据结构测试 临时存储在单元内的数据——错误的根源 不合适或不相容的类型说明 变量无初值 变量初始化或默认值有错 不正确的变量名 出现上溢、下溢和地址异常 （3）单元接口测试 输入的实参和形参的个数、类型是否匹配 是否修改了只读型参数 文件属性是否正确 文件使用前是否打开 （4）边界条件测试 如果在单元测试时不做边界值测试，在以后的测试很难发现，即使发现也很难追踪。 （5）错误处理通路测试 输出的出错信息难以理解 记录的错误与实际的错误不相符 异常处理不当 错误陈述中未能提供足够的定位出错信息 （6）其它 单元边界处理测试 软件经常在边界上失效 内存分析 内存泄漏会导致系统的崩溃，尤其是嵌入式系统 3.驱动程序和桩程序 4.单元测试的管理 在单元测试的各个阶段中，必须遵守一定规则，以一些设计文档等为依据，并产生报告、分析文档等 将文档管理与单元测试过程管理结合起来 计划阶段 《软件需求规格说明书》 《单元测试计划》 执行阶段 《软件详细设计说明书》 《单元测试用例》 设计阶段 《缺陷跟踪报告》 《代码审查检查表》 《单元测试检查表》 提交阶段 评估阶段 测试完备性评估 代码覆盖率评估 《单元测试报告》 V模型 软件测试应该贯穿于整个软件开发过程中 需求分析 概要设计 详细设计 代码实现 验收测试 系统测试 集成测试 单元测试 7.4 集成测试 为什么总是集成不起来？ 集成测试的内容与原则 集成测试的模式 集成测试的方法 集成测试又称“组装测试”、“联合测试” 把已通过单元测试的软件单元（或模块）逐步组合在一起进行测试，验证模块接口之间存在的问题。 一 集成测试内容与原则 补充单元测试的不彻底性 能有效地加快进度，减少隐患 1. 定义 穿越模块接口的数据丢失问题 集成后能否达到预期的总体功能 模块功能相互影响 全局数据结构的问题 误差积累、误差放大问题 共享资源的访问问题 2. 集成测试内容 3. 集成测试原则 足够的资源和时间 严密的计划，严格的执行 增量式的分步集成方式 自动化技术的引入（提高效率） 测试用例的积累和管理（回归测试） 二 集成测试的模式 模式 非渐增式 渐增式 工作量 小 大 发现错误时间 晚 早 诊断错误 困难 容易 测试程度 不彻底 彻底 需要的机器时间 少 多 并行测试 不能 能 三 集成测试的方法 大棒集成法 自顶向下法 自底向上法 混合法 三明治集成法 改进的三明治集成法 持续集成法 1. 大棒集成法(Big-bang Integration) 一次性集成 缺点：错误定位难、错误原因查找难 优点：适合较小规模的应用系统 驱动程序/驱动模块（driver） 桩程序/桩模块（stub） 2. 自顶向下法(Top-down Integration) M1 S1 M3 M2 S7 M5 M5 M8 深度优先：M1 → M2 → M5 → M8 → M6 →M3 →S7 → S4 宽度优先：M1 → M2 →M3 →S4 →M5 →M6 →S7 →M8 从主控模块开始，用桩程序代替附属模块 根据策略，依次用实际模块代替一个桩程序（回归测试） 结合新模块进行测试； 重复②③。 M1 S1 M3 M2 S7 M5 M5 M8 优点： 不需要驱动程序； 在测试早期验证系统的主要功能； 在早期发现上层模块的接口错误。 缺点： 需要桩程序； 低层模块中的错误发现较晚； 在测试早期不能充分展开人力。 3. 自底向上法(Bottom-up Integration) 划分子功能族； 开发驱动程序； 子功能族测试； 去掉驱动，引入新单元，组成更大功能