테스트 스위트를 생성한 후에는 테스트 콘텐츠를 추가해야 합니다. Apidog는 다양한 테스트 관리 요구 사항을 충족하기 위해 유연한 "정적" 및 "동적" 모드를 제공합니다.테스트 콘텐츠 가져오기#
테스트 스위트 상세 페이지의 Orchestration 탭에서 + Add Endpoint Test Case 또는 + Add Test Scenario를 클릭하십시오. 팝업 선택 창에서 Static 또는 Dynamic 모드로 전환할 수 있습니다.1. 정적 모드#
정적 모드는 실행할 테스트 항목을 정확하게 지정하는 데 사용됩니다.시스템은 사용자가 선택한 특정 테스트 케이스의 ID를 기록합니다. 소스 카테고리에 새 테스트 케이스가 추가되더라도 이 스위트의 실행 범위는 변경되지 않으므로 테스트 결과의 제어 가능성이 보장됩니다.버그 수정 검증(Hotfix): 버그와 강하게 관련된 테스트 케이스 3~5개를 선택하여 "검증 패키지"를 구성하고, 관련 없는 케이스를 실행하는 데 시간을 낭비하지 않으면서 수정 결과를 빠르게 검증합니다.
핵심 비즈니스 안정화(Core Path): "주문-결제"와 같이 매우 핵심적이고 안정적인 프로세스에 사용합니다. 신규 사용자가 불완전한 테스트 케이스를 실수로 추가하여 모니터링 알림이 트리거되는 상황을 방지할 수 있습니다.
이전 버전 호환성 테스트: 이전 버전 클라이언트 호환성을 검증하기 위해 기 존 엔드포인트 테스트 케이스 묶음을 특별히 선택합니다.
높은 유지 관리 비용: 이 특화된 테스트에 새 케이스를 포함해야 하는 경우 수동으로 추가해야 합니다.
2. 동적 모드#
동적 모드는 규칙을 통해 실행할 테스트 항목을 자동으로 필터링하는 데 사용됩니다.시스템은 **"필터 규칙"(범위 및 필터)**을 저장합니다. 실행할 때마다 시스템은 전체 프로젝트를 실시간으로 스캔하고, 조건을 충족하는 모든 최신 케이스를 실행 계획에 포함합니다.모듈 수준 회귀 테스트: "거래 센터" 폴더를 소스 폴더로 설정합니다. 테스터는 해당 폴더에 새 케이스를 작성하기만 하면 되며, 스위트 실행 시 자동으로 해당 케이스가 포함됩니다.
스모크 테스트: Priority = P0 규칙으로 동적 스위트를 생성합니다. 각 릴리스 전에 실행하여 P0로 표시된 모든 핵심 케이스를 자동으로 커버합니다.
버전 반복 검증: 태그 기능을 사용하여 규칙을 Tag = v2.5.0으로 설정합니다. 개발이 완료된 후 이 스위트를 실행하여 해당 버전의 모든 새 기능을 검증합니다.
유지 관리 비용 없음: 규칙을 구성한 후에는 스위트 자체를 별도로 유지 관리할 필요가 없으며, 케이스 속성(위치, 태그, 우선순위)만 유지 관리하면 됩니다.
실행 순서 조정#
가져온 콘텐츠는 목록으로 표시되며, 목록 항목을 드래그하여 실행 순서를 조정할 수 있습니다."정적으로" 추가된 항목의 경우 Edit을 사용하여 테스트 케이스를 개별적으로 삭제하거나 전체 그룹을 삭제할 수 있습니다."동적으로" 추가된 그룹의 경우 전체 그룹을 삭제하거나 필터 조건을 편집할 수만 있으며, 그룹 내 개별 항목은 삭제할 수 없습니다.고급 구성#
테스트 스위트 설계 페이지 오른쪽에서 Advanced Config를 펼쳐 테스트 스위트 실행 방식을 더 세부적으로 제어할 수 있습니다.정의: 기본적으로 테스트 스위트에 이미 설정된 실행 환경을 상속합니다. 여기에서 환경을 지정하면 실행 중 해당 환경 구성이 우선 적용됩니다.
사용 사례: 서로 다른 환경에서 동일한 테스트 단계 세트를 재사용해야 하는 시나리오에 적합합니다.
테스트 데이터#
실행 중 테스트 데이터를 사용할지 여부를 지정하는 데 사용됩니다.테스트 데이터 없음: 테스트 단계가 한 번만 실행되며, 데이터 기반 테스트를 실행하지 않습니다. 테스트 데이터 사용: 테스트 데이터를 기반으로 여러 번 실행되며, 일반적으로 매개변수화된 테스트에 사용됩니다.
오류 발생 시#
테스트가 오류를 처리하는 방식을 구성합니다. 여기에는 어서션 실패, 데이터 형식 검증 실패, 엔드포인트 요청 예외, 서버 오류 등이 포함될 수 있습니다.무시: 오류가 발생해도 현재 실행을 중단하지 않고 후속 단계를 계속 실행합니다.
계속: 오류가 발생하면 현재 라운드의 남은 단 계를 건너뛰고 다음 실행 라운드로 바로 진입합니다.
실행 종료: 오류가 발생하는 즉시 후속 단계를 종료합니다.
반복 횟수#
정의: 각 스레드가 모든 단계를 반복 실행하는 횟수입니다.
사용 사례: 일반적으로 안정성 검증 또는 간단한 부하 테스트 시나리오에 사용됩니다.
정의: 각 테스트 단계가 완료된 후 다음 단계를 실행하기 전에 대기할 시간(밀리초, ms)을 설정합니다.
사용 사례: 높은 요청 빈도로 인해 대상 서버에서 속도 제한 또는 서킷 브레이커 메커니즘이 트리거되는 것을 방지하여 원활한 테스트 실행을 보장합니다.
요청/응답 저장#
정의: 테스트 보고서에 요청 및 응답의 상세 데이터(예: 헤더, 본문 등)를 포함할지 여부를 제어합니다.
전체: 성공/실패 여부와 관계없이 모든 단계의 전체 세부 정보를 저장합니다. 데이터 용량이 크며, 심층 디버깅에 적합합니다.
실패한 항목만: 실행 중 실패한 단계의 세부 정보만 저장합니다. 권장되는 옵션이며, 저장 공간을 절약하고 실패 원인을 빠르게 식별하는 데 도움이 됩니다.
저장하지 않음: 어떠한 세부 정보도 저장하지 않고, 성공/실패 상태와 소요 시간만 기록합니다.
환경/전역 변수 값#
환경/전역 변수 값은 이 테스트 시나리오에서 환경/전역 변수에 사용할 실제 값을 지정합니다. 두 가지 선택지가 있습니다. 자세한 정보는 여기에서 확인할 수 있습니다. Runner에 저장된 변수 값을 사용하도록 선택하면, 사용할 변수 범위를 추가로 선택해야 합니다.이 범위의 목적은 사용자가 실제 요구 사항에 따라 변수를 더 잘 분리하도록 도와, 한 예약 작업 실행으로 인해 변수 변경이 발생하고 다른 작업이 실패하는 상황을 방지하는 것입니다. 범위를 선택한 후에는 제품 인터페이스에 표시되는 진입점을 통해 이 범위 내 변수 값을 확인할 수도 있습니다. | Runner의 변수 범위 | 환경/전역 변수 읽기/쓰기 | 설명 |
|---|
| 현재 테스트 시나리오에서만 공유 | - 현재 지정된 Runner에서 이 테스트 시나리오는 환경/전역 변수를 영구적으로 저장하기 위한 전용 파일을 가집니다.
- 현재 테스트 시나리오만 이 파일의 변수를 읽고 쓸 수 있습니다.
| 영향이 가장 작은 최소 변수 범위입니다. 이 테스트 시나리오의 이전 실행 결과를 다음 실행에서 사용해야 하는 경우에 적합합니다.
테스트 시나리오, 작업 및 작업 폴더의 변수 파일은 모두 Runner 컨테이너 경로 /opt/runner/variables에 저장됩니다. |
| 현재 예약 작업의 모든 테스트 시나리오에서 공유 | - 현재 지정된 Runner에서 예약 작업은 모든 테스트 시나리오에서 사용할 수 있는 환경/전역 변수를 저장하기 위한 파일을 가집니다.
- 현재 예약 작업의 모든 테스트 시나리오는 이 파일의 변수를 읽고 쓸 수 있습니다.
| 영향이 중간 정도인 권장 변수 범위입니다. 동일한 예약 작업 내 서로 다른 테스트 시나리오 간에 데이터를 공유해야 하는 경우에 적합합니다. |
| 현재 예약 작업 폴더의 모든 예약 작업에서 공유 | - 현재 지정된 Runner에서 예약 작업 폴더는 모든 예약 작업 및 테스트 시나리오에서 사용할 수 있는 환경/전역 변수를 저장하기 위한 파일을 가집니다.
- 현재 폴더 내 모든 예약 작업의 모든 테스트 시나리오는 이 파일의 변수를 읽고 쓸 수 있습니다.
| 영향이 가장 큰 최대 변수 범위입니다. 특정 예약 작업을 실행하면서 변수 값이 수정되어 다른 예약 작업이 실패할 가능성이 있습니다. 동일한 폴더의 여러 작업 간에 데이터를 공유해야 할 때 적합합니다. |
Modified at 2026-06-09 08:53:32
