测试用例是对需求的另一种描述，它能引导大家进一步加深对系统的理解和对特性的全面关注，从而帮助产品和开发重新审核需求的合理性和一致性，所以应该是测试工程师最重要的一项产出。

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

根据二八原则或者称数据统计，前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

【编辑推荐】

1. 浅谈优秀的测试用例
2. 心中的测试用例结构 为新模型做准备
3. 浅谈测试用例分析和设计
4. 如何有效减少测试用例数目