一个基于UML协作图的集成测试用例生成方法(二)(3)

　　测试模式是一个测试策略，是建立在测试模型基础上的，而测试模型应该是被测软件系统的一个表示，能够从测试模型上获取测试需求，导出测试规约，从而生成测试用例。协作图是对象、组件、子系统、系统范围需求的良好来源，对系统的一个有限片断来说，提供了实现的抽象视图，它通常是过多或过少细节之间的一个良好的折中，可以用于在不同抽象级别和粒度级别建立软件系统的模型。由于协作图是描述的对象之间的交互，而系统的功能正是通过这些交互实现的，所以要考虑将设计描述的协作图作为生成集成测试的测试用例的测试模型。协作图上包括了对象间传递的消息及其顺序，这正是设计级的控制流和数据流信息，以往数据流和控制流只能从程序源码中分析得到。数据流和控制流对生成测试有很大的作用，所以我们利用协作图生成测试用例，就是要从协作图上提取出相应的数据流和控制流信息，利用传统的数据流、控制流生成测试用例的方法，生成可用于集成测试的测试用例。所以本文使用作为系统设计描述的协作图作为测试行为的测试模型，避免重新构造测试模型或者进行模型转换。

　　2.1中分析了协作图中描述的信息，这也是作为测试模型的协作图中包含的对生成测试用例有用的信息，这些信息是规约在转变成实现时必须保持的，这些信息也是测试时要确认在软件实现中是否正确保持的设计信息，因此这就是测试工作第一步要获取的测试需求。测试需求的正确实现要求也就是测试规约，它规定了能让软件执行并正确反应测试需求的测试用例。如果我们能够用足够的测试用例执行了程序，并证明协作图上所有测试需求都在软件中正确保持了，就可以说测试充分了，本文主要关注协作图表示的系统的动态交互行为，而协作图上用于表示交互行为的主要是消息及其偏序序列，所以本文研究的测试方法的充分性准则是协作图上所有的消息及其偏序关系都被测试用例覆盖。表1中的协作图的集成测试需求说明至少有一个测试用例测试对应的关系来检查测试需求是否满足。

　　符号 关系 集成测试需求

　　实线实心箭头 扁平控制流 发送者与接受者之间的偏序

　　实线刺状箭头 过程调用

　　条件过程调用

　　迭代过程调用

　　递归过程调用 发送者发送消息到接受者并返回

　　发送者发送消息到接受者并返回，

　　发送者不发送消息到接受者

　　发送者重复发送消息到接受者并返回

　　发送者发送消息到自己

　　虚线刺状箭头 从过程调用返回 可不考虑

　　表1 消息对应的集成测试需求

　　一个场景路径上由消息激活的方法序列表示了我们要测试的行为，路径上对象间的消息传递描述了要实现相应的功能对象间必要的交互，协作图上场景路径的构造能够满足表1描述的协作图对应的集成测试需求，这样我们就可以把问题转换到满足协作集成测试需求的场景路径的分析和处理上。我们在协作图上遍历生成场景路径的同时，很容易基于路径覆盖准则获取相应场景执行过程中的控制流和数据流、覆盖路径的条件，然后可以确定每一路径所需要的输入和状态条件，当满足所有路径条件时线程就会沿着该路径执行，测试用例的定义需要满足路径条件的特定输入和状态。为了确定测试用例的值，需要分析每条路径上的谓词，从第一个谓词开始，选择满足相应路径条件输入和状态值。直到完成所有的路径条件，最后确定每个测试用例的预期结果，包括方法调用序列。第3部分详细描述从协作图构造场景路径，然后基于场景路径生成测试用例的方法。

原文转自：http://www.ltesting.net