MBT的优点
基模测试的优点很多。相对于手动设计（编写）单个测试用例，建立测试模型意味着有必要考虑和确定被测系统的整体行为。根据我们的经验，反之这促使了组织间的交流以便把要求建立这样一个模型的各方都汇集起来，既有利于协作又促进共同理解。
当从一个单一的模型生成大量测试用例时，维护也被简化了，而且更新模型一次并重新运行生成器会可以立刻更新所有测试用例，而不要单独重新运行几百个测试用例。
一个精心设计的测试模型表现出了作为一个整体的被测系统的被选方面。被允许和支持的测试值而不是单个测试值的范围应该在测试模型中被发现并表示。不利用测试（模型）设计师把开发人员和领域专家聚到一起是不可能。也许基模测试应用中通常观察到的最大的好处是：建设和共享对系统的限制和功能的明确理解，并把所有的假设都列到表格中。
当这种理解被记录到一个测试模型中，某种程度上它就成了一个可执行的规范，因为它可以被用来生成测试用例以实施。然后，不断的测试用例将验证被记录的理解也与实施一致。如果不是这样，就有待达成一个新的共同的理解，细化的模型，或不变的实施。
当然，该测试模型不能充分地描述该被测系统的所有可能的行为，或者它会变得和实现本身一样复杂甚至更复杂。因此，需要为建模内容选择一个合适的范围，为测试模型选择一个相当高的抽象级别。测试模型的设计需要把重点放在系统的核心部分，该核心部分被视为对严格的测试和验证最重要。这个变化要跨几个系统，例如，安全关键系统可能比不太重要的应用包含了更详细的内容。因为基模测试过程不仅提供了所生成的测试用例，而且还有对系统规范和功能的严格审查，这个审查被要求用来生成测试模型。我们发现这对一个高层次的系统概述和核心关键要素的详细研究特别有用。
从测试生成的角度来看，基模测试的主要好处在于它的自动模型探索能力且在探索测试模型中不挑测试生成器。根据我们的经验，一个领域（测试）专家要查看系统并对它是如何工作的做出某些内在假设很简单，凸显一些东西，在手动设计测试用例中重复这些假设。手工操作也很昂贵，在各种不同的开发迭代中很少有时间或资源来广泛测试一大组不同的选项，或者保证一个大堆测试得以审查和更新。
使用测试模型为基础的测试生成器的限制较少。有一个好的测试模型，该工具就可以结合不同的模型覆盖准则探索不同场景并把随机模型覆盖融合进去，就避免了一些专业偏差还扩大了探索选项集合。自然，该工具无法避免模型内的偏差，但是当几位专家一起进行模型工作（甚至部分，如审查）时，模型具有巨大偏差的可能性就小了，工具将更加不知疲倦更彻底地探索模型。在现有计算能力和测试执行时间内，它可以生成并执行大量测试用例而不会厌倦，并在每次迭代中重复同样的过程，只需更新单个测试模型就行。
许多关于使用基模测试的案例研究已经发表，也许这其中最广泛的就是微软协议文档工作[ ACM ] 。微软研究表明：把所有元素（包括学习曲线等）考虑在内时使用基模测试对比手工脚本有42％的利益。它还强调了许多我们所观察到的接下来将要讨论的问题。
采用需求及潜在问题
如果基模测试这么棒，为什么我们不一直用它呢？因为基模测试的初始成本较高，需要多样化的技能，它的利益却难以衡量。初始成本用于获取技能，学习测试建模的思维模式，并创建测试模型。无法证明自己的系统和域的好处的话，这样的初始成本很难被接受，如果所有人至今为止都一直手写测试，就很容易安于现状而不会为组织去尝试不同的和未知的事物。
创建良好的测试模型需要良好的编程技巧（及一般的软件工程技能），测试专业知识，建模专业知识和领域专业知识。这是一个多样化的技能组合，很难靠单个专家获得。而当有这样的专家时，管理层往往快速将他们分配定位成为一个开发而不是测试。同样，管理层基本不会提供各种昂贵的资源（如领域专家，软件开发人员）用于和软件测试的筒仓相关的活动，即使他们需要成功的测试活动。从模型设计角度来看，测试模型也并不是一个传统的顺序计算机程序，而是指导测试生成器的一个规则和行动的集合，它本身与传统的顺序程序设计有点不同。
一般情况下，当开始进行评估，（可能的话）采用基模测试方法的时候，或许最大的障碍就是需要采用一个完全不同类型的思维模式。有必要把重点放在考虑SUT的整体功能和目的或者它所选择的一部分上，而不要独自想着单用场景和单个测试用例。这需要与组织中的其他专家密切合作，这就可能需要对一般的工作实践稍作改变。
这也强调了关于计算优点的问题。如果管理被用来测量如被写测试用例的数量之类的东西，他们要么就看不到测试用例（只有一个测试模型）要么就是一大堆测试用例（所有生成的）。 [ GRAHAM ]中已对该问题及其可能结果做了详细说明，[ GRAHAM ]中测试人员最初恶评如潮，后来因为已观察到的影响而被承认。还有，最初获得用该工具生成测试用例的启动成本会显得使用这种规格没有任何价值。然而，它可以是建立共同理解并将之记录在一个可执行的规范（测试模型）中的过程中最有用的部分。正如在任何自动化测试工作（或任何其他工作）中 ，管理支持，沟通和理解都是非常重要的。
该方法和测试生成结果的有效性取决于设计的测试模型的质量。没有一个高质量的模型，就没有测试生成可以生产好测试。因此，投入足够精力去产生好模型并和其他专家一起检验它很重要。
生成一大组测试用例也能生出一大组需要进行分析的结果。根据我们的经验，当考虑实施基模测试时，许多人通常认为这就是一个潜在的问题。然而，实践中，我们已经观察到：这问题不大，因为测试生成基本是使用某种形式的场景或（对系统具体部分分析关注的）专注模式指导的。然而，模型设计仍应仔细考虑诸如有趣元素有哪些以及它们从所有可能输入到测试的组合，所以测试生成的重点应放在最有用的方面。至于结果分析，积极地说，当更多的精力可以从手动复制测试脚本中被转移到分析结果时，这就可以使工作更有趣而不那么单调乏味。总之，测试自动化应该一层层往上建。
有效实施基模测试需要将之建于一个好的基础的测试自动化平台之上。如果它无法写出可以自动化执行的测试脚本，那么继续进行基模测试去产生这样的脚本就毫无意义。建立基础的测试自动化需要良好的水平，这个水平上，基模测试过程可作为一个额外工具来提高总体质量。例如，如自动控制SUT的GUI进行测试一类的事，应该在测试一个基于GUI的应用程序时就得到解决。
过程
使用基模测试的过程可以用四个简单的步骤描述为一个迭代过程，图3所示。开始时，我们通常为系统所选的小一部分创建一个最初的测试模型。这使我们能够学习基本工具和框架，并看看他们是如何连接以形成整个测试环境并在该环境中定位基模测试工具。 图4.过程模型设计
一旦拥有了测试模型的工作版本，我们就用它来生成并执行测试用例。生成的测试用例的执行可以在所谓的“在线基模测试”中与他们的生成进行交错，或在所谓的“离线基模测试”中的一个单独的阶段中完成。这就很快地给我们提供了对模型情况和对当前模型设计中被测系统的那些部分的反馈。
当我们已经生成并执行测试用例时，我们分析出被测系统上及测试模型中错误的结果。
在令人满意的水平上，我们开始一步步地扩展模型并添加更多功能。这意味着我们要从头重复这些步骤及这个过程，直到在我们觉得我们已得到了一个描述有趣元素的合适水平上的测试模型。
一些测试模型可以用来设计系统的不同部分。测试场景被用来指导测试生成，或者它可以使用不同的模型和生成器配置去重点关注不同的区域和观点。
我们采用的一种做法是帮助合作伙伴开始使用开源工具理解这个概念，看到好处，并学习技术。开源工具也有适应特定需求和环境的优点。一旦基本技术，及其实施和效益被更好的理解了，就可以选取不同的前进道路，包括转用（从广泛付费支持和大规模开发先进算法的资源获益的，如Spec Explorer和Conformiq Designer的）商业工具这个选择。然而，在许多情况下，我们早已经看到了开源选项提供的不错利益。
可以运用基模测试的一个好地方是有很多变量和很多（需要进行测试的）交互的地方。一旦我们意识到把这个手动缩放到要求的复杂度和质量水平很昂贵的时候，基模测试就是一个值得考虑的好技术。另一个不错的地方是安全性软件，在这种软件中必须完全相信一个好的几乎无错的解决方案已被建成。
结论
基模测试可能听起来像一个很酷但却吓人的技术，很难上手。然而，经过一些初步学习之后，它并不比常规测试和测试自动化更复杂。我们一般采取的做法是建议一开始（最好是在熟悉这个概念的人的帮助下让对该方法及其潜力超振奋的人）把它用在一个较小的试点项目中。我们通常以现有的测试自动化和测试脚本为出发点，以这些为基础一次一小部分地开始建立测试模型。至于抽象层，一个好的起点可以是：（通过利用现有的SUT的API去定义可能采取的行动或关注可以观察到很多变化且很难测量手动测试的地方，在该系统复杂／易出故障的部分或在核心关键功能上，构建一个促进共同理解的高层次的总体模型中的）任何东西。
作者介绍：
TeemuKanstrén是一名资深科学家，目前在芬兰VTT技术研究中心工作，他还是多伦多大学的一名客座博士后。他的工作涉及：以改进行业现状，和生产实际有用的解决方案并帮助行业伙伴接受采纳它们为目的的自动化测试领域的研究和开发。他软件行业工作了好几年，已帮助众多合作伙伴开发和采用以基于模型的测试技术为基础的测试自动化解决方案。他是开源的基于模型的测试工具OSMO Tester的主要创造者。2010年他获得了芬兰大学测试自动化和基于模型的测试的博士学位。 |