UML软件工程组织 |
应用 Rational 工具简化基于 J2EE 的项目第 8 部分 : 测试软件 | ||||||||||||||||||||||||
本文是演示了在分布式的、基于 J2EE 的项目中使用 Rational 工具的系列文章(如下面所列)的第 8 部分。
本文中所虚构我们是一家软件公司 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)术语反映了测试的两个不同的维度:“单元测试”是在将要被测试的软件的开发阶段进行的 — 在这个时候测试是针对最小的可测试的软件单元的 — 而“功能测试”和“负载测试”是针对特定测试目标的,不管是在被测试软件的哪个开发阶段。本文中所讨论的关于单元测试的大多数内容也可以应用在我们后面的开发阶段的测试工作中(例如,在集成测试期间合并不同的组件或者子系统)。 单元测试 虽然 ASDI 项目的第 1 阶段只是一个概念上的验证,但是我们也具有艰苦的时间忍耐在系统中显而易见的 bug 。在拥有坚固、可靠的软件和频繁的集成、快速的演示之间找到一个平衡是非常不容易的。我们定义了第 1 阶段项目的范围,这样我们就必须进行不止一次的技术上的演示;客户期望演示是一个可以使用的系统的 beta 版本。 这里,我们将看一下我们的单元测试工作的范围,我们可以选择(或者不)使用自动化的能力,并且我们使用 Rational PureCoverage 来确定我们测试的彻底性。 测试的范围
在代码测试的次数方面,在之前的项目中我们没有打算在我们的软件中进行 100% 代码覆盖率的测试。完全的覆盖是非常昂贵的并且很难达到,因为我们必须要手工的检查我们的代码以确定哪一行代码没有被测试覆盖到。对单元测试的小的变化将要求我们重新检查代码以确保完全的覆盖率被维护。然而,我们得感谢 Rational PureCoverage ,在 ASDI 项目中我们能够容易得实现了接近 100% 的代码覆盖率(由于项目预算和范围的原因,少量的未测试的残留是被允许的)。PureCoverage 很大程度的简化了检查代码覆盖率的任务,这使识别哪一部分的代码已经或者还没有被测试变得非常简单。 就像我们在这个系列的第 6 部分提到的那样,我们的单元测试工作几乎与核心的软件开发本身开始的一样早。我们多数的开发人员在他们拥有一个能够被测试的软件单元不久就开始编写单元测试。他们喜欢当代码在他们的头脑中产生时测试软件的内部构件。 单元测试的执行总是先于系统的构建;将明显能够通过单元测试来消除的简单缺陷引入到一个构建版本中是让人不可接受的。单元测试总是在代码被分发检查之前被执行。此外,开发人员以规范的基础运行他们的单元测试以确保他们的定期变化不会破坏软件。我们的方法不像一些软件方法那样激进 — 比如 极限编程(XP),在 XP 中单元测试的开发通常是先于代码的开发的 — 但是我们将单元测试当作是一个重要的软件开发的早期步骤。 自动化的能力 对于我们的非 GUI 测试,我们观察了与每一个类相关联的单元测试的习惯;我们编写驱动代码访问类,并报告成功或者是失败。我们尝试使用能够为我们自动生成、管理和运行测试的测试框架,比如被 XP 所推荐的那些工具,但是他们将产生混杂的结果。虽然理论是很好的,但是这些框架(包括,比如 JUnit)对于我们的项目目的来说来是不够成熟的。不过,我们的开发人员非常自信如果他们有时间熟悉和对这些工具进行改进,这些测试框架对我们的单元测试是非常有价值的。我们也许在将来的项目中更多的使用这些测试框架。在我们的 ASDI 项目中,采用 XP 的方法也许是太冒险了;相反,我们更加愿意接受 XP 在控制和风险降低方法方面的概念和思想。你能够在 the XProgramming.com 网站上找到大量有关 XP 思想的内容。 我们没有使用 Rational 的测试工具来测试非 GUI 的代码,因为我们觉得他们不能达到一个足够底层的级别。对于自动化测试我们的 GUI 驱动的代码,Rational 的测试工具真的表现的非常出色。用户界面测试是非常手工和交互的,并且要求大量的内容确认; Rational 的测试工具以一种一致的并快速的方式使我们反复的进行这些测试变得更加的简单容易。 代码覆盖率 PureCoverage 除了可以支持 C 或者 C++ 的应用程序以外,还可以支持 Java 程序,并且可以通过与 Quantify 相同的方式来配置和运行(在这个系列的第 6 部分被讨论过)。这个工具能够使我们浏览我们的单元测试;以两种方法进行代码覆盖测试:使用 Coverage Browser 或者指定文件的 Coverage Fileview 方式。 使用 Coverage Browser 的方式(图 1 ),我们能够看到在单元测试中被包括的每一个文件(和目录)的代码覆盖测试的统计学的总结。这些统计表包括了所有方法的调用次数,方法被访问或者遗漏的次数,还包括被访问或者遗漏的代码行的数量。 我们能够双击一个在总结中的方法来进入 Coverage Fileview ,仅仅显示在那个方法中哪些代码行被访问或者被遗漏。就像被显示在图 2 中的例子,被遗漏的代码行被用红色突出出来(被访问的代码行用蓝色标识)。 功能测试
我们尽可能早的开始创建我们的功能测试集合,因为这些测试对工程团队来说是非常有价值的工具。我们在代码被分发检查之前适当的拥有测试脚本的目标有时是很难实现的,可能是因为代码的一些部分和一些组件要比其他的代码和组件花费更多的时间来完成,或者是因为集成和测试(I&T)团队太慢以至不能及时的完成测试脚本。在一种情况下,当用户界面仍然在变化时,测试脚本已经被完成了;虽然一些返工是必要的,但是变化的出现是相当容易集成的。 一旦我们拥有了一个强有力的功能测试集合,重新测试系统将是非常容易的。这样当你需要在后来的迭代中重新测试系统小的改变时得到很大的回报,并且可以确保变化不会影响其他的代码部分。我们映射我们的功能测试脚本到用例上,以便我们可以立即知道当被关联到被给定的用例的需求被修改时哪一个测试应该被运行。 GUI 测试
一些 GUI 测试尤其令人讨厌,包括相同的入口,在几个域中填写冗长的值。可以使用剪切和粘贴,但是对于团队来说一遍一遍的重复这些测试仍然是非常琐碎的工作。有些页面有 50 个不同的测试必须被执行,每个测试都包括很多的步骤。 虽然我们最初不倾向使用 Rational 的测试工具,但是我们觉得我们在 GUI 上的困难是我们深入研究 Rational 测试工具的很好的理由。我们决定使用 Rational Robot 来自动化我们 GUI 的大部分测试。我们通过以下的方式调整了这些测试:
这个方法工作的非常好。它不仅仅在集成与测试团队没有太多的事情做的开发过程的早期阶段给他们在更多的工作,而且也给他们一个机会通过揭示单元测试说明来了解整个软件系统。此外,我们为 GUI 测试使用 Robot 的经验也为阿我们对其他的功能测试脚本进行了准备。 当 Rational Robot 启动时,它需要一个已存在项目(使用 Rational Administrator 创建的)的选择,测试脚本将与这个项目进行关联。在我们的例子中,项目的定位必须是在网络上可访问的,以便我们能够在整个团队中共享项目的数据库。我们在 Administrator 中创建了 ASDI 项目,如图 3 所示,并且当 Robot 提示我们选择一个项目时,我们选择了这个项目。 一个验证测试的例子 创建测试脚本 在点击 OK 这后,我们被提供了一个录制控制器(图 6),然后当 Robot 录制我们的动作时,我们使用我们的基于窗口的应用。在这个例子中,我们启动了
Internet Explorer 5 ,在 Robot 将我们的动作记录在一个 GUI 脚本中(图 7 )。这是一个非常简单的例子;我们实际的测试会包括更加复杂的测试脚本。我们不用创建成百上千个独立的脚本,而是尽量为每一个屏幕界面设计一个大的脚本。在 Robot 的文章中有进行测试设计的非常详细的信息,我们能够从 Robot 文档中所推荐的内容中得到大量的借鉴。 通过使用易读的并且可以容易的进行编辑的脚本,我们就不必为只是有很小差异的测试重复的录制测试脚本了。有时我们可以不用重新运行测试就直接编辑测试脚本,或者我们只是重新录制一个测试的一小部分,然后将它粘贴到已存在的脚本中。 运行测试 假设我们想测试代码的错误处理能力,比如坏的数字不再被捕获 — 也就是说,没有出现一个指明错误的窗口,我们的应用就会将整个数据传送到 servlet 来执行查询。当我们通过回放脚本重新运行这个 GUI 测试时,Robot 将会捕获这个问题,并且将结果写到报告中(图 9 ),包括显示出这个测试是失败的。 总结 计划未来 我们的风险列表在此刻已经非常的短了。客户在演进系统上的合作并不太令人惊讶,我们的技术风险已经非常少了,非常感谢工程团队带来的良好的进展。 现在我们必须对我们的代码开发进行最后的加工、执行系统的测试、识别系统中的任何缺陷并按计划交付阶段一的系统给客户。当团队接近主要阶段的尾声时,及时的将所有的细节包装起来通常时很难的。如果我们想避免超出计划,我们就需要系统有少量的缺陷,并且能够快速的矫正在测试中发现的任何问题。
|
版权所有:UML软件工程组织 |