取这个标题，感觉有点大，只能说我写的内容是围绕这个意思来的。

　　最近已经是带了第二个新人了，自然要教别人怎么写测试用例，我给新人的建议都是测试用例要追求有效性和高效性。

　　我总结的经验呢，测试用例最重要是要抓住，合适的测试样本、准确的测试路径和明确的测试目的。虽然听起来感觉有点像废话，但我觉得很多人写测试用例就是容易忽略这几点。

　　首先是合适的测试样本，比如测试某个功能，它是有一些前提已经存在的，可以理解为一些数据限制。举个例子，比如我们测试一个会记录用户历史数据的软件，对于一个全新的样本和有历史数据的样本是不一样的，样本的不同元素条件也决定了他在做一些操作时软件的反馈是不一样的。

　　然后是准确的测试路径，理论上最保险的应该是A*B*C*D*E*F*...个路径。一个流程，就是一条路径，但一个流程中包含了几个环节，每个环节有几种测试边界。根据数学的排列组合，最保险的路径数是不是应该把每个边界数相乘？但这个就不高效了。如果能发现其中不同环节之间的出bug的相连性呢。比如知道在A步骤的第三种边界如果出bug，那在C步骤的第二种边界肯定出bug。或者比如知道在B步骤的第二种边界表现是正常的，那在D步骤的第一种边界肯定也是正常的。那是不是就能省掉一些亢余重复的路径了呢？如果你知道两个步骤中的两个数据都读的数据库中的同一个字段，那这两个步骤显然就可以看一个地方的边界就好了。如果你知道两个地方共用的一个控件，那如果控件出问题，那肯定两个地方都会出问题。所以高效点的测试路径，应该精简为A*（B-M）*（C-N）*D*E*F...再然后如果确定E、F步骤跟A、B、C、D生成的数据毫无关系，那可以再精简为A*（B-M）*（C-N）*D+E*F...我们知道如果对于一次修改，往往不是所有的步骤的边界都受影响的，如果确定出某次改动只影响了A、C、E步骤的边界，那测试路径可以再精简为A*1*（C-N）*1+E*1...上面说的这些都是理论上的数学组合分析，而在实际测试过程中，如果对一个系统比较熟悉，我们只要抓住影响的相关性、影响的不相关性、步骤边界的相互限制，就能抓住几条最高效且有效的测试路径，对一个改动带给一个系统的风险进行测试。

　　最后说下明确的测试目的。只要是测试用例，都有测试目的，可能是对一个全新的功能进行测试，可能是对一个改动可能带来的风险进行测试，可能是验证现有的一个功能在某种特定条件下的表现。测试目的一定要明确，这就好比你是要去吃一顿丰盛的午餐，还是去喝杯下午茶，还是半夜饿了爬起来吃点夜宵，我想这其中的区别大家还是可以理解的。