有以下几种原因。

 

　　使用 GUI 测试很难彻底地测试到系统的每一条路径，GUI 仅仅是影响系统的一种方
式。可能存在后台运算、脚本和各种各样的其他访问点，这也需要进行测试，然而，它们

 

通常并不具有 GUI。
　　GUI 级的测试是一种非常粗粒度的测试。这种测试只是在宏观水平上测试系统的行为，
这意味着一旦发现存在问题，则与此问题相关的整个子系统都要进行检查，这使得找出
错误将是非常困难的事情。
　　GUI 测试通常只有在整个开发周期的后期才能很好地得到测试，这是因为只有这那

 

个时候 GUI 才得到完整的定义。这意味着只有在后期才可能发现潜在的错误。

 

　　一般的开发人员可能没有自动的 GUI 测试工具。因此，当一个开发人员对代码进行
更改时，没有一种简单的方法来重新测试受到影响的子系统。这实际上不利于进行良好的
测试。如果开发人员具有自动的代码级单元测试工具，开发人员就能够很容易地运行这些
工具以确保所做的更改不会破坏已经存在的功能。
　　如果添加了自动构建功能，则在自动构建过程中添加一个自动的单元测试工具是非
常容易的事情。当完成这些设置以后，整个系统就可以有规律地进行重建，并且回归测试
几乎不需要人的参与。

 

　　另外，我们必须强调，使用 EJB   

和 Web 服务进行分布式的、基于组件的开发使得测

“

试单个组件变得非常必要。如果没有 GUI”需要测试，您就必须进行低级(lower-level)测

 

试。最好以这种方式开始测试，省得当您将分布式的组件或 Web 服务作为您的应用程序
的一部分时，您不得不花费心思重新进行测试。
　　总之，通过使用自动的单元测试，能够很快地发现系统的缺陷，并且也易于发现这
些缺陷，使得测试工作变得更加系统化，因此整体的质量也得以提高。
　　4. 按照规范来进行开发，而不是按照应用服务器来进行开发。
　　要将规范熟记于心，如果要背离规范，需经过慎密的考虑后才可以这样做。这是因为
当您背离规则的时候，您所做的事情往往并不是您应该做的事情。

 

　　当您要背离 Java EE 允许您做的事情的时候，这很容易让使您遭受不幸。我们发现

 

有一些开发人员钻研一些 Java EE 

“

”

允许之外的东西，他们认为这样做可以 稍微 改善 

Java EE 的性能，而他们最终只会发现这样做会引起严重的性能问题，或者在以后的移
植(从一个厂商到另一个厂商，或者是更常见的从一个版本到另一个版本)中会出现问题。

 

实际上，这种移植问题是如此严重，以致 [Beaton] 将此原则称为移植工作的基本最佳
实践。

 

　　现在有好几个地方如果不直接使用 Java EE 提供的方法肯定会产生问题。一个常见

 

的例子就是开发人员通过使用 JAAS 

 

模块来替代 Java EE 安全性，而不是使用内置的遵

 

循规范的应用服务器机制来进行验证和授权。要注意不要脱离 Java EE 规范提供的验证
机制。如果脱离了此规范，这将是系统存在安全漏洞以及厂商兼容性问题的主要原因。类

 

似地，要使用 Servlet   

和 EJB 规范提供的授权机制，并且如果您要偏离这些规范的话，

 

要确保使用规范定义的 API(

 

例如 getCallerPrincipal())作为实现的基础。通过这种方式，

您将能够利用厂商提供的强安全性基础设施，其中，业务要求需要支持复杂的授权规则。

 

　　其他常见的问题包括使用不遵循 Java EE 规范的持久性机制(这使得事务管理变得困
难)、在 Java EE

 

程序中使用不适当的 J2SE 方法(

 

例如线程或 singleton)，以及使用您自

己的方法解决程序到程序(program-to-program)

 

的通信，而不是使用 Java EE 内在支

持的机制(

 

例如 JCA、JMS   

或 Web 服务)

 

。当您将一个遵循 Java EE 的服务器移植到其他