페이퍼요약 - 안드로이드 애플리케이션의 모델 기반 GUI 테스팅 사례 by Takala

제목: 안드로이드 애플리케이션의 모델 기반 GUI 테스팅 사례(Experiences of System-Level Model-Based GUI Testing of an Android Application)

저자: Tommi Takala 외 2인, 핀란드

문서유형: 학계 컨퍼런스 페이퍼(총 10 페이지), 2011년

 

 

안드로이드 애플리케이션인 BBC News Widget에 모델 기반 GUI 테스팅 자동화 방법인 TEMA를 적용한 경험을 기술한 자료

---

 

모델 기반 테스팅(Model-based testing: MBT)

• 테스트 대상 시스템(SUT)을 정형적인 모델로 기술하고 이 모델에 특정 알고리즘을 적용하여 자동으로 테스트 케이스를 도출해 내는 테스팅 방법. 예) 상태 머신(state machines)으로 모델을 기술하고 그래프 알고리즘을 적용하여 테스트 케이스를 생성
• 테스트 유지보수에 드는 노력이 줄며(테스트 스크립트를 일일이 유지보수 하는 대신에 모델을 유지보수) 자동 도구를 사용하여 많은 수의 테스트 케이스를 생성할 수 있는 장점이 있다.
• 여러 장점에도 불구하고 모델링 노력에 드는 전문성 결핍, 모델링 기초가 되는 명세서 부재, 쉽게 사용 가능한 도구 미비 등의 이유로 실제 조직에서 적용은 크게 활발하지 않다. 

 

GUI 테스트 자동화(GUI Test Automation)

• GUI 테스트 자동화는 위젯을 통한 사람과 GUI의 상호작용을 흉내 낸다. 즉, GUI 이벤트의 입력과 그에 따른 GUI 상태 검증을 자동화한다.
• 키 누름, 스크린 좌표 찍기 같은 사용자 입력 정보의 자동화는 비교적 쉽게 달성 가능하지만 복잡한 그래픽 표현으로부터 나온 정보의 해석은 때때로 문제가 될 수 있다.
• GUI 검증은 비트맵 비교(bitmap comparison)와 API(Application Programming Interface) 사용의 두 가지 방법으로 나뉘며, GUI로부터 나온 텍스트 정보를 해석하는 경우는 세 번째 방법인 광학 문자 인지(optical character recognition: OCR)를 사용할 수 있다.
  - 비트맵 비교 방법은 구현이 쉽지만 GUI에 작은 변경이라도 생기면 비교에 사용되는 모든 비트맵을 다시 얻어야 하므로 유지보수에 많은 노력이 든다.
  - API를 통해 GUI를 검증하는 방법은 유지보수 측면에서는 유리하지만 API가 항상 가용하지는 않을 수도 있으며 또한 API로부터 얻은 정보와 GUI를 통해 보여지는 정보가 약간 다를 수도 있는 문제가 있다.
  - OCR 방법은 직접적인 비트맵 비교 방법보다는 유지보수 측면에서 더 좋지만 정확성이 떨어지거나 실행이 느린 단점이 있다.

 

키워드 기반 GUI 테스트 자동화

GUI 테스트 자동화에서 효과적인 테스트 설계 방법으로 키워드 기반(keyword-driven) 방법이 있다.

• 키워드를 사용하여 하위 레벨 UI 오퍼레이션을 추상화하는 방법
• 키워드는 대개 기본적인 사용자 이벤트(예, 키 누름, 스크린상의 오브젝트를 찍거나 끌고 가기, 메뉴의 항목 선택 등)를 나타내며, 일부 키워드는 테스트 대상 시스템의 상태를 검증한다(예, 스크린에 의도된 텍스트 또는 GUI 오브젝트가 존재하는지 확인).
• 키워드는 테스트가 실행될 때 자동화 도구의 API 호출이나 기타 방법을 통해 테스트 대상 시스템의 구체적인 UI 오퍼레이션으로 변환된다.
• 장점은 테스트 자동화 로직을 테스트 설계로부터 분리하여 테스트 유지보수가 용이하고, GUI의 사소한 변경에 영향을 받지 않아 테스트 변경이 줄어들며, 하위 레벨 스크립트에 비하여 키워드로 쓰인 테스트가 작성하고 읽기가 더 쉽다.

 

안드로이드 애플리케이션 환경

• 안드로이드는 모바일 기기(특히 스마트폰)의 오픈 소스 운영 체제이다.
• 리녹스 운영 체제 커널에 기반한 안드로이드 플랫폼은 구글의 Open Handset Alliance에 의해 개발되며, 아래의 4개 계층으로 구성된다.
  1) 최하위 계층은 하드웨어 추상화 계층(hardware abstraction layer) 역할을 하는 리녹스 커널이며,
  2) 그 위로는 네이티브 C/C++ 라이브러리와 안드로이드 런타임(자바 가상 머신을 안드로이드에 맞게 구현한 Dalvik 가상 머신 포함)이 위치하고,
  3) 네이티브 라이브러리의 속성(properties)은 애플리케이션 프레임워크(Application Framework)를 형성하는 자바 코어 라이브러리에서 사용되며,
  4) 최상위 계층에는 애플리케이션 프레임워크 계층을 사용하여 생성되는 자바 기반 애플리케이션이 포함된다.
• 안드로이드 애플리케이션의 주요 빌딩 블록은 액티비티(activities), 서비스(services), 콘텐츠 제공자(content providers), 브로드캐스트 수신자(broadcast receivers)이다. 액티비티는 개별 GUI 뷰를 정의하고, 서비스는 백그라운드 프로세싱을 핸들링하며, 브로드캐스트 수신자는 시스템이나 다른 애플리케이션이 발생시킨 메시지를 청취하고(예, 배터리 저하, 전화 호출), 콘텐츠 제공자는 다수의 애플리케이션간에 애플리케이션 데이터를 공유하는데 사용된다. 이 애플리케이션 요소들은 여러 애플리케이션 간에 공유가 가능하므로 병행성(concurrency) 관련 에러가 발생할 수 있다.
• 안드로이드 GUI는 일차적으로 터치 스크린을 사용하여 통제되며 일부 기기는 트랙볼(trackballs), 항해키(navigational keys), 완전한 키보드(full keyboards)를 포함하기도 한다.

 

안드로이드 환경에서 GUI 테스팅 자동화(가용한 수단들)

안드로이드 소프트웨어 개발 키트(SDK)는 GUI 테스팅 자동화에 활용할 수 있는 여러 도구(유틸리티)를 포함하고 있다(아래 참조). 하지만 안드로이드의 보안 기능 때문에 이 도구들로 시스템 레벨의 GUI 테스팅 자동화를 하는 데는 현재 제약이 있다.

• 안드로이드 인스트루멘테이션 프레임워크(Android instrumentation framework): 별도의 테스팅 애플리케이션을 테스트 대상 애플리케이션(SUT)과 같은 프로세스에서 돌리는 것을 허용. 인스트루멘테이션을 위해서는 SUT의 소스 코드에 액세스가 필요
• Monkey 테스팅 도구: 키 누름, 스크린 찍기 같은 의사무작위 사용자 이벤트(pseudorandom user events)를 기기로 보내는 도구. 시스템 충돌/중단(crash)을 발생시키는 버그를 찾는데 유용(즉, 애플리케이션의 안정성을 테스팅). 플랫폼 버전 1.6부터는 클라이언트로부터 개별 GUI 이벤트를 받을 수 있는 Monkey 네트워크 인터페이스가 포함됨
• 액세스 기능(accessibility features): 장애가 있는 사용자를 돕기 위해 플랫폼 버전 1.6에서 새롭게 도입된 기술(예, 시력 문제가 있는 사용자를 위해 GUI 콘텐츠가 음성 지원되는 애플리케이션 개발). 이 액세스 기술의 API는 테스트 자동화에도 적용 가능하다. 즉, 기기의 백그라운드에서 동작하면서 다양한 GUI 이벤트 알림 정보(이벤트를 발생시킨 위젯에 대한 일부 정보도 포함됨)를 수신하는 액세스 서비스(accessibility services)를 개발자가 생성할 수 있도록 허용한다.
• Hierarchy Viewer: 애플리케이션 개발자가 안드로이드 GUI의 레이아웃을 조사할 수 있게 해주는 안드로이드 SDK 애플리케이션. Hierarchy Viewer는 Android Debug Bridge(adb)를 사용하여 안드로이드 기기 또는 에뮬레이터와 커뮤니케이션 한다(adb는 사용자가 PC에서 기기를 관리할 수 있게 함). Hierarchy Viewer는 GUI의 레이아웃을 트리 형태로 표현하고 스크린상의 모든 GUI 위젯의 정보(예, ID, 타입, 텍스트 콘텐츠, 위치, 크기)를 제공한다. 단점은 에뮬레이터 또는 보안 기능이 비활성화된 플랫폼 빌드의 기기(하드웨어 비잠금 상태의 개발 폰)에서만 사용 가능하다는 점이다.

 

안드로이드 환경의 키워드 기반 GUI 테스팅 자동화 도구

• 본 논문은 안드로이드 애플리케이션에 MBT를 적용하는 연구를 위해 안드로이드 에뮬레이터에서 동작하는 키워드 기반 GUI 테스트 자동화 도구를 구현함
• 이 도구는 GUI 이벤트 입력을 위해서는 Monkey 네트워크 인터페이스를 사용하고 GUI 상태 검증을 위해서는 Hierarchy Viewer를 사용한다.
• Hierarchy Viewer는 스크린상의 GUI 오브젝트의 원 데이터를 받기(a raw data dump) 위하여 기기 내부에서 동작하는 Window service라 불리는 서비스와 연결한다. 즉, 테스트 자동화에서 Window service가 GUI 콘텐츠를 검증하기 위한 방법으로 선정되었으며, Window service의 원 데이터를 읽고 그로부터 오브젝트 계층 구조(an object hierarchy)를 생성하는 파서도 개발함
• Monkey와 Window service를 사용하는 이 키워드 기반 테스트 자동화 도구는 Python 프로그래밍 언어를 사용하여 구현되었으며 구조는 아래와 같다.

 

[안드로이드의 키워드 기반 GUI 테스트 자동화 도구 아키텍쳐]

 

• GUIReader: Window service와 커뮤니케이션 하는 메인 컴포넌트
• MonkeyDriver: Monkey 네트워크 인터페이스로 연결
• Keyword: 모든 키워드를 위한 공통 메쏘드를 포함하는 추상화된 수퍼클래스
• ObjectKeyword: UI 오브젝트와 관련된 모든 키워드들의 수퍼클래스. UI 계층구조에서 특정 오브젝트를 찾기 위한 메쏘드를 포함한다.
  (실제 실행 가능한 키워드는 Keyword 또는 ObjectKeyword로부터 확장됨)
• MBTClient: TEMA MBT 테스트 엔진의 클라이언트 측을 구현하며 모델로부터 생성된 테스트를 런 한다.

 

안드로이드 키워드 기반 GUI 테스팅 자동화 도구의 키워드 예

예1) TapObject ’Feeds’    //’Feeds’라는 텍스트를 가진 오브젝트를 찾아 탭 한다.

예2) TapObject id/title     //’id/title’의 ID를 가진 오브젝트를 찾아 탭 한다.

예3) TapObject id/tabs:::’Feeds’       //오브젝트 계층도에서 ’id/tabs’의 ID를 가진 오브젝트 하에서
발견된 ’Feeds’라는 텍스트를 가진 오브젝트를 찾아 탭 한다.

 

예4) TapCoordinate 80,75            //주어진 스크린 좌표를 탭 한다.

 

 

 

TEMA: 모델 기반 GUI 테스팅 도구 집합

• TEMA는 S60 스마트폰의 빌트인 GUI 애플리케이션을 테스트하기 위해 개발된 모델 기반 테스팅 도구 셋이다.
• 리녹스(Gnome), 안드로이드, Java Swing, Qt(Maemo 기기) 환경에서도 적용이 연구됨
• MBT의 여러 단계(테스트 모델링, 테스트 설계, 테스트 생성, 테스트 디버깅) 각각에 대한 도구를 포함하고 있는 도구들의 집합으로 아래 그림과 같은 구조를 가진다.

 

[TEMA 도구의 아키텍쳐]

 

TEMA의 주요 컴포넌트는 아래와 같다.

• 테스트 모델링(The test modeling): 모델의 설계 및 기타 유틸리티를 위한 도구 포함
• 테스트 설계(The test design): 특정 테스트 목적(즉, 테스트 케이스) 설계를 위한 Web GUI 포함
• 테스트 생성(The test generation): 실제 테스트를 생성하기 위해 모델과 테스트 설계를 사용하는 여러 알고리즘 포함
• 테스트 디버깅(Test debugging): 성공적이지 않은 테스트 런을 해석하기 위한 도구 포함
• 키워드 실행(The keyword execution): 테스트 대상 시스템에 테스트를 실행. 도구 집합 중 유일하게 플랫폼에 의존하는 부분임. 본 논문에서 기술한 ‘안드로이드 키워드 기반 GUI 테스트 자동화 도구’가 여기에 해당됨
• 모델 라이브러리(The model library): 새로운 애플리케이션 모델이 생성될 때 유일하게 업데이트가 필요한 부분

 

TEMA의 모델링

• LSTS(labeled state transition systems)로 불리는 상태 머신(state machines)을 사용
• LSTS는 상태(states), 상태 간의 전환(transitions), 전환에 첨부된 액션(actions), 상태에 첨부된 레이블(labels)로 구성된다.
• 실 규모의 애플리케이션을 하나의 상태 머신으로 모델링하면 이해 및 유지보수가 어려운 모델이 생성되므로 여러 개의 작은 모델 컴포넌트를 생성하고 parallel composition이라 불리는 프로세스에서 이들을 자동으로 합쳐서 하나의 전체 테스트 모델로 만든다.
• 각 모델 컴포넌트는 액션 머신(an action machine)과 정제 머신(a refinement machine)이라는 두 개의 별도 상태 머신으로 기술된다.
  - 액션 머신은 전환에 첨부된 액션으로 모델링되는 액션 워드(action words)와 상태에 첨부된 레이블로 모델링되는 상태 검증(state verifications)을 사용하여 상위 레벨 기능을 기술한다.
  - 액션 워드와 상태 검증의 구현은 키워드를 사용하여 정제 머신에서 기술된다.
  - 이런 2계층 모델 구조의 장점은 모델이 새로운 도메인(예, 또 다른 스마트폰 모델)에서 사용될 때 정제 머신만 재구현하고 액션 머신 모델은 재사용이 가능하다는 점이다.
• TEMA 모델은 로칼라이제이션 테이블(localization tables)과 데이터 테이블(data tables)의 두 가지 타입의 테스트 데이터를 지원한다.
  - 로칼라이제이션 테이블은 로칼 스트링(localized strings)을 정제 머신으로부터 분리하는데 사용된다(스트링이 심볼명으로 참조됨).
  - 데이터 테이블은 복잡한 구조화 데이터(예, SUT에 주어진 입력 데이터)를 저장하는데 사용된다. 

 

TEMA의 액션 워드와 키워드 구분

• 액션 워드는 추상화 상위 레벨에서 사용자의 액션을 기술함(예, SMS 전송, 전화 응답, 새로운 연락처 추가 등)
• 액션 워드는 하위 레벨 키워드 시퀀스로 변환되며(예, 메뉴 네비게이션, 텍스트 입력 등), 일부 액션 워드는 하나 이상의 다수의 키워드 시퀀스로 구현될 수도 있다.
• 액션 워드와 키워드는 추상화 레벨이 다른 별도 모델로 분리된다(액션 워드는 액션 머신에서 사용되고 키워드는 하위 레벨 모델인 정제 머신에서 사용됨)

 

사례 연구: TEMA 도구로 안드로이드 애플리케이션에 MBT 수행

• 안드로이드 마켓에서 무료로 가용한 BBC News Widget(BBC 뉴스 피드를 가져오는 RSS 리더)이라는 애플리케이션을 테스트하는데 TEMA를 적용
• BBC News Widget은 뉴스 피드 나열 및 뉴스 아이템 읽기를 위한 메인 애플리케이션을 포함하며, 또한 선택된 특정 피드의 최신 헤드라인 표시를 위하여 홈 스크린에 추가할 수 있는 위젯을 포함한다. 애플리케이션 시작은 위젯을 탭 하거나 또는 애플리케이션 메뉴에서 메인 애플리케션을 선택하여 이루어진다.
• 모델링: 7개의 개별 뷰를 가진 BBC News Widget에 대한 총 16개의 상태 머신을 생성함.
• 테스트 런: 에뮬레이터에서 생성된 모델의 모든 액션을 커버하도록 테스트를 실행(모델에 에러가 없는 것을 확인하기 위한 목적). 이 테스트가 완성된 후 모델의 전환(transitions)을 무작위로 선택하여 테스트 하는 랜덤 테스트 수행. 또한 Contacts, Gallery, Camera 같은 주요 안드로이드 애플리케이션과 BBC News Widget 애플리케이션간의 인터액션 테스트도 수행함.
  - 총 240개의 테스트 런이 이루어짐(27,000개의 액션 워드와 50,000개의 키워드가 실행됨)
  - 모든 테스트를 런 하는데 약 115 시간이 소요됨(가장 긴 런 시간은 약 3시간, 평균 런 시간은 약 30분)
  - 테스트 런에서 키워드 하나의 평균 실행 시간은 약 8초 소요
• 테스트 결과: 아래 표와 같은 총 14개의 버그를 발견(8개는 모델링 프로세스에서 나머지 6개는 테스트 실행 단계에서 발견). 이 중 2개 버그(버그 5와 13)는 애플리케이션 크래시를 유발하며, 버그 5는 재생하기가 다소 어려움

 

번호	버그 기술	발견 단계
1	버튼이 비활성화 상태에서 빠져 나오지 못함	모델링
2	메인 피드가 변경될 때 피드 헤더가 업데이트 되지 않음
3	OK와 Cancel 버튼이 preferences의 값을 저장/복구하지 않음
4	위젯 피드가 변경될 때 피드 뷰가 업데이트 되지 않음
5*	preferences를 변경한 후 피드를 리프레싱하면 때때로 애플리케이션 크래시 가 발생
6	preferences에서 최대 헤드라인 값이 0인 경우가 적절하게 처리되지 않음
7	다수의 위젯 피드간에 스위칭 될 때 일관성 결여
8	피드 뷰에서 뉴스 아이템 개수가 제대로 업데이트 되지 않음
9	위젯으로부터 애플리케이션이 시작되었음에도 불구하고 Preferences가 ”Select default feed”를 보여줌	실행
10	뉴스 타이틀에 여분의 화이트 스페이스
11	뉴스 리드를 표시할 때 리프레시가 비일관적임
12	위젯이 백그라운드에서 포어그라운드로 스위칭 될 때 이전 자신의 상태를 잃어 버림
13*	업데이트 빈도 값이 0인 경우가 제대로 처리되지 않음(뉴스 피드의 업데이트 빈도를 0으로 변경하면 디바이스로의 로드가 너무 많아져 무반응 상태가 되거나 또는 애플리케이션 크래시 발생)
14	위젯 피드가 가용하지 않으면 위젯이 메인 애플리케이션을 시작시킴

[BBC News Widget의 MBT 테스트 결과 발견된 버그(* 표시는 crash 유발 버그)]