Introduction to the integral framework
0 likes223 views
The document introduces the integral framework, which emphasizes simplicity by breaking down components into easy-to-understand parts, ultimately enhancing automation efficiency. It discusses the structure of component scripts, driver scripts, master scripts, and the use of description objects instead of object repositories to facilitate object identification in automated tests. Additionally, it covers input and output parameters, the role of reusable external files, and the organization of driver and master scripts to simulate user experiences across various scenarios.
Introduction to the integral framework
- 1. Introduction to the integral Framework INTRODUCTION TO THE INTEGRAL FRAMEWORK BY KARTHIK SUBRAMANIAN https://www.linkedin.com/in/karsub1 karsubp@gmail.com
- 2. Introduction to the Integral Framework One definition of the word Integral is: consisting or composed of parts that together constitute a whole. The focus of this framework is Simplicity. By creating and maintaining easy-to-understanding parts, it is possible to create and maintain an easy-to-understand whole. Simplicity here means minimizing the key resources involved in the framework and making sure those resources follow clear lines of communication with each other. The Integral framework places a majority of its emphasis on Description Objects, Component Scripts and Actions, Function Libraries (VBS files), Driver Scripts and Actions and Master Scripts and Actions. The Following Diagram shows a simplified hierarchy of these resources.
- 4. Description Objects Instead of using the Object Repository feature in Quick Test Pro (QTP), each component action will use explicitly defined Description Objects which are property name/value collections used to identify an object within the Application Under Test (AUT) Component Scripts Component Scripts are composed of very small, reusable, automated pieces of functionality within the AUT. Examples of component actions include entering text in a field or clicking on a Button
- 5. Function Libraries External functions and subroutines written as VBS files can be an extremely valuable way to reuse code in an automation framework Driver Scripts Driver Scripts are composed of reusable actions that dictate the order in which component actions are executed so that a user experience in simulated. The focus of a driver script is on page- specific activity.
- 6. Master Scripts Master Scripts decide the order in which driver scripts are executed so that a full, end-–to-end test scenario can be simulated. The focus of a master script is on system-wide activity Component Scripts Each component script contains a collection of reusable actions that can be used to manipulate or validate objects on a particular screen in the AUT. Separate component scripts should be created to handle areas of the screen that appear on more than one screen (e.g. a navigation banner at the top of the left of the screen that appears on most of the screens). Popup windows and dialogs should be considered different screens within the AUT and should have corresponding component scripts as well. The following illustration shows how each object on the AUT screen has a corresponding reusable action in the component script
- 7. Component script Application Under Test = Reusable Action Login Username Password Login Enter Username Enter Password Click Login Component script Application Under Test = Reusable Action
- 8. Component Action Types There are two main types of component actions within the Integral Framework: manipulation actions and validation actions. Manipulation actions are those actions that do something to an object on the application’s user interface. Validation actions are those actions that check something in the system, comparing an expected value against an actual value or application state. The following illustration shows how component actions can be used to validate or manipulate specific objects in the AUT.
- 9. Component script Application Under Test ValUsername ValTodaysDate ClickStart Welcome Welcome SunRaise! Today’s Date: January 1, 10 Start Component script Application Under Test = Reusable Action
- 11. Input Parameters Input parameters are used to pass information to reusable component actions. An action that handles entering text into a text field will have an input parameter that specifies what text should be entered into the field. Input parameters, depending on the parameter type (i.e. String, Number, Boolean, etc.), might utilize a default value when a similar value will often be passed into the action. Output Parameters Output parameters can be used to return information back to the calling driver action. Output parameters are typically used to retrieve information that is generated by the AUT and that is needed later during the automated script’s execution
- 12. Referencing External Files When multiple components actions use very similar code to perform their object manipulations, the code is a good candidate for reuse by moving it to an external file. The following illustration shows how two component actions that contain similar code can reuse code by moving the logic to an external file and simply calling the external file. WebEdit_EnterText.vbs
- 13. Moving code to an external file not only allows the code to be referenced more easily by component actions but it also allows for simpler maintenance of the code since it’s only in one place. Imagine if the logic of enter text was in 500 components actions and then had to be updated. One would have to make the logic update in 500 places instead of just one. Use the ExecuteFile command in QTP to retrieve the external file and put the file’s code into memory for execution. In the previous example, Both EnterUsername and EnterPassword actions would need to perform the following command before the calling the subroutine in the external file. ExecuteFile “WebEdit_EnterText.vbs”
- 14. Description Objects The Integral Framework uses description objects instead of object repositories to identify objects in the AUT. Using description objects allows the engineer to be very specific when defining the property names and values to use when identifying the object being manipulated or validated. Storing property names and values in object repositories requires additional space and processing during script execution since it forces QTP to create and reference an XML file where all the property names and values are stored and then create description objects based on those properties. It also avoids identifying similar fields on different pages. By manually creating description objects, engineers can save space and skip extra processing required by QTP.
- 15. The following example code shows how to create a description object and assign a property or properties name/value pair to it. ‘Set aside memory for the description object variable Dim descrWebEdit ‘Create the description object and assign it to the variable Set descrWebEdit=Description.Create() ‘Add the Property to our object, supplying as the property value descrWebEdit(“name”).value=”MyfeildName” Note: Use the Object Spy tool in QTP to discover the properties that uniquely identify the object being manipulated or validated.
- 16. Piecing It all Together: Using Component Actions The following diagram shows an example of everything discussed thus far. “SunRaise” is passed into the component action EnterUsername as an input parameter. Because EnterUsername handles only entering text into the Username fields, the action only needs to: (1) identify the field being manipulated, and (2) enter text into the field. Step (1) is handled by creating a description object that uniquely identifies the field on the screen. Step (2) is handled by the external file WebEdit_EnterText.vbs which contains a subroutine of the same name. To enter text into the password field, the engineer would create a component action called EnterPassword where a description object is created to uniquely identify the Password field, and then make a call to the same WebEdit_EnterText.vbs.
- 18. Driver Scripts Each driver script contains reusable actions that call component actions in a particular order to simulate a user experience on a particular screen in the AUT. While component actions focus on a particular field or object on a screen, driver actions focus on manipulating more than one object on the screen A user experience on a particular screen may involve manipulating one or more pop-up windows or may require navigating to and from another screen in the application in order to complete the activity. Manipulating pop-up windows and /or navigating to another screen should take place within the same driver action if, and only if, those extra steps are necessary to the activity. Driver scripts control which specific data is passed to the component actions it calls i.e. the username “SunRaise” should be passed from the driver action as an input parameter to the component action EnterUsername
- 19. Driver Action Types There are two main types of driver actions within the Integral framework: Independent actions and dependent actions. Independent actions are those actions that can be executed regardless of the application state. Dependent actions are those actions that can execute successfully only if the application is in a particular state (i.e., on a particular screen). An example of an independent action might be creating a new user account in the system. An action such as creating a new record that does not rely on any other record being created previously can usually take place at any time while in the application. As long as the automated test can perform the necessary actions to return the application to a ‘start’ state (e.g. returning to a home page or login screen), the independent action can execute successfully.
- 20. An example of dependent action might be performing a task on the fourth screen in a wizard-like sequence of screens. Without first executing the actions that correspond to the previous screens in the wizard, the dependent action cannot execute successfully. Creating a Driver script The reusable actions that make up a driver script should be named in a way that clearly and concisely describes what the action is doing on the particular screen. An example might be AddUserAccount for a driver action that simulates entering in information for a new user account, submitting that information to the system and performing validation to ensure that the activity was successful.
- 21. Piecing It All Together: Using Driver Actions The following illustration shows a driver action that enters a username and password and then clicks the Login button – in that order - to simulate a user logging into the system. Note that “…”denotes QTP Syntax that has been removed in this document
- 22. Component Action Component Action Component Action Application Under Test WebEdit_EnterText.vbs WebButton_Click.vbs RunAction “EnterUsername”, …. ,”SunRaise” RunAction “EnterPassword”, …. ,”Password” RunAction “ClickLogin”, … EnterPassword Click Login EnterUsername Code to Enter text Code to Enter text Login Username Password Login SunRaise ********** Driver Action: Login WebButton_Click.vbs
- 23. Data Scenarios A data scenario is a collection of specific data that are used to populate fields, act as expected values for validations and otherwise drive an action to simulate the information a user might input into the system and expect to receive from the system as output. As an example, imagine that there are two user accounts in the system. Each user account has an associated username and password that must be used together in order to gain access into the system. The following table represents two possible data scenarios that could be used for the driver action Login shown above Username Password 1 SunRaise SunPassword1 2 Moonlight CoolWinter
- 24. By referencing the first data scenario in the Login driver action, the automation would simulate logging into the system as SunRaise. By referencing the second data scenario, the automation would simulate logging into the system as Moonlight. Note that the driver action would not have to be changed at all in order to perform either simulation. It would only be necessary to manage what input data was supplied to the component actions called in the driver action. This is where driver action input parameters are introduced. Input Parameters Input parameters are used to tell the driver action which data scenario to use. Like component actions, a default value can be assigned to be input parameter for the driver action.
- 25. Piecing it All Together: Using Data Scenarios The following illustration shows how a call from master action can dictate which data scenario is referenced by a driver action, thereby determining how the driver action will simulate a user experience.
- 27. Referencing External Files There are two types of external files within the Integral Framework: AUT-focused libraries and framework – focused libraries. AUT- focused libraries are the functions and subroutines that are used by component actions to manipulate or validate the AUT. Framework- focused libraries are the functions and subroutines that are used within the framework itself to control execution flow and data. Most AUT-focused libraries can be thought of as replacing the code that QTP automatically generates during a recording of an action. QTP might generate the following line after clicking a web button. Browser(…).Page(…).WebButton(…).Click
- 28. The Integral Framework uses a description object to uniquely identify the WebButton, and then passes that description object to the WebButton_Click subroutine managed in the external file WebButton_Click.vbs Framework – focused libraries are designed to make the framework more easily maintained and flexible by implementing code reuse. Framework-focused libraries can contain functions that handle commonly used tasks (e.g. formatting data in a particular way) or dictate how the automation test should be executed (e.g. how many times an action should be executed and which data scenario to use) .
- 29. Master Scripts Each master action will contain only calls to driver actions in a particular order that simulates a user experience across more than one screen in the system. Each call to a driver action also contains the row number of the data scenario to use while executing. If more than one row number is supplied, the driver action will be executed once for each row number supplied and in the order that the numbers are supplied. This functionality should be implemented in the driver actions using a separate VBS file.
- 30. KARTHIK SUBRAMANIAN https://www.linkedin.com/in/karsub1 karsubp@gmail.com Meet The Expert Selenium – Page Object Framework Overview