The test result data model is the model for the data as it is being offered by a test result service. This may differ from the structure of an underlying database. The model described here does not cover all Requirements, but the missing requirements can be implemented "orthogonally", i.e. without structural changes to this model. The requirements that should be covered by the data model, and aren't in this one are:

• TRDB.TestLogs. There is no entity for logs yet and treating logs as a special variable doesn't do justice to the technical requirements for log storage. Logs can be easily added to the data model though by creating a log-entity that has a 1-on-1 or 1-to-many relation with test executions.
• TRDB.UserAccount. There is no notion of ownership of tests or test executions.
• TRDB.Views. There is no definition of a 'view'. This could be added to the data model, or it could be left to an application specific data model.

Data model

The model is comprised of four main entities.

Test

A test describes a test procedure that can be performed. Tests typically have some relation with some Part Under Test. Tests can have one or more test variables and for every time that the test is actually performed a report instance will be created that refers to this test.

Variable

Variables describe what can be reported from a test. This entity describes the name, type and unit of variables and which tests have what variables. Note that tests can generally have 2 types of variables: those that describe the results of a test execution and those that describe the context of a test execution. Examples of context-variables are 'Tester name' and 'Test system name'. 'Result' is a typical example of a result-variable. Some variables may be more quantitative in nature, for example 'Duration'. Other tests may have more specific quantitative variables. A database performance test may for example have a 'Small image read performance' variable.

The database does not make a distinction between context variables and result variables. It shall be possible to query for both types and it shall be possible to use both types of variables to filter. For example, it must be possible to ask for all values for 'Small image read performance' (variable) from test executions where 'test system' (variable) is 'X' (value), but it must also be possible to ask for all 'test system' values where 'Small image read performance' is larger than '200'.

Report

This entity represents one test execution on a particular time on a particular system (-configuration). The details of the test execution are not a fixed part of this entity, but are instead stored in values.

Value

Every report will have a value for at least one variable. Values are the core of the database. Each value is linked to

1. The test execution that resulted in this value, and
2. The variable for which this is a value.

Relation to API

Note that this data model does not prescribe what functions are offered by the API. The API could deliver the results of a single test execution with results as a nested data structure, where the results are pre-joined with information from the variable entity. Example: querying for all tests performed on test system X could result in a data structure that looks like this:

reports : [
  {
     test:'DB performance',
     time: '2013-01-01T10:00:00',
     id:130732,
     values : [
         { name:'Result', type:'enum', id:1, value:'Failed'},
         { name:'Read performance', type:'integer', unit:'im/s', id:313, value:1027}
     ]
   },
   {
     test:'System color',
     time: '2012-07-03T09:23:11',
     id:24123,
     values : [
         { name:'Result', type:'enum', id:11, value:'Succeeded'},
         { name:'Color', type:'enum', id:32134, value:'white'}
     ]
   },
   etc, etc,
]