[NDC]-프로그래밍 게임 테스트 자동화 5년의 기록, 〈리니지M〉 과 〈리니지2M〉 의 자동테스트 회고

날짜 2022년 12월 25일 일요일

날씨 맑음

제목 [NDC]게임 테스트 자동화 5년의 기록, 〈리니지M〉 과 〈리니지2M〉 의 자동테스트 회고 강의정리

게임 테스트 자동화의 인식

​

자동 테스트를 통해 얻고자 하는 것

사람을 대신하지 않고 사람이 하지 않아도 되는 일을 하고, 사람보다 정확하고 실수 없이

가장 기본적이면서도 반복적인 것을 자동화 하고자함

​

qa 업무를 대신하는 테스트 로보트를 만드는 게 아니다

​

최신 게임은 서비스 오픈 이후 빠른ㄹ 업데이트와 실수 없는 서비스를 제공하는 것이 중요하다

​

게임 개발 이후의 테스트 작업에 대한 기술적인 개선을 이루고자 함

​

빠르고 실수 없이 정확하게 테스트를 수행하기 위함

​

----------------------------------------------------

게임 테스트 자동화 여정

목표

- 모바일 기기의 자동테스트 서비스를 구축하여 qa에게 일원화 된 테스트 환경 제공

- 프로젝트에서 자동테스트에 적합한 영역을 개발, 테스트 커버리지 확장과

퀄리티 향상에 기여

​

자동 테스트 서비스

- 예약/반복/빌드 배포시 자동 실행

- 실행할 테스트 스크립트 및 데이터 관리/편집

- 테스트 기기 할당

- 순차적/분산 테스트 설정

- 각종 테스트 로그(스크립트, 테스트시스템,기기 로그 등)-테스트 실패 요인 탐색 쉬움

- 체크 항목 스크린샷/ 테스트 과정 녹화 동영상 - 테스트 과정 전체 확인

​

하나의 테스트 환경

- 모든 테스트 스크립트를 한 곳에서 정리

- 각기 다른 플랫폼/통일된 테스트 환경

- 안드로이드/ios/앱플레이어 퍼플 플랫폼을 한곳에서 볼수 있다

- 하나의 테스트 스크립트로 모든 플랫폼에서 확인가능

- 각기 다른 게임 엔진/ 하나의 개발도구 -학습의 난이도 저하

- 다른 목적의 테스트/ 같은 형식의 리포트 - 테스트 목적이 다르더라도 익숙한 포맷 제공

​

테스트 커버리지 확장

- 매 빌드 배포마다 자동 검증 - BAT, 영역별 기본 기능 자동 수행

- 정기점검 시 , 테스트 서버 수 증가 2-> 30 개로 서버 테스트 수 증가

- 재화 사용 영역 리그레션 테스트 - 기획 변경시 총 321개 항목, 5개 기기에서 1시간 수행

- 단순/반복테스트, 대량 설정 자동화 - BM 아이템 제작/ 모든 변신 카드효과 확인/ 상자확률, 몬스터 아이템 드랍 확률

​

자동테스트 영역 확대

- 리그레션 테스트 자동화 - 기존 기능이 잘 동작하는 지 확인 하는 테스트

- 국내 뿐 아니라 해외(대만/일본) 자동 테스트 확장

- 다른 테스트가 없는 주말에 집중적인 장시간 테스트

- 단순/ 반복테스트중 휴먼 에러 제거

- 새벽 시간 예약테스트로 기능 변경 여부 확인

- 앱스토어 심사를 위한 심사 서버의 자동점검

​

테스트 자동화를 적용하면서 생긴 어려움

- 게임의 UI의 지속적인 변경- 개발 중인 개임 뿐 아니라 라이브 서비스 중인 게임도 변경 필요

​

- 여러 게임 엔진과 새로운 버전 업데이트 대응 - 개능 변경 시 다른 게임 모두에

대해서도 테스트 필요

​

- 테스트 스크립트 수가 늘 수록 수정 해야 할 것도 증가 물리적인 문제도 발생

테스트 기기 수가 증가 하면서 모바일 기기 이상, 케이블, 충전 전원, USB 허브 ,

무선랜 대역폭 부족등 온갖 생길 수 잇는 모든 영역의 문제 경험

​

- 자동 테스트용 빌드를 직접 빌드 - 개발팀의 빌드가 나오면 자동테스트 빌드를

별도로 만드는 것을 반복

​

해결방안

- 플러그인에 대양한 오브젝트 검색 방법을 추가하여 UI변화에 대비, C++/STL 사용으로

엔진 독립적으로 구현 의존성 줄임

라이브러리가 아닌 소스 형태로 플러그인 배포하여 버전 의존성을 줄였다

​

- 스크립트에서 게임 UI 의존적인 부분을 공통 라이브러리로 분리 - 변경시 바꾸어야

할 부분 최소화

테스트 시나리오 부분과 게임 UI검색 부분을 최대한 나눔

​

- 물리적 문제들은 하나하나 틀어막았다

모니터링 시스템 도입, 원격 재부팅, 검증된 허브, 무선랜 AP추가 등

​

- 개발팀에서 자동 테스트 빌드를 제공 또는 사내 빌드에 디폴트로 포함

모 스토어 등록 빌드에는 포함 되지 않도록 주의

​

​

게임 qa가 신뢰 할 수 있는 자동 테스트

- qa가 자동 테스트의 결과를 신뢰 할 수 있는가 문제, 자동테스트

시나리오를 이해/ 오류 재현 가능

게임qa가 테스트를 설계/시나리오를 작성하도록 함

​

- 자동테스트 자체의 성공률이 높아야 함

기존 이미지 비고 방법으로는 정확도가 60~70% 정도 , 해상도가 바뀌면 정확도는 더 떨어짐

​

- 자동테스트에서 사용하는 기술의 정확도가 99.9%는 되어야함

99% 정확도가 높은 수준이 아니다

책 한페이지 7~800자 , 99% 정확도의 OCR이라면 한페이지 7~8자 오 인식 발생

​

현재 수행 중인 자동 테스트 종류

- 빌드 인수 테스트 (BLT)

- 게임 영역 별 기본 기능 자동 테스트

- 모바일 기기 호환성 테스트

- 라이브 서버 자동점검, 임시점검

- 반복 업무 자동 테스트

- 재화 관련 테스트/ 변신 카드 공격&이동속도 전수 테스트

​

빌드 인수 테스트 (BLT)

- qa에 배포된 빌드가 테스트 가능한 수준인지 확인 하는 테스트

- 배포 사이트에 빌드가 올라오면 자동실행

- qa가 매뉴얼 테스팅 하기 전에 빠르게 수행

- 서버도 업데이트가 되는 경우 준비 될 때 까지 대기하였다가 자동 테스트 시작

​

자동테스트 시스템 구현 원리

- 게임 내의 UI를 컨트롤 하는 스크립트를 작성하여 수행

- web 테스팅에서 사용하는 식별자 생성 방식인 xpath와 비슷하게 UI 오브젝트 식별자를 생성 하는 플러그인을 클라이언트에 삽입

​

- 모바일 자동 테스트 시스템인 Appium을 확장하고 파이썬 스크립트로 테스트 시나리오에 맞춰

모바일 웹과 게임 UI를 식별 및 컨트롤

​

게임 개발팀과 자동 테스트를 위한 협업

​

- 자동 테스트 환경을 게임 개발 과정에도 사용할 수 있다

- 같은 UI라도 기능이 다르면 UI에 다른 이름을 붙여라

게임 UI의 이름을 기능마다 다르게 붙어라

화면 위의 버튼의 이름 전부가 button 이란 이름은 아닐 것이다

- 대규모 UI 변경이든 작은 변경이든 미리 고지할 것

UI가 변경되면 자동 테스트 스크립트를 모두 체크해야 하기 때문

- 자동 테스트를 위한 별도의 테스트 명령어를 제공하면 좋다

- 테스트 명령어 결과를 로컬 파일로 남길 수 있으면 테스트가 빨라진다

----------------------------------------------------------------------------------------

게임 테스트 자동화로 얻은 교훈과 비전

​

BOT AI와 자동테스트는 다르다

​

BOT AI - 특정 목적(자동사냥, 아이템 채집, 경매소 탐색)을 위해 최적 행동을 함

보상(reward)를 극대화 하는 것이 목표

​

자동테스트 - 테스트 항목 확인 위한 테스트 시나리오로 일련으 동작을 수행

최대한 많은 테스트 항목을 확인 하는 것이 목표

성공 뿐 아니라 의도적인 실패도 목표

테스트를 위해 BOT AI도 사용할 수 있는 더 포괄적인 개념

​

자동 테스트를 통해 얻은 것

- 기능 업데이트는 사람이 하고 반복/리그레션은 자동 테스트로 하자

- 스크립트의 지속적 관리 필요, 테스트가 정확할 수록 작은 변화에도 취약

- 테스트 수행 시간제약이 사라짐

- 간단한 검증도 수 백 가지 항목을 반복하면 중요한 검증이 된다 (양질전환)

- 단순/반복적 테스트는 자동 테스트로 전환하여 휴먼에러를 없애기도 좋다

​

자동테스트를 위한 숨겨진 비용

- 스크립트 개발보다 자동 테스트 시스템 개발에 더 많은 프로그래머가 필요

- 자동테스트 시스템을 안정적으로 운영하고 개선하는 것도 큰 개발 비용

- 한가지 방법만으로 모든 테스트 불가, 요구사항은 계속 등장한다

- 새 게임 빌드가 나올 때 마다 스크립트를 검증/유지보수 발생

- os 업데이트나 새 모바일 기기가 나올 때도 검증/유지 보수 발생

​

자동 테스트를 어렵게 하는 것

- UI 변화에 취약

- UI변경이 되어도 스크립트가 변경 내역을 추적 할 수 있는 방법 강구

- 오브젝트만을 식별 하기에 시각적/청각적 문제를 식별 할 수 없음

- 프로그래머가 아닌 게임qa가 스크립트를 쉽게 만들수 있는 방법 강구

- 사람이 하는 메뉴얼 테스트 보다 테스트 커버리지가 더 좁다

- 테스트 실패시 결과만으로는 원인 파악이 쉽지 않다

​

테스트 실패시 결과 분석을 자동화 화여 시나리오 이해가 없어도 쉽게 파악하는 방법 강구

​

​

​

​

​