Sign up in 30 seconds.
No credit card.
No risk.
No download.
PushToTest Review
- Tags:
PushToTest is a tool for performing load testing. The project is open source and written mostly in Java from what I noticed. The source is available online at cvs.pushtotest.com/var/cvsroot. However, the license stipulates that the free binary and source are only to be used with a max of 10 virtual users, developers requiring more users must pay some sort of licensing fee to PushToTest. PushToTest provides a modified version of TestGen4Web with its source. This is extremely easy to use and most of TestGen4Web's features are documented in that service's homepage.
Capabilities:
Protocol Handlers
HTTP
HTTPS
SOAP
REST
WS-*
XML-RPC
SMTP
POP3
IMAP
Build tests in a variety of languages
Java
.NET
Jython
Groovy
PHP
Ruby
and many others
Testing:
Functional
Load
Monitoring
User GUI:
I found the user GUI for this testing framework to be the easiest and simplest of all. Getting a test up and running took no time at all. A user simply creates the test using TestGen4Web and imports it into the TestMaker. The XML style scripts are easy readable and writable. Furthermore, the XML scripts can call a number of different types of tests written in the varieties of languages as given above. The variety offered by this test framework makes the source difficult to read with the variety of languages involved.
Once a test has completed, a number of useful reports and graphs can be automatically generated. TestMaker will attempt to create legible results from the data.
Distributed Load Testing:
The TestMaker simply distributes the resources and XML scripts to the various nodes pointed at by IP in the XML. Each node will run a copy of the script. The user documentation for PushToTest recommends 200 or more virtual users per node on an Intel Pentium 3.0 GHz Linux System. Also, PushToTest supports service monitoring of the target system. The service monitor will relay CPU, memory, and network I/O as the test is run.
Comments
Christian, you missed the two
Christian, you missed the two of the greatest features: the ability to reuse a test script for functional, performance or production monitor and the ability to run multiple scripts in a test, regardless of their protocol (you can run a soapui, html and flash scripts in the same test scenario)
So I can setup a scenario that gets data from a soap interface, us that data for a HTTP/S web test, interact with a flash/flex interface (native AMF support) and confirm the data in a sql database all in the same scenario.
And I can run this as a functional test, then a performance test then deploy it to provide performance over time on my production systems.
Now if the back end changes, I update a test asset (script) and all my other tests that reference that asset are updated - one change all fixed.