Testing functionality, performance of mobile Web applications
John Overbaugh
Rating: -3.00- (out of 5)
|
I use a four-part strategy in testing mobile Web applications. I look at functionality, mobile layout, device and browser compatibility and, finally, carrier support. In this article, we will examine the first of these strategies, functional testing.
Before you even get to the point of testing functionality, you've got to do some legwork in testing mobile Web applications for usability and context. In this article, we'll assume your feedback on usability and context was taken, and the new mobile site is well-designed.
Testing functionality
The good news about testing functionality is that you can use most of the standard tools that you use when testing full-fidelity Web sites. In this phase of testing, which is focused primarily on server-side testing, you're going to be validating a few things: content, standards compliance, and server functionality.
First of all, y...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
ou'll be validating content. No special tools are required in this phase, because you're focusing on the server-side. Firefox, IE, or your favorite browser is essentially all you will need for content retrieval, page element and presentation, and server-side processing testing.
Many sites, mobile and full-fidelity, use content management systems to store and present content. If this is the case for your site, you'll be testing the retrieval of content during the functional test phase. If you are building your site on top of a content management system, make sure you equivalence-class partition your testing. In other words, make sure you include in your testing one or two examples of each content object type you expect to be serving up on your site. Your goal is to simply make sure each content type is served up when an http request is made.
If your site is not making use of a content management system, this is still the best time to test site content. Using a desktop browser gives you access to your entire desktop and it sure makes reading easier!
A key component of functionality testing is ensuring your site conforms to XHTML standards. Most desktop browsers are very forgiving of mal-formatted HTML. Mobile browsers, on the other hand, can be super-sensitive to poorly formatted XHTML; XHTML is a superset of markup language, and HTML is a subset of this superset. Firefox's Web developer toolbar includes functionality to validate XHTML; run this on every page or an instance of every template you will be serving up on your mobile site.
Finally, in this phase you will want to test any server-side business logic. Again, doing this testing from your desktop makes it easier to complete your testing. Specs, requirements and test cases are probably all available to you via your desktop machine. In addition, you will find it faster and easier to interact with the site.
The functional testing phase also provides you the easiest opportunity to develop and run automated regression tests. There are a few harnesses available on mobile device platforms, but by far the easiest way to write and run automated web application tests is on the desktop. You can easily cover your functional testing in this phase.
Performance testing
Finally, your functional testing phase is the time to run performance tests. I categorize performance testing into four areas: response time, load, MTTF (mean time to failure) and performance tuning. Here's a breakdown of what I'm looking for in each area.
- Response time: This is the measure of time needed for a response to complete -- from request to last response -- at both normal and peak loads for a Web site. This is generally the user-perceived time, and in a Web application it should generally include the time to load html pages, css and jsp, as well as images.
- Load: This is the measure of response time as load is increased from 0 to a "very large load." Generally the upper load limit will be a multiplication factor of the highest expected peak load. The key metric in this test is to watch how the response time increases as load increases. Are response time increases linear, meanging that as the load level increases, the response time increases proportionally? Or, are response times logarithmic , so that as the load level increases, the response time increases more.
- Mean time to failure: This is how engineers generally predict the required maintenance cycle for an application. By estimating the number of transactions per minute, hour, or day for the application, you can extrapolate the number of transactions for a week or a month. The application should then be brought to a high, but stable, load rate. I generally shoot for 85% of my first bottleneck -- CPU, RAM, disk I/O, etc. The site is then allowed to run indefinitely, and the total transactions are recorded. From that number, you can predict how long the site will run given normal conditions. At Microsoft, we generally set a requirement of 30 days of simulated load; at 85% (or 90% to 95% on the server products I worked on), we could generally perform this simulation in about a week.
- Performance tuning: The final effort is to tune the application. The site is placed under increasing load levels until a bottleneck is reached (site becomes non-responsive due to a downstream dependency). That bottleneck should then be fixed, either by fixing non-performant code (preferable) or by scaling up or out.
For more information about this area, check out the CodePlex.com tutorial on Performance Testing Guide for Web Applications.
Regardless of the device used to browse your site, you're going to need to do performance testing. Use the standard tools you leverage to-date, and hold your mobile site to the same standards you hold your full-fidelity site.
About the author: John Overbaugh has 15 years of experience in product and project IT, focusing on quality and defect prevention, working with Microsoft Corp. and other companies.
|
|
|
|
|
|
