Create QTP Test Scripts QTP Tutorial 1 You can create tests using the keyword-driven methodology, step

p recording, or a combination of both. The keyword-driven methodology enables you to select keywords to indicate the operations you want to perform on your application. Step recording enables you to record the operations you perform on your application. After you create your tests, you can enhance them using checkpoints and other special testing options. This section includes: About reating Tests !eciding "hich #ethodology to $se - %eyword-!riven or &ecording 'nhancing Your Test $sing &elative (aths in )T( About Creating Tests You can create tests using the keyword-driven methodology, step recording, or a combination of both. reating tests using the keyword-driven methodology re*uires an infrastructure for all of the re*uired resources. &esources include shared ob+ect repositories, function libraries, and recovery scenarios. Setting up the infrastructure re*uires in-depth knowledge of your application and a high level of )T( e,pertise. Although setting up the infrastructure may initially re*uire a longer time-investment in comparison to recording tests, using the keyword-driven methodology enables you to create tests at a more application-specific level and with a more structured design. This enables you to maintain your tests more efficiently and provides you with more fle,ibility than a recorded test. -n some cases, you may want to let )T( generate test steps by recording the typical processes that you perform on your application. As you navigate through your application, )T( graphically displays each step you perform as a row in the %eyword .iew. A step is anything a user does that changes the content of a page or ob+ect in your application, for e,ample, clicking a link or typing data into an edit bo,. &ecording may be easier for new )T( users or when beginning to design tests for a new application or a new feature. "hile creating your test, you can insert checkpoints. A checkpoint compares the value of an element captured when the ob+ect was saved in the ob+ect repository, with the value of the same element captured during the run session. This helps you determine whether or not your application is functioning correctly. "hen you test your application, you may want to check how it performs the same operations with different data. This is called parameterizing your test. You can supply data in the !ata Table, define environment variables, instruct )uickTest to generate random numbers, and so on. Deciding Which Methodolog to !se " #e $ord"Dri%en or &ecording You can create the steps in your tests using the keyword-driven methodology, recording, or a combination of both. &ecording Tests &ecording can be useful in the following situations: &ecording helps novice )T( users learn how )T( interprets the operations you perform on your application, and how it converts them to )T( ob+ects and built-in operations. &ecording can be useful for more advanced )T( users when working with a new application or ma+or new features of an e,isting application /for the same reasons described above0. &ecording is also helpful while developing functions that incorporate built-in )T( keywords. &ecording can be useful when you need to *uickly create a test that tests the basic functionality of an application or feature, but does not re*uire long-term maintenance. Creating Tests !sing #e $ord"Dri%en Testing %eyword-driven testing advantages include the following: %eyword-driven testing enables you to design your tests at a business level rather than at the ob+ect level. 1or e,ample, )T( may recogni2e a single option selection in your application as several steps: a click on a button ob+ect, a mouse operation on a list ob+ect, and then a keyboard operation on a list sub-item. You can create an appropriately-named function to represent all of these lower-level operations in a single, business-level keyword. 3y incorporating technical operations, such as a synchroni2ation statement that waits for client-server communications to finish, into higher level keywords, tests are easier to read and easier for less technical application testers to maintain when the application changes. %eyword-driven testing naturally leads to a more efficient separation between resource maintenance and test maintenance. This enables the automation e,perts to focus on maintaining ob+ects and functions while application testers focus on maintaining the test structure and design. "hen you record tests, you may not notice that new ob+ects are being added to the local ob+ect repository. This may result in many testers maintaining local ob+ect repositories with copies of the same ob+ects. "hen using a

keyword-driven methodology, you select the ob+ects for your steps from the e,isting ob+ect repository. "hen you need a new ob+ect, you can add it to your local ob+ect repository temporarily, but you are also aware that you need to add it to the shared ob+ect repository for future use. "hen you record a test, )T( enters the correct ob+ects, methods, and argument values for you. Therefore, it is possible to create a test with little preparation or planning. Although this makes it easier to create tests *uickly, such tests are harder to maintain when the application changes and often re*uire re-recording large parts of the test. "hen you use a keyword-driven methodology, you select from e,isting ob+ects and operation keywords. Therefore, you must be familiar with both the ob+ect repositories and the function libraries that are available. You must also have a good idea of what you want your test to look like before you begin inserting steps. This usually results in well-planned and better-structured tests, which also results in easier long-term maintenance. Automation e,perts can add ob+ects and functions based on detailed product specifications even before a feature has been added to a product. $sing keyword-driven testing, you can begin to develop tests for a new product or feature earlier in the development cycle. 'nhancing (our Test You can use a variety of options to enhance your e,isting tests. This section describes some of the ways in which you can enhance your e,isting tests. Checkpoints You can add checkpoints to your test. A checkpoint is a step in your test that compares the a specified item during a run session with the values stored for the same item within the test. This enables you to identify whether or not your application is functioning correctly. There are several different checkpoint types. Tip: You can also use the CheckPropert method, which enables you to verify the property value of an ob+ect without using the checkpoint interface. Parameterization You can parameteri2e your test to replace fi,ed values with values from an e,ternal source during your run session. The values can come from a !ata Table, environment variables you define, or values that )T( generates during the run session. )utput *alues You can retrieve values from your test and store them in the !ata Table as output values. You can subse*uently use these values as an input parameter in your test. This enables you to use data retrieved during a test in other parts of the test. Actions You can divide your test into actions to streamline the testing process of your application. Programming Statements You can use special )T( options to enhance your test with programming statements. The Step 4enerator guides you step-by-step through the process of adding recordable and non-recordable operations /methods and properties0 to your test. You can also synchroni2e your test to ensure that your application is ready for )T( to perform the ne,t step in your test, and you can measure the amount of time it takes for your application to perform steps in a test by defining and measuring transactions. You can also manually enter standard .3Script statements, as well as statements using )T( test ob+ects and operations, in the '+pert *ie$ !sing &elati%e Paths in QTP )T( enables you to define the path to a resource that you are adding to the file system or to )uality enter, as a relative or an absolute path. Note: If you are working with the Resources and Dependencies model with Quality Center 10 00! specify an a"solute Quality Center path "hen you specify a path to a function library, shared ob+ect repository, recovery scenario, or environment variable file, )T( checks if the path, or the initial part of the path, e,ists in the 1olders pane of the 5ptions dialog bo, /Tools , )ptions , -olders node0. The 1olders pane contains a search list in which you can define where )T( searches for tests, actions, or files. )T( then opens one of the following two dialog bo,es, depending on whether the path you specified, or a part of the path, e,ists in the 1olders pane. 6ote: If you are connected to QualityCenter 10 00! these dialog "o#es are displayed only if you select a path in the file system or in a QualityCenter $ # pro%ect .otes/ You can choose not to show one or both of these dialog bo,es when you enter a path to a resource by selecting the !o not show this message again check bo,. To show these dialog bo,es again, select the &emind me to use relative

paths when specifying a path to a resource check bo, in the 1olders pane of the 5ptions dialog bo,. This check bo, is selected by default when you first start )T(. Managing QTP Test Scripts " QTP Tutorial 0 "e can use the -ile menu to create, open, save, 2ip, un2ip, and print tests, as well as create standalone, portable tests. This section includes: reating a 6ew Test 5pening an ',isting Test Saving a Test reating (ortable opies of Your Tests 7ipping a Test $n2ipping a Test (rinting a Test Creating a .e$ QTP Test To create a new test, click the 6ew button or select 1ile 8 6ew 8 Test. A new test opens, with a new action selected in the %eyword .iew. You are ready to start creating your test. -f the test you select was last saved in an older version of )uickTest, you may be asked whether to convert the test to the current version or view it in read-only format. To open an e+isting test/ /5ptional0 onnect to a )uality enter server and pro+ect. Select 1ile 8 5pen 8 Test, or click the 5pen down arrow and select Test. The 5pen Test dialog bo, opens. -n the sidebar, select the location of the test, for e,ample, 1ile System or )uality enter Test (lan. 3rowse to and select a test. You can select the 5pen in read-only mode option at the bottom of the dialog bo,. lick 5pen. The test opens and the title bar displays the test name. 6ote: -f the test is stored in a version control-enabled )uality enter pro+ect, the 5pen button contains a down arrow, enabling you to open the test and immediately check it out. Tip: You can open a recently used test by selecting it from the &ecent 1iles list in the 1ile menu. Sa%ing a Test You can save a new test or save changes to an e,isting test. Tip/ -f changes are made to an e,isting test, an asterisk /90 is displayed in the title bar until the test is saved. .ote/ You must use the Save As option in )T( if you want to save a test under another name or create a copy of a test. You cannot copy a test or change its name directly in the file system or in )uality enter. To sa%e a ne$ test/ :. /5ptional0 onnect to a )uality enter server and pro+ect. )T( information, see onnecting to and !isconnecting from )uality enter. ;. lick the Save button or select 1ile 8 Save to save the test. The Save )T( Test dialog bo, opens. <. -n the sidebar, select the location to save the test, for e,ample, 1ile System or )uality enter Test (lan. =. 3rowse to and choose the folder in which to save the test. 6ote: -n the file system, )T( suggests a default folder called Tests. 1or all supported operating systems e,cept "indows .ista, this folder is located under your )T( (rofessional installation folder. 1or "indows .ista, this folder is located under #y!ocuments>?(>)T( (rofessional. @. Type a name for the test in the 1ile name bo,. 6ote that the test name cannot e,ceed ;;A characters /including the path0, cannot begin or end with a space, and cannot contain the following characters: > B : 9 C D E 8 F G H -f you save the test to )uality enter, the file path must not contain two consecutive semicolons /II0. J. -f you are recording and want to save the Active Screen files with your test, confirm that Save Active Screen files is selected. -f you clear this bo,, your Active Screen files will not be saved, and you will not be able to edit your test using the options that are normally available from the Active Screen. K. learing the Save Active Screen files check bo, can be especially useful for conserving disk space once you have finished designing the test and you are using the test only for test runs. Tip: -f you clear the Save Active Screen files check bo, and then later want to edit your test using Active Screen options, you can regenerate the Active Screen information by performing an $pdate &un operation. .ote/ You can also instruct )T( not to capture Active Screen files while recording or to only capture Active Screen information under certain conditions. You can set these preferences in the Active Screen pane of the 5ptions dialog bo,.

lick Save. )T( displays the test name in the title bar. To sa%e changes to an e+isting test/ :. lick the Save button to save changes to the current test. ;. Select 1ile 8 Save As to save an e,isting test to a new name or a new location. -f you select 1ile 8 Save As, the following options are available: Select or clear the Save Active Screen files check bo, to indicate whether or not you want to save the Active Screen files with the new test. 1or more information, see step J above. Select or clear the Save test results check bo, to indicate whether or not you want to save any e,isting test results with your test. 6ote that if you clear this bo,, your test result files will not be saved, and you will not be able to view them later. learing the Save test results check bo, can be useful for conserving disk space if you do not re*uire the test results for later analysis, or if you are saving an e,isting test under a new name and do not need the test results. Creating Portable Copies o1 QTP Test Scripts Tests and their resource files are often stored on a network drive or in )uality enter, as this enables the reuse of actions and other resources, and helps ease test management. Sometimes, you may need to open or run a test when you do not have access to a network drive or )uality enter. 1or e,ample, you may need to create a portable copy of a test for use when travelling to other sites. You can save a standalone copy of your test and its resource files to a local drive or to another storage device using the 1ile 8 Save Test with &esources command. "hen you save a test in this manner, )T( creates a copy of the following and saves the files in the location you specify: Source test. )T( saves a copy of this test in the location you specify. &esource files. )T( saves a copy of all resource files associated with the source test, such as function libraries and shared ob+ect repositories. )T( stores these files in sub-folders of the copied test. alled actions. )T( saves a copy of any e,ternal actions called by the source test. 1or e,ample, if Test A calls actions that are stored in Test 3, )T( creates a local copy of the actions stored in Test 3 and stores them in a sub-folder of Test A. The sub-folder has the same name as the test from which the called actions were copied. -n this e,ample, the sub-folder is named TestL3. )T( also creates a copy of any resources associated directly with these actions, such as its local shared ob+ect repositories and action sheets in the !ata Table. )T( does not, however, save the resource files associated with Test 3, so you must ensure that these resources are associated with the source test, Test A. This enables you to modify or run the test without access to a network drive or )uality enter. Tip: -f you use )T( with a concurrent license but do not have access to the concurrent license server /for e,ample, during a business trip0, you can install a commuter license. 2ipping QTP Test Scripts )T( tests contain a series of configuration, run-time, setup data, and /optionally0 Active Screen files. )T( saves these files together with the test. You can 2ip these files to conserve space and make the tests easier to transfer. To 2ip a test: !o one of the following: Select 1ile 8 ',port Test to 7ip 1ile to open the ',port to 7ip 1ile dialog bo,. Select the Archive test and resource files in a .2ip file check bo, in the Save Test with &esources dialog bo, /1ile 8 Save Test with &esources0. Type a 2ip file name and path, or accept the default name and path, and click 5%. )T( 2ips the test and its associated files. !nzipping a Test You can un2ip a test when needed. To un2ip a 2ipped test: Select 1ile 8 -mport Test from 7ip 1ile. The -mport from 7ip 1ile dialog bo, opens. 'nter or select the name of the 2ip file that you want to un2ip, choose a target folder into which you want to un2ip the files, and click 5%. )T( un2ips the test and its associated files. Print QTP Test Scripts You can print your entire test from the %eyword .iew /in table format0. You can also print a single action either from the %eyword .iew /in table format0 or the ',pert .iew /in statement format0. "hen printing from the ',pert .iew, you can also specify additional information that you want to be included in the printout. To print 1rom the #e $ord *ie$/ lick the (rint button or select 1ile 8 (rint. A standard (rint dialog bo, opens.

lick 5% to print the content of the %eyword .iew to your default "indows printer. Tip/ You can select 1ile 8 (rint (review to display the %eyword .iew on screen as it will look when printed. 6ote that the (rint (review option works only with tests created using )T( M.A and later. To print 1rom the '+pert *ie$ lick the (rint button or select 1ile 8 (rint. The (rint dialog bo, opens. Specify the print options that you want to use. -f you want to print to a different printer, or change your printer preferences, click Setup to display the (rint Setup dialog bo,. lick (rint to print according to your selections. !nderstanding the QTP #e $ord"Dri%en Methodolog You can create a test using the keyword-driven methodology, which enables you to select keywords to indicate the operations you want to perform on your application. This enables you to create structured tests that are easier to update and maintain over time. The keyword-driven methodology is especially useful for organi2ations that have both technical and less technical users because it offers a clear division of automation tasks. This enables a few e,perts to maintain the resource framework while less technical users design and maintain automated test steps. Additionally, once the basic infrastructure is in place, both types of users can often do their tasks simultaneously. 3efore you begin creating tests, you need to plan your tests to ensure that your tests cover your testing re*uirements. Tip: &ou can also create a test "y recording the operations you perform on your application! as descri"ed in Creating Tests 'sing the Recording (echanism )fter you create your test! you can enhance it using checkpoints and other special testing options !nderstanding the #e $ord"Dri%en Methodolog %eyword-driven testing is a techni*ue that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly. This section provides a general overview of the steps you perform when planning and implementing your tests. Stage 1/ Anal zing (our Application 3efore you begin creating a test, you need to analy2e your application and determine your testing needs. 1irst, determine the development environments in which your application controls were developed, such as "eb, Nava, or .6'T, so that you can load the re*uired )T( add-ins. Then determine the functionality that you want to test. To do this, consider the various activities that customers perform in your application to accomplish specific tasks. "hich ob+ects and operations are relevant for the set of business processes that need to be testedC "hich operations re*uire customi2ed keywords to provide additional functionalityC "hile you are thinking about the business processes you want to test, consider how you can divide these processes into smaller units, which will be represented by your testHs actions. 'ach action should emulate an activity that a customer might perform when using your application. As you plan, try to keep the amount of steps you plan to include in each action to a minimum. reating small, modular actions helps make your tests easier to read, follow, and maintain. Stage 0/ Preparing the Testing 3n1rastructure To complete the infrastructure that is part of the planning process, you need to build the set of resources to be used by your tests, including shared ob+ect repositories containing test ob+ects /which are representations of the ob+ects in your application0, function libraries containing functions that enhance )T( functionality, and so on. At this stage you also need to configure )T( according to your testing needs. This can include setting up your global testing preferences, your run session preferences, any test-specific preferences, and recovery scenarios. You can also create automation scripts that automatically set the re*uired configurations /such as the add-ins to load0 on the )T( client at the beginning of a run session. Oastly, you create one or more tests that serve as action repositories in which you can store the actions to be used in your tests. 4enerally, you create an action repository test for each area of your application to be tested. Storing all of your actions in specific tests enables you to maintain your actions in a central location. "hen you update an action in the action repository, the update is reflected in all tests that contain a call to that action. "hen you run a test, only the relevant action repository tests are loaded.

You then associate the shared ob+ect repositories with the relevant actions. This enables you to later insert steps using the ob+ects stored in the ob+ect repositories. "hen you create your tests, you insert calls to one or more of the actions stored in this repository. Stage 4/ Adding Steps to (our Actions -n this stage, you add steps to the actions in your test action repository. 3efore you begin adding steps, make sure that you associate your function libraries and recovery scenarios with the relevant tests, so that you can insert steps using keywords. You can create steps using the keyword-driven functionality available in the table-like, graphical %eyword .iew Por you can use the ',pert .iew, if you prefer to program steps directly in .3Script. You can add steps to your test in one or both of the following ways: !rag ob+ects from your ob+ect repository or the from Available %eywords pane to add keyword-driven steps in the %eyword .iew or ',pert .iew. The ob+ect repository and Available %eywords pane contain all of the ob+ects that you want to test in your application. /You create one or more ob+ect repositories when you prepare the testing infrastructure, as described in Stage 0/ Preparing the Testing 3n1rastructure56 "hen you drag an ob+ect into the %eyword .iew, a step is created in the action with the default operation for that ob+ect. 1or e,ample, if you drag a button ob+ect into the %eyword .iew, the click operation is automatically defined for the step. You can then modify the step as needed. &ecord on our application5 As you navigate through your application during a recording session, )T( graphically displays each step you perform as a row in the %eyword .iew. A step is something that causes or makes a change in your application, such as clicking a link or image, or submitting a data form. -n the ',pert .iew, these steps are displayed as lines in a test script /.3Script0. The Documentation column of the %eyword .iew also displays a description of each step in easy-to-understand sentences. Stage 7/ 'nhancing (our Test You can enhance the testing process by modifying your test with special testing options andBor with programming statements, such as: -nsert checkpoints and output values into your test. A checkpoint checks specific properties or other characteristics of an ob+ect and enables you to identify whether or not your application is functioning correctly. You can also use output values to e,tract data from your test. An output %alue is a value retrieved during the run session and entered into your !ata Table or stored in a variable or a parameter. You can subse*uently use this output value as input data in your test. This enables you to use data retrieved during a run session in other parts of the test. 3roaden the scope of your test by replacing fi,ed values with parameters. "hen you test your application, you can parameteri2e your steps to check how your application performs the same operations with different data. You may supply data in the !ata Table, define environment variables and values, define test or action parameters and values, or instruct )T( to generate random numbers for current user and test data. "hen you parameteri2e your test, )T( substitutes the fi,ed values in your test with the values stored in the relevant parameters. "hen you use !ata Table parameters, )T( uses the values from a different row in the !ata Table for each iteration of the test or action. /'ach run session that uses a different set of parameteri2ed data is called an iteration.0 Add user-defined functions by creating function libraries and calling their functions from your test. $se the many functional testing features included in )T( to enhance your test andBor add programming statements to achieve more comple, testing goals. Stage 8/ &unning and Debugging (our Test After you create your test, you can perform different types of runs to achieve different goals. &un our test to debug it5 You can control your run session to help you identify and eliminate defects in your test. You can use the Step 3nto, Step )%er, and Step )ut commands to run your test step by step. You can begin your run session from a specific step in your test, or run the test until a specific step is reached. You can also set breakpoints to pause your test at predetermined points. You can view or change the value of variables in your test each time it stops at a breakpoint in the !ebug .iewer. You can also manually run .3Script commands in the !ebug .iewer. &un our test to check our application5 The test starts running from the first line in your test and stops at the end of the test. "hile running, )T( connects to your application and performs each operation in your test, including any checkpoints, such as checking any te,t strings, ob+ects, tables, and so forth. -f you

parameteri2ed your test with !ata Table parameters, )T( repeats the test /or specific actions in your test0 for each set of data values in the !ata Table. &un our test to update it5 You can run your test using Maintenance &un Mode when you know that your application has changed, and you therefore e,pect that )T( will not be able to identify the ob+ects in your test. "hen you run a test in #aintenance &un #ode, a wi2ard opens for steps that fail because an ob+ect could not be found in the application. The wi2ard then guides you through the steps of resolving the issue, and, after you resolve the issue, the run continues. You can run your test using !pdate &un Mode to update the property sets used for test ob+ect descriptions, the e,pected checkpoint values, the data available to retrieve in output values, andBor the Active Screen images and values. Stage 9/ Anal zing Test &esults and &eporting After you run your test, you can view the results of the run in the Test &esults window. You can view a summary of your results as well as a detailed report. -f you captured still images or movies of your application during the run, you can view these from the Screen &ecorder tab of the Test &esults window. -f you enabled local system monitoring for your test, you can view the results in the System #onitor tab of the Test &esults window. 1inally, you can report defects detected during a run session. -f you have access to )uality enter, the ?( centrali2ed *uality solution, you can report the defects you discover to the pro+ect database. You can instruct )T( to automatically report each failed step in your test, or you can report them manually from the Test &esults window. Creating QTP Scripts !sing &ecording Mechanism QTP Tutorial 7 About &ecording Tests You record your tests while navigating through your application. As you navigate, )T( graphically displays each step you perform as a row in the %eyword .iew and a line in the ',pert .iew. A step is anything a user does that changes the content of a page or ob+ect in your application, for e,ample, clicking a link or typing data in an edit bo,. Your test steps represent the operations you perform on your application. !uring a run session, )T( uses the recorded steps to replicate the operations you performed while recording. "hile you record your test steps, )T( creates test ob+ects representing the ob+ects in your application on which you perform operations. This enables )T( to identify the ob+ects in your application both while creating a test and during a run session. &ecording can be useful in the following circumstances: You are new to )T( and want to learn how )T( interprets the operations you perform on your application and how it converts them to )T( ob+ects and built-in operations. You need to *uickly create a test that tests the basic functionality of an application or feature, and the test does not re*uire long-term maintenance. You are working with a new application or with ma+or new features of an e,isting application, and you want to learn how )T( interacts with the application. You are developing functions that incorporate built-in )T( keywords. After creating your initial test, you can further enhance it by adding and modifying steps in the %eyword .iew or ',pert .iew. :uidelines 1or &ecording QTP Test Scripts onsider the following when recording tests: -f you are recording steps on a "eb-based application, evaluate the types of events you need to record. -f you need to record more or fewer events than )T( generally records by default, you can configure the events you want to record. onsider increasing the power and fle,ibility of your test by replacing fi,ed values with parameters. "hen you parameteri2e your test, you can check how it performs the same operations with multiple sets of data, or from data stored or generated by an e,ternal source. onsider using actions to streamline the testing process. -f you have useful "in&unner assets, you can link to "in&unner tests and call "in&unner TSO functions from your )T( test. "hen you record tests, you may not notice that new ob+ects are being added to the local ob+ect repository. This may result in many testers maintaining local ob+ect repositories with copies of the same ob+ects. "hen using a keyword-driven methodology, you select the ob+ects for your steps from the e,isting ob+ect repository. "hen you

need a new ob+ect, you can add it to your local ob+ect repository temporarily, but you are also aware that you need to add it to the shared ob+ect repository for future use. "hen you record a test, )T( enters the correct ob+ects, methods, and argument values for you. Therefore, it is possible to create a test with little preparation or planning. (art Q;: Step by Step method of )T( &ecording (rocess. Choosing the QTP &ecording Mode " QTP Tutorial 8 6ormal recording mode records the ob+ects in your application and the operations performed on them. This mode is the default and takes full advantage of the )T( test ob+ect model, recogni2ing the ob+ects in your application regardless of their location on the screen. "hen working with specific types of ob+ects or operations, however, you may want to choose from the following, alternative recording modes: Analog &ecording5 'nables you to record the e,act mouse and keyboard operations you perform in relation to either the screen or the application window. -n this recording mode, )T( records and tracks every movement of the mouse as you drag the mouse around a screen or window. This mode is useful for recording operations that cannot be recorded at the level of an ob+ect, for e,ample, recording a signature produced by dragging the mouse. 6ote: You cannot edit Analog &ecording steps from within )T(. ;o$ ;e%el &ecording5 'nables you to record on any ob+ect in your application, whether or not )T( recogni2es the specific ob+ect or the specific operation. This mode records at the ob+ect level and records all runtime ob+ects as "indow or "in5b+ect test ob+ects. $se low-level recording for recording in an environment or on an ob+ect not recogni2ed by )T(. You can also use low-level recording if the e,act coordinates of the ob+ect are important for your test. 6ote: Steps recorded using ;o$ ;e%el &ecording mode may not run correctly on all ob+ects. QTP Analog &ecording Tutorial You can switch to Analog &ecording mode only while recording. The option is not available while editing. To record in Analog &ecording mode/ :. -f you are not already recording, click the &ecord button to begin a recording session. ;. lick the Analog &ecording button or select Automation , Analog &ecording. The Analog &ecording Settings dialog bo, opens.

<.

Select from the following options: &ecord relati%e to the screen5 )T( records any mouse movement or keyboard input relative to the coordinates of your screen, regardless of which application/s0 are open or which application/s0 you specified in the &ecord and &un Settings dialog bo,. Select &ecord relati%e to the screen if you perform your analog operations on ob+ects located within more than one window or if the window itself may move while you are recording your analog operations. 6ote: "hen you record in Analog &ecording mode relative to the screen, the run session will fail if your screen resolution or the screen location on which you recorded your analog steps has changed from the time you recorded. The analog tracking continues to record the movement of the mouse until the mouse reaches the )T( screen to turn off Analog &ecording or to stop recording. licking on the )T( icon in the "indows taskbar is also recorded. This should not affect your test. The mouse movements and clicks on the )T( screen itself are not recorded. &ecord relati%e to the 1ollo$ing $indo$5 )T( records any mouse movement or keyboard input relative to the coordinates of the specified window. Select &ecord relati%e to the 1ollo$ing $indo$ if all your operations are performed on ob+ects within the same window and that window does not move during analog recording. This guarantees that the test will

run the analog steps in the correct position within the window even if the windowHs screen location changes after recording. 6ote: -f you have selected to record in Analog &ecording mode relative to a window, any operation performed outside the specified window is not recorded while in Analog &ecording mode. =. -f you choose to &ecord relati%e to the 1ollo$ing $indo$, click the pointing hand and click anywhere in the window on which you want to record in Analog &ecording mode. The title of the window you clicked is displayed in the window title bo,. @. lick Start Analog &ecord. J. (erform the operations you want to record in Analog &ecording mode. All of your keyboard input, mouse movements, and clicks are recorded and saved in an e,ternal file. "hen )T( runs the test, the e,ternal data file is called. -t tracks every movement and click of the mouse to replicate e,actly the operations you recorded. K. "hen you are finished and want to return to normal recording mode, click the Analog &ecording button or selectAutomation , Analog &ecording to turn off the option. -f you chose to &ecord relati%e to the screen, )uickTest inserts the &unAnalog step for a Desktop item. 1or e,ample:

The track file called by the &unAnalog method contains all your analog data and is stored with the current action. You can use this track file in more than one action in your test, and also in other tests, by saving the action containing the &unAnalog step as a reusable action. A reusable action can be called by other tests or actions. 6ote: "hen entering the &unAnalog method, you must use a valid and e,isting track file as the method argument. Tip: To stop an analog step in the middle of a run session, press trl R 'sc, then click Stop in the Testing toolbar. Tips 1or !sing the Pointing <and You can hold the left trl key to change the pointing hand to a standard pointer. You can then change the window focus or perform operations in )T( or in your application, such as right-clicking, using the scroll bars, or moving the pointer over an ob+ect to display a conte,t menu. -f the window containing the ob+ect you want to select is partially hidden by another window, hold the pointing hand over the partially hidden window for a few seconds until it comes to the foreground. Then point to and click the re*uired ob+ect. You can configure the length of time re*uired to bring a window into the foreground using the 4eneral pane of the 5ptions dialog bo,. -f the window containing the ob+ect you want to select is fully hidden by another window, or if a dialog bo, is hidden behind a window, press the left trl key and arrange the windows as needed. -f the window containing the ob+ect you want to select is minimi2ed, you can display it by holding the left trl key, right-clicking the application in the "indows task bar, and choosing &estore from the conte,t menu. -f the ob+ect you want to select can be displayed only by performing an event /such as rightclicking or moving the pointer over an ob+ect to display a conte,t menu0, hold the left trl key. The pointing hand temporarily turns into a standard pointer and you can perform the event. "hen the ob+ect you want to select is displayed, release the left trl key. The pointer becomes a pointing hand again. QTP ;o$ ;e%el &ecording Tutorial You can switch to ;o$ ;e%el &ecording mode only while recording a test. The option is not available while editing a test.

To record in Oow Oevel &ecording mode: :. -f you are not already recording, click the &ecord button to begin a recording session. ;. lick the ;o$ ;e%el &ecording button or select Automation , ;o$ ;e%el &ecording. The record mode changes to ;o$ ;e%el &ecording and all of your keyboard input and mouse clicks are recorded based on mouse coordinates. "hen )T( runs the test, the cursor retraces the recorded clicks. <. "hen you are finished and want to return to normal recording mode, click the ;o$ ;e%el &ecording button or selectAutomation , ;o$ ;e%el &ecording to turn off the option. The following e,amples illustrate the difference between the same operations recorded using normal mode and ;o$ ;e%el &ecording mode. Suppose you type the word tutorial into a user name edit bo, and then press the Tab key while in normal recording mode. Your test is displayed as follows in the %eyword .iew and ',pert .iew:

Working $ith #e $ord *ie$ in <P QTP " QTP Tutorial 9 The %eyword .iew provides an easy way to create, view, and modify tests in a graphical easy-to-use format. About "orking with the %eyword .iew in ?(Ss )T(: The %eyword .iew enables you to create and view the steps of your test in a modular, table format. 'ach step is a row in the %eyword .iew that is comprised of individual, modifiable parts. You create and modify steps by selecting items and operations in the %eyword .iew and entering information as re*uired. 'ach step is automatically documented as you complete it, enabling you to view a description of your test in understandable sentences. You can also use these descriptions as instructions for manual testing, if re*uired. You can use the %eyword .iew to add new steps to your test and to view and modify e,isting steps. "hen you add or modify a step, you select the test ob+ect or other step type you want for your step, select the method operation you want to perform, and define any necessary values for the selected operation or statement. "orking in the %eyword .iew does not re*uire any programming knowledge. The programming re*uired to actually perform each test step is done automatically behind the scenes by )T(. The Keyword View The %eyword .iew enables you to create and view the steps of your test in a keyword-driven, modular, table format. The %eyword .iew is comprised of a table-like view, in which each step is a separate row in the table, and each column represents the different parts of the steps. The columns displayed vary according to your selection.

Actions are the highest level of the test hierarchy. They contain all the steps that are part of that action, and can include calls to other reusable actions. -n the %eyword .iew, you can use the Action toolbar to view either the flow of all the top-level action calls in the test, or the content of a specific action. You can also display an action by double-clicking it in the Test 1low pane. You can insert a new action, a call to an action, or a copy of an action, to your test. Tip: &ou can copy and paste or drag and drop actions to mo*e them to a different location within a test 'ach action is comprised of steps. 'ach step is inserted as a row in the %eyword .iew. 1or e,ample, the %eyword .iew could contain the following rows:

These rows show the following three steps that are all performed on the Welcome/ Mercur Tours page of the #ercury Tours sample "eb site: tutorial is entered in the user.ame edit bo,. An encrypted string is entered in the pass$ord edit bo,. The Sign"3n image is clicked. The Documentation column translates each of the steps into understandable sentences. 1or every step in the %eyword .iew, )T( displays a corresponding line of script in the ',pert .iew. -f you select a specific row in the %eyword .iew and switch to the ',pert .iew, the cursor is located in the corresponding line of the script. You can use the %eyword .iew to add steps at any point in your test. After you add steps, you can modify or delete them using standard editing commands and drag-and-drop functionality. You can print the contents of the %eyword .iew to your "indows default printer /and even preview the contents prior to printing0. -n the %eyword .iew, you can also view properties for items such as checkpoints, output values, and actions, use conditional and loop statements, and insert breakpoints to assist you in debugging your test. The %eyword .iew can contain any of the following columns: 3tem, )peration, *alue, Assignment, Comment, andDocumentation. A brief description of each column is provided below. Columns Description/ -tem olumn: The item on which you want to perform the step /test ob+ect, utility ob+ect, function call, or statement0. This column displays a hierarchical icon-based tree. The highest level of the tree are actions, and all steps are contained within the relevant branch of the tree. Steps performed within the same parent ob+ect are displayed under that same ob+ect. 1unction calls, utility ob+ects, and statements are placed in the tree hierarchy at the same level as the item above them /as a sibling0. You can collapse or e,pand an item in the item tree to change the level of detail that the tree displays. To collapse an item and its sub-items, click the arrow / 0 to the left of the itemHs icon, press the minus key /-0 on your keyboard number pad, press the left arrow key on your keyboard, or right-click the item and selectCollapse Sub Tree. The item tree hides all its sub-items and the collapse arrow changes to e,pand.

To collapse all the items in the tree, select *ie$ , Collapse All. To e,pand an item one level or to its previously e,panded state, select it and click the arrow /down arrow0 to the left of the item icon, press the plus key /R0 on your keyboard number pad, press the right arrow key on your keyboard, or right-click the item and select '+pand Sub Tree. The tree displays the details for the item and all its first-level sub-items and the e,pand arrows change to collapse. To e,pand an item and all its sub-items, select the item and press the asterisk /90 key on your keyboard number pad. The tree displays the details for the item and all its sub-items and the e,pand arrows change to collapse. To e,pand all the items in the tree, select *ie$ , '+pand All. Note: +hen you use the +! -! and * keys to e#pand and collapse the Item tree! make sure that the entire row is selected ,"y clicking to the left of the item-s icon. and that a specific column is not selected! "efore pressing the re/uired key 0therwise! the keys will not work 5peration olumn: The operation to be performed on the item. This column contains a list of all available operations /methods, functions, or properties0 that can be performed on the item selected in the 3tem column, for e,ample, Click andSelect. The default operation for the item selected in the 3tem column is displayed by default. .alue olumn: The argument values for the selected operation, or the content of the statement. The *alue cell is partitioned according to the number of arguments of the selected operation. -f an argument has a predefined list of values, )T( provides a drop-down list of possible values. -f a list of values is provided, you cannot manually type a value in this bo,. Assignment olumn: The assignment of a value to or from a variable. 1or e,ample, Store in cCols would store the return value of the current step in a variable called c ols, which you could then use later in the test. You can select either Store in or :et 1rom, depending on whether you want to retrieve the value from a variable or store the value in a variable. A Store in = value in the Assignment column is e*uivalent to an = > ?step, line in the ',pert .iew. A:et -rom = value in the Assignment column is e*uivalent to a ?step, > = line in the ',pert .iew. omment olumn: A free te,t edit bo, for any information you want to add regarding the step. These are also displayed as inline comments in the ',pert .iew. 6ote: You can also enter a comment on a new line below the currently selected step by choosing 3nsert 8 Comment. 6ote: -f you do not see one or more of the columns in the %eyword .iew, you can use the %eyword .iew 5ptions dialog bo, to display them. Tips for "orking with the %eyword .iew: You can use the left and right arrow keys to move the focus one cell to the left or right, with the following e,ceptions: -n the 3tem column, the left and right arrow keys collapse or e,pand the item /if possible0. -f not possible, the arrow keys behave as in any other column. "hen a cell is in edit mode, for e,ample, when modifying a value or comment, the left and right arrow keys move within the edited cell. "hen a *alue cell is selected, press trlR1:: to open the .alue onfiguration 5ptions dialog bo,. "hen the entire step is selected /by clicking to its left0, use the @ key /e,pands a specific branch0, " key/collapses a specific branch0, and A key /e,pands all branches0 to e,pand and collapse the 3tem tree. "hen a row is selected /not a specific cell0, you can type a letter to +ump to the ne,t row that starts with that letter. Working $ith Actions in QTP QTP Tutorial B You can divide )T( Test Scripts into actions to streamline the process of testing your application. This section covers the basic use of actions in your test. $sing advanced action-related features is described in Working $ith Ad%anced Action -eatures5 3ntroduction to QTP Actions Actions help divide your test into logical units, such as the main sections of a "eb site, or specific activities that you perform in your application. A test comprises calls to actions. "hen you create a new test, it contains a call to a single action. 3y creating tests that call multiple actions, you can design tests that are more modular and efficient.

An action consists of its own test script, including all of the steps in that action, and any ob+ects in its local ob+ect repository. 'ach action is stored together with the test in which you created it. You can insert a call to an action that is stored with the test and, depending on the properties of the action, you may also be able to call an action stored with another test. "hen you open a test, you can choose to view the test flow /calls to actions0 or you can view and edit the individual actions stored with your test. -f you work with tests that include many steps or lines of script, it is recommended that you use actions to divide your test steps. Actions should ideally contain no more than a few do2en test steps. 1or e,ample, suppose you want to test several features of a flight reservation system. You plan several tests to test various business processes, but each one re*uires the same login and logout steps. You can create one action that contains the steps re*uired for the login process, another for the logout steps, and other actions for the main steps in your test. After you create the login and logout actions, you can insert those actions into other tests. -f you create a test in which you log into the system, book one flight, and then log out of the system, your test might be structured as shownPone test calling three separate actions:

Actions enable you to parameteri2e and iterate over specific elements of a test. They can also make it easier to modify steps in one action when part of your application changes. 1or every action called in your test, )T( creates a corresponding action sheet in the !ata Table so that you can enter !ata Table parameters that are specific to that action only. !sing :lobal and Action Data Sheets in QTP "hen you output a value to the !ata Table or add a !ata Table parameter to your test, you can specify whether to store the data in the :lobal data sheet or in the action data sheet. hoosing :lobal sheet enables you to create a new column or select an e,isting column in the :lobal sheet in the !ata Table. "hen you run your test, )T( inserts or outputs a value from or to the current row of the 4lobal data sheet during each global iteration. You can use the columns in the 4lobal data sheet for !ata Table output values or !ata Table parameters in any action. This enables you to pass information between actions. 'ach action also has its own sheet in the !ata Table so that you can insert data that applies only to that action. hoosing Current action sheet Clocal6 enables you to create a new column or select an e,isting column in the corresponding action sheet in the !ata Table. 6ote that the name of the action sheet is the same as the name of the relevant action. "hen you run your test, )T( inserts or outputs a value from or to the current row of the current action /local0 data sheet during each action iteration. "hen there are parameters or output value steps in the current actionHs sheet, you can set )T( to run one or more iterations on that action before continuing with the current global iteration of the test. "hen you set your action call properties to run iterations on all rows, )T( inserts the ne,t value from or to the corresponding action parameter or output value during each action iteration, while the values of the global parameters stay constant. Note: If you create Data Ta"le parameters or output *alue steps in your action and select to use the Current action sheet (local) option! "e sure that the run settings for your action are set correctly in the Run ta" of the

)ction Call 1roperties dialog "o# &ou can set your action to run without iterations! to run iterations on all rows in the action-s data sheet! or to run iterations only on the rows you specify 1or e,ample, suppose you want to test how a flight reservation system handles multiple bookings. You may want to parameteri2e the test to check how your site responds to multiple sets of customer flight itineraries. "hen you plan your test, you plan the following procedures: :. The travel agent logs into the flight reservation system. ;. The travel agent books five sets of customer flight itineraries. <. The travel agent logs out of the flight reservation site. "hen you consider these procedures, you reali2e that it is necessary to parameteri2e only the second stepPthe travel agent logs into the flight reservation system only once, at the beginning, and logs out of the system only once, at the end. Therefore, it is not necessary to parameteri2e the login and logout procedures in your test. 3y creating three separate actions within your testPone for logging in, another for booking a flight, and a third for logging outPyou can parameteri2e the second action in your test without parameteri2ing the others. Test -lo$ pane in QTP The Test 1low pane uses the following icons to indicate the different types of item in the hierarchy:

Tips: T You can right-click in the Test 1low pane title bar to view available display options and decide how to display the Test 1low pane. 1or e,ample, you can auto hide the pane, dock it, or close it. T You can click the Test -lo$ Pane toolbar button to hide or show the Test 1low pane view. "orking with Actions in Test 1low (ane You can perform the following operations in the Test 1low pane: Displa an action in the #e $ord *ie$ and '+pert *ie$5 !ouble-click an action in the Test 1low pane to show only that action in the %eyword .iew and ',pert .iew. *ie$ or hide the sub"nodes in the test5 &ight-click the Test node in the tree and select '+pand All orCollapse All to view or hide the sub-nodes in the tree. You can also select the Test node and press @ or 9 on the keyboard to e,pand all the nodes in the test, and " to collapse the nodes. Displa the test properties5 &ight-click the Test node in the tree and then select Settings to display the Test Settings dialog bo,. !etails of the test and its path are displayed. *ie$ or hide the sub"nodes o1 an action5 &ight-click an action in the tree and then select '+pand Sub Treeor Collapse Sub Tree to view or hide the sub-nodes in the action. You can also select a sub-node and press @or 9 on the keyboard to e,pand the node and " to collapse the node.

Displa the action properties5 &ight-click an action in the tree and then select Action Properties to display the Action (roperties dialog bo,. The name of the action and its path are displayed. Displa the action call properties5 &ight-click an action in the tree and then select Action Call Properties to display the Action all (roperties dialog bo,. Work $ith the )bDect &epositor 5 &ight-click an action in the tree and then select )bDect &epositor to open the 5b+ect &epository window, which displays a tree containing all ob+ects in the current test. Manage Actions5 &ight-click an action in the tree and then select Cop or Delete. Select Cop to open the Select Action dialog bo, and create a copy of the action in your test. Select Delete to remove the action from your test. &un the test5 &ight-click an action in the tree and then select &un 1rom Action or &un to Action to start a run session from the beginning of the selected action, or to run the test until the beginning of the selected action and then pause the run session. Debug our test5 &ight-click an action in the tree and then select Debug 1rom Action to begin /and pause0 a debug session at the beginning of the selected action. Change the run order o1 actions5 You can perform either of the following steps to move a top-level action /a direct child of the test0 in the Test 1low (ane tree, and change the run order of the test accordingly. The action and any sub-actions are moved. &ight-click a top-level action in the tree and then select Mo%e !p or Mo%e Do$n. You can also press trlR$p arrow or trlR!own arrow to move an action and its sub-actions. !rag a top-level action in the tree up or down to the re*uired location. "hen you drag a selected action, a line is displayed, enabling you to see the location in the tree to which the action will be moved. You can only drag top-level actions. Selecting the parent action automatically includes all its sub-actions. You cannot drag a sub-action, nor can you drag a parent action together with only some of its sub-actions. -f a test contains a call to an action that does not e,ist or cannot be found, the action still appears in the tree in the Test 1low pane, and )T( lists the action in the #issing &esources pane. Smart script creation $ith QTPEs Action Toolbar in the #e $ord *ie$ The Action toolbar contains options that enable you to view the top-level actions in the test flow or to view any action stored with your test /whether or not the action is actually called in the test0. The Action toolbar is automatically displayed above the %eyword .iew when a reusable or e,ternal action is included in test. Tip: &ou can display or hide the )ction tool"ar in the 2eyword 3iew "y choosing View > Toolbars > Action -n the ',pert .iew, the Action Oist is always visible and the ',pert .iew always displays the steps for the selected action. The Action ;ist enables you to view either the test flow /the calls to the top-level actions in the test0 or you can view the steps for a selected reusable or e,ternal action. Selecting Test -lo$ in the Action Oist displays the overall flow of your test with all the calls to the top-level actions in your test. The test flow also enables you to view and edit the individual steps of non-reusable actions. An action view displays all the details of the selected reusable or e,ternal action.

-n the test flow, reusable actions are not e,pandable. You can view the e,panded steps of a reusable action by selecting the action from the Action Oist. There are several ways to open the action view for a reusable or e,ternal action in the %eyword .iew: -n the Test 1low pane, double-click the action you want to view. $se the Action toolbar to display the top-level Test 1low and then double-click the call to the action you want to view.

$se the Action toolbar to display the top-level Test 1low and then highlight the call to the action you want to view and click the Sho$ button. Select the name of the action from the Action Oist. You may have actions that are stored with your test, but are not currently called from your test. /They may be called by other tests, and you can insert calls to these actions from within your test, if needed0. Actions that are not called in your test are not displayed in the Test 1low pane, but they are displayed in the Action Oist. You can select these actions to view or edit their contents. -f an action is stored with your test but is not called by the test, and you are sure that you do not need the action for this test or any other test, you can delete the action from the test. Create Actions in QTP " Step b Step Tutorial You can create new actions and add calls to them, as needed. You can call the new action from your test flow as a top-level action, or you can call the new action from within another action in your test as a sub-action /or nested action0. You can also split an e,isting action into two actions. To create a new action in your test: :. -f you want to insert a call to the new action from an e,isting action in your test, click the step after which you want to insert the new action. To insert a call to the new action from the test flow as a top-level action, click any step. ;. Select 3nsert , Call to .e$ Action or click the 3nsert Call to .e$ Action button on the 3nsert toolbar. The -nsert all to 6ew Action dialog bo, opens.

<. -n the .ame bo,, type a new action name or accept the default name. -f you rename the action, make sure that the action name is uni*ue /within the test0, does not e,ceed :A;< characters, does not begin or end with a space, and does not contain the following characters: > B : 9 C D E 8 F G H U V W =. -n the Description bo,, add a description of the action. You can also add an action description at a later time using the Action (roperties dialog bo,. Tip: !escriptions of actions are displayed in the Select Action dialog bo,. The description makes it easier for you to choose an e,isting action you want to call. @. 'nsure &eusable Action is selected if you want to be able to call the action from other tests or multiple times from within this test. 3y default, this option is selected. You can also set or modify this setting at a later time using the Action (roperties dialog bo,. J. !ecide where to insert the call to the action by selecting At the end o1 the test or A1ter the current step. hoosingAt the end o1 the test creates a call from the test flow to a top-level action. hoosing A1ter the current step inserts the call to the action from within the current action /nests the action0. Note: If the currently selected step is a reusa"le action from another test! the new action is added automatically to the end of the test ,the location options are disa"led.

7. lick )#. A new action is stored with your test and the call to it is displayed at the bottom of the test or after the current step. You can move your action call to another location at a parallel /sibling0 level within your test by dragging it to the desired location. 1or more information on moving actions, see $sing the Test 1low (ane. M. -f you inserted the call to the new action while editing your test, make sure your new action is selected before adding steps to it. Con1iguring Actions in QTP Setting Action Properties/ The Action (roperties dialog bo, enables you to define options for the stored action. These settings apply each time the action is called. You can modify an action name, add or modify an action description, and set an action as reusable or non-reusable. 1or an e,ternal action, you can set the !ata Table definitions. The Action (roperties dialog bo, also enables you to define input and output parameters to be used by the action, and specify the ob+ect repositories that are associated with the action. 1or more information, see Associating 5b+ect &epositories with Actions. 6ote: The following sections describe how to define action properties using the Action (roperties dialog bo,. You can also define actions and action parameters in the ',pert .iew. You can open the Action (roperties dialog bo, while working with your test by: &ight-clicking an action node in the Test 1low pane and selecting Action Properties. hoosing 'dit 8 Action , Action Properties when an action node is highlighted in the %eyword .iew or displayed in the ',pert .iew. &ight-clicking an action node in the %eyword .iew and selecting Action Properties. The Action (roperties dialog bo, always contains the 4eneral tab, the (arameters tab, the Associated &epositories tab, and the $sed 3y tab:

6ote: -n addition to the tabs shown above, the Action (roperties dialog bo, for a called e,ternal action also contains an ',ternal Action tab, and the other tabs are read-only. Setting :eneral Action Properties You can use the 4eneral tab of the Action (roperties dialog bo, to modify the name of an action, add or edit an actionHs description, or change the reusability status of the action. To open the Action (roperties dialog bo,, right-click an action in the Test 1low pane and select Action Properties, or select 'dit , Action , Action Properties.

6ote: The name of the action and its path are displayed in the tab. -f it was defined with a relative path in )T(, then the path is displayed as .>Ename of action8. -f the action is a reusable action or an e,ternal action, then &eusable action or'+ternal Action is displayed ne,t to the action name. The 4eneral tab includes the following options: )ption 6ame Description The name of the action. 3y default, the action name is the internal name provided by )T(, such as Action :. This number is incremented by : for each new action that is added to the test. You can rename the action, as needed. The action name must be uni*ue /within the test0, cannot begin or end with a space, cannot e,ceed :A;< characters, and cannot contain the following characters: > B : 9 C D E 8 F G H U V W The folder or )uality enter path where the action is stored.

Oocation

!escription You can insert comments about the action. An action description helps you and other testers know what a specific action does without reviewing all the steps in the action. The description is also displayed in the description area of the Select Action dialog bo,. This enables you and other testers to determine which action you want to call or copy from another test without having to open it. .ote/ You can also add a description when inserting a call to a new action. &eusable action -ndicates whether the action is a reusable action. 3y default, this check bo, is selected. A reusable action can be called multiple times within a test and can be called from other tests. 6on-reusable actions can be copied and inserted as independent actions, but cannot be inserted as calls to the original action. "hen you change this setting, the action icon changes to a non-reusable action icon or reusable action icon as appropriate. -f the steps of the action were e,panded, they collapse after changing a non-reusable action to a reusable action. You can view the steps of the reusable action by selecting the action name in the Test 1low pane.

6otes: T -f the action is called more than once within the test flow or if the action is called by a reusable action, the &eusable action option is read-only. -f you want to make the action non-reusable, remove the additional calls to the action from the test. T You cannot e,pand reusable actions from the test flow view. You can view details of a reusable action by double-clicking the action in the %eyword .iew, or selecting the action from the Action Oist. 1or more information on the test flow and action views, see $sing the Action Toolbar in the #e $ord *ie$5 Setting Properties 1or an '+ternal Action "hen you insert a call to an e,ternal action, you can choose where you want )T( to store the !ata Table data. You can specify this in the ',ternal Action tab of the Action (roperties dialog bo,. To open the Action (roperties dialog bo,, right-click an action in the Test 1low pane and select Action Properties, or select 'dit , Action , Action Properties.

The ',ternal Action tab includes the following options: )ption Description !ata Table -ndicates where to store the actionHs !ata Table data: parameters To use the original actionHs data, select !se data stored $ith the original action Cread"onl 6. -f you select this option, the data is read-only when viewed from the calling test, and all changes to the original actionHs data sheet apply when the action runs in the calling test. To use an editable copy of the data in the testHs !ata Table, select !se a localF editable cop . -f you select this option, a copy of the called actionHs data sheet is added to the calling testHs !ata Table and is independent of the original action. hanges to the original actionHs data sheet do not affect the calling test even if you insert another call to this action after the actionHs data sheet is modified. -f the called action has parameteri2ed steps that rely on new information in the original actionHs data sheet, enter the relevant column names and re*uired data to the action sheet in the calling test manually. .ote: "hen you call an e,ternal action, the global data sheet columns and data from the called actionHs test are always imported as a local, editable copy in the calling testHs global data sheet. hanges to the original actionHs global data sheet do not affect the calling test even if you insert another call to this action after the called actionHs global data sheet is modified. -f the called action has parameteri2ed steps that rely on new information in the global data sheet, enter the relevant column names and re*uired data to the calling testHs global data sheet manually. *ie$ing a ;ist o1 the Tests and Actions !sing this Action -f your tests are stored in )uality enter and are using the resources and dependencies model, the Action (roperties dialog bo, displays the $sed 3y tab. This enables you to view a list of the tests and actions that contain calls to this particular action. This is the same list that is displayed in the !ependencies tab of the Test (lan module in )uality enter. To open the Action (roperties dialog bo,, right-click an action in the Test 1low pane and select Action Properties, or select 'dit , Action , Action Properties.

The $sed 3y tab includes the following options: )ption Test Action Description -ndicates the )uality enter path of the test containing a call to this action. -ndicates the internal name of the action containing a call to this action. The internal name is the name that )T( applies to an action by default when the action is created, for e,ample, Action :. The internal name of the action calling this action is displayed even if the calling action was renamed.

.esting Actions in QTP Sometimes you may want to call an action from within an action. This is called nesting. 3y nesting actions, you can: #aintain the modularity of your test. &un one or more actions based on the results of a conditional statement. 1or e,ample, suppose you have parameteri2ed a step where a user selects one of three membership types as part of a registration process. "hen the user selects a membership type, the page that opens depends on the membership type selected in the previous page. You can create one action for each type of membership. Then you can use 31 statements to determine which membership type was selected in a particular iteration of the test and run the appropriate action for that selection. -n the %eyword .iew, your test might look something like this:

-n the ',pert .iew, your test might look something like this: 3rowser/D#embership (referenceD0.(age/D#embership (referenceD0."eb&adio4roup/D#emTypeD0.Select !ataTable/DmemtypeD, dt4lobalSheet0 #emLTypeX3rowser/D#embership (referenceD0.(age/D#embership (referenceD0."eb&adio4roup/D#emTypeD0.4et&5(roperty /DvalueD0 -f #emLTypeXDpaidD Then &unAction D(aidL#emD, one-teration 'lse-f #emLType X DfreeD Then &unAction D1reeL#emD, one-teration 'lse &unAction D(referredD, one-teration 'nd -f To nest an action within an e,isting action: :. ?ighlight the step after which you would like to insert the call to the action. ;. 1ollow the instructions for inserting a call to a new action as described in reating 6ew Actions.

Splitting Actions in QTP You can split an action that is stored with your test into two sibling actions or into parent-child nested actions. "hen you split an action, the second action starts with the step that is selected when you perform the split action operation. You cannot split an action, and the option is disabled when: an e,ternal action is selected the first step of an action is selected you are working with a read-only test recording a test running a test "hen you split an action in your test that uses a local ob+ect repository: )T( makes a copy of the local ob+ect repository. The two actions have identical local ob+ect repositories containing all of the ob+ects that were in the original local ob+ect repository. -f you add ob+ects to one of the split actions, the new ob+ects are added only to the corresponding local ob+ect repository. To split an action/ :. Select the step before which you want the new /second0 action to begin.

;. Select 'dit , Action , Split Action, click the Split Action button, or right-click the step and select Action , Split. The Split Action dialog bo,

opens. <. Select one of the following options: 3ndependent o1 each other5 Splits the selected action into two sibling actions. .ested Cthe second action is called b the 1irst65 Splits the selected action into a parent action whose last step calls the second, child action. =. -f you want, modify the name and description of the two actions in the .ame and Description bo,es. 6ote: -f a reusable action is called more than once in a test and you split the action into two independent actions, each call to the action within the test will be followed by a call to the new /reusable0 action. -f a reusable action is called from another test, however, splitting it may cause the calling test to fail. &ename QTP Actions To rename an action in the &ename Action dialog bo,: :. -n the %eyword .iew, select the call to the action you want to rename and select 'dit , Action , &ename Action. -n the ',pert .iew, display the action that you want to rename and select 'dit , Action , &ename Action. The &ename Action dialog bo, opens.

;. 'nter a new name for the action in the .e$ name bo,. #ake sure that action name is uni*ue within the test, does not begin or end with a space, does not e,ceed :A;< characters, and does not contain the following characters: > B : 9 C D E 8 F G H U V W <. lick )# to save the change. Tip/ (ou can also press Shi1t @ -0 to open the &ename Action dialog bo+5 To rename an action in the Action Properties dialog bo+/ :. -n the Test 1low pane or in the %eyword .iew, right-click the action and select Action Properties. Alternatively, in the %eyword .iew or in the ',pert .iew, select an action and select 'dit ,

Action , Action Properties. The Action (roperties dialog bo, opens.

;. 'nter a new action name in the .ame bo, of the 4eneral tab. 'ach action name within a test must be uni*ue. #ake sure that action name is uni*ue within the test, does not begin or end with a space, does not e,ceed :A;< characters, and does not contain the following characters: > B : 9 C D E 8 F G H U V W <. lick )# to save the change. &emo%ing Actions 1rom a Test Script in QTP -f an action is no longer needed in )T( Test Script, you can remove it from your test. -f the action is stored with your test /reusable or non-reusable action0 and is called only once in the test, then removing the action deletes it entirely. Alternatively, if the action is stored in another test /e,ternal action0, or is called more than once in this test /reusable action0, removing the action deletes the selected call to the action, without affecting the source action. The following table illustrates what happens when you delete an action:

Tips 1or &emo%ing Action Calls and Deleting Actions )T( provides several locations from which you can remove calls to actions: &esources pane5 $se to simultaneously remove all calls to a specific action. -f you remove a reusable or non-reusable local action, )T( removes all calls to the action in this test and deletes the action in its entirety. -f you remove an e,ternal action, )T( removes all calls to the action from the test, but does not affect the source action in any way. Test -lo$ pane or the #e $ord *ie$5 $se to remove specific calls to an action. -f a test contains multiple calls to a single reusable action, and you remove somePbut not allPof the calls, )T( removes the calls to the action in the specified locations, but does not delete the action itself. This means that the action can continue to be called by this test and by other tests, as needed. -f you remove all calls to an action, the result is the same as removing the action from the &esources pane. 1or reusable and non-reusable actions, )T( removes all calls to the action in this test and deletes the action in its entirety. 1or e,ternal actions, )T( removes all calls to the action from the test, but does not affect the source action in any way. "hen )T( deletes an action in its entirety, the corresponding action sheet is removed from the !ata Table, but columns related to this action that are located in the 4lobal sheet are not removed.

-f you open a test containing a call to an action you removed, )T( informs you that the action is missing. To remo%e a call to an action or delete an entire action/ :. -n the &esources pane, the Test 1low pane, or the %eyword .iew: &ight-click the action you want to remove and select Delete. Select the action you want to remove and press the Delete key on your keyboard. Select the action you want to remove and select 'dit , Delete. ;. lick (es in the confirmation message bo,. 6ote: -f an action stored in this test is called by other tests, deleting the action in this test may cause other tests to fail. Action Templates in QTP -f you want to include one or more statements in every new action in your test, you can create an action template. 1or e,ample, if you always enter your name as the author of an action, you can add this comment line to your action template. An action template applies only to actions created on your computer. To create an action template/ :. reate a te,t file containing the comments, function calls, and other statements that you want to include in your action template. The te,t file must be in the structure and format used in the ',pert .iew. ;. Save the te,t file as ActionTemplate5mst in your ?QTP3nstallation -older,Gdat folder. All new actions you create contain the script lines from the action template. 6ote: 5nly the file name ActionTemplate5mst is recogni2ed as an action template. 3nsert Multiple Actions in a QTP Script "hen you create a )T( Script, it includes one action. All the steps you add and all the modifications you make while editing your test are part of a single action. You can divide your test into multiple actions by creating new actions and inserting calls to them, by inserting calls to e,isting actions, or by splitting e,isting actions. The actions used in the test, and the order in which they are run, are displayed in the Test 1low pane. There are three kinds of actions: &eusable action5 An action that can be called multiple times by the test with which it is stored /the local test0, as well as by other tests. .on"reusable action5 An action that can be called only in the test with which it is stored, and can be called only once. '+ternal action5 A reusable action stored with another test. ',ternal actions are read-only in the calling test, but you can choose to use a local, editable copy of the !ata Table information for the e,ternal action. 3y default, new actions are reusable. You can mark each action you create in a test as reusable or non-reusable. 5nly reusable actions can be called multiple times from the current test or from another test. You can store a copy of a non-reusable action with your test and then insert a call to the copy, but you cannot directly insert a call to a nonreusable action saved with another test. -nserting calls to reusable actions makes it easier to maintain your tests, because when an ob+ect or procedure in your application changes, it needs to be updated only one time, in the original action. Two or more tests can call the same action and one action can call another action /this is known as nesting an action0. omple, tests may have many actions and may share actions with other tests. "hen you run a test with multiple actions, the test results are divided by actions within each test iteration so that you can see the outcome of each action, and you can view the detailed results for each action individually. Associating )bDect &epositories $ith Actions You can associate obDect repositories with actions in several ways: You can associate a single action with an ob+ect repository by right-clicking the action in the &esources pane and choosing Associate repositor $ith actionfrom the conte,t menu. This opens the 5pen Shared 5b+ect &epository dialog bo,, enabling you to associate an ob+ect repository with the selected action. You can use the Associated &epositories tab of the Action (roperties dialog bo, to associate one or more ob+ect repositories with the current action. /&ight-click an action in the Test 1low pane and select Action Properties, or select 'dit , Action , Action Propertiesto open the Action (roperties dialog bo,.0

Tip: &ou can associate shared o"%ect repositories with multiple actions simultaneously! using the )ssociate Repositories dialog "o# )T( searches these files to locate test ob+ect descriptions when identifying ob+ects in your application. You can associate ob+ect repositories that are saved in your file system or in a )uality enter pro+ect. 6ote: )T( uses associated ob+ect repositories from )uality enter pro+ect folders only when you are connected to the corresponding )uality enter pro+ect. -f you are not connected to the relevant )uality enter pro+ect, all associated ob+ect repositories that are stored in your )uality enter pro+ect are listed as missing in the #issing &esources pane. /)T( always lists any associated ob+ect repository that cannot be found in the #issing &esources pane.0 -n addition, if an ob+ect repository cannot be found, )T( displays a warning message when you click the Associated &epositories tab in the Action (roperties dialog bo,. )T( also adds a *uestion mark to the missing ob+ect repository icon to the left of the missing ob+ect repository in the Associated obDect repositories list. You can associate as many ob+ect repositories as needed with an action, and the same ob+ect repository can be associated with different actions as needed. You can also set the default ob+ect repositories to be associated with all new actions in all tests. The order of the ob+ect repositories in the list determines the order in which )T( searches for a test ob+ect description. -f there are test ob+ects in different ob+ect repositories with the same name, ob+ect class, and parent hierarchy, )T( uses the first one it finds based on the priority order defined in the Associated &epositories tab. The local ob+ect repository is always listed first and cannot be moved down the priority list or deleted. You can enter an associated ob+ect repository as a relative path. !uring the run session, )T( searches for the file in the folders listed in the 1olders pane of the 5ptions dialog bo,, in the order in which the folders are listed. 6ote: -f you want other users or ?( products to be able to run an action on other computers, and the actionHs associated ob+ect repositories are stored in the file system, you can set the file path as a relative path /click the path once to highlight it, and then click it again to enter edit mode0. Any users who want to run this action should then specify the drive letter and folder in which )T( should search for the relative path in the 1olders pane of the 5ptions dialog bo, /Tools , )ptions, -olders node0. 3mportant/ -f you are working with the &esources and !ependencies model with )uality enter :A.AA, you should store the actionHs associated ob+ect repositories in the )uality enter Test &esources module and specify an absolute )uality enter path in the 1olders pane. You can add, delete and prioriti2e the ob+ect repositories associated with the action using the following buttons: