Challenges posed by testing Web 2.0 programs

Use GUI Recovery performance metrics to supplement WEB 2.0 performance testing

Learn how to use existing tools to better test end user experience with WEB 2.0 to help your organization solve challenges and improve the quality of your tests. Using the test tools tailored to the test service, you can optimize the use of WEB 2.0 technology and build a better business logic structure for your browser.

Challenges in WEB 2.0 testing

WEB 2.0 is a new and useful technique for building multiple client programs on the Internet. Depending on who is describing it, it can be a social network in terms of demand dynamic content or a range of other things, mashups.

From a test point of view, the main focus now is on the new technologies used, and how these new technologies change test scenarios. Web 2.0 technology translates Web programs into a sophisticated program logic structure for browsers (for example, clients) created using client technology, through Javascript,flex, Ajax,dojo, and other Web 2.0 technologies. Because most of the performance testing tools are optimized to determine the response time of the server, this creates a gap between functional testing and performance testing of WEB 2.0 programs that use these new technologies.

One of the consequences of this pattern shift is the increased reliance on testing from end clients, especially when navigating in a graphical user interface (GUI) in a browser. This is true for functional validation of Java scripting operations because of the response time for the test program. There is no API interface layer.

Previously, the time to deliver the GUI in a browser was considered to be 0 compared to the server processing time. It is wrong to think so now. User experience can be defined as "When can I click on something again?" "When performance testing relies on server response time to predict the user experience in WEB 2.0 programs, one of the common problems is," what program is going on for such a long time? "In fact, people can no longer assume that the server response time is sufficient to predict the user experience of response time."

These issues can also have an impact on the team that provides the sizing guide. Determine the server configuration to ensure that sufficient response time for the expected server load is well documented. But how does a team make deployment recommendations when the server is no longer the main bottleneck? In this way, the browser performance beyond your control has become more important. But people still don't notice the problem of program construction.

What are testers going to do? WEB 2.0 Performance testing now needs to consider GUI delivery issues and some of the work that performance tools do not need to do.

The solution to this problem:

Design a meaningful use case to validate the GUI response time.

Perform a performance test of a performance tool that executes a use case.

Create GUI automation for the same use cases using timers (later with more information).

Run GUI Automation in Single-user mode (there is no load on the system) to create a baseline that is responsible for the tool load.

Use performance automation to load the server and rerun the GUI Automation operation. This step may be done in the context of the growing workload and stress scenarios.