Intelligent Test Automation | TurnKey Solutions
[pic]
| |
TurnKey cFactory 2.6 User Guide
Revision 2
TurnKey Solutions Corp.
Confidentiality Notice
The descriptive materials and related information in this document contain information that is confidential and proprietary to TurnKey. No rights in said material are hereby transferred to TurnKey’s Partners or Customers. This information is submitted with the express understanding that it will be held in strict confidence and will not be disclosed, duplicated or used, in whole or in part, for any purpose other than for information only.
Contents
Contents 1
1 cFactory 2.6 Overview 6
2 Using cFactory 7
2.1 cFactory 2.6 Environment 7
2.2 Launching cFactory 2.6 7
2.3 cFactory Main Window 7
2.4 Creating an ALM/QC Connection 9
2.4.1 ALM/QC Connection Pop-up 10
2.5 Create New Components 13
2.5.1 Setup Default Rules Base and Application Area 14
2.5.2 Learn Component 16
2.6 Editing Components 23
2.6.1 cFactory Component Editor 23
2.6.2 Editing Component Steps 31
2.6.3 Automating DFFs in Oracle 36
2.7 Saving Components 41
2.8 Batch Build Component Creation 43
3 Common Keywords 45
3.1 Web-based Keywords 45
3.1.1 WebEdit Keywords 46
3.1.2 Web List of Value (LOV) Keywords 49
3.1.3 Web CheckBox Keywords 49
3.1.4 Web RadioGroup Keywords 50
3.1.5 Web Table Keywords 50
3.1.6 WebButtons Keywords 54
3.1.7 Link keywords 55
3.1.8 Web Tables Error! Bookmark not defined.
3.2 OAF Extensibility Keywords 55
3.2.1 TKSWebEdit 55
3.2.2 TKSWebList 56
3.2.3 TKSWebCheckBox 56
3.2.4 TKSWebRadioGroup 56
3.2.5 TKSWebTable 56
3.3 Oracle Keywords 57
3.3.1 Oracle Text Field Keywords 57
3.3.2 Oracle LOV Keywords 58
3.3.3 Oracle CheckBox Keywords 59
3.3.4 Oracle RadioGroup Keywords 59
3.3.5 Oracle Buttons Keywords 59
3.3.6 Oracle Table Keywords 59
3.4 SAP Keywords 62
3.4.1 SAPGuiEdit Keywords 62
3.4.2 SAPGuiLOV Keywords 64
3.4.3 SAPGui CheckBox Keywords 64
3.4.4 SAPGui Button Keywords 65
3.4.5 SAPGui Table Keywords 65
4 Test Creation 68
4.1 High-Level Operational Flow 68
4.2 Creating Test Cases 69
4.2.1 Parameters 70
4.2.2 Adding Components 71
4.2.3 Grouping and Iteration 75
4.3 Creating Test Sets 78
5 DataDriver 81
5.1 DataSheet Creator 81
5.2 DataLoad from DataSheet 85
5.3 DataSheet Structure 86
5.3.1 Components 86
5.3.2 Data Scenarios 88
5.3.3 Screen Clips 89
5.3.4 Expanding/Collapsing Components 91
5.4 Entering Data into the DataSheet 92
5.4.1 Passing Data between Test Cases 93
5.4.2 Consumable Data 94
5.4.3 Linking 96
5.4.4 Data Support for Iterations 97
5.4.5 Complex Flow Control Using Group Iterations 103
5.5 Updating DataSheets 105
6 Executing Tests 105
6.1 Data Sources 106
6.1.1 Static Data 106
6.1.2 Dynamic Data 106
6.1.3 Run-Time Data 106
6.2 Setting Up a Run-Time Parameter 107
6.3 Test Results 108
6.4 Debugging 112
6.4.1 Debugging/Unit Testing Components 112
6.4.2 Debugging Test Plan 122
7 Component and Test Case Maintenance 124
7.1 Updating/Changing Components 124
7.1.1 cFactory Comparison Mode 124
7.1.2 Compared Steps 128
7.1.3 Fixing Updates 131
7.1.4 Accept/Reject Updates 131
7.2 Automatically Updating DataSheets 132
7.2.1 DataSheet Updates When Components Change 132
7.2.2 DataSheet Updates When Test Cases Change within Test Set 134
7.2.3 Data Repository Updating 145
8 Advanced Training Concepts 146
8.1 Application Areas 146
8.2 Manipulating the Object Repository 148
8.2.1 Capturing Objects/Formatting the Object Repository 148
8.2.2 Configuring object identification properties 148
8.2.3 Adding Simple Web Objects 150
8.2.4 Adding Web Tables (Non-Simple Objects) 154
9 TurnKey Software Customizations 158
9.1 Customizing Library and Keywords 159
9.1.1 Creating New Keywords 159
9.2 Customizing the Rules Base 161
9.3 Customizing or Creating Extensibility 164
10 APPENDIX 1 – Best Practices 167
11 APPENDIX 2 – Scoping Practices for Components 169
cFactory 2.6 Overview
cFactory is TurnKey’s component generation product family that enables users to create automated tests without having to write VB scripts. It also allows for data-driven testing. This technology allows users to:
• Automatically generate Keyword-driven BPT components through a discovery and rules-based analysis process
• Simplified component editing and maintenance
• Works in conjunction with HP QTP/UFT to capture one or more screens of an application and store them to an Object Repository (OR), which is part of a BPT Application Area file
• Keywords are included in libraries provided by cFactory and the Accelerator packages
o Keyword libraries are maintained and supported by TurnKey
o Keyword libraries can be extended as needed for unique or customized client environments
o Supports TurnKey’s “scriptless” test automation
• Imports the OR information, analyzes it using rules-based technology, and then creates BPT components directly in HP QC/ALM using supplied Keyword library files
• Supports multiple different application technologies through the use of a rules base (also called templates), which can be plugged-in to provide rules specific to a given application or type of application technology
• Rules files are written in universal XML/Xquery, and can be easily modified for unique applications or UI technologies – see the advanced section of the manual for the part of the Rules Base that customers can modify – if any modifications are needed, please contact TurnKey Support for guidance
• Data-driven architecture
• cFactory Supports:
o Oracle e-Business Suite
o SAP
o PeopleSoft
o Salesforce
o HTML
o .Net
o Java
o 3270/5250/Telnet
o Custom Software
o Legacy Systems
• TurnKey has built extensibility for custom applications not supported by QTP/UFT
o Please contact TurnKey Support for latest availabilities
Using cFactory
3.
4.
3.
4.
1 cFactory 2.6 Environment
Note: Please see release notes for latest certified versions
Additional Requirements:
• Microsoft Excel 2013, 2011, 2010
• Altova XML Conversion Tool
2 Launching cFactory 2.6
Make sure that you have launched and logged into the following applications in the given order before launching cFactory.
• ALM with BPT
• QTP / UFT
During installation, an icon is added to the desktop for launching the application. After you have ALM and UFT open, you can launch cFactory by double clicking the icon.
[pic]
Note: It is recommended that cFactory be opened before the application for which you are creating components.
3 cFactory Main Window
You will see the main window when you launch cFactory. Below is a screen shot of the application when it first launches. You will notice that at first the editing features are grayed out. These will become active when you create a new component or open an existing component.
[pic]Task Bar
The Task Bar contains all functionality. These functions are also provided in the application menu.
[pic]
[pic]Ribbon
The Ribbon contains basic editing tools that would be needed to manipulate the steps of the components in the component editor for quick and easy access to key functions
[pic]
[pic]Component Workspace
This is the main workspace of cFactory 2.6, where you will create, edit and save components.
[pic]
[pic] ALM Connection Information Bar
The ALM Connection Information Bar tells you what domain, project and user is associated with cFactory.
[pic]
4 Creating an ALM/QC Connection
The cFactory application needs to be connected to an Application Lifecycle Management (ALM) or Quality Center (QC) Project in order to create or update components.
The very first thing to do after opening cFactory is to establish this connection.
To do this, click the “ALM/QC Connection” button (it looks like a blue ball with a wire connected to it) or open the Application Menu and click on "ALM/QC Connection” as shown below. Once clicked, a pop-up window with the connection information will show up. You can also click the “New Component” button (it looks like a blank piece of paper) and it will also open the connection window since you can’t create a component without being connected to a project.
[pic]
[pic]Application Menu
[pic]
[pic]ALM/QC Connection
Clicking this option opens up the pop-up window that allows creating a connection to ALM/QC.
[pic]ALM Connection Status Bar
[pic]
The ALM Connection Status Bar shows the ALM/QC project that you are connected to and the current ALM/QC user name in the main cFactory window.
1 ALM/QC Connection Pop-up
After clicking the “ALM/QC Connection” button, the following pop-up window will open. This is where you will specify which ALM/QC project that you want to connect to.
You will need to provide the URL Address of the ALM/QC Project along with the credentials for the user you want to login as.
After providing that information, you can choose the Domain and Project from the list of Projects that the user you logged in as has access to.
The content in the following screenshot is for illustrative purposes only.
[pic]
[pic]Server Address
[pic]
This is your ALM/QC Server Address to connect to. Enter the ALM/QC URL. It should end with “/qcbin”.
[pic]Automatically connect to this server on startup. Check Box
[pic]
Automatically connect to this server on startup. Select this checkbox if this is the ALM/QC Server to connect to whenever starting the application. This connection can always be changed after starting cFactory if necessary.
[pic]Connection Button
[pic]
Click the “Connect” button to connect to the ALM/QC Server specified in the Address field.
[pic]User Name
[pic]
This is the User Name. Enter the ALM/QC User Name of the User to login as.
[pic]Password
[pic]
This is the Password for the User Name provided above. Enter the ALM/QC Password for the User provided in the User Name field.
[pic]Automatically connect to this user on startup. Check Box
[pic]
Automatically connect to this user on startup. Select this checkbox if this is the User Name and Password to connect to whenever starting the application. This connection can always be changed after starting cFactory if need be.
[pic]Login Button
[pic]
Click the “Login” button when the ALM/QC User Name and Password have been entered. This button will only be enabled once the ALM/QC Server connection has been made and the User Name and Password are provided.
[pic]Domain
[pic]
This is a dropdown with the list of the ALM/QC Domains available to the User Name that was logged into. Select the Domain of the project to connect to.
[pic]Project
[pic]
This is a dropdown with the ALM/QC projects that are associated with the Domain that was selected in the Domain dropdown. Select the Project to connect to.
[pic]Automatically connect to this project on startup. Check Box
[pic]
Automatically connect to this project on startup. Select this checkbox if this is the ALM/QC Domain and Project to connect to whenever starting the application. This connection can always be changed after starting cFactory if need be.
[pic]Select Button
[pic]
Click the “Select” button once the ALM/QC Domain and Project have been selected to connect to the project. This button will only be enabled once an ALM/QC Server connection has been made, a user has logged in, and the Domain and Project have been selected.
[pic]Close Button
[pic]
Click this button once you have finished connecting to the QC Project to close the Pop-Up window.
5 Create New Components
This section contains the steps for creating a new component and editing it to fit your automation needs.
Before creating the components, an Application Area (AA) needs to be created that has the Function Libraries suited for your Application. Application Areas will be covered in more details later on in the training document. This can be found in the “Advanced Training Topics” section.
There only needs to be one Application Area (AA) for each of your applications that you are building components for, but there can be more if you desire.
1 Setup Default Rules Base and Application Area
Before you can create a new component, you need to select the default Application Area (AA) and default Rules Base to use when building the components.
The Application Area (AA) determines the keywords that are available for each object type on the screen based on the Keyword Libraries that are associated with it. The Keyword Libraries are function libraries where the keywords are stored. They are .vbs files that are stored in the Test Resources of ALM. The libraries are then associated with the Application Areas that are used when building components. Having the correct libraries associated with the AA that is being used to build the components allows the correct keywords to be available for the different object types.
The Rules Base is the set of rules that cFactory follows in order to create components. The Rules Base was designed with the goal of automating as much manual repeatable work as possible (even when it comes to script creation). Therefore, the design/layout of components was to make them reusable, independent, user-friendly sequential steps.
The Rules Base is made up of two files. The first is a .template file with the name of this file being the name of the Rules Base. This is a file created by TurnKey with the rules for the structure of the component. For example, in this file is the rule that tells cFactory to add the DataLoad operation as the first step of every component. This file is encrypted and cannot be edited by anyone except TurnKey.
The second file is an .xml file which contains the default keywords used for all of the object types that can get added to the component. TurnKey refers to this component as the Defaults.xml file. For example, in Oracle Java Forms, when an OracleEditBox is in the Object Repository and gets added to the component, the .xml file has a rule that says the default keyword is Enter_TKS. This file is not encrypted and can be modified. Once you have identified all of the major keywords (functions) you would like to use during the automation of an application, you need to decide which of those you would like to associate with the different object types. The goal is to automate as much manual, repeatable work as possible (even when it comes to script creation). Therefore, you should think of what keywords you will use most for the different object types and make those the defaults.
Navigate to the Configurations Tab by clicking on the "Options" button or the “Options” menu item under the Application menu.
[pic]
[pic]Open the application Menu by clicking the [pic] cFactory Icon.
[pic]Click on Options.
Under the "Component Generation Tab", select the default AA and default Rules Base to use when building the components.
[pic]
The AA determines the keywords that are available for each object type on the screen and the Rules Base determines how the component will be built.
This tab contains the default settings for generating component from learned objects.
Select the Rules Base that you want to use for your application.
Select the AA that has the Function Libraries with the keywords you want to use in your components.
You can also assign the dataDriver Parameter Descriptions and their Colors on this tab. These descriptions will color code the DataSheet.
Note: If you have not connected to an ALM/QC project, the AA List will be blank since the AA’s are stored in the Test Resources module of the ALM/QC project.
2 Learn Component
Now that you have selected the Default Rules Base and Default AA, you can begin to create new components. The first step is to capture or learn the screens of the application. You will start from the Application Menu by clicking "Learn from Application" or clicking the “New Component” shortcut button on the main window.
If you have not selected a rules base, an application area or created an ALM/QC connection, you will be prompted to do so.
After clicking on "Learn from Application", the “Learn” window will open. Here you will choose the learn option and the cFactory window will minimize and change the mouse pointer to the [pic] "hand" cursor. You will now be able to click on an application window (object) that you would like to capture. After this, an Object Selection window will appear.
[pic]
Next the Learn pop-up prompts us to choose what Rules Base and Application Area to use. We also have the choice to click “Learn” or “Advanced Learn” to continue.
• Rules Base – A Rules Base is a set of Rules that allow cFactory to understand how screens and regions of an application are to be divided into components, how those components should be constructed and what keywords are to be used for the objects on the screen. For this example we are using SAP however we support many applications today and can easily create a Rules Base for most any application.
• Application Area – This is the BPT Application Area used for testing your application. It is important that the Application Area has the correct libraries so the proper keywords are available to cFactory. It is best practice to only have one pair of Rules Base and Application Area and that their names be understood to work for each application. This will make it easy to make the correct choice.
• Learn – This will be the option you use most often. After clicking on this, the cFactory window will minimize and change the mouse pointer to the [pic] "hand" cursor. You will now be able to click on an application window (object) that you would like to capture. After clicking on the application, the “Object Selection” window will appear in UFT. The “Object Selection” is explained in the next section.
• Advanced Learn – This option will behave the same as “Learn” however once you have completed the “Object Selection” you will be prompted with the “Object Repository”. This is useful for applications that may require some manual intervention when collecting the object information. Such manual intervention could include renaming objects, modifying recognition properties, adding new objects not in the “Object Selection,” etc.
1 Object Selection - Add to Repository Window
Once you have clicked on the object (in the application that you want to create components for) the UFT “Object Selection” window will appear. Either select the single field (also called the child object) that you had clicked on, or select the form/page object (also called the parent object) to create the component.
If you select the child object, only that object will be added to the component. If you select the parent object (as is shown in the image below) all of the objects on the form/page will be added to the component. Selecting the parent object is the recommended method.
[pic]
[pic]Select the container object you want to make a component for. Most of the time this will be called a “Page”, “Form”, or “Window”. Selecting the parent is the recommended option so that all of the fields on the screen get learned.
[pic]Click the ‘OK’ button. Because you selected a parent object from the list, the “Define Object Filter” Window will show up when you click OK.
2 Define Object Filter Window
If you selected a parent object in the “Object Selection” Window, the “Define Object Filter” Window will open. In this window, you can select what object types to add to the component.
[pic]
[pic]Select this option if you want to add only the object types that you define. This is the recommended selection for most components. You can customize which object types you wish to automate and which types you want to ignore.
[pic]This button is enabled when the “Selected object types” option is selected. Click this button to open up a list of all object types in the “Select Object Types” Window. From this list, you can define what object types to add to your component. This is the recommended selection if you are not using the Default object types.
[pic]Once you have selected which object types to add to the component, click the “OK” button. The “Component List View” Window will be displayed.
3 Select Object Types Window
[pic]
[pic]Select the object types you would like to capture. Each UFT/QTP add-in and extension will add object types to this list. Please note that you do not want to have all object types captured by default. For example, Buttons, Images, and Links may be automated using descriptive programming and do not require an object to be captured. Uncheck these objects to keep the object repository clean. Object types are discussed later in this document. You will notice that these different applications have similar objects selected like Edit Boxes, Check Boxes, List Boxes, etc.. Below are lists of recommended objects to capture for a few different applications. Also, the more objects you have selected, the longer it will take to analyze the screen. This can also increase the size of the object repository that needs to load for the component.
Web Objects to Select
Browser: Browser
Check Box: WebCheckBox
Edit Box: WebEdit, WebFile
List: WebList
Radio Button Group: WebRadioGroup
Web Page: Page
Oracle Objects to Select
Check Box: OracleCheckBox
Edit Box: OracleTextField
Error/Message Window: OracleNotification
Form: OracleFormWindow
List: OracleList
List of Values: OracleListOfValues
Radio Button Group: OracleRadioGroup
Tab Strip: OracleTabbedRegion
Tree: OracleTree
SAP Objects to Select
Check Box: SAPGuiCheckBox
Edit Box: SAPGuiEdit, SAPGuiTextArea
List: SAPGuiComboBox
Radio Button: SAPGuiRadioButton
Session: SAPGuiSession
Tab Strip: SAPGuiTabStrip
Tree: SAPGuiTree
[pic]Click OK to continue after setting the Object Types.
4 Object Repository
If you selected the standard “Learn” option, it would now go to the “Select Component” Window of cFactory. If you selected “Advanced Learn”, at this point the Object Repository will open in UFT.
[pic]
You can rename the objects by right clicking on it and selecting rename.
You can change/update the recognition properties in the Object Properties section on the right hand side of the window. The most common changes in the OR are renaming objects so they have a more logical name or adding regular expressions to the object properties. Regular expressions are a way to allow the tool to recognize an object if its properties have a consistent pattern but the details change over time. For example, if your application displays the Sales Order or Purchase Order number in the title, that title will change every time you create a new Sales Order or Purchase Order so the window would not be recognized the second time you ran the component. To get around this issue, a regular expression can be added to the title property to recognize the window no matter what Sales Order or Purchase Order number is displayed. Regular Expressions are covered in more detail in the “Advanced Training Concepts” section of the manual.
5 Select Component Window
After selecting the object types you want to add to the component in the “Object Selection” Window, the “Select Component” Window will open in cFactory. This list is the possible components to create for objects you just learned. You will notice that there is a component for the different sections of the screen. You will also notice that there is a verification component along with the standard component for each section.
The standard component has the default keywords typically set as an editing action while the verification component has the default keywords typically set as a verification action.
Next to each component, there is a checkbox. You have the ability to create more than one component at a time. Simply select the checkboxes next to all of the components in the list that you want to create.
[pic]
[pic]Select the component/s that you wish to build.
[pic]Click the “Select” button and the main cFactory window will open with the new/updated component steps.
After clicking the “Select” button, the main cFactory window will open with the newly built component.
Each cFactory component has some typical steps that are automatically added for that rules base. These steps are at the beginning and end of the component and cover the functionality for data management, screen capturing, and navigation.
[pic]
This example illustrates the typical functionality of an Oracle component but similar steps are added to all components, no matter what application they are created for. At the top is LoadData. LoadData is the data management function that locates the current component data from the source Excel DataSheet and loads it into the component. Next we verify that the application is in the expected place for reporting purposes. For some rules bases, we may have a navigation step that involves clicking on a tab or menu item before verifying the screen.
At the bottom cFactory typically adds two steps. First, CaptureScreenClip_TKS which will take a screen shot when the Test Set “Screen Clip(Y/N)” user-defined-field is set to ‘Y’ (Yes). This setting is explained in section 4.3 Creating Test Sets. Next is the ClickButtonText_TKS, which allows the user to provide the “Button_Label” name information since most screen entries or changes do not take effect until you click something. Which functions you see at the top and bottom of a component vary depending on the target application you are testing; however, the types of functionality that they handle are the same.
6 Editing Components
1 cFactory Component Editor
The editor becomes available once a component has been learned or a component is opened.
The component editor shows the automation steps for a component. You can modify these steps directly in cFactory and any changes made to the component are automatically stored in ALM/QC after hitting the “Save” button.
[pic]
[pic]Editing Bar
The Editing Bar contains multiple options for editing the component steps. They will be covered in more detail later in the document.
[pic]Editable Component Steps
This is where the component steps are listed. You can modify each step to fit your automation needs. You will notice that every component you create contains LoadData as the first step. Do not modify, move or delete this step.
[pic]Component Tab Listing
You can have more than one component open at the same time. They will show up here as separate tabs. In this example, there is only one component open so you only see one tab.
1 Component Steps
This section describes the component steps section of the cFactory window.
[pic]
[pic]Step Number
This is the automation step number for a given object. If you move the steps around, the number will automatically change. You cannot manually change the step numbers.
[pic] Item
This is the Item/Object that the action is being performed on. This row will typically be the objects from the application you are creating the component for, but can also contain an Operation (see step one, LoadData, of this component). An Operation is an action that is being automated that is not tied to a specific object type. This can be changed by selecting a different object or the Operation icon from the dropdown list. Simply select the current item and click the icon on the right of the field and the dropdown list will show up.
[pic]Operation
[pic]
This is the operation/action that the automation step is doing. This is a dropdown field and can be changed to any of the keywords in the list. The list of operations that are available will change depending on which object is being automated. This list is also dependent on the Function Libraries that are in the Application Area that is associated to the component, so it is important to have to correct function libraries in the AA.
To help you understand what each keyword is for, we have added a description to the right of each keyword. To get a more complete description of the keyword, simply click the [pic]icon next to that keyword and the help file page will open.
[pic]Value
This is the data value that will be used for this automation step. If the value is never going to change between runs on the test, the value can be made a constant. Typically, for most objects, the values will change between runs so a component parameter is created with the same name as the objects. For every component parameter, a column is added in the DataSheet that is created for the test. To add an Input value, simply open the following pop-up by clicking the ellipse (…) button and enter the desired information.
[pic]
Select whether you want the input to be a Constant Value or a Parameter (which will get the data from the DataSheet). Enter a name for the parameter after clicking the “+” button, typically this should be the same name as the field. You can also make the input a Local Parameter instead of a Component Parameter. The Local Parameter value will not come from the DataSheet and in fact, they will not have a column in the DataSheet. They are only used inside the component. The value stored in the Local Parameter will typically come from a prior step that outputs the Local Parameter. Click OK to close the Value window.
This description is what color codes the DataSheet. The color coding is explained in the DataSheet section of this manual. When you click on the parameter, you will notice that the back ground will show a color based on the description so you can quickly identify what the description for that parameter is. There are two ways to change the description. For your convenience we have added a menu when you right click on a parameter that will show you the Parameter’s “Description.” You can open the pop-up mentioned above and type it in the Description field or you can right click on the parameter in the main window and choose the radio button that corresponds to the desired description.
[pic]
[pic]Output
This is the output of the automation step. This can be a Local Parameter that can be used within the component at a later step or an Output Parameter that can be used in other components and gets saved to the DataSheet. To add an Output value, simply open the following pop-up and enter the desired information. Select the type from the Parameter Drop Down and then type the name of the parameter into the Name field after clicking the “+” button. Typically, you will not give it a Value or a Description.
[pic]
[pic]Documentation
This Documentation column on the right is a statement describing the action the step will take. This statement is often compiled with the values and parameter names added to the statement. This statement was written in such a way that someone would be able to understand and execute the step manually if they chose to.
2 Component Group of the Editing Bar
[pic]
Properties
Click on the Properties button to bring up the “Component Properties” Window. This window contains all of the component details. These are the same details that can be seen in ALM/QC on the Details tab in the Business Components Module. You can add descriptions, comments and modify any of the user fields. The user fields that are shown in this window are the same as the user fields in ALM/QC.
[pic]
Highlight
Click this button when a step of the component is selected and cFactory will attempt to highlight that object in the application. The application should come forward and a black border will flash around the object of that step. Note: Only one object can be highlighted at a time.
Advanced Mode
This button will have you save the component in ALM/QC and then it will reopen it in QTP/UFT. This option can be used to quickly switch to QTP/UFT for unit testing the component if any is needed. Note: Unlike cFactory, QTP/UFT can only have one component open at a time so only the component that is selected when you click the Advanced Mode button will be opened in QTP/UFT.
Snapshot
Click on the Snapshot button to bring up the component “Selection Editor” Window.
[pic]
This window will allow you to capture a picture of the application and save it as the Component Snapshot. Click the Capture Screen Area Button. A grey transparent box will open. Simply resize the window and position it over the screen you want to capture. When you are ready to capture the snapshot, click the camera icon that is in the center of the box. This will bring you back to the component Selection Editor window. If the image is what you want, click the Attach button. If you want to change the image, simply re-click the Capture Screen Area button.
1 Script Engine
The Script Engine is a solution that allows Test Automation Engineers to design QTP/UFT scripts to do automation work that benefits the creation and maintenance of BPT components.
The solution is made up of 2 independent features. The cFactory API and Script Engine Interface Fig 1. Both features are independent and can be used separately if desired.
The API allows for the creation, discovery and editing of components in cFactory. The Script Engine Interface allows the user to launch QTP/UFT scripts. These scripts will work with the API and the application under test to accomplish additional component work that would not be possible by analyzing the OR alone.
Fig 1.
[pic]
1 Script Engine Interface
Figure 1 shows the Script Selection list box and the Run button that are in the Editing Bar. Simply select your script and click the run button. The selection will be limited to the scripts that you have developed and the scripts that are prepackaged with cFactory.
Adding a Script
To add a script to cFactory you will first need a Script Library folder existing or added to the Templates folder of cFactory (Usually: C:\Program Files (x86)\Turnkey Solutions Corp\cFactory\templates). The folder will be named the same as the Rules Base with the suffix of “Script Library”. Example: “Custom Oracle Web Script Library”.
Once you have a Script Library folder for the Rules Base you can place any .vbs file in that folder and it will appear in the Script Engine Interface.
2 cFactory API
The script you create will be up to you. The cFactory API allows you to edit any component loaded in cFactory and create new ones.
Getting started
Code Examples will be in VBScript though the cFactory API is a COM API so other languages can be used but will have to apply their own model and syntax.
In VBscript you will use the GetObject operation to create an object for “cFactory.Application”.
Example: GetObject(,""cFactory.Application"")
When sending a script to QTP/UFT with this statement it will fail UFT’s Syntax checker because of the empty first argument. The script will be prevented from running so to prevent this we wrap the operation in an Eval argument and the Syntax Checker ignores the string of text.
Example: Set cF = Eval("GetObject(,""cFactory.Application"")")
Once you have the cFactory Application object you can work with the current active component through the cF.ActiveComponent object. Most of what is available in the cFactory user interface for a component is available from the ActiveComponent object. The API also allows you to change the active component and create new ones. You can also make your script to create new component steps for different object types. For example, column names are not captured by UFT for SAPGuiGrid objects. This means if you create a component for this object type, you won’t see steps for each of the columns like you do with other table objects. After creating the initial component, you can run a script from cFactory that will go analyze the columns for the grid and then the script will create steps for each of the columns it finds. This is just one example of what a script can be built to do.
4 Editing Component Steps
It is often necessary to make small changes to a component to make it do something different from the usual flow or function. It is also sometimes necessary to combine the functionality of more than one component into a single component. For this reason, cFactory 2.6 is equipped with a fully functional editor. Because cFactory allows multiple components to be open at the same time you can copy steps from one component to another.
1 Changing Object Names and Operations
Sometimes it is necessary to change the objects within a component:
[pic]
[pic]Object Name
You can change the name of an object directly inside of any step where that object is being used. There is no need to open the object repository to do this.
Once you have changed the name you may see that the parameter of the same name has also changed. This happens for all arguments that are named "DataValue". If the argument that keyword is not “DataValue” then cFactory will not automatically update the parameter name to match the object name. You will manually have to make this update.
cFactory does this in order to reduce the number of steps it takes to rename an object and its associated parameter.
[pic]
You will also notice that the parameter is now shown in red. This indicates that you need to open the pop-up for this parameter and verify that it is named the way you want it and the description is also set properly. As soon as you verify this, click the OK button on the pop-up and the parameter will no longer be red. Note: You cannot save a component if any of the parameters are red.
Furthermore, a user may want to change component step operations:
[pic]
[pic]Operation
You can change the operation that you wish to perform against an object by selecting it from the drop down list. If the new operation has an argument named DataValue that argument will automatically be assigned a Parameter with the same name as the object used in the step. Otherwise, you will need to provide the Parameters. Note: When you open the drop-down for the keywords available for the object, you will see three columns. The first contains the link to the Help File Page, the second contains the keywords and the third contains a brief description of what that keyword actually does.
Section 3 contains a list of the most common keywords. Please see the provided Help File document for more information on what keywords are available and how to use them.
2 Change Argument Value
Click the [pic] Button to change the argument values. When you do, the Value window will come up.
Value window
[pic]
[pic]Constant
Choose the Constant option to provide a constant value to the argument.
[pic]Parameter
Choose the Parameter option if you will be using a variable value for the argument. You will need to pick a parameter from the Name dropdown or create a new parameter to continue.
Parameter Name
The parameter name should represent the screen field name exactly. Put an underscore (_) between words. The system will not accept spaces between words. All fields in the current screen should be added as a parameter at the time of creation. This helps with the maintenance of the component. If you already have all the steps and your new scenario needs data entered in a new field, you won’t have to update the component. You can just update the DataSheet with the new data.
By default most application screens will flow from left to right – top to bottom so the order of the steps and parameters are created in this order. In the case of tables the order is determined by the “column names” property.
Default Value
In most cases there is not a default value as the component will use the DataSheet to retrieve the value needed to run the component in a test case. Where there may be static data that will never change, the value can be put in this field (this is not recommended though). If you decide to add data here, the first line of the DataSheet will be filled with this data. Note: If you change the value in the DataSheet then the DataSheet value will be used. Data in the DataSheet trumps the data in the default value field.
Description
In the description, change the value to either “REQUIRED:”, “OPTIONAL:”, “VERIFICATION:” or “EXCLUDE:”. These will be reflected in the DataSheet.
REQUIRED: If the data defaults in to the screen, or data input is required, then the component parameter will be labeled as “REQUIRED:”. These will be highlighted yellow in the DataSheet.
[pic]
OPTIONAL: This is the default description for all parameters and represents fields which can be left blank or optionally entered. If the data input is optional, the description in the DataSheet will be white.
VERIFICATION: Used to ensure that specific data elements in a component are correct. Typically, data in these fields defaults in from other screens or it is a display type of screen. Specifying that “VERIFICATION:” is needed, will cause the associated DataSheet column to be highlighted in blue. The associated automation step keyword should also be a verification type operation so that the parameters designation of “VERIFICATION:” and automated step both match.
Additionally, Output columns in the DataSheet are highlighted in green. They do not need to have a description. They are automatically highlighted green. An output column is one where data is captured during the test run from the application.
[pic]
[pic]+ button
To add a new blank parameter to the parameter list, click the ‘+’ button. You will need to provide a name for the new parameter in order to continue. This is how you can add new input and output component parameters. After clicking the button, the Name field will become blank. This signifies that a new parameter is able to be created. Simply type in the name of the parameter to be added and it will be created.
[pic]OK button
Click the “OK” button when finished
3 Cut Copy Paste
[pic]
Cutting, Copying and Pasting can be done within a single component as well as from one component to another. This allows you to merge steps between two or more components. When copying/cutting between two components, the objects that are being copied are moved into the Object Repository of the component to which they are being pasted.
[pic]Cut
Select one or many steps (by using shift or Ctrl when selecting) and Cut by either by right-clicking and selecting “Cut”, or by selecting “Cut” from the tool bar.
[pic]Copy
Select one or many steps (by using shift or Ctrl when selecting) and Copy by either right-clicking and selecting “Copy”, or selecting “Copy” from the tool bar.
[pic]Paste
Paste by either right-clicking and selecting “Paste” or selecting “Paste” from the tool bar. The steps will be pasted below the currently selected automation step.
5 Automating DFFs in Oracle
Descriptive FlexFields can occur in the header of an Oracle form and/or in the Oracle tables as seen in the picture below.
[pic]
DFF’s are highly customized therefore they are automated as part of the business component for the area of the form in which they reside. For instance, the automation for DFF “1” in the screenshot above will be automated in the business component for the Purchase Order Header component. Since they are so customized, we do not include them in the components that are delivered to you. Therefore, you will need to add the steps of your DFF’s to your components.
Adding the steps for the DFF to an existing component is simple. The first step is to open the component that will contain the DFF in cFactory. Once the component is open, navigate to the form where the DFF is opened from and open the DFF. To add the steps of the DFF to the open component, you will learn the steps from the DFF like you are creating a new component. Return to cFactory and click the “New Component” button. When the mouse turns to a pointing hand, click in the DFF. You should see the following pop-up in UFT.
[pic]
Select the OracleFlexWindow object and click OK. The Object Filter window will open.
[pic]
Select “Default object types” and click OK. cFactory will then create a new tab with the steps for the DFF.
[pic]
You will notice that this tab does not have the traditional steps of a component. There is no LoadData step and no VerifyExist_TKS step. It only contains the steps for the fields on the DFF and a CaptureScreenClip_TKS. This is because we do not create DFFs as stand alone components, but instead, add the steps in to existing components.
Return to the original component tab. The component will not have a step for the field that the DFF is opened from. Select the line in the component that will be right before the DFF steps. For example, in the Purchase Order Header, the DFF is at the bottom right of the screen so it will be the last step of the component before the CaptureScreenClip_TKS and ClickButtonText_TKS steps. So I will select the step right above those two and click the Add Step button. In the Item column for the new step, open the drop down window. This will show you all of the fields that were captured when the component was built. Find the field that the DFF is opened from and select it.
[pic]
Now in the Operation column, select the OpenDialogIfNotOpen_TKS keyword. In the Value column, open the Value window but clicking the ... button.
[pic]
In this window, you will enter the title of the DFF in the Constant field. This is telling the automation step the title of the DFF to open. Your step for opening the DFF should look similar to the image below.
[pic]
Now that you have added the step to open the DFF, you need to add the rest of the DFF steps. Return to the DFF tab that was created earlier and copy all of the steps. Then return to the main component and paste the steps under the step for opening the DFF. It should look similar the the image below.
[pic]
The final thing to add to the component is a step to click one of the buttons on the DFF. Select the CaptureScreenClip_TKS step for the DFF window. Copy the step and then hit the paste button. This will create a new step for the DFF window. Change the keyword to ClickButtonText_TKS and in the value column, add a new parameter and call it something along the lines of DFF_Button_Label so that you can differentiate the button label for the DFF window from the button label for the Form window. Your step should look similar to the highlighted step below.
[pic]
Once you are finished adding all of the DFFs to the component, you can save it. It is now ready to be run with the DFF steps.
7 Saving Components
The save option allows you to save a component to your ALM/QC project or the hard disk (File System). After clicking the “Save” button, the following window will show up.
You can choose the relevant tab from the window and then browse to the location where you would like to save a component. The components must be saved in the ALM/QC project if they are to be used in a test case. If a component is saved to the file system, it is saved with a proprietary file type. It can then be sent through email or saved on a shared drive. To get that component into an ALM project, simply open the component with cFactory and do a Save As into the ALM project.
[pic]
[pic]Folder Structure
This is where the folder structure is displayed. The component can either be saved in the ALM/QC project (by selecting the ALM/QC Tab), or it can be saved to the local File System (by selecting the File System Tab). A folder must be selected before the component can be saved. The save button will be disabled until a folder has been selected and the component has been given a name.
[pic]Component Name
Enter the name for the component that is being saved. Be sure to name the component something meaningful so that test case creation will be straight-forward.
[pic]Save Button
Click the “Save” button to save the component in the selected folder.
[pic]Cancel Button
Click the “Cancel” button to stop the saving of the component.
8 Batch Build Component Creation
This section contains the steps for creating a batch of new components from an Application Area and Object Repository. You must have an Application Area and Object Repository already created in order to use the functionality. Most of you will not be using this method. It has been added mainly for backwards compatibility and for customers who may have shared ORs built in a manner that this could be used to convert to components.
Central to the success of creating clean and clear components in Batch Mode is to create clean and clear object repositories in the application areas in UFT. Since cFactory analyzes the tree structure, it must be organized in a uniform manner so that cFactory can systematically read the parent and child objects to create each of the business components. Best Practice is to create an object repository for each screen, section of a screen, tab or table in a screen.
cFactory adopts the naming convention used when capturing the parent and child objects in UFT. It is recommended that objects be named to reflect what is shown on the screen of the application. cFactory will create components using these names in the naming of the parameters and the component itself.
1 Batch Build Window
To create a Batch of components, you will need to click the "Batch Build" option of the Application Menu.
It will open the batch build window
[pic]
[pic]Application Area
This is the Application Area to analyze to find the components to build. Select the Application Area from this list.
[pic]Rules Base
This is the Rules Base to use to create the components with. Select the Rules Base that corresponds to your application.
[pic]LIST COMPONENTS Button
Click the LIST COMPONENTS button to analyze the Application Area selected above. This will generate a list of components based on the Object Repository that is in the Application Area.
[pic]Component List
This is the list of components that are possible to build from the Application Area that was selected above. This list is empty (shown above) until you click the LIST COMPONENTS button. See below for an image with the components listed.
[pic]Component Folder Structure
This is the component structure of your ALM/QC project. After selecting the components you want to build from the component list to the left, you must select a folder to build the components in.
The window should look similar to this once you have clicked LIST COMPONENTS and selected a folder from the folder structure.
[pic]
[pic]CREATE COMPONENTS button
The CREATE COMPONENTS button will be enabled after you have selected components to build from the component list and you have selected the folder to build the components in from the component folder structure. Click this button to build the components.
[pic]Status bar
The status bar will say “Building...” when it is in the process of building the components. It will say “Ready” when it has finished building the components. You can then open the components from the main cFactory window and make any changes to the component that are desired.
Common Keywords
Since keywords are the building-blocks of components created by cFactory, it is important to understand the most common ones. These are grouped by functional type: Web, Oracle, and SAP.
5.
1 Web-based Keywords
Note: All keywords that are discussed in this section have and ending of _TKS. This simply means that it is a keyword developed by TurnKey Solutions.
1 WebEdit Keywords
WebEdit keywords allow you to enter values into a Text Field with the value being taken from the DataSheet.
Here is a sample web page:
[pic]
Data needs to be entered into the “Description” field.
If you click on the dropdown in the Operation column for the “Description” object, you can see all of the possible keywords that are defined for this object type (WebEdit):
[pic] [pic]
If the step was as follows,
[pic]
The operation would optionally set the “Description” object to a value based on its parameter’s value. The data that is provided in the DataSheet will be entered into this field.
There is a separate keyword if you need to enter a value where the page would perform data base validation for that value – let’s say the “* Buyer” field.
[pic]
The application would look for that value, and if it finds the exact match, it would leave the value typed into the control as it is.
“EnterWait_TKS” could be selected – this behaves exactly as Enter_TKS and then waits for one second to give enough time for the web page to perform/validate the search criteria.
However, what would happen if the value is a “partial match” to the existing value? For example, you want to put the value “TurnKey1” into the field, but “TurnKey1” is actually also a partial value of “TurnKey10”, “TurnKey11”, etc…
[pic]
The following pop-up that might be displayed when putting value “TurnKey1”. In that case, you would use the “EnterMore_TKS” keyword.
[pic]
[pic]
In this example, the component will optionally enter the value provided for the “Buyer” parameter value into the Web Edit field, then it would wait for a few seconds for the page “Search and Select List of Values” to appear. If that page appears, it would try to select the value provided for the “Search By” criteria if the “SearchBy” parameter value was provided, and would click on the “Go” button. Then it would look for the first match in the “Last Name” column of the table, would select the appropriate radio-button and then would click on the “Select” button, would verify that “Search and Select List of Values” popup disappears, and only then it would report a “Pass” status for this step. If something went wrong at that time – it would report the appropriate failure. Since there are many fields with the “search” icon, it makes sense to create a more complex keyword like this to handle those types of scenarios. The main objective here is to be able to enter values into all fields for this Web Page tab so that all those steps would be in the same component in order to keep the code organized, reusable and user-friendly all at the same time.
The keyword “EnterMoreSlow_TKS” is the same as EnterMore_TKS. The only difference is that it waits a few seconds after the popup has been closed (for example, in some rare cases, you need to wait in order to the application enough time to refresh itself).
You may want to enter a value for controls only if those controls appear in the application; in those cases, you would use “EnterIfExist_TKS” keyword.
Capturing value from the screen within a component:
If you need to output a value into the DataSheet from the application, you would use the “OutputToSheet_TKS” keyword.
[pic]
For that case, you should tell the keyword what Excel column to use so that output value in the DataSheet will be written to the appropriate excel column. We also define and select an “Output” parameter so that the DataSheet Creator will generate that output column in Excel in advance.
Note: ALM/QC provides linking of input parameters to values of output parameters in components within ALM/QC, however, TurnKey recommends all linking within DataSheets so that users do not have to modify test cases. All you have to modify are data files – the ALM/QC test cases would remain static.
Please see the Changing Argument Values section for steps on how to add the Output Parameter.
[pic]
NOTE: The excel column name provided in the “Value” column should match the name of the Output Parameter.
Verifying value within a component
“Verification” keywords are available for every object type where you want to verify a value. TurnKey does not use standard HP checkpoints so that checkpoints are dynamic and easily-updateable from the same DataSheet where the values are being provided and saved to.
For example, you may want to capture a value from the application on one form, and then later verify that this value is persistent on another form or page.
The first step for verifying a value is to select the “Verify_TKS” keyword in the Operation column. A parameter will then need to be added to the Value column so the actual value being verified will be provided in the DataSheet.
[pic]
And the resulting step is showed below:
[pic]
VerifyDefault_TKS is similar to Verify_TKS, except all it does is it verifies that the field is not empty. If the field is empty, it will report a failure. If the field is not empty (no matter what value except empty spaced), it will report “Pass”, indicating that field value is not empty.
2 Web List of Value (LOV) Keywords
The default keyword for the List of Value (LOV) control is Select_TKS that would select a single item from the LOV control.
[pic]
It is very similar to “Enter_TKS” which is for WebEdit control.
One trick that’s worth mentioning, is that when you have the first value in the drop-down that is empty, and in fact you want to set the field to that empty value, you should use the “” variable in the Excel DataSheet, and it will set it to the value “#0”, which usually corresponds to the empty value for that LOV control.
“OutputToSheet_TKS” works the same way as for WebEdit control. “SelectIfExist_TKS” works the same way as “EnterIfExist_TKS” does for WebEdit control.
“SelectSubString_TKS” looks for a partial value (substring) and will select the first match.
“SelectMore_TKS” is little tricky. For example, in an Oracle Web app, there may be very long lists of data that need to be stored under LOV controls which would cause a hit to the overall page performance. In other cases, developers may sometimes leave a few values under that LOV control and assign it a “More…” value. When the user selects the “More…” value from that LOV, it will bring up a popup where the user would be able to select a value which is similar to the “EnterMore_TKS” keyword.
3 Web CheckBox Keywords
We have similar keywords for CheckBox as for the LOV object: Select_TKS, Verify_TKS, SelectWait_TKS, and SelectCheckBoxIfExists_TKS.
[pic]
The only difference between WebEdit and CheckBox keywords, is that for CheckBoxes, you will set or verify the value to “” or “” (check or uncheck) in the DataSheet.
4 Web RadioGroup Keywords
[pic]
One way to be able to select a value for a RadioGroup is by using “Select_TKS”. The value that will be provided in the DataSheet is the value that UFT assigns when recording that particular radio button for this radio group. You can use the Object Spy to determine what those values are.
The “SelectFromList_TKS” keyword requires that you specify all possible values of the RadioGroup in advance in the keyword itself, so that you can use a user-friendly value directly in the Excel sheet when selecting the appropriate value.
[pic]
5 Web Table Keywords
There are 3 basic actions a component may take when working with a table: Adding a row, editing a row, or verifying the data on a row. Each of these activities can be automated using the GetRecordByValue_TKS keyword. This keyword is used to determine what row you want to interact with. That row number is then used in the following steps to determine what cell in the table is being interacted with. The first step for all WebTables is GetRecordByValue_TKS. This is the step that determines which row the tool will interact with during automation. This keyword only has one input parameter and is typically called Search_Criteria. Depending on what information you put in it, you have many options for finding the correct row.
The format for entering the data for Search_Criteria is as follows.
SearchColumn::SearchValue|regex||isText::TRUE||maxPages::10
The first section to notice is SearchColumn::SearchValue. In order to find the row that the tool should automate, you will need to provide the data it will search for. For example, in the picture below, if I wanted to search for a specific Line number, I would enter the following “Line::3” This is telling the tool to search in the “Line” column for the row with the value “3” in it.
[pic]
If you want to search for a row based on more than one value, for example searching by both the Type and the Line columns, you can add a second SearchColumn::SearchValue and separate the two with “||”. This would look like “Type::Goods||Line::4”. The tool would then search for the value “Goods” under the “Type” column and “4” under the “Line” column. The only limit to the number of values you can search for is the number of columns in the table. In the picture above, the maximum number of values you could search by is 10.
If any of the values you are searching for is a partial text in the cell, you can add “|regex” after the SearchValue. You will want to add |regex after each and every SearchValue that is a partial text. This is not set for all of the SearchValues unless you add it to each of them.
If you set isText to true by entering “isText::True” after the SearchColumn::SearchValue, then the tool does not look for any controls within table cell, but uses the HP function “GetCellData” which retrieves the plain text found in table cell. In some cases, you want to get the cell text even if a WebEdit or LOV control is present. This allows the flexibility to retrieve value from a cell without needing any controls.
If you have an application with more than 10 records of data, and the table is using the “Paging” feature to browse through next 10 records of data. The following screenshot demonstrates this:
[pic]
You can add “|MaxPages::15” to the end of the Search_Criteria value. The number after the :: is the maximum number of pages to search for the value in. For example, when you are looking for a record among thousands of other records you may want to search for it in the first 5 or 10 pages, where each page has 10 data records. If the value you search for is not found, “Fail” the test case. If it is found, stop on that page and report “Pass” for this step.
Here is an example of Search_Criteria for the table in the picture above.
Order::6179||Rev::0||Site::SANTA ROSA|regex||isText::True||maxPages::5
This will search for the row with 6179 in the Order column, 0 in the Rev column, and the partial text SANTA ROSA in the Site column. It will treat all of these values as plain text and will search through the first 5 pages of the results.
Usually when there are too many records, the application has some other screen where you can search for the exact record using multiple search fields. So if the data you are looking for is too far ahead, you should use the screen flow through the “Search” screen.
The GetRecordByValue_TKS will look for value in a particular column even if it is within WebEdit, LOV control or just plain text within a table cell.
The keyword for entering data into a cell in the table is EnterField_TKS. This is used if the cell is an edit box, list box, or checkbox. There is not a SelectField_TKS keyword for the list or check boxes that are embedded in the table.
EnterWithSearch_TKS is pretty handy since it handles dynamic controls that are found within a static table. For example, if you application looks like this
[pic]
Instead of using the RadioGroup, “learn” the parent table, which has 3 columns and 5 rows (first column had “RadioButtons”, second was empty – spacer, and last one would contain labels that would correspond to the radio buttons). In that case you could use the keyword EnterWithSearch_TKS as follows:
EnterWithSearch_TKS “Search_Column”, “Search_Value”, “Enter_Column”, “Enter_Value”
If you use constant values, it would look like:
EnterWithSearch_TKS “1”, “Reset Approval List”, “3”, “”
Or if you use parameters, it would look like:
EnterWithSearch_TKS “1”, Parameter(“Search_Value”), “3”, Parameter(“Enter_Value”)
Effectively, this keyword combines both keywords, GetRecordByValue_TKS and EnterField_TKS.
You could also search for an exact label or for a partial label value – that’s why there are variations like EnterWithSearch_TKS and EnterWithExactSearch_TKS etc.
For more info on different table keywords please refer to the provided help manual.
You can also optionally click on the link or image in the cell (see snapshot below):
[pic]
If using the “OptionalSelectImageByProperty_TKS” keyword, then enter “alt” or “image name” property value. If using the OptionalSelectImageInCell_TKS” or “OptionalClickLinkInCell_TKS” keywords, specify “” in order to select any link or image in specific cell.
Anytime you want to skip an action, leave the keyword value blank.
To verify a field use the “VerifyField_TKS” keyword.
[pic]
[pic]
If you wanted to capture value to DataSheet, use one of the following:
[pic]
NOTE: In most cases you will use the OutputToSheet_TKS keyword.
6 WebButtons Keywords
[pic]
Click_TKS has one parameter and the value can be set to “” if needed to be clicked, or just left blank if step is to be skipped.
SetToParameter_TKS – we use this when we want to store the object in the local parameter. For example, you might want to pass the whole WebButton object as just one of the parameters for some other keyword.
[pic]
SetObjectIndexByWebTableParent_TKS – is another tricky keyword. In some situations you have the exact same button, but you only want to click on it based on its parent WebTable. Those WebTables can sometimes change order dynamically; however, you want to be able to click on the correct button depending upon its parent table. This keyword passes the “InnterTextStart” value (basically it is the beginning of the inntertext property of the parent WebTable). Once the keyword locates the correct parent table within the page, it will set proper Index TO property of the current WebButton related to other WebButtons on that page with exact same properties. Then subsequent keywords within that component would work with correct WebButton object.
7 Link keywords
[pic]
Click_TKS is similar to how it works on CheckBox objects (set to “” if need to click on link, or don’t set to anything to skip this step).
2 OAF Extensibility Keywords
Most of the Keywords that are used with the OAF Extensibility are going to work the same way as the standard web keywords. This section will describe the differences.
1 TKSWebEdit
The TKSWebEdit objects are similar to the regular WebEdits. There are a few standard keywords that you will utilize. The first one is Enter_TKS. This keyword is used for entering data into the field. The main difference between the Enter_TKS used for the TKSWebEdit versus the Enter_TKS used for the standard WebEdit is that the TKSWebEdit is a combination of Enter_TKS and EnterMore_TKS. Now one keyword will handle the fields with and without the Search and Select pop-up window. The keyword will use the default Search By value and will search for the exact match of the value entered into the datasheet. It does not automatically open the Search and Select pop-up but it will handle it if it is opened during automation.
No changes have been made to the following keywords: EnterIfExist_TKS, EnterWait_TKS, OutputToSheet_TKS, Verify_TKS, and VerifyDefault_TKS. Please reference the WebEdit Keyword section for more information.
2 TKSWebList
None of the keywords have changed for the TKSWebLists. Select_TKS, SelectWait_TKS, OutputToSheet_TKS, Verify_TKS, and VerifyDefault_TKS are the main keywords you will use. Please reference the WebList Keyword section for more information.
3 TKSWebCheckBox
None of the keywords have changed for the TKSWebLists. Select_TKS, SelectCheckBoxIfExist_TKS, SelectWait_TKS, OutputToSheet_TKS, Verify_TKS, and VerifyDefault_TKS are the main keywords you will use. Please reference the WebCheckBox Keyword section for more information.
4 TKSWebRadioGroup
None of the keywords have changed for the TKSWebLists. Select_TKS and SelectFromList_TKS are the main keywords you will use. Please reference the WebRadioGroup Keyword section for more information.
7 TKSWebTable
The first step for all TKSWebTables is GetRecordByValue_TKS. This works the same as the GetRecordByValue_TKS keyword for standard WebTables.
Another common keyword for TKSWebTables is OptionalClickItemInCell_TKS. This will click a link or image in a cell. The input parameters for it are Row, Column, and ClickStatus. The ClickStatus will typically be a parameter with the name of the column that the automation step is for. In the datasheet you will provide or based on whether or not you want to click the item in the cell.
OptionalClickItemInCellbyIndex_TKS is a variation of OptionalClickItemInCell_TKS when there are more than one links or images in a single cell. In the picture below you will see an example of this in the Actions column. There are three images in the cell and the main way to click the items is by their index. Instead of providing or in the datasheet, you would provide the index of the link or image in the cell that you want to click.
[pic]
3 Oracle Keywords
1 Oracle Text Field Keywords
Note: All keywords discussed have and ending of _TKS. This simply means that it is a keyword developed by TurnKey Solutions.
In most cases, you may want to enter values into a Text Field with the value being taken from the DataSheet.
Here is a sample Oracle Form:
[pic]
Data needs to be entered into the “Description” field.
If you click on the dropdown in the Operation column for the “Description” object, you can see all of the possible keywords that are defined for this object type
[pic]
You could set up this step as the following:
[pic]
This operation would optionally set the “Description” object to a value based on its parameter’s value. The data that is actually entered into the field will be provided in the DataSheet.
In some cases you may want to enter a value for controls only if those controls appear in the application. For those cases use the “EnterIfExist_TKS” keyword.
Capturing value from the screen within a component:
If you need to output a value into the spreadsheet, you would use “OutputToSheet_TKS” keyword.
[pic]
When using this keyword, specify the column name so that output value will be written to the appropriate column in the DataSheet. We can also define and select an “Output” parameter so that the DataSheet Creator will generate that output column in Excel in advance.
Note, ALM/QC provides linking of input parameters to values of output parameters in components within ALM/QC; however, TurnKey performs all linking within DataSheets so that users do not have to modify test cases. All you need to modify are data files; ALM/QC test cases would remain static.
Please see the Changing Argument Values section below for steps on how to add the Output Parameter.
Verifying value within a component.
“Verification” keywords are available for every object type you want to verify a value for. TurnKey does not use standard HP checkpoints because TurnKey wants checkpoints to be dynamic, and easily updateable from the same DataSheet where the values are being provided and saved to.
For example, often you want to capture a value from the application on one form, and then later on verify that this value still holds on another form.
The first step for verifying a value is to select the “Verify_TKS” keyword in the Operation column. A parameter will then need to be added to the Value column so the actual value being verified will be provided in the DataSheet.
[pic]
And the resulting step is showed below:
[pic]
VerifyDefault_TKS only verifies that a field is not empty. If the field is empty, it will report a failure. If the field is not empty (no matter what value except empty spaced), it will report “Pass”, indicating that field value is not empty.
2 Oracle LOV Keywords
The default keyword for the LOV control is Select_TKS, which selects a single item from the LOV control.
[pic]
One trick that’s worth mentioning, is that when you have the first value in the drop-down that is empty, and you to set it to that empty value, you should use the “” variable in the DataSheet. This variable sets the value to “#0” value which corresponds to the empty value for that LOV control.
“OutputToSheet_TKS” works the same way as for Oracle Text Field control.
3 Oracle CheckBox Keywords
There are similar keywords for CheckBox as for LOV object (Select_TKS, Verify_TKS, etc.)
The only difference between Oracle Text Field and the CheckBox keywords, is that with CheckBox, we set or verify value to “” or “” (check or uncheck). If we leave the value blank, then the keyword will be skipped.
4 Oracle RadioGroup Keywords
The “Select_TKS” keyword can be used to select a RadioButton. The value that UFT assigns when recording that particular radio button for this radio group should be used in the DataSheet and that can be determined by spying on the selected RadioButton.
5 Oracle Buttons Keywords
Click_TKS has one parameter and the value can be set to “” if needed to be clicked, or just left blank if step is to be skipped.
6 Oracle Table Keywords
There are 3 basic actions a Component may take when working with an Oracle table: Adding a row, editing a row, or verifying the data on a row. Each of these activities can be automated using the AddEditLine_TKS keyword.
1) This Business Component has 3 parameters for each table component, AddEditLine, Search_Column and Search_Value.
2) Set the AddEditLine parameter description to “REQUIRED”, indicating that this parameter must have data in the DataSheet. In the DataSheet the value will be either “Add” or “Edit” or the specific row number to work with.
a) If the value=”Add” then the Search_Column=the column name to search for a blank row under. Search_Value parameter will be ignored as it will locate the first empty row found based on the named column name.
b) If the value=”Edit” then the Search_Column parameter =the column name to search for a value under and the Search_Value parameter will require the value that should be found in the named column.
c) If the value is set to a number that row number will always be used instead of finding the correct row every time the keyword is executed.
3) Set the Search_Column and Search_Value parameters description to “SEARCH”. There are three operations/keywords that will add or edit a row.
[pic]
The first step is the AddEditLine_TKS keyword. This keyword will let you know which record you are working with and output that record to a Local Parameter (Record_Number). An alternative way to find the record number is to use GetRecordByValue_TKS with parameters:
“Column_Name” – in which column are we searching for value “Column_Value” – what value are you searching for
See the snapshot below:
[pic]
In this example you are looking for column named “Line”, for exact value that will be stored in parameter “Line”. The value for the parameter “Line” will be taken from DataSheet.
The numeric value of the record found will be stored in local parameter “Record_Number”, and this parameter will in turn be reused in the rest of table keywords that work with particular row that was found here.
The GetRecordByValue_TKS will look for value in a particular column even if it is within Oracle Text Field, LOV control or just plain text within a table cell.
Optional Enter Table keywords
[pic]
EnterField_TKS utilizes 3 parameters:
“Record_Number” – this is the row number in which to enter data
“Column_Number” – this is the column in which to enter data
“DataValue” – the data that needs to be entered into the table cell specified by the Record_Number and Column_Name.
The verification would be very similar to EnterField_TKS – except that we would put “VerifyField_TKS” keyword.
[pic]
If you wanted to capture value to DataSheet, use OutputToSheet_TKS.
For more info on different table keywords please refer to provided help manual.
Here is a practical example how you could automate “Lines” components (imagine it was an order with multiple lines – more than 10 lines in the order).
[pic]
And this is how the automation steps would look like (see snapshot below)
[pic]
4 SAP Keywords
1 SAPGuiEdit Keywords
Note: All keywords discussed end with “_TKS”. This simply means that it is a keyword which was developed by TurnKey Solutions.
In most cases, you want to optionally enter values into a Text Field, having the value provided by the DataSheet.
Here is a sample SAP screen (T-Code VA01):
[pic]
Data needs to be entered into the “Sales Organization” field.
If you click on the dropdown in the Operation column for the “Sales Organization” object, you can see all of the possible keywords that are defined for this object type
[pic]
You could have this step as:
[pic]
The operation would optionally set the “Sales organization” object to a value based on its parameter’s value. The parameter’s value would be provided in the DataSheet.
Capturing value from the screen within a component:
If you need to output a value into the spreadsheet, use the “OutputToSheet_TKS” keyword.
[pic]
Enter parameters for the keyword so that the output value will be written to the appropriate column in the Excel DataSheet. You should enter in a constant value for the input because you always want to output a value to the same column every time you run that particular steps. We also define and select an “Output” parameter so that the DataSheet Creator test case would generate that output column in Excel in advance. The value entered into the input should match the name of the output parameter exactly. Note: ALM/QC provides linking of input parameters to values of output parameters in components within ALM/QC, however, TurnKey usually performs all linking within DataSheets so that users do not have to modify test cases. All you have to do is modify the DataSheets.
[pic]
Please see the Changing Argument Values section below for steps on how to add the Output Parameter.
Verifying value within a component.
“Verification” keywords are available for every object type for which you want to verify a value. TurnKey does not use standard HP checkpoints because TurnKey wants checkpoints to be dynamic and easily updateable from the same DataSheet where the values are being provided and saved.
For example, often you may want to capture a value from the application on one form, and then later on verify that this value still holds on another form.
The first step for verifying a value is to select the “Verify_TKS” keyword in the Operation column. A parameter will then need to be added to the Value column so the actual value being verified will be provided in the DataSheet.
[pic]
And the resulting step is showed below:
[pic]
2 SAPGuiLOV Keywords
The default keyword for the LOV control is Select_TKS. This selects a single item from the LOV control.
[pic]
This is very similar to “Enter_TKS”.
One trick that’s worth mentioning, is that when you have the first value in the drop-down that is empty, and you want to set it to that empty value, use the “” variable in the DataSheet, which sets the value to “#0” value which corresponds to the empty value for that LOV control.
“OutputToSheet_TKS” works the same way as for SAPGuiEdit control.
3 SAPGui CheckBox Keywords
There is a similar keyword for SAPGuiCheckBox as for SAPGuiLOV object (Select_TK)
[pic]
The only difference between SAPGuiEdit and CheckBox keywords, is that with SAPGuiCheckBox you set or verify the value to “” or “” (check or uncheck) in the DataSheet.
4 SAPGui Button Keywords
The default keyword used for SAPGui Button is Click_TKS.
Click_TKS has one parameter and the value can be set to “” if needed to be clicked, or just left blank if step is to be skipped.
5 SAPGui Table Keywords
There are 3 basic actions a Component may take when working with a SAPGui table: Adding a row, editing a row or verifying the data on a row. Each of these activities can be automated using the AddEditLine_TKS keyword.
The Business component has 3 parameters for each table component, AddEditLine, Search_Column and Search_Value.
1) Set the AddEditLine parameter description to “REQUIRED”, indicating that this parameter must have data in the DataSheet. In the DataSheet the value will be either “Add” or “Edit” or the specific row number to work with.
a) If the value=”Add” then the Search_Column=the column name to search for a blank row under. Search_Value parameter will be ignored as it will locate the first empty row found based on the named column name.
b) If the value=”Edit” then the Search_Column parameter =the column name to search for a value under and the Search_Value parameter will require the value that should be found in the named column.
c) If the value is set to a number that row number will always be used instead of finding the correct row every time the keyword is executed.
2) Set the Search_Column and Search_Value parameters description to “SEARCH”.
There are three operations/keywords that will add or edit a row.
[pic]
The first step is the AddEditLine_TKS keyword. This keyword will let you know which record you are working with and output that record to a Local Parameter (Record_Number).
An alternative way to find the record number is to use the GetRecordByTwoValue_TKS keyword.
See the snapshot below:
[pic]
In this example you are looking for the row that contains the column that is named in “col1” with value “val1” and the second column named in “col2” with the value “val2”. The values for these 4 parameters will typically be taken from the DataSheet.
For example, if you wanted to search for the row that had “1” in the “Item” column and “T-AS701” in the “Material” column, you would enter “Item” in “col1”, “1” in “val1”, “Material” in “col2”, and “T-AS701” in “val2”. You would then enter the row number of the first row you want to start searching from in the ‘StartRow”.
The numeric value of record found will be stored in local parameter “Record_Number”, and this parameter will in turn be reused in the rest of table keywords that work with particular row that was found here.
The GetRecordByTwoValue_TKS will look for value in a particular column even if it is within WebEdit, LOV control or just plain text within a table cell.
Optional Enter Table keywords
[pic]
EnterField_TKS utilizes 3 parameters:
“Record_Number” – to know in which record is control to which you need to enter data “Col” – to know in which column is control to which you need to enter data “DataValue” – the data that needs to be entered into control in that table cell.
The verification would be very similar to EnterField_TKS – except that we would put “VerifyField_TKS” keyword.
[pic]
And if you wanted to capture value to DataSheet, you would use OutputToSheet_TKS:
[pic]
Here is a practical example how we would automate a SAPGuiTable:
[pic]
And this is what automation steps would look like (see snapshot below):
[pic]
Test Creation
1 High-Level Operational Flow
The following set of operations provides a high-level overview of the things you will need to do in order to create and execute test cases using TurnKey’s solution. Each of the operations is outlined in detail throughout this document.
A. Create Test Cases
1. Open and then configure QTP/UFT
• Ensure that the correct add-ins are selected (e.g. Oracle, SAP, Web, TKS_OAF, etc.)
• Set run option to allow Application Lifecycle Management (ALM) to run tests within UFT
2. Open ALM, making sure that you are connected to the correct domain and project
• Run the Object Identification Script in Resources (one-time per user per machine)
3. Open cFactory
4. Open and then configure the application to be tested with automation
• For Oracle: setup the Oracle Forms Launcher Profile
• For SAP: enable scripting
• For other applications: no setup required
5. Create Components using cFactory (or update Accelerator components)
6. Assemble Components into Test Cases in ALM Test Plan area
7. Configure output columns for common components
8. Configure iterations and/or groups of components
B. Build a Test Set
1. Create the test set in the Test Lab area
2. Configure user fields
3. Put the correct test cases into the test set
4. Setup test execution flow on the execution flow tab
5. Create a DataSheet
6. Enter data into the DataSheet
7. Save and upload the DataSheet and refresh the Test Set
8. Configure data scenarios for each test case within the DataSheet
9. Execute the Test Set and troubleshoot as necessary
2 Creating Test Cases
This section will outline the essentials elements needed for a TurnKey test to work.
Go to the Test Plan, navigate the folder structure to the location you want to build the test and click the “New Test” button. Enter the Test Name and make sure the Test Type is BUSSINESS- PROCESS and click the “OK” button.
[pic]
To add components to the test, go to the Test Script tab and click the “Select Components” button. A window will open on the right with the folder structure of the business components.
[pic]
The DataLoad component is required at the beginning of every test. DataLoad is the only component whose parameters must be set in ALM/QC. No other values need to be set at the test level. This is because the two parameters will determine the source for all other values. If the DataLoad component is not present, a test will fail since it will fail to find and load the datasheet. DataLoad must always be the first component of a test case.
1 Parameters
DataSheet: This parameter is the tab name for the Excel DataSheet that contains your test data. This should be the same name as the test case to avoid confusion with users filling out the DataSheet. NOTE: Excel enforces a 31 character limit for the tab name. Make sure your DataSheet name is 31 characters or less. You may need to abbreviate some of the words of the test case name to get around this limitation.
DataScenario: This is the only promoted parameter in the framework. This parameter will be provided at runtime and determines what set of data is used for each test iteration. It should always be set to “{DataScenario}” – the curly braces are required.
Note: Configuring the DataScenario parameter incorrectly is a common mistake that many people make. This is one of the first things to check if your DataSheet is not creating correctly.
[pic]
Because DataScenario is the only promoted parameter, we train users to select “Add Without Promoting Parameters” when adding components to their test cases.
[pic]
If a user promotes parameters, all of the parameters must be cleaned out of the test case manually.
2 Adding Components
Typically, the next component will be a navigation component to get the application to the correct screen/form. To make your test as reusable as possible, they should start and stop at the home screen of the application. Your navigation will vary depending on what application you are automating. For example, a web application may use a common link component while the SAP GUI uses a component called Transaction Call and the Oracle Jinit uses a component called Navigator Forms.
After the navigation component, the components corresponding to the screens of the business process can be added. These will vary based on the flow of the application for each different test case.
[pic]
[pic]
1 Using Common Components
There are a number of components that cover common functionality that is reused in multiple Test Cases. You can find more information about the common components by looking at their descriptions in ALM. Some of the components are listed below, along with their associated parameters:
DataLoad
DataSheet – The name of the tab in the MS Excel DataSheet file that contains the data for the Test Case, i.e. GLCreateManualJournalEntries.
DataScenario – A runtime parameter that allows for multiple and varied data sets to run in the excel spreadsheet.
Common Web Components
Common Button Web
Page_Title – The name of the page where the button is located Button_Name – The name of the button to click
Index – The index of the button to be clicked (this will be used to identify the correct button if there are multiple buttons with the same name on the page)
Parent_Table_Text – The name of the table that the button is in
Common Link Web
Page_Title – The name of the page where the link is located Frame_Name – The name of the frame where the link is located Link_Name – The name of the link that is to be clicked
Index – The index of the link to be clicked (this will be used to identify the correct link if there are multiple links with the same name)
Data Capture Web
Page_Title – The name of the current page that is open
Tag_Name – The HTML Tag property value of the value that needs to be captured
Left_String – The string of characters to the left of the value that needs to be captured
Right_String – The string of character to the right of the value that needs to be captured
OutputColumnName – The name of the column to save the captured value to in the DataSheet. This must be entered into QC/ALM at the Test Plan level.
Navigate Link Path
LinkPath – The path of links to click, separated by “:”
LinkIndex – The index of the link to clicked (this will be used to identify the correct link if there are multiple links with the same name)
Close All Browsers Web
There are no user input parameters for this component. It will search the machine for any open browsers and close all of them (except for the browser with ALM/QC).
Return to Navigator Web
Page_Title – The name of the current page that is open
Link – The name of the link that is used to return to the Navigator
Link_Index – The index of the link to be clicked (this will be used to identify the correct link if there are multiple links with the same name)
Home_Page_Title – The name of the home page to which you are navigating (this is to verify that the tool navigated to the correct home page)
Common Oracle Components
Close Window
This allows you to close up to 5 forms.
Form_Title – The name of the current form that is to be closed
Form_TimeOut – The amount of time for the form to be found (before closing it)
Common Button
This allows you to click up to 5 buttons.
Form_Title – The name of the current form that the button resides on
Button_Label – The label of the button to be clicked
Tab_Region_Label – The name of the tab that the button resides on (if applicable)
Form_TimeOut – The amount of time for the form to be found
Navigator Forms
Path – The path of the form to be opened separated by “:”
Return to Navigator Forms
EventStatus – The status to report to the run results if the step fails (this should stay “micFail” so the step will show as failed in the run results if it wasn’t able to return to the navigator)
Select Menu Item
Menu_Nav_Path – The menu path to be selected separated by “->”
Form_index – The index of the form from which to select the menu path
Verify Status Line
NotificationReportStatus – The status to report to the run results if the step fails (this should stay “micFail”)
Status – The message to verify in the status line
Common SAP Components
Common Button
This allows you to click up to 7 buttons.
ButtonName – The name of the button to click
Return_SAP_Easy_Access_Screen
There are no user input parameters for this component. It will enter “/n” into the OK Code field to return to the Easy Access Screen
Save_Command_Button
There are no user input parameters for this component. It will click on the “Save” button and capture any numbers that appear in the status bar (such as a document number) and save it to the DataSheet.
Transaction_Call
Transaction_Code – The T-Code to navigate to
Button_Label – The button to click after entering the T-Code (this will be “Enter” the majority of the time)
3 Grouping and Iteration
Some components need to be run multiple times in a row. This is always the case for table components and sometimes apply to non-table components. Tables almost always have multiple rows that need to be interacted with. Instead of adding the component multiple times in the test case, you can set it up for iterations. Adding the component multiple times will limit the number of times you can run the component to the number of time you have added it to the test case. It also increases the size of your DataSheet unnecessarily. Instead, you can set the component up for iterations when you are creating your test case.
Add the component to the test case and click the “1 Iterations” link for that component. A pop up window will open. In this “Iterations” window click the “Add Iteration” button. You must add at least one more iteration to the component than you are going to actually run. This “extra” iteration is used to exit or stop the looping of the component at run time. You can add more iterations than you will actually run without any ill effects. The tool will only run the number of iterations that you provide data for in the DataSheet.
When you setup a component for iterations a blue border will be added around that component in the DataSheet. So any time you see a blue border in the DataSheet it indicates the component can be iterated.
Components can also be grouped when they are to be iterated together. When a group is setup, all of the components in the group will run once through, and when the end of the group is reached, the components inside of it will be run again.
To create a grouping of components, simply select all of the components that are to be in the group, right click and select “Grouping->Group”.
NOTE: To create a group, all components must have the same number of iterations.
[pic]
To add iterations to the group, select the “1 Iterations” link for the group.
[pic]
The Iterations pop-up will show up and you can add or delete iterations using the buttons at the top of the window. Remember to add at least one more iteration here than you are going to run.
[pic]
[pic]
Doing this creates a special grouping in the DataSheet which is denoted by a thick border as shown below. It differs from the single component iteration because the blue border surrounds all the components in the group.
[pic]
3 Creating Test Sets
When the user selects the folder that the test is to be created in and clicks the “New Test Set” button, the “New Test Set” window will open. There are three user-defined fields that are required by TurnKey that dictate the operation of the DataSheets associated with the test set:
[pic]
These fields have been added to the test set module in ALM/QC that allows control of certain global variables.
a. DataSource: This is required for the dataDriver to locate the proper Excel DataSheet to run from when the test set is executed. This DataSheet contains the Test input and output values and can be attached either to the Test Set or the Test Case. At runtime, the file with the same name as the test set (if it is attached at the test set level) or the same name as the test case (if it is attached at the test case level) will be downloaded from the attachments to the local temp folder on the machine. If the DataSheet exists in that path from a previous run it will be replaced by the newly downloaded DataSheet.
i. Test Set: If this is selected when the Test Set is run, the DataSheet will be downloaded from the attachments of the test set and used for the data. This is the recommended option since all of the data for an End-to-End Scenario will be in a single DataSheet.
ii. Test Case: If this is selected when the test case is run from the Test Lab, the DataSheet will be downloaded from the attachments of the test cases used in the test set and used for the data. It will download as many DataSheets as there are test cases.
iii. UNC Path: You can also specify a local file path to run the test from. Instead of having the DataSheet attached in ALM, the file will on your machine or a machine on the network. You simply provide the path to where the sheet is located (ie. “C:/User/Desktop/DataSheet.xlsm”).
b. Upload: This is a required for the dataDriver to know what to do with the DataSheet after execution of the test. There are three options to choose from:
i. Archive DataFile: after the test has executed the data file with the data from the current run will be uploaded to ALM/QC when this option is selected. The data file will be uploaded with a date and timestamp appended to the DataSheet name when it is uploaded to the attachments so that the original DataSheet is not overwritten. The archived DataSheet will contain the original data that was entered into the spreadsheets and the output created when the tests are run.
ii. Don’t Upload: If this is selected, after execution of the test, the data file with the data from the current run will not be uploaded to ALM/QC.
iii. Replace DataFile: If this is selected, after execution of the test, the data file with the data from the current run will be uploaded to ALM/QC. It will override the original data file and will contain the original data you entered into the spreadsheet and the output created when the tests are run.
c. Screen Clip (Y/N): this is a yes/no field that turns on (Y) or off (N) Screen capturing while the tests are running. This field works as an operation (“CaptureScreenClip_TKS”) used in the automation of the business component. Whenever the tool sees the CaptureScreenClip_TKS keyword during execution a picture of the application is taken and saved to the run results if this is set to “Y”. Whether this is set to “Y” or “N”, if there is an error during the execution, the tool is designed to take a screenshot and save it to the run results. This is independent from this Screen Clip setting.
Once the test set has been created, go to the “Execution Grid” Tab. Click the “Select Tests” button and then add the test cases needed for the test set.
[pic]
Once you have added your test cases, go to the “Execution Flow” Tab in order to assign the order in which the tests are to be run. To change the flow, simply click on the first test set and drag your mouse to the test that will come after it. The arrow will start at the first test set and end on the second. Once finished developing the test flow, click the “Refresh” button to complete the changes and clean up the tree view.
[pic]
DataDriver
1 DataSheet Creator
The “DataSheet Creator” is an application that creates an Excel DataSheet with the name of the test set/test case, whichever one is selected. It then attaches the DataSheet to either the test set or test case, whichever is defined in the user defined fields in the Details tab section of Test Set in the test lab. This utility is packaged with cFactory.
Launch the “DataSheet Creator” application from the desktop.
The theme of the application can be changed by clicking on the “Change Theme” button in the upper right hand corner. A list will show up with the available themes. Click the desired theme to change the application to.
[pic]
Navigate to the “ALM/QC Connect” tab. This is where the connection to the ALM/QC project needs to be established. Enter the URL of the project and click Connect. Then enter the user login information and click Authenticate. Then, select the Domain and Project and click “Login”.
To always log into this project when opening the application, check the three “Automatically connect” checkboxes in each section.
[pic]
DataSheets can be created for either Test Sets or Test Cases. It is recommended that DataSheets be created for Test Sets since you can control the flow of test cases by doing so. This also allows you to link data between test cases and all of the data for an End-to-End scenario is in a single file.
To create a DataSheet for a Test Set, navigate to the Test Lab tab.
[pic]
The folder structure from the ALM/QC project Test Lab section will be shown. Select the Test Set that the DataSheet needs to be created for and then click Generate.
To create a DataSheet for a Test Case, navigate to the Test Plan tab.
[pic]
The folder structure from the ALM/QC project Test Plan section will be show. Select the Test Case that you want to build a DataSheet for and then click Generate.
When the DataSheet has been created, you will get a pop-up saying it has successfully been created. You can find your DataSheet on the Attachments tab of the Test Set or Test Case that you created it for.
2 DataLoad from DataSheet
An Excel DataSheet will run on the local client. The Excel DataSheet is where the dynamic data that will be entered during the execution of the test set is housed. Each test case will load values from this file. The data provided in the DataSheet will enter data in the application screens and manage the navigation through the forms/screens. Also, if you have setup any of the components to capture data from the application, the data will be saved to the DataSheet.
There is a tab created in the DataSheet for each test case in the test set if you create the DataSheet at the test set level.
DataSheet Tips and Guidelines
• Do not use QuickTestPro’s “DataTable” Method for any input or output data.
• Excel macros must be enabled to use DataSheets to control the flow of your test cases
3 DataSheet Structure
1 Components
Components are represented across the top of the DataSheet in row 2. They are ordered in the same way they are ordered in the Test Plan of ALM.
[pic]
Rows 2 and 3 in column “A” of the DataSheet are used to identify the:
• Component Label (cell A2)
• Object \ Parameter Name and the Data Scenario (cell A3)
Component Labels displays each component in the test case. The brown vertical border lines encase each component in the test case.
[pic]
ALM/QC Groups or single component iterations that are created in the ALM/QC Test Plan/Test Case are created as shown below. This blue border is created for single component iterations and groups within test cases. It is used to control looping within the test cases. It is important to have this blue border in order to loop through the component or group of components that need to be iterated.
[pic]
Row 3, “Object \ Parameter”, is the parameter created in the component for each field in the application.
[pic]
There is a column created for every parameter in a component so most of the component labels will span multiple columns. It is important that you do not un-merge the component label cell. If you do un-merge the component label, the tool will only see the first parameter as being in the component.
2 Data Scenarios
“Data Scenario”, also on row 3, defines the scenarios for a test case from line 6 down. In a simple test case, all of the data for a test case could be stored on one row as shown here in row 6. For more complex test cases that require iterations, the data for a single test case run for as many rows as the number of iterations setup in the test case.
[pic]
To add a new scenario of one line, click the “New Scenario” button. If you want a scenario with more than one line, put the number of lines you want in the cell next to the New Scenario button (in column B).
[pic]
Click the “New Scenario” button and a new scenario with the number of lines you specified will be created. In this example, I entered 5.
Note: In column A the cells are all merged for the multiline scenario. This tells the tool that it is a single scenario with multiple lines. Do not unmerge this or the tool will see it as 5 separate single line scenarios.
[pic]
Note: Do not delete the Add Scenario button. If you do, you will have to copy it from another DataSheet and paste it back into the one you deleted it from.
3 Screen Clips
The screen clips of the components can be seen from the DataSheet. This can be a good visual reference of what screen the component is automating. If the component has a screen clip attached to it in ALM/QC, the following symbol will be shown to the left of the component name.
[pic]
Clicking on the symbol will open the Snapshot viewer window with the screen clip that is attached to the component in ALM/QC.
[pic]
The screen clips are not automatically added to the DataSheet. They can be added from the Index tab after the DataSheet is created. There is a button in cell A3 called “Download” that will download the screen clips from QC/ALM and make them available in the DataSheet.
Note: The snapshots are actually downloaded to the temp directory of the machine and the icon is a link to open the file from the temp directory. So keep in mind that if you send the DataSheet to someone through email – they will also have to download the snapshots to be able to see them from the DataSheet.
[pic]
4 Expanding/Collapsing Components
The components will default to an expanded view.
[pic]
To contract a component, double-click the component name. This will hide all of the columns in the component except for the first parameter. You can have a component collapsed and still run the test. When executing, the test can see the data in the hidden columns.
[pic]
To expand or collapse all components, click the “Expand/Contract All” button in cell A1.
[pic]
4 Entering Data into the DataSheet
From row 6 down, data is manually entered that will be used when the test case is executed. An example is shown below. The data is manually entered and maintained by the tester/user except for the output data which is generated and written to the DataSheet at the time the test is executed.
[pic]
The DataLoad component is not included in the DataSheet, therefore the first component is the navigation component that was added to the test case after the DataLoad component.
[pic]
Below is an example DataSheet with the second component in this test case being the Requisition Header. The input parameter “Operating_Unit” is left blank as this data is not required, it is optional. The white color depicts that this is an optional field for data entry. The “Type” input field is set to “Purchase Requisition” which will be entered in the Oracle form as well as the data for the “Description” parameter.
[pic]
1 Passing Data between Test Cases
In Order to use data that was output from one test case for use in a subsequent test case, standard Excel functionality is used to reference the cell. First select the cell you wish the value to appear in your current test. Then, press the “=” (equals) key from your keyboard. With the mouse, navigate to where the output value is stored, select the output cell and then press the “Enter” key from your keyboard.
This will link your test’s input value to the output value of another sheet and is automatically passed at runtime.
[pic]
In the above example, the Find Requisition Lines “Requisition” parameter will reference the “Requisition_Number” of the ‘PO_Create_Requisitions’ DataSheet tab with the formula “=PO_Create_Requisitions!G5”. This is standard Microsoft Excel functionality.
2 Consumable Data
Consumable Data refers to data that, once it is used in a test case, can no longer be reused by that test case. Data can also be consumed over time, as with dates and time periods.
Much of the consumable testing data can be generated at the time of test execution (runtime). There are 3 ways we can generate data at runtime. The first is by using special variables created by TurnKey to generate data values for you.
1 Variables
The following is a list of variables which can also be viewed on the index sheet of any DataSheet created by the “DataSheet Creator”:
• - Return unique value in the format YYYYMMDDHHmmss
o abcdef - would return abc20070131120121def
• - Return unique value with the length specified by 'x' for example would return '12345'
o abcdef - would return abc1234def
• - Return unique value in the format 123-45-6789
• - Return the current date in the oracle format: 06-APR-2007
• - Return the current date +/- any number following the variable in the oracle format: 31-MAR-2007
• - Return the current date in the SAP format: 06.04.07
• - Return the current date +/- any number following the variable in the SAP format: 07.04.07
• - Skip entry into a cell or field, same as leaving the data blank
• - Use the data from the test case and not from the spreadsheet for the input parameter.
• - Clears out a value in the object being entered
Below is an example where a variable can be used, circled in blue, in order to keep a date field in sync with the current or system date. For example, if running the “PO Create Requisitions” test case, in the Requisition Lines component there is a parameter called “Need_By”. This is the date a product on the requisition is required. If the current date is manually entered as seen below circled in red, it will most likely work today, but most likely will not work tomorrow or next month when the test is run again.
[pic]
If the test is run several days without going in and updating this date, this error message will appear when the test is executed and the test will fail due to a data error and not an application functionality error.
[pic]
It is recommended to use the “” variable as illustrated above (circled in Blue). This variable will be replaced at runtime with the current or system date + 7 days.
There are other reasons why data may be considered consumable. If a test case creates a new supplier, batch, employee, etc. a unique name is most likely required. In this case a “” variable can be used like “batch - ” and a unique name will be created every time this test runs.
2 Formulas
The second way to generate values at runtime is by using Excel formulas. The subject of Excel formulas is too vast to fully cover in this document; however, here are some examples of formulas that can be useful in producing values for Oracle.
• Oracle End of Month
=UPPER(TEXT(DATE(YEAR(TODAY()),1+MONTH(TODAY()),1)-1, "dd-mmm-yyyy"))
• Oracle End of Year
=UPPER(TEXT(DATE(1+YEAR(TODAY()),MONTH(12),1)-1, "dd-mmm-yyyy"))
• Oracle Beginning of Month
=UPPER(TEXT(DATE(YEAR(TODAY()),MONTH(TODAY()),1), "dd-mmm-yyyy"))
• Phone #
=CONCATENATE("5", TEXT(NOW(), "mm"), "-0", TEXT(NOW(), "dd-hhmm"))
• This Period
=UPPER(TEXT(TODAY(), "mmm-yy"))
• Last Period
=UPPER(TEXT(DATE(YEAR(TODAY()),MONTH(TODAY())-1,1), "mmm-yy"))
• Today (with special formatting)
=TEXT(TODAY(), "mm-dd-yy")
Some other formats may include “dd-mmm-yyyy”, “dd/mm/yyyy”, etc
Note: The date formats (“dd-mmm-yyyy”) can be changed to any date format your application needs
3 Linking
Sometimes consumable data is generated by the application at runtime such as a PO Number. This data can then be used by subsequent test cases.
[pic]
[pic]
In the example of the “Procure to Pay” Test Set: The test set starts at PO – Create Requisitions. PO – Autocreate Purchase Orders then links the Requisition number from PO – Create Requisitions and uses it to create a New PO. The New PO is then used throughout the rest of the end-to-end process.
Using variables, Excel functions and linking data can assist with working around consumable data to prevent manually updating this information each time the tests are executed.
4 Data Support for Iterations
Iterations are a repetition of steps that can take place in a component or in a test case. An example of repetition of steps in a component can be entering multiple lines of material in an order.
An example of repetition of a business process in a test case is creating multiple sales orders for multiple customers. These two Iterations scenarios are not exclusive, creating nested loop iteration. For example a test case to create a sales order can create multiple orders and each order may have multiple lines of material. By defining scenarios, multiple sets of data are used for testing multiple test scenarios.
1 Method 1A – Iterating Component(s) within a Test Case
This method is used when one or more components are expected to run multiple times with different sets of data independent of each other. The components must be designed so that the start and end points of the component are the same in the application. After the setup is complete, the test set or test case can be executed as usual in ALM/QC. The component iterations will occur automatically as defined in the setup of the test case and the data in the DataSheet.
[pic]
1. Go to the “Test Plan” section in ALM
2. Select the test case that contains the component to be iterated
3. Click on the “Test Script” tab
4. Click on the iterations link for the component to be iterated.
[pic]
The Iterations window will appear.
NOTE: In this window, you must add one more iteration than the number of iterations in the test case tab of your DataSheet.
5. Click on “Add Iteration” for each iteration of the component.
6. Close the Component’s Iterations window by Clicking on “OK”
2 Method 1B – Iterating a Group of Components within a Test Case
This method is used when two or more components are to be run multiple times in succession. All of the components in the group will run once in order prior to running the second iteration. Each iteration may use different sets of data. After the setup is complete, the test set or test case can be executed according to standard ALM/QC functionality. The group iterations will occur automatically as set in ALM/QC and in the DataSheet.
To create group iteration in ALM/QC:
1. Go to the “Test Plan” section in ALM/QC
2. Select the test case that contains the components to be iterated
3. Select the first component in the test case to be included in the grouping.
4. Hold the shift key down and click on the last component that should be included the grouping.
5. Right-Click on the selection and select Grouping->Group Components
[pic]
To set the number of iterations of the group:
1. Select the Group1 row, Right Click and select iterations (or click the iterations link in that row).
2. Click on the “Add Iteration” button in the Group Iterations window that will appear. Click until the number of iterations listed is one greater than the number of iterations in the DataSheet. Then click “OK” in the Group Iterations window.
[pic]
3 Method 2 – Iterating a Test Case with Different Data Scenarios
This method is used when an entire test case is to be run multiple times with different data scenarios. The test case will run as many times as identified in the DataSheet.
To iterate a test case in this manner, the DataLoad component in the test case must be using a Run- Time Parameter for the DataScenario. See the “Setting up a run-time parameter” section for more information.
[pic]
The number of iterations or Data Scenarios which are run is determined by the iterations set up in the test set.
[pic]
1. Go to the Execution Grid window for the test set in the Test Lab.
2. Select the Test Case that is to be iterated and right click.
3. Select Test Instance Details
4. Select Test Execution Settings.
5. Click the “Add Iteration” button for the number of times that you want to iterate the test case.
6. Modify the value in the DataScenario column to match the data scenario in the DataSheet.
[pic]
[pic]
Note: After setting up multiple data scenarios, a single data scenario can still be run by clicking on the “Select Iterations” button and limiting the iterations to a range or to a single iteration. The data will be retrieved appropriately from the DataSheet.
The DataSheet for this Iteration setup would look like the following:
[pic]
Notice that the Same Data Scenarios that were entered into ALM/QC are also entered into the DataSheet. This is the link that tells dataDriver to use specific rows of data from the DataSheet.
5 Complex Flow Control Using Group Iterations
The examples that have been explained are very basic iterations. dataDriver supports multiple levels of sub-iterations and branching. Through the use of dataDriver and the data entered in the DataSheet a test case can create a purchase order with any number of lines. Each of those lines can have any number of shipments and each of those shipments any number of distributions. This nested iteration functionality can continue to an unlimited number of sub-iterations or nested iterations.
The Group Iteration for this complex scenario is setup in ALM/QC as described above. The setup of the DataSheet is the key to implementing the complex flow control for a complex nested iteration.
Shading a field or a component in the DataSheet allows you to skip those elements, thus allowing you to handle such things as complex, nested iterations. The shading can be any non-white or non-black color. White is treated as no shading. Black is used to exit a group immediately and not run any of the remaining components in that group. Below is an abbreviated example of how the shading can be applied in the DataSheet:
[pic]
• Column “A”, Rows “6-10” have been merged to indicate that all data in those rows refer to one DataScenario. That DataScenario will be executed for one test run of the test case.
• The REQUISITIONS HEADER component will run once.
• The grouping “Group 1” sets up the iteration that has 5 components each of which will run 5 times (once for each row “6-10”).
1. Requisitions Lines Tab Table
2. Requisitions Lines Footer
3. Requisition Distributions Accounts Table
4. Select Menu Item
5. Close_Window
• The last component, Capture Text Field, will run once.
• A shaded field in the DataSheet indicates during execution that this component will not be executed for that run in the iteration.
Step-by-step, this test case will do the following:
1. Run Requisition Header component and enter a type into the “Type” field.
2. Start Line 1 for Scenario 1, Iteration 1
3. Run the Requisitions Lines Tab Table component, enter “1” in the “Num” field and “Goods” in the “Type” field.
4. Run the Requisitions Line Footer component, enter “Expense” in “Destination_Type” and “Supplier” in ‘Source’ and then clicks the “Distributions” button.
5. Run PO Distributions component, enter “1” in the “Num” field, enter “5” in the “Quantity” field, and then enter the “Charge Account”.
6. The “Select Menu Item” and “Close Window” components will be skipped at runtime because they are shaded.
7. Group 1 ends and goes to the next row in the group to begin execution of the second iteration row for Scenario 1
8. Start Line 2 for Scenario 1, Iteration 2
9. SKIP Requisitions Lines Tab Table
10. SKIP Requisitions Lines Footer
11. Run Requisitions Distributions Accounts Table, enter “2” in the “Num” field, enter “2” in the “Quantity” field of a new line then press “OK”.
12. Run the Select Menu Item component
13. Run the Close_Window component.
14. End the execution of the 2nd row for Scenario 1 Iteration 2
15. Start Line 3 for Scenario 1 Iteration 3
16. The pattern repeats steps 1 – 13 above except for the Requisition lines “Num” parameter being set for line Num “2” of the Requisitions lines.
17. Once the test execution reaches iteration 5 of Scenario 1, dataDriver will see that there are no more rows of data to execute with and exits Group 1.
18. Run Capture Text Field Component and any components thereafter.
Stepping through each step and comparing it to the setup in the DataSheet will make it clear what is happening in that test case. It is important to note that if the cells in a component are shaded, then that component will be skipped. If the cells are not shaded then the component will be executed with data from the DataSheet.
Note: If the cells are shaded in black, the entire group will be skipped at runtime.
Based on the functionality and behavior described above, it now may become clear that a group of components can execute or not execute based on data. Therefore the flow of components can be controlled via the DataSheet and allows for adding branching or complicated nested iterations.
Branching is when there is a need to open different forms to complete different types of line items all within the same test case. To branch it is needed to add the input parameters to some if not all of the common components. By providing different parameter values to components like Common_Button, the test flow can be steered down a different path for any given iteration. That path can then be tested by activating only the component used in that path while skipping any components used in alternate paths.
5 Updating DataSheets
When updating or editing a DataSheet, TurnKey recommends the following set of steps to ensure that their changes are not lost.
1. Make changes to the DataSheet (you can double click the sheet directly from ALM in the test set attachments tab).
2. Save your changes, but do not close the DataSheet.
3. In the ALM Test Lab, go to the attachments tab for the test set and click Update Attachment followed by the Refresh button.
4. Watch the timestamp change on the DataSheet attachment to ensure that the upload has completed successfully. If the timestamp does not change, save the DataSheet to the desktop. Then click the Attach (paperclip icon) button in ALM and select the DataSheet from the desktop. If you close the DataSheet without the timestamp updating, you may lose your changes.
5. Then you must close the DataSheet before running the test set.
Executing Tests
Tests are generally executed from within a test set according to the standard HP functionality so that TurnKey DataSheets can control the flow from test case to test case within a scenario.
The Excel DataSheet will run on the local client triggered by the DataLoad component. The Excel DataSheet is where the dynamic data that will be entered during the execution of the test set is housed. Each test case loads values from this file. The data provided in the DataSheet will enter data in the application screens and manage the navigation through the forms/screens.
If included, extensibility loads with the first component executed.
1 Data Sources
Data can be supplied to a component during test execution from three different sources:
1 Static Data
Data for a test case can be set in the Test Case in the Test Plan section of ALM/QC. This level of data is referred to as “Static” data. Static data is data that will never change from test run to test run. Static data is setup at the time the test case is created. An example of static data is the data used for the Navigator Forms and the Common button components, or when debugging test cases. Customers often forget that they have setup static data that remains the same for all runs of the test case.
[pic]
Note: It is not recommended to have the data in ALM/QC. It is recommended to have all of the data in the DataSheets.
2 Dynamic Data
Dynamic data is provided at runtime from the DataSheet that is defined in the Test Set Properties / Details tab in the Test Lab. Dynamic data, such as an invoice number or supplier name, will be fed to the test case at runtime from the Excel spreadsheet. Dynamic data should never be placed in the test case in the Test Plan. This method supports data transfer between test cases and can be easily changed from one test run to the next if necessary.
3 Run-Time Data
There is a need to sometimes change data at the time a test set is executed. By setting up a Run-time parameter you determine how a test will run during execution. The Accelerator uses a Run-time parameter only to define Iterations in the Test Case in the Test Plan. See “Iterations” below. Always setup the DataLoad Component “DataScenario” parameter as a run-time parameter. Do not set up any other parameter as run-time parameters.
2 Setting Up a Run-Time Parameter
A run-time parameter is setup in the Test Plan to configure the DataScenario within the DataLoad component.
1. Go to the Test Plan section of ALM/QC.
2. Browse and select the test case.
3. Select the Test Script Tab.
4. Click the Iterations link to view the Run Time Parameter for the DataLoad Component.
[pic]
5. Set a Value for the Run-Time Parameter. This is only done for the DataScenario parameter of the DataLoad component. You should always enter “{DataScenario}” for this.
The next step is to set the value of the Run-Time Parameter in the test set. Go to the Test Set in the Test Lab and right-click on the test case and select Test Instance Details -> Execution Settings
[pic]
Enter the value to use for this test case in the parameter box. In this case “Scenario 1”, “Scenario 2” and “Scenario 3” have been entered.
[pic]
To add iterations, the number of times this test is expected to run at the time of execution, click on the “Add Iteration” button. You can use any text to identify the DataScenario such as
“Create Manual Entry”, “Scenario 1", etc. The values that are entered into ALM/QC should have the same name of any scenario you wish to run from the DataSheet.
The “Select Iterations” button allows you to choose a single or range of iterations that you would like to run when the test is executed.
3 Test Results
Test results look a little different using the results engine/viewer than standard ALM.
To run the Test Set, go back to the Execution Grid Tab and click the Run Test Set button to run the entire test set or the Run button to run a selected test case.
[pic]
a. After the script has run, the Last Run Results report can be read by clicking on the Status in the Last Run Results window to verify the results.
b. In the “Last Run Result” section at the bottom of the Execution Grid section, the result hierarchy can be expanded by clicking on the “+” next to each node or by clicking on the “Passed” or “Failed” status hyperlink to open the complete Test Results report.
c. Here you can see exactly what happened. If a script does not complete successfully, this report may help determine the reason. Click on the “+” symbol to expand the test results or click on the individual components to see additional information.
[pic]
Once results have been opened, we can select any step to see detailed description.
[pic]
At the end of most components we will have snapshots of the application depending on whether Test Set parameter “Screen Clip (Y/N)” has been set to “Y” or “N”.
[pic]
In order to see the iterations of data, just select the correct group and data underneath.
[pic]
Note: Upon any failure in many cases the Accelerator’s error handling will look for common indicators as to why the test failed. In this case it captured a screen clip to assist you in diagnosing why the test case failed. This will be done independent of the “Screen Clip (Y/N)” setting at the Test Lab Level.
4 Debugging
1 Debugging/Unit Testing Components
Open the Business Component that will be unit tested in UFT.
Click on: File -> Open -> Business Component
Note: If you have the component open in cFactory, you can click the “Advanced Mode” button and it will be opened in UFT.
[pic]
The “Open business Component” window will appear. Highlight the component to be unit tested.
Click the “Open” button
[pic]
The business component will open in the main UFT window.
[pic]
Highlight the row of automation from which you want to start testing.
Put a Break Point at the “CaptureScreenClip_TKS” operation by clicking in the left margin next to that row. A red dot will appear in that area when you have successfully added the breakpoint.
[pic]
[pic]
Make sure that the application is open to the screen that you are unit testing.
[pic]
Layer UFT right on top of the application screen that will be unit tested.
[pic]
To enter the data to be tested, click on the Properties window that is on the right of the UFT window. Then click the tab that looks like a footprint with arrows. Here you will see the list of input parameters for the component. You can enter the data you want to test here.
[pic]
To run the component, go to the “Run” menu option and choose the “Run from Step” option.
[pic]
The Run window will open. In the Results Location tab select the Temporary Run radio button.
[pic]
Select the Input Parameters tab. The same values that were put in the setting should appear in the value column. They can also be modified in this location.
[pic]
When you are ready to run the test click the “Run” button.
When the Run is finished you will see a yellow arrow in the break point. Click the Stop icon in the toolbar to stop the test.
You will also see the data entered into the application screen.
[pic]
You can access the results from the View -> Results menu path or by clicking the Results button.
[pic]
The results report will open so you can review the unit test results.
2 Debugging Test Plan
Select Test case, set “DataScenario” parameter value to match the one in DataSheet, and then click on the arrow button to start test case playback.
[pic]
In the menu, select the components that you want to run in debug mode.
[pic]
UFT/QTP starts the test case in debug mode, and a message box appears with DataLoadManager path that was last executed from test set. You have the opportunity to change it to any DataSheet you like. If the path does not default in, save a copy of your DataSheet to the Desktop and provide the path to it in this pop-up.
[pic]
Once the test case is running in debug mode, it will automatically stop on each of the components that were set to “Debug” mode. From this point on, continue debugging components as was mentioned in the previous section with the exception that data will be automatically taken from current DataSheet (no need to set any default values like we did when we were unit-testing components).
Component and Test Case Maintenance
When a user’s application changes, components, test cases, test sets and DataSheets can all be impacted.
1 Updating/Changing Components
1 cFactory Comparison Mode
When updating an existing component from the application, cFactory will enter Comparison Mode. cFactory is looking at the names of the objects and the recognition properties of the objects on the updated screen and comparing those properties to the objects that are in the original component. It then displays the comparison in the main cFactory window. In this mode, you can see all of the changes or updates that cFactory found to the component, side-by-side with the original component. You can now either “Accept” or “Reject” the changes individually or in bulk. You will notice that in the comparison mode, there are two sets of component steps. The steps on the left are the original component steps and the ones on the right are the updates that cFactory found.
1 Open Component
A component needs to be opened in cFactory before updates can be made. You can open a component from the Application Menu.
[pic]
[pic]Open the application Menu by clicking the [pic] cFactory Icon.
[pic]Next, click the “Open Component” Button. After clicking this button, the cFactory File Browser Window will appear.
File Browser window
Components can be saved to your ALM/QC project or to the local File System. There are separate tabs for the File System and the ALM/QC project. Select the tab of the location the component is to be opened from.
[pic]
[pic]Select the component you want to open.
[pic]When you have selected a component, the name will show in the edit box at the bottom of the window.
[pic]Click the “Select” button to open the component that is selected from the component list.
2 Update from Application
[pic]
[pic]Click the “Update From Application” Button.
[pic]
Once again you will get the Learn Pop-up window only this time the Application Area field has been disabled. This is because you are updating an existing component already associated to an Application Area.
You proceed the same as we did in the sections under “Create New Components”.
3 Select Component
[pic]
[pic]Select the component with the same name as the original.
Note: Naming conventions may change over time in which case the component names may be slightly different. Screen and region names are always used as a naming best practice to ensuring names will always be similar. In most cases the names will be exactly the same.
[pic]Click the “Select” button and the Compare View will open for you to review changes.
2 Compared Steps
[pic]Menu Bar
[pic]
This is where you can “Accept” or “Reject” updates that cFactory found.
[pic]Component Steps
[pic]
Component steps are color-coded depending on the updates that need to be made. There are four main updates that you might see: new fields, obsolete or removed fields, field where names have changed, fields that changed position or order within the component. The default colors are as follows: new fields are colored in green, obsolete fields are colored red, changes in position are colored blue, and changes in name are colored orange. You can changes these colors using the “Color Settings” button on the Configuration Tab if desired.
Menu Bar
[pic]
When cFactory is in Comparison mode, the Edit tab has new buttons shown for accepting or rejecting the changes. The accepting and rejecting of changes are on a case by case basis so it's up to you to determine for each step change whether to accept or reject the change.
[pic]Accept
Click the “Accept” button to accept the change that is currently selected.
[pic]Accept All
Click the “Accept All” button to accept all of the changes that cFactory found for the component.
[pic]Reject
Click the “Reject” button to reject the change that is currently selected.
[pic]Reject All
Click the “Reject All” button to reject all of the changes that cFactory found for the component.
[pic]Skip
Click the “Skip” button to skip the current change that is selected.
[pic]Close
Click the “Close” button to close the Comparison Mode.
In this example, you can see that many steps are colored and some remain white. The colored steps are those in which cFactory has detected changes. The white steps are the ones that cFactory found no difference in the item; the properties have not changed.
[pic]
[pic]Load Data
The LoadData Operation is always the first step or item in a component; therefore, this step will not need to be updated. It is highlighted in grey because it is the current line that is selected.
[pic]Non-Updated Step
Typically, the second step in any component is a verification that the application is on the correct screen/form. The properties of the main form in this example did not change, so this step does not need updated and, as such, is not shaded.
[pic]Name Change
This step is an example of a step that contains a field with a name that was modified. It is shaded in orange to show that cFactory recognized that the field only changed names and all other identification properties remained the same.
[pic]New Field
The step shown here does not have any values on the left-hand side because cFactory found a new field on the form that was not in the original component. The step is only shown on the right and is shaded in green to indicate that cFactory found a field that was not in the original component.
[pic]Obsolete Field
The step shown here does not have any values on the right hand side because cFactory did not find a field on the form that corresponds to a field that was in the original component. The step is only shown on the left and is shaded in red to indicate that cFactory did not find a field that was in the original component.
3 Fixing Updates
Sometimes, cFactory will see some fields on the updated forms as new, even though they correspond to a field in the old component. cFactory will see the field as a new step and the original step in the component as obsolete. In this case, you need to manually tell cFactory that the two fields are in fact the same. To do this, select the new step that you want to associate with the old step. In this example, step 14 on the right corresponds to step 18 on the left. After selecting step 14 on the right, click and drag it down to step 18.
[pic][pic]New Step [pic]
[pic]Old Step
[pic]
After dragging the new step down to row 18 to associate it with the old step, it will look as follows. It is color coded in orange to indicate a change. The step will need to be accepted in order for the change to actually be made to the component.
[pic]
4 Accept/Reject Updates
Each update that is found must be Accepted or Rejected before you can save the component. You can Accept/Reject All steps by clicking the “Accept/Reject All” button or you can Accept/Reject the steps individually. To do it individually, select the step and click either the “Accept” or the “Reject” button.
[pic]Step to Accept/Reject
[pic]
When the step has been Accepted or Rejected, it will become uncolored.
[pic]
Note: The step in this example was accepted so you will notice that the original name of the field was updated from Supplier Name to Trading Partner Name. If the step had been rejected, the name would have stayed as Supplier Name.
When you have Accepted/Rejected all of the updates, click the “Close” button to return back to the Component Editor View. Here you can make any further changes to the component and save the changes.
2 Automatically Updating DataSheets
1 DataSheet Updates When Components Change
When saving changes to a component that is in an existing test case and/or test set that have Datasheets already created, you will see the following window. cFactory has the ability to modify the DataSheets with the changes that have been made to the component so you do not have to recreate the DataSheet or update it manually. You can choose any and/or all of the DataSheets that contain the component that was updated.
[pic]
Select the datasheets that you want to update with the changes you have made to a component by checking the checkboxes next to the name of the datasheets.
Click the Update button once you have selected the datasheets you want cFactory to update.
Click the Close button if you want to cancel the update of datasheets at this time.
When the DataSheets are updated, the changes will be indicated in the Datasheet in row 3 right below the parameter name. The cell will be color coded based on the change that was made. If a new parameter was added to the component, a column for that parameter will be inserted into the DataSheet and row 3 for that parameter will be colored green and have the text “New” in the cell. If an existing parameter was changed, then the corresponding column for that parameter will also be changed and row 3 for that parameter will be colored orange and have the text “Changed” in the cell. If any of the parameters were reordered by reordering the steps in the component, the columns corresponding to those parameters will be moved accordingly. There will be no indication in row 3 that the order was change.
One thing to keep in mind when updating the DataSheets is that none of the columns in the data sheet will be deleted, even if the step that it corresponded to was deleted. The obsolete column will be moved to the end of the component and will be row 3 for those parameters will be colored red to indicate to the user that the component is no longer using that column. This will ensure that no data is lost. The user is free to delete the obsolete columns if desired without interfering with the automation.
These colors and text in the DataSheet will remain until the user removes the text and changes the color back to the default blue color manually. For the columns that have the “Removed” text, the user is free to leave them in the DataSheet or manually update them.
Below is an example of an updated DataSheet:
Original DataSheet:
[pic]
Updated DataSheet:
[pic]
Notice that the Country_of_Original column has moved from column AO to column AS. Also the Alias column was moved to the end and colored red to indicate that it was removed from the component. The URL parameter name was changed to URL_Address and the Organization_Address column was added to the datasheet indicating that a new parameter was added to the component.
2 DataSheet Updates When Test Cases Change within Test Set
cFactory has the ability to analyze existing DataSheets and compare them to the Test Cases and Test Sets that they are attached to. If cFactory finds any changes to the tests, for example components were added or removed, components were reordered in a test case or components steps were updated, the tool will find those differences and update the DataSheet accordingly. The same color coding for row 3 that is used when updating a component in cFactory will still apply when using this method.
To update the DataSheets for a Test Case, Test Set, or batch of components, open cFactory and open the menu of cFactory. Click on the Update DataSheet Manager option. There is also a shortcut button to the right of the cFactory menu button.
[pic]
This will open a window similar to the update window when saving a component that was changed. This window has three tabs, one for Components, one for Test Plan and one for Test Lab. In each of these you can see all of the Test Cases and Test Sets that have been created. You can also see all of the Datasheets that are attached to them.
NOTE: When an update is being done from the Datasheet Manager, you can interact with the other applications on you system (including the main cFactory window). Depending on the number and type of updates you are performing, the updates may take some time. While the updates are running, you could be creating new components for new tests or creating/modifying tests in ALM. This will allow you to make more progress on your implementation effort.
[pic]
Components Tab
If you select the Components tab, you will see a listing of all of the components in your project. You can update the Datasheet for the steps inside of a component from this tab.
As you expand the tree, you will see which of the components are used in test cases and test sets that have attached Datasheets.
[pic]
For any given component, it will show you every test case and test that it is used in and you can pick and choose which of the Datasheets that use that component that you want to update by clicking the checkbox next to the Datasheets.
[pic]
You can select Datasheets from under multiple components at a time. Once you select the Datasheets and hit the Update button, you will see the Datasheets you selected in the status section of the window on the right. It will show you which Datasheet is currently being updated, which Datasheets are next to be updated, and which Datasheets have finished updating.
[pic]
[pic]
When the Datasheet is being updated at this level, only the components that you have selected the Datasheet for are being reviewed. This is not a catch all update. This update is for the component steps only and the updater will only compare the steps of the component with the columns in the Datasheet for the selected component. Please refer to the next sections for information on how to do a more comprehensive update of the Datasheet.
Test Plan Tab
There are two levels of updates you can perform from the Test Plan Tab. You can have the updater compare the component order only of the case you have selected, or you can have the updater compare the component order of the case as well as the steps inside all of the components used in the test case. If you have only added a new component, removed and existing component, changed the order of the components or added grouping or iterations to components inside the test case(and have not changed any of the steps inside of those components), then you want to have the updater check for only the test case structure updates when it is updating the Datasheet. If you have made changes to both the test case structure and changed the steps inside of some of the components used in the test case, then you will want to have the updater to an epanded update that would catch all of those changes. We have included a non expanded mode and expanded mode in the Datasheet Updater to account for both levels of changes.
If you are doing the non-expanded mode of update (meaning that you have only changed the test case structure and not changed any steps inside of the components used in the test case), then you will want to make sure that the checkbox at the bottom of the updater window is turned OFF.
[pic]
To make sure the expanded update is off, look at the orange bar along the bottom of the updater window and make sure it says “OFF”. If it says “ON”, click the orange bar to expand the expanded mode section and make sure th check box is not checked.
If you want to do the expanded update (meaning that you have changed both the test case structure and the steps in one or more of the components used in the test case), then you will want to make sure that expanded update is turned “ON”. To make sure the expanded update is on, look at the orange bar along the bottom of the updater window and make sure it says “ON”. If it says “OFF”, click the orange bar to expand the expanded mode section and make sure th check box is checked.
[pic]
NOTE: The expanded update will take longer than the non-expanded update because the updater is have to make more references and checks to ALM.
To make the updates, choose whether to have expanded mode ON or OFF, navigate to the test case/s that you updated in the tree structure and select the DataSheets that use those test cases and click the Update button. As explained in the Components Tab section, you can monitor the status of the updates by viewing the status section on the updater screen.
Test Lab Tab
There are three levels of updates you can perform from the Test Lab Tab. You can make a change to the order/structure of the test set (meaning you could add or remove a test case or change the order of the test cases). Also you could have made order/structure changes to one or more of the test cases in the test set (meaning you could have added, removed or changed the order of the components in the test case or added grouping or iterations to those components), or you could have changed the steps inside of one or more of the components used in the test set.
Similar to the Test Plan Tab, there is an expanded mode option in the test lab. If you only made changes to the test set structure, you will run the updater with expanded mode off. This level of update will only check to see if you have changed the order, added, or removed one or more test cases. It will then reorder the tabs, add tabs, or mark tabs as removed depending on the changes it sees to the test set. It will not go analyze the component structure in the test cases or the steps in the components.
[pic]
To make sure the expanded update is off, look at the orange bar along the bottom of the updater window and make sure it says “OFF”. If it says “ON”, click the orange bar to expand the expanded mode section and make sure th check box is not checked.
If you have made changes to one or more of the test cases inside the test set(meaning you have only added a new component, removed and existing component, changed the order of the components or added grouping or iterations to components inside the test case), then you will want to run the update with expanded mode turned ON and choose the Test Case option in the drop down.
[pic]
Choosing the Test Case in the dropdown of the expanded mode section tells the updater that it needs to check both the test set structure as well as the test case structures. This will not check the steps inside the components used in the test set.
If you have made changes to the test set structure, test case structure and/or the steps in side the components, then you want to run the updater with expanded mode turned ON and choose Component from the dropdown. This is essentially the catch-all version of the updater. It is going to review all of the test cases in the test set, review the component structure of all of those test cases and then go one step further and review all of the steps inside of all of the components used in all of the test cases and make any updates to the Datasheet that are required. Please note that this process can take some time. The tool is doing a full comparison of what is in your Datasheet to what is in your ALM project and then making the updates.
[pic]
3 Data Repository Updating
Many of the components were generated prior to the release of cFactory 2. This means that they were generated in a manner similar to the batch build method meaning their objects are located in a Shared Object Repository. With cFactory 2, the components are now built with the objects located in a Local OR. When a component that has its objects stored in a Shared Object Repository is opened and updated with cFactory, the objects will automatically be moved from the Shared OR into a Local OR.
Advanced Training Concepts
1 Application Areas
Creating the Application Area
Launch UFT/QTP with Add-ins that are necessary to automate that particular web application.
[pic]
Note, since in our case we are using Oracle Web application, and because there is a UFT/QTP limitation where UFT/QTP would load add-ins of the first component only and will re-use it for all subsequent components for that particular test case, therefore we really need to select web + Oracle add-ins (because in some cases we could access Web application directly from Oracle Forms, and ideally we would want to handle this particular situation as well).
Most likely, for Web applications we would select Web Add-in only, but sometimes we might also choose an extensibility Add-in depending on whether extensibility has been developed for the particular application (like TKSSapCustomAddin in the screenshot above).
To create new Application Area, in QTP select “File>New>Application Area”.
[pic]
The naming convention for Application Areas includes the name of the application that the AA is being created for
Next we need to associate libraries with the Application Area (see snapshot below).
[pic]
Here we click on “Function Libraries” tab, then click on “+” sign, select the libraries that need to be added (those could be custom libraries that you might have created), and “Open”.
For any application, make sure the following function libraries are added.
1. Common.txt
2. Web.txt
3. Common_TKS.vbs
4. The library that contains the keywords for the application
2 Manipulating the Object Repository
1 Capturing Objects/Formatting the Object Repository
cFactory component generation is driven by the Object Repository. cFactory analyzes the tree structure of an object repository and builds components based on the structure it finds there. The structures parent child relationships and object types are systematically read by the rules file to create each of the business components. Because cFactory interacts with the object repository to produce components, we can organize the OR structure and what goes into it in order to produce different results.
One of the most common rules for cFactory is to create a new component for each parent branch of the OR. Parent branches are the large container objects like Pages, Forms, and other screen size objects. For each component you would like to produce, you simply learn a new parent container even if that parent already exists in the OR. It is common to add the same parent container object several times in order to build the OR in such a way that cFactory will yield separate components for sub regions of a screen. For instance, components built to automate Tables are often built separately from other objects on the screen because of the need to iterate when working with them.
Note: cFactory uses object names when naming components and parameters. It is recommended that OR objects be named to reflect what is shown on the screen of the application.
2 Configuring object identification properties
Users can configure object identification properties and capture objects for a sample Web application.
The first step is to decide what properties will be used when capturing objects. For that, in QTP we will go to Tools->Object Identification, and will configure following properties (see snapshot below):
[pic]
Select the appropriate Add-in (Web in this case), then select each of the objects we use during automation and will configure mandatory properties for main object identification, but also smart identification for Optional Filter properties that are only for cFactory use. We are NOT using smart identification for UFT/QTP playback, but this is a place-holder that is used by cFactory to retrieve extra properties in order to properly generate automated business components. We are using abs_x and abs_y for most objects in order to know its position on the screen. cFactory will lay them out from left to right, top to bottom based on X/Y values that are associated with each of the objects (except pages, browsers and frames).
For Tables we are also using a property called “column names”. This property will store information about column names for Web Tables. cFactory will later use this property to properly generate Tables with the correct column names as UFT/QTP would identify it.
We provide an object identification script that can help in setting all those properties automatically, and it is located in ALM/QC under Test Plan->Subject->BPT Resources->QTP Config->Attachments tab (see snapshot below).
[pic]
The user would need to run it once. In order to run it, make sure UFT/QTP is closed. Then download this script to local hard-drive, and double click it. This script should start UFT/QTP, run its identification, and at the end give a notification message box (it should take about 1 minute to run). Then it is best to restart UFT/QTP and verify that the UFT/QTP identification properties have changed.
The script can be modified based on the application that is under test. Those properties can also be configured manually through UFT/QTP, and then saved in UFT/QTP through the “Tools->Object Identification->Generate Script” option.
So now, since we configured object identification properties for all objects, let’s learn them to repositories. We are always using Local repositories to store objects.
3 Adding Simple Web Objects
In order to add simple objects such as regular edit text boxes, checkboxes, radio buttons, etc., follow these steps:
1. Open the applicable Object Repository in UFT/QTP.
2. Open the Oracle WebPage that corresponds to the Object Repository.
3. Click on the “Add Objects” button.
4. The hand will convert to a pointer and the focus will be on the Oracle screen as long as UFT/QTP is tiled right over Oracle Apps. Click anywhere on the page to capture all objects within the page or click on the individual object to capture a single object.
[pic]
5. After clicking on the Oracle page, you will automatically return to UFT/QTP and the Object Repository. The Object Selection - Add to Repository dialog box will appear. Several Layers of forms will appear in this form. To capture all simple objects on a page, select the object with the prefix "Page" then, click the ‘OK’ button. To add an individual object, just select the object in the “Object Selection – Add to Repository” window and click OK.
[pic]
6. The Define Object Filter dialog will now appear. Select the “Selected Object Types” radio button, then click the “Select…” ratio button (Note: you need to do it only once on each PC for each Windows Username since next time UFT/QTP will remember the "Selected object types" you chose).
[pic]
7. The select object types list will appear. The following checkboxes should be selected: Browser:Browser, CheckBox: Web checkbox, Editbox - Webedit, Webfile, List:Weblist, RadioButton Group:WebRadioGroup, and WebPage:Page. Click OK.
[pic]
8. Click “OK” in “Define Object Filter” window and it will capture all previously checked objects if they are found on the current Oracle WebPage. This exercise will efficiently select only those objects on the form that are required for testing and minimize the cleanup and deletion of objects that are not needed in the object repository.
[pic]
9. If not named automatically, name the Objects exactly with the same text label that is visible on the Oracle form. Those names will later be used for Parameters generation in cFactory.
[pic]
10. Tip: To verify the correct field, you can highlight the object by clicking on the highlight icon in UFT/QTP. The corresponding field in Oracle will be highlighted.
11. After we add the first page, we can modify the name of the browser and add a regular expression to it so that we could put other pages underneath. So we would first rename the Browser’s title property by using Regular Expressions.
[pic]
12. Since, when we learning objects, we are trying to learn them in a fashion so that cFactory would be able to generate appropriate components by name (component name would be taken from Web Page name), we can create the same page again in a temporary repository, rename it appropriately, learn all new child objects underneath (could be Web Table for example), and then copy that page into the “Master” repository that will be later on used by cFactory. We could get rid of that temporary repository since we won’t need it anymore.
4 Adding Web Tables (Non-Simple Objects)
Open the Object Spy in UFT/QTP and spy on the web table (just spy on any of the web table cells).
Go up the hierarchy from the control you spied on to the very first web table and up until the right web table is selected. To verify that it is the right table, make sure that the column names property values correspond to what is seen on the web page. Verify that the number of columns (cols) and rows corresponds to number of visible rows and columns and confirm that the “class” property or “html id” are not empty. Close the spy window.
[pic]
1. Click on the Add icon and click on the table. Jot down the name of table in the Oracle form. Click the “OK” button.
[pic]
2. Verify the class, html id and inner text properties of the web table are identified.
[pic]
3. Highlight the object in the Object Repository and click “Highlight in Application” to be sure the table is highlighted in the application.
[pic]
4. Modify the innertext property. Change to a regular expression by including wild-card characters at the end like “.*” to take into account remaining columns. Make sure that the first few columns are part of the regular expression which will uniquely identify this object on the web page. Click OK.
[pic]
5. Set the ordinal identifier type to “Index” and the identifier value equal to “0” in the Ordinal Identifier dialog box.
6. After verifying the properties for the web table, click on the Highlight UFT/QTP icon. The correct web table should then be highlighted in the web application.
[pic]
TurnKey Software Customizations
1 Customizing Library and Keywords
In the libraries and keywords, it is important that customers do not change core keywords directly in the keyword library as this will violate a user’s maintenance and support agreement. New keywords can be added and core keywords can be modified if the customer creates a custom keyword library and makes the changes in it. If the customer wants to modify a TurnKey provided keyword, they must copy the keyword from the TurnKey Library and paste it into their custom keyword library. They can make the modifications to the keyword in their library. In order for their keyword to be used instead of the TurnKey keyword, they must add their library to the Application Area before the TurnKey library. If you open the Application Area in UFT, you can add the library to the list in the Function Library section of the Application Area. The first instance of a keyword is the one used during runtime so if the custom library is before the TurnKey library in the list, the modified keyword will be used instead of the TurnKey keyword. See the Advanced Training Concepts section for more information on Creating/Updating Application Areas.
[pic]
1 Creating New Keywords
Keywords are in essence functions that are associated with specific object types. By registering those functions to contain a specific keyword name – it allows for user friendly intellisense to work from within UFT. A keyword should have proper documentation/description of what it is supposed to do, function input parameter descriptions that would be visible when selecting the keyword from UFT and cFactory, proper error handling and reporting so that, ideally, only one step would be reported (pass or fail) with a detailed description of what happened. An important functionality that is provided with TurnKey keywords is that a snapshot of the application or of the Desktop is captured when something went wrong during execution, so that not only do we get the most probable description of what happened during playback, but we also get a screenshot of what happened at that time.
1 Registering function code
Registering a keyword is very straight-forward. All that needs to be done is to put RegisterUserFunc “ObjectClassName”, “keyword name”, “implemented function name”, [Default True or False].
The command RegisterUserFunc should be placed below the function that is implementing the particular action.
1st parameter - “ObjectClassName” - will tell what objects are associated with a specific keyword.
2nd parameter - “keyword name” - is the name of the keyword users would be able to select.
3rd parameter - “implemented function name” - is the name of the function or Sub that implements a particular keyword.
4th parameter - if set to “TRUE” then it would be the default keyword when selecting that particular object from the keyword screen in UFT. If it is not set to anything, then UFT will assume that keyword is not the default one. Note – we should have only one keyword for a specific object type that is “TRUE”.
2 Reporting inside of keywords
One thing to note with the keywords is that TurnKey turns off the standard HP reporting and uses its own reporting. You can see in the previous example that we use the TriageReportWeb line for reporting. Directly following TriageReportWeb is a micFail, micPass, or micGeneral. These values are telling the tool how to report the step in the run results. If micFail is used, it will report the step as a failure, thus making the test have a failed status. If micPass is used, it will report the step as a pass. When micGeneral is used, it reports the step as a purely information step with neither a passed nor failed status.
3 Keyword Example
The following is an example of the “Enter_TKS” function:
'------------------------------------------
'Enter_TKS
'------------------------------------------
' User Documentation. ''
' Optionally enters a specified value into a specified object. '@Param DataValue Value to enter into a specified object. '@Description Optionally enters value into WebEdit.
'@Documentation Enter in the . Public Sub OptionalEnter(obj, DataValue)
If EndTestIter Then NavigateHomeWeb("") ExitTestIteration
End If
procedure = "Enter """ & DataValue & """ into the """ & obj.ToString() & """ ." Dim FilterVal
FilterVal = Reporter.Filter Reporter.Filter = rfDisableAll On Error Resume Next
DataVal = DataValueHandler(DataValue) Select Case DataVal
Case ""
'Do nothing skip entering of data Case Else
obj.Set DataVal If Err = 0 Then
TriageReportWeb micPass, procedure, _
Chr(34) & DataVal & Chr(34) & " was entered into the """ & obj.ToString() & """ .", obj
obj.FireEvent "onchange"
Else
TriageReportWeb micFail, procedure, _
"Failed to enter " & Chr(34) & DataVal & Chr(34) & " into the """ &
obj.ToString() & """ ." _
& "Error: " & Err.Description, obj
End If
End Select reporter.Filter=FilterVal
End Sub
RegisterUserFunc "TKSWebEdit", "Enter_TKS", "OptionalEnter", True RegisterUserFunc "WebEdit", "Enter_TKS", "OptionalEnter", True RegisterUserFunc "WebFile", "Enter_TKS", "OptionalEnter", True RegisterUserFunc "WinEdit", "Enter_TKS", "OptionalEnter", True
2 Customizing the Rules Base
The rules base is the set of rules that tells cFactory what component steps to create, in which order. For every TurnKey component, LoadData is the very first component step. LoadData is the data management function that locates the current component data from the source Excel DataSheet and loads it into the component. The next step in a TurnKey component is to verify that the application is in the expected place for reporting purposes. In some rules bases, there may also be a navigation step that involves clicking on a tab or menu item before verifying the screen.
At the bottom of a TurnKey component, cFactory typically adds two steps. First, CaptureScreenClip_TKS takes a screen shot when the Test Set “capture screen clip(Y/N)” user-defined-field is set to ‘Y’ (Yes). Next is the ClickButtonText_TKS, which allows the user to provide the “Button_Label” name information since most screen entries or changes do not take effect until you click something. Which functions you see at the top and bottom of a component vary depending on the target application you are testing; however, the types of functionality that they handle are the same.
Customers can edit only the Custom Rules base provided by TurnKey. The other rules base files are encrypted and not editable. This file contains two parts: the first part is the default keywords which can be changed. Typically customers want to rename keywords to suit their needs. The second part is the rules for creating components which should never be edited. If these are edited, you will need to reinstall the file.
If a customer wants to modify the defaults keyword file, they must make a copy of the original and modify the copy. Rename the original file to something else and make sure the copy of the file that is being modified has the name of the original file. The name of the file is important for the tool to look at the correct file. For example if you are modifying the Oracle defaults keyword file, the name of the .template file is Oracle.template. The corresponding default keyword file that this file is looking for should be called Oracle Defaults.xml.
New associations of objects and their default keywords can be added to the Default.xml document of cFactory for the Rules Base you want to modify. These files can be found in the < cFactory Application directory>/xml/ folder. To understand how to add a new default keyword for an object class, let’s look at an existing entry.
[pic]
This is an example of the WebEdit class being defaulted to the Enter_TKS keyword. We know this keyword takes one argument and that argument is normally associated to a parameter with the same name as the logical name given to the WebEdit object itself. Let’s go through each element and attribute in the xml to show how we have defaulted the common behavior we would like to see cFactory produce whenever it comes across a WebEdit object.
For those who like raw xml here it is:
Start with the Default Element node and provide the “Class”, “Operation” and “AddParam” attributes. The class is WebEdit and we are associating the Enter_TKS operation to it. This tells cFactory to create an Enter_TKS keyword step whenever it sees a WebEdit. The AddParam is a true or false attribute that tells cFactory to create a parameter of the same name as the WebEdit object or not.
Next is the Arguments element. This element is simply there to contain the Argument repeater elements seeing as though we may have several arguments.
The next element is the Argument element and it’s one and only attribute “Order”. We assign the order of the attributes here, starting with “1” and increment the value as we add more arguments. In this particular example we only have one argument.
Next is the Parameter element and the “Name” and “Local” attributes. The ”Name” attribute is assigned the text "Test Object Name". This is a special key phrase that tells cFactory to place the objects logical name in the place where a parameter is named in an argument. For example if you have an WebEdit object named “Password”, cFactory will set the first argument for the Enter_TKS to Parameter(“Password”). We know this parameter will exist because the “AddParam” attribute for the Default element above is set to “true”. The “Local” attribute is telling cFactory to treat this Parameter as a LocalParameter or not. It is set to false so it is a component parameter and not a local one.
Arguments are sometimes constant values rather than parameters. The following example shows how to set the value to an argument rather than a parameter.
[pic]
This is an example of the WebTable default. Unlike the rest of the object defaults in the xml, the WebTable default is used to create several steps according to the rules base template.
[pic]
There are a few differences when it comes to this WebTable Default:
First is the AddParam argument. It is set the same as with the WebEdit, however in the special case of WebTables, the Rules base is going to create a parameter for every column in the WebTable (if the columns are listed in the object repository under the “column names” property).
The second difference is that the first “Argument” element is set to a “Parameter” named “Record_Number” with the “Local” attribute set to true. This means the first argument will be set to LocalParameter(“Record_Number”). This will work nicely because the rules base has been told to create a step at the beginning of the WebTable block called GetRecordByValue_TKS. The product of that step is to output the Record number of a found value to LocalParameter(“Record_Number”) .
Next is the second “Argument” element with a “Value” element rather than a “Parameter” element. This tells cFactory to set a constant value to this argument rather than a parameter. We also see a new key phrase “Test Object $Column” which tells cFactory to use the current column name as the constant value. cFactory will use this keyword step for each column of the WebTable and each step will be for a different column in the table. This argument tells EnterField_TKS what column to enter a value into.
The final argument for EnterField_TKS is the Data value argument or the value you would like to enter into the column. You can see by the last “Argument” element, it is set to a parameter that is named the same as the column used in the current step.
Now that you have an understanding of what each Element and attribute does in the Defaults.XML files, you should have an easy time creating a new Object Class Default. The easiest way to go about it is to locate a similar Default element to the one you wish to add. Copy and paste it as a new entry and then change the attributes to what they need to be, starting with the “Class” attribute. A Class can only be used once under the ParentAddIn element.
3 Customizing or Creating Extensibility
In most cases, you can extend default keywords/object identification properties by using the Web Extensibility Accelerator. In QTP 11 and older, this is a built in tool that can be opened directly from QTP by going to Tools->Extensibility Accelerator (or F12 in QTP). Users can define new object identification properties and operations. These are generally written in JavaScript and DOM for Internet Explorer browser.
[pic]
Here is a sample of yahoo object types, or any other object types, that can be developed using this Web Extensibility Accelerator.
[pic]
Once Extensibility is ready and has been tested, it can be loaded into UFT by selecting the appropriate checkbox under the Web Add-In section of the Add-Ins Manager window.
[pic]
Customers requiring extensibility support must engage TurnKey’s Professional Services organization.
APPENDIX 1 – Best Practices
The Following items are best practices when using the cFactory products in your test automation project.
Requirements
Time spent gathering good requirements and data is never wasted! Put as much effort as possible into this before you automate. The better the requirements and test flow, the better the test cases. Plus, if you have a set of complete requirements that you’re implementing, you can more easily track what you automated and what is still left to automate. Issues will also be easier to resolve.
Creating Components for Tables
Create one component for every table within a screen, page or form. Use the Advanced Learn function when learning the component. Change the innertext name using 2 or 3 columns for the innertext name and then regex with ‘.*’ for table components. If you have more than one table in a component, make sure that you keep as many columns as necessary to distinguish the two; tables often reuse column names which appear in other tables.
Component Values
The Description field within the component parameters is set to OPTIONAL: by default, unless you are setting up a verification component. You must go in and set the description by hand if you want it to be setup correctly in the datasheet with the proper color-codes. Values REQUIRED:, SEARCH: and VERIFICATION: are also valid descriptions in addition to OPTIONAL:. These should always be entered in ALL CAPS because you can sometimes run into QTP issues if you have mixed case descriptions of component parameters within a test case. It is best if you do not change the descriptions in ALM; change them in cFactory instead.
Naming Components
It is very important to name components appropriately so that you will be able to find and use them in the future. A general rule of thumb is that you should name the component the same thing as the page, form or screen that you are learning. cFactory will generally default to the same name as the page, form or screen; however, If you are creating a component for a sub-section or particular region of a page, form or screen (e.g. a header, footer or table), you should manually add that sub-section designation to the component name (e.g. Catalog_Request_Table).
Add the t-code to the beginning of SAP component names to help you recognize the component later.
Iterations
When setting up iterations for a component, such as for a table, you will need one extra iteration than you actually want to use. That extra iteration is for exiting the iterations. We use the adage: “One is one and two is three.”
Updating Components
Don’t change the application area when updating components. Use the one that was originally used when the component was developed. If you feel that you must change it, create a new component altogether.
Snapshots
Create a snapshot for every component you create. It’s worth it when you or your BA’s are filling out datasheets (you can import snapshots within the datasheets). It’s also much easier to unit test your components if you have a snapshot.
Test Case Creation
Develop test cases in your development project environment and then copy them over to the production environment. Make sure you have both projects under source control; therefore, you can learn the differences and selectively move the changed pieces over to the production environment. ALM does not have the capability to compare changes. Be sure to choose the “Copy Tests and link to existing related entities” selection to make sure that all components, libraries and functions are all copied over as well if you are simply pasting into a different environment.
DataSheet Names
MS Excel limits tab names for worksheets to 31 characters; therefore datasheet names are limited to 31-characters as well. Because each test case has its own worksheet within the datasheet, keep that in mind when naming test cases.
DataSheet Creation
Setup your test plan before you create the datasheet so that you can plan for and setup iterations. Do not create datasheets until after you test out the entire test flow with data. Otherwise you will waste a lot of time updating the datasheet if/when you change component orders and/or iterations when you are developing test cases.
Extensibility
If your test cases span multiple applications that require extensibility, create separate test cases for each. ALM has a limitation that only one extensibility package can be loaded and in use at a time successfully.
To help manage extensibility packages, create a backup directory in both of these locations:
C:\Program Files (x86)\HP\QuickTest Professional\dat\Extensibility\Web
C:\Program Files (x86)\HP\QuickTest Add-in For ALM-QC\dat\Extensibility\Web
These are the two directories that QTP looks for extensibility. Having a backup location for all different types of extensibility allows you to easily switch back and forth without losing track of it.
APPENDIX 2 – Scoping Practices for Components
How Object Repositories are built will determine how the business components will be created in Quality Center. It is recommended that separate components are built for the separate areas/regions of a screen, such as tabs and tables. In this section we will cover when and why we develop different components for different areas.
Components can cover any amount of automation we decide. Making the correct decisions about component scope will improve the usability of your framework where making incorrect decisions will make your framework hard to use and add unnecessary maintenance. TurnKey scopes its BPT components based on user recognition, reusability and functionality.
Recognition
Our studies have shown that business users, when talking someone through a process, will talk in terms of screens and regions. Anything smaller is too detailed and anything larger won’t explain what is necessary to go through the process.
Reusability
Since TurnKey uses a data driven framework, reusability is already maximized for a component because the data drives what actions take place in a component and what actions are ignored. This allows us to build components with an action for every object the user might want to interact with. With components like this, you only need one because they can cover any flow path through that region.
Functionality
Iteration is the one Functional requirement that will force us to scope a component at a certain place. In the case of Tables for instance, we often need to iterate through them. With a Keyword framework we iterate at the component level so we want to make a component that covers the table area alone. In some cases there are external fields from the table (usually in a footer area) that are associated with the lines of the table. This is considered part of the table area and steps for those fields should be added to the table component.
-----------------------
TurnKey Solutions – Proprietary & Confidential Do Not Copy or Distribute
Copyright © TurnKey Solutions 2016
TurnKey Solutions – Proprietary & Confidential Do Not Copy or Distribute
Copyright © TurnKey Solutions 2015
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- turnkey websites for sale
- turnkey drop shipping websites
- vw bug turnkey performance engines
- turnkey business opportunity low investment
- turnkey dropshipping websites for sale
- turnkey online stores with dropshippers
- free turnkey dropship website
- turnkey websites that make money
- intelligent product solutions ny
- automation test strategy document
- unit test automation tools
- test automation tools selenium