2. 2
NCSOFT (2004 ~ 현재)
SET 팀 (Software engineering in test) 2015 ~
前 리니지 이터널 Technical director (2007 ~ 2013)
모바일 게임기 개발 프로젝트 (2004 ~ 2005)
모코코(2000)
임베디드 리눅스 기반 PDA 플랫폼, PalmOS 5.x 스마트폰 개
발(갤럭시)
한글과컴퓨터(1994)
윈도우 용 아래아한글 3.0 시리즈, 한글 96 등 개발
휴먼컴퓨터(1991), 한메소프트 (1992)
윈도우 프로그래밍 개발 시작, 한메 한글 for 윈도우
월간 마이크로소프트웨어와 ZDNet 에 여러 기술 관련 글과 ‘망치와모루’ 라
김종원
3.
4. 4
(현재상황) 보급선은 식량이 떨어진 후 15 일 후에 도착 예정
책임자 : 발사 일정을 13일 정도 더 줄일 방법 있나?
담당자 : 탑재는 3일 걸림, 점검과 시험과정에 10일 걸림
책임자 : 점검 과정 중 크리티컬 문제 발견 확률은?
담당자 : 대략 2.5% (허걱, 불안한데?)
책임자 : 성공 확률 0%보단 97.5% 가 나음. 점검 생략. 고고~
담당자 : ㅠㅠ (건너 뛸 생각이면서 왜 물은 거야?)
식량 보급을 위한 보급선 발사 일정 협의 중
9. 구글 페이스북
QA업무 개발 개발
테스트 관련 직무
SET - 테스트 인프라 및 테스트 기능 개발
TE - 테스트 엔지니어, 사용자이자 기술자
없음
테스트 조직 생산성혁신팀 (Engineering productivity) 없음
목표
근본 원인 파악 및 예방에 중점
테스팅이 기술 혁신과 개발에 방해되지 않도록 함
개발 효율 극대화 및 테스트 수행 대기 최소화
테스트 범위
개발자는 소형 테스트, 중형은 SET, 대형은 TE가 테
스트 주체
개발자가 모든 테스트 케이스 작성 및 유지 보수
코드 리뷰
리뷰 시스템에 코드 뿐만 아니라 테스트 결과도 포
함 시켜 리뷰 받음
구글과 동일
테스트 자동화 사람의 직관이 필요하지 않은 것은 모두 자동화
테스트 유형별로 자동화 수행. 항상 성공하는 테스트
케이스는 제거함
배포 단계 테스팅' 단계에서 사내 배포. 이후 '베타'로 오픈 릴리즈 일주일 전에 사내 배포. 업데이트는 하루 2번
구글과 페이스북의 테스팅
9
10. QC (Quality Control) 품질 제어
품질에 대해 미리 정의된 요구사항을 검증하는 프로세스
일련의 요구사항을 부합하는지 점검하는 것과 미리 정의된 요구사
항 충족 검증
QA (Quality Assuarance) 품질 보증
QC 업무를 할 수 있는 프로세스에 대해 지속적으로 개선과 유지보수를
제공하는 업무
QC 프로세스를 포함하는 메타 프로세스
테스트 엔지니어링(Software test engineering)
QC라는 실제 세계와 QA라는 메타 세계를 연결하는 다리 역할
테스트를 하는 것이 아니라 테스트 환경을 개발한다
QC와 QA를 연결하는 테스트 엔지니어링
10
11. 유저 측면
작은 이슈에 민감하여 이탈이 심하다
단 한 번의 앱 크래시만으로도 게임 삭제/유저 이탈
PC게임에 비해 브랜드 충성 고객 적음, 게임 브랜드 인식이 쉽게 나빠짐
기기 측면
기기 파편화가 심해, 최소한의 호환성 확보가 가장 중요
같은 기기 모델에도 여러 OS 버전 분포 (OS 업데이트 잘 안 함)
국가별 기기 확보/ 환경 설정의 어려움
모바일 게임의 런칭 이슈 1/2
11
14. 네트워크 사용성 측면
불안정한 무선 네트워크 환경(지연 및 음영 지역, 비정상 연결)
사용자 이동에 따른 네트워크 단절 및 전송 지연(예: 엘리베이터 이동)
게임 사용 중 전화, 문자, 푸시 알림으로 인한 플레이 인터럽트
프로젝트 관리 측면
다수 게임 동시 개발, 출시 일정이 겹치는 경우
출시 프로젝트에 비례하여 테스트 인력을 증가시킬 수 없음
출시 후 라이브 단계는 최소의 인력으로 동일한 QA 품질 확보
예) 회귀(리그레션) 테스트는 어떻게?
모바일 게임 이슈 2/2
* 회귀 테스트: 수정된 부분이 기존 기능에 영향을 주었거나 과거 발생했던 문제가 다시 발생하는 지 확인하는 테스트
14
15. 15
모바일 게임 자동화 사례 (해외)
B사
구글과 MS 출신으로 구성된 별도의 테스트 엔지니어 팀 활용
SET 또는 SDET 이라고 부르는 직군
개발 초반부에 자동 테스트 시스템 구축에 집중
빌드 시스템에서 테스트 용 빌드를 생성, PC 상에서 자동 테
스트 진행
QA 는 자체 인력 30여 명 외에 현지 외주 QA 회사 활용
16. 16
테스트 자동화의 수난
부정적 인식
• 게임 테스트는 사람이 직접 하는 것이라는 인식
• 게임은 웹 브라우저나 네이티브 앱과 달리 자동 테스트 툴 없음
테스트 프레임워크가 게임 내 UI 구성 요소를 인식하지 못함
랜덤으로 터치하는 방식이나 화면 좌표 기록으로 테스트 스크립트 작성
• 개발 중의 잦은 UI 변경으로 좌표기반 스크립트 무용지물
• OS와 플랫폼에 맞춰 각기 다른 테스트 스크립트 작성 비용 증가
• 화면 비율과 해상도가 달라 좌표 기반의 스크립트를 제한 적용
• 직접 사람이 테스트하는 것이 더 유용하다는 인식
17. 수동 테스트 vs 자동 테스트
좁은 범위 테스트, 많은 비용과 시간 넓은 범위 테스트 범위, 빠른 테스트 및 적은 비용
17
18. 18
테스트 할 모바일 디바이스도 필요한데
꼭 필요한 기기 호환성 테스트
• 국내는 점유율 상위 50개의 기기가 90% 정도 차지
• 중국 테스트 업체의 경우 300개 이상의 기기에서 호환성 테스트 진행
• 북미, 유럽의 경우 150개 이상의 기기 테스트 필요
• 해당 기기 확보 뿐만 아니라 테스트 인력 비용도 만만치 않음
클라우드 테스팅 환경 제공 업체
• 테스트 대행 업체들 중 자체 테스트 랩을 대여하여 테스트 환경 제공
• 자체 기기에 앱 설치 및 기본적인 테스트 스크립트를 동작
• 소규모 뿐만 아니라 대형 업체들도 가세
19. 19
모바일 디바이스 테스트 랩
클라우드 서비스를 이용하여 테스트 장비 대여
• 리모트 터미널을 이용한 개별 테스트, 다수 디바이스에 대한 일괄 테스
트
• 성능 모니터링 및 테스트 결과 리포트가 제공
• 접근성(속도) 및 보안(테스트 앱 삭제 등)이 중요
• 개별 기기 대여보다는 스크립트 기반의 일괄 테스트가 유용
서비스 제공사
• Perfecto Mobile, TestObject, Bitbar (TestDroid),
Xamarin Test Cloud 등의 중소 업체들
• Amazon Device Farm, Google cloud test lab 등의 대형 업체
• 기존 테스트 결과 로그가 그대로 남아 있는 사례가 있어 보안에 좀 더
신경 써야 함
20. 20
테스트 자동화 프레임워크
사람 대신 일을 시킬 테스트 환경이 필요
• PC 환경에서는 오랫동안 여러 툴이 사용되어 왔음
• 매크로나 스크립트 기반의 툴이 지금도 다양하게 존재
• 모바일 환경은 PC만큼 자유롭지도 않고 플랫폼도 여러 개로 나뉘어 존
재하여 통합된 테스트 환경이 필수적임
대표적인 모바일 테스트 프레임워크
• Appium, Robotium, Calabash, UIAutomator, Espresso
• 확장성이나 스크립트 언어 등을 고려하여 선택해야 함
22. 22
모바일 자동 테스트 방법
• 몽키테스트 (랜덤 터치 + 시스템 이벤트)
• 화면 컴포넌트의 랜덤 터치 테스트
• 테스트 순서를 레코딩한 것을 재생
• 화면 이미지 검색을 통해 원하는 컴포넌트를 찾아 터
치
단점
테스트 중의 예외 상황 또는 일정 확률로 발생하는 이벤트에
대한 대비를 하기 위해 이벤트 검출 코드를 작성해야하는데
무척 어려움
23. • 테스트 하려는 앱에 특정 코드나 모듈을 삽입하여 컴파일하지
않고도 테스트 할 수 있도록 하는 것이 목표
• Selenium WebDriver API를 제공하는 언어는 무엇이든 스크립
트로 쓸 수 있다 (Java/Javascript/Python/Ruby/C#/…)
• 테스트 스크립트는 http방식으로 Appium 서버와 통신하고 서
버는 디바이스에서 동작하는 테스트 지원 라이브러리인
UIAutomator 같은 서비스와 TCP로 연결, 명령과 결과를 주고
받는다
• 네이티브, 하이브리드, 웹 앱 방식의 모바일 앱 테스트 가능
• Android/iOS 플랫폼 모두 지원
Appium
23
24. 안드로이드 앱의 테스트 과정
1. 테스트 시나리오 기반 스크립트 작성 (Java) 및 컴파일
2. 디바이스 연결 및 Appium 서버 실행
3. 테스트 러너(JUnit/TestNG)를 사용하여 테스트 스크립트 실행
4. Appium 는 adb를 이용하여 디바이스에 부트스트랩 앱을 다운로드
5. 부트스트랩 앱은 Appium서버와 연결 후 UIAutomator의 API로 서버
의 명령을 전달
6. 스크립트의 명령을 Appium 서버가 받아서 UIAutomator를 이용 앱의
동작을 제어하는 방식
7. 테스트 명령이 기대하는 결과가 나오지 않으면 테스트 러너에서 예외 발
생하고 중단
Appium
24
25. Windows / OS X
Android Device
Appium 프레임워크의 동작 방식
Test script
UI Automation
iOS Driver
UI automator
Instrumentati
on
iOS device
Appium server
(node.js)HTTP
JSON wire protocol
Command
Command
UI automator
(Android 4.2+)
Selendroid
(Android 2.3+)
Test runner
Appium
client API
25
26. 26
오브젝트 기반의 자동 테스트
• 클라이언트 내의 UI 오브젝트를 일정 규칙의 path로
명명하여 스크립트에서 컨트롤하는 방법
• 스크립트에서는 해당 오브젝트의 존재 유무나 상태를
보고 기다릴 것인지 이벤트를 발생할 것인지 판단함
• 예외 상황에 대한 처리도 다른 방법에 비해 쉬움
• UI의 텍스트를 추출해 원하는 수치와 비교를 하거나
클라이언트에 삽입한 모듈과 통신하여 테스트를 위한
명령이나 로그를 비교할 수 있음
27. 게임 테스트를 위한 프레임워크 확장
Appium
Server
UI Automation
Library
Test Script
(오브젝트 기반)
Game Object
Find Module
In-Game Object
Query
Test
App
return objects
information
Game
Object
Inspector
Module
확장 Appium 프레임워크 (게임 내 테스트 용 모듈 삽입)
기존 Appium 프레임워크
Appium
Server
UI
Automation
Library
Test Script
(좌표 기반)
Test
App
27
28. 28
모바일 게임 테스트를 위한 확장
(1/2)
게임 테스트 자동화를 위한 플러그인 모듈 개발
• 화면상의 좌표로만 테스트를 해야 하던 기존의 테스트 방식
을 개선
• 게임 내 UI 오브젝트의 정보를 제공하는 모듈 개발
(Unity3D 플러그인)
• 모바일 테스트 프레임워크인 Appium의 서버를 확장하여
게임 내 오브젝트를 찾는 인터페이스 추가
• 테스트 스크립트 작성을 위한 Appium 클라이언트 API 확
장
findElementByGameObjectName
findElementByGameObjectNameAndTag
…
29. 29
모바일 게임 테스트를 위한 확장
(2/2)
좌표 기반이 아닌 오브젝트 기반 테스트 스크립트 작성
• 화면 배치가 바뀌어도 동작이 되도록 좌표가 아닌 문자열을
사용
• 게임 엔진 내의 Scene 내부의 계층 구조와 이름 등을 이용
오브젝트 ID 생성 (자체 개발한 Unity3D Inspector 툴을
이용 타겟 UI 문자열 추출)
• 문자열 ID 기반으로 된 스크립트를 한 번 작성하면 화면 비
율이나 해상도가 바뀐 기기에서 재사용 가능
• 막연히 특정 시간 동안 기다리는 방식을 피할 수 있어 테스
트 속도 향상
특정 오브젝트가 나올 때까지 기다렸다가 해당 오브젝트를 터치할 수 있어
테스트 시간 및 정확도를 높임
33. 33
소규모 개발사의 테스트 자동화
테스트를 위한 여러 툴을 직접 개발할 수는 없는 상황
Appium의 이미지 비교 방식이 바로 사용해볼 수 있는 방법
클라이언트 프로그래머의 지원을 받을 수 있다면
• 테스트 용도로 PC에서 실행하는 테스트 코드와 게임 클라이언트
와 네트워크를 연결. 테스트 코드에서 게임에 접속해서 사전에
정의한 UI의 ID를 사용하여 클릭 또는 표시 대기 등의 동작을 수
행
• 테스터가 아닌 프로그래머가 테스트 코드를 직접 작성하는 것이
훨씬 빠름. 테스터는 해당 코드를 기반으로 살 붙이기
• UI의 ID를 동작과 연관되어 이해하기 쉽게 명명하고 리소스 에디
터 내에서 해당 오브젝트의 정보를 바탕으로 테스트 코드를 작성
하도록 함
34. 34
오브젝트 ID 명명 TIP
테스트 스크립트를 쉽게 하는 이름 붙이기
• 오브젝트의 ID를 중복 없이 컨텐츠 마다 이름 규칙을 부여
• 반복 사용하는 오브젝트는 ID를 짧게 부여하는 것이 좋음
• 연속된 동작에서 같은 ID를 사용한 UI 오브젝트를 사용하는 것은
피할 것. 예를 들면 재사용되는 팝업 윈도우의 경우 어느 화면에
서 열린 윈도우인지 파악이 어려움. 스크립트 작성 시 혼동을 피
할 수 있게 구분
• 화면 전환 시 전환 시점을 명확히 알 수 있는 시스템 로그나 메시
지를 제공하면 테스트가 훨씬 수월해짐
• 화면에 동시에 여러 객체를 같은 이름으로 생성하는 것은 절대
피할 것. 스크립트에서 구별할 수 없음
35. 35
테스트 명령어 (빌더 명령어)
빠른 테스트를 위한 테스트 명령어 제공
• 개발 및 테스트를 위해 클라이언트 및 서버에서 수행하는 명령
• 보통 숨겨진 콘솔창을 띄워서 입력
• 서비스 바이너리에서는 동작하지 않도록 기능이 제거됨
• 테스트 스크립트에서 테스트 명령을 사용할 수 있도록 하면 테스트가
훨씬 수월해짐
command(“ShowMeTheMoney 1000000”)
command(“SkipTutorial”)
36. 36
남겨진 과제
스크립트 작성 속도 향상
• 직관적인 테스트 스크립트 작성 환경 제공 필요
• 스크립트 중간부터 실행을 다시 할 수 있는 기능 개발
게임 UI를 위한 헬퍼 함수 개발
• 테스트에 도움을 줄 수 있는 게임 별 라이브러리 구축
Appium 프로젝트와 머지
• 확장한 코드를 Appium 프로젝트에 계속 머지 해야 하는 문제
• 기존의 기능은 변경하지 않고 최소한의 수정만을 함
다양한 게임 엔진 지원
• Unity3D 외에 UnrealEngine이나 Cocos2D와 같은 게임 엔진들을 지원하는
플러그 인의 개발 필요
• 엔진 버전 마다 기능이 다르고 NGUI 같은 상용 라이브러리 버전에도 영향을 받
음