Flag Product

Web services programming tips and tricks: Stress testing Web services

Add to my list

Send to friend

Compare prices

Shop for it: (added from 1 site)

Buy itibm.com

See more products from this brand »

Added by 1 people

cabeleira added to Programming

0 Hearts

Description:

Test systems that attempt to stress a Web service need to be designed to exercise code in particular ways. These styles go beyond functional verification to see if a Web service not only does what it is supposed to, but also... See more » Test systems that attempt to stress a Web service need to be designed to exercise code in particular ways. These styles go beyond functional verification to see if a Web service not only does what it is supposed to, but also continues to perform as it should when certain stressful conditions are applied. There are four basic conditions which stress tests must apply to a Web service. Many established stress systems apply these conditions. Effective stress testing systems apply these key conditions: * Repetition: Probably the most obvious and easy to understand stress condition is test repetition. In other words, test repetition means performing a particular operation or function over and over, such as repeatedly calling a Web service. A functional verification test can be designed to see if an operation either works or does not work. A stress test will determine if an operation works and continues to work every time it is carried out. This is essential in concluding whether a product is fit to be used in a production situation. A customer will typically use a product repeatedly, and therefore stress testing should find the code defects before a customer finds them. Many naive stress systems implement only this condition, but simply extending a functional verification test to be repeated many times does not constitute an effective stress test. When used in combination with the following principles, repetition can uncover obscure code defects. * Concurrency: Concurrency is the act of performing several operations simultaneously. In other words, performing several tests at the same time, for example calling a number of Web services on the same server simultaneously. This principle may not apply to all products (such as stateless services), but the majority of software has some element of concurrent or multi-threaded behavior, which can only be tested by executing multiple instances of the code. A functional or unit test will rarely incorporate any concurrent design. A stress system must go beyond the functional tests to exercise multiple code paths at the same time. How this is done depends on the specific product. For example, a Web service stress test would need to simulate multiple clients at once. A Web service (or any multi-threaded code) will typically access some shared data amongst the thread instances. The complication that is added by this extra dimension of programming often means that code has many defects attributed to the concurrency. Since introducing concurrency means that code in a thread might be interrupted with code from other threads, defects are uncovered that are only found when a set of instructions are executed in a particular order (such as with a particular timing condition). By combining with the principle of repetition, you can cover many code paths and timing conditions. * Magnitude: Another condition that stress systems should apply to their products concerns the amount of load they apply in any single operation. A stress test can repeatedly carry out an operation, but that operation should also strain the product by itself. For example, if you have a Web service that allows a client to enter a message, you could incorporate high usage into a single operation by simulating a client that enters a huge message. In other words, you increase the magnitude of the operation. This magnitude is always application specific, but can be identified by looking for values in the product that can be measured and modified by a user - for example, size of data, length of delay, amount of funds transferred, speed of input, variety of input, etc. On its own, a single strenuous operation might not find a code defect (or might only find a functional defect), but when combined with the other stress principles, you increase the chances of finding a problem. * Random Variation: Finally, no stress system would be complete without an element of randomness. If you randomly use the countless number of variables that the previous stress principles introduce, you are able to cover many different code paths each time a test See less »

Tags:

stress test, web services

Flag Comments

Comments (1)

Try Dotcom-monitor it is cheap and smart

Add a Comment:

Not a Kaboodler? Join Now, It's Free!

Email:

Screen Name:

Password:

Birthday:

Security Check
(Reload)

Enter Both Words

I have read and agree to the Terms of Service

Remember me on this computer.

Kaboodle will send you a newsletter and updates from your friends. You can unsubscribe at any time. Kaboodle does not sell or share your email address or personal information with anyone.

Cancel Already a Kaboodler? Sign in

Web services programming tips and tricks: Stress testing Web services

Comments (1)

Add a Comment:

Thanks for Hearting!

Not a Kaboodler? Join Now, It's Free!

Sign in to Kaboodle