软件检验与软件测试PPT课件

精品课件 1 第9章软件检验与软件测试 教材第19章 20章 有关概念V V规划软件检查程序的自动静态分析软件测试的目的和原则测试用例设计软件测试过程面向对象测试测试的管理软件的可靠性与可用性 精品课件 2 9 1检验与有效性验证的有关概念 检验和有效性验证 VerificationandValidation V V 也有人称为验证与确认 是整个软件生命周期中对各阶段 需求评审 设计评审 代码检查 产品测试 过程活动的结果检查和分析的过程 以确保软件既能符合定义中的要求 又能满足客户或用户的要求 Boehm给出了二者之间的不同 检验 是否正确地建立一个产品 有效性验证 是否建立了一个正确的产品 检验 验证 的作用是检查软件是否符合它的描述中所定义的功能和非功能的需求 而有效性验证 确认 要说明软件是否最终满足用户的要求 如需求中的一些错误和遗漏可能在系统完全实现后才能发现 精品课件 3 在V V过程中有两个系统检验和分析技术 软件检查检查各种文档 静态检验技术 软件测试动态检验技术 实现运行检验 下图给出了两个技术活动在软件过程中的位置 软件检查 需求描述 高层设计 形式化描述 详细设计 软件实现 原型 软件测试 静态 动态检验和有效性验证 箭头指示的是该项技术活动在那个阶段使用 精品课件 4 验证技术包括程序检查 自动化源代码分析和形式化检验 但静态技术只能检查程序及其描述之间的吻合程度 检验 不能够说明软件真的是有用的 也不能检验软件的非功能特性 只有通过测试才能验证系统的有效性 测试和调试是两个不同的过程 测试是一个发现软件缺陷 Defect 的过程 调试是一个对缺陷定位和修改的过程 如图所示 测试结果 描述 测试用例 定位错误 修改设计错误 修改代码 对程序再测试 调试过程 精品课件 5 9 2V V规划 该过程的规划应该在开发过程的早期开始 下图说明了测试计划如何从系统描述和设计中导出 有时也称之为V模型 需求描述 实现 系统设计 详细设计 单元测试 子系统集成测试 系统集成测试 验收测试 验收测试计划 系统集成测试计划 子系统集成测试计划 单元测试计划 精品课件 6 对测试的规划主要是制定测试过程标准 主要组成部分见下表 软件测试计划的结构 精品课件 7 9 3软件检查 系统的软件测试过程很耗时间 成本是昂贵的 软件检查在程序完成之前就应进行 检查的对象是可以是系统模型 系统描述或源代码 要充分利用开发系统的知识和源表示形式的语义来发现错误 软件检查是一种有效的错误检测技术 能够在初始阶段发现绝大多数错误 有专家报告说明超过60 的程序错误是通过检查发现的 软件检查不仅包括程序检查 还包括对软件过程中生成的所有文档的的检查 精品课件 8 程序检查程序检查的目标是发现缺陷 缺陷可能是逻辑错误 错误的条件 或是与机构和项目标准不相符的问题 程序检查的过程是一个正式的过程 应该由4个人以上的小组来实行 教材P295列出了检查过程中的角色 下图列出了一般的程序检查过程 规划 概览 个人准备 会议讨论 修改缺陷 后续行动 检查过程 仲裁者决定是否反复 最后要对审查清单签署意见 精品课件 9 检查过程应该有一个程序员常出错误的核对清单 团队有经验的人员经过讨论建立该清单 并随着经验的积累丰富这个清单 不同的程序语言由于编译器提供的检查层次不同应该有不同的清单 教材P296列出了要检查的项目 数据 控制 I O 接口 存储管理 异常管理等方面的缺陷 专家建议检查过程不要超过两小时 否则缺陷检查的效率会大大降低 因此在程序开发过程中应该经常进行检查 每次选择一个相对较小的组件 管理者一定要将程序检查和人事评价严格分开 检查结果暴露的错误不能作为程序员事业评估的依据 要建立起一种鼓励发现错误 不会因为这些错误引来指责的良好的企业文化 精品课件 10 9 4自动静态分析 静态程序分析器是一个软件工具 如Unix系统中用于C语言的Lint 扫描源代码 通过解析程序文本识别缺陷 如 有不可到达的代码段 未初始化的变量或指针 未说明或使用的变量 可能的数组越界 参数类型或个数不匹配等 静态分析包括以下几个阶段 控制流分析找出并显示有多重出口或入口的循环以及不可到达的代码段 如无条件转移语句包围的一段代码 条件语句中不可能到达的条件 数据使用分析突出显示变量的使用情况 也发现那些判定值从不发生改变的条件 精品课件 11 接口分析检查函数或子程序说明和使用的一致性 强类型检查语言 Pascal Java 编译器已包含该功能 接口分析能发现类型检查较弱的语言 如C或C 较小的子集 中的类型错误 也能发现已定义但未被调用的函数和子程序或从未使用过的函数结果 信息流分析找出输入变量和输出变量之间的依赖关系 显式地列出程序中使用的变量值的出处 能给出影响变量值的条件 路径分析找出所有可能的路径并列出在一条路径中执行的语句 精品课件 12 信息流分析和路径分析产生大量的信息 是从不同视点展示这个程序 往往只用在检查程序不规则状态的部分 基于工具的分析不能替代程序检查 如 虽能发现未初始化的变量 但不能发现不正确的初始化 虽能发现形实参之间类型和个数不一致 但不能发现传递的值不正确等情况 因此需要动态测试 精品课件 13 9 5软件测试的目的和原则 1 软件测试的目的案例1 1963年 美国 飞往火星的火箭爆炸 损失 10million 原因 FORTRAN循环 DO5I 1 3误写为DO5I 1 3案例2 1994年秋天 迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏LionKingAnimatedStorybook 销售额非常客观 然而 12月26日 圣诞节后的一天 迪斯尼公司的客户支持部电话开始响个不停 后来证实 迪斯尼公司没有对市场上投入使用的各种PC机型进行正确的测试 软件在用于开发游戏的系统中能正常工作 但在大众使用的常见系统中却不行 精品课件 14 由以上两个案例不难看出 软件测试的重要性 小到游戏的瘫痪 大到投入上亿元的航天项目 引起软件缺陷的原因也多种多样 有的仅仅是一个小数点的错误 有的是跨平台的不兼容性 软件测试的工作量约占整个项目工作量的40 左右 对于要求极高的系统测试工作量还要成倍增加 微软Exchange2000和Windows2000中的人员结构Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人测试人员 开发人员2 51 9 精品课件 15 为什么需要这么多人 花这么多代价进行测试 目的何在 证明程序正确 对吗 Myers对软件测试目的提出以下观点 1 软件测试是为了发现错误而执行程序的过程 2 一个好的测试用例能够发现至今尚未发现的错误 3 一个成功的测试是发现了至今尚未发现的错误的测试 因此 测试阶段的基本任务应该是根据软件开发各阶段的文档资料和软件的结构 精心设计一组 高产 的测试用例 利用这些用例执行程序 找出软件中潜在的各种错误 Bug 和缺陷 Defect 精品课件 16 2 软件测试的原则 1 测试用例不但应有输入数据 还应有预期的输出结果 这样便于对照检查 做到 有的放矢 2 测试用例不仅选用合理的输入数据 还要选择不合理的输入数据 这样能更多地发现错误 提高程序的可靠性 对于不合理的输入数据 要将反馈信息提供给用户 3 除了检查程序是否做了它应该做的事 还可检查程序是否做了它不应该做的事 例如程序正确地打印出用户所需信息的同时还是否打印出用户并不需要的多余信息 4 应制定测试计划并严格执行 排除随意性 5 长期保留测试用例 为以后进行的回归测试和维护提供方便 精品课件 17 6 对发现错误较多的程序段 应进行更深入的测试 二八原则 另外在修改错误过程中容易引入新的错误 7 为了达到最有效的测试效果 测试最好由第三方来进行 3 测试阶段的信息流程 预完善 精品课件 18 其中软件配置 需求说明书 设计说明书和源程序 测试配置 测试计划 测试工具 测试用例 Testcase 和测试驱动程序 Driver 桩程序 Stub 等 4 测试方法 1 黑盒 Black box 法不考虑被测程序的内部结构和处理过程 只关心它的输入和输出是否能达到预期结果 因此也称为功能性测试 2 白盒 White box 法使用更细致的测试策略 检查被测程序的内部逻辑 黑盒测试法与白盒测试法互为补充 在测试的不同阶段使用以发现不同类型的错误 精品课件 19 测试用例如何设计 是否考虑所有的数据域或所有的路径 穷尽测试 completetest 通常是不可能的 例如 Black box 程序要求输入3个整形数据 若字长16位 则各种可能输入的排列组合共有216 216 216 3 1014若程序执行一次需一毫秒 则对于所有合法输入的测试大约需用一万年 还未包含测试输入非法数据的情况 精品课件 20 例 White box 下图所示的程序中共有520 1014条可能的执行通路 显然 每条通路都执行一遍是不现实的 即使每条路径都测试了 程序仍可能有错 如一个升序程序编成了降序 穷尽测试也发现不了 精品课件 21 9 6测试用例设计 白盒法和黑盒法是设计测试用例的基本策略 每一种策略对应着多个设计用例的技术 每种技术可达到一定的测试目的 1 白盒技术被测对象基本上是源程序 以程序的内部逻辑结构为基础设计测试用例 原则是 保证被测程序中每一条独立的路径至少执行一次 保证所有判断的每一分支至少执行一次 保证每一循环都在边界条件和可操作的范围内各执行一次 验证内部数据结构以确保其有效性 精品课件 22 1 逻辑覆盖主要用于测试选择结构 语句覆盖 每个语句至少执行一次 Testcase A 2 B 0 X 4 问题 若AND错写为OR 或X 1错写为X 1 则错误无法由上例测出 精品课件 23 判定覆盖 每个判定的每个分支至少执行一次Testcases A 3 B 0 X 3 A 2 B 1 X 1问题 若X 1错写为X 1 仍然无法被测出 精品课件 24 条件覆盖使得每个判定的每个条件的取值至少执行一次 Testcases A 2 B 0 X 4 满足A 1 B 0 A 2 X 1 A 1 B 1 X 1 满足A 1 B 0 A 2 X 1 问 条件覆盖包含判定覆盖 答 不一定 反例 A 2 B 0 X 1 A 1 B 1 X 2 精品课件 25 表面上看 条件覆盖标准测试了所有条件的取值 但事实并非如此 为什么 应该将条件表达式进行分解 以便有效的检查所有条件 如右图 A 1 B 0 X X A A 2 X 1 X X 1 T T T T 判定 条件覆盖 即判定覆盖 条件覆盖仍然有上述问题 将前述例子的结构改为单个条件判定的嵌套结构 精品课件 26 条件组合覆盖 每个判定表达式中条件的各种可能组合都至少出现一次 全部可能的条件组合为 A 1 B 0 A 1 B 0 A 1 B 0 A 1 B 0 A 2 X 1 A 2 X 1 A 2 X 1 A 2 X 1Testcases A 2 B 0 X 4 TT A 2 B 1 X 1 FT A 1 B 0 X 2 FT A 1 B 1 X 1 FF 问题 没有测试到 TF 的路径 精品课件 27 路径覆盖每条可能的路径都至少执行一次 路径数目很大时 难以覆盖所有的路径 必须把覆盖路径数目压缩到一定限度 路径覆盖 条件组合覆盖 精品课件 28 2 循环覆盖要覆盖含有循环结构的所有路径是不可能的 可通过限制循环次数来测试 给出以下设计原则 单循环设n为允许执行循环的最大次数 作以下测试 跳过循环 仅循环一次 循环m次 m n 分别循环n 1次 n次 n 1次 嵌套循环 置外循环处于最小循环计数值 对内层进行单循环测试 由里向外 回退到上一层循环测试 并置循环若完全独立 采用单循环策略 若第一个循环的计数器作为第二个循环的初值 用嵌套循环策略 精品课件 29 3 基本路径测试由TomMcCabe提出的方法 可以解决覆盖程序路径庞大的难题 主要思想 该方法把要覆盖的路径数压缩到一定限度内 程序中的循环体最多只执行一次 它是在程序控制流图的基础上 分析控制结构的环路复杂性 导出基本可执行路径集 由此设计一组测试用例 保证对程序中的每一条可执行语句至少执行一次 精品课件 30 基本路径测试的步骤为 以详细设计或源程序为基础导出程序的控制流图 简称为流图 flowgraph 它是反映控制流程的有向图 其中小圆圈 为控制流图的一个结点 表示一个或多个无分支的PDL语句或源程序语句 表示控制流的箭头称为边或路径 右图中显示了程序流程图及对应的流图 10 精品课件 31 转换时注意 一条边必须终止于一个结点 在选择结构中分支汇聚处即使无语句也应有一个汇聚结点 如果判断中的条件表达式是复合条件 则需改为一系列只有单个条件的嵌套判断 如下图所示 精品课件 32 计算流图G的环路复杂性可以用3种方法计算 V G 封闭区域数 1其中封闭区域为边和结点圈定的区域 1为图形外的区域 V G 判定结点数 1 V G E N 2其中设E为流图的边数 N为节点数 例如 29页的流图V G 4 精品课件 33 确定只包含独立路径的基本路径集 一条独立路径是至少包含一条在其它独立路径中从未有过的边的路径 即至少包含一条新边 程序的环路复杂性给出了程序基本路径集中的独立路径条数 这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界 基本路径集不唯一 对于给定的流图 可以得到不同的基本路径 精品课件 34 例如 在29页图示的控制流图中 一组独立的路径是path1 1 11path2 1 2 3 4 5 10 1 11path3 1 2 3 6 8 9 10 1 11path4 1 2 3 6 7 9 10 1 11路径path1 path2 path3 path4组成了控制流图的一个基本路径集 设计测试用例 确保基本路径集中的每一条路径的执行 必须注意 某些独立的路径往往不能以独立的方式被测试 即穿越路径所需的数据组合不能形成程序的正常流 在这种情况下 这些路径的测试必须作为另一条路径测试的一部分进行测试 精品课件 35 例 用基本路径测试方法对以下的程序 伪码描述 设计用例 Sort for i 1 ia j k jendfor if k i swap a i a k endfor endSort 精品课件 36 Path1 1 7Path2 1 2 5 1 7Path3 1 2 5 6 1 7Path4 1 2 3 2 5 1 7Path5 1 2 3 4 2 5 6 1 7设计用例 输入 方案 预期输出结果通过路径n 1排序表中只有一个数Path1n 2且输入表已排序的输出表Path4中已排序n 2且输入表已排序的输出表Path5中未排序Path2和Path3无法单独测试 但已包含在Path4和Path5中测试过了 精品课件 37 一小段C语言程序 voidfun intiCount intiType 1 2intx 0 3inty 0 4while iCount 0 5 6if 0 iType 7 x y 2 break 8elseif 1 iType 9 x y 10 10else x y 20 11 12 精品课件 38 9 4 6 8 10 11 7 12 精品课件 39 为了使基本路经测试自动化 称为图矩阵 graphmatrix 的数据结构很有用 PPt34页的流图可转化为如右图的连接矩阵 矩阵中的值为连接权值 可赋予如下属性 执行连接边的概率 穿越连接的处理时间 穿越连接时所需的内存 穿越连接时所需的资源最简单的权值为1 有连接 或0 无连接 1234567 1234567 连接矩阵 结点 连接到结点 含有两个或两个以上项的行表示判定结点 精品课件 40 2 黑盒技术被测对象是功能独立的模块或构件 注重测试软件的功能需求 试图发现以下几类错误 不正确或遗漏的功能 接口错误 数据结构或外部数据库访问错误 性能错误 初始化和终止条件错误 几种具体的方法 1 等价类划分主要思想 根据被测对象的功能说明和输入域 按合理的或不合理划分为若干等价类 为每个等价类设计一个测试用例 这样大大减少测试次数 提高测试效率 该方法步骤如下 精品课件 41 划分等价类对被测程序功能说明的输入域或输出域划分等价类 以下是一些原则或经验 当规定了输入范围时可划分 无效类 有效类 无效类 当规定了输入数据必须遵循的规则时 可确定一个合理等价类 符合规则 和若干不合理等价类 可从各种角度违反规则 例如 Windows文件名可以包含255个字符 但不能包含 等字符 文件名的等价类划分为下表 精品课件 42 为便于设计用例 每个等价类可划分为更小的等价类 当规定了输入的一组值 且对不同值做不同处理时 每个允许的输入值是一个合理的等价类 另有一个不合理的等价类 任何一个不允许的输入值 以上经验也适用于对输出信息的划分 例如在一个序列中搜索某个给定关键字的元素 它的输出有两个明显的等价划分 输入的关键字在这个序列中 输入的关键字不在这个序列中 精品课件 43 设计测试用例 为每个等价类编号 设计一个测试用例 使其尽可能多地覆盖尚未被覆盖的合理等价类 重复这一步直到所有合理等价类都被覆盖 设计一个测试用例 使其只覆盖一个尚未被覆盖的不合理等价类 重复这一步直到所有不合理等价类都被覆盖 2 边界值分析输入域的边界比中间更容易发现错误 是一种补充等价类划分的设计测试用例技术 3 错误推测根据经验或直觉推测程序中可能存在的各种错误 有针对性的设计检查这些错误的测试用例 如 输入 输出数据为零的情况 输入表格为空或输入表格只有一行的情况 精品课件 44 4 使用判定表如果功能说明中含有多个输入条件的逻辑组合 可以建立判定表 判定表的每一列对应一个测试用例 5 状态测试基于状态转换图 选择测试用例 原则 每一种状态至少访问一次 测试最常见的状态转换 测试最不常用的分支 测试所有错误状态及其返回值 测试随机状态转换 在实际测试中 综合使用这些方法 以达到最有效的测试 精品课件 45 例 测试一个二分法的检索程序 二分法检索将检索空间划分成了三个部分 每个部分构成了一个等价类 选择这些等价类集合的边界值作为测试用例 再结合错误推测 考虑 检索序列中只有一个值 序列长是奇数 序列长是偶数 检索的关键字不在检索序列中 精品课件 46 二分法检索程序的测试用例 精品课件 47 9 7软件测试过程 下图列出了软件测试的步骤 包括各个测试活动之间的关系以及需要的信息 精品课件 48 1 单元测试完成对最小的软件设计单元 软件构件或模块的测试 使用详细设计描述作为指南 对重要的控制路径进行测试以发现错误 多采用白盒测试技术 该步骤可以针对系统中多个构件或模块并行进行 1 测试任务 模块接口 局部数据结构 重要的执行路径 错误处理 边界条件 精品课件 49 2 测试环境单元测试紧接在编码之后进行 但一个模块一般不能独立运行 测试时要对每个模块开发驱动程序 driver 和桩程序 stub 驱动程序 接收测试数据 调用被测程序 打印结果 需正确定义驱动程序与被测模块的接口 桩程序 用来模拟测试时缺少的被调用模块的活动 将来由被测程序调用的真正模块替代 桩程序的接口同真正模块一致 内部只做少量处理 如响应调用请求 打印 进入 退出 消息 或直接传回所需数据 精品课件 50 2 集成测试也称为组装测试 对单个构件或模块的测试达到目标之后 将它们组合成一个能工作的系统 一般根据设计中建造的软件体系结构采用黑盒技术进行测试 单个模块能正常工作 组装起来不会有问题 真的吗 单元测试使用的驱动模块和桩模块 与它们所代替的真正模块并不完全等效 因此单元测试有不彻底 不严格的情况 各个模块组装起来 穿越模块接口的数据可能会丢失 一个模块的功能可能会对另一个模块的功能产生不利的影响 各个模块的功能组合起来可能达不到预期的总的功能 精品课件 51 单个模块可以接受的误差 组装起来可能积累和放大到不能接受的程度 全局数据可能会出现问题 因此必须要进行集成测试 用于发现模块组装中可能出现的问题 最终构成一个符合要求的软件系统 深度优先自顶向下宽度优先渐增式三明治式集成的方法自底向上非渐增式 精品课件 52 集成测试的具体方法与步骤设系统是构件组成的的层次结构 如图所示 精品课件 53 1 自顶向下集成 top downintegration 精品课件 54 与单元测试结合起来的自顶向下测试 精品课件 55 集成测试的步骤 测试顶端模块 M 用桩模块 S 替代直接下层模块 根据深度优先或宽度优先的策略 每次用一个实际模块 M 代换一个桩 每结合进一个模块后进行测试 全部或部分地重复以前做过的测试 M 精品课件 56 优点 能在早期发现高层模块接口 主要控制等方面的问题 初期的程序概貌可让人们较早地看到程序的主要功能 增强人们的信心 缺点 桩模块只是对低层模块的模拟 不能提供完整的信息 许多重要的测试须推迟进行 桩模块设计较多 测试开销大 早期不能并行工作 不能充分利用人力 精品课件 57 2 自底向上集成 Bottom upintegration 精品课件 58 自底向上集成步骤 把底层模块 M 组合成族 每族实现一个子功能 用驱动程序 D 输入测试数据 测试子功能族 用实际模块 M 替代驱动程序 把子功能族组合成更大的族 重复上述工作 直至系统整个结构都测试完毕 M M M 精品课件 59 优点 随着上移 驱动模块逐步减少 测试开销较小 容易设计测试用例 早期可以并行工作 底层模块的错误能较早发现 缺点 系统整体功能最后才能看到 全局性的问题发现较晚 精品课件 60 3 三明治式集成 sandwichintegration 精品课件 61 4 一次性集成 big bangintegration 非渐增式测试 优点 并行工作 充分利用人力 缺点 很难找出错误的原因 不易区分接口错误和其他类型错误 精品课件 62 集成策略的比较 Myers1979 精品课件 63 微软的集成方法 微软的集成策略是由市场驱动的 基于尽快产生能运作的产品的需要 使得测试小组能随着开发人员对产品能做什么和应该做什么有更多的了解的同时 随时变动产品说明的特征 产品和项目按特征被划分成各部分 不同的小组负责不同的特征 里程碑的定义由特征的划分来决定 分为最重要的 需要的和最不重要的 最重要的特征首先被开发和集成 而每个里程碑包含了 缓冲时间 处理意外的复杂性或延迟 如果进度必须缩减 则从产品中删掉最不关键的特征 下图显示了里程碑的演化 精品课件 64 精品课件 65 3 系统测试有如下过程 1 功能测试 检查集成的系统在运行时是否满足需求中指定的功能 单元测试和集成测试的重点是构件及构件间的交互 这里的测试不必知道正在执行哪个构件 但必须知道系统是作什么的 与功能相关的活动集合称为线程 thread 因此这里的功能测试有时称为线程测试 功能测试采用黑盒技术 测试用例从需求文档中产生 如 对一个文字处理系统的测试可以检查文档创建 文档修改 文档删除等功能 有时可分析需求的语义 用输入与输出之间或输入与转换之间的逻辑关系建立判定表来实现测试 精品课件 66 2 性能测试 针对的是非功能性需求 即测试的类型由非功能性需求的定义来决定 强度测试 stresstest 评价系统在短时间内到达其极限时的表现 如一个系统设计成每秒最多处理300个事务 容量测试 volumetest 检查系统对大量数据的处理 恢复测试 environmentaltest 检查系统的容错 出错 故障 掉电等处理 能力 能否在指定时间内修正错误并重新启动系统 安全测试 securitytest 测试系统的保护措施及数据与服务的完整性 保密性等 还有许多方面的测试 如对用户的响应时间 执行某个功能的运行时间的计时测试 系统的可用性测试等 精品课件 67 3 接口测试每个构件或子系统都有一个事先定义好了的接口供其它构件调用 接口有多种类型 参数接口 主要是数据和函数指针 由一个构件传递给另一个构件 共享内存接口 有一个被子系统共享的内存块 有存有取 程序接口 在接口中 有子系统封装的一组程序 这些程序可被其他子系统调用 消息传递接口 子系统通过消息传递请求其他子系统上的服务 接口测试的一般准则 下页 精品课件 68 接口测试的一般准则 设计用例 对传给外部构件的参数选择取值范围的边界 当有指针从接口传递时 可用空指针来测试接口 当构件通过程序接口被调用时 设计一些容易引起构件失败的测试 在消息传递系统中进行强度测试 当构件间通过共享内存来交互时 设计一组测试用例 对激活构件的次序有所改变 如生产与消费数据的顺序 静态技术在接口测试中有重要的价值 以上是开发人员以需求规约为依据 采用黑盒技术 通过对系统及其目标的理解而进行的测试 开发人员的理解需要用户的认可 因此还要进行以下用户确认的测试 精品课件 69 3 验收测试 也称确认测试 指验收软件的有效性 使用户确信他们需要的就是这个系统 有时在实际环境中进行 有时在开发环境中进行 除了检查系统功能性能外 还要进行软件配置审查 包括文档的完整性 一致性 准确性的检查 是否具有维护阶段必需的细节 有2种测试策略 Alpha测试 软件交付用户后 用户在开发环境中由开发人员 指导 下进行的测试 Beta测试 用户在目标环境 实际使用环境 下进行的测试 如微软的 WindowsXP Beta2测试版由用户免费试用 半年后测试版作废 4 安装测试 在实际环境中进行的测试 测试系统的完备性及可能被现场条件影响的那些功能或非功能性特性 精品课件 70 4 调试软件测试是一个系统地加以计划和说明的活动 定义测试策略 设计测试用例 根据预期结果评估测试结果 调试 debugging 出现在成功的测试之后 调试的目的 寻找错误的原因并改正 调试的结果 1 发现问题的原因并加以改正 2 未能找到原因 需要假设一个原因 使用测试用例来验证这个假设 重复此过程直到改正错误 调试的方法 个人的经验与技巧 1 蛮力法 bruteforce 2 回溯法 backtracking 3 原因排除法 演绎或归纳并引入二分法的概念 三种方法都可用手工或工具 如C Test 实现 精品课件 71 9 8面向对象的测试 1 面向对象测试的特点面向对象测试的整体目标 以最小的工作量发现最大数量的错误 与传统软件测试的目标是一致的 但是OO程序的性质改变了测试策略与战术 1 传统测试主要是基于程序运行过程的 即选择一组输入数据运行被测程序 通过比较实际结果与预期结果从而判断程序是否有错 而OO程序中的对象通过发送消息启动相应的操作 并且通过修改对象的状态达到转化系统运行状态的目的 同时 在系统中还可能存在并发活动的对象 应此传统的测试方法应扩展 精品课件 72 2 传统程序的复用以调用公共模块为主 运行环境是连续的 而面向对象复用很多是用继承实现的 子类继承过来的同名操作有新的语境 必须要重新测试 随着继承层次的加深 测试的工作量和难度也随之增加 由继承支持的多态的特性同样给测试带来了难度 3 面向对象软件的开发是渐进 演化的开发 从分析 设计到实现使用相同的语义结构 如类 属性 操作 消息 因此要扩大测试的视角 精品课件 73 例如 在分析模型中定义了一个无用的属性 围绕着这个属性可能会带来以下错误 在分析模型中 定义了一个与该属性有关的操作 导致了不正确的类关系 为共享属性和操作创建了不必要的子类 为适应该属性和操作刻画了其类和系统的行为 如果问题在分析阶段未被发现 再将错误继续传播 使得设计模型可能存在 与该类有关的不合适的子系统或进程的划分 与该无用属性有关操作的算法设计 与该无用属性有关操作的接口及消息模式 精品课件 74 如果问题在设计阶段仍未被检测到 并传送到编码活动中 则大量的工作将被花在生成那些实现一个不必要的属性 不必要的操作 不必要的消息通信以及很多其它相关问题的代码 由于分析设计模型不能被执行 所以不能进行传统意义上的测试 只能通过正式技术复审来检查分析模型和设计模型的一致性 精品课件 75 4 面向对象开发工作的演化性使面向对象测试活动也具有演化性 每个构件产生过程中 单元测试随时进行 迭代的每一个构造都要进行集成测试 后期迭代还包括大量的回归测试 迭代结束时进行系统测试 是否设计模式的使用将减轻OO系统的繁重测试 Binder认为每次复用是一个新的使用语境 需要重新谨慎的测试 为了获得OO系统的高可靠性 可能需要更多的而不是更少的测试 精品课件 76 2 面向对象的测试过程在面向对象系统中 Sommerville认为测试可分为4个层次 教材P317 1 测试与对象关联的单个操作 传统的单元测试 白盒 黑盒测试方法相结合 2 测试单个对象类 黑盒测试原理不变 单元测试 3 测试对象集群 严格的自顶向下或自底向上的集成不适用于一组关联对象 应使用其他方法 如基于场景的测试 集成测试 4 测试面向对象系统 根据系统需求进行验证与确认 精品课件 77 1 单元测试 对象或组成的小簇 OO语境中 由于每个类或对象封装了属性和操作这些属性的服务 最小的可测试单位不是个体模块 单元的概念发生了变化 而是封装了多个操作的类或对象 类测试由封装在该类中的操作和类的状态行为驱动的 Sommerville在比较面向对象系统和使用功能模型开发的系统之间的差别时指出 对象作为一个单独的组件一般要比一个功能模块大 类包含一组不同的操作 并且某个特殊操作可能作为类的一部分存在 如子类中继承的操作 因此 单元实际上是类或若干相关的类组成的小簇 精品课件 78 单元测试不再孤立的测试单个操作 而是将操作作为类的一部分 例如 命令 execute 粘贴命令 execute 拷贝命令 execute execute由基类定义并被一组子类继承 每个子类的execute被应用于每个子类定义的私有属性和操作的语境内 因此 仅在基类内测试execute是不充分的 应该在每个子类的语境内测试execute 当然 可在基类的测试要求和测试用例上添加新的要求和用例 精品课件 79 单元测试若用于测试不发生请求的类 如 栈 类 其中操作有 pop push empty 时 同样要设计驱动程序 封装在一个测试类 包 中 测试类负责运行测试用例并给出结果 每个测试用例用一个操作名表示 单元测试如果测试发生请求的类 则需要设计桩程序 封装在桩类中 单元测试主要的参考模型是 类图 类的状态图 活动图 精品课件 80 2 集成测试 大簇 构件 子系统 这里的构件或子系统应该与系统的体系结构相对应 集成测试主要以检查这些构件 子系统的接口为目的 对于类之间的集成 RogerS Pressman认为面向对象软件没有明显的控制层次结构 传统的自顶向下和自底向上集成的测试策略没有太大意义 他提出了两种集成测试策略 基于线程的测试 thread basedtesting 集成一组相互协作的对某个输入或事件作出响应的类 每个线程被分别测试 并使用回归测试以保证没有副作用产生 基于使用的测试 use basedtesting 按层次测试系统 先测试不依赖服务器的独立类 如管理和显示数据的类 然后测试依赖独立类的其他类 逐步增加依赖类 直到测试完整个系统 Sommerville提出基于用例或场景的测试 教材P319 也是一种有效方法 精品课件 81 对于子系统之间的集成 如果系统划分为层次结构 则可以按自顶向下或自底向上集成 同时也需设计驱动类和桩类 如 一个OO系统的结构为 用户界面 A 应用逻辑 B 访问数据库 C 网络通信 D 应用系统的一个结构 该系统可以采用自顶向下 自底向上或三明治式进行集成测试 见下图 精品课件 82 UI层 桩 桩 UI层应用层 桩 桩 UI层应用层 数据库网络 数据库层 网络层 驱动 驱动 数据库网络应用层 驱动 驱动 UI层 桩 桩 数据库层 网络层 驱动 驱动 自顶向下自底向上三明治式 精品课件 83 TestA TestB TestC TestD TestA B TestB C TestB D TestA B C D 单元测试集成测试集成测试 测试过程 UML活动图 集成测试的参考模型是 顺序图 协作图 活动图 概念层 精品课件 84 3 确认测试在确认和系统测试层次 和传统的一样 对用户来讲 系统使用什么方法开发的不是主要问题 测试的内容主要集中于用户可见的动作和用户可识别的系统输出 用户可见的功能 以及系统性能 强度 安全 质量属性等方面的需求 测试人员应该根据需求规约和用例模型设计测试用例 精品课件 85 3 面向对象软件的测试用例设计传统的测试用例设计是由软件的输入 加工 输出视图或个体模块的算法细节驱动的 面向对象测试关注于设计合适的操作序列以测试类的状态和用例的实现 1 传统方法的可用性白盒测试 测试类中定义的每个操作 方法 一个操作相当于传统方法中的函数或子程序 黑盒测试 测试单个对象类 检查类的状态或行为确定是否存在错误 测试对象集群和整个系统的集成测试 确认测试 组件 子系统是黑盒 测试序列跟踪跨越类协作的操作流 即跟踪一个用例的实现 精品课件 86 2 类级测试用例设计 单元测试 着重于单个类及封装的操作 传统的白盒测试要保证所有程序中的语句至少执行一遍 所有的路径都要执行到 在测试对象时 完全的覆盖测试应该包括 测试对象类中的所有操作 测试对象所有属性的设置和访问 测试对象所有可能的状态 即模拟引起状态改变的事件 可按照以下方法设计用例 精品课件 87 随机测试考虑一个银行应用程序 其中account类有下列操作 open setup deposit withdraw balance summarize creditLimit和close 但问题的性质隐含了一些限制 例如 账号必须在其它操作可应用前被打开 在所有操作完成后被关闭 一个account实例的最小行为生命历史包括下面操作 open setup deposit withdraw close它们表示了account的最小测试序列 然而大量的其它行为可能在下面序列中发生 open setup deposit deposit withdraw balance summarize creditLimit n withdraw close一系列操作序列可以随机产生 例如 测试用例1 open setup deposit deposit balance summarize withdraw close 精品课件 88 测试用例2 open setup deposit withdraw deposit balance creditLimit withdraw close可随机选取其它的测试序列以测试该类对象不同的生命历史 划分测试可以减少测试类所需的测试用例的数量 采用与传统测试的等价划分相同的方式 即输入 输出被分类 为处理每个类别设计测试用例 划分类别的具体方法是 基于状态的划分基于类操作改变类状态的能力来对类操作分类 类中有的操作改变类的状态 如account类中的deposit和withdraw 有的操作不改变类的状态 如balance summarize和creditLimit 因此分别独立测试改变状态的操作和不改变状态的操作 精品课件 89 基于属性的划分根据操作使用的属性来划分类操作 即使用相同属性的操作划分在一个等价类中 如account类中 以属性creditLimit来定义划分 操作被定义成3个类别 使用creditLimit的操作 修改creditLimit的操作 不使用或不修改creditLimit的操作 然后对每个划分设计测试序列 基于操作类别的划分如在account类中的操作可被分类为 初始化操作 open setup 计算操作 deposit withdraw 查询操作 balance summarize creditLimit 和终止操作 close 精品课件 90 从行为模型导出的测试类的STD可用于帮助导出测试类的动态行为的测试序列 下图是银行应用系统account类的STD 所涉及的测试应覆盖所有的状态 即操作序列应该导致account类的转换穿越所有允许的状态 精品课件 91 测试用例1 open deposit initial withdrawal final close 最小测试序列 测试用例2 open deposit initial deposit balance credit withdrawal final close测试用例3 open deposit initial deposit withdraw accntInfo withdrawal final close setupacct workingacct nonworkingacct open deposit initial deposit balance credit accntInfo withdrawal final close withdraw 精品课件 92 回想第9章气象台系统的例子 要测试气象台对象的所有状态 必须使用以下状态模型 应该测试到的状态序列的例子包括 shutdown waiting shutdownwaiting calibrating testing transmitting waitingwaiting collecting waiting summarising transmitting waiting shutdown waiting calibrating transmitting testing summarising Collecting Startup Shutdown clock Collectiondone reportWeather Weathersummarycomplete Testcomplete CalibrationOK Transmissiondone Test Calibrate operation 精品课件 93 对对象类中的每个方法至少发送一个消息 使对象从 状态到 状态 表明经过的所有方法均是可操作的 可以使用 宽度优先的方式 遍历STD 一个测试用例测试单个状态转换 当测试新的转换时 仅使用以前被测试过的转换 精品课件 94 3 类间测试用例设计 集成测试 测试类或构件被组装后相互之间能否正常交互完成指定的功能 使用use case作为测试的主要驱动 时序图 协作图为测试提供帮助 和单个类一样 可通过应用随机和划分方法以及基于use case场景和行为模型导出测试用例 随机测试Kirani等人建议用下面的步骤生成多个随机测试序列 对每个客户类 用类操作列表生成随机测试序列 这些操作将发送消息给其他服务类 对生成的每个消息 确定协作类及相应的操作 对服务对象中的每个操作 已被客户类发送的消息调用 确定它所发送的消息 对每个消息 确定下一层被调用的操作并将其引入到测试序列中 精品课件 95 如 某一个应用问题的类协作图如下 A B C D E x1 x2 x3 x4 对B的随机测试序列可能是x1 x2 为了考虑涉及到该测试的协作者 要考虑上述序列中每个操作相关联的消息 设B必须与C协作 需执行x3 以执行x1 B与D协作 需执行x4 以执行x2 因此 对B的测试序列应该是 x1 x3 x2 x4 测试序列跟踪跨越类协作的操作流 基于用例的实现是产生随机测试序列的基础 精品课件 96 划分测试类似于单个类划分测试方法 但需扩展测试序列以包括那些通过发送给协作类的消息而激活的操作 另一种方法是基于特殊类的接口来划分测试 如上图 B接收来自类A和类E的消息 可以通过将B中的方法划分为服务于A和服务于E的操作来测试 基于交互场景的测试先测试那些最常用到的交互场景 不寻常的或异常的场景放在稍后测试 交互场景可以从设计的用例中来 为了补充测试信息 需要用时序图来更详细说明对象是如何完成一个场景的 下图给出了气象台子系统在响应一个采集数据请求时的操作序列 精品课件 97 通信控制器 气象台 气候数据 Request report Acknowledge Report Summarise Send report Reply report Acknowledge 收集气象数据的时序图 可看出发出一个上报数据请求时产生以下的线程来执行 CommsController request WeatherStation report WeatherData summarise 精品课