All Products
Search
Document Center

Performance Testing:Structures and data allocation in test scenarios

Last Updated:Nov 01, 2024

This topic describes the logical structure relationships in common test scenarios and how data is allocated in test scenarios.

Terms

  • Test API: an API request that simulates a specific request to an application. It is crucial in performance testing.

  • Session: a structured sequence of performance testing APIs, which is similar to a transaction.

  • Associate data file: The test API uses parameters from the data file. The data file is therefore associated. If multiple file parameters are used from different data files, multiple data files are associated.

  • Data configuration node: If an API in a session needs file parameters or defines secondary file parameters (such as in MD5 encoding), you must configure or define them in a data configuration node before the API can use them.

  • Data export instruction: exports data from a session for being used in other sessions and for sharing the exported data globally.

  • Checkpoint (assertion): indicates whether a request is successful and checks whether the responses for requests meet expected values.

  • One data poll: If file parameters are used, the data file is polled only once to prevent duplicate request data.

  • Output parameter: When you create a session, the returned data of the upstream API is used as parameters.

Common structures and data allocation rules in test scenarios

The following figure shows details.

image

Notes:

  • Session 1 and session 2 are in a parallel.

  • A session is similar to a transaction. All test APIs in a session are called in order. The requests of the upstream API must be sent or time out before the request of the current API are sent.

    Note

    The number of requests sent by a downstream API is less than that of requests sent by upstream APIs, because some requests are not completed by an intermediate API when the test is finished.

  • The file parameters can be used by all APIs in a session only after you configure the data configuration node.

    • API 1 in Session 1 uses a parameter of File 2 (200 rows), API 2 uses a parameter of File 3 (1000 rows), and API 3 uses a parameter of File 2 (200 rows) and a parameter of File 1 (100 rows). When no benchmark file is specified, File 1 (100 rows) is selected as the benchmark. The first 100 rows are truncated from File 2 and File 3 and polled repeatedly.

    • If you select one data poll for a parameter, the parameter is selected as the benchmark. The same number of rows as in its source file are selected in the combination. The test on the current API is terminated after the required number of requests are sent. The test on the session is terminated after the specified number of requests required in the combination are sent.

  • If checkpoints (assertions) are specified and if the assertion of the current request fails, the subsequent APIs or instructions are not be executed (only for this sequential execution process). If the assertion is successful, the process continues.

Structure of logon-dependent test scenarios

The following figure shows the typical configurations if API 1 of Session 1 is logon-dependent.

image

Notes:

  • Data export instructions are generally used when multiple services need to be tested in parallel after logon. They can be used to export standard cookies or output parameter (custom export actions in business). A maximum of five parameters can be exported. You can specify the export level for each parameter.

  • If Session 1 uses data exporting instructions, tests on other sessions can start only after the data is export. Session 1 is not in parallel with other sessions.

    Note

    Only when data export instructions are used, not all sessions are in parallel.

  • To ensure the uniqueness of user logon information, you must select one data poll for a parameter in the data configuration node of the test API. In this example, one data poll is selected for the parameter in Session 1.

  • After the required number of users have logged on, the user logon information is shared with other sessions in the scenario. You must set the Export Level parameter. Tests on the remaining sessions in the scenario are triggered only when this parameter value is reached.

  • The specified value must be less than or equal to the number of file rows for the logon API. In the preceding example, the associated data file has 200 rows, so the export level is set to 100.

    Note

    If the specified value cannot be satisfied (for example, some load generators are disconnected during the test), you can click Release Global Preparations in the lower part of the test page to continue the tests on other sessions.