The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates.

Maximo Test Automation

The Maximo Test Automation Framework is a Java framework based on the Rational Functional Tester (RFT) API. It is used to create automated functional tests against Maximo-based products. Using RFT, we are able to dynamically find and use objects in Maximo.

This framework is based on a common architecture created by the IBM Quality Software Engineering group and it consists of four tiers:

  • “Appobject” classes that logically group GUI elements together by application. These classes consist of discrete, granular private object maps that contain a small number of related GUI elements, along with routines that provide access to these elements.
  • “Apptask” tasks or methods that execute commonly-travelled paths through the GUI.
  • Test cases that invoke the tasks, verify the state of the application, and log the results.
  • Test suites that group a set of test cases together by function or test area.

Test script and test suite execution depends on a properties file at execution time. The properties file contains variables (such as the url, username, password and database information) that define the test environment the script will be executed against.

Automation Project Structure

The Maximo automation framework is comprised of two projects – Common and TIVAUTOMATION (stands for Tivoli Automation). The Common project contains utility files used to manipulate the environment and/or test data. The TIVAUTOMATION project contains all of the framework files used to navigate through the Maximo screens, as well as the files that store the fields, common tasks and testcases. We will talk more about each of these projects.

Project layout:

  • Common
  • Tivautomation
  • com
  • ibm
  • tivoli
  • industrysolutions
  • …..
  • maximo
  • common
  • database
  • lib
  • util
  • widget
  • uitest
  • appobjects
  • apptasks
  • testcases
  • testsuites
  • ibm

Common project

The Common project is where the utility files that control the environment and data it may use. Some examples are properties files, XML files for MEA testing and various datastore files for runtime data manipulation.

One of the most important files for our automation execution, the maximo.properties file, resides in this location. In this file, we specify the url to be used, the user name and password, the database information, such as the driver and db.url. This allows us to call these properties at runtime instead of having the user specify them when the test is run, or to hard-code them into test cases.

Another type of properties file found in this location is the properties file used when the BVT (Build Verification Test) is run. When the BVT is run, all new data is created to perform the test so that we do not need to rely on maxdemo data. When the Setup portion of the script completes, the records created are written to a properties file. Each of the subsequent tests reads that same properties file to retrieve the records it needs to properly run the script.

Tivautomation project

The Tivautomation project contains the framework files, as well as our object getters, common tasks, test cases and test suites. The Tivautomation project is organized into 4 folders: com, etc and ibm.

com.ibm.tivoli folder

The com.ibm.tivoli folder contains all of the Maximo-specific classes, including the common Maximo framework tasks, as well as all of the object getters, test cases and test suites. The folder is organized by project (core Maximo vs. Maximo add on), and each of the projects contains a uitest folder and 4 sub-folders in uitest: appobjects, apptasks, testcases and testsuites, all found in subfolder called uitest (e.g.: maximo.uitest). The Maximo folder contains the Maximo framework code used in the project.

common folder

The com.ibm.tivoli.maximo.common folder contains the Maximo framework classes that contain the common actions across applications.

database folder

The database folder contains the class files that allow the scripts to access and query the database.

lib folder

The lib folder contains the .jar files that a user needs to import upon project creation to run the Maximo automation project.

util folder

The util folder houses the utility files that contain the actions that are common across Maximo. There are files relating to MEA and how to interact with it, browser interaction, string manipulation, and the most used file in Maximo automation, the WebUtil file.

WebUtil file

The WebUtil file is one of the most important files in the framework. Most of the common actions in Maximo reside in this class file.

Some examples of methods in the WebUtil file:

  • click
  • field, checkbox state verification
  • field value verification
  • browser readiness (ready, exists)
  • open tabs within an application
  • navigating the Go To and Select Action menus
  • select a button
  • select a checkbox
  • select a detail menu
  • select a link
  • select a value from a Select Value dialog
  • select a toolbar button
  • set text in a field

widget folder

The widget folder contains classes that allow the user to interact with different controls in the UI. Some of the class files contained in the folder are files that interact with menus, checkboxes, dialogs, radio buttons and toolbars. There are two important framework files contained in this folder, Component and ComponentsTable, that allow a user to interact with fields and tables.

Component class

The Component class is the class that contains the methods that allow the scripts to interact with a text field. The method to get the text field, check box or radio button is found in this class, as well as the methods to interact with it once found. Once the object is found, any associated description fields, buttons (long description, detail menu, select value) and rich text editors can also be found.

Examples of some of the methods found in the class that interact with the field and/or buttons:

  • check or uncheck a checkbox
  • clear text from a field
  • verify a field, checkbox or radio button exists
  • select a detail menu and select a menu item
  • select a GL Account from the dialog
  • select a radio button
  • select a Select Value lookup and choose a value from the dialog
  • set text in a field or description field
  • verify the state of a checkbox
  • verify the text in a field is the expected text

ComponentsTable class

The ComponenstTable class is the class that contains the methods that allow the scripts to interact with a table. The method to get the table, as well as methods to interact it once found, are found in this class file. Once the table is found, the associated filter, images, New Row button, etc can also be found.

Examples of some of the methods found in the class that interact with the table:

  • open and close row details
  • delete and undelete a row
  • select an image in a row
  • filter the table
  • get the row count
  • select a button (e.g. New Row)
  • select the Select All Records checkbox
  • select the Select Record checkbox for a row
  • select any of the table header images (e.g. Clear Filter Fields, Next Page)

uitest folder

The uitest folder contains the object getters, application methods, test cases and test suites. There are also a few classes located in the root that are common actions throughout Maximo. A few examples are the BaseActions, BaseConstants, BaseLogin, and BaseObjects classes.

BaseActions class

The BaseActions class contains actions that are common to most Maximo applications. When a change is made to the functionality or logic of a set of steps to complete an action, a change needs to be made in this file only.

Some examples of the common actions in the class file:

  • using the various dialogs associated with Advanced Search
  • change the status of a record
  • manipulating the classification tree
  • filtering a table on a dialog or page
  • opening the Help -> System Information dialog
  • using the various dialogs associated with the Profile menu
  • searching for a record using the quick search field
  • selecting a line type (e.g. the Line Type dropdown in the PO application)

BaseConstants class

The BaseConstants class contains enums of some of the constants used when creating and manipulating records in Maximo. If the name or abbreviation of one of these is changed, an update needs to be made in this one class only.

For example:

  • an enum with the names of the various statuses available when changing a record status
  • an enum with the names of the toolbar buttons
  • an enum of the application names

BaseLogin class

The BaseLogin class contains code that manages logging into Maximo. There are various methods, depending on what type of environment you are logging into, and what type of information the user needs to provide (url, username, password, etc).

BaseObjects class

The BaseObjects class contains most of the core object code that many of the other class files use. When changes are made in the Maximo UI, many of the changes are made within this class file.

appobjects folder

The appobjects folder is where all test objects and their getters are stored.

The folder is organized by application (each application has its own folder), and the classes within the folder are organized by main application page and then by dialog.

Examples:

-The assets folder contains a class called AssetPage, which contains all objects found on the tabs in the Assets application.

-The assets folder contains a class called ChangeItemNumberDialog, which contains all objects found in the Change Item Number dialog.

The appobjects file is organized by object (field, table, menu item, tab) title and the getter. By keeping all of the labels and getters in one place, if a field (or tab, table, or menu item) name changes (or a client customizes a label), updates only need to be done in one place, and test cases will continue to run.

Example:

-public final static String ASSET = “Asset”; is the definition of the Asset field label. The object getter will use this label to find the field and its associated description field, and any associated icons. If the Asset field label changes, it only needs to be changed in this one place instead of in every test case that uses the getter.

apptasks folder

The apptasks folder contains all application-specific method libraries.

Like the appobjects folder, the apptasks folder is organized by application, and the classes within the folder are organized by main application page and then by dialog.

Methods contained in these files are things like a new record creation, adding table records to a record, etc. Reusable methods that are specific to one application reside in this location. If a change is made to logic or process, a change needs to be made in just one place instead of within test cases, allowing the test cases to continue to run.

testcases folder

The testcases folder contains all test case files, organized into folders by their function (e.g. Build Verification Test (BVT)), and/or their functional area (e.g. inventory).
testsuites folder

The testsuites folder contains all test suite files, consisting of suite files compromised of classes from the testcases folder.

ibm folder

The ibm folder contains the core common IBM framework classes such as the Widget class and the VisualReporter logger class. The ibm folder contains subfolders that contain libraries of core automation classes that complement the Rational automation classes. The folders are broken down into several categories such as loggers, tools, util, widgets, etc.

loggers folder

The loggers folder contains the class files for the custom logging available in the Maximo automation framework.

widgets folder

The widgets folder contains the class files for the different object types used in the automation framework. The class files in this folder contain the getters for the various widgets available to the tester. These widgets are used to get the objects in Maximo and are extended in the framework to manipulate the widgets.

Some of the widgets contained in this folder are button, checkbox, combobox, image, link, radio button, static text, table and text field.

Examples of how the classes interact with each other:

From the Assets appobjects class:

/** text field label for "Asset" */

publicfinalstatic String ASSET = "Asset";

/** get text field "Asset" */

public Component getTextField_Asset()

{

returnnew Component(ASSET);

}

From the Assets apptasks class:

publicvoidcreateNewAsset(boolean goToApp, String asset, String assetDescription, String parent, String location, String vendor, String manufacturer, boolean saveRecord)

{

VisualReporter.logTestCaseInfo("Create asset " + asset);

if (goToApp)

goto_Assets();

// Insert a new asset

insert();

// Give it a name and description

assetsPage.getTextField_Asset().setText(asset);

assetsPage.getTextField_Asset().setText_Description(assetDescription);

....

The createNewAsset method calls the appobject (field getter) for the Asset field from the appobjects class. The setText and setText_Description methods are called from the Component class.

If you wanted to change the Asset’s status to Active, the changeStatus method is called from the BaseActions class. The constant Active from the BaseConstants class is used as the status.

BaseActions.changeStatus(Status.Active);

The WebUtil class is used in many different ways in test cases. Examples:

To go to a tab within an application, the openPage method is called from WebUtil, and the tab name comes from the appobjects class.

WebUtil.openPage(AssetsPage.TAB_ASSET);

To select a menu item from the Select Action menu, the selectAction method is called from WebUtil and the action name comes from the appobjects class.

WebUtil.selectActionMenu(AssetsPage.SA_MANAGEMETERREADINGHISTORY);