记得去年年初的时候，就做过关于如何写的分享，说了为什么要写测试用例，什么是测试用例，如何写测试用例，什么样的才叫好的用例，什么样的叫不好的用例，也说了写用例的纠结：前提条件和执行步骤的纠结；测试用例标题的纠结；预期结果的验证的纠结等等。
个人觉得讲得很详细了，觉得效果不错的，为啥后来那些培训的同学对于写测试用例没有一个系统的概念呢，不知道怎么去写一个好的用例呢？这个blog的作用不是讲这些，而是说下工作一两年内都很容易出现的用例结构问题。你去问一线测试工程师，资深测试工程师，TL，Manager，甚至是Director，都不能对怎么写好用例达成一个共同的意识，以及共同的作业方式，当然我们不期望流程化，死板化，但我希望我们不要忘了我们的测试信念，我们的质量意识。
背景介绍：今年部门大量采用新模型进行项目测试，将去年做好基础的自动化测试，接口测试用到项目过程中去，真正的做到测试提前，为开发质量提高更早，更前面的保证和跟踪。模型注意改进点在开发Coding阶段，我们先看下以前SPR模型下，测试做了哪几个工作：
1. 接口说明文档评审
2. 数据库设计文档评审
3. 测试设计
4. 测试用例编写
5. 测试用例评审和修改
相比较旧模型而言，下面再看下新模型下，测试又会去做什么呢：
1. 制定测试开发计划
2. 接口说明文档评审
3. 数据库设计文档评审
4. 自动化测试设计
5. 自动化测试脚本开发准备（Page Model 和 DB model的建立；自动化脚本伪代码编写）
6. 接口测试设计
7. 接口测试脚本开发（搭建接口测试环境，接口测试代码编写，调试，后期Hudson上回归）
8. 自动化测试脚本和接口测试设计评审和修改
9. Code Review
大家是不是感觉到了明显的变化，那就是我们测试需要做更多的前期事情，那这样我们就需要对我们的测试用例模型（MM图）进行改进，以适应新的变化。对于做MM图，我自己对MM图的理解也许和大家不一样，我每次做项目，做出来的MM图都比较细，不仅仅是列出我要测试的每个功能点，而且每个功能点的测试设计和测试场景都写出来了，而且我觉得一个非常好的MM图（测试设计）需要经过如下三个步骤：
MM 1 ——— PRD阶段，使用RBT方法做出来的MM图（功能点划分，P1 和 P2的用例场景）
MM 2 ——— UC阶段，使用RBT方法强烈Review UC做出来的MM图（补充P1 和 P2的用例场景，P3和P4的用例场景）
MM 3 ——— 系统设计阶段，通过Review接口说明文档，详细设计文档，数据库设计文档（补充每个功能点容易遗漏的异常场景和详细校验点）
当然这里面的MM 图不是一成不变的，在测试执行阶段，这个MM图也会新增或修改测试思路（特别是发现了一些用例没有写的bug），下面就看一下例子吧：
那么如果我们使用了新模型后，我们的MM图就必须加一些标记了，新模型的coding阶段，我们测试人员没有太多时间去编写详细的测试用例，我们有很多的自动化测试用例和接口测试用例，这时我们的MM图就可以变成这样了：
注意上图的Automan就是自动化测试脚本的标记，iTest就是接口测试脚本的标记，另外一个就是Manual了。
当然也不能简单了，我们最好能把自动化测试脚本和接口测试脚本编写的环境连接起来，比如我打开了一个标记为自动化测试用例的环境，如下：
Page Model，DB Model 和 Ruby编程环境，能够把用例标题写入脚本模板中
再比如我打开了一个标记为接口测试用例的环境，如下：
Java代码编写环境，能够把用例标题写入脚本模板中，优化脚本模板
其实这里面区别开我们的手工测试用例，自动化测试用例，接口测试用例可以有2种方式：
1. 一种是在功能点来进行划分：细分到一个很小的功能点，写测试思路的时候，不用Care是什么类型的测试用例，最好评审完后，加上一个简单的标记即可，上图的方式就是这种方式，就是统计数据比较麻烦一点。
2. 另一种是根据用例类型来划分：首先划分3个维度，然后再维度后面加上自己的功能点的测试思路
这样做的优点就是很清晰的知道不同的测试类型的用例个数或复杂度等，但注意这里面有个缺点：就是有可能一个功能点会存在多个不同的测试类型，所以本人建议使用第一种方式来做。
最后需要强调的是我们的测试思路的标题一定要是可见性的，正确性的，目的性的。另外如何在一个功能需求模块中把这些用例结构清晰的抽象出来，需要多思考，需要对于即将测试的需求有整体性的把握，然后在完善MM图的过程中不断的调整用例MM结构图，使其能让开发清楚的知道我们即将要测试哪些点。我们也可以很快捷方便的完善我们的所以测试思路。
最后说明下，这里的测试思路的载体MM图，如何去进行组织用例结构和思路编写规范，是需要一些探索式测试ET 的一些技巧的，特别是测试设计和测试执行的相关注意点。
【编辑推荐】
