认识达内从这里开始

软件测试是我们在开发软件过程中需要实施的一项测试工作内容，而今天我们就一起来了解一下，软件测试中的模型测试都有哪些优势。

基模测试的优点很多。相对于手动设计(编写)单个测试用例，建立测试模型意味着有必要考虑和确定被测系统的整体行为。根据我们的经验，反之这促使了组织间的交流以便把要求建立这样一个模型的各方都汇集起来，既有利于协作又促进共同理解。

当从一个单一的模型生成大量测试用例时，维护也被简化了，而且更新模型一次并重新运行生成器会可以立刻更新所有测试用例，而不要单独重新运行几百个测试用例。

一个精心设计的测试模型表现出了作为一个整体的被测系统的被选方面。被允许和支持的测试值而不是单个测试值的范围应该在测试模型中被发现并表示。不利用测试(模型)设计师把开发人员和领域聚到一起是不可能。也许基模测试应用中通常观察到的大的好处是：建设和共享对系统的限制和功能的明确理解，并把所有的假设都列到表格中。

当这种理解被记录到一个测试模型中，某种程度上它就成了一个可执行的规范，因为它可以被用来生成测试用例以实施。然后，不断的测试用例将验证被记录的理解也与实施一致。如果不是这样，就有待达成一个新的共同的理解，细化的模型，或不变的实施。

当然，该测试模型不能充分地描述该被测系统的所有可能的行为，或者它会变得和实现本身一样复杂甚至更复杂。因此，需要为建模内容选择一个合适的范围，为测试模型选择一个相当高的抽象级别。测试模型的设计需要把重点放在系统的核心部分，该核心部分被视为对严格的测试和验证重要。这个变化要跨几个系统，例如，安全关键系统可能比不太重要的应用包含了更详细的内容。因为基模测试过程不仅提供了所生成的测试用例，而且还有对系统规范和功能的严格审查，这个审查被要求用来生成测试模型。我们发现这对一个高层次的系统概述和核心关键要素的详细研究特别有用。

从测试生成的角度来看，基模测试的主要好处在于它的自动模型探索能力且在探索测试模型中不挑测试生成器。根据我们的经验，一个领域(测试)要查看系统并对它是如何工作的做出某些内在假设很简单，凸显一些东西，在手动设计测试用例中重复这些假设。手工操作也很昂贵，在各种不同的开发迭代中很少有时间或资源来广泛测试一大组不同的选项，或者保证一个大堆测试得以审查和更新。

使用测试模型为基础的测试生成器的限制较少。有一个好的测试模型，该工具就可以结合不同的模型覆盖准则探索不同场景并把随机模型覆盖融合进去，就避免了一些专业偏差还扩大了探索选项集合。自然，该工具无法避免模型内的偏差，但是当几位一起进行模型工作(甚至部分，如审查)时，模型具有巨大偏差的可能性就小了，工具将更加不知疲倦更彻底地探索模型。在现有计算能力和测试执行时间内，它可以生成并执行大量测试用例而不会厌倦，并在每次迭代中重复同样的过程，只需更新单个测试模型就行。

许多关于使用基模测试的案例研究已经发表，也许这其中广泛的就是微软协议文档工作[ACM]。微软研究表明：把所有元素(包括学习曲线等)考虑在内时使用基模测试对比手工脚本有42%的利益。它还强调了许多我们所观察到的接下来将要讨论的问题。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。