MBT-模型驱动测试的探索与实践（一）

作者：干玥

开鑫金服资深测试工程师

二宝辣妈

我应在江湖悠悠

饮一壶浊酒

醉里看百花深处愁

最近遇到了个这样的问题：

chapter1  我们家产品汪宣布要盖一栋新型狗屋，于是开发汪哼哧哼哧开始了开发，而测试喵写了200+的用例来检测狗屋的质量；

chapter2 产品汪又宣布要盖一栋复合型的狗屋，开发汪说好办，我们把之前的狗屋模型拿来改改就行，而测试喵又满怀激情的写了200+的用例；

chapter3、chapter4 again again again

测试喵突然有一天感觉腰也酸了，腿也疼了，干不动了，当测试在复制黏贴中沦为纯体力活，激情和价值都不复存在。

 

测试喵想：

针对这些业务流程、规则类似，但可能在某些分支场景上存在差异的产品，用例似乎可以复用，不需要完全重新设计，但是到底哪些是一致的可以共用的，哪些是需要单独设计的呢？难道完全靠经验来筛选么？出了问题完全看命？改变工作方式的需求呼之欲出，模型驱动测试-MBT进入了测试喵的视线。

 

 

模型驱动测试MBT是什么

 

今天第一篇开篇，我们先来分享一下模型驱动MBT的概念，之后我们会有篇续文分享我司在这方面的实践和探索。

 

模型驱动测试MBT顾名思义就是基于模型的测试，核心在于模型，模型是对被测系统的抽象。

 

模型驱动测试MBT并不是什么新鲜的概念，事实上IBM的Rational Rhapsody TestConductor Add On 和 Rational Quality Manager，微软的Spec Explorer都是基于模型驱动的测试工具，腾讯等大厂在这方面均有实践，只是暂时没有看到通用性很强的工具。

 

 常见MBT建模种类

 

我们通常建立的模型有以下几种：

Mental Model（心智模型）：即是人们对于世界的理解方式是透过询问：这是什么？为什么这样？这样有什么目的呢？这个东西是如何运作？它会造成什么后果？将这些问题简化成下列的架构图，这里我们可以将其归纳为对产品的理解、设想和体验。

 

 

SUT Model：System Under Test Model 是心智模型（对产品的理解、设想和体验）的外化（以及与现有模型的整合），是一种图形化或形式化的类比模型。它涉及到不同的层次（如系统、组件和工作环境）、不同视角（如语境/上下文、组件与结构、功能、行为和用户体验）和不同关注点（如数据类型、因果关联、程序结构、任务控制、动作、事件和接口）等经过抽象、泛化和删减后，SUT模型只保留有助于实现特定测试目的的特征。SUT模型的实例化可能用到的技术包括Finite State Machine (FSM)，Message Sequence Chart (MSC)， Control FlowGraph (CFG)，Event Flow Diagram，MarkovChains和UML Testing Profile ，语法测试（SYNTAX TESTING），NLP（自然语言语义模型），此外还有从整体视角的HTSM和ACC等等。

 

TRM：Test-Ready Model 是对SUT模型的扩展和转化，以使模型达到可测试的标准；该模型也可独立使用，即给出相关信息，我们就可以设计或使用一套测试设计算法，用来产生可以运行的测试用例。它根据SUT模型特征和项目实际情况增加或凸显质量风险信息。必要时TRM需要创建新的模型，这是测试建模的主要难点之一，但也体现了我们价值所在。另外，它转化SUT模型以达到可测试标准，并增加“怎么测”的信息，同时为SUT模型修改重构提供反馈。

TRM目前缺少成熟的工具和方法，是MBT的难点和研究方向；可见我们平常通过流程图来推演测试场景的过程本身也是建模的过程，并没有那么高大上对不对。

 

 

MBT建模途径

 

 

建模的过程又有以下几种路径，不同的路径决定了不同的测试设计过程：

 

路径一（红色箭头）：从心智模型（Mental Model）直接得到测试用例（Ad-hoc Test Design，基于临时需求）；

路径二（黄色箭头）: 从心智模型（Mental Model）得到TRM模型，再由TRM模型生成测试用例（传统测试设计）；

路径三（蓝色箭头->紫色箭头）：从心智模型（Mental Model）到SUT模型，再由SUT模型生成测试用例（教科书式）；

路径四（蓝色箭头）：从心智模型（Mental Model）到SUT模型，再由SUT模型到TRM模型，最终由TRM模型生成测试用例（MBT）。

 

 

实践举例

 

说了这么多理论，我们来举个实际的例子（路径四）：

需求描述：投资中我们需要增加起投金额的判断 假设项目剩余金额为X，投资金额Y输入校验：  a.Y大于等于起投金额Z；  b.X-Y需大于等于起投金额Z；  a、b条件为且的关系

 

第一步，建立Mental Model（心智模型）：

需求：投资金额合法性判断

1.投资金额>=起投金额 且  项目剩余可投金额-投资金额>=起投金额  投资成功

2.投资金额<起投金额    投资失败

3.项目剩余可投金额-投资金额<起投金额  投资失败

 

第二步，根据心智模型建立SUT模型：

第三步，根据SUT建立TRM模型：

TRM通过SUT建立的模型，增加检查点等，将SUT转化成可执行的用例；

1、投资金额<起投金额

2、投资金额=起投金额

3、.....

 

 第四步：将模型转换成用例

模型建立好，我们还需要工具支持将我们的模型转化成用例（最好是可执行的用例）。

 

 

MBT测试过程

 

 

A、根据需求选择合适的模型来描述被测试对象（测试设计的核心）

B、根据模型生成测试用例及期望结果（MBT工具的核心），如果能够直接生成可执行的用例最好；

C、在被测系统上执行用例

D、比较系统行为及输出和预期结果、反馈验证结果；

虽然MBT工具使用的语言千差万别但是基本过程基本一致，我司的MBT测试工具也是这个思路。

 

 

MBT带来的好处

 

1、模型建立的过程有助于我们从立体的角度重新认识我们的被测对象，同时也把我们对被测对象的理解通过模型化的方式表达出来，能够更高效的和开发团队中的其他人员沟通；

2、如果模型建立适当，我们可以获得我们的基线业务模型、最大程度的减少我们测试设计上的重复工作量，聚焦于变化的部分，并将这种分析从单纯的靠经验转化成通过工具来实现；

3、我们可以通过维护模型来保持我们的产品知识库、测试设计、测试数据、用例与系统当前实现的一致性，避免由于版本的快速迭代造成的文档和实际系统脱节的问题；

4、为测试leader在测试范围评估过程中的识别风险模块提供现实的依据。

 

总结一句话，懒惰才是推动人类科学进步的动力，就像电梯是因为我们懒得爬楼才应运而生的，扫地机器人是因为我们懒得扫地才有市场的，现在我们也懒得反复造轮子写一堆几乎一样的用例，我们要引入新的测试方法，把我们的力气发挥在更有价值的地方。

 

编辑：开普勒鑫球-大玲

 

推荐阅读：

迄今为止最接地气的区块链应用，没有之一！

Elasticsearch依赖Guava类库冲突的解决方案

知识是一种概率

 

关注公众号↓，第一时间获取下期信息

 

转载于:https://my.oschina.net/u/2969787/blog/1816242