测试用例优先级划分

        这份是在网上看到的,觉得不错就转发了。

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

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 步将让你任意的分组测试用例,如果你也停下来思考每个测试用例的测试的内容,它们都将变的很重要。因此只需要:

(a) 把你所有功能性验证(或基本路径(Happy Path))的测试标注为高优先级别

(b) 把你所有错误和边界值或确认测试标注为中优先级别

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

2)提升和降级:

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

(a) 把功能性验证测试分为两组:重要和不是十分重要。

(b) 将“不是十分重要”的能性验证测试降级为中优先级别

(c) 把错误和边界测试分成两组:重要和不是十分重要

(d) 将“重要”的错误和边界测试升级为高优先级别

(e) 把非功能性测试分成两组:重要和不是十分重要

(f) 把“重要”的非功能性测试升级为中优先级别

(g) 针对每组高,中和低优先级别的测试用例,重复划分和升级/降级流程直到你达到一个点,可以在不同优先级别之间移动的测试用例的数量到最小。

3)识别小版本验证测试用例(Build Verification Tests):

        现在,为了确保小版本是可以测试的并准备好给小组其他成员开始测试,哪些测试用例是必须在每个小版本中都检查呢?

(a) 将好优先级别的测试用例分成两组:严重和重要的

(b) 将“严重”的高优先级的测试用例升级为BVT优先级

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

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

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

使用从一到五的一个刻度,从最严重到最少的严重程度,量化可靠性风险如下:

(a) 这个功能的失败将影响用户

(b) 这个功能的失败将给公司造成重大的影响

(c) 这个功能的失败将引起一个潜在的延期给客户

(d) 这个功能的失败对公司将有较小的影响

(e) 这个功能的失败没有任何影响

这个和其相似的刻度可以帮助你达到你测试用例优先级别划分的最后一步。

参考资料: http://tech.sina.com.cn/s/2009-11-11/12471128458.shtml

©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

  • 怎么样的设计才能算测试用例 引自:IEEE Standard 610 (1990): A set of test ...
    Criss陈磊阅读 4,529评论 0 0
  • 参考https://www.cnblogs.com/dulijuan/p/4474657.htmlhttps://...
    Helen_Cat阅读 10,179评论 0 28
  • 1.测试与软件模型 软件开发生命周期模型指的是软件开发全过程、活动和任务的结构性框架。软件项目的开发包括:需求、设...
    宇文臭臭阅读 11,712评论 5 101
  • 1.问:你在测试中发现了一个 bug ,但是开发经理认为这不是一个 bug ,你应该怎样解决。 首先,将问题提...
    qianyewhy阅读 13,056评论 4 123
  • 1.0测试用例框架 1.1黑盒测试概述 •黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测...
    ltfdhr阅读 6,389评论 0 4

友情链接更多精彩内容