MBT测试思想在苏宁蛙测的运用实践分享

什么是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测试设计的目的在于帮助测试人员更方便的进行测试设计，后续会再做继续演进，在设计的时候结合自动化，能够在测试设计的时候也组合成对应的自动化，每一个步骤就对应自动化执行的一步。最终测试人员可以基于模型去执行自动化，并能评估产品质量。

原文转自：http://tech.it168.com/a2018/0622/3210/000003210659.shtml