有了测试用例和百分比组合，测试团队现在就可以执行脚本了。为了实现合理的测试结果，测试应该包括：
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的解决方案，但可能有必要构建额外的应用程序和基础设施来支持性能测试工作。没有异步消息传递接口测试经验的组织可能不会认识到需要进行额外的工作来进行性能测试。不过，成功的生产环境的基本需求仍然与以前相同，这些需求对测试的全面化和经常化非常重要！
文章来源于领测软件测试网 https://www.ltesting.net/
