林曙?：

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

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

　　林曙?的“模型”上下文是：

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

　　徐毅说的“模型”是：

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

　　林曙?也同意两个不是一回事：

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

　　架构师Jack也加入了讨论：

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

　　对此，徐毅认为：

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

　　之浩提到：

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

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

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