abhishekh_07
Joined: 31 Aug 2007 Posts: 13
|
Posted: Sun Sep 02, 2007 6:01 pm Post subject: WEBSITE DYNAMIC VALIDATION |
|
|
Confirming validity of what is tested is the key to assuring WebSite quality -- the most difficult challenge of all. Here are four key areas where test automation will have a significant impact.
Operational Testing: Individual test steps may involve a variety of checks on individual pages in the WebSite:
*Page Consistency : Is the entire page identical with a prior version? Are key parts of the text the same or different?
*Table, Form Consistency. Are all of the parts of a table or form present? Correctly laid out? Can you confirm that selected texts are in the "right place".
*Page Relationships. Are all of the links on a page the same as they were before? Are there new or missing links? Are there any broken links?
*Performance Consistency, Response Times. Is the response time for a user action the same as it was (within a range)?
Test Suites: Typically you may have dozens or hundreds (or thousands?) of tests, and you may wish to run tests in a variety of modes:
Unattended Testing. Individual and/or groups of tests should be executable singly or in parallel from one or many workstations.
*Background Testing. Tests should be executable from multiple browsers running "in the background" on an appropriately equipped workstation.
*Distributed Testing. Independent parts of a test suite should be executable from separate workstations without conflict.
*Performance Testing. Timing in performance tests should be resolved to the millisecond; this gives a strong basis for averaging data.
*Random Testing. There should be a capability for randomizing certain parts of tests.
Error Recovery:While browser failure due to user inputs is rare, test suites should have the capability of resynchronizing after an error.
Content Validation: Apart from how a WebSite responds dynamically, the content should be checkable either exactly or approximately. Here are some ways that content validation could be accomplished:
*Structural. All of the links and anchors should match with prior "baseline" data. Images should be characterizable by byte-count and/or file type or other file properties.
*Checkpoints, Exact Reproduction. One or more text elements -- or even all text elements -- in a page should be markable as "required to match".
*Gross Statistics. Page statistics (e.g. line, word, byte-count, checksum, etc.).
*Selected Images/Fragments. The tester should have the option to rubber band sections of an image and require that the selection image match later during a subsequent rendition of it. This ought to be possible for several images or image fragments.
Load Simulation:Load analysis needs to proceed by having a special purpose browser act like a human user. This assures that the performance checking experiment indicates true performance -- not performance on simulated but unrealistic conditions.
Sessions should be recorded live or edited from live recordings to assure faithful timing. There should be adjustable speed up and slow down ratios and intervals.
Load generation should proceed from:
*Single Browser Sessions. One session played on a browser with one or multiple responses. Timing data should be put in a file for separate analysis.
*Multiple Independent Browser Sessions. Multiple sessions played on multiple browsers with one or multiple responses. Timing data should be put in a file for separate analysis. Multivariate statistical methods may be needed for a complex but general performance model. |
|