测试分析与设计模型.pptVIP

第十一章测试分析与设计模型 11.1 指导性审查分析与设计模型 11.2 测试指定类型的模型 11.1指导性审查 开发者对所构建的软件进行建模，有助于理解正在解决的问题，并管理正在开发的系统的复杂性。 分析和设计模型对具体的实现起指导作用，模型质量的高低对项目极其重要。 指导性审查：专为检验模型而创建的检测技巧，用于验证模型是否符合项目的需求，在开发过程早期就使用了测试的观点。　　 指导性审查的基础 指导性审查技术通过使用明确的测试用例，为查找工作成果中的缺陷提供了客观的系统的方法。 基本的测试步骤： 定义测试位置。 使用特殊的策略从测试位置选择测试值 将测试值用于被测产品中 对测试结果及模型覆盖率进行评估。 具体化的测试步骤 指定检查的范围和深度：范围通过一系列详细的用例来定义；深度通过某种ＵＭＬ图的集合层次中的级别来定义。 ·确定ＭUＴ（需要测试的模型）产生的基础：一般为前一阶段创建的一系列模型。 ·开发测试用例：一般从用例模型出发。 ·为测量的覆盖率建立标准：类图中的所有类。 ·使用合适的检查列表进行静态分析。将ＭＵＴ与基本模型比较确定它们之间的连贯性。 ·执行测试用例：（象征性执行） 评价标准 　模型是否正确？正确性是对模型的准确程度测量，在分析阶段，指对问题描述的准确性；在设计阶段，指对解决问题的方案描述的准确性。模型的正确性与多少测试用例相关，则只有这些测试用例的期望结果正确时才说明模型是正确的。 　模型对信息的描述是否完整？完整性是对模型包含性的测量，模型是否遗漏了某个必须的或至少是有用的因素，是否存在测试用例，提出了模型中的元素无法表达的假设。当然，完整性与所期望的当前增量的成熟度有关，另一个影响完整性标准的有效性因素是测试覆盖率，若测试执行的结果可用模型的内容充分表述，则模型是完整的。 模型是否内部一致以及是否与它的基类一致？一致性是对模型内部以及当前模型与它的基础模型之间是否存矛盾的测量。 指导性审查活动的组织 基本角色：领域专家（输入，所期望的结果），测试者（分析，选择测试用例）开发者（与测试人员一道检测模型） 详细说明审查：详细说明检查的范围（一套用例，程序包，接口和抽象类）和深度（消息发送所处的集合层次中的层数） 现实模型：对模型中的图例分层，类图（包——包——类），顺序图。为审查选择测试用例：从指定的用例出发可以开发多个测试用例。 传统方法：等价类划分。 正交缺陷分类做为测试用例选择器：选择测试用例来查找指定类型的缺陷，即测试用例通过覆盖导致缺陷的系统行为的不同类型来确定缺陷。导致缺陷被发现的活动归为“触发器”类。 使用轮廓做为测试用例选择器：使用轮廓是在对单个用例的频率值和危险值进行组合的基础上对该用例的排序，每个使用用例所需测试用例的数量是由其在序列中的位置来调整的。例：Brickls游戏中，类的newgame（），exit（），help（）函数。 风险作为测试用例选择器，以风险为基础来决定该做多少测试。 通过用例创建测试用例，用例包含一系列场景：通用用例。扩展和异常用例，每个场景都包括行动者采取的行动和系统的响应，可从一个场景构建一个测试用例或多个测试用例。 用例模板具有三种场景：使用场景，可替换场景，异常场景。 单独审查：检查人员检查模型，完成审查列表（当前模型与基本模型的比较＋当前模型的检查） 交互式审查会话：包括测试者和开发者在内的交互会话，测试用例模型执行，来发现故障，一般包括主持人，记录员，绘图员。 11.2 测试指定模型 应用需求可以归结为创建一个对该系统的使用模型. 用例（文本、用例图） 利用图例可以构建系统测试用例 审查需求模型的标准：完整性、正确性、一致性，领域专家和产品定义人员的详细审查将会找出故障。 测试需求模型的基本概要 通过用例的频率和关键性信息划分用例的等级 确定可用资源数量的条件下所构建测试用例的总数（时间 、人） 根据等级给测试定量，分配测试用例数目给各个用例 根据领域专家角色的知识写测试场景 在测试会话上（开发者、测试人员），测试场景编写者对每一种场景进行介绍，模拟执行，寻找故障。 测试分析模型 域分析模型：对领域的认识建模，域模型的审查标准如右表所示。 应用分析模型：对一个应用的认识建模 右表是应用模型审查标准 P102图4.18 两模型之间的映射 测试设计模型——体系结构设计模型 是整个应用的框架，通过定义一系列的接口是如何关联的为应用提供了基本的结构。 评价标准（如右表）： 测试过程 构建测试用例：测试用例基本上是在子系统之间的接口层次上定义的。（example：bricks游戏的基本接口处于一个模型：puck，paddle——视图：bricksview 之间） 模拟执行测试：构建一个消息-顺序图来执行测试 结