测试用例是对需求的另一种描述,它能引导大家进一步加深对系统的理解和对特性的全面关注,从而帮助产品和开发重新审核需求的合理性和一致性,所以应该是测试工程师最重要的一项产出。
看了几篇关于用例级别如何设定的文章, 总结总结吧。
根据二八原则或者称数据统计,前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
名称栏目:测试用例级别总结
本文链接:http://www.shufengxianlan.com/qtweb/news17/367267.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联