8应用 Rational 工具简化基于 J2EE 的项目.docVIP

应用 Rational 工具简化基于 J2EE 的项目，第 8 部分: 测试软件 Steven Franklin (steve@), 软件设计师和过程专家 Steven Franklin 在软件的设计、架构和工程过程方面有非常广泛的背景，这些经验通常被用到大的，分布式的信息管理和控制系统中。他从1997年开始使用 Rational 工具，他主要的兴趣在 XML 、J2EE、无线和软件工程技术方面。你可以通过 steve@联系 Steven. 简介：?当我们正在进行的样例项目进入到了这个阶段时，我们开始大量的使用 Rational 的测试工具来完成项目的单元测试工作，尤其是在功能测试（包括脚本化的 GUI 测试）方面。 本文是演示了在分布式的、基于 J2EE 的项目中使用 Rational 工具的系列文章（如下面所列）的第 8 部分。 第 1 部分: 项目介绍；高层次计划 第 2 部分: 风险管理；需求管理 第 3 部分: 模型创建和访问控制；需求分析 第 4 部分: 用例细化；产成报告；工具和技术选择 第 5 部分: 体系架构和设计 第 6 部分: 详细设计；早期开发；双向工程；早期单元测试 第 7 部分: 继续开发；早期的构建；演示 第 8 部分: 单元测试策略；功能测试；GUI 测试脚本 第 9 部分: 系统构建和测试；缺陷跟踪；产品交付 第 10 部分: 项目完成；结论；未来的工作 本文中所虚构我们是一家软件公司 Lookoff Technologies Incorporated，我们的客户 Audiophile Speaker Design, Inc. (ASDI)，它雇用我们实现他们最初的 IT 需求。对于更详细的信息，参见 第 1 部分。 本文是这个系列文章的第 8 部分，本文中对最初在这个系列的 第 6 部分介绍的测试方面的主题进行了详细的讨论。在第 6 部分的文章中，我们看到了在早期的开发当中我们开始使用 Rational Purify 和 Rational Quantify 检查内存的使用情况和性能的瓶颈。同时也讨论了我们在早期的单元测试工作的很多细节。本文将描述这些工作的进展，并回顾我们使用 Rational 测试工具的自动化测试的能力来减少测试的成本，主要是 Rational PureCoverage 和 Rational Robot 的使用情况。在项目的这个阶段，我们主要关注在功能测试（包括 GUI 测试）上，虽然我们也从事了一些早期的负载测试。 注意，这里使用的 Rational 统一过程（RUP）术语反映了测试的两个不同的维度：“单元测试”是在将要被测试的软件的开发阶段进行的 — 在这个时候测试是针对最小的可测试的软件单元的 — 而“功能测试”和“负载测试”是针对特定测试目标的，不管是在被测试软件的哪个开发阶段。本文中所讨论的关于单元测试的大多数内容也可以应用在我们后面的开发阶段的测试工作中（例如，在集成测试期间合并不同的组件或者子系统）。 第 8 部分快照 在第 8 部分演示的工具和技术： Rational PureCoverage—用于在单元测试期间分析代码的覆盖率（代码被执行的次数） Rational Robot—为可重复的自动化执行录制和回放测试脚本 Rational Administrator— 用于创建项目，与 Rational Robot 一起使用，关联与项目相关的测试脚本 Rational TestManager— 组织和管理测试，并查看测试的结果 被创建或者更新的产物： Robot 测试脚本—为自动化测试的执行而被创建 第 6 部分提到的那样，我们的单元测试工作几乎与核心的软件开发本身开始的一样早。我们多数的开发人员在他们拥有一个能够被测试的软件单元不久就开始编写单元测试。他们喜欢当代码在他们的头脑中产生时测试软件的内部构件。 单元测试的执行总是先于系统的构建；将明显能够通过单元测试来消除的简单缺陷引入到一个构建版本中是让人不可接受的。单元测试总是在代码被分发检查之前被执行。此外，开发人员以规范的基础运行他们的单元测试以确保他们的定期变化不会破坏软件。我们的方法不像一些软件方法那样激进 — 比如 极限编程（XP），在 XP 中单元测试的开发通常是先于代码的开发的 — 但是我们将单元测试当作是一个重要的软件开发的早期步骤。 自动化的能力 这里当然也有一些如何进行测试的问题，特别是什么样的测试应该被自动化的范围。编写“后台”（非 GUI ）代码的开发人员是幸运的，他们能够编写自动化的测试，包括 Java 驱动程序、代码存根和脚本。然而，就像我们早些时候提到的，GUI 开发人员的测试是更加困难的。 对于我们的非 GUI 测试，我们观察了与每