模型驱动测试在实际应用中是可行的技术吗？

Question

计算机科学家正在积极研究模型驱动的测试，作为自动测试应用程序的一种手段。我读过的论文很有趣，但到目前为止，建模技术似乎太不成熟，无法应用于“玩具”应用之外的任何东西。

你们中有谁以专业的身份使用过模型驱动的测试(即超越学校项目)，如果是的话，你的经历是什么？

Answer 1

我相信基于模型的测试不仅对从模型生成测试用例有好处，对模型检验也有好处。当完全测试实现太昂贵时，检查抽象模型的正确性是明智的(困难的设置，昂贵的原型)。

实例化

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

为了验证赋值，我编写了一个简单的工具，它根据任务共享的给定实体矩阵打印哪个任务块。没有正式的检查，矩阵是否正确。我是决定锁是不是太多/太少侵略性的先知。

经验教训

1. 我做了这个模型检查肯定太晚了，因为我们已经实现了系统，我们发现整个锁定的想法是有缺陷的，因为它没有给我们提供正确的锁控制级别，也就是说，可能没有完全满足这种需求的配置(矩阵)。
2. 然而，模型检查帮助我们找到了锁的次优配置。
3. 模型检查并不取代实际系统的测试。一些锁后来被发现实现不正确。
4. 模型检查帮助我们识别了许多用于测试真实系统的关键测试用例。

Answer 2

就我个人而言，基于模型的测试完全让我动脑筋！

我喜欢认为我不是世界上最愚蠢的人，但即使在和HWTSAM一起坐下来，卷起袖子，试着进入其中，我也无法让它在我尝试的基于网络的应用程序中工作。

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

我还认为，在“现实世界”测试中，时间紧迫，人们没有那么多时间花时间学习基于模型的测试(在Visual中使用规范探索者 )，现在的时间太长，没有足够的结果。

像光谱流这样的东西，以及在没有模型的情况下自己编写测试，在快速测试用例方面给了我更大的回报。