尽管所有这些详述了怎样彻底地测 试您的应用程序，但是我们仍然看到一些人认为只要他们测试了 GUI（可能是基 于 Web 的 GUI，或者是独立的 Java 应用程序），则他们就全面地测试了整个应 用程序。仅进行 GUI 测试是不够的。GUI 测试很难达到全面的测试，有以下几种 原因。

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

GUI 级的测试是一种非常 粗粒度的测试。这种测试只是在宏观水平上测试系统的行为，这意味着一旦发现 存在问题，则与此问题相关的整个子系统都要进行检查，这使得找出错误将是非 常困难的事情。

GUI 测试通常只有在整个开发周期的后期才能很好地得到 测试，这是因为只有这那个时候 GUI 才得到完整的定义。这意味着只有在后期才 可能发现潜在的错误。

一般的开发人员可能没有自动的 GUI 测试工具。 因此，当一个开发人员对代码进行更改时，没有一种简单的方法来重新测试受到 影响的子系统。这实际上不利于进行良好的测试。如果开发人员具有自动的代码 级单元测试工具，开发人员就能够很容易地运行这些工具以确保所做的更改不会 破坏已经存在的功能。

如果添加了自动构建功能，则在自动构建过程中添加一个自动的单元测试工具 是非常容易的事情。当完成这些设置以后，整个系统就可以有规律地进行重建， 并且回归测试几乎不需要人的参与。

另外，我们必须强调，使用 EJB 和 Web 服务进行分布式的、基于组件的开发 使得测试单个组件变得非常必要。如果没有“GUI”需要测试，您就必须进行低级 （lower-level）测试。最好以这种方式开始测试，省得当您将分布式的组件或 Web 服务作为您的应用程序的一部分时，您不得不花费心思重新进行测试。

总之，通过使用自动的单元测试，能够很快地发现系统的缺陷，并且也易于发 现这些缺陷，使得测试工作变得更加系统化，因此整体的质量也得以提高。

最重要的Java EE最佳实践(4)

4. 按照规范来进行开发，而不是按照应用服务器来进行开发。

要将规范熟记于心，如果要背离规范，需经过慎密的考虑后才可以这样做。这 是因为当您背离规则的时候，您所做的事情往往并不是您应该做的事情。

当您要背离 Java EE 允许您做的事情的时候，这很容易让使您遭受不幸。我 们发现有一些开发人员钻研一些 Java EE 允许之外的东西，他们认为这样做可以 “稍微”改善 Java EE 的性能，而他们最终只会发现这样做会引起严重的性能问 题，或者在以后的移植（从一个厂商到另一个厂商，或者是更常见的从一个版本 到另一个版本）中会出现问题。实际上，这种移植问题是如此严重，以致 [Beaton] 将此原则称为移植工作的基本最佳实践。

现在有好几个地方如果不直接使用 Java EE 提供的方法肯定会产生问题。一 个常见的例子就是开发人员通过使用 JAAS 模块来替代 Java EE 安全性，而不是 使用内置的遵循规范的应用服务器机制来进行验证和授权。要注意不要脱离 Java EE 规范提供的验证机制。如果脱离了此规范，这将是系统存在安全漏洞以及厂商 兼容性问题的主要原因。类似地，要使用 Servlet 和 EJB 规范提供的授权机制 ，并且如果您要偏离这些规范的话，要确保使用规范定义的 API（例如 getCallerPrincipal()）作为实现的基础。通过这种方式，您将能够利用厂商提 供的强安全性基础设施，其中，业务要求需要支持复杂的授权规则。（有关授权 的更详细内容，请参见 [Ilechko]。）

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

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!