BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

测试人员微博热议模型驱动测试MBT

| 作者 郑柯 关注 3 他的粉丝 发布于 2012年11月7日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

林曙湧是一位敏捷教练,在诺基亚西门子工作,专供敏捷测试、自动化测试。他在一条微博中指出:

在我看来,MBT可以解决很多自动化测试中的顽疾,比如测试架构混乱,重复步骤很多导致测试执行效率低,自动化测试的杀虫剂效应等等。当然,要用好MBT,我们还会面临诸多的挑战,包括理念上的,工具上的,技能上面的。不过已经有很多先行者帮我们铺好了道路,比如微软的测试架构师Harry Robinson。

社区知名敏捷教练徐毅有些疑问:

找到银弹了?2011年我组织Conformiq的CTO到成都NSN介绍过MBT,我觉得MBT本身理念不错,但适用范围有限,引入MBT要进行思维转化,这对当时NSN的测试现状不见得是好事。MBT的重点在于测试建模,缺乏此能力做不好MBT,但培养此能力也耗费不低。

林曙湧的回应是:

没错,这个世界上没有银弹。不过它的确可以解决很多自动化测试中的问题,当然,这也是有代价的,没有免费的午餐。如何能够具备应用MBT需要的能力,思维的培养,还有如何与敏捷的上下文结合起来,也许值得讨论。

徐毅认为:

MBT的主要出发点是专业测试人员只需要开发出测试模型即可,而产生自动化脚本的过程则可以委托给工具去完成,而在我看来这就是不靠谱的地方。自动生成代码的工具,多年前在开发领域早就出现过,至于它的效果如何,不必我浪费口舌。而至于那些自动生成的代码,可维护性如何,大家心里有数。

林曙湧回应:

测试代码和产品代码的性质还是不太一样的,在开发领域不适用未必在测试领域不适用。产品代码要考虑很多细节的东西,比如硬件的差别,性能的优化,等等,而测试代码更多地从用户需求来描述,复杂性相对有限。在我们的实践中,生成的测试用例只是很薄的一层,复杂的逻辑全部放在库里面。

徐毅认为:

测试自动化本身就是开发,测试代码就应该等同于产品代码进行对待,应该放在同一个代码库,维系同一版本号。另外,“把逻辑放在库里面”,你这句话说得不够清晰,我不知道你说的是“业务逻辑”还是“程序逻辑”,我认同后者应该放在库里,但如果把前者放在库里,那就是测试自动化的大忌。 

“建模思想”确实重要。我当时另一个出发点是,如果公司本身就在采用UML那一套路的开发方式,那么测试发展的下一步选择MBT是比较自然也是比较经济实惠的方案。但是,我当时所接触的那些产品线,用OO开发的很少,用建模套路的更少,使用MBT,会有极高的学习曲线,且开发也无经验借鉴。

林曙湧认为还是可以做到控制:

测试自动化是开发没错,但不见得所有的开发都遵循完全一样的规律啊,开发里面也有很多分支啊,不能一概而论。业务逻辑是通过模型去表现的。你说得没错,业务逻辑应该尽可能往上移,但是在具体实现的时候,有时候也会有些Tradeoff。总得来说,还是我们可以控制的。

徐毅提出四点:

1,确实不是所有开发道理都一样;

2,但是测试自动化其实比一般的开发更复杂,因为“需求来源”更不稳定和易变;

3,业务逻辑用模型体现,我想很多UX的人不一定认同

4,我也认同有tradeoff,但到底有多少,多和少,是有区别的,这决定了控制的成本,也影响了ROI。

林曙湧:

在我们的实践中,发现通过MBT来实现自动化测试,的确比原来的方式对测试人员的能力要求更高,包括你说的建模能力,以及测试人员的编码能力。所以现在还是要手把手教的,但是测试人员学会了之后,反响都很不错,愿意在他们的领域推广使用。

徐毅发现:可能他和林曙湧说到的“模型”不是同一个概念

林曙湧的“模型”上下文是:

我们碰到的问题是case数量爆炸,而且测试的输入数据,测试步骤固化在case里面也不利于引入变化,无论是应对需求的变化还是避免自动化测试的杀虫剂效应。所以在原有的测试用例上抽象出一层,我们把它叫做模型,测试用例可以由它生成。

徐毅说的“模型”是:

对系统抽象理解的呈现,并以此为基准开发出测试用例。你举例的模型,我认为最多称为测试集(set或collection)。关键区别在于自顶向下还是自底向上。

林曙湧也同意两个不是一回事:

一般自底向上会采用抽象和归纳的手段建模,自顶向下会采用分而治之的手段。决不能说自底向上就不是建模。不过我的理解你说的MBT更多指战略层面的应用,的确这不是我们现在做的事情。 

架构师Jack也加入了讨论:

关键还是你的团队具备测试建模的能力吗?测试建模不是直接把产品的流程模型复制过来,还有在产品模型的基础上衍生出更多分支才是测试模型。如果只有边界值、等价类、正交组合这样的测试方法是不够进行测试建模的。

对此,徐毅认为:

是否具备测试建模能力是一方面,也即是否可以立刻产生效果。另一方面是,如果暂不具备,是否愿意投入来培养这个能力,包括是否能够承受这个投入,或者说当前应该专注的是其他方面和提升点。这是我2011年在诺西时对MBT的看法的出发点。 

之浩提到:

难得看到有讨论MBT的,modeling的过程是好入手但是很难做好的,否则状态爆炸、路径筛选困难等问题会很难搞,而本身边界值这种扁平式的测试也不太适合MBT。btw,即便在微软内部很多team对MBT也是尝试后放弃之。

InfoQ之前介绍过的、在微软工作的刘彪也参与到讨论中。他说自己在与Harry Robinson吃饭时,专门问了下为什么微软也没有推广起来MBT,而Harry给出的答案是:

最主要的原因是做测试人其实不是真正想做测试,不愿意在测试上专研。

围绕这个讨论,很多测试方面的技术人员都参与进来,希望了解更多内容的,可以去看这条微博的详细转发和讨论。 

此外,林曙湧还推荐了两个网址,可供大家了解更多关于MBT的知识:

林曙湧在自己的博客上还有很多关于MBT、敏捷测试和自动化测试方面的文章,感兴趣的同学可以前往阅读。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

测试不单纯 by song zhang

专业的测试不可能太专注于测试

RE: by cao Alex

感觉鸡同鸭讲

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT