从未有足够的时间做所有我们需要做的事情，这是在软件项目，尤其在测试中的一个普通的话题。假使你在可用的有间内，你如何知道你的测试工作做的好？你知道当应用程序发布时，总会有些遗漏的缺陷没有被发现。对于测试而言，目标是通过改进产品质量使风险减到小，并且这可以部分的通过建造一套具体的测试用例来将应用程序按照它的速度完成等方法实现。

　　IEEE Standard 610 (1990) 中定义测试用例为：

　　1. 为一个为特定目标而开发一组测试输入，执行条件和的期望结果，例如测试某个程序路径或核实是否满足某个特定的需求。

　　2.指定输入，预期结果和一组测试项的执行条件的文档 (IEEE Std 829-1983)。

　　当然，你将发现在项目的生命周期里的每一个应用程序的版本上执行你全部的测试用例是很困难的。但是你将如何知道哪个测试用例必须在每一个版本中执行，什么应该被执行，同时如果你有时间的话，什么又可以被执行？

　　给你的测试用例划分优先级别

　　你的应用程序不需要十全十美，但它必须迎合你目标用户的需求和期望。为了了解你项目的期望，你需要确定什么是应用程序中重要的，目标和风险又是什么。

　　Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中详细的讨论了这个问题，她在文中注解到：“当我们在详细的计划，设计或编码之前沟通质量目标时，我们有一个更好的机会来避免在后时刻的质量不匹配，那意味着迎合计划，弥补花费并且赢利将有一个更好的成功的机会。”

　　为了测试计划的目的，在你项目版本的进度下，测试执行的组织和安排你的测试用例将帮助达到这些目标。作为这种组织的一部分，我们要考虑每一个测试用例的优先级别。根据优先级别分组你的测试用例将帮助你决定不同类型的版本需要什么样的测试用例，因此计算需要的时间。如果你只有有限的时间，你可以查看什么是合适。

　　Ross Collard在"Use Case Testing"一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。

　　测试用例的优先级划分将帮助确定找出了这前10%到15%的测试用例。

　　如何划分测试用例的优先级别

　　你曾查看过多少次你的测试用例并且能够很容易的挑选出重要的一个小的子集？这个答案可能是不经常。停止思考“所有的测试用例都是同等重要”这个问题是非常困难的。当设计测试用例时，分配优先级别是不容易，并且在项目期间里不一定是静止的。然而，我们可以通过构造一个划分优先级别流程的例子来开始处理划分测试用例优先级别的第一步。让我们假设你刚刚根据功能说明书， 用例和其他一些关于你应用程序的目标行为和能力的信息源完成了建立测试用例。现在是时候来为每个测试用例分配一个优先级别了。

　　测试用例的优先级别

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

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

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

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

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

　　我们将测试用例分成4类：BVTs，高，中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟，优先级别将指出哪些测试用例被认为是需要更频繁的执行的，哪些又不是，怎样着手分配优先级别.
　1) 随意地分配：
基于如果你没有足够的时间测试却又至少要保证所有的产品需求已经被确认可以在设想的良好状况下象它们被期望的那样工作的想法，前面这3 步将让你任意的分组测试用例，如果你也停下来思考每个测试用例的测试的内容，它们都将变的很重要。