Andrew's Garage

NHN 검색QA팀 손민혁

끊임없이 테스트 자동화 도구가 나오는 이유는, 그 필요성은 절대적이지만 그 어느 것도 요구를 충분히 만족시키지 못하고 있기 때문입니다.

QA 부서에 있으면서 주변의 테스트 자동화 사례를 살펴보면, 자동화 작업을 진행하다가 어느새 조용히 중단하기도 하고, 끝까지 완료해도 오랫동안 유지보수하지 못하는 경우가 많습니다. 그 이유 중 하나는 테스트 스크립트 작성/유지보수가 어렵기 때문입니다. 프로젝트 기간 동안 일정에 맞춰서 개발하고 QA를 진행하기에도 바쁜데 테스트 스크립트를 작성하고 변경되는 코드에 따라 테스트 스크립트까지 계속 유지보수하려면 항상 인력과 시간이 부족합니다.

그렇다면 지속적인 테스트 스크립트 유지보수는 왜 그렇게 어려울까요? 테스트 대상 프로젝트의 특성, 작업 환경, 투입 리소스, 잦은 기능 변경, 작업자의 노력 등 여러 가지 이유를 들 수 있을 것입니다. 그러나 여기에서는 자동화 도구에 초점을 맞추었습니다. 기존의 테스트 자동화 도구가 좋지 않다거나 기능이 떨어지는 것은 아닙니다. 다만 우리의 현실과 다소 맞지 않는 것이 문제입니다. 이 문제를 해결하기 위해 GUITAR(GUI test automation framework)라는 테스트 자동화 시스템을 개발했습니다.

• GUITAR 주요 기능

  GUITAR는 이미지 기반의 웹 테스트 자동화 프레임워크이다. IDE 환경에서 스크립트를 작성하고 스크립트에 필요한 이미지를 캡처할 수 있으며 실행한 테스트 결과 리포트도 제공한다.

  주요 특징은 다음과 같다.

• 한글 스크립트 사용
• 크로스 브라우징(인터넷 익스플로러, 파이어폭스, 사파리, 크롬, 오페라) 지원
• 자바스크립트 오류 자동 검출(인터넷 익스플로러, 파이어폭스, 크롬)
• 변수, include, 조건문, 반복문 지원
• 원격 관리/실행 지원(CI 연동)
• 리포트, 알림, 동영상 캡처 지원
• AutoIt 내부 명령어 지원

• GUITAR 구조

  GUITAR는 스크립트를 유지보수/실행하는 메인 프로그램과 원격 관리를 담당하는 에이전트, 이미지 모듈, 업데이트 모듈로 구성된다.

  GUITAR로 작성된 스크립트는 이미지와 텍스트로 저장되며, 인터넷 익스플로러를 비롯한 다양한 브라우저를 대상으로 테스트를 수행할 수 있다.

  실행 결과는 HTML 형태로 제공되며, 전체적인 테스트 현황을 보여주는 요약 리포트 화면과 상세 리포트 화면으로 나뉜다. 메일, SMS 등으로 테스트 결과를 전송할 수도 있다.

  

  그림 1 GUITAR 시스템 구조

• 스크립트 구조

  GUITAR의 스크립트는 다음 그림과 같이 크게 3개의 트리로 구성된다.

  

  그림 2 GUIRAT 스크립트 구조

  테스트 스크립트에는 실제 수행될 스크립트 파일이 있고, 공용 스크립트와 공용 이미지에는 테스트 스크립트 내부에서 참조하여 사용하는 스크립트와 이미지가 있다. 테스트 스크립트의 최종 리프(leaf) 폴더에는 실제 수행될 스크립트 폴더가 존재하며, 각 테스트 스크립트 폴더에는 해당 스크립트가 사용하는 이미지 폴더가 존재한다. 계층 구조 형태로 공용 폴더나 자신의 하위 폴더에 위치한 스크립트를 자유롭게 호출하여 사용할 수 있다.

• 한글 스크립트

  다음은 테스트 자동화 도구로 가장 많이 사용하는 Selenium으로 작성한 테스트 스크립트의 예이다.

  

  그림 3 Selenium 테스트 스크립트

  위 스크립트가 어떤 테스트를 수행하는지 쉽게 알 수 있는가? 위 스크립트의 기능은 다음과 같다.

• 네이버 메인 페이지에 접속한다.
• 검색어 “GUI 테스트 자동화”를 입력하고 검색을 수행한다.
• 검색 결과 내용을 확인한다.

그럼 아래 내용을 보자.

그림 4 GUITAR 테스트 스크립트

위 내용은 테스트케이스 문서의 일부가 아니다. 위의 Selenium 스크립트와 같은 기능을 수행하는 GUITAR의 테스트 스크립트이다. GUITAR를 사용하면 한글로 테스트 스크립트를 작성할 수 있으므로 자동화 작업 담당자가 변경되거나 오랜 시간이 지난 뒤 유지보수를 위해 스크립트를 다시 보더라도 테스트 스크립트를 이해하기 쉽다.

• 대상과 명령

  위 예제에 사용한 실제 테스트케이스 문서를 한번 살펴보자.

  

  그림 5 테스트케이스 문서

  일반적으로 테스트케이스는 다음 두 가지를 핵심 항목으로 포함하고 있다.

• 수행할 명령
• 명령의 대상

GUITAR는 테스트케이스의 핵심인 ‘명령’과 ‘대상’을 한국어 어순에 따라 사용하기 때문에 쉽게 스크립트를 작성할 수 있다.

• 명령

명령에는 클릭, 이동, 입력 등과 같이 실제 테스트 스크립트 내에서 특정 동작을 수행하는 명령과 결과를 확인하는 등 수행한 명령을 확인하는 명령이 있다. 그리고 테스트 작업에 필요한 캡처, 대기와 같은 명령도 있다.

GUITAR는 현재(2011년 9월) 40여 개의 테스트 명령을 제공하고 있으며, 지속적으로 명령을 추가하고 개선할 예정이다.

• 대상

대상은 자동화 명령의 형태에 따라 다르다. 대부분의 대상은 이미지 형태로 사용하지만 텍스트, 변수, 숫자가 대상인 명령도 있다.

그림 6 GUITAR에서 대상의 종류

• XPath vs 이미지

  기존의 테스트 도구는 대부분 명령 대상을 지정할 때 다음 그림과 같이 DOM 트리 기반의 XPath 형식을 사용한다.

  

  그림 7 Xpath 기반의 대상 지정

  XPath를 사용하면 다양한 형태로 대상을 정확하게 지정할 수 있지만, 화면 상의 고유한 XPath를 찾아내고 이를 검증하는 추가 작업이 필요하다. 또한 스크립트를 디버깅하거나 분석하기 위해 XPath 값으로 원래 대상을 찾아내기도 쉽지 않다. 최근에는 이런 문제를 해결하기 위해 XPath 값을 변수로 바인딩하여 스크립트의 가독성을 높이는 방법을 사용하지만 여전히 XPath를 찾아야 한다는 근본적인 문제는 남아있다.

  GUITAR는 대상으로 XPath가 아니라 이미지를 사용한다. 따라서 내용이 변경되어도 쉽게 확인하고 스크립트를 수정할 수 있다.

  

  그림 8 이미지 기반의 대상 지정

• 이미지 방식의 장점

  이미지를 대상으로 사용하면 브라우저 화면 상에 보이는 이미지 기반으로 명령 대상을 찾기 때문에 HTML, 플래시, 액티브 X 컨트롤 등의 화면 구현 방법과 관계없이 대상으로 지정할 수 있다.

  아래 그림과 같은 플래시 화면의 구성 요소는 Selenium으로는 테스트할 수 없었지만 GUITAR로는 테스트할 수 있으며, 브라우저의 모달(modal) 창이나 팝업 창도 쉽게 제어할 수 있다.

  

  그림 9 Selenium으로는 테스트할 수 없는 영역

• 이미지 방식의 단점과 해결 방안

  이미지 방식으로 대상을 찾으면 미세한 픽셀 차이에도 민감하게 반응한다는 단점이 있다. 따라서 가변적인 데이터가 많은 시나리오에서는 비효율적이다. 또한 테스트 시스템의 환경 차이(색 농도, 운영체제, 시스템 설정)로 인해 이미지를 찾지 못하는 경우도 발생할 수 있다. 실제 GUITAR를 개발할 때 이런 문제가 발생했고, 다양한 방법으로 해결했다.

• 색 농도 차이

운영체제의 색 농도 설정에 따라 화면에 표시되는 이미지 색상이 미세하게 달라질 수 있다. 따라서 이미지 검색 엔진은 미세한 색상 오차를 무시하고 검색할 수 있는 tolerance 옵션을 제공한다. 이 옵션 값을 조절하면 미세하게 색상이 다른 이미지도 쉽게 찾아낼 수 있다. 아래 그림은 32비트 색 농도 환경에서 캡처한 버튼 이미지를 16비트 색 농도 환경에서 찾지 못할 때 tolerance 값을 증가시켜 이미지를 찾는 예이다.

그림 10 tolerance 옵션

그러나 tolerance 값을 너무 높게 지정하면 의도하지 않은 이미지를 찾는 경우도 생길 수 있다. 이 문제를 해결하기 위해 GUITAR는 원본 이미지의 CRC 값과 대상 이미지의 CRC 값을 비교하는 작업을 수행한다.

그림 11 이미지 CRC 추가 확인

• 글꼴 차이

운영체제에 따라 같은 글꼴도 미세하게 다르게 표현된다. 이렇게 달라진 글씨를 캡처하여 다른 운영체제에서 사용하면 이미지를 인식하지 못할 수 있다. GUITAR는 이 문제를 해결하기 위해서 테스트 작업 중에는 자동으로 운영체제의 클리어타입 옵션을 해제한다.

그림 12 클리어타입 설정 시와 해제 시 글꼴 표현 차이

• 다중 이미지 검색

브라우저의 렌더링 엔진에 따라 이미지가 미세하게 다르게 표현될 수도 있다. 이런 경우에는 브라우저별로 원본 이미지를 추가로 캡처해야 한다. 하지만 캡처한 이미지의 이름을 각각 다르게 지정해야 한다면 유지보수가 어려울 것이다.

GUITAR는 하나의 대상에 여러 이미지를 등록할 수 있다. 다음은 페이지에 접속할 때마다 이벤트 배너가 달라지기 때문에 “이벤트배너”라는 이름으로 3개의 이미지를 등록하여 사용하는 예이다.

그림 13 다중 이미지 검색

테스트 중 현재 화면에 3개의 이미지 중 하나의 이미지와 일치하면 테스트는 성공으로 처리한다.

• 복합 이미지 검색

이미지를 대상으로 지정하면 화면에 찾는 이미지가 여러 개 표시되어 원하는 이미지를 정확하게 지정하기 어려운 경우가 있다. 다음과 같은 화면에서는 거리뷰 버튼이 여러 개 존재한다.

그림 14 한 화면에 같은 이미지가 여러 개 표시되는 예

위 예에서는 아래 그림과 같이 텍스트 나루를 포함하여 캡처해서 사용하면 된다.

그림 15 텍스트와 이미지를 같이 캡처

그런데 이렇게 여러 요소를 포함하여 캡처하면 브라우저의 특성에 따라 미세한 차이가 발생하여 해당 이미지를 찾지 못하는 현상이 발생할 수 있다.

그림 16 브라우저에 따른 차이

또한 나중에 거리뷰 버튼의 이미지가 변경되면 거리뷰 버튼을 포함하는 이미지를 모두 다시 캡처해야 하는 상황이 발생한다.

이 문제를 해결하기 위해서 GUITAR는 대상을 쉼표로 구분하여 여러 개 지정하면 서로 인접한 이미지를 찾는다.

그림 17 복합 이미지 검색

대상 이미지를 두 개로 나누고 “나루, 거리뷰버튼”을 대상으로 지정하면 나루에 가까이 위치한 거리뷰 버튼을 찾는다. 이렇게 주변 이미지를 찾는 기능을 사용하면 다양한 조합으로 원하는 대상을 쉽게 찾을 수 있고, 유지보수에도 유리하다.

• 그 외 기능

• 크로스 브라우징

GUITAR는 이미지를 대상으로 인식하기 때문에 다양한 브라우저에서 테스트를 할 수 있다. 현재는 인터넷 익스플로러, 파이어폭스, 사파리, 크롬, 오페라를 지원한다.

그림 18 GUITAR가 지원하는 브라우저

• 변수, 조건문, 반복문 지원

GUITAR는 외부 스크립트를 참조하여 실행하는 기능과 변수, 조건문, 반복문 등 스크립트 진행 흐름에 필요한 기능을 지원한다. 또한 AutoIt 내부 명령도 사용할 수 있어서 다양한 예외 케이스를 처리할 수 있다.

• 자바스크립트 오류 자동 검출

GUITAR는 테스트 중에 발생하는 자바스크립트 오류를 자동으로 감지하여 알려 주므로, 따로 스크립트를 검증하지 않아도 된다. 인터넷 익스플로러, 파이어폭스, 크롬에서 테스트할 때 이 기능을 사용할 수 있다.

그림 19 자바스크립트 오류 검출 화면

• CI등 외부 시스템 연동

GUITAR는 스크립트별로 테스트 실행 URL과 결과 보기 URL을 제공하므로 빌드 배포 시스템 등의 외부 시스템과 연동하여 배포 후 자동으로 테스트가 실행되도록 설정할 수 있다. 자동으로 테스트가 실행되도록 설정하려면 빌드 배포 스크립트에서 배포 작업 뒤에 URL 접속 명령을 추가한다.

NHN에서는 BDS라는 빌드 배포 시스템을 개발하여 사용하고 있다. BDS에서 배포 서버의 PostScript에 테스트 실행 URL에 접속하는 명령을 CURL과 같은 명령어로 추가하면 배포할 때 테스트 스크립트가 자동으로 실행된다. 현재 네이버 지도 서비스는 TEST, STAGING, REAL 빌드를 배포할 때마다 각 단계에 맞는 테스트 스크립트를 실행하도록 설정되어 있다.

그림 20 BDS의 PostScript를 통한 테스트 실행

GUITAR는 테스트 결과 페이지의 URL을 제공하므로 CI 서버와 같은 외부 시스템에 결과 리포트 위치의 링크만 연결하면 쉽게 연동할 수 있다.

그림 21 Hudson 연동 화면

• GUITAR 적용 효과

  GUITAR는 일반적인 회귀 테스트(regression test)에서부터 API 테스트까지 다양한 부분에 활용할 수 있다.

• 회귀 테스트 자동화

네이버 지도 서비스에 파일럿으로 개발 중인 GUITAR를 적용해 보았다. 자동화의 목표는 지도 서스테이닝 통합 테스트케이스를 크로스 브라우징 기준으로 자동화하는 것이었다. 지도는 서비스 특성상 플래시, AJAX 등으로 구현된 부분이 많아 Selenium으로는 30% 정도밖에 테스트할 수 없었다(서스테이닝 기준). 이러한 상태에서 GUITAR를 적용하자 자동화할 수 있는 영역이 96%로 늘어났다.

그림 22 지도 서스테이닝 GUITAR 적용 결과

지도 서스테이닝 통합 테스트케이스 400여 개를 자동화하는 데 1명이 하루 3~4시간 동안 스크립트를 작성하여 1개월 정도 걸렸다. 테스트케이스 작성 기간 이후에는 일정 시간 테스트 스크립트 안정화 기간을 거쳐 실제 서비스의 배포 프로세스에 적용하여 운영하고 있다.

• 이터레이션 테스트 자동화

지도 서스테이닝 자동화 이후에 반복점진개발 방식으로 진행된 “지도 도보 길찾기” 프로젝트에도 GUITAR를 적용했다. GUITAR의 테스트 스크립트는 빠르게 작성할 수 있기 때문에 UI 산출물이 나오기 시작하는 후반 이터레이션(iteration)부터 QA 과정 중에 일부 자동화 작업을 같이 진행할 수 있었다. 이렇게 이터레이션 기간 중에 작성된 스크립트는 프로젝트 출시 후 회귀 테스트에서도 사용하고 있다.

그림 23 도보 길찾기 프로젝트 이터레이션별 자동화 적용

• API 테스트

  조건에 따라서 서비스 API 검증 테스트에도 GUITAR를 활용할 수 있다. 최근 네이버 지도 서비스에서 “대중교통 길찾기 엔진”을 수정했다. 지금까지는 엔진이 변경되면 QA와 테스트 엔지니어가 수동으로 길찾기를 실행하여 그 결과를 일일이 비교해서 검증했다. 그러나 이번에는 GUITAR를 이용하여 자동으로 길찾기 작업을 반복하고 길찾기 결과 화면을 캡처하여 이전 내용과 비교한 리포트를 생성하도록 했다. QA와 TE는 최종 리포트 결과 화면을 보고 이전 버전과 차이가 발생하는 부분만 확인하면 되므로 검수에 들어가는 비용을 절약할 수 있었다.

  

  그림 24 대중교통 길찾기 결과 비교 리포트

• 데이터 검수

  콘텐츠 형태의 서비스나 검색 형태의 서비스는 검색어나 조건을 변경하면서 반복적으로 데이터를 검수해야 할 때가 많다. 이런 경우에 GUITAR의 ‘테이블 변수’ 기능을 사용하면 쉽게 반복 테스트를 수행할 수 있다. GUITAR는 테스트를 수행하면서 자동으로 자바스크립트의 오류도 검출해 준다. 또한 테스트 대상 브라우저를 쉽게 추가할 수 있으므로 크로스 브라우징 테스트도 편리하게 수행할 수 있다.

• 맺음말

  시간은 없고 빨리 테스트를 자동화해야 할 때, 제대로 된 크로스 브라우징 테스트가 필요할 때, 팝업창이나 플래시 때문에 테스트가 막막할 때 GUITAR를 사용해 보길 바란다.

•