软件测试PPT课件.ppt

第10章软件测试 2 130 第10章软件测试 10 1软件测试基础 10 2白盒测试 10 3黑盒测试 10 4测试策略 10 5面向对象测试 10 6测试完成的标准 10 7调试 3 130 教学目的与要求 掌握软件测试的目的 基本原则 测试方法 熟练掌握白盒测试 黑盒测试及测试用例的设计 掌握单元测试 集成测试 确认测试 系统测试等测试策略 4 了解面向对象测试的基本内容 理解测试完成标准 掌握调试的概念及调试方法 4 130 教学重点 软件测试的目的 基本原则 白盒测试 黑盒测试及测试用例的设计 测试策略 教学难点 白盒测试 黑盒测试及测试用例的设计 面向对象测试的基本内容 教学学时5学时 5 130 教学方法采用多媒体课件 讲授法 启发式相结合教学 教学参考文献 软件工程导论 第五版 张海藩 清华大学出版社 软件工程 第二版 齐治昌 高等教育出版社 软件测试教程 宫云战 机械工业出版社 软件测试技术概论 古乐 清华大学出版社 软件性能测试与LoadRunner实战 于涌 人民邮电出版社 6 130 10 1软件测试基础 一 软件测试的目的 测试是一个为了发现错误而执行程序的过程一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例一个成功的测试是指揭示了迄今为至尚未发现的错误的测试根据这个测试目的 应该排除对测试的错误观点 设计合适的测试用例 用尽可能少的测试用例 来发现尽可能多的软件错误 7 130 有关软件测试的错误观点 软件测试是为了证明程序是正确的 即测试能发现程序中所有的错误 事实上这是不可能的 要通过测试发现程序中的所有错误 就要穷举所有可能的输入数据 例 程序P有两个整型输入量X Y 输出量为Z 在32位机上运行 所有的测试数据组 Xi Yi 的数目为 232 232 264 1毫秒执行1次 共需5亿年 8 130 程序测试是证明程序正确地执行了预期的功能 实际上 一个程序不仅要完成它所需完成的功能 而且不应完成它不该做的事 如不能把边长为0 0 0的三条边判断为等边三角形 9 130 二 软件测试的原则 Davis提出了一组指导软件测试的基本原则 1 所有的测试都应可追溯到客户需求2 应在测试工作开始前的较长时间就进行测试计划3 Pareto原则 测试中发现的80 的错误可能来自于20 的程序代码4 测试应从 小规模 开始 逐步转向 大规模 5 穷举测试是不可能的6 为达到最有效的测试 应由独立的第三方来承担测试 10 130 其他的测试原则 1 在设计测试用例时 应包括合理的输入条件和不合理的输入条件2 严格执行测试计划 排除测试的随意性3 应当对每一个测试结果做全面检查4 妥善保存测试计划 测试用例 出错统计和最终分析报告 为维护提供方便5 检查程序是否做了应做的事仅是成功的一半 另一半是检查程序是否做了不该做的事6 在规划测试时不要设想程序中不会查出错误 11 130 三 软件测试方法 软件测试方法 1 静态分析方法指以人工的 非形式化的方法对程序进行分析和测试 主要形式 审查 评审和走查 静态分析动态测试 12 130 评审 Review 评审是由若干开发人员 项目经理 测试人员 用户或领域专家等组成一个会审小组 通过阅读 讨论和争议 对工作制品进行静态分析的过程 类型 需求评审 设计评审和代码评审 评审过程 小组负责人先把需求规格说明 设计说明或程序代码及有关要求 规范等分发给小组成员 作评审依据 在充分阅读有关材料后召开评审会议 主要开发人员进行讲解 其他成员提出问题并展开讨论 审查是否存在错误 评审小组形成产品评审的书面报告 13 130 走查 Walkthrough 走查是由设计人员或编程人员组成一个走查小组 通过阅读一段文档或代码 并进行提问和讨论 从而发现可能存在的缺陷 遗漏和矛盾的地方 类型 设计走查 代码走查 走查过程 与评审过程类似 即先把材料先发给走查小组每个成员 让他们认真研究程序 然后再开会 与评审的区别 评审通常是简单地读程序或对照错误检查表进行检查 走查则是按照所提交的测试用例 人工模仿计算机运行一遍 并记录跟踪情况 14 130 无论Y为何值 都不能够调用子程序 READY Y 0 N X Y X 0 Y N Y 调用子程序 A B C D E 即执行ABC后 是不可能执行路径CDE的 走查时 还常使用以下分析方法 调用图 从语义的角度考察程序的控制路线 15 130 数据流分析图 检查分析变量的定义和引用情况 节点 表示单个语句 有向边 表示控制结构 d 定义r 引用u 未引用 R duuuuuS uruuurY uuddru R 0 5 W 1 S Y A W Y E W Z X Y C Z S 123456 只定义不用未定义引用连续定义 16 130 审查 Inspection 检查是由一些经过严格训练的人员根据评估标准 对于开发过程中的产品或中间制品进行检查 发现其中存在的错误 检查一般是按规定程序和时间计划进行的 参与者来自开发人员 测试人员 质量保证人员或用户 以3 7人组成小组 检查过程 检查遵循一个严格的过程 人员经过培训 检查过程有评估标准 检查过程包括计划 会议准备 会议召开 修改错误 问题跟踪等环节 目的是获得项目管理和质量评估的数据 并改进检查过程本身 17 130 测试用例的设计是软件测试的关键所在设计尽可能少的测试用例来发现尽可能多的错误设计最有可能发现软件错误的测试用例 同时避免使用发现错误效果相同的测试用例测试用例的设计方法大体可分为两类 白盒测试和黑盒测试 2 动态测试方法通过选择适当的测试用例 执行程序 18 130 白盒测试 又称结构测试 把测试对象看作一个透明的盒子 测试人员根据程序内部的逻辑结构及有关信息设计测试用例 检查程序中所有逻辑路径是否都按预定的要求正确地工作 白盒测试主要用于对模块的测试 包括 程序模块中的所有独立路径至少执行一次对所有逻辑判定的取值 真 与 假 都至少测试一次在上下边界及可操作范围内运行所有循环测试内部数据结构的有效性等 19 130 黑盒测试 又称功能测试 把测试对象看做一个黑盒子 测试人员完全不考虑程序内部的逻辑结构和内部特性 只依据程序的需求规格说明书 检查程序的功能是否符合它的功能需求 黑盒测试可用于各种测试 它试图发现以下类型的错误 不正确或遗漏的功能接口错误 如输入 输出参数的个数 类型等数据结构错误或外部信息访问错误性能错误初始化和终止错误 20 130 10 2白盒测试 常用的白盒测试方法有 逻辑覆盖测试基本路径覆盖测试数据流测试循环测试 21 130 逻辑覆盖测试 语句覆盖判定覆盖条件覆盖 判定 条件覆盖条件组合覆盖路径覆盖 逻辑覆盖主要考察使用测试数据运行被测程序时对程序逻辑的覆盖程度 通常希望选择最少的测试用例来满足所需的覆盖标准 主要的覆盖标准有 22 130 例 对下列子程序进行测试Procedure varA B X real beginif A 1 and B 0 thenX X A if A 2 or X 1 thenX X 1end 该子程序接受A B X的值 并将计算结果x的值返回给调用程序 与该子程序对应的流程图如下 23 130 24 130 语句覆盖 语句覆盖是指选择足够的测试用例 使得运行这些测试用例时 被测程序的每个可执行语句都至少执行一次 欲使每个语句都执行一次 只需执行路径L1 sabcde 即可 测试用例如下 25 130 判定覆盖 判定覆盖 也称分支覆盖 是指选择足够的测试用例 使得运行这些测试用例时 被测程序的每个判定的所有可能结果都至少执行一次 即判定的每个分支至少经过一次 判定覆盖将每个判定的所有可能结果都至少执行一次 所以 程序中的所有语句也必定都至少执行一次 因此 满足判定覆盖标准的测试用例也一定满足语句覆盖标准 26 130 欲使每个分支都执行一次 只需执行路径L3 sacde 和L4 sabce 即可 或者 执行路径L1 sabcde 和L2 sace 27 130 条件覆盖 条件覆盖是指选择足够的测试用例 使得运行这些测试用例时 被测程序的每个判定中的每个条件的所有可能结果都至少出现一次 28 130 判定a中各种条件的所有可能结果 A 1 A 1 B 0 B 0 判定c中各种条件的所有可能结果 A 2 A 2 x 1 x 1 a A 1 and B 0 c A 2 or x 1 29 130 条件覆盖通常比判定覆盖强 但有时虽然每个条件的所有可能结果都出现过 但判定表达式的某些可能结果并未出现 上面的二个测试用例满足了条件覆盖标准 但判定c为 假 的结果并未出现 30 130 判定 条件覆盖 判定 条件覆盖是指选择足够的测试用例 使得运行这些测试用例时 被测程序的每个判定的所有可能结果都至少执行一次 并且 每个判定中的每个条件的所有可能结果都至少出现一次 显然 满足判定 条件覆盖标准的测试用例一定也满足判定覆盖 条件覆盖 语句覆盖标准 31 130 a A 1 and B 0 c A 2 or x 1 32 130 条件组合覆盖 条件组合覆盖是指选择足够的测试用例 使得运行这些测试用例时 被测程序的每个判定中条件结果的所有可能组合都至少出现一次显然 满足条件组合覆盖标准的测试用例一定也满足判定覆盖 条件覆盖 判定 条件覆盖 语句覆盖标准 33 130 判定a中条件结果的所有可能组合 A 1 B 0 A 1 B 0 A 1 B 0 A 1 B 0判定c中条件结果的所有可能组合 A 2 x 1 A 2 x 1 A 2 x 1 A 2 x 1 a y 1 and z 0 c y 2 or x 1 34 130 a A 1 and B 0 c A 2 or x 1 35 130 条件组合覆盖是上述五种覆盖标准中最强的一种 然而 条件组合覆盖仍不能保证程序中所有可能的路径都被覆盖 本例中 满足条件组合覆盖标准的测试用例就没有经过sabce路径 36 130 路径覆盖 路径覆盖是指选择足够的测试用例 使得运行这些测试用例时 被测程序的每条可能执行到的路径都至少经过一次 如果程序中包含环路 则要求每条环路至少经过一次 37 130 本例中所有可能执行的路径有 L1 sabcde a为 t 且c为 t L2 sace a为 f 且c为 f L3 sacde a为 f 且c为 t L4 sabce a为 t 且c为 f a A 1 and B 0 c A 2 or x 1 38 130 路径覆盖实际上考虑了程序中各种判定结果的所有可能组合 但它未必能覆盖判定中条件结果的各种可能情况 因此 它是一种比较强的覆盖标准 但不能替代条件覆盖和条件组合覆盖标准 39 130 基本路径测试 在实际问题中 一个不太复杂的程序 特别是包含循环的程序 其路径数可能非常大 因此测试常常难以做到覆盖程序中的所有路径 为此 希望把测试的程序路径数压缩到一定的范围内 基本路径测试是TomMcCabe提出的一种白盒测试技术 这种方法首先根据程序或设计图画出控制流图 并计算其区域数 然后确定一组独立的程序执行路径 称为基本路径 最后为每一条基本路径设计一个测试用例 40 130 程序的控制流图 也称程序图 流图由结点和边组成 分别用圆和箭头表示 设计图中一个连续的处理框 对应于程序中的顺序语句 序列和一个判定框 对应于程序中的条件控制语句 映射成流图中的一个结点 设计图中的箭头 对应于程序中的控制转向 映射成流图中的一条边 对于设计图中多个箭头的交汇点可以映射成流图中的一个结点 空结点 41 130 上述映射的前提是设计图的判定中不包含复合条件 如果设计图的判定中包含了复合条件 那么必须先将其转换成等价的简单条件设计图 42 130 把流图中由结点和边组成的闭合部分称为一个区域 region 在计算区域数时 图的外部部分也作为一个区域 例如 右图所示的流图的区域数为3 独立路径是指程序中至少引进一个新的处理语句序列或一个新条件的任一路径 在流图中 独立路径至少包含一条在定义该路径之前未曾用到过的边 在基本路径测试时 独立路径的数目就是流图的区域数 43 130 例如 对一个PDL程序进行基本路径测试 该程序的功能是 最多输入N个值 以 999为输入结束标志 计算位于给定范围内的那些值 称为有效输入值 的平均值 以及输入值的个数和有效值的个数 44 130 45 130 其区域数为6 选取独立路径如下 路径1 1 2 10 11 13路径2 1 2 10 12 13路径3 1 2 3 10 11 13路径4 1 2 3 4 5 8 9 2 10 12 13路径5 1 2 3 4 5 6 8 9 2 10 12 13路径6 1 2 3 4 5 6 7 8 9 2 10 11 13为每一条独立路径设计测试用例 假设 n 5 minimum 0 maximum 100 46 130 路径1 1 2 10 11 13测试数据 value 90 999 0 0 0 预期结果 Average 90 total input 1 total valid 1路径2 1 2 10 12 13测试数据 value 999 0 0 0 0 预期结果 Average 999 total input 0 total valid 0路径3 1 2 3 10 11 13测试数据 value 1 90 70 1 80 预期结果 Average 80 total input 5 total valid 3 47 130 路径4 1 2 3 4 5 8 9 2 10 12 13测试数据 value 1 2 3 4 999 预期结果 Average 999 total input 4 total valid 0路径5 1 2 3 4 5 6 8 9 2 10 12 13测试数据 value 120 110 101 999 0 预期结果 Average 999 total input 3 total valid 0路径6 1 2 3 4 5 6 7 8 9 2 10 11 13测试数据 value 95 90 70 65 999 预期结果 Average 80 total input 4 total valid 4 48 130 值得注意的是 某些独立路径 如例中的路径1和路径3 不能以独立的方式进行测试 此时 这些路径必须在其他的独立路径测试中被覆盖 49 130 循环测试 循环分为4种不同类型 简单循环 嵌套循环 串接循环和非结构循环 1 简单循环按照下列规则设计测试用例 零次循环 从循环入口到出口 一次循环 检查循环初始值 二次循环 检查多次循环 m次循环 检查多次循环 最大次数循环 比最大次数多一次的循环 比最大次数少一次的循环 50 130 51 130 按照下列规则设计测试用例 先测试最内层循环 所有外层的循环变量置为最小值 最内层按简单循环测试 由里向外 测试上一层循环 测试时此层以外的所有外层循环的循环变量取最小值 此层以内的所有嵌套内层循环的循环变量取 典型 值 该层按简单循环测试 重复上一条规则 直到所有各层循环测试完毕 对全部各层循环同时取最小循环次数 或者同时取最大循环次数 2 嵌套循环 52 130 3 串接循环如果串接的各个循环互相独立 则可以分别用简单循环的方法进行测试 但如果第一个循环的循环变量与第二个循环控制相关 则两个循环不独立 此时 把第一个循环看作外循环 第二个循环看作内循环 然后用测试嵌套循环的办法来处理 4 非结构循环这类循环应先将其结构化 然后再测试 53 130 10 3黑盒测试 黑盒测试是依据软件的需求规约 而不考虑程序的内部结构与特性 检查程序的功能是否符合需求规约的要求 主要的黑盒测试方法有 等价类划分边界值分析比较测试错误猜测因果图 54 130 等价类划分 等价类划分方法将所有可能的输入数据划分成若干个等价类 然后在每个等价类中选取一个代表性的数据作为测试用例 等价类是指输入域的某个子集 该子集中的每个输入数据对揭露软件中的错误都是等效的 测试等价类的某个代表值就等价于对这一类其他值的测试 等价类划分方法把输入数据分为有效输入数据和无效输入数据 55 130 等价类划分设计测试用例的步骤 确定等价类根据软件的规格说明 对每一个输入条件 通常是规格说明中的一句话或一个短语 确定若干个有效等价类和若干个无效等价类 可使用如下表格 56 130 确定等价类的规则 1 如果输入条件规定了取值范围 则可以确定一个有效等价类 输入值在此范围内 和两个无效等价类 输入值小于最小值及大于最大值 例如 规定输入的考试成绩在0 100之间 则有效等价类是 0 成绩 100 无效等价类是 成绩 0 和 成绩 100 57 130 2 如果输入条件规定了值的个数 则可以确定一个有效等价类 输入值的个数等于规定的个数 和两个无效等价类 输入值的个数小于规定的个数和大于规定的个数 例如 规定输入构成三角形的3条边 则有效等价类是 输入边数 3 无效等价类是 输入边数 3 和 输入边数 3 58 130 3 如果输入条件规定了输入值的集合 即离散值 而且程序对不同的输入值做不同的处理 那么每个允许的值都确定为一个有效等价类 另外还有一个无效等价类 任意一个不允许的值 例如 规定输入的考试成绩为优 良 中 及格 不及格 则可确定5个有效等价类和一个无效等价类 59 130 4 如果输入条件规定了输入值必须遵循的规则 那么可确定一个有效等价类 符合此规则 和若干个无效等价类 从各个不同的角度违反此规则 例如 在Pascal语言中对变量标识符规定为 以字母开头的 串 那么有效等价类是 以字母开头的串 而无效等价类有 以数字开头的串 以标点符号开头的串 等 60 130 5 如果输入条件规定输入数据是整型 那么可以确定三个有效等价类 正整数 零 负整数 和一个无效等价类 非整数 6 如果输入条件规定处理的对象是表格 那么可以确定一个有效等价类 表有一项或多项 和一个无效等价类 空表 以上只是列举了一些规则 实际情况往往是千变万化的 在遇到具体问题时 可参照上述规则的思想来划分等价类 61 130 设计测试用例在确定了等价类之后 建立等价类表 列出所有划分出的等价类 并为每个有效等价类和无效等价类编号 62 130 边界值分析 边界值分析也是一种黑盒测试方法 是对等价类划分方法的补充 人们从长期的测试工作经验得知 大量的错误是发生在输入或输出范围的边界上 而不是在输入范围的内部 因此针对各种边界情况设计测试用例 其揭露程序中错误的可能性就更大 63 130 边界是指 相对于输入等价类和输出等价类而言 直接在其边界上 或稍高于其边界值 或稍低于其边界值的一些特定情况 使用等价类分析方法设计测试用例时 原则上 等价类中的任一输入数据都可作为该等价类的代表用作测试用例 而边值分析则是专门挑选那些位于边界附近的值 即正好等于 或刚刚大于 或刚刚小于边界的值 作为测试用例 64 130 边界值分析方法选择测试用例的规则如下 1 如果输入条件规定了值的范围 则选择刚刚达到这个范围的边界的值以及刚刚超出这个范围的边界的值作为测试输入数据 例如 规定输入的考试成绩在0 100之间 则取0 100 1 101作为测试输入数据 2 如果输入条件规定了值的个数 则分别选择最大个数 最小个数 比最大个数多1 比最小个数少1的数据作为测试输入数据 例如 规定一运动员的参赛项目至少1项 最多3项 则可选择参赛项目分别是1项 3项 0项 4项的测试输入数据 65 130 3 对每个输出条件使用第1条 例如 输出的金额值大于等于0且小于104 则选择使得输出金额分别为0 9999 1 10000的输入数据作为测试数据 4 对每个输出条件使用第2条 例如 规定输出的一张发票上 至少有1行内容 至多有5行内容 则选择使得输出发票分别有1行 5行 0行 6行内容的输入数据作为测试数据 5 如果程序的输入或输出是个有序集合 例如 顺序文件 表格 则应把注意力集中在有序集的第1个元素和最后一个元素上 66 130 6 如果程序中定义的内部数据结构有预定义的边界 例如 数组的上界和下界 则应选择使得正好达到该数据结构边界以及刚好超出该数据结构边界的输入数据作为测试数据 例如 程序中数组A的下界是10 上界是20 则可选择使得A的下标为10 20 9 21的输入数据作为测试数据 7 发挥你的智慧 找出其他可能的边界条件 由于边值分析方法所设计的测试用例更有可能发现程序中的错误 因此经常把边值分析方法与其它设计测试用例方法结合起来使用 67 130 比较测试 backtoback 有些软件有很高的可靠性要求 特别是那些可能危及人的生命安全的软件系统 需要冗余的硬件和软件来减少错误发生的可能性 通常 可由二支软件开发队伍 根据相同的需求规格说明分别开发二个软件版本 然后 用相同的测试用例对二个版本的软件分别进行测试 比较二个版本软件的测试结果 如果测试结果相同 则可认为二个版本的软件都是正确的 如果测试结果不同 则要分析各个版本 以发现错误的所在 此测试称为比较测试 68 130 值得注意的是 比较测试并不能保证软件没有错误 如果规格说明本身有错 那么所有的版本都可能反映这种错误 另外 如果各个版本产生相同的但都不正确的结果 那么比较测试也无法发现这种错误 69 130 错误推测法 错误猜测是一种凭直觉和经验推测某些可能存在的错误 从而针对这些可能存在的错误设计测试用例的方法 这种方法没有机械的执行步骤 主要依靠直觉和经验 错误猜测法的基本思想是 列举出程序中所有可能的错误和容易发生错误的特殊情况 然后根据这些猜测设计测试用例 70 130 因果图 在等价类划分方法和边界值方法中未考虑输入条件的各种组合 当输入条件比较多时 输入条件组合的数目会相当大因果图方法是一种帮助人们系统地选择一组高效测试用例的方法 它既考虑了输入条件的组合关系 又考虑了输出条件对输入条件的依赖关系 即因果关系 其测试用例发现错误的效率比较高 71 130 因果图方法的特点是 考虑输入条件的组合关系 考虑输出条件对输入条件的依赖关系 即因果关系 测试用例发现错误的效率高 能检查出功能说明中的某些不一致或遗漏 72 130 用因果图设计测试用例的步骤 1 分割功能说明书将输入条件分成若干组 然后分别对每个组使用因果图 这样可减少输入条件组合的数目 2 识别 原因 和 结果 并加以编号原因是指输入条件或输入条件的等价类 结果是指输出条件或系统变换 每个原因和结果都对应于因果图中的一个结点 当原因或结果成立 或出现 时 相应的结点的值为1 否则为0 73 130 3 根据功能说明中规定的原因与结果之间的关系画出因果图因果图的基本符号如下 图中左边的结点表示原因 右边的结点表示结果 或 与 74 130 原因和结果之间的关系有 恒等 若a 1 则b 1 若a 0 则b 0非 若a 1 则b 0 若a 0 则b 1或 若a 1或b 1或c 1 则d 1 否则d 0与 若a b c 1 则d 1 否则d 0画因果图时原因在左 结果在右 由上向下排列 并根据功能说明中规定的原因和结果之间的关系 用上述符号连接起来 必要时还可以引入一些中间结点 75 130 4 根据功能说明在因果图中加上约束条件因果图的约束条件如下图所示 要求 76 130 图中互斥 包含 唯一 要求是对原因的约束 屏蔽是对结果的约束互斥 表示a b c中至多只有一个为1 即不同时为1包含 表示a b c中至少有一个为1 即不同时为0唯一 表示a b c中有且仅有一个1要求 表示若a 1 则要求b必须为1 即不可出现a 1且b 0屏蔽 表示若a 1 则b必须为0 即不可出现a 1且b 1 77 130 5 根据因果图画出判定表列出满足约束条件的所有原因组合 写出每种原因组合下的结果 如有的话 6 为判定表的每一列设计一个测试用例 78 130 例如 有一个处理单价为5角钱的饮料自动售货机软件 其规格说明如下 饮料自动售货机允许投入5角或1元的硬币 用户可通过 橙汁 和 啤酒 按钮选择饮料 售货机还装有一个表示 零钱找完 的指示灯 当售货机中有零钱找时指示灯暗 当售货机中无零钱找时指示灯亮 当用户投入5角硬币并押下 橙汁 或 啤酒 按钮后 售货机送出 橙汁 或 啤酒 当用户投入1元硬币并押下 橙汁 或 啤酒 按钮后 如果售货机有零钱找 则送出相应的饮料 并退还5角硬币 如果售货机没有零钱找 则饮料不送出 并且退还1元硬币 79 130 分析规格说明 列出原因和结果规格说明中的红色部分是输入条件 原因 蓝色部分是输出条件 结果 由于 售货机有零钱找 是在投入1元硬币时判断是否能找零钱的依据 也可把它看作是一个输入条件 即原因 与之对应的结果是售货机指示灯亮 或暗 原因结果 售货机有零钱找 21 售货机 零钱找完 灯亮 投入1元硬币 22 退还1元硬币 投入5角硬币 23 退还5角硬币 押下 橙汁 按钮 24 送出 橙汁 饮料 押下 啤酒 按钮 25 送出 啤酒 饮料 80 130 2 画出因果图 所有原因结点列在左边 所有结果结点列在右边 其中中间结点的含义如下 11 投入1元硬币且押下饮料按钮 12 押下 橙汁 或 啤酒 按钮 13 应找5角硬币且售货机有零钱找 14 钱已付清 81 130 3 由于原因2与3 4与5不能同时发生 分别加上约束条件E 4 根据因果图画出判定表 5 根据判定表设计测试用例 82 130 83 130 10 4测试策略 一种测试策略就是将测试分为单元测试 集成测试 确认测试和系统测试 单元测试是针对程序中的模块或构件 主要揭露编码阶段产生的错误 集成测试针对集成的软件系统 主要揭露设计阶段产生的错误 确认测试是根据软件需求规约对集成的软件进行确认 主要揭露不符合需求规约的错误 对于基于计算机系统中的软件 还需将它集成到基于计算机系统中 并进行系统测试 以揭露不符合系统工程中对软件要求的错误 84 130 V模型 描述软件开发各阶段与测试策略之间的对应关系 85 130 单元测试 UnitTesting 单元测试又称模块测试 它着重对软件设计的最小单元 软件构件或模块 进行验证单元测试根据设计描述 对重要的控制路径进行测试 以发现构件或模块内部的错误单元测试通常采用白盒测试 并且多个构件或模块可以并行进行测试这里将构件或模块统一称为模块 86 130 1 单元测试的内容 模块接口 确保模块的输入 输出参数信息是正确的 包括参数的个数 次序 类型等 局部数据结构 确保临时存储的数据在算法执行的过程中都能维持其完整性 如不合适的类型说明 不同数据类型的比较或赋值 文件打开和关闭的遗漏 超越数据结构的边界等 边界条件 确保程序单元在极限或严格的情况下仍能正确地执行 87 130 2 单元测试过程 单元测试通常与编码工作结合起来进行 模块本身不是一个独立的程序 在测试模块时 必须为每个被测模块开发一个驱动 driver 程序和若干个桩 stub 模块 88 130 驱动模块接收测试数据 调用被测模块 把测试数据传送给被测模块 被测模块执行后 驱动模块接收被测模块的返回数据 并打印相关结果 驱动程序的程序结构如下 数据说明 初始化 输入测试数据 调用被测模块 输出测试结果 停止 89 130 桩模块的功能是替代被被测模块调用的模块 它接受被测模块的调用 验证入口信息 把控制连同模拟结果返回给被测模块 桩模块的程序结构如下 数据说明 初始化 输出提示信息 表示进入了哪个桩模块 验证调用参数 打印验证结果 将模拟结果送回被测程序 返回 90 130 集成测试 IntegratedTesting 集成测试也称组装测试 联合测试经单元测试后 每个模块都能独立工作 但把它们放在一起往往不能正常工作 91 130 主要问题在于 数据可能在通过接口时丢失 一个模块可能对另一个模块产生产生非故意的 有害的影响 即副作用 当子功能被组合起来时 可能不能达到期望的主功能 单个模块可以接受的不精确性 如误差 连接起来后可能会扩大到无法接受的程度 全局数据结构可能会存在问题 92 130 集成的方式有两种 非增量式集成 先将所有经过单元测试的模块组合在一起 然后对整个程序 作为一个整体 进行测试 这种测试在发现错误时 很难为错误定位 增量式集成 根据程序结构图 按某种次序挑选一个 或一组 尚未测试过的模块 把它集成到已测试好的模块中一起进行测试 每次增加一个 或一组 模块 直至所有模块全部集成到程序中 在增量集成测试过程中发现的错误 往往与新加入的模块有关 93 130 增量式集成又可分为自顶向下集成和自底向上集成 自顶向下集成 从主控模块 主程序 开始 然后按照程序结构图的控制层次 将直接或间接从属于主控模块的模块按深度优先或广度优先的方式逐个集成到整个结构中 并对其进行测试 94 130 深度优先测试次序 M1 M2 M5 M8 M6 M3 M7 M4广度优先测试次序 M1 M2 M3 M4 M5 M6 M7 M8 95 130 自顶向下集成的步骤 主控模块 主程序 被直接用作驱动程序 所有直接从属于主控模块的模块用桩模块替换 然后对主控模块进行测试 根据集成的实现方式 下层的桩模块一次一个地替换成真正的模块 从属于该模块的模块用桩模块替换 然后对其进行测试 用回归测试来保证没有引入新的错误 重复第 2 和第 3 步 直至所有模块都被集成 96 130 自顶向下集成的优点 不需要驱动模块 能尽早对程序的主要控制和决策机制进行检验 能较早发现整体性的错误 深度优先的自顶向下集成能较早对某些完整的程序功能进行验证 自顶向下集成的缺点 测试时低层模块用桩模块替代 不能反映真实情况 重要数据不能及时回送到上层模块 97 130 自底向上集成 从程序结构的最底层模块 即原子模块 开始 然后按照程序结构图的控制层次将上层模块集成到整个结构中 并对其进行测试 自底向上集成在测试一个模块时 它的下层模块 已测试过 可用作它的桩模块 98 130 自底向上集成的步骤 将低层模块组合成能实现软件特定功能的簇 为每个簇编写驱动程序 并对簇进行测试 移走驱动程序 用簇的直接上层模块替换驱动程序 然后沿着程序结构的层次向上组合新的簇 凡对新的簇测试后 都要进行回归测试 以保证没有引入新的错误 重复第 步至第 步 直至所有的模块都被集成 99 130 100 130 自底向上集成的优点 不需要桩模块 所以容易组织测试 将整个程序结构分解成若干个簇 对同一层次的簇可并行进行测试 可提高效率 自底向上集成的缺点 整体性的错误发现得较晚 101 130 策略的选择自顶向下集成测试与自底向上集成测试各有优缺点 将这两种策略组合起来可能是一种最好的折衷 其策略是 在程序结构的高层使用自顶下向策略 而在低层则使用自底向上策略 集成测试时应特别关注关键模块的测试 关键模块是指具有下列一个或多个特征的模块 与多个软件需求有关 含有高层控制 位于程序结构的高层 本身是复杂的或是容易出错的 含有确定的性能需求 关键模块应尽早测试 回归测试时也应集中在关键模块的功能上 102 130 回归测试 RegressionTesting 在集成测试过程中 每当增加一个新模块时 原先已集成的软件就发生了改变 新的数据流路径被建立 新的I O操作可能出现 还可能激活新的控制逻辑 这些改变可能使原本正常的功能产生错误 当测试时发现错误后 需修改程序 或者在软件维护时也需修改程序 这些对程序的修改也可能使原本正常的功能产生错误 回归测试是对已进行过的测试的子集的重新执行 以确保对程序的改变和修改 没有传播非故意的副作用 103 130 确认测试 ValidationTesting 确认测试标准确认测试以软件需求规约为依据 以发现软件与需求不一致的错误 主要检查软件是否实现了规约规定的全部功能要求 文档资料是否完整 正确 合理 其他的需求 如可移植性 可维护性 兼容性 错误恢复能力等是否满足 104 130 确认测试的结果可分为两类 满足需求规约要求的功能或性能特性 用户可以接受 发现与需求规约有偏差 此时需列出问题清单 105 130 软件配置评审软件配置评审也称软件审计 其目的是保证软件配置的所有成分都齐全 各方面的质量都符合要求 具有维护阶段必需的细节 而且已经编排好分类目录 软件配置主要包括计算机程序 源代码和可执行程序 针对开发者和用户的各类文档 包含在程序内部或程序外部的数据 106 130 测试是由一个用户在开发者的场所进行的 软件在开发者对用户的 指导下 进行测试 经 测试后的软件称为 版软件 测试是由软件的最终用户在一个或多个用户场所进行的 开发者通常不在测试现场 测试是软件在一个开发者不能控制的环境中的 活的 应用 用户记录所有在 测试中遇到的问题 并定期把这些问题报告给开发者 在接到 测试的问题报告后 开发者对软件进行最后的修改 然后着手准备向所有的用户发布最终的软件产品 测试和 测试 107 130 系统测试 SystemTesting 系统测试是对整个基于计算机的系统进行的一系列测试 系统测试的种类很多 每种测试都有不同的目的 它们从不同的角度测试计算机系统是否被正常地集成 并完成相应的功能 常用的系统测试包括 恢复测试 recoverytesting 安全测试 securitytesting 压力测试 stresstesting 性能测试 performancetesting 108 130 恢复测试 recoverytesting 恢复测试是通过各种手段 强制软件发生故障 然后来验证系统能否在指定的时间间隔内恢复正常 包括修正错误并重新启动系统 如果恢复是由系统自身来完成的 那么 需验证重新初始化 检查点机制 数据恢复和重启动等的正确性 如果恢复需要人工干预 那么要估算平均修复时间MTTR meantimetorepair 是否在用户可以接受的范围内 109 130 安全测试 securitytesting 安全测试用来验证集成在系统中的保护机制能否实际保护系统不受非法侵入 在安全测试过程中 测试者扮演一个试图攻击系统的角色 采用各种方式攻击系统 例如 截取或码译密码 借助特殊软件攻击系统 故意导致系统失效 企图在系统恢复之机侵入系统等等 一般来说 只要有足够的时间和资源 好的完全测试一定能最终侵入系统 系统设计者的任务是把系统设计成 攻破系统所付出的代价大于攻破系统后得到信息的价值 110 130 压力测试 stresstesting 压力测试也称强度测试 它是在一种需要非正常数量 频率或容量的方式下执行系统 其目的是检查系统对非正常情况的承受程度 如 当系统的中断频率是每秒1或2个时 执行每秒10个中断的测试用例将输入数据的数量提高一个数量级来测试输入功能如何响应执行需要最大内存或其它资源的测试用例执行可能导致大量磁盘驻留数据的测试用例 111 130 性能测试 performancetesting 性能测试用来测试软件在集成的系统中的运行性能 它对实时系统和嵌入式系统尤为重要 性能测试可以发生在测试过程的所有步骤中单元测试时 主要测试一个独立模块的性能 如算法的执行速度 软件集成后 进行软件整体的性能测试 计算机系统集成后 进行整个计算机系统的性能测试 性能测试常常需要与压力测试结合起来进行 而且常常需要一些硬件和软件测试设备 以监测系统的运行情况 112 130 10 5面向对象测试 面向对象软件的测试目标仍然是用最少时间和工作量来发现尽可能多的错误但面向对象软件的性质改变了测试的策略和测试战术 面向对象软件的测试也给软件工程师带来新的挑战 113 130 面向对象语境对测试的影响 继承 封装 多态性 基于消息的通信等概念都是面向对象软件的重要特征 它们对面向对象测试有很大的影响 单元适用于面向对象测试的两种单元定义单元是可以编译和执行的最小软件部件单元是决不会指派给多个设计人员开发的软件部件类是面向对象软件中的单元 114 130 封装 因属性和操作被封装在类中 故测试时很难获得对象的某些具体信息 而给测试带来困难 继承 测试了父类的操作后 并不表示其子类就不必对继承的操作进行测试 多态性在测试时 应覆盖反映多态的所有实现方法 基于消息的通信 面向对象软件是通过消息通信来实现类之间的协作 它们没有明显的层次控制结构 因此 传统的自顶向下和自底向上集成策略不适用于面向对象软件测试 115 130 面向对象的测试策略 把类作为面向对象软件的单元 传统的单元测试等价于面向对象中的类测试 也称类内测试 它包括类内的方法测试和类的行为测试 面向对象中的类间测试相当于面向对象的集成测试 它有两种集成策略 基于线程的测试 集成一组互相协作的类来响应系统的一个输入或事件 每个线程逐一被集成和测试 并通过回归测试保证其没有产生副作用 116 130 面向对象的确认测试和系统测试策略与传统的确认测试和系统测试策略相同 在面向对象确认测试时 应该利用用况模型 通过用况提供的场景来发现与用户需求不一致的错误 基于使用的测试 按使用层次来集成系统 把那些几乎不使用其他类提供的服务的类称为独立类 把使用类的类称为依赖类 集成从测试独立类开始 然后集成直接依赖于独立类的那些类 并对其测试 按照依赖的层次关系 逐层集成并测试 直至所有的类被集成 117 130 面向对象测试用例设计 传统的测试用例设计方法及其思想在面向对象测试中仍是可用的 类内测试测试类中的每个操作 相当于传统软件中的函数或子程序 通常采用白盒测试方法 如逻辑覆盖 基本路径覆盖 数据流测试 循环测试等 测试类的行为 通常用状态机图来描述 利用状态机图进行类测试时 可考虑覆盖所有状态 所有状态迁移等覆盖标准 也可考虑从初始状态到终止状态的所有迁移路径的覆盖 118 130 划分测试 与等价类划分方法相似 它将输入和输出分类 并设计测试用例来处理每个类别 划分的方式有多种 基于状态的划分是根据操作改变类状态的能力对操作分类 基于属性的划分是根据使用的属性对操作分类 如使用属性a的操作 修改属性a的操作 既不使用又不修改属性a的操作 基于类别的划分是根据操作的种类对类操作分类 如初始化操作 计算操作 查询操作 终止操作 119 130 类间测试类间测试主要测试类之间的交互和协作 在UML中通常用顺序图和通信图来描述对象之间的交互和协作 可以根据顺序图或通信图 设计作为测试用例的消息序列 来检查对象之间的协作是否正常 基于场景的测试场景是用况的实例 它反映了用户对系统功能的一种使用过程 基于场景的测试主要用于确认测试 在类间测试时也可根据描述对象间的交互场景来设计测试用例 120 130 10 6测试完成的标准 因为无法判定当前查出的错误是否是最后一个错误 所以决定什么时候停止程序测试就成了最困难的问题 但是测试最后一定要停止的 几种实用的测试完成标准 Musa和Ackerman提出了一个基于统计标准的答复 不 我们不能绝对地认定软件永远也不会再出错 但是相对于一个理论上合理的和在试验中有效的统计模型来说 如果一个在按照概率的方法定义的环境中 1000个CPU小时内不出错运行的概率大于0 995的话 那么我们就有95 的信心说 我们已经进行了足够的测试 121 130 使用指定的测试用例设计方法产生测试用例 运行这些测试用例均未发现错误 包括发现错误后已被纠正的情况 则测试可终止 观察测试阶段中单位时间内发现错误数目的曲线 122 130 10 7调试 Debugging 测试的目的是发现错误 调试 也称排错 的目的是确定错误的原因和准确位置 并加以纠正调试过程 123 130 124 130 调试方法 蛮力法蛮力法是一种最省脑筋但又最低效的方法 它通过在程序中设置断点 输出寄存器 存储器的内容 打印有关变量的值等手段 获取大量现场信息 从中找出错误的原因 这种方法效率低 输出的信息大多是无用的 通常在其他调试方法未能找到错误原因时 才使用这种方法 可以采用二分法来逐步缩小出错的范围 125 130 回溯法回溯法是从错误的征兆出发 人工沿着控制流程往回跟踪 直至发现错误的根源 这种方法适用于小型程序 对大型程序 由于回溯的路径太多 难以彻底回溯 原因排除法原因排除法又可分为归纳法和演绎法 126 130 归纳法是一种从特殊推断一般的系统化思考方法 其基本思想是 从一些线索 错误征兆 着手 通过分析它们之间的关系来找出错误的原因 127 130 演绎法演绎法从一般原理或前提出发 假设所有可能出错的原因 排除不可能正确的假设 最后推导出结论 128 130 纠正错误修改一个错误常常会引入新的错误 在为纠正某个错误而修改程序之前应该回答三个问题 在程序的其他地方是否也存在同类的错误 本次修改可能会引发什么新的错误 为了防止这个错误 我们应该做什么 129 130 教学小结 软件测试是保证软件质量的重要手段 也是软件人员必须掌握的重要技术 本章在介绍软件测试的目的 基本原则以及白盒测试和黑盒测试概念的基础上 详细介绍各种白盒测试方法 包括逻辑覆盖测试 逻辑表达式错误敏感测试 基本路径测试 数据流测试和循环测试 和黑盒测试方法 包括等价类划分 边界值分析 比较测试 错误猜测和因果图 然后 介绍各种测试策略 包括单元测试 集成测试 确认测试和系统测试 对面向对象测试只作简单的介绍 最后介绍测试完成标准和几种常用的调试方法 130 130 作业 教材P301的习题 预习实验指导书的软件测试工具与单元测试的实验内容