PDF基于模型的测试：它的现状？
即使基于模型的测试 (MBT) 仅部分实现高期望，它对效率和有效性也有积极影响。
Robert V. Binder、Bruno Legeard 和 Anne Kramer
您可能听说过 MBT（基于模型的测试），但像许多没有使用过 MBT 的软件工程专业人士一样，您可能对其他人使用这种测试设计方法的经验感到好奇。
从 2014 年 6 月中旬到 2014 年 8 月初，我们进行了一项调查，以了解 MBT 用户如何看待其效率和有效性。2014 年 MBT 用户调查是 2012 年类似调查的后续 (http://robertvbinder.com/real-users-of-model-based-testing/)，向所有评估或使用过任何 MBT 方法的人开放。它的 32 个问题包括 2013 年高级自动化测试用户大会上分发的一项调查中的一些问题。一些问题侧重于 MBT 的效率和有效性，提供了管理人员最感兴趣的数据。其他问题更具技术性，旨在验证通用的 MBT 分类方案。通用的分类方案可以帮助用户理解通用多样性和具体方法。
2014 年的调查提供了 MBT 实践现状的真实写照。本文介绍了调查结果的一些亮点。完整结果可在 http://model-based-testing.info/2014/12/09/2014-mbt-user-survey-results/ 上查阅。
调查受访者
大量人员收到了 2014 年 MBT 用户调查的参与邀请，遍布欧洲和北美。此外，它还发布到各种社交网络群组和软件测试论坛。几家工具提供商帮助分发了邀请。最后但并非最不重要的是，ETSI（欧洲电信标准协会）通过在高级自动化测试用户大会上通知所有参与者来支持这项倡议。
截止日期前，共有 100 位 MBT 从业人员做出了回应。并非所有参与者都回答了每个问题；如果答案数量明显少于 100，则会标明答案数量。这些部分响应集的百分比基于特定问题的实际响应数量。
绝大多数受访者（86%）来自企业。其余 14% 代表研究机构、政府机构和非营利组织。组织的规模从 3 名员工到 30 万名员工不等（图 1）。
如图 2 所示，几乎一半的受访者已从评估和试点阶段转变为推广或普遍使用阶段。平均而言，受访者有三年的 MBT 经验。实际上，答案范围从零（表示“刚刚开始”）到 34 年不等。
为了了解 MBT 相对于其他测试设计技术的重要性，调查询问了 MBT、手工编码测试自动化和手动测试设计在总测试工作量中所占的百分比。这三种测试设计方法各约占总测试工作量的三分之一。因此，MBT 不是边缘现象。对于那些使用它的人来说，它的重要性与其他类型的测试自动化相当。
近 40% 的受访者来自嵌入式领域。企业 IT 占另外 30%，Web 应用程序约占 20%。系统被测的其他应用领域包括软件基础设施、通信、游戏，甚至教育。确切的分布如图 3 所示。
外部 MBT 顾问的角色比预期的要小。尽管我们最初推测 MBT 主要由外部驱动，但调查显示了不同的情况。大多数（60%）回答调查的人员是内部 MBT 专业人员。只有 18% 的受访者是外部 MBT 顾问，22% 是 MBT 应用领域的研究人员（图 4）。
MBT 是否如预期般有效？
在我们的项目中，我们观察到人们对 MBT 的期望通常非常高，甚至极高。“MBT 是否满足期望？” MBT 用户调查询问了五个不同类别的期望是否得到满足：测试是否变得更便宜；测试是否变得更好；模型是否正在帮助管理系统在测试方面的复杂性；测试设计是否更早开始；以及最后，模型是否正在改善利益相关者之间的沟通。
图 5 显示了每个类别的响应数量和满意度。答案反映出略微的失望。MBT 在成本降低、质量改进和复杂性方面并未完全满足极高的期望，但仍有超过一半的受访者表示部分或完全满意（图 5 中的绿色条表示）。对于其余两个类别，MBT 超出了预期。将模型用于测试目的肯定可以改善利益相关者之间的沟通，并有助于更早地启动测试设计。
总体而言，受访者认为 MBT 是一项有用的技术：64% 的人认为它在某种程度上或非常有效，而只有 13% 的人认为该方法无效（图 6）。超过 70% 的受访者表示，他们非常有可能或极有可能继续使用该方法。在 73 位受访者中，只有一位拒绝了这个想法。然而，参与者是自我选择的，因此我们不能排除对 MBT 持积极态度的轻微偏差。
为了获得更多关于有效性和效率的量化数据，调查提出了三个相当具有挑战性的问题
• MBT 在多大程度上减少或增加了遗漏的错误数量——即交付前没有人发现的错误数量？
• MBT 在多大程度上降低或增加了测试成本？
• MBT 在多大程度上缩短或延长了测试持续时间？
显然，这些问题很难回答，并且不可能从调查中获得的 21 个答案中推断出具有统计意义的信息。只有一位受访者明确否定了遗漏错误的数量。所有其他受访者都提供了积极的数据，其中两个答案不合逻辑。
在成本方面，调查询问受访者成为熟练的 MBT 用户需要多少小时。答案从零到 2,000 小时的技能开发不等，中位数为两周工作时间（80 小时）。
什么是基于模型的测试？
基于模型的测试用于软件开发的所有阶段，最常用于集成测试和系统测试（图 7）。一半的调查受访者报告进行了基于模型的集成测试，约四分之三的受访者报告进行了基于模型的系统测试。几乎所有受访者都使用模型进行功能测试。MBT 在性能、可用性和安全性测试中发挥了次要作用，每项的使用率均低于 20%。
只有一位参与者认为难以将 MBT 融入敏捷方法，而 44% 的人报告在敏捷开发过程中使用 MBT，其中 25% 处于高级阶段（推广或普遍使用）。
在模型重点方面存在明显的偏好：59% 的 MBT 模型（此处将用于测试目的的任何模型称为 MBT 模型）由调查受访者使用，仅关注行为方面，而 35% 的模型同时具有结构和行为方面。纯粹的统计模型发挥了次要作用（6%）。对于符号类型，这种趋势更加明显。图形符号占主导地位，为 81%；只有 14% 是纯文本 MBT 模型——即，它们不使用任何图形元素。然而，使用了各种组合。一位受访者非常清楚地指出：“我们每个被测系统使用不止一个模型。”
独立于设计建模的测试建模
请注意，超过 40% 的受访者没有在其他开发阶段使用建模。只有八位参与者表示，他们重用了分析或设计中的模型，而没有进行任何修改。图 8 显示了不同程度的重用。十二位参与者表示，他们编写了完全不同的模型用于测试目的。其他人或多或少地调整了现有模型以满足测试需求。这明确表明，即使其他开发方面不是基于模型的，也可以使用 MBT。这一结果与通常认为只有在需求和设计也使用建模时才能使用基于模型的测试的观点相反。
基于模型的测试与手动测试兼容
2014 年 MBT 用户调查还表明，自动化测试执行不是应用基于模型测试的唯一方式。当被问及生成的工件时，绝大多数人提到了用于自动化测试执行的测试脚本，但超过一半的受访者还从 MBT 模型中生成了用于手动执行的测试用例（见图 9）。三分之一的受访者手动执行了他们的测试用例。此外，工件生成甚至不必是基于工具的：12% 的人手动从模型中获得测试用例；36% 的人至少部分使用了工具；53% 的人建立了完全自动化的测试用例生成过程。
结论
一百位参与者在 2014 年 MBT 用户调查中分享了他们的经验，并为本次分析提供了宝贵的意见。尽管该调查不具有广泛的代表性，但它提供了在广泛的环境和组织中积极使用 MBT 的概况。对于这些用户而言，即使 MBT 仅部分满足了一些极高的期望，它对效率和有效性也产生了积极影响。绝大多数人表示他们打算继续使用模型进行测试。
关于通用的分类方案，响应证实了 MBT 方法的多样性。没有两个答案是相同的。这可以结束关于 MBT 模型是否可以归类为系统模型、测试模型或环境模型的讨论。它不能。任何用于测试目的的模型都是 MBT 模型。通常，它在不同程度上关注所有三个方面。对这方面进行分类似乎是一项空闲的任务。一些技术问题没有提供有用的信息。显然，“抽象程度”的 MBT 模型本身就太抽象了。似乎很难将 MBT 模型归类为“非常抽象”或“非常详细”。
工作尚未结束。我们仍在寻找相关性和趋势。如果您对一般的 MBT 以及特别是对调查有具体问题或想法，请联系我们。
喜欢它，讨厌它？请告诉我们
Robert V. Binder ([email protected]) 是一位高可靠性企业家，也是 System Verification Associates 的总裁。他开发了数百个应用系统和高级自动化测试解决方案。作为微软开放协议计划的测试流程架构师，他领导将基于模型的测试应用于微软的所有服务器端 API。他是权威著作《面向对象系统测试：模型、模式和工具》以及其他两本书的作者。
Bruno Legeard([email protected]) 是弗朗什-孔泰大学的教授，也是 Smartesting 的联合创始人兼高级科学家，在基于模型的测试领域被国际公认为专家和知名演讲者。他曾在众多测试和软件工程会议上发表演讲和主题演讲。Bruno 是第一本面向行业的基于模型的测试书籍《实用基于模型的测试：工具方法》的合著者。
Anne Kramer ([email protected]) 拥有物理学博士学位，并在 sepp.med gmbh 担任项目经理和高级流程顾问，sepp.med gmbh 是一家服务提供商，专门为复杂的安全相关领域提供集成质量保证的 IT 解决方案。她教授各种认证培训课程，包括 iSQI（国际软件质量研究所）认证的基于模型的测试员。与 Bruno Legeard 一起，她是建立 ISTQB（国际软件测试资格认证委员会）基于模型的测试员基础培训计划的作者组成员。
© 2014 1542-7730/14/1200 $10.00
最初发表于 Queue 第 13 卷，第 1 期—
在 数字图书馆 中评论本文
更多相关文章
Sanjay Sha - 企业应用程序的可靠性
企业可靠性是一门学科，旨在确保应用程序以一致、可预测且经济高效的方式交付所需的业务功能，而不会损害诸如可用性、性能和可维护性之类的核心方面。本文介绍了一套核心原则和工程方法，企业可以应用这些原则和方法来帮助他们驾驭复杂的企业可靠性环境，并交付高度可靠且经济高效的应用程序。
Robert Guo - MongoDB 的 JavaScript Fuzzer
随着 MongoDB 随着时间的推移变得更加功能丰富和复杂，开发更复杂的方法来查找错误的需求也在增长。三年前，MongoDB 将自制的 JavaScript fuzzer 添加到其工具包中，它现在是我们最多产的错误查找工具，在两个发布周期中负责检测到近 200 个错误。这些错误涵盖了 MongoDB 组件的各个方面，从分片到存储引擎，症状范围从死锁到数据不一致。fuzzer 作为 CI（持续集成）系统的一部分运行，在 CI 系统中，它经常捕获新提交代码中的错误。
Terry Coatta, Michael Donat, Jafar Husain - EA 的自动化 QA 测试：事件驱动
对于数百万游戏迷来说，在 Electronic Arts 担任 QA（质量保证）测试员的职位似乎是一份梦想的工作。但从公司的角度来看，与 QA 相关的开销可能看起来非常可怕，尤其是在大型多人游戏时代。
James Roche - 在质量保证中采用 DevOps 实践
在很长一段时间里，软件生命周期管理都是一项受控的活动。产品设计、开发和支持的持续时间足够可预测，以至于公司及其员工围绕产品发布安排他们的财务、假期、手术和合并。当开发人员忙碌时，QA（质量保证）就很轻松。随着发布周期的编码部分接近尾声，QA 接管，而支持部门开始加强。然后，当产品发布时，开发人员松了一口气，休息了一下，然后再次开始循环，而支持人员则过渡到忙于支持新产品。
© 保留所有权利。