在传统的性能测试中，必须遵循一些基本原则，才能获得有意义、有用且可靠的数据。本文将介绍这些原则将如何有效应用于面向服务的体系结构（Service Oriented Architecture，SOA）解决方案，以及在SOA领域中收集有用性能数据所必须考虑的其他事项。

　　旧学派

　　某天，我的一位同事问我，关于对面向服务的体系结构（Services Oriented Architecture，SOA）解决方案的性能测试有什么建议。这让我陷入了沉思……性能测试是一门具有必须遵循的基本原则的科学，但从性能测试的角度而言，是否存在尚未针对SOA进行的任何特定事项？

　　首先让我们了解一下基础知识。

　　了解要测试的对象

　　对于任何性能测试，首先都要标识和编写有效的用例。标识用例的两个最好方法是：

　　·分析运行站点的访问日志，了解所出现的实际用例。

　　·让业务分析人员提供其预期应用程序将处理的用例。

　　无论采用哪种方法，由于性能测试的价值取决于所测试的用例，这里的主要目标是不要忽略任何用例。未测试的用例将最终导致在生产中出现问题。

　　例如，对于典型的电子商务站点，有四个（至少）基本用例：

　　·访问主页：始终会有针对访问站点的每个用户的登录页。

　　·浏览目录：访问登录页的有些用户将浏览目录，并查看目录中不同的物品。

　　·购物：浏览目录的有些用户会将一个或多个物品放入购物车。其中有些用户还会从其购物车删除物品。

　　·结帐：在购物车中放入物品的有些用户将购买这些物品。

　　用例百分比组合

　　标识了用例之后，接下来需要了解每个用例的频率。在电子商务示例中，您可能已经了解到：

　　100%的电子商务网站用户将访问登录页。

　　其中，约80-85%将浏览目录。

　　25%将在购物车中添加或删除物品。

　　2-3%将结帐，购买其购物车中的物品。

　　必须在测试中表示对应的用例混合。

　　构建测试用例

　　通过使用IBM Rational Performance Tester之类的负载测试工具，测试团队将获取所标识的用例，并构建用于测试每个用例的测试脚本。请记住，测试用例的有效性取决于作为其基础的用例。例如，由于您知道有些购物者将从其购物车删除物品，因此需要一个用例来测试在购物车中添加和删除物品的重要功能以及其对应用程序的影响。

　　负载测试和压力测试

　　有了测试用例和百分比组合，测试团队现在就可以执行脚本了。为了实现合理的测试结果，测试应该包括：

　　1.作为生产发布候选版本的应用程序版本。这并不一定意味着应用程序的这个特定版本将推广到生产环境中，而仅仅是生产候选版本而已。发布候选版本可以因为多个原因避免（或拒绝）投入生产环境，其中一个原因就是性能测试失败。通常，发布候选版本至少是已经进行了功能测试的可正常工作应用程序。

　　2.与生产环境类似的数据。对于电子商务站点，您必须拥有在生产环境中已有或将投入使用的目录版本。此外，必须对任何与隐私相关的用户相关数据（如电话号码、地址等）进行清理，在保持作为测试数据有效性的同时，不能将这些数据与任何特定的用户的真实身份进行关联（如将电话号码处理为1-222-555-1212）。

　　3.与生产环境类似的基础设施。很多组织都很难提供这一点。根据经验，至少要三个操作系统逻辑实例和类似防火墙、路由器、交换机等。

　　4.能够在操作系统的每个逻辑实例中提供足够的虚拟用户许可证，以提供与生产负载类似的负载。

　　测试团队可以使用按照准确的测试用例百分比组合开发的测试用例对环境进行负载和压力测试。应用程序监视和数据收集在负载测试和压力测试期间至关重要。在负载测试或压力测试出现问题时，非常适合使用IBM Tivoli Composite Application Manager（ITCAM）for SOA之类的工具进行应用程序监视和故障排除。

　　分析

　　收集了数据之后，必须由性能专家对其进行测试。此人负责以下事项：

　　·确定测试是否成功，收集的数据是否完整。需要重新运行不成功的测试。

　　·了解成功的测试是否是最优测试，或者是否需要对应用程序代码或环境配置进行更改。

　　·应用程序操作（如代码或配置更改）需要在分析完成之后进行。对更改进行了功能测试之后，可以再次对应用程序进行负载测试和压力测试，然后再次进行分析。

　　SOA场景

　　现在我们已经有了大量的性能测试基本知识，是否存在可能特定于SOA的任何测试场景呢？

　　高使用率服务

　　SOA环境趋向于拥有一组使用率可能比较高的核心服务（供外部服务使用者或跨企业使用者使用）。这些服务通常不仅需要具有高性能，而且还具有高可用性；这些服务通常对业务极为重要。

　　一个不错的推论是Facade层中的无状态会话Bean无状态会话Bean通常用于一些业务功能，并会供多个其他应用程序重用。虽然EJB组件或SOA服务的业务重要性可以保证在不同的运行时环境中具有更高的可用性，但此因素并不能从根本上改变这些组件的性能测试方式。无论组件对业务如何重要，都必须对每个组件执行性能测试，以了解其在生产环境中的工作情况。大多数生产环境采用了某种级别的共享，在这种情况下引入未经过良好测试的组件可能会存在很大风险，特别是组件可能会占用CUP时间或内存的情况下更是如此。

　　组合服务

　　组合服务是在后台调用一个或多个服务的服务。此场景与上面提到的无状态会话Bean Facade非常类似。Facade的传统性能测试尝试对Facade后台的每个服务进行逐个测试，以了解每个服务的行为方式以及为了获得最优吞吐性能需要进行哪些调整或应用程序代码更改。最后，当完成所有服务的个体测试后，Facade（或前端服务）本身经过了性能测试，并可能随后对Facade或某个后端服务进行调整。

　　对前端服务的后台的各个服务进行测试可能并不总是可行，因为服务可能使用不适合进行测试的接口，如异步消息传递接口。在这些情况下，性能测试通常通过前端Facade完成，或通过添加Servlet层来发起恰当的消息传递调用执行测试。这可能需要一些不会推广到生产环境中的额外代码或基础设施，这些代码或基础设施将严格用于性能测试目的。

　　总的说来，传统性能测试方法似乎仍然适用于基于SOA的解决方案，但可能有必要构建额外的应用程序和基础设施来支持性能测试工作。没有异步消息传递接口测试经验的组织可能不会认识到需要进行额外的工作来进行性能测试。不过，成功的生产环境的基本需求仍然与以前相同，这些需求对测试的全面化和经常化非常重要！