MBT概述
基本概念
无论是软件还是硬件，甚至在日常生活中，所有的测试都可以视为系统因某个激励产生响应，然后对其进行检查的过程。在基于模型的测试中，我们认为模型在某种程度上就是激励-响应的一种表达方式。 关于模型，软件和系统设计模型通常包含两种类型——针对结构的模型和针对行为的模型。在通用建模语言UML中，针对结构的模型集中于类、类的属性、方法和类之间的连接，类似继承、聚合等关系。而对于测试人员而言，这类涉及到函数底层的架构并没有太多的价值。我们重点需要关注的是针对行为的模型。
我们需要将被测试系统，抽象为一个一个基于行为的模型，拓展并优化这些模型，用以支持基于模型的测试。所以在MBT中有一个不可避免的局限性，只有原生模型足够好，派生出来的测试用例才能够同样好。
MBT的形式
基于模型测试的过程有三种基本形式：
- 手动测试
- 半自动测试
- 全自动测试
在手动测试中，我们构建并分析被测系统（SUT）的模型，是为了测试设计用例。对SUT进行建模，识别并转换成测试用例。比如在一个状态机模型中，我们需要根据测试需求，选择哪些测试用例将予于执行。比如根据
- 覆盖所有状态
- 覆盖所有变迁
- 覆盖所有路径
这三种情况来进行用例选择。而手动测试和半自动化测试区别就在于，是否有工具来替我们挑选了满足我们需求的用例。而半自动化测试和全自动化测试的区别，就是是否有工具或者系统来帮我们将挑选出来的用例转换为自动化测试脚本，进行执行。
MBT的作用
- 测试人员了解并熟悉各类模型，将测试系统或者需求抽象成为符合预期的模型，利用这些模型进行测试用例设计，这同样也是一种高级测试用例设计方法。
- 当有一套完整且优秀的MBT测试方案后，测试人员只需要专注于被测系统的了解并抽象，MBT会帮助我们完成用例设计及报告数据。
常用的模型详解
以直播项目的一个测试需求来作模型详解
流程图
计算机领域很早就开始使用流程图了，这可能是使用最早的一类行为模型。
流程图中的路径可以直接推导出抽象的测试用例。
对于流程图的优势，它是易于被理解的，过程框和决策框中的文本都可以使用自然语言。因此流程图使得客户和开发者之间具有更好的交互性。但流程图也有限制。由于流程图的本质是将过程序列化，所以很难表达事件驱动的系统。因为在事件驱动的系统中，独立事件可能以任意顺序发生。比如测试一个MP3、或者一个车库大门的驱动系统等。同时流程图几乎没有办法表达数据，只能作一些简单粗浅的表达，对于复杂系统的复杂数据交互，流程图模型是无法完成对系统的模型抽象的。
决策表
决策表是一种充分考虑系统之间的输入组合、约束以及输出因果关系的用例设计方法。
特别适合于针对不同逻辑条件的组合，测试对象需要执行不同操作的场景。
决策表的组成
条件桩： 列出系统的所有输入，通常认为列出的输入次序无关紧要
动作桩： 列出系统所有可能执行的操作，这些执行操作没有顺序约束
条件项： 列出输入项的各种取值
动作项： 列出输入项的各种取值情况下应该采取的动作
决策表的步骤
- 列出所有的条件桩和动作桩
- 确定规则的数目
- 填入条件项和动作项得到初始的决策表
- 简化相似的规则，得到优化的决策表
- 每列规则，设计一个测试用例
示例
公司规定如下：
- 中国去欧美的航线所有座位都有食物供应。每个座位都可以播放电影
- 中国去非欧美的国外航线都有食物供应，只有商务仓可以播放电影
- 中国国内的航班的商务仓有食物供应，但是不可以播放电影
- 中国国内的航班的经济仓除非飞行时间大于2小时就有食物供应，但是不可以播放电影
列出所有的条件桩和动作桩
- 列出所有的条件桩和动作桩
等价类：
A1={航线为国外欧美航线}
A2={航线为国外非欧美航线}
A3={航线为国内航线}
P1={舱位为经济舱}
P2={舱位为商务舱}
T1={飞行时间大于2小时}
T2={飞行时间不大于2小时}
条件桩
C1：航线为{A1,A2,A3}之一
C2：舱位为{P1,P2}之一
C3：飞行时间为{T1,T2}之一
动作桩
A1：食物供应
A2：电影播放 - 确定规则的数目
3x2x2=12 - 插入条件项和动作项得到初始的决策表
- 简化相似的规则，得到优化的决策表
- 每列规则，设计一个测试用例
