什么是MBT测试设计?MBT(Model based testing)中文名称为基于模型的测试, 基于模型的测试属于软件测试领域的一种测试方法。
通常MBT的方法是需要搭配工具使用的，这样在模型画好的同时，可以自动生成对应的测试用例以及自动化脚本。
MBT的测试设计理念，是基于需求的功能流程，然后进行建模，基于这个模型，才称得上是测试需求。
也就是说做MBT测试设计的前提是对需求和业务有深刻的认识。
为什么要做MBT测试设计？我们所熟悉的传统测试设计方式主要分为等价类、边界值、决策表、状态转换图、决策树、正交法等。
传统测试设计没有一些工具的支持，主要依赖与测试人员的思考分析。
传统测试设计流程先介绍一下传统测试设计的主要流程，测试人员首先进行需求评审后，这个过程是熟悉和了解需求的过程，然后开始进行测试设计，测试设计主要运用的方法是之前提到过的“等价类、边界值、决策表、状态转换图、决策树、正交法等”，但是这些方法没有现成的工具使用，通常情况测试人员需要用笔在纸上去画一下，计算下场景组合，这些思考完成后，距离测试用例还有一段距离，此时测试人员会用在思维导图软件上把之前想到的场景列出来，之后再根据列出的场景逐一转化成文本案例。
下面举一个例子来说明一下：以物流打印作业通知单功能为例，功能的场景为在采购入库搜索/打印页面按照条件搜索出条目点击打印操作。
·第一步业务梳理，该需求场景流程如下图：·第二步分析打印操作这步有哪些场景：分析这步时需要依赖测试人员对需求的理解，对测试设计方法的运用，如下图在思维导图中梳理出所有场景，分别运用了流程场景设计、判断法、正交法设计方法。
·第三步将列好的思维导图编写成测试用例此时需要测试人员逐条去编写测试用例，编写步骤描述、预期输出、预置条件、标记编号、名称等信息。
全部完成后才输出完整测试用例。
·第四步用例评审用例评审也是测试设计中的关键一步，传统用例评审时是测试人员把设计好的用例，一般是excel格式发给相关人员评审。
·第五步用例修改评审后，根据评审意见需要对测试用例进行修改。
改动可能是某一步骤修改，也可能是需要增加其中一个场景。
·第六步用例维护测试用例不仅仅是编写完成工作就结束，后续需求功能变动，都需要去维护修改测试用例，后续功能如果发生变更时则需要修改之前的测试用例，其中某一步骤功能变更后可能需要修改所有的测试用例。
传统测试设计的存在痛点由上述例子可以看出，测试人员在测试设计时，分析场景、编写用例、评审用例以及用例后期维护都是比较耗费时间的。
·需求分析的痛点上述传统的测试设计中，测试人员只需在头脑中理解大致的需求，即根据自己的理解输出测试用例;·分析场景的痛点之前在做测试设计场景分析时，运用的设计方法对测试人员个人技术依赖比较高，不同的测试人员设计出来的测试用例质量也是存在差别，其中如正交法，如果正交因子比较多时，没有工具支撑的情况下很容易遗漏。
·编写用例的痛点将思路转化成用例这步，也是耗时比较长的一步，测试人员需要逐条编写，工作相对枯燥，占用时间长，往往用例的步骤描述时存在偷工减料的现象，用例编写规范得不到落实。
·评审用例的痛点评审用例时，评审人员拿到的是成型的用例，此时评审人员并不能看到设计者的当时的思路，以及运用的测试设计方法。
逐条查看完整用例才能明白这步用例具体的操作，同样耗费评审人员的宝贵时间。
·后期维护的痛点测试用例后期最怕的是用例维护，往往需求后续过程中一个小的优化点，都需要逐条修改用例，修改的时间甚至赶上了之前的编写时间，往往很多测试人员都忽视了这一环节。
赘述了这么多，既然传统测试设计存在这么多痛点，为什么我们不去解决改变这些痛点呢?所以我们要做的MBT测试设计工具，目的就是为了解决测试设计中的痛点，进而提升测试设计过程的效率。
MBT测试设计流程还是继续上文的例子，用MBT测试设计流程工具如何去做设计呢?·首先拿到需求后对需求进行分析首先需求分析是我们做测试设计的前提，这步是必不可少的一步，主要分析对应用户是谁?解决什么场景问题?·明确被测特性的目的和价值明确用户时如何使用这个功能，存在哪些场景、边界。
从用户使用角度，会发现很多因子，将因子记录下来。
·功能点划分将整个需求分成多个功能点，每个模型内部主题明确，模型间没有太多重复，需求要被完整覆盖。
·对每个模型进行粗略设计模型的业务流程是怎么样，有哪些分支因子在模型什么位置，有哪些数据因子在模型什么位置。
同样我们会先梳理出业务主流程。
用MBT进行测试建模是基于需求的功能流程，然后进行建模，基于这个模型，才称得上是测试需求。
鉴于此，就要求对于需求要有深刻的认知，所以熟悉业务是很必要的，若是业务不熟悉，那建模过程将会充满艰难险阻。
这样也反向促进测试人员需要在需求和功能理解上下更多的功夫。
·建立MBT测试模型，对每个功能点进行进一步分析经过分析在打印这步操作上会有一些业务场景分支。
这时候在模型中对这一步进行细化分析。
中间可能会用到场景划分、判断法、正交因子等设计方法，会在模型中体现出来。
这样当时运用了哪些方法，思路都会体现在模型中。
合作伙伴功能为SH的因子图：·通过工具基于模型生成测试用例进一步去填写步骤中对应的预置条件、测试步骤、预期结果。
关键节点的公用步骤只需要填写一次，这样也减少了重复工作。
·MBT测试设计评审测试设计评审时展现给评审人员的是模型图，不再是一行行的用例记录。
评审人员能够看到设计者当时的设计思路，用的什么测试方法。
·测试用例的维护用例维护与之前不同点在于，维护是在模型上维护，如果增加一条分支，或者其中一个步骤有修改，只需要修改对应的分支和步骤再次点击同步。
后续需求功能点优化时，重新打开对应的模型能看到之前业务流程图，新参与的人员可以更快的熟悉对应的功能。
由上所述，对比MBT测试设计和传统测试设计是不是有很大的不同呢。
我们总结一下，MBT测试设计要求测试人员对需求理解更深，设计、编写、评审以及维护都围绕了一张模型图，设计评审过程都比较透明。
MBT测试设计在苏宁蛙测的运用既然MBT测试设计对比传统测试设计有很多优势点，那为何很多测试人员没有去用呢?其实是因为做MBT测试设计必须得依赖工具，市面上又没有合适的工具，久而久之测试人员还是用的老方法。
现在苏宁蛙测平台结合业务场景，分析测试人员需求，研发出了一套MBT测试设计建模工具，下面介绍一下苏宁蛙测平台这款工具的特点。
工具使用介绍在苏宁蛙测平台中MBT测试建模工具的入口在创建测试案例中，用户可以在对应案例集的模块下右击创建测试设计模型。
建模的操作非常简单，测试人员只需要做简单的拖拉连线的动作，在模型中梳理自己的思路。
·初始建模页面左侧方有步骤、案例、多因子和批注。
“步骤“对应到模型设计中的具体操作步骤，设计时将多个步骤和案例串联起来，一条连线上会对应一个测试场景。
·编辑案例/步骤属性菜单选择步骤名，右击步骤，可自定义步骤属性;编辑步骤窗口可以去细化测试步骤、预期、预置条件的描述。
·编辑后按保存经过一系列拖拉连线动作后，测试人员的模型就设计好了。
这时点击一下保存，或者同步。
就可以生成案例了。
·同步后生成案例工具支持多种设计方式前面提到的多种测试设计方法如流程图、等价类、边界值、正交法等，测试人员设计时主要是通过自己在纸上笔画或者在脑海里思考，没有对应的工具。
而蛙测平台的MBT测试设计工具也支持这些设计方法，模型中的多因子功能就运用了正交法，运用工具可用省去了测试人员在纸上笔画和思考的过程。
操作举例如下：拖动多因子到模型中，右击多因子图标，选择打开多因子。
·第一步：设置多因子json报文注：如果多因子变量值是字符串用””号表示，如用户名[“张三”];如果是数字就输阿拉伯数字，如ID[123456];·第二步：选择组合因子数(默认因子数为2)·校验多因子json数据格式·生成多因子组合点击生成组合按钮，输入多因子变量名名称，按确定按钮后，生成多因子案例工具特点与效果平台工具结合了多种测试设计方法，用模型表达需求，工具的支撑可以实现科学覆盖。
模型设计通过拖拉连线方式，操作简单，无需复杂的培训学习成本。
蛙测平台的测试设计建模工具正在多个业务中心推广使用，试用过程中，经过对比测试人员用例写作效率和用例维护效率上都有所提升。
随着广泛推广以及工具的持续优化效果将更明显。
愿景MBT测试设计的目的在于帮助测试人员更方便的进行测试设计，后续会再做继续演进，在设计的时候结合自动化，能够在测试设计的时候也组合成对应的自动化，每一个步骤就对应自动化执行的一步。
最终测试人员可以基于模型去执行自动化，并能评估产品质量。