How do u do batch testing in WinRunner & Is it possible to do in QTP, if so explain?

WinRunner provides you the facility of executing a certain batch of the unattended tests. This feature of the winrunner has proved to be quite useful especially in the situations when a large groups of tests have to be run over night i.e., an over night run. 

How to do batch testing in WinRunner?

- A batch test can be viewed as a test consisting of a test script which holds the calls to the other tests. 

- Such call statements execute each and every test called in the list and also save the result up on execution.

- A batch test may consist of n number of tests depending up on the need and requirement of the user. 

- A batch as such just seems like a normal test but with an unusual large number of calls. 

- A batch test can be run by using the option “run in batch mode”. 

- This option is available in the run category of the general dialog box which gets invoke just before the start of the execution of the test. 

- Whenever a test is run in batch mode, all of the messages that may be displayed during the test run are suppressed by the winrunner. 

- This is done so that the winrunner is able to run a batch test unattended. 

- The execution of the batch tests is therefore different from the regular, interactive test runs where you may come across several messages popping up on the screen. 

- In batch tests, this thing is not there and so a lot of time is saved. 

- The current chain of all the called tests can be viewed at a break point in the call chain pane available for viewing in the debug viewer window. 

- After the completion of the batch test run the winrunner makes the results available in the test results window. 

- Winrunner provides you the facility of running the batch test via command line.

Is it possible to do batch testing through QTP?

- The quick test professional is the successor of the winrunner and is quite advanced and efficient in many respects as compared to the winrunner. 

- Batch testing is possible in quick test professional. 

Difference lies in the way in which the batch testing is carried out here. 

- The quick test professional facilitates the batch testing service with the help of a separate built-in tool called the test batch runner or QTP batch testing tool. 

- With this tool you can group the tests in to a number of batches which are then executed. 

- The result of this batch test run is made available in the test result viewer. 

- In quick test professional, batch wise viewing of the result is not possible. 

- Results for individual tests have to be viewed. 

- For the execution of a test batch you need to open the path of the test batch and give the run command. 

- In quick test professional, other mercury products for batch testing can also be installed and used if one is not comfortable with the in built tool of the quick test professional i.e., the test batch runner. 

- For doing this you need to follow the below mentioned sequence:

Tools menu à options à run à check the check box “allow other mercury products” à apply à ok

- Even a partial batch test is also possible! 

- You just need to deselect the tests that you want to be executed. 

- MTM or multi test manager is another mercury product using which one can carry out batch testing. 

What are User Define Functions? What are all the different types of User defined functions? (In WinRunner)

The testing capabilities of the winrunner can be extended further by letting the user create his own TSL functions. The TSL functions thus created can be used in a compiled module as well as in a test. 

Apart from just providing the built in functions, the TSL allows you to do the following:

1. The user defined functions can be defined by the user. After defining the function once in the test script, it can be called from anywhere in the tests.

2. The user defined functions can be defined by the user for compiled modules. Once that particular gets loaded, the functions it holds can be called from anywhere.

3. These user defined functions can be called from anywhere in the Microsoft API and other external DLL functions as well.

- The user defined functions are used when it is required to perform the same operations several number of times. 

- Instead of repeating the same code again and again, a single function can be written that will perform the same operations a number of times. 

- This has the following benefits:

1. It makes your test scripts more modular.
2. It makes your test scripts more readable.
3. It becomes easier to maintain the code and debug it.

What are User Defined Functions?

- A user defined function because of being incorporated in to the compiled module can be accessed from any where. 

- At the same time the time taken for the execution is reduced since the compilation of the function is done in the earlier stages only. 

- Below stated is the typical declaration for a user defined function:

[class] function name ( [mode]  parameter.... )

{

Declarations;

Statements;

}

- The class of the function can either be public or static. 

- Whenever a static function is declared with static class it is made available to the module or the test within which that function lies. 

- Once a function with a public class is executed, it is made available to almost all the tests for the time till the test holding that function remains open. 

- This seems to be the most convenient option when it is required that the function should be accessible from all the tests. 

- However if the case is as such that it is required that many tests should be able to access the function, then the function has to be placed in a compiled module. 

- Whenever a function is placed in the compiled module, it becomes accessible until the duration of the testing session ends. 

- Unlike the class, there is no need of declaring the parameters explicitly. 

Parameters can possess any one of the following modes:

1. In: in this mode the value is assigned from outside the function.
2. Out: in this mode the value is assigned from inside the function.
3. Inout: in this mode the value can assigned either from inside or from outside the function.

Types of User Functions in WinRunner

Now let us state all are the types of user defined functions:

1. Scalar functions
2. Multi- statement table valued functions and
3. Inline table valued functions

- A user defined function may consist of either zero parameter or more then that.

- The function may return either a table or a scalar value.

- However, the input parameters have a limit of 1024. 

- If the function is to be driven with the default values then the key word DEFAULT must be specified while you call the function. 

- This key word is added in order to get a default value for the user defined functions. 

- In some cases if you omit the parameters then the parameters are treated to be default values. 

What are data driven tests and how they are created in WinRunner?

When you go for testing of your software system or application, it serves good if you check the performance of your software system or application with multiple sets of different data for some set of same operations. 

For doing so you can go for creating a data driven test! Let us see in detail what actually the data driven tests are and how you can create one in the winrunner. 

What are Data Driven Tests?

- Data driven tests cuts down on the difficulty of manually executing the same test over and over again. 

- The data driven test is created with a loop that iterates exactly the same number of times as there are sets of data to be implemented. 

- Say the loop executes 20 times, so in all these 20 iterations the loop executes with a different set of data and drives the test with it. 

- Since every time the test is driven by a different set of data, the test has been termed as the data driven test. 

- However, in order to make the winrunner run a data driven wizard, use parametrization which involves the linking of the data to the test script which it is to drive. 

- After parameterization, the data is stored in a table called data table. 

- It is up to you that whether you carry out this whole process on your own manually or you take the assistance of the data driver wizard. 

- Usually a non driven test consists of the following three steps:

1. Creation of a test
2. Execution of the test
3. Analyzation of the test results.

- In data driven testing there are two additional steps are there in addition to the above mentioned 3 steps. 

- These two extra steps lie between the creation of the tests and execution of the tests. 

- These two extra steps are as mentioned below:

1. Conversion of the test in to a data driven test and
2. Creation of a corresponding data table.

Stages involved in creation of data driven test

The below stated are all the stages that are involved in the process of data driven test creation:

1. Creation of a test
2. Conversion of a data driven test
3. Preparation of data table
4. Running the test
5. Analyzation of the test results.

- You cannot directly convert a test in to a data driven test. 

- For doing so, first it is required that you should create a basic test and then convert it in to a data driven test. 

- This basic test can be created by recording a test with only a single set of data. 

- Now this test is recorded by going to the insert menu, then selecting GUI check point, then “for single property” command.

- This is to ensure that the correct order is open. 

- This order can be later modified and updated. 

- There is an alternative to this, which is that you can create bitmap check points, bitmap synchronization points and data driven GUI check points. 

- Firstly, the values contained in the check point statements and recorded statements with parameters are replaced and a data table is created which stores the values that are to be assigned to the parameters. 

- This is the parameterization process. 

- The functions and statements are added to the test scripts so that they can be read from the data table. 

What are the types of Exception available in Win Runner? How do you handle an Exception in WinRunner?

In this article, we talk about the various kinds of exceptions available in winrunner and how to handle them. Basically 4 types of exceptions are available in winrunner and they have been mentioned below:

1. Pop up exceptions
2. Object exceptions
3. TSL exceptions and lastly
4. Web exceptions

Web exceptions are available only if you have installed the web add- ins.

How are different types of exceptions are handled in WinRunner?

- A pop up exception handler is provided in the wirunner package for handling the pop up exceptions that often show up during the execution of the test scripts during the running of acceptance user test.  

- Winrunner can be made to handle pop ups by making it learn the window and by specifying a handler for the exception. 

- These handlers can be:

1. User defined handlers: The names of these handlers can be specified by clicking on the user defined function name and changing it according to your own will.
2. Default actions: Winrunner makes its own choice whether to press ok or cancel option. The desired default handler can be selected in the dialog box.

What if your batch test is executing up on a highly unstable version of the software system or application? 

- Obviously it will crash and you would want to recover the test execution. 

- This is possible only through the TSL exceptions which help in the test recovery by instructing the winrunner to exit the current test and restart the application.

- The winrunner can be easily instructed upon how an unexpected event or error can be handled that may occur in the testing environment while you test your web site. 

Here now we explain how to handle such exceptions. 

- Whenever you load some web test add in, the winrunner can be very well instructed up on how a particular exception can be handled that occurred during a test run in your web site. 

- The simplest example that can be given is of the security alert dialog box that some times appears during the test run. 

- The user can resume the normal testing by clicking on the yes button of the security alert dialog box. 

- All the exceptions that are supported by the winrunner are mentioned in a list and can be viewed in the web exception editor.

- This list can be modified and additional exceptions that you want the winrunner to support can be configured and added to the list. 

- All the new exceptions are to be added to the list of exceptions stored in the web exception editor. 

- You need to go down to the tools menu and select the option of web exception handling.

- This opens the web exception editor. 

- There is a pointing hand, clicking on that adds a new exception to the list. 

- For categorizing the exception you need to select a category in the type list. 

- The MSW_class, message and title of the exception are displayed by the editor.

- There is an action list available which provides you the options for carrying out the following execution:

1. Web_ exception_ handler_ dialog_ click_ default: For activating the default button.
2. Web_ exception_ handler_ fall_ retry: For reloading the web page as well as activating the default button.
3. Web_ exception_ enter_ user name_ password: For using the given user id and password.
4. Web_ exception_ handler_ dialog_ click_ yes: For activating the yes button.
5. Web_ exception_ handler_ dialog_ click_ no: For activating the no button.

- The other operations that can be carried out in winrunner up on exceptions are defining, modifying, activating and deactivating them. 

What is TSL? What 4GL is it similar too?

TSL and 4GL are two major languages that are coming in to the scenario of the present world programming languages. What do you mean by a test script actually? 

Test scripts form a set of instructions that in turn can be performed on some software system or application under test for checking whether or not the functions are giving the desired output i.e., if they are working properly or not. There are two ways via which these test scripts can be executed as mentioned below:

1. Manual testing and
2. Automated testing

In this article we shall discuss regarding the test script language or TSL and fourth generation language or 4GL. First let us start our discussion with the test script language. 

About Test Script Language

- The Test script language lies at the heart of the integrated testing environment created by the mercury interactive.

- Test script language is categorized under the category of high level languages. 

- Its usefulness is born out of the combination of the flexibility as well as the power of the conventional programming languages and functions that have been developed as a tool or a feature to be used along with the products of the mercury interactive like winrunner and test director. 

- Also, this feature of the test script language has made it to be used for the modification and programming of the sophisticated test suites. 

- The functions that the test script language provides have been grouped in to the following four categories:

1. Analog functions
2. Context sensitive functions
3. Customization functions and
4. Standard functions.

- All of the above mentioned functions do not come with all the mercury interactive products. 

- Winrunner is one such mercury interactive product which supports all of these functions. 

- Apart from just the built in functions the test script languages gives its users the provision of creating their own functions.

What are Fourth Generation Languages - 4GL?

- A fourth generation programming language needs not necessarily be a language only it can also be a programming environment. 

- The 4GLs have been developed with a certain set of design patterns in mind and are assigned a specific problem domain. 

- 4GLs were developed as a succession to the 3GLs and are known to define a higher trend of statement power as well as abstraction. 

- It was observed that the 3GL languages were quite slow and much prone to errors. 

- As a result of the efforts to overcome this problem, the 4GL languages were born and these were more focussed towards aspects like:

     1. Systems engineering

     2. Problem solving and so on.

- The fourth generation language was designed as such that they cut down on the following: 

     1. programming efforts,

     2. Time consumed in development and of course

     3. The cost of the software development.

- However, in some of the cases, a try at achieving all this resulted in an ineffective and unmanageable code. 

- A formal definition of the 4GL was given by John Capers in terms of developer productivity (i.e., in terms of function points per staff month). 

- 4GL languages are said to support 12- 20 function points per staff month. 

- The 4GLs are a subset of domain specific programming languages has been stated a number of times by some researchers. 

- 4GLs have been classified in to 4 types as stated below:

1.Table driven programming (codeless): Uses table driven algorithm. Example: power builder.

2. Report generator programming languages: Generates the required report.

3. Fourth generation environments or more ambitious 4GLs: Specialize in generation whole system from output of CASE tools.

4. Data management 4GLs: such as-

             a)   SPSS

             b)   SAS

             c)   Stata

What is a Module? What is a Compiled Module? (In WinRunner)

Modules are the basic elements of any software system or application that make up the foundation of that software system or application. In winrunner usually the term “compiled module” is used. We shall see in this article that what are the compiled modules and how they can be created in winrunner. 

What are Compiled Modules?

- Compiled modules store the frequently used functions and so are considered to be a kind of libraries. 

- In compiled modules, the functions defined by users i.e., the user defined functions can be stored and later these stored user defined functions can be called from the test scripts. 

- Compiled modules are considered to be a library since they are actually a script containing all the user defined functions which are required to be called many times from other tests. 

- Whenever a compiled module is loaded, the functions that it contains are subjected to automatic compilation and reside in the memory itself. 

- After this, they can be called directly and from within any test. 

- With the compiled modules, the performances as well as the organization of the tests that you create are improved significantly.

- This happens so because the compiled modules are debugged before they are used and therefore the tests that we created require very less error- checking. - In addition to all this, the interpretation of a function in a test script is quite slower than the calling of a function that has already been compiled.

There are 2 ways available for compiling a module as mentioned below:

1. Loading the module to be compiled from a test script with the help of the TSL load function.
2. Running the script of the module to be compiled with the help of the winrunner run commands.

- The step commands can be used for performing the incremental compilation if in case you need to debug or modify an already existing module. 

- After this, the part of the compiled module that you made changes to needs to be run so that the entire compiled module will be updated. 

- It is necessary that the user defined functions present in your compiled modules are automatically compiled every time the winrunner starts up. 

- For this you need to add load statements top the start up tests. 

- However, you should know that for loading the recovery compiled module there is no need for adding the load statements to the start up tests or any other tests.

- This is so bacuse the recovery compiled module loads by itself when the winrunner is started. 

- Another point to be taken care of is that the compiled modules cannot load the GUI map files when you are working in the GUI map file per test mode.

- If the compiled module has to make references to any of the GUI objects present in the application software then it is required that the referred GUI objects must also be referred in the test which is responsible for loading that particular compiled module. 

- Like a regular TSL test the compiled module can be opened, edited or saved.  - However, there is a big difference in the contents of a compiled module or ordinary tests. 

- Like a regular test, a compiled module does not contain any analog input or check points. 

- This is so because a compiled module is designed to store user defined functions rather than just performing a test. 

- The purpose why it stores all the frequently user defined functions is to speed up the execution process by providing a quick and convenient access from the other tests. 

- Its contents are:

1. Function definitions and declarations,
2. External functions prototypes
3. Load statements etc. 

What are the other codes you can write/call with in TSL?

TSL or test script language is the sole language of the winrunner i.e., it is the only language in which the winrunner test scripts are generated. One requires a deep knowledge of TSL so as to create highly sophisticated test scripts. 

A good knowledge of the language also cut downs on the need of the manual intervention. A small number of keywords and operators make the TSL language quite compact. Proficiency in languages like C and C++ will make it easier for you to deal with TSL language. 

The TSL language being a script language has a very simple syntax structure when compared to other programming languages. This feature of TSL adds to its both advantage and disadvantage. The advantage is that it is as easy as a wink to learn because of a less complex structure and the disadvantage is that being so simple reduces its capabilities. 

Below mentioned are the features of the TSL language that can be used to write the code:

1. Comments
2. Naming rules
3. Data types
4. Data storage
5. Operations
6. Branching
7. Functions and
8. Loops.

Knowledge of other languages like following also adds in quick learning of TSL:

1. Java
2. Perl
3. JavaScript etc.

- The QTP codes that are written using the HP’s quick test professional can be written or called in TSL language also. 

- The reverse is also possible i.e., the code written in TSL can be migrated in to QTP format. 

- The other codes thus written using TSL language usually sever less time turnaround but it largely depends on the degree of the complexity of the code as well as the process.

- Winrunner provides a shareable environment in which users can organize, write and maintain a set of automated test cases as well as supporting software libraries. 

- The winrunner along with TSL provides a perfect tool box for the creation of a testing frame work but the responsibility to build the right frame work lies in the hands of the user. 

- Winrunner provides a good software development environment that caters to all the needs of the test automation engineers. 

- The TSL can be considered to be a simplified version of C language or one of its derivatives since it does looks and feels like C language. 

- Test automation engineers who are quite experienced with C take less time and face little difficulty in becoming proficient with TSL language. 

- The organization of the TSL code depends largely up on the skills of the test automation engineers. 

- They must organize and maintain the code base.

- The winrunner comes with a large number of automation wizards which aid in every process of test automation. 

- Even though the winrunner meets all the needs of the testing organization, it is required that an additional development paradigm and testing frame work must be implemented with it. 

- This is necessary because otherwise the values obtained from the test automation will be lost in the due course of maintenance.

- The web, GUI, .NET and java codes can be written and called with in TSL and can also be verified. 

- TSL language is a standard start up script that is easily invoked during the start up of the winrunner. 

- The TSL codes are used for the standardization of several operational aspects of the winrunner like the following:

1. Standard functions
2. GUI map configurations
3. Shared scripts
4. Shared libraries and so on.

- There are a hundred functions that TSL provides for various uses categorized under various groups and categories namely:

1. Analog
2. Context sensitive
3. Customization and
4. Standard.

What are all the different languages that can be called using TSL in between the scripts?

A suite of manual test cases was developed by some of the organizations with the help of text editor which was found to be quite difficult to be used, maintained and executed as efficiently as in the case of other test cases. 

These test cases prove to be quite effective in detecting the defects before the production phase starts but consume more time in their management and execution and thus affect the investment terribly.

This problem becomes graver as the role of the organizations grows. The only solution to this problem is the investment in a sound test automation tool. 

Winrunner is such a test automation tool whose core language is the TSL or “test script language”. 

The three basic needs of the test automation engineer are addressed by the winrunner and TSL both namely:

1. Management and organizational needs
2. Test architecture
3. End user

What are the features of WinRunner?

The winrunner possesses the following features:

1. It enables the users to author, organize and maintain a set of automated test cases.
2. Provides a web enabled and shareable environment.
3. It supports test case design.
4. Provides automation
5. Supports execution of the best practices (that have been defined the test organization).
6. It serves as a tool box for building a testing frame work.

All the facilities are provided by the winrunner, now the responsibility of building a test frame work lies solely with the test automation engineers. 

What is TSL? What languages can be called through TSL?

- Winrunner is driven by the test scripts created in the language TSL.

- Test script language is a programming language which is quite close to the C programming language.

- Most of the features of the test script language resemble the features of the C programming language though it is quite simple than C programming language.

- The test automation engineers who are quite experienced with the languages such as C do not find it much difficult to master the test script language. 

- The organization is responsible for the maintenance and organization of this TSL code base.

- Few of the different languages that can be called using the test script language in between the scripts are:

1. Web scripts
2. GUI
3. >NET
4. Java
5. Javascript
6. HTML and so on.

- With the test script language the integration of other tool sets is also possible and is done via some API. 

- TSL actually comes in to play whenever the user records a test. 

- The default code that is generated in the winrunner window is in test script language only. 

- This script written in test script language is saved as some script file. 

- The TSL language apart from just creating the test scripts also combines functions developed from some specific purpose for the test in some other language that has got TSL like features like control flow statements, variables, arrays and user defined functions.

- Another good thing about test script language is that there is no need to compile it. 

- The scripts can be immediately executed just after they have been recorded. - Four types of functions are provided by the test script language as stated below:

1. Analog functions
2. Context sensitive functions
3. Standard functions and
4. Customization functions.

- Not even just language codes and functions but also the whole application written in a different language can be invoked in between the scripts with test script language.  

- This is actually done via the function “invoke_application” that is defined using test script language only. 

What are all the default codes WinRunner generates when you start an application?

Automation might be quite a headache but it helps in decreasing the execution time by a great margin and in a way it saves a large number of precious man hours. Once you are done with the default installation of the winrunner you will observe that a winrunner directory has been created under programs. 

This folder consists of the following:

1. Winrunner executable
2. Uninstall winrunner
3. Soft key configuration
4. Read me
5. Fonts expert
6. Sample application folder and
7. Documentation folder etc.

The purpose of the winrunner is that it has been designed for performing functional testing and regression testing. Take a moment to study some sample application saved in the folder “sample application”. Now let us take a look at the winrunner application! 

- A tool bar is there which contains options such as new, open, save and list box for run modes namely:

1. Verify
2. Debug and
3. Update

- Plus a red button for recording purpose, green arrow for running the test scripts from line 1 and a purple line pointer for running scripts from the current line. 

- Apart from this there are start, stop and pause buttons. 

- Rest of the options on this tool bar are for debugging purpose.  

Now let us begin with the recording of a simple script! 

- You open the application software and winrunner as well. 

- Re-size both the windows such that both of them are visible to you and they do not overlap. 

- Start recording by clicking on the record button and perform some specific operations (like entering some user id and password of the start up page is login page) on the start up screen of the application. 

- After performing some 3-4 operations click on the stop button of the winrunner application and the recording will be stopped. 

- After this, the scripts can be played back and if you might have observed there is a code that the winrunner might have developed for you. 

- Now, after saving the script take a look at the code which some what looks like this:

        #startup window

        Set_window(“login”,3);

        Edit_set(“user id”,”active);

        Password_edit_set(“password”,”*****”);

        Button_press(“sign in”);

        And the code continues.

- Like the above code, the default codes are generated by the winrunner up on the start up of an application software.

- The symbol “#” marks the comments in winrunner. 

- The code may or may not contain a couple of comments. 

- The comments are inserted by the winrunner during the recording phase itself. 

- The second arguments or the numbers in the code represent the time lag between any two statements while the scripts are being recorded.

- Whenever a script is saved through winrunner, a folder by either a default name or name given by the user as the case may be is created which consists of a file by the name “script”. 

- This file consists of the default generated code in plain ASCII codes. 

- This code can be run in two modes namely the verify mode and the debug mode. 

- After this phase, comes the development mode in which the debug mode is used. 

- Finally, the verify mode is used. 

- The set_window() statement in the code lays down the focus on the window. - This helps in performing a particular function on a specific window. 

- When you type in the user id, it is identified by the winrunner and the edit_set statement is generated accordingly. 

- The next statement i.e., the  password_edit_set statement is similar to the edit_set statement, the only difference being that this field contains encrypted data and for security reasons is to be displayed as a series of asterisk “*” marks.