概述
使用模型来描述系统的行为对于测试开发团队来说是一种成熟、主要的优势。模型在贯穿整个产品的生命周期中会在很多地方使用，例如提高产品规格质量，代码生成，可靠性分析和测试生成。这篇文章将聚焦于模型给测试带来的效益，并且回顾一下那些阻碍基于模型测试的的历史问题和展现如何克服这些苦难。另外，将在两个实际程序中展现基于模型的方法，一个是呼叫流程特性，另一个面向数据库系统的流程的UI。
大纲
1、合理建模
2、产品使用规格一样的行为模型
3、使用模型进行测试设计和生成
4、案例学习：长距离呼叫流程特性
5、案例学习：基于用户界面/数据库系统的流程
6、结论
1、合理建模
模型在许多学科被用例理解，识别和开发系统。从DNA和基因研究到新兴战斗机的研发，模型都被用例促进理解和为产品开发提供一个可复用的框架。在软件工程的过程中，模型作为现代面向对象分析和设计的部分方法被主要的面向对象的方法论所接受。关于模型的测试开发，可靠性分析的应用文章和书籍在近20年中层出不穷；但是，除了引领世界的大公司，测试创新仍然是一个缺乏度量和低复用的人工的过程。这篇文章的目的是为测试创新探求一种新方法，基于图形化模型，可以描述被测系统的行为；和一系列可以使得测试生成通过模型的启发。
建模是一种非常经济的获得系统知识并把这种知识在系统发展过程中加以复用的方法。对于测试团队来说，这条信息和金子一样重要。测试工程师百分之多少的任务是花时间去理解被测系统正确的行为（而不是它的行为）。一旦信息被理解，它如何传递给下一个工程师，下一个发布，需求变更？如果在在测试计划中，简直太幸运了，但是它更多的时候在测试脚本中被埋葬，遗漏，等待被发现。通过特别的输入，得到描述系统期望行为的系统建模，这样团队现在有了结构化化分析系统的机制。场景，被描述为一系列系统的行为（模型中也是这样定义），对系统的正确响应也会被定义。在被测系统、可用资源、可交付的范围这些语境中，测试范围被理解，测试计划被开发。最大的好处是重用，所有这些工作都不会丢失。下一个测试循环在这个循环结束时就可以开始。如果产品有了新的功能，它们要被增量地加到模型中去，如果质量需要提高，模型需要改进而测试需要扩展。如果有新的团队成员，他们能很快地通过这些模型来跟上当前的步伐。
2、规格
前提：被测的软件处于集成或者在开发过程中的系统测试阶段。（图一） 暗含的测试对象是为了保证从外部视角来看系统满足需求。关注的
焦点不在如何执行，而在于用户如何评估它们。测试将根据规格衡量系统的整体的功能的编译，而不是根据代码覆盖率。这些测试有时候被理解为验收测试，这是一种传统的黑盒测试的执行实施。
