Generating Automated Test Scripts for
AltioLive using QF‐Test
Author: Maryam Umar
Contents
1. Introduction 2 2. Setting up QF‐Test 2 3. Starting an Altio application 3 4. Recording components 5 5. Performing checks 6 6. Testing Altio components 7 7. Testing business logic in QF‐Test script 8 8. Jython scripting 9 9. Use of procedures and structuring the Test Script 10 10. Testing various areas of AltioLive Studio Enterprise 12Introduction
This document describes how to use QF‐Test 2.2.2 for generating test scripts for AltioLive Client. QF‐Test can be used in multiple ways for this purpose: o Record and playback o Using Jython scripts Both these methodologies will be discussed here. Further detail can be found in the QFtest user manual and reference guides (http://qftest.com/en/qftest/manual.html).
Setting up QF‐Test
QF‐Test is a testing tool which enables testing of Java applications. It can be used to create automated regression and load tests for Swing‐based applications, Eclipse plug‐ins and Java applets.Browser SUT (1)
SUT (2) Launch app
Connect using RMI Uses custom eventQueue QF-Test
Figure 1 – Connection of applications in QF‐Test When the System Under Test (SUT) is started by QF‐Test, Java applications are run in separate Java Virtual Machines (JVM). An extra layer of code is executed to set up an RMI connection to QF‐Test and to install a custom EventQueue before control is handed to the SUT itself. The EventQueue is needed to keep track of all the GUI components in the SUT and to record events. To achieve this connection with the SUT, the JDK on the host machine should be instrumented in QF‐Test. When QF‐Test is replaying a test‐sequence, the event data is sent together with the data for the target component via the RMI connection to the extra layer in the SUT. A robust algorithm for component recognition is used to determine the component that should receive the event.
Starting an Altio Application
To test any Altio application, we first need to ensure that the Altio application has a valid username, password, view file name and htmltemplate specified. To do so, use the Altio login manager to provide a generic username/password e.g. admin/admin for the Altio application you are interested in testing. Also specify the view.xml file which the user requires to run in addition to the htmltemplate file which will be used to specify the parameters for the application. To launch any Java applet, QF‐Test requires the URL used for running that applet. In this scenario, we need the URL to launch the Altio application in running mode. To launch an application from QF‐Test: 1. Start QF‐Test; by default there will be a Test‐suite created in it. 2. Expand the Test node and right‐click on it.3. From the popup menu, select Insert node ‐> Dependencies ‐> Setup. 4. A window will popup asking the user to enter some parameters for the node. Simply specify a name for the node e.g. startup application and click Ok. 5. Now, expand the Setup node and right‐click on it. 6. From the popup menu, select Insert node ‐> Process nodes ‐> Start SUT client 7. Specify the following values in the popup window:
a. In the ʺClientʺ Field, enter the name of the SUT. This will be used as a reference to the application by QF‐Test. This can be any name, but the same name will be used to reference the SUT in other nodes, so this name should be used consistently. In this example, we will use ‘ChartDemo’ as client name.
b. In the “Executable” field, the executable program used to launch the SUT in will be specified. For Altio, this will be the file path for the browser you want to use to launch your application in. In this example, we will use ‘C:/Program Files/Internet Explorer/IEXPLORE.EXE’
c. In the “Parameters” field, the command line arguments for the executable can be specified. Each parameter should be specified on a separate line. For Altio, this will be the URL used to launch the Altio application along with its APPID, username and password i.e.
‘http://localhost:8077/altio52/servlet/com.altio.login.AltioLogin?USER_NAME=a dmin&PASSWORD=admin&APP_ID=Chart’
For testing various other Altio applications, the same URL will be used. Only the username, Password and APPID fields will change. You also need to ensure that whichever application you want to test is deployed on your Altio installation.
Figure 2 – Starting Altio application from QF‐Test
8. After specifying the Start SUT client node, we also need to setup a Wait for client node. This node ensures that QF‐Test waits for successful connection of the Altio application with the tool. To do so:
a. Right‐click on Start SUT Client
b. From the popup menu, select Insert node ‐> Process nodes ‐> Wait for client.
c. Specify ‘ChartDemo’ as the client name and click Ok
Now the setup node is complete. This node will be the same across various test scripts for Altio applications. The only difference will be in the URL for the username, password and APPID.
Recording components
the ‘Play’ button on the top menu bar. The Altio application will launch in a new browser window as specified in the Start SUT client node. When the ‘Record’ button becomes enabled, it means that the Altio application has successfully launched and connected with QF‐Test. The user can now record various components in the application and perform some tests.
To record a simple sequence, simply click on the Record button. Switch to the application window of the SUT. Every mouse and keyboard action performed within the SUT window now will be recorded. Click on some controls and switch back to your QF‐Test test‐suite window. Press ‘Stop recording’ button . Youʹll find the recorded sequence placed under ‘Extras’ node on the left side of the main window, as seen below:
Figure 3 – Recorded sequence of events in QF‐Test
You can replay this recording by selecting the sequence node and clicking on the Play button. You will notice that exactly the same sequence of mouse and keyboard events are replayed within the SUT window. This sequence can be copied under the Setup node to include it in the main test‐suite. To do this: 1. Select sequence node. 2. Right‐click and select copy. 3. Now collapse the Setup node. 4. Right‐click and paste. The recorded sequence will be pasted under the setup node.
It’s important to remember that when the test script is played back, only events under the test suite node will be executed. No events under the Extras node will be replayed.
Performing checks
QF‐Test allows a user to perform various checks on the components available in the SUT. To demonstrate how to do so, close the browser window running the SUT and replay the Setup sequence. To begin recording of a check, click on the ‘Record a check’ button . Switch to the Chart window. Now when you move your mouse over the components they invert their colour. To record a check, move to the component of interest, in this case, the list control, and right‐click. Youʹll then see a popup menu appear which gives you the choice of several checks, starting with ‘Cell’ and ‘The Cell’s selected state’, as seen below:Figure 4 – Recording checks for a list control in QF‐Test
This sequence of checks can also be copied into the main test suite in the same fashion as we copied the previous recorded sequence.
Figure 5 – Recorded sequence of checks in QF‐Test
All the components recorded in any sequence can be located under the Windows and Components node in QF‐Test. Right‐click a node and select ‘Locate Component’ to locate a component in the hierarchy. This will help a user find out what kind of Java swing component a particular component is recognized as.
QF‐Test provides various types of checks depending on the component selected at run‐time. However, for some components like charts, gif animator, etc. only image checks are available. To test such components in greater detail, Jython scripting can be used.
Testing Altio components
AltioLive has a number of controls which can be tested in various ways in QF‐Test. Below are outlined the checks available in QF‐Test on the various controls: 1. Label control – User can check the label’s text or enabled state. 2. Text control – User can perform text value checks as well as tests to check the editable and enabled state of a text control. Since the text part of the combobox and date‐picker control is similar to the text control, the same tests can be performed on these as well.
3. Button control – QF‐Test can be used to perform check text and check enabled state tests on this control.
4. Checkbox and Radio button control – User can test for the selected state, enabled state or text of these controls.
5. Combo box and date‐picker controls – QF‐Test does not record checks for popup controls like select and date‐picker. For this purpose, the user can make use of Jython scripting. Various API functions can be used to interrogate the items in the dropdown list.
6. Menu control – for a menu control, a user can test the text value and the enabled state.
7. List control – a number of tests can be performed on the list control. User can check a cell’s value as well as its selected state and editable state. Tests can also be performed on a column, a column which has been selected and the enabled state of the list.
8. Treeview control – Like the list control, multiple tests can be performed on the treeview control. Test nodes can be created to check for the text value of a node or a node’s selected state. Checks can be performed for the text value of all nodes or all nodes with their selection as well.
9. Image control – simple image checks can be performed. QF‐Test takes screenshots of the image for this particular test and tries to match the image pixel‐by‐pixel during playback.
10. Tab control – Checks can be performed for one tab or all tabs in a single test node. Text value checks for the selected tab, this tab and all tabs can be performed. In addition, this tab’s selected state, this tab’s enabled state and the tabbed control’s enabled state can be tested as well.
Tests are also available to perform image checks and geometry checks on all components. In addition to these tests, user can also perform Jython scripting to interrogate the components further.
Testing business logic in a QF‐Test script
take the list control in the application we are trying to test. Assume that this is an auto‐column list. For our test case, we want to check that every time the application is run, all the data comes back i.e. there a certain number of columns that should be visible in the list. QFtest can be used to perform an ‘All Titles’ check on the list header. This is another test which will help us ensure that all the columns appear every time we run the application. An ‘All Titles’ check can be recorded as:
Figure 6 – Recording checks for ‘All Titles’ in a list
For regression purposes, if at any time, any change in the Altio application which changes the data coming back into the list, the number of columns will change and the above recorded check will fail. Depending on the change, a decision can be made as to whether a bug has been introduced or the test script requires re‐factoring. We can also perform checks in the test script which ensure correct functionality of our Altio application by introducing a causal connection between some actions of the user which leads to a reaction from the application. For this, we can generate a sequence which performs that action and then record a check for responding event. These checks can either be recorded or performed by the use of a Jython script.
Jython scripting
As opposed to other GUI testing tools, QF‐Test allows a user to embed Jython scripts within a test‐suite. Jython is a java implementation of python in the sense that it runs python in a JVM. Jython provides the user with the flexibility of either using Java or Python libraries to generate automated test scripts. To create a Jython script for your test suite, do the following: 1. Right‐click on a sequence node. 2. Select Insert node ‐> Control Structures ‐> SUT script This will open a window where a user can type in the script. Alternatively, you can also specify an external editor for the same purpose. QF‐Test provides a special environment for all the components in the SUT in which a local variable named rc is bound. This variable represents the run‐context which encapsulates the current state of the execution of the test. It provides an interface for accessing QF‐Testʹs variables, for calling QF‐Test ʹProceduresʹ and can be also be used to add messages to the run‐log. For ʹSUT scriptsʹ, it also provides access to the actual Java components of the SUTʹs GUI. This proves beneficial for Altio applications because of the usage of Swing components. Common functions provided consist of:Component getComponent(String id, int timeout=‐1, boolean hidden=false) – This function allows us to find a component or a component’s sub‐item using QF‐Test’s component recognition mechanism.
void check(Boolean condition, String msg, int level=rc.ERROR) – This function allows us to check that a condition is true and log a message according to the result. void logMessage(String msg, boolean dontcompactify=false) – This function allows us to add a plain text message to the run‐log.
String callProcedure(String name, dictionary parameters=none) – This function allows us to call a ‘Procedure’ in a test‐suite.
An example of a typical Jython script looks like this:
# get components
panel = rc.getComponent($(getPanel)) chart = panel.getChart()
plot = chart.getPlot()
#rc.logMessage(plot.toString()) type = plot.getPlotType() rc.logMessage(type)
#get dataset for the plot dataSet = plot.getDataset() rc.logMessage(dataSet.toString())
#get row keys and column keys colKeys = dataSet.getColumnKeys() rc.logMessage(colKeys.toString()) rowKeys = dataSet.getRowKeys() rc.logMessage(rowKeys.toString())
#get the number of rows & columns for the dataset rowCount = dataSet.getRowCount() rc.logMessage(rowCount.toString()) colCount = dataSet.getColumnCount() rc.logMessage(colCount.toString()) for x in range(rowCount): rc.logMessage("Series: %i" %x) for y in range(colCount): valueData = dataSet.getValue(x,y) numValue = valueData.intValue() rc.logMessage(numValue.toString())
Use of Procedures and structuring the Test Script
Like in most programming languages, QF‐Test also provides the flexibility of creating procedures. A user can pass variable values through procedure calls to the concerned procedure. Before creating a procedure call, you need to create a procedure:
1. Right‐click on ‘Procedures’ node
2. Click on Insert node ‐> Procedure nodes ‐> Procedure
parameters list. You can then record a sequence and add it to the body of the procedure/function. To call a procedure from the test‐suite, do the following:
1. Right‐click on a sequence node in the test‐suite.
2. Click on Insert node ‐> Procedure nodes ‐> Procedure call
3. User can select procedures from the current test‐suite or other test‐suites which might be open as shown below:
Figure 6 – Making a procedure call in QF‐Test
Any parameters required for the called procedure will also be copied over hence ensuring that the user provides valid arguments for them.
For Altio testing, a QF‐Test script can be setup which will function as a library. Common procedures which can be created are for Startup and Cleanup nodes. Variables can be used to specify APPIDs for various Altio applications in the setup
node. Similarly, procedures can be created for various other repetitive tests.
For a well‐structured test suite, it’s imperative that there are one or more test cases contained in it. Every test case should effectively just have one piece of functionality being tested on. Every test‐suite should also have at least one startup and cleanup node to successfully launch and close down the Altio application, respectively.
Testing various areas of AltioLive Studio Enterprise
In addition to testing various Altio applications, QF‐Test can also be used to test various other modules of AltioLive. This includes the Designer and Application Manager. All you need is the URL to launch them. For example, to test the Designer, we can modify the Start SUT client node created above with this URL
‘http://localhost:8077/altio52/servlet/com.altio.login.AltioLogin?USER_NAME=admin&PA SSWORD=admin&APP_ID=Chart&TYPE=DESIGNER’.
Doing so will launch the view.xml file for the Chart application in the Designer. User can then record various sequences for adding components to window, changing their properties and saving the view.
Furthermore, QF‐Test also provides the use of local or global variables and data drivers. Variables can be helpful when certain components or their values need to be accessed out of the scope of a procedure. Data drivers are useful when you need to perform checks regarding data coming from a database. This will also help avoid creation of long Jython scripts for checking multiple values coming back in the Altio application at runtime.
Conclusion
Our use of QF‐Test with Altio applications has proved beneficial. We have successfully been able to test various components in the applications by using the simple record/check playback methodologies. Jython has allowed testing of various complicated components like the list control and the datepicker. The availability of Java and Python APIs has provided greater flexibility in testing.
