那么如果我们使用了新模型后，我们的MM图必须加一些标记了，新模型的coding阶段，我们测试人员没有太多时间去编写详细的测试用例，我们有很多的自动化测试用例和接口测试用例，这时我们的MM图可以变成这样了：

注意上图的Automan是自动化测试脚本的标记，iTest是接口测试脚本的标记，另外一个是Manual了。

当然也不能简单了，我们好能把自动化测试脚本和接口测试脚本编写的环境连接起来，比如我打开了一个标记为自动化测试用例的环境，如下：

Page Model，DB Model 和 Ruby编程环境，能够把用例标题写入脚本模板中

再比如我打开了一个标记为接口测试用例的环境，如下：

Java代码编写环境，能够把用例标题写入脚本模板中，优化脚本模板

其实这里面区别开我们的手工测试用例，自动化测试用例，接口测试用例可以有2种方式：

1. 一种是在功能点来进行划分：细分到一个很小的功能点，写测试思路的时候，不用Care是什么类型的测试用例，好评审完后，加上一个简单的标记即可，上图的方式是这种方式，是统计数据比较麻烦一点。

2. 另一种是根据用例类型来划分：首先划分3个维度，然后再维度后面加上自己的功能点的测试思路

这样做的优点是很清晰的知道不同的测试类型的用例个数或复杂度等，但注意这里面有个缺点：是有可能一个功能点会存在多个不同的测试类型，所以本人建议使用第一种方式来做。

后需要强调的是我们的测试思路的标题一定要是可见性的，正确性的，目的性的。另外如何在一个功能需求模块中把这些用例结构清晰的抽象出来，需要多思考，需要对于即将测试的需求有整体性的把握，然后在完善MM图的过程中不断的调整用例MM结构图，使其能让开发清楚的知道我们即将要测试哪些点。我们也可以很快捷方便的完善我们的所以测试思路。

后说明下，这里的测试思路的载体MM图，如何去进行组织用例结构和思路编写规范，是需要一些探索式测试ET 的一些技巧的，特别是测试设计和测试执行的相关注意点。下次找个案例来详细说明下这个思路的变化。