当前位置：文档库 › 软件测试之软件测试中浅析软件测试用例的优先级(完整版)

软件测试之软件测试中浅析软件测试用例的优先级(完整版)

软件测试中浅析软件测试用例的优先级

由安博测试空间技术中心https://www.wendangku.net/doc/a34819679.html,/提供

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

测试用例的定义：

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

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

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

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

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

Sue Bartlett在“How to Find the Level of Quality Your Sponsor W ant s”一文中详细的讨论了这个问题，她在文中注解到：“当我们在详细的计划，设计或编码之前沟通质

量目标时，我们有一个更好的机会来避免在最后时刻的质量不匹配，那意味着迎合计划，弥补花费并且赢利将有一个更好的成功的机会。”

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

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) 把你所有错误和边界值或确认测试标注为中优先级别

2)提升和降级：

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

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

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

(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) 这个功能的失败将给公司造成重大的影响

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

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

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

总结

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

记住，你怎样给你的测试任务划分优先级和如何执行测试用例将取决于你在你的项目周期的位置。当你朝发布前进并通过调查和观察确定危险和缺陷出现的地方时，你可能会重新

给你的测试用例划分优先级别。向上为每个阶段建立你的测试目标并保证他们在你的测试用

例的优先级别上被反映，当它在解释并执行你的计划时，将使你的生活变得容易得多。

最后，拥有划分了优先级别的测试用例也为你潜在的，待定的自动化项目给出了一个好

的起点。比如，自动化BVT中的测试用例，度量收益，改进测试自动化，自动化高优先级的

测试用例等方面。

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

软件测试中获取负面测试用例的技术

由安博测试空间技术中心https://www.wendangku.net/doc/a34819679.html,/提供

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，

以便测试某个程序路径或核实是否满足某个特定需求。

测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软

件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试

环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理

软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我

们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品

的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的

测试构成了一个个测试用例。

要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

确定测试用例之所以很重要，原因有以下几方面。

测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可

以更准确地估计测试周期各连续阶段的时间安排。测试设计和开发的类型以及所需的资源主要都受控于测试用例。测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：·一个测试用例用于证明该需求已经满足，通常称作正面测试用例；·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

1. 负面测试的目的

负面测试在BS7925-1中的英国标准定义是采用Beizer的定义，其定义负面测试为“旨在说明软件不能工作的测试”（原文：Testing aimed at showing software does not work）。它可以带出一系列补充性的和竞争性的目的。

?发现导致重大失效、崩溃、破坏和安全漏洞的故障

?观察和度量系统对外界问题的响应

?揭露软件的弱点和开发的潜力

虽然有个一个公正的定义，但是它离被普遍接受还差的很远。负面测试是一个紧跟着被重新定义的术语，有时甚至是各小组的。一个常见的方法，其实践和英国标准定义不同的是它包括旨在使用专门对付失效的功能的测试。

? 输入验证，拒绝和重新请求的功能（人工输入和外界系统）

? 内部数据验证和拒绝

? 应付缺乏的，缓慢的或坏掉的外界资源

? 错误处理功能，例如消息，日志，监视功能

? 恢复功能，例如故障恢复，回滚和恢复

2. 获取测试用例的技术

负面测试不是一种测试设计技术，说是一种方法或分类更加合适。使用许多正式的测试设计技术来获取那些能够被划分为‘负面测试’的测试是很有可能。这一节详述了各种各样的知名技术的应用。

? 边界值分析和等价类划分Boundary Value Analysis and Equivalence Class Partitioning

? 状态转换测试State Transition testing

? 逆着已知的约束测试Test against known constraints

? 故障模式和结果分析Failure Mode and Effects analysis

? 并发Concurrency

? 用例和误用的用例Use cases and mis-use case s

2.1. 边界值分析和等价类划分

有两种基于输入和输出数据和系统行为期望的技术。

边界值分析（BVA：Boundary Value Analysis）利用关于预知系统行为转换位置的边界的需求和设计来检查那些能够带出一连贯范围数值的数据元素。

这个方法用于产生三个数值－一个就是边界本身，另外两个在前者的两边（尽可能的和数字相接近）。如果边界在有效和无效范围之间，使用无效数值的测试用例将成为一个负面测试用例。例如，使用66在只接受从18～65数值的年龄字段。

等价类划分（ECP：Equivalence Class Partitioning）着眼于边界之间的范围。给出的等价类中的每个成员应该在一个已知测试的环境里，使系统做同样的事情－这样测试员不必要测试在等价类中每一个数值。无效输入数据的范围可以被看成为负面测试－例如，一个年龄

字段可能被期望用相同的方法拒绝所有的负数。

ECP一般被延伸到包括非连续数值的集合，胜于连续的数值范围。要注意一些输入可能看上去等价，但是实际上出现很多不同的行为。例如，一个简单web的表单的输入是为空或者太长时可能会被拒绝，但是控制字符的正确组合可能危害潜在web服务器的安全。

2.2. 状态转换测试

假设有一个状态转换图或者一个与其等价的理解，那么就很容易获得可以明确地检查不可到达的状态是否真的不可到达的测试用例。与这种方法相同的变种称为n-switch 测试，在一套已知的转换之后，那些不可到达的状态仍然是不可到达吗？图形工具，例如Compendium-TA [4]能够帮助你获得这样的测试。

2.3. 逆着已知的约束测试

大多数的系统有明确的和含蓄的限制和约束。如同需求一样对待这些约束（参加Robinson+Robinson, [5])）就可以得到各种负面测试。例如：

? “The site is designed to be viewed with Internet Explorer 4.5 or later” –负面测试可以使用IE3.0或Netscape.

? “No more than five users will use the system at the same time” –负面测试可以尝试6个，然后8。

概括来说，测试包括度量和观察系统的行为胜于直接逆着期望结果测试。这只能在系统的操作参数之外工作时被使用，并且这种观察可能导致对系统的进一步了解。

2.4. 故障模式和结果分析

从对潜在的技术，实现和已知故障的分析来预见系统特有的故障是很有可能的。这种分析是观察在故障条件下系统行为的测试基础。捕获和文档化这种信息是非常重要的－特别是如果他们允许诊断数据和环境。对于那些监视他们系统并且拥有在系统被使用时（例如银行，电话公司）可以采取行动的技术专家的组织而言，这些文档通常是测试的必要输出。另一方面，对于更广泛的分布式软件包来说，这些信息也可以成为FAQ或故障诊断指南的一部分。这些测试可能不可能在没有一个有效的测试工具或应用驱动下执行。这样的工具通常是自定制的，并且可能需要在代码的已提交版本里运行。

然而，象Canned HEAT和Holodeck (都出自the Florida Institute of Technology, [6])这样的工具允许将普通性故障引入到运行在Windows的软件中。

6.4.1. 故障家族

有很多来源可以帮助你开发故障模式的家族。既有故障的根本原因分析，系统设计文档，基础设施特有问题的知识能够帮助识别故障模式，并且因此为获取测试提供来源。

以下列表虽不详尽，但或许可以帮助引发更多的关于可能的故障想法。

? 外部资源：反应迟钝或缓慢的，莫明其妙或不恰当的反应。

? 协处理器故障：独特的间断处理器，多任务和递归

? 并发使用：资源锁定，请求已拒绝的锁定，死锁，锁定响应延迟

? 牺牲处理器Sacrificial processes：允许失败的处理器并且用可控方式恢复

? 文件系统：文件不能被找到，打开，读，写，权限变更，文件系统识别介质错误，介质移除，介质装满

? 网络：网络中断，网络忙碌/缓慢，传输段丢失、损坏、无序，处理器之间的对话被中断? 内存：不足以给请求的分配，碎片

? 已达到的限制：排队，licences，线程，连接，数组大小，资源分配

2.5. 并发

测试对资源的并发使用可以是一个非常富有成效的找bug方法。初始分析包括鉴别也许会尝试同时使用的数据，数据库条目，文件、连接和超过一个处理器的硬件。通过允许测试者在系统之前利用资源，简单，定制的工具可能有些帮助, 并且在他们选择的时候发布它。测试也应该检查第二个请求者最终得到了资源。更加复杂的测试将着眼于二个以上的请求, 排队, 超时和死锁。

2.6. 用例和误用的用例

用例，在实践中趋向于处理系统的‘happy path’。各种错误输入的覆盖，拒绝的循环和部分转换通常是很稀少的。‘误用的用例’术语，虽然不是偏僻的标准，但是能够帮助明确地识别和区分他们。执行这些路径地用例可以通过图解期望结果正常范围外的用户的活动来帮助提高设计，并且允许一个正式的方法来测试选择和覆盖。