从MDV（模型驱动测试用例设计方法）看测试用例自动生成

MDV把的基本方法，是把需求作为测试用例设计的输入，通过测试需求分析，转换为测试模型，在根据测试模型生成测试用例。

我们的方法论，更进一步：

需求模型
 
测试模型
 
测试用例
 
测试场景
 

测试场景，更多的体现了测试过程的流程，体现了需求对流程的描述，对需求中各个业务流程、业务功能的测试。

通过这个方法，我们能够覆盖到应用系统的各个流程和不同的测试数据分支。

下面，我们简要的介绍一些各个阶段的转换：

l         从需求模型到测试模型

在进行功能测试的时候，输入是需求。如果需要进行MDV ，则需要对需求进行约束，也是我们需要对需求进行形式化。需求的形式化，便于我们很方便的转换何曾为测试模型。

需求的形式化，是需要对需求的表述，从自然语言转换成为UML的形式。在测试中，主要采用UML的usecase图和活动图来表述。

解决了需求的形式化，要求在需求导入的时候，必须导入活动图，否则需要测试需求分性做更多的工作，自己来解决没有必要需求，自己来表述的问题了。这样会导致理解的偏差和测试的不足。

很多时候，不是没有UML图的问题，而是发现需求本身不全面。因此建立需求UML的过程，也是对需求进行补充的过程。

需求建立之后，我们需要把需求转换为测试需求。转换的基础是：定义测试项。也是，需要在本需求中，定义那些内容是需要进行测试的。根据测试项，对活动图进行分析，察看是否需要增加为了需求项（会转换成检查点）来增加检查节点。如果原来的活动图已经能够满足要求，可以直接把需求活动图转换成为测试活动图；如果缺少，需要对需求活动图增加检查点，主要是增加检查功能，典型的是增加查询，并且可以根据查询结果进行校验。

l         从测试模型到测试场景

测试模型建立完成，我们需要把测试模型转换成为测试场景。

这个方法是路径扫描，发现从“开始”到“结束”节点，有多少条路径。

测试模型中的每条路径是一个测试场景。

这个部分是自动来实现的，不需赘述。

l         从测试场景到测试用例

测试场景建立完成，需要进行测试用例设计。从MDV的角度，测试用例是给测试场景增加了测试数据来形成的：测试场景+测试数据=测试用例’s

因此，这个阶段的重点工作是设计测试数据，或者添加测试数据给测试场景，形成测试用例（很多个测试用例）。