You are on page 1of 3

Component-Based Test Automation (CBTA)

Use

Component-based test automation (CBTA) allows you to create automatic tests.

An automatic test is made up of a test script that includes components. There are two kinds of
components: default and screen components:

 Default components perform basic actions like clicking on a button or selecting a tab. They
are delivered in the SAP Solution Manager system. For more information,
see https://wiki.scn.sap.com/wiki/x/OhdQGg .

 Screen components are generated for either SAP GUI transaction screens or SAP CRM
Web UI views. Web Dynpro ABAP application views are supported, but only in native mode, not
when embedded in the portal. They are created with a parameter for each field on the screen. The
value of a parameter is given to the corresponding field during execution. Screen components are
generated automatically at the end of a test recording.

There is only one screen component per SAP GUI transaction screen, SAP CRM Web UI application
view, and SAP Web Dynpro application. And there is only one screen component per logical
component to ensure that the tested application is of a dedicated version. So a screen component
can be shared among several tests.

Use the Solution Documentation application to create and maintain test configurations. The test
scripts created with the CBTA tool are compatible with the eCATT framework.

Integration

 SAP Solution Manager: Store data required to create, optimize, and maintain tests and
components.
 Test composition environment: Create test configurations and test scripts recorded with
CBTA. For more information see Test Repository

 Test plan management: Schedule the execution of tests.

Features

 Recording tests scripts ( SAP S/4 HANA support improvements)

 Quick repair: Continue previous recording.

 Cross technology recording in one session (ex: start with CRM and continue on SAP UI5...)

 Record multiple SAP SUI windows

 Record embedded HTML into SAP GUI transaction

 Record IE: SAP GUI continues recording

 Include one CBTA script into another CBTA script (modularized some action like a test step )

 Easy maintenance ( default/screen component concept, mass update of control identifier in


all test scritps,…)

 Managing test configurations with shared components.

 Managing screen components and their parameters.

 Using the test data container (TDC) to define several sets of data.

A CBTA test is an eCATT test so it can use the eCATT features. The object structure is defined as
follows:

 The solution documentation references test configurations to test selected executables.

 The Test Repository - Test Scripts and Test Repository - Test


Configurations applications lists all existing test configurations and test scripts.

 A test configuration includes the following assets:


o A system data container (SDC) to define on which system the test recording and
execution are performed. There is only one SDC attached to a solution. In this scenario, the SDC is
automatically generated with the same name as the solution, prefixed with the character Z.

o A test data container to define different sets of data to provide the input parameters
for the tests.

o A test script which includes the following:

 The executable object that defines the transaction, program, or URL for the
test. It is linked to a logical component group, as defined in the related solution landscape.

 A test profile that defines which business user is to be used for recording and
execution. It is defined in the SUT Management application. For more information, see SUT
Management.

The steps of the automatic tests, for example, clicking a button, selecting a tab, or entering data in
an input field.

You might also like