什么是基于模型的测试？
编辑团队
什么是基于模型的测试？
基于模型的测试 是一种软件测试技术，它将被测软件的运行时行为与模型预测的结果进行比较。模型是对系统行为的描述，它以输入序列、动作、条件、输出以及从输入到输出的数据流来表达。一个可用的模型必须易于理解、可重用和可共享，并且必须精确地描述被测系统。
目前有许多模型可供选择，每个模型都描述了系统行为的不同方面。常见的例子包括：
基于模型的测试描述了系统如何响应模型所确定的动作。输入动作后，检查系统的响应是否与模型预测一致。两者之间的任何偏差都表明软件存在缺陷或模型存在错误，两者都值得查找。
它是一种轻量级的系统验证形式化方法，既适用于硬件测试，也适用于软件测试。由于测试用例源自行为规范而非代码，因此该技术属于…… 黑盒测试 的家庭 软件测试技术.
基于模型的测试示例
理解行为模型最简单的方法就是实际操作一遍。下图模拟了一个简单的文本编辑任务，每个方框代表应用程序的一种状态，每个箭头代表用户可以执行的操作。
该模型解释了在记事本中创作诗歌的简化方法，以及与每个步骤相关的可能操作。对于每个操作，例如启动应用程序、输入诗歌或保存文件， 测试用例 可以生成测试用例并验证输出结果。例如，在同一张图表中执行不同的路径（例如，不保存就开始和结束），即可生成不同的测试用例，而无需额外的设计成本，这正是该技术的经济优势所在。
MBT 类型
基于模型的测试框架有两种类型，它们之间的区别仅仅在于测试步骤的生成时间：
- 离线/先验： 在执行测试套件之前生成测试套件。测试套件是测试用例的集合，在这种模式下，测试套件会像其他任何测试套件一样被存储、审查和重新运行。 自动化测试 资产。
- 在线/即时： 在测试执行过程中生成测试套件，其中下一步是根据系统对前一步的实际响应来选择。
离线生成适用于需要可审查、可重复测试套件的受监管环境。在线生成适用于针对有状态系统的长时间探索性测试，因为生成器可以根据实际响应而非预测响应做出反应。
基于模型的测试是如何工作的
无论使用哪个框架，该技术都遵循相同的五个阶段。每个阶段都会生成一个工件，供下一阶段使用，因此团队维护的是模型，而不是测试脚本。
- 第一步：构建模型。 将需求或规范翻译成绝对值tract 预期行为模型，定义状态、状态之间的转换以及触发每次转换的输入。
- 步骤 2：选择测试选择标准。 判断标准决定生成器何时停止。常见的标准包括：全状态覆盖（至少访问每个状态一次）、全转换覆盖（至少执行每个转换箭头一次）以及路径或数据流覆盖（用于更深入的探索）。
- 步骤 3：生成腹肌tract 测试用例。 该工具遍历模型并发出绝对值序列。trac满足所选标准的 t 个步骤，以及每个步骤的预期结果。
- 步骤 4：将腹肌具体化tract检验。 适配器层映射每个绝对值trac采取针对系统的实际行动，例如用户界面交互， API 调用或协议消息。此映射ping 只需编写一次，即可被所有生成的测试重复使用。
- 第五步：执行并作出判决。 针对被测系统进行具体测试，将每次观察到的响应与模型预测进行比较，并记录通过或失败的判定结果。 trac回到生成它的模型元素。
此 trac步骤 5 中创建的可执行性是实际的回报。当需求发生变化时，模型也会随之改变，受影响的测试用例会被重新生成而不是重写，这就是为什么团队需要频繁地进行测试的原因。 回归测试 相对于稳定的规范而言，优势最为明显。
测试中的不同模型
为了理解MBT，有必要了解下面解释的一些模型。每个模型都在表达能力和努力程度之间进行权衡，因此选择哪种模型取决于被测行为的复杂程度。
有限状态机
该模型有助于测试人员根据所选输入评估结果。不同的输入组合可以导致系统呈现相应的状态。
该系统将具有特定状态和当前状态，该状态由测试人员给出的一组输入决定。
请看下面的例子。一个系统允许员工登录应用程序。员工当前状态为“外出”，登录系统后状态变为“在线”。在“在线”状态下，员工可以在系统中查看、打印和扫描文档。
该示例的状态机如下所示，每个箭头都标有引起状态转换的输入。
州图
状态图是有限状态机的扩展，可用于复杂和实时系统。状态图描述系统的各种行为，具有确定数量的状态，并且系统的行为以每个状态对应的事件形式进行分析和表示。在实践中，最重要的扩展是层次结构：状态图允许嵌套和并行状态，因此原本需要数十个扁平状态才能表示的机器可以用简洁的方式绘制出来。
例如，缺陷在缺陷管理工具中以“新建”状态创建。开发人员修复缺陷后，状态必须更改为“已修复”。如果缺陷未修复，状态则更改为“重新打开”。状态图的设计应确保每个状态都对应一个事件。
缺陷生命周期如下图所示，每个状态都表示为一个阶段，每个工作流程操作都表示为将缺陷从一个阶段转移到另一个阶段的事件。
统一建模语言 (UML)
统一建模语言 (UML) UML是一种标准化的通用建模语言。UML包含一系列图形符号技术，用于创建能够描述非常复杂的系统行为的可视化模型。
UML 具有如下符号：
- 游戏及活动
- 演员
- 业务流程
- 组件
- 编程语言
活动图和状态机图是测试生成器最常读取的图，如下面的 UML 模型示例所示。
基于模型的测试工具
纸上的模型本身并不能生成任何东西。我们需要一个生成器来运行模型并生成测试路径，而工具市场则分为开源生成器和商业测试设计平台。
- GraphWalker — 一个开源工具，可以读取以有向图形式存在的模型，并从中生成测试路径，具有可选择的生成器和停止条件。
- fMBT — 英特尔提供的开源基于模型的测试工具集，支持针对状态模型生成和执行测试。
- Conformiq — 一款商业化的自动化测试设计产品，它从图形化的行为模型中导出测试用例和脚本。
- MaTeLo 和 MBTsuite —面向统计使用模型和将测试生成到现有自动化框架中的商业平台。
- 规格探索器 - Microsoft的基于模型的 Visual Studio 测试扩展，在协议测试文献中被广泛引用。
选择工具与其说是取决于功能列表，不如说是取决于两个问题：团队实际能够绘制哪种符号，以及该工具能否将测试用例导入到已使用的自动化框架中。如果生成器生成的测试用例无人能够执行，那么它只会增加流程步骤，而不是简化流程。
基于模型的测试与传统测试设计
与手写测试设计相比，值得一提的是，这两种方法的不足之处并不在于哪一种方法更好。
| 方面 | 基于模型的测试 | 传统测试设计 |
|---|---|---|
| 测试用例来源 | 由行为模型自动生成 | 由测试人员根据需求单独编写 |
| 需求变更的影响 | 更新模型，重新生成受影响的测试 | 手动查找并编辑每个受影响的测试用例。 |
| 保障范围 | 以模型标准（例如所有状态或所有转换）进行衡量 | 根据需求进行衡量，并取决于测试人员的判断。 |
| 预付费 | 高：建模技巧、工具设置和适配器层 | 低：测试人员可以立即开始编写代码 |
| 最合适 | 具有稳定规范的有状态、长寿命系统 | 短期项目、一次性专题报道和探索性工作 |
| 主要故障模式 | 错误或过时的模型会悄无声息地生成错误的测试结果。 | 大型套件中会积累大量缺失和重复项。 |
下面的发展历程将这项技术置于背景之中：手动测试执行让位于自动化执行，而基于模型的方法将自动化提前了一个层次，进入了测试设计本身。
基于模型的测试的挑战
在组织中部署基于模型的训练（MBT）需要投入大量的资金和精力。以下是MBT的缺点： 软件工程:
- 测试人员需要具备传统测试设计所不要求的建模技能。
- 学习曲线很长，而且第一个项目的成本通常大于节省的成本。
- 该模型本身可能难以理解和审查，尤其是在其发展壮大之后。
- 如果模型与规范不符，就会产生自信但错误的测试结果。
- 将 abs 转换为 abs 的适配器层trac实际操作的步骤必须单独编写和维护。
- 模型规模增长迅速，因此不受约束的状态模型可以产生比任何团队能够执行的路径都多的路径。
这些都不是避免使用这种技术的理由，但它们共同解释了为什么MBT通常先在一个稳定的子系统上引入，而不是在整个系统中引入。 软件测试生命周期 立刻。
基于模型的测试的优势
考虑到这些成本，MBT 的优势在于：
- 测试用例和测试套件的维护变得容易，因为编辑的是模型而不是单个测试。
- 在长期项目的整个生命周期内降低成本。
- 优化 测试覆盖率因为生成器会探索人们会跳过的路径。
- 生成的不同测试套件可以在任意数量的机器上并行运行。
- 及早发现缺陷，因为在模型构建过程中，在执行任何代码之前，就会出现歧义。
- 在相同的测试工作量下，发现的缺陷数量却增加了。
- 模型和适配器一旦存在，即可节省测试设计时间。
- 测试人员的工作满意度提高，因为工作重心从重复性的脚本编写转移到了建模和分析。
测试人员在工作中本来就会构建心智模型，而MBT只是将这些心智模型转移到纸上，以便进行审查、版本控制和重复使用。该技术与其他可用方法的契合点在文中阐述。 软件测试类型.
