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

　　在我看来，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。