Database Schema

XStudio's database is complex: it includes more than 200 tables.
But it can be useful to understand how it works for instance if you wish to use the SQL report feature. Indeed, you need to provide SQL queries to create a SQL report.

Tree Structure

All the data are organized in tree in XStudio. The recursive folder hierarchy is managed in one single table:



Each tree is then constructed starting from its root folder:

Tree type	Root folder Id
Users	1
SUTs	2
Requirements	3
Specifications	4
Tests	5
Campaigns	6
Bugs	7
Agents	8
Projects	9
Documents	11
SQL Reports	12
Assets	13

Traceability

One of the more important feature in XStudio is the traceability. If you have the specifications enabled in your server settings then the tables managing the traceability are:




If you chose not to handle the specifications, then it's a bit simpler:

Versioning

Almost all the data in XStudio are versioned completely transparently (you don't have to update or commit versions explicitly).
Each time you modify an item, a new version is automatically stored in the database.

This versioning also applies on links in between items.

Whenever you want, you can also assign a timetag to all your data so that, in the future, you can go back in time to this point.
A timetag can be seen as a label you can use as a reference.
The User's Manual contains a dedicated section about the TimeShifting feature.



All the information stored in the *_data tables (i.e. table_test_data) are versioned.

To easily retrieve the latest version of an object, just retrieve the object version associated with the special LATEST timetag.
This timetag (this is the only one that is set 100% automatically) has tag_id=10 and always point to the latest revision of each object.

For instance, if you need the details about one test (in its last revision) the SQL query would look like:

SELECT *
FROM table_test, table_test_data, table_test_data_tag
WHERE table_test.test_id=table_test_data.test_id
AND table_test_data.data_id=table_test_data_tag.data_id
AND table_test.test_id=123
AND tag_id=10;

You can also get the details of a specific version:

• if you know the timetag name of this specific version: addi the table table_tag in the SQL query and provide the appropriate tag_name
• if you know the revision number: provide the right revision in your SQL query
• if you know the approximate date: add some comparisons in your SQL query with date_submitted

Test execution and link with bugs

Tests are organized in campaigns. Each time you execute a campaign it's called a campaign session.
Each campaign session can be executed on different agents simultaneously and in different threads on each agent.

Custom Fields

Custom fields can be assigned to almost any kind of object in XStudio.
The custom fields values are assigned to the *_data tables so that we can track the custom field value changes.



The cust_*_source_type column defines on which type of object the custom field will be visible:

Object	Source type
SUTs	11
Requirements	4
Specifications	5
Tests	6
Test cases	7
Bugs	10

Test case parameterization

When you create some test cases, they can be parameterized.
This means you can affect some parameters to each test case along with a value (or even let the system generate the parameter combinations for you).

When you do that, the test case is actually considered as a template that is referenced several times. If you modify it, it will be modified everywhere it's referenced. The only difference in between all these calls to the same template is the parameter's values associated: