软件测试(ppt)完整版.ppt

软件测试 由 6 1软件测试的基本概念 一 软件测试的目的和重要性因为开发工作的前期不可避免地会引入错误 测试的目的是为了发现和改正错误 这对于某些涉及人的生命安全或重要的军事 经济目标的项目显得尤其重要 1963年美国飞往火星的火箭爆炸 原因是FORTRAN程序 DO5I 1 3误写为 DO5I 1 3损失1000万美元 1967年苏联 联盟一号 宇宙飞船返回时因忽略一个小数点 在进入大气层时打不开降落伞而烧毁 二 软件测试的特点 1 软件测试的开销大按照Boehm的统计 软件测试的开销大约占总成本的30 50 例如 APPOLLO登月计划 80 的经费用于软件测试 二 软件测试的特点 结论 3 软件测试难度大根据上述分析 既然不能进行 穷举 测试 又要查出尽可能多的错误 软件测试工作的难度大 只有选择 高效的测试用例 什么是 高效的测试用例 如何选择 高效的测试用例 这就是本章讨论的主要问题 三 软件测试的基本原则 3 充分注意测试中的群集现象 1 尽量不由程序设计者进行测试 2 关键是注重测试用例的选择 输入数据的组成 输入数据 预期的输出结果 既有合理输入数据 也有不合理的输入数据 用例既能检查应完成的任务 也能够检查不应该完成的任务 长期保存测试用例 由安博测试空间技术中心提供 四 测试的基本步骤 模块测试 整体测试 功能测试 预测试 系统测试 验收测试 安装测试 概要设计审查 详细设计审查 代码审查 测试 单元测试 组装测试 有效性测试 确认测试 6 2软件测试方法 软件测试方法分为两类 静态分析 动态测试 一 静态分析方法指以人工的 非形式化的方法对程序进行分析和测试 桌前检查代码会审步行检查 步行检查时 还常使用以下分析方法 调用图从语义的角度考察程序的控制路线 数据流分析图检查分析变量的定义和引用情况 调用图 无论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 验证分析运行结果与预期结果 逻辑结构 白盒法举例 Procedure VARA B X REAL BEGINIF A 1 AND B 0 THENX X A IF A 2 OR X 1 THENX X 1END 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 作业 PROGRAMbubble input output CONSTn 100 TYPEcolarr ARRAY 1 n OFINTEGER VARa colarr t i j INTEGER BEGINFORi 1TOnDOREAD a i READLN FORj 1TOn 1DOFORi 1TOn jDOIFa i a i 1 THENBEGINt a i a a i 1 a I 1 tEND FORi 1TOnDOBEGINWRITE a i 4 IFIMOD5 0THENWRITELNEND WRITELNEND 用白盒法测试以下程序段 要求写出覆盖标准 列出所有判定情况 选择测试用例 作业 退出 上页 首页 下页 末页 用C语言编写选择排序的程序 并用白盒法进行测试 二 动态测试方法 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 因果图法 4 因果图法 causeeffcetgraphicei 因果图的基本符号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 4 因果图法 causeeffcetgraphicei 对 与 或 函数的限制符号 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 第一列字符为A50 修改文件2 第一列字符为B51 发信息X123 第二列字符为数字52 发信息X13 画出因果图 中间结点是导出结果的进一步原因 考虑到原因1 2不可能同时为1 加上E约束 11 将因果图转换为判断表 11 51 50 52 6 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 问题 1 自顶而下增值与自底而上增值各有何优 缺点 2 为什么在实际的组装测试中 都应该采用混合增值的方法 3 请自己设计2 3个混合增值的测试方法 确定集成过程的原则 自顶而下增值优点 能够尽早发现系统主控方面的问题 缺点 无法验证桩模块是否完全模拟了下属模块的功能 自底而上增值优点 驱动模块较容易编写桩模块 能够尽早查出底层涉及较复杂的算法和实际的I O模块中的错误 缺点 最后才能发现系统主控方面的问题 集成过程的原则 尽早测试关键模块 尽早测试包含I O的模块 3 混合增值 常见的混合增值方案 衍变的自顶而下先自底而上集成子系统 再自顶而下集成总系统 自底而上 自顶而下增值对含有读操作的子系统采用自底而上 对含有写操作的子系统采用自顶而下 回归测试在回归测试中自底而上 对其余部分 尤其是对修改过的子系统 采用自顶而下 三 确认测试 validationtesting 1 任务又称为有效性测试或功能测试 其任务是验证系统的功能 性能等特性是否符合需求规格说明 选择测试人员 选择测试用例 实际运行测试 软件计划 用户文档 开发文档 源程序文本 支持环境 有效性测试 软件配置审查 管理机构裁决 专家鉴定会 交用户 运行维护 测试报告 软件配置 2 确认测试步骤 1 有效性测试制定测试计划 运用黑盒法 验证软件特性是否与需求符合 2 软件配置复查软件配置 指软件工程过程中所产生的所有信息项 文档 报告 程序 表格 数据 随着软件工程过程的进展软件配置项 SCIsoftwareConfigurationItem 快速增加和变化 应复查SCI是否齐全 3 测试和 测试 测试是在开发机构的监督下 由个别用户在确认测试阶段后期对软件进行测试 目的是评价软件的FLURPS 功能 局域化 可使用性 可靠性 性能和支持 注重界面和特色 测试由支持软件预发行的客户对FLURPS进行测试 主要目的是测试系统的可支持性 FunctionTesting功能测试LocalAreaTesting局域化测试UsabilityTesting可使用性测试RegressionTesting回归测试PerformanceTesting性能测试SupportabilityTesting可支持性测试 四 系统测试 systemtesting 将经过确认测试的软件 与计算机硬件 外设 支持软件等一起 在实际运行环境下测试 五 验收测试 acceptancetesting 验收测试是以用户为主的测试 软件工程课程设计的验收测试 19周进行 1 步骤为 1 由课题组根据测试用例 自己演示系统所有功能 2 由教师进行测试 2 软件工程课程设计验收表 3 软件测试文档 模块测试报告至少选择一个典型模块进行测试 A 综合测试策略 静态分析 白盒法为主 辅以黑盒法 B 测试情况 根据覆盖标准列出 C 测试用例 保留 D 查错记录 数量 位置 分析结果 组装测试报告A 组装次序 测试方法 以黑盒法为主 B 测试情况C 测试用例 保留 D 查错记录 数量 位置 分析结果 功能测试与系统测试与上类似 6 4面向对象的测试 传统的观点认为测试要在编码之后才进行 假设测试的对象是程序代码 需求和设计是代码产生的基础 需要对需求和设计进行测试 需求或设计的测试通常以两种方式进行 一是在没有代码的情况下进行测试 二是在有代码的情况下进行测试 面向对象的测试 既要使用许多传统的成熟的软件测试方法和技术 也有其不同的特点 主要反映在测试对象和内容的不同 6 4 1分析模型测试的重要性 在不同的软件开发过程模型中 需求 设计和编码总是有一定的时序特性 需求模型 设计模型和实现代码之间还具备解释特性 即设计解释了需求 实现代码解释了设计 1 需求的质量影响并决定了设计的质量 进而影响并决定了代码 直至整个系统的最终质量 必须首先重视需求的质量 而测试是质量保证的重要手段 2 需求测试可以较早地发现需求中不合理的项目 以及错误地理解了用户需求的项目 避免对于成本和资源的消耗 同时也减少了返工的几率 应尽早发现并解决这些问题 3 减少需求的模糊性 用户需求是用户对待实现的系统的要求 通常以一种非正规的形式给出 具有一定的模糊性 这种模糊性带入了设计 甚至代码中 将可能引发几倍 甚至几十倍的错误 这必将极大地消耗系统的资源和成本 6 4 2测试方法 也分为静态测试和动态测试两类 评审的目的是对具体的工作产品集 如文档 源代码 进行评价 并对管理提供以下信息 是否符合制定的软件规格 是否按照项目的标准和方法完成 是否所有的更改都正确地得到完成 在UML中 对需求模型的测试 评审 事务流 场景 模型等方法测试 需结合具体的模型描述 测试的目的是发现代码中的错误 测试的关键是确定高效的测试用例 测试的主要步骤有 面向对象的单元测试测试单元为封装的类和对象 但不能孤立地测试单个操作 应把操作作为类的一部分来测试 面向对象的集成测试集成测试的策略有 基于线程的测试 Thread basedtesting 基于使用的测试 Use basedtesting 3 面向对象的确认测试类似传统的确认测试和系统测试 根据动态模型和描述系统行为的脚本来设计测试用例 可用黑盒法 一 评审计划需要列出的项目 解决测什么 什么时候测 谁来测 哪些人将参加评审会 各自的职责是什么 需要准备哪些材料 必须满足什么条件 要完成的检查单或其他的指标 评审会完成所必须满足的条件或准则 评审会结束后需要保留归档的记录和文档 二 参加评审人员 用户 软件项目负责人 软件工程师 软件配置管理人员 软件质量保证人员 软件独立验证与确认人员 软件开发无关的专家 评审计划 测试实际上也是一个项目 测试也有需求 设计和实现 并且测试本身也会有测试 测试中的测试 测试作为项目开发活动中的一部分 在时间上应该有明确的要求 测试计划对于测试来说也是至关重要的 UML分析模型的每个模式 从严格意义上说都应该经过测试 实际上 通常对用例模型 类对象模型以及用例中典型场景进行测试 6 4 3测试过程 通常测试步骤如下 测试用例模型 测试某些用例中的典型场景 类及对象模型 某些类测试其状态模型 1 用例模型测试重点是检查用例模型作为整体是否实现了用户需求 相当于系统测试 通过系统的用户对系统的功能需求来设计测试用例 3 类模型测试对类模型的测试是分析模型的核心 通常是根据问题域来进行测试 黑盒法 2 用例测试是对某些用例中的典型场景进行测试 典型场景的测试关心的是用例的执行情况 评审 4 状态模型测试对重要的状态模型进行测试 分析阶段的测试只能采用评审法 测试对象的生命期和转移事件的条件 分析模型测试内容 用例模型的测试相当于系统测试 测试的主要目标是用例模型对于用户需求的可跟踪性 用例模型的测试可以通过系统的可能用户对系统的功能要求来设计测试用例 以系统的用户为主要的出发点设计测试用例 通过模拟某个系统用户的行为来测试整个系统 对于该用户的服务提供情况 从而检查系统功能的完整性 用户需求可跟踪性等情况 用例模型的测试从系统用户的角度测试系统的服务 并不关心每个测试用例所实现的功能如何 所以应该是黑盒测试 6 4 1用例模型的测试 下面以一个订货中心系统的用例模型为例说明测试用例的设计 识别五个主要的系统角色 用户 管理者 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来处理订单 以上测试未触及某个具体用例 体现了用例模型测试和用例测试的区别 类模型是分析模型中的核心 它抽象出了问题域中的对象和实体 以及它们在问题域中的职责 为确保类模型的正确性和完整性 只根据问题域测试类模型 测试方法是评审会 类图实际上由类和类之间的关系组成 评审会的检查单可从以下两个方面制定 6 4 5类模型的测试 针对每个类提问 1 该类在问题域中对应的实体 或对象 是什么 2 履行什么职责 3 在类图中被赋予了哪些职责 4 该类在问题域中的职责和在类图中的职责能匹配吗 5 该类的每个数据属性都是问题域所关心的吗 针对类图中的类之间的关系提问 1 这种类关系是反映了问题域本质的关系还是为管理类模型而引入的关系 如果类之间的关系并非反映问题域的本质 那么这个关系的存在就值得怀疑 2 仔细检查每个继承关系 到底是聚集关系还是继承关系 3 针对关联关系中的关联数目 提一些问题结合实际场景来考察 从模型的角度可以关心如下问题 1 状态模型刻画了对象的生命周期吗 2 针对每个状态而言 状态转移触发条件是状态转移的充分条件吗 3 对象在问题域需要响应的所有条件是否在状态模型中都有响应 4 关心对象在某些状态中的动作 如果对象需要发送消息给其它对象 那么此时接收该消息的对象处在其声明周期的什么阶段 5 从初始状态开始 每个状态都可以达到吗 6 4 6类状态模型的测试 类状态模型描述了一个对象在问题域中的活动历程 在分析阶段 识别的对象还只是停留在较粗的层次上 因此 对象状态模型的测试通常只能采用评审会的办法 只测试在问题域中非常重要的对象 如电梯系统中的电梯对象 上述五个问题可以作为评审会问题检查单的选择 对问题 1 检查状态模型对于对象状态的划分 一旦出现识别的状态不足 或者某些状态超出问题域的关心 分析原因 分析员在评审会报告想法和理由 对问题 2 检查状态转移条件 验证当触发条件满足时是否会出现状态转移 要求触发条件是最简化的 无冗余条件 对问题 3 通过一张对照表可以找出答案 对问题 4 检查较复杂 容易发现分析错误的一个环节 通常 分析员以为进行交互的其它对象都处于 良好 状态 但这个假设常常不能成立 因为两个不同的对象可能与相应的事件会有交叉 如定时事件 因此 当当前分析的对象发生了