websphere

本文描述了 WebSphere Application Server 及 WebSphere 相关产品（比如 WebSphere Portal）的理想环境。“环境”一词是以含义尽可能最广泛的方式使用的--它实际上包含企业应用程序中从产品开发到产品实现的方方面面。本文解释了为什么每个阶段都是必需的，以及在适当的时机减少成本的各种方法。
本文描述了 WebSphere Application Server 及 WebSphere 相关产品（比如 WebSphere Portal）的理想环境。“环境”一词是以含义尽可能最广泛的方式使用的--它实际上包含企业应用程序中从产品开发到产品实现的方方面面。本文解释了为什么每个阶段都是必需的，以及在适当的时机减少成本的各种方法。

引言

当使用企业级基础架构开发一个大型的复杂应用程序时，训练有素、保持谨慎、细致规划都是最大可能地保证成功所必需的。建立这样一个缜密的系统涉及许多方面，包括但并不限于严格的软件工程、强大的体系结构、详细的设计、合格的员工、细致的计划以及风险管理等等。本文着重讨论人们常常忽略的一个方面：一些设计良好的阶段，在这些阶段中，我们可以严格地开发、测试以及部署应用程序。

尽管本文的重点在于 WebSphere 环境，但是这些内容并不是专门针对 WebSphere 的，相反，我们讨论的是与缜密的开发有关的一般问题，认识到这一点是非常重要的。

图 1 展示了一个理想的 WebSphere 环境。

图 1. 理想的 WebSphere 环境
 

图 1 展示了一个理想的环境，它包括一流严格的环境的各个必需的阶段。在这个环境中，每个子环境都能够根据需要完整地实现预定的功能。

如图所述，您所采用的环境的范围取决于您的应用程序所能接受的风险程度。如要建立图 1 所示的完整环境则需要在时间和资金两 方面都有大的投入。开发简单一些的应用程序或愿意假定风险是逐步增加的组织可以按比例地缩小这个理想的环境的某些方面。在本文的后半部分，我们将描述这样做的方法以及相关风险。首先，我们将更详细地讨论每个阶段。

环境的各个阶段



1.开发环境

开发环境是开发人员每天生活、工作的环境；也就是他们努力工作争取多出成果的环境。因此，他们需要最好的工具以及最少的工作障碍。WebSphere 的理想开发环境如图 2 所示。这个开发环境由许多开发工作站（每个开发人员一台）、一个源码管理工具（SCM）工具和集成工作站组成。

图 2. 理想的 WebSphere 开发环境
 

在理想状况下，应用程序开发人员会使用 WebSphere Studio。使用 WebSphere Studio 有很多优势，其中包括能够实现与 WebSphere 产品家族的紧密集成（例如，WebSphere Application Server 和 WebSphere Portal Server 非常紧密地集成到 WebSphere Studio中）。一般来说，单元测试环境的代码库与运行时环境的代码库相同，因此开发人员能够在集成开发环境（IDE）中测试他们的应用程序，而且有理由应用程序在开发环境中的行为将非常类似于其在生产环境中的行为。

当然，并不是只能选择WebSphere  Studio作为开发工具，其他的开发工具同样可以使用。如果不使用 WebSphere Studio，我们推荐在开发人员的桌面机中安装 WebSphere Application Server以支持单元测试。另外，即使开发人员使用譬如共享的 unix服务器，每个开发人员使用他们自己的 WebSphere Application Server进行测试也是可能的。

全部测试中的绝大部分（90%）都应该在单元测试环境中进行。测试应该持续不断的进行--当开发人员以增量的方式开发并随后测试他们的工作时，他们通常每个小时多次在单元测试环境中运行应用程序。为了使重复的测试效率更高，可以使用某种形式的自动单元测试。请参阅 附录，以了解更多关于单元测试的信息。

在开发人员完成各个功能部件上的工作，他们应该立即根据存储库中的当前工作合并他们的更改。在提交他们自己的工作到存储库之前，开发人员应该集成他们的工作与其他的更改。这样的集成在一天当中应该频繁地进行。

1.1集成工作站
由专门的机器来完成集成工作是很有好处的。这意味着在理想状况下集成工作站可以运行WebSphere Studio（或另外的开发配置），同时又建立与 SCM的连接。

集成团队或开发总监应当定期（可能每天）将代码加载到集成工作站并且进行整套单元测试。这种测试有助于发现错误，这些错误可能是由于开发人员没有与基准保持同步造成的。更重要的是，这有助于形成规范的集成流程，同时也容易发现集成流程中存在的问题（如开发人员不按照规定的集成要求工作）。这样，集成流程就会变得规范起来而且便于控制。程序员的反应可能是形式上的东西尽可能地少一些，但是这不符合需要产生大量文档并且进行错误追踪的开发阶段的要求。

由一个独立的开发工作站来完成集成工作在技术上是可行的。然而，在一个物理上独立的硬件上执行集成流程更利于流程的规范。而且，集成环境的作用在于鼓励频繁地集成。进一步说，这通常意味着每次集成都包含相对较少的变化，一般来说，这会使得集成工作更容易进行。随着改变的数量越来越少，发生流程部分中断的情况也会越来越少，而与此同时，也能以更短的时间、更小的难度去发现并解决出现的问题。

当开发集成工作站不用于集成工作时，它包含了最新的应用程序版本（并且一直在运行）。这使得可以方便地用该机器来进行快速演示（当需要时）。

1.2设备
开发人员使用的桌面机应当是高性能的机器。开发效率是至关重要的，而反应缓慢、功能低下的机器（CPU功能、磁盘空间或内存不足）只会妨碍开发的成功。在极端的情况下，功能低下的系统可能会在基础产品中产生相当多的错误，而这样的产品是没有人购买的，这可能会浪费宝贵的时间

请参考正在使用的工具的正式产品文档以获得推荐（而非最低）配置，并且确保您的机器至少具有这样的性能。如果能够拥有功能更加强大的机器就更好了，这样做是非常有益的。

1.3配置管理系统
运行源代码管理软件的硬件必须是高性能的并且具有高的可靠性（强烈推荐日常备份）。开发人员将从版本管理服务器中频繁地来回移动文件，而系统的崩溃可能会在开发人员的工作效率方面付出沉重的代价。为了实现更好的运行效果，机器运行速度必须很高，并且具有大量的内存和磁盘空间。不要使用那些没人要的过时的机器。同时，对于所有的项目（如果项目非常非常小则除外），应当避免使用开发桌面机作为版本管理服务器。要了解关于硬件设备的详细信息，可以与您的供应商联系。

2. 开发集成运行时

开发集成运行时环境可以供开发人员在硬件和软件上测试他们的应用程序，它类似于目标生产环境。在这种环境中进行测试有助于发现与开发系统和生产系统之间的细微差别有关的问题，并且可以测试部署程序。这可以包括各种操作系统的使用、WebSphere Application Server安全性、备份系统以及其他方面。开发人员可以使用这样的环境来执行所有系统组件的集成测试。这种环境还可以用于测试安装和操作程序，它们常常是特定于操作系统的。

图 3. 理想的开发集成运行时环境
 

集成开发运行时环境配置成能以尽可能最小的规模和复杂性反映生产环境。一般来说，这种环境不包括诸如负载平衡器、路由器或防火墙这样的设备。

这种环境中的系统测试并不是每天而是定期进行的，有可能是两周或者是当重要的改变引入应用程序时。推荐的做法是，开发人员定期在这些类似生产环境的平台上运行应用程序。

这种环境是由开发团队管理的；它是供开发人员日常使用的并且可以在必要时进行升级以执行他们的测试。可定期地使用正式构建、部署和测试程序来更新系统，以去除其中任何不一致的地方并测试完整的构建和安装程序。

一般来说，这种环境不包括任何开发工具。因而，测试依赖测试脚本和追踪的使用来确定正确性和鉴别问题。

2.1动机
开发机器通常是有别于生产平台：一般在开发桌面机上使用Windows 或 Linux，而将更健壮的 Windows、Linux,UNIX 或 z/OS系统用于生产。WebSphere Application Server具有平台无关性的特征，因此在一种平台上构建的应用程序在所有其他平台上都应该具有相同的行为方式。一般来说，J2EE构件（比如 Servlet、JSP 和 EJB在所有的平台上都应该具有相同的工作方式。

然而，单元测试和生产环境之间的不同可以通过这种测试显现出来。在开发阶段，最好尽可能早地发现这些差别。一般来说，发现并纠正开发周期中关键之处的少量错误比较容易，而在您尝试将应用程序投入生产时再发现和纠正大量的错误就要困难得多。

2.2 装备
开发集成运行时环境以尽可能最小的规模反映生产环境。对于典型的项目，这是一台单独的机器，运行相同的操作系统和用于生产环境的 WebSphere Application Server版本。

2.3 估计开发集成运行时环境的大小
一个经常被提及的主题是如何正确地估计开发集成运行时环境的大小。我们将不讨论像多少CPU或多大内存这样的具体细节，因为影响这些问题的因素太多了，以致难以胜数。这里要讨论的问题是大体确定什么是合适的。

把许多的钱花在所需的硬件上是不值得的，但是硬件投资又必不可少。在一个小的开发团队（10人或更少）中，有一个共享的环境是可行的。开发人员在他们的桌面系统中完成他们绝大部分的工作，只是偶尔才会使用开发集成运行时环境。当他们使用这种环境时，由于它是共享的，所以他们承担着妨碍其他人工作的风险，不过，这应该是可控制的。

A如果开发团队扩大或多个项目共享相同的机器，管理一个共享的集成环境就会变得异常的困难。在这种情况下，应该创建多个环境，这样开发人员就可以相互独立地进行试验。这正是事情变得棘手之处。为了达到彻底的分离，开发人员需要完全独立的 WebSphere Application Server 域或单元。因而，单个开发集成运行时环境需要支持大量的单元或需要包括多个环境。

根据经验，不超过 5 到 10 人的开发团队可以共享一个“集成”环境。就您而言，正确的数字可能会或高一些或低一些，但是我们希望这会给您提供一个概念。总会有少数开发人员需要进行更复杂的试验，这些试验可能会损害有关单元。他们可能需要专门的 WebSphere Application Server 实例或整个单元来进行试验。关键是，您应当计划创建多个单元或多个应用程序服务器实例，而且应该有充足的硬件来对此进行支持。

3. 系统测试环境

系统测试环境是精心控制的正式测试环境。开发团队相对少地在这种环境中运行他们的应用程序--可能每六到八周一次。与开发集成环境相比，系统测试环境更接近地反映了生产环境，但是它仍然尽可能以最小的规模来这样做。图 4 展示了示例系统测试环境。

图 4. 理想的系统测试环境
 

规范化是系统测试环境的关键。这种环境的目的是保证应用程序将在需要时真正地部署和运行在生产中。因而，系统测试团队负责测试系统的方方面面，包括功能性需求和非功能性需求。功能性需求通常是显而易见的：应用程序能否如设计一样执行业务规则；应用程序能否根据需要运行（从用户的角度）等等。然而，记住此处的测试也应该包括非功能性需求是非常重要的，这些非功能性的需求有安装、备份和失败程序（failure procedure）。在系统测试过程中的任何失败都会导致拒绝构建。而开发试验是在开发集成运行时环境中非正式地进行的。

系统测试环境可以服务多种角色。除了由测试人员正式使用之外，其他的组也可以使用它，这取决于在您的环境中什么是合适的。例如，管理人员可以在新的补丁程序和配置更改并入预生产和生产环境之前使用这种环境对它们进行测试。如果用户接受测试（User Acceptance Testing）是您的开发流程中的正式阶段，则这种测试也可以在此进行。正式的用户接受流程通常意味着系统可以在一段明确定义的时间内维持运行（没有开发人员接触它），而用户简单地使用该系统来验证它是否如他们所愿进行工作。在许多方面，这重复了功能性测试的概念。终端用户社团实际上赞同系统满足他们的概念是有价值的。而且，如果这些测试尽早进行的话，很多问题都可以解决。

一个系统测试环境可服务与多个管理者。在测试中，其他人员可以象在自己的环境中一样独立的完成测试。例如：管理人员可以在产品进入实际运行阶段前检测新的补丁程序。如果，系统测试在你的开发流程中是个规范的阶段，那么用户测试也可以在此阶段执行。用户测试仅仅检测系统是否按照设计好的原则运行，以及是否如用户所愿进行工作。很多时候都会认为这样的测试是重复的。但是，进行最终用户测试对于满足用户的需求是可取的，而且，如果这样的测试能尽早实施的话，很多问题也就不会发生了。

系统测试无疑将有许多不同的活动需要细心地控制、调度和管理。而实际的测试可能会比较的漫长。出现每个问题都需要用规范的程序去解决，否则就可能会造成重要信息的丢失。在理想的状况下，系统测试环境由开发团队以外的人员组成的单独的组来管理和运行。

3.1 装备
这种环境通常需要多个应用程序实例运行在物理硬件的多个部件上。这种环境也应该使用与生产相同的操作系统和软件版本。系统测试团队使用这种环境来观察应用程序如何运行在负载平衡的环境中。这种测试可能包括譬如通过测试来查看应用程序在故障转移的情况下如何响应。

4.性能和负载测试

进行性能与负载测试的目的是为发现应用程序中与负载有关的问题。这种测试需要高度专业化的技能和装备，以便最优化地进行。因而需要专门的环境与开发团队。

类似于系统测试环境，性能测试环境同样是一个精心控制正式测试环境。开发人员在这种环境中运行他们的应用程序的频次会更少。性能测试环境在复杂性方面反映了生产环境，但是它是以尽可能最小的规模这样做的。（用户接受测试也可能发生在预生产环境或性能/负载测试环境中）。图5 展示里了一个理想的性能测试环境的示例。

图 5. 理想的性能测试环境
 

与负载有关的问题可以在几个地方发现：验证能力是否满足响应和可伸缩性标准、确定扩展因素以及搜索潜在的错误。要了解更多关于性能测试的信息，请参见 [Joines]。

在负荷测试运行的过程中，测试团队应当密切关注以下几个方面的性能：CPU、内存、磁盘的使用情况、响应时间等等。他们将使用这些信息来确定系统是否满足响应和可伸缩性标准，并且确定系统扩展的程度。第二项数据可用于预测当系统在生产中扩展时未来的硬件要求。最后，测试团队将把应用程序尽可能接近地推向中断点，以发现潜在的错误。遗憾的是，许多系统包含难于检测到的错误，它们或者很少出现，或者是在并发访问时引起的。只有通过大规模的负载测试，才有可能在您的客户发现这些错误之前把它们找出来。

在理想的状况下，这种环境是由专门的性能测试组管理和操作的，其成员具有专业的负载测试技能。与运行在系统测试环境中相比，应用程序进行负载测试的频次更少。如同系统测试环境的情况一样，一个应用程序只测试一次。

4.1 装备
与系统测试环境非常相似的是，性能测试环境也具有特定的目的。这种环境也反映生产环境，只不过是以比系统环境更大的规模这样做。这种环境应该使用与生产环境相同的硬件和软件（包括操作系统版本），并且运行在专门的网络（或子网）上，其中包含专用的防火墙、Web服务器、负载平衡器和其他所需资源（如数据库）。

另外，负载测试环境将包括用于生成所需负载的工具，比如 Mercury Interactive's LoadRunner。这些工具需要专用的高性能客户端机器来用于生成负载。

5.预生产

预生产的目的是尽可能多地模拟生产（以 确实存在的标准）。这是确保事情将真正地在生产中发挥作用的最后机会。

这种环境用于三个目的：

它给操作团队提供了熟悉应用程序及其操作程序的最后机会。
它提供了测试一起运行的无关应用程序的机会。对于共享的部署环境这是至关重要的。在此之前，应用程序已经独立测试和构建完毕。
它给操作团队提供了测试他们的操作程序（备份、失败转移、问题解决等等）的机会。

正如前面所提到的，预生产还可能用于用户接受测试。在任何情况下，在预生产分阶段环境中进行测试通常都符合应用程序的版本安排。每个来自外部的应用程序版本在最后迁移到生产系统之前都必须在预生产系统中进行测试。这种环境通常用于证明与其他的应用程序工作良好。

质量保证测试人员可以把这种环境作为发布周期的一部分。

5.1装备
在理想状况下，预生产环境在复杂性和规模方面确切地反映了生产环境（包括专用的防火墙、Web服务器、负载平衡器和其他所需的资源）。这种环境用于测试一起运行的多个--可能是不相关的--应用程序，就像它们是在生产环境中一样。

6生产

毋庸费言，生产当然是要生产出产品。这是真正运行应用程序的环境。关键是，如果您在此之前严格地遵循了程序，那么在实际投入生产时，一切都会显得平淡，一切都会在预料之中，没有什么让人感到兴奋之处，也没有什么引起您惊慌的事情，因为每件事情都已经测试过，现在投入生产是理所当然的了。

工具

由于系统测试环境、性能测试环境和预生产环境用于测试，所以有一组工具是理想的环境不可或缺的。这些工具提供了收集帮助分析应用程序的基准特性的数据的能力。当改变和新的版本应用到这些环境中时，这些工具既重新创建环境，又提供数据来显示是否有所改进。其中有些工具还有助于诊断故障和确定问题。

加载工具

如果不在性能测试环境中进行某些加载测试，则没有任何一种环境能够预测加载时应用程序的行为。加载工具是应用量的方法。有像 Apache的 JMeter4和 IBMAlphawork的 Web 性能工具这样的开放源代码工具，也有像MercuryInteractive 的 LoadRunner这样的高端商用工具。高端工具通常提供诸如绘图、响应确认和生成器之类的特征，这些特征是开放源代码工具所不提供的，并且允许您手工使数据相关联。

响应确认是非常重要的。我们曾经遇到过加载中的应用程序大约在 0.1%的时间内返回错误的应答。扫描输出日志来查找这样的结果是不可行的，因此需要自动工具来检查响应是否是所需要的响应。

应用程序监控

为了理解应用程序在加载时的行为，您需要能够了解应用程序服务器环境本身。通过使用应用程序监控工具可以做到这一点，应用程序监控工具提供了统计信息，比如Servlet 响应时间和当前打开的JDBC连接的数量。在这个领域存在多种多样的工具，从来自 IBM的低端（免费）工具到高端工具（比如 Wily的 Introscope和 Tivoli的性能工具）都有。而且，高端工具往往提供大量的特征，比如提供对整个集群的查看，这是像资源分析器（Resource Analyzer）所没有的。

故障诊断

虽然在典型的故障诊断练习中您将会使用加载工具和应用程序监视器，但是其他一些更低端的工具也有助于问题确定和根本原因分析。一些工具（比如 HTTP Proxy Tunnel）允许快速分析浏览器和 Web 服务器之间的流量。（WebSphere Studio 提供了像这样的内置工具，不过有些免费的工具也可以执行类似的功能。）对于真正的困难问题，可以使用像 Ethereal这样的高级方法来提供网络级包测错功能。

降低成本

在理想的状况下，所有的组织都将遵循本文所做的推荐。然而，大多数组织有非常现实的成本约束。此外，并非所有的应用程序都是“企业级”的。因而有正当的理由可以尝试降低前面的部分所暗示的成本。在这一部分中，我们将简要描述降低成本的可能方法以及这样做所涉及的风险。

预生产分阶段

虽然的确是值得要的，但是构建和维护分阶段环境是相当昂贵。对于比较小的公司和复杂性低的环境，拥有分阶段的环境的情况并不常见。

系统测试

虽然系统测试不可缺少，但是可以做几件事来降低成本。

首先，系统测试环境可以为几个团队所共享。如前所述，在各个测试周期中，每个应用程序可能只使用环境几天。因而，如果多个应用程序将部署到相似的硬件中，共享这种环境具有重要的意义。在有许多正在并行开发项目的大型组织中，共享系统测试环境也是有意义的。在任何情况下，对这些环境的访问都应该精心地管理和安排。然而，请记住，共享不可避免地会产生时间安排方面的冲突。要保证应用程序将没有冲突的需求将简直是不可能。因此，虽然在硬件还有可能人员配备方面节省了相当多的资金，但是应用程序测试周期将会更长。

其次，严格地模拟生产是没有必要的。特别地，没有必要为系统测试环境配备大规模高性能硬件。事实上，为了更早地发现与加载有关的错误，在系统中使用功能更低的硬件是比较合适的。

性能测试

对于具有低的性能需求的小型应用程序，没有必要进行正式的性能测试。某些简单的加载测试可以在别的地方进行。然而，请记住，如何不进行基本的加载测试，潜在的错误将永远不会被发现。

同样，我们推荐专门的性能测试环境和团队也仅仅是针对部分组织而言的。例如，在这种情况下，性能测试可以由系统测试团队在系统测试硬件上进行。然而，需要谨记的是，系统测试环境因而需要硬件（意味着系统测试将需要大规模模拟生产的机器、防火墙和加载平衡器）和技能来支持这种类型的测试。特别地，也别忽视了专用网络的重要性；否则，性能测试数字也就毫无意义了。

开发集成测试

为开发团队配备大规模昂贵的机器来进行开发是很常见的。这常常会造成资金的浪费。使用型号最新装备齐全的机器来进行开发是没有必要的。只要操作系统和基本特征是相同的，旧一点慢一点的机器也是很合适的。例如，如果生产将使用带有20 个 CPU 的大型 AIX 机，那么使用带有 4 个 CPU的小型机应该就足够了。当然，需要谨记的是，如果是大型的开发团队，就需要一台大型机来支持所有的开发人员，正如前面所提及的。

在理想状况下，每个开发团队都有自己的开发集成运行时环境。如果资金非常紧张，通过适当的安排，多个开发团队可以共享环境。然而，如果不同的时间表上的不同用户有不一致的硬件和软件需求、不一致的版本（这是最严重的问题），那么共享环境可能会导致相当严重的冲突。同样，请记住，如果共享太多，则需要严格而繁复的改变控制程序。这对于开发而言是不适当的。开发人员需要现在就完成工作。后期阶段需要规范化，前期阶段则是相对松散的。如果可能，多个小组可以共享相同的物理硬件而使用单独的WebSphere 单元来缓解这个问题。

最后，在最极端的情况下，开发集成运行时环境和系统测试环境可以组合在一起。然而，这样做是格外危险的并且可能会造成严重的后果。当开发人员有权使用相同的机器时，很难确保系统测试正在真正正确的构建。实际情况表明，开发人员可能会在完全无意识地修改了系统测试团体正在使用的配置文件。物理上的高度分离有助于预防这些类型的错误的发生。

总结

本文讨论了利用企业级软件开发复杂系统的各种子环境（或阶段）。我们描述了为什么每个阶段是必需的以及降低成本的可能途径。将这些建议应用于您的企业可能会引起前期费用增加，但是从长远看，我们相信，应用这些建议将使您高枕无忧，不会出现一些意想不到的情况，譬如某些项目在没有任何前兆的情况下就突然落后于预定计划好几个月--甚至还会更糟糕，系统在生产中出现严重故障，这时您的客户将会看到这些问题。

记住：在客户发现错误之前改正错误远比在客户发现错误之后弥补错误的花费少的多。这是经验之谈。

附录：自动单元测试

关于开发的文章没有完全不讨论自动单元测试的。我们的经验表明，单元测试特别是自动单元测试在开发过程中是非常有帮助的。利用诸如 JUnit这样的工具进行的自动单元测试可以加速重复的开发流程，自动单元测试使开发人员自信对应用程序所作的改变是正确的，因为他们知道可以充分地测试这些改变及其影响。

在理想状况下，应用程序开发人员自己为他们编写的代码构建测试用例。在最佳场景中，单元测试实际上是先于待测试的代码而构建的。这样做有两方面的原因，其一，如果首先构建单元测试，则可以在一定程度上保证将实际构建单元测试。其二，单元测试可以收集这样一些信息，假定代码如何工作（假定代码做什么）以及哪些工具可以使创建代码更容易；如果在您的头脑中有一幅清晰的假定代码做什么的图画，构建代码就更加容易了。创建单元测试是一个耗费时间的过程。一般来说，所有开发时间中有25% 以上花在构建这些测试上面。The tradeoff can be enormous.这种牺牲的回报可能是非常大的。单元测试使早期发现和解决问题更容易，这可以转化成项目开发时间的大量节省。

编写好的测试案例是一项繁重的工作。如果初次接触，则需要很多的帮助。成功的单元测试能给开发人员很大的信心；遗憾的是，失败的单元测试则会降低开发信心。单元测试必须作为一级的应用程序代码来进行管理。中断的或不正确的单元测试比没有测试更加糟糕。Martin Fowler的”Refactoring”一文非常详细的介绍了单元测试的相关知识。

编写好的测试是一项繁重的工作。如果您只是刚开始了解单元测试，则可以获得一些帮助。单元测试让开发人员对他们的工作感到自信；不幸的是，坏的单元测试也会给他们自信，这常常会造成损失惨重的后果。单元测试必须作为一级应用程序代码管理。未维护的或不正确的单元测试比根本没有进行单元测试更有害。 MartinFowler 的“重构”中关于测试的章节很好地介绍了单元测试。

致谢

我们非常感谢 Alex Polozoff 为本文所作的贡献。

参考资料

您可以参阅本文在 developerWorks 全球站点上的 英文原文.


Martin Fowler 撰写的 Refactoring: Improving the Design of Existing Code（Addison-Wesley，1999 年）。


Stacy Joines、Ruth Willenborg 和 Ken Hygh 等撰写的 Performance Analysis forJava Web Sites（ISBN 0-201-84454-0，2002 年）。


作者简介
Keys Botzum是 IBM Software Services for WebSphere 的一名高级顾问。他在大型分布式系统设计方面有着十多年经验，并且专攻安全性问题。他使用过各种分布式技术，包括 Sun RPC、DCE、CORBA、AFS 和 DFS。最近，他着重研究 J2EE 及其相关技术。他拥有斯坦福大学计算机科学硕士学位和卡内基梅隆大学应用数学／计算机科学学士学位。  

Wayne Beaton 是IBM Software Group 的 Software Services for WebSphere 部门的一名高级软件顾问。他的主要研究领域是从WebSphere 和有竞争力的产品的早期版本到 WebSphere 5.0 的迁移。他与人合著了关于迁移主题的两本 IBM 红皮书。Wayne 担任的多种角色使他有机会涉足很多有趣的领域，从 WebSphere Skills Transfer 程序到一般的顾问等。Wayne 在空余时间喜欢说服别人，让他们相信极端编程、重构和单元测试真是有用的。