测试用例的优先级别划分

摘自网络:http://www.educity.cn/se/523513.html

测试用例的优先级别

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

  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):

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

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

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

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

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

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

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

  I)这个功能的失败将影响用户。

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

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

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

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

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

  总结:

  这是一个简化的划分测试用例优先级别过程的例子。然而,在快速组织测试用例和安排测试进度和工作量,及制订项目计划时需要完成哪些测试用例等方面,它可以给你很多帮助。

  记住,你怎样给你的测试任务划分优先级和如何执行测试用例将取决于你在你的项目周期的位置。当你朝发布前进并通过调查和观察确定危险和缺陷出现的地方时,你可能会重新给你的测试用例划分优先级别。向上为每个阶段建立你的测试目标并保证他们在你的测试用例的优先级别上被反映,当它在解释并执行你的计划时,将使你的生活变得容易得多。

  最后,拥有划分了优先级别的测试用例也为你潜在的,待定的自动化项目给出了一个好的起点。比如,自动化BVT中的测试用例,度量收益,改进测试自动化,自动化高优先级的测试用例等方面。

时间: 2024-10-06 01:18:51

测试用例的优先级别划分的相关文章

测试用例之等价划分

前提 程序输入测试数据,怎么才能够算得上最全面的测试?输入所有的可能性,利用穷举法进行测试.但是,想一想就会知道,穷举法测试是一种低成本并且无法实现的测试.所以,我们所能做的工作就是,如何设计最少的测试用例做最全面的测试. 测试用例中常用到的一种方法,等价类划分,就是解决如何选择适当的数据子集来代表整个数据集的问题,通过降低测试的数目去实现"合理的"覆盖,覆盖了更多的可能数据陷.在这里详细的跟大家介绍一下. 一.理论 定义 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),

测试用例的优先级别

一.测试优先级的划分 1.测试时间和资源有限,可能无法执行所有的测试用例,穷尽 测试是不可能的 2.首先执行最重要的测试用例或优先测试用户最需要的功能,尽快尽早发现可能多的bug 3.测试用例优先级的划分和测试执行顺序的确定,取决于项目的特征,应用领域和客户的要求 4.即使测试过早结束,也要保证在时刻测试工作能达到最好的效果 二.测试优先级的划分细则 1.使用频率或失效的概率 2.失效的风险 3.失效的可见性 4.需求的优先级 5.质量特性 6.开发人员的角度 7.测试对象的复杂性 8.高项目风

软件测试理论测试用例测试之等价类划分

定义 把所有可能输入的数据,即程序的输入域划分策划若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例,是一种黑盒测试方法 有效等价类和无效等价类    有效等价类指对于程序规格说明来说,是合理的.有意义的输入数据构成的集合 无效等价类和有效等价类相反,无效等价类是指对于软件规格说明而言,没有意义的.不合理的输入数据集合 等价类划分原则 如果输入条件规定了取值范围,或值的个数,则可以确立一个有效等价类和两个无效等价类 如果输入条件规定了输入值的集合,或者"必须如何"

测试用例举例之等价类划分

概念 根据可能输入域数据,划分成若干个子的输入域子集,从每一个子集中选取少数具有代表性的数据作为测试用例. 设计方法:找出输入条件,划分等价类,测试用例编写 等价类划分有两种不同的情况:有效等价类和无效等价类,一般要求一条用例尽量多的覆盖有效等价类,而无效等价类则要求一对一的覆盖 有效等价类:指用户输入的有效数据,并得到预期的或正常的结果 无效等价类:异常的或不符合规定的输入,相应的也会得到异常的输出或提示信息 编写方法 从划分出的等价类中按以下三个原则设计测试用例: (1)每一个等价类规定一个

黑盒测试用例设计技术--等价类划分法

本文通过案例的形式,详细讲解黑盒测试用例设计技术中的等价类划分法. 等价类划分是一种典型的黑盒测试方法,其原理是把程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例. 通过等价类划分,可以在尽可能覆盖所有测试路径的前提下,大幅度减少测试用例的数目. 本文的主要内容有: 等价类的概念介绍 划分等价类的原则 根据等价类设计测试用例的方法 案例演示 划分等价类 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理的假设,

【转】编写接口测试的测试用例体会

来淘宝目前已经3周了,这三周只重复地做了一个事情,编写测试用例,修改测试用例.不断地修改让我对自己的语言组织能力和逻辑思维能力产生了怀疑,同时,越来越觉得测试用例的写法扑朔迷离.我问了3个人,结果每个人都告诉我不同的写法.把我自己弄的不知所措.但是问的多了,慢慢也就明白了,每个人都有每个人的编写风格,作为测试新人,我们要了解如何去编写测试用例,而不是copy别人的测试用例.只有真正了解了如何去编写,才能写出有自己风格的测试用例. 测试用例基本上都包括以下五部分: 1.前置条件 2.输入参数 3.

软件测试用例知识点梳理

一.概念 怎样以最少的人力.资源投入,在最短的时间内完成测试,去发现软件系统的缺陷(bug),保证软件的优良品质,是软件公司探索和追求的目标. ▲测试用例是测试工作的指导,是软件测试的必须遵守的准则,更是软件测试质量稳定的根本保障 ▲测试用例是指为实施测试而向被测试系统提供的输入数据,操作或者各种环境设置以及期望结果的一个特定集合. 简单来说------测试用例就是解决要测什么,怎么测和如何衡量的问题 二.测试用例的属性: 1.用例ID(编号) 2.用例名称() 3.测试目的 4.测试级别 5.

作为测试人员,如何写好优秀的测试用例

作为一名功能测试人员,最基本的要求就是能写出测试用例.一份好的用例直接反映出测试人员的思维方式和严谨性.那么我们就要想了,何写好一份测试用例,利用所写用例来测试验证产品质量呢? 写好测试用例,需要多方位的思考. 1.   测试用例设计 这是写好用例的前提,尽可能多的站在不同的角度分析问题.比如在运营维护.用户等角度来看待软件,分别针对性的设计测试用例; 2.   测试用例设计方法 这个是测试工程师必备的技能,通过项目的需要来划分测试粒度,然后设计测试用例,具体的方法可能有这些: 边界值分析法:对

[Tommas] 测试用例覆盖率(一)

一.测试用例的切面设计 所谓测试切面设计,其实就是测试用例大项的划分.测试用例划分的经典方法是瀑布模型,也就是从上到下,逐渐细分,大模块包括小模块,小模块包括更小的模块.但仅仅如此是不够的,我们还要从更多的角度切入系统,从不同的角度把系统切分成一块一块的,来进行测试,从而确保测试大项的完整性. 1.功能点切面 这是最常见的切面,通常我们认为页面上的一个按钮就是一个功能点.然后我们可以根据功能的复杂程度,按每个功能:或一个功能点分多页:或多个功能点合成一页来进行用例的撰写. 2.特定切面 除此以外