| UML软件工程组织 | |||
| |
|||
|
|||
探究用例以改善测试质量
2008-03-28 作者:Debra Sheldon,Sylvia Lenters 来源: IBM
理解测试和质量保证组织是如何通过使用用例技术来提高测试质量的。 测试组织通过利用用例的优势可以实现测试质量的重要利益。几年来，开发人员和业务分析人员一直利用用例模式来捕获需求。测试组织能够通过利用这些相同的用例技术获得巨大的利益。构建良好的用例能够以有效率的，易于跟踪的，以及评估准确性的方式为测试任务提供价值。它们还可以转移部分全球部署虚拟团队的风险。但是从数量上来看，最大的利益则在测试用例的生成中。 对于识别和创建单元、功能、系统集成，以及用户验收测试来说，用例和相应的支持工件是价值无法估量的驱动。每个测试水平都有唯一的不同输入设置的目标和需求来达到可靠的测试覆盖率，但是所有的测试水平都能够从这个项目的用例中获取一定的价值。通过执行用例方法、工作空间，以及评审，测试组织能够交付定义良好的测试，同时能够获得更高的准确性和更高的效率。 在测试中使用用例的论点用例多年来一直是软件开发人员的一种工具。一个用例清楚地描述了一个被指定的用户是如何执行一个指定的过程，从而向用户交付指定的结果的。正确地指定用例能够提供一个直接的连接，来帮助用户和开发人员开发一个系统用户需求的共同理解。它们是一个被证明有效的软件开发工具。 测试组织还应该充分利用用例提供的利益。测试人员是通过将用例转换为效率高的，有效的，阶段性适合的测试，从而充分利用用例执行带来利益的唯一受益者。测试人员重新利用这些用例，对于用户和开发组织不需要额外的工作或者支出，为测试估计和测试用例的生成提供一个完备和一致的基础，将生成比预期更好的质量测试解决方案。 测试人员能够实现所有的这些利益，因为用例和相应的支持工件提供了根源和驱动，从而为测试人员在几个有疑问的区域创建了牢固的基础。因为用例早就已经交付，并且它们能被项目上所有资源所理解，测试团队在这个项目中能够比用行项目需求收集方法更早地执行更加准确的测试估计工作。此外，用例驱动了更清楚的沟通，加强了这些用户需求开发的理解。它们的简单性改善了全球地域分布的风险，和虚拟解决方案交付团队。用例还提供了简化需求跟踪的机会，从而确保更完整的测试覆盖率。 测试团队能够利用新的用例，为增强覆盖率和有效性改善技术，同时获得更精确的范围定义和测试优先权。这些综合的利益最终导致更有效，更严格的测试过程和更有预见性的测试结果。 由于用例提供了许多利益，测试组织应该积极主动地确保每个用例都能够被正确地构建。如果需要的话，这个项目团队应该能够管理一个或者几个用例的工作空间，包括在所有的测试阶段雇用测试编写人员。每个用例必须经历静态的测试来确保它包含清晰而且有利的信息，根据这些信息测试人员可以为指定的测试阶段构建适当的测试用例。通过重新使用构建良好的用例和支持性工件，测试组织就能拥有目标明确的、有效的测试。 什么是用例？自从20世纪八十年代中期，当这个概念第一次由 Ivar Jacobson 描述后就生成了用例。 1 Jacobson 是一位早期基于组件设计概念的先锋者之一。他还是统一建模语言(UML) 和 IBM®Rational® Unified Process®，或者 RUP®的主要创始人。他最感兴趣的是软件开发最佳实践引导他开发用例概念，从而更好地识别和描述软件需求。 尽管这些用例的概念自从二十多年前就已经生成，实际上许多软件从业者从没使用过它们或者甚至从来没有了解过他们。业务转型方法论越来越普遍，这很大程度上取决于过程规则，其实正在改变这个状况。普遍的工具比如 IBM Rational RequisitePro®(用来支持 RUP) 结合用例的生成作为需求定义过程的一部分。UML 的引入为软件描述设定了标准，已经进一步促进了用例的采用。 用例主要强调涉众需要这个系统交付什么，而不是描述如何实现最终的结果。用例采用“黑盒”接近这个系统。 2 它应该陈述将要发生什么行为，但是并不陷入关于行为如何被实现的具体细节中。将一个用例看作是来自参与者观点导向的结果。只要结果被实现，这个参与者实际上并不真正在意这个行为是怎样执行的。因此，一个用例必须代表支持对参与者有重要价值的结果。 UML 将一个用例定义为“一个系统执行的一系列行为的描述，包括变量，它将生成特殊参与者所得值的可观测结果。” 3 当决定一个用例的构成时，这个“价值”的概念十分重要。如果您不想识别这个将由参与者识别的具体值，那么这个行为可能对一个用例来说就不是一个很好的候选。 4 一个用例可以是图形的，也可以是文本的，但理论上两者都是用例。 5 用例可以创建为只读文本的格式，但是最初都储存在像 Microsoft Word 这样的工具中。长期以来，在用例图中以图形的格式表示就变得越来越普遍。使用 UML 和支持 RUP 的工具来构建用例模型是最为常见的方法。这样的工具支持文本描述和支持图的多样性，从而更好地图解化此系统是如何被使用的。 用例图经常被分组来显示涉众们的需求集合（请看图 1中的例子）。在这个图中，任何一个直接与系统联系的单位通常都被看作是一个“参与者”。一个参与者可以是一个人或者代表一个或者多个人的角色。它还可以是另一个计算机系统。一个参与者通常由一个“人性图标”代表，即使当这个参与者是另一个计算机系统时也是这样。每个用例都由一个椭圆形代表，用描述这个用例将要执行什么样的行为的说明型陈述进行标注。这个陈述作为这个用例的名称。它应该简洁，但是描述的行为应该被执行。还可以绘制沟通连线来显示参与者与用例之间的关系。  图 1：用例图 用例可以由用例描述来支持，包括关键属性，比如先决条件，和一系列的事件。一个用例模型由这个用例的图，参与者定义构成，也可能包括这个用例的描述。 6 一个团队开发用例最初目的是，识别用户涉众们想要从这个系统中获取的所有的核心功能。一旦他们确定了这些功能，这个团队就可以开始展开每个关键功能相关的细节，他们也开始关注可能与每个被识别的用例相关的可选过程流程及例外条件。 在用例的开发过程中，通常假设这个核心功能将有一个正面的或者成功的结果。这通常被看作是“基本路径”或者“快乐路径”。例如，如果使用“搜索一个产品”，这个正面的结果将是被搜寻产品的结果。大量的可选择流程，包括例外情况和错误，也可能存在。比如，如果这个产品没有找到该怎么办呢？或者，这个产品目录所在的系统没有反映该怎么办呢？或者，一个消费者在这个搜索区域中键入了无效的信息该怎么办呢？这些还是有效的路径，应该在文档中可以获取。 用例文档细节的层次和类型在不同的组织或者公司中有很大的区别，甚至从一个项目到同一个组织中的另一个项目也有很大的差别。这些差别可能会受到许多不同因素的影响，包括这个项目的预算或者范围 (尤其当这个解决方案本质上是面向对象时)，可利用资源的技术组合，UML 的使用，以及 RUP 或者其它方法的使用。 正如上面所提到的，用例可能完全是不带支持的基于文本的图，或者它们可能仅仅使用简单的用例图来描述，如图 1所示。根据对象管理组织， UML 2.0 有十三种不同类型的图。 7 这些图被分成了三个类别：结构图，行为图，以及交互图。结构图，比如类图，代表静态应用软件的构架。行为图，比如用例和活动图，代表普通类型的行为。交互图，比如一系列的图，代表交互作用的不同方面。除了团队可以生成的各种图外，团队还可以创建其它支持型工件，比如一个词汇表或者特设需求文档（例如，一个非功能型的需求）。 8 一个项目用例的开发通常被看作是促进需求收集过程的一种方法，从而加速应用软件的开发。大多数出版物看起来似乎主要强调的用例的这些方面。而大多数软件测试出版物并不会参考用例，实际上这些用例在许多区域的驱动改善方面，对测试组织具有极其重要的价值。 用例对测试组织的利益正如我们在下面部分将要显示的，用例为改善测试质量和效力提供了引人注目的利益。用例在测试估计领域提供了令人兴奋的机会。John Smith 9 详细说明了利用 Constructive Cost Model (COCOMO) 将一个用例转化为源代码行(SLOC) 的详细过程，反之，利用这个信息开发 Rough Order of Magnitude (ROM) 的估计。 10 这种方法的成功是假定那个低层次工作产品，比如构架和数据设计，先前已经生成了。 11 另一个估计技术，用例功能点(UCFP) 评估，是功能点计算方法的改编。它与 COCOMO 方法有相同的风险。由于支持评估的这两种比较旧的方法基础存在一定的缺陷，想连接细节层次与分解之间的鸿沟，被认为是很难有效地被克服。然而，由于 ROM 估计有被锁定的趋势，并在项目早期考虑到了后果，因此任何提供可靠信息的并且与测试估计相关的工具，在此过程早期仍然有一定的价值。 这个用例点方法(UCPM) 似乎为有效测试估计提供了最高的潜能。这种方法的开发是建立在更新的设计方法基础上的，而不是被更新来处理用例的使用的。1992年 Gustov Karner 介绍过，这个评估是由用例的元素驱动的。 12 通过一些修改，这个方法可以直接被测试组织所利用。 13 如果测试组织被越多黑盒、工作流所驱动，主要的用例文档就越能有效地在估计中运用。因此，有了 UCPM 用户的验证或者系统的整合，团队就能够生成更精确的比其它测试阶段更早的评估。由于任何估计工具或者方法都会依赖于输入的准确度，历史的估计数据，当它们逐渐变得可利用时，将在这些评估技术中提供更高的信任度。 用例能够促进开发测试组织所依赖的更高质量的输入和代码。由于用例开始具体化，这些用户或者参与者的需求也按照目的进行讨论。这个过程迫使开发者将重点集中在所使用的开发模式外部的功能需求之上。 14 这个方法将开发人员拉进用户的思维过程中 (比如，他们的目标)，开发人员就能看到这种环境下的需求。这个过程将促使开发人员更彻底地了解这个系统将希望做什么，因此，能够向测试人员交付一个构建良好的解决方案。 尽管这个过程需要进一步的技术分析，但是这些用例能够为可靠的测试要求的输入到其它工作产品中而被分解。从这一点看，这些相关的或者黑盒情景已经被转换成白盒工具。 15 分析设计建模输出与驱动它的用例直接相连接。此外，用例驱动用户体验建模，为确保用户界面在整个解决方案过程中的一致性设置了相应的阶段。在面向对象的编程用例中，这些模型清楚地展示了连接到用例地类和方法。低层次文档中任何变更的影响都能够连接到返回到任何高层次用例。 16 在一个解决方案所有质量因素中最关键的是跟踪开发和交付过程所有阶段的需求能力。IEEE 引用从一个工件到另一个工件的连接元素，并用这种定义作为这个练习中单纯证明。 17 用例能够定义前任继承者关系，并为驱动因素示例特征。 然而，对于可追溯性最纯粹的经济变量是，它提供证明来执行一个具体的测试。大家都知道每个测试用例都可以被追溯，最终到一个业务需求，测试计划者可以确保测试是由当前财政所负担的，而不是其它机构所负责。相反，这个方案的发起者就能够直接识别这个方案正向他们提供业务价值的证据。 用例可以很大程度地提高一个测试人员的能力，从而调解开发缺陷清单。从请求者，到执行者，到验证者是一条线路。Booch et al. 的总结：在这个解决方案整个交付过程中没有沟通需求跟踪的已经制定好的标准。 18 关键的应用软件对于一个单一的需求如何连接到每个工件的通信相关性要求有更严格的方法。 19 然而，即使一个典型的非关键系统也应该要求相关性关系有简单的识别。这个将消费者需求转换成用例的基本过程在测试交付结果中提供了可跟踪性。当用例驱动方案测试时，您应该知道为什么要测试以及测试什么，为这个方案能够满足消费者期望提供信任度。 没有用例，开发满足特定阶段目标的唯一测试用例的问题将变成一个复杂而且模棱两可的运作，因为不同的测试团队会从相同的源文件中生成测试。这样会导致多余的或者不合适的测试和覆盖区域。有了用例驱动开发，每个测试水平使用工件的不同分组，从而有助于使测试保持在这个阶段适当的范围内。由于用例是根据用户目标来表达的，所以需要为执行所创建的额外的工件是方案更加完整。例如，当创建用例和支持性工件时，一个单元测试人员可以恢复合适的类来验证。对于功能测试人员，用例与支持性工件一起创建这个功能目的和有效测试输入的完整画面。他们能够访问通过查看设计信息支持的特殊值。系统集成测试阶段回到主要用例，识别整个用例中交替可变路径的合适编码。最后，用户验收测试团队可以执行有效的直接回应解决方案问题的测试用例。 当利用这些用例模式时，测试人员可用更有效地设计和执行测试。用例模式允许测试人员从视觉上识别他们地测试用例，尤其是当这个过程包括一个用例图时。 有时它会被引用作为不同的分支、路径，或者变异性识别，在测试设计者识别各种方法的所有用例中，用户或者外部的系统都可以执行这个用例。在这个过程的这一点上，用例为识别有效测试，清除多余路径，以及在不用猜想的情况下设计黑盒测试提供了一个方法作为覆盖范围。通过识别整个用例的所有可变路径，测试人员能够指出在哪些地方路径覆盖了其它情景。覆盖的或者多余的路径是从计划测试用例执行库中清除的候选者。Clay Williams 通过研究行为和序列确定了一种优化测试用例生成的方法。 20 当清除多余区域时，叫作“Method and System for Generating an Optimized Suite of Test Cases”的用一种算法可以使覆盖区域达到最少的测试用例。 无论是利用一种已经建立好方法，还是创建一种“民众的”方法来达到最少复制更完整覆盖的目的，利用基于用例的方法比用行式项目需求方法有更大的优势。 将要执行的测试用例进行排序是测试组织十分关键的一种管理工具。有好几种确定优先级的方法，要选择合适方法，对于不同的项目、团队和开发方法有不同的方法。不管测试优先级是如何操作的，用例都会提供一个比旧的需求方法更精简的过程。 测试人员可能会通过考虑用户社区中功能的临界性来对测试优先性进行排序。用例通过允许发起者清楚地识别结果来支持这种方法，然后可以直接跟踪功能一直到这些结果。这样明显优于通过传统地分解行式项目需求的方法，传统的方法好像失去了焦点或者跟踪性，因为它需要的是一种多个步骤且并不直接的过程。 在传统的过程中，测试人员被迫将附有高水平用户结果的技术与需求团队连接起来。用这种方法决定测试优先权浪费时间而且容易出错，因为它需要将用户的心里印象和/或者多个测试用例的重组逆转回到发起者开始想要表达的的基于情景的目标。利用用例，这些容易出错的行为几乎不存在。因为它们直接映射到测试下功能想要的结果中， 测试可以很容易地被按照发起者先前建立的关键需求的顺序来排序。每个测试有了目标以后更容易被识别，优先级最难的点变成了使业务发起者按照重要程度处理新的或者变更的功能的排序问题。 最简单的处理测试用例优先权的方法是关键路径的识别。关键路径是为了解决方案对最终的用户有价值而使面向用户的功能按照一定的顺序进行操作的需求。关键路径在回归测试和其它有严格时间控制的测试中十分有用。然而识别关键路径，尤其是对于有许多需求的大量释放，可以说是一项令人敬畏的任务。证明用例（尤其是用例图）十分有利是另一个区域的讨论范围。由于用例图开始识别正面的，或者“令人愉快的”，路径，然后分支显示可选的流程和例外条件，它们提供了一种识别整个应用软件中大多数直接路径的方法。这个技术还提供了允许快速决策的信息，这些信息是关于哪些可选流程和例外最重要的。 用例实现打开了一扇通往更精细更有潜在可能性的有效优先权测试方法的门。例如，ranTest initiative for Software Engineering 2006 利用加权特殊标准的用例。 21 ranTest 技术针对发布版本完全使用了用例，并静态地对它们进行优先权排序。然后测试组织就按照那个顺序来执行测试用例。预算或者时间表如果没有覆盖整个测试单元，那个就会省略一些关键的用例。 此外，这个技术还支持动态的优先排序。当在基于静态的优先级团队执行识别的测试时，风险区域也会被识别。这样，测试用例优先权的第二层也被创建，它重点是证明最关键的功能是与最高可靠性并存的。最终的产品是一种有效的测试方法，提供了确保解决方案能够满足消费者目标需求具体水平的有效测试方法。 用例还提高了缺陷优先处理的精确度。当一个测试失败了，基于用例的方法可以迅速确定问题的分类和优先权，因为这个用例的整体重要性已经被建立。测试人员可以直接依赖发起者在制定需求规范时赋予这个具体用例的值，而不是对缺陷进行主观地评估。缺陷优先排序几乎变成瞬间而且无可争议了。而且，在缺陷发现和它的优先权确定的时间也大大减少了。 在一个特定的市场，业务往来发生在文化和法律框架之中。法定的市场行为证明，最接近的文化之外的最佳成功机会是在类似的文化或者文化体系中。 22 这个行为与当前从全球外包开发和测试的软件交付模式是相冲突的，并经常导致用户和开发者之间的误解。这种继续向更复杂和过程驱动解决方案移动的行为将增加用户和开发者之间“断开”的风险。这些条件联合起来使保证这个方案能适合目标市场的风险变得更加复杂。 正如 Bittner 和 Spence 指出那样，“用例通过让我们从视觉上明白这个系统将要做什么以及如何利用它来进行操作。” 23 通过使用用例，全球的测试资源挽回一些在跨越文化边境的过程中可能丢失的文化。它们对业务目标有更充分的认识，从而促进应用软件将要被投放的具体市场的需求。 用例使用户在需求过程中操作，并允许他们与测试人员进行清楚地沟通，了解这个方案是否准确地针对目标市场。 24 这种理解与传统表达需求的方式在不同的个体之间有很大的差别。因为反映具体结果的用例早就被交付，一个全球测试团队有足够的时间来开拓对这个用户目标良好的理解。前面额外的时间允许测试人员来验证他们对实现和想要的结果的理解。当出现这样的挑战因素时，如不能可视化地与需求所有者沟通， 25 不同的时间区域，以及产品将要服务的市场确保功能和性能的挑战，所测试的内容和所交付的内容以及业务真正所需要的时间空缺将十分引人注目。当利用全球性资源团队来交付方案时，用例会提供降低这种需求到实现“转换”风险的动力。 创建测试用例用例实现对测试组织最大的影响是在测试用例的创建过程中。用例创建直接输入到一些高水平测试中去。对于验收测试，当被适当地执行时，用例缩小了测试人员 概念化和用户目标现实之间的距离。尽管最初可交付成果对于单元测试人员是临界值，但是缺乏细节迫使这个方案交付团队随后创建包含低水平测试所必须的输入的支持性工件，比如单元测试。实际上，每个测试阶段都有权输入此阶段或者其它阶段明晰目标所需的合适且完整的信息。此外，由于他们特殊的本质，这些输入十分清晰，而且这些信息很容易就可以转化成适当的测试阶段的测试用例。测试人员不会因为为他们特定的测试阶段而在整个较大的，包括所有类型的文件中搜寻而心烦意乱。这些结果是拥有更好的代码和更好目标的测试。 一般来说，从一个用例驱动方法来创建测试用例包括以下四个基本步骤：
并不是所有的测试水平都以相同的方式来达到以上的步骤的。下面的部分描述了怎样为用例模型驱动的项目的测试阶段创建合适的测试用例 因为用例包括参与者真实语言的目标信息，用户验收的测试用例可以在为其它测试阶段创建测试之前编写。用例是从用户的角度来定义的，而不是系统的内部活动，因此验收测试可以直接从用例中创建。 26 此外，用例非常适合于用户验收测试，因为需要验收测试用例来模拟最初从系统涉众中抽取的情景。 27 就像 Lee Copeland 指出的，用例最适合端到端的黑盒测试——更准确地说，是在用户验收测试被执行的条件下。 28 验收测试的测试用例的生成在不同的测试阶段是不同的，这是由于这个和其它测试水平潜在的前提之间存在一些明显偏差所导致的。验收测试存在于生命周期的这样一个点上，技术测试团队已经得出此应用软件已经完整且准备交付给消费者了。单个的测试用例是由用例驱动的，而不是附加的，非功能性需求规格。测试用例是上游测试的不同子集。另一个区别是验收团队是通过将最终的结果看作方案完整性来达到获取测试结果的。最后，这个测试人员很像一个“非技术的”普通涉众，并不期望了解潜在的构架，但是要十分熟悉测试中转换描述的目的。 由于用例是透明且独立于系统，所以对于测试阶段，他们将丢失一些关键的细节信息。用户验收测试用例编写者并不希望用例中有具体的数据。然而，当 Copeland 清楚地被识别时，处理测试，一个验收测试之下的类别失败了，很显然它是依靠数据的。 29 Boris Beizer 支持数据的临界性，规定其生成、捕获，以及用百分之三十到四十的工作来提取数据帐户。 30 这样引导出这样的问题：验收测试到底需要多少具体的数据和脚本。我们的立场是，附有具体数据输入的具体脚本和违反直觉运行用户验收测试总体目标的用户界面步骤是测试用例脚本不需要的。Cem Kaner 和 James Bach 宣称“如果一个脚本的工作是可重复性的，我们可以将这些工作委托给廉价的劳动力。” 31 有了由超级用户，顶级装备或者其它主要领域专家组成的验收团队，用户验收测试用例将不需要低水平用户界面或者类细节。根据这个用例的目标，在测试用例的前置条件或者设置中还需要一些数据输入。 要开始创建测试用例，用户验收测试资源将需要查看这个用例的流程图。在图 2中，这个基本流程，或者快乐路径，径直穿过这个图。这个可选的流程将被取消。这些代表了额外的测试用例。 
图 2：用例的流程图 当从一个带有少量路径的用例开始工作时，您可以合情合理地期望用户验收测试执行所有地路径。对于包含许多可选情景和变量，或者对于那些连接到其它用例的用例来说，为每一个路径进行测试几乎是不可能的。尤其是对非关键的应用软件，这样的路径就好像不被业务用例所支持。 32 此外，这些路径中很多可能是多余的或者甚至是无效的。 McGregor 和 Major 提供了一种对测试用例筛选可管理的方法，这对用户验收测试社区有格外的吸引力。 33 作者描绘了不用种类的用户，创建了可操作的配置文件。一般采取操作剖面图来筛选路径的方法实际上是优化验收水平测试最好的方法。为了使适合那些操作剖面图的用户执行，测试用例的合成子集将向发起者提供这样的保证：所有的用户社区都可以利用这种方案来达到定期的目标。同时，操作剖面图是一种优化或者减少测试筛选的工具。根据这个测试阶段的目标来看，循环和例外的路径并不是需要的覆盖范围，除非这样的路径通常是由用户社区中一些人执行的。 系统集成测试阶段验证一个类似生产环境中所有应用软件(包括组织内部和外部的界面)以及它们的硬件、软件，以及组成组件的集成。 这种将用例转变成测试用例的方法与系统集成测试对用户验收测试的方法十分相似；不同的是系统集成测试比用户验收测试在范围上更广更深。由于用户验收测试团队可能主要关心的是快乐路径以及可能是为特定用例定义的一个或者两个可选择路径，如图 3所示，系统集成测试团队将很可能需要执行这个快乐路径以及大多数可选路径和例外路径(尤其是那些与错误条件有关联的路径).  图 3：系统集成测试的例外路径 正如上面所讨论的，对于有许多路径的较大的而且比较复杂的过程来说，测试人员可能需要仔细分析，确保能够测试关键的路径功能以及这种测试效率能够维持下去。 系统集成测试要求有获得一个比验收测试所得的更详细的系统视图。除了在较低水平仔细验证这个体统的功能方面的情况之外，系统集成测试还完成了非功能性的测试。此外，这个系统集成测试团队比验收团队更关注数据测试，尤其是在关于数据已被传递或者从其它系统接受方面。因此，用户验收测试团队实际上是可以使用例对测试用例成为一对一的比率，对于系统集成测试用例对测试用例的比率也可以是以对多。 要充分并有效地测试这些区域，系统集成测试团队需要的不仅仅是用例。系统集成从一些更详细的 UML 图，比如活动或者流量图中获得利益。Dean Leffingwell 和 Don Widrig 将活动图定义为一种“合理熟悉程度的优势。” 34 这些流程图甚至连非技术资源也可以容易地读懂，它们主要识别业务过程和规则。它们允许这个场景有一个视觉参考。另一个工件，一系列的图，提供了关于目标之间按顺序发生的相互交互的信息。 35 这些图，有文本描述的补充说明，应该为系统集成测试提供足够的信息，从而可以是这个项目在其生命周期的早期开始构建功能的类型。利用变量表格和数据表格或者文档的决策树可以完成这些测试用例。 有些组织可能不支持 UML 或者不使用任何类型的标准用例建模工具。如果这些用例仅仅是基于文本的，它们对为测试和生成测试用例而计划的系统集成测试 团队来说仍然有十分重要的价值，但是系统集成测试团队需要参与到用例的工作空间，从而确保这些用例被压低到足够的水平来支持他们的测试需求。然而，在这种情景下，这个团队很可能依靠于那些直到在项目生命周期的晚期才生成的外部设计文档。 所有的用例方法，正式的或者非正式的，都需要附加文档来完成测试用例的创建过程。系统集成测试人员能够通过提取与非功能集成测试用例相关的信息来完成测试用例的程序库。测试用例的安全性、性能、可用性、转化，等等都是由这些类型的文档所驱动的。一般情况下，只有等到用例良好地创建完成之后，这些文档才可以利用。设定这些文档类型交付的时间风险是环境获得的潜在延迟，具体的细节在这篇文章有详细描述。测试组织应该通过计划来减轻这种独立的风险。 尽快掌握生成大多数测试用例和脚本的能力对系统集成测试团队来说有很多好处。对利用 UML 使用用例建模工具也是一个很好的理由。 早期测试用例开发允许测试团队有足够的时间来处理同等的检验并保持涉众的评论。事实上，团队甚至有充分的时间来进行迭代检验，这样他们可以完善这些 测试用例，从而满足技术上和用户的需求。 在功能验证测试阶段中，不明显的功能块也会被仔细地验证。功能验证测试通常被认为是针对详细需求以及外部和内部设计 文档的功能组成的测试。内部和外部的界面可能是利用残断的数据输入和截留的数据输出来测试的。 不像系统集成测试，它更多关注的是应用软件影响其它软件和系统的能力，功能验证测试则分步对它本身的应用软件进行检测，包括测试单个组分和过程，界限和极限，以及其它外部技术细节。对于功能验证测试，用例与测试用例的比率将是一对多。功能测试团队将对组成基奔流，可选流，以及例外流的组分感兴趣，而且这些流稍后将由系统集成和用户验收测试团队进行测试。 为了在这个粒度达到最佳的结果，功能验证测试团队可以从一些更详细的 UML 图中获取利益，比如类和序列图。Copeland 将一个类图定义为“描述构成系统以及它们之间静态关系的类。类是按照它们的名称、属性（或者数据），以及行为（或者方法）来定义的。” 36 序列图提供了目标之间按照序列顺序生成交互的信息。每个交互都将生成一些想要的结果。 37 这些图的类型，有文本描述的补充说明，应该为功能验证测试团队在这个项目周期中工件测试用例提供充分的信息。 图 4 显示了一个来自 IBM DeveloperWorks 的 Rational UML 序列图，描述了进入和出来的消息（交互）。  图4： 一个来自 IBM DeveloperWorks 的 Rational UML 序列图，表述了进入和出去的消息 如果一个项目在类和序列图中不使用 UML 或者不继续使用用例文档到一定的程度，Function 测试人员就要一直等到构建测试用例所需的具体的外部和内部设计文档完成之后。另外，用例还不覆盖非功能需求，这对功能验证测试阶段来说是非常普通的。 我们最后讨论单元测试，是因为这个水平的测试的输入需要以后的文档由这个项目团队创建。单元测试是模块中新代码和变更代码最初进行的测试。大多数这种类型的测试利用白盒测试方法。这是软件测试的最低水平，也是动态测试中寻找软件缺陷的第一道防线。在这个阶段，缺陷可以很容易且经济地被识别和修正。只有一少部分地实际用例被直接输入道单元测试用例中。单元测试的量取决于以这些用例为基础的低水平工件。 由于用例可以通过黑盒访问这个系统，所以它们成为单元测试人员的关键性驱动。然而，它们可以在单元测试人员利用局部的黑盒方法执行测试时提供有意义的价值。用例可以为用户如何期望系统工作提供深刻的见解；而且，如果有完备的文件，他们不但识别这个应用软件的基奔流，还会将可选流，可能的分支流与可选流，例外或者错误流相联系起来。黑盒测试依赖于这个测试，因为这个测试了解系统所输出的将成为一个特定系统输入。这些在用例中被识别的过程流信息对进行单元测试的开发人员有很大的帮助，因为它让他们很容易就能理解用户期望信息如何被输入这个系统，以及他们所希望的输出是基于特殊的输入的。 如果这个项目组织利用 UML 来建模，那么单元测试将需要序列图，类图，可能还会需要活动图。类图交付单元测试所需的构架信息。序列图，在功能验证中有很重要的价值，提供交互的信息。他们显示了“参与者在做什么，他正与那些部分发生交互，以及有哪些参数正被通过，” 38 以及他们对测试人员开发单元测试用例有特别重要的作用。因此，这个负责单元测试的开发团队应该确保这个类和序列图包含在项目交付产品中。 单元测试人员访问实际用例之外的，与被分解的信息相沟通的工件是十分重要的。这个水平的信息能够创建可靠的单元测试用例和覆盖范围。如果这个组织不使用 UML，这个开发团队将很可能要等到具体的设计文档被创建以后，而且这个文档是在他们需要这些信息创建测试用例之前创建的。 弥补测试覆盖的空缺用例驱动测试过程，但是它们不直接处理各种类型的测试用例。非功能性需求并不包含在用例中，主要是因为方法、指导方针，可能是由一个有效的驱动触发的。但是，实际上，为这样的属性创建一个外部列表，或者行式项目需求，远比创建一个用例要有效得多。照这样说，这个覆盖空缺增加了这样一个缺陷进入未被发觉的产品中的可能性。 当为下面的测试步骤构建测试用例时，测试人员需要从其它工件中拉取：
这种接触没有干涉单元或者验收测试目标。单元水平测试人员是由最低水平文档驱动的。验收测试则由用例的最高形式触发的。而且没有从发现非功能性相关缺陷中直接排除测试人员。我们甚至找到一个这个限制是优先权形式的理由，因为当在类似产品环境中执行时，这些限制条件下发现的非功能性缺陷似乎影响了更多的终端用户。 要为非功能性需求的构建测试用例，测试人员要依赖于附加的文档，因此也称作需求补充说明。 39 Bittner 和 Spence 曾经写到，可以将具体的需求（并不运用到整个系统的需求）置于一个用例中，这样对高水平测试用例的编者来说也更容易接近。 40 但是一般说来，这种类型的信息，以及这样有关联的测试用例，开发过程中信息的生成应该晚于由那些测试用例驱动的生成的。 确认用例从用例中生成测试用例过程的局面将会停止。在这种情形下，识别驱动因素是十分重要的。常见的驱动有：
上面的大多数情况都可以通过在循环早期提前操作而避免。因为它们有太多处于危险状态，测试组织必须安置来影响用例的质量构建。正如 Leffingwell 和 Widrig 指出的那样，“用例技术构建了一套可以直接驱动测试过程的资产。” 41 但是在测试开发时期修正一个薄弱且错误的用例十分困难而且成本很高，尤其是当使用一个基于瀑式开发方法的时候。这样，我们建议一种双交叉的方法来确保这个用例对测试人员来说还具有功能上的价值。首先，包含在用例创建中的一个测试代表应该使团队远离用例编写的常见陷阱。其次，团队应该始终执行用例的静态测试。 首先要避免的陷阱是功能分解，一个源自行为多样化的问题。分解抽象化的形式是将用例分解成更小的部分。 42 在这个用例中，当低水平信息被一个用户或者系统代替时就会发生这样的情况。发生的方式之一是将数据流图和用例图混淆在一起。 43 从根本上说，用例编写者会根据设计而不是功能来查看这些目标。结果是用例不能独立存在来创建可测试的场景。 一个相关的陷阱是在这个用例中将需求和设计混淆在一起。在这种情况下，用例可以用来创建可测试场景，但是隐藏信息所包含的内容 44 与维持测试用例穿越任何设计变更的能力相冲突。 太多或者太少的信息是另一种常见的陷阱，但是在决策方面它包含的艺术多于科学。如果没有足够的信息，对测试人员来说创建一个坚固的测试用例组合是十分困难的。如果信息太多，又会使识别测试路径和优先化测试的过程变得很困难。一开始就了解正确的平横关系，需要拥有用例以及个人在项目中的历史支持组合方面的经验。 要避免的一个单纯的陷阱是，用团队的失败来加强设计原理、方法，以及过程。 45 这包含编写风格以及内容。尽管这是一个广泛的话题，有一致的过程跨越这个项目团队的功能区域，测试团队可以很容易地避免这个陷阱。 尽管有一个有经验且受过良好训练的团队，但是仍然有风险，用例可能有缺陷，从而影响最终创建一个功能强大的测试用例的能力。第二个确保用例是一个测试所需的可靠的而有用的输入的机会是，对测试用例进行静态测试。团队甚至可以将用例的静态测试作为一个闸门机制。当静态测试被看作是为了这个活动的成功实现，其项目计划依存关系中的一个被识别的风险时，测试人员就要保证这些用例对于他们的交付结果是可靠的输入。用例的静态测试可以由检查表驱动，安全的各种水平也应该包含测试人员。 有很多静态测试项目用例的方法。对无领域专家尤其有用，Copeland 建议将用例分解成三个部分：语法、领域专家测试，以及可追溯性。 46 用这种方法，每个用例都要测试。NASA 建议只对精选的用例进行分析。 47 分析诸如边界、元素命名，以及被执行的发起。Alistair Cockburn 推荐了一个问题列表来考虑何时读取用例。 48 这些问题对识别缺口很有帮助，但是遗漏其它颗粒元素没有被公开，它们可能阻碍成功地使用用例来驱动测试用例的行为。这种处理用例检验的方法可以变化，但是很明显，这些用例在测试用例的创建种有重要的价值，团队必须从形式上关注这些用例的质量。 用例的工作空间对于用例何时以及怎样被开发有很多种理论。在有些组织中，具体的团队，比如系统工程或者架构，都要对用例的创建负责。 他们在几乎是真空的环境中创建用例，用他们自己的判定，使用他们所能聚集的所有信息。他们可能会访问利益关系者和开发人员来收集需要的信息，或者他们实际上是基于发布的需求来创建用例的。开发过程的“下游的”团队，比如测试和 文档，可能不会被考虑。实际上他们是设计和开发过程的下游，可能对增加需求讨论还有一定的价值。这样降低了用例的真实价值。 Bittner 和 Spence 提出了一个不同凡响的开发用例的方法。 49 他们建议在这个项目生命周期的早期开始，保持一个用多种参与者团队的用例工作空间，这些参与者有多种技术和知识。他们指出工作空间中参与者的混搭包括项目中每个主要利益关系团队懂得代表。这种方法提供了许多潜在的利益。包括用户代表，开发人员，测试人员，构架师，以及/或者其他主要利益关系减少机会关键问题将会被忽略，因为每个团队都将他们自己对应用软件唯一的观点提到表格上来。它还给每个团队代表提供了确保他们团队的需求能够被满足的机会。这个工作空间提供了一个在成员和每个利益关系团队之间建立良好工作关系的机会；而且它还能保证每个参会的人员对需求都有相同的理解。 根据这个团队的动态，规格，以及所有的努力，可以为三个独立的工作空间建立良好的变量。应该有一个最初的工作空间作为用例的生成之地。第二个工作空间应该包括所有的测试用例为用例验证所用。最后，序列和类图，或者类似的交付产品，从而构成了第三个工作空间的建议。 某些利益关系团队参与这样的工作空间从而获得了辅助的利益——他们获得在这个项目生命周期早期完成有生产价值工作的机会。测试团队是一个特别好的例子。通常情况下，测试人员不会被带进项目中，直到这个开发周期的晚期。因此，他们基本上都依赖于其它团队向他们提供需求信息，外部和内部的设计文档，以及其它相关信息。一旦他们接受了这个信息，他们必须将它与在没有参加任何早期股东会议情况下进行比较。通过将测试编者包含于用例工作空间，这个团队可以开发股东对相关项目需求的前期理解。测试用例编者可以获得这个项目的范围以及技术复杂性的理解，这样他们就可以在这个项目生命周期的早期提供更准确的测试估计。他们能够按照测试策略进行工作，并可以比按照通常的方法提前几个星期甚至几个月完成。如果将这种方法与变更控制紧密联合，将在测试质量上生成相当大的提升。 要获得这个工作空间所有的利益，包含正确的测试资源是十分重要的。团队应该包含一个技术测试领导或者其他测试项目专家，他们对这个应用软件有熟练的经验，而不是依赖于一个键盘输入水平的测试人员或者测试项目的管理人员。每个测试团队派遣到会议的代表都应该为提前完成制定自己的目标。参加这个会议，团队代表都应该有一个他们团队在工作空间所必须的交付产品的列表。 结论当用例不能覆盖所有的测试类型时，他们可以为几个主要的测试阶段提供重要的价值，包括用户验收测试，系统集成测试，功能验证测试，以及单元测试。要最大化这个价值，每个测试所有者都必须是一个活跃的参与者，从而确保在他们特殊的测试阶段能创建高质量和高水平的用例。 如果创建了结构良好、高质量的用例，它们可以为测试组织提供许多利益。他们有助于确保在这个项目的生命周期的早期创建更准确的测试估计。它们可以帮助开发人员更好地理解这个系统希望做什么，帮助构建正确地解决方案。开发循环中的改善意味着一个更高质量的产品被传递到这个测试团队，他们最终帮助将它交付给利益关系者。用例对证明被测试和交付方案需求跟踪性能力有很大的贡献。创建的各种工件都是用例建模的一部分，为测试组织提供了有价值的必需的信息，这些信息在开发测试用例中被利用到。在建模过程中构建的流图在帮助测试人员识别关键路径，优化测试用例执行时十分有用，并且为特定的测试阶段提供了更有效的测试覆盖率。最后，当利用全球方案团队是，用例甚至可以通过减小需求到执行的“转换”风险帮助减轻全球化资源的压力。 要实现测试中使用用例的最大价值，这个项目应该调解用例工作空间的需求。在这个项目生命周期的早期投资一个用例工作空间必须包含所有的必需资源和必需的技术，从而使用例建模顺利到达项目的适当水平。测试人员必须能够清楚地识别为每个测试阶段更彻底地创建适当地测试而附加文档和图。所有这些关键路径交付产品应该在项目水平被跟踪。这些步骤将使得用例能够有效地利用，从而提高这个方案地总体测试质量。 注释
附加参考资料Berger， B. (2001)。“将用例作为测试用例的危险。”文章在 2001的 Starwest 中被提出。StickyMinds.com。从以下网页中获取http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=3096 Wood， D. 和 Reis, J. (1999)。“由用例衍生的测试用例。”论文在1999年的 StarEast 中发表。StickyMinds.com。从以下网页中获得http://www.stickyminds.com/s.asp?F=S2021_ART_2 参考资料
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
