测试用例实例及优先级划分
参考文章：https://www.cnblogs.com/cheneyboon/p/11339795.html
https://wenku.baidu.com/view/f28003335f0e7cd1842536b0.html
http://www.51testing.com/html/27/n-848427.html
https://www.iteye.com/blog/onemonth-2005790
1.测试用例的模板
| 测试用例编号 | 用例名称 | 用例说明 | 前置条件 | 预置输入 | 执行步骤 | 优先级/重要程度 | 预期结果 | 实际结果 |
2.标题解释
测试用例编号：编号具有唯一性、易识别性，由数字和字符组合成的字符串，如你可以简单的用1做开始依次递增。
规则：系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX。
集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX。
单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX。
用例名称：测试用例的概括，简单的描述用例的出发点，关注点，原则上不能重复。
用例说明：描述当前所测试的功能点。
前置条件：执行当前测试用例需要的前提条件，是后续步骤的先决条件。如:登录账号时，前置条件就是账号已注册。
预置输入：输入测试的数据，如登录的账户名及密码。
测试步骤：1）要有条有理，一般分1，2，3步骤来写；
2）需要在步骤中描述操作环境等信息；
3）详细描述测试过程，言简意赅。
优先级（重要程度）：高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；
中：重要程度介于高和低之间的测试用例；
低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。
预期结果：应该出现的结果，使用错误的账号登录，应填写的结果为提示使用正确的账号密码登录。
实际结果：实际出现的结果，上例中如果输出的是登录成功，那么填写登录成功，即使使用的错误的账号，实际软件提示的结果。
3.实例
| 测试用例编号 | 用例名称 | 用例说明 | 前置条件 | 预置输入 | 执行步骤 | 优先级/重要程度 | 预期结果 | 实际结果 |
| HJWZ-ST-DL001-001 | 登录功能 | 界面文字显示正确性验证 | 登录页面打开正常 | 无 | 点击登录链接或按钮 | 低 |
1.界面文字显示正确，无错别字 2.表单，按钮正常显示，无重叠，可点击 |
与预期结果相同 |
4.测试用例的优先级
4.1 划分等级
P0： 核心功能测试用例（冒烟测试BVT），BVT也成为冒烟测试用例集。是每次测试开始allin投入前最希望被运行得以确认的测试用例集，此部分测试用例如果fail会阻碍大部分其他测试用例的验证。
P1： 高优先级测试用例，最常执行以保证功能性是稳定的；基本功能测试，重要功能测试，和重要的错误、边界测试。
举例：web信息系统中的各种增删查改功能，登录功能，权限管理，用户管理等核心功能。
P2： 中优先级测试用例，更全面的验证功能的各个方面，异常测试，边界、中断、断网、容错、UI等测试用例。
P3： 低优先级测试用例，不常常被执行，性能、压力、兼容性、稳定性、安全、可用性等等。
4.2 划分原则
1.使用频率或失效的概率：
系统的某些特定的被经常使用的功能优先级更高（若该功能包含了故障，其在被频繁使用而导致的概率将会很高，故该功能的用例具有更高的优先级）。
2.失效的风险
高风险失效的用例应该比低风险失效的用例具有更高的优先级（用户或客户在使用时，高风险失效导致的后果和造成的损失将更加严重）。
3.失效的可见性
失效对用户的可见性，是划分测试优先级的更进一步准则（尤其在交互系统中，用户可减的失效，例如：界面错误，会导致用户对产品的极度不信任）。
4.需求的优先级
系统对使用的用户来说，各个功能的重要性不同，某些不重要的功能对用户来说缺失该功能是致命的，但是有些功能，即使缺失，用户也是可以接受的。
5.质量特性
质量特性对用户也有不同的重要性，因此验证与重要质量特性是否一致的用例具有更高的优先级。
6.开发人员角度
能够导致系统或组件崩溃的测试用例具有更高的优先级。
7.测试对象的复杂性
复杂的程序的组件需要加强测试，因为开发人员可能在该位置引入更多的缺陷；但不是说简单的程序组件就可以忽视，该部分缺陷往往由于开发人员的粗心导致。
8.高项目风险的失效
存在高项目风险的缺陷应该尽早被发现（该类失效会导致大量的修正工作，并导致项目时间的明显延迟）。
9.缺陷的集群效应
在先前发现缺陷的位置可能会存在更多的缺陷。
4.3 划分方法（转自网络，如有侵权，请告知）
第一步：随意分配
I)把你所有功能性验证（或基本路径（Happy Path））的测试标注为高优先级别。
II)把你所有错误和边界值或确认测试标注为中优先级别。
III)把你所有非功能性的测试（例如性能和可用性）标注为低优先级别。
第二步：提升和降级
并非所有的功能性测试都一样的重要，并且和边界和非功能性测试一样的重要。思考一下测试的重要性及相对于其他同等优先级别的测试，你想要检查这个功能的频率，考虑质量目标和你项目的需求。
I)把功能性验证测试分为两组：重要和不是十分重要。
II)将“不是十分重要”的能性验证测试降级为中优先级别。
III)把错误和边界测试分成两组：重要和不是十分重要。
IV)将“重要”的错误和边界测试升级为高优先级别。
V)把非功能性测试分成两组：重要和不是十分重要。
VI)把“重要”的非功能性测试升级为中优先级别。
VII)针对每组高，中和低优先级别的测试用例，重复划分和升级/降级流程直到你达到一个点，可以在不同优先级别之间移动的测试用例的数量到最小。
在这个流程的最后，就是要检查优先级别的百分比分布情况是：高为20-30%,，中为40-60%，低为10-15% 。
在升级和降级测试用例时，需要考虑的方面是用户将要求这个功能或功能性的频率是怎样。同样的，对于用户日常的或月尾的活动而言，这种行为的严重性是如何。Robyn Brilliant在测试进度报告中提供了一个清单，你可以在考虑降级或升级测试用例的时候使用
使用从一到五的一个刻度，从最严重到最少的严重程度，量化可靠性风险如下：
I)这个功能的失败将影响用户。
II)这个功能的失败将给公司造成重大的影响
III)这个功能的失败将引起一个潜在的延期给客户
IV)这个功能的失败对公司将有较小的影响
V)这个功能的失败没有任何影响
这个和其相似的刻度可以帮助你达到你测试用例优先级别划分的最后一步。
总结：
这是一个简化的划分测试用例优先级别过程的例子。然而，在快速组织测试用例和安排测试进度和工作量，及制订项目计划时需要完成哪些测试用例等方面，它可以给你很多帮助。
记住，你怎样给你的测试任务划分优先级和如何执行测试用例将取决于你在你的项目周期的位置。当你朝发布前进并通过调查和观察确定危险和缺陷出现的地方时，你可能会重新给你的测试用例划分优先级别。向上为每个阶段建立你的测试目标并保证他们在你的测试用例的优先级别上被反映，当它在解释并执行你的计划时，将使你的生活变得容易得多。
最后，拥有划分了优先级别的测试用例也为你潜在的，待定的自动化项目给出了一个好的起点。比如，自动化中的测试用例，度量收益，改进测试自动化，自动化高优先级的测试用例等方面。
