[计算机]面向对象分析设计Chapter05.pptVIP

* §5.1 分析模型测试的重要性 第五章 分析模型的测试 §5.3 测试过程 §5.2 测试方法 第五章小结 §5.4 用例模型的测试 §5.5 类模型的测试 §5.6 类状态模型的测试 §5.7 典型场景的测试 传统的观点认为测试要在编码之后才进行，假设测试的对象是程序代码。 需求和设计是代码产生的基础，需要对需求和设计进行测试。 需求或设计的测试通常以两种方式进行： 一是在没有代码的情况下进行测试； 二是在有代码的情况下进行测试。 第五章 分析模型的测试 分析模型的测试实际上包括两部分内容： 针对分析模型测试模型的完整性； 根据分析模型为系统的测试(包括类级别的单元测试、集成测试等)，定义测试用例。 通常模型的测试采用正式评审会方式进行。 在需求阶段不会执行什么实在的测试用例，定义测试用例。 在设计阶段需要设计测试用例。 在不同的软件开发过程模型中，需求、设计和编码总是有一定的时序特性。 需求模型、设计模型和实现代码之间还具备解释特性，即 设计解释了需求，实现代码解释了设计。 需求的质量影响并决定了设计的质量，进而影响并决定了代码，直至整个系统的最终质量。 §5.1 分析模型测试的重要性 必须首先重视需求的质量，而测试是质量保证的重要手段。 需求测试可以较早地发现需求中不合理的项目、以及错误地理解了用户需求的项目，避免对于成本和资源的消耗。 同时也减少了返工的几率，应尽早发现并解决这些问题。 用户需求是用户对待实现的系统的要求，通常以一种非正规的形式给出，具有一定的模糊性。这种模糊性带入了设计，甚至代码中，将可能引发几倍，甚至几十倍的错误，这必将极大地消耗系统的资源和成本。 §5.2 测试方法 基于代码 —— 代码走查 静态 基于非代码—— 评审(需求和设计规格说明) 动态 —— 测试用例驱动代码执行 根据测试方式目的可分为： 数据流测试方式； 控制流测试方式； 事务流测试方式(数据流和控制流综合测试)。 测试是否应深入到代码逻辑中： 黑盒测试 白盒测试 在UML中，对需求模型的测试： 评审； 事务流(场景)模型等方法测试(需结合具体的模型描述)； 正式 —— 承担责任，写出评审报告 评审 非正式 评审的目的是对具体的工作产品集(如文档、源代码)进行评价，并对管理提供以下信息： 是否符合制定的软件规格； 是否按照项目的标准和方法完成； 是否所有的更改都正确地得到完成。 评审计划需要列出的项目(解决测什么，什么时候测，谁来测)： 哪些人将参加评审会，各自的职责是什么； 需要准备哪些材料； 必须满足什么条件； 要完成的检查单或其他的指标； 评审会完成所必须满足的条件或准则； 评审会结束后需要保留归档的记录和文档。 参加评审人员： 用户，软件项目负责人，软件工程师，软件配置管理人员，软件质量保证人员；软件独立验证与确认人员，软件开发无关的专家。 测试实际上也是一个项目。 测试也有需求、设计和实现，并且测试本身也会有测试(测试中的测试)。 测试作为项目开发活动中的一部分，在时间上应该有明确的要求，测试计划对于测试来说也是至关重要的。 UML分析模型的每个模式，从严格意义上说都应该经过测试。实际上，通常对用例模型、类对象模型以及用例中典型场景进行测试。 §5.3 测试过程 通常测试步骤如下： 测试用例模型 ? 测试某些用例中的典型场景 ? 类及对象模型 ? 某些类测试其状态模型 单个用例测试采取典型应用场景的测试方法，用例模型的测试相当于系统测试，测试的主要目标是用例模型对于用户需求的可跟踪性。 以系统的用户为主要的出发点设计测试用例，通过模拟某个系统用户的行为来测试整个系统，对于该用户的服务提供情况，从而检查系统功能的完整性，用户