EMBRACE THE NEW ERA OF INDUSTRY
来源: 日期:2024-05-29
本文翻译自:Understanding Model-Based Testing: Benefits, Challenges, and Use Cases
原文作者:Qt Group质量保证市场营销主管Sebastian Polzin
审校:Jinjing Li
对于那些寻求系统化和条理化测试方法的测试工程师而言,模型驱动测试提供了一个强有力的工具集。这种方法涉及利用模型来指引测试流程。
除了创建测试模型,你还可以对应用程序行为、应用程序结构、数据和环境等进行建模。在本文中,我们将重点关注测试——即考虑测试哪些方面以及如何进行测试来推动建模。
让我们深入探讨模型驱动测试涉及的内容及其优点、面临的挑战,以及它最有效的应用场景。
模型驱动测试是一种围绕模型使用的测试方法。与需要逐一审视每一个复杂细节的传统测试不同,模型驱动测试采取了一种更宏观的方法,能够让你专注于核心功能,而不需纠结于每一个小细节。
让我们来看一个例子——假设你在测试一个地址簿应用程序。在这种情况下,你可以对以下行为进行建模:
启动应用程序
创建新文件
添加联系人
移除联系人
保存文件
打开文件
退出应用程序
这种方式不是像开发者那样对整个应用程序进行建模,而是把握需要优先考虑的测试用例。这有助于你组织测试用例和最终的测试脚本,这些脚本会用在测试用例执行的自动化中。
通过关注高层次的抽象,模型驱动测试可以帮助你避免陷入细节。这种策略性方法允许你跳过不必要的测试用例,优化测试工作和资源。
最终,这将带来更高质量的测试,聚焦关键功能。
模型有助于达成对需求的共同认识,并检测潜在的误解。它们使得向内外部利益相关者传达测试需求变得更加轻松。
例如,使用模型,你可以向管理层展示你的测试流程是什么样的,以及为什么需要额外资源。或者你可以向开发团队解释你当前的测试方式,并讨论某些部分为何未按预期工作。
模型提供的视觉辅助往往比口头讨论问题或查看抽象的测试脚本更有效。
在开发过程的早期阶段,更好的沟通同样有助于早期发现bug——这也是我们的第三个优点。
在传统的开发过程中,需求、设计和测试的步骤使用多种工具依序进行。由于测试是最后阶段,大多数缺陷——在之前阶段累积的——都是在流程的后期才被发现的。这使得修复它们既耗时又成本高昂。
模型驱动测试是进一步实现所谓的“测试左移”的一种方法。这意味着在时间线上的一个转变——测试在需求阶段就可以开始进行。
在实施之前,可以与项目利益相关者分享模型,以验证需求并识别对需求理解中的差异。如果你不能对某个对象建模,这也可能暴露出一个问题区域。
因此,缺陷可以更早地被发现和移除,从而降低整体开发成本。根据MathWorks的数据,与传统测试方法相比,节省的成本可以达到20%到60%。
虽然建模前期需要一定的投入,但它在实施和维护方面大大减少了工作量。
模型驱动测试依赖于测试用例的模块化特性。在传统测试方法中,应用程序的某个组件发生变更,可能需要修改每个测试用例。而在模型驱动测试中,你可以把测试用例看作像乐高一样的积木块,只需修正一个积木块,就能够使所有相关测试用例得到更新。
同时,当你学会以更有组织性的方法去实施时,也能节约时间。你能够找出最优先执行的测试用例,并避免任何无谓的重复工作。
从传统测试流程过渡到模型驱动测试需要一段时间的调整和学习。
并非所有测试工程师都擅长抽象建模。创建有效的模型要求具备抽象思维和归纳概括的技能。要取得成功,你需要保持对整个测试过程的宏观把控。
选择合适的抽象层次至关重要。过度抽象,测试的实用性可能降低;太过细致,则模型可能变得难以使用。
然而,抽象本身涉及到简化,并且可能会导致关键细节的丢失,从而忽视掉重要的内容。
虽然模型驱动测试是一个强大的工具,但它可能不适合每个场景。如果您正在处理一个简单的应用程序,它可能过于复杂,从而导致过度工程化。
然而,对于那些能够在抽象模型层面进行工作的复杂软件系统及其团队来说,模型驱动测试显得非常重要。
模型驱动测试是一种强有力的方法,它使测试工程师能集中精力于应用程序测试的关键方面。通过把模型作为高层级抽象,团队可以提升测试质量、减轻工作量,并改善沟通。
尽管它需要转变思维方式和特定的技能,但其带来的好处远远超过所面临的挑战,尤其是在复杂的软件环境中。和所有测试方法一样,关键在于对测试方法周全的应用和根据特定项目需求做出适应性调整。