是的 - 适用时。基于模型的测试只是另一种测试设计技术——但当被测应用程序（或被测特征区域）表现得像一个有限状态机时，它工作得很好。

在 Microsoft，我们已经广泛使用基于模型的测试来测试像状态机一样的功能。协议测试可能是最大的例子（TCP/IP 或 SIP 等协议）是状态机的很好例子，并且可以使用 MBT 进行很好的测试（我们使用Spec Explorer来生成模型和测试。

本次讨论中还有一些关于使用 Spec Explorer 进行基于模型的测试的其他成功案例。

我相信基于模型的测试不仅可以用于从模型生成测试用例，还可以用于模型检查。当完全测试实现过于昂贵（硬设置，昂贵的原型设计）时，检查抽象模型的正确性可能是明智的。

真实例子

在我们的系统中，用户可以同时工作，但不能执行写入/读取共享实体的任务。当这种情况发生时，UI 应该停用被阻止任务的按钮。我们有许多共享实体和许多使用它们的任务，因此分配将被任务锁定的实体的正确组合并预测哪个任务将被哪个任务阻止是相当困难的。

为了验证分配，我编写了一个简单的工具，它根据任务共享的给定实体矩阵打印哪些任务阻止了哪些任务。没有正式的检查器，矩阵是否正确。我是决定锁是不是太激进/太少的神谕。

得到教训

1. 我做这个模型检查肯定太晚了，因为我们已经实现了系统，我们发现锁定的整个想法存在某种缺陷，因为它没有给我们正确级别的锁定控制，即可能没有配置（矩阵）将完全满足该要求。

2. 然而，模型检查帮助我们找到了锁的次优配置。

3. 模型检查不能代替真实系统的测试。后来发现有些锁实现不正确。

4. 模型检查帮助我们确定了一些用于测试真实系统的关键测试用例。

就个人而言，基于模型的测试完全让我印象深刻！

我喜欢认为我不是那里最愚蠢的人，但即使在与 HWTSAM 坐下来，卷起袖子并试图进入它之后，我也无法让它在我正在测试的基于 Web 的应用程序中工作在我尝试的时候。

也就是说，我不认为这意味着它不能工作，我认为这意味着有效的基于模型的测试有一个陡峭的学习曲线，然后你才能获得任何结果和超越其他技术的现实世界的好处。

我还认为，在“现实世界”测试中，时间很紧，人们没有那么多时间花在学习基于模型的测试上（在 Visual Studio 中使用Spec Explorer），目前投入的时间太多了结果。

像Specflow这样的东西，在没有模型的情况下自己编写测试，在敲击快速测试用例时让我物有所值。