First of all, this is a difficult problem. Selenium’s documentation attempts to provide a way to categorize tests:
What parts of your application should you test? That depends on aspects of your project: user expectations, time allowed for the project, priorities set by the project manager, and so on. Once the project boundaries are defined though, you, the tester, will certainly make many decisions on what to test.
We have created a few terms here for the purpose of categorizing the types of test you may perform on your web application. These terms are by no means standard, although the concepts we present here are typical for web-application testing.
Testing Static Content
The simplest type of test, a content test, is a simple test for the existence of a static, non-changing UI element. For instance:
Does each page have its expected page title? This can be used to verify your test found an expected page after following a link.
Does the application’s home page contain an image expected to be at the top of the page?
Does each page begin with heading text using the <h1> tag? In addition, does each page have the correct text within that header?
You may or may not need content tests. If your page content is not likely to be affected, then it may be more efficient to test page content manually. If, for example, your application involves files being moved to different locations, content tests may prove valuable.
A frequent source of errors for websites is broken links or missing pages behind links. Testing involves clicking each link and verifying the expected page. If static links are infrequently changed then manual testing may be sufficient. However if your web designers frequently alter links, or if files are occasionally relocated, link tests should be automated.
These would be tests of a specific function within your application, requiring some type of user input, and returning some type of results. Often a function test will involve multiple pages with a form-based input page containing a collection of input fields, Submit and Cancel operations, and one or more response pages. User input can be via text-input fields, check boxes, drop-down lists, or any other browser-supported input.
Function tests are often the most complex tests you’ll automate, but are usually the most important. Typical tests can be for login, registration to the site, user account operations, account settings changes, complex data retrieval operations, among others. Function tests typically mirror the user-scenarios used to specify the features and design or your application.
Testing Dynamic Elements
Often a web page element has a unique identifier used to uniquely locate that element within the page. Usually, these are implemented using the HTML tag’s "id" attribute or its "name" attribute. These names can be a static, i.e unchanging, string constant. They can also be dynamically generated values that vary each instance of the page. For example, some web servers might name a displayed document doc3861 one instance of a page, and "doc6148" on a different instance of the page depending on what "document" the user was retrieving. A test script verifying that a document exists may not have a consistent identifier to use for locating that document. Often, dynamic elements with varying identifiers are on some type of result page based on a user action. This, though, certainly depends on the function of the web application.
Here’s an example.
<input type="checkbox" value="true" id="addForm:_ID74:_ID75:0:_ID79:0: checkBox"/>
This shows an HTML tag for a checkbox. Its ID (addForm:_ID74:_ID75:0:_ID79:0:checkBox) is a dynamically generated value. The next time the same page is opened, it will likely be a different value.
Ajax is a technology which supports dynamically changing user interface elements which can dynamically change without the browser having to reload the page, such as animation, RSS feeds, and real-time data updates among others. There are countless ways Ajax can be used to update elements on a web page. But, the easy way to think of this is that in Ajax-driven applications, data can be retrieved from the application server and then displayed on the page without reloading the entire page. Only a portion of the page, or strictly the element itself is reloaded.