모바일 이미지 매칭 기반 테스트 툴 개발

작년에 모바일 앱 개편 프로젝트가 있었다. 이것은 검색어를 입력하고 버튼 들을 누르는 일련의 동작으로 시나리오가 구성되어 있는데 다수의 키워드에 따라서 나오는 화면이나 아이콘들도 다르고 키워드만 바꿔가면서 동일한 동작을 매우 여러 번 실행할 필요가 있었기에 프로토 타입 형태의 테스트 툴을 만들어 실제 프로젝트에 적용해 보았다.

여기에 쓰인 기술들은

1. 개발 언어는 AutoIT, 이미지 매칭을 지원하는 DLL

2. 주요 컨셉은

- 텍스트 시나리오 파일에서 단위 시나리오를 읽어서

- 그중 이미지와 관련된 정보를 읽어 이미지 파일이 화면에 있다면 어떤 마우스 액션을 하는 것이다.

일견 구현하기 어려운 것으로 생각되지만 이미 많은 선각자들이 해놓은 것이 있으므로 기본적인 검증은 이미 다 된 상태였다.

현재 구현 완료된 상태는 아이폰/안드로이드 모두 동작 가능, 입력 키워드 들을 텍스트 파일로 별도로 저장해 두어 하나 씩 읽어 화면상에 입력, 글자 입력은 한글/영문 모두 가능, 글자 입력은 단순히 클립보드를 붙여넣기 하거나 메시지를 한꺼번에 전달하는 방식이 아닌 - 아이폰의 경우는 이렇게 할 수도 없다 - 정말 화면에 발생해 있는 아이폰/안드로이드의 쿼티 자판을 하나씩 클릭해 가면서 글자를 입력하는 것. 이것이 가능한 이유는 한글 영문 글자를 자소 단위로 분리한 후 다시 특수키와의 조합이 필요한 글자인지 또 분리하고 그 분리된 것들을 하나 하나 현재 모바일 폰의 자판 상태 - 한글, 영문, 숫자, 숫자-한글, 숫자-영문 -를 판단해서 입력하기 때문이다.

여러 번의 테스트 결과 P사의 V 모델은 이 테스트에 아주 적합하지 않았다. 수 백번의 실험 끝에 알아낸 결론인데, 이 폰은 반복 자동화 테스트에 쓰면 안 된다는 거였다. 이유는 실행 반응성이 일정하지 않고 느려지다가 빨라지는 것에 아무런 일관성이 없기 때문이다. 추측컨대 무리하게 오버클럭을 하거나 강제로  CPU 클럭을 조정하는 게 아닌가 싶다. 반복 작업의 테스트에서는 아주 취약한 이슈이므로 이제는 이 폰을 반복 자동화 테스트 용도로 사용하지 않는다.

한글 자소 분리하는 알고리즘은 이미 자바로 많이 나와있으므로 포팅에는 문제가 없었다. 관건은 모바일 자판의 상태를 알아내는 것인데 이것도 찬찬히 따져보니 나름의 규칙이 있어 이를 구현했다. 이렇게 하는 이유는 이런 방식이야 말로 아이폰, 안드로이드 구분 없이 하나의 키워드 텍스트 파일만으로 자판 입력을 할 수 있기 때문이다.

금년 들어 이 자판 자동 입력도 고도화를 진행하고 있는데 그 주안점은 다음과 같다.

1. 키패드가 열려 있는 상태인지 아닌지 판단

2. 자판의 배열은 몇 몇 개를 빼면 모두 일정한 규칙을 가지고 있기 때문에 5-6개의 키의 좌표만 입력하면 나머지 다른 자판의 XY 좌표를 계산하도록 변경 (이 때문에 새로운 자판을 입력하기가 백만배! 줄어 들었다!)

3. 자판 입력에 필요한 로직을 탈 때 이어 나오는 글자의 순서에 따라 자판 타이핑 속도가 들쭉 날쭉하게 되는데 이것을 항상 2s 이상 걸리도록 계산

4. 버스번호 입력을 위해 - 자판 지원

이제는 스트링을 날리면 알아서 화면 상의 자판을 하나씩 터치해 준다. 물론 느리다. 그렇지만 통계적으로 자주 사용되는 키워드들을 매 빌드마다 마음만 먹으면 입력해서 결과를 이전과 비교해 볼 수 있다는 장점은 이 시간을 상쇄해 주고도 남는다. 당연히 머신이 정해진 시나리오를 진행하는 동안 나는 다른 일을 할 수 있지 않은가!

이 이미지 매칭 모바일 반복 테스트 툴의 장점은

기존에 일련의 스크립트 방식으로 액션을 요청하는 툴들에서 볼 수 있는 SLEEP을 수치로 지정하지 않아도 된다는 것이다. 이것이 무슨 말인가 하면 어쨌든 액션과 액션 사이에는 일정 시간의 유휴가 필요한데 특히나 모바일 폰에서는 서버에서의 응답이 느리거나 모바일 폰 자체가 반응성이 일정치 않을 수 있기 때문에 고정 값을 주는 것 자체가 무의미 하다.

결국 이 문제에 대한 해결책은 또 이미지를 통해서 찾았는데 모바일 앱의 주요 화면 구성을 보면 맨 위는 검색창 아래는 키패드 중간 영역은 거의 변하지 않도록 되어 있다. 그래서, 이 중간 영역의 픽셀을 모두 잡아서 MD5 Hash 값으로 만들고 시간이 지남에 따라 이 Hash값이 바뀌지 않는 회수가 일정수에 도달하면 아! 이제는 화면 움직임이 멈췄구나... 다음 액션을 실행해도 된다! 는 것이다. 매우 간단한 알고리즘이지만 구현하는데 어려움이 매우 많았다. 화면 픽셀을 가져다가 연산을 하는 도중에 PC 메모리 리키지가 발생해서 결국에는 PC 프로그램이 메모리 부족을 내었기 때문이다. 결국 변변한 프로파일링 툴 조차 없는 상황에서 일일이 주석 처리를 해가며 1-2시간 돌려서 여전히 메모리 부족인지 판단하기를 수 차례 반복해서 결국엔 내가 할당한 메모리를 해제하지 않았음을 알게 되었다. 이제는 3-4시간 돌려도 PC가 메모리 부족에 빠지는 경우는 없으며 오히려 아이폰 메모리가 줄어들어 블랙 아웃이 되어 버린다.

위와 같은 화면 픽셀 to Hash 방식을 통해 SLEEP을 줄 필요가 없으며 같은 회수를 얼마로 할 것인지 타임아웃이 얼마나 필요한지만 결정하면 화면 출렁임이 멈춘 이후에 다음 액션을 수행할 수 있었다.

1. 시나리오에서 SLEEP 값을 결정하지 않고 사용하지 않아서 발생하는 이득

2. 시나리오가 실패하면서 받는 스트레스와 재실행 낭비 시간

이 이득인 반면, 단위 시나리오들이 최적의 시간 안에 실행되지 않는다는 단점은 있을 것이다. 하지만, 여러 번 반복해서 시나리오를 실행하다보니 이 시나리오 전체는 약 3시간 정도 걸리겠구나 하는 것을 알 수 있었고 그에 대응해서 작업을 하면 되었다.

현재 고도화는 진행중인 상태이며 위에 언급 말고도 많은 진전이 있었다. 언젠간 전체 세트가 완성된 후 다시 그 개발 소감을 적을 날이 올 것이다.

그럼...