Rational 테스팅 툴을 단위 테스팅, 특히 함수 테스트(스크립트로 된 GUI 테스트 포함)에 적용하는 방법을 설명한다.

• Part 1: 프로젝트 소개, 고급 플래닝
• Part 2: 상세 플래닝, 리스크 관리, 요구 사항 관리
• Part 3: Rational Rose 모델 생성과 액세스 제어, 요구 사항 분석
• Part 4: 유스 케이스 조정, 리포트 생성, 툴과 기술 선택
• Part 5: 아키텍처와 디자인
• Part 6: 디자인 상세, 초기 개발, 라운드트립 엔지니어링, 초기 단위 테스트
• Part 7: 개발, 초기 구현, 데모
• Part 8: 단위 테스팅 전략, 기능 테스트, GUI 테스트 스크립트
• Part 9: 시스템 구현과 테스팅, 오류 트래킹, 제품 승인
• Part 10: 프로젝트 결과, 결론, 앞으로의 작업

Lookoff Technologies Incorporated라는 가상의 소프트웨어 회사가 있고, Audiophile Speaker Design, Inc. (ASDI) 라는 고객은 자신들의 IT 요구 사항들을 처리해 줄 회사로 Lookoff를 선택했다. 자세한 내용은 Part 1을 참조하라.

Part 8에서는 Part 6에 소개되었던 테스팅을 다루도록 하겠다. Part 6에서는 초기 개발 동안 Rational Purify와 Rational Quantify를 사용하여 메모리 사용과 퍼포먼스 병목현상을 검사했다. 또한 초기 단위 테스팅에 대한 상세한 부분들을 설명했다. 이 글에서는 이러한 노력들이 어떻게 진행되는지를 설명하고 Rational의 테스팅 툴, 특히 Rational PureCoverage와 Rational Robot을 사용하여 자동화를 통해서 테스팅 비용을 줄일 수 있는 방법을 검토할 것이다. (GUI 테스트를 포함하여) 함수 테스트에 초점을 맞추겠지만 추기 부하 테스트도 수행할 것이다.

여기에서 사용되는 Rational Unified Process (RUP) 용어들은 두 개의 다른 차원의 테스팅을 반영한다. "단위 테스트(unit test)"는 테스팅 되고 있는 소프트웨어 개발의 단계를 의미한다. 테스트 할 수 있는 가장 작은 소프트웨어 단위를 의미한다. 반면, "함수 테스트(function test)"와 "부하 테스트(load test)"는 테스팅 되는 소프트웨어의 개발에 관계 없는 특정 테스트 객체를 의미한다. 단위 테스팅의 정황에서 이 글에서 설명하는 대부분이 나중의 개발 단계(예를 들어, 다른 컴포넌트들과 하위 시스템들을 결합하는 통합 테스트 동안)에서 수행했었던 테스팅에도 적용된다.

단위 테스팅

개발이 진행되면서 우리의 단위 테스팅 노력이 개발 노력을 능가한다는 것을 깨달았다. 우리가 구현했던 애플리케이션에 사용되는 복잡한 사용자 인터랙션 때문이었다. 단위 테스팅에는 많은 노력이 필요하지만 여기에 많은 시간을 투자하지 않는다. 사소한 프로세스가 개입된 GUI 테스트 역시 진행 과정을 더디게 만들었다.

ASDI 프로젝트의 Phase 1이 개념의 입증을 위해 있는 것이지만, 시스템에서 눈에 띄는 버그들을 감당하느라 힘든 시간을 보냈다. 견고하고 믿을 수 있는 소프트웨어를 만드는 것과 빈번하고 빠른 데모를 보이는 것 사이의 균형을 맞추기가 힘들었다. 우리는 Phase 1의 범위를 기술 데모 보다 더 많아야 한다고 정의했다. 고객은 베타 버전을 사용하고 싶어했다.

여기에서 우리는 단위 테스팅 노력의 정도, 우리가 사용하기로 했던(또는 사용하지 않기로 했던) 자동화 기능, Rational PureCoverage를 사용한 철저한 테스팅에 대해서 살펴 볼 것이다.

테스팅의 범위

단위 테스팅의 범위-무엇을, 얼마나, 언제 테스트 할 것인가-에는 다음과 같은 변수들이 작용한다.

• 소프트웨어의 복잡성
• 제품의 특징과 인터페이스
• 특정 소프트웨어가 전체 제품에 미치는 영향력
• 팀의 오류 내구성

얼마나 많은 코드 테스팅을 해야 하는가 라는 관점에서 볼 때, 이전 프로젝트에서 소프트웨어에 100%의 코드 커버리지를 목표로 하지 않았다. 전체 커버리지는 비용이 많이 들고 달성하기도 어려웠다. 코드를 직접 검사하여 어떤 라인을 테스트 해야 하고, 테스트 하지 않아야 하는지를 결정해야 했기 때문이다. 단위 테스트에 생긴 작은 변화들 때문에 코드를 다시 검사하여 전체 커버리지를 관리했다. 하지만 Rational PureCoverage 덕택에 ASDI 프로젝트에서 쉽게 100%의 커버리지에 다다르게 되었다. (프로젝트 예산과 범위 때문에 적은 부분만 테스트 되지 못했다.) PureCoverage는 코드 커버리지 검사 태스크를 매우 단순화 시켰고 코드의 어떤 부분이 테스트 되었고, 테스트 되지 않았는지를 쉽게 구분할 수 있게 해주었다.

Part 6에서 언급한 것처럼 단위 테스팅 노력은 코어 개발만큼 빨리 시작되었다. 대부분의 개발자들은 테스트를 받을 만한 소프트웨어 단위가 생기자 마자 단위 테스트를 작성하기 시작했다.

단위 테스트의 실행은 언제나 구현에 앞섰다. 단위 테스트 동안 포착된 오류들이 구현에 생기지 않도록 했다. 코드가 리뷰용으로 배포되기 전에 언제나 단위 테스트가 수행되었다. (그리고 결과가 기록되었다.) 더욱이 개발자들은 정기적으로 단위 테스트를 실행하여 주기적인 변경 때문에 소프트웨어에 이상이 생기지 않도록 검사했다. 가끔 단위 테스트 개발이 코드 개발 보다 선행하는 Extreme Programming(XP) 처럼 급진적인 방식은 아니었지만 우리 역시도 단위 테스팅을 중요한 초기 단계로서 인식했다.

자동화 기능

물론 테스팅을 수행하는 방식에 문제들이 있었다. 특히 테스트를 어디까지로 자동화 해야 하는가 하는 문제가 있었다. "막후(behind-the-scenes)" (non-GUI) 코드를 작성하는 개발자들은 자바 드라이버, 스텁, 스크립트로 구성된 자동화된 테스트를 작성할 수 있었다. 하지만 앞서 언급했지만, GUI 개발자들은 더 어려워졌다.

비 GUI 테스트의 경우, 단위 테스트들은 각 클래스와 제휴되어 있었다. 드라이버 코드를 작성하여 클래스를 연습하고 성공 또는 실패를 보고했다. 테스트를 자동으로 생성, 관리, 실행하는 테스팅 프레임웍을 사용하여 실험했지만 혼합된 결과를 얻었다. 철학은 우수했지만 프레임웍(예를 들어, JUnit) 같은 사이트에서 이와 관련한 많은 아이디어를 참조하기 바란다. 프로세스를 감당할 만큼 성숙하지 못했다. 그럼에도 불구하고, 우리 개발자들은 이러한 유틸리티를 습득하고 개인화 하는데 충분한 시간이 있다면 자신감을 보이기도 했다. 그들은 테스팅 프레임웍이 단위 테스트에 매우 중요하다는 것을 인식했다. 앞으로의 프로젝트에서 이런 프레임웍을 더 많이 사용할 것이다. ASDI 프로젝트에서 XP 원리를 채택하기란 위험성이 컸다. 대신, 이것을 위험을 완화한 방식으로 개념을 다듬었다. XProgramming.com 사이트에서 이와 관련한 많은 아이디어를 참조하기 바란다.

우리는 Rational의 테스팅 툴을 사용하여 비 GUI 코드를 테스트 하지 않았다. 이 툴은 저 수준 레벨까지는 다루지 못했기 때문이다. 그러한 툴들이 진전한 빛을 발하는 곳은 GUI 중심 코드에 대한 자동화 테스트를 할 때이다. 사용자 인터페이스 테스트는 다분히 수동식이며 대화식이고, 많은 콘텐트 확인이 필요했다. Rational의 테스팅 툴을 사용하면 이러한 테스트들을 일관성 있고 빠르게 반복할 수 있다.

코드 커버리지

Rational PureCoverage를 사용하여 단위 테스트의 실행 동안 코드 커버리지를 결정하는 시간을 많이 줄일 수 있었다. 어떤 메소드와 라인들이 실행("적중") 또는 소실되었는지를 빠르게 결정할 수 있었다. 이 툴을 사용하여 테스트가 제공하는 커버리지를 감시하고 테스트를 향상시켜야 하는지 아니면 직접적인 검사를 통해 코드를 테스트 할 것인지를 결정할 수 있었다.

PureCoverage 2001A는 자바 코드는 물론 C와 C++ 애플리케이션에도 작동하고 Quantify와 Purify(Part 6참조)와 같은 방식으로 설정 및 실행되었다. 이 툴을 사용하여 단위 테스트의 코드 커버리지를 두 가지 방법으로 볼 수 있었다. 바로Coverage Browser를 사용하거나 완전한 스팩의 Coverage Fileview를 사용했다.

Coverage Browser(그림 1)을 사용해서 단위 테스트에 포함된 각 파일들(그리고 디렉토리들)의 코드 커버리지를 요약하는 통계를 볼 수 있었다. 이 통계에는 모든 메소드에 얼마나 많은 호출이 있었는지, 얼마나 많은 메소드들이 적중 또는 소실되었는지, 얼마나 많은 코드 라인("죽은" 또는 실행되지 않는 라인 제외)이 적중 또는 소실 되었는지 등이 포함되어 있다.

그림 1: Coverage Browser

(크게보기)

이 요약에서 메소드를 더블 클릭하여 Coverage Fileview로 들어갈 수 있었다. 이것은 어떤 라인이 해당 메소드에서 적중 또는 소실되었는지를 보여준다. 그림 2의 예제에서 보듯, 소실된 라인들은 빨간 색으로 강조되어 있다. (적중 라인은 파란색으로 표시되었다.)

그림 2: Coverage Fileview

(크게보기)

위로

함수 테스트

함수 테스트는 유스 케이스에 정의된 요구 사항들을 테스팅 함으로서 소프트웨어가 적절히 수행되고 있는지를 확인하는 것이다. 모든 요구 사항들이 철저하게 테스트 되었다는 것을 입증하기 위해, Rational Robot과 Rational TestManager를 사용하여 함수 테스트를 디자인 및 구성했다. (Robot을 사용한 함수 테스팅 전략에 대해서는 Robot 사용자 가이드를 참조하기 바란다.) Robot을 사용하여 테스트 스크립트가 쉽게 기록되고 나중에 자동화 된 테스트에도 실행된다. 두 가지 유형의 스크립트가 Robot을 사용하여 만들어 질 수 있다.

• GUI 스크립트는 사용자 인터페이스 액션을 기록하고, 재생되었을 때, 사용자가 애플리케이션을 조작하는 것처럼 윈도우를 시작 및 제어한다. 웹 애플리케이션에 삽입된 ActiveX 제어의 클라이언트 측 테스팅의 경우, 이 스크립트를 사용해야 한다. GUI 테스트는 특별한 문제를 우리에게 부과하기 때문에 이러한 유형의 함수 테스트에 대해서는 다음 섹션에서 자세히 설명하겠다.
• VU 스크립트는 애플리케이션을 사용하고 어떤 네트워크 정보가 패킷 레벨에서 송수신되는지를 추적하는 동안 애플리케이션을 감시한다. 재생될 때, 이러한 스크립트는 애플리케이션을 시작할 필요 없이 테스트를 재실행 하여 GUI 스크립트 보다 빠르고 가볍다. 비 GUI 함수 테스트와 B2B 인터페이스의 부하 테스트에 VU 스크립트를 사용했다.

우리는 가능한 한 빨리 함수 테스트 슈트를 만들기 시작했다. 이러한 테스트들은 엔지니어링 팀에 있어서는 매우 중요한 툴이기 때문이다. 코드와 컴포넌트의 특정 부분들이 다른 것보다 완수하는데 더 오래 걸리거나 통합 및 테스트 팀이 테스트 스크립트를 제시간에 완료할 수 없기 때문에 코드가 리뷰용으로 배포되기 전에 테스트 스크립트를 생성하는 것은 어려운 일이었다. 어떤 경우 테스트 스크립트는 사용자 인터페이스가 여전히 수정되고 있는 동안 완료되었다. 재작업이 필요했지만 그 변경 사항들은 통합하기가 비교적 쉬웠다.

강력한 함수 테스트 세트를 갖추고 나서는, 시스템을 재 테스트 하기가 쉬웠다. 작은 변경 사항들을 재 테스트 하고 변경 사항들이 다른 코드에 영향을 미치지 않는다는 것을 확인하려고 할 때 반복 작업까지도 수월하게 했다. 우리의 함수 테스트 스크립트를 유스 케이스에 매핑하여 주어진 유스 케이스와 제휴된 요구 사항들이 변경되었을 대 어떤 테스트를 실행해야 하는지 즉시 알 수 있다.

위로

GUI 테스트

비 GUI 코드의 개발자들이 단위 테스팅 노력을 통해 매우 생산적이 될 수 있는 반면, JSP/서블릿 개발자들은 스케줄을 지키느라 힘든 시간을 보냈다. 이들이 가장 힘들어 하는 것은 GUI 필드의 테스팅 과정이었다. 다음과 같은 과정을 반복적으로 수행해야 했다.

1. 데이터베이스에 테스트 데이터를 설정한다.
2. 웹 브라우저를 통해 애플리케이션에 로그인 한다.
3. 테스팅 될 스크린을 검색한다. (필드가 채워져야 하는 형식)
4. 특정 테스트에 의존하여 스크린에 한 개 이상의 필드를 채운다.
5. 알맞은 버튼을 눌러 형식을 제출한다.
6. 결과를 검사한다.
7. 모든 가능한 조합들을 테스트 할 때까지 다른 테스트(다른 필드 값 또는 필드)를 위해 4 단계로 돌아간다.

몇몇 GUI 테스트는 특별히 성가시다. 똑 같은 길이가 긴 값의 엔트리를 여러 필드에 두어야 한다. cut-and-paste를 사용하는 것이 도움이 되었지만 이러한 테스트를 반복적으로 수행해야 하는 팀에게는 여간 성가신 일이 아니었다. 몇몇 스크린은 50개의 다른 테스트를 갖고 있었다.

원래 Rational의 테스팅 툴을 사용하려고 하지 않았지만 GUI 테스팅의 어려움 때문에 이 툴을 사용하는 것을 검토하게 되었다. Rational Robot을 사용하여 대부분의 GUI 단위 테스트를 자동화 하기로 했다. 이러한 테스트들을 다음과 같은 방식으로 조정했다.

• 개발자들은 각 테스트의 단위 테스트 스팩에 대한 윤곽을 짰다.
• 주니어 I&T 멤버들이 단위 테스트 스팩을 가져다가 현재 소프트웨어 구현에 기반한 스크립트를 만들었다.
• 단위 테스트 스크립트는 설정 관리형이기 때문에 변경 사항들이 추적될 수 있었다.
• 주기적으로, 개발자는 I&T 팀에 단위 테스트 스크립트를 실행하고, 단위 테스트 스팩의 성공 또는 실패를 알리는 태스크를 할당했다.

이러한 접근 방식이 놀랍게 통했다. I&T 팀에게 초기 개발 과정 동안 더 많은 작업을 줄 뿐만 아니라 단위 테스트 스팩을 노출하여 소프트웨어를 검사할 기회를 주었다. 더욱이 GUI 테스트에 Robot을 사용한 경험으로 다른 함수 테스트 스크립트를 준비할 수 있었다.

Rational Robot이 시작하면 테스트 스크립트가 제휴 될 기존 프로젝트(Rational Administrator를 사용하여 만들어짐)를 선택해야 한다. 우리의 경우, 프로젝트의 위치는 네트워크 상에서 액세스 가능했기 때문에 프로젝트 데이터베이스를 전체 팀들과 공유할 수 있었다. Administrator 툴에서 ASDI 프로젝트를 만들어서(그림 3) Robot에 의해 하나가 프롬프트 될 때 프로젝트를 선택했다.

그림 3: Rational Administrator로 프로젝트 생성하기

A Validation Test Example

매우 단순한 GUI 테스트 예제처럼, 클라이언트 측 밸리데이션이 partSearch.jsp 스크린에 대해서도 정확히 작동한다는 것을 확인하는 것이다. 이것은 JavaScript 코드를 실행하여 필드의 유효성을 검사하는 것이다. 예를 들어, 이 스크린에 입력된 파트 넘버는 0 보다 큰 정수여야 했다. 사용자가 무효 파트 넘버를 입력하면 자바스크립트 모드는 에러를 보고하고 서버에 잘못된 값을 보내지 않는다. 우리의 자바스크립트 코드는 형식 밸리데이션을 위한 Netscape의 샘플 코드에 제시된 방식을 따랐다. 비록 우리는 FormChek.js 파일 대신에 우리만의 밸리데이션 코드를 작성했지만 말이다. 이 코드를 적소에 배치하여 음수 파트 넘버 엔트리가 창에 나타난다.(그림 4)

그림 4: partSearch.jsp 스크린 밸리데이션

Test Script 만들기

Robot에서 스크립트를 만들어서 파트 넘버 필드 밸리데이션이 알맞게 작동하는지 여부를 테스트 했다. Robot은 스크립트의 이름을 입력하라는 프롬프트를 띄운다.(그림 5)

그림 5: 새로운 GUI 스크립트 기록하기

OK를 클릭한 후에 레코딩 콘트롤(그림 6)이 생겼고 Robot이 애플리케이션을 기록하는 동안 윈도우 기반 애플리케이션을 사용할 수 있었다. 이 예제에서 Internet Explorer 5를 시작하여 partSearch.jsp 페이지를 검색하고 잘못된 파트 넘버(-123456)를 입력하고 Submit을 클릭했다.

그림 6: Robot recording control

Robot은 GUI 스크립트에 우리의 액션을 기록했다.(그림 7) 이는 매우 단순화된 예제이다. 실제 테스트에는 보다 포괄적인 테스트 스크립트가 포함된다. 우리는 수 백 개의 개별 스크립트를 만들지 않고 대신 스크린 당 하나의 큰 스크립트를 디자인 했다. Robot 관련 문서에는 테스트 디자인에 대해 상세히 나와있다. 그 권고안에서 많은 것을 차용했다.

그림 7: Robot GUI 스크립트 샘플

(크게보기)

인간이 읽을 수 있고 쉽게 편집할 수 잇는 스크립트가 있기 때문에 테스팅 시 작은 변경 사항에 대해 일일이 전체 스크립트를 재기록 할 필요가 없었다. 가끔 테스트를 재실행 하지 않고 스크립트를 직접 편집하거나 테스트의 작은 부분을 재기록 하고 이를 기존 스크립트에 붙였다.

테스트 실행하기

테스트를 다시 실행하려면 Robot 레코딩 콘트롤 상에 "play" 버튼을 누른다. (또는 File 메뉴에서 Playback을 선택한다.) 스크립트는 원래 수행했던 것처럼 테스트를 재실행 했고, 끝마쳤을 때 Rational TestManager를 실행하여 결과를 요약했다. 위 예제의 경우, TestManager는 그림 8과 같은 리포트를 디스플레이 한다.

그림 8: Robot 테스트 성공을 알리는 TestManager

(크게보기)

잘못된 파트 넘버가 포착되지 않아서 코드가 깨졌을 경우 에러를 나타내는 윈도우를 디스플레이 하는 대신 애플리케이션은 서블릿에 대한 데이터를 붙여 검색을 수행한다. 스크립트를 재생하는 것으로 GUI 테스트를 재실행 하면 Robot은 문제를 잡고 TestManager 리포트가 결과를 보여준다.

그림 9: Robot 테스트 실패를 알리는 TestManager

(크게보기)

위로

요약

우리가 ASDI 프로젝트를 시작했을 때, Rational의 분석 및 디자인 툴을 사용하고 아울러 테스팅 툴도 사용하려고 했었다. Phase 1 지점에서 Rational의 테스팅 툴을 사용해서 테스팅 프로세스를 자동화 하고 향상시킬 수 있다는 것에 놀랐다. 이 툴은 많은 교육이 필요하지만 일단 각 툴의 특징을 이해하면 팀의 생산성은 매우 높아졌다. 어떤 경우, 개발자들이 개별적으로 Rational Purify, Quantify, PureCoverage 같은 툴을 사용하여 단위 테스팅 노력을 보완했다. Rational Robot 같은 기타 툴들은 I&T 의 전문성과 집중을 요했다.

예고

팀은 시스템 레벨에서 통합 및 테스팅을 수행해야 했다. 대부분의 단위 테스팅 노력은 끝났지만 하위 시스템과 전체 시스템을 보다 철저히 테스트해야 했다. 이는 정식 구현, 최종 구현 문서, I&T 강화를 의미했다. 특히 부하 테스팅은 테스팅 노력에서 작은 부분을 차지했지만 전체 시스템의 테스팅에는 큰 부분을 차지할 것이다. 다행히, 우리의 테스트 슈트는 95% 완성되었고 소프트웨어는 스케줄 대로 진행되기 때문에 시스템 테스팅에 대한 추가적인 노력을 기울이면 Phase 1을 완성이 멀지 않았다.

주요 리스크

기사의 원문보기

• Applying Rational tools to a simple J2EE-based project, Part 8: Testing the software

필자소개

아티클 순위

의견

위로

목차

• 단위 테스팅
• 함수 테스트
• GUI 테스트
• 요약
• 필자소개
• 의견