测试用例设计着重点

日常设计测试用例的时候，有许多经典的测试理论。比如边界法、等价法，这些经常用到我们日常的工作中。当然也有许多的理论，比如正交分解法是使用起来非常费劲。往往转化为实际的容易理解的测试语言就非常困难。

　　测试的时候，我们也会碰到难堪的场景，那就是测试遗漏。

　　我们来分析下，开发的过程。开发拿到需求后，就会开发相应的代码，然后简单的测试下功能。代码之间有可能是互相调用的，代码可能影响到的模块，有些开发是知道的，有些是不知道的。如果是有关数据库的操作，一个地方的改动有可能影响了多个模块。所以问题的复杂性就体现在这里了。

　　那么对于日常测试每个新功能，我们该怎么去构筑我们坚固的质量堡垒呢。

　　根据开发过程的特点，总结了我们设计测试用例六个方面。

　　一、功能

　　关注页面单个功能点验证，充分考虑开发改动的每个点。这个是保证开发每个已知的修改点都能改对。

　　二、关联

　　重点考虑修改点对其他模块的影响，包括代码的影响和操作数据引起的影响。

　　比如新增加的功能增加了数据库表的字段，必须关联的验证每个使用该表的该字段的模块是否正常工作。难点在于需要分析出已知和未知的影响模块，考虑的越多，往往遗漏的问题就越少。

　　三、流程

　　很多系统是有流程的，比如工作流系统。当修改了一个点的时候，我们必须考虑整个流程是否能够正常运转起来。

　　四、升级

　　我们大部分系统都是对已有的系统进行升级。对于升级前的数据，我们必须保证能够正常工作。升级之前，需要模拟好各种情况。同时，也需要对升级的数据库脚本进行充分的检查。

　　五、安全

　　比如菜单功能权限等。

　　六、性能

　　有的时候需要对性能进行考虑，比如升级脚本的执行效率，功能点的响应时间，事务交易的时间。

　　这六方面现在已经应用到了我们日常设计测试计划，测试用例工作中去了，成为了大家思考的一个入口点。后来大家发现有如下特点：

　　1）实践证明，该方法非常灵活。

　　在不同的颗粒度设计测试用例都可以作为我们思考的一个切入点。比如站在测试计划的角度，站在每个测试用例的角度都可以使用。

　　2）平易近人

　　道理非常简单，非常容易理解，可操作性非常高。不再是只能在课堂上讲，在实践中用不上的理论了。

　　3）功能和关联使用频率最高