测试用例是对需求的另一种描述，它能引导大家进一步加深对系统的理解和对特性的全面关注，从而帮助产品和开发重新审核需求的合理性和一致性，所以应该是测试工程师最重要的一项产出。
看了几篇关于用例级别如何设定的文章， 总结总结吧。
根据二八原则或者称数据统计，前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.51testing.com/html/12/n-232512.html
【编辑推荐】
