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

SOA 테스트란 무엇입니까?

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

SOA란 무엇입니까?

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

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

SOA의 소프트웨어 개발자는 SOA라는 프로그램 덩어리를 개발하거나 구매합니다. 서비스.

서비스란 무엇입니까?

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

웹 서비스

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

웹에 게시하고, 검색하고, 사용할 수 있습니다. 그들은 인터넷을 통해 의사소통을 할 수 있습니다.

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

예시

웹사이트의 홈 페이지와 검색 엔진에는 매일의 날씨 정보가 표시됩니다. 일기 예보 섹션 전체를 코딩하는 대신 공급업체로부터 일기 예보 서비스를 구입하여 페이지에 통합할 수 있습니다.

SOA 테스트

SOA는 다양한 기술로 구성됩니다. SOA를 사용하여 구축된 애플리케이션에는 느슨하게 결합된 다양한 서비스가 있습니다.

SOA 테스트는 3가지 시스템 계층에 중점을 두어야 합니다.

서비스 계층

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

예를 들면 –

다음으로 구성된 웰니스 웹사이트를 고려해보세요.

1. 무게 추적기
2. 혈당 추적기
3. 혈압 추적기

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

• 체중 추적 서비스
• 혈당 추적기 서비스
• 혈압 추적기 서비스
• 로그인 서비스

프로세스 레이어

프로세스 계층은 단일 기능의 일부인 서비스 모음인 프로세스로 구성됩니다.

프로세스는 사용자 인터페이스(예: 검색 엔진)의 일부, ETL 도구(데이터베이스에서 데이터를 가져오기 위한)의 일부일 수 있습니다.

이 계층의 주요 초점은 사용자 인터페이스와 프로세스에 있습니다.

체중 추적기의 사용자 인터페이스와 데이터베이스와의 통합이 주요 초점입니다.

아래 기능을 고려할 것입니다.

1. 새 데이터 추가
2. 기존 데이터 편집
3. 새 트래커 만들기
4. 데이터 삭제

소비자 계층

이 계층은 주로 사용자 인터페이스로 구성됩니다.

계층을 기반으로 SOA 애플리케이션 테스트는 세 가지 수준으로 분산됩니다.

1. 서비스 수준
2. 인터페이스 수준
3. 엔드투엔드 수준

• 테스트 설계에는 하향식 접근 방식이 사용됩니다.
• 테스트 실행에는 상향식 접근 방식이 사용됩니다.

SOA 테스트 전략

테스트 계획 접근 방식,

• SOA 테스터는 애플리케이션의 전체 아키텍처를 이해해야 합니다.
• 애플리케이션은 독립적인 서비스(자체 요청 및 응답 구조를 가지며 응답을 형성하기 위해 다른 서비스에 의존하지 않는 서비스)로 분할되어야 합니다.
• 애플리케이션 구조는 데이터, 서비스, 프런트 엔드 애플리케이션의 세 가지 구성 요소로 재구성되어야 합니다.
• 모든 구성 요소를 주의 깊게 분석하고 비즈니스 시나리오를 작성해야 합니다.
• 비즈니스 시나리오는 일반 시나리오와 애플리케이션별 시나리오로 분류되어야 합니다.
• A 추적 성 매트릭스 준비해야 하며 모든 테스트 사례는 비즈니스 시나리오를 추적해야 합니다.

테스트 실행 접근 방식

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

SOA 테스트 방법

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

• 시스템과 관련된 다양한 비즈니스 측면을 분석해야 합니다.
• 시나리오는 다음의 통합을 기반으로 개발되어야 합니다.
• 여러 웹 서비스 응용 프로그램의
• 웹 서비스 및 애플리케이션.
• 위의 시나리오를 기반으로 데이터 설정을 수행해야 합니다.
• 엔드투엔드 시나리오도 포괄할 수 있도록 데이터 설정을 수행해야 합니다.

2) 스텁

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

3) 회귀 테스트

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

4) 서비스 수준 테스트

서비스 수준 테스트에는 기능, 보안, 성능 및 상호 운용성에 대한 구성 요소 테스트가 포함됩니다.

각각의 모든 서비스는 먼저 독립적으로 테스트되어야 합니다.

5) 기능 테스트

기능 테스트는 각 서비스에 대해 수행되어야 합니다.

• 서비스가 각 요청에 대해 올바른 응답을 제공하는지 확인하세요.
• 잘못된 데이터, 잘못된 데이터 등의 요청에 대해 올바른 오류가 수신됩니다.
• 서비스가 런타임에 수행해야 하는 각 작업에 대한 각 요청과 응답을 확인합니다.
• 서버, 클라이언트 또는 네트워크 수준에서 오류가 발생할 때 오류 메시지를 확인합니다.
• 수신된 응답이 올바른 형식인지 확인하십시오.
• 요청한 데이터에 해당하는 응답으로 수신된 데이터를 검증합니다.

6) 보안 테스트

웹 서비스의 보안 테스트는 SOA 애플리케이션의 서비스 수준 테스트 중 중요한 측면입니다. 이는 애플리케이션의 안전을 보장합니다.

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

• 웹 서비스는 WS-Security 테스트에서 정의한 산업 표준을 준수해야 합니다.
• 보안 조치는 완벽하게 작동해야 합니다.
• 데이터 암호화 및 Digi문서에 대한 총 서명
• 인증 및 승인
• SQL 주입, 악성 코드, XSS, CSRF, 기타 취약점은 XML에서 테스트됩니다.
• 서비스 거부 공격

7) 성능 테스트

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

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

• 서비스의 성능과 기능은 과부하 상태에서 테스트되어야 합니다.
• 서비스의 성능은 개별적으로 작업하는 동안과 결합된 애플리케이션 내에서 비교되어야 합니다.
• 서비스의 부하 테스트를 수행해야 합니다.
• 응답 시간을 확인하기 위해
• 병목 현상을 확인하기 위해
• CPU와 메모리의 활용도를 확인하기 위해
• 확장성을 예측하기 위해

8) 통합 수준 테스트

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

9) 엔드 투 엔드 테스트

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

아래 항목은 전체 테스트 중에 테스트되도록 보장됩니다.

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

SOA 테스트의 과제

• 서비스 인터페이스 부족
• 테스트 프로세스는 여러 시스템에 걸쳐 진행되므로 복잡한 데이터 요구 사항이 발생합니다.
• 응용 프로그램은 변경되는 경향이 있는 다양한 구성 요소의 모음입니다. 회귀 테스트의 필요성이 더 자주 발생합니다.
• 다층 구조로 인해 결함을 분리하기가 어렵습니다.
• 서비스는 다양한 인터페이스에서 사용되므로 부하를 예측하기 어렵고 성능 테스트 계획이 번거롭습니다.
• SOA는 이기종 기술의 모음입니다. SOA 애플리케이션을 테스트하려면 다양한 기술 세트를 가진 사람들이 필요하며, 이는 계획 및 실행 비용을 증가시킵니다.
• 애플리케이션은 여러 서비스의 통합이므로 보안 테스트에는 그 자체로 문제가 있습니다. 인증 및 승인 유효성 검사는 매우 어렵습니다.

SOA 테스트 사용 사례

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

주문 처리

PHASE 1

SOA 테스트의 첫 번째 단계, 즉 테스트 전략 단계에서 애플리케이션은 서비스와 비즈니스 기능으로 구분됩니다.

아래에서 애플리케이션의 서비스를 고려해 보겠습니다.

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

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

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

PHASE 2

테스트 계획 단계. 테스트 케이스는 각 레벨별로 작성됩니다.

1. 엔드투엔드 수준. 테스트 사례는 각 비즈니스 사용 사례 및 흐름에 대해 작성됩니다. 아래는 테스트 케이스 예시입니다
   • 활성 사용자로 주문을 생성합니다.
   • 비활성 사용자로 주문을 생성합니다.
   • 주문 수량 < 사용 가능 수량으로 사용 가능한 제품으로 주문을 생성합니다.
   • 주문수량 > 사용가능수량으로 사용가능상품으로 주문을 생성합니다.
   • 여러 항목으로 주문 만들기
   • 주문을 완전히 취소합니다.
   • 부분적으로 주문을 취소합니다.
2. 통합 수준. 데이터베이스와 사용자 인터페이스의 통합을 위해 테스트 케이스가 작성되었습니다. 아래는 예시 테스트 케이스입니다.
   • 단일 항목으로 새 주문을 생성합니다. 데이터베이스에 주문이 생성되었는지 확인합니다.
   • 단일 항목으로 새 주문을 생성합니다. 주문에 대해 계산된 가격이 올바른지 확인하십시오.
   • 단일 항목으로 새 주문을 생성합니다. 구매 가능한 상품의 수량이 주문 금액보다 적은지 확인하세요.
   • UI에 표시된 주문 상태가 데이터베이스의 주문 상태와 동일한지 확인하세요.
   • 주문을 취소하고 데이터베이스에서 주문 상태가 수정되었는지 확인하세요.
   • 최초 결제 시, UI에 입력한 결제 세부정보가 데이터베이스에 저장되었는지 확인하세요.
   • 결제 반환의 경우, 데이터베이스의 결제 세부정보가 UI에 표시되는지 확인하세요.
3. 서비스 수준. 각 서비스는 모든 데이터 조건에 대해 테스트됩니다.

다음은 몇 가지 예입니다.

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

3단계 – 테스트 실행

테스트 실행은 상향식 접근 방식을 사용합니다. 즉, 서비스 수준 테스트가 먼저 수행된 다음 통합 수준, 마지막으로 수행됩니다. 엔드 투 엔드 테스트.

1) 서비스 수준

우리가 그것을 고려하자 비누이 응용 프로그램을 테스트하기 위해 도구가 고려됩니다.

이 어플리케이션에는 XNUMXµm 및 XNUMXµm 파장에서 최대 XNUMXW의 평균 출력을 제공하는 wsdl 및 URL은 SOAP의 테스트 창으로 탐색됩니다.

각 서비스에 대한 요청은 요청 창에 표시됩니다.

서비스 수준 테스트 케이스에 따라 데이터를 수정하여 각 테스트 케이스에 대한 요청이 생성됩니다.

테스트 케이스	의뢰	예상되는 반응
주문을 생성합니다. 품목 수 = 주문 수량 1개 < DB 수량	x2 2	o3251 성공적인
주문번호 생성 품목 수 > 주문 수량 1개 < DB 수량	y1 1 y2 삼	o3251 성공적인
주문번호를 생성하세요. 품목 수 = 주문 수량 1개 > DB 수량	x23 200	없는 실패
데이터베이스의 주문 상태 확인 상태 = 활성	o9876	활동적인 성공적인
데이터베이스의 주문 상태 확인 상태 = 배송됨	o9656	배송됨 성공적인
주문 상태 확인주문 ID = 유효하지 않음	y5686	없는 실패
제품 가용성 확인제품 수량 >0	d34	34 예 성공적인
제품 가용성 확인제품 수량 =0	y34	0 아니요 성공적인
제품 가용성 확인제품 ID = 유효하지 않음	sder	실패

2) 통합 수준

통합 수준 테스트 사례는 사용자 인터페이스와 데이터베이스에서 실행됩니다.

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

3) 엔드투엔드 수준

비즈니스 흐름과 사용 사례는 사용자 인터페이스에서 실행됩니다.

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

결론

좋은 서비스를 제공하기 위한 테스트, 리소스, 도구 및 규정 준수에 대한 올바른 전략을 스케치함으로써 SOA 테스트는 완전하고 완벽하게 테스트된 애플리케이션을 제공할 수 있습니다.