2Target Group and Prerequisites Implementation and integration teamsQuality managers supervising in-house developmentPrerequisitesExperience of software testingAn understanding of the architecture of the SAP Web Application Server (as provided in course SAPTEC)
3In this course, you will learn Course GoalsIn this course, you will learnWhat and when you need to test in the SAP Solution LifecycleThe advantages of eCATT for testing SAP systems compared with other automated test toolsHow to set up your system environment for testing with eCATTHow to create test cases to test various different kinds of SAP applicationsHow to create executable tests, and how these can be managed using the SAP Test WorkbenchHow to migrate CATT objects to eCATT
4Contents Unit 1 Unit 5 Getting Ready to Test Testing Transactions - I Testing Transactions - IIUnit 2Getting Ready to Test with eCATTUnit 7Testing Transactions - IIIUnit 3eCATT Scripts and the Script EditorUnit 8Building Executable TestsUnit 4Non-UI TestingUnit 9Advanced Topics
6In this unit, you will learn: Unit ObjectivesIn this unit, you will learn:When you need to test in your SAP environmentThe advantages and disadvantages of manual and automated testingDecision criteria for selecting an automated test toolWhat can be tested using SAP eCATT
7Addition and integration of new components In-house developments Occasions for TestingNew SAP installationsAddition and integration of new componentsIn-house developmentsFunctional TestsIntegration tests with other componentsUpgrades – regression testingApplication of Legal Change PackagesSometimes we hear the question Why do you have to test off-the-peg software at all? Of course SAP tests its software, but the tested state of an SAP system is not the state in which it will be used productively by a customer. Customizing, Enhancements, Modifications, and in-house developments all ensure that each SAP installation is very probably unique – which means that it has to be tested on installation, on upgrade, and whenever new components are added to an existing landscape.
8Manual or Automated Testing Manual TestingRequires a group of testers who mustHave lab space to work inBe trainedBe released from their other duties (internal) or “bought-in” (external)Is time-consumingOffers little potential for reuse of test resourcesBut does have the advantage that manual testers spot errors and issues that are beyond the scope of the test planAutomated TestingRequires fewer people and resourcesExecution takes less timeParameterization of fields allows replay with any number of different sets of valuesOffers considerable possibilities for reusing test scriptsMakes it easier to reproduce errors that occur during testingThere are two ways to perform functional testing on a system – manually or automatically.Manual testing has the advantage and disadvantage of using real people. Advantage because people have common sense, and can see beyond the boundaries of the test case that they are working on, but disadvantage because people make mistakes, especially if they are under pressure (the product is being rolled out next week) or bored (I'm re-testing this function for the 8th time).Automated testing offers a range of options for speeding up your test execution and making it more flexible and reliable. However, it will never be able to identify or foresee problems that lie outside the scope of the test case.
9The Economics of Testing Automated testing requires good planning and modelingLearning to use a new test tool takes timeAn automated test script will only give you maximum ROI if it is reusableA switch to automated testing requires investment and commitmentNot every test scenario has to be automatedIf it doesn't have to be repeatable, it doesn't necessarily have to be automatedAutomation is a means to an end, not an end in itself. If it is taking too long to automate the last 5% of your test scenario, consider running that part manually!Automated testing is not a magic solution to your testing requirements. A good test automation project requires careful planning, commitment from the test team, and support from management.In the early stages of test automation, you will not see much in terms of concrete results. Much effort will be devoted to modeling the test cases and creating the relevant scripts. The real benefits of automated testing become apparent when you find that your carefully-crafted scripts are reusable in the future!The decision to switch to automated testing does not mean that you have to automated 100% of your test activities. Some applications will be automation-resistant for one reason or another.
10Choosing an Automated Test Tool – External Tools Classic automated test tools can test an SAP System by driving the SAP GUI...Automated Test ToolScriptSAPGUI WindowFrontend... But treat the SAPGUI Window as a standalone desktop application:Generally not aware of the multiple tier solutionNo access to what is happening on the application server or the databaseBackendVarious test tools currently on the market can support SAP testing by driving the SAP GUI. However, they often cannot provide total support for the full range of user interface controls that are used in later SAP GUI versions (particularly the controls that belong to the SAP Control Framework).Test tools that drive the SAP GUI are unaware that the SAP GUI is only one layer in a multiple-layer architecture. As such, they do not provide you with access to the application server or the database.
11Choosing an Automated Test Tool – SAP CATT CATT – Computer Aided Test ToolAvailable from Release 3.0AdvantagesShipped free with SAP Basis SystemMost effective testing method for SAP transactionsDisadvantagesControl technology not fully supportedNo support for tabular parameters of function modulesOnly limited support for distributed system environmentsOnly limited support for external applicationsSAP has long had its own functional test tool – the Computer Aided Test Tool (CATT). CATT is part of the standard SAP Basis (SAP Web Application Server) installation and can be used at no extra cost.Using the SAP Batch Input Interface, CATT allows you to record and replay transactions running in the SAP GUI for Windows or Java. However, because of this technical background, it is unsuitable for testing transactions that were redesigned in the Enjoy SAP initiative (Release 4.6B and higher) and contain controls such as the SAP List Viewer, SAP Tree Control, and so on.Due to this and various other limitations, CATT is no longer a suitable tool for testing in a mySAP environment.
12Choosing an Automated Test Tool - SAP eCATT The Extended Computer Aided Test Tool (eCATT) is the successor to SAP‘s CATT.Its design aims were toEnable as many SAP transactions as possible to be tested automaticallyProvide a simplified concept for testing in a complex system landscapeAllow reuse of test data by storing it in separate container objectsLeverage the benefits of the existing CATTeCATT is available with Release 6.20 of the SAP Web Application ServerWith it, you can remotely test any mySAP.com solution that is running R/3 Basis Release 4.6C or higher (see note for details of required support packages)Given the limitations of CATT, SAP decided to develop a new tool, called the Extended Computer Aided Test Tool (eCATT). eCATT is contained in Release 6.20 of the SAP Web Application Server, and is therefore available as part of R/3 Enterprise and the SAP Solution Manager Release 2.2 and 3.1.eCATT allows you to test not only locally in your 6.20 system but also in remote systems with Release 4.6C or higher. Consequently, by installing a SAP Web Application Server 6.20 as part of your existing system landscape, you can use it to test your SAP systems that are running on SAP Basis releases 4.6C, 4.6D, and 6.10, as well as your 6.20-based systems.
13What Applications Can Be Tested Using eCATT? . . . Using Built-In eCATT MeansTransactions in SAP GUI for WindowsTransactions in SAP GUI for JavaFunction Modules and BAPIs. . . Using eCATT Together With a Certified External ToolWeb-based TransactionsIn order to test different kinds of applications, eCATT provides a range of test drivers, each one suited to a particular kind of application.Function modules, BAPIs, and transactions running under SAP GUI for Windows and SAP GUI for Java can be tested using built-in eCATT drivers.External applications that run on the Windows Desktop or in a web browser can be tested using eCATT together with a certified external tool.Desktop-based transactions
14What Does Testing an Application Mean? Making thetest reusableSetting checks on the application to make the test react to different circumstancesParameterizing the application to allow it to be replayed with varying valuesRecording the application so that it can be replayedThe most basic test case involves simply recording an application so that it can be replayed. However, such a test case will only be of limited use, since it is restricted to replaying the application with the same data as you entered during the recording, and does not provide any analysis of the results.Having recorded an application, you need to be able to parameterize it, that is:Assign variable values to its input fieldsRetrieve values from its output fields and assign them to variables in the scriptYou also need to be able to evaluate the results that the application returns by setting checks. These might beSimple checks where the value of an output field at runtime is compared against a check valueComplex checks, where a value is incorporated in a larger plausibility check involving several field values and complex calculationsThe effort of automating a test case can only be justified if the test case is reusable. This should be one of your most important design considerations.
15What Systems Can Be Tested Using eCATT? You require at least one SAP Web Application Server 6.20 to operate as a test serverFrom this central test system, you can test any other system that is running the component SAP_BASIS with Release 4.6 Support Package 32 or higherR/3Web AS 6.20eCATTCRMAPOeCATT is designed to be used within a central test system. This system must be running on the SAP Web Application Server 6.20 and could, for example, be:An R/3 Enterprise SystemA SAP Solution Manager System (Release 2.2 or higher)A standalone SAP Web Application Server 6.20All of the eCATT objects that you create are stored in this system. The eCATT runtime, which is necessary for test cases to run, is also located here.The actual applications that you want to test can be located in any other system in your system landscape that isRunning software component SAP_BASIS with Release 4.6C or higherAccessible from the central test system by RFC
16In this unit, you have learned Unit SummaryIn this unit, you have learnedSome of the issues you have to consider in deciding a test strategyThe functional test tools that are available from SAPThe scope of eCATTThe applications that you can test with itThe system landscape in which you can test
18In this unit, you will learn: Unit ObjectivesIn this unit, you will learn:How a finished eCATT test case is put togetherThe different object types used in eCATTHow to set up a system for use with eCATTSome of the security aspects that you need to consider
19Test Configuration Archive A Finished ExampleTest ConfigurationTestInstructionsSystemLandscapeDescriptionData to drive the testResultsArchiveA finished test case – the test case that a user will see in their worklist in the SAP Test Workbench – consists ofA set of instructions that describe the test caseOne or more sets of data with which the test case will be executedA description of the system landscape in which the test is to be performed.The result of each test run is a log. The log contains detailed information about the test environment (system – including technical platform information and release, user, time and date) and the commands that were executed during the test. You can also see the data that was fed into the test case, and the results that it returned. Logs can be either archived or deleted using periodic background jobs.On the next slide, you will see the different eCATT object types corresponding to the different elements of a test case.
20The Different Object Types Test ScriptThe set of commands that forms the testSystem Data Container A list of systems that are addressed during the execution of a test scriptTest Data ContainerReusable sets of data that can be used to run testsTest Configuration A test script, combined with data from one or more test data containers, plus a system data container that describes the correct system landscapeA test script is the set of commands that describes a test. Typically, this will include a recording of one or more transactions with the associated checks and calculations required to evaluate the results.In order to address different systems, you need a description of the system landscape. This is contained in a system data container. Each entry in a system data container describes one target system.Unlike CATT, eCATT separates test instructions from test data. The test instructions are contained in a test script. Test data is stored in test data containers. By separating the test data from any particular test case in this way, it should be easier to reuse data in a variety of test cases.None of the objects test script, system data container, or test data container is executable from the Test Workbench. A complete automated test case requires a combination of one test script to provide the instructions, one system data container to describe the relevant system landscape, and one or more sets of data (variants) with which to execute the test. This combination is called a test configuration. The variants that are used may be entered manually or may be drawn from one or more test data containers.
21Constructing an Automated Test Series What applications am I going to test?What does my system landscape look like?How can I best create an automated test for my applications?What data do I need to drive the tests?How can I organize my test cases?Test data containerSystem data container12345Test WorkbenchThe graphic shows how the different eCATT objects fit into the test development process. The first step is to define just what you want to test within the scope of your project.Having done this, you must create a system data container in which you map out the system landscape for the project. Without a system data container, you cannot write test scripts that access other systems.The third step is to create the test scripts themselves.Once you have finished your test scripts, you need to consider the data that you will need to run the tests. These data need to be arranged in test data containers to allow the maximum degree of reuse and to eliminate as much redundancy as possible.Finally, when you have finished creating your components, you can move on to assemble the test configurations and assign them to test catalogs and test plans within the Test Workbench. The configurations can then be assigned to individual users for testing.Testscript
22Support Package Levels Setting Up the SystemSupport Package LevelsEach system in which you want to test must have at least the following support package level4.6C: Support Package 324.6D: Support Package 216.10: Support Package 17Client SettingsIn each client in which you want to test, you must ensure that the CATT/eCATT flag is set to allow tests to runGUI ScriptingIn order to use the new GUI Scripting functions, the following settings have to be made:Profile parameter sapgui/user_scripting must be set to TRUESAP GUI must be Version 6.20 with patch level =>18 and GUI Scripting installedBefore you can start testing, you must prepare your various systems. Each of your target systems must have the appropriate support package level as shown above.In each client in which you want to test, you must ensure that eCATT is allowed. To do this, start transaction SCC4, pick the relevant client and ensure that the Restrictions when starting CATT and eCATT option is set to CATT and eCATT allowed.To use the SAPGUI command (see unit 6), you must ensure that GUI Scripting is active in the central test system and in any target systems that you may require. To do this, start transaction RZ11 in the relevant system, enter profile parameter sapgui/user_scripting and choose Display. If the current value is FALSE, change it to TRUE. You must log off and back on again for the change to take effect.
23Mapping the System Landscape Web AS 6.20eCATTTest CRM transactionCheck table entries in R/3Run transaction in R/3Call function module in APORFCCRMR/3APOThe first step towards an automated test is to map the system landscape in which you will be working. There are two main considerations here:The applications that you want to test are generally not present in your central test system, so you must test remotely.The business process that you want to test may extend across system boundaries, so you need to be able to test in several different remote systems.In order to test remotely, you use Remote Function Call (RFC). However, in an eCATT test script, you do not address target systems directly using an RFC destination. Instead, you assign a logical system name to each system in your landscape, and it is this name that you use in the test script.Resolving the logical name, as used in the script, into an RFC destination that identifies a particular system is the task of a system data container.Business Process
24Defining RFC Destinations Source SystemTarget SystemRFC DestinationTarget TransactionClient: 100Lang: ENUser: testerPwd: letmeinDirect but unsafeClient: 100Lang: ENUser: <current>RFC DestinationTarget TransactionSafe but cannot run unattendedThe RFC destinations that you use in eCATT are normal R/3 -> R/3 destinations that you define in transaction SM59.In each RFC destination, you can specify not only the location of the system that you want to address, but also the user credentials that will be used to log onto that system. The logon to the remote system can only take place unattended if the logon data is complete (client, user, and password). Storing passwords in RFC destination definitions is, however, not to be recommended.If you do not store a password, the logon data is incomplete, and a logon screen will be displayed when time your test case tries to enter that system. Consequently, the test case can no longer run unattended.The way around this problem is to establish a trusted/trusting relationship between systems, in which the target system trusts calls that are made by the central test system. This eliminates the need to store a password within the destination definition but ensures that the logon can still run unattended.For details of how to set up a trusted/trusting RFC relationship, refer to SAP Note
25Function of System Data Containers Test ScriptCommandWithLogicalTargetSystem Data ContainerTarget SystemTarget < -- > RFC Dest.The logical target describes the function of the system – for example R/3. The system data container maps the logical name to a particular RFC destination.The task of a system data container is to map the logical names that are used in a script to a particular RFC destination that specifies the system, client, and user that the test case is to access.You can assign the logical names yourself. As a rule, they should reflect the function of a system and should not relate to a particular release or system name – they should remain relevant beyond the lifetime of a particular release or system.Consider the following example: Your R/3 System has Release 4.6C and has the System ID P01. Possible logical names for this system might be:R3R3_46CR3_P01P01_46CNow consider the situation after an upgrade to R/3 Enterprise: Your system no longer runs under Release 4.6C and may have moved so that the system is no longer called P01. Any logical name that refers to either the release or the system name is therefore obsolete: In our example, only R3 is still relevant.
26Creating a System Data Container SAP Web AS 6.20System under testRelationship described by RFC destination XYZSystem Data ContainerTarget systemRFC Destination. . .R3XYZTo create a system data container, start transaction SECATT, select the System data container radio button, enter a name for your system data container, and choose Create.On the next screen, you must maintain various attributes for the system data container – in particular, it must have a title, an application component, and a package.On the System data tab, you will see that the default system NONE is already present. This refers to the default RFC destination NONE, allowing you to refer to the current system at any time.To add a new system to the container, choose the Create icon. eCATT appends a new row to the table. In it, you must specify a logical name for your system and, in the third column, assign an RFC destination that already exists (you can use possible values help to display all relevant RFC destinations). In the second column, you may enter a description of the system.Repeat the previous step for each system in your system landscape.
27Advantages of System Data Containers ConsistencyOne container can serve a whole projectThe RFC destinations can contain the client, language, and user name for the logon – eliminates sources of errorsAccess to SM59 and the authorization to create system data containers can be restricted to project leadsReuseUsing logical system names in a script means that the execution environment of the script can be changed by switching system data containers. Changes in the script coding are not required.System data containers help you to achieve greater consistency in your test activities. You can create a single system data container for a test project (or subproject). Since the RFC destinations behind the logical destinations contain a full set of logon credentials, you can be sure that your test developers and testers are using the correct systems, clients, and users.System data containers also improve the stability of your scripts. In a script, you only ever refer to a particular target system by its logical name, which remains constant. The actual system to which that logical name points is dependent on the current system data container. Thus you can execute a script against a completely different system landscape simply by linking it with a different system data container, and you never have to change the script coding.
28In this unit, you have learned Unit SummaryIn this unit, you have learnedThe different object types with which you work in eCATTHow these object types support you in the various stages of planning an automated test projectHow to set up a system to enable eCATTHow to define secure RFC destinationsHow to create a system data container
30In this unit you will learn: Unit ObjectivesIn this unit you will learn:The structure of an eCATT scriptThe essential features of the eCATT script editorThe main aspects of the eCATT scripting languageHow to work with parameters
31Design Considerations for a Script Definite GoalBefore you write your script, work out exactly what you want it to doReusabilityTry to create small self-contained script modules. This will make them more easily reusable.Although it is impossible to make general rules about how to write the perfect script, there are two guidelines to consider:Have a definite goal! Before you start writing the script, make sure that you know exactly what you want it to do.Aim for reusability! There is little point in packing an entire order-to-cash scenario into a single script, because it contains many parts that you might be able to reuse in other test scenarios. You should therefore aim for smaller test scripts – it is very easy to create one "master script" at the end that does nothing other than call a series of smaller scripts.
32Test Script Attributes Parameters Importing Exporting Commands Structure of a ScriptTest ScriptAttributesParametersImportingExportingLocal variablesCommandsIn terms of its structure, a test script is similar to a function module. It contains various attributes, an interface in the form of importing and exporting parameters, and the commands that actually form the test. Scripts may also contain local (private) variables for use within the coding.
33Script Attributes Administrative data about the script Search terms: Can be used in InfosystemAttaches system data container to script, allowing access to other systemsWhen you create a script, you must first maintain certain attributes.The following attributes are mandatory: Title, package, person responsible, application component.The maintenance system attributes are important. It is here that you can assign a system data container to your script. You can then address any of the systems listed in the system data container from your script. In addition, you can make any one system from this system data container the default target system by entering its logical name in the target system field.On the Versioning Data tab, you can specify the validity of the current version of your script. You will learn more about versioning in Unit 9.The Restrictions tab contains optional documentary attributes. You can, for example, specify that the test script applies to a particular locale or platform. Note, however, that these attributes are not evaluated by eCATT when you run a script. You can only use them as useful search terms.
34Parameter List Structure Editor Command Editor The Script EditorParameter ListStructure EditorCommand EditorThe script editor has three areas – the command editor, where you enter the script coding, the parameter list, where you can create importing and exporting parameters, as well as local variables for your script, and the structure editor, where you can edit any structured parameters within the script.A structured parameter can beA structureAn internal tableA command interface (interface of an eCATT command)
35CHEVAR ( I_IMPORT <> 'UA' ). . . . Simple ParametersCreationUseI_IMPORT = 'LH'.CHEVAR ( I_IMPORT <> 'UA' ).. . .You create parameters in the parameter editor section of the script editor. Each parameter must have a name, a type, and be defined as an Importing parameter, an Exporting parameter, or a local Variable.Parameters can have any data type except for String and XString. The default data type is C with length 128. You can also type a parameter with reference to an ABAP Dictionary type (either simple or structured).Parameters may also have a default value, which you enter in the Value field.In the command editor, you work with parameters in the same way as you would work with variables in any programming language – you can use them freely in assignments and logical expressions as shown above.
36Structured Parameters UseI_STRUCTURE-CARRID = 'LH'.I_ITAB-CONNID = '0400'.GETLEN ( I_ITAB, VAR ).As well as elementary parameters, you can also create structured parameters – that is, structures or internal tables.To create a structured parameter, the reference type must be a structure in the ABAP Dictionary.To create an internal table parameter, the reference type must be either an internal table type in the ABAP Dictionary or a structure type followed by opened and closed square brackets, for example SPFLI.To address a component of a structure, you use the same notation as in ABAP, that is <structure>-<component>.To address a particular component of an internal table, you use the notation <table>[index]-<component>.The eCATT command GETLEN allows you to find out the number of entries in an internal table. Its syntax is GETLEN ( TABLE, VARIABLE ). which places the number of lines in table TABLE into the field VARIABLE.If you assign whole structures using the form struc2 = struc1, the assignment uses MOVE-CORRESPONDING logic.
37Script Language Recording and playback of applications Conditions ChecksLoopsCalculationsSimulation of Customizing settingsReading table valuesBlocks of ABAP codingeCATT has its own scripting language. It is similar to ABAP, but nevertheless a different language. It allows you to record and replay applications, perform checks, and use various common programming control structures.
38Commands for Recording Applications Recording and playback of applicationsFUN calls a function moduleTCD allows you to record and replay SAP transactionsSAPGUI allows you to record sequences of screens containing controlsAn interface allows you to integrate test tools from third-party vendors with SAP eCATTThere are four different ways of testing applications. Each of them is appropriate for a particular kind of application that you might want to test.It is important to remember that no single way is suitable for testing everything. For this reason, you should always take care to pick the correct driver before you start to record your script.On the next page, you will learn how to pick the correct driver for a test.
39Choosing the Right Driver Is the application a function module or BAPI?NoDoes the application run under SAP GUI for Windows or Java?NoUse ext. toolYesUse FUNYesDoes the application use controls?NoUse TCDNoYesAre the controls essential within the transaction?No single driver provides the best solution for every applicationYou can use the graphic to help you choose the right driver to test a particular application.When it comes to testing applications using the TCD and SAPGUI drivers, you should bear in mind that the TCD command is the most efficient in terms of runtime, because it runs in the background with no SAPGUI window attached. The SAPGUI command has the overhead of having to instantiate the SAP GUI window. Consequently, it should only be used for transactions where TCD cannot be used.YesUse SAPGUI
40&MSX – Number of messages returned by a transaction &USER – User name Special Variables&SZBRC - Return code&TIME - Current time&DATE – Current date&YEAR – Current year&YEARA – Next year&YEARB – Last year&LPC – Loop counter&MSX – Number of messages returned by a transaction&USER – User name&CLIENT – Current clienteCATT has a range of special variables, similar to the sy- fields in ABAP. A full list is available in the eCATT documentation.You can also use sy- fields in eCATT scripts. Note, however, that sy- fields always relate to the local system, and that special eCATT variables always relate to the target system. So, for example, if you are logged onto the test system as user SMITH, but the RFC destination that connects to the target system logs on as TESTER, sy-uname will have the value SMITH, but &USER will have the value TESTER.
41Pattern FunctionThe Pattern function is similar to the statement pattern in the ABAP Editor. It allows you to build individual eCATT commands.A command consists of:The command keywordArgument (the target object)Interface (parameters that need to be passed)Target systemThe pattern function allows you to create eCATT commands quickly and easily. The first step is to pick a command. Once you have done that, you must supply the argument – for example, the function module you want to call or the transaction you want to record. Next, the system proposes the name for the command interface. You can accept the default, or change it if you like. Finally, you specify a target system. You can use any system that is defined in the current system data container. If there is no system data container attached to the script, you can only execute the command locally.
42Most eCATT commands have a command interface, which corresponds to: The interface of a function module (for FUN)The screen and field structure of a transaction (for TCD)A list of user interactions (for SAPGUI)The importing and exporting parameters of a referenced scriptCommand interfaces are stored in XML format in the local system, even if the object that they describe only exists in a remote system.Command interfaces represent the input/output interface of the command to which they belong. They are always displayed in tree form in the structure editor.To open a particular command interface in the structure editor, double-click its name either in the parameter list or in the eCATT command in which it is used.You can assign literals or variables to parameters in the command interface. Literals must be enclosed in single quotes. If you use variables, you must remember to declare them as script parameters in the parameter list.
43In this unit, you have learned Unit SummaryIn this unit, you have learnedThe various areas of the eCATT Test Script EditorThe features of the eCATT script languageHow to create eCATT parametersHow to use the pattern function in the eCATT Script EditorWhich driver to use for various kinds of applications
44Function Modules and BAPIs Table Operations Inline ABAP Unit 4: Non-UI TestingFunction Modules and BAPIs Table Operations Inline ABAP
45In this unit you will learn: Unit ObjectivesIn this unit you will learn:How to test function modules and BAPIsHow to read from and test against the databaseHow to use blocks of ABAP coding to enhance your test scripts
46Choosing the Right Driver Is the application a function module or BAPI?YesUse FUN
47Non-UI Testing: Function Modules Unit TestFunctionModuleWhole Backend ProcessFunctionModuleTransactionUtility Within a ScriptThere are various situations in which you might need to test function modules:As a unit test, where you test a single function moduleAs a backend process, where you test a string of function modules that make up a whole process, passing the results of one module onto the nextAs utilities within a script, for example, to retrieve data from the database that you want to use in transactions, or to perform a complex plausibility check for which you know that a function module already exists.
48Testing Function Modules FUN ( <function module>, <interface>, [<target>] ).Command InterfaceFunction ModuleImportingExportingChangingTablesExceptionsIn the graphic, you can see the syntax of the FUN command.The FUN command interface is split into the same sections as you find in the definition of the function module itself – Importing, Exporting, Changing, Tables, and Exceptions.To pass a value to the function module, assign the relevant literal or variable to the correct parameter in the command interface. Do the same thing to receive an exporting parameter into a script parameter.
49Parameterizing the Interface orINTERFACE-IMPORTING-PARAMETERNAME = value.INTERFACE-IMPORTING-STRUCTURE-FIELDNAME = value.INTERFACE-TABLES-TABLE[idx]-FIELDNAME = value.As well as assigning parameter values using the structure editor, you can also address parameters programatically within the script editor. This is particularly useful if, for example, you need to assign values dynamically.The syntax for addressing components within a command interface is shown above. It is similar to the ABAP syntax for addressing complex structures. Note that if you are working with internal tables, you must specify the relevant table index in square brackets.
50Interface Interface Trapping Exceptions Exceptions DATA_INCOMPLETE CREATE_FAILEDExceptionsInterfaceDATA_INCOMPLETECREATE_FAILEDExceptionsInterfaceSometimes, the aim of a test will be to make a function module trigger an error. In such a case, you will want the test case to be marked as successful if an exception is triggered.eCATT, however, normally handles function module exceptions as errors and, as shown in the top half of the graphic, will mark the test case red in the log.To define an exception as “successful”, you must assign it the value ‘X’ in the command interface. If the exception then occurs, the script will not fail.Defining an exception as successful does not mean that the script will fail if the exception does not occur. If you want this to happen, you must query the special eCATT variable &EXCEPTION yourself in the script. For example, in the above example, you would write CHEVAR ( &EXCEPTION = ‘DATA_INCOMPLETE’).
51Test Script Database Application Table Customizing Table Table OperationsTest ScriptDatabaseGETTAB ( TAB, INTF, [DEST] ).Application TableCHETAB ( TAB, INTF, [DEST] ).SETTAB ( TAB, INTF, [DEST] ).RESTAB ( TAB, [DEST] ).Customizing TableThe GETTAB and CHETAB commands allow you to read and check single database table entries. Each has a command interface with the structure of the table line. In the structure editor, key fields are marked with (K).In both commands, you enter values in the command interface that should be used to make the database selection.If the GETTAB statement finds a corresponding row in the database table, it places the contents of that row into the command interface. Note that if you do not specify the full table key, the single record returned by GETTAB may not be the only one that matches your key specification. If you want to retrieve multiple lines from the database, consider using a function module or writing a SELECT statement in an Inline ABAP block.The CHETAB command searches for a table entry matching the key (plus any other non-key fields) that you specified. If it finds one, the command is marked as successful. If it does not find a corresponding table entry, the statement fails, and with it, the script.Note that you must assign values to all key fields in the CHETAB command. If one or more key fields are not relevant to your query, assign them the value *.The SETTAB and RESTAB commands allow you to simulate changes to Customizing settings within a script. You can only use them on tables that are defined as Customizing tables in the ABAP Dictionary. SETTAB makes temporary changes to a Customizing table. With RESTAB, you can roll back these changes at the end of the script.Do not use SETTAB for extensive Customizing modifications. Business Configuration Sets are far better suited to this task.
52Name Description Value I/E/V Ref Type Using Inline ABAPABAP.* Any ABAP Coding that is allowed in a subroutine* may appear hereENDABAP.ParametersName Description Value I/E/V Ref TypeV_TAB SFLIGHT-table <INITIAL> V SFLIGHTABAP.SELECT * FROM sflight INTO TABLE v_tab WHERE carrid = ‘LH’AND connid = ‘0400’.ENDABAP.Expecting a result set of more than one line.No corresponding function module available.“Once-off” queryThere are cases where the eCATT scripting language may be insufficient for your needs. For example, you cannotTest classes and methodsRead multiple lines from the database in a single commandFor cases such as these, you can use blocks of ABAP coding in your script. Each block is introduced with the keyword ABAP and ends with ENDABAP.Inside each block, you can use any ABAP coding that is valid in the default target system of your script. Technically the blocks are compiled into FORM routines. This means:You cannot define your own FORM routines within an ABAP blockAny data objects that you declare using the DATA statement are not visible beyond the end of the block.Within an ABAP block, only the local variables of the script are visible. Consequently, if you want to use an importing or exporting parameter of the script in an ABAP block, you must first assign it to a local variable.
53In this unit you have learned: Unit SummaryIn this unit you have learned:How to test function modules and BAPIsHow to read from and test against the databaseHow to use blocks of ABAP coding to enhance your test scripts
54Unit 5: Testing Transactions - I Testing conventional transactions using the TCD command
55In this unit you will learn: Unit ObjectivesIn this unit you will learn:What transactions are suitable for testing using the TCD commandHow to record a transaction using the TCD commandHow to set input fields, read output fields, and perform fields checks with the TCD command
56Choosing the Right Driver Is the application a function module or BAPI?NoDoes the application run under SAP GUI for Windows or Java?YesDoes the application use controls?NoUse TCDNoYesAre the controls essential within the transaction?
57Characteristics of the TCD Command The TCD command is the recording technique that was used to test transactions in CATTIt is based on the Batch Input InterfaceIt allows you to record a transaction, parameterize its input fields, and read or set checks against its output fields
58Background: The Batch Input Interface Background: Data-consistency checks in SAP transactions are often implemented within the coding of the screen flow logic (Process After Input)Batch Input is a technique originally developed for data transfer from legacy systems into an R/3 System that processes transactions in the backgroundCATT used this technique for unattended transaction testing. It is a very efficient testing method, and has consequently been retained in eCATT
59TCD ( transaction, interface, [sys] ) The TCD CommandTCD ( transaction, interface, [sys] )Same systemDifferent systemTo record a transaction that does not contain controls, use the TCD command. It is easiest to insert the command by choosing the TCD (Record) entry from the dropdown list box. You will then be prompted to enter a transaction code. From this, the system generates a proposal for the command interface name.You may also specify a target system (as long as you have entered a system data container in the script attributes).Once you have filled out the arguments in the statement pattern, eCATT starts the transaction, and you can work through it normally. The system records all of your entries.When you leave the transaction, control passes back to eCATT, and you will be asked whether you want to use the data you have just recorded. Choose yes.If you now double-click the name of the command interface in either the parameter list or the command editor, the structure of the transaction will appear in the structure editor. From here, you can assign parameters to individual screen fields.
60How TCD Really Works - Recording ENTERFIELD VALUEKUAGV-KUNNR 1280 VBAP-MATNR P BDC_OKCODE SICHFIELD VALUEVBAK-AUART AF VBAK-VKORG BDC_OKCODE ENT2The TCD command is based on the batch input technique. When you record a transaction, the recorder is triggered each time you choose a function (such as pressing Enter, choosing a menu entry, clicking a pushbutton, and so on). At this point, it collects all of the field contents from the screen and stores them in a table, along with the function code of the function you chose.
61How TCD Really Works - Replay No SAP GUI sessionFIELD VALUE. . . BDC_OKCODEField valuesFIELD VALUEKUAGV-KUNNR 1280 VBAP-MATNR P BDC_OKCODE SICHVBAK-AUART AF VBAK-VKORG 1000TCD commands are replayed without the transaction having any contact with a SAP GUI instance. The batch input system is able to replay transactions using just the field contents and function codes.While this provides quick playback for scripts containing TCD commands, it makes TCD unsuitable for transactions that make extensive use of controls, since controls, in order to behave properly, must be alive at the frontend both during both recording and playback.ENT2Function code
62The Command Interface Transaction Screen Field The command interface of a TCD command divides the transaction into screens, and the screens into fields.Each screen may be either active or inactive.Fields are identified by a name. This is the same name as appears under the Field description for batch input when you display the technical information about a screen field ( F1 followed by the Technical Information icon).
63Parameterizing Input Fields You can replace the recorded values with either literals or variablesField nameValueDouble-clickThe input and output fields on screens can be parameterized.To assign a value to an input field, open the field list of the relevant screen by double-clicking the "Field Mode Name Valin" row beneath the screen number in the tree display. The field list opens to the right of the tree.Find the field that you want to set and ensure that its mode is set to 'S' (set value). Enter the new value (either a literal or a variable) in the VALIN column.
64Reading and Checking Output Fields To...Read a valueCheck a valueMODE must be...'G''C'Field name in VALIN columnWill contain value from output field at the end of the transactionContains the value that must be present in the screen field at runtimeWith the TCD command, there are two options for parameterizing output fields – you can either place the value from an output field into a variable in your script, or you can check the value against a predefined check value.To read a value, you must set the Mode of the field in question to 'G' (Get value). Then enter the name of a parameter in the VALIN column. At runtime, eCATT will place the value from the screen field into the script parameter.To check a value, you must set the Mode of the field to 'C' (Check value).Then enter either a literal check value or the name of a parameter containing the required check value. At runtime, the screen field will be checked against the value that you specified. If the values do not match, the script will fail.
65Number of messages &MSX Message HandlingTCDCommand InterfaceLocation of message(program and screen)Message attributes(type, ID, number)MSGInternal TableMessage variables(up to four)Full text of message(in logon language)Number of messages &MSXAll of the messages sent by a transaction are stored within the command interface in an internal table called MSG. MSG has the following fields:TCODE –transaction code from which the message was sentDYNAME –program nameDYNUMB –screen numberMSGTYP –message typeMSGSPRA – language of the messageMSGID – message classMSGNR – message numberMSGV1 … MSGV4 – variables (optional) that replace placeholders in the messageENV – not used (batch input-specific)FLDNAME – the text of the message in fullThe number of messages sent by the transaction is contained in the eCATT system variable &MSX.
66Reading Message Contents Addressing the Last Message<interface>-MSG[&MSX]-<component>Looping Through All MessagesDO &MSX. <interface>-MSG[&LPC]-<component> ENDDO.Using &MSX, you can find any given message.To retrieve the last message, you address MSG with index &MSX. The precise syntax is <interface>-MSG[ &MSX ]-<component>.To loop through messages, you can use &MSX as the count for a DO statement.The following example shows how you could use a loop to check whether a particular message appeared during the transaction:DO &MSX.IF ( command_interface-MSG[ &LPC ]-MSGID = message_class AND command_interface-MSG[ &LPC ]-MSGNR = message_number ).* Do something.ENDIF.ENDDO.
67Require that a particular message is sent Testing MessagesRequire that a particular message is sentON_LAST_MESSAGE_CHECK ( 031 ).TCD ( EC_TUTORIAL_TCD, EC_TUTORIAL_TCD_1 ).Tolerate all messagesON_LAST_MESSAGE_CHECK ( * ).TCD ( EC_TUTORIAL_TCD, EC_TUTORIAL_TCD_1 ).The ON_LAST_MESSAGE_CHECK command allows you to specify before a TCD command the number of a message that must occur during that command.In the first example above, the message with number 031 must be sent by the subsequent TCD command, otherwise the script will fail.To tolerate all messages (including errors), use the command ON_LAST_MESSAGE_CHECK ( * ). This allows you to implement your own message analysis after the TCD command.Note that this command will be superseded in Release 6.40 by a new rule-based message handling mechanism. This has already been implemented for the SAPGUI command, and you will learn about it in the next unit.
68Troubleshooting the TCD Command By default, the TCD command runs in the background. Consequently, you do not see anything between clicking the Execute button and the appearance of the log.The start options of the TCD command allow you to troubleshoot it by running it in the foreground (mode A). In this mode, the transaction is played back screen-by-screen so that you can analyze the various field contents and establish where things are going wrong.Another useful troubleshooting mode is mode E. In this mode, the transaction is played back in the background, but switches to foreground processing if an error occurs.
69In this unit you have learned: Unit SummaryIn this unit you have learned:What transactions are suitable for testing using the TCD commandHow to record a transaction using the TCD commandHow to set input fields, read output fields, and perform fields checks with the TCD command
70Unit 6: Testing Transactions - II Testing control-based transactions using the SAPGUI command
71In this unit, you will learn: Unit ObjectivesIn this unit, you will learn:Why the TCD driver is not suitable for testing all transaction typesHow GUI Scripting worksHow to use the eCATT SAPGUI command to record a transactionHow to set input fields, read output fields, and perform field checks in a SAPGUI recording
72Choosing the Right Driver Is the application a function module or BAPI?NoDoes the application run under SAP GUI for Windows or Java?YesDoes the application use controls?YesAre the controls essential within the transaction?YesUse SAPGUI
73Why TCD Cannot Test Everything ControlALVTreeCalendarOCX control under WindowsBean under JavaSAP GUI WindowFrontendAction leads to local processing in SAP GUINew recording componentAction leads to event handler on application serverTCDRecordereCATTBackendApplicationLogicThe TCD command and batch input interface only work for applications that are programmed using "classic" SAP dialog programming – that is, where the transaction is controlled exclusively by using Process After Input (PAI) and Process Before Output (PBO).New transactions, or transactions that were redesigned in the EnjoySAP initiative (Release 4.6B), frequently use the SAP Control Framework to implement part of their user interface. Examples of Control Framework controls are the SAP List Viewer, SAP Tree Control, SAP HTML Viewer, SAP TextEdit Control, and so on.One of the principal characteristics of these controls is that their features and functions are implemented locally within the SAP GUI. Further functions are implemented by the application using the control in the form of event handler methods. Functions that are implemented in these ways do not form part of the standard PAI/PBO logic, and therefore cannot be recorded by the TCD recorder.The only way to enable these applications to be tested was to implement a new testing driver at the frontend as part of the SAP GUI that works by intercepting the actions that a user performs on a screen, regardless of whether those actions belong to a conventional screen element like a pushbutton or an input field, or to a control such as the SAP List Viewer.
74Introducing GUI Scripting Scripting host in GUI(Requires SAP GUI 6.20)eCATT at backendThe SAPGUI driver in eCATT is based on the GUI Scripting function in Release 6.20 of the SAP GUI. GUI Scripting allows you to create scripts that automate the SAP GUI in much the same way that macros allow you to automate Office applications. GUI Scripting is a standalone feature of the SAP GUI that you can also use independently of eCATT. For full details and a range of documents on the subject of GUI Scripting, use the search function on the SAP Service Marketplace (http://service.sap.com) to search for the term "SAP GUI Scripting".A scripting host within the SAP GUI intercepts the actions that you make on a screen. If you are using GUI Scripting on its own, the actions are translated into VB Script or Java Script. If you are working with eCATT, the actions are transferred to eCATT, where you can see them as the command interface of the SAPGUI command.
75Recording the SAPGUI Command – Procedure 1. Select SAPGUI(Record)2. Set the scripting granularityThe procedure for recording the SAPGUI command is slightly more complex than when you record a transaction using TCD. A TCD command always contains a single transaction, and all of the input and output is recorded. With SAPGUI, both the granularity of the recording and the amount of data to be included is variable, and you have to specify this at the beginning of each recording.This page and the next are intended to give you a general overview of the recording procedure. We will return to each step in more detail later on.To start a SAPGUI recording, use the Pattern function and select the command SAPGUI (Record).The next thing that you have to do is to specify how you want the recorded data to be arranged in your script.
76Recording the SAPGUI Command - Procedure 3. Confirm that you want to record4. Pick the relevant initial states to recordAfter you have set the granularity of your recording, eCATT opens a new window of your chosen target system and asks you if you want to record in it. Choose Yes at this point.You now have to specify the kinds of user interface elements for which you want to record the initial state. Recording the initial state allows you to extract the contents of output fields. Having done that, you are ready to record.
77Scripting Granularity ActionSessionActionTransactionActionScreenSTSAs we have already seen, a TCD command has a defined structure based on the fact that TCD can only ever record a single transaction. That transaction is broken down into screens, and each screen contains fields.Because the SAPGUI command works at frontend level, it only recognizes actions. One consequence of this is that, unlike the TCD command, you can use the SAPGUI command to record a part of a transaction or, indeed, several transactions. It also means that there is no predefined granularity as is the case with the TCD command.The first thing that you have to do when you start recording a SAPGUI command is to define the level at which you want the system to generate new commands. This can be at various levels:Session level, which means that all of the actions performed in a SAPGUI window (and that could encompass several transactions) are combined into a single SAPGUI command.Transaction level, in which the system generates a new SAPGUI command for each new transactionScreen level, where a new SAPGUI command is generated each time there is a screen change during recordingUser interaction level, where a new SAPGUI command is generated each time the token is exchanged between frontend and backend.In deciding on a granularity level, you must take into account the size of the generated command interfaces. If you record at session level, for example, you will have a single command with a huge command interface. If you record at user interaction level, the command interfaces will be smaller, but you will have a large number of commands.Generally speaking, it is easier to work with command interfaces that are not too big. Screen level is often a good level at which to work.T: New Transaction S: New Screen
78Making Sense of the Command Interface - 1 One ProcessedScreen node per screenEvery SAPGUI command interface contains details of the actions that you performed on that particular screen.The command interface is split up into ProcessedScreen nodes – one for each screen within that particular command interface.Below the ProcessedScreen node is a section called UserChangedState. This section contains a list of the actions that you performed on the screen during recording. It is here that you can parameterize fields, as you will see on the next page.UserChangedState describes the user actions on the screen
79Parameterizing an Input Value Field nameEnter parameter name in this fieldDouble-clickEach GUI element with which you interacted during recording has its own GuiElement node under the UserChangedState node. A blue arrow pointing towards an attribute name in the State node denotes a set parameter.To parameterize the value of a field, find the relevant field and double-click the Text attribute. In the grid that appears, enter the name of a variable against the Value element.Do not change the Name field.You can only set values of fields with which you interacted during recording. No other fields are recorded.The methods of controls are denoted by a pair of square brackets [ ] (not shown in the example above). Underneath the method node are the individual parameters, which you can also parameterize.Within the UserChangedState section of a command interface, you can only set values. Furthermore, to set the value of a field, you must have changed the value of the field during the recording.You cannot retrieve the values of output fields. This is the task of the InitialState section, which you will learn about on the following pages.
80Recording the SAPGUI Command – Initial State By default, the SAPGUI command only records the actions that you perform in an application. This means that only the entries that you make in fields, and not the field contents that are displayed in output fields, are recorded.To access the contents of output fields, you must record their initial state. You do this by setting the appropriate options in the dialog box shown in the graphic above.Since recording initial states increases the volume of data transferred from the frontend to eCATT, you can restrict the initial state recordings to certain types of user interface element – for example, input/output fields.Once you have selected the initial states that you want to record and decided whether to record with active or inactive checks, choose "Activate mode for initial states". This communicates your selection to the frontend.You can now start recording in the new window that eCATT opened.
81Active and Inactive Checks Record the initial states of the selected screen element typesOn replay, check that the values in the fields correspond to the recorded initial statesInactive ChecksRecord the initial states of the selected screen element types so that they can be placed into script parameters and used in the rest of the scriptWhen you record initial states, you can choose whether to record them with active checks or inactive checks. If you choose active checks, the field contents at runtime will be compared with the field contents that were present during recording. If they do not correspond, an error will occur. If you choose inactive checks, all of the necessary information to perform a check is recorded, but the check is deactivated. The options in this dialog box activate or deactivate checks for the whole of your recording. Later, when you edit the command interfaces, you can activate and deactivate checks for individual fields.
82Making Sense of the Command Interface - 2 One InitialState node per processed screenAre checks active?Field nameField value during recordingThe InitialState node gives information about the contents of screen elements at the beginning of each ProcessedScreen node.If checks are active, the value of a particular GUI element during playback will be compared with its value during recording. You can parameterize the check values.A check will only be performed if the Check option is set along the whole path of the tree from the top of the InitialState node down to the element in question.
83Retrieving an Output Value Enter parameter name in this fieldDouble-clickA blue arrow pointing away from an attribute name in the State node denotes a get parameter.To retrieve the value of a field from the SAPGUI interface, find the relevant field in the InitialState section of the interface, and double-click the Text attribute. In the grid that appears, enter the name of a value against the Value element.Do not change the Name field.
84Activating and Deactivating Field Checks In the InitialState section of the SAPGUI command interface, you have the opportunity to enable or disable field checks. For a check to be active, all of the Check attributes between the top of the current ProcessedScreen and the element that you want to check must be set to 'X'.
85Message Handling – MESSAGE Stipulate that certain messages must/must not occur in order for the script to be a successFind out what messages occurred during a particular block of SAPGUI commandsAn important part of testing an application can be to analyze the messages that occur when the application is replayed. The SAPGUI command supports you in this in two ways, allowing you to:Specify rules as to what messages are allowed, which are prohibited, and which should be toleratedAnalyze the messages that actually occurred during script playback, along with their contents.To work with messages that are sent during the course of SAPGUI commands, you enclose the SAPGUI commands between the eCATT commands MESSAGE and ENDMESSAGE. Both have a command interface:The MESSAGE command interface contains rule definitionsThe ENDMESSAGE command interface contains a list of messages that occurred during replay.
86Message Handling - ENDMESSAGE MIDX MODE MSGTYP MSGID MSGNR MSGV1 MSGV2 MSGV3 MSGV4<n> F E ECDEMO LH 04002 A E ECDEMO 0213 A S XY 100E_MSG_1E_MSG_1-MIDX contains the total number of messages in the tableThe command interface of the ENDMESSAGE command is similar to the MSG table in the command interface of the TCD command – it contains a list of the messages that have been sent since the opening MESSAGE command.The MIDX field contains the index of the current message, except in the first row of the table, where it contains the total number of messages contained in the table.You can access details of the individual messages using the following fields:MSGTYP – Message typeMSGID – Message classMSGNR – Message numberMSGV1… MSGV4 – Variable parts of the messageThe ENDMESSAGE command interface always contains details of the messages sent during the application, regardless of whether you specified any rules in the MESSAGE statement.
87Creating Rules in the MESSAGE Statement Rule = What to do + Message qualificationWhat to doR: RequireE: ExpectA: AllowF: FailModeExitContinue processing or jump directly toENDMESSAGE?Message qualificationAny combination ofMessage TypeMessageClassMessage NumberIn the MESSAGE statement, you define rules for message processing. There are two aspects to each rule – the mode and the object.There are four possible modes:Require – The message or messages that you specify in the object must occur for the script to succeedExpect – At least one of the messages specified in one of any number of rules defined with this mode must occur for the script to succeedAllow – Messages specified in the object will be toleratedFail – The message or messages specified in the object must not occur. If they do, the script will fail.In addition to the mode, there is a parameter Exit. This specifies what should happen if an incoming message satisfies the rule:Exit = ' ': Carry on processing as normalExit = 'X': Jump directly to the ENDMESSAGE command.The object of a message can be any combination of message type (S, I, W, E, A, X), message class, and message number.
88Some Sample Message Rules “Tolerate all error messages”Mode Exit MSGTYP ID Number'A' 'E'“Fail script and jump to ENDMESSAGE on error message ZJM 001”Mode Exit MSGTYP ID Number'F' 'X' 'E' 'ZJM' '001'Above are some sample message rules. The first is very general, specifying that all error messages (only the type is specified – no message ID or number) are to be allowed.The second rule is far more specific – its mode is to fail the script and exit if error message ZJM 001 occurs.The order in which you define rules is crucial. As soon as eCATT has successfully applied a rule to an incoming message, no further messages will be processed. In the case of the rules above, it would mean that the first rule would always overshadow the second, because message ZJM 001, when sent as an error message, will satisfy the first rule and consequently be allowed.If you define rules that conflict (as is the case here), the more specific rule must come before the more generic rule.
89Default Message Handling Rules User-defined RulesSuccessInformation messagesWarningAllowErrorTermination messagesDumpFail and ExitAs well as rules that you define, there is also a set of default rules in the MESSAGE command:Success, information, and warning messages are allowedError, termination, and type X messages cause the script to failThe default rules are always processed after your own user-defined rules. Consequently, if you create a rule of your own that conflicts with a default rule (for example, you choose to allow certain error messages), your rule will take precedence over the default rule.
90Look up in user-defined Message ProcessingLook up in user-definedrulesLook up in defaultrulesNewMessageDiscardProcess accordingto ruleProcess accordingto ruleWhen a new message arrives, eCATT first checks it against your rules. If a rule is satisfied, the script continues according to the rule definition and no further rules are processed.If none of your rules are satisfied, the default rules are processed. Again – if a rule is satisfied, the script continues according to the rule definition and, once again, no further rules are processed.Since your rules are processed before the default rules, any rule that you define that conflicts with a default rule will take precedence.Since no further rules are processed once a particular rule is satisfied, you must pay particular attention to the sequence in which you define your rules. The more specific the rule, the higher it should be in your list. Generic rules, such as “allow all error messages”, should come near the bottom of the list.
91The SAPGUI Command Interface 4 System InformationThe system information part of the command interface contains three important nodes – the ConnectionId and SessionId, and the ResetGUI option.The ConnectionId and SessionId nodes determine the window in which the command will be replayed. Essentially, the precise values in these fields do not matter, but what is important is that all SAPGUI commands that you want to replay in a single window must have the same ConnectionId and SessionId.SAPGUI commands will only replay properly if each successive command starts at exactly the same point at which the last command stopped. Everything that you record in a single attempt will, of course, fulfill this condition. However, if you record a script in sections – for example, a transaction at a time – it may be that your starting point for a new section does not match the end point of the previous SAPGUI command.If this is the case, you can use the ResetGUI option. If you set ResetGUI to ‘X’, eCATT performs the equivalent of ‘/n’ before starting the transaction in the next ProcessedScreen section of the command interface.Do not use ResetGUI within a transaction.
92Activating and Deactivating Screens Active = ‘X’: Screen activeActive = ‘ ’: Screen inactive Active = ‘O’: Screen optionalScreen 1Screen 2Screen 3You can activate or deactivate individual ProcessedScreen nodes within SAPGUI commands. The Active node can take the following values:‘X’: The screen is active and will be processed‘ ’: The screen is inactive and will not be processed‘O’: The screen is optional. It will be processed if it appears, but ignored if it does not.When you deactivate screens, you must be aware that subsequent screens may depend on information from that screen.“Join” OK?
93Troubleshooting in the SAPGUI Command Set automation queue behaviorRun commands with stops at various granularity levelsThere are various start options that you can set to help you troubleshoot problems that occur with the SAPGUI command.Processing mode: This allows you to disable the automation queue, a helpful diagnostic tool if a control is causing errors.Error Mode: This specifies whether the SAPGUI command should terminate or continue when an error occurs.Stop When: This option allows you to run a SAPGUI command with stops at various levels of granularity. For example, you can stop before each screen is processed. The granularity levels available range from transaction down to individual method call. You can also stop before each SAPGUI command, regardless of the granularity at which it is recorded.Close GUIs: This option allows you to specify whether eCATT should automatically close generated GUI sessions at the end of a script (the default setting) or whether they should be left open. This would allow you to inspect the state of the application at the end of the script.Close GUI sessions or leave them open for inspection
94In this unit, you learned: Unit SummaryIn this unit, you learned:Why the TCD driver is not suitable for testing all transaction typesHow GUI Scripting worksHow to use the eCATT SAPGUI command to record a transactionHow to set input fields, read output fields, and perform field checks in a SAPGUI recordingHow to activate and inactivate screens in a script, and the things that you have to consider when doing so
95Unit 7: Testing Transactions - III Testing Web- and Desktop-based Applications Using an External Tool
96In this unit, you will learn: Unit ObjectivesIn this unit, you will learn:When to use TCD and SAPGUI, and when you have to use an external toolWhy SAP chose to work with external toolsThe advantages of the external tool integrationHow the integration works
97Choosing the Right Driver Is the application a function module or BAPI?NoDoes the application run under SAP GUI for Windows or Java?NoUse ext. tool
98Configuring The System for an External Tool Run function module SET_EXTERNAL_TOOL in test modeRun programECATT_GENERATE_ET_USERto generate service userBefore you can use an external tool with eCATT, you must perform the following configuration steps:Declare the external tool to eCATT by running the function module SET_EXTERNAL_TOOL using the test mode in transaction SE37. If you execute the function module without entering any field values, the default values will be used. These default values set up the system to work with Compuware TestPartner.Run program ECATT_GENERATE_ET_USER from transaction SE38. This generates a service user that the external tool requires in order to communicate with eCATT.Regenerate the authorizations in role SAP_ECET. To do this, start transaction PFCG and open role SAP_ECET in change mode. On the Authorizations tab, choose Change authorization data. On the next screen, place the cursor on the role name and choose Authorizations -> Generate.Regenerate authorizations in role SAP_ECET
99External Tool Integration - Architecture Application ServerDatabaseeCATTScript with AttributesScripts stored in SAP databaseFrontendExternal ToolPhysical script commandsApplication Under TestWhen you create a script in eCATT, you can specify on the initial screen that the script should be created using an external tool. Scripts that you create in this way are the same as any other eCATT script – they are Repository objects, can be called from other scripts, and so on. However, within eCATT itself, you can only maintain the attributes of the script. To create or edit the script, you must start the external tool (by choosing the Script function from the script editor).Once the external tool has started, you can use it as normal to record and edit a script.When you have finished, you upload the external script to eCATT, where it is stored in the SAP database.
100Using Compuware TestPartner to Record a Script ChecksVBA FunctionalityParameterizationRecordingThere are four steps to creating a script using Compuware TestPartner:Record the applicationParameterize the input/output fields of the applicationAdd any necessary VBA coding to the scriptImplement any necessary checks for your test case
101Passing Arguments To and From TestPartner – Argument Container eCATTArgument ContainerScriptTestPartner scripts do not possess importing and exporting parameters. To pass data between eCATT and a TestPartner script, you use an intermediate object called an argument container.The argument container allows you to define importing and exporting parameters for a TestPartner script. You do this in TestPartner under the menu entry Tools -> SAP eCATT ->Argument Container.The importing and exporting parameters that you define in the argument container form the interface of the script. When you call the TestPartner script from within eCATT, you have the opportunity to fill them with values.TestPartner
102Passing Arguments To and From TestPartner – Script Coding Argument ContainerName Type Direction ...I_Name String IMPORT ...E_Value String IMPORT ...Script: VBA CodingSub Main ()Dim ImportParam As String, ExportParam As StringImportParam = GetEcattArg("I_NAME"). . .SetEcattArg "E_VALUE", ExportParamEnd SubOnce you have defined importing and exporting parameters in the argument container, you can use them in your TestPartner script. To use an importing parameter from the argument container, you must assign it to a variable in your script using the following function:GetEcattArg( Name as String) As StringTo return an exporting parameter from a script variable to the argument container, use the function SetEcattArg Name as String, Value as String
103Uploading Scripts Projects for upload Script name and version Administrative settingsWhen you have finished recording, editing, and testing your script, you can upload it to eCATT.Choose Tools -> SAP eCATT -> Save BLOB -> Save and Goto eCATT.In the dialog box that appears, select the projects that you want to upload. The entire contents of the project or projects that you select are stored within the script that you created in eCATT. Since this means that one eCATT script can contain several TestPartner scripts, you must select a primary project and primary script – that is, the script that will actually be executed when you call the external script from within eCATT.Choose Save to upload the resources to eCATT.
104Calling External Scripts REFEXT ( SCRIPT, INTERFACE, VERSION ).To call an external script from another eCATT script, you use the command REFEXT.In the REFEXT command, you specify the name of the script and its version.The command interface of the REFEXT command contains the importing and exporting parameters of the external script as you created them in the argument container within TestPartner.
105In this unit, you have learned: Unit SummaryIn this unit, you have learned:When to use TCD and SAPGUI, and when you have to use an external toolWhy SAP chose to work with external toolsThe advantages of the external tool integrationHow the integration works
106Unit 8: Building Executable Tests Calling Other Test Objects Test Configurations and Test Data Containers The Test Workbench
107In this unit, you will learn: Unit ObjectivesIn this unit, you will learn:How you can modularize tests at script levelThe difference between a test script and a test configurationHow to create test configurationsHow to manage test data
108Modularization at Script Level There are two reasons for modularization:To split up parts of a process into separate eCATT scripts to increase the possibility of reusing themTo allow the integration of non-eCATT objects, that isExternal scriptsExisting CATT procedureseCATT contains a range of commands that you can use to call other script objects. These can be divided into three kinds of scripts:eCATT scriptsExternal scriptsCATT proceduresThe fact that scripts can call other eCATT scripts allows you to build up a library of reusable scripts, each of which covers a small part of a business process. You can then create "master scripts" that call all of the elements necessary to test an entire process.eCATT scripts can also call existing CATT procedures. This gives you flexibility in deciding how and when to migrate your existing CATT procedures to eCATT.
109Scripts can call other scripts: REF ( SCRIPT, INTERFACE, [TARGET]). Create OrderREFATP CheckREFREFREFManufacturingThe REF command allows you to call another eCATT script. In it, you specify the name of the script and a default target system if required. If you do not enter a default target system for the script that you are calling, the default target system of the current system will be used instead.The command interface of the REF command contains two sections – one for the importing parameters of the called script, and one for its exporting parameters.Billing
110From eCATT, you can call CATT procedures residing in the same system: REFCATTFrom eCATT, you can call CATT procedures residing in the same system:REFCATT ( CATT, INTERFACE, [TARGET] ).REFCATT ( CATT, INT, TGT ).TGTCATTProcedureREFCATT allows you to call an existing CATT procedure that is stored in your central test system. You may specify a target system in which the CATT procedure is to be executed.The command interface of the REFCATT command allows you to pass data to and from the CATT procedure.The results of the CATT procedure are contained in a CATT log. The log of the eCATT script that called the procedure contains a link to this log.
111You can also call CATT procedures that reside in a remote system: REMOTECATTYou can also call CATT procedures that reside in a remote system:REMOTECATT ( CATT, INTERFACE, TARGET ).REFCATT ( CATT, INT, TGT ).EXECATTProcedure inTGTREMOTECATT is similar to REFCATT, but allows you to call a CATT procedure that resides in a remote system. In the command, you specify the name of the CATT procedure and, in the TGT argument, a destination pointing to the system in which the procedure is stored.Within the command interface of the REMOTECATT command, you can specify a third system, in which the CATT procedure will be executed. This third system must be a logical target system from the current system data container. The RFC destination attached to this logical target system does not have to exist in the central eCATT system, but must be defined in system TGT (where the CATT procedure resides).
112Script Test Configuration Data - Variants Importing Parameters System mappingSystem data containerCommand <interface>, <target>.Although it describes the substance of a test, a test script on its own does not form a complete automated test. A complete test case is represented by a test configuration, which is based on a test script, but also contains a system data container, which tells the script where to execute the various commands, and one or more variants – sets of data with which the test script will be executed.To create a test configuration, choose the Test configuration radio button on the initial screen of transaction SECATT, enter a name, and choose Create.Test configurations must be assigned to a package and an application component.
113Quick entry for a few variants Manual VariantsQuick entry for a few variantsCut and paste possible from delimited text file (Excel)Variants bound to a single configuration – not reusableOn the Variants tab of a test configuration, you will see a grid. There is a column in the grid for each of the importing parameters of the script that you assigned to the configuration. Each row in the grid represents a single variant.You can enter variants manually. Equally, you can cut and paste variants from an external file into the grid. Note, however, that this only works 30 rows at a time.
114Reusing Test Data: Test Data Containers VariantsTest data containerImporting ParametersScriptSystem mappingSystem data containerCommand <interface>, <target>.If you enter variants manually, they cannot be reused with any other configuration. You may also find that you are entering a lot of repeated field values.The alternative to this is to store data separately from test configurations in test data containers. These allow you to store data once-only in a central location, allowing you to reuse it in any number of test configurations that require that data. They also eliminate the redundancy caused by entering the same values in multiple variants because a single set of data, once entered, can be reused in any number of variants within the same configuration.
115Test Data Container Parameters Variants Name Value Ref System ABAP Type LengthAirline LH S_CARR_IDDate DVariantsVariant Description Airline DateVar1 Data AAVar2 Data LHTest data containers consist of parameters, which describe the interface of the container, and variants, in which the actual data are stored.You define parameters in the same way that you define script parameters in an eCATT script.Each variant contains a value for each parameter in the test data container.For data from a test data container to be assigned to a test script automatically, the source parameter in the test data container and the target parameter in the script must have the same name.
116Test Script Test Data Container Managing Test Data 1Test ScriptParametersP1P2 P3Test Data ContainerParametersP1P2 P3The simplest use of test data containers is to create a separate one for each test script. However, this does not provide you with any of the advantages of reuse, and, compared with CATT, only doubles the number of objects of which you need to keep track.
117Test Data Container Parameters P1, P2, P3, P4, P5, P6 Managing Test Data 2Test ScriptParametersP1P2 P3Test ScriptParametersP1P4 P5Test ScriptParametersP2P5 P6Test Data ContainerParameters P1, P2, P3, P4, P5, P6An alternative approach might be to have a single test data container that contains the parameters required by a whole series of scripts within a single application or sub-application. However, this can lead to very high numbers of parameters in the test data containers, making the whole thing hard to manage. You may also find that it does not eliminate the redundancy of data – one of the principal aims of test data containers.
118. . . Test Script Test Script Test Script Test Data Container Managing Test Data 3Test Script20 ParametersTest Script15 ParametersTest Script24 ParametersTest Data ContainerParameter Group 1Test Data ContainerParameter Group 2Test Data ContainerParameter Group nThe best approach to test data management is to analyze your test project and try to divide up the required data into logical groups. You can then create a whole series of test data containers for your project.You can link any number of test data containers to a test configuration and create variants by merging data from several sources.. . .
119Configuration Variants Variant WizardStart variant wizardTest Data ContainerConfiguration VariantsVariantsVariantsIn the variant wizard, the variants in the test configuration are displayed on the right-hand side. On the left-hand side are the various test data containers that you have assigned to the configuration. You can drag variants from a test data container and drop them into the configuration variants. The variants in the configuration contain references to the values in the test data container. Consequently, changes to the variants in the test data container are automatically applied to the corresponding variants in the configuration.The arrow buttons in the left-hand pane of the variant wizard allow you to scroll between the test data containers that you assigned to the configuration.To merge data from a test data container into an existing variant in the configuration, select one line in the left-hand grid, one line in the right-hand grid, and choose Add to variant.
120Managing Test Data - Example I_CARRID I_CONNID I_FLDATE I_FARE I_CURR I_TYPE I_MAX_E I_MAX_B...LH EURLH EURLH EURQF AUDQF AUDConsider the example above – it is a transaction based on the flight data model for creating a new flight in the database.The user must enter a flight number, followed by details about the flight such as the date, fares, and type of aircraft to be used.From the grid in the graphic, you can see that much of the data can be combined into groups of parameters, and much of it is redundant.To avoid this, we can store the data in reusable test data containers as shown on the next page.
121Managing Test Data - Example Test Data ContainerAIRLINESTest ConfigurationData for a particular test caseMaximize reuseMinimize redundancyTest Data ContainerAIRCRAFTBy storing the data required for tests in test data containers, you canMaximize reuse: The test data containers can be used with any scripts that require that particular dataMinimize redundancy: If you look at the grid on the previous page, the entry ‘LH 400’ occurs several times. If you are using a test data container, you only need to store the combination ‘LH 400’ once. You can then reference it any number of times. If you needed to change the data for any reason, you would only have to change it in one place.
122Modularization at Test Organizer Level Test CatalogTest PlanUserTest PackageTest ConfigurationTest ConfigurationThe Test Organizer is SAP's tool for creating and administering test projects. It is divided up as follows:A test catalog is a basic pool of test objects for a particular project. These might be eCATT test configurations, CATT procedures, manual test cases, or documentation objects.A test plan is a concrete test project, consisting of elements taken from one or more test catalogs.A test package is a subset of a test plan. It contains one ore more test elements, which are assigned to a user for execution.When users open their test worklists, they see test packages. From these test packages, they can either execute test configurations individually or execute the entire package. In this case, all of the test configurations in the package will be executed automatically one after the other.
123In this unit, you have learned: Unit SummaryIn this unit, you have learned:How you can modularize tests at script levelThe difference between a test script and a test configurationHow to create test configurationsHow to manage test data
124Versioning of Scripts Migrating CATT Procedures Unit 9: Advanced TopicsVersioning of Scripts Migrating CATT Procedures
125In this unit, you will learn Unit ObjectivesIn this unit, you will learnWhy script versioning is necessaryHow to create different versions of a scriptHow the system picks the correct version of a script for executionHow to migrate CATT procedures to eCATT
126VersioningFor different implementations of the same test (for example, transaction with / without controls), you can create different versions of the same script.There are many conditions that can invalidate a test script. For example:Changes to the screen sequence of a transactionAddition of new obligatory fields in a transactionChanges to the interface of a function moduleRe-implementation of an application (introduction of controls, implementation as a web application)When this happens, you must recreate your test script. However, instead of creating a new script, it is now possible to create a new version of the previous script.
127How Versioning Works Test Configuration R/3 EC_DEMO EC_DEMOSYSTEMS R3 Version 1: SAP_APPL 46CVersion 1: SAP_APPL 46CScriptEC_DEMOVersion 2: SAP_APPL 470Sys. DataEC_DEMOSYSTEMSTarget Sys.R3Release?4.6CR/3Rel. 4.6CWhen you call a test script from a test configuration or using the REF command, you never have to specify the script version that you want to be used.Instead, eCATT interrogates the target system to find out its software components and releases. Based on this information, it chooses the relevant version to be used.
128Specifying the Validity of a Version Target SystemWhen you create a new version of a script, you must specify the software components (for example, SAP_BASIS) and releases (46D, 610, and so on) for which it is valid.eCATT uses this information to find the most appropriate script version when it executes a test configuration or a referenced test script.As soon as you have more than one version of a script, you must specify, individually, all of the releases for which it is valid. The only exception to this is that one script version may have the vaildity *. This makes it the default version, which is taken if there is no version that is explicitly valid for the actual release of the target system.Only one version of a script can be used for a particular release.eCATT cannot execute a script in a system with a release that has not been entered in the validity range of one of the script versions. For example, if version 1 of a script is valid in 4.6C and version 2 is valid in 6.20, the script will not run in a 6.10 system.The import and export parameters of a script are constant across all versions.The local variables of a script are version-specific.
129Backup Versions Version 1 Version 2 Version 2 Version 3 SAP_BASIS 610 Version 3SAP_BASIS 620You may, in order to preserve a change history, want to keep multiple versions of a test script that are all valid for the same release. Normally this is not allowed – there can only be one version of a script that is valid in any given release.Old versions of scripts that you want to keep but that have been superseded by a new version that is to be valid in the same release can be marked as backup versions. You do this by setting the Backup flag in the versioning attributes of the script. Once you have done this, a further script version can have the same validity as the script you flagged as a backup.Scripts marked as backup scripts are not considered for execution when eCATT determines the correct version to be used.
130Test System Target System ‘X’ MigrationTest SystemeCATTMigration FunctionTarget System‘X’CATT ModuleCATT ModuleNew eCATT ScripteCATT contains a migration function that you can use to migrate existing CATT routines to eCATT scripts.In the simplest case, the CATT module resides in the eCATT system, and can be migrated “locally”.Equally, however, it is possible to migrate CATT modules from other systems. To do this, you must specify a system data container and target system in the migration dialog box. eCATT then looks in that system for the CATT module you specified.The migrated eCATT script is always stored in the eCATT system, regardless of where the original CATT module was located.Migrating a CATT module does not change or otherwise invalidate it.New eCATT ScriptWith target system X
131New eCATT Script with target system X Migrating VariantsTest SystemTarget System‘X’CATT ModuleVariantsNew eCATT Script with target system XTest ConfigurationScriptTarget System XVariantsIf an existing CATT module contains variants, you can migrate them into a test configuration. The migration tool creates the test configuration with the same name as the new eCATT script and the same parameters as the CATT module.
132Test System Target System ‘X’ Recursive MigrationTest SystemTarget System‘X’CATT ModuleREF… REF…New eCATT Script with target system XREF…New eCATT ScriptNew eCATT Script with target system XWhen you migrate a CATT module, you can choose to migrate all other CATT modules that it references at the same time.If you do not choose this option, the existing modules are referenced from the new eCATT script using the REMOTECATT command.Remember that if you subsequently migrate the referenced CATT modules, you must change these REMOTECATT commands to REF commands manually. It is therefore a good idea to select the recursive migration option when you migrate the main CATT module.
133In this unit, you have learned Unit SummaryIn this unit, you have learnedWhy script versioning is necessaryHow to create different versions of a scriptHow the system picks the correct version of a script for executionHow to migrate CATT procedures to eCATT
134In this course, you have learned Course SummaryIn this course, you have learnedWhat and when you need to test in the SAP Solution LifecycleThe advantages of eCATT for testing SAP systems compared with other automated test toolsHow to set up your system environment for testing with eCATTHow to create test cases to test various different kinds of SAP applicationsHow to create executable tests, and how these can be managed using the SAP Test WorkbenchHow to migrate CATT objects to eCATT