Allure TestOps migration

Migration from version 3.X.X to Allure TestOps 5+

WARNING

This functionality is available in the tool tom-v.j.m only.

WARNING

MIGRATION FOR LEGACY ALLURE TESTOPS VERSION AVAILABLE > 3.185.3

Migration Configuration Guide

This guide explains how to configure the migration script by modifying the JSON configuration file. The script transfers test cases from an old TestOps instance to a new one, project by project, while maintaining metadata and relations.

Java 21 is required!

Script Execution Example

java -jar tom-1.2.0-all.jar /path/to/config/file/testops.json

Configuration Structure

The configuration file consists of two main sections:

• allureConfig: Defines the target system where test cases will be migrated.
• testopsConfig: Specifies the source system from which test cases will be fetched.

Configuration Fields

General Settings

{
  "type": "testops",    // Defines the migration type
  "debug": true,         // Enables debug mode
  "oneByOne": true       // Migrates test cases one by one instead of batch processing
}

Target System (allureConfig)

"allureConfig": {
  "endpoint": "http://target-endpoint/",  // URL of the target TestOps instance (mandatory parameter)
  "token": "your-api-token",             // API token for authentication (mandatory parameter)
  "sslTrustAll": true,                     // If true, SSL certificate validation is disabled
  "projectId": 7,                          // ID of the target project (mandatory parameter)
  "migrationTagPrefix": "testops",        // Tag is applied to migrated test cases 
  "issueTrackerId": 5,
  "workflowId": 3                       // WorkflowId in a target system, -1 by default 
}

INFO

Issue tracker integration must be configured in TestOps to successfully migrate linked issues.

Source System (testopsConfig)

"testopsConfig": {
  "endpoint": "http://source-endpoint/",  // URL of the source TestOps instance (mandatory parameter)
  "token": "your-3.185.api-token",       // API token for authentication (mandatory parameter)
  "sslTrustAll": true,                     // If true, SSL certificate validation is disabled 
  "testCaseIds": "1,2,3,4",               // List of test case IDs to migrate (optional, can be removed)
  "projectId": 4,                          // ID of the source project (mandatory parameter)
  "oldScenario": true,                      // Marker for scenarios in TestOps 3.x (mandatory parameter)
  "oldTestCaseRelation": true,              // Marker for relation support in TestOps 3.x (mandatory parameter)
  "rqlFetchQuery": "insert your AQL query here",  // Query to migrate test cases by a specific query (optional, can be removed)
  "customFields": {                         // Mapping of custom fields between source and target
    "Feature": "Feature",
    "Story": "Story",
    "Epic": "Epic",
    "Custom": "Custom",
    "Test1": "Test1"
  },
  "testLayers" : {                         // Test Layer names mapping
      "UI Tests": "UI Tests",
      "API Tests": "API Tests",
      "Unit Tests": "Unit Tests"
    },
  "workflows" : {                         // Workflow names mapping  
      "Unique Workflow": "Unique Workflow"
    }
}

Important Notes

• Ensure both source and target TestOps systems are accessible via the provided endpoints.
• Custom fields must be mapped correctly to avoid data loss.
• Before using rqlFetchQuery, ensure that the query is valid within the TestOps AQL syntax.
• To ensure that the custom workflow along with its custom statuses is migrated correctly, you need to recreate the exact same workflow structure and status on the target instance, matching the one from the source instance.

Example of a Valid Configuration File

{
  "type": "testops",
  "debug": true,
  "oneByOne": true,
  "allureConfig": {
    "endpoint": "https://testing.testops.cloud",
    "token": "my-api-token",
    "sslTrustAll": true,
    "projectId": 12075,
    "migrationTagPrefix": "testops"
  },
  "testopsConfig": {
    "endpoint": "https://grumpy-firefox-3.lt.aws.qameta.in",
    "token": "another-api-token",
    "sslTrustAll": true,
    "oldScenario" : true,
    "projectId": 1,
    "oldTestCaseRelation" : true,
    "customFields": {
      "Feature": "Feature",
      "Story": "Story",
      "Epic": "Epic",
      "Custom": "Custom"
    }
  },
  "testLayers" : {
      "UI Tests": "UI Tests",
      "API Tests": "API Tests",
      "Unit Tests": "Unit Tests",
    },
    "workflows" : {
      "Unique Workflow": "Unique Workflow"
    }
}

Data migration from Allure TestOps ver. 4.X.X to Allure TestOps 5+

WARNING

This functionality is available in the tool testops-migration-4.j.m-pre0.jar. Use the latest available version.

Configuration file example

Create the json file with content like:

{
  "type": "testops",
  "debug": true,
  "requestLog": false,
  "oneByOne": true,
  "allureConfig": {
    "endpoint": "https://demo.testops.cloud/",
    "token": "api-token",
    "sslTrustAll": true,
    "projectId": 96,
    "migrationTagPrefix": "testops"
  },
  "testopsConfig": {
    "endpoint": "https://old-allure-testops-endpoint/",
    "token": "api-token",
    "sslTrustAll": true,
    "projectId": 3,
    "testCaseIds": [1,2,3],
    "customFields": {
      "Feature": "Feature",
      "Story": "Story"
    }
  }
}

Fields description

Name	Mandatory
commonProperties	yes	see description here: Common properties
allureConfig	yes	see description here: Allure TestOps properties
testopsConfig.endpoint	yes	Old Allure TestOps instance url
testopsConfig.token		Old Allure TestOps token
testopsConfig.sslTrustAll	no	Flag if the host validation should take place. Example "true".	true
testopsConfig.projectId	yes	Old testops project id	2
testItConfig.testCaseIds	no	A list of specific cases for migration can be specified. Without this parameter the migration will be done for all cases in the project	[1,2,3]
testopsConfig.customFields	no	A list of cf values which need to be migrate to allure as custom fields. "customFields": { "Suite": "Suite", "Feature": "Feature" }