ReadyAPI에서 Apidog으로 마이그레이션하는 방법

요약

ReadyAPI에서 Apidog로 마이그레이션하는 것은 REST 중심의 테스트 스위트의 경우 간단합니다. ReadyAPI 프로젝트를 내보내고, OpenAPI 가져오기를 통해 가능한 부분을 변환하며, Groovy 스크립트는 JavaScript로 수동으로 다시 만드세요. SOAP 테스트 케이스는 가장 많은 수동 작업이 필요합니다. 테스트 적용 범위를 지속적으로 유지하기 위해 단계별 마이그레이션을 계획하십시오.

💡

Apidog는 OpenAPI 사양 및 Postman 컬렉션을 가져오고 JavaScript 스크립트를 사용하여 테스트 파이프라인을 실행하는 무료 올인원 API 개발 플랫폼입니다. Apidog를 신용 카드 없이 무료로 사용해보세요.

버튼

소개

API 테스트 인프라를 마이그레이션하는 것은 시작하기 전까지는 간단하게 들리는 작업 중 하나입니다. ReadyAPI 프로젝트에는 수년간 축적된 테스트 케이스, 사용자 지정 Groovy 스크립트, 데이터 파일, 환경 및 복잡한 테스트 스위트 구조가 포함될 수 있습니다. 이 모든 것을 Apidog로 가져오려면 자동으로 전환되는 것, 수동 변환이 필요한 것, 그리고 남겨두기로 결정할 수 있는 것을 이해해야 합니다.

이 가이드는 마이그레이션 프로세스를 단계별로 설명합니다. ReadyAPI 프로젝트 내보내기, 현재 상태 분석, Apidog로 가져오기, Groovy-JavaScript 변환 처리, CI/CD 설정, 그리고 두 도구가 동시에 실행되는 전환 기간 관리 방법을 다룹니다.

Step 1: 시작하기 전에 ReadyAPI 프로젝트 감사

무엇이든 내보내기 전에 현재 ReadyAPI 프로젝트에 무엇이 포함되어 있는지 이해하는 데 시간을 할애하십시오. 이 감사는 마이그레이션에 걸리는 시간과 노력을 집중할 부분을 결정합니다.

ReadyAPI 프로젝트를 열고 다음 질문에 답하십시오.

테스트 스위트, 테스트 케이스, 테스트 스텝은 몇 개입니까? 내비게이터 패널을 열고 세어보십시오. 50개의 테스트 케이스가 있는 프로젝트는 몇 시간 안에 마이그레이션됩니다. 500개의 프로젝트는 며칠이 걸립니다.

REST 대 SOAP 테스트 케이스의 비율은 어느 정도입니까? REST 테스트 케이스는 훨씬 더 깔끔하게 마이그레이션됩니다. SOAP 테스트 케이스는 특히 WS-Security 정책이나 복잡한 어설션을 사용하는 경우 더 많은 수동 작업이 필요합니다.

테스트 케이스에 Groovy 스크립팅이 얼마나 있습니까? 테스트 케이스를 클릭하고 스크립트 단계를 찾아보십시오. 사용자 지정 Groovy 로직이 있는 테스트 케이스 수를 세어보십시오. 각 Groovy 스크립트는 JavaScript로 수동 변환이 필요합니다.

DataSource 단계를 사용하여 데이터 기반 테스트를 사용하고 있습니까? Apidog는 CSV 및 JSON 데이터 파일을 사용한 데이터 기반 테스트를 지원하지만, 설정 방식은 ReadyAPI의 DataSource/DataSink 패턴과 다릅니다.

Properties 또는 Property Transfer 단계를 많이 사용하고 있습니까? 이러한 패턴은 Apidog에서 다르게 작동합니다. 대신 변수와 환경 변수를 사용하게 됩니다.

LoadUI Pro를 통해 부하 테스트를 실행하고 있습니까? LoadUI Pro 통합은 Apidog로 이전되지 않습니다. 해당 시나리오를 위해서는 k6 또는 다른 부하 테스트 도구를 별도로 설정해야 합니다.

조사 결과를 문서화하십시오. 테스트 케이스 이름, 유형(REST/SOAP), Groovy 유무(예/아니오), 복잡도(단순/중간/복잡)가 포함된 스프레드시트는 시작하기 전에 마이그레이션 예상치를 제공합니다.

Step 2: ReadyAPI 프로젝트 내보내기

ReadyAPI는 프로젝트를 XML 파일로 저장합니다. 분석을 위해 프로젝트를 내보내려면:

ReadyAPI를 열고 프로젝트를 여십시오.
파일 > 다른 이름으로 저장을 선택하여 프로젝트를 독립 실행형 XML 파일로 저장하십시오.
테스트가 참조하는 외부 데이터 파일(CSV, Excel, XML 테스트 데이터)을 모두 저장하십시오.
환경 섹션에 설정한 모든 환경 구성을 기록하십시오.

프로젝트 XML에는 모든 테스트 스위트, 테스트 케이스, 테스트 스텝, 스크립트 및 구성이 포함되어 있습니다. 이는 테스트 프로젝트의 완전한 표현입니다.

Step 3: API 정의 추출

REST API에 대한 가장 깔끔한 마이그레이션 경로는 ReadyAPI 프로젝트 XML에서 직접 가져오는 것이 아니라 OpenAPI 사양을 통하는 것입니다.

옵션 A: ReadyAPI에서 내보내기. ReadyAPI에 REST 서비스가 있는 경우, 내비게이터에서 해당 서비스를 마우스 오른쪽 버튼으로 클릭하고 내보내기 또는 API 정의 생성 옵션을 찾으십시오. ReadyAPI는 서비스 정의에서 Swagger/OpenAPI 사양을 내보낼 수 있습니다.

옵션 B: 백엔드의 OpenAPI 사양 사용. 백엔드 서비스가 이미 OpenAPI 사양(/openapi.json 또는 유사한 경로)을 노출하는 경우, 이를 직접 다운로드하십시오. 이렇게 하면 가장 정확하고 최신 정의를 얻을 수 있습니다.

옵션 C: 수동으로 추출. 기존 사양이 없는 API의 경우 ReadyAPI REST 요청을 소스로 사용하십시오. 엔드포인트, 요청 본문, 헤더 및 응답 구조를 기록하십시오. 이들을 Apidog에서 다시 생성해야 합니다.

Step 4: Apidog로 가져오기

OpenAPI 사양이 준비되면 Apidog로 가져오십시오.

Apidog를 열고 새 프로젝트를 생성하십시오.
API > 가져오기로 이동하여 형식을 선택하십시오 (OpenAPI 3.0, Swagger 2.0 등).
사양 파일을 업로드하거나 URL을 붙여넣으십시오.
Apidog는 사양을 분석하고 모든 엔드포인트에 대한 API 정의를 생성합니다.

가져오기 후에는 모든 엔드포인트, 매개변수, 요청 본문 및 응답 스키마가 채워진 구조화된 API 정의를 갖게 됩니다. 이것이 테스트 케이스의 기초가 됩니다.

기존 Postman 컬렉션(이전 도구에서 마이그레이션했을 수 있음)이 있는 경우 Apidog는 파일 > 가져오기 > Postman을 통해 이를 가져올 수 있습니다.

Step 5: REST 엔드포인트용 테스트 케이스 다시 생성

REST 테스트 케이스의 마이그레이션 프로세스는 다음과 같습니다.

ReadyAPI REST 테스트 케이스를 엽니다.
사용하는 요청, 어설션 및 모든 데이터 소스를 식별합니다.
API 엔드포인트를 선택하고 테스트 스텝을 추가하여 Apidog에 해당하는 테스트 케이스를 생성합니다.

어설션은 다음과 같이 번역됩니다.

포함 어설션(본문에 문자열 포함)은 JavaScript 어설션이 됩니다: pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); });
상태 코드 어설션: pm.test('status 200', () => { pm.response.to.have.status(200); });
JSONPath 어설션: pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });

Groovy가 없는 간단한 GET 및 POST 테스트의 경우 이 마이그레이션은 빠릅니다. 5~10개의 어설션이 있는 간단한 테스트 케이스는 15~30분 안에 다시 생성할 수 있습니다.

Step 6: Groovy 스크립트를 JavaScript로 변환

이는 사용자 지정 스크립팅이 많은 프로젝트 마이그레이션에서 가장 노동 집약적인 부분입니다.

일반적인 Groovy 패턴 및 해당 JavaScript 등가물:

// Groovy (ReadyAPI)
def response = context.expand('${TestStep#Response}')
def json = new groovy.json.JsonSlurper().parseText(response)
def value = json.fieldName

// JavaScript (Apidog)
const response = pm.response.json();
const value = response.fieldName;

변수 설정:

// Groovy
testRunner.testCase.setPropertyValue('myVariable', someValue)

// JavaScript
pm.variables.set('myVariable', someValue);

조건부 어설션:

// Groovy
if (statusCode == 200) {
  assert responseBody.contains("success")
}

// JavaScript
if (pm.response.code === 200) {
  pm.test('response contains success', () => {
    pm.expect(pm.response.text()).to.include('success');
  });
}

날짜 조작:

// Groovy
def now = new Date()
def formatted = now.format('yyyy-MM-dd')

// JavaScript
const now = new Date();
const formatted = now.toISOString().split('T')[0];

Java 라이브러리 가져오기 또는 복잡한 로직이 있는 복잡한 Groovy 스크립트의 경우 변환에 신중한 분석이 필요합니다. 각 스크립트를 읽고 무엇을 하는지 이해한 다음 동등한 JavaScript를 작성하십시오. 자동 번역을 시도하지 마십시오. 의미론은 당신을 속일 만큼 충분히 가깝지만, 조용한 버그를 유발할 만큼 충분히 다릅니다.

Step 7: SOAP 테스트 케이스 처리

SOAP 테스트 케이스는 ReadyAPI 마이그레이션에서 가장 어려운 부분입니다. Apidog에는 전용 SOAP 도구가 없으므로 다른 접근 방식이 필요합니다.

REST 인터페이스를 노출하는 SOAP 서비스(점점 더 흔해지고 있음)의 경우, 테스트를 REST 엔드포인트를 사용하도록 마이그레이션하고 SOAP 계층을 제거하십시오.

REST 대안이 없는 SOAP 서비스의 경우 두 가지 옵션이 있습니다:

SOAP 전용으로 ReadyAPI 유지. SOAP 테스트 케이스의 경우 ReadyAPI를 병렬로 실행하고 REST의 경우 Apidog를 사용하십시오. 이는 REST 마이그레이션을 방해하지 않고 SOAP 적용 범위를 유지하는 실용적인 중간 지점입니다.
SoapUI 오픈 소스 사용. SoapUI 오픈 소스는 무료이며 SOAP 테스트를 처리합니다. ReadyAPI의 모든 기능을 대체할 수는 없지만 라이선스 비용 없이 기본적인 SOAP 기능 테스트를 수행합니다.

SOAP 마이그레이션을 서두르지 마십시오. 특히 WS-Security 테스트 케이스는 어설션이 신중하게 재현되지 않으면 상당한 위험을 수반합니다.

Step 8: 환경 및 변수 설정

ReadyAPI의 환경 기능은 Apidog의 환경 시스템에 매핑됩니다. 구성한 각 ReadyAPI 환경에 대해:

Apidog에서 일치하는 환경을 생성하십시오 (설정 > 환경).
동일한 변수를 추가하십시오: 기본 URL, 인증 토큰, 공유 헤더 등.
테스트 케이스가 URL 필드 및 요청 본문에서 올바른 Apidog 구문: {{variableName}}으로 변수를 참조하는지 확인하십시오.

Step 9: CI/CD 구성

ReadyAPI의 CI 설정은 일반적으로 빌드 에이전트에서 testrunner 명령을 포함합니다. Apidog는 다른 접근 방식을 사용합니다.

CI 에이전트에 Apidog CLI를 설치하십시오:

npm install -g apidog-cli

테스트 컬렉션 실행:

apidog run "path/to/collection.json" -e "environment-id"

GitHub Actions의 경우 워크플로우 단계는 다음과 같습니다:

- name: Run API tests
  run: apidog run collection.json --environment staging

Jenkins의 경우, 파이프라인에 Apidog CLI를 호출하는 셸 스텝을 추가하십시오. 빌드 에이전트에 ReadyAPI 설치가 필요하지 않습니다.

새 명령을 사용하도록 CI 구성 파일을 업데이트하십시오. Apidog 실행이 올바르게 검증되면 ReadyAPI testrunner 참조를 제거하십시오.

Step 10: 전환 기간 동안 두 도구를 병렬로 실행

하루 만에 ReadyAPI에서 Apidog로 전환하지 마십시오. 최소한 한 번의 릴리스 주기 동안 두 도구를 병렬로 실행하십시오.

병렬 기간 동안:

CI에서 ReadyAPI 테스트를 권위 있는 테스트 게이트로 실행하십시오.
Apidog 테스트를 함께 실행하고 결과를 비교하십시오.
ReadyAPI에 나타나지 않는 Apidog의 모든 실패를 조사하십시오.
점진적으로 새로운 테스트 케이스를 Apidog에만 추가하십시오.

Apidog가 ReadyAPI와 동일한 실패를 감지한다는 확신이 들면 CI 파이프라인에서 ReadyAPI를 제거하십시오. ReadyAPI 설치는 몇 달 동안 예비용으로 유지하십시오.

FAQ

ReadyAPI에서 Apidog로 마이그레이션하는 데 일반적으로 얼마나 걸립니까? Groovy 스크립팅이 최소화된 REST 전용 프로젝트는 1~3일 내에 마이그레이션될 수 있습니다. 광범위한 Groovy 스크립트, SOAP 테스트 케이스 및 복잡한 테스트 구조를 가진 대규모 프로젝트는 2~6주가 소요될 수 있습니다. 1단계의 감사는 시작하기 전에 가장 명확한 예상치를 제공합니다.

제 ReadyAPI 테스트 데이터 파일이 Apidog에서 작동할까요? CSV 데이터 파일은 Apidog의 데이터 기반 테스트 기능과 함께 작동합니다. 가져오기 형식은 유사합니다. Excel 파일은 먼저 CSV로 변환해야 합니다. XML 데이터 파일은 ReadyAPI에서 사용된 방식에 따라 재구성해야 합니다.

마이그레이션 중에 ReadyAPI와 Apidog를 동일한 CI 파이프라인에서 실행할 수 있습니까? 예, 그리고 이것이 권장되는 접근 방식입니다. ReadyAPI testrunner 단계와 함께 Apidog CLI 단계를 기존 파이프라인에 추가하십시오. 전환 기간 동안 실행별로 결과를 비교하십시오.

환경을 수동으로 다시 생성해야 합니까, 아니면 자동화된 방법이 있습니까? 환경 구성은 Apidog에서 수동으로 다시 생성해야 합니다. ReadyAPI 환경 설정을 자동으로 가져오는 기능은 없습니다. Apidog에서 환경을 다시 생성하는 동안 ReadyAPI 환경을 한 창에 열어 두십시오.

REST 대안이 없는 ReadyAPI 테스트는 어떻게 됩니까? REST 대안이 없는 SOAP 전용 테스트 케이스의 경우, 현실적인 옵션은 해당 특정 테스트를 위해 ReadyAPI를 유지하거나(아마도 더 적은 라이선스로), SoapUI 오픈 소스로 마이그레이션하거나, 서비스가 레거시이고 위험이 낮은 경우 테스트 공백을 수용하는 것입니다.

Apidog가 ReadyAPI와 동일한 어설션 유형을 지원합니까? Apidog는 ReadyAPI의 내장 어설션 유형과 동일한 논리적 조건을 표현할 수 있는 JavaScript 어설션을 지원합니다. 구문은 다르지만 REST 테스트의 기능은 유사합니다. 일부 ReadyAPI 특정 어설션 유형(SOAP Fault, WS-Security)은 Apidog에 상응하는 것이 없습니다.

ReadyAPI에서 Apidog로의 마이그레이션은 의미 있는 프로젝트이며, 한나절에 끝나는 작업이 아닙니다. 신중하게 계획하고, 명확한 감사를 시작으로, REST 테스트 케이스를 먼저 마이그레이션하고, 전환 기간 동안 두 도구를 병렬로 실행하는 팀은 적용 범위 누락이나 테스트 회귀 없이 이 작업을 완료할 수 있습니다.