NagaRaju Sample
DSNApplication DataBase
Front End Back End
DSN Application DataBase Front End Back End Data Base Check Point Wizard Select 3 2 1
In GUI checking test same application but with expected behavior. In Database checking test twice on the original data.
To conduct testing, test engineer collects some information from development team. • Connection String or DSN
• Table definitions or Data dictionary
• Mapping between front end forms and backend tables. Database Testing Process:
Create Database checkpoint (Current content of database selected as Expected.) Insert / Delete / Update operation through front end.
Execute Database checkpoint (Current content of database selected as Actual)
Navigation: In GUI & Bitmap checkpoints we will starts with selecting the position in script. Create Menu, Database Checkpoint, default checkpoint, specify connection to database (ODBC / Data Junction) , select sql statement(c:\\PF\MI\WR\temp\testname\msqr1.sql), click next, click create to select DSN, write select statement ( select * from orders ), click finish. Syntax: db_check("Check List File .cdl", "Query Result File.Xls(EXE File)");
Ex: db_check("list5.cdl", "dbvf5"); Criteria: Expected Difference – Pass
Wrong Difference – Fail What Updated: Data Validation
Who and when updated: Data Integrity New Record - Green Color. Modified Record - Yellow Color.
Custom Check: Test engineer use this option to conduct backend testing depends on rows count or columns count or table content or combination of above three properties.
Default Checkpoint: Content is Property & Content is Expected
Custom Checkpoint: Rows Count is Property & No of rows is Expected.
During Custom check point creation, winrunner provides a facility to select these properties, in general test engineers are using default check option as maximum. Because content is also suitable to find the number of rows and columns.
Syntax: db_check("Check List File .cdl", "Query Result File.Xls(EXE File)"); db_check("list11.cdl", "dbvf8");
Front End – Programmers (Programming Division) Back End – DataBase Administrators (DB Division)
The front objects names should be understandable to the end user. (WYSIWYG)
Runtime Record Checkpoint: Sometimes test engineer use this option to find mapping between front end objects and backend columns, it is optional checkpoint.
Navigation: Create Menu, Database Checkpoint, runtime record check, specify SQL statement, click next, click create to select DSN, write select statement with doubtful columns ( select orders.order_number, orders.customername from orders), select doubtful front end objects for that columns, click next, select any of below options
• Exactly one match • One or more match • No match record Click finish.
Note: For custom and default check points you have to give ; at the end of the sql statement. But in Runtime record check point u have no need to give it.
Syntax: db_record_check("Check list File Name.cvr", DVR_ONE_MATCH/ DVR_ONE_MORE_MATCH / DVR_NO_MATCH, Variable);
Ex: db_record_check("list1.cvr", DVR_ONE_MATCH, record_num);
In the above syntax checklist specifies expected mapping to test and variable specifies number of records matched. If mapping correct the same values will be presented.
Runtime record checkpoint allows you to perform changes in existing mapping, through below navigation. A B 3 1 2 1 2 3 X Y Expected: X A Y B
Create menu, edit runtime recordlist, select checklist file name, click next, change query (if u want to test on new columns), click next, change object selection for new objects testing, click finish.
Synchronization:
To define the time mapping between testing tool and application, we can use synchronization point concepts.
Wait(): To define fixed waiting time during test execution, test engineer use this function. Syntax: wait (time in seconds);
Ex: wait (10);
Drawback: This function defines fixed waiting time, but our applications are taking variable times to complete, depends on test environment.
Change Runtime settings:
During our test script execution, winrunner doesn't depends on recording time parameters. To maintain any waiting state, in winrunner we can use wait () function or change runtime settings.
It maintains mainly following information: Delay: Time to wait between window focusing
Timeout: How much time application should wait for context sensitive stage and checkpoints.
There are two runtime settings time parameters Delay: For window synchronization
Timeout: For execute in context sensitive and check points
Window based statements are not able to execute: Delay + Timeout. Object based statements are not able to execute: Timeout.
Navigation: Settings, General options, run tab, change delay & timeout depends on requirement, click apply, click ok.
Window statements : delay – 1sec To focus – 10 sec Set_window(“”,6) ; -- time = 11sec -- 2. button_press(ok); time = 10 3. button_check_info(“ok”,”enabled”,1);
time = 10sec
Drawbacks in Change Settings: If you are changing the Settings once they will be applied to each and every test without user specifications.
Due to this most of the times they are not using this change runtime settings option.
Now a days most of the test engineers are using the for object / window property for avoiding the time mismatch problems
For Object/Window Property:
Navigation: Select position in script, create menu, synchronization point, for object/window property, select object, specify property with expected ( Ex: Status / Progress Bar – 100% completed and enabled…), specify maximum time to wait, click ok.
Syntax: obj_wait_info("Object Name", "Property", Expected Value, Maximum time to wait);
Ex: obj_wait_info("Insert Done...","enabled",1,10); For Object / Window Bitmap:
Sometimes test engineer defines time mapping between tool and project depends on images in that application.
Navigation: Select position in script, create menu, synchronization point, for object/window Bitmap, select the required image,
Syntax: obj_wait_info("Object Name", "image1.bmp", Maximum time to wait); For Screen Area Bitmap:
Sometimes test engineer defines time mapping between tool and project depends on image area in that application.
Navigation: Select position in script, create menu, synchronization point, for Screen Area Bitmap, select the required image region, right click to releave.
Syntax: obj_wait_info("Object Name", "image1.bmp", Maximum time to wait, x, y, width, height);
Text Check Point:
To cover calculation and other text based tests, we can use this option / concept in WinRunner.
To create this type of check points in testing, we can use this “Get Text” option from the create menu.
This option consists of two sub options : 1. From object / window
From object / window: To capture object values into variables we can use this option. Navigation: Create Menu, Get Text, From Object / Window, select required object (Dbl Click)
Syntax: obj_get_text("Object Name", Variable); Ex: obj_get_text("Flight No:", text);
Syntax: obj_get_info("Object Name", "Property", Variable); Ex: obj_get_info("ThunderTextBox_3","value",v1);
From Screen Area: To capture static text in your application build screen we can use this option.
Navigation: Create Menu, Get Text, From Screen area, select required required region to capture value [+sign] , right click to relieve
Syntax: obj_get_text("Object Name", Variable, x1,y1,x2,y2); Ex: obj_get_text("Flight No:", text,2,3,50,60);
Retesting: Re execution of our test on same application build, with multiple test data is called retesting. In WinRunner retesting is also called as Data Driven Test (DDT).
Data is driving or changing to test the application. Input Output
NagaRaju Sample
Item No Ok Quantity Price $ TotalIn WinRunner test engineers are conducting Retesting in 4 ways 1. Dynamic test data submission
2. Through flat file (notepad) 3. From front end grids (List box) 4. Through excel sheet
During the test execution based on first type, tester gives values based on that test execution will be completed (like scanf() in C)
But in the remaining three types can be done with out tester execution.
Dynamic test data submission: To conduct retesting, to validate functionality, test engineer submits required test data to tool dynamically.
To read keyboard values during the test execution, test engineer use below TSL statements. Syntax: create_input_dialog(“ Message “);
Ex: create_input_dialog(“ Enter Your Account Number : “);
Exp: res = no1 * no2
Build Key Board
Test Script
No1 No2 Result Multiply Item No Ok Quantity Price $ Total $Tl_step(): tl stands for test log. Test log means that test result. We can use this function to define user defined pass or fail message.
Pass – green – 0 Fail – red – 1
Password_edit_set(“pwd”,password_encrypt(y))
Problem:
First enter EmpNo and Click Ok Button. Then it will displays bsal, comm. and gsal. Exp: gsal = bsal + comm.
Bsal >= 15000 then comm. is 15%
If bsal between 15000 and 8000 then commission is 5% If bsal < 8000 then comm. is 200.
User Id Password Login Next Display Text2 Sample 2 Ok Text1 Sample 1
Through flat file (notepad)
Sometimes test engineer conducts data driven testing, depends on multiple test data in flat files (like notepad .txt files).
To manipulate file data for testing test engineer uses below TSL functions
file_open(): To load required flat file into RAM, with specified permissions, we can use function.
Syntax: file_open(“Path of the File”,FO_MODE_READ/ FO_MODE_WRITE/ FO_MODE_APPEND);
file_getline(): We can use this function to read a line from a opened file. Syntax: file_getline( “Path of the File”, Variable);
Like in C file pointer incremented automatically.
file_close(): We can use function to swap out a opened file into RAM. Syntax: file_close(“Path of the File”);
file_printf(): We can use this function to write specified text into a opened file in WRITE or APPEND mode.
Syntax: file_printf(“Path of the File”, ”Format”, what values you want to write or which variable values you want to write);
%d - integer, %s - string, %f – floating point, \n – New Line, \t - Tab, \r – Carriage return Substr: we can use this function to separate a substring from given string.
Syntax: Substr (main string, start position, length of substring); Split: we can use this function to divide a string to field:
Syntax: Split(main string, array name, separator); In the above syntax separator must be a single character. File-compare: to compare two file contents.
Syntax: file_compare(“ path of file1”, “ path of file2”, “path of file3”); File3 is optional. And it specifies concatenate of content of both files.
Exp: res = no1 * no2 Build Values
Test Script
File
.txt
No1 No2 Result Multiply Item No Ok Quantity Price $ Total $ User Id Password Login NextFrom Front End Grids (ListBox):
Sometimes test engineer conducts retesting depends on multiple test data objects (like list box).
To manipulate file data for testing test engineer uses below TSL functions
list_get_item(): We can use this function to capture specified list box item through item number.
list_get_item(“ListBox Name”,Item No,Variable);
list_select_item(): We can use this function to select specified list box item through given variable.
list_select_item(“ListBox Name”,Variable);
list_get_info(): We can use this function to information about the specified property(like enabled, focused, count) of list box item into given variable.
list_get_info(“ListBox Name”, Property, variable);
Page 71 of 132 Fly From
Fly To
NagaRaju Journey
Software Testing Material
Data Driven Testing: In generally test engineers are creating data driven tests, depends on excel sheet data.
Build
Test Script
Display Text2 Sample 2 Ok Text1 Sample 1 List1 Ok Display TextNagaRaju Sample1
NagaRaju Sample2
Type
From Excel Sheet:
In general test engineers are creating retest test scripts depnds on multiple test data in excel sheet. To generate this type of script, test engineer use data driven test wizard. In this type of retesting, test engineer fills excel sheet with test data in two ways.
1. From data base tables using select statement (Back End) 2. Our own test data
Navigation:
Create test script for one input, tools menu, data driven wizard, click next, browse the path of the excel sheet ( path ), specify variable name to assign path of excel sheet ( by default table as variable ), select add statements to create ddt, select import data from database, optimized text 1. line by line 2. automatically, click next, specify connection to database, specify database connection (ODBC/Data Junction), select specify sql statement mssql1.sql , click next, click create to select dsn (machine data sourse – flight32), write select statement to capture database content for testing into excel sheet, specify position to replace excel sheet column in ur test script, select show data table now, click finish.
Problems:
1. Prepare a data driven program to find factorial of given number. Write result into same excel sheet.
-- -- -- Build Test Data
Test Script
Excel Sheet
Data
LoopC3 = c1 + c2
Col1 Col2 Col3Test Script
Ddt_open(): We can use this function to open excel sheet into Ram. In specified mode. Syn: ddt_open(“path of file”, DDT_MODE_READ/ DDT_MODE_READWRITE)
This function will returns E_FILE_OPEN when that file is opened into RAM. Else it returns E_FILE_NOT_OPEN.
Ddt_update_from_db(): To extend excel sheet data depends on dynamic changes in the database ( Insert , Delete, Update
Syn: Ddt_update_from_db(“path of excel sheet”, “path of query file”, variable); In the above syntax variable specifies that how many rows newly altered. Ddt_save(): To save recent modifications in excel sheet.
Ddt_save(“ path of excel sheet”);
Ddt_get_row_count(): To find the no of rows in excel sheet. Ddt_get_row_count(“path of excel sheet”, variable)
Var stores the no of rows in sheet.
Ddt_set_row(): To point a row in excel sheet. Ddt_set_row(“path of excel file”,row no):
Ddt_val(): To read a value from specified column & pointed row. Ddt_val(“path of excel file”,col no):
Ddt_set_val(): To write a value into a specified column and pointed row. Ddt_set_val(“path of excel file”, “col name”, value or variable):
Ddt_close(): To swap out excel sheet from ram Ddt_close(“path of excel file”):
Write a program to write list box items into a excel sheet one by one.
Test Suite / Test Batch:- Arranging all tests in one proper order based on their functionality. It gives what test output is used as a input to all other values.
Batch Testing: In general test engineers are executing their scripts as batches. Every batch consists of a set of tests, they all are dependent.
In every batch end state of one test is base state to next test. When you are executing our tests as batches you are getting a chance to increase our probability of defect detection.
Syntax: call “test name” () call “path of the test”();
In the above syntax we can use first one, when calling and called tests both are in the same folder. We can use second syntax when both are in different folders.
Parameter passing: Winrunner allows you to pass arguments between, calling test to called test, or main test to subtest.
Navigation: Open subtest, file menu, test properties, select parameters table, click add to create more parameters, click apply, click ok, use that parameters in required place to test script.
From the above model main test is passing values to subtest. To receive that values, subtest maintains a set of parameter variables.
Data Driven Batch Test: WinRunner allows you to execute our batches with multiple test data.
texit(): sometimes test engineers are using the statement in test script to stop test execution in the middle of the process.
Treturn(): we can use this statement to return a value from a called test to a calling test. Treturn(variable or value); Call TestName() --- --- --- --- --- --- Calling Test Main Test Test Name1 SubTest Call TestName(n) --- --- --- --- --- --- Calling Test Main Test Test Name SubTest n = 10
Silent Mode: In general winrunner returns pause message, any standard checkpoint is failed during test execution. If u want to execute our tests scripts without any initiation when a checkpoint is failed we can follow below navigation to define silent mode.
Navigation: Settings, general options, run tab, select “run in batchmode” option, click apply, click ok.
Temp = Call TestName(n) If(temp==1) Printf(); Else Printf(); Edit_set(“”,n); If(condition) Treturn(0) Else Treturn(1); Calling Test Main Test Test Name SubTest n = 10
Fail Test1
Next
Enabled
Test2
Test3
Test4
Fail Test1 Sample
Windo w appear s
Test2
Test3
window appears:
if (win_exists(“sample”) == E_OK)
win_exists() we can use this function to find existence of a window. In the desktop in min, max or hidden position.
Syn: win_exists(“ window name “, time); Time – is optional.
Homework: Login after 5 secs.
If next enabled go to next window. Else try for other user.
Shopping:
Prepare above batch test for ten users which information available in excel sheet during this batch execution tester passing item no & quantity as parameters.
User Defined Functions: Like as programming languages winrunner also provides a facility to create user defined functions. In TSL user defined functions are created by test engineer to initiate repeatable navigation.
In the above example, test engineer creates four automation test scripts to test four different functionalities depends on functionality dependency. Test engineers are calling this login process as base state.
Public / static function function name(in/out/inout argument name, ……) {
return (value or variable ) }
if u want to create a user defined function to maintain end state of one time execution is base state to next execution we can use static functions.
But static maintains constant locations for internal variables in that current test execution. Out put of one test execution is input to other test.
Note1: User Defined Functions allows only context sensitive statements and Control statements and doesn't allow check points and Analog statements.
Note2: In batch testing one test calling other test through saved test name. One test invoking one function depends on function name. to call one function in test, that function .exe must reside in RAM.