Chapter 12. Import/Export

Table of Contents

12.1. Importing Test Cases from Excel
12.1.1. Import Format
12.1.2. Prerequisites
12.1.3. Execution
12.2. Importing Test Cases from XML
12.2.1. Prerequisites
12.2.2. Execution
12.3. Importing Requirements from Excel
12.3.1. Import Format
12.3.2. Prerequisites
12.3.3. Execution
12.4. Importing and Synchronizing Requirements from XML
12.4.1. Prerequisites
12.4.2. Importing
12.4.3. Synchronization
12.5. Importing Test Results
12.5.1. The JUnit XML++ format
12.5.2. Prerequisites
12.5.3. Execution
12.5.4. Jenkins Plugin
12.6. Exporting Test Results
12.6.1. Export-Format
12.6.2. Execution
12.7. Exporting Table Content
12.8. Backup/Recovery
12.8.1. Backup via REST

Klaros-Test­management provides several interfaces to import data from other tools and export its data into several formats.

User authentication is mandatory for all import operations. The user role required varies with the type of data being imported. For importing test results, the Tester role is sufficient as for requirements and test cases the Manager role is required.

[Important] LDAP Authentication
.

If the setting Login default is enabled in the LDAP configuration, then authentication is done exclusively via the LDAP directory. Local authentication information is always ignored in this case.

12.1. Importing Test Cases from Excel

Klaros-Test­management allows importing of test cases from Excel sheets structured in a predefined format which will be further detailed in Section 12.1.1, “Import Format”.

In addition to the standard fields provided for test cases, users of the Klaros-Test­management Enterprise Edition are also able to import data for user-defined fields. For this it is necessary to prepare the project according to what is listed in Section 12.1.2, “Prerequisites”.

The import interface consists of a simple REST interface which can be accessed by command line tools as well as custom applications. This is further detailed in Section 12.1.3, “Execution”.

12.1.1. Import Format

The Excel sheet used to import test cases has to follow this strict format:

  1. Each test case is located on a separate sheet.

  2. Each sheet is divided into three sections: general properties, test case steps and custom properties.

  3. The fields A:1 to A:22 are reserved for the standard attributes of a test case. The corresponding values are entered in the fields B:1 to B:22. It is not mandatory to fill all fields.

  4. Column G is for the names of any number of user-defined properties. In column H the corresponding values are entered.

  5. The Step field in cell A:25 must remain. Changing or deleting the A:25 field will cause the import of this table to be rejected. From here the definition of the test steps begins:

    • Column A for the test step number,

    • Column B for the action,

    • Column C for the precondition,

    • Column D for the postcondition and

    • Column E for the expected result.

Test Case Excel Sheet Sample

Figure 12.1. Test Case Excel Sheet Sample


12.1.1.1. General Properties

The table below lists the cell coordinates for the general test case properties. The test case ID does not have to be specified. The ID is generated during the import. None of these values are mandatory. Some fields can take only predefined values which are listed there.

Coordinate

Value

B2

Name

B3

Revision (only used in export)

B5

Description

B6

Precondition

B7

Postcondition

B8

Expected Result

B10

Note

B11

Area ( FUNCTIONAL, NON_FUNCTIONAL, STRUCTURAL, REGRESSION, RE_TEST)

B12

Design Method ( BLACK_BOX, WHITE_BOX)

B13

Variety ( POSITIVE, NEGATIVE)

B14

Execution ( MANUAL, AUTO)

B15

Priority ( LOW, MEDIUM, HIGH)

B16

State ( NEW, APPROVED, LOCKED, INVISIBLE)

B17

Team

B18

Level ( COMPONENT, INTEGRATION, SYSTEM, ACCEPTANCE)

B19

Document Base

B20

Dependency

B21

Evaluation

B22

Traceability

Table 12.1. General Property Coordinates


12.1.1.2. Test Steps

Test cases may contain a variable number of test steps. These are listed one per row starting from cell A:26 downwards. The import parser will stop reading steps once it encounters an empty step number.

Coordinate

Value

A26 (ff)

Step Number

B26 (ff)

Action

C26 (ff)

Precondition

D26 (ff)

Postcondition

E26 (ff)

Expected Result

Table 12.2. Test Step Coordinates


12.1.1.3. Custom Properties

Test cases may contain custom properties. These may be listed as name/value pairs starting from cell G1 downwards.

For the import to succeed, the names of the listed properties must match with user defined properties defined for the project targeted by the import.

The value field for enumeration properties must exactly match the name of the enumeration property value definition to be parsed.

If an empty name cell is found, processing stops.

Coordinate

Value

G1 (ff)

Property name

H1 (ff)

Property value

Table 12.3. Custom Property Coordinates


12.1.2. Prerequisites

To import Excel based test cases the following prerequisites have to be met:

  1. The file that is going to be imported has to be XLS or XLSX format.

  2. The project that should contain the imported test cases has to be already created.

  3. If user defined properties (only available in Klaros-Test­management Enterprise Edition) are to be imported they have to be created for the project prior to starting the import process.

12.1.3. Execution

To import Excel-based test cases a REST interface is available which allows you to upload your data from the command-line or other applications.

The following example shows how to import an Excel sheet containing test cases into the project named P00001 using the curl command line application. Curl should be available in every Linux distribution and as part of the Cygwin http://www.cygwin.com/ distribution or as a command line tool from http://curl.haxx.se/download.html for the Microsoft Windows operating system family.

[Important] Incompatible Windows Powershell curl Alias

Windows Powershell also defines an alias named curl which also can be used for this purpose but takes a completely different set of arguments. If you prefer to use the Linux compatible curl executable under Powershell, use curl.exe instead of curl.

curl -v -T TestCases.xls "<klaros-app-url>/seam/resource/rest/import/testcase/xls?config=P00001\
&username=user&password=secret"

Example 12.1. Excel Test Case Import via Command Line


[Note] ID Format

All objects which are referenced during import (like projects or test cases) contain five digits in their id.

For example, P00001 is a valid project ID, while P0001 and P000001 are not.

12.2. Importing Test Cases from XML

Klaros-Test­management allows importing of test cases from XML Files. The import process will always create new instances of the supplied test cases for each invocation.

The format of the XML file is described in Appendix C, Test Case Import File Specification. The XML schema is available at the following URL: https://www.klaros-testmanagement.com/files/schema/klaros-testcases-1.0.xsd.

12.2.1. Prerequisites

To import XML based test cases the following prerequisites have to be met:

  1. The file that is going to be imported has to in XML format.

  2. The project that should contain the imported test cases has to be already created.

  3. If user defined properties are to be imported, they have to be created in the project prior to starting the import process.

12.2.2. Execution

To import XML-based test cases a REST interface is available which allows you to upload your data from the command-line or other applications.

The following example shows how to import an XML file containing test cases into the project named P00001 using the curl command line application. Curl should be available in every decent Linux distribution and as part of the Cygwin http://www.cygwin.com/ distribution or as a command line tool from http://curl.haxx.se/download.html for the Microsoft Windows operating system family.

curl -v -T TestCases.xml "<klaros-app-url>/seam/resource/rest/import/testcase/xml?config=P00001\
&username=user&password=secret"

Example 12.2. XML Test Case Import via Command Line


12.3. Importing Requirements from Excel

In order to correctly import requirements from Excel spreadsheets, the data must exist in a specified format. This format is described in detail in the following section Section 12.1.1, “Import Format”.

In addition to the standard fields provided for requirements, users of the Klaros-Test­management Enterprise Edition are also able to import data for user-defined fields. For this it is necessary to prepare the project accordingly. You can find more information about this at Section 12.1.2, “Prerequisites”.

The import interface consists of a simple REST interface which can be accessed by command line tools as well as custom applications. This is further detailed in Section 12.1.3, “Execution”.

12.3.1. Import Format

The Excel sheet used to import requirements has to follow this strict format:

  1. Each requirement is located on a separate sheet.

  2. Each sheet is divided into two sections: general properties and custom properties.

  3. The fields A:1 to A:9 are reserved for the standard attributes of a requirement. The corresponding values are entered in the fields B:1 to B:9. It is not mandatory to fill all fields.

  4. Column G is for the names of any number of user-defined properties. In column H the corresponding values are entered.

Requirement Excel Sheet Sample

Figure 12.2. Requirement Excel Sheet Sample


12.3.1.1. General Properties

The table below lists the cell coordinates for the general requirement properties. None of these values are mandatory. Some fields can take only predefined values which are listed there.

Coordinate

Value

B1

ID (only used in export)

B2

Name

B3

Revision (only used in export)

B5

Summary

B6

Description

B8

Priority ( LOW, MEDIUM, HIGH)

B9

State ( NEW, APPROVED, LOCKED, INVISIBLE)

Table 12.4. General Property Coordinates


12.3.1.2. Custom Properties

Requirements may contain custom properties. These may be listed as name/value pairs starting from cell G1 downwards.

For the import to succeed, the names of the listed properties must match with user defined properties defined for the project targeted by the import.

The name in the name column must exactly match the name of a user defined property for a value to be parsed correctly. The parsing stops once an empty name cell has been found. The value field for enumeration properties must exactly match the name of the enumeration property value definition to be parsed.

Coordinate

Value

G1 (ff)

Property name

H1 (ff)

Property value

Table 12.5. Custom Property Coordinates


12.3.2. Prerequisites

To import Excel based requirements the following prerequisites have to be met:

  1. The file that is going to be imported has to be in XLS or XLSX format.

  2. The project that should contain the imported requirements has to be already created.

  3. If user defined properties (only available in Klaros-Test­management Enterprise Edition) are to be imported they have to be created for the project prior to starting the import process.

12.3.3. Execution

To import Excel-based requirements a REST interface is available which allows you to upload your data from the command-line or other applications.

The following example shows how to import an Excel sheet containing requirements into the project named P00001 using the curl command line application. curl is available in almost any Linux distribution and for the Microsoft Windows operating system family as part of the Cygwin http://www.cygwin.com/ distribution or as a command line tool from http://curl.haxx.se/download.html.

curl -v -T Requirements.xls "<klaros-app-url>/seam/resource/rest/import/requirement/xls?config=P00001\
&username=user&password=secret"

Example 12.3. Excel Requirement Import via Command Line


12.4. Importing and Synchronizing Requirements from XML

Klaros-Test­management allows to both import and synchronize requirements from XML Files.

An import is limited to a one-time action that always creates new instances of the delivered requirements. Synchronization, on the other hand, allows updating existing requirements with the content of the XML file and creating new revisions of them as needed.

The format of the XML file is described in Appendix D, Requirement Import File Specification. The XML schema is available at the following URL: https://www.klaros-testmanagement.com/files/schema/klaros-requirements-1.0.xsd.

12.4.1. Prerequisites

To import XML based test cases the following prerequisites have to be met:

  1. The file that is going to be imported has to be in *.XML format.

  2. The project that should contain the imported requirement has to be already created.

  3. If user defined properties are to be imported, they have to be created in the project prior to starting the import process.

  4. If the imported requirements should be assigned to test cases via externalTestCaseId, Test cases with this external ID must already exist.

12.4.2. Importing

To import XML-based requirements a REST interface is available which allows you to upload your data from the command-line or other applications.

The following example shows how to import an XML file containing requirements into the project named P00001 using the curl command line application. curl is available in almost any Linux distribution and for the Microsoft Windows operating system family as part of the Cygwin http://www.cygwin.com/ distribution or as a command line tool from http://curl.haxx.se/download.html.

curl -v -T Requirements.xml "<klaros-app-url>/seam/resource/rest/import/requirement/xml?config=P00001\
&username=user&password=secret"

Example 12.4. XML Requirement Import via Command Line


12.4.3. Synchronization

To synchronize XML-based requirements a different REST interface is available (ending with /sync/requirement/xml). It understands the same import format as defined for importing requirements but requires additional elements to be present for correct operation.

In contrast to an import a synchronization action is intended to update the set of requirements stored in Klaros-Test­management from arbitrary external applications on a regular basis.

The synchronization supports creating and updating as well as revisioning of requirements. Changes to the requirements will be reflected in the Klaros-Test­management database on a per-field basis for each synchronization action.

[Caution] Synchronization Overrides Local Changes!

Be aware that all data received via synchronization will overwrite any changes made to the requirements stored in Klaros-Test­management.

[Tip] externalId

Supplying the externalId element (See Section D.11, “<externalId>”) will identify a requirement for subsequent synchronisation attempts. It is required field when using this interface. If you change this value, a new requirement object will be created instead of replacing the content of the previously created requirement.

[Tip] revision

Supplying the revision element (See Section D.15, “<revision>”) will identify the version of a requirement for subsequent synchronisation attempts.

  • If the value is empty, the currently selected revision of the requirement is updated.
  • If a new revision is entered, a new version of the requirement is created and updated.
  • If an older revision is entered, the entered revision will be updated.

The following example shows how to synchronize an XML file containing requirements into the project named P00001 using the curl command line application. curl is available in almost any Linux distribution and for the Microsoft Windows operating system family as part of the Cygwin http://www.cygwin.com/ distribution or as a command line tool from http://curl.haxx.se/download.html.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<r:container xmlns:r="http://klaros-testmanagement.com/export-requirements-1.0">
 <r:requirements>
  <r:requirement>
   <r:attributes/>
   <r:externalId>RTM-00001</r:externalId>
   <r:revision>1.0</r:revision>
   <r:priority>MEDIUM</r:priority>
   <r:shortname>Remote-controlled door panels / unlocking</r:shortname>
   <r:summary>Doors must me remote controllable.</r:summary>
  </r:requirement>
 </r:requirements>
</r:container>

Example 12.5. XML Requirement Synchronization via Command Line


curl -v -T Requirements.xml "<klaros-app-url>/seam/resource/rest/sync/requirement/xml?config=P00001\
&username=user&password=secret"

Example 12.6. XML Requirement Import via Command Line


12.5. Importing Test Results

Test automation tools typically generate test results in file form. These files can be imported via a REST interface and automatically converted into test results.

12.5.1. The JUnit XML++ format

JUnit XML++ is the generic format used internally by Klaros-Testmanagement for importing test case results from external sources. This format is upward compatible with the JUnit XML format.

By extending the JUnit XML format, the JUnit XML++ format enables you to specify individual test steps of a test, as well as to embed binary attachments in an XML document. In addition, with the result type inconclusive it allows to indicate ambiguous results.

12.5.1.1. The JUnit XML format

Unfortunately, a clear formal JUnit XML format specification does not exist, as JUnit itself does not create XML reports. XML reporting usually results from the processing of the JUnit invocation within a build tool such as the Ant JUnit task, the Maven Surefire plugin, or Gradle.

The JUnit XML format has established itself as a generic (quasi-)standard format for test case results across tool and programming language boundaries and is supported by a large number of automation tools. Despite the ambiguity of the format, there have been several attempts in the past to document the format in the form of an XML schema. Detailed commented schema definitions can be found, for example, here: https://llg.cubic.org/docs/junit/ and here: https://github.com/windyroad/Junit-Schema/blob/master/JUnit.xsd.

12.5.1.2. The JUnit XML++ format

The JUnit XML format unfortunately does not offer all the possibilities that are supported in Klaros-Test­management, especially it lacks:

Das JUnit XML Format bietet leider nicht alle Möglichkeiten, die in Klaros-Test­management unterstützt werden, insbesondere fehlt hier:

  • Describing and evaluating tests at the test step level
  • Adding binary attachments (images, documents, etc.) to the test results
  • Support additional test ratings (unclear)

We have added this to the JUnit XML format without changing the existing syntax. In the following we call this new format JUnit XML++.

12.5.1.2.1. Test step results

Within a testcase element there can now occur any number of teststep elements. These must contain a time attribute which specifies the execution time of the test step in seconds.

As with test cases, error, failure or skipped elements within a test step control their rating.

Also likewise to the test cases, system-out as well as system-err elements are supported. If these contain content, they are automatically added as binary attachments to the test case result generated during import.

Optionally, the elements action, precondition, postcondition and expectedResult can be mapped to the test step result.

If these are available, they are transferred to the corresponding fields of a test step result in Klaros-Test­management. This information is not mandatory, but it is recommended at least for the action field in order to better identify individual test steps.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testcase name="Test 1" time="0.008">
    <teststep time="0.006">
        <action>Textual description of the action taken in this step</action>
        <precondition>Precondition information</precondition>
        <postcondition>Postcondition information</postcondition>
        <expectedResult>Expected result of this test step</expectedResult>
    </teststep>
    <teststep time="0.002">
        <failure>
            Detailed failure message
        </failure>
        <system-out>Log message</system.out>
    </teststep>
</testcase>

Example 12.7. 


12.5.1.2.2. Attachments

For the documentation of a test (step) result, it may be useful to supplement it with a file (screenshot, document, etc.) in addition to the textual description. To enable this, additional content can be defined in the system-out and system-err elements.

After successful extraction and saving, this content is not transferred to any additionally created system-out/system-err attachments. The content is defined according to the Jenkins plugin JUnit Attachments and may appear in three different forms:

Base64 Encoded Attachment

Syntax: [[ATTACHMENT_DATA|«attached-file.xyz»|«encoded data»]]

In encoded data a base64-encoded binary content is expected. After successful decoding, this is stored under the file name attached-file.xyz as an attachment to the test case result or test step result.

So this method saves the entire attachment as part of the result file. This requires more storage space, but allows access to the content at any time.

URL Attachment

Syntax: [[ATTACHMENT_URL|/«url/to/attached-file.xyz»]]

An attempt will be made to download the contents of the URL url/to/attached-file.xyz and to save it as an attachment under the filename attached-file.xyz.

This method expects the attachment to be available on the network. It is mandatory that the Klaros instance has access to this URL at import time for the extraction to succeed.

File Attachment

Syntax: [[ATTACHMENT|/«path/to/attached-file.xyz»]]

An attempt is made to download the contents of the file path/to/attached-file.xyz and save it as an attachment under the file name attached-file.xyz.

With this method it is expected that the attachment is provided in the local file system. It is mandatory that the Klaros instance has access to this file at the time of import for the extraction to succeed.

12.5.1.2.3. Test results

For test case results ( testcase) as well as for test step results ( teststep), it is possible to set inconclusive (unclear) as result type besides error, failure or skipped, since this is supported in Klaros-Test­management but not in JUnit.

12.5.2. Prerequisites

To import test results the following prerequisites have to be met:

  1. The project, iteration, test environment and system under test that should contain the imported test case or test suite results have to be created.

12.5.3. Execution

The default URL of the import interface is located at http://localhost:18080/klaros-web/seam/resource/rest/importer. The content is transferred via an HTTP PUT request using the above URL and various URL query parameters.

[Tip] The <klaros-app-url> Term

The http://localhost:18080/klaros-web URL shown above is the default klaros application url when accessing Klaros-Test­management from the host it is installed on and may vary with your setup. Throughout this chapter the term <klaros-app-url> will be used instead to reflect this.

The following parameters are supported:

config

The ID of the project to import the results into (e.g. P0001).

iteration

The ID of the iteration to relate the results to (e.g. ITR00001). This parameter is optional.

env

The ID of the test environment in which the tests have been run (e.g. ENV00001). Please make sure that this test environment already exists in the project before starting the import.

sut

The ID of the system under test in which the tests have been run (e.g. SUT00001). Please make sure that this system under test already exists in the project before starting the import.

type

The type of the import format. The following types are supported:

aunit

AUnit

boost

Boost Test

Check

Check

cpptest

CppTest

cppunit

CppUnit

ctest

ctest (CMake)

cunit

CUnit

fitnesse

Fitnesse

fpunit

Free Pascal Unit

gtester

GLib/gtester

googletest

GoogleTest

jbehave

JBehave

jmeter

JMeter

jsunit

JsUnit

jubula

Jubula / GUIdancer

junit

JUnit / Gauge / Robot Framework / Selenium / Squish / TestNG

mbunit

MBUnit

mstest

MSTest

nunit

NUnit

phpunit

PHPUnit

qftest

QF-Test

qtestlib

QTestLib

tessy

TESSY

testcomplete

TestComplete

tusar

TUSAR

uft

Unified Functional Testing (UFT) / QuickTest Professional (QTP)

cpptestunit

UnitTest++

valgrind

Valgrind

xUnit.net

xunitdotnet

job

The optional ID of a job this test run should be assigned to (e.g. JOB00001). If given, the job must already exist in the project before starting the import.

time

The time of the test execution. Please make sure the fixed format for the time is dd.MM.yyyy_HH:mm. This parameter can be used to override the test run date which is otherwise bound to the time of import.

createTestSuiteResults

If set to true test suite results are automatically created for the corresponding test suite information contained in the result file. This information may vary with the import format. Additionally, a corresponding test suite is created for the test suite result if it did not yet exist.

autoCreateTestCases

If set to false test cases are no longer automatically created for test case results for which no associated test case can be found. The default setting for this parameter is true.

username

The username for the import.

password

The password for the import.

A complete example for a QF-Test import URL would look like this:

http://localhost:18080/klaros-web/seam/resource/rest/importer?\
config=P00001&env=ENV00001&sut=SUT00001&type=qftest&time=01.03.2011_12:00&username=me&password=secret

Example 12.8. QF-Test import URL sample


The result file is contained in the HTTP request body.

The curl command line tool can be used on Linux or Windows/Cygwin to trigger an import in a single command line.

curl -v -H "Content-Type: text/xml" -T <test result file> \
"<klaros-app-url>/seam/resource/rest/importer?config=P00001&env=ENV00001&sut=SUT00001&type=junit\
&time=23.05.2011_14:55"

Example 12.9. Curl Command Line Example


[Important] Incompatible Windows Powershell curl alias

Windows Powershell also defines an alias named curl which also can be used for this purpose but takes a completely different set of arguments. If you prefer to use the Linux compatible curl executable under Powershell, use curl.exe instead of curl.

curl -Method put -InFile <test result file> -Uri \
"<klaros-app-url>/seam/resource/rest/importer?config=P00001&env=ENV00001&sut=SUT00001&type=junit\
&time=23.05.2011_14:55"

Example 12.10. Powershell Curl Alias Command Line Example


12.5.4. Jenkins Plugin

This plugin integrates a continuous integration server with Klaros-Test­management by publishing the test results of a Jenkins build to the Klaros-Test­management application. The test results will be stored in the Klaros-Test­management database for further evaluation and reporting purposes. You can find the installation and configuration guide for the plugin in the Jenkins GitHub page.

12.6. Exporting Test Results

Klaros-Testmanagement provides a JUnit XML export interface that enables the export of test results.

12.6.1. Export-Format

Appendix Verweis??? oder nicht nötig???

12.6.2. Execution

The default URL of the export interface is located at http://localhost:18080/klaros-web/seam/resource/rest/export/result/junit. The content is transferred via an HTTP GET request using the above URL and various URL query parameters.

[Tip] The <klaros-app-url> Term

The http://localhost:18080/klaros-web URL shown above is the default klaros application url when accessing Klaros-Test­management from the host it is installed on and may vary with your setup. Throughout this chapter the term <klaros-app-url> will be used instead to reflect this.

The following parameters are supported:

config

The ID of the project to export the results from (e.g. P0001).

env

The ID of the test environment in which the tests have been run (e.g. ENV00001).

sut

The ID of the system under test in which the tests have been run (e.g. SUT00001).

job

The ID of the job to export the results of (e.g. JOB00001).

testRun

The ID of the test run to export the results of (e.g. TRU0000001).

username

The username for the export.

password

The password for the export.

Both individual test results of a job or a test run and all test results of a system under test or a combination of system under test and test environment can be exported. This can be controlled by specifying the parameters.

The curl command line tool can be used on Linux or Windows/Cygwin to trigger an export in a single command line.

curl \
"<klaros-app-url>/seam/resource/rest/export/result/junit?config=P00001&job=JOB00001&user=me&password=secret"

In this example, the results of the job JOB00001 from the project P00001 are exported.

Example 12.11. Curl Command Line Example


[Important] Incompatible Windows Powershell curl alias

Windows Powershell also defines an alias named curl which also can be used for this purpose but takes a completely different set of arguments. If you prefer to use the Linux compatible curl executable under Powershell, use curl.exe instead of curl.

curl -Method get -Uri \
"<klaros-app-url>/seam/resource/rest/export/result/junit?config=P00001&testRun=TRU0000001&username=me&password=secret"

In this example, the results of the test run TRU0000001 from the project P00001 are exported.

Example 12.12. Powershell Curl Alias Command Line Example


12.7. Exporting Table Content

With Klaros-Test­management it is possible to export the content of all tables to an Excel file. The current filter and sort settings will be considered.

Export Table Content to Excel

Figure 12.3. Export Table Content to Excel


12.8. Backup/Recovery

To move data between different database installations, or to selectively import data, Klaros-Test­management provides the functionality to import and export database content via XML files. Section 10.6, “Backup” explains the import and export functionality in detail.

12.8.1. Backup via REST

Klaros-Test­management Enterprise Edition contains a REST-based interface that grant access to back up files of single projects. The following URI for example returns the backup xml file of the project P00004: http://{host}:{port}/klaros-web/seam/resource/rest/io/backup/project/P00004.

[Note] Note

For more information on how to access REST-based interfaces, see Chapter 13, The Remote API.