Markus Helfen, Michael Lauer, Hans Martin Trauthwein

Testing SAP® Solutions

Bonn

Boston

Contents at a Glance
1 Introduction ............................................................ 21

PART I Methodology 2 3 Theory of Software Testing ..................................... Test Methodology ................................................... 31 43

PART II Functional Testing 4 Test Management with the SAP Solution Manager ..................................................................

71

5 6 7 8

Economic Aspects of Test Automation ................... 143 Test Automation with eCATT .................................. 171 SAP Test Data Migration Server ............................. 253 Coverage Analyzer ................................................... 269

PART III Performance Testing 9 10 11 12 A Project Outline of a Performance Test ................... 279 SAP LoadRunner by Mercury .................................. 305 Performance Testing Using SAP GUI Scripting ...... 321 Monitoring a Performance Test .............................. 341 The Authors ............................................................. 363

Contents
Preface ......................................................................................... 13 Foreword ...................................................................................... 15

1

Introduction ............................................................. 21

PART I Methodology 2 Theory of Software Testing ...................................... 31
2.1 2.2 2.3 2.4 Test Types .................................................................. Test Stages ................................................................. Black-Box Test and White-Box Test ............................. Test Case Design for the Black-Box Test ...................... 2.4.1 Equivalence Class Partition ............................. 2.4.2 Boundary Value Analysis ................................ 2.4.3 Error Guessing ................................................ Test Data .................................................................... 31 32 35 36 37 39 40 40

2.5

3

Test Methodology .................................................... 43
3.1 Roadmaps in SAP Solution Manager ........................... 3.1.1 Project Phases ................................................ 3.1.2 Roadmaps ...................................................... Project Preparation ..................................................... 3.2.1 Test Strategy and Test Concept ...................... 3.2.2 Test Tools ...................................................... 3.2.3 Competencies and Responsibilities ................. Business Blueprint ...................................................... 3.3.1 Mapping the Business Process Structures ....... 3.3.2 Test Standards ............................................... Realization .................................................................. Final Preparation ........................................................ Go-Live and Support ................................................... 44 44 45 48 48 50 50 51 51 52 55 61 67

3.2

3.3

3.4 3.5 3.6

7

Contents

PART II Functional Testing 4 Test Management with the SAP Solution Manager
4.1 SAP Solution Manager ............................................... 4.1.1 Implementation ............................................. 4.1.2 Operation ..................................................... 4.1.3 Optimization ................................................. 4.1.4 Integration Capabilities of SAP Solution Manager .......................................... SAP Solution Manager vs. SAP Test Organizer ............ Test Case Management .............................................. 4.3.1 Connection with the System Landscape ......... 4.3.2 Creating a Project .......................................... 4.3.3 Test Standards ............................................... 4.3.4 Design of the Project Structure ...................... 4.3.5 Integrating Test Cases .................................... 4.3.6 KW Functions in SAP Solution Manager ........ Generating Test Plans and Packages ........................... Test Execution ........................................................... Status Analysis ........................................................... Integration Scenario ................................................... Customer Report from BSH Bosch and Siemens Hausgeräte GmbH ........................................ Customer Report from Reno Fashion & Shoes GmbH ..............................................................

71
72 74 75 76 77 78 81 83 86 94 96 98 101 105 109 114 119 125 134

4.2 4.3

4.4 4.5 4.6 4.7 4.8 4.9

5

Economic Aspects of Test Automation .................... 143
5.1 A Cost Model for Software Testing ............................. 5.1.1 Costs of Designing Test Cases ........................ 5.1.2 Costs of Testing Tools .................................... 5.1.3 Costs of Implementing Test Automation ........ 5.1.4 Costs of Maintaining Test Cases ..................... 5.1.5 Costs of Implementing a Test Cycle ............... 5.1.6 A Customized Testing Cost Model ................. A Cost Model for Software Errors ............................... Overall View .............................................................. Customer Report from INVISTA Resins & Fibers GmbH .............................................................. 145 145 146 148 149 150 151 152 155 157

5.2 5.3 5.4

8

Contents

6

Test Automation with eCATT ................................... 171
6.1 6.2 6.3 6.4 6.5 Test Components and Architecture of the Test Landscape ........................................................... Technical Requirements for Implementing eCATT ....... Structure of the eCATT Scripts .................................... Testing Transactions without Controls ........................ Testing Transactions with Controls .............................. 6.5.1 Recording SAPGUI Commands ....................... 6.5.2 Reading and Checking GUI Elements .............. Testing Web Dynpro Applications ............................... Testing Web Services .................................................. Integration with External Tools ................................... Checking the Results ................................................... 6.9.1 Testing Parameters ......................................... 6.9.2 Direct Testing of Values ................................. 6.9.3 Message Handling .......................................... 6.9.4 Parameterization of the Message Handling ..... 6.9.5 Checking Tables ............................................. Managing Test Data .................................................... Modularizing Test Scripts ............................................ Running eCATT Scripts ............................................... 6.12.1 Start Options ................................................. 6.12.2 Versioning ...................................................... Debugging eCATT Scripts ............................................ Overview of the eCATT Versions ................................. Further Steps .............................................................. Summary: Advantages of the Integration of eCATT in the SAP System ............................................ Customer Report from Zürcher Kantonalbank ............. 172 175 179 181 189 190 194 200 205 208 212 214 215 216 222 224 225 232 236 237 238 238 241 242 243 245

6.6 6.7 6.8 6.9

6.10 6.11 6.12

6.13 6.14 6.15 6.16 6.17

7

SAP Test Data Migration Server .............................. 253
7.1 7.2 Functions and System Landscape of the SAP TDMS .... 254 Customer Report from Behr GmbH & Co. KG .............. 261

8

Coverage Analyzer .................................................... 269

9

..................................... Phase Model of a Performance Test .........................7 10 SAP LoadRunner by Mercury .............. 321 11......................1 Executive Summary .........2 Performance Test for Portal Applications ......7..............................5 Documentation of the Test Execution .4 SAP GUI Scripting . 9......................................4 Load Test—Stress Test—Volume Test ................................................. 9..............................5 11....................... 9.........7.....4........................2 Single-User Test ......5.......Contents PART III Performance Testing 9 Project Outline of a Performance Test ...............4 Result Analysis .............. 305 10........ Availability of the Consulting Solution .. 9.....7 10 ..............2 Action Plan .............................................................7...3 11..............6 11.....................2 9...........................................5.........1 10....................... 9.................................1 Data and System Preparation ......... Customer Report from Universitätsklinikum Würzburg .....................2 Terminal Servers ...........4.....2 Data Analysis ...........................1 Process Analysis ............ Test Preparation ................................ 11..........3 9.........4... Execution Log ..........3 Selecting the Load Test Tool ..........5..... 9....5.............................3 Description of the Test Structure .5 9......................... 11. Performing the Load Test ....................... Final Report ...........4 The Load Profile ... 322 323 325 327 328 328 329 329 330 11.. Script Development .......... Roles in a Performance Test Project ..4...........................................4 Description of Test Goals ..... 311 11 Performance Testing Using SAP GUI Scripting ...... 281 282 284 286 286 292 293 293 295 295 297 297 298 299 300 301 302 302 303 303 303 9....................................................................... 9.................... 279 9......1 11......... Load Generators ....................................... 9...... 9.............4................... 9.6 9........................ 9..................1 9..........5....3 Multi-User Tests .................................................... 9.. 9................... 306 Customer Report by Sanofi-Aventis .......... Load Test Architecture ......................................5 Optimization ..2 11.......................1 PC Farm .................. 9.....................4...7............................. Performing the Stress Test .7....................................

...................... Transactions for Technical Monitoring . 12..................................................................2...................................1 12............................................................................2 SM12: Lock Entry List ................2...........................2.........5 ST02: Overview of SAP Buffers .................4 STAD: Transaction Analysis ..2 Procedure ................................................................3 SM66: Global Work Process Overview ............ 12........... 342 348 348 349 350 351 352 353 354 356 358 359 360 361 Appendix ... 12.........2.......................... 12..2...........9 SM04: User List .............. 12............................7 ST05: SQL Trace Analysis ..6 ST04N: Database Overview . 365 11 . 12......... 12..2......2.........................2............ 12.......2........ 12...............1 AL08: List of all Users Logged On .. 12........................................................ 361 A The Authors .Contents 12 Monitoring a Performance Test ...........11 ST22: ABAP Runtime Error ........................... 363 Index ..12 Summary .8 OS07/ST06: System Monitor ...........................................2......... 341 12...........10 SM21: System Log .. 12....................................2......... 12..........2..

robust test tools. more importantly. we must first become process-oriented. To fulfill all these requirements. and achieving transparency of results by using license free and integrated SAP test tools. We have made it a standard of ours to support our customers in a holistic way. Testing plays a central role in the fulfillment of this need. or through the offerings of our expanding ecosystem of customers and partners. we must also provide the relevant methodologies. the procedure that is used to execute test projects. In order to react appropriately to market requirements and to leverage technological innovations. we must focus on the methodology—that is. throughout the whole software lifecycle.Preface SAP AG has served its customers as a strategic partner for many years now. services. our customers need an efficient and optimized upgrade and implementation process. and fast adaptability. SAP provides a goal-oriented portfolio of services. which at the same time make a significant contribution to application quality. 13 . This book shows you exactly what SAP offers its customers in this regard. minimizing the duration of projects. This methodology is then enhanced by the relevant services and tools for automating functional tests and performance tests. We thus enable our customers to reduce on an ongoing basis the resources they require for testing by providing flexible and. this means that besides the applications themselves. using real-world customer experience reports to emphasize the practical aspects. This portfolio contains tools for designing test tasks. and tools that enable us to do more than just fulfill our customers’ and partners’ expectations— be it through SAP directly. It does so based on its role as a provider of software applications that support process and business modelling innovations. flexibility. processes. In my board area of Global Service and Support in particular. reducing project costs by increasing methodological efficiency. and tools for this purpose. In other words. as a “trusted advisor”.

Only by the productization of our offerings and consulting services in the form of standard services can we help customers in companies of all sizes. This productization approach guarantees that our services have excellent availability and are of the highest quality. as testing costs can be accurately forecasted and calculated in advance. What is more. Our experts in this area use mainly SAP test tools and enable SAP technologies. Productization also allows us to make the process of transferring knowledge to our customers more efficient. In this context. we have been at pains to ensure that our offerings can be used throughout all phases of the software lifecycle and for all software applications. As for you. cost controlling becomes more transparent. Also. from small and midsize enterprises to large enterprises. so that it can handle all our customers’ needs and requirements. These standard services are delivered by the SAP Test Management Consulting team. new SAP tools like the Test Data Migration Server (TDMS) and widely-used third-party products such as those from Compuware and Mercury are also supported. I would like to extend my sincere thanks to the authors for their commitment to provide our customers and partners with the benefit of their combined experience in the form of this book. I hope that this book gives you much in the way of useful information about our tools and practical tips for your own activities. at SAP we have paid particular attention to make our offering scalable. SAP is thus ideally positioned to fulfill our own vision of being the “trusted advisor” for our customers. such as the SAP Solution Manager or eCATT. dear readers.Preface In implementing the methodology. thanks to goal-oriented analysis of customer experiences. Best regards Gerhard Oswald Member of the Executive Board of SAP AG 14 . However. and that you can then put these tips and information to good use in your own work.

SAP had already successfully passed the stage of the New Dimension products. and tools—in a presentation slide. In particular. rules. This applies to the various test types and stages. the representation problem was solved. but the title for our slide came to us only when the above-mentioned song was played on the radio and gave us the inspiration we needed. Challenges 15 . The technology also posed challenges in terms of test execution and the testing tools that were mainly used. At that time. After a few more miles of driving. methodology. The solution landscapes operated by SAP customers had many different levels of heterogeneity. We wanted to represent these four different dimensions—solutions. robust. and technologies in a sustainable. we spent a long time discussing the challenges that our customers face in the area of testing. A wide range of tools from different providers are available on the market. technologies. solutions. companies were making purchasing decisions with financial consequences that went far beyond the licensing costs of the third-party tools in focus. and conditions. chatting about how to optimize our presentation material. at that point.Foreword Welcome to the Jungle! Welcome to the Jungle? What does this catchy tune from Guns N’Roses have to do with a serious specialized book from SAP PRESS? It all started some years ago as we drove back from a customer meeting. Our spontaneous brainstorming session brought up several challenges that we categorized as follows: Customer processes had been mapped to span multiple systems in a solution landscape. and cost-effective way? Test projects should follow a minimum set of methodological principles. Could the automation tools in particular handle SAP’s user interfaces. We wanted to illustrate these challenges in a presentation slide in order to represent our proposed solutions in a way that would “speak to” the customer.

it is still in use today.0 SAP NetWeaver Mobile Sales APO SAP xApps CATT EBP TestDirector System Tests Test Management Test Organizer SAPGUI 6.. 380 customer projects As you read this book. Testing Seems to be a Jungle . 4. but that the wide range of experience we’ve gained in our real-world consulting work has made it possible for us to undertake the writing of this book.nn Load and Stress Tests Integration Tests WinRunner SAP Solution Manager R/3 Enterprise Vantage Track Record Functional Tests BIW 3. we were in the fortunate position of having access to findings from approximately 380 customer engagements and projects. Issue Management Java QA Run QA Load SAP Test Workbench CRM eCATT Web AS 6. 4.. in particular. “Testing seems to be a jungle” and by the way.Foreword The animated slide was entitled. albeit in updated form. Much of our experience comes from customer projects. you will see that not only we have continued thinking about our customers since our fateful trip. Test Management Consulting 1 User Modifications End-To-End Rel. we come across this situation several times a year. for example. Perhaps you have come across it. Many of our observations and arguments arose from or were affirmed in discussions and collaborations with our customers. Again and again. plus numerous other events and presentations on the subject of testing and quality assurance in and with the SAP customer base. IS . the wrong drivers were recommended for 16 . we encountered situations in which customers received poor consulting arising from lack of experience on the part of the consulting partner.7 WinGui Unicode SCM LoadRunner QA Director WebDynpro BIW 2. 4.x Figure 1 “The Jungle” Slide Findings from approx.6C SiteScope Regression Tests TestPartner Rel.. In the eCATT area.nn Topaz QuickTest Pro HTML Rel.x © SAP AG 2004.. We also realized that there still remains a significant need for information and reliable consulting in this area.

This reputation has been built on the basis of countless customer contacts. However. and arguments from the world of testing at SAP.Foreword the specific use in an automation activity. This book gives the reader access to the technical basics. Even the requirements of customers that are subject to compliance regulations can now be easily fulfilled. it is the customer who suffers the consequences of such misinformation if the topic falls out of favor and the motivation to continue working on it no longer exists. Central test documentation 17 . which is why in creating this book. the estimated level of unreported usage is undoubtedly much higher than may at first appear. our customers still have a great need for information about the SAP Solution Manager. we can say only that based on the available evidence. Based on our monitoring of our customer base. Ultimately. engagements. although the basic functionality of those systems is still alive and stable. We do not have exact figures for the usage levels of SAP test tools amongst the SAP customer base. Using proprietary SAP test tools is a natural consequence of using SAP NetWeaver as a strategic business process platform and of the associated increase in homogeneity of the solution landscape. companies that are looking for a suitable initial use case of the SAP Solution Manager will quickly find what they are looking for in the area of testing. It would be careless. This represents a real step forward from earlier versions of the classic Test Workbench from SAP R/3 system releases. and even neglectful. we have paid much attention to the topic of integrating the SAP test tools into the SAP Solution Manager. The SAP Solution Manager enables us to document projects and tests in a thoroughly reproducible manner in a central system. Also. In particular. you may place your trust in the reputation of SAP Test Management Consulting as a trusted advisor in the testing environment. and projects. and be able to immediately realize the benefit potential by finally dispensing with spreadsheet-based solutions. our best practices. to squander this advantage by using other tools without discovering and evaluating the alternative: the test tools from SAP. procedures. we have seen that the level of traceable usage increases with the usage level of the SAP Solution Manager.

and executing numerous test projects with different goals and of different sizes Decision-makers and managers in IT departments. including creating. they also good-naturedly tolerated our mental absence even when we were physically present! Even with all the commitment and dedication in the world. on the basis of more than 30 years of work and experience of best practices. and we are very grateful for this. This decision was based largely on our view that a book seemed to be the best way of passing our experiences to customers. Without doubt. along with us. planning. we took on the challenge of writing this book in a well-tried team in order to lead a path through and shed light into the abovementioned jungle. We also express our thanks to our customers. certifying. operating. the implementation of this kind of project requires certain financial conditions. We would therefore like to thank everyone who encouraged and supported us in writing this book. and auditing quality management systems in different companies Quality assurance in developing. Acknowledgements The completion of a work of this scope and length is no way thanks only to the authors. we focused on the following areas of activity: Quality management. who at the start of 2005 began looking for a publication on the subject of testing SAP solutions. implementing. as represented by Gerhard Oswald. In response to the initiative of Galileo Press.Foreword In designing this book. particularly those who. not only did they have to do without us on occasion. as well as program and project managers of SAP customers will find in this book tried-and-tested procedures for planning and realizing their own test projects. the first people who deserve thanks are our spouses and children. are sharing their experiences with readers in this 18 . During the writing process. These conditions were fulfilled entirely spontaneously and adequately by the Executive Board of SAP. and operating software products Designing. implementing.

Thanks are also due to those customers with whom we gained our experience in this field over the years. We are as proud as ever to be part of this company. It has been a wonderful experience to take part in and complete this project in a company like SAP. January 2007 Markus Helfen Hans Martin Trauthwein Michael Lauer 19 . and we wish you all the best in your role as Consultant! Our editor and interface with the publishing house was Florian Zimniak. Their feedback confirmed our approach and without it. he took our knowledge and experiences and put them together with his research to create impressive results. There are also several people within SAP AG itself to be thanked for their support and advice: Jonathan Maidstone (Product Manager SAP NetWeaver Test Tools). Marc Oliver Schäfer (Product Manager SAP Solution Manager). Tim. Working with him was always a pleasant and successful experience. we could not have written this book. Over the course of numerous conversations. whose culture continues to encourage and enable such projects. A big thank-you. and Dr. Manfred. and Ron. Dr. contributions.Foreword book. Anja Marschollek. Christian Hansen for his support with creating the Coverage Analyzer chapter. Our editor Tim Dahmen also played a central role in bringing our work to fruition. who always tries to create maximum value for the readers from our manuscripts. Many thanks to Florian Zimniak. Ralf Debus and Dennis Landscheidt in the Test Data Migration Server area. and corrections. Ingbert. Jörg Bischof on behalf of the whole eCATT development team. Germany. We extend special thanks to Andreas Wentz as a representative of all our colleagues at SAP Test Management Consulting. Thomas. who provided support in the form of ideas. Peter. In our own departments. Peter Keller. we would like to thank our managers for their support: Dorothée. St. Special thanks to Mirja Werner for her support in the translation process.

and the system data specifying the systems to be tested. Test configuration System data Test logic Test data SAP System Transactions without controls Transactionen with controls Web Dynpro applications BAPIs Function modules Web Services Driver TCD SAPGUI WEBDYNPRO FUN FUN WEBSERVICE Non-SAP system External components REFEXT Figure 6.1 Structure of a Test Configuration Test drivers To flexibly interact with the system to be tested.1 Test Components and Architecture of the Test Landscape Test configuration and modularity The basic object for working with eCATT is the test configuration. An important aspect is the modularity achieved by separating test logic. eCATT uses test drivers. 172 . and system data. Both test and system data can thus be used in more than just one test configuration. These adapters interlink on different levels with the system to be tested.6 Test Automation with eCATT 6. A test configuration consists of the test data to be used. a test logic controlling the test process. and thus enable you to directly check the different application components. test data. The test logic also has a modular structure so that individual modules of the test logic call each other and can be implemented in several test configurations.

4. web services can be tested in a similar way to function modules. depending on the implementation purpose and release of Web AS. as well as transactions and Web Dynpro applications. Only the establishment of a connection 173 . these applications are additionally supported on the Java stack.Test Components and Architecture of the Test Landscape 6. Therefore it is possible to process the recorded transactions in the background (without GUI). The following drivers are provided for selection. Management transactions Function modules and BAPIs can be called directly from eCATT without using a management transaction like SE37. the SAP system to be tested can be addressed at different levels. Web service driver From Web AS 7. Additionally. TCD driver The TCD driver is appropriate for conventional transactions (without controls). It is handled differently than the TCD driver because the recording directly refers to the user interaction with the controls.0. the TCD driver enables you to make small adaptations to finalized scrips.1 By implementing the appropriate driver you can test both functionlike objects (like BAPIs). With the basis release 7. An advantage is that the TCD mode is based on the batch input technology.0 of Web AS.40. for example. which allows for very efficient tests. More details about the SAPGUI driver can be found in Section 6. This driver is therefore particularly easy to maintain. Web Dynpro driver Web Dynpro applications on the ABAP stack are supported by a separate driver with the SAP basis release Web AS 6. SAPGUI driver The SAPGUI driver enables you to test transactions that use controls. The driver exclusively works with and via the SAP GUI for Windows. function modules. More details about the TCD driver can be found in Section 6.6. and web services.5. Therefore the transaction sequence in the test process can remain unchanged as opposed to a manual test performance. More information can be found in Section 6. Using a test driver.

This means that eCATT itself is maintained on the central test administration system and accesses the application to be tested via an RFC connection.1 or higher Test Workbench eCATT Test Organizer mySAP BI SAP R/3 4. testing several components on different systems in an integrated way. each of which is addressed via an appropriate driver. e.7. The application to be tested can reside on any standalone system of the system landscape. This encapsulation ensures that the information about the systems to be tested can be exchanged very easily. An interesting possibility is the testing of applications that provide their services both as a Web Dynpro application and as a web service. e. that is. a number of logical targets Encapsulation 174 . test case descriptions) test scripts as well as test and system data containers that are placed on the central test system. SAP recommends implementing the SAP Solution Manager for both manual and automated tests.2.6 Test Automation with eCATT requires special handling. when the system landscape has changed.6C or higher mySAP CRM Non-SAP Figure 6.20 or higher SAP Solution Manager 3. The requirements for operating eCATT as a central test administration system are described in Section 6. Central test system SAP Web AS 6. Central test administration system eCATT was designed to be operated via a central test system. In a system data container. are supported by eCATT as well. The test documentation (i.2 Central Test System in the SAP Application Landscape All created test objects (i. the evidence of test performances) is managed on the central test system. eCATT provides a very simple and effective mechanism for this encapsulation. System data container and logical targets To execute eCATT scripts on different systems. Integration tests. More information can be found in Section 6. e. It can consist of any components. g. it is necessary to encapsulate the system-specific aspects of the script.

only the logical target specifications are used.2 within the test landscape are defined.3 Function of the System Data Container Thus. The test system and the central test management system communicate via the remote function call interface (RFC). Setting up the trusted RFC connections 175 . Alternatively. 6. every logical target is assigned exactly one RFC connection that references the physical system to be tested. A logical target describes the role of an application instance in the solution landscape. In eCATT scripts. Typically. In the system data container.Technical Requirements for Implementing eCATT 6. however. These belong to different applications that are distributed to and running on several systems. and the business process is mapped by a chain of transactions.2 Technical Requirements for Implementing eCATT In addition to the requirements to the test organization that have been described in detail in the previous chapters. only the system data container needs to be exchanged within the test configuration. Script 1 Action 1 on CRM CRM = RFC27 Action 2 on SCM SCM = RFC02 Action 3 on SCM RFC02 System data container RFC27 Script 2 Action 4 on SCM SCM system CRM system Figure 6. A central test management system uses a test script to control the test of the components on all systems. a test landscape consists of several systems. a different system data container can be specified for executing the tests. there are some technical requirements for implementing eCATT. when changing to a different target system within the test landscape.

The following selection is available: eCATT and CATT Not Allowed Prevents test scripts to be started in the client. 176 . Using inline ABAP and function modules.10 SAP R/3 4. The clients are adapted in Transaction SCC4. a connection via RFC always requires an interaction with the user because the client. eCATT and CATT Allowed Enables you to implement eCATT and CATT without restrictions.6D SAP R/3 4. Basis release Web AS 6. Although this problem could be solved by storing the logon data in the RFC connection.1 Minimum Requirements Regarding the Support Package Level According to Installed Release More information about required release and support levels can also be found in SAP Note 519858. Client maintenance An explicit permission must be set for every client in which an automated test is to be run via eCATT. it is not recommended for security reasons. The procedure recommended by SAP is to set up a trusted RFC connection. This option may not be set for any client in which automated tests are to be run. Call the client maintenance and select the respective client. Support Package Level First. This requires neither a manual logon to the target server nor would the logon data need to be stored anywhere. An exact instruction for setting up a trusted RFC connection can be found in SAP Note 128447.20 or higher Web AS 6. all systems to be tested must fulfill specific minimum requirements regarding the installed support package levels of the basis if their basis release is older than 6. any code can be run on the target system (security).6C Basis support package level No requirements At least 17 At least 21 At least 32 Table 6. Under CATT and eCATT Restrictions you can select among several options.6 Test Automation with eCATT Even for an automated test run.20. the user name and the password must be re-entered for every system called via RFC.

it disturbs the automatic script execution. eCATT Allowed. Disabling the Notify When a Script Attaches to a Running GUI option is recommended (see Figure 6. you need to install and enable scripting on the frontend during the SAP GUI setup. However. If you want to record transactions with controls using the SAPGUI driver. the full range of functions can be implemented for tests on this client.Technical Requirements for Implementing eCATT 6. These predefined values are then automatically completed in the Dynpro. eCATT Allowed. you must verify this setting and possibly adjust it. They must be addressed via eCATT. The second item.4) because although it is relevant to security. This option is very comfortable for the user but can lead to errors in the following Parameter preassignment via Transaction SU3 Enabling SAP GUI scripting 177 . only transactions can be executed in the target client. The corresponding profile parameter is sapgui/user_scripting which must be set to TRUE. Scripting is enabled via the menu Customizing of Local Layout (Alt-F12)—Options.2 eCATT and CATT Only Allowed for ‘Trusted RFC’ Automated test cases can be started only if the target system has been addressed via a trusted RFC connection.4). both the central test system and all target systems must have SAP GUI scripting enabled. Transaction SU3 enables you to make user-specific preassignments to parameters. if necessary. cross-client Customizing must also be permitted. should remain enabled because eCATT does not establish any connections via scripts. please note that the settings in this dialog box are clientspecific. The setting of the scripting permission on the server is maintained via Transaction RZ11. In this case. Additionally. Notify When a Script Opens a Connection. but FUN/ABAP and CATT not Allowed With this setting. but FUN/ABAP and CATT only for ‘Trusted RFC’ This protection level allows calling function modules and executing inline ABAP provided that the connection to the target system is established via a trusted RFC. This setting is maintained via Transaction SCC4 as well. If you change your work center. You can enable the SAP GUI scripting in the corresponding dialog box (see Figure 6. Another necessary preparation step is to remove the existing parameter preassignments. In addition to the actual execution of eCATT scripts.

4 Customizing the Local Layout (Alt-F12)—Options Dialog You should therefore ensure that no user-specific parameters are predefined. e. you can create a new user. you can use Transaction SU3 to delete the parameter preassignments for your user before recording. if you need to document the creator of the automatic test case for verification management. The same happens if the script is to be processed by a different user (SAP user). g. and use it exclusively for recording. the changed assignment can produce errors. TESTRECORD.6 Test Automation with eCATT two ways when eCATT is used. For this purpose. Alternatively. Delete Predefined Values Figure 6. Ensure that Scripting is Installed Enable Scripting Turn Off Message Figure 6. If the preassignments are changed between recording and processing the script.5 Delete All User-Specific Parameter Preassignments 178 .

Import parameters are used for importing test data from variants or other scripts. and commands. They are the input interface of the script and contain the input values at runtime. Versioning data enables the system to automatically select the correct script version if there are several versions. according to their function and visibility. person responsible. parameters. the values of which are only available within the script. Results of the script can be forwarded using export parameters.3 6. and component. Another usage of local variables is the transfer of values between called scripts.Structure of the eCATT Scripts 6. They are used as additional storage space for interim results. The keywords enable you to specifically search for scripts. the attributes of a test script also include keywords and versioning information that are used by the system for supporting script management. It consists of attributes. package. Parameters are divided into three classes. Different scripts can therefore contain parameters of the same name. Local variables are parameters.6 Structure of an eCATT Script In addition to management information like title. Test Script Attribute Import Parameter (I) Parameter (E) Local Variables Export Commands Figure 6. Attributes Parameters 179 . Every parameter has a unique name that is valid only within the script.3 Structure of the eCATT Scripts The structure of an eCATT is similar to an ABAP function module. which are the output interface.

A parameter used for entering a customer number. The test steps and check logic of eCATT scripts can be supported by a wide range of commands. several transactions can be recorded in a test script. a parameter has a type reference. they are comparable to tables. the eCATT script can perform calculations and comparisons in a second step to compare the result returned by the test object to an expected value. though. This procedure is called “parameterization. it can be necessary to directly search a database table for the existence and characteristics of specific values. Generally. like the columns in a table. These comparisons are mainly performed using the messages and values returned by the system. because they prevent the script from being reused and require a lot of maintenance effort due to redundancies. These more complex script structures should be avoided. Tabular parameters are made up of a sequence of structured parameters. You should therefore make sure to give parameters in different scripts the same names if they are used for fields with matching contents. Complex parameters In addition to its name. First. Structured parameters correspond to a row in a table. The import parameters of the script are thus passed to the input interface of the test object. Commands Recommended modularization procedure 180 . a structured or tabular parameter is created. As soon as the test object has been executed. Typically. In more complex test cases.” It is essential for a successful script because the parameterization links the pure recorder function of the test drivers to the test data. More information about Modularizing Test Scripts can be found in Section 6. and they consist of several fields identified by names. a function module. or a BAPI. which is either a transaction. for example. It transfers the control flow (execution management) to the test object. a test driver is called. Using such a reference to a structured data type from the ABAP Dictionary. In individual cases. however. an eCATT script consists of two blocks.11.6 Test Automation with eCATT Using this name. the test data is assigned to the parameters. These and other conventions should be documented in an automation manual that is mandatory for your organization. it is preferable to divide the test case into several partial scripts and have them called by a top script. could be named I_CUSTOMER_NO throughout all scripts.

The lower area is Script editor 181 . commands. The commands support the mapping of test scripts and check logic. first start eCATT (Transaction SECATT). Its interface is divided into three areas (see Figure 6. They link commands to test data. In the initial screen (see Figure 6. select the Test Script item. Conclusion 6. and enter a name. The parameters are the interface of the script to the outside.7 Typical Process of an eCATT Script An eCATT script consists of attributes. and parameters.Testing Transactions without Controls 6. They are used for addressing a test driver and for checking results.4 Assign System Data Assign Test Data Call Test Driver Check Results Write Log SAP System Figure 6. Note that the name must reside in the customer-specific namespace.8 eCATT Initial Screen The central tool for creating eCATT scripts is the script editor.4 Testing Transactions without Controls To create an eCATT script.8). The attributes are management information for organizing the scripts. Create Script Insert Script Name eCATT Object Select Test Script Figure 6.9).

The first step for creating the script logic is recording a transaction. If you want to edit a command interface. An appropriate interface is then automatically created by the script editor. First select the desired function group (UI addressing) and then the test driver. the available commands are not yet grouped into functions. Note In the basis release of Web AS 6. Use the recorder function of the script editor for this purpose. In the following we assume that you use the TCD driver for recording transactions without controls. 182 .20. A dialog is displayed where you can specify the necessary settings for the recording (see Figure 6. As soon as you select the driver you can select the transaction to be tested. The available commands are sorted by functions and divided into groups. the structure editor is additionally opened to the right.10).9 The Script Editor The upper area provides an input possibility for creating the parameters of a script (see below). You then select the command directly. in the script editor select the Pattern button. Switching View between Parameter and Command Interfaces Editor for Parameter or Command Interfaces Open Structure Editor Command Editor Structure Editor Figure 6.6 Test Automation with eCATT occupied by the command editor. There you edit the script logic that is composed of the different commands. It can be enabled by double-clicking on the name of a command interface in the command editor. Start recording To start recording.

The TCD command is designed for addressing the TCD driver. Perform the transaction as usual and then close the transaction window (F12). TCD command A TCD command must always be created via a recording.Testing Transactions without Controls 6. During the execution of the test script. The data you entered and the default values for fields you did not fill in are recorded. The entire recorded transaction is now included in the corresponding command interface. [<target system>] ).4 Select Command Group Select Command Command Interface is Automatically Created Specify Transaction to be Recorded Figure 6. eCATT asks you if you want to accept the data. No fixed values are recorded for fields you kept at their predefined default values. the command interface records all dynpros with all fields that have been displayed in the transaction. the corresponding fixed values need to be replaced with parameters (see Figure 6. If you confirm with OK. The values you entered are displayed as fixed values in the command interface. When recording. When a TCD driver is used. a new command line with the TCD command is displayed in the editor. It has the following format: TCD ( <transaction code>.10 Start Recording Dialog eCATT now opens the transaction. If the test case is to be executed with different values than those used during the recording. the parameter value is then inserted in the appropriate Command interface Script parameterization 183 . <command interface>. ensure that you enter input values for all fields that are relevant to the test case.12). During parameterization. You can later use the search function to find these fixed values during parameterization. you therefore you might have difficulties with identifying these fields.

13).12 Replacing Input Fixed Values with Parameters Because the automatic creation of parameters is not supported until basis release Web AS 6. Use import parameters to transfer values to input fields. For this purpose. This procedure links a part of the command interface of the TCD command to parameters that are visible to the outside. Command Interface Transaction Dynpro Field (Value=0) Field (Value=37) Dynpro Field Figure 6. complete a row in the parameter editor to add a parameter (see Figure 6.20.11 Structure of the Command Interface Script Parameter Import Parameter Import Parameter Import Parameter Export Parameter Variable Variable Command Interface Transaction Dynpro Field Field Dynpro Field Field Figure 6.6 Test Automation with eCATT place. you need to manually create the required parameters if you are using release 6. fields of the command interface can be linked to parameters to return results of the TCD command. Use export parameters or local variables to process results from the command interface. In other words.40. 184 .

specify “I” for import or “E” for export parameters.14). When you have found the corresponding field. all export parameters with “E_”. A well-established procedure is to have all import parameters start with “I_”.Testing Transactions without Controls 6. In the parameter editor. If you need local variables you can create them now as well.14 Script Editor During Parameterization To parameterize a recorded TCD command. and all local variables with “V_”. Set the type to “V”.13 Adding a Parameter Every parameter has a unique name for identification. Recommended procedure for naming conventions Parameter types Replace with Parameter Fixed Values Entered while Recording Set Mode Figure 6. open the related command interface in the structure editor (double-click). you specify their visibility.4 Add Parameter Identifier Description (Free Text) Default Value Type (I/E/V) Figure 6. Once the names of the parameters have been defined. Look for the entered fixed values. 185 . To improve the readability of the scripts it is recommended to keep a consistent notation. replace the value with the name of the parameter (see Figure 6.

186 .8. If the comparison fails. Via user parameters. see Section 6. though. valuable insights can still be gained. The “O” refers to an output field that is neither read nor checked by the eCATT script. after installing a support package. 3. you should use the “G” mode to first read the field value and then check it later using the CHEVAR command. 2. you can set the appropriate mode: 1. Note that the possibilities of this test are rather limited. Although the joy at a successful test—which is always successful when errors are found—is usually muted by the implicated difficulties for the operation or the project. G (get value) This mode is designed for exporting values from the command interface. A value calculated by the transaction is transferred to an export parameter or a local variable after the TCD command has been executed. We distinguish between three actions. Additionally. Re-recording The TCD driver enables you to re-record driver calls that have already been parameterized. the “I” mode refers to an input field that is not changed by eCATT.6 Test Automation with eCATT Parameter mode eCATT supports different kinds of parameterization. for example. the error must be corrected in the application. The obvious case is that the change has caused an error in the application logic. C (check value) The third mode permits a simple verification of the results. there are two passive modes available. For more complex conditions. I/O (passive) In this case. For more information. Such an error can have two causes. The value returned by the TCD command is compared to the specified parameter. S (set value) This mode is used for transferring import parameters or local variables to transaction fields. In this case. just like user input. This option is used if the test script encounters an error after the underlying transaction has been changed. the application can predefine the field with values. 4. the test case is regarded as faulty. If you select this mode the parameter value is transferred to the corresponding dynpro field during script execution. In the MODE column.

The options relevant to the TCD driver can be found under the UI Control tab in the TCD field. This functionality is exclusively available in the TCD driver and makes the recordings performed using this driver extremely easy to maintain. there are various start options available for selection. Trigger the re-recording of the transaction and record the transaction as usual. Start Re-Recording Figure 6.16 Start Options when Processing a TCD Recording 187 . you can re-record an existing TCD driver call while maintaining the existing parameterization.Testing Transactions without Controls 6. Double-click on the command to open the Change Command dialog (see Figure 6. Fields that have already been parameterized are taken over from the old command interface according to their field names. Since the structure of a transaction changes more frequently than its fields (a field can be assigned to a different dynpro or another group but is hardly ever renamed or deleted).15). the transaction is already fully parameterized immediately after the recording. Select Options for UI-Control Start options for the TCD driver Select Start Option for TCD Figure 6. Only newly added fields must be completed during the parameterization.4 The cause of the second error can be that the structure of the recorded transaction has been changed and is now incompatible with the existing test script.15 Change Command Dialog For processing a script. In most cases.

Display Errors Only. The database is updated synchronously. All actions of the script can be observed on screen. they can be viewed in the automatically created log of the eCATT run.6 Test Automation with eCATT Start options are selected before a script is processed. Asynchronous Update This option processes the script completely in the background. For tests using eCATT. The database is updated synchronously. e. without user interface. Synchronous Not Local The script is processed in the background. Process in Background. By disabling a synchronous update you can often considerably increase the speed. and the update takes place synchronously but via a different work process than the 188 . e. This means that the control flow might return to the script before the updater has changed all values in the database. Synchronous Local This option processes the script completely in the background. Synchronous Local The script is processed in the foreground. The database is updated asynchronously. This option ensures that all input values have been updated in the database before the next step in the script is executed. the respective position is displayed in the user interface. The error can now be manually corrected. The option can be used when eCATT is implemented to provide mass data in the system. it can therefore not be guaranteed that a change from a previous step has been implemented in the database. This can be the case either during a data migration or when test data is created for preparing manual tests or trainings. i. Process in Background. The script is then continued in the background until another error occurs or the test case has been completed. If an error occurs during the execution. For a subsequent step of the script. The database is updated synchronously. Errors are not reported immediately. with a user interface. you should always select one of the options with synchronous update for the reason mentioned above. After the script has been executed. You have the following options: Process in Foreground. i. There is no output to the screen. Synchronous Local This option processes the script in the background. Process in Background.

An important difference is that the SAPGUI driver does not connect to the application server but to the frontend. transactions are able to present more complex and user-friendly graphical user interfaces via SAP GUI controls. One characteristic of this way of programming is that a part of the application logic is run on the frontend.5B. Since the TCD driver immediately interferes with the application server. you replace the fixed values entered during the recording process with parameters and can thus create a flexible. the SAPGUI command only allows the transfer of values to the application. 189 . It has the following format: SAPGUI ( <command interface>. The SAPGUI driver works with the SAP GUI for Windows and interferes with the SAP system at a different level than the TCD driver. Regarding the message handling within the TCD driver. This option is obsolete and is only supported for downward compatibility. Use Default The option stored in the command interface of the command is used.5 Testing Transactions with Controls Starting with release 4. eCATT provides its own test driver for recording transactions with controls.Testing Transactions with Controls 6. 6. Changing the assignment mode enables you to read and check the actual values of a parameter. Therefore. The SAPGUI command is designed for addressing the SAPGUI driver. usable script. application parts running on the frontend are outside its reach. please refer to Section 6. SAPGUI command In contrast to the TCD command.5 transaction. During the parameterization.9. in the context of the Enjoy SAP initiative. Conclusion Transactions without controls can be recorded by the TCD driver in a way comparable to a macro recorder that you might know from Microsoft Excel. There are separate commands for reading and testing values. [<target system>] ).3.

e. 190 . this means that the SAPGUI driver only records information about the fields that are actually changed. Reading and Checking Field Values 6. the input of text in a text field or the expansion of a branch in a tree control. the SAPGUI driver registers events. 2. In particular. These events refer to changes of the state of screen elements. Function Parameterizing Reading Check Passive (output) Passive (input) TCD Driver TCD (mode S) TCD (mode G) TCD (mode C) TCD (mode O) TCD (mode I) SAPGUI Driver SAPGUI GETGUI CHEGUI Table 6. the selection of a value in a listbox. and therefore decisively enhances reusability and maintainability. not the entire sequence. Per dynpro Events referring to the same dynpro are joined to form one command. 1. it is only necessary to re-record the affected part of the script. to adapt it to a new support package level. This division ensures a better overview.2 Commands for Parameterizing. Another difference is that the SAPGUI driver uses different commands for reading and querying screen elements while the TCD driver serves all actions of the TCD command (see Table 6.2). If it should become necessary to change the test script. for example. Per dialog step For every GUI event (every token exchange between frontend and backend).6 Test Automation with eCATT Events While the TCD driver records the result of the input in the record fields.1 Recording granularity Recording SAPGUI Commands Because this type of recording generates a large number of events for complex transactions you can divide the generated eCATT script into several SAPGUI commands. a separate row containing one SAPGUI command is inserted into the script. enables you to insert explanatory comments between the individual steps. g. The SAPGUI command distinguishes five levels of granularity that are explained in the following.5.

Specify a setting and confirm your selection by clicking on Start Recording.5 3. After you confirm that you want to record via this connection. even if they span several dynpros. 191 .17 Granularity Levels of the SAPGUI Command The SAP Test Management Consulting recommends the granularity level per dynpro as appropriate for most requirements. a dialog is displayed in which you can set the granularity of the recording (see Figure 6. Per session All events between starting and ending an SAP GUI session are joined to form one command. 4.Testing Transactions with Controls 6. Describe this granularity level as the default setting in your automation manual. Per transaction Events referring to the same transaction are joined.18). To begin recording one or several SAPGUI commands. If you use this option. Manual The creation of an SAPGUI command is explicitly triggered by the user. eCATT estab- Recommended granularity levels lishes a connection to the target system. select the Pattern button and then the SAPGUI (Record) command. Per Session Per Transaction Per Dynpro Per Dialog Step SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI Figure 6. who presses an appropriate button during the recording. you should add a comment to the creation of every command to maintain a better overview. 5.

After the transaction has finished. you must now start the transaction by entering the corresponding transaction code. Enable Manual Command Generation Trigger Command Generation Important: Confirm here when Changes are made Automatic Command Generation: Set Granularity Figure 6. you are able to specify a transaction to be started.6 Test Automation with eCATT Set Granularity Set Start Transaction Confirm and Start Recording Figure 6. Initial state recording Because the eCATT commands CHEGUI and GETGUI were not introduced until the basis release of Web AS 6. you access the first screen of the selected transaction.40. In this case. If you did not specify a transaction or if you use eCATT in the basis release Web AS 6.19) and trigger the creation of SAPGUI commands using the appropriate button. If you use the manual mode you must change back to the recording window (see Figure 6. you go back again and terminate the recording. a different option of accessing field values had to be used in the basis release of Web AS 192 .18 Record SAP GUI Command Dialog With the basis release Web AS 6.19 Dialog Box for Controlling the Recording Execute the transaction as usual.20.40.

In most cases. the initial state recording was implemented. In the Record SAP GUI Command dialog box (see Figure 6.40.20 Dialog Box for Starting the Recording in the New Session With the basis release of Web AS 6. Link “Checking Initial States”.20. they primarily simplify the maintenance of the scripts. eCATT automatically creates a new session. and the dialog box automatically recognizes the values of this newly created session. For this purpose. it is therefore sufficient to confirm with Yes.Testing Transactions with Controls 6. Then execute the script. At the beginning of a recording. An important aspect is that SAPGUI commands recorded as of the basis release of Web AS 6. You may need to truncate commands or temporarily mark them as comments. search for “Initial State Recording”.40 can be extended at a later stage. Session ID and connection ID Values are Automatically filled Select »Yes« to Record the New Session Figure 6. More detailed information about this can be found on the SAP Service Marketplace1. Editing SAPGUI commands 193 . To extend a script you first need to ensure that it ends where you want to insert the extension. there are a number of functions for revising SAPGUI commands that have already been recorded. Ensure that the Do Not Close Created Sessions option has been selected in 1 See the SAP Service Marketplace. select the session to be recorded. In addition to improving the usability.20).5 6.

This ensures a better overview.2 CHEGUI. The existing script is extended by adding the new steps. GETGUI Reading and Checking GUI Elements There are separate commands for reading and checking values from GUI elements as of the basis release of Web AS 6. CHEGUI enables you to directly compare a GUI element to a planned value. You can choose between Transaction change Dynpro change Dialog step Methods/Property With the basis release of Web AS 7. This is very useful for inserting CHEGUI/GETGUI commands at a later stage and improving the readability of the script. e. highlight the relevant command. From the menu.5. A number of new SAPGUI commands is created the command interfaces of which store the same actions as the highlighted command. Open the context menu. select the Join item. and its command interface comprises the actions of all highlighted commands. As soon as the session has reached the appropriate state. Split functionality divides an SAPGUI command into several commands. you can split in any place.40. Splitting SAPGUI commands 6. highlight them and open the context menu. return to the script editor. The old commands are marked as comments. From the Pattern dialog.0. To split a long SAPGUI command. the end of the existing part of the script. you can split commands to specified granularities. but is even more important in a re-recording. and the command needs to be truncated in a specific defined place.40. A new SAPGUI command is created. GETGUI transfers the value of a GUI element to a parameter. Joining SAPGUI commands To join SAPGUI commands. when a part of the command needs to be newly recorded.6 Test Automation with eCATT the script execution dialog. i. and select the Splitting AT submenu. select SAPGUI (Attach) and execute the script recording as usual. The highlighted command is marked as a comment. The function of splitting or joining SAPGUI commands after the recording has also been added to the basis release of Web AS 6. With the basis release of Web AS 6.40. This 194 .

Return to the recording dialog box (see Figure 6. The easiest way to do so is to insert it during the recording. particularly because the number of required parameters can be reduced. like list fields. When checking complex calculations. Click on the field the value that you want to read. After selecting the corresponding field you are brought to the dialog for editing the GETGUI/CHEGUI command (see Figure 6. Read Value Check Value Confirm Figure 6. After you click on the button. For some other screen elements. the SAP GUI is in selection mode. for example.5 parameter can then be transferred to subsequent commands in the script or to other scripts. Selection mode 195 .22). scripts become clearer with many simple checks if you use the CHEGUI command. this is the Text property to be found under Get/GeneralState/Text.21) and insert the command using the Insert GETGUI Command button. it often makes more sense to first store the values to be checked in parameters and then process their contents. you must decide which of these properties you want to check. Usually. however. the input value is named Value and can be found in the same place.21 Recording Running Dialog Box There are two possibilities of inserting a GETGUI/CHEGUI command. For text fields.Testing Transactions with Controls 6. Because every screen element contains quite a number of properties. Usually this is the input value of the field. This means that a screen element is highlighted as soon as you place the mouse over it.

If you select several conditions within a CHEGUI command. This enables you to cover several test variants with different 196 . confirm with Insert and Continue. confirm with Insert and Exit.22 Dialog for Editing a CHEGUI/GETGUI Command In some situations it might make sense to check the availability of a screen element before it is accessed. Flexibility of the recording There are several possibilities for flexibly designing SAPGUI commands. there is an Available property. The fixed values used in the conditions can be changed at a later stage or replaced with parameters. For this purpose. and select more fields. Checking several conditions Within a CHEGUI statement. you can check several conditions. The conditions are therefore implicitly connected via and. This property is available only at runtime.9.6 Test Automation with eCATT Select Field Here Confirm and Extend CHEGUI Command Confirm and Complete CHEGUI Command Figure 6. the command is successful only if all specified conditions are met. The conditions for the checks are stored in the command interface of the CHEGUI command. More information about checking results can be found in Section 6. To conclude the CHEGUI command. Otherwise it has a value of “ ” (space). For this purpose. It has a value of “X” if the screen element is accessible.

When processing a script using SAPGUI commands. this part of the script is skipped. You can also set the editing of a dynpro to optional.3). Otherwise. g. The common use case of this option is to handle popup windows in the script that. For this purpose.Testing Transactions with Controls 6. Section 6. depending on the input data or context.23 Command Interface of the CHEGUI Command You can create more complex constructs to cover alternative paths using a dynpro. select a fine granularity for the recording.5 details in a single test script. are either displayed or not (see Figure 6.23). Method.24 Start Options for Executing SAPGUI Commands 197 . The dynpro is edited only if it is displayed by the application.24). you are provided with separate SAPGUI-specific start options (see Figure 6. Condition 1: Value 1 = LH Condition 2: Value 2 = 400 Figure 6. set the ProcessedScreen[n]\Active value from “X” to “O” for optional. In the command interface of the SAPGUI command. Start options for the SAPGUI driver Figure 6.9. and then toggle between different SAPGUI commands using conditionals (see the IF command. e.

This 198 . This option can be very useful for debugging scripts. The Stop When option causes eCATT to interrupt the script execution in specific places. The Error Mode for SAPGUI option controls the behavior of eCATT in the case of an error. The Minimize eCATT GUI option minimizes the SAP GUI window running eCATT to an icon on the task bar. Synchronous GUI Control Bypasses the Automation Queue and Sends GUI Updates Directly to the Frontend Use this option if you want to trace the progress of the script on screen.13. This is useful if you encounter difficulties with opening a new session due to a stored limitation of the number of sessions (default: 6). However.6 Test Automation with eCATT The option Execution of All SAPGUI Commands in a Single Session per Destination causes one session to be used per destination (target system). you should therefore select the synchronous GUI control presented below. If you additionally enable Stop in Debugger. This option is particularly useful during the script development phase. The following modes can be selected: Optimized Performance In this mode. The Processing Mode for SAPGUI option is a performance parameter. If the Highlight the Called GUI Elements option is enabled the active screen element is highlighted with a red frame while the script is being executed. on the other hand. the eCATT script switches to the debug mode whenever it is interrupted.00.25). More information can be found in Section 6. The Close GUIs enables you to automatically close the modes that have been automatically created during the script execution. On the one hand. Screenshot functionality As of basis release Web AS 7. the functionality for automatically creating and saving screenshots is provided (see Figure 6. It is not continued until the user confirms it. the GUI updates are processed via the automation queue. not all of the interim steps of the script might be displayed correctly. The selections are self-explanatory. If the execution of a script is to be traced on screen. this increases the performance.

It may make more sense in such a case to use the SAPGUI driver even for recording a transaction without controls.25 Screenshot Options in the Start Options To enable the functions for automatically creating screenshots. For reading and checking values. although it can be corrected at a later stage in more recent eCATT versions.Testing Transactions with Controls 6.bmp format. 199 . In an environment requiring validation you should consider this when you select the test driver. The screenshots are saved in . The screenshot options are displayed. However. The specification of the granularity level defines for which application events the screenshots are to be created. for example. the GETGUI and CHEGUI commands are available. Enable Screenshot Function Specify Granularity Specify Directory (on Frontend) Figure 6. Specify the granularity and a directory where the screenshots are to be stored. in the start options select the Save Screenshots option. Conclusion Transactions with controls can be recorded using the SAPGUI driver. Because the functionality for automatically creating screenshots requires the availability of a user interface.3 for more information about message handling within the SAPGUI driver. Please refer to Section 6.5 functionality was designed primarily for covering the documentation requirements in an environment where validation is mandatory. it is only available for the SAPGUI driver. a sequence of screenshots can also be useful for tracing the individual steps of test runs for troubleshooting purposes. The selection of the correct granularity is very important in this context.9. even though you would normally use the TCD driver due to its better maintainability and performance.

Communication takes place via the XML client of the Web Dynpro Runtime (WDR) (see Figure 6. However.6 Testing Web Dynpro Applications With the basis release of Web AS 6. if necessary. Smart Client Callback XML Client Web Dynpro Runtime (WDR) eCATT Plug-in Simulator Simulator eCATT SAP Web AS Browser Request User Figure 6.27). the eCATT plug-in in the Web Dynpro runtime environment extends the application so that the browser also sends specific control data for eCATT in addition to requests to the application. Communication while recording When a Web Dynpro transaction is recorded. eCATT supports the direct testing of Web Dynpro-based applications.26 Recording Web Dynpro Commands Communication while processing While transactions are processed.6 Test Automation with eCATT 6. Using the simulator.27 Processing a Web Dynpro Transaction 200 . Both Web Dynpro for ABAP and for Java are supported.40. you can trace the processing of the transactions on screen.26). Response Request Figure 6. This client receives requests from the Web Dynpro simulator and responds to them. the situation is less complicated. the user handles the application via the browser as usual (see Figure 6.

for ABAP applications you should create an HTTP connection to the R/3 system (connection type H). there have been sporadic problems with the DNS resolution of the target system. insert a logical target in the system data container.28). In the http Destination column.Testing Web Dynpro Applications 6. the extension has the following format: <Java URL extension> = sap/bc/webdynpro/sap The first step for recording a Web Dynpro-based application is the creation the targets for the HTTP connections. the extension is: <ABAP URL extension> = webdynpro/dispatcher If the WDR is based on Java. As soon as you have created and successfully tested the HTTP connection. Depending on the system setup. Creating the connections 201 . store the newly created connection for this target system. Note the different prefixes for Java and ABAP applications. The URL extension looks different depending on whether the Web Dynpro runtime environment is based on the Java or the ABAP stack. If you are using the ABAP stack. Enter hostname and port of the target system as well as a path prefix (see Figure 6.6 The URL for addressing the Web Dynpro application is structured as follows: HTTP://<Server>:<Service>/<URL extension>/<Application> Structure of the URL The meaning of server (name or IP address) and service (port) is expected to be known. Use Transaction SM59 for this purpose. Java-based applications require an HTTP connection to an external server (connection type G). If you have difficulties establishing an HTTP connection. first try storing the IP address of the target system in the Target Host field instead of the host name.

Select a target system (the target system with the HTTP connection you previously created).6 Test Automation with eCATT Name of the Connection Server Name (or IP) Port Path Prefix Figure 6. and from the UI Control group select the WEBDYNPRO command. Select Pattern. A dialog box for specifying the Web Dynpro application is displayed (see Figure 6.28 Creating a Connection in Transaction SM59 Recording Web Dynpro transactions To record a WEBDYNPRO command. go to the script editor. Note that usually the Web Dynpro target system is not the same as the target system for the SAP GUI recording.29).29 Start the Web Dynpro Recording 202 . Target System (Web Dynpro System) Application Aufzeichnung Start Recording Figure 6.

Click on the Start Recording button. As soon as you start recording. you operate the application as usual and populate the dialog elements with values.31).31 Dialog Box for Stopping the Recording 203 . complete the basis URL of the connection with an application-specific part. Stop Recording Here Figure 6.30 Browser Window with Web Dynpro Application During the Recording At the same time. another window opens and indicates that the recording is running (see Figure 6. Your input is recorded and is later available in the command interface of the WEBDYNPRO command (see Figure 6. In this browser window. Web Dynpro Application in the Browser Operate Application as Usual Figure 6.30). eCATT automatically opens a browser window containing the Web Dynpro application.6 In the Application input field. The address parts are then merged by eCATT. This part depends on the application to be recorded.Testing Web Dynpro Applications 6.

Like with an SAPGUI command. you can parameterize the recording to link the Web Dynpro command to the test data.6 Test Automation with eCATT As soon as you have stopped the interaction with the Web Dynpros. The target system must be an HTTP connection of the G type (for Java Server) or the H type (for ABAP Server).. As of the basis realease of Web AS 7. The script editor displays a new command: a WEBDYNPRO statement. You have the following options: If you select the Process in Background option. the start options are limited to the selection of the processing mode.9.0.32 Command Interface of the Web Dynpro Command Messages Messages sent during the recording can also be found in the command interface under the PAGE/ SCREEN/MESSAGES node. Structure of the Web Dynpro Application Parameterize Here Figure 6. ENDMESSAGE block as well (see Section 6. you can process messages from Web Dynpro applications via a MESSAGE . Open the command interface of the command and search the values input during the recording under SCREEN DATA. use the task bar to change to this window and stop the recording. WEBDYNPRO The WEBDYNPRO command is designed for addressing the Web Dynpro driver. [<Target system>] ).. The progress of Start options for the Web Dynpro driver 204 .3). It has the following notation: WEBDYNRPO (<Command interface>. the script is processed without being displayed in a user interface. If you use the Web Dynpro driver.

this option is very helpful for the troubleshooting process during the script development. and Security). The necessary ABAP proxy classes are generated automatically. this ensures the best performance. With the basis release of Web AS 7. first generate an HTTP connection using Transaction SM59. eCATT supports the automated testing of web services.7 Testing Web Services The SAP Web Application Server enables enterprises to extend their solutions by integrating web services and providing them to their users. Because the functionality of the eCATT web service driver is not limited to testing web services provided via the SAP Web Application Server. A web service is then called like an internal ABAP function module. SOAP (Stateless. the recording takes place in parallel while the browser is being operated by the SAP application. you can integrate it seamlessly in the test coverage via eCATT scripts.0. As long as the third-party system in your process chain has a web service interface. Conclusion Web Dynpro applications can be recorded just like SAP GUI transactions. Testing third-partysolutions 205 . click on the Pattern button and from the Enterprise Services category select the WEBSERVICE command. The URL is opened automatically in a browser. However. It supports the XML. 6. Then in the eCATT script editor.7 the script cannot be traced on screen. Stateful. WSDL and UDDI standards. To test a web service. you indirectly obtain an interesting alternative for testing third-party solutions. Due to its possibility of comparison. The Process in Foreground option (display recorded page in parallel) causes the progress of the test case in the application at the time of recording to be displayed in a second user interface in addition to the actual script.Testing Web Services 6. the progress of the script is displayed in a user interface. If you select the Process in Foreground option.

Otherwise. you need an ABAP proxy object. you will want to obtain the description directly from the used server. Instead. eCATT queries the capabilities of the web service and generates an ABAP proxy class with appropriate stub methods. click on the Generate Proxy Class button. 206 . The WSDL description (Web Service Description Language) specifies the functions provided by the service. Usually. enter a URL where a web service description can be found. You need to assign the class to a package. If the web service is implemented on an SAP Web Application Server and you know upon which ABAP class it is based. In that case. In the WSDL URL for Web Service Definition field.33 Insert the Web Service Test ABAP proxy objects and WSDL For this purpose. This provides you with the stubs of the web service methods. no recording occurs in this place. This generated class is entered directly in the ABAP Proxy Class field. you specify a method call that is submitted to the web service. Web Service Driver Server URL Select Method Generate Proxy Class Automatically Figure 6. you can select the corresponding ABAP proxy class from the directory. eCATT supports you by automatically creating an appropriate ABAP proxy class.6 Test Automation with eCATT Because web services are function-like objects that do not allow for direct user communication. the URL normally uses the following format: HTTP://<Server>:<Port>/ <Web Service Name>/Config?wsdl As soon as the correct address for the service description has been entered.

Web Service Command Parameter of the Web Service Method Output of the Web Service Method Figure 6. addressing a web service is just as simple and comfortable as calling a function module. The WEBSERVICE command is used for addressing web services. Integration of Web Dynpros and web services Conclusion The web services test is fully supported and integrated with eCATT in the basis release of Web AS 7. Therefore you do not need to worry about the structure of the transferred parameters. and close the dialog box. [<Target system>] ). this results in very elegant possibilities of testing modern service-oriented solution landscapes via different forms of access. Usually. it is generated automatically from the WSDL. a data record can be entered via an automated Web Dynpro transaction to check the correct update of the data in the test system via an appropriate web service call. It has the following format: WEBSERVICE(<Command interface>. Just populate the command interface with appropriate values.7 Once you have a functioning proxy class you can select the visible methods of the class in the ABAP Proxy Method field. Select the wanted method from the list. In combination with Web Dynpros.Testing Web Services 6.0. Due to the automatic generation of ABAP proxy classes from WSDL descriptions. eCATT then generates a WEBSERVICE command in the script editor. WEBSERVICE The command interface corresponds to the interface of the selected function from the ABAP proxy class.34 Command Interface of the WEBSERVICE Command An interesting application scenario is created when web services are tested that are integrated with Web Dynpro-based transactions. This enables a continuous test of service-oriented solution landscapes. 207 . For example.

business processes can be essentially tested automatically with eCATT. and consistent data storage even for the integration of external tools. This ensures a central. For this purpose. 2.8 Integration with External Tools The driver for external test tools plays a special role among the eCATT test drivers. An external tool is a program that uses the implementation of the BC-eCATT interface to interact with eCATT. BC-eCATT Such an external test tool must be installed on the frontend to be tested.6 Test Automation with eCATT eCATT Script Create Booking Import Export SAP Web AS Web Dynpro Driver Document ID Web Dynpro Transaction Document ID Script Cancel Booking Import Export Database Web Service Driver Document ID Web Service Figure 6. continuous. A recording using an external tool takes place as follows: 1.35 Example of a Test Scenario with Web Dynpros and Web Services 6. Recorded scripts are transferred via BCeCATT and stored in the central repository like native eCATT scripts. the tool is addressed by eCATT via the BC-eCATT interface. and registered in the backend. Recording 208 . e. 3. eCATT starts the external tool. the user stops the recording and selects the Save and Return to eCATT option. i. The user starts the recording in the external tool. After the interaction with the application to be tested is completed. In heterogeneous solution landscapes. the recording and processing of user interactions is controlled via the external tool. The external test tool then covers those process steps the UI of which is not a SAP GUI for Windows or a Web Dynpro. The work process. The external program works as an adapter to the software to be tested.

45 Accelerator 47 Active Global Support 76 allow (message) 218 Anonymization 255 ASAP (AcceleratedSAP) 43 ASAP process model 44 Authorizations 58 D Data analysis 292 Data Dictionary 257 Data reduction 254 Data transfer 259 Database overview 353 Database time 351 Degree of test coverage 273 Developer test 32 Document management 80 Dynpros. optional 197 B BC-eCATT 208 Black box 35 Boundary value analysis 39 Business blueprint (project phase) 44. 86 Cookies 310 Coverage Analyzer 269 CPU time 351 CPU utilization 357 Customer development 272 F fail (message) 218 Filter 217 Final preparation 45 Final preparation phase 61 Full copy 254 Function modules 248 Functional tests 246 G GoingLive Check 318 Go-live and support 45. 82. 247 CHEVAR 214.Index A AcceleratedSAP 43. 67 H History 113 Hit ratio 352 365 . 96 E EarlyWatch Alert 75 eCATT 171 Equivalence class partition 37 Error guessing 40 Error management process 54 Error recording 111 exit (message) 218 expected (message) 218 C CATT 235 Change request 122 Change request management 76 Collaboration platform 74 Command (eCATT) CHEGUI 195 CHETAB 225. 247 DO 221 GETGUI 194 GETTAB 225 IF 221 MESSAGE 216 REF 232 REFCATT 235 REFEXT 210 SAPGUI 190 TCD 183 Components. 51. logical 85.

48. forgotten 298 S Sample test 274 Sanofi Aventis 311 SAP Quick Sizer 289 SAP Solution Manager 43. 125 RFC connection. 82 Refreshing the test system 260 Regression test 34. 112 Service Level Agreements 75. checking 224 Template project 87 Test case attributes 54 Test case description. virtual 306 R Realization (project phase) 44. 88 Proxy. trusted 176 Risks 279 Roadmaps 45 Rule 217 K Knowledge Warehouse 80. 55. 127 SAP Test Data Migration Server 253 Service Desk 77. digital 80. 101 L Load test 281 Lock 349 Lock entry list 349 Locks. 61 Reload 352 require (message) 218 Retest 123. missing 298 Input data combinations 36 Integration test 33 Interfaces 248 Internet-enabled household appliances 126 Project types 87. 103 Single-user test 297 SM66 350 Snapshot technology 258 Solution landscape 83 SQL trace 355 Standard reports 114. 312 Process analysis 286 Processing blocks 269 Program buffer 352 Project preparation (project phase) 44. 82 Project structure 96 T Tables. 280 Session ID 309 Signature.Index I Implementation project 87 Index. 115 Status analysis 114 Status assignment 110 Swap memory 358 Synthetic test data 246 System failure 279 System Landscape Directory 84 System monitor 356 System test 33 System. automated 100 366 . non-production 257 M Maintenance project 87 Message processing 121 Message recording 120 Monitor 341 Multi-user test 297 N Negative test 213. 223 NetWeaver Portal 312 O Operation 75 P Performance test 279 Popup window 197 Portal 306.

88. 96 SOLAR02 44. 108 Test plan 105. 114. 103 SOLAR01 44. 181 SM12 349 SMSY 44 SOLAR_EVAL 45.Index Test case description. 94 Test systems 58 Test tools 50 Test-end criteria 54 Testers 57 Testpartner 211 Trace analysis 354 Traffic light icon 110 Transaction SECATT 121. 98 ST02 352 ST04N 353 ST05 354 STAD 351 STWB_2 105. 118 SOLAR_PROJECT_ADMIN 44. 109 STWB_Work 114 Transaction analysis 351 U Upgrade project 87 User acceptance test 34 V Variant external 230 manual 226 Visibility 185 Volume test 281 W White box 35 Work packages 47 Work process 350 Z Zürcher Kantonalbank 245 367 . 63. manual 98 Test case template 53 Test catalog 78 Test concept 48 Test configuration 226 Test coverage degree 56 Test data 59 Test data container 227 Test documentation 110 Test drivers (eCATT) 173 Test execution 109 Test focus 63 Test notes 111 Test package 105. 116 STWB_INFO 116 STWB_SET 95 STWB_WORK 108. 107 Test report 116 Test reporting 54 Test scope 273 Test series 95 Test standards 52.

Sign up to vote on this title
UsefulNot useful