The data stored in Allure TestOps

The information described in this article might be useful for the people trying to set up the cleanup rules or just to understand how the data in Allure TestOps is stored.

Test results

Allure TestOps consumes the test results files generated by your tests. Ideally, these are allure results (generated by the integration with allure framework).

Types of allure results test result files

*-container.json

container file contains

• name of a test
• links to the files related to this particular test (result, attachments)
• list and data on the fixtures (setUps and tearDown blocks of a test)

*-result.json

result files contain:

• test's attributes 
  • name, 
  • full name, 
  • historyId, 
  • labels (in Allure TestOps these are used as Custom Fields and other meta data such as tags, roles, layers)
• test's scenario
• error messages for non-passed tests

*-attachment.[ext]

• each attachment file represents a single attachment with a file extension relevant for attachment's MIME type.
• extension and MIME type are defined in the code of your automated test

Data stored in Allure TestOps' database

Test's meta data

Meta data for each test and for each launch are stored in report's database. 

For example:

- test result status (passed, failed etc)

- test name

- test full name

- tags

- roles

- custom fields

References to files

- references to fixtures

- references to attachments

Scenario

Starting from the release 4.9.2 the scenarios of the tests are stored in the database

Data stored on the blob storage

Ideally (see the docs) S3-like solution to be used to store the tests' artefacts.

The following data is stored on the blob storage as files:

• test results' fixtures
• test results' attachments

Storage eaters

The most of the storage space is consumed by the attachments of the successfully passed tests for these are almost the same from run to run, thus have almost no value. These must be cleaned in the 1st place.

Scenarios for the successfully passed tests create significant load for the database these need to be cleaned as well as these are identical from run to run and you don't need more than 2 most recent copies.