Report Variant Execution Authorization!

To execute table variants, you need proper authorization. It is checked against Auth. Object /DVD/VVAR. Auth. Fields checked are Activity (16 - Execute), Validate test type (TAB - Table), and then the Variant testing object (Table name in this case).

The user starting execution must have appropriate authorization. In case of execution via RFC the user used in the RFC connection must also have appropriate authorization.

Default /DVD/VALIDATE role allows you to execute all tables whose names start with /DVD/. At the moment Test Plan and Test Case are not checked.

Table Test Case Execution

When a Table Test Case is added to the Test Plan a new backend Test Run is automatically created and a Run ID is generated. The description holds the technical name of the Test Plan and the Test Case. All Table Variants selected during the creation of the Table Test Case are automatically added to the Table Variant selection for the generated Test Run.
To execute a Table Test Case from Test Management click on Execute. Afterward, the standard Table Testing scenario is displayed. Refer to the section below for a more detailed description of each scenario step.

Table-based backend testing

Table-based testing uses data directly from the database tables. Based on the user specification set, the table columns are read from the database table and are used to create before and after image. These images are then compared.
Recommendations:

For one Table testing run a maximum of 1000 Table variants should be used.

Test Scenario EQS_TABLE (Table testing)

_{Table Testing Scenario}

Table testing contains the following steps:

Selecting Table Variants
Generation of before image tasks
Creation of before images
Performing specific tasks in the system outside SNP Validate (like conversion, migration, etc.)
Generation of after image tasks
Creation of after images
Generation of comparison tasks
Execution of comparison tasks
Display of results

Select Table Variants

By double-clicking on the first Test Step Select Table Variants, you can define which Table variants are to be used in this Test Run for testing, or you can simply create new Table variants.
Once you have the variants selected for the Test Run, you need to save the selection by clicking on the Save button (Ctrl + s) on the main screen of the Table variants selection.
You can add Table Variants in the following ways:

Create New Table Variant: You can create a new Table Variant by clicking on the Create New Table Variant button (Shift + F1). For more information refer to Create new Table Variant section.
Add Existing Table Variant: You can display all of the existing Table variants in the system by clicking on the Add Existing Table Variant button (Shift + F2). You can then select one or more variants to be added to this Test Run.
Add Table Variants of Run: By clicking on the Add Table Variants of Run button (Shift + F4) you can select another (distinct from the current) run, and add all of the Table Variants of the selected run into the current Test Run.
Copy Table Variants of Run: By clicking on the Copy Table Variants of Run button (Shift + F8) you can select another (distinct from the current) run and add all of the Table Variants of the selected run into the current Test Run as copies.
Add Variants of Test Case: By clicking on the Add Variants of Test Case button (Shift + F11) you can select an existing Test Case, and add the Table Variants of the selected Test Case into the current Test Run.
Copy Variants of Test Case: By clicking on the Copy Variants of Test Case button (Shift + F12) you can select an existing Test Case, and add all of the Table Variants of the selected Test Case into the current Test Run as copies.
Copy Variants: Refer to the Copy Table Variants section for function details.

Generate tasks for before image

To generate the tasks, you can double-click the Test Step Generate tasks for before image to execute it. This will prepare the tasks for the following step Create before images.

Create before images

By double-clicking on this step, you first define the number of background jobs to be used to create the before image for each of the specified Table variants. The Image creation of some Table variants can fail due to too many rows read. This is a safety limit that can be adjusted by changing the setting Max. Table image row size. See the Settings section for more details on how to change this setting.

In a very unlikely case of numeric overflow during DB aggregation (values are stored in 16 bytes-packed numbers, thus making overflow practically impossible), SNP Validate is capable of handling numeric aggregation overflows. Automatic overflow handling is executed when the Table own aggregation setting is set to X and aggregation of results fails because of numeric overflow. In cases of problematic overflowing the key figure is set to 0 for all returned rows. And in cases of multiple overflowing key figures, these will be set to 0. Overflow handling is always logged. DB aggregation is always preferred for performance reasons and own aggregation should be used for handling special situations only.

Generate tasks for after image

To generate the tasks, you can double-click the Test Step Generate tasks for the after image to execute it. This will prepare the tasks for the following step Create after images.

Create after images

By double-clicking on this step, you first define the number of background jobs to be used to create the before image for each of the specified Table variants. The Image creation of some Table variants can fail due to too many rows being read. A limit can be set/ adjusted by changing the setting Max. Table image row size. See the Settings section for more details on how to change this setting.

In a very unlikely case of numeric overflow during DB aggregation (values are stored in 16 bytes-packed numbers, thus making overflow practically impossible), SNP Validate is capable of handling numeric aggregation overflows. Automatic overflow handling is executed when the Table own aggregation setting is set to X and aggregation of results fails because of numeric overflow. In cases of problematic overflowing the key figure is set to 0 for all returned rows. And in cases of multiple overflowing key figures, these will be set to 0. Overflow handling is always logged. DB aggregation is always preferred for performance reasons and own aggregation should be used for handling special situations only.

Generate tasks for comparison

To generate the tasks, you can double-click the Test Step Generate tasks for comparison to execute it. This will prepare the tasks for the following step Compare before and after images.

Compare before and after images

You define the number of background jobs to be used for task execution. Each of the tasks compares the before image data with the after image data for one Table Variant, refer to the Comparison logic section.

Display results

You can view the outputs and their comparison results for the Table Variants executions, refer to the Results overview section.

There is a possibility to display more additional fields with information about the testing process.

_{Addition of fields for variant results}

Browser not supported