模型驱动的测试是否适用于实际应用？

#1 楼

是的-适用时。基于模型的测试只是另一种测试设计技术-但是，当被测应用程序（或被测特征区域）的行为类似于有限状态机时，该技术可以很好地运行。对于行为类似于状态机的功能，广泛使用基于模型的测试。协议测试可能是最大的例子（TCP / IP或SIP等协议是状态机的很好例子），可以使用MBT很好地进行测试（我们使用Spec Explorer生成模型和测试。

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

#2 楼

我认为基于模型的测试不仅可以从模型生成测试用例，而且可以用于模型检查。当完全测试实现过于昂贵时（复杂的设置，昂贵的原型制作），检查抽象模型的正确性可能是明智的。

真实示例

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

为了验证分配，我编写了一个简单的工具，该工具根据任务共享的给定实体矩阵，打印哪些任务阻止了哪个任务。没有正式的检查员，矩阵是否正确。我是一个先知，决定锁是否不是太多/太少攻击性。

吸取的经验教训


由于我们已经实施了该系统，所以我进行此模型检查肯定为时已晚，并且我们发现锁定的整个想法在某种程度上存在缺陷，因为它没有给我们正确的锁定控制级别，即，可能没有能够完全满足该要求的配置（矩阵）。
但是，模型检查可以帮助我们找到锁的次优配置。
模型检查不能代替对实际系统的测试。发现某些锁后来被错误地实施。
模型检查帮助我们识别了一些用于测试实际系统的关键测试用例。

#3 楼

就我个人而言，基于模型的测试完全可以使我全神贯注！它，我根本无法使其在我尝试时正在测试的基于Web的应用程序上运行。我认为，这意味着有效的基于模型的测试需要一个陡峭的学习曲线，才能获得任何结果，并且比其他技术更能给现实世界带来好处。太紧了，人们没有太多时间花在学习基于模型的测试上（使用Visual Studio中的Spec Explorer），目前只是花了太多时间而没有足够的结果。

类似在没有快速模型的情况下，Specflow和自己编写无需模型的测试可以让我付出更多的努力。