用例级别定义

hueslife

以下均为引用csdn上一个仁兄的观点，大家来说说自己的理解和看法吧：

用例级别：

表明该用例的重要程度。用例的重要性并不对应用例可能造成的后果，而是对应用例的基本程度，一个可能导致死机的用例未必是高级别的，因为其触发条件可能相当生僻。测试用例的级别分4级：

级别“1”：基本：正向。该类用例涉及系统基本功能，主要是系统业务流程正向的测试用例。用于版本提交时作为“版本通过准则”。如存在不通过的项目时可考虑重新提交版本，例如申请书不能添加成功等。1级用例的数量应受到控制。

级别“2”：基本：反向。该类用例涉及系统基本功能，主要是系统业务流程反向的测试用例。该类用例涉及单个版本特性，例如添加依托单位未注册的申请书，可定义为2级用例。

级别“3”：详细。该类用例仅影响某单项功能的某一细节方面。例如某新业务的登记和使用正常，但和另一个新业务发生不应有的冲突。有关性能、极限（大容量）、数据库中断等方面的测试可归入3级用例。有关用户界面的基本规范等方面的测试可归入3级用例。

    级别“4”：生僻。该类用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误，但是那些用例的触发条件非常特殊，仍然应该被置入4级用例中。 有关用户界面的优化等方面的测试可归入4级用例。


定义用例的级别，即是定义此用例在测试执行过程中的重要程度，包括优先执行
第一、继成测试需求的优先级
第二、根据发生错误的可能性
第三、根据发生错误的危害性
第四、此功能点使用的频繁程度




据我所理解，定义用例级别是为说明用例在测试执行时的优先程度以及用例的重要程度，而用例执行的优先程度首先取决于该用例所测试的用户需求点的紧急程度、使用频率以及重要程度，因此，个人觉得用例的级别定义首先要继承测试需求点的优先级别，那么就先应先将整理的测试需求进行优先级定义，而后再对需求点对应的系列测试用例的优先级别进行定义。

在根据用户需求和需求分析文档提取测试需求时，我们会知道所有需求中，那些是用户急需使用的部分，那些是用户使用频繁的部分，那些是系统最不能出现错误的部分等等，那么这些部分就是我们测试级别最高的需求点。

综上，个人觉得定义用例级别，应考虑如下事项：
1、继承测试需求的优先级别
2、用例在用户实际使用时使用的概率及频率
3、用例导致错误的概率
4、用例导致系统发生错误后对系统的危害性

当然，用例的级别不是一定下来就不变的，根据实际测试过程中的实际情况，可以变化，如：最初定义级别低的一个用例，由于在实际测试中，发生错误的的概率比较高，那么我们就应当在本轮测试结束前提高此用例的级别；再如：最初定义级别高的一个用例，由于在实际测试中导致出现错误的触发条件或操作组合或用户使用频率非常不易达到，或者，由于用户需求变更，导致此需求点变为使用概率非常低的功能点了，那么我们就应当在本轮测试结束前降低此用例的级别，等等。

根据我们现在具体的情况，本人对用例级别定义建议如下：
1、由于我们系统的业务流程性比较繁杂，建议将业务流程的测试用例整理到一个专门区域，定义为级别高的用例
2、对继承的需求级别，其中，每个需求测试点的主测试用例定义为级别高的用例
3、对继承的需求级别，其中，级别为高的测试需求点的主要辅助测试用例级别定义为高或次高
4、对继承的需求级别，其中，级别为高的测试需求点的完善性测试用例、建议性测试用例、易用性测试用例等定义为次高或一般
5、对继承的需求级别，其中，级别为非高的测试需求点的测试用例定义为次高或一般
6、对继承的需求级别，其中，级别为非高的测试需求点的完善性测试用例、建议性测试用例、易用性测试用例等定义为一般或低
7、允许用例级别的调整

以上纯属个人意见，不尽之处敬请各位指正！谢谢！