스텁 이라고도 하는 가상 서비스로 TCP 연결을
시뮬레이션할 수 있습니다.
이 태스크 정보
프로시저
- 다음 방법 중 하나를 사용하여 메시지를 스텁에 전송하도록 테스트 중인 시스템을 구성하십시오. 스텁 작성 프로세스 중에 TCP 메시지를 기록한 경우에는 이 선택사항이 유사합니다. 레코딩과 가상화의 차이점으로는
패킷 캡처는 가상화를 허용하지 않으며 레코딩에는 직접 연결 옵션을 사용할 수 없다는 사실이 포함됩니다.
그림 1에서는 가상화 없는 네트워크를 보여줍니다.그림 1. 프록시 없음, 가상화 없음
- 가장 간단한 방법은 Rational Integration Tester HTTP/TCP
프록시를 리버스 TCP 프록시로 구성하는 것입니다(그림 2 및 그림 3 참조). 시스템이
프록시에 대한 전달 규칙의 바인드 속성에 지정된 호스트 및 포트로
트래픽을 전달하도록 테스트할 시스템에서 사용되는 엔드포인트의 호스트 이름과 포트를
변경하십시오. 스텁이 실행 중인 경우 메시지가 스텁에 동적으로 라우팅됩니다. 스텁이
실행되지 않는 경우 메시지가 라이브 시스템(사용 가능한 경우)으로 전송됩니다. HTTP(S) 리버스 프록시 또는 TCP 포트 전달 구성의 내용을 참조하십시오. 그림 2에서는 테스트할 시스템에서 프록시 서버가 실행 중인 메시지 주소를 호스트 시스템으로 지정하는 것을 보여줍니다. 실행 중인 스텁이 없으면 프록시에 대한 전달 규칙의 바인드 속성에서 지정한 대로 프록시 서버가 메시지 주소를 활성 시스템으로 다시 지정합니다.그림 2. 프록시 서버가 대상 호스트를 활성 서버로 변경
참고: 많은 TCP 애플리케이션은 활성 시스템에 대해 하나의 영구적 연결을 설정하고 이를 통해 여러 메시지를 보냅니다. 애플리케이션이 TCP 프록시에 연결하기 전에 스텁이 시작되었는지 확인하십시오. 이렇게 하지 않으면 활성 시스템에 대한 연결이 설정된 후에 스텁이 사용되지 않습니다.그림 3에서는 다시 테스트할 시스템에서 메시지를 프록시 호스트로 보내는 것을 보여줍니다. 이번에는 스텁이 실행 중이므로 스텁이 프록시에서 작성한 규칙을 기반으로 프록시 서버가 메시지를 스텁으로 경로 재지정합니다. Rational Test Control Panel의 에이전트 페이지에서 해당 규칙을 볼 수 있습니다. 자세한 정보는 실행 중인 에이전트 보기의 내용을 참조하십시오.그림 3. 프록시 서버가 대상 호스트를 스텁으로 변경
- 다른 대체 방법은 스텁에 직접 연결하도록 테스트할 시스템을 구성하는
것입니다(그림 4 참조). 이 프로세스를
위해서는 고정 포트 번호를 스텁이 사용하는 전송에 지정해야 합니다. 이를 수행하려면
Rational Integration Tester
Architecture School 퍼스펙티브의 실제 보기로 이동하여 TCP 서버 자원을 마우스 오른쪽 단추로 클릭한 후 실제
자원 열기를 클릭하십시오. 서버 페이지의 소켓 대체 섹션에서
스텁을 실행할 호스트와 충돌하지 않는 숫자를 포트 필드에 입력하십시오. 해당 호스트는 다음 서버 중 하나입니다.
- Rational Integration Tester를 실행 중인 서버
- Rational Test Control Panel을 통해 실행 중인 경우, Rational Integration Tester 에이전트를 실행 중인 서버
소켓 대체에 대한 자세한 정보는 실제 TCP 서버 작성의 내용을 참조하십시오.
다음, 라이브 시스템을 위한 호스트 및 포트를 사용하는 대신 스텁을 실행 중인 서버의 호스트 및 포트 번호를 해당 엔드포인트로 사용하도록 테스트 중인 시스템을 구성하십시오. 다음 제한사항에 유의하십시오.- 이 방법은 메시지를 동적으로 라우팅하지 않습니다. 스텁이 실행되지 않는 경우 연결에 실패합니다.
- 지정된 엔드포인트에 대한 모든 트래픽은 스텁에 라우팅됩니다. 이 방법은 오퍼레이션을 기반으로 트래픽을 필터링하지 않습니다.
- 사용자는 다른 방법으로 여러 에이전트를 가질 수 있으며, 스텁은 올바른 환경을 위해 Rational Test Control Panel과 함께 등록된 에이전트에서 실행할 수 있습니다. Rational Test Control Panel을 사용하는 경우, 이 방법을 사용하려면 에이전트가 스텁을 실행하는 정확한 시스템을 사용하도록 테스트할 시스템을 구성해야 합니다.
그림 4에서는 테스트할 시스템에서 스텁을 호스트하는 시스템으로 직접 연결하는 것을 보여줍니다. 활성 시스템으로 이동하는 메시지가 없습니다. 메시지 주소가 모두 스텁으로 지정되어 스텁으로 직접 전송됩니다. 메시지를 필터링하려면 앞에서 설명한 프록시 서버를 사용하십시오.그림 4. 스텁에 대한 직접 연결
그림 5에서는 클라이언트가 스텁이 실행 중일 것이라고 예상하는 포트에 직접 연결하기 때문에 스텁이 실행 중이 아닌 경우 연결이 실패함을 보여줍니다. 이 문제를 방지하려면 앞에서 설명한 프록시 서버를 사용하십시오.그림 5. 실행 중이 아닌 스텁에 대한 직접 연결
- 가장 간단한 방법은 Rational Integration Tester HTTP/TCP
프록시를 리버스 TCP 프록시로 구성하는 것입니다(그림 2 및 그림 3 참조). 시스템이
프록시에 대한 전달 규칙의 바인드 속성에 지정된 호스트 및 포트로
트래픽을 전달하도록 테스트할 시스템에서 사용되는 엔드포인트의 호스트 이름과 포트를
변경하십시오. 스텁이 실행 중인 경우 메시지가 스텁에 동적으로 라우팅됩니다. 스텁이
실행되지 않는 경우 메시지가 라이브 시스템(사용 가능한 경우)으로 전송됩니다. HTTP(S) 리버스 프록시 또는 TCP 포트 전달 구성의 내용을 참조하십시오.