SOA性能测试
项目的非功能需求（如性能、可伸缩性、可靠性、高可用性、故障恢复）对其架构有重大的影响。但对这些需求的测试的创建往往留给项目的结束。
 
  SOA的使用导致开放架构，有助于各种类型的性能测试。
 
  测试必须在系统开发的早期进行，越早越好。从测试获得的结果可能会需要对配置进行调整，对系统架构进行修改来消除瓶颈，或添加硬件资源。
 
  每个测试目录都有其特殊的目的。计划测试时需要有清晰地陈述的目标和成功的准则。测试必须尽早在项目生命周期开始，各种类型的测试可以平行的执行，在进入下一个测试之前完成某个测试任务是测试误解。
 
  (1)目标基础结构测试
 
  目标基础结构测试是系统中每一层/每个部件单独的测试。
 
  方法:
 
  SOA的使用意味着每个部件可能存在一个WEB服务接口。这就为了测试的目的为将各种部件互相隔离提供了出的手段。在系统作为整体测试之前，可以执行每种测试（性能、压力、负载等）。
 
  测试工具可以直接面对低层服务，使用它们暴露出的WEB服务接口。高层部件（如BPEL脚本）可以与其依赖的服务隔离开来，方法是这些服务的Stub版本（只实现了足够的逻辑来使得可以进行测试）。
 
  目的:
 
  这些测试的目的是去识别单个的部件（或许为称为瓶颈，限制系统的整体能力），能够在给定的性能等级上递交。
 
  结果说明:
 
  这些单独测试的结果可以对系统的整体性能进行预测。此项测试可以在项目的很早期进行，甚至在系统集成之前。这就允许在最早的可能时间采用纠正行动。
 
  单个部件的吞吐量将限制系统的整体吞吐量。如果一个到达顶层服务的单一请求将导致对单独部件的多个请求，在考虑整体的吞吐量需求时就必须考虑这一点。
 
  整个系统的响应时间可以基于单个部件的响应时间进行预测。
 
  (2)性能测试
 
  性能测试识别了低负荷时系统的端到端时间。
 
  方法:
 
  性能测试必须在类似生产环境中测试，构建尽可能接近生产环境。
 
  目的:
 
  测试的目的是设置给定配置下的系统最可能的响应时间。
 
  结果说明:
 
  性能测试必须去验证整个系统性能的预测（作为性能测试的结果）。
 
  (3)压力测试
 
  压力测试决定系统失败的负载，并决定系统是如何失败的。
 
  方法:
 
  通过逐步增加负载（从用于性能测试的较低负载到失败开始出现的点）来测试系统。
 
  目的:
 
  这些测试的目的是识别给定配置下系统的最大可能的负载。这个可以与需求进行比较。
 
  有一点很重要就是去知道这样的负载是否会导致灾难性系统故障，或一切开始变得很慢。
 
  结果解释:
 
  识别故障开始发生的哪个点并不意味着系统使得测试失败了；测试的目的是去识别这个点。然而，它必须发生在大于所需系统负载的那个点。如果不是这样，就必须采取纠正行动，比如所用硬件的规格。
 
  压力测试也提供了机会去扼杀系统，这样所开发的系统继续高效的运行，并适当的确保稳定性。通过设置消息从输入队列读取的速度，并发进入的HTTP请求数，服务器内的使用的线程池，可以实现扼杀。
 
  (4)负荷测试
 
  负荷测试是在预期生产负荷下端到端的性能测试。
 
  方法:
 
  在预期的负荷之下测试系统，并测量响应时间。预期负荷的精确定义是此类测试的必要条件。
 
  目的:
 
  可以使用负荷测试来确定系统在负荷下满足性能期待的可能性。也可以用于识别最小的硬件配置需求。
 
  负荷测试也提供了进行"后台测试"的机会。这是用户接受测试的一种形式，这是在系统处于期待负荷下的执行的。
 
  结果说明:
 
  核实响应时间仍然是可接受的。它们是如何变化的？比如，平均响应时间是可接受的，但如果响应时间变化太大，这是不可接受的。
 
  执行负荷测试作为目标基础设施测试的一部分的能力对于识别为什么响应时间是不可接受的是很重要的因素。
 
  (5)容量测试
 
  容量测试测量了系统的吞吐量。
 
  方法:
 
  识别直接影响系统容量的事情。比如，增加消息大小比增加消息的数量对容量有明显的影响。
 
  考虑系统的数据量将增加的各个方面，并为它们设计特殊的测试。比如，允许数据库表大小增长，或消息队列的规模增加。如果完成一次事务能引起资源的释放，就要测试事务慢或停止的地方。
 
  目的:
 
  使用这些测试来确保在部署生命周期期间系统满足性能需求。也可以使用这些测试来识别可选的过程，如数据库的维护。
 
  可以使用可选的过程来减轻影响，这些测试可以识别合适的设置来报警。
 
  结果说明:
 
  可以使用容量测试结果和压力测试结果来识别系统适当的节流。
 
  可以期待系统的性能来随系统负荷的变化而波动。这些波动在可接受的限制范围内，或用可选的过程来控制这些波动。否则，就要采取步骤来最小化变动。
 
  (6)故障排除测试
 
  故障排除测试验证当系统处于负荷时的冗余机制。
 
  方法:
 
  当系统涉及到集而不是单一服务器，在期待的负荷下测试系统，然后移走一个服务器。
 
  也要执行故障恢复测试来验证从集中移走一个服务器能够成功地添加回来。
 
  目的:
 
  这些测试确保故障排除机制得以工作，剩下的部件能够处理一旦移走部件，外露给它们的负荷。
 
  结果说明:
 
  使用故障排除来确保即使在单个部件出现了故障时系统仍然可用。对于一个真正冗余的系统，每一样都必须有两样。也要考虑故障之间的平均时间，导致故障发生之前的部件的替换。通常经济问题阻止了这点，只有在故障被认为是风险的地方提供冗余。此时，提供清晰的陈述在哪些地方是没有冗余的，以及在没有冗余的部件发生故障时遵循的过程。
 
  故障排除确保在部件故障时系统继续可用。
 
  (7)渗入测试
 
  渗入测试验证在高负荷下还能运行一段时间。
 
  方法:
 
  设置一个负荷测试，负荷量比期待的负荷要大，但比压力测试识别到的故障点低。在这样的负荷下运行一段时间。需要这样的测试的时间长度是计划中的重要因素。所需的渗入时间必须在早期达成一致并写入进度计划。
 
  在进行渗入测试时，有必要实现可选的过程（在容量测试是识别的）。
 
  目的:
 
  这些测试的目的是证实系统可以运行一段延迟的时间。这确保了一旦单个请求处理完成，资源释放得以重用。
 
  结果说明:
 
  首要的目的是确保系统持续运行一段定义好的时间。另外，系统的性能没有降低。可以监控诸如内存这样的资源来确保利用率维持不变。
soa 
  (8)网络灵敏度测试
 
  网络灵敏度测试聚焦在广域网（WAN）限制和网络活动。这点在SOA中特别重要，因为系统跨越Internet分布。
 
  方法:
 
  网络灵敏度测试是对负荷测试的变化，更大或更地理上分散的网络，或许是比开发实验室更"真实"的场景。
 
  目的:
 
  这些测试的目的是确保系统（很可能是在单一LAN上开发和测试的）在WAN上行为一样。
 
  结果说明:
 
  WAN或许会引起响应时间比LAN变化更大。系统的吞吐量或许更小。或许更容易发生间歇连接错误。由于性能特征是不同的，测试必须确保性能在可接受的范围内。
 
  结论
 
  需要对系统进行仔细的计划、分析和设计来递交非功能需求。最后系统的性能必须通过一系列的测试来优化和验证。
 
  必须在早期就开始测试，并与系统本身平行开发测试。测试结果的定位需要对系统重分解，所以需要将可能性写入项目计划。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。