WinRunner: Test Director - Test Repositories?
A Separate test repository will be created for each groups project. The test repositories will be created as Common Directories and will be located on a network server (this area should be a shared area where the group stores the rest of their files and documents).
> Initially all test repositories will be created using a Microsoft Access Database. In the future we may change this to SQL Server.
> The path to the network area can not be more than 47 characters (A Test Director restriction).
> The path can not contain any special characters such as $,& -, or %.
> All folders that contain the test repositories should start with TD_ .
> All test repositories should start with TD_ .
* Reports : Created automatically by Test Director, this is where it stores results of tests etc.
* Tests : This is where the test scripts will reside if use WinRunner also.
* GUImap : This is where the GUI map files will reside
* Datafile : This is where all data flat files and excel spreadsheets will reside
* Docs : This is where copies of documents that pertain to this project will reside Fonts
> This is where a copy of the font groups will reside
* Functions : This is where the function library for the project will reside.
> Within Test Director various folders can be created as a way to organize your project and tests. These folders are stored in the database and may or may not be apparent on the file system.
* FolderName : Folder for functional regression tests
* SubFolder : Sub folder for Specific Window
* FolderName : Folder for SC functional regression tests
> It is not recommended to nest the folders more than 3 levels deep.Reply
Online Vs Batch Execution - Functions & Compiled Modules - User Defined Functions Creating user-defined libraries and functions: How to access if a script should be made a function - What are the pros and cons of making a script a function versus just using it as a script and calling it from the driver file?
We have to load the function library first before we are able to make a call out to any of the functions defined in a function library. Using User-defined function is more efficient in the sense that they are compiled and loaded into memory before a function is being called and a function can be used over and again without having to recompile the function library.Reply
Online Vs Batch Execution - Functions & Compiled Modules-Data Fetch Should we open and read from data table in driver scripts? Why or why not?
The Purpose of the driver script is to setup the application and then calls each individual scripts. To open, read and close the data-file should happen at the individual test script level. Reply
Online Vs Batch Execution - Functions & Compiled Modules-Load Library
Loading libraries and memory issues, i.e. if a library contains 100 functions and only one function is used then unnecessarily we are loading all the function into memory. Should we make multiple smaller libraries and load and unload libraries frequently or just have one big library and keep it loaded all throughout the execution of master driver Known Issue.We will run into memory issues when loading 100 functions into memory.Reply
Online Vs Batch Execution - TRe-Runnable Tests Calling a driver file from within a driver file? Is this advisable?
Test Recorder about Data Access
In automation Test Data becomes very critical to control, supplement and transfer in the application. In automation tools the Test Data is handled in data sheets of Excel format or a.csv file that is basically a character separated file using the Data driven technology. In most regression batch testing the Test Data is handled in data tables with proper allocation of test data in the sheets. Reply
> Before we start the "if else" construct the nature of the control point is commented along side. For e.g.,
# Home Page Validation
If (<return-code> == "0")
print ("Successfully Launched");
print ("Operation Unsuccessful");
> For all Data Table operation the return-code of the Open function should be handled in the "if else" construct.Reply
Test Recorder about Control Points
In any given automation tool the overall control of AUT is by Object identification technique. By this unique feature the tool recognizes the Application as an medium to interrogate with the Tester supplied inputs and tests the mobility of the Business Logistics. Invoking this object identification technique the test tool does have certain control features that checks the application at various given point of time. Innumerous criteria, myriads of object handlers, plenty of predefined conditions are the features that determine the so called object based features of the Functional Check points. Each tester has a different perspective of defining the Control points. Reply
Test Recorder about Script Environment: Automation Inits ()
Common Functions that get into Initialization Script are
> Usage of built-in commands to keep the test path dynamically loaded. Options to rule out the possibility of Test Path Definitions
> Close all the object files and data files in the Initialization Script
> Connection to the database should be done in the Inits Script
> Always Unload and Load the Object library, and it should be done only in Inits Script.
> Define all the "public" Variables in the Inits Script
> Establish the db connections in the Inits Test Script Reply
Test Recorder about Test Properties ?
> Every Script before recording ensure that the Test properties is in Main Test with the defaults
> Do not entertain any Parameters for Main Test
> It is not a good practice to load the Object library from the Test Options (if any). Rather the Object library is loaded from the Script using the suitable tool commands. This would actually avoid the hidden settings in the Script and also the ease of Setting the Object library Load and Unload can be better done dynamically in the Test Script rather than doing it manually every time the Test Suite is ran.
> Ensure the Add-ins is correct from the Add-ins tab. Reply