Transaction point:
QTP has provided the following transaction options.
- Start transaction
- End transaction
Syntax:
Services.start transaction ”transaction name”
“ statement 1”
“ statement 2
Services.end transaction ”transaction name”
Tuesday, December 27, 2016
Transaction point in QTP
QTP Framework:
Hi Friends while I was exploring different blogs or different community or networking websites i found mainly many questions related to QTP framework.Here i am going to share a article with you that how we can establish a QTP framework and what are the main things need to take care while creating a framework.
1. The automation process
The following sections describe in detail the process required to create automated scripts to regression test existing projects with maintenance releases.
1.1. Automation Workflow
The diagram above depicts the process in which existing applications require automation for regression testing.
1.1.1. Pre-requisites for QTP Automation Process
The following are pre-requisites or dependencies for QTP automation:
• Knowledge and hands-on experience with the use of QTP;
• Quality Centre (QC) and QTP installed and configured;
• QC and QTP are integrated;
• QTP Add-Ins are installed (if required);
• QC user groups are defined and granted access to Quality Centre projects;
• The application or product is in a stable state;
• Creation of new automated scripts requires existing manual test cases to have been executed successfully. This task is performed by the application tester or business representative and is performed prior to handover to QTP automation.
• The manual test cases must have been executed successfully and that there are no other changes in the application. Existing automated scripts can be updated directly to reflect the changes as part of maintenance releases.
• All test cases must start and end at the same point. This is normally the First screen of the application. This allows for test cases to be batched together into a test suite.
• All environment, software or data table changes must be advised to the automated testing team. There will potentially be an impact on the running of automated test cases with the introduction of these changes.
• The test cases must not be data dependant. All data required in the test case must be created in the test case. In the event that data cannot be created and the test case is data dependant, the data must be able to be restored, or manipulated back to the initial state after a test case updates the data. This then allows for any test case to be rerun at anytime
Existing manual test cases exist in QC in the standard format (see the QC user guide) and a copy of the test case to be automated are placed in the regression folder alongside any existing automated scripts.
2. QTP Functional Testing Methodology
Each Test case is built using a series of Quick Test Professional Functions. Each function executes Quick Test Professional code to input data onto a screen.
Each object in the Quick Test Professional Function resides in the Object Repository, thus allowing Quick Test Professional to identify all fields in the application.
• Each test case uses functions. Each function is either an applet on a screen or a whole screen depending on the amount of fields.
• Each function is named AUT_Screen Name e.g. MRS_Close_Application
• Every field/object on the screen or applet must be learnt into the object repository and renamed where required to a more meaningful screen name.
• Each function library must reside as .vbs file
• All functions are accessible via the step generator.
Function is placed into testcase via the step generator. The rc value is passed back to Quality Centre via the Reporter. ReportEvent rc command. Quality Centre accepts 0 for a pass, 1 for a fail and 2 as done. Always try to pass 1 or 0.
The testcase function call invokes the function as displayed above. This is the actual vbscipt that drives QTP. Each function uses a function template. Define in the function, the variables to uniquely identify the screen and any fields on the screen.
The function displayed above selects links via a parameter link_name. The links have been learnt into the object repository. Notice the browser, page and frame name are the same as what has been learnt into the object repository.
2.1. Initial Condition
Automated test scripts must begin from the same starting point. It is best practise to end all open browsers and start the Application under Test from the beginning. This ensures that all scripts can run back to back in an unattended batch mode.
2.2. Start Up Script
The start up script will copy all functions from the LAN and load them on the C Drive of the PC executing the test case. It will also build the infrastructure libraries if they don’t exist.
2.3. Test case Failure / Exception condition handling
All Quick Test Professional functions must use an exception handling framework. This allows any Quick Test Professional function to fail, report the failure and backout of the application.
The exception handling framework is built by:
An Environment Variable set in the Quick Test Professional startup_script set as ENVIRONMENT(EXCEPTION_COND)=”N”.
The MRS_Logon function sets the ENVIRONMENT(EXCEPTION_COND) to a value of “N”.
If any function has a failure by not finding the screen is should be on, or any known exception condition is triggered, the EXCEPTION_COND value is set to “Y”. The application is shutdown and all functions in that testcase flush. The next use of a MRS_Logon function will reset the EXCEPTION_COND to “N”.
The following diagram demonstrates the exception handling process:
3. Create Infrastructure
Infrastructure libraries are created to store QTP functions, utilities, documentation and object repository files
The Infrastructure libraries are created for each release of the software. Under each release folder (eg REL23) the folders below must exist, otherwise QTP will fail in the startup script.
Examples of the libraries for releases are as follows:
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Documentation
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Functions
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Repository
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Testcase
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Txtfiles
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Utilities
The following diagram displays the directory structure for the Rel23 libraries. They are as follows
:
3.1. Library Definitions for each Release
The application under test must have a QTP release specific directory, i.e. REL11, REL 12 and Sandpit
Each of the release directories hold release specific infrastructure code or release specific infrastructure objects that QTP requires in order to run the application under test. Therefore the REL11 functions folder will hold all functions that execute on the Rel11 application code and the REL12 functions folder will hold any new application screen functions and modified Rel11 functions.
3.2. Sandpit Libraries
Sandpit libraries are for use on the test automator’s pc to develop or modify QTP code. By saving in these libraries, data is not overwritten with the baseline code after a restart of QTP.
The sandpit libraries remain empty on the \\HCOPROD4\QSA drive. The sandpit library on the C drive is where changes can be made or new functions can be created. Once tested, they can be appended to the end of the Function or Utility VBS files on the \\HCOPROD4\QSA drive under the appropriate Release Folder.
The function and utility Sandpit libraries must contain a template function. If not, these libraries cannot be executed via an executefile command.
3.3. Documentation
The Documentation directory holds Word or Excel documents which reference the application.
4. Functions Library
The Functions Library contains QTP functions. These are based on one function per screen. This library is a sequential file of all the QTP functions for that application release. As more than one software release can be tested at any one time, the QTP function library can be concatenated in QTP with as many prior function libraries as required. The following shows a library concatenation of rel13, rel12 and rel11
Sandpit
FunctionABC
FunctionDEF
REL12
Function XYZ
REL11
Function 123
Function 346
FunctionABC
The above shows that Sandpit function FunctionABC would be a modified version of REL11 Function ABC and a new function functionDEF as the sandpit library would override the rel11 function library.
As each application release gets tested, only the new functions and functions that require modification are held in the Sandpit function library. All Functions that are not changed are still accessed via the concatenation of new and old release function libraries in the QTP Startup
The QTP startup script will copy all available Release folders to the C:Drive or D:Drive of each test machine.
At the end of each VBS file, an ENVIRONMENT library variable will be used to load other libraries if required.
4.1. Function Creation
When creating a new function, the following steps must be followed:
1. Learn Object Repository entries into the \\HCOPROD4\QSA drive Object Repository.
2. Rename Object Repository entries to meaningful names.
3. Create function by copying the template function into your sandpit/function library
4. Add the field names of the screen to the parameter list of the function.
5. Add the new Object Repository entry names into the function, as AP_webedit, AP_weblist, etc. This will allow the function to communicate to the object repository and play data into each field
6. Save the function and test change
7. Once satisfied that new function is ok, append it to the \\hcoprod4\qsa drive function library.
4.2. Object Repository
The Object Repository library holds all the application objects for the application under test. This library is not concatenated as only one Object Repository, with the same entries in it, can be opened at any time.
When creating a new release of the Object Repository, a “save as” must be done on the old Object Repository to the new release library. Any subsequent changes can then be done in the new Object Repository library.
When a QTP script is executed, a copy of the Object Repository is taken and saved to C:\Application\Release\Repository. This is done to ensure no corruption occurs on the master that is held on the \\HCOPROD4\QSA drive.
If changes are required, they must be done directly to the \\HCOPROD4\QSA drive copy of the object repository. This is because when merging two object repositories, QTP sees like defined objects as the same.
By learning new objects into the \\HCOPROD4\QSA drive Object Repository a rename on objects can be done and the Object Repository can be resaved onto the \\HCOPROD4\QSA drive. Ensure that a backup of the object repository is done first. If the Object Repository gets corrupted, then QTP will not run.
E.g. MRS uses \\HCOPROD4\QSA\Group\QTP_MRS\REL23\Repository\MRS.tsr .The Object Repository is copied from the \\HCOPROD4\QSA:\Group\QTP_MRS\REL23\Repository\MRS.tsr folder when the test case starts to C:\Group\QTP_MRS\REL23\Repository\MRS.tsr.
4.2.1. Object Repository Naming Standards
Any object placed into the Object Repository should be named according to the field name on a screen. As web GUI entries will be captured as the html programming name, rename this to an understandable name such as CustomerName or CustomerPhoneNumber. This will then mean the GUI entry is shown in functions and test scripts as something understandable. A GUI entry in the format F032fwfn is not acceptable.
Any GUI entries that are non web based must also have an understandable name.
4.3. Testcase Folder
This library holds reusable actions that we can use for data loading. i.e. creating a piece of data that we can reuse in the test script later. Any data that is created must be saved as an Environment variable.
This library also contains the startup script and template script.
4.4. Txtfiles Folder
This library holds files that are created at run time. This can also be used for transient data that is used between test scripts. This practice is not recommended as test cases should be data independant.
4.5. Utilities Folder
This library holds non specific functions that can be used in any test script. Functions may include reading and writing from files, button press, edit sets, list selects etc.
5. Build Automated Scripts
5.1. Manual Test Cases
Each Test Case must be written into Quality Centre. From Quality Centre, login to your project and select the test case. The Details tab of Quality Centre describes the tests Purpose, Test Conditions, Pre requisites, Dependencies, Environments and post-test Cleanups.
View your ‘manual’ steps by clicking on the tab, Design Steps. Ensure that manual Test Cases have been written and executed without error and are therefore verified as correct before automating.
Before any test case is automated it must pass the following criteria:
• Each script has been written so that each application screen in the test case flow is a new test step and each verification point is a new step.
• Test cases are stand alone, non data dependant, logon to the application under test at the start and logoff or shutdown the application at the end of each test case.
• All data requirements are defined in the details tab of Quality Centre.
5.2. Generate QTP Script
You can now convert this manual Test Case in to a Quick Test Professional script. To do this, click on the Generate Script button and select the QUICKTEST_TEST option.
Quality Centre has now generated Quick Test Professional code and has attached it to this manual Test Case. This can be viewed by clicking on the tab Test Script. This generated code is nothing more than a series of comments and reporter events. The Quality Centre manual Test Case has been copied in to Quick Test Professional and each step has been placed in as comments.
5.3. Generated QTP Script
After generating a Quick Test Professional script from Quality Centre all the Step details are placed into comments in the Quick Test Professional script
5.4. Test Settings and Options
Each new script requires test settings, record and run settings, associate repositories and options to be set.
5.4.1. Test Settings
Click on File and select Settings. Click on Run tab. Ensure that ‘Run on all rows’ is selected. At field: When error occurs during run session: select ‘proceed to next step’.
Ensure that the two tick boxes are also ticked.
Click on Resources tab. Click on ‘+’ to add resource library and utilities. Ensure that functions are associated to local C:\ or D:\ and that sandpit libraries are listed first.
5.4.2. Record and Run Settings
Select Automation, then Record and Run Settings.
When using a Windows based application, set as per example below:
5.4.3. Associate Repositories
In QTP, click on Resources and then select Associate Repositories. Click on ‘+’ to create repository association. Click on ‘>’ to associate ‘Action1’.
5.4.4. Options
Click on Tools, select Options. Click on Run tab. Ensure Run Mode is set to ‘Normal’. As displayed in diagram above, ensure the following are ticked:
- View results when run session ends
- Allow other Mercury products to run tests and components
- Save still image captures to results. Select ‘For errors’ from drop list
5.5. Step Generator
All Quick Test Professional functions are written and stored in Libraries and are added to the Step Generator (F7) in Quick Test Professional.
To access these functions, click on Insert, then Select Step Generator or press F7 from within QTP.
The functions have been sorted alphabetically to make it easier to find the function that matches your Application screen. Once you have found the function that will perform the functionality matching the Application screen, you can fill in the value column with appropriate arguments that will be set to the function.
Every parameter must have an argument value specified. The return value box needs to be ticked each time a new function call is set. Insert another step to be ticked as required.
When creating a function you must enter data into every field of the function to verify it can run the function correctly.
The return value (rc = return code) stores whether the function has passed or failed. The rc is then passed to the report and decides whether the particular step has passed or failed.
5.6. Editing QTP Scripts
Now edit and build the Automated Test Script via Quick Test Professional. To make the script workable, we begin adding in to the Test Script the functions or Test conditions that will perform the automated tests, thus building up a test scenario. The idea here is to match the manual Test Case steps to the appropriate Quick Test Professional Function.
Each test case should have one or more Quick Test Professional functions per step. This function will relate to each screen of the tested application, as per the Automated Functional Testing Methodology.
The Automated Functional Testing Methodology gives the advantage of modular programming; it enables an easy and fast way to create reusable test cases. Other advantages of this methodology are, ease of maintenance of scripts and ability to run scripts in any environment due to no data dependencies.
Ensure that you add the following text at the top of the Quick Test Professional script to identify who has written the script and when:
E.g. “# Revision History: KH Initial Version 10/03/08 MRS version 2.2.3”
You are now ready to edit/create the Automated Test Script. To do this, start up Quick Test Professional and access the test script that was created in Quality Centre via the Open command. There are two areas where Test Scripts can reside. They can reside within Quality Centre or in the File System (PC or Network folders).
If we have created the Test Script via Quality Centre then the script will reside with in Quality Centre. Just follow the same path you used when accessing the Manual Test Script, to find the Automated Test Script.
5.7. QTP Add-Ins
When Quick Test Professional scripts are created from Quality Centre, Quality Centre sets the script default addin setting to blank.
Once you have started up the Quick Test Professional script you have to add all the Add-ins for the application under test. To do this, go to File / Test Properties… and click on the Add-ins tab. From here you can select all the add-ins that will be needed by clicking on appropriate items then pressing Enter.
If this is not done, Quick Test Professional will be forced to shutdown and the script will not run at all, due to Webtest commands being executed in the functions while the WebTest addins have not been started when Quick Test Professional is invoked.
Alternatively, any add-ins can be selected during opening QTP application.
5.8. QTP Template Script
Each test case will use a template script at the start. This script will copy all functions from the LAN and load them on the C Drive of the PC executing the test case. It will also build the infrastructure libraries if they don’t exist.
It will then execute a function.vbs file so at run time these functions will override the function library associated at build time.
The template script will be administered by QSA.
The location of the template is:
\\hcoprod4\Group\ QTP_MRS\REL23\Testcase\ActionTemplate.mst
The PC that will be running the automated scripts will reference the abovementioned Action template. A copy of this template is placed in C:\Program Files\Mercury Interactive\QuickTest Professional\dat
5.9. Completed Testcase
Each test case should have one or more QTP functions per step. The function should pass a return code back to the test case, therefore allowing QTP to pass Quality Centre the step status.
At the start of each test case, pre required data can be added. Most pre required data for MRS can be created using a test case that uses variables, e.g. first name and surname. A global variable is created which can be addressed anywhere else in the test case.
Any pre required data scripts exist in QTP_MRS/Rel23/Testcases. These testcases are reusable actions. The line RunAction denotes a called action.
The tester should ensure they have a good understanding of what is available. If new data scripts are required, it is best to model them off existing scripts.
A test case will appear as per the following example:
6. QTP – Connection to Quality Centre
6.1. Connection
Server Connection
From Quick Test Professional, select Tools; Quality Centre Connection and on the Quality Centre Connection page enter the following:
Server url: http://postapps/qcbin Click on button Connect
E.g. Project Connection
Domain: PROJECTQC
Project: MRS
User Name: QC_MRS
Password: Click on button Connect
Other
Reconnect at startup: check this box.
Save password for reconnection on startup: check this box.
7. Maintenance Approach
To ensure that release changes of software can be accommodated by QTP, some tasks must be completed before running any tests.
7.1. Regression Test Changes
When a new release of software causes old functions to perform incorrectly, changes need to be done to these functions and object repositories to allow for testing to continue. These changes may be due to a new screen, a screen change or an object being seen differently in QTP, e.g. a change in a button name.
7.2. New Infrastructure
When building a new release of QTP Infrastructure, the first thing to do is build the infrastructure libraries as documented previously. This will give you the ability to make release dependant changes to old functions, scripts and Object Repositories in the new libraries.
Copy the QC folder within the project to a new version. This will allow for test cases changes in the new version of the QC folder and also keep the old QC folder as is. This will allow for easier reporting of the testing effort in the new release.
7.2.1. Building a new QTP Environment
As each new release of software is placed into an application testing environment, the QTP environment will need to be updated to allow for new functions, and the ability to run regression tests against the old software. The following tasks need to be performed to build the environment:
• The release specific infrastructure libraries must be created for the new release, as documented earlier in Section 4.
• The Object Repository for the current release must be “saved as” into the new release Repository folder
• The Function Library requires just a comment in it, so it does not appear as an empty file.
• The C:\TEMP\QTP_Start_Up.vbs file must be modified with the correct version of the application you wish to test with. Depending on the Release or Project, this is to be updated accordingly.
Once this is completed, restart QTP and ensure you are able to run a script through to completion. Any function changes can then be done by copying the function from the previous release’s function library and placing it into the new function library. From this new function library, you are then able to make the appropriate changes.
The following steps outline the build for new environment:
1. Open Windows explorer.
2. On network \\hcoprod4\qsa, open QTP_MRS folder
3. Create new folder e.g. REL31 and then create folders as per previous release:
- Documentation (to be empty)
- Functions (to contain blank function.vbs file)
- Repository (to contain empty repository file)
- Testcase (Copy Startup and QTP Startup from previous release)
- Txtfiles (to be empty)
- Utilities (to contain blank utilities.vbs)
4. Highlight the Testcase folder.
- Open up QTP Startup.vbs. Update release number in path
- Open up Startup.vbs. Update Dim Release +1 (2) and Add Release (2)
- Add Revision comments. Updates to be made in new function.vbs.
1. The automation process
The following sections describe in detail the process required to create automated scripts to regression test existing projects with maintenance releases.
1.1. Automation Workflow
The diagram above depicts the process in which existing applications require automation for regression testing.
1.1.1. Pre-requisites for QTP Automation Process
The following are pre-requisites or dependencies for QTP automation:
• Knowledge and hands-on experience with the use of QTP;
• Quality Centre (QC) and QTP installed and configured;
• QC and QTP are integrated;
• QTP Add-Ins are installed (if required);
• QC user groups are defined and granted access to Quality Centre projects;
• The application or product is in a stable state;
• Creation of new automated scripts requires existing manual test cases to have been executed successfully. This task is performed by the application tester or business representative and is performed prior to handover to QTP automation.
• The manual test cases must have been executed successfully and that there are no other changes in the application. Existing automated scripts can be updated directly to reflect the changes as part of maintenance releases.
• All test cases must start and end at the same point. This is normally the First screen of the application. This allows for test cases to be batched together into a test suite.
• All environment, software or data table changes must be advised to the automated testing team. There will potentially be an impact on the running of automated test cases with the introduction of these changes.
• The test cases must not be data dependant. All data required in the test case must be created in the test case. In the event that data cannot be created and the test case is data dependant, the data must be able to be restored, or manipulated back to the initial state after a test case updates the data. This then allows for any test case to be rerun at anytime
Existing manual test cases exist in QC in the standard format (see the QC user guide) and a copy of the test case to be automated are placed in the regression folder alongside any existing automated scripts.
2. QTP Functional Testing Methodology
Each Test case is built using a series of Quick Test Professional Functions. Each function executes Quick Test Professional code to input data onto a screen.
Each object in the Quick Test Professional Function resides in the Object Repository, thus allowing Quick Test Professional to identify all fields in the application.
• Each test case uses functions. Each function is either an applet on a screen or a whole screen depending on the amount of fields.
• Each function is named AUT_Screen Name e.g. MRS_Close_Application
• Every field/object on the screen or applet must be learnt into the object repository and renamed where required to a more meaningful screen name.
• Each function library must reside as .vbs file
• All functions are accessible via the step generator.
Function is placed into testcase via the step generator. The rc value is passed back to Quality Centre via the Reporter. ReportEvent rc command. Quality Centre accepts 0 for a pass, 1 for a fail and 2 as done. Always try to pass 1 or 0.
The testcase function call invokes the function as displayed above. This is the actual vbscipt that drives QTP. Each function uses a function template. Define in the function, the variables to uniquely identify the screen and any fields on the screen.
The function displayed above selects links via a parameter link_name. The links have been learnt into the object repository. Notice the browser, page and frame name are the same as what has been learnt into the object repository.
2.1. Initial Condition
Automated test scripts must begin from the same starting point. It is best practise to end all open browsers and start the Application under Test from the beginning. This ensures that all scripts can run back to back in an unattended batch mode.
2.2. Start Up Script
The start up script will copy all functions from the LAN and load them on the C Drive of the PC executing the test case. It will also build the infrastructure libraries if they don’t exist.
2.3. Test case Failure / Exception condition handling
All Quick Test Professional functions must use an exception handling framework. This allows any Quick Test Professional function to fail, report the failure and backout of the application.
The exception handling framework is built by:
An Environment Variable set in the Quick Test Professional startup_script set as ENVIRONMENT(EXCEPTION_COND)=”N”.
The MRS_Logon function sets the ENVIRONMENT(EXCEPTION_COND) to a value of “N”.
If any function has a failure by not finding the screen is should be on, or any known exception condition is triggered, the EXCEPTION_COND value is set to “Y”. The application is shutdown and all functions in that testcase flush. The next use of a MRS_Logon function will reset the EXCEPTION_COND to “N”.
The following diagram demonstrates the exception handling process:
3. Create Infrastructure
Infrastructure libraries are created to store QTP functions, utilities, documentation and object repository files
The Infrastructure libraries are created for each release of the software. Under each release folder (eg REL23) the folders below must exist, otherwise QTP will fail in the startup script.
Examples of the libraries for releases are as follows:
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Documentation
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Functions
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Repository
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Testcase
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Txtfiles
\\HCOPROD4\QSA\Group\QTP_MRS\REL23\Utilities
The following diagram displays the directory structure for the Rel23 libraries. They are as follows
:
3.1. Library Definitions for each Release
The application under test must have a QTP release specific directory, i.e. REL11, REL 12 and Sandpit
Each of the release directories hold release specific infrastructure code or release specific infrastructure objects that QTP requires in order to run the application under test. Therefore the REL11 functions folder will hold all functions that execute on the Rel11 application code and the REL12 functions folder will hold any new application screen functions and modified Rel11 functions.
3.2. Sandpit Libraries
Sandpit libraries are for use on the test automator’s pc to develop or modify QTP code. By saving in these libraries, data is not overwritten with the baseline code after a restart of QTP.
The sandpit libraries remain empty on the \\HCOPROD4\QSA drive. The sandpit library on the C drive is where changes can be made or new functions can be created. Once tested, they can be appended to the end of the Function or Utility VBS files on the \\HCOPROD4\QSA drive under the appropriate Release Folder.
The function and utility Sandpit libraries must contain a template function. If not, these libraries cannot be executed via an executefile command.
3.3. Documentation
The Documentation directory holds Word or Excel documents which reference the application.
4. Functions Library
The Functions Library contains QTP functions. These are based on one function per screen. This library is a sequential file of all the QTP functions for that application release. As more than one software release can be tested at any one time, the QTP function library can be concatenated in QTP with as many prior function libraries as required. The following shows a library concatenation of rel13, rel12 and rel11
Sandpit
FunctionABC
FunctionDEF
REL12
Function XYZ
REL11
Function 123
Function 346
FunctionABC
The above shows that Sandpit function FunctionABC would be a modified version of REL11 Function ABC and a new function functionDEF as the sandpit library would override the rel11 function library.
As each application release gets tested, only the new functions and functions that require modification are held in the Sandpit function library. All Functions that are not changed are still accessed via the concatenation of new and old release function libraries in the QTP Startup
The QTP startup script will copy all available Release folders to the C:Drive or D:Drive of each test machine.
At the end of each VBS file, an ENVIRONMENT library variable will be used to load other libraries if required.
4.1. Function Creation
When creating a new function, the following steps must be followed:
1. Learn Object Repository entries into the \\HCOPROD4\QSA drive Object Repository.
2. Rename Object Repository entries to meaningful names.
3. Create function by copying the template function into your sandpit/function library
4. Add the field names of the screen to the parameter list of the function.
5. Add the new Object Repository entry names into the function, as AP_webedit, AP_weblist, etc. This will allow the function to communicate to the object repository and play data into each field
6. Save the function and test change
7. Once satisfied that new function is ok, append it to the \\hcoprod4\qsa drive function library.
4.2. Object Repository
The Object Repository library holds all the application objects for the application under test. This library is not concatenated as only one Object Repository, with the same entries in it, can be opened at any time.
When creating a new release of the Object Repository, a “save as” must be done on the old Object Repository to the new release library. Any subsequent changes can then be done in the new Object Repository library.
When a QTP script is executed, a copy of the Object Repository is taken and saved to C:\Application\Release\Repository. This is done to ensure no corruption occurs on the master that is held on the \\HCOPROD4\QSA drive.
If changes are required, they must be done directly to the \\HCOPROD4\QSA drive copy of the object repository. This is because when merging two object repositories, QTP sees like defined objects as the same.
By learning new objects into the \\HCOPROD4\QSA drive Object Repository a rename on objects can be done and the Object Repository can be resaved onto the \\HCOPROD4\QSA drive. Ensure that a backup of the object repository is done first. If the Object Repository gets corrupted, then QTP will not run.
E.g. MRS uses \\HCOPROD4\QSA\Group\QTP_MRS\REL23\Repository\MRS.tsr .The Object Repository is copied from the \\HCOPROD4\QSA:\Group\QTP_MRS\REL23\Repository\MRS.tsr folder when the test case starts to C:\Group\QTP_MRS\REL23\Repository\MRS.tsr.
4.2.1. Object Repository Naming Standards
Any object placed into the Object Repository should be named according to the field name on a screen. As web GUI entries will be captured as the html programming name, rename this to an understandable name such as CustomerName or CustomerPhoneNumber. This will then mean the GUI entry is shown in functions and test scripts as something understandable. A GUI entry in the format F032fwfn is not acceptable.
Any GUI entries that are non web based must also have an understandable name.
4.3. Testcase Folder
This library holds reusable actions that we can use for data loading. i.e. creating a piece of data that we can reuse in the test script later. Any data that is created must be saved as an Environment variable.
This library also contains the startup script and template script.
4.4. Txtfiles Folder
This library holds files that are created at run time. This can also be used for transient data that is used between test scripts. This practice is not recommended as test cases should be data independant.
4.5. Utilities Folder
This library holds non specific functions that can be used in any test script. Functions may include reading and writing from files, button press, edit sets, list selects etc.
5. Build Automated Scripts
5.1. Manual Test Cases
Each Test Case must be written into Quality Centre. From Quality Centre, login to your project and select the test case. The Details tab of Quality Centre describes the tests Purpose, Test Conditions, Pre requisites, Dependencies, Environments and post-test Cleanups.
View your ‘manual’ steps by clicking on the tab, Design Steps. Ensure that manual Test Cases have been written and executed without error and are therefore verified as correct before automating.
Before any test case is automated it must pass the following criteria:
• Each script has been written so that each application screen in the test case flow is a new test step and each verification point is a new step.
• Test cases are stand alone, non data dependant, logon to the application under test at the start and logoff or shutdown the application at the end of each test case.
• All data requirements are defined in the details tab of Quality Centre.
5.2. Generate QTP Script
You can now convert this manual Test Case in to a Quick Test Professional script. To do this, click on the Generate Script button and select the QUICKTEST_TEST option.
Quality Centre has now generated Quick Test Professional code and has attached it to this manual Test Case. This can be viewed by clicking on the tab Test Script. This generated code is nothing more than a series of comments and reporter events. The Quality Centre manual Test Case has been copied in to Quick Test Professional and each step has been placed in as comments.
5.3. Generated QTP Script
After generating a Quick Test Professional script from Quality Centre all the Step details are placed into comments in the Quick Test Professional script
5.4. Test Settings and Options
Each new script requires test settings, record and run settings, associate repositories and options to be set.
5.4.1. Test Settings
Click on File and select Settings. Click on Run tab. Ensure that ‘Run on all rows’ is selected. At field: When error occurs during run session: select ‘proceed to next step’.
Ensure that the two tick boxes are also ticked.
Click on Resources tab. Click on ‘+’ to add resource library and utilities. Ensure that functions are associated to local C:\ or D:\ and that sandpit libraries are listed first.
5.4.2. Record and Run Settings
Select Automation, then Record and Run Settings.
When using a Windows based application, set as per example below:
5.4.3. Associate Repositories
In QTP, click on Resources and then select Associate Repositories. Click on ‘+’ to create repository association. Click on ‘>’ to associate ‘Action1’.
5.4.4. Options
Click on Tools, select Options. Click on Run tab. Ensure Run Mode is set to ‘Normal’. As displayed in diagram above, ensure the following are ticked:
- View results when run session ends
- Allow other Mercury products to run tests and components
- Save still image captures to results. Select ‘For errors’ from drop list
5.5. Step Generator
All Quick Test Professional functions are written and stored in Libraries and are added to the Step Generator (F7) in Quick Test Professional.
To access these functions, click on Insert, then Select Step Generator or press F7 from within QTP.
The functions have been sorted alphabetically to make it easier to find the function that matches your Application screen. Once you have found the function that will perform the functionality matching the Application screen, you can fill in the value column with appropriate arguments that will be set to the function.
Every parameter must have an argument value specified. The return value box needs to be ticked each time a new function call is set. Insert another step to be ticked as required.
When creating a function you must enter data into every field of the function to verify it can run the function correctly.
The return value (rc = return code) stores whether the function has passed or failed. The rc is then passed to the report and decides whether the particular step has passed or failed.
5.6. Editing QTP Scripts
Now edit and build the Automated Test Script via Quick Test Professional. To make the script workable, we begin adding in to the Test Script the functions or Test conditions that will perform the automated tests, thus building up a test scenario. The idea here is to match the manual Test Case steps to the appropriate Quick Test Professional Function.
Each test case should have one or more Quick Test Professional functions per step. This function will relate to each screen of the tested application, as per the Automated Functional Testing Methodology.
The Automated Functional Testing Methodology gives the advantage of modular programming; it enables an easy and fast way to create reusable test cases. Other advantages of this methodology are, ease of maintenance of scripts and ability to run scripts in any environment due to no data dependencies.
Ensure that you add the following text at the top of the Quick Test Professional script to identify who has written the script and when:
E.g. “# Revision History: KH Initial Version 10/03/08 MRS version 2.2.3”
You are now ready to edit/create the Automated Test Script. To do this, start up Quick Test Professional and access the test script that was created in Quality Centre via the Open command. There are two areas where Test Scripts can reside. They can reside within Quality Centre or in the File System (PC or Network folders).
If we have created the Test Script via Quality Centre then the script will reside with in Quality Centre. Just follow the same path you used when accessing the Manual Test Script, to find the Automated Test Script.
5.7. QTP Add-Ins
When Quick Test Professional scripts are created from Quality Centre, Quality Centre sets the script default addin setting to blank.
Once you have started up the Quick Test Professional script you have to add all the Add-ins for the application under test. To do this, go to File / Test Properties… and click on the Add-ins tab. From here you can select all the add-ins that will be needed by clicking on appropriate items then pressing Enter.
If this is not done, Quick Test Professional will be forced to shutdown and the script will not run at all, due to Webtest commands being executed in the functions while the WebTest addins have not been started when Quick Test Professional is invoked.
Alternatively, any add-ins can be selected during opening QTP application.
5.8. QTP Template Script
Each test case will use a template script at the start. This script will copy all functions from the LAN and load them on the C Drive of the PC executing the test case. It will also build the infrastructure libraries if they don’t exist.
It will then execute a function.vbs file so at run time these functions will override the function library associated at build time.
The template script will be administered by QSA.
The location of the template is:
\\hcoprod4\Group\ QTP_MRS\REL23\Testcase\ActionTemplate.mst
The PC that will be running the automated scripts will reference the abovementioned Action template. A copy of this template is placed in C:\Program Files\Mercury Interactive\QuickTest Professional\dat
5.9. Completed Testcase
Each test case should have one or more QTP functions per step. The function should pass a return code back to the test case, therefore allowing QTP to pass Quality Centre the step status.
At the start of each test case, pre required data can be added. Most pre required data for MRS can be created using a test case that uses variables, e.g. first name and surname. A global variable is created which can be addressed anywhere else in the test case.
Any pre required data scripts exist in QTP_MRS/Rel23/Testcases. These testcases are reusable actions. The line RunAction denotes a called action.
The tester should ensure they have a good understanding of what is available. If new data scripts are required, it is best to model them off existing scripts.
A test case will appear as per the following example:
6. QTP – Connection to Quality Centre
6.1. Connection
Server Connection
From Quick Test Professional, select Tools; Quality Centre Connection and on the Quality Centre Connection page enter the following:
Server url: http://postapps/qcbin Click on button Connect
E.g. Project Connection
Domain: PROJECTQC
Project: MRS
User Name: QC_MRS
Password:
Other
Reconnect at startup: check this box.
Save password for reconnection on startup: check this box.
7. Maintenance Approach
To ensure that release changes of software can be accommodated by QTP, some tasks must be completed before running any tests.
7.1. Regression Test Changes
When a new release of software causes old functions to perform incorrectly, changes need to be done to these functions and object repositories to allow for testing to continue. These changes may be due to a new screen, a screen change or an object being seen differently in QTP, e.g. a change in a button name.
7.2. New Infrastructure
When building a new release of QTP Infrastructure, the first thing to do is build the infrastructure libraries as documented previously. This will give you the ability to make release dependant changes to old functions, scripts and Object Repositories in the new libraries.
Copy the QC folder within the project to a new version. This will allow for test cases changes in the new version of the QC folder and also keep the old QC folder as is. This will allow for easier reporting of the testing effort in the new release.
7.2.1. Building a new QTP Environment
As each new release of software is placed into an application testing environment, the QTP environment will need to be updated to allow for new functions, and the ability to run regression tests against the old software. The following tasks need to be performed to build the environment:
• The release specific infrastructure libraries must be created for the new release, as documented earlier in Section 4.
• The Object Repository for the current release must be “saved as” into the new release Repository folder
• The Function Library requires just a comment in it, so it does not appear as an empty file.
• The C:\TEMP\QTP_Start_Up.vbs file must be modified with the correct version of the application you wish to test with. Depending on the Release or Project, this is to be updated accordingly.
Once this is completed, restart QTP and ensure you are able to run a script through to completion. Any function changes can then be done by copying the function from the previous release’s function library and placing it into the new function library. From this new function library, you are then able to make the appropriate changes.
The following steps outline the build for new environment:
1. Open Windows explorer.
2. On network \\hcoprod4\qsa, open QTP_MRS folder
3. Create new folder e.g. REL31 and then create folders as per previous release:
- Documentation (to be empty)
- Functions (to contain blank function.vbs file)
- Repository (to contain empty repository file)
- Testcase (Copy Startup and QTP Startup from previous release)
- Txtfiles (to be empty)
- Utilities (to contain blank utilities.vbs)
4. Highlight the Testcase folder.
- Open up QTP Startup.vbs. Update release number in path
- Open up Startup.vbs. Update Dim Release +1 (2) and Add Release (2)
- Add Revision comments. Updates to be made in new function.vbs.
Subscribe to:
Posts (Atom)