The state of the art in automating usability evaluation of user interfaces
ACM Computing Surveys (CSUR)
Observations and lessons learned from automated testing
Proceedings of the 27th international conference on Software engineering
Selective capture and replay of program executions
WODA '05 Proceedings of the third international workshop on Dynamic analysis
Automation of GUI testing using a model-driven approach
Proceedings of the 2006 international workshop on Automation of software test
Test automation for hybrid systems
Proceedings of the 3rd international workshop on Software quality assurance
DejaView: a personal virtual computer recorder
Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles
Maintaining and evolving GUI-directed test scripts
ICSE '09 Proceedings of the 31st International Conference on Software Engineering
Hi-index | 0.00 |
Scarcity of commercially available testing tools that could support all native or application specific message formats as well as those that cater to non GUI or non web based backend applications leads to creating your own customized traffic generators or scripts. Also the test environment setup may differ from one system to another -- some may use simulators or mocks to stub out complex software, others may just be a scaled down (in terms of number of servers) replica of the production environment. So what are the factors that need to be considered when creating scripts that can be used for native request formats and for non GUI or web based applications? How do we design a script that is easy to maintain and extend when new test scenarios are added to accurately assess the performance of an application? This paper provides (1) the general design principles for a test script that can be used to generate traffic for any request format as well as (2) specific factors to keep in mind when creating a script that will work in a test environment that uses a mock. In addition to this the core activities of testing include not only traffic generation but also setting up the environment, verifying that both the hardware and software configurations are accurate prior to sending traffic and creating a report at the end of the test. Therefore the test script needs to be part of a complete harness that accomplishes these tasks. The paper will address the (3) design and properties of such a harness. It provides a simple framework that can be easily used to complete an end to end testing process -pre test, traffic generation and post test activities.