NDC Replay

모바일 게임 테스트 자동화
김종원
엔씨소프트
	윈도우용 아래아한글 3.0 시리즈를 개발하였으며 이후 모코코에서 리눅스 기반 스마트폰을 개발하였다. 엔씨소프트에서는 리니지 이터널의 테크니컬 디렉터로 7년간 게임 개발을 하였으며 현재는 SET 팀에서 모바일 테스트 자동화를 위한 연구 개발을 하고 있음
	모바일 게임 환경에서는 다양한 화면 크기의 디바이스로 인한 파편화로 게임의 동작이 다르기 때문에 테스트가 중요하다. 여러 디바이스에서 반복 테스트를 하기 위한 툴을 소개를 하고, 게임에서 이러한 툴을 확장하여 테스트하는 방법을 보여준다. 이를 통해 효율적인 개발 환경을 구축한다
[새 창에서 슬라이드 보기]
방금 소개받은 김종원입니다. 이렇게 많은 분들이 와주실 줄은 몰랐는데요, 꽉 채워주셔서 좀 부담이 되고 있습니다. 어, 그럼 모바일 게임 테스트 자동화에 대한 간략한 내용을 좀 전달해 드리도록 하겠습니다. 

목차는 다음과 같구요, 일반적으로 모바일 게임에 대한 이슈들을 테스트 관점에서 설명을 하고, 테스트를 자동화하기 위한 프레임 워크의 소개와 그 다음에, 저희 팀에서 좀더 게임에 특화된 테스트 환경을 구축하고자 확장한 부분에 대해서 간단하게 소개를 드리도록 하겠습니다.

어, 저는 지금 SET팀이라고, 소프트웨어 엔지니어 테스트라고 약자로 되어있는 테스트 자동화 관련된 팀에서 작년부터 일을 하고 있구요, 그 전에는 <리니지 이터널>의 테크니컬 디렉터로 7년간 일을 했습니다. 어, 엔씨 들어오기 전에는 임베디드 리눅스에다가 PDA 세트들을 올리는 작업들을 2000년 초반에 했구요, 엔씨 들어오기 전에는 이제, 팜 OS 기반의 스마트폰 시스템 OS들을 만드는 작업을 했었습니다. 엔씨에는 이제 모바일 게임기를 만들겠다 그래서 들어왔는데, 드랍이 되고, 어. 일을 찾다가 이터널을 개발하게 되었었습니다. 그 전에는 한글과 컴퓨터에서 윈도우 아래아 한글을 개발을 했었고요. 그 전에는 뭐 또, ~에서 91년부터 처음, 첫 월급을 받으면서 일을 시작을 했습니다. 마이크로소프트웨어나 지디넷에 망치와모루라는 필명으로 칼럼을 기고를 했었구요. 뭐 제 나이대쯤 된 분들은 대부분 ~~키드라고 해서, 1986년 전국 퍼스널 컴퓨터 경진대회 인데요, 가운데 있는 게 접니다. 정말.. (웃음) 파릇파릇하죠. 중학교 3학년이니까요. 어.. 다들, 보기 힘든 요즘. 저 컴퓨터를 다 집에서 들고 왔어야 된다는 사실에 다들 놀라더라고요. (웃음) 체육관에서 300명이 모여서 대회를 합니다. 3시간 동안 문제를 풀면서.. 자, 이제 본격적으로 들어가 보겠습니다. 

제목대로 모바일 게임과 PC게임의 환경을 비교를 해봤는데요, PC게임을 저도 7년간 만들어 봤으니까, 그때 생각했던 거에 비해서 모바일 게임은 완전히, 오더라고 그러죠, 규모가 너무 다른 것 같습니다. 그래서, 플레이어 수라든지, 설치되어 있는 OS의 버전이라든지, 기기의 다양성, 뭐 화면의 크기, 네트웍 관련된 이슈들이 다들 숫자가 너무 크게 다른 거예요. 그러다 보니 어떻게 이 부분들을 감당해야 될지. 다들 운에 맡기고 일을 하고 있는 거죠. 그래서, 모바일 게임 이슈들을 보면 이제, 유저 측면과 기기 측면을 일단 보자면, 유저들은 굉장히 작은 이슈에 민감합니다. 그래서 설치하다가 크래시가 나. 그럼 그냥 지워버리죠. 그리고 특별히 이게 유명한 데서 만들었다 하더라도 내게 안 되면 굳이 그거를 하려고 애쓰지 않더라도 다른 게임이 많이 있죠, 그래서 충성도가 별로 없습니다. 아무리 유명한 데서 나왔다 그래도 그냥 안 돌아가면 마는 거죠. 

기기적인 측면에서 보자면 다들 최신 휴대폰만 들고 다니는 건 아니지 않습니까, 그래서 굉장히, 게임이 돌아가는 환경 자체가 굉장히 다양합니다. 심지어는 같은 모델조차도 몇 번의 OS 업그레이드가 이루어지면 모든 사람들이 그걸 같이 따라가지 않아요. 그래서 뭐 예를 들면, 갤럭시노트2다. 그러면 OS가 한 세 개 네 개 쯤 흩어져 있는 거죠. 거기에 돌아가는, 같은 갤럭시노트2라지만 다른 동작을 하게 됩니다. 

이게 굉장히 유명한 그림이에요, 2014년에 이제, 나온 그림인데, 안드로이드 기기들에 대한 개수와 모델들을 그린 겁니다. 찾아보시면 나올텐데요, 2014년이니까 지금 2년 전이라 훨씬 더 많은 모습들을 볼 수 있고, 이렇게 굉장히 다양한 안드로이드 기기들이 있습니다. 
화면들을 볼게요. 왼쪽이 이제 화면 해상도별로 쭉 그림을 보인 건데요, 진하게 보이는 게 기기들이 많은 거고, 흐리게 보이는 게 개수가 상대적으로 적은 그림인데요, 보시면 이제 해상도가 다 다르죠. 뭐 이렇게, 생각하시기에 몇 개의 해상도가 없을 거라고 생각하실 수 있겠지만 저 사이에 수많은 흐릿하게 생긴 저 다양한 해상도를 보시면, 내가 만든 게임이 어떤 해상도에서 동작할 거라고 예측한다는 건 굉장히 오만하구나 라고 생각할 수도 있을 거예요. 

오른쪽 그림은 비교적 최근에 나온, 블로그에서 제가 캡쳐를 해왔는데요, 지난 5년간 휴대기기 화면의 변화라고 하면서, 다양한 인치, 저게 해상도는 또 아닙니다. 물리적인 인치에 대한 분포도로 보시면 될 거 같습니다. 보시면 다양한 기기들이 존재합니다. 그 환경에서 우리는 어떻게 테스트를 해야 되는지가 이제 고민이 되는 거죠. 이것 외에도, 네트워크 사용성 측면이라든지, 프로젝트 관리 측면에서도 이슈가 있습니다. 뭐, 네트웍은 여러분이 잘 아시겠지만 PvP게임할 때는 엘레베이터 타면 안 되죠. 하다가 끊기면 이제, 끝나있죠 다. 다 부서져 있고. 
프로젝트 관리 측면에서 보자면 이제, 저희 엔씨처럼 조금만 큰 회사들, 뭐 다른 여타 게임도 마찬가지겠지만 두세 개의 프로젝트는 다들 동시개발할 수 있어요. 근데 이제 테스트 인력은 정해져있고, 하필 잘못 맞춰서 출시일이 겹친다거나 업데이트가 겹치면 난감하죠. 그러면 이제 어느 쪽부터 먼저 해줘야 되느냐, 이런 얘기가 나오게 되구요. 그 다음에, 라이브로 들어간 게임들은 이미 기존에 잘 동작하던 게임인데 새로 업데이트 들어간 거 때문에 문제가 생길 수 있습니다. 그러면 이거를 다 테스트를 해야 되는데, 라이브 들어갔다고 QA인력은 조금밖에 안 들었고, 그러면 이제 방법이 없죠. 새로 들어간 것만 테스트하고 나머지는 잘 되기를 그냥 기도할 뿐이죠. 그럼 이제 이 상황이 제가 알아보니, 대부분의 다른 회사들도 똑같은 상황이고, 이거 어떻게 안 될까. 다들 ‘어떻게 안 될까’ 하지, 답을 갖고 있는 데는 별로 없는 거 같더라고요.

잘나가는 N사. 뭐, 추측하지 마세요. 그냥 N사는 굉장히 많습니다. (웃음) 뭐 이런데서.. 몽키러너를 이용한 어떤 UI기반 테스트를 시도를 했대요. 알아보니까, 근데 결국, UI가 자꾸 바뀌는 거죠. 만들다가 쪼금 바꾸는 건 일도 아니니까. 그러다 보니까 결국은 그냥 포기를 하게 되고, ‘아, 안되겠다.’ 그러고, 좀 그나마 시도를 해본 게, 정상적으로 동작하는 스크린샷을 찍어놨다가 이런 거를 나중에 이제, 테스트하면서 찍어논 거를 비교를 하는 형태로 시도를 했지만 결국은 국내에서는 이렇다 할 자동화 사례는 존재하지 않고, 결국 막판에, 프로젝트 출시 막판에 엄청나게 많은 인력을 최대한 투입을 해서, 호환성을 집중적으로 테스트한 게 현재 국내의 환경이더라. 라는 거였습니다. 

그러면 이제, 잘나가는 B사. 추측하지 마십시오. 구글과 MS 출신으로 구성된 별도의 테스트 엔지니어 팀을 활용을 하고 있더라고요. 그래서, 정말? 너네들 정말 그래? 쉽지 않을 텐데? 그랬는데, 일단 다 자기네가 만든 게임을 다 하는 건 아니고, 한 게임만 그렇게 하고 있다고 하더라고요. 보통 구글에서는 SET라고 부르고요, MS에서는 SDET라고 부릅니다. 어, 좀 특이한 건 개발 초반부부터 이제, 어떻게든 자동화를, 자동 테스트 시스템을 만들겠다 라고 해서, 거기에 굉장히 집중을 했다고 하더라고요. 그래서 팀이 있고, 그 팀들이 적극적으로 테스트용 환경을 만들어서 빌드 시스템에서 빌드용 바이너리도 같이 생성을 하고, PC 상에서 해당 바이너리 가지고 자동 테스트를 쭈욱 진행을 해서, 빌드마다 테스트 결과를 뽑아낸다.라고 합니다. 이와 별도로 따로 QA인력이 따로 있고요. 
그 다음에, 이제 국가별로 테스트도 해야 되니까 현지 외주 QA회사도 존재하고. 확실히 잘 나가는 회사는 한국과는 좀 많이 다른 것 같았어요. 근데 한국에서는 이런 부분을 자동화하겠다 그러면 어떤 식이냐면, 일단 사람이 하는 게 기본이다.라고 생각을 해요. QA하시는 분들 얘기 들어보면 거의 “이런 걸 어떻게 컴퓨터가 알아서 합니까, 다 사람이 해야지” 라고 하는게 일단 기본적으로 깔려 있구요, 특히 게임 같은 경우에는 이제 웹 화면 테스트라든지, 아니면 네이티브 컨트롤 이용한 테스트랑 달리 툴이 거의 없습니다. 특히 게임 같은 경우에는 거의 그냥 랜덤하게 테스트를 하는, 랜덤터치를 해가지고 한다든지, 아니면 화면 레코딩을 해서 반복적으로, 여러분들 이제 PC 같은 데서나, 블루스텍이나, 녹스 같은 걸 가지고, 하는 경우에 매크로툴을 쓸 수도 있는데요, 뭐 그런 정도의 게임 플레이는 할 수 있지만 그거 자체를 가지고 적극적으로 게임 테스팅을 하는 건 거의 어렵다고 보고 있습니다. 그리고 무엇보다도 앞에서 나왔던 것처럼 UI가 굉장히 바뀌게 되면 버튼 위치가 왼쪽에 있다 오른쪽으로 간다거나, 네모낳게 만들었다가 동그랗게 만들면 동작을 하지 않죠. 몇 번 시도는 해보겠지만 결국 그런 상황이 반복되기 시작하면 다들 그냥 포기하게 됩니다. 그리고 이제, 안드로이드만 출시하면 참 좋은데 ios도 해야 돼요. 뭐 아시겠지만 요즘 유니티나 이런 엔진들이 많은 부분을 커버해준다고는 하지만 플랫폼이 달라지기 때문에 실제로 결제 시스템이라든지 뭐, 페이스북 로그인이라든지 이런 별도의 여러 가지 시스템들이 달라붙으면서 실제로는 다른 스크립트 작법을 해야 되는 상황이 됩니다. 그리고 무엇보다도 이제 화면 비율하고 해상도가 달라지니까 레코딩 같은 걸 해가지고 좌표 기반으로 스크립트를 작성을 하더라도 거의 무용지물이죠 뭐, 비율이라도 잘 맞으면 좋은데 우리가 생각하는 비율, 아까 보셨죠 그림에서? 우리가 생각하는 비율처럼 그렇게 일정한 비율이 존재하지 않아요. 그러니까 살짝살짝 어긋나게 되죠. 
그래서 결국 사람들은 ‘아 자동화하느니 그냥 사람이 하자’, ‘사람이 다 못하니 그냥 호환성 테스트만 하자’라는 게 거의 현재 상황이에요. 수동 테스트하고 자동 테스트를 비교를 해보면 다들 알아요, 자동으로 하는 게 가장 좋다. 근데 수동으로 할 수밖에 없는 상황. 거의 이런 상황인 거죠. 무엇보다 자동으로 하게 되면 가장 좋은 게 앞서 말씀 드린 것처럼, 회기 테스트라고 말하는 부분 있죠? 내가 실제로 과거에 동작하던 기능들이 지금도 동작할 것인가. 과거에 문제가 있던 부분이 다시 버그가 나타나진 않을 것인가. 이런 부분들을 문제가 생길 때마다 하나씩 하나씩 테스트 스크립팅을 만들어 놓으면 이것만 나중에 돌리면 되는데, 이걸 매번 사람이 확인해야 하는 상황이라고 생각하면 끔찍해지죠. 

조금 전에 말씀 드린 것처럼 그런 테스트 관련된 이슈 말고도, 실제로 작은 회사들, 인디라든지, 규모가 작은 회사들은 테스트할 디바이스들을 확보하는 것도 문제가 됩니다. 뭐 한국에서만 확보하면 상관이 없는데, 일본에 출시해야 된다거나, 어, 중국에 나가야 된다거나. 북미에 나가야 된다 그러면 출장가서 수백 개씩 사올 순 없잖아요. 보통 이제 이런 경우에는 대행업체들이 존재합니다. 중국 같은 경우에는 300개쯤 이상의 자체적으로 기기를 가지고 있는 경우도 있구요. 북미, 유럽 같은 경우엔 150개 이상의 기기들이 있어야 된다고 합니다. 근데 이제 이렇게 기기들을 빌려서 테스트하고, 그 다음 테스트해주세요 하고 외주를 맡기면 비용이 만만치 않죠. 뭐 중국 테스트 업체들이 아무리 싸다고 하더라도 결국 한 번밖에 테스트 못하는데. 출시하기 전에 한 번 테스트해 갖고는 안 되지 않습니까. 그래서 여러 번 하게 되면 만만치 않은 상황이 되구요. 그래서 테스트 외주를 하는 거 보다 이런 테스트 대행업체들 중에서 자기네들이 가지고 있는 테스트 디바이스들을 빌려주는 회사들이 나오기 시작을 했습니다. 그래서 자체 기기에 해당 디바이스에다 기기를 내가 직접 설치할 수도 있고, 아니면 테스트 스크립트를 미리 만들어서 그 디바이스들한테 뭐, 예를 들면 50개를 제가 빌려서 이 바이너리를 다운로드 한 다음에 스크립트를 돌려주세요, 그리고 그 결과를 리포팅해주세요. 하는 형태로 운영을 하는 곳들이 있습니다. 이런 게 이제 실제로 니즈가 계속 생기다 보니까 구글이나 아마존 같은 데서도 이런 일들을 하게 됐어요. 보통 이걸 모바일 디바이스 테스트 랩이라고 부르긴 하는데요, 기본적으로는 클라우드 환경에, 클라우드 서비스라고 보통 얘기를 하는데 자신들의 디바이스들이, 리스트들이 있고 그 리스트를 선택을 해서 몇 개 렌탈을 하는 형태로 테스트를 하게 됩니다. 그래서, 뭐 내가 없는 기계들을 테스트하기 위해서 뭐, 하나나 두 개만 빌려서 리모트 터미널로 열어서 다운로드 시켜서 테스트를 해 볼 수도 있고요. 아니면 아까 말씀 드린 것처럼 몇십개를 일괄적으로 빌려서 한꺼번에 테스트할 수도 있습니다. 그런 테스트들이 끝나고 나면 그 업체들이 제공하는 성능 모니터링 툴을 통해서 그래프도 예쁘게 그려주고, 여기서 메모리 사용량 같은 것도 나오게 됩니다. 이런 경우에는 이제 문제가 되는 건 해당 디바이스들이, 다른 사람들도 쓸 수가 있지 않습니까? 그러면 내가 테스트하고 난 다음에 과연 이 바이너리가 혹시 다른 사람이 쓰게 될까봐 걱정이 될 수도 있죠. 약간 그런 어떤, 내가 테스트한 환경이 다른 사람들에게 사용될 때 충분히 잘 지워질 것인지. 이런 고민들도 하게 됩니다. 굉장히 불안해지면, 이제 클라우드 환경에서 테스트가 굉장히 힘들어지게 되죠. 이런 서비스 제공사들을 보면 이제, 좀만 검색해보면 나오구요. 뭐, 퍼펙토모바일이나 테스트오브젝트, 테스트드로이드라고 서비스를 제공하는 비트바, 그 다음에 최근에 MS에 인수된 자마린이 이런 일들을 했었구요, 아마존에서는 아마존 디바이스 팜이나, 구글에서는 구글 클라우드 테스트랩이라는 이름으로 베타서비스를 제공을 하고 있습니다. 아마존이 좀더 적극적으로 제공을 하고 있고요. 다만 이런 경우에도 마찬가지로, 테스트 환경이라는 게 게임에 적합하기보다는 그냥 네이티브 앱들, 또는 조그만 서비스들을 위한 앱에 더 특화되어있고, 대개 구글이나 아마존 만나봐도, 게임에 대해서는 그닥 적극적이지 않아요. 왜냐면, 시장이 없다가 아니라 방법이 뚜렷한 게 없기 때문에, 본인들이 할 수 있는 건 “랜덤 테스트 30분 돌리세요.”, 뭐 이런 정도인 거죠. 그래서, 이런 부분들을 해결해야 되겠다라고 생각을 하게 됐습니다. 근데 그걸 해결하려면 어쨌든 기본적으로 사람 대신에 대신 무엇인가를 해줘야 될 프레임워크가 필요하게 되었는데요, PC에서는 오랫동안 개발이 되어왔기 때문에 여러 가지 툴들이 존재합니다. 매크로라던지, 여러 스크립트 기반의 툴들이 다양하게 존재하지만 모바일 환경에서는 PC만큼 자유롭지도 않고요. 플랫폼도 여러 개로 나눠져 있다 보니까 각 플랫폼 별로 존재하는 경우도 많았습니다. 근데 이제 개발하는 입장에서 보면 각 ios 따로, 안드로이드 따로 이렇게 가져갈 순 없으니까, 이왕이면 다 하나의 스크립트만 작성해서 다 썼음 좋겠다, 뭐 100% 똑같진 않더라도 기본적으로 프레임웍이 같아서 약간의 변화만 가져가서도 테스트했으면 좋겠다, 라는 생각을 하게 됐구요. 그래서 대표적인 모바일 테스트 프레임워크를 좀 찾아봤습니다. 그랬더니 뭐 appium이라던지, robotium, Calabash, UI오토메이터, 에스프레소 뭐 이런 형태의 프레임웍들이 이제 검색에서 나왔어요. 하나하나 다 들여다봤구요. 그래서 저희가 프레임워크 비교들을 쭉 해봤는데, 안드로이드도 되고, ios도 되고. 그 다음에 사용 언어도 뭐, 자바라든지 다양한 언어들을 사용할 수도 있고, 오픈소스에 대해서도 저희가 설명하기 쉽고, 뭐 여러 가지로 점수표를 쭉 비교를 했더니 Appium이 가장 좋더라고요. 막상 또 선정하고, 다른 업체들을 찾아봤더니 구글이나 아마존도 다 Appium 프레임웍을 다 지원하고 있었습니다. 그래서, 아 우리가 선택을 한 것은 맞구나. 이것을 가지고 게임에 특화시켜 보자. 라고, 진행을 하게 된 거죠. 

Appium의 특징을 보면, 기본적으로는 테스트하려고 하는 앱을 고치지 않고, 블랙박스 형태로 바깥에서 컨트롤할 수 있도록 한 것이 목표였습니다. 그리고 웹 브라우저에서 제공하는 셀레니움 API, 테스트 API를 모바일로 확장한 부분도 있습니다. 그래서 이 API를 지원하는 라이브러리면 무엇이든지 다 스크립트로 사용할 수 있습니다. 그래서, 뭐 자바 클라이언트도 존재하구요. 자바 스크립트도 쓸 수 있고, 파이썬도 있고 루비도 있고, 다 있습니다. 그래서 해당되는 클라이언트들이 쭉 있고요, 본인들이 테스트하기 쉬운 그런 언어를 선택을 해서 작성하시면 됩니다. 기본적으로 테스트 스크립트는 이 Appium 서버랑 서로 통신하기 위한 라이브러리를 제공하고 있고요. 이 라이브러리랑 연결을 해서, 테스트를 하시면 되고. 기본적으로 Appium은 네이티브 앱이나, 하이브리드 앱, 웹 앱 등 모든 방식의 모바일 앱 테스트가 가능하다고 합니다. 게임 쪽은 언급이 별로 없죠. 대신에 안드로이드나 ios, 심지어는 PC플랫폼의 웹 브라우저도 다 테스트가 가능하기 때문에 어떻게 보면 굉장히 범용적이다라고 볼 수도 있습니다. 물론 화면 해상도도 다르고 실제 브라우저가 바뀌면 보여지는 컴포넌트라든지 이런 것도 달라질 수도 있기 때문에 하나의 스크립트로 세분돼서 다 쓸 수 있습니다 라고 말할 순 없어요. 그렇지만 어쨌든 기본적인 프레임웍이 같다라고 하는 것만으로도 굉장히 큰 장점이 있습니다. 

안드로이드 앱의 테스트하는 과정을 잠깐 말씀을 드리면, 기본적인 어떤 테스트 시나리오를 기반으로 스크립트를 작성을 하게 되구요. 여기서는 자바로 작성한다고 가정을 하겠습니다. 그리고 디바이스를 연결해서 Appium 서버를 실행합니다. 노드js로 구현되어 있습니다. 그래서 노드를 설치하고, Appium서버를 끼우면, 되구요. 기본적으로는요. 테스트러너를 통해서 자바로 만든 코드를 실행하게 됩니다. 그러면 테스트러너가 자바 스크립트, 자바로 만들어진 코드를 실행을 하면서 앞에서 말씀 드린 것처럼 셀레니움, 웹드라이버와 프로토콜을 이용해서 Appium서버로 연결을 하게 되고요. Appium서버는 안드로이드 디버그 브릿지라고 부르는 ADB를 이용해서 자기가 원하는 간단한 앱을, 부트스트랩이라고 부르는 앱을 실제 디바이스에 다운로드를 합니다. 그럼 이 앱이 Appium서버랑 TCP를 주고 받으면서 실제 디바이스 상에 있는 UI오토메이터라고 하는 테스트 환경을 컨트롤하게 됩니다. 여기까지는 실제 테스트를 하시는 분들은 굳이 아실 필요는 없지만, 기본적인 어떤 메커니즘에 대해서 간단히 설명을 드린 거고요, 결과적으로는 내 스크립트에서 실행시키는 명령이 실제 디바이스까지 앞서 말씀 드린 과정을 통해서 전달된다고 보시면 되겠습니다. 이렇게 하나하나 테스트를 진행을 하면서 어떤 컴포넌트가 나오면 얘를 클릭해라, 뭐 요런 화면이 나오면 텍스트 입력을 해라 이런 형태로 스크립트를 작성을 하신 다음에 나중에, 원하는 것들이 안 나올 수가 있습니다. 그러면 테스트 러너가 에러를 겪게 되고, 이 테스트는 실패했다라고 판단을 하게 되는 거죠. 그림을 간단하게 그리면 왼쪽에 테스트 러너가 존재를 하구요, 그 다음에 Appium 클라이언트 API를 통해서 테스트 스크립트가 동작을 하게 됩니다. Appium서버는 이제, ios나 안드로이드 버전도 이제, 2.3, 4,2까지 각기 다른 구현 방식을 가지고 있습니다. 4.2가 API 17인데요, 4.2부터 UI 오토메이터가 들어가 있기 때문에 테스트 방식이 다른 상황이구요, 요 부분에 대해서 실제 구현하신 분들은, 테스트 스크립트를 작성하신 분들은 큰 문제가 없습니다만 실제 구현 방식이 어떤 식으로 달라지는지에 대해서는 이해를 하셔야 하기 때문에 도식화했습니다. 이이제, Appium에 대해서는 이렇게 간단하게 설명을 드리고요, 저희 팀에서 시도를 한 건 게임 테스트를 어떻게 좀 더 잘 해볼 것인가 라고 하는 고민들을 해 봤습니다. 가장 큰 문제는 좌표로만 테스트를 해야 되는 테스트 방식을 개선을 해 보자. 라고 하고, 게임의 오브젝트들을 저희가 찾을 수 있는 모듈을 간단하게 만들었습니다. 일단 유니티3D 플러그인을 만들었고요, Appium서버랑 통신을 해서 싱글에프에서 UI컴포넌트들을 저희가 지정을 하게 되면 이 싱글에프의 상대적인 위치들을 저희가 문자열을 만듭니다. 그래서 이 문자열을 가지고 오브젝트에 특정을 하게 되는 거죠. 좌표가 아니라, 저희가 어떤 오브젝트 메뉴를 만들었다고 보면 되는 거예요. 그래서 실제 테스트 스크립트에서는 뭐, 게임 오브젝트 네임이나 또는 태그 같은 것들을 이용을 해서 서로 조합을 해서 오브젝트를 지칭할 수 있게 하고요. 테스트 스크립트에서는 좌표를 지정하고 있지 않기 때문에 여러 가지 얻는 이득이 있습니다. 일단 화면이 배치가 바뀌어도, 오브젝트 이름 자체가 바뀌는 경우는 굉장히 드뭅니다. 그래서 그런 오브젝트들을 지칭할 수 있게 됐고요, 그리고 이 부분은 저희가 모듈 내에 인스펙터 툴도 같이 제공을 하고 있기 때문에 그러한 실제 테스트를 게임 플레이를 하면서 내가 이 버튼의 이름이 알고 싶어, 요 아래에 아이콘의 이름이 알고 싶어, 그러면 저희가 인스펙터를 통해서 클릭을 하면, 그 버튼의 이름들을 리턴을 하는 형태로 구현을 해놨습니다. 일단 ID 기반으로 하게 되면 뭐 특정 좌표라든지 화면 해상도라든지 이런 거에 영향을 받지 않게 되고요, 그 다음에 보통 스크립트를 작성하실 때 클릭하고 난 다음에 3초를 기다렸다가 그 다음에 다시 뭐가 나오면 또 다시 3초를 기다리고, 이런 식으로 막연하게 시간을 기다리게 하는 형태의 스크립트를 많이 짤 수밖에 없게 되는데요, 차라리 이런 특정 오브젝트가 나올 때까지 기다려라라는 형태로 스크립트를 작업할 수 있기 때문에 그냥 막연하게 기다리는 것이 아니라 그 오브젝트가 화면에 나오자마자 바로 클릭하고 그 다음 화면으로 넘어갈 수 있기 때문에 환경 자체가 빠르게 진행이 될 수 있습니다. 그래서 저희가 Appium서버를 고치고 게임의 오브젝트들을 집어넣는 걸 간단하게 도식화를 하였습니다. 그래서, 인게임의 오브젝트 쿼리를, 노드JS 코드를 고쳐서 저희가 만든 API가 호출이 되면, 게임 내에 이 오브젝트의 좌표나 또는 인포메이션을 물어보는 형태의 쿼리를 던지게 되고, 저희 모듈들은 그런 정보들을 던져줌으로써 Appium서버가 해당 오브젝트들이 어느 위치에 있는지, 어느 좌표에 있는지, 어떤 정보를 가지고 있는지를 알 수 있기 때문에 커다랗게 수정되지 않더라도 테스트가 무난히 진행될 수 있게 구현이 되었습니다. 그래서 Appium의 거의 기본적인 매커니즘을 그대로 다 쓰면서도, 게임을 지원할 수 있게 됐습니다. 

안드로이드용 게임 스크립트의 예제인데요, 잘 보이실진 모르겠는데 기본적으로는 페이스북 로그인 화면들을 인게임 내에서 버튼들을 눌러서 페이스북 계정을 로그인하는 과정을 간단히 보여드렸고요, 보시면 이제 빨간색으로 되어있는 게 저희가 추가한 API입니다. 그래서, 좌표가 아니라 네임들을 가지고 조합해낸 문자열들을 보실 수 있을 것 같고요, 일부분 파란색이나 이런 부분들은, 아 파란색이 아니군요. 저 아래쪽에 보면 원래 Appium이나 앱 드라이버에서 사용하는 XPath라고 하는 방식으로 지정하는 것들도 보실 수 있습니다. 이렇게 만든 이유는 실제로 웹뷰 같은 것들을 띄워서 웹 브라우저 내에 있는 것들을 컨트롤해야 될 수도 있습니다. 이런 부분들은 저희가 만든 방식으로 동작하지 않구요. 원래 제공되는 방식으로 지정을 해야 됩니다. 
간단하게 동작 시연을 보여드리겠습니다. 유니티로 만들어진 샘플 앱이구요, 여기서 보시면 빨간색 방바닥이 나오는데, 저거는 저희가 클릭한 걸 알 수 있도록 하기 위해서 의도적으로 집어넣은 모듈입니다. 이게 다 지금 인게임 내의 오브젝트들이구요. 여기서 이제 실제 페이스북 뜬 겁니다. Fail을 가정한 테스트 시나리오를 진행한 거구요. 다음 장면은 정상적으로 다시 ID와 패스워드를 넣는 로그인 화면입니다. Appium 서버가 하나씩 집어넣음으로써, 게임과 웹뷰를 서로 오고가면서 테스트되는 것을 보실 수 있습니다. 

남겨진 과제들이 좀 있습니다. 그래서 일단은 기본적으로는 클릭하고 간단한 스와이프 정도로만 추가가 되어있고요. 실제 게임마다 각기 다른 동작의 API들을 요구를 하게 됩니다. 실제 게임 플레이를 테스트하기 위해서는 더 추가되어야 될 부분들이 있어서, 게임들을 실제 적용해나가면서 추가적으로 더 확보할 예정이구요, 그 다음에, Appium 프로젝트 자체를 저희가 브랜치를 해서 저희가 수정한 거기 때문에 Appium프로젝트와 머지하는 게 제일 좋다고 생각합니다. 다만, 맨 처음 말씀 드린 것처럼 블랙박스 형태로 테스트하는 게 Appium 컨셉이기 때문에 그런 부분들과 맞지 않은 문제가 조금 있긴 합니다. 그리고 지금은 현재 언리얼만 지원하고 있는데, 아니 유니티 3D만 지원하고 있는데 하반기에는 언리얼 엔진이나 코코스2D 같은 부분들도 지원을 할 예정이고요. 무엇보다 이제, 이 테스트가 자동화되기 시작하면, 개발 도중에 CI랑 같이 연동하는 게 제일 좋습니다. 어쩌다 한 번씩 테스트 돌리는 것이 아니라, 코드를 넣고 자동 빌드가 되면 뭐, 데일리 빌드처럼 아침에 빌드가 나오면 자동 테스트 한 번 돌려서 필요한 테스트 스크립트가 잘 돌아갔는지를 확인을 하고 결과를 출근하면 받아볼 수 있는 환경이 가장 이상적이고요, 그래서 맨 마지막 단계, QA를 뭐 일주일에 한 번, 한 달에 한 번 하는 게 아니라, 매일매일 자동으로 돌리는 게 가장 이상적이구요. 이런 부분들을 하는 게 쉬운 일은 아닙니다만 이렇게 함으로써 전체적인 테스트들을 안정적으로 확보할 수 있다고 생각을 하게 됩니다. 

네, 양이 생각보다 많아서 시간이 많이 부족했습니다. 간단하게 Q&A들을 진행하기로 하겠습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
