소개

이 기사에서는 SOI(Service Oriented Integration) 유형의 인터페이스를 위한 검증 및 자동화된 ITF(Interface Test Framework)를 소개한다. 이 프레임워크는 인터페이스의 유닛 테스트를 위한 테스트 케이스를 관리하고 그룹화하는 기능과 테스트 실행 후 보고서를 생성하는 기능을 제공한다. 이 방법은 ESB(Enterprise Service Bus) 또는 미들웨어 제품에서 사용할 수 있다.

SOI(Service Oriented Integration)에는 미들웨어 환경 외부에 있는 애플리케이션 또는 데이터베이스와의 통합이 포함된다. 솔루션은 주로 제품에 의해 실행 코드로 변환되는 코드 스니펫이나 그래픽 편집기를 사용하는 미들웨어 제품을 사용하여 개발된다. 따라서 자동화된 테스트 프레임워크가 없으면 인터페이스의 개별 구성 요소를 종합적으로 테스트하기가 어렵다.

이 프레임워크를 사용하면 서비스 지향적 인터페이스에 대한 화이트박스 인터페이스 테스트를 수행할 수 있다. 화이트박스 테스트를 수행하려면 시스템을 전체적으로 가장 잘 테스트할 수 있는 방법을 파악하기 위해 내부 구조를 알아야 한다. 이 프레임워크는 구성 요소를 독립적으로 또는 적합한 스텁 및 드라이버와 함께 테스트할 수 있는 유닛 또는 구성 요소 테스트 환경을 제공하는 강력한 도구이다. 이 프레임워크는 다양한 환경에서 인터페이스의 회귀 테스트 및 스모크 테스트를 지원하도록 빠르게 확장할 수 있다. 다음과 같은 기능을 제공한다.

• 예상 결과에 대한 테스트를 수행할 수 있다.
• 공통 테스트 데이터를 공유할 수 있다.
• 특정 테스트 케이스 또는 테스트 케이스 그룹을 실행할 수 있다.

또한 요구사항을 설정하고, 아키텍처를 규정하고, 코드를 디버깅, 통합, 릴리스, 최적화 및 테스트할 수 있다.

위로

Interface Test Framework의 목적

이 프레임워크를 사용하여 테스트 케이스를 작성하면 설계 또는 구현 결함을 찾아낼 수 있다. 유닛 테스트는 ESB 시스템의 첫 번째 사용자로서 설계 문제점이나 결함이 있는 기능을 식별한다. 일반적인 수준의 개발 경험을 쌓으면 ITF에 익숙해질 수 있다. 유닛 테스트 스위트를 작성한 후에는 ESB 시스템의 사용과 관련된 문서 양식으로 사용할 수 있다. ITF를 사용하면 데이터 지향적 유닛 테스트를 쉽게 작성할 수 있으며 이러한 유닛 테스트는 데이터 소스의 레코드별로 실행되고 바인드된 해당 데이터에 대한 전체 액세스 권한을 가지고 있다.

아마도 ITF의 가장 중요한 장점 중 하나는 테스트 스위트를 잘 작성해 놓으면 원본 개발자가 유지보수 및 추가적인 기능 향상을 위해 다른 개발자에게 코드를 편하게 전달할 수 있다는 것이다. 코드를 받은 개발자가 원본 기능에 버그를 삽입하더라도 이러한 유닛 테스트는 해당 오류를 검출하고 문제점을 진단할 수 있는 강력한 기능을 제공한다.

ITF는 회귀 테스트의 핵심 요소이다. 회귀 테스트에는 새 기능을 추가한 후 오류나 버그가 발생하지 않았는지 확인하기 위해 소프트웨어를 다시 테스트하는 작업이 포함되어 있다. ITF를 사용하면 회귀 테스트 시간이 획기적으로 줄어든다.

위로

ITF 기능

다음은 ITF에서 지원하는 주요 소프트웨어 테스트 기능 중 일부이다.

테스트 지향적 개발

TDD(Test-Driven Development)는 테스트할 코드를 작성하기 전에 유닛 테스트를 작성하는 방법이다. 개발자는 시스템을 설계 및 빌드하기 전에 스펙에 따라 테스트 케이스를 작성한다. TDD는 작고 관리 가능한 단계가 포함된 연속적인 개발 주기를 따른다. ITF는 TDD 구현 지원을 통해 기업의 중추적인 역할을 맡을 수 있다.

어설션

유닛 테스트의 성공을 확인하는 가장 일반적인 방법은 예상 결과와 실제 결과를 비교하는 것이다. ITF의 어설션 기능을 통해 개발자는 예상 결과를 테스트의 출력으로 제공하고 이후에 실행한 실제 결과와 비교할 수 있다. 런타임 중에 설정된 예상 결과 내의 동적 값은 정규식 기반 비교를 사용하여 처리된다. 이 기능은 테스트 실행 비교를 위한 핵심 기능이다.

코드 검사

ITF는 코드 검사에 필요한 모든 기능을 지원한다. 코드 검사는 추적 논리를 자동으로 삽입하여 테스트를 실행하는 동안 프로세스 내에서 실행되는 활동을 모니터링한다. 이 기능의 가장 중요한 결과는 테스트되지 않은 코드 영역에 대한 식별 결과이다. 코드에는 일반적인 상황에서 실행되지 않는 분기 또는 예외 처리 논리가 있을 수 있다. 따라서 코드 검사를 사용하여 이러한 영역을 식별하는 것이 중요하다. 코드 검사가 유용한 도구이기는 하지만 이 도구에만 의지해서 유닛 테스트 효과를 확인해서는 안된다. 이 도구를 통해서는 코드의 실행 방법을 알 수 없기 때문에 다른 데이터 또는 시간을 사용할 때 발생하는 오류가 누락될 수 있다. 다양한 입력 및 실행 명령을 기반으로 하는 유닛 테스트 스위트를 사용하면 코드의 정확성, 완성도 및 복원성을 보장할 수 있다. 결과적으로 코드 검사는 테스트에서 놓친 코드를 식별하는 데 도움이 된다.

네거티브 테스트

강력한 코드는 모든 예외 시나리오를 중단 없이 깔끔하게 처리할 수 있어야 한다. 개발자는 예외가 발생할 때 코드가 올바르게 동작하는지 확인하려고 한다. 이 작업은 오류가 많거나 올바르지 않은 입력 데이터를 제공하여 수행할 수 있다. 일반적으로 예외를 발생시키는 유닛 테스트는 실패한 것으로 간주된다. ITF는 네거티브 테스트 시나리오를 지원하므로 개발자가 포지티브 테스트 케이스 또는 네거티브 테스트 케이스를 선택해서 지정할 수 있다.

로깅 및 예외 검사

좋은 코드에서는 로깅 및 예외를 효율적으로 처리한다. 유닛 테스트의 일부로서 개발자는 코드가 메시지를 예상대로 로깅하는지와 예외가 올바르게 처리되는지를 확인해야 한다. 일반적으로 기업에는 GAL(Global Audit Logging) 및 Global Exception Handling) 프레임워크가 있다. ITF는 GAL 및 GEH 프레임워크와 원활하게 통합될 수 있으며 특정 테스트 케이스에 대한 예상 로그 및 예외 메시지의 수를 지정할 수 있는 기능을 제공한다. 이 기능을 통해 개발자는 코드가 모든 로그 및 예외 메시지를 올바르게 라우팅하는지 확인할 수 있다.

회귀 테스트

회귀 테스트의 목적은 발견된 오류를 기반으로 버그 수정이 성공적으로 수정되었다는 것과 원래 문제점을 수정하는 과정에서 다른 오류가 추가되지 않았다는 것을 보장하는 것이다. 일반적으로 회귀는 영향을 받는 소프트웨어 코드/요구사항 변경사항을 적절하게 처리하는 데 필요한 최소 테스트 스위트를 자동으로 선택하여 버그 수정을 효율적으로 테스트하는 데 사용된다. 회귀 테스트에는 일반적으로 이전에 실행한 테스트를 실행한 후 이전에 수정한 오류가 다시 발생하는지 여부를 확인하는 방법이 사용된다. ITF는 테스트 케이스를 매우 쉽고 빠르게 다시 실행할 수 있기 때문에 회귀 테스트 플랫폼으로 사용하기에 매우 적합하다.

성능 테스트

성능 테스트는 시스템의 일부 기능이 특정 워크로드에서 얼마나 빨리 수행되는지 확인하기 위해 수행된다. 또한 확장성, 신뢰성, 자원 사용량 등과 같은 시스템의 다른 품질 특성을 유효성 검증 및 확인하는 데도 사용된다. 성능 테스트는 실제 코딩 작업을 시작하기 전에 시스템의 설계 및 아키텍처에서 얻을 수 있는 성능을 확인할 수 있다. ITF에서 작성한 테스트 케이스는 여러 시스템에서 동시에 실행하고 반복할 수 있으므로 성능 테스트에 좋은 플랫폼이다.

ITF 요구사항

다음은 ITF에서 충족해야 하는 중요 요구사항 중 일부이다.

1. ITF는 새로운 테스트 케이스를 추가할 수 있어야 한다.
2. ITF는 관련 테스트 케이스를 테스트 스위트로 그룹화하는 기능을 제공해야 한다.
3. ITF는 ITF에서 작성한 개별 테스트 케이스, 테스트 케이스 그룹 또는 모든 테스트 케이스를 실행 및 요약할 수 있어야 한다.
4. ITF는 테스트 케이스 간에 다시 사용할 수 있도록 다양한 엔드포인트를 작성할 수 있어야 한다.
5. ITF 테스트 케이스에는 다음과 같은 항목이 포함되어야 한다.
   1. 고유 이름
   2. 설명
   3. 테스트 케이스가 속해 있는 그룹
   4. 입력 엔드포인트 세부 사항
   5. 출력 엔드포인트 세부 사항
   6. 제한시간 값
6. ITF 엔드포인트에 포함되어야 하는 필드는 다음과 같다.
   1. 엔드포인트 유형: WS(Webservice) 또는 JMS(Java Message Service). 이 필드는 테스트 중인 서비스가 JMS-JMS, WS-WS 등인지 여부를 확인한다.
   2. 메시지 유형: 바이트, 텍스트 등.
   3. 인코딩 유형: 바이트 메시지에 필요한 필드이며 기본값은 UTF-8이다.
   4. 비교 플래그: 이 필드는 테스트 어설션을 위해 프레임워크에서 실제 출력을 예상 결과와 비교해야 하는지 여부를 나타낸다.
   5. 머리글 세부 사항
      1. destinationQueue: 대상 큐 이름
      2. replyToQueue: replyTo 큐 이름(WS 엔드포인트에만 필요함). 기본값은 임시 큐이다.
      3. JMSPriority: JMS 메시지 우선순위. 기본값은 4이다.
      4. JMSDeliveryMode: JMS 전달 모드로 PERSISTENT 또는 NON_PERSISTENT이다. 기본값은 PERSISTENT이다.
      5. JMSCorrelationID
      6. requestTimeout: 메시지 제한시간 값. WS 엔드포인트에만 필요하다.
   6. 특성 세부 사항
      1. SOAPAction: WS 엔드포인트에만 필요하다.
   7. 본문: JMS 엔드포인트에만 필요하다.
   8. 요청: WS 엔드포인트에만 필요하다. 웹 서비스에 대한 SOAP 봉투를 포함해야 한다.
   9. 응답: WS 엔드포인트에만 필요하다. 웹 서비스에 대한 SOAP 봉투를 포함해야 한다.
7. ITF 테스트 출력 결과는 다음 중 하나를 포함해야 한다.
   1. 성공: 모든 작업이 성공적으로 완료되었다.
   2. 실패: 출력이 수신되었지만 예상 출력과 일치하지 않았다.
   3. 오류: 프로세스를 테스트하는 중에 오류가 발생하여 비교할 출력이 생성되지 않았다.
8. ITF는 전개 가능한 환경에서 실행할 수 있는 기능을 제공해야 한다.
9. ITF는 GAL 및 GEH의 로그 항목을 검사할 수 있는 기능을 제공해야 한다.
10. ITF는 테스트 케이스 실행의 버전을 관리할 수 있는 기능을 제공해야 한다.

위로

아키텍처

ITF에는 테스트 케이스를 추가/작성/수정 및 실행하고 실행 결과를 생성할 수 있는 유틸리티를 제공하는 테스트 엔진 구성 요소가 있다. ITF는 테스트 중인 인터페이스를 빌드하는 데 사용된 것과 동일한 미들웨어 제품으로 구현할 수 있다. 이렇게 하면 IDE(Integrated Development Environment)와 쉽게 통합할 수 있다.

ITF는 백엔드 데이터베이스의 테이블 세트를 사용하여 모든 테스트 케이스, 엔드포인트 및 테스트 실행 관련 정보를 저장한다. 모든 테스트 케이스 정보를 데이터베이스에 저장하면 개발자가 어디에서나 저장소에 액세스할 수 있고 특정 워크스테이션에 얽매이지 않아도 된다는 장점이 있다. 따라서 동일한 테스트 케이스를 다양한 위치에서 실행할 수 있다. ITF에는 코드와 마찬가지로 ESB의 모든 구성 요소에 대한 전체 액세스 권한이 있다. 이는 ITF가 코드와 마찬가지로 동일한 연결 매개변수 및 클라이언트 라이브러리를 사용하기 때문이다. 또한 구성 매개변수를 즉시 수정할 수 있기 때문에 다양한 환경에서 쉽게 테스트할 수 있다. EMS(Enterprise Messaging Services), JDBC(Java Database Connectivity), SOAP 엔드포인트 등과 같은 ESB의 다양한 구성 요소는 ITF 내장 연결 설정에서 쉽게 액세스할 수 있다.

ITF는 백엔드 테이블에 대한 쿼리를 실행하여 사용자 정의된 맞춤형 보고서를 생성한다. 이러한 보고서는 테스트 케이스 또는 테스트 실행과 관련된 보고서일 수 있다. ITF에는 요약 또는 세부 사항 보고서를 제공하는 옵션이 있다.

위로

설계

ITF 오브젝트

ITF에 사용되는 네 가지 오브젝트에는 TestCase, InputEndpoint, OutputEndpoint 및 Group 오브젝트가 있다. TestCase 오브젝트는 TestCase를 정의한다. 표 1에서는 TestCase 오브젝트의 모든 속성을 보여 준다. InputEndpoint 오브젝트는 시작 측에서 테스트할 코드와 ITF 사이에 전달되는 메시지의 유형을 정의한다. 표 2에서는 InputEndpoint 오브젝트의 모든 속성을 보여 준다. OutputEndpoint 오브젝트는 종료 측에서 테스트할 코드와 ITF 사이에 전달되는 메시지의 유형을 정의한다. 표 3에서는 OutputEndpoint 오브젝트의 모든 속성을 보여 준다. Group 오브젝트는 테스트 스위트에 대한 테스트 케이스의 연관을 정의한다. 표 4에서는 Group 오브젝트의 모든 속성을 보여 준다.

ITF 프로세스 플로우

그림 2, 3 및 4에서는 ITF에서 테스트 케이스/그룹/엔드포인트를 정의하고, 테스트 케이스/그룹을 실행하고, 테스트 실행 보고서를 생성하는 작업과 관련된 단계를 보여 준다.

입력

1. 테스트 케이스 이름
2. 테스트 케이스 설명
3. 테스트 케이스가 속할 그룹
4. 입력 메시지 및 출력 메시지. 이 메시지는 다음과 같은 항목으로 구성되어 있다.
   1. 엔드포인트 참조
   2. WS 엔드포인트에 대한 요청 및 응답 메시지
   3. JMS 엔드포인트에 대한 본문
   4. 다른 모든 엔드포인트 필드를 대체한다.
5. 예상 GAL/GEH 수
6. 예상 출력 - 성공, 실패 또는 오류
7. 제한시간 – 입력 엔드포인트에서 메시지를 보낸 후 프레임워크가 출력 엔드포인트를 기다리는 시간

   
<?xml version = "1.0" encoding = "UTF-8"?>
<Input xmlns:def = "http://www.ibm.com/ams/common/unittestframework/definition">
	<TestCase>
		<def:Name>Sample</def:Name>
		<def:Description>Sample TestCase for illustration</def:Description>
		<def:Outcome>S</def:Outcome>
		<def:InputEndpoint>
			<def:Name>SampleWSEndpoint</def:Name>
			<def:JMSPriority>7</def:JMSPriority>
			<def:Request><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
                <SOAP-ENV:Envelope xmlns:SOAP-ENV=
                                        "http://schemas.xmlsoap.org/soap/envelope/">
                <SOAP-ENV:Body></SOAP-ENV:Body></SOAP-ENV:Envelope>]]>
                                         </def:Request>
			<def:Reply>Some reply with UNIQUE_TRANSACTIONID_REPLACEMENT
                                        </def:Reply>
		</def:InputEndpoint>
		<def:OutputEndpoint>
			<def:Name>SampleJMSEndpoint</def:Name>
			<def:Body>Some body with UNIQUE_TRANSACTIONID_REPLACEMENT
                                        </def:Body>
		</def:OutputEndpoint>
		<def:Timeout>10</def:Timeout>
		<def:ExpectedGALCount>1</def:ExpectedGALCount>
		<def:ExpectedGEHCount>0</def:ExpectedGEHCount>
		<def:Group>
			<def:Name>Sample</def:Name>
		</def:Group>
	</TestCase>
</Input>

단계:

1. 입력을 받는다.
2. 데이터베이스에 있는 기존 정의에 대해 입력을 검사한다.
3. 필요에 따라 엔드포인트를 작성한다.
4. 필요에 따라 그룹을 작성한다.
5. 테스트 케이스를 작성한다.
6. 그룹과 테스트 케이스 간의 관계를 작성한다.
7. 엔드포인트, 그룹 및 테스트 케이스의 성공 및 실패 결과를 보여 주는 요약 정보를 리턴한다.

출력: 작성된 테스트 케이스/그룹/엔드포인트

입력:

1. 테스트 케이스 이름
2. 그룹 이름

  
<?xml version = "1.0" encoding = "UTF-8"?>
<Input>
  <TestCases>
    <TestCase xmlns = "http://www.ibm.com/ams/common/unittestframework/execution">
	<Name xmlns = "http://www.ibm.com/ams/common/unittestframework/definition">
             testcase1</Name>
		</TestCase>
	</TestCases>
</Input>

기본 단계:

1. 입력을 받는다.
2. 입력을 기반으로 데이터베이스의 모든 테스트 케이스를 가져온다.
3. 각 테스트 케이스에 대해 Process Execute를 실행한다.
4. 각 테스트 케이스의 결과를 수집한다.
5. 데이터베이스에 있는 요약을 업데이트한다.
6. 요약 및 세부 사항을 다시 리턴한다.

하위 단계:

1. 메시지, 입력 및 출력 엔드포인트의 유형을 검사한다.
2. 출력 엔드포인트의 리스너를 시작한다.
3. 메시지를 입력 엔드포인트에 보낸다.
4. 입력 엔드포인트가 WS이면 응답을 기다린다.
5. 출력 엔드포인트가 WS이면 메시지를 수신한 후 응답을 돌려 보낸다.
6. 비교 플래그가 true이면 출력 엔드포인트의 메시지를 예상 메시지와 비교한다. ITF에서 비교를 수행하는 방법에 대한 자세한 정보는 아래의 유효성 검증 구성 요소를 참조하기 바란다.
7. 적용 가능하고 비교 플래그가 true이면 입력 응답의 메시지를 비교한다.
8. GAL 및 GEH 데이터베이스에서 수를 가져와서 예상 수와 비교한다.
9. 결과를 다시 리턴한다.

출력: 실행된 테스트 케이스/그룹이 출력되고 실행 세부 사항이 데이터베이스에 저장된다.

유효성 검증 구성 요소:

예상 결과에는 시간소인, 상관 ID 등과 같은 동적 값이 포함되어 있을 수 있다. 그러한 경우 결과의 동적 부분은 "배제" 패턴으로 대체되며, ITF가 실제 출력 및 예상 출력에 대한 정규식 비교를 수행한다. 이 기능이 없으면 항상 불일치하는 비교 결과가 발생한다. 출력 결과에 동적 구성 요소가 없는 경우에는 ITF가 정규 문자열 비교를 수행한다.

입력:

1. 테스트 케이스 이름
2. 그룹 이름
3. 버전 번호

  
<?xml version = "1.0" encoding = "UTF-8"?>
<Input>
	<Report>
		<TestCase xmlns = 
"http://www.ibm.com/ams/common/unittestframework/report">
			<Name xmlns = 
"http://www.ibm.com/ams/common/unittestframework/definition">testcase1</Name>
			<Version xmlns = 
"http://www.ibm.com/ams/common/unittestframework/definition">testcase1</Version>
		</TestCase>
	</Report>
</Input>

단계:

1. 그룹/테스트 케이스 및 버전을 가져온다.
2. ITF 데이터베이스에 쿼리하여 테스트 실행 세부 사항을 가져온다.
3. 실행 요약이 담긴 파일을 생성한다.

출력: 실행 요약 보고서가 생성된다.

위로

ITF 테스트 주기

그림 5에서는 ITF 테스트 주기를 보여 준다. 개발자/테스터는 테스트 케이스, 테스트 그룹 및 엔드포인트를 식별한 후 ITF 지정 입력 템플리트를 사용하여 식별한 요소를 정의한다. 그러면 ITF가 테스트 케이스, 테스트 그룹 및 엔드포인트를 작성하고 데이터베이스에 저장한다. 테스트 케이스 실행 동안 CBT(Code Being Tested)가 사전 정의된 입력 엔드포인트 중 하나를 통해 ITF로부터 입력을 수신한다. 실행이 완료되면 CBT가 사전 정의된 출력 엔드포인트 중 하나에 있는 ITF에게 응답을 보낸다. 선택적으로, ITF의 모든 입력에 대해 CBT가 입력 응답을 보낼 수 있으며 ITF에 대한 모든 출력에 대해 코드가 ITF의 출력 응답을 기대할 수 있다.

SOI 통합 패턴을 기반으로 CBT와 ITF 사이에 전송되는 다음과 같은 네 가지 유형의 메시지 플로우를 살펴보자.

1. JMS에서 JMS로
2. 웹 서비스에서 웹 서비스로
3. JMS에서 웹 서비스로
4. 웹 서비스에서 JMS로

JMS에서 JMS로

CBT의 입력 및 출력 엔드포인트가 JMS 큐이다. 따라서 선택적 응답이 필요하지 않다. 입력 메시지는 CBT의 입력 큐에 전송되고 출력은 출력 큐에 전송된다. ITF는 출력 큐에서 읽은 메시지를 실행 중인 테스트 케이스에 연관된 예상 출력 메시지와 비교한다. 비교 결과를 바탕으로 ITF가 테스트 케이스의 성공 또는 실패 여부를 결정한다.

웹 서비스에서 웹 서비스로

CBT의 입력 및 출력 엔드포인트가 웹 서비스이다. 따라서 두 엔드포인트 모두 선택적 응답이 필요하다. 입력 메시지가 CBT의 입력 큐에 전송되고 ITF는 요청의 replyTo 큐에서 코드의 응답을 기다린다. CBT가 요청에 대한 입력 응답을 생성하며, ITF가 이 응답을 캡처하여 예상 응답과 비교한다. ITF가 사전 정의된 응답을 CBT에 의해 설정된 출력 replyTo 큐에 다시 보내서 코드에서 호출하고 있는 서비스를 모방한다. 결과적으로 응답이 CBT에 의해 입력 replyTo 큐에 다시 전송된다. 이 응답은 ITF에 캡처된다. 그런 다음 ITF가 입력 응답을 예상 응답과 비교한다. 비교 결과를 바탕으로 ITF가 테스트 케이스의 성공 또는 실패 여부를 결정한다.

JMS에서 웹 서비스로

CBT가 입력 응답을 생성하지 않고 출력 응답만 예상한다. ITF가 입력 메시지를 입력 큐에 보낸다. CBT가 입력을 처리한 후 출력 큐에 요청을 보낸다. ITF가 이 요청을 캡처하여 예상 출력과 비교한다. ITF는 사전 정의된 출력 응답을 CBT에 의해 설정된 출력 replyTo 큐에 다시 보내서 코드에서 호출하고 있는 서비스를 모방한다.

웹 서비스에서 JMS로

CBT가 입력 요청에 대한 응답을 생성하지만 출력 메시지에 대한 응답을 기대하지 않는다. 입력 메시지가 입력 큐에 전송되고 송신측에서는 입력 replyTo 큐에 되돌아올 응답을 기다린다. CBT가 요청을 처리한 후 메시지를 출력 큐에 전송한다. 그러면 ITF가 이 메시지를 캡처하여 예상 출력과 비교한다. 또한 CBT는 입력 replyTo 큐에 돌려보낼 응답을 생성한다. 이 응답은 ITF에 캡처된다. 그런 다음 ITF가 입력 응답을 예상 응답과 비교한다. CBT가 입력 요청에 대한 응답을 생성하지만 출력 메시지에 대한 응답을 기대하지 않는다. 입력 메시지가 입력 큐에 전송되고 송신측에서는 입력 replyTo 큐에 되돌아올 응답을 기다린다. CBT가 요청을 처리한 후 메시지를 출력 큐에 전송한다. 그러면 ITF가 이 메시지를 캡처하여 예상 출력과 비교한다. 또한 CBT는 입력 replyTo 큐에 돌려보낼 응답을 생성한다. 이 응답은 ITF에 캡처된다. 그런 다음 ITF가 입력 응답을 예상 응답과 비교한다.

데이터베이스 설계

1. ITF에서는 6개의 테이블을 사용하여 모든 필수 정보를 저장한다.
2. UT_DEF_TEST_CASE 테이블에는 모든 테스트 케이스 관련 정보가 있다.
3. UT_DEF_GROUP 테이블에는 모든 테스트 케이스 그룹 관련 정보가 있다.
4. UT_DEF_ENDPOINT 테이블에는 모든 엔드포인트 관련 정보가 있다.
5. UT_DEF_CASE_GROUP_REL 테이블에는 모든 테스트 케이스 - 그룹 관련 정보가 있다.
6. UT_EXE_SUMMARY 테이블에는 모든 테스트 케이스 실행 요약 관련 정보가 있다.
7. UT_EXE_DETAILS 테이블에는 모든 테스트 케이스 실행 세부 사항 관련 정보가 있다.

위로

결론

ITF는 SOI 구현의 테스트 단계에서 수행되는 다양한 작업을 효율적으로 수행할 수 있는 도구이다. 이 도구는 빠르게 빌드할 수 있을 뿐만 아니라 대부분의 미들웨어 통합 제품에 원활하게 통합된다. 개발/테스트 팀에서 ITF를 사용할 경우 높은 비용 절감 효과를 얻을 수 있는 것으로 밝혀졌다. ITF를 사용하는 팀이 그렇지 않은 팀보다 일관되게 적은 수의 결함을 생성했다.

참고자료

교육

• developerWorks의 SOA와 웹 서비스 영역에서 개발자의 기술을 향상시키는 데 도움이 되는 참고자료를 다운로드할 수 있다.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  

제품 및 기술 얻기

• IBM 제품 평가판을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
  
  

토론

• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• 소개
• Interface Test Framework의 목적
• ITF 기능
• 아키텍처
• 설계
• ITF 테스트 주기
• 결론
• 참고자료
• 필자소개
• 의견