测试用例的优先级别

识别小版本验证测试用例（Build Verification Tests）：
　　为了确保小版本是可以测试的并准备好给小组其他成员开始测试，哪些测试用例是必须在每个小版本中都检查呢？
　　(a) 将好优先级别的测试用例分成两组：严重和重要的
　　(b) 将“严重”的高优先级的测试用例升级为BVT优先级

　　注意：不要先识别BVT测试用例！BVT只是高优先级别测试用例的精选，它们已经被确定为对系统和测试是非常重要的。

　　在这个流程的最后，就是要检查优先级别的百分比分布情况是：BVT为10-15%，高为20-30%,，中为40-60%，低为10-15% 。

 

在升级和降级测试用例时，需要考虑的方面是用户将要求这个功能或功能性的频率是怎样。同样的，对于用户日常的或月尾的活动而言，这种行为的严重性是如何。下面提供了一个清单，可以在考虑降级或升级测试用例的时候使用

　　使用从一到五的一个刻度，从最严重到最少的严重程度，量化可靠性风险如下：
　　(a) 这个功能的失败将影响用户
　　(b) 这个功能的失败将给公司造成重大的影响
　　(c) 这个功能的失败将引起一个潜在的延期给客户
　　(d) 这个功能的失败对公司将有较小的影响
　　(e) 这个功能的失败没有任何影响
这个和其相似的刻度可以帮助设计者达到测试用例优先级别划分的最后一步。

　　总结

这是一个简化的划分测试用例优先级别过程的例子。然而，在快速组织测试用例和安排测试进度和工作量，及制订项目计划时需要完成哪些测试用例等方面，会有很多帮助。

首先，必须确定什么是优先级别的类型和其暗示着什么。就我们的目的来说， 我们将用一个假设开始，那就是我们可能发现的缺陷的严重程度和那些相应测试用例的优先级别之间是平行的。

    1 –小版本确认测试（BuildVerification Tests(BVTs)：也叫做“冒烟测试”，一组想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。

    2 – 高（Highs）：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。

    3 – 中（Mediums）：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例。

    4 – 低（Lows）：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性，压力和性能测试。

　　我们将测试用例分成4类：BVTs，高，中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟，优先级别将指出哪些测试用例被认为是需要更频繁的执行的，哪些又不是

 

怎样着手分配优先级别

　　1）随意地分配：

基于如果没有足够的时间测试却又至少要保证所有的产品需求已经被确认可以在设想的良好状况下像它们被期望的那样工作的想法，前面这3步将让可以任意的分组测试用例，如果停下来思考每个测试用例的测试的内容，它们都将变的很重要。因此只需要：
　　(a)  把所有功能性验证（或基本路径（Happy Path））的测试标注为高优先级别
　　(b)  把所有错误和边界值或确认测试标注为中优先级别

　　(c)  把所有非功能性的测试（例如性能和可用性）标注为低优先级别.

  

    2）提升和降级：

　　并非所有的功能性测试都一样的重要，并且和边界和非功能性测试一样的重要。思考一下测试的重要性及相对于其他同等优先级别的测试，想要检查这个功能的频率－考虑质量目标和项目的需求。

　　(a) 把功能性验证测试分为两组：重要和不是十分重要。
　　(b) 将“不是十分重要”的能性验证测试降级为中优先级别
　　(c) 把错误和边界测试分成两组：重要和不是十分重要
　　(d) 将“重要”的错误和边界测试升级为高优先级别
　　(e) 把非功能性测试分成两组：重要和不是十分重要
　　(f) 把“重要”的非功能性测试升级为中优先级别
　　(g) 针对每组高，中和低优先级别的测试用例，重复划分和升级/降级流程直到达到一个点，可以在不同优先级别之间移动的测试用例的数量到最小。