Automation Testing - Best Practice（书写规范）

Coding Standards

Coding Standards are suggestions that will help us to write automation Scripts code using any language. Naming conventions for creating automation Script, objects, variables and procedures. Commenting standard in the scripting, Text formatting and align guidelines for the script.

Naming Conventions:

Naming Conventions should be followed at all levels of the project for e.g. Variables, Constants, Objects

Standards of Variable Naming

For easy readability purpose use the prefixes like below examples, along with descriptive names for variables in Automation Script code.

Example:

String – sName
Object – oObjectname
Integer,Byte,Long – nNumber
Array – arrListitems
Boolean – bYes
Single,Double – fPrice
DateTime – dToday
Error – errResponse
Currency – cRupees

Standards of Constant Naming

Constant names should be in uppercase with underscores (_) between the words.

Example: USER_LIST_MAX, NEW_LINE

Object Naming Standards

For the objects created in the Automation script, use prefix “o” (small letter o).

Example:

ADODB.Connection – oConn
ADODB.Recordset – oRset
Scripting.xmlobject – oXmlobj
Scipting.FileSystemObject – oFsobj
Scipting.TextStream – oTxt
Scripting.Dictionary – oDic
Excel.Application – oXls

Reusability:

Abstraction to be followed for Code Reuse at all possible levels – function library, config file, POM

POM (Page Object Model) based approach

POM approach is to create a separate class file which would find web elements, fill them or verify them. This class can be reused in all the scripts using that element. In future if there is change in the web element, we need to make change in just 1 class file and not 10 different scripts.
This Page class will find the WebElements of that web page and also contains Page methods which perform operations on those WebElements
A lot more expressive as we look at the code. With well named methods, we create a higher level of abstraction that is easier to read and understand
If the UI changes (an id of a field), we go to our one method, update the id and we are good to go

For frequent changes we use properties/Excel sheet/XML file

We can use excel sheet for storing our test data. It is easy to maintain the data in excel and also easy to modify the test data as per the business requirements.

Use custom exception which can be easily understood

Custom exception helps to clearly understand the error. Please find below some key points for using custom exceptions:

Add situation specific data to an exception. Ideally this data would help another developer to track down the source of the error.
Provides a type safe mechanism for a developer to detect an error condition.
No existing exception adequately described my problem.

Maintainability and Extensibility:

Use of Interface based programming to achieve the maintenance of existing scripts and extension of new ones

Portability:

Code often has to run on all the platforms.

No hard coding to be used unless absolutely necessary

Locator Identification Techniques

If you’ve come here looking for the perfect, unbreakable locator, then I’m afraid to tell you that there is no perfect locator. That HTML changes and locators become incompatible are realities of writing automated UI tests. There is no other option than getting used to update them as the development teams experiment with design, streamline HTML and fix bugs as long as the application is evolving.

A good element locator:

is as small as possible to indicate the GUI element
will continue working when GUI elements around the GUI element change
will continue working when properties of the GUI element change

A failing locator is a good thing so don’t be afraid of it. The trusty NoSuchElementException, rather than an assertion failure, is often your first sign that there is a regression in your software.

ID Locator

In a perfect world, each web element has an html 'id'. Finding an element by html id is the most precise way to define an element, since the id is usually the property that’s less likely to change. By W3C standards, it should be unique in the page meaning you will never have a problem with finding more than one element matching the locator.

The ID is also independent of the element type and location in the tree and thus if the developer moves the element or changes its type WebDriver can still locate it.

IDs are often also used in the web page’s JavaScript so a developer will avoid changing an element’s ID to avoid having to change his JavaScript. That’s great for us testers!

If you have flexible developers or even an eye for the app source code you can always try and get extra IDs added into the code. A good use case will definitely convince even the developers to add the ids to the elements. However, sometimes adding IDs everywhere is impractical or not viable so we need to use CSS or Xpath locators.

CSS and Xpath locators

CSS and Xpath locators are conceptually very similar.

These types of locators with combinations of tag name, descendant elements, CSS class or element attribute makes the matching pattern strict or loose, strict meaning that small HTML changes will break the pattern and lose meaning that it might match more than one HTML element.

When writing a CSS or Xpath locator it’s all about finding the balance between strict and loose; durable enough to work with HTML changes and strict enough to fail when the app fails.

Find an anchoring element

A good way to start a CSS or Xpath locator is to start with an element that you know is not likely to change much and use it as an ‘anchor’ in your locator. It may have an ID or stable location but not be the element you need to locate but is a reliable position to search from. Your anchoring element can be above or below the current element in the HTML tree, but most often it’s above.

<div id=”main-section”>

    <p>Introduction</p>

    <ul>

      <li> Option 1</li>

    </ul>

</div>

In this example the <li> element that we want to locate does not have an ID or a CSS class making it difficult to locate. There is also the chance there is more than one list in the HTML. The div with the id “main-section” makes a good anchoring element from which to find the <li> element. It narrows down the HTML the locator is searching in.

When to use ‘index’ locators like nth-child() and [x]

nth-child(), first-child, [1] and such index-type locators should only be used if you are using it against a list itself. In this case the test should explicitly know it wants to pick an item at that index from the list, for example validating the first item of search results. Using an index-type locator to locate an element that is not index-placed is likely to cause you problems when the order of the elements is changed and thus should be avoided!

<menu>

  <button>Option 1</button>

  <button>Option 2</button>

  <button>Option 3</button>

</menu>

//menu/button[1] is a suitable locator only when you know you want to interact with the first menu item regardless of how the list of buttons is sorted. The order of the buttons may change and cause your test to fail. Would this be a legitimate failure or one that requires you to re-write the locator?

Depending upon the objective of your test a non-index based locator like //menu/*[text()=’Option 1’] might be more suitable. <menu> is the ideal anchoring element.

CSS class names often tell their purpose

Assuming that the Front end designers will often give CSS classes, the names that represent their purpose, we can take advantage of the situation. We can choose locators that are dependent upon the functionality rather than the styling because styling often changes.

<footer class="form-footer buttons">

  <div class="column-1">

      <a class="alt button cancel" href="#">Cancel</a>

  </div>

  <div class="column-2">

      <a class="alt button ok" href="#">Accept</a>

  </div>

</footer>

In this example ignore the class “column-1” and “column-2”. They refer to the layout and thus might be susceptible to changes if the development team decide to adjust the design. It will be more reliable to target the button directly. Although “button.ok” would be quite a ‘loose’ locator there could be more than one on the page. You can use the footer as your anchoring element, making “footer .ok” a good locator in this example.

Spotting future fragility

By observing the HTML you can spot potential future fragility. In the previous example, 3 more things are intentionally left out of the locator: the <a>’s tag name, the <a>’s content text and any direct descendants ( > ) between footer and a. In the HTML it looks like the dev team have already changed the text label and the tag from “ok” and “button” respectively. The class, text content and tag names are all mismatched!

If the dev team are indecisive or experimenting with UX and performance improvements, these might still change again so we will err on a slightly “looser” locator that will tolerate some changes in the HTML.

Direct descendents

CSS example: div > div > ul > li > span

Xpath example: //div/div/ul/li/span

A direct descendent refers to the parent to child relationship of HTML elements. A good example is the first <li> element inside a <ul>.

A long chain of direct descendants like in the locator example above might help you find an element where there are no classes or IDs but it is sure to be unreliable in the long term. A large block of content without IDs or classes is likely to be very dynamic too and probably move around and change HTML structure often. It only takes one element in the chain to change for your locator to come tumbling down.

If you absolutely must use direct descendants in your locators then try to only use a maximum of one in each locator.

Adjust it for purpose

<section id=”snippet”>

    <div>Blurb</div>

</section>

Only use as much of a locator you need. Less is more! If you are only capturing text then using a locator like “#snippet div” is unnecessary. WebDriver will return the same text content for the locator ‘#snippet and ‘#snippet > div’ but the latter locator would break if the div element were changed to a <p> or <span>.

Locating on element attributes

...

Tag name, link text, name locating strategies

...

CSS and Xpath Axes

An axis defines a node-set relative to the current node.

Axis Name	Result
Axis Name	Result
ancestor	Selects all ancestors (parent, grandparent, etc.) of the current node
ancestor-or-self	Selects all ancestors (parent, grandparent, etc.) of the current node and the current node itself
attribute	Selects all attributes of the current node
child	Selects all children of the current node
descendant	Selects all descendants (children, grandchildren, etc.) of the current node
descendant-or-self	Selects all descendants (children, grandchildren, etc.) of the current node and the current node itself
following	Selects everything in the document after the closing tag of the current node
following-sibling	Selects all siblings after the current node
namespace	Selects all namespace nodes of the current node
parent	Selects the parent of the current node
preceding	Selects all nodes that appear before the current node in the document, except ancestors, attribute nodes and namespace nodes
preceding-sibling	Selects all siblings before the current node
self	Selects the current node