根据统计分析，一个基本功能，使用手工测试，需要达到测试用例：测试功能点=5:1以上，才比较有意义。使用更多的测试用例，才能够发现更多的问题，这是根据经验归纳来的。
设计测试用例，是整个测试工作的最核心部分。目前绝大多数的测试设计方法，都属于测试设计“技巧”，如：等价类划分、边界值、因果图等，都是在具体设计测试数据时候来考虑如何根据测试数据的不同来设计测试用例。
基于这些具体测试技巧，对整体测试用例设计水平的提升，帮助不是很大。目前，基于这些方法，真正影响测试用例质量的，是测试设计人员对被测试系统需求的理解、业务层面的理解。
MDV的方法，是想通过建立一套设计测试用例的流程，通过标准化的输入、标准化的处理，生成更可靠的测试用例。
MDV，就是基于测试模型的测试设计方法，MDV把的基本方法，就是把需求作为测试用例设计的输入，通过测试需求分析，转换为测试模型，在根据测试模型生成测试用例。
我们的方法论，更进一步：
需求模型——>测试模型——>测试用例——>测试场景
测试场景，更多的体现了测试过程的流程，体现了需求对流程的描述，对需求中各个业务流程、业务功能的测试。
通过这个方法，我们能够覆盖到应用系统的各个流程和不同的测试数据分支。
下面，我们简要的介绍一些各个阶段的转换：
● 从需求模型到测试模型
在进行功能测试的时候，输入是需求。如果需要进行MDV ，则需要对需求进行约束，也就是我们需要对需求进行形式化。需求的形式化，便于我们很方便的转换何曾为测试模型。
需求的形式化，就是需要对需求的表述，从自然语言转换成为UML的形式。在测试中，主要采用UML的usecase图和活动图来表述。
解决了需求的形式化，就要求在需求导入的时候，必须导入活动图，否则就需要测试需求分性做更多的工作，自己来解决没有必要需求，自己来表述的问题了。这样会导致理解的偏差和测试的不足。
