테스트 자동화 프레임워크 - appium 도입

! 앱피움 소개, 설치 방법을 가이드하는 글이 아닌, 조직에 도입하면서 겪은 경험을 일기처럼 써 내려간 글입니다. 글 중간중간 가볍게 적은 내용에서 인사이트를 얻으실 수 있기를 바랍니다.

---

https://github.com/appium/appium-desktop

앱 테스트 자동화를 알아보다 보면 엷은 물줄기가 호수로 모이듯이 결국 앱피움(appium)이라는 오픈소스 테스트 자동화 프레임워크로 귀결된다. 이번에 QA 조직에서 테스트 자동화를 도입할 수 있도록 가까운 곳에서 지원하며 익힌 내용을 두서없이 기록해본다. 이미 인터넷에는 앱피움의 소개 글이나 설치 방법들을 어렵지 않게 찾아볼 수 있는데 정작 이것으로 무엇이 가능하고, 어떻게 활용되는지에 대한 글은 부족해 보인다.

공식 홈페이지의 내용인데 현실은 그렇지 못하단다.

 

아니, 어쩌면 이미 얕게 충분히 살펴본 사람들의 글이라서 지식의 저주[1]에 빠져 내용 전달이 부실하게 느껴진다. 공식 홈페이지를 살펴보고 나서 찾아본 블로그 내용들은 하나 같이 2% 부족했다. 그나마 appium을 어느 정도 이해하고 나면 배달의 민족 기술 블로그에 올아와있는 글은 상당히 잘 작성되어 있는 게 보인다. 아무튼, 그래서 이번 글에서는 처음 appium이라는 키워드를 접한 사람 기준으로 내용을 살펴보도록 하겠다. 키워드를 처음 접하고 테스트 자동화를 도입하려는 모든 분들께 도움이 되기를 바란다. - 내 글도 결국 2% 부족한 글로 남을지도 모른다.

Hello, appium

앞서 말한 대로 appium은 테스트 자동화 프레임워크이다. iOS, AOS 그리고 웹 환경을 지원한다

출처 : Mobile Test Automation with Appium

 

여기서는 네이티브 앱 기준으로만 설명할 텐데 iOS와 AOS의 보안 규격이나 플랫폼을 구성하는 기반부터 차이가 있기 때문에 처음 접하는 사람 기준으로는 가급적 AOS로 appium을 시작하라고 이야기하고 싶다. iOS는 .ipa파일로 리얼 디바이스 테스트하거나 소스 코드 기반으로 .app파일을 시뮬레이션 환경에서 돌릴 수 있지만 개발 조직과 QA 조직이 분리되어 있는 상황이라면 소스코드를 공유해야 하는 등 여러 가지로 녹록지 않기 때문이다 [2]. 반면 AOS는 .apk파일만 있으면 시뮬레이션, 리얼 디바이스 환경에 모두 대응이 가능하다. 이 내용은 공식 도큐먼트에 있지만 찾지 못하면 하루 종일 삽질하게 될 수 있는 내용이다. 

여기서 앱피움의 설치에 대한 이야기는 하지 않을 예정이다. 공식 홈페이지나 다른 블로그 글을 통해 어렵지 않게 설치할 수 있을 것이기 때문이다. 아, 설치가 쉬운 것뿐이지 디펜던시(Dependency)를 모두 잡아내는 건 또 다른 이야기이다. appium 깃헙 레포지토리에 등록된 issue를 살펴보면 디펜던시를 모두 잡아내는 게 보통일이 아니라는 사실을 알게 된다. 부디 이 글을 보고 처음 appium에 진입하는 사람의 환경에 축복이 내려 운 좋게 모든 디펜던시를 비켜나가기를 바랄 뿐이다. 그나마 AOS는 수월하다.

등록된 이슈 개수를 보라

 

생각해보면 이렇게 많은 이슈가 있지만 Star와 Fork 숫자를 보면 핫한 오픈소스는 틀림없다 [3]. 또한 아직까지 활발하게 커밋되고 있는 이력을 보면 대세는 분명하다. 혹은 앱 테스트 자동화에 다른 대안이 없기 때문에 여기에 매달리는지도.

hello, Recorder

설치가 마무리되었으면 앱을 실행하고 레코딩 기능을 적극 활용해서 테스트 자동화를 할 수 있도록 한다. 처음 레코더 기능을 접하면 드는 의아한 생각이 있는데 녹화 버튼은 있는데 재생 버튼을 찾을 수 없다. 카탈론 같은 프레임워크를 다뤄본 사용자라면 내 행위를 녹화하고 그걸 그대로 플레이시키는 게 테스트 자동화의 시작이라는 사실을 알 수 있으니까 말이다.

녹화하거나 중지하거나, 그것뿐이다. 재생은 없다.

 

appium에서 레코더는 사용자의 액션을 소스코드로 추출하는데 목적이 있다. 소스코드를 추출하고 그것을 재생시키는 것은 별도의 테스트 코드를 작성해줘야 한다. 그렇기 때문에 appium은 개발을 전혀 할 줄 모르는 누군가에게는 굉장히 어려운 툴이겠다.

테스트 코드는 1) 네이티브 앱의 환경을 변수에 설정하고 2) WebDriver를 통해 앱피움에 연결하는 코드를 작성. 3) 레코더를 통해 추출한 코드를 붙여 넣는다 4) 끝으로 WebDriver를 닫는 등 사용한 자원을 정리해준다. 이 동작이 테스트 자동화의 기본 요소인데 다른 부분은 한번 작성되면 수정할 일이 별로 없다. 1번 로직은 테스트 설정을 별도의 파일로 빼놓고 여러 기기에 테스트 될 수 있도록 하면 좋다. 보통 개발자가 dev, stg, prd 환경을 관리하는 것과 유사하다고 생각하면 좋다. 그리고 3번 로직에 손이 많이 가게 될 텐데, 테스트 시나리오 별로 함수를 작성하고 테스트 성공/실패에 대한 리포트를 받을 수 있으면 좋다. 리포트는 이메일도 좋지만 슬랙을 회사 메신저로 사용하는 곳이라면 빠르게 연동해주도록 하자. 개발팀은 필히 이 리포트를 받아보고 대응해야 할 것이다. 전체 소스 작성은 아래 공식 홈페이지에서 사용하는 언어의 코드를 가져다 사용하면 된다. 위에서 언급한 1~4번 로직 대부분의 내용이 녹아있다.
https://github.com/appium

개발과 한걸음 떨어진 조직에서는 아무래도 파이썬이 진입 허들이 낮기 때문에 추천하도록 한다.
https://github.com/appium/python-client/blob/master/README.md

마무리

앱피움 키워드를 알고 나서 약 일주일 정도 파헤졌다. 회사에서 해야 하는 일은 따로 있던 터라 일과를 쪼개서 틈틈이 봐야 했고 더 다양한 시도를 하지 못해 아쉬움이 남는다. 아마도 다음 사람이 앱피움 기반으로 더 많은 것을 이루리라 믿어 의심치 않는다. 이전에 숙박 플랫폼을 개발하는 회사에 재직하던 시절 각 파트의 기술에 대해 공유하는 시간이 매주 있었는데 QA 조직에서 테스트 자동화에 대한 부분이 이야기되었었다. 당시에는 흘려 들었는데 이제야 이해가 되고 안개가 걷히는 느낌이다. 본인은 “자동화” 자체에는 꽤 일가견이 있어서 파이썬으로 셀레니움을 꽤 능숙하게 다루고 있었지만 웹이 아닌 앱으로 넘어와서 자동화를 하려고 보니 장님이 된 듯한 느낌이었다. 이번 기회에 눈을 가리고 있던 무지를 없애고 또 하나의 지식을 늘리게 돼서 대단히 기쁘다. 나와 비슷한 상황의 누군가에게 이 글이 도움이 되기를 바란다. 끝으로 조직에 도입할 수 있도록 힘써주신 헤라님께 감사. :) 

 

---

[1] 어떤 정보에 대해 청중이 모를 거라는 생각 자체를 하지 않는다. 예를 들면 우리 동네에 놀러 온다는 조카에게 버스에 탈 때 교통카드를 찍어야 한다는 사실을 말하지 않는 것과 같다. 하지만 조카는 버스를 타본 적이 없다. 이건 다 같은 지식수준을 갖고 있을 거라는 함정에 빠진 것이다.
[2] 보통의 개발 조직에서 소스코드 열람 권한은 관련된 개발자에게만 허용된다.
[3] 깃헙에서 star와 fork 숫자는 그 프로젝트의 인기 척도를 나타낸다고 해도 과언이 아니다.