软件测试之“软件测试用例设计原则”

上一篇 / 下一篇 2011-06-28 15:39:53 / 个人分类：测试入门

　　不管是从个人角度还是从公司角度，根据我这几年的经验我觉得case的设计应该符合以下几点：

　　1、一个case一个功能点：每个case都要有个测点，找准一个测点则可，不能同时覆盖很多功能点，否则执行起来牵连太大;

　　2、case的易读：从执行者的角度去写case，最好不要有太多的术语在里面，如果要有最好指明具体位置;

　　3、case的执行粒度：粒度越小越好;软件

　　4、步骤清晰：一个case多个步骤，可一个重点，步骤指名人们怎么去操作，expect则指明这样操作之后应该看到什么结果---最好不要用正确，正常，错误之类的含糊主观的字眼。

　　5、总体设计：先正常，后异常，这样可以确保正常情况下功能能够走通。

　　总之：对于一个新来的tester，给他个case和我们的软件，他就能顺利取执行case，这是最佳状态，也是我们case设计的标准，按照这个标准，我想出了以上几点要求。

　　这样做的好处是：

　　1、执行者不会因为case看不懂再三的去烦扰你，你也不会因为时间长了，业务忘了，看不懂case;

　　2、如果原来的designer有事，公司可以很快请人顶上，测试可以继续进行，不会被block住;

　　3、执行case的人能更快的去掌握业务系统流程，不会因为要看懂一个case而大伤脑筋，更别说去真正的执行它了。

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

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

　　一、功能

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

　　二、关联

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

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

　　三、流程

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

　　四、升级

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

　　五、安全

　　比如菜单功能权限等。

　　六、性能

http://www.ltesting.net/ceshi/ceshijishu/csyl/2011/0621/202716.html

TAG: