Show TOC

Procedure documentationCreating Test Profiles and Logon Data for SUTs

 

In the system data container (SDC), you define the access information for the systems under test (SUT). These are the systems in which tests are recorded and executed. This requires RFC and HTTP destinations, user names, and passwords.

In the test composition environment (which is accessible when you edit a test configuration in the Test Repository - Test Configurations application), the test profile associates a user and password with a test script. It allows you to reuse combinations of destinations and users for different system roles. When you change the system role, depending on the type of definition, the credentials can be role-dependent or role-independent.

Basically, a test profile is a name that is associated to a user name and password. In the editor of the test repository, a test profile is assigned to a test script.

In the SUT Management application you can define test profiles. They can be defined per SDC, target component, logical component, and system role. In case of component-based test configuration (CBTA), test profiles are defined along with a technical RFC destination that is used at recording and execution time to retrieve technical information from the SUT.

Note Note

Test profiles have the following advantages for your testing environment:

  • With test profiles, you can make the system role concept available also for HTTP destinations and URLs.

  • You do not have to define a separate RFC destination for each business user of your test.

  • Reliable SUT identification: In previous releases, the technical destination was determined at runtime, from the SDC target component in the scenario. The SUT Management application establishes a direct link between a SUT and its technical destination. This increases robustness and ensures that an SUT is identified reliably and attributes are received, for example, to open session or create screen components. By default, the technical destination TST_<SID>_CLNT<CLNT> is created in the CBTA configuration scenario of SAP Solution Manager.

  • Reduced maintenance effort: Business RFC destinations are no longer required. SUT management provides the business user IDs and credentials for CBTA scenarios. Dedicated RFC destinations for each user are no longer required, and business users no longer require technical authorization.

  • Manage business user passwords at one location: Business user IDs and their passwords only need to be maintained in SUT management, no longer in both the RFC destinations and the secure password store.

  • Switch target components for non-RFC-based UI technologies: In SAP Solution Manager, you can define SDC target components using logical component groups. The logical component groups can switch the target system by changing the system role in the SUT management. (Previously, this was only supported by systems accessed by RFC destinations). Also in technologies such as SAP Portal or HTTP destinations, you can switch the target system by changing the system role.

  • Test profiles are also used by eCATT-based test scripts, including third-party tool tests and composite tests. This kind of test profiles allows to define a business RFC destination to be used at recording and execution times. In this case, the user and passwords are not defined in the SUT Management but ruses those from the business RFC destination are used.

End of the note.

Prerequisites

Procedure

Accessing SUT Management

There are three ways to access the SUT Management:

  • In the Solution Documentation application, select a solution and branch and navigate to the test cases and open or create the test configuration. In the editor, choose Start of the navigation path Goto Next navigation step SUT Management End of the navigation path.

  • In the Administration - Test Suite view, choose Start of the navigation path Test Automation Framework Next navigation step System Under Test Management Next navigation step Maintain SUT Systems End of the navigation path.

  • In the Test Repository applications, edit or create a test script or test configuration. Choose Start of the navigation path Goto Next navigation step SUT Management End of the navigation path.

  • In SAP Solution Manager Configuration (transaction SOLMAN_SETUP), choose Start of the navigation path Test Suite Next navigation step SAP Solution Manager Next navigation step Component-Based Test Automation Next navigation step Configure System Under Test End of the navigation path.

Displaying the Technical Destination in the Original or the Enhanced SDC

CBTA is integrated in the test suite, so the target component in the SDC is the starting point to determine the connectivity to an SUT.

Note: See Defining System Data Containers later in this document, to avoid unnecessary re-work.

When you open an SDC in transaction SECATT, the list of target components (also known as target systems) is displayed. Each one has a logical component group as defined in the solution documentation and selected in the context of the current user. This context is accessible from transaction SECATT, when you maintain and SDC, in the menu under Start of the navigation path Utilities Next navigation step Settings End of the navigation path. It contains the following:

  • Solution documentation

  • Branch

  • System role

From the target component, the referenced logical component group is displayed, for which the relevant logical component is shown. This logical component is derived from the branch of the user context, as defined in the solution documentation.

Finally, from the logical component and the system role of the user context, the RFC destination is derived and displayed.

This chain of dependencies allows the user to know which SUT is used depending on the target component that is selected in the test, but also depending on the user context settings.

Caution Caution

Do not edit the SDC. It is automatically generated and adapted when the logical component group is changed in the solution documentation. The name of the generated SDC is the same as the solution name, prefixed by the character Z.

End of the caution.
Migrating User Data from Previous Version of CBTA 3.0

Use the guided activity for migration in SAP Solution Manager, especially the second guided activity, step 8. For more information, see Migrating User Data to CBTA SUT Management.

Defining an SDC Enhancement for the Target Component

Depending on the UI technology of the SUT, define a technical destination for your target component.

Selecting the SDC enhancement target and type

  1. In the SAP Solution Manager launchpad, choose Start of the navigation path Administration - Test Suite Next navigation step Test Automation Framework Next navigation step System Under Test Management Next navigation step Maintain SUT Systems End of the navigation path.

  2. To import a new SDC, choose Import.

    In the popup, search for the required SDC and validate.

    Once you have imported an SDC into SUT management, CBTA only uses the RFC destination that is defined in the test profiles of SUT management, for the technical communication between the SAP Solution Manager and the SUT.

  3. The definitions of all imported SDCs and target components (target systems) appear in the navigation tree in SUT management.

    The data is displayed hierarchically:

    • Level 1: SDC

    • Level 2: SDC target component (also known as SDC target system). This corresponds to one logical component group.

    • Level 3: logical component

    • Level 4: available system roles

    Navigate to the target component. Drill down and select the system role you want to enhance.

    The available enhancements are displayed as tab pages. The available system roles are listed when they are relevant, depending on the type of objects in the target components: Select the system role and the existing configuration is displayed.

  4. Choose Edit.

  5. Create a test profile, depending on the SUT type.

    The test profile is used in the test repository, to associate a test script with the user, password, and system information. For more information, see Maintaining SAP Attributes on the Attributes Tab Page and Executable Types.

    Note Note

    With SUT Management, an entry in the hierarchy, is associated to the following information:

    • For an RFC-based SUT for CBTA tests:

      • Technical RFC destination for which the name is defined like TST_<SID>_CLNT<Client>. Note that there are only two underscore characters (_). Example: TST_YA3_CLNT800

      • List of test profiles with a test profile (simply a name), user name, and securely saved password.

    • For an RFC-based SUT for other eCATT tests:

      A list of test profiles including a test profile name and a business RFC destination that is used to identify the SUT but also the user and password.

    • For an SUT accessed via URL:

      A list of test profiles including the following:

      • Test profile name

      • Either a base URL with protocol type (http:// or https://), server name, optional port and base query string,

        or an HTTP destination name as defined in SM59. This destination must contain information similar to that for a base URL.

    End of the note.

  6. To select the SDC enhancement type, choose the related tab page. There are two different types of enhancement definitions: SAP ABAP Backend or URI-based SUT.

    • For all SAP ABAP-based systems, create SDC enhancements on the SAP ABAP Backend tab.

    • Configure URI-based enhancements only if a system cannot be accessed by RFC. Because in URI-based configurations, you cannot retrieve system attributes for the creation of screen and view components, for example.

    Caution Caution

    Except for dual-stacks, define entries for a system role on only one tab page, either for SAP ABAP backend or for URI-based SUT. The ABAP stack requires an RFC destination, otherwise the system attributes are not available and tests are only executed with default components. When you define an SDC enhancement for SAP ABAP backend, Web Dynpro, CRM Web Client, Web GUI, and BSP, URLs are created automatically depending on the executable object in the test script.

    End of the caution.
Creating SDC enhancements for SAP ABAP-Based systems

  1. In the SUT management, choose Edit.

  2. Enter the name of the technical destination. (You have created a valid technical destination (with the naming pattern TST_<SID>_CLNT<CLNT> under Start of the navigation path SAP Solution Manager Configuration Next navigation step Test Suite Next navigation step CBTA End of the navigation path.

    Note Note

    You can only select TST* as destination. These destinations are created during the setup of CBTA in SAP Solution Manager Configuration (SOLMAN_SETUP).

    End of the note.

    RFC destination names are case-sensitive.

  3. To execute the destination check, under Technical Destination, choose Check.

    Note: The destination check only verifies whether the technical destination and its user can access the SUT, not whether the authorizations are sufficient for a certain UI technology.

  4. Under Business Destination Enhancement Details, enter a valid user and password.

    You can define enhancement entries with and without test profile names. An entry without a test profile name is called DEFAULT and is used automatically in test scripts with no test profile. It ensures that test scripts that are created with CBTA prior to 3.0 SP02 can be executed without modification.

  5. To check the business user credentials, select the new entry and choose Check.

  6. Save your entries.

  7. Repeat the process for each system role for the test.

    If you want to execute a test script with a certain test profile on different systems by changing the system role in your user context, define the test profiles in different system roles, and with the same name. So you do not need to update the test script when you change the system role.

The next time you create a test script, the target is retrieved by SUT management. You may need to refresh the view to see a newly added enhancement.

The original eCATT SDC remains unchanged.

Creating SDC enhancements for URI-based systems

  1. Choose the URI-based SUT tab page, and choose Edit.

  2. Add a new table line.

  3. In the Connection Type field, select the URI type.

    • If you choose BASE_URL, enter the base URL in the Connection URI field, in the format http://<hostname>:<port>.

    • If you choose HTTP_DEST, enter the name of the HTTP destination in the Connection URI field, which you created in transaction SM59. This HTTP or HTTPS destination contains the base URL, containing the target host and service number, and optionally the path prefix. For information about creating URI-based SUT entries, see Executable Types.

  4. Select a test profile name, or leave the Test Profile field empty, to create a default test profile.

  5. If required, enter user and password.

  6. Save your entries.

  7. Repeat the process for each system role for the test.

Details On the Determination of System Roles

In ABAP backend systems, logical components groups allow you to switch target SUTs by changing the system role. SUT management uses this to enhance the system roles in the logical component group.

SUT management supports enhancement definitions for the system roles, such as development, quality, and pre-production system.

We link entries in SUT management to the roles in the logical component because in integrated scenarios, the underlying RFC destinations of the original SDC are used, for example when the system creates TBOM traces. So the TBOM creation still uses the RFC destination defined in the SDC. And for TBOM creation, the RFC destination stored in SUT Management must refer to the same system as the RFC destination of the SDC does. For more information, see the section Defining System Data Containers for ABAP SUTs.

You could not switch the target system by changing the system role for URI-based SUTs in CBTA prior to 3.0 SP02. This now possible in SUT Mangement, which lists all existing system roles that you can enhance.

Defining System Data Containers for ABAP SUTs

To avoid inconsistencies in integrated scenarios, for example in TBOM creation with CBTA, the SDCs are now generated automatically from the solution documentation. All target components of the SDC that are linked to the solution, refer to one logical component group.

The name of the generated SDC is the same as the solution name, prefixed with character Z.

Using Test Profiles

Test profiles are used in CBTA test scripts. A test profile is an identifier that defines the following:

  • The SUT, which is connected by the technical RFC destination if it is an ABAP backend system, and by the URI if it is a system of a different type.

  • The business user ID on which scenarios are to be processed, and a password. The definition is mandatory for ABAP-based SUTs and optional for URI-based SUTs.

Test profiles are identified by a string of up to 32 alphanumeric upper-case characters. Spaces and special characters are not allowed. A test profile is valid for the system role of the SDC target component for which it was defined in the SUT management.

Recommendation: In SUT management, use the same test profile ID for different system roles of your SDC target component. So you can execute the test script on different SUTs, by only changing the system role and without further modification. If the test data on those different SUTs is not identical, define a test configuration that refers to test data containers for the different SUTs, and select the test data container that corresponds to the selected system role (target SUT) manually.

Note: The warning message No default profile defined appears when you define a test profile with a test profile name, without having defined a test profile without a name, which is the DEFAULT test profile. The name of this default test profile is empty:

A DEFAULT profile is used in test scripts that are not assigned to the test profile, to ensure backward compatibility of tests that were created with CBTA prior to 3.0 SP02. It is not mandatory to create such default profiles, but it is recommended.

Updating an SDC after changing the original SDC by synchronization

If you have changed the structure of the original SDC (that is, when you added, removed, or changed a logical component group in the solution documentation), synchronize the previously imported SDC. Otherwise, the test can no longer be executed. The synchronization logic is as follows:

  • If you added target components to the original SDC or maintained further system roles in a logical component group, the new definitions are added, and the synchronization does not have any impact on existing SDC enhancement entries and their usage.

  • If you deleted target components from the SDC, the effects depend on their usage:

    If you defined an enhancement that is not yet used in test scripts, it is deleted.

    If you defined an enhancement that is used in test scripts, the dialog box informs you about the broken test scripts. From the dialog box, go to the test scripts by link and repair them.

To update a previously imported SDC in the SUT management, select the SDC to be updated. Choose Synchronize. If tests are broken due to the change, a warning popup displays links to the affected test cases.

Note: If a target component was deleted from the original SDC, the test scripts are already invalid when the original SDC is modified, it is not the synchronization that breaks them. So the purpose of the warning popup is to indicate tests that must be adapted anyway.

Executing a test script for systems with different roles

You can execute a test script for systems with different roles if, for example, you have an SDC target component that contains the development system and the quality assurance system of your SUTs.

Prerequisite: The same test data is available on both SUT instances, in the development and the quality assurance systems.

  1. Create test profiles with the same name but with the different roles of your SUT.

  2. Create a CBTA test script on the development system.

  3. Change the system role. Without changing the script, you have switched the target system on which the test is to be executed.