什么是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测试设计的目的在于帮助测试人员更方便的进行测试设计,后续会再做继续演进,在设计的时候结合自动化,能够在测试设计的时候也组合成对应的自动化,每一个步骤就对应自动化执行的一步。最终测试人员可以基于模型去执行自动化,并能评估产品质量。
![MBT测试思想在苏宁蛙测的运用实践分享](https://i-blog.csdnimg.cn/blog_migrate/10526cfbde62ef7aff44afed5ca81963.png)
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31077337/viewspace-2156495/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/31077337/viewspace-2156495/