学历代表过去、能力代表现在、学习力代表未来!

【转】测试用例级别总结

上一篇 / 下一篇  2011-04-29 08:40:13 / 个人分类:软件测试相关

看了几篇关于用例级别如何设定的文章, 总结总结吧。

  根据二八原则或者称数据统计,前20%的用例可以发现80%的重要BUG。

  当设计测试用例时,分配优先级非常不容易,且这个优先级也不是固定不变的。

  一般,我们会假设发现的bug的严重程度和bug对应的测试用例的优先级是平行的。

  1、最高(又称Build Verification tests)也叫冒烟测试用例,一组你运行以确定这个build版本是否可测的测试用例。

  2、高:这种用例运行,能发现重要的错误,或者它能够保证软件的功能是稳定的。俗称大的基本功能的测试用例

  3、中:检查功能的一些细节,包括边界,配置测试

  4、低:较少执行的测试用例,并不代表它不重要,而是说不是经常被运行。例如压力测试错误信息等。

  用例级别设置的流程:

  1、如果没有很多的时间来确定优先级,那么可以先大致的进行划分:

  把所有功能性验证的用例标注为高

  把边界值或错误能力的用例标注为中

  把非功能性和易用性的标注为低

  2、提升和降级

  针对1描述的所有高级别的功能性用例划分为重要和不十分重要两种,然后重要的保持高,不十分重要的降级为中。同理,对应中级别的用例,重要的进行升级,不十分重要的保持中。对应低级别的,重要的升级,不十分重要的保持。

  3、确定BVTs

  将高优先级的用例划分为严重和重要, 严重的将升级为bvts

  经过这个流程后,大致会控制bvt10% 高为25% 中55% 低10%

  具体还要结合具体的项目和质量目标确定。

倘若从文档的角度,用例的级别首先要继承需求点的优先级级别,整理的测试需求进行优先级定义,然后对需求对应的测试用例进行优先级定义;

  因为在根据客户需求和产品需求说明书提取测试需求时,在所有的需求中,有客户急需使用的部分,有客户频繁使用的部分,有系统绝对不能出现错误的部分,这些都是高级别的需求点。

  所以要考虑四点:

  1、测试需求的级别

  2、测试用例导致的错误的级别

  3、测试用例对应的场景使用的概率(频率)

  4、测试用例发现问题的概率

  所以在实际测试中,若用例发现的bug频率很高,我们就应该适当地调节它的级别。

  又比如一个定义级别很高的用例,发现在实际测试中出现错误的触发条件是否罕见,所以就适当降低,或者客户需求产生了变化,对某个需求要求很低了,所以也适当降低。

  因此,

  1、建议将涉及到业务流程的用例,整理到一个专区,定义为P4

  2、每一个需求的主测试用例定义为P4

  3、每一个需求的辅助测试用例定义为P4或P3

  4、级别为高的需求点的完善性测试用例,建议性 易用性等,定义为P3 P2

  5、级别非高的需求点的主测试用例为P3 或P2

  6、级别非高的需求点的辅助用例完善用例 建议用例易用性用例为P2 P1

版权声明:本文出自myflap的51Testing软件测试博客:http://www.51testing.com/?280033

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。


TAG:

smith1982的个人空间 引用 删除 smith1982   /   2011-04-29 10:06:17
非常好
 

评分:0

我来说两句

simplezhuo

simplezhuo

得意之时谨记,一半命运还掌握在上帝手里;失意之时须知,一半命运还掌握在自己手里。

日历

« 2021-11-03  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 27983
  • 日志数: 124
  • 建立时间: 2011-02-13
  • 更新时间: 2017-03-08

RSS订阅

Open Toolbar