개요
이 도구 사용 도움말은 Rational QualityArchitect에서 수행되는 기본적인 유닛 테스트 타스크의 개요를 제공합니다.
-
유닛 테스트
-
시나리오 테스트
-
스텁 생성
-
EJB 세션 레코딩
개발 프로세스에서 모든 컴포넌트가 완전한 시스템으로 어셈블될 수 있을 때까지 테스트를 연기하는 것은 위험한 제안입니다. 라이프사이클에서 결함이 너무 늦게 발견되면 수정하기가 더 어려워지며 특히 수정하려면 많은
부분을 다시 디자인해야 하는 아키텍처 문제점일 경우 심각한 스케줄 지연이 발생할 수 있습니다.
팀이 시스템 컴포넌트의 품질에 대해 상당한 자신을 갖고 있어도, 시스템 전체에 대한 확신은 여전히 허용할 수 없을 만큼 낮을 수 있습니다. 예를 들어 다섯 개의 컴포넌트로 구성된 단순 시스템을 고려해 보십시오.
이때 각 컴포넌트는 95% 신뢰할 수 있다고 평가됩니다(테스트 적용 범위 메트릭이나 덜 정량적인 메소드로). 시스템 신뢰성은 누적되므로 전체 평점은 95% x 95% x 95% x 95% x 95%, 즉 77%가
조금 넘습니다. 하나의 컴포넌트에서 문제점 발생 가능성은 1/20이지만 전체 시스템의 경우에는 1/4에 가까워집니다. 이것도 상대적으로 적은 컴포넌트를 가지고 있는 시스템의 경우가 그렇습니다.
반대로, 반복적 개발 프로세스에 걸쳐 컴포넌트 테스트를 통합하는 개발 프로세스는 몇 가지의 중요한 장점을 제공합니다.
-
분리된 컨텍스트에서 문제점을 발견하고 수정할 수 있으므로, 쉽게 수정할 수 있을 뿐만 아니라 쉽게 발견하고 진단할 수 있습니다.
-
테스트 및 개발이 라이프사이클에 걸쳐 단단하게 결합되어 있으므로, 진행상태 척도를 더 신뢰할 수 있습니다. 이제는 코딩된 프로젝트 양과 코딩되어 작동 중인 프로젝트의 양 측면에서 진행상태를 볼 수 있습니다.
-
예기치 못한 문제점으로 인한 스케줄 지연이 최소화되어, 전체 스케줄이 보다 현실적이 되고 프로젝트 위험성도 감소합니다.
초기 테스트에는 많은 이점이 있지만 중간 층의 GUI가 없는 컴포넌트를 테스트하는 경우에는 쉽지 않습니다.
이유는 무엇입니까? 그 이유는 이를 수행하는 데 많은 시간이 필요하고 지루하며, 과거에는 종종 이와 같은 실제 문제를 극복하기 위한 비용을 이점보다 더 중요시했기 때문입니다. 또한, 대부분의 테스트는 특정
컴포넌트에 맞게 조정되므로 재사용 기회가 적습니다. 많은 조직에서 처음부터 테스트 하니스와 스텁을 빌드하고 프로젝트마다 사용한 후 다시 버리는 것을 낭비라고 인식하고 있습니다. 조직에서는 제한된 자원을 다른 영역에
집중시키려고 합니다.
QualityArchitect를 사용할 경우, 테스트 하니스 및 스텁이 자동으로 생성(단 한 번이 아니라 개발에 걸쳐 모델이 전개되는 대로 점진적으로)되므로 초기 테스트가 편리하게 됩니다. 컴포넌트 테스트의 결과가
성급한 시스템 테스트를 방지하기 위해 더 강력한 진입 기준을 촉진하므로 전체 개발 프로세스가 한층 구조화되고 측정되며 가시화됩니다. QualityArchitect는 개발자가 테스트 정의의 창조적 측면에 초점을 맞출
수 있도록 하므로, 개발자는 테스트 드라이버 및 스텁을 작성하고 디버깅하는 대신 컴포넌트를 연습하기 위한 최상의 방법에 대해 생각하는 데 시간을 투자할 수 있습니다. 개발자와 설계자는 공유 비주얼 모델을 사용하여
함께 밀접하게 작업하므로, 서로 더 생산적인 관계를 가지게 됩니다.
이 도구 사용 도움말은 Windows 98/2000/NT 4.0 실행 시 적용 가능합니다.
도구 단계
이 도구 사용 도움말에서는 QualityArchitect를 사용하는 자동 컴포넌트 테스트 구현과 연관되는 다음과 같은 기본 타스크를 다룹니다.
-
유닛 테스트의 전제 단계
-
유닛 테스트 구현
-
시나리오 테스트 구현
-
스텁 컴포넌트 작성
-
EJB 세션 레코더 사용
QualityArchitect를 사용하여 테스트를 생성하려면 테스트가 EJB 컴포넌트 COM용인지 여부에 관계없이 Rational Administrator를 사용하여 Rational 프로젝트를 작성하고 구성해야
합니다. 이 프로젝트에는 테스트 결과 및 데이터풀과 같은 모든 테스트 자산을 보유할 테스트 데이터 스토어가 있어야 합니다. 자세한 정보는 도구 사용 도움말: Rational Administrator를 사용하여 프로젝트 구성을 참조하십시오.
유닛 테스트의 목표는 주어진 컴포넌트에 대해 주어진 오퍼레이션이 주어진 입력 세트에 대해 올바른 리턴값을 제공하는지 확인하는 것입니다. 유닛 테스트는 논리 보기의 클래스 스펙으로부터 작성됩니다. 유닛 테스트 작성
및 실행 프로세스는 다음의 세 가지 단계로 구성됩니다.
-
유닛 테스트 코드 생성
-
유닛 테스트 데이터 생성
-
테스트 실행 및 결과 점검
유닛 테스트 코드 생성
유닛 테스트 코드는 컴포넌트를 인스턴스화하는 데 필요한 모든 지시사항을 포함하고 테스트할 오퍼레이션을 호출하며 기준선에 대해 리턴된 결과를 점검합니다.
COM 컴포넌트의 경우
-
논리 보기의 컴포넌트 인터페이스 아래에서 테스트할 오퍼레이션을 선택하십시오.
-
컴포넌트 인터페이스 아래에 나열된 오퍼레이션을 마우스 오른쪽 단추로 클릭하고 Rational Test > 유닛 테스트 생성을 선택하십시오. 이 프로세스 중에 프롬프트가 표시되면
Rational 프로젝트에 로그인해야 할 수도 있습니다.
QualityArchitect는 이 프로세스의 산출물로 Visual Basic 6 호환 가능 코드를 생성합니다.
Visual Basic의 경우 먼저 코드 컴파일을 시도한 다음 컴파일 오류를 점검해야 합니다. 특정 상황에서는 QualityArchitect로 복잡한 데이터 유형을 광범위하게 사용하는 오퍼레이션을 테스트하기 위한
코드를 생성할 수 없습니다. 이와 같은 경우, QualityArchitect는 올바르지 않은 코드를 삽입하여 컴파일 시 수동 코딩이 필요한 코드 세그먼트를 강조표시합니다. 코드가 컴파일되면 다음 단계인 유닛 테스트 데이터 생성으로 진행할 수 있습니다.
EJB 컴포넌트의 경우
-
논리 보기의 원격 인터페이스에서 테스트할 오퍼레이션을 선택하십시오.
-
오퍼레이션을 마우스 오른쪽 단추로 클릭하고 Rational Test > 유닛 테스트 템플리트 선택을 선택하십시오.
-
EJB 서버에 적절한 템플리트를 탐색하십시오. WebSphere의 경우에는 EJBWebSphereBusiness 메소드 폴더에서 websphere_remote.template를 선택하십시오. Web
Logic의 경우에는 EJBWeb LogicBusiness 메소드 폴더에서 weblogic_remote.template를 선택하십시오.
-
Rational Test > 유닛 테스트 생성을 선택하십시오. 이 프로세스 중에 프롬프트가 표시되면 Rational 프로젝트에 로그인해야 할 수도 있습니다.
QualityArchitect는 이 프로세스의 산출물로 Java 코드를 생성합니다.
IDE 또는 편집기 중에서 선택하여 Java 코드를 점검하십시오. Rational Rose는 이 목적으로 사용할 수 있는 R2 편집기와 함께 제공됩니다.
사용자 편집기에서 먼저 코드를 컴파일하십시오. 컴파일 오류를 점검해야 합니다. 특정 상황에서는 QualityArchitect로 복잡한 데이터 유형을 광범위하게 사용하는 오퍼레이션을 테스트하기 위한 코드를 생성할 수
없습니다. 이와 같은 경우, QualityArchitect는 컴파일되지 않을 올바르지 않은 코드를 삽입하여 수동 코딩이 필요한 코드 행에 플래그를 표시합니다. 코드가 컴파일되면 다음 단계인 유닛 테스트 데이터 생성으로 진행할 수 있습니다.
성공적인 유닛 테스트의 확실한 척도는 테스트 데이터입니다. 테스트 코드 자체는 일회용입니다. QualityArchitect가 언제든지 코드를 다시 생성할 수 있기 때문입니다. QualityArchitect는 테스트
코드를 작성할 수 있지만 의미있는 테스트 데이터는 작성할 수 없습니다. 이는 분석가나 구현자의 책임입니다. 대표적인 긍정적 및 부정적 테스트의 유효성을 검증하는 테스트 데이터를 작성할 때는 주의해야 합니다.
컴포넌트 논리의 경계 조건에 초점이 맞춰진 테스트 데이터는 유닛 테스트 데이터의 훌륭한 후보가 됩니다.
COM 컴포넌트의 경우
-
논리 보기의 컴포넌트 인터페이스에서 테스트할 오퍼레이션을 선택하십시오.
-
오퍼레이션을 마우스 오른쪽 단추로 클릭하고 Rational Test > 데이터풀 작성을 선택하십시오.
-
데이터풀 작성을 선택하면 데이터풀 특성 대화 상자가 표시됩니다. 이 시점에서, 데이터풀 데이터 편집을 선택하여 데이터 입력을 시작하거나 데이터풀 필드 정의를 선택하여
QualityArchitect가 사용자 대신 테스트 데이터를 생성하도록 할 수 있습니다.
EJB 컴포넌트의 경우
-
논리 보기의 원격 인터페이스에서 테스트할 오퍼레이션을 선택하십시오.
-
원격 인터페이스에 나열된 오퍼레이션을 마우스 오른쪽 단추로 클릭하고 Rational Test > 데이터풀 작성을 선택하십시오.
-
데이터풀 작성을 선택하면 데이터풀 특성 대화 상자가 표시됩니다. 이 시점에서, 데이터풀 데이터 편집을 선택하여 데이터 입력을 시작하거나 데이터풀 필드 정의를 선택하여
QualityArchitect가 사용자 대신 테스트 데이터를 생성하도록 할 수 있습니다.
데이터풀 필드 정의를 선택하면 QualityArchitect의 테스트 데이터 생성 기능을 사용할 수 있게 됩니다. QualityArchitect는 다양한 일반 데이터 유형을 생성할 수 있습니다. 이
유형은 유형 필드의 데이터 유형 드롭 다운 목록에서 지정됩니다.
적절한 유형을 선택한 경우, 생성할 행 수를 선택하고 데이터 생성을 클릭하십시오. QualityArchitect가 사용자 대신 모든 데이터를 생성할 수 있는 것은 아닙니다. 예를 들어,
QualityArchitect는 일반적인 미국 도시 목록은 생성할 수 있지만 주문 시스템에 대한 올바른 시스템 특정 송장 번호 목록은 생성할 수 없습니다. 이 데이터는 수동으로 데이터 유형으로 입력하거나 데이터풀에
직접 입력해야 합니다. 사용자 정의 데이터로 데이터 유형을 작성하면 그 시점부터 QualityArchitect가 데이터풀 필드 정의 인터페이스에서 이 유형의 데이터를 생성할 수 있게 됩니다. 데이터풀에 직접
데이터를 입력하면 해당되는 특정 데이터풀만 이를 사용할 수 있습니다.
데이터풀 데이터 편집을 선택하면 직접 의미있는 테스트 데이터를 입력하게 됩니다. 인수마다 하나의 필드가 있고 예상 리턴에 대한 필드 하나와 예상 오류에 대한 필드 하나가 있습니다. 오류를 지정하면 오류
번호와 오류 텍스트 메시지 항목도 입력하게 됩니다. 오퍼레이션의 인수로 복잡한 오브젝트가 필요하거나 복잡한 오브젝트를 리턴해야 할 경우, 데이터풀에 해당 오브젝트 참조를 삽입할 수 없습니다. 대신, 오브젝트
인스턴스를 구성하는 데 필요한 간단한 인수 유형으로 오브젝트를 분류하십시오. 앞에 삽입 및 뒤에 삽입 단추를 사용하여 이 목적의 필드를 데이터풀에 추가하십시오. 테스트 코드를 수정하여
제공된 데이터로 오브젝트 인스턴스를 구성해야 합니다.
테스트 실행 및 결과 점검
테스트 코드와 테스트 데이터를 모두 작성하면 테스트를 실행할 준비가 완료된 것입니다. IDE에서 테스트를 실행하거나 TestManager Suite에서 테스트 스케줄을 지정할 수 있습니다. 이 주제에 대한 자세한
정보는 도구 사용 도움말: Rational TestManager를 사용하여 Test Suite 실행을 참조하십시오.
-
테스트 실행이 시작되면 테스트 로그 결과의 위치를 제공하도록 요청하는 프롬프트가 표시됩니다. 위치를 지정하면 TestManager가 테스트 실행 결과를 그 위치에 넣습니다.
-
실행 종료 시 TestManager는 테스트 로그를 표시합니다. 테스트 결과를 보려면 로그 표시기 창의 자세히 보기 탭을 선택하십시오. 결과 트리 보기를 펼쳐서 테스트 실행 세부사항을 보십시오.
임의 행을 마우스 오른쪽 단추로 클릭하고 특성을 선택하여 추가 정보에 액세스할 수 있습니다.
시나리오 테스트의 목표는 주어진 일련의 컴포넌트 사이에 주어진 일련된 오퍼레이션이 결합되어 공동 타스크를 올바르게 수행하는지 확인하는 것입니다. 시나리오 테스트는 상호작용 다이어그램(특히 시퀀스 및 협업
다이어그램)에서 작성됩니다. 시나리오 테스트 작성 및 실행 프로세스는 다음의 세 가지 단계로 구성됩니다.
-
시나리오 테스트 코드 생성
-
시나리오 테스트 데이터 생성
-
테스트 실행 및 결과 점검
시나리오 테스트 코드 생성
시나리오 테스트 코드는 컴포넌트를 인스턴스화하는 데 필요한 모든 테스트 드라이버 코드로 구성되며 테스트할 오퍼레이션을 호출하고 검증 포인트를 사용하여 오퍼레이션 결과를 평가합니다. 검증 포인트는 테스트 코드가
데이터베이스에 대해 SQL 문을 실행하여 기반 데이터의 적절한 조작을 확인할 수 있는 메커니즘입니다.
EJB 컴포넌트의 경우
-
브라우저에서 협업 다이어그램을 선택하십시오.
-
다이어그램을 마우스 오른쪽 단추로 클릭하고 Rational Test > 시나리오 테스트 템플리트 선택을 선택하십시오.
-
EJB 서버에 적절한 템플리트를 탐색하십시오. WebSphere의 경우에는 EJBWebSphereScenario 폴더에서 websphere_scenario.template를 선택하십시오.
Web Logic의 경우에는 EJBWeb LogicScenario 폴더에서 weblogic_scenario.template를 선택하십시오.
-
테스트할 시나리오를 모델링하는 주어진 시퀀스 또는 협업 다이어그램을 여십시오. 다이어그램에서 테스트할 컴포넌트에 대해 컴포넌트의 메시지를 지정해야 합니다. 메시지 행을 두 번 클릭하고 일반 탭의
드롭 다운 목록 상자에서 이름을 지정하여 메시지를 지정하십시오. 이름은 테스트하는 오퍼레이션에 해당되어야 합니다. 또한, 테스트 케이스 데이터를 포함하도록 스펙을 수정할 수도 있습니다.
예를 들어, Rose는 기본적으로 다음과 같이 메시지 스펙을 드러냅니다.
getTransactions(customerID : String)
이 스펙은 다음과 같이 단일 데이터 케이스를 포함하도록 수정될 수 있습니다.
getTransactions(customerID : String="BBryson")
모든 시나리오 테스트에 대해, QualityArchitect는 자동으로 테스트 케이스 데이터의 데이터풀을 생성합니다. 다이어그램의 데이터는 첫 번째 행에 채워집니다. 여기서부터 행을 더 추가할
수 있습니다.
-
테스트를 시작하려면 브라우저에서 다이어그램을 마우스 오른쪽 단추로 클릭하고 Rational Test > 시나리오 테스트 생성을 선택하십시오. 프로젝트에 로그인하도록 요청하는 프롬프트가
표시되면 로그인하십시오.
-
시나리오 테스트 대상을 선택하도록 요청하는 대화 상자가 표시됩니다. 다이어그램에서 테스트에 포함시킬 모든 컴포넌트를 선택하십시오. 선택된 컴포넌트마다 컴포넌트 메시지에 지정된 해당 오퍼레이션이 호출됩니다.
COM 컴포넌트의 경우
-
테스트할 시나리오를 모델링하는 주어진 시퀀스 또는 협업 다이어그램을 여십시오. 다이어그램에서 테스트할 컴포넌트에 대해 컴포넌트의 메시지를 지정해야 합니다. 메시지 행을 두 번 클릭하고 일반 탭의
드롭 다운 목록 상자에서 이름을 지정하여 메시지를 지정하십시오. 이름은 테스트하는 오퍼레이션에 해당되어야 합니다. 또한, 테스트 케이스 데이터를 포함하도록 스펙을 수정할 수도 있습니다.
예를 들어, Rose는 기본적으로 다음과 같이 메시지 스펙을 드러냅니다.
getTransactions(customerID : String)
이 스펙은 다음과 같이 단일 데이터 케이스를 포함하도록 수정될 수 있습니다.
getTransactions(customerID : String="BBryson")
모든 시나리오 테스트에 대해, QualityArchitect는 자동으로 테스트 케이스 데이터의 데이터풀을 생성합니다. 다이어그램의 데이터는 첫 번째 행에 채워집니다. 여기서부터 행을 더 추가할
수 있습니다.
-
테스트를 시작하려면 브라우저에서 다이어그램을 마우스 오른쪽 단추로 클릭하고 Rational Test > 시나리오 테스트 생성을 선택하십시오. 프로젝트에 로그인하도록 요청하는 프롬프트가
표시되면 로그인하십시오.
-
시나리오 테스트 대상을 선택하도록 요청하는 대화 상자가 표시됩니다. 다이어그램에서 테스트에 포함시킬 모든 컴포넌트를 선택하십시오. 선택된 컴포넌트마다 컴포넌트 메시지에 지정된 해당 오퍼레이션이 호출됩니다.
검증 포인트
호출되는 각 오퍼레이션 및 테스트 마지막에 검증 포인트를 삽입하도록 요청하는 프롬프트가 표시됩니다. 검증 포인트는 QualityArchitect에서 오퍼레이션이 올바르게 발생하는지 확인하기 위해 사용됩니다. 검증
포인트 아키텍처는 개방적이고 확장 가능하지만, 현재는 데이터베이스 검증 포인트만 구현됩니다. 데이터베이스 검증 포인트를 사용하여 조회를 실행할 SQL을 입력할 수 있습니다. 테스트 시 작성된 조회가 실행되어
컴포넌트가 데이터베이스를 올바르게 조작하는지 확인합니다.
QualityArchitect 온라인 도움말에 있는 단계를
사용하여 자체 검증 포인트를 구현할 수 있습니다.
-
검증 포인트를 삽입하려면 예를 선택하십시오.
-
삽입하려는 적절한 검증 포인트 유형을 선택하십시오. 자체 검증 포인트를 구현하지 않았으면 데이터베이스 VP를 선택해야 합니다.
-
조회 빌더가 표시되며, 이 조회 빌더를 사용하여 사용자 데이터베이스에 대한 연결 매개변수를 설정하고 호출되는 오퍼레이션의 올바른 작동을 확인하기 위해 실행될 조회를 빌드합니다. 연결을 설정하고 조회를
작성하려면 기반 데이터베이스와 SQL 구문에 대한 기초적인 지식이 필요합니다.
모든 컴포넌트를 인스턴스화하고 모든 오퍼레이션을 호출하며 삽입된 검증 포인트를 실행하는 데 필요한 코드가 이 단계의 산출물입니다.
시나리오 테스트 데이터 생성
생성되는 모든 시나리오 테스트에 대해, QualityArchitect는 자동으로 데이터풀을 작성하여 테스트 데이터를 포함합니다. 다이어그램에 지정된 데이터가 있으면 이 데이터풀의 첫 번째 행은 이미 해당 정보와
삽입된 검증 포인트에 관련되는 정보로 채워집니다. 그렇지 않으면 데이터풀에는 검증 포인트와 관련되는 정보만 포함합니다.
이 정보를 보고 편집하려면 다음 단계를 수행하십시오.
-
Rose에서 도구 > Rational Test > 도구 모음을 선택하십시오.
-
도구 모음에서 데이터풀을 편집할 두 번째 도구 모음 항목을 선택하십시오. QualityArchitect는 시나리오 다이어그램의 이름(_D로 끝나는)을 포함하는 데이터풀을 작성합니다. 데이터풀에 이름을 지정할
때 사용되는 알고리즘은 너무 복잡해서 이 문서에서 모든 데이터풀 이름을 예측하지는 못합니다.
이 데이터를 편집하려면 데이터풀에 대한 작업에 아웃라인된 동일 기본 단계를 수행하십시오.
테스트 실행 및 결과 점검
테스트 코드와 테스트 데이터를 모두 작성하면 테스트를 실행할 준비가 완료된 것입니다. IDE에서 테스트를 실행하거나 TestManager Suite에서 테스트 스케줄을 지정할 수 있습니다. 이 주제에 대한 자세한
정보는 도구 사용 도움말: Rational TestManager를 사용하여 Test Suite 실행을 참조하십시오.
-
테스트 실행이 시작되면 테스트 로그 결과의 위치를 제공하도록 요청하는 프롬프트가 표시됩니다. 위치를 지정하면 TestManager가 테스트 실행 결과를 그 위치에 넣습니다.
-
실행 종료 시 TestManager는 테스트 로그를 표시합니다. 테스트 결과를 보려면 로그 표시기 창의 자세히 보기 탭을 선택하십시오. 결과 트리 보기를 펼쳐서 테스트 실행 세부사항을 보십시오.
임의 행을 마우스 오른쪽 단추로 클릭하고 특성을 선택하여 추가 정보에 액세스할 수 있습니다.
검증 포인트의 경우, 첫 번째 실행 시에는 통과 또는 실패 표시기가 제공되지 않습니다. 이 첫 번째 실행은 차후의 테스트 실행에 대한 기준선 데이터로 사용될 조회 결과 스냅샷을 캡처하는 데
사용됩니다.
검증 포인트를 두 번 클릭하여 조회 결과를 표시하는 비교기를 표시하십시오. 이 결과는 편집할 수 있으므로, 조회에서 올바른 결과가 리턴되지 않는 경우에 이 데이터를 수정할 수 있습니다. 이 테스트의 모든 후속
실행에서는 조회 결과를 첫 번째 실행에서 캡처된 결과와 비교합니다.
유닛 또는 시나리오 테스트에서 테스트되는 컴포넌트는 종종 다른 컴포넌트에 의존하여 타스크를 완료합니다. 이와 같은 보조 컴포넌트가 작동하지 않을 경우 문제점이 발생합니다. 보조 컴포넌트는 때때로 아직 개발 중이거나
문제점이 있을 수 있습니다. 그렇지만 보조 컴포넌트가 제공될 때까지 기본 컴포넌트 테스트를 미룰 필요는 없습니다. 대신 테스트 목적으로 스텁 또는 임시 컴포넌트를 작동하지 않는 컴포넌트 대신 사용할 수 있습니다.
스텁은 실제 컴포넌트의 기능성을 구현하지 않으며 단지 입력에 반응하기만 합니다. 스텁은 로직을 구현하지 않고 지정된 값 세트에 대해 프로그래밍된 응답을 리턴합니다. 이는 단순한 자극 응답 관계입니다.
QualityArchitect는 COM 및 EJB 컴포넌트 둘 다에 대해 쉽게 스텁을 작성할 수 있습니다. 이 스텁은 찾아보기 테이블에 의존하여 대체하는 컴포넌트의 비즈니스 로직을 복제합니다. 테이블(데이터풀로
구현됨)은 지정된 입력 세트에 대해 리턴해야 하는 값을 판별합니다.
스텁 작성 및 배치 프로세스는 다음의 세 가지 단계로 구성됩니다.
-
스텁 컴포넌트 생성
-
스텁 찾아보기 테이블 생성
-
스텁 배치
스텁 컴포넌트 생성
스텁을 생성할 경우 완전한 컴포넌트를 생성해야 합니다. 스텁을 생성하는 오퍼레이션에 대해 찾아보기 테이블을 작성해야 합니다. 스텁 생성 컴포넌트(해당 컴포넌트의 모든 오퍼레이션에 대한 스텁 코드를 포함함)가 스텁
생성 프로세스의 산출물입니다. 단일 오퍼레이션에는 스텁을 생성할 수 없습니다.
COM 컴포넌트의 경우
-
논리 보기에서 컴포넌트 인터페이스를 선택하십시오.
-
인터페이스를 마우스 오른쪽 단추로 클릭하고 Rational Test > 스텁 생성을 선택하십시오. 생성된 스텁 코드를 넣을 위치를 묻는 프롬프트가 표시됩니다. 이 위치를 선택하십시오.
그러면 코드가 생성됩니다.
EJB 컴포넌트의 경우
-
논리 보기에서 Bean 구현 클래스를 선택하십시오.
-
클래스를 마우스 오른쪽 단추로 클릭하고 Rational Test > 스텁 생성을 선택하십시오. 생성된 스텁 코드를 넣을 위치를 묻는 프롬프트가 표시됩니다. 이 위치를 선택하십시오. 그러면
코드가 생성됩니다.
스텁 찾아보기 테이블 생성
실제 컴포넌트의 논리를 복제하려면 주어진 인수 세트에 대해 실제 컴포넌트가 어떻게 반응하는지를 스텁이 알고 있어야 합니다. 이 로직은 찾아보기 테이블에서 유지보수됩니다. 이 테이블에는 주어진 인수 세트에 대해
리턴할 값이나 오류가 지정됩니다. 스텁이 생성되는 컴포넌트의 각 오퍼레이션에 하나의 찾아보기 테이블을 작성하십시오.
COM 컴포넌트의 경우
-
논리 보기의 컴포넌트 인터페이스에서 오퍼레이션을 선택하십시오.
-
인터페이스를 마우스 오른쪽 단추로 클릭하고 Rational Test > 찾아보기 테이블을 선택하십시오. 데이터풀 특성 대화 상자가 표시됩니다.
-
이 찾아보기 테이블을 작성하려면 데이터풀에 대한 작업에 아웃라인된 동일 기본 단계를 수행하십시오. 테이블을 사용하여 지정된 인수
세트에 대해 리턴할 값 또는 예외를 지정합니다.
EJB 컴포넌트의 경우
-
논리 보기에서 Bean 구현 클래스로부터 오퍼레이션을 선택하십시오.
-
클래스를 마우스 오른쪽 단추로 클릭하십시오.
-
Rational Test > 찾아보기 테이블 작성을 선택하십시오. 데이터풀 특성 대화 상자가 표시됩니다.
-
이 찾아보기 테이블을 작성하려면 데이터풀에 대한 작업에 아웃라인된 동일 기본 단계를 수행하십시오. 테이블을 사용하여 지정된 인수
세트에 대해 리턴할 값 또는 예외를 지정합니다.
스텁 배치
스텁 및 찾아보기 테이블이 생성되면, 기존 컴포넌트 대신 스텁을 배치해야 합니다. 이 프로세스는 환경에 따라 다르며, 이 타스크에 대한 안내는 QualityArchitect 온라인 도움말에서 해당 표제에 제공되어
있습니다.
EJB 세션 레코더는 배치된 활성 EJB 컴포넌트와 상호작용할 수 있는 Java 응용프로그램입니다. 이 기능성은 Enterprise JavaBeans에만 사용 가능하며 COM 컴포넌트에는 사용할 수 없습니다.
EJB 세션 레코더 사용 프로세스에는 다음 단계가 포함됩니다.
-
XML 레코딩 세션 시작
-
EJB 서버에 연결
-
테스트할 Bean의 인스턴스 작성
-
Bean에 대한 오퍼레이션 호출
-
검증 포인트 및 Java 코드 삽입
-
EJB 세션 레코딩에서 테스트 코드 생성
EJB 세션 레코더는 두 가지 모드(레코딩 및 비레코딩)에서 사용할 수 있습니다. 레코딩 모드에 있을 경우, 수행한 모든 조치는 EJB 세션 레코더가 실행 가능 Java 코드로 변환할 XML 로그에 레코딩됩니다.
코드에는 모든 메소드 호출, 삽입된 Java 코드 및 검증 포인트가 포함됩니다. 비레코딩 모드에서 작동할 경우, 도구는 EJB 인스턴스 작성 및 해당 오퍼레이션 호출만 수행합니다.
-
EJB 서버에 연결하려면 제공자 URL과 InitialContextFactory를 제공해야 합니다. 이 정보는 클라이언트 코드가 서버에 연결하기 위해 사용하는 정보와 같아야 합니다. WebSphere 및
Web Logic의 기본 연결 정보는 온라인 제품 문서를 참조하십시오.
-
연결 정보를 제공했으면 연결을 선택하십시오. 그러면 해당 서버에 배치된 Bean의 목록이 제시됩니다. 세션 중에 일 대 다수 Bean과 상호작용할 수 있으므로 이 시점에서 상호작용할 첫 번째
Bean을 선택해야 합니다.
-
여기에서 테스트할 첫 번째 Bean의 인스턴스를 작성합니다. 메소드 창의 상단에서 적절한 작성 메소드를 선택하십시오. 작성 메소드에 특정 매개변수가 필요할 경우에는 매개변수 섹션에서 매개변수를
지정하십시오. 완료되면 호출을 선택하여 Bean의 인스턴스를 작성하십시오.
-
Bean 인스턴스가 작성되면, EJB 세션 레코더는 해당 Bean에 대해 사용 가능한 다양한 오퍼레이션을 표시합니다. 메소드 창의 상단에는 Bean의 고유 오퍼레이션이 표시되고 하단에는 상속된 오퍼레이션이
표시됩니다. 보통 상속된 오퍼레이션은 테스트하지 않습니다. 테스트할 오퍼레이션을 선택한 다음 매개변수 창에서 오퍼레이션에 필요한 매개변수를 제공할 수 있습니다.
-
매개변수가 복잡한 오브젝트이면 새로 작성 단추가 표시됩니다. 이 단추를 클릭하면 필요한 오브젝트의 인스턴스를 작성할 수 있는 대화 상자가 표시되는 후속 창이 열립니다. 이 창에는 오브젝트의 인스턴스를
구성하기 위해 모든 생성자 및 필수 인수가 표시됩니다. 생성자 정보를 제공한 경우, 오브젝트에 이름을 지정하여 필요에 따라 나중에 레코딩할 때 이 이름을 참조할 수 있도록 해야 합니다.
-
매개변수에 이름을 지정하면 세션 레코딩 중에 다시 이 값을 사용하기 좋습니다. 이름을 제공하면, QualityArchitect는 모든 매개변수 필드에서 마우스 오른쪽 단추로 클릭하여 이 값을 채울 수
있습니다.
-
호출을 클릭하면 오퍼레이션이 제공된 매개변수와 함께 호출됩니다. 최종 리턴값 필드에 리턴값이 표시됩니다. 이 값이 후속 호출의 입력으로 필요할 경우에는 필요한 필드로 끌어다 놓을 수
있습니다. 또한 마우스를 값을 삽입할 매개변수 필드에 위치시킨 다음 마우스 오른쪽 단추로 클릭할 수도 있습니다. 마우스 오른쪽 단추 클릭 메뉴에 표시되는 값을 판별하기 위해, EJB 세션 레코더는 매개변수
유형을 테스트 중에 사용한 이전 유형과 일치시킵니다.
-
세션 내의 모든 지점에서 삽입 메뉴를 통해 java 코드나 검증 포인트를 삽입할 수 있습니다. 이 검증 포인트는 시나리오 테스트 코드를 생성할 때 사용한 검증 포인트와 같습니다. 마찬가지로,
Java 코드를 삽입하여 추가 처리를 수행할 수 있습니다.
-
레코드 모드에 있는 경우, 테스트의 모든 단계가 완료되면 XML 기반 레코딩을 Java 코드로 변환할 수 있습니다. 이 조치를 수행하려면 중지를 클릭하십시오. XML 코드를 Java 코드로
변환하도록 요청하는 프롬프트가 표시되며, 여기에 세션 이름과 스크립트 이름을 제공해야 합니다. 레코딩 중에 수행한 단계를 복제하기 위해 실행할 수 있는 Java 코드가 이 프로세스의 산출물입니다.
|