单元测试计划与实施1分析报告.ppt

? IPL Information Processing Limited 1997 An Introduction to IPL ? IPL Information Processing Limited 初步介绍 主题 范围 一些基本概念 主题 基本定义 单元测试方法 设置测试目标 动态分析 功能/黑盒技术 结构/白盒技术 开发测试说明书 范围 3GL 开发的单元测试 适合所有集成水平的软件 适合任何领域的应用软件 不特指哪一个工具 一些基本概念 : 软件测试的定义 Hetzel (1973): “测试是对软件或系统是否完成应有的功能建立信心的过程 Myers (1979): “测试运行程序和系统来找错的过程 IEEE (1983): “测试是手工或自动方式执行或评估一个系统来验证是否符合需求或者检验期望结果和实际结果之间的差异 Hetzel (1983): “测试是把评估程序或系统的属性或能力的任何活动”; “测试是对软件质量的衡量 正向测试 和逆向测试 综合以上所有的定义: “软件的行为是否符合需求? 关键的是 需求 正向测试 Does it do everything it is specified to do? 逆向测试 Does it do anything it is not specified to do? 黑盒测试和白盒测试 黑盒 (功能)技术 用单元的接口和功能描述 无需知道单元内部如何建立 白盒 (结构) 技术 使用单元内部工作的信息，包括分支，路径 什么是单元测试? 什么是单元? 软件说明书中提供的最小组件: 函数 子程序 过程 类 包 4GL 菜单和显示 测试这些组件 (单元) 最底层的正式测试 测试和调试 调试是: 当软件出问题时，分析并且定位故障的过程 调试支持测试 但是不能替代测试 测试找到错误 找到错误出在哪里为什么出现 从需求规范书开始 如果没有需求规范，测试就失去了意义 更好的测试需要更好的需求规范 更好的需求规范驱动更好的测试 No 需求规范 = No 定义 = No 期待 = No 真正的测试! 属性 怎么知道测试通过了? 比较真实/期望输出 确定性的测试: 期望的输出可以准确预测 输出结果在重复的时候不会变化 当环境或者软件改变时: 测试必须维护 和 重复 当测试出现不足时: 测试必须维护 确定性 和可重复性 可维护性的前提 桩和驱动 测试驱动 为了测试软件去运行软件 提供一个框架: 设置输入 运行软件 检查输出 桩 是单元的一个模仿品 代替真实的单元推动测试 单元测试的三种通用方法: Top down自顶向下 Bottom up自底向上 Isolation隔离 自顶向下 单元测试： 使用上层的调用者 下层函数用桩代替 自顶向下测试 最上层的函数最先测试 自顶向下测试 最上层的函数最先测试 A Top Down Test Plan 1 Test A; stub B, C, D 2 Test B; call B from A; stub C, D 3 Test C; call C from A; use B; stub D 4 Test D; call D from A; use B, C; stub E, F, G 5 Test E; call E from D, call D from A; use B, C; stub F, G, H, I, J 6 Test F; call F from D, call D from A; use B, C, E; stub G, H, I, J 7 Test G; call G from D, call D from A; use B, C, E, F; stub H, I, J 8 Test H; call H from E; call E from D, call D from A; use B, C, E, F, G; stub I, J 9 Test I; call I from E, call E from D, call D from A; use B, C, E, F, G, H; stub J 10 Test J; call J from E, call E from D, call D from A; use B, C, E, F, G, H, I 自顶向下优点 提供尽早的集成 ‘看得见的’功能 在软件集成阶段之前 真正的单元测试和软件集成的结合 详细设计也是top down 按照单元设计的顺序 单元可以在设计的时候开始编程和测试 自顶向下缺点 测试数据分散在许多桩模块中 需要了解单元的结构方面的知识 测试很难理解和维护 随着模块的层次下降 测试越来越困难 特别是当单元被多个单元调用时去过 提高