《软件测试》PPT课件.ppt_第1页
《软件测试》PPT课件.ppt_第2页
《软件测试》PPT课件.ppt_第3页
《软件测试》PPT课件.ppt_第4页
《软件测试》PPT课件.ppt_第5页
已阅读5页,还剩83页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试 第八章 8 1软件测试的基本概念 一 软件测试的目的和重要性因为开发工作的前期不可避免地会引入错误 测试的目的是为了发现和改正错误 这对于某些涉及人的生命安全或重要的军事 经济目标的项目显得尤其重要 软件测试是软件开发过程中保证软件质量 提高软件可靠性的最主要的手段之一 是在软件产品交互用户使用之前 对分析 设计 编码等开发工作的最后检查和复审 及时发现并校正错误 测试的根本目的就是发现尽可能多的缺陷 测试 测试由测试员完成 调试 调试由程序员完成 1963年美国飞往火星的火箭爆炸 原因是FORTRAN程序 DO5I 1 3误写为 DO5I 1 3损失1000万美元 1967年苏联 联盟一号 宇宙飞船返回时因忽略一个小数点 在进入大气层时打不开降落伞而烧毁 测试的目标以最小的工作量和成本 尽可能多地发现软件系统中潜在的各种错误和缺陷 以确保软件系统的正确性和可靠性 二 软件测试的特点 1 软件测试的开销大按照Boehm的统计 软件测试的开销大约占总成本的30 50 例如 APPOLLO登月计划 80 的经费用于软件测试 3 软件测试难度大根据上述分析 既然不能进行 穷举 测试 又要查出尽可能多的错误 软件测试工作的难度大 只有选择 高效的测试用例 什么是 高效的测试用例 如何选择 高效的测试用例 这就是本章讨论的主要问题 三 软件测试的基本原则 1 应尽早地和不断地进行软件测试 2 尽量不由程序设计者进行测试 采用独立测试 开发者总以为程序正确开发者对程序功能 接口十分熟悉 使用不会出错开发者对程序的珍爱心理3 关键是注重测试用例的选择 输入数据的组成 输入数据 预期的输出结果 既有合理输入数据 也有不合理的输入数据 用例既能检查应完成的任务 也能够检查不应该完成的任务 长期保存测试用例 测试用例的质量可以由以下四个特性来描述 有效性 能否发现软件缺陷或至少可能发现软件缺陷 可仿效性 可仿效的测试用例可以测试多项内容 从而减少测试用例数量 经济性 测试用例的执行分析和排错是否经济 修改性 每次软件修改后对测试用例的维护成本 四个特性之间会有影响 如可仿效性有可能导致经济性和修改性较低 因此 通常情况下 应对上述四个特性进行一定的权衡折衷 4 充分注意测试中的群集现象 群集现象是指 在测试过程中 发现错误比较集中的程序段 往往可能残留的错误数较多 因此必须注意这种群集现象 对错误群集的程序段进行重点测试 以提高测试投资的效率 5 避免测试的随意性 制定详细 完善的测试计划 包括测试范围 测试方式 测试成本 测试工作量 测试时间等 严格执行测试计划 6 全面检查每一个测试结果 7 妥善保管测试过程中的一切文档 为软件维护提供方便 测试计划 测试用例 测试结果 出错统计等都是软件测试的重要文档 另外 Davis也提出了一组测试原则 在设计有效地测试用例时必须理解 所有的测试都应根据用户的需求来进行 应该在测试工作真正开始前的较长时间内就进行测试计划 测试规划 一般而言 测试计划可以在需求分析完成后开始 详细的测试用例定义可以在设计模型被确定后立即开始 因此 所有测试可以在任何代码被编写前进行计划和设计 Pareto原则应用于软件测试 Pareto原则意味着测试发现的错误80 的很可能集中在20 的程序模块中 测试应从 小规模 开始 逐步转向 大规模 即从模块测试开始再进行系统测试 穷举测试是不可能的 因此 在测试中不可能覆盖路径的每一个组合 然而 充分覆盖程序逻辑 确保覆盖程序设计中使用的所有条件是有可能的 为达到最佳的测试效果 提倡由第三方来进行测试 四 软件测试的过程 软件测试的过程图 测试的基本步骤 模块测试 整体测试 功能测试 预测试 系统测试 验收测试 安装测试 概要设计审查 详细设计审查 代码审查 测试 单元测试 组装测试 有效性测试 确认测试 软件测试文档 1 测试计划2 测试规范3 测试用例4 缺陷报告 3 软件测试文档 模块测试报告至少选择一个典型模块进行测试 A 综合测试策略 静态分析 白盒法为主 辅以黑盒法 B 测试情况 根据覆盖标准列出 C 测试用例 保留 D 查错记录 数量 位置 分析结果 组装测试报告A 组装次序 测试方法 以黑盒法为主 B 测试情况C 测试用例 保留 D 查错记录 数量 位置 分析结果 功能测试与系统测试与上类似 8 2软件测试方法 软件测试方法分为两类 静态分析 动态测试 一 静态分析方法指以人工的 非形式化的方法对程序进行分析和测试 并不运行程序 桌前检查 DeskChecking 由程序员检查自己的程序 对源代码进行分析 检验 代码会审 CodeReadingReview 由程序员和测试员组成评审小组 按照 常见的错误清单 进行会议讨论检查 步行检查 Walkthroughs 最常用的静态分析方法 与代码会审类似 也要进行代码评审 但评审过程主要采取人工执行程序的方式 故也称为 走查 调用图 无论Y为何值 都不能够调用子程序 READY Y 0 N X Y X 0 Y N Y 调用子程序 A B C D E 即执行ABC后 是不可能执行路径CDE的 步行检查时 还常使用以下分析方法 调用图从语义的角度考察程序的控制路线 数据流分析图检查分析变量的定义和引用情况 数据流分析图 节点 表示单个语句 有向边 表示控制结构 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 只定义不用未定义引用连续定义 二 动态测试方法 1 通过选择适当的测试用例 执行程序 常用的方法 1 白盒法又称结构测试 逻辑驱动测试或基于程序的测试 分析程序的内部逻辑结构 注意选择适当的覆盖标准 设计测试用例 对主要路径进行尽可能多的测试 2 黑盒法又称功能测试 数据驱动测试或基于规格说明的测试 是一种从用户观点出发的测试 不考虑程序的内部结构与特性 只根据程序功能或程序的外部特性设计测试用例 白盒法 白盒法又称为逻辑覆盖法 因为要以程序 模块 内部的逻辑结构为基础来设计测试用例 主要用于单元测试 测试的关键也是如何选择高效的测试用例 其测试用例选择 是按照不同覆盖标准确定的 发现错误能力 语句覆盖 选择足够的测试用例 使得程序中每个语句至少都能被执行一次 判定覆盖 执行足够的测试用例 使得程序中每个判定至少都获得一次 真 值和 假 值 每个分支 条件覆盖 执行足够的测试用例 使得判定中的每个条件获得各种可能的结果 至少满足一次 判定 条件覆盖 执行足够的测试用例 使得判定中每个条件取到各种可能的值 并使每个判定取到各种可能的结果 条件组合覆盖 执行足够的例子 使得每个判定中条件的各种可能组合都至少出现一次 白盒法常用的覆盖标准 白盒法步骤 例 用白盒法测试以下程序段 Procedure VARA B X REAL BEGINIF A 1 AND B 0 THENX X A IF A 2 OR X 1 THENX X 1END 1 选择逻辑覆盖标准 2 按照覆盖标准列出所有情况 3 选择确定测试用例 4 验证分析运行结果与预期结果 逻辑结构 1 语句覆盖 使得程序中每个执行语句至少都能被执行一次 A 1ANDB 0 X X A A 2ORX 1 X X 1 a b c d e 满足语句覆盖的情况 执行路径 ace 选择用例 2 0 4 2 0 3 用例格式 输入 A B X 输出 A B X Y N Y N 2 判定覆盖 使得程序中每个判定至少为TRUE或FALSE各一次 A 1ANDB 0 X X A A 2ORX 1 X X 1 a b c d e 覆盖情况 应执行路径ace abd或 acd abe 选择用例 其一 2 0 4 2 0 3 ace 1 1 1 1 1 1 abd 2 1 1 2 1 2 abe 3 0 3 3 1 1 acd Y Y N N 3 条件覆盖 A 1ANDB 0 X X A A 2ORX 1 X X 1 a b c d e 使得判定中的每个条件获得各种可能的结果 应满足以下覆盖情况 判定一 A 1 A 1 B 0 B 0判定二 A 2 A 2 X 1 X 1 选择用例 2 0 4 2 0 3 1 1 1 1 1 1 N N Y Y 2 A 1 A 2 0 B 0 4 X 1 1 A 1 A 2 1 B 0 1 X 1 注意 1 0 3 1 0 4 2 1 1 2 1 2 满足条件覆盖 但不满足判定覆盖 4 判定 条件覆盖 同时满足判断覆盖和条件覆盖 A 1ANDB 0 X X A A 2ORX 1 X X 1 a b c d e 应满足以下覆盖情况 条件 A 1 A 1 B 0 B 0A 2 A 2 X 1 X 1应执行路径ace abd或 acd abe 选择用例 2 0 4 2 0 3 ace 1 1 1 1 1 1 abd Y Y N N 5 条件组合覆盖 使得每个判定中条件的各种可能组合都至少出现一次 A 1 X X A A 2 X X 1 a b c d e B 0 X 1 Y N Y N Y N Y N 编译系统下的执行情况 部分路径未被执行 满足以下覆盖情况 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 1 选择用例 2 0 4 2 0 3 2 1 1 2 1 2 1 0 3 1 0 4 1 1 1 1 1 1 二 动态测试方法 2 等价分类法 边值分析法 错误推测法 因果图法 2 黑盒法不考虑程序的内部结构与特性 只根据程序功能或程序的外部特性设计测试用例 黑盒测试法注重于测试软件的功能需求 主要试图发现下列几类错误 功能不对或遗漏 性能错误 初始化和终止错误 界面错误 数据结构或外部数据库访问错误 1 等价分类法 基本思想 根据程序的I O特性 将程序的定义域划分为有限个等价区段 等价类 从等价类中选择出的用例 具有 代表性 等价类分为 有效等价类 对于程序的规格说明 是合理的 有意义的输入数据构成的集合 无效等价类 对于程序的规格说明 是不合理的 没有意义的输入数据构成的集合 等价分类法步骤 应按照输入条件 如输入值的范围 值的个数 值的集合 输入条件必须如何 划分为有效等价类和无效等价类 例如 每个学生可选修1 3门课程可以划分一个有效等价类 选修1 3门课程 可以划分两个无效等价类 未选修课 选修课超过3门 划分 等价类 显然 关键是如何划分等价类 A为每个等价类编号 B使一个测试用例尽可能覆盖多个有效等价类C特别要注意 一个测试用例只能覆盖一个无效等价类 选择测试用例 等价分类法步骤 2 边值分析法 基本思想 选择等价类的边缘值作为测试用例 让每个等价类的边界都得到测试 选择测试用例既考虑输入亦考虑输出 分析步骤 A先划分等价类 B选择测试用例 测试等价类边界 边界选择原则 A按照输入值范围的边界 B按照输入 输出值个数的边界 C输出值域的边界 D输入 输出有序集的边界 A按照输入值范围的边界 例如 输入值的范围是 1 0至1 0 则可选择用例 1 0 1 0 1 001 1 001 B按照输入 输出值个数的边界 例如 输入文件可有1 255个记录 则设计用例 文件的记录数为0个 1个 255个 256个 C输出值域的边界 例如 检索文献摘要 最多4篇 设计用例 可检索0篇 1篇 4篇 和5篇 错误 D输入 输出有序集 如顺序文件 线性表 的边界 应选择第一个元素和最后一个元素 边值分析法举例 黑盒法应用实例 对FORTRAN编译系统中的DIMENSION语句进行测试 语句格式为 DIMENSIONad ad ad为数组描述符 形式为n d 其中 n 数组名 字母打头的字母数字串 长6 D为界偶 1 7个 ld ndld和nd的值为1 65535 ld缺省为1 40个等价类 3 错误推测法 凭经验或直觉推测可能的错误 列出程序中可能有的错误和容易发生错误的特殊情况 选择测试用例 把输入条件视为 因 把输出条件视为 果 将黑盒看成是从因到果的网络图 采用逻辑图的形式来表达功能说明书中输入条件的各种组合与输出的关系 根据这种关系可选择高效的测试用例 因果图是一种形式化语言 是一种组合逻辑网络图 因果图法的基本原理是通过因果图 把自然语言描述的功能说明转换为判定表 然后为判定表的每一列设计一个测试用例 4 因果图法 causeeffectgraphics 因果图的基本符号0 表示 不出现 1 表示 出现 恒等若a为1 则b为1 否则b为0 非 函数若a为1 则b为0 否则b为1 或 函数若a或b为1 则d为1 否则d为0 与 函数若a与b同为1 则d为1 否则d为0 对 与 或 函数的限制符号 E约束 异 排斥即a b不能同时为1 I约束 或 包容a b c不能同时为0 O约束 唯一 选一a b中仅有一个为1 R约束 要求 需要a为1时 b必须为1M约束 强制 屏蔽若a为1时 则b强制为1 a b E a b c I a b R a b O a b M 因果图法的步骤 分析规范 即将问题分为若干可工作的步骤 标识出规范中的原因与结果 原因 输入条件结果 输出或系统变换 将因果图转换为有限项判断表 将判断表的每一列 转换为一个测试用例 分析规范语义 内容 转换为因果图 因果图法应用举例 规范 文件名第一列字符必须为A或B 第二列字符必须为数字 满足则修改文件 第一字符不正确发出信息X12 第二个字符不正确发出信息X13 1 分析规范原因结果1 第一列字符为A50 修改文件2 第一列字符为B51 发信息X123 第二列字符为数字52 发信息X13 2 画出因果图 中间结点是导出结果的进一步原因 考虑到原因1 2不可能同时为1 加上E约束 11 3 将因果图转换为判断表 11 51 50 52 白盒测试与黑盒测试两类方法的对比 条件组合覆盖 等价分类法边界值分析法错误推测法因果图法 8 3软件测试的步骤 测试步骤及策略所有测试过程都应采用综合测试策略 即先作静态分析 再作动态测试 并事先制订测试计划 测试过程通常可分4步进行 一 模块测试 ModuleTesting 1 测试内容 模块 模块接口测试 局部数据结构测试 重要路径测试 错误处理测试 边界条件测试 I O参数值的个数 类型 次序 格式是否正确 I O文件属性 操作是否正确等 数据说明是否正确 一致 变量及其初值定义是否正确等 检查 错误处理程序 本身的错误 边界条件常包括循环边界 最大最小值 控制流中等于 大于 小于的比较值等 重要路径通常是指完成模块功能的主要路径 一般是控制结构 也称单元测试 unittesting 以白盒法为主 2 模块测试步骤 考虑到被测模块与其它模块的联系 因此测试时需要使用两类辅助模块来模拟其他模块 驱动模块 driver 模拟主程序功能 用于向被测模块传递数据 接收 打印从被测模块返回的数据 桩模块 stub 又称为假模块 用于模拟那些由被测模块所调用的下属模块功能 一般 驱动模块比桩模块容易设计 但都是额外开销 测试方法以白盒法为主 被测模块 驱动模块 桩模块 桩模块 桩模块 二 组装测试 IntegrationTesting 1 组装测试的任务 确定模块组装方案 将经过测试的模块组装为一个完整的系统 组装方案分为渐增式及非渐增式 测试方法以黑盒法为主 按照组装方案进行测试 也称为联合测试或集成测试 重点测试模块的接口部分 需设计测试过程使用的驱动模块或桩模块 问题 渐增式与非渐增式各有何优 缺点 为什么通常采用渐增式 2 渐增式组装测试 渐增式是先进行模块测试 然后将这些模块逐步组装成较大的系统 每连接一个模块进行一次测试 两种方案 设计驱动模块或桩模块 对每一个新组装的子系统进行测试 对发现问题较多的子系统或模块应该用白盒法作回归测试 自顶而下增值自底而上增值 自顶而下增值 M1 M4 M3 M2 M6 M5 程序模块示意图 S5 M1 S1 S1 S1 S2 S2 S2 S3 S3 S3 第一步 测试主控模块M1设计桩模块S1 S2 S3 模拟被M1调用的M2 M3 M4 M2 M3 M4 第二步 依次用M2 M3 M4替代桩模块S1 S2 S3 每替代一次进行一次测试 S4 S4 S4 S5 S5 第三步 对由主控模块M1和模块M2 M3 M4构成的子系统进行测试 设计桩模块S4 S5 M5 M6 第四步 依次用模块M5和M6替代桩模块S4 S5 并同时进行新的测试 组装测试完毕 自底而上增值 M3 M6 M5 D1 D2 D3 D1 D1 D2 D2 D3 D3 M2 M4 M1 第四步 把已测试的子系统按程序结构连接起来完成程序整体的组装测试 D4 D4 D4 D5 D5 D5 M1 M4 M3 M2 M6 M5 程序模块示意图 第一步 对最底层的模块M3 M5 M6进行测试 设计驱动模块D1 D2 D3来模拟调用 第三步 设计驱动模块D4 D5和D6模拟调用 分别对新子系统进行测试 第二步 用实际模块M2 M1和M4替换驱动模块D1 D2 D3 D6 深度优先与宽度优先 无论是自顶而下增值还是自底而上增值 还可选择深度优先或者宽度优先增值 举例 按自顶而下增值法 写出下图中分别按照深度优先或者宽度优先增值的模块组装次序 A B C D H G J E F I K L M N 确定集成过程的原则 自顶而下增值优点 能够尽早发现系统主控方面的问题 缺点 无法验证桩模块是否完全模拟了下属模块的功能 自底而上增值优点 驱动模块较容易编写 能够尽早查出底层涉及较复杂的算法和实际的I O模块中的错误 缺点 最后才能发现系统主控方面的问题 集成过程的原则 尽早测试关键模块 尽早测试包含I O的模块 3 混合增值 常见的混合增值方案 衍变的自顶而下先自底而上集成子系统 再自顶而下集成总系统 自底而上 自顶而下增值对含有读操作的子系统采用自底而上 对含有写操作的子系统采用自顶而下 回归测试在回归测试中自底而上 对其余部分 引起是对修改过的子系统 采用自顶而下 问题 1 自顶而下增值与自底而上增值各有何优 缺点 2 为什么在实际的组装测试中 都应该采用混合增值的方法 3 请自己设计2 3个混合增值的测试方法 三 确认测试 validationtesting 1 任务又称为有效性测试或功能测试 其任务是在开发环境下验证系统的功能 性能等特性是否符合需求规格说明 以黑盒法为主 2 确认测试步骤 1 有效性测试制定测试计划 运用黑盒法 验证软件特性是否与需求符合 2 软件配置复查软件配置 指软件工程过程中所产生的所有信息项 文档 报告 程序 表格 数据 随着软件工程过程的进展软件配置项 SCIsoftwareConfigurationItem 快速增加和变化 应复查SCI是否齐全 3 测试和 测试 测试是在开发机构的监督下 由个别用户在确认测试阶段后期对软件进行测试 目的是评价软件的FLURPS 功能 局域化 可使用性 可靠性 性能和支持 注重界面和特色 测试由支持软件预发行的客户对FLURPS进行测试 主要目的是测试系统的可支持性 FunctionTesting功能测试LocalAreaTesting局域化测试UsabilityTesting可使用性测试RegressionTesting回归测试PerformanceTesting性能测试SupportabilityTesting可支持性测试 四 系统测试 systemtesting 将经过确认测试的软件 与计算机硬件 外设 支持软件等一起 在实际运行环境下测试 五 验收测试 acceptancetesting 验收测试是以用户为主的测试 步骤 1 由课题组根据测试用例 自己演示系统所有功能 2 由用户进行测试 8 3 6综合测试策略 软件测试是保证软件可靠性的主要手段 也是软件开发过程中最艰巨 最繁杂的任务 软件测试方案是测试阶段的关键技术问题 基本目标是选择最少量的高效测试用例 从而尽可能多地发现软件中的问题 因此 无论哪一个测试阶段 都应该采用综合测试策略 才能够实现测试的目标 一般都应该先进行静态测试 再考虑动态测试 最后进行验收测试 AcceptanceTesting 是以用户为主的测试 测试过程 方法和测试内容与系统测试基本相同 有时也将验收测试与系统测试合二为一 此时 参加测试的人员最好包括 有经验的系统测试专家 用户代表 软件开发人员及QA 质量保证 人员也应参加 8 4面向对象的测试 而面向对象的测试贯穿软件开发的全过程 是与开发过程密切相关 而又分离出来的过程 面向对象的测试 既要使用许多传统的成熟的软件测试方法和技术 也有其不同的特点 主要反映在测试对象和内容的不同 传统的观点认为测试要在编码之后才进行 主要测试的对象是程序代码 面向对象的测试更关注对象 而不是完成单一的输入 输出功能 因此测试可以在分析和设计阶段介入 可以更好地配合软件生产过程 8 4 1面向对象测试的特点 1 强调需求或设计的测试 通常以两种方式进行 在没有代码的情况下进行测试 在有代码的情况下进行测试 2 在传统测试方法的基础上 根据面向对象的主要特性 需要改变测试策略和方法 例如 封装 对数据的隐蔽 减少了对数据非法操作 可简化该类测试 继承 提高了代码复用性 但错误也会以同样方式被复用 多态性 提供强大的处理能力 但也增加测试的复杂性 8 4 2面向对象测试类型 模型测试类测试交互测试系统 子系统 测试验收和发布测试 采用正式技术评审的方法 检查分析与设计模型的正确性 完整性和一制性 模型测试方法包括 用例场景测试 系统原型走查 需求模型一致性检查 分析模型的检查和走查 8 4 2面向对象测试类型 模型测试类测试交互测试系统 子系统 测试验收和发布测试 类测试即传统测试中的单元测试 即验证类的实现与类的规约是否一致的活动 完整的类测试包括 类属性的测试 类操作的测试 可能状态下的对象测试注意 不能 孤立 进行测试 操作测试应该包括其可能被调用的各种情况 8 4 2面向对象测试类型 模型测试类测试交互测试系统 子系统 测试验收和发布测试 交互测试用于代替传统测试方法中的集成测试 将类进行联合测试 以确定它们能否在一起共同工作 交互测试的方法有 用例或基于场景的测试 线程测试 对象的测试 8 4 2面向对象测试类型 模型测试类测试交互测试系统 子系统 测试验收和发布测试 测试系统或独立子系统 确保系统无明显故障 并满足用户需求 系统测试包括 功能测试 压力测试 安全测试 兼容性测试 安装测试 恢复测试 8 4 2面向对象测试类型 模型测试类测试交互测试系统 子系统 测试验收和发布测试 验收测试 交付用户前的系统测试 发布测试 为了确保系统安装软件包能够正常交付使用 8 4 3分析模型测试 2 需求测试可以较早地发现需求中问题如 不合理的项目 以及错误地理解了用户需求的项目 避免对于成本和资源的消耗 1 需求的质量影响并决定了设计的质量在软件开发过程模型中 需求 设计和编码总是有一定的时序特性 而且 需求模型 设计模型和实现代码之间还具备解释特性 一 分析模型测试的重要性 3 减少需求的模糊性用户需求是用户对待实现的系统的要求 通常以一种非正规的形式给出 具有一定的模糊性 这种模糊性带入了设计 甚至代码中 将可能引发几倍 甚至几十倍的错误 这必将极大消耗系统的资源和成本 测试实际上也是一个项目 测试也有需求 设计和实现 并且测试本身也会有测试 测试中的测试 测试作为项目开发活动中的一部分 在时间上应该有明确的要求 测试计划对于测试来说也是至关重要的 UML分析模型的每个模式 从严格意义上说都应该经过测试 实际上 通常对用例模型 类对象模型以及用例中典型场景进行测试 二 测试过程 通常测试步骤如下 测试用例模型 测试某些用例中的典型场景 类及对象模型 某些类测试其状态模型 单个用例测试采取典型应用场景的测试方法 用例模型的测试相当于系统测试 测试的主要目标是用例模型对于用户需求的可跟踪性 以系统的用户为主要的出发点设计测试用例 通过模拟某个系统用户的行为来测试整个系统 对于该用户的服务提供情况 从而检查系统功能的完整性 用户需求可跟踪性等情况 用例模型的测试从系统用户的角度测试系统的服务 并不关心每个测试用例所实现的功能如何 所以应该是黑盒测试 三 用例模型的测试 下面以一个订货中心系统的用例模型为例说明测试用例的设计 有一个订货中心 接受客户的电话 传真 电子邮件 信件和Web主页表单等形式的订货请求 建立订单 根据客户要求的发货目的地 订货中心将以最经济的方式确定一家仓库来负责向客户发货 当仓库收到订单后 按照一定的策略进行发货 在填写发货的有关信息后 将订单返回订货中心 案例订货中心系统 识别五个主要的系统角色 用户 管理者 Manager 发货人员 Shipper 收款人员 Tollcollector 商务客户 Customer 信用卡 Creditcard 从各个角色出发 通过下边的问题识别用例 角色要求系统提供的功能有哪些 系统在提供这些功能的时候该角色需要做什么 角色需要创建 阅读 销毁或存储系统的哪些信息 系统中的哪些事件需要通知该角色 以管理者为例 1 管理者要求系统为他提供什么功能 管理者需要做哪些工作 答 管理者要求系统提供 a 接受顾客订货请求并创建订单 b 计算订单的价钱 c 根据订单信息选择仓库 并将订单发送给仓库 d 查询订单货物发送情况 e 查询客户订单付款情况 f 评价商务结果 g 顾客退货处理 h 把仓库返回的订单发送到收费处 i 商品价格更新 管理者需要做 生成订单 查询订单时输入订单号 2 管理者需要阅读创建 销毁 更新或者存储系统哪些信息 答 信息包括 订单 职员 仓库人员 收费人员等 信息 顾客信息 物品条目及价格信息 仓库信息和税务信息 3 系统中的事件一定要告诉管理者吗 答 是 这些事件包括 仓库有关物品短缺以致无法满足某订单 订单数据出现错误 顾客超过期限未付款 可见 管理者要使用系统的十个功能 因此至少可以设计出十个测试用例 以第三条功能 根据订单信息选择仓库 并将订单发送给该仓库 为例 说明用例的选择 假设订货中心共有三个仓库 管理者要决定应该选择哪个仓库处理订单 订单主要信息 订单号 送货地点 货物名称及数量等 管理者考虑将订单分配到某仓库的因素 1 首先仓库必须能够满足订单上的货物要求 2 选择地理位置与发货点较近的仓库发货 3 信誉满意度越高的客户就越应该以较高的服务质量来回报 结合考虑上面三个因素 以最少的成本取得最好的收益 三个订单信息如下 测试用例1 输入 订单1预期结果 选择仓库B来处理订单 三个均可 大宗订单 客户信誉度高 测试用例2 输入 订单2预期结果 选择仓库A来处理订单 个人订单 客户信誉一般 测试用例3 输入 订单3预期结果 选择仓库C来处理订单 以上测试未涉及某个具体用例 体现了用例模型测试和用例测试的区别 8 4 4类的测试 类测试即传统测试中的单元测试 即验证类的实现与类的规约是否一致的活动 类测试包括 类属性的测试 类操作的测试等 例2Date类是一个描述日期的类 其属性为三个成员变量 年 月 日 在Date类中 操作decrease 是使Date类的对象改变为当前日期的前一天 printDate 是打印日期信息 而Date类的三个成员变量所属的类是calendarUnit类的子类 在calendarUnit类中 也有操作decrease 并通过继承关系在Day Month Yers三个类中重写 设计测试用例 对Date类的操作decrease 进行测试 8 4 4类的测试 注意 操作测试应该考虑其可能被调用的各种情况 图8 16calendarUnit类的继承关系 calendarUnit currentVal Integer CalenderUnit pVal Integer SetValue pVal Integer decrease Boolean 例如 对date类中的decrease方法进行测试 在设计测试用例时 采用等价分类法 划分等价类时

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论