Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Performance testing SOA is quite a buzz, but in reality it's easier than performance testing most applications, because the simple answer is that you just don't performance test the SOA part unless your team wrote it.
If you are performance testing an application that simply uses a service, all you can do is stub it out (or use the "secret test data" from the service provider), performance test "around it," then add the performance numbers from the service-level agreement (SLA) into your results. If that results in unacceptable performance numbers, you have four choices:
- Renegotiate the SLA (which typically means paying the provider more).
- Get a new provider.
- Tune the part that your team build enough to make up for it.
- Build a replacement service in-house.
|
 |
If it so happens that your company actually built the service, that team should be doing performance testing at a component level -- possibly using one of the many tools currently on the market that support SOA protocols. Even if this is the case, assuming you're in charge of performance testing the system end-to-end, treat the service just like any other component you're used to testing, such as a database or application server.
Hope that helps!
This was first published in June 2008