Test Recorder about Generic Test Environment Options ?
Some generic settings we need to set in General Options:
> Default Recording Mode is Object mode
> Synch Point time is 10 seconds as default
> When Test Execution is in Batch Mode ensure all the options are set off so that the Batch test runs uninterrupted
> In the Text Recognition if the Application Text is not recognizable then the Default Font Group is set. The Text Group is identified with a User Defined Name and then include in the General Option.Reply
Test Recorder about Object Vs Actions ?
In automation tools the Test Recorder is of two modes Object based and Action Mode. It requires a meticulous but yet a simplified approach on which mode to use. Though it is inevitable to avoid Action mode, it is still used for many at TE Based applications. As a best practice the object based is widely accepted and mandatory mode of operation in Test Automation. To the extent possible we will avoid Action based functions and stick on the object mode of operation. Reply
Definition of Tests ?
As a prime entry point defining the test needs a idea to classify the scripts into finer elements of functions each contributing the various aspects of automation Techniques. Looking into this perspective the elements of the Automation Script would require the Record Play Back techniques, details of the application as better understood as Objects in tools, execution of Business Logic using loop constructs, and the test data accessibility for either Batch Process or any Back end operations. Ultimately we need this entire salient features to function at the right point of time getting the right inputs. To satisfy these criteria we require a lot of planning before we start automating the Test Scripts .Reply
Loading and Calling the Above DLLs from WinRunner
Loading and calling DLLs from WinRunner is really very simple. There are only 3 steps.
> Load the DLL using the command load_dll.
> Declare the function in the DLL as an external function using the extern function.
> Call the function as you would any other TSL function.
As simple as this is, there are some things you need to be aware of.
* WinRunner has a limited number of variable types; basically, there is string, int, and long. Windows has many different types. Two common types, which may confuse you, are HWND and DWORD. Which WinRunner type do you choose for these? You should declare these as long.
* If we are building a function in a DLL and you are testing it in WinRunner, make sure you unload the DLL in WinRunner using the unload_dll function before you try to recompile the DLL. If we leave the DLL loaded in WinRunner and try to recompile the DLL, you will receive an error message in VC++ that looks like this :
> LINK : fatal error LNK1104: cannot open file "Debug/<project name>.DLL Error executing link.exe
To resolve this error, step through the unload_dll line in WinRunner, then compile the DLL.
* Before shipping a DLL make sure you compile it in Release mode. This will make the DLL much smaller and optimized. Reply
Define: Creating MFC Dialog DLLs for use with WinRunner
> Create a new MFC AppWizard(DLL) project, name it, and click <Next>.
> In the MFC AppWizard Step 1 of 1, accept the default settings and click <Finish>.
> Click <OK> in the New Project Information dialog.
> Select the ClassView tab in the ProjectView and expand the classes tree. You will see a class that has the following name C<project name>App; expand this branch also.
> You should see the constructor function C<project name>App(); double-click on it.
> This should open the .cpp file for the project. At the very end of this file add the following definition :
#define EXPORTED extern "C" __declspec( dllexport )
> Switch to the ResourceView tab in the ProjectView.
> Select Insert Resource from the VC++ IDE menu.
> Select Dialog from the Insert Resource dialog and click .
> The Resource Editor will open, showing you the new dialog. Add the controls you want to the dialog, and set the properties of the controls you added.
> Switch to the ClassView tab in the ProjectView and select View ClassWizard from the VC++ IDE menu, or double-click on the dialog you are creating.
> The Class Wizard should appear with an "Adding a Class" dialog in front of it. Select "Create a New Class" and click .
> In the New Class dialog that comes up, give our new class a name and click <OK>.
> In the Class Wizard, change to the Member Variables tab and create new variables for the controls you want to pass information to and from. Do this by selecting the control, clicking , typing in the variable name, selecting the variable type, and clicking <OK>. Do this for each variable you want to create.
> Switch to the Message Maps tab in the Class Wizard. Select the dialog class from the Object IDs list, then select the WM_PAINT message from the Messages List. Click <Add Function>, then <Edit Code>. This should bring up the function body for the OnPaint function.
> Add the following lines to the OnPaint function so it looks like the following:
void <the dialog class>::OnPaint()
CPaintDC dc(this); // device context for painting
// Do not call CDialog::OnPaint() for painting messages
> Select IDOK from the Object IDs list, then select the BN_CLICKED message from the Messages
list. Click <Add Function>, accept the default name, and click <Edit Code>.
> Add the line UpdateData(TRUE); to the function, so it looks like this:
19. When you are done with this, click <OK> to close the Class Wizard dialog and apply your changes. Your new class should appear in the ProjectView in the ClassView tab.
> In the tree on the ClassView tab, double-click on the constructor function for the C<project name>App (see step 5).
> At the top of the file, along with the other includes, add an include statement to include the header file for your dialog class. It should be the same name as the name you gave the class in step 13 with a .h
appended to it. If you are unsure of the name, you can look it up on the FileView tab under the Header Files folder. 22. At the very end of the file, after the #define you created in step 6, create a function that looks something like this:
EXPORTED int create_dialog(char* thestring)
<dialog class> theDlg;
<do whatever conversion is necessary to convert the value to a string>
strcpy(thestring,strVar1); //this will pass the value back to WinRunner.
> Choose Build <Project name>.DLL from the VC++ IDE menu.
> Fix any errors and repeat step 23.
> Once the DLL has compiled successfully, the DLL will be built in either a Debug directory or a Release directory under your project folder depending on your settings when you built the DLL.
> To change this setting, select Build Set Active Configuration from the VC++ IDE menu, then select the Configuration you want from the dialog. Click <<OK>, then rebuild the project (step 23).
> All the DLLs types that you are going to create are loaded and called in the same way in WinRunner. This process will be covered once in a later section. Reply
Defien : Creating MFC DLLs for use with WinRunner?
How i Creating C++ DLLs for use with WinRunner?
Define : Creating C DLLs for use with WinRunner?
All the TSL script files should begin with a comment that lists the Script name, Description of the script,
All the TSL script files should begin with a comment that lists the Script name, Description of the script, version information, date, and copyright notice :
Date created and modified:
Comments generated by WinRunner.
WinRunner automatically generates some of the comments during recording..If it makes any sense leave them, else modify the comments accordingly
Single line comment at the end of line.
Accessfile = create_browse_file_dialog ("*.mdb"); # Opens an Open dialog for an Access table.
It is mandatory to add comment for your test call
Call crea_org0001 (); #Call test to create organization
It is mandatory to add comments when you are using a variable which is a public variable and is not defined in the present script.
Web_browser_invoke (NETSCAPE, strUrl); #strUrl is a variable defined in the init script
Note:The frequency of comments sometimes reflects poor quality of code. When you feel compelled to add a comment, consider rewriting the code to make it clearer. Comments should never include special characters such as form-feed. Reply
Why Have TSL Test Code Conventions ?
TSL Test Code conventions are important to TSL programmers for a number of reasons:
> 80% of the lifetime cost of a piece of software goes to maintenance.
> Hardly any software is maintained for its whole life by the original author.
> TSL Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
> If we ship our source code as a product, we need to make sure it is as well packaged and clean as any other product we create.Reply