基于模型的测试MBT

oceanwell

最近接触到MBT（Model-Based Testing 基于模型的测试），因用例设计的几种工程方法如正交分析、判定表分析、场景分析等，操作起来比较困难，实际应用效果也不是很好，用MBT这种新的模式来提高用例设计质量的，坛子里有这方面的专家没?

oceanwell

这东东不好玩

flysilea

研究得咋样了？分享一下啊~~

mwx17338

这个是HW现在推行的测试思路，配合自研工具推行，基于场景进行设计，能够自动生成测试用例。

Jackc

MBT 基础概念
MBTModel based testing 基于模型的测试基于模型的测试属于软件测试领域的一种测试方法。按照此方法测试用例可以完全或部分的利用模型自动产生。

通俗一点，将测试目标按照类似UML（状态图）的方法进行分解。 通过规范被分解的各个测试单元的测试标准，再根据测试单元之间的逻辑关系，设计出较高覆盖率的测试用例。
优点在于可以通过控制测试单元的标准，达到对测试目标的测试质量进行宏观的把控。

整体来说，MBT属于复合型的测试用例方法设计。除要求测试人员具备一般测试用例设计方法外，还需要掌握较高的建模能力。简单来说，就是根据需求/设计文档，重新拆解测试项。。。(单个小功能还好说，如果是针对ERP系统，终端产品 这些大型测试目标，至少我个人很难想象需要什么样素质的测试团队来完成这个需求再分解）

相对于普通的用例设计方法，MBT降低了一线执行测试人员的素质要求，提高了策略类测试人员的要求。

Jackc

以下为一封来自builder在线的关于MBT讨论的转帖：http://www.builder.com.cn/2013/0221/2145226.shtml

蓝色字体为我个人的感受
--------------------------------热议模型驱动测试MBT
本文摘要
MBT可以解决很多自动化测试中的顽疾，比如测试架构混乱，重复步骤很多导致测试执行效率低，自动化测试的杀虫剂效应等等。当然，要用好MBT,我们还会面临诸多的挑战，包括理念上的，工具上的，技能上面的。（介绍一下背景，目前自动化测试比较成熟的公司，最希望解决的是：“用例覆盖率和脚本维护资源之间的平衡。”故高效的用例建模，对于自动化测试来说，可以说是一项“质”的飞跃）

    林曙涌是一位敏捷教练，在诺基亚西门子工作，专供敏捷测试、自动化测试。他在一条微博中指出：
在我看来，MBT可以解决很多自动化测试中的顽疾，比如测试架构混乱，重复步骤很多导致测试执行效率低，自动化测试的杀虫剂效应等等。当然，要用好MBT,我们还会面临诸多的挑战，包括理念上的，工具上的，技能上面的。不过已经有很多先行者帮我们铺好了道路，比如微软的测试架构师Harry Robinson.

社区知名敏捷教练徐毅有些疑问：
找到银弹了？2011年我组织Conformiq的CTO到成都NSN介绍过MBT,我觉得MBT本身理念不错，但适用范围有限，引入MBT要进行思维转化，这对当时NSN的测试现状不见得是好事。MBT的重点在于测试建模，缺乏此能力做不好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也是尝试后放弃之。(微软 在MBT上碰到钉子，至少可以说明1点，MBT的投入与对团队要求，不能使用普通标准来衡量。不过国内最缺的是“创意”，而不是“改良”，个性化的MBT会逐渐多起来的，虽然以前其实就有一些类似MBT的概念，只是没有推广开来而已。概念这玩意，还得靠宣传。。)
我们之前介绍过的、在微软工作的刘彪也参与到讨论中。他说自己在与Harry Robinson吃饭时，专门问了下为什么微软也没有推广起来MBT,而Harry给出的答案是：
最主要的原因是做测试人其实不是真正想做测试，不愿意在测试上专研。(看到这里其实有一些愤愤，“失败== 团队成员的问题？”。个人感觉要么是断章取义，要么就是回答太随意了。)
————————————————————————