Search This Blog

Wednesday 9 September 2015

CBTA Test Planning procedure and Test Execution procedure using SAP Solution Manager



1.    Introduction


This guide describes the Test Planning procedure and Test Execution procedure using SAP Solution Manager

The procedures are part of the Test Planning and Test Execution processes in SAP Application Lifecycle;





The guide is for using Solution Manager as a tool – not a guide for the test strategy and test process.


Sunday 6 September 2015

Recording a Test Script Using Component-Based Test Automation

Recording a Test Script Using Component-Based Test Automation


To record transactions in SAP GUI or CRM Web UI systems and create automated test cases, you can use SAP Component-Based Test Automation.
You can create tests and components from the screens of a transaction, and parameterize them. These tests are for a single transaction and can be combined into a scenario test. You maintain the components in the Test Composition Environment.

Procedure

  1. Under Test Repository, choose the Test Scripts subview.
  2. Choose Create.
    A dialog box appears.
  3. Select CBTA as test tool and enter data as required.
  4. Specify the title, application component and system under test.
  5. Save your entries.
  6. Choose Start CBTA.
    A dialog box appears.
  7. Connect to the system under test.
    The Test Creation Wizard is started.
  8. Enter an analysis name. The recording is stored under this name and can later be used to generate another test script.
  9. To confirm, Choose Next.
    The executable is started. The Test Creation Wizard is in recording mode.
  10. Perform the business process.
  11. Optional: To add a checkpoint, in the Test Creation Wizard choose Add Checkpoint.
  12. To stop the recording, in the Test Creation Wizard choose Stop the PFA.
  13. Choose Next.
    The structure of the process flow is displayed.
  14. Verify that the business process is correctly and completely recorded, and choose Next to confirm.
  15. To create the test, select End the analysis and create the test, and choose Next to confirm.
    To cancel the recording, select End the recording without creating a test.
    The test components are uploaded to the Test Composition Environment.
  16. Choose Finish.

    Source: www.help.sap.com

Technical Bill of Materials (TBOM)

Technical Bill of Materials (TBOM)


A TBOM contains a list of all objects in an executable entity. These objects are, for example, elements of the user interface, module pools, function modules or tables.
These objects are assigned to a TBOM Enhancement. When a TBOM is created, the system creates a first TBOM enhancement which contains all objects in this initial recording. You can add any number of enhancements to a TBOM, increasing the list of relevant objects.
TBOM extensions can be generated dynamically or statically. For more information about the creation types, 

The Business Process Change Analyzer can use a TBOM to determine whether an executable entity is affected by a change (for example, by changed objects in a transport request).

Structure

Information About TBOM Enhancement
The following information is saved with every TBOM enhancement (you can view this information on the TBOMtab page in the Enhancements dialog):
  • Enhancement name
  • Enhancement type (dynamic, static, or automatic test case)
  • Logical component
  • Managed system name
  • Managed system client
  • TBOM enhancement status
  • Number of objects in the enhancement
  • Managed system product version
  • Managed system role
  • Created by and on/at
  • Name of the automatic test case by means of which the enhancement was created
The system also saves the following dates for each TBOM enhancement:
  • Creation date
  • Last change date
  • Date of last obsolescence check
These dates are used during the obsolescence check. Based on these dates, the system defines the scope of transport requests for which objects must be checked.
Information About the Objects Contained
The TBOM also contains the following information about the individual objects involved in the executable entity (you can view this information in the TBOM content display):
  • Program ID: ID of the object, for example, R3TR for complex objects such as programs and all related elements or LIMU for subobjects
  • Object type: Precise assignment of the object to a type, for example, REPS for Report Source, FUNC for functions, TABL for tables
    There are several hundred different object types.
  • Object name: Technical name of the object
Program ID, object type, and object name together uniquely identify the object.
  • Origin: Origin of the object
    • D for dynamically generated objects
    • S for statically generated objects
  • Classification type: Different object types are summarized to a classification type. The default assignment of classification types to object types is stored in the system.
    The following classification types have been predefined:
    • TABC = Table Class
    • UI = User Interface
    • TRAN = Business Transaction
    • FUNC = Business Function
    • DOKU = Technical Documentation Object
    • DDIC = Data Dictionary
    • AUTH = Authorization Object
    • CUSX = Customer Extension Points (EnhSpots)
    • MISC = other classification types
  • Classification values: Objects of classification type TABC (tables) are subdivided further using the classification value as follows:
    • A = Application table (master and transaction data)
    • C = Customizing table (entries and changes can only be performed by the customer, no SAP Import)
    • L = Table for storing temporary data (supplied blank)
    • G = Customizing table (new entries only from SAP, existing entries in the customer system are protected)
    • E = Control table (SAP and customer have own key areas)
    • S = System table (entry and changes can only be made by SAP, change = modification)
    • W = System table (content can be transported using own TR objects)
  • Package: Development class
  • Software component: Name of the application from which the object originates, for example SAP_BASIS.
  • Object type: Designation from the version database. Since reference objects are used there, the designation can deviate further from the object type mentioned earlier in some rare cases.
  • Object name: Designation from the version database. Since reference objects are used there, the designation can deviate further from the object name mentioned earlier in some rare cases.
  • Table key: When database tables are accessed, the values of the key fields used to access the tables are also entered in addition to the database tables. This enables the system the reduce the number of hits in the change impact analysis.

    Note
    Only the following table types can be accessed:
    • C = Customizing table
    • G = Customizing table
    • E = Control table
    • S = System table
    • W = System table
    Whether the system can record a key value for table access also depends on the type of access. The following access types are supported:
    • Any access covered by the SAP table buffer
    • Access for which at least one key field is specified
    The following access types are currently not supported:
    • Access with SQL statement SELECT FOR ALL ENTRIES
    • Access with range tables
    • Access with join expressions
    If the system cannot record a key value when accessing a table, the TBOM contains the table name only. In the change impact analysis, each changed entry in such tables leads to hits in all executable entities that access these tables.

Integration

The TBOM is an attribute of an executable entity in the Business Process Hierarchy (SOLAR01).
Dynamic TBOMs: In systems with kernel 620/640, the creation of dynamic TBOMs is only possible after status ST-PI 2008_01 SP03. In all other systems (kernel 46C or after 640), the creation of dynamic TBOMs is available.
Cross-system TBOMs: If an executable entity addresses other systems (e.g. by RFC), the objects in the other systems are also recorded. A separate TBOM enhancement is created for these objects per system. This function is available if all managed systems involved have a kernel status of at least 700.
Web applications: To record TBOMs for web applications, the managed systems must have a kernel status of at least 700.