Implimenting Region Image comparision v1.0 in IBM Rational Functional Tester 7.0.0

WHITE PAPER

On

IMPLIMENTING REGION IMAGE COMPARISION V1.0 IN RFT 7.0.0: Extending Functional Tester functionality using java scripting

Original work done by

KRISHNAKANT VISHWAKARMA

([email protected])

WHITE PAPER ON IMPLIMENTING REGION IMAGE COMPARISION V1.0 IN RFT 7.0.0 : Extending Functional Tester functionality using java scripting

KRISHNAKANT VISHWAKARMA ([email protected]) 07/02/2008 1

WHITE PAPER

On

IMPLIMENTING REGION IMAGE COMPARISION V1.0 IN RFT 7.0.0: Extending Functional Tester functionality using java scripting

Introduction

RFT is one of the best automation testing tool that IBM has given to the software testing industry .I have seen many blogs ,forums ,web sites for article ,questions ,differences or features of RFT with respect to other tools . The only thing which is highlighted is “RFT doesn't have IMAGE COMPARISION verification point (VP)”.

But the best thing about RFT is tool limitation is not the tester's limitation. This is because of RTS (Rational Test Script) framework.

This paper also focuses on how RTS eases a tester's job in test development phase for automation testing by providing the JAVA power with Eclipse IDE for RFT .How easily Functional Tester functionality can be extend to implement image comparison VP in the script.

Let's first see why this verification is so much of interest to an automation test engineer.

This verification point is necessary for automation testing in following cases:

1. Sometimes tool is not able to recognize the object because of that one is not able to validate the state of that object through any of the verification point. At this time every action performed on the object (while recording) the information is stored in terms of screen coordinates in the test script.

At this point IMAGE COMPARISION verification point comes into picture. This doesn't need exact object reference to object map to capture image of that particular unrecognized object.

For example consider scenario 1:

We want to convert a statement of manual test case into automated test script:

Manual test case statement:



STEP 3: Verify that on “Quantity:” edit box “1” is present by default.

STEP 4: Click on OK button.

To automate STEP 3 we have to put property verification point but while applying drag hand selection edit box is not highlighted and test object browser doesn't have that test object.

It simply means either tool is not able to capture/recognize the object or there can be some problem with the application itself which is stopping us to automate STEP 3.

Here a simple solution is to put region image verification point and capture the region of the screen containing “Quantity:” edit box.

Let's see what happens when we perform some action on such objects.

For example consider scenario 2:

Manual test case statement:

STEP 10: On Member Logon window Select New Customer radio button.

STEP 11: Click on OK button.

After automation following code is generated in script listing 1.0 instead of listing 1.1 .

memberLogon().click(atPoint(80,100)); ok().click();

Listing 1.0: showing recording (when tool is not able to recognize New Customer radio button)

newCustomer().click(); ok().click();

Listing 1.1: showing recording (when tool is able to recognize New Customer radio button)



This reveals that even if tool fails to recognize a particular object , action performed on it are recorded as low level actions in terms of screen coordinates with reference to the parent test object.

2. One case would be that when we actually want to have IMAGE COMPARISION a possible case may be client's logo, or any image. Here we need to compare pixel by pixel between expected and actual.

3. Another case would be we need to validate object`s presence at the particular location or what is present at particular location. (Of course ,in terms of screen coordinate across different built)



MAIN IDEA:

Basic principle:

Get coordinate information of the region of interest. Call custom methods created in the Helper Super class and provide the recorded coordinate information. This method uses some methods from a plain JAVA class called Robot class (Thanks to SUN developers to show special interest for testers also).

There are two important method which I have used one to capture image and another is to compare it.

Play it. See the log for comparison result or result of region image verification point.

Implementation:

Assumptions and scenario considered:

• The project has super_image_comparator Helper Super Class defined in the separate folder.

• We need to validate that the place order button in old built (classicsJavaA) is present at the same location in next built (classicsJavaB).

There are eight basic steps to be followed for implementing Region Image Verification Point.

STEP 1: go to file >new>select Functional Test Script Using Recorder.

STEP 2: Select the project containing super_image_comparator Helper Super Class. Name the script. Click on next .Browse for super_image_comparator Helper Super Class. Click on finish. Recording starts.

STEP 3: Launch classicsJavaA application form recording monitor.

STEP 4: Move mouse pointer to position just above the left corner of the target object press left button of mouse drag it to just below the right corner of the targeted object (As shown in fig 1.0).Such that recording monitor shows code like listing 1.2.

Fig 1.0: Showing how to capture image for region image verification point.



KK

Stamp

classicsJava().dragToScreenPoint(atPoint(384,292), toScreenPoint 539, 361));

listing1.2: Showing the recorded action after STEP 4 on the Recording monitor window.

STEP 5: Click on X button to close classicsJavaA application.

STEP 6: Repeat STEP 3 AND STEP 4 for classicsJavaB application. Stop recording .And see the recorded script, it should look something like listing 1.3:

public class Script5 extends Script5Helper

{

public void testMain(Object[] args)

{

startApp("ClassicsJavaA");

// Frame: ClassicsCD

classicsJava().dragToScreenPoint(atPoint(384,292), toScreenPoint(539, 361));

classicsJava(ANY,MAY_EXIT).close();

startApp("ClassicsJavaB");


}

}

Listing 1.3: Showing the recorded action after STEP 6 on the java editor of RFT .



STEP 7: Modify the recorded script so that it as shown in listing1.4:

public void testMain(Object[] args) throws AWTException

{

long ex, ac;

startApp("ClassicsJavaA");

sleep(4);


/*classicsJava().dragToScreenPoint(atPoint(384,292),

* toScreenPoint(539, 361));

*/

ex = capture_ expected (classicsJava(), 384,292,539, 361);


sleep(3);

startApp("ClassicsJavaB");

sleep(5);


ac = capture_actual(classicsJava(), 384,292,539, 361);


try {

compare(ex, ac, 5, 15, false);

} catch (Exception e) {

System.err.println(e);

}

}

}

Listing 1.4: Showing the modification to be done in recorded script after STEP 6.



STEP 8: Play it. And see the log for result (log result for this script is shown in fig 1.2):

Fig 1.2: log showing expected image, actual image, result of verification point, and comparator result output image (notice the additional_info which shows why verification point failed and what the warning threshold was also notice the red marks on the result image which shows difference in actual from expected)



KK

Stamp

KK

Stamp

Methods USED (to modify the recorded script):

1. capture_expeted()

Ø Variables passed :4

• GuiTestObject o:

Parent expected object(here frame) of the target expected object (place order button)

• int i:

X coordinate of point that is just above the right corner of the target expected object.

• int j:

y coordinate of point that is just above the right corner of the target expected object .

• int k:

X coordinate of point that is just below the left corner of the target expected object.

• int l:

y coordinate of point that is just below the left corner of the target expected object .

Ø Variables returned:1

• Long ex:

Returns image id that is being captured (expected image).



2. capture_actual ()


• GuiTestObject o:

Parent actual object(here frame) of the target actual object (place order button)

• int i:

X coordinate of point that is just above the right corner of the target actual object .

• int j:

y coordinate of point that is just above the right corner of the target actual object .

• int k:

X coordinate of point that is just below the left corner of the target actual object.

• int l:

y coordinate of point that is just below the left corner of the target actual object .


• Long ac:

Returns image id that is being captured (actual image).



3. compare()


• long ex:

Returned image id of expected image from capture_expeted().

• long ac:

Returned image id of actual image from capture_ actual() .

• int min:

Lowest value (in percentage) of warning threshold . This act as reference for super_image_comparator comparison result .i.e. if actual image differs less than this value comparison result is pass.

• int max:

Highest value (in percentage) of warning threshold . This act as reference to super_image_comparator for comparing .i.e. if actual image differs more than this value comparison result is fail.

• boolean only_diff:

If set true: only the differed contents in actual image will be shown from expected result in the Comparator Result Output Image will be shown in actual image and expected image.

If false: the differed contents in actual image will be shown in red in the Comparator Result Output Image.


• boolean result:

If true: comparison passed with or without warning depending on the warning threshold.

If false: comparison failed depending on the warning threshold.



Features:

1. Pixel by pixel comparison: even if there is small change in brightness or contents such as text, it will be notified in the log (provided proper warning threshold is set) .

2. Captured images are stored in the in drive_name:\Workspace_name\Project1_name\resources folder each with unique id so that it can be referenced any time once captured when needed for comparison .

3. Comparison threshold can be customized depending on the need or strictness.

4. Difference is highlighted in red if there is already lot of red color in expected image only difference in actual image can be notified.

5. With the help of Helper Super Class front end (functional test script) is easily modified in the specified way .I.e. it is easy to use. A tester doesn't have to bother about Helper Super Class.

6. Interactive log messages are shown which gives in detail information of comparison i.e. by what percentage the actual image differs from expected image and what is the current value of warning threshold.

7. Log file is used as to show the images expected, actual, comparison result output, which can be viewed any time from the project explorer log.

Limitations:

1. Sensitive to screen coordinates: if in next built same window appears at different position the comparison fails.

2. It is not always possible to left click or right click or drag mouse to capture the screen coordinates of the target area.

3. Not suitable for web pages/sites.

4. For a small expected change like alphabets in text of label or button if large region of image is captured then comparison may provide false result.

Conclusion:

1. RFT provides JAVA power because of which tool limitation is not the tester's limitation.

2. RTS is rich of pre defined custom JAVA methods which helps tester to test whatever he needs.

3. This idea has got limitation but still region image verification point can be implemented which can solves a testers problem at major extent.





Date post:	10-Apr-2015
Category:	Documents
Upload:	krishnakant-vishwakarma
View:	497 times
Download:	0 times

Implimenting Region Image comparision v1.0 in IBM Rational Functional Tester 7.0.0

Documents