SOA 테스트란 무엇입니까? 예제가 포함된 튜토리얼

SOA 테스트란 무엇입니까?

SOA(서비스 지향 Archi(구조) 테스트 이는 SOA 아키텍처 스타일을 테스트하는 것으로, 애플리케이션 구성 요소들이 일반적으로 네트워크를 통해 통신 프로토콜로 통신하도록 설계된 방식입니다.

SOA란 무엇입니까?

SOA는 비즈니스 요구 사항을 충족하기 위해 비즈니스 애플리케이션과 프로세스를 함께 통합하는 방법입니다.

In 소프트웨어 공학SOA는 비즈니스 프로세스에 민첩성과 유연성을 제공합니다. 프로세스나 애플리케이션에 대한 변경 사항은 전체 시스템에 영향을 주지 않고 특정 구성 요소에만 적용할 수 있습니다.

SOA 분야에서 일하는 소프트웨어 개발자들은 프로그램 덩어리를 직접 개발하거나 구매합니다. 서비스.

서비스란 무엇입니까?

아래 다이어그램은 여러 전자상거래 사이트에서 호출할 수 있도록 서비스로 게시된 결제 게이트웨이를 보여줍니다.

• 서비스는 애플리케이션이나 비즈니스 프로세스의 기능 단위로, 다른 애플리케이션이나 프로세스에서 재사용 또는 반복될 수 있습니다. (예를 들어, 위 이미지에서 결제 게이트웨이는 모든 전자상거래 사이트에서 재사용할 수 있는 서비스입니다. 결제가 필요할 때마다 전자상거래 사이트는 결제 게이트웨이 서비스를 호출하거나 요청합니다. 게이트웨이에서 결제가 완료되면 전자상거래 웹사이트로 응답이 전송됩니다.)
• 서비스는 쉽게 조립되고 구성 요소를 쉽게 재구성할 수 있습니다.
• 서비스는 빌딩 블록에 비유할 수 있습니다. 필요한 모든 애플리케이션을 구성할 수 있으며, 애플리케이션이나 비즈니스 프로세스에서 서비스를 추가하거나 제거하는 것도 쉽습니다.
• 서비스는 코드 덩어리라기보다는 수행하는 비즈니스 기능에 따라 정의되는 경우가 많습니다.

웹 서비스

대부분의 SOA 서비스는 웹 서비스로 제공되므로 테스트 계층을 구축하기 전에 웹 서비스 호출의 메커니즘을 명확히 정의하는 것이 중요합니다.

웹 서비스 웹을 통해 사용할 수 있는 독립적인 애플리케이션 구성 요소입니다.

이러한 정보는 웹상에 게시되고, 검색되고, 사용될 수 있으며, 인터넷을 통해 서로 소통합니다. 아래 그림은 제공자, 등록기관, 그리고 소비자가 어떻게 상호작용하는지를 보여줍니다.

• 서비스 공급자는 서비스를 인터넷에 게시합니다.
• 클라이언트는 웹 서비스 레지스트리에서 특정 웹 서비스를 검색합니다.
• A URL 그리고 wsdl 필요한 웹 서비스에 대한 정보가 반환됩니다. WSDL과 URL서비스 제공자와 요청자 간의 통신은 SOAP 메시지를 통해 이루어집니다.
• 소비자가 웹 서비스를 호출하면 공급자와의 HTTP 연결이 설정됩니다.
• SOAP 메시지는 공급자에게 필요한 웹 서비스 로직을 호출하도록 지시하기 위해 생성됩니다.
• 공급자로부터 수신한 응답은 HTTP 응답에 포함된 SOAP 메시지입니다. 이 HTTP 응답은 소비자 애플리케이션이 이해할 수 있는 데이터 형식입니다.

예시

아래 스크린샷은 외부 서비스에서 제공받아 검색 엔진 홈페이지에 삽입된 날씨 예보를 보여줍니다.

웹사이트 홈페이지와 검색 엔진에는 매일 날씨 정보가 표시됩니다. 날씨 정보 부분을 처음부터 직접 코딩하는 대신, 공급업체로부터 날씨 정보 서비스를 구매하여 페이지에 통합할 수 있습니다.

SOA 테스트 레이어

SOA는 다양한 기술로 구성되며, SOA를 사용하여 구축된 애플리케이션은 느슨하게 결합된 다양한 서비스를 포함합니다. 아래 다이어그램은 테스트 계획이 다뤄야 할 세 가지 계층을 보여줍니다.

SOA 테스트는 시스템의 세 가지 계층에 집중해야 합니다.

서비스 계층

이 계층은 비즈니스 기능에서 파생된, 시스템이 노출하는 서비스로 구성됩니다.

예를 들어, 다음과 같은 요소로 구성된 웰빙 웹사이트를 생각해 보세요.

• 중량(평량) TracKER
• 혈당 TracKER
• 고혈압 TracKER

Trackers는 해당 데이터와 입력 날짜를 표시합니다. 서비스 계층은 데이터베이스에서 해당 데이터를 가져오는 서비스로 구성됩니다.

• 중량(평량) Trac케르 서비스
• 혈당 Trac케르 서비스
• 고혈압 Trac케르 서비스
• 로그인 서비스

프로세스 레이어

프로세스 계층은 프로세스, 즉 단일 기능의 일부를 구성하는 서비스들의 모음으로 이루어져 있습니다.

이러한 프로세스는 사용자 인터페이스(예: 검색 엔진)의 일부일 수도 있고, 데이터베이스에서 데이터를 추출하는 ETL 도구의 일부일 수도 있습니다.

이 계층의 주요 초점은 사용자 인터페이스와 프로세스입니다. 가중치의 사용자 인터페이스가 여기에 해당합니다. trac핵심은 커널과 데이터베이스의 통합입니다.

다음 기능들이 고려 대상입니다:

• 새 데이터 추가
• 기존 데이터 편집
• 새로 만들기 tracKER
• 데이터 삭제

소비자 계층

이 계층은 아래 화면에서 볼 수 있듯이 주로 사용자 인터페이스로 구성됩니다.

이러한 계층 구조를 기반으로 SOA 애플리케이션 테스트는 세 단계로 나뉩니다.

• 서비스 수준
• 인터페이스 수준
• 엔드투엔드 수준

두 가지 진행 방향은 서로 다릅니다. 테스트 설계에는 하향식 접근 방식이 사용되는 반면, 테스트 실행에는 상향식 접근 방식이 사용됩니다.

SOA 테스트 전략

테스트 계획 접근법

• SOA 테스터는 애플리케이션의 전체 아키텍처를 이해해야 합니다.
• 애플리케이션을 독립적인 서비스(자체적인 요청 및 응답 구조를 가지고 있으며 응답을 생성하기 위해 다른 서비스에 의존하지 않는 서비스)로 분해해야 합니다.
• 애플리케이션 구조를 데이터, 서비스, 프런트엔드 애플리케이션의 세 가지 구성 요소로 재구성해야 합니다.
• 모든 구성 요소를 신중하게 분석하고 비즈니스 시나리오를 수립해야 합니다.
• 비즈니스 시나리오는 공통 시나리오와 애플리케이션별 시나리오로 분류해야 합니다.
• A Trac능력 매트릭스 모든 테스트 케이스를 준비해야 하며, 모든 테스트 케이스는 다음과 같아야 합니다. trac비즈니스 시나리오에 맞춰 조정되었습니다.

테스트 실행 접근 방식

• 각 서비스 구성 요소를 테스트해야 합니다.
• 통합 테스팅 서비스 및 데이터 무결성을 통한 데이터 흐름의 유효성을 검사하려면 서비스 구성 요소 중 하나를 수행해야 합니다.
• 시스템 테스트 전체 모델에 대한 검증을 통해 프런트엔드 애플리케이션과 데이터베이스 간의 데이터 흐름을 확인해야 합니다.
• 성능 시험 미세 조정과 최적의 성능을 위해 수행되어야 합니다.

SOA 테스트 방법

1) 비즈니스 시나리오 기반 데이터 테스트

• 시스템과 관련된 다양한 비즈니스 측면을 분석해야 합니다.
• 애플리케이션의 다양한 웹 서비스 통합 및 웹 서비스와 애플리케이션 간의 통합을 기반으로 시나리오를 개발해야 합니다.
• 데이터 설정은 위의 시나리오를 기반으로 진행해야 합니다.
• 데이터 설정은 엔드 투 엔드 시나리오를 모두 포함해야 합니다.

2) 스텁

• 더미 인터페이스는 서비스를 테스트하기 위해 생성됩니다.
• 이러한 인터페이스를 통해 다양한 입력을 제공할 수 있으며 출력을 검증할 수 있습니다.
• 애플리케이션이 테스트 대상이 아닌 외부 서비스(타사 서비스)에 대한 인터페이스를 사용하는 경우, 통합 테스트 중에 스텁을 생성할 수 있습니다.

3) 회귀 테스트

• Regression Testing 애플리케이션에 대한 업데이트는 여러 릴리스가 있을 때 수행되어야 시스템의 안정성과 가용성을 보장할 수 있습니다.
• 애플리케이션의 중요한 부분을 구성하는 서비스를 포괄하는 포괄적인 회귀 테스트 스위트가 생성됩니다.
• 이 테스트 스위트는 프로젝트의 여러 릴리스에서 재사용할 수 있습니다.

4) 서비스 수준 테스트

서비스 수준 테스트는 구성 요소의 기능, 보안, 성능 및 상호 운용성을 테스트하는 것을 포함합니다. 모든 서비스는 먼저 개별적으로 테스트되어야 합니다.

5) 기능 테스트

기능 테스트 각 서비스에 대해 다음 작업을 수행해야 합니다.

• 서비스가 각 요청에 대해 올바른 응답을 제공하는지 확인하십시오.
• 유효하지 않거나 잘못된 데이터가 포함된 요청에 대해 올바른 오류 메시지가 수신되도록 하십시오.
• 서비스가 실행 중에 수행해야 하는 모든 작업에 대한 각 요청과 응답을 확인하십시오.
• 서버, 클라이언트 또는 네트워크 수준에서 오류가 발생할 때 오류 메시지의 유효성을 검사합니다.
• 수신된 응답이 올바른 형식인지 확인하십시오.
• 응답으로 받은 데이터가 요청한 데이터와 일치하는지 검증합니다.

6) 보안 테스트

웹 서비스 보안 테스트는 SOA 애플리케이션의 서비스 수준 테스트에서 중요한 부분입니다. 왜냐하면 애플리케이션의 안전성을 보장하기 때문입니다.

테스트 중에는 다음과 같은 요소가 고려되어야 합니다.

• 웹 서비스는 WS-Security에서 정의한 업계 표준을 준수해야 합니다.
• 보안 조치는 완벽하게 작동해야 합니다.
• 데이터 암호화 및 문서에 대한 디지털 서명.
• 인증 및 권한 부여.
• SQL 인젝션, 멀웨어, XSS, CSRF 및 기타 취약점을 테스트해야 합니다. XML.
• 서비스 거부 공격.

7) 성능 테스트

서비스는 재사용 가능하며 여러 애플리케이션이 동일한 서비스를 사용할 수 있으므로 서비스 성능 테스트를 수행해야 합니다.

테스트 중에는 다음과 같은 요소가 고려됩니다.

• 서비스의 성능과 기능은 과부하 상태에서 테스트되어야 합니다.
• 서비스의 성능은 개별적으로 작동할 때와 애플리케이션 내에 통합되어 작동할 때를 비교해야 합니다.
• 부하 테스트 서비스 테스트는 응답 시간 검증, 병목 현상 확인, CPU 및 메모리 사용률 검증, 확장성 예측 등을 위해 수행되어야 합니다.

8) 통합 수준 테스트

• 서비스 수준 테스트는 개별 서비스가 제대로 작동하는지 확인하는 것이며, 결합된 구성 요소들이 제대로 작동하는 것을 보장하는 것은 아닙니다.
• 통합 테스트는 주로 다음 사항에 중점을 두고 수행됩니다. 인터페이스.
• 이 단계에서는 가능한 모든 비즈니스 시나리오를 다룹니다.
• 이 단계에서는 애플리케이션의 비기능 테스트를 다시 한 번 수행해야 합니다. 보안, 규정 준수 및 성능 테스트는 시스템의 가용성과 안정성을 모든 측면에서 보장합니다.
• 통신 및 네트워크 프로토콜을 테스트하여 서비스 간 데이터 통신의 일관성을 검증해야 합니다.

9) 엔드 투 엔드 테스트

이 단계에서는 애플리케이션이 기능적 및 비기능적 측면 모두에서 비즈니스 요구 사항을 충족하는지 확인합니다.

아래 항목들은 반드시 테스트를 거칩니다. 종단 간 테스트:

• 통합 후 모든 서비스가 예상대로 작동함
• 예외 처리
• 애플리케이션의 사용자 인터페이스
• 모든 구성 요소를 통한 적절한 데이터 흐름
• 비즈니스 프로세스

SOA 테스트의 과제

이러한 방법을 적용하는 것은 결코 간단하지 않으며, 아래와 같은 어려움은 거의 모든 SOA 프로그램에서 반복적으로 발생합니다.

• 서비스용 인터페이스 부족.
• 테스트 과정은 여러 시스템에 걸쳐 진행되므로 복잡한 데이터 요구 사항이 발생합니다.
• 해당 애플리케이션은 변경되는 경향이 있는 다양한 구성 요소의 모음이므로 회귀 테스트가 더 자주 필요합니다.
• 다층 구조로 인해 결함을 분리하기 어렵습니다.
• 하나의 서비스가 여러 인터페이스에서 사용되기 때문에 부하를 예측하기 어렵고, 이로 인해 성능 테스트 계획 수립이 복잡해집니다.
• SOA는 다양한 기술들이 모여 있는 개념입니다. SOA 애플리케이션 테스트에는 각기 다른 기술 수준을 가진 인력이 필요하므로 계획 및 실행 비용이 증가합니다.
• 이 애플리케이션은 여러 서비스를 통합하기 때문에 보안 테스트에 어려움이 많습니다. 인증 및 권한 부여를 검증하는 것이 까다롭습니다.

SOA 테스트 도구

시중에는 테스터가 SOA 애플리케이션을 테스트하는 데 도움이 되는 다양한 SOA 테스트 도구가 있습니다. 다음은 몇 가지 인기 있는 SOA 테스트 도구입니다.

1) SoapUI

SoapUI 는 서비스용 오픈소스 기능 테스트 도구입니다. API 테스트.

• 데스크탑 애플리케이션
• SOAP, REST, HTTP, JMS, AMF, JDBC 등 다양한 프로토콜을 지원합니다.
• 웹 서비스는 개발, 검사 및 호출이 가능합니다.
• 부하 시험에도 사용할 수 있습니다. 자동화 테스트및 보안 테스트
• 스텁은 MockServices에서 생성할 수 있습니다.
• 웹 서비스 클라이언트를 통해 웹 서비스 요청 및 테스트를 자동으로 생성할 수 있습니다.
• 내장된 보고 도구를 갖추고 있습니다.
• SmartBear에서 개발했으며, SmartBear는 다음 두 제품을 모두 배송합니다. 오픈 소스 SoapUI 유통 및 상업 ReadyAPI 판

2) 브로드컴 서비스 가상화(구 iTKO LISA)

LISA는 SOA와 같은 분산 시스템을 위한 기능 테스트 솔루션을 제공하는 제품군입니다. 이 제품은 iTKO에서 CA Technologies로 넘어갔으며 현재는 Broadcom Service Virtualization이라는 이름으로 판매되고 있습니다.

• 회귀 테스트, 통합 테스트, 부하 테스트 및 성능 테스트에도 사용할 수 있습니다.
• 테스트를 설계하고 실행하는 데 사용할 수 있습니다.

3) UFT 원(이전 명칭: HP 서비스 테스트)

Service Test는 UI 테스트와 공유 서비스 테스트를 모두 지원하는 기능 테스트 도구입니다. API 테스트 기능은 Unified Functional Testing에 통합되었으며, 현재는 다른 회사에서 판매하고 있습니다. OpenText as UFT 하나.

• 서비스의 기능 테스트와 성능 테스트 모두 단일 스크립트로 수행할 수 있습니다.
• 품질 센터와 통합되어 현재 판매 중입니다. OpenText ALM/품질 센터.
• 엄청난 양의 서비스와 데이터를 관리할 수 있습니다.
• JEE, AXIS, DotNet 클라이언트 환경을 시뮬레이션하여 상호 운용성 테스트를 지원합니다.

4) 파라소프트 SOAtest

Parasoft SOAtest는 API 및 API 기반 애플리케이션 테스트를 위해 개발된 테스트 및 분석 도구 모음입니다.

• 웹 서비스, REST, JSON, MQ, JMS, TIBCO, HTTP 및 XML 기술을 지원합니다.
• 기능 테스트, 단위 테스트, 통합 테스트, 회귀 테스트, 보안 테스트, 상호 운용성 테스트, 규정 준수 테스트 및 성능 테스트가 가능합니다.
• 스텁은 다음을 사용하여 생성할 수 있습니다. 파라소프트 가상화보다 더 뛰어난 능력을 가진 SoapUI 모의서비스.

SOA 테스트 사용 사례

아래 예시에서는 위에서 설명한 전략, 방법 및 도구를 하나의 전자상거래 사이트에 단계별로 적용합니다.

다음과 같은 기능과 하위 기능을 포함하는 전자상거래 웹사이트를 생각해 보세요.

주문 처리

아래 차트는 주문 처리 과정을 서비스가 되는 하위 기능들로 나누어 보여줍니다.

PHASE 1

SOA 테스트의 첫 번째 단계인 테스트 전략 단계에서는 애플리케이션을 서비스와 비즈니스 기능으로 나눕니다.

아래 애플리케이션에서 제공되는 서비스들을 살펴보겠습니다.

• 주문 작성
• 고객 상태 확인
• 주문 상태 변경
• 주문 상태 확인
• 재고 확인

비즈니스 기능은 웹사이트의 기능과 동일합니다.

참고: 테스트 전략 문서에는 테스트해야 할 서비스 및 기능 목록이 포함되어야 합니다.

PHASE 2

이 단계는 테스트 계획 단계입니다. 테스트 케이스 각 레벨별로 작성되어 있습니다.

엔드 투 엔드 수준. 테스트 케이스는 각 비즈니스 사용 사례 및 흐름에 맞춰 작성됩니다. 아래는 테스트 케이스의 예시입니다.

• 활성 사용자를 사용하여 주문을 생성하세요.
• 비활성 사용자로 주문을 생성합니다.
• 재고가 있는 제품으로 주문 수량이 재고 수량보다 적은 주문을 생성하세요.
• 주문 수량이 재고 수량보다 많은 재고 상품으로 주문을 생성하세요.
• 여러 품목을 포함하는 주문을 생성하세요.
• 주문을 완전히 취소합니다.
• 주문을 부분적으로 취소합니다.

통합 수준. 데이터베이스와 사용자 인터페이스의 통합을 위해 테스트 케이스가 작성되었습니다. 아래는 예시 테스트 케이스입니다.

• 단일 항목으로 새 주문을 생성합니다. 데이터베이스에 주문이 생성되었는지 확인합니다.
• 단일 항목으로 새 주문을 생성합니다. 주문에 대해 계산된 가격이 올바른지 확인하십시오.
• 단일 품목으로 새 주문을 생성합니다. 재고 수량이 주문 수량만큼 감소했는지 확인합니다.
• 사용자 인터페이스에 표시된 주문 상태가 데이터베이스에 저장된 상태와 동일한지 확인하십시오.
• 주문을 취소하고 데이터베이스에서 주문 상태가 수정되었는지 확인하세요.
• 첫 결제 시에는 사용자 인터페이스에 입력한 결제 정보가 데이터베이스에 저장되었는지 확인하십시오.
• 결제 반환의 경우, 데이터베이스의 결제 세부정보가 UI에 표시되는지 확인하세요.

서비스 수준. 각 서비스는 모든 데이터 조건에 대해 테스트됩니다. 아래는 몇 가지 예입니다.

그렇지 않습니다.	주문 정보	주문조건
1	주문을 생성합니다. 항목 수 = 1	주문 수량 < 데이터베이스 수량
2	주문을 생성합니다. 항목 수 > 1	주문 수량 < 데이터베이스 수량
3	주문을 생성합니다. 항목 수 = 1	주문 수량 > 데이터베이스 수량
4	주문 상태 확인	데이터베이스 상태 = 활성
5	주문 상태 확인	데이터베이스 상태 = 배송됨
6	주문 상태 확인	데이터베이스 상태 = 취소됨
7	주문 상태 확인	주문 ID = 유효하지 않음
8	제품 가용성 확인	제품 수량 >0
9	제품 가용성 확인	제품 수량 =0
10	제품 가용성 확인	제품 ID = 유효하지 않음

3단계 — 테스트 실행

테스트 실행은 하향식 접근 방식을 사용합니다. 서비스 수준 테스트를 먼저 수행하고, 그 다음 통합 수준 테스트를 수행한 후 마지막으로 엔드투엔드 테스트를 수행합니다.

1) 서비스 수준

다음 사항을 고려해 봅시다. SoapUI 이 도구는 애플리케이션 테스트에 사용됩니다. WSDL과 URL 테스트 창에 표시됩니다. SoapUI각 서비스에 대한 요청은 요청 창에 표시됩니다. 서비스 수준 테스트 케이스에 따라 데이터를 수정하면 각 테스트 케이스에 대한 요청이 생성됩니다.

테스트 케이스	의뢰	예상되는 반응
주문 생성. 품목 수 = 1, 주문 수량 < 데이터베이스 수량	x2 2	o3251 성공적인
주문 생성. 품목 수 > 1, 주문 수량 < 데이터베이스 수량	y1 1 y2 삼	o3251 성공적인
주문 생성. 품목 수 = 1, 주문 수량 > 데이터베이스 수량	x23 200	없는 실패
주문 상태를 확인하세요. 데이터베이스 상태는 활성(Active)입니다.	o9876	활동적인 성공적인
주문 상태를 확인하세요. 데이터베이스 상태는 '배송 완료'입니다.	o9656	배송됨 성공적인
주문 상태를 확인하세요. 주문 ID = 유효하지 않음	y5686	널 실패
제품 재고를 확인하세요. 제품 수량 >0	d34	34 예 성공적인
제품 재고를 확인하세요. 제품 수량 = 0	y34	0 아니요 성공적인
제품 재고를 확인하세요. 제품 ID가 잘못되었습니다.	sder	실패

2) 통합 수준

통합 수준 테스트 케이스는 사용자 인터페이스와 데이터베이스에서 실행됩니다. 단일 품목으로 주문을 생성해 보세요.

• 사용자가 웹사이트를 엽니다.
• 사용자가 주문을 하려고 합니다.
• 사용자는 유효한 제품과 수량을 선택하고 주문을 저장합니다.
• 주문이 성공적으로 완료되었다는 메시지가 표시되어야 합니다.
• 사용자는 데이터베이스를 열어 주문 세부 정보가 웹사이트에 입력된 내용과 일치하는지 확인합니다.

3) 엔드투엔드 수준

비즈니스 흐름과 사용 사례는 사용자 인터페이스에서 실행됩니다. 여러 품목으로 주문을 생성해 보세요.

• 사용자가 웹사이트를 엽니다.
• 사용자가 주문을 하려고 합니다.
• 사용자가 원하는 제품과 수량을 문의하고 장바구니에 담습니다.
• 다른 유효한 제품들이 유효한 수량과 함께 추가되고 주문이 저장됩니다. 새로운 결제 수단을 통해 결제가 완료되면 주문이 접수됩니다.
• "주문이 성공적으로 완료되었습니다"라는 메시지가 표시되어야 합니다.
• 테스터는 데이터 왜곡 없이 전체 흐름이 완료되는지 검증해야 합니다.

자주 묻는 질문