[Post] Best Practices for automated testing tools

[Post] Best Practices for automated testing tools

 

1. Definition of test

As a major entry point, defining a test requires a method to classify scripts as excellent functional elements, and each element is responsible for different aspects of automation technology. To study this method, the elements of the automated script require the recording and Playback Technology to understand the details of the application as much as the objects of the tool. The loop statement is used to execute the business logic, test data accessibility during the batch processing and back-end operations. Finally, we need this feature to run to get the correct input for activity at the right time point. To meet these conditions, we need to make a lot of plans before starting the automated test script.

1.1 Test recoder 1.1.1 Object vs action

In automated tools, the test recorder has two modes: Object-based and action mode ). A cautious but simplified method is required for any mode. Although we try to avoid using the action mode, we still need to use a lot in Terminal (TE) applications. As a good habit, the object mode is widely accepted and mandatory in testing automation. For future expansion, we should try to avoid using the action mode and stick to the object mode.

1.1.2 common test environment options

The following are some common settings that need to be set in the general option menu.

1. "Default recording mode" is "Object Mode ";

2. "synch point time" is 10 seconds, which is set by default;

3. If "test execution" is set to "batch mode", make sure that all options are set to disabled so that the batch test is not disturbed;

4. If the text in the application cannot be recognized, set it to the default font group in text recognition ). If a text group can be recognized by a user-defined name, put it in "general option.

1.1.3 test attributes

1. Before recording, make sure that the default attribute of each script is main test );

2. do not include any parameters in the main test;

3. (even if necessary) loading the object library from the test options is not a good habit. Instead of loading the object library in a script, use appropriate tool commands. In this way, the hidden settings in the script will be eliminated, and it can be executed dynamically in the test script better than the manual setting of the Object Library Loading/detaching each time when the test package is run;

4. Make sure that the add-ins tab is correct.

1.2 script Environment)

The best way to set a test bed is to make the test package portable and run easily in any environment under the assumption of initial conditions. To achieve this, automated tools need to support many features to evolve into a common method that enables us to hide all the built-ins running before the test package starts executing the script. In other words, the methods for organizing test scripts are kept in the minds of test automation developers to anticipate problems and to avoid obstacles with a small number of programs.

1.2.1 automation inITS ()

Common functions of the initialization script are:

1. Use the built-in command to dynamically load the test path. Exclude the definition of the test path with the option;

2. Close all object files and data files in the inits test script;

3. The database connection should be completed in the inits test script;

4. The object library is often uninstalled and loaded, and should only be executed in the inits test script;

5. Define all public variables in the inits test script;

6. Create a database connection in the inits test script.

1.2.2 test script elements

Before developing a test script, you need a proper plan to determine the style of the test script. Let's take a look at some inputs about determining the test element.

Test element (Test Ware)	Test Library (Test Repository)
Test Suite)	Sub folders, exception handlers, global object files, set data file, and driver scripts should be included ), initialize and end the script (initialization & Termination scripts)
Driver script)	Object checks, bit map checks, text check, Web check, user-defined functions, global test report folder)
Driver script)	GUI/binary image/GUI/Text check (GUI/bit/Text check), external library files, I/O handlers

 

1.3 Control Points)

In any given automated tool, all the control in aut is through the object recognition technology. With this unique feature, the tool identifies the application as an intermediary for testing the input and business logic flexibility provided to testers. By calling this object recognition technology, the test tool has certain control functions that can check applications at different given points of time. A large number of conditions, countless object processors, and many pre-conditions are used to determine the so-called function checkpoint function, which is based on objects. Each tester has different opinions on the definition control points.

1.3.1 if .... Else

1. Before we start "If else", the essence of constructing a control point is as follows:

# Home page validation

If (<return-code >== "0 ")

Print ("successfully launched ");

Else

Print ("Operation unsuccessful ");

2. for all data table operations, the return code of the open function must be processed in the "If else" structure.

1.3.2 check points)

1. No X & Y axis value is required for any checkpoint. In some actual periods, if there is a checkpoint with the X and Y axes parameters, the availability of this checkpoint has no significance for the application under the test. The following are some criteria that indicate the checkpoint needs and do not need.

 

No	Check Point	Include	Exclude
1	Text check	Capture text,	Position of the text, font & font size, text area,
2	Bitmap check	Only the picture	Window or screen that holds the picture, x-y co-ordinates,
3	Web check	URL check, orphan page	Avoid any Text Validation

 

2. As a case study, here we use the winrunner automation tool as an example to create a checkpoint. Using obj_check_info or win_check_info can avoid and persuade the idea of always using multi-attribute GUI checkpoints. Its advantage is that it can recognize every small object and its sub-item, attributes, and attributes of previous versions. This not only serves as a regression comparison, but also gives you the flexibility to define GUI checkpoints in the physical states of all objects.

 

 

1.4 access data)

In automated testing, it is important to control, supplement, and transmit data in applications. Use an Excel data table or a. CSV file to store test data in the automation tool. In batch tests of most regression, test data is stored in their respective data tables by appropriate allocation methods.

1.4.1 data handlers

Test data can be accessed through the built-in data function. Some common habits can help testers use data tables in a correct way.

1. Single data table: by default, each automated tool uses a data table as an input file. You can use a tool wizard or a CSV file to create a data table. The wizard can help us create a data table with the objects in the test object as their column names. With this concept, we can evolve a technology to load any file or operate aut based on a predetermined set of use cases.

2. Multiple Data Tables (multiple data table): It is a common habit for many test scripts to use separate default data files. In this case, the data table usage constraint is usually a file. It is not recommended to process multiple data tables, and this will also lead to a large amount of redundant code to Process Table operations. A common method is to map data files to each script. This means that in order to make data access easier and data operations easier to maintain, each test script will have a unique data table.

Use the following code in qarun of compuware.

// Run a test script

Testdata (your creditlogon.csv ")

Call testfunc1

 

For example, in winrunner of mercury interactive,

Call_close "test_script1" (dtable1.xls );

#

Call_close "test_script2" (dtable2.xls );

3. Before starting with a simple tool command, pass a standard template data table to a real template and initialize the data file. Through this exercise, you can avoid deleting data after each operation in the data table.

In winrunner of Mercury Interactive, the following code snippet explains the initialization process of the data table.

#/*************** Data table initialization *****************

Ddt_open (template, ddt_mode_read );
Ddt_open (dtable, ddt_mode_readwrite );
Ddt_export (template, dtable );
Ddt_save (dtable );
Ddt_close (dtable );
Ddt_close (Template );
Ddt_close_all_tables ();

#/*************** Data table initialization *****************

4. loading data dynamically from database operations is the most sensible and trustworthy habit, however, using cautious programs to process dB operations can always help testers avoid many risky operations and reduce the time for accessing data from remote database servers to local data tables.

When we use dB commands, some tips need to be followed in the TSL of winrunner.

Set the row number before writing a value to the data table.

For example, use the following TSL command

Public count;

Count = 1;

Ddt_set_row (dtable, count );

Now we can use the set value through the line command to write the value in it.

Ddt_set_val_by_row (dtable, count, "cts_emp_name", value );

 

To avoid confusion, it is best to use the same column name, as shown in the database table. In addition, no columns must be inserted before or after the names of columns in the winrunner data table. The better way is to load data tables together with the data in the background database.

 

2. test execution

 

2.1 online vs batch execution

 

2.1.1Online Test script

 

1. Q. How do we use online scripts?

 

A.The dialog function can be used for interactive testing.

 

The following code can be used in Mercury Interactive:

SSN = create_input_dialog ("Please enter the SSN number ");

The following code can be used in compuware's qarun:

Dialog "array_a" array_a []

User = array_a ["userid"]

Pass = array_a ["password"]

2.1.2User input

 

2. Q.Should the input_dialog_box function be stored in the drive file or in an independent script?

 

A.This function should be stored in the drive file (in the master drive and in each type of drive file)

 

2.1.3Test result (Test Results)

3. Q.Even if the script is independent, is it necessary to return the result to the drive file? How should the results be returned?

A.If your script is independent, you do not need to return the result to the drive script.

 

2.1.4Re-run test (Re-runnable tests)

4. Q.Can the setting script become re-running? If so, why? What is the best way to re-run it? (Should it contain a random number string or use the if statement to check whether the data already exists ?)

A.It is best to create a re-run script, but we also know that it is impossible to change the re-run of all the set scripts.

5. Q.Can I call another drive file from one drive file? Is this feasible?

A.No.

 

2.2 Functions & Compiled modules

 

2.2.1Load LibraryLoad Library

 

Library file loading and memory problems. For example, if a library file contains a 100-song function and only one function is used, no function is loaded to the memory. Are we making multiple small library files and loading and uninstalling library files frequently? Are we still only making a large library file and loading it in the memory all the time when the script on the master drive is executed?

 

Known issues

When 100 functions are loaded into the memory, memory overflow may occur.

2.2.2Data Acquisition

 

2. Q.Can we open the data table in the drive script and read the data from it? Why?

A.The purpose of the drive script is to set the application and then call each independent script. Open, read, and close data files should be placed at the level of an independent test script.

2.3 User-Defined Functions

 

3. Q.Create a user-defined library file and function: If a script has a function, how to access it-what are the prerequisites for making the script a function? Which function becomes a script and is called by the drive file?

A.First, you must load the function library before you can call any function outside the function library. Using user-defined functions is more efficient in a certain sense, because they have been compiled and loaded in the memory before the function is called, and functions can be used repeatedly without the need to re-compile the function library.

 

2.4 wildcard characters

 

5. Q.Whenever an application changes, I need to change the Object Name and re-run the test script. Are you recommended?

 A.If the object in the application only makes a small change, it is best to use wildcards in the object attributes.

Http://blog.csdn.net/imlogic/article/details/415395