Tool Investigation

HUI Analyzer built using .NET

For each GUI component on the screen of the mobile device, listeners are added for specific events.
Once the events are fired an appropriate XML script line is generated.
This is done first by the developer simulating actions which generates the Expected Test Sequences
Then the user is asked to try the same task, which generates the the Actual Test Sequence.
A comparison is made between these to evaluate the usability of the application.

HUI Analyzer compares Expected Sequence XML against the Actual sequence XML as opposed to simulating the actions again. With Hermes we want to be able to simulate script actions rather than checking differences between XML schema's.
HUI Analyzer was tested on an application that was made by the developers. Hermes needs to be generic to any application developed. This avoids the accusation of HARD-CODING the testing.

Structure of the XML is very concise due to the accurate mapping of actions from the components
Actions are added in an efficient way. The top level form is retrieved first then an iteration through each of the components is done to add the action listeners for specific events.

Can only be developed for .NET applications running the Windows OS. While Java applications are far more popular and compatible on most mobile devices.
Familiarity with the .NET platform is not as high as that with Java.

Mobile Life wanted us to use the J2ME Polish RMI for connectivity between the mobile phone and the server.
J2ME Polish is a wrapper around HTTP that allows developers to call server-side code more easily. (This is similar to Java RMI).
Mobile Life wanted the client module to iteratively poll the server for the next test instruction and then execute this instruction and report the outcome to the server.

As it focuses on mainly GUI development, the final deployed jar package may be larger than necessary
Compile time is long compared to J2Me itself

The Robot class within AWT is a class which simulates user input on desktop computers.
It is contained within java.awt.Robot
It cannot be used with J2ME

Multi-threading. This can be used to attach the testing code module to the application and then send the whole package to the phone. The test application could then be launched from within the phone. There would be an inner class which implement runnable and instantiates the application. This is how two applications can be run at the same time.
- The first application will be the testing application.
- The second application will be the actual application to test.

During the multi-threading investigation a simple exit instruction simulation was conducted
The following steps were completed to achieve this:

Create a background thread running the MIDlet application
Create a new Command, in this case EXIT
Get the Displayable element (the form in this case) and invoke the applications commandAction() method parsing in the command and form objects

So far J2ME threads have proven successful for simulating commands such as EXIT and START.

Use Bluetooth for Connectivity.
Use J2ME's multithreading for running the test application as well as the actual application.

Use bluetooth for connectivity between server and client
Use a mixture of J2ME and J2ME polish for the testing application
- Use J2ME multithreading for the test application
- Use J2ME polish for masking device heterogeneity