SIKULI를 이용한 GUI 테스트 자동화

현재 직장에서 툴 프로그래머로 일하고 있습니다. 소스 코드 규모가 커지고 작업하는 사람들이 많다보니, 한쪽에서 작업한 변경으로 다른 모듈 기능에 의도치 않은 장애가 발생하는 일이 잦았습니다. 특히 엔진 쪽 변경으로 에디터 관련 기능에 장애가 생기는 일이 자주 생겼습니다. 이 문제를 해소하고자 에디터 테스트를 일부라도 자동화할 수 있는 방법을 찾게 되었습니다.
(이하에서는 GUI 관점에서의 black-box testing에 대해서만 다룹니다.)

고려했던 대안들
기존에 익숙했든 AuotIt부터 시작해서 다음과 같은 도구들을 고려해봤습니다.
AutoIt
  • 윈도 플랫폼에서 돌아가는 Basic과 유사한 스크립트 언어
  • 컨트롤 아이디, 클래스, 텍스트 등으로 특정 UI 요소 식별
  • 일반 용도의 자동화 도구로도 매우 유용
TestComplete
  • 상용 테스트 자동화 도구
  • 일반적으로 위의 AutoIt 유사한 UI 요소 식별법 사용
  • 편리한 IDE 제공
  • 여러 스크립트 언어 지원
SIKULI
  • Jython 기반으로 멀티플랫폼
  • 컴퓨터 비전 기반 UI 요소 인식
    • 이미지 비교 결과(퍼센티지 문턱값 지정)에 따라 매치 여부 결정
  • 기본적인 IDE 제공
  • 개발 초기 단계
신선한 개념과 이미지 인식 기반이라 화면 상 임의의 요소에 반응할 수 있다는 장점에 끌려 시쿠리로 방향을 잡았습니다. 시쿠리가 어떻게 기능하지는 아래 동영상이나 튜토리얼 페이지를 보시면 금방 감잡으실 수 있습니다.

이하에서는 저의 시쿠리 실험이 어떻게 진행되었는지 이야기합니다.

진행 상황

일단 QA 팀에서 하고 있는 에디터 수동 테스트의 상당수를 자동화 하는 것이 첫 목표였습니다. 현재까지 대략 기존 수작업 테스트의 70% 정도는 자동화 했습니다. 등록된 테스트가 모두 끝나면 html 형식의 리포트를 만들게 했습니다. 각 테스트 항목의 성공 여부를 보여주고, 실패한 경우 어떤 이미지 매치가 문제였는지 표시하였습니다.
[예제 테스트 항목들]
  • 에디터 실행/종료
  • 각종 서브에디터 창 열기
  • 새 레벨 생성 및 저장
  • 기존 레벨 불러오기
  • 레벨 익스포트
  • 뷰모드 전환
  • 각 서브에디터별 기능 테스트
하지만 작업 과정이 생각했던 것만큼 수월치는 않았습니다. 가장 큰 문제는 역시 컴퓨터 비전 기반이라는 점에 있었습니다. 화면 상 이미지에 의존한다는 것이 양날의 검이었던 것이죠.

느낀 점
  • 유지보수가 힘들다: UI가 변할 때마다(아이콘, 컨트롤 텍스트, 리사이징) 테스트에 사용되는 이미지도 적절히 갱신해주어야 합니다. 상당히 번거롭습니다.
  • UI 요소를 식별하기 위해 적절한 비교 이미지 영역을 선택하는 것이 쉽지 않다: 너무 작은 부분을 고르면 매치 영역이 여럿이 되어버리고(정밀도가 떨어지고), 그렇다고 확실하게 크게 잡으면 UI 리사이즈같은 작은 변화에 너무 민감하게 되어서 유지보수가 번거로워지는 일이 다반사였습니다.
  • 테스트 성공 여부 식별의 문제: 테스트 성공 여부도 특정 UI 요소 혹은 특정 텍스트가 보이는지 여부로 결정하게 됩니다. 이 역시 노이즈에 너무 약합니다. 이론적으로는 렌더링 결과 비교도 가능합니다만, 역시 개발 중에는 렌더링 변경이 잦은 관계로 안정적인 테스트가 힘들었습니다. 가령, 백버퍼 클리어 색상이 바뀌었다든지 하면 역시 잘못된 실패 보고가 뜨고 그 때마다 테스트 이미지들을 갱신해주어야 했습니다. 결국에는, 컴퓨터에 의존하지 않고, 뷰포트 스샷을 찍어 최종적으로 테스터가 성공 여부를 판별케 하는 반자동(?) 방식을 일부 도입해야 했습니다.
  • 아직 개발 초기라 다듬어지지 못한 부분이나 버그가 많다: 특정 함수 관련 메모리 릭과 같은 버그도 있었고, 키보드 레이아웃이 영어가 아닌 경우 키입력 함수(type())가 오작동하는 버그도 있었습니다(이 경우, 클립보드 함수인 paste()를 이용하는 방법으로 문제를 우회할 수 있었습니다). 매치에 사용되는 이미지 관리에도 리네이밍 같은 필수적이 기능이 IDE에 빠져있었고(최근 버전에서 해결), 테스트 세트가 커질 경우 중요한 모듈화 및 그 관리에도 현재로선 명쾌한 해답이 없는 상황입니다. 다행히, 버그에 대한 개발자의 응답 및 임시방편 제시는 생각보다 빨랐습니다. 질답 게시판도 도움이 되었고요.
  • 디버깅의 어려움: 전문적인 디버깅 환경이 지원되지 않다보니, 긴 테스트 함수에서 특정 매치가 실패할 경우, 문제 지점을 파악하고 수정하는 과정이 더딥니다.
  • 수행 성능도 이미지 비교 기반인지라 아주 빠르지는 않습니다만, 크게 문제될 정도는 아니었습니다. 개발 시에 IDE의 특정 동작이 매우 느리게 동작하는 경우가 있어 답답하긴 했습니다.

결론
쓰다보니 아주 몹쓸 물건처럼 묘사된 것 같습니다만...; 꼭 그렇지는 않습니다. 사실 다른 대안들에서 사용하는  컨트롤 아이디나 클래스 기반 UI 식별도 빈도는 적을지 몰라도 유사한 유지보수 문제를 안고 있습니다. 그리고 분명 그런 대안들에서는 아예 불가능한 것들이 시쿠리로는 쉽게 되는 부분도 많았습니다.
  • 아직은 개발 초기로 거친 면이 많은게 사실입니다. 하지만, 개발자가 계속 의지를 가지고 개선해나가면 전망은 밝다고 봅니다.
  • 내부 코드의 도움없이 순수히 외부 UI 식별만으로 안정적인 UI 테스트 자동화를 이루기는 거의 불가능합니다. 내부 스크립팅 기능을 외부에서 접근해서 자동화할 수 있다면, 훨씬 견고하고 유지보수가 용이한 테스트 세트를 구축할 수 있습니다.
  • 렌더링 회귀 검사에 유용해보입니다.
  • 개인 작업의 자동화 용도로도 강추입니다.


Trackback 0 Comment 12

top