SOAP는 사라지지 않았습니다. 은행 시스템, 결제 게이트웨이, 정부 서비스 및 오래된 엔터프라이즈 플랫폼은 여전히 SOAP 엔드포인트를 노출하며, 누군가는 이를 테스트해야 합니다. REST와 JSON만을 다루는 커리어를 보냈다면, SOAP 서비스는 낯설게 느껴질 수 있습니다. 프로토콜은 더 엄격하고, 페이로드는 XML이며, 계약은 별도의 WSDL 파일에 존재합니다.
다행스럽게도 SOAP API 온라인 테스트는 실제 요구 사항을 이해하면 어렵지 않습니다. 이 가이드는 SOAP 테스트가 REST 테스트와 어떻게 다른지 설명하고, 실제 요청을 살펴보고, 번거로움 없이 SOAP를 처리하는 온라인 도구를 소개합니다.
SOAP 테스트가 다른 이유
REST는 스타일입니다. SOAP는 규칙을 가진 프로토콜입니다. 이러한 차이가 테스트 방식의 모든 것을 결정합니다.
SOAP 메시지는 항상 엔벨로프(envelope)에 래핑된 XML 문서입니다. 엔벨로프는 인증이나 라우팅과 같은 메타데이터를 위한 헤더와 실제 작업 및 매개변수를 담는 바디(body)를 가집니다. 느슨한 JSON 객체를 보낼 수는 없습니다. 구조는 필수적이며, 형식이 잘못된 엔벨로프는 로직이 실행되기 전에 거부됩니다. 또한 SOAP는 데이터를 읽는 작업에서도 거의 항상 HTTP POST를 통해 전송되며, 특정 Content-Type(일반적으로 text/xml 또는 application/soap+xml)을 예상합니다.
가장 큰 실질적인 차이점은 WSDL입니다. WSDL(웹 서비스 기술 언어) 파일은 서비스가 제공하는 모든 작업, 각 요청 및 응답의 정확한 형태, 그리고 엔드포인트 주소를 나열하는 기계 판독 가능한 계약입니다. REST는 이렇게 엄격한 것을 거의 제공하지 않습니다. SOAP를 테스트할 때 WSDL은 당신의 지도입니다. 좋은 온라인 SOAP 테스터는 WSDL을 읽고 요청 템플릿을 생성하여, 수동으로 엔벨로프를 입력하는 수고를 덜어줍니다. 더 넓은 계약 그림을 원한다면, API 계약 테스트에 대한 저희 글에서 엄격한 계약이 왜 자산이 되는지 설명합니다.
실제 SOAP 요청은 어떤 모습인가요?
다음은 통화 변환 서비스에 대한 실제 SOAP 요청입니다. 엔벨로프, 네임스페이스 선언, 그리고 바디에 중첩된 작업을 주목하십시오.
POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Header>
<cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
</soap:Header>
<soap:Body>
<cur:ConvertAmount>
<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
</cur:ConvertAmount>
</soap:Body>
</soap:Envelope>
응답은 동일한 방식으로 래핑되어 돌아옵니다:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Body>
<cur:ConvertAmountResponse>
<cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
</cur:ConvertAmountResponse>
</soap:Body>
</soap:Envelope>
두 가지 세부 사항이 사람들을 혼란스럽게 합니다. SOAPAction HTTP 헤더는 많은 서비스에서 필수적이며 작업과 일치해야 합니다. 그렇지 않으면 오류(fault)를 받게 됩니다. 그리고 무언가가 실패할 때, SOAP는 깔끔한 메시지와 함께 HTTP 400을 반환하지 않습니다. 대신 바디 안에 <soap:Fault> 요소를 포함한 HTTP 200을 반환합니다. 테스트는 호출이 실제로 성공했는지 알기 위해 바디를 파싱해야 합니다. 상태 코드만 확인하는 것으로는 충분하지 않으며, 이것이 바로 구조화된 API 어설션이 REST보다 여기에서 더 중요한 이유 중 하나입니다.
SOAP API 테스트를 위한 온라인 도구
Apidog
Apidog는 REST, GraphQL, WebSocket과 함께 SOAP를 한곳에서 처리합니다. WSDL을 임포트하면 요청 구조를 생성하여 수동으로 엔벨로프를 만들 필요가 없습니다. XML 요소에 대한 어설션을 추가하고, 요청을 시나리오로 연결하며, 전체를 자동화된 스위트로 실행할 수 있습니다. API를 설계하고 모킹하는 기능도 제공하므로, 실제 서비스가 준비되기 전에 SOAP 응답을 모킹할 수 있습니다. 무료 티어에서 SOAP 서비스를 테스트하려면 Apidog를 다운로드하십시오.
SoapUI
SoapUI는 오리지널 SOAP 테스트 도구이며 여전히 가장 깊이 있는 기능을 제공합니다. WSDL을 가리키면 모든 작업이 포함된 프로젝트를 구축합니다. 오픈 소스 에디션은 기능 및 데이터 기반 SOAP 테스트에 무료로 강력하게 사용할 수 있습니다. 더 무거운 Java 데스크톱 애플리케이션이며, 가장 세련된 보고 기능은 유료 ReadyAPI 티어에 있습니다. 자세한 내용은 SoapUI가 무엇이며 어떻게 작동하는지를 참조하십시오.
Postman
Postman은 SOAP 요청을 보낼 수 있습니다. 바디를 원시 XML로 설정하고, Content-Type 및 SOAPAction 헤더를 수동으로 추가한 다음, 엔벨로프를 붙여넣습니다. 작동은 하지만, Postman은 WSDL을 파싱하지 않으므로 엔벨로프를 직접 구축해야 합니다. 일회성 확인에는 괜찮지만, 광범위한 SOAP 인터페이스에는 덜 편리합니다.
브라우저 기반 SOAP 테스터
여러 경량 웹 도구를 사용하면 WSDL URL을 붙여넣고 브라우저 탭에서 요청을 실행할 수 있습니다. 설치할 필요 없이 빠른 확인에 편리합니다. 그러나 얇은 어설션 지원, 자동화 기능 부족 또는 부재, 실제 테스트 스위트를 구성할 방법이 없다는 점에서 한계가 빠르게 드러납니다. 엔드포인트가 활성 상태인지 확인하는 데 사용하고, 회귀 테스트 스위트를 구축하는 데는 사용하지 마십시오.
빠른 SOAP 테스트 워크플로우
- WSDL 가져오기. 대부분의 SOAP 서비스는 엔드포인트 URL에
?wsdl을 추가하여 WSDL을 노출합니다. 이를 열어서 로드되는지 확인하십시오. - WSDL을 도구로 임포트. Apidog와 SoapUI는 이를 통해 요청 템플릿을 생성합니다. 이것이 가장 큰 시간 절약 요소입니다.
- 작업 매개변수 채우기. 실제 값을 사용하십시오. 실제 금액과 유효한 통화 코드로 통화 변환을 테스트하십시오.
- 헤더 설정.
Content-Type과 필요할 경우SOAPAction을 확인하십시오.SOAPAction누락은 설명되지 않는 오류의 가장 흔한 원인입니다. - 바디 전송 및 검사. HTTP 상태 코드에서 멈추지 마십시오. 응답 바디를 열어
<soap:Fault>가 있는지 확인하십시오. - 어설션 추가. 특정 요소가 존재하고 예상 값을 포함하는지 어설션하십시오. 그런 다음 워크플로우에 필요한 경우 후속 호출을 연결하십시오.
유지 보수 가능한 세트로 이들을 구성하는 데 있어서, API 자동화를 위한 테스트 스위트 구축에 대한 저희 가이드는 SOAP 작업에도 직접적으로 적용됩니다.
SOAP 오류 및 어설션 방법
SOAP 오류(fault)는 프로토콜의 오류 구조입니다. faultcode, faultstring, 그리고 때로는 detail 요소를 포함합니다. HTTP 200과 함께 도착하기 때문에, 상태만 확인하는 테스트는 실패한 호출에서도 통과할 것입니다. 이는 조용하고 위험한 오탐(false positive)입니다.
바디 내부를 확인하도록 SOAP 어설션을 작성하십시오. 성공 경로에서는 <soap:Fault> 요소가 없는지 어설션하십시오. 의도적인 오류 경로에서는 반대로 오류가 나타나고 faultcode가 예상과 일치하는지 어설션하십시오. 실패 사례를 테스트하는 것은 성공 경로만큼 중요합니다. SOAP 서비스는 거부된 거래와 같은 비즈니스 규칙을 데이터 대신 오류로 인코딩하는 경우가 많기 때문입니다. 공식적인 세부 정보가 필요한 경우 W3C SOAP 오류 문서에 구조가 설명되어 있습니다.
WS-Security는 또 다른 계층을 추가합니다. 많은 엔터프라이즈 SOAP 서비스는 서명되거나 토큰을 포함하는 보안 헤더를 예상합니다. 요청이 인증 오류로 실패하는 경우, WSDL 또는 서비스 문서는 어떤 보안 프로필이 적용되는지 알려줄 것입니다. SoapUI 및 Apidog와 같은 도구를 사용하면 XML을 수동으로 작성하는 대신 이러한 헤더를 구성할 수 있습니다.
길을 잃지 않고 WSDL 읽기
WSDL 파일은 처음 열면 위협적으로 보입니다. 길고 깊이 중첩된 XML이며, 대부분은 기계적인 부분입니다. 모든 것을 읽을 필요는 없습니다. 실제로 원하는 정보를 담고 있는 네 가지 부분이 있습니다.
types 섹션은 일반적으로 XML 스키마로 데이터 구조를 정의하므로, 여기에서 각 매개변수의 정확한 형태와 제약 조건을 알 수 있습니다. message 요소는 각 작업에 대한 입력 및 출력을 설명합니다. portType은 수행할 수 있는 호출인 작업 자체를 나열합니다. service 및 binding 섹션은 구체적인 엔드포인트 주소와 전송 세부 정보를 제공합니다. WSDL을 도구로 임포트하면 이 네 가지를 모두 읽고 편집 준비가 된 요청으로 변환합니다. 이것이 수동 입력보다 임포트가 항상 더 나은 이유입니다.
알아둘 가치가 있는 한 가지 세부 사항: WSDL은 import 문을 사용하여 여러 파일로 분할될 수 있으며, 종종 별도의 위치에서 스키마를 가져옵니다. 도구가 누락된 유형을 보고하는 경우, 참조된 파일이 해결되지 않았을 가능성이 있습니다. 도구가 실행되는 위치에서 임포트된 모든 URL에 접근할 수 있는지 확인하십시오. 이러한 종류의 계약 종속성은 팀이 WSDL을 서버에만 존재하는 것이 아니라 버전 관리되는 아티팩트로 취급하는 정확한 이유입니다.
데이터 기반 SOAP 테스트
SOAP 서비스는 엄격한 비즈니스 규칙을 포함하는 경우가 많으며, 단일 성공 경로 요청만으로는 많은 것을 증명하기 어렵습니다. 통화 서비스는 유효한 쌍, 지원되지 않는 통화, 0 금액, 음수 금액으로 테스트되어야 합니다. 결제 서비스는 승인된 카드, 거부된 카드, 만료된 카드로 테스트되어야 합니다. 이들 각각을 수동으로 입력하는 것은 느리고 오류가 발생하기 쉽습니다.
데이터 기반 테스트는 이 문제를 해결합니다. 요청을 플레이스홀더와 함께 한 번 작성한 다음, 입력 행과 예상 결과 테이블을 제공합니다. 도구는 각 행에 대해 요청을 실행하고 각 결과를 확인합니다. SoapUI는 수년 동안 이 패턴을 지원해왔고, Apidog는 시나리오 러너를 통해 이를 지원합니다. 그 결과는 SOAP 서비스가 오류로 인코딩하는 경향이 있는 엣지 케이스에 대한 실제 적용 범위를 제공합니다. 더 넓은 패턴에 대해서는, CSV 및 JSON을 사용한 데이터 기반 API 테스트에 대한 저희 가이드가 입력 데이터를 구성하는 방법을 설명하며, 이는 REST와 마찬가지로 SOAP에도 적용됩니다.
자주 묻는 질문
SOAP와 REST 테스트의 차이점은 무엇인가요?
SOAP 테스트는 WSDL 계약, 필수 엔벨로프, HTTP 200 바디 내에 반환되는 오류를 가진 엄격한 XML 프로토콜을 기반으로 작동합니다. REST 테스트는 일반적으로 JSON, 더 느슨한 규칙, 의미 있는 HTTP 상태 코드를 다룹니다. SOAP 테스트는 성공을 확인하기 위해 응답 바디를 파싱해야 하지만, REST 테스트는 종종 상태 코드를 신뢰할 수 있습니다.
SOAP API를 테스트하는 데 WSDL이 필요한가요?
정확한 엔벨로프 구조를 이미 알고 있다면 WSDL 없이도 SOAP 요청을 보낼 수 있습니다. 그러나 WSDL은 도구가 올바른 요청 템플릿을 생성해주기 때문에 테스트를 훨씬 쉽게 만듭니다. 대부분의 서비스는 엔드포인트 URL에 ?wsdl을 추가하여 WSDL을 노출합니다. 항상 거기서부터 시작하십시오.
상태가 200인데도 SOAP 요청이 오류를 반환하는 이유는 무엇인가요?
SOAP는 오류를 HTTP 오류 코드가 아닌 바디 내의 <soap:Fault> 요소로 보고하므로, 오류가 포함된 200은 정상입니다. 일반적인 원인으로는 SOAPAction 헤더 누락 또는 오류, 잘못된 형식의 엔벨로프, 네임스페이스 불일치 또는 보안 확인 실패가 있습니다. 구체적인 이유를 알려면 faultstring을 읽으십시오.
SOAP API를 온라인에서 무료로 테스트할 수 있나요?
예. Apidog는 무료 티어에서 SOAP를 지원하고 WSDL 파일을 임포트할 수 있으며, SoapUI의 오픈 소스 에디션은 SOAP를 위해 제작되었습니다. 가벼운 브라우저 테스터도 빠른 확인을 위해 존재하지만, 실제 어설션 및 자동화 지원이 부족합니다.
SOAP API 테스트를 자동화하는 방법은 무엇인가요?
WSDL을 임포트하고, 작업을 순서대로 연결하는 시나리오를 구축하고, 응답 요소 및 오류 부재에 대한 어설션을 추가한 다음, 도구의 러너 또는 CI 파이프라인에서 실행하십시오. SoapUI와 Apidog는 모두 예약되거나 파이프라인으로 트리거되는 SOAP 스위트를 지원하므로, SOAP 회귀 실행은 REST와 동일한 자동화 흐름에 맞습니다.