‘<<’顺序关系是强制顺序关系，那么即使它们在顺序图的时间轴上存在先后关系，这两个事件实际发生的先后顺序也是不确定的。例如图4中，尽管(m1,r)在(m3，r)的上方，但是在系统实际运行中，由于m1, m2, m3都是异步消息，因此(m1,r)并不一定先于(m3,r)发生，这是由于图形表示的局限性造成的。
一个简单顺序图(不包括分支)刻画了系统运行的一个场景，其运行过程表现为一个事件的序列(e1 , e2,…, em),其中事件ei+1 在事件 ei后发生(1≤ i ≤m-1)。由于事件之间存在强制顺序关系‘<<’，因此并不是所有事件序列都是顺序图允许的。而且，由于‘<<’并不是一个全序关系，所以一个顺序图的场景可能允许多个事件序列。可以用一个有向无环图(DAG)来表示‘<<’关系，对于任意两个事件 ei，ei∈ E，如果 ei<< ei，则画一条从ei 指向ei 的边，直到所有事件都在这个有向图上。
通过遍历所得的DAG图，可以很容易的得到顺序图中的每一个有效的事件序列。在图4的例子中，<(m1,s), (m2,s), (m2,r),(m3,s),(m3,r),(m1,r)>和<(m1,s),(m1,r), (m2,s), (m2,r), (m3,s), (m3,r)>就是两个有效的事件序列。
定义2(顺序图的场景)对于顺序图SD=，场景定义为一个消息序列< M1,M2,…,Mm>，并且满足下面两个条件：
(1)所有M中的事件在序列中出现且仅出现一次，也就是说{M1,M2,…,Mm}=M且对于所有的i j，Mi Mj。
(2)对于任意两个消息序列Mi,MjÎM，如果(Mi,s)<<(Mj,s),那么序列中Mi在Mj的前面。
根据场景的定义，通过所找到的合法的事件序列就可以确定与该事件序列相应的场景。如图4，就是一个有效的场景。
3、基于UML顺序图生成场景测试用例的方法
顺序图中的场景设计可能与实现不一致，例如由于消息名的编码错误、不正确的或缺少输出等，那么通过执行顺序图中的所有可能场景，至少能在其中的一个场景的执行过程中达到该错误，因此只要从顺序图中生成覆盖所有场景的测试用例就能有效地找出存在的错误。在测试用例的生成过程中，我们将环境条件与输入，方法调用序列和预期输出作为最终的测试用例，最后将系统测试后的实际输出和方法调用序列与预期的输出和方法调用序列进行比较，从整体上验证系统的最终实现是否与设计一致，从而完成顺序图的场景测试。
3.1、测试衡量方法
测试的主要评测方法包括覆盖和质量，测试覆盖是对测试完全程度的评测，质量是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的评测。对于顺序图的场景测试，最基本的评测方法就是测试覆盖，即要求针对每一个场景都至少生成一个测试用例。但是顺序图本身并不能充分地对系统交互行为进行建模，仅通过顺序图并不能生成充分地场景测试用例。所以我们将顺序图与交互对象的状态图相结合，生成更充分的测试用例。为此，定义如下评测方法：
1) 顺序图中的每个场景至少被测试一次。
2) 如果顺序图中的对象存在状态图，那么与场景相关的每个状态至少要被测试一次。
3.2、顺序图场景测试用例生成方法的步骤
第一步，检查顺序图中的每一个对象，如果其存在状态图，就将对象状态加入到顺序图中。以DHCP-Server对象为例，其状态图如图3所示，Has free IP addresses和Has no free IP addresses是Server可能处于的两种状态，我们将这两个状态加入顺序图，加入状态信息后的最终结果如图5所示。
文章来源于领测软件测试网 https://www.ltesting.net/