Testing 基于模型的测试策略

您在基于模型的测试中使用了哪些策略

• 您是否专门为您使用它 集成测试，或分支测试 外派到其他地区 （单元/功能/系统/规范验证）
• 您是构建专注的“密封”模型，还是随着时间的推移发展复杂的onibus模型
• 在产品周期中，您何时投资创建MBT
• 您专门为MBT创建什么样的基本测试库
• 为了更好地支持MBT，您在功能性基本测试库中做了哪些改变？

---

我们没有做过任何/太多的I&t，并且几乎完全使用单元测试，只进行了一些系统测试。但我们的重点显然是单元测试。我对我们构建/提供的API非常严格，所以假设是，如果它自己工作，它将协同工作，并且还没有太多错误

我们的模型专注于单一目的/模块，依赖性尽可能少

重点总是尽可能早地开始（TDD），但不幸的是，我们并不总能做到这一点。问题是，你总是要把它卖给管理层，然后这很难，因为虽然测试提高了稳定性（总体质量保证），但是来自外部（技术外部）的人在不好的事情发生之前无法真正理解这意味着什么

---

因为我们使用PHP，所以我们使用PHPUnit进行单元测试。总之，我们使用各种不同的工具进行CI：

[有几篇文章值得一读。Stack Overflow不允许我发布多篇文章，因此我将它们汇总在一篇博客文章中，并在回答的末尾链接。]

首先，简要说明条款。我倾向于使用詹姆斯·巴赫（James Bach）对测试的定义，即“为了评估产品而质疑产品”。所有测试都依赖于被测试应用程序的/心智/模型。然而，基于模型的测试这一术语通常用于描述通过自动化开发模型的编程。例如，可以指定应用程序可能处于的许多状态、这些状态之间的各种路径，以及关于在这些状态之间的转换中应该发生什么的某些断言。然后，可以让脚本在状态模型中执行转换的半随机排列，记录可能感兴趣的结果

这里有真正的成本：建立一个有用的模型，创建探索它的算法，记录系统，让人们能够筛选出有趣的故障，等等。成本是否合理与你想回答的问题有很大关系？一般来说，从“我想知道什么？我怎样才能最好地了解它？”开始，而不是寻找一种有趣技术的用途

综上所述，一些优秀的测试人员已经从基于模型的自动化测试中获益匪浅。有时我们会遇到一些关于被测应用程序的重要问题，这些问题最好通过自动化、高容量的半随机测试来探索。Harry Robinson（基于模型的测试的主要理论家和支持者之一）描述了一个非常丰富多彩的例子，在这个例子中，他使用基于模型的测试（使用ruby的Watir库编写）在Google驾驶指南中发现了许多有趣的bug

罗宾逊在贝尔实验室、微软和谷歌等公司成功地使用了MBT，并撰写了许多有用的文章

Ben Simo（另一位伟大的测试思想家和作家）也写了很多值得一读的关于基于模型的测试的文章

最后，有几点需要注意：为了更好地利用战略，需要探索其优势和劣势。为此，詹姆斯·巴赫（James Bach）就基于模型的测试的局限性和挑战进行了精彩的演讲。这篇博文是巴赫一小时演讲的链接（以及相关幻灯片）。[4]

最后，我要讲到Boris Beizer所谓的杀虫剂悖论：“你用来预防或发现虫子的每一种方法都会留下一些微妙的虫子，而这些方法是无效的。”脚本测试（无论是由计算机还是个人执行）特别容易受到杀虫剂悖论的影响，每次执行同一个脚本时，倾向于发现越来越少的有用信息。人们有时会转向基于模型的测试，认为它可以绕过农药问题。在某些情况下，基于模型的测试可能会发现比给定的脚本测试更大的错误集……但我们应该记住，它仍然受到杀虫剂悖论的根本限制。记住它的局限性——从MBT能够很好地解决的问题开始——它有可能成为一种非常强大的测试策略

---

上面提到的所有文章的链接都可以在这里找到：

最好的方法是自己尝试一个基于模型的测试工具。这是了解基于模型的测试是否适合您的环境的最佳方法。好的策略是什么

我建议您使用All4Tec的“MaTeLo”工具（www.All4Tec.net）

“MaTeLo是一个用于黑匣子功能和系统测试的测试用例生成器。按照基于模型的测试方法，MaTeLo使用马尔可夫链对测试进行建模。此统计数据允许以系统的方式进行产品验证。效率是通过减少所需的人力资源、增加模型重用和增强测试策略相关性（由于可靠性目标）来实现的。MaTeLo独立且用户友好，为验证活动提供从测试脚本到真正的测试工程，并专注于测试的真正附加值：测试计划”

您可以申请评估许可证，然后自己试一试

---

你可以在这里找到一些例子：

Harry Robinson，MBT图书的作者，曾在谷歌和微软工作过很多，他在这个网站上提供了一些很好的信息和白皮书