探究用例以改善测试质量测试用例:2

优先级

将要执行的测试用例进行排序是测试组织十分关键的一种管理工具。有好几种确定优先级的方法，要选择合适方法，对于不同的项目、团队和开发方法有不同的方法。不管测试优先级是如何操作的，用例都会提供一个比旧的需求方法更精简的过程。

另一个估计技术，用例功能点(UCFP) 评估，是功能点计算方法的改编。它与 COCOMO 方法有相同的风险。由于支持评估的这两种比较旧的方法基础存在一定的缺陷，想连接细节层次与分解之间的鸿沟，被认为是很难有效地被克服。然而，由于 ROM 估计有被锁定的趋势，并在项目早期考虑到了后果，因此任何提供可靠信息的并且与测试估计相关的工具，在此过程早期仍然有一定的价值。

估计估算

正如我们在下面部分将要显示的，用例为改善测试质量和效力提供了引人注目的利益。

然而，对于可追溯性最纯粹的经济变量是，它提供证明来执行一个具体的测试。大家都知道每个测试用例都可以被追溯，最终到一个业务需求，测试计划者可以确保测试是由当前财政所负担的，而不是其它机构所负责。相反，这个方案的发起者就能够直接识别这个方案正向他们提供业务价值的。

·用LoadRunner编写socket应用的测试脚本

有时它会被引用作为不同的分支、径，或者变异性识别，在测试设计者识别各种方法的所有用例中，用户或者外部的系统都可以执行这个用例。在这个过程的这一点上，用例为识别有效测试，清除多余径，以及在不用猜想的情况下设计黑盒测试提供了一个方法作为覆盖范围。通过识别整个用例的所有可变径，测试人员能够指出在哪些地方径覆盖了其它情景。覆盖的或者多余的径是从计划测试用例执行库中清除的候选者。Clay Williams 通过研究行为和序列确定了一种优化测试用例生成的方法。当清除多余区域时，叫作“Method and System for Generating an Optimized Suite of Test Cases”的用一种算法可以使覆盖区域达到最少的测试用例。

为适当的阶段开发适当的测试

在一个解决方案所有质量因素中最关键的是开发和交付过程所有阶段的需求能力。IEEE 引用从一个工件到另一个工件的连接元素，并用这种定义作为这个中单纯证明。用例能够定义前任继承者关系，并为驱动因素示例特征。

·【高端】寻找下一代CTO向冠军冲刺

·LoadRunner脚本编程

在传统的过程中，测试人员将附有高水平用户结果的技术与需求团队连接起来。用这种方法决定测试优先权浪费时间而且容易出错，因为它需要将用户的心里印象和/或者多个测试用例的重组逆转回到发起者开始想要表达的的基于情景的目标。利用用例，这些容易出错的行为几乎不存在。因为它们直接映射到测试下功能想要的结果中， 测试可以很容易地被按照发起者先前建立的关键需求的顺序来排序。每个测试有了目标以后更容易被识别，优先级最难的点变成了使业务发起者按照重要程度处理新的或者变更的功能的排序问题。

·【高端】畅谈“寻找下一代CTO”

用例还提高了缺陷优先处理的精确度。当一个测试失败了，基于用例的方法可以迅速确定问题的分类和优先权，因为这个用例的整体重要性已经被建立。测试人员可以直接依赖发起者在制定需求规范时赋予这个具体用例的值，而不是对缺陷进行主观地评估。缺陷优先排序几乎变成瞬间而且无可争议了。而且，在缺陷发现和它的优先权确定的时间也大大减少了。

当利用这些用例模式时，测试人员可用更有效地设计和执行测试。用例模式允许测试人员从视觉上识别他们地测试用例，尤其是当这个过程包括一个用例图时。

这个用例点方法(UCPM) 似乎为有效测试估计提供了最高的潜能。这种方法的开发是建立在更新的设计方法基础上的，而不是被更新来处理用例的使用的。1992年 Gustov Karner 介绍过，这个评估是由用例的元素驱动的。通过一些修改，这个方法可以直接被测试组织所利用。如果测试组织被越多黑盒、工作流所驱动，主要的用例文档就越能有效地在估计中运用。因此，有了 UCPM 用户的验证或者系统的整合，团队就能够生成更精确的比其它测试阶段更早的评估。由于任何估计工具或者方法都会依赖于输入的准确度，历史的估计数据，当它们逐渐变得可利用时，将在这些评估技术中提供更高的信任度。

覆盖有效性

用例实现打开了一扇通往更精细更有潜在可能性的有效优先权测试方法的门。例如，ranTest initiative for Software Engineering 2006 利用加权特殊标准的用例。ranTest 技术针对发布版本完全使用了用例，并静态地对它们进行优先权排序。然后测试组织就按照那个顺序来执行测试用例。预算或者时间表如果没有覆盖整个测试单元，那个就会省略一些关键的用例。 此外，这个技术还支持动态的优先排序。当在基于静态的优先级团队执行识别的测试时，风险区域也会被识别。这样，测试用例优先权的第二层也被创建，它重点是证明最关键的功能是与最高可靠性并存的。最终的产品是一种有效的测试方法，提供了确保解决方案能够满足消费者目标需求具体水平的有效测试方法。

·【技术专题】SQL Server 2008数据挖掘指南

·LoadRunner创建测试脚本

无论是利用一种已经建立好方法，还是创建一种“的”方法来达到最少复制更完整覆盖的目的，利用基于用例的方法比用行式项目需求方法有更大的优势。

尽管这个过程需要进一步的技术分析，但是这些用例能够为可靠的测试要求的输入到其它工作产品中而被分解。从这一点看，这些相关的或者黑盒情景已经被转换成白盒工具。分析设计建模输出与驱动它的用例直接相连接。此外，用例驱户体验建模，为确保用户界面在整个解决方案过程中的一致性设置了相应的阶段。在面向对象的编程用例中，这些模型清楚地展示了连接到用例地类和方法。低层次文档中任何变更的影响都能够连接到返回到任何高层次用例。

用例对测试组织的利益

可追溯性

最简单的处理测试用例优先权的方法是关键径的识别。关键径是为了解决方案对最终的用户有价值而使面向用户的功能按照一定的顺序进行操作的需求。关键径在回归测试和其它有严格时间控制的测试中十分有用。然而识别关键径，尤其是对于有许多需求的大量，可以说是一项令人的任务。证明用例（尤其是用例图）十分有利是另一个区域的讨论范围。由于用例图开始识别正面的，或者“令人愉快的”，径，然后分支显示可选的流程和例外条件，它们提供了一种识别整个应用软件中大多数直接径的方法。这个技术还提供了允许快速决策的信息，这些信息是关于哪些可选流程和例外最重要的。

用例能够促进开发测试组织所依赖的更高质量的输入和代码。由于用例开始具体化，这些用户或者参与者的需求也按照目的进行讨论。这个过程开发者将重点集中在所使用的开发模式外部的功能需求之上。这个方法将开发人员拉进用户的思维过程中 (比如，他们的目标)，开发人员就能看到这种下的需求。这个过程将促使开发人员更彻底地了解这个系统将希望做什么，因此，能够向测试人员交付一个构建良好的解决方案。

没有用例，开发满足特定阶段目标的唯一测试用例的问题将变成一个复杂而且模棱两可的运作，因为不同的测试团队会从相同的源文件中生成测试。这样会导致多余的或者不合适的测试和覆盖区域。有了用例驱动开发，每个测试水平使用工件的不同分组，从而有助于使测试保持在这个阶段适当的范围内。由于用例是根据用户目标来表达的，所以需要为执行所创建的额外的工件是方案更加完整。例如，当创建用例和支持性工件时，一个单元测试人员可以恢复合适的类来验证。对于功能测试人员，用例与支持性工件一起创建这个功能目的和有效测试输入的完整画面。他们能够访问通过查看设计信息支持的特殊值。系统集成测试阶段回到主要用例，识别整个用例中交替可变径的合适编码。最后，用户验收测试团队可以执行有效的直接回应解决方案问题的测试用例。

测试人员可能会通过考虑用户社区中功能的临界性来对测试优先性进行排序。用例通过允许发起者清楚地识别结果来支持这种方法，然后可以直接功能一直到这些结果。这样明显优于通过传统地分解行式项目需求的方法，传统的方法好像失去了焦点或者性，因为它需要的是一种多个步骤且并不直接的过程。

用例在测试估计领域提供了令人兴奋的机会。John Smith详细说明了利用 Constructive Cost Model (COCOMO) 将一个用例为源代码行(SLOC) 的详细过程，反之，利用这个信息开发 Rough Order of Magnitude (ROM) 的估计。这种方法的成功是假定那个低层次工作产品，比如构架和数据设计，先前已经生成了。

用例可以很大程度地提高一个测试人员的能力，从而调解开发缺陷清单。从请求者，到执行者，到验证者是一条线。Booch et al. 的总结：在这个解决方案整个交付过程中没有沟通需求的已经制定好的标准。关键的应用软件对于一个单一的需求如何连接到每个工件的通信相关性要求有更严格的方法。然而，即使一个典型的非关键系统也应该要求相关性关系有简单的识别。这个将消费者需求转换成用例的基本过程在测试交付结果中提供了可性。当用例驱动方案测试时，您应该知道为什么要测试以及测试什么，为这个方案能够满足消费者期望提供信任度。

开发输入

·【热点专题】08年最受欢迎的图书

·使用LoadRunner 编写JAVA 测试脚本