模型驱动测试用例设计方法

根据统计分析，一个基本功能，使用手工测试，需要达到测试用例：测试功能点=5:1以上，才比较有意义。使用更多的测试用例，才能够发现更多的问题，这是根据经验归纳来的。

　　设计测试用例，是整个测试工作的最核心部分。目前绝大多数的测试设计方法，都属于测试设计“技巧”，如：等价类划分、边界值、因果图等，都是在具体设计测试数据时候来考虑如何根据测试数据的不同来设计测试用例。

　　基于这些具体测试技巧，对整体测试用例设计水平的提升，帮助不是很大。目前，基于这些方法，真正影响测试用例质量的，是测试设计人员对被测试系统需求的理解、业务层面的理解。

　　MDV的方法，是想通过建立一套设计测试用例的流程，通过标准化的输入、标准化的处理，生成更可靠的测试用例。

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

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

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

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

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

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

　　● 从需求模型到测试模型

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

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

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

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

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

　　● 从测试模型到测试场景

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

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

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

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

　　● 从测试场景到测试用例

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

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

　　这个方法，我们叫做面向测试模型驱动的测试设计方法。