什么是MBT测试设计?
通常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测试设计的目的在于帮助测试人员更方便的进行测试设计，后续会再做继续演进，在设计的时候结合自动化，能够在测试设计的时候也组合成对应的自动化，每一个步骤就对应自动化执行的一步。最终测试人员可以基于模型去执行自动化，并能评估产品质量。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
