1 –小版本确认测试(Build Verification Tests (BVTs)：也叫做“冒烟测试”，一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。
2 – 高(Highs)：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
3 – 中(Mediums)：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例
4 – 低(Lows)：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性，压力和性能测试。
我们将测试用例分成4类：BVTs，高，中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟，优先级别将指出哪些测试用例被认为是需要更频繁的执行的，哪些又不是。
怎样着手分配优先级别
1) 随意地分配：
基于如果你没有足够的时间测试却又至少要保证所有的产品需求已经被确认可以在设想的良好状况下象它们被期望的那样工作的想法，前面这3 步将让你任意的分组测试用例，如果你也停下来思考每个测试用例的测试的内容，它们都将变的很重要。因此只需要：
I) 把你所有功能性验证(或基本路径(Happy Path))的测试标注为高优先级别
II) 把你所有错误和边界值或确认测试标注为中优先级别
III) 你所有非功能性的测试(例如性能和可用性)标注为低优先级别.
2) 提升和降级：
并非所有的功能性测试都一样的重要，并且和边界和非功能性测试一样的重要。思考一下测试的重要性及相对于其他同等优先级别的测试，你想要检查这个功能的频率-考虑质量目标和你项目的需求。
I) 把功能性验证测试分为两组：重要和不是十分重要。
II) 将“不是十分重要”的能性验证测试降级为中优先级别
III)把错误和边界测试分成两组：重要和不是十分重要
IV) 将“重要”的错误和边界测试升级为高优先级别
V) 把非功能性测试分成两组：重要和不是十分重要
VI) 把“重要”的非功能性测试升级为中优先级别
VII) 针对每组高，中和低优先级别的测试用例，重复划分和升级/降级流程直到你达到一个点，可以在不同优先级别之间移动的测试用例的数量到最小。
3) 识别小版本验证测试用例(Build Verification Tests)：
现在，为了确保小版本是可以测试的并准备好给小组其他成员开始测试，哪些测试用例是必须在每个小版本中都检查呢?
文章来源于领测软件测试网 https://www.ltesting.net/
