그래피컬 사용자 인터페이스 테스트

Graphical user interface testing

소프트웨어 엔지니어링에서 그래피컬 사용자 인터페이스 테스트란 제품의 그래픽 사용자 인터페이스(GUI)가 사양을 충족하는지 테스트하는 프로세스입니다.이는 보통 다양한 테스트 케이스를 사용하여 수행됩니다.

테스트 케이스 생성

테스트 케이스 세트를 생성하기 위해 테스트 설계자는 시스템의 모든 기능을 커버하고 GUI 자체를 완전히 연습하려고 합니다.이 작업을 수행할 때의 어려움은 도메인 크기와 시퀀스를 처리하는 두 가지입니다.또한, 검사자는 회귀 테스트를 수행해야 할 때 더 많은 어려움에 직면합니다.

Command-Line Interface(CLI; 명령줄 인터페이스) 시스템과 달리 GUI에는 테스트해야 하는 추가 작업이 있을 수 있습니다.Microsoft WordPad와 같은 비교적 작은 프로그램에서는 325개의 GUI [1]조작이 가능합니다.대규모 프로그램에서는, 조작의 수가 몇 배나 되는 경우가 있습니다.

두 번째 문제는 시퀀싱 문제입니다.시스템의 일부 기능은 일련의 GUI 이벤트를 통해서만 실행할 수 있습니다.예를 들어 파일을 열려면 먼저 파일 메뉴를 클릭한 다음 열기 작업을 선택하고 대화 상자를 사용하여 파일 이름을 지정한 다음 새로 열린 창에 응용 프로그램을 포커스를 맞춰야 합니다.가능한 작업 수를 늘리면 시퀀스 문제가 기하급수적으로 증가합니다.이는 테스터가 테스트 케이스를 수동으로 작성할 때 심각한 문제가 될 수 있습니다.

GUI에서도 회귀 테스트가 어려운 경우가 많습니다.GUI 는, 기반이 되는 애플리케이션이 큰폭으로 변화하지 않는 경우가 있습니다.버튼, 메뉴 항목 또는 대화상자가 위치 또는 모양을 변경했기 때문에 GUI를 통해 특정 경로를 따르도록 설계된 테스트가 실패할 수 있습니다.

이러한 문제로 인해 GUI 테스트의 문제 도메인은 자동화됩니다.완전하고 사용자 동작을 시뮬레이트하는 테스트 스위트를 자동으로 생성하기 위해 다양한 기술이 제안되어 왔습니다.

대부분의 테스트 기술은 이전에 CLI 프로그램 테스트에 사용되었던 것을 기반으로 구축하려고 하지만 이러한 기술을 GUI에 적용할 경우 확장 문제가 발생할 수 있습니다.예를 들어 유한 상태 머신 기반[2][3] 모델링(시스템을 유한 상태 머신으로 모델링하고 모든 상태를 실행하는 테스트 케이스를 생성하기 위해 프로그램을 사용하는 경우)은 제한된 수의 상태를 가진 시스템에서 잘 작동하지만 GUI에 대해 지나치게 복잡하고 다루기 어려울 수 있습니다(모델 기반 테스트 참조).

계획 및 인공지능

CLI[4] 기술을 채택한 테스트 스위트 생성에 대한 새로운 접근법에는 계획 [5]시스템을 사용하는 것이 포함됩니다.계획은 인공지능(AI) 영역에서 잘 연구된 기술로, 다음 4가지 매개 변수를 포함하는 문제를 해결하려고 시도합니다.

  • 초기 상태
  • 목표 상태
  • 연산자 집합 및
  • 조작할 수 있는 오브젝트 세트

계획 시스템은 연산자를 사용하여 초기 상태에서 목표 상태까지의 경로를 결정합니다.계획 문제의 단순한 예로서, 두 개의 단어와 한 단어의 한 문자를 다른 문자로 대체하는 단일 연산이 주어진다면, 목표는 한 단어를 다른 단어로 바꾸는 것일 수 있습니다.

저자들은 플래너[6] IPP를 사용하여 이 기법을 시연했다.가능한 작업을 결정하기 위해 먼저 시스템의 UI를 분석합니다.이들은 계획 문제에 사용되는 연산자가 됩니다.다음으로, 초기 시스템 상태가 결정되고, 테스트자가 시스템을 연습할 수 있다고 느끼는 목표 상태가 지정됩니다.계획 시스템은 초기 상태에서 목표 상태까지의 경로를 결정하며, 이것이 테스트 계획이 됩니다.

플래너를 사용하여 테스트 케이스를 생성하면 수동 생성에 비해 몇 가지 특별한 이점이 있습니다.계획 시스템은 본질적으로 테스터에게 매우 유익한 방식으로 계획 문제에 대한 솔루션을 생성합니다.

  1. 그 계획은 항상 유효하다.시스템의 출력은 목표 상태에 도달하기 위해 연산자를 사용하는 유효하고 올바른 계획이거나 계획이 전혀 없습니다.이는 테스터가 작동한다고 생각했지만 성공하지 못한 잘못된 테스트 사례로 인해 테스트 스위트를 수동으로 생성할 때 많은 시간이 낭비될 수 있기 때문에 유용합니다.
  2. 계획 시스템은 순서에 주의를 기울인다.대부분의 경우 특정 기능을 테스트하려면 테스트 케이스가 복잡해야 하며 GUI를 통해 특정 순서로 동작이 실행되는 경로를 따라야 합니다.수동으로 실행하면 오류가 발생할 수 있으며 수행하기도 매우 어렵고 시간이 많이 걸릴 수 있습니다.
  3. 마지막으로 가장 중요한 것은 계획 시스템이 목표 지향적이라는 것입니다.테스터는 테스트 스위트 생성에 가장 중요한 사항을 집중하여 시스템의 기능을 테스트합니다.

테스트 스위트를 수동으로 작성할 때 테스터는 기능을 테스트하는 방법(GUI를 통한 특정 경로)에 더 집중합니다.계획 시스템을 사용하여 경로를 관리하고 테스터는 어떤 기능을 테스트해야 하는지에 집중할 수 있습니다.이 방법의 또 다른 장점은 경로 생성 시 계획 시스템이 어떤 식으로든 제한되지 않고 테스터에 의해 전혀 예상되지 않은 경로를 발견할 수 있다는 것입니다.이 문제는 [7]싸워야 할 매우 중요한 문제이다.

GUI 테스트 케이스를 생성하는 다른 방법은 초보 사용자를 시뮬레이트합니다.시스템의 전문 사용자는 GUI를 통해 직접적이고 예측 가능한 경로를 따르는 경향이 있지만 초보 사용자는 보다 랜덤한 경로를 따릅니다.따라서 초보 사용자는 전문가보다 GUI의 가능한 상태를 더 자세히 살펴볼 수 있습니다.

문제는 '새로운' 시스템 사용을 시뮬레이션하는 테스트 스위트를 생성하는 데 있습니다.이 [7]문제를 해결하기 위해 유전자 알고리즘을 사용하는 것이 제안되었다.시스템을 통과하는 초보 경로는 랜덤 경로가 아닙니다.첫째, 초보 사용자는 시간이 지남에 따라 배우고 일반적으로 같은 실수를 반복하지 않습니다. 둘째, 초보 사용자는 계획을 따르고 있으며 도메인이나 시스템에 대한 지식이 있을 수 있습니다.

유전자 알고리즘은 다음과 같이 작동한다: 일련의 '유전자'가 무작위로 생성된 후 몇 가지 작업을 받는다.임무를 가장 잘 완수하는 유전자는 보존되고 그렇지 않은 유전자는 폐기된다.생존한 유전자가 복제되고 나머지 유전자가 무작위 유전자로 채워지면서 이 과정이 다시 반복된다.결국 하나의 유전자(또는 어떤 역치 세트가 있는 경우에는 작은 유전자 세트)가 그 세트의 유일한 유전자가 될 것이고 주어진 문제에 자연스럽게 가장 적합할 것이다.

GUI 테스트의 경우는, 다음과 같이 동작합니다.각 유전자는 본질적으로 일정한 길이의 무작위 정수값의 목록입니다.이들 유전자는 각각 GUI를 통과하는 경로를 나타냅니다.예를 들어 특정 위젯 트리의 경우 유전자의 첫 번째 값(각 값을 대립 유전자라고 함)이 조작할 위젯을 선택하고 다음 대립 유전자가 위젯에 입력될 수 있는 개수에 따라 위젯에 입력을 채웁니다(예를 들어 풀다운 목록 상자에는 입력이 하나...선택된 목록 값이 포함됩니다).유전자의 성공은 최고의 '새로운' 행동에 보상을 주는 기준에 의해 평가된다.

X 윈도우 시스템에 대해 이 테스트를 수행하지만 모든 윈도우 시스템으로 확장 가능한 시스템에 대해 설명합니다.[7]X Window 시스템은 XServer 및 에디터 프로토콜을 통해 GUI를 직접 사용하지 않고 프로그램에 GUI 입력을 동적으로 전송하고 GUI 출력을 얻을 수 있는 기능을 제공합니다.예를 들어 XSendEvent()를 호출하여 풀다운메뉴 클릭을 시뮬레이트할 수 있습니다.이 시스템은 연구자들이 유전자 생성과 테스트를 자동화할 수 있도록 하여 테스트 대상 어플리케이션에 대해 일련의 초보 사용자 테스트 케이스를 만들 수 있도록 한다.

테스트 케이스 실행

처음에 이러한 전략은 CLI 테스트 전략에서 이행 및 조정되었습니다.

마우스 위치 캡처

CLI 환경에서 일반적으로 사용되는 방법은 캡처/재생입니다.캡처 재생은 시스템 테스트 중에 여러 번 시스템 화면이 비트맵 그래픽으로 "캡처"되는 시스템입니다.이 캡처를 통해 테스터는 테스트 프로세스를 "재생"하고 테스트 출력 단계의 화면을 예상 화면과 비교할 수 있습니다.케이스가 합격하면 화면이 같고 불합격하면 화면이 다르기 때문에 이 검증은 자동화될 수 있습니다.

캡처/재생 사용은 CLI 세계에서는 매우 효과적이지만 GUI 기반 [8]시스템에 구현하려고 하면 큰 문제가 발생합니다.가장 명백한 문제는 GUI 시스템의 화면이 다른 반면 기본 시스템의 상태는 같을 수 있기 때문에 자동 검증이 매우 어렵다는 것입니다.이는 GUI를 통해 그래픽 객체의 화면 외관과 위치가 달라지기 때문입니다.글꼴은 다를 수 있으며 창의 색상이나 크기는 다를 수 있지만 시스템 출력은 기본적으로 동일합니다.이는 사용자에게는 분명하지만 자동 검증 시스템에서는 분명하지 않습니다.

이벤트 캡처

테스터는 이 문제와 다른 문제를 해결하기 위해 '후드 아래'에 가서 기본 윈도우 시스템에서 [9]GUI 상호작용 데이터를 수집했습니다.이 창을 로그로 캡처함으로써 시스템과의 상호작용은 GUI의 외관과 분리된 형식으로 이루어집니다.이제 이벤트 스트림만 캡처됩니다.이벤트 스트림은 일반적으로 매우 상세하고 대부분의 이벤트는 문제와 직접 관련이 없기 때문에 이벤트 스트림에 대한 필터링이 필요합니다.이 접근방식은 예를 들어 MVC 아키텍처를 사용하여 모델 및 컨트롤러가 모든 로직을 보유하고 있는 동안 뷰(여기서는 GUI)를 최대한 단순하게 함으로써 보다 쉽게 할 수 있습니다.또 다른 접근방식은 소프트웨어의 내장 보조 기술을 사용하여 HTML 인터페이스 또는 3계층 아키텍처를 사용하여 사용자 인터페이스를 다른 애플리케이션과 더 잘 분리할 수 있도록 하는 것입니다.

GUI에서 테스트를 실행하는 또 다른 방법은 GUI에 드라이버를 내장하여 명령 또는 이벤트를 다른 [7]프로그램에서 소프트웨어로 전송할 수 있도록 하는 것입니다.이 방법은 입력 및 출력 테스트를 완전히 자동화할 수 있고 사용자 오류를 제거할 수 있으므로 테스트 시 시스템과의 직접 이벤트 송수신 방법이 매우 적합합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b 아티프 M. 메몬, 마사 E. 폴락, 메리 루 소파.GUI의 테스트 케이스를 생성하기 위한 목표 지향 접근방식을 사용한다.ICSE '99 제21회 소프트웨어 엔지니어링 국제회의의 속행.
  2. ^ J.M. 클라크동작 모델에서 자동 테스트 생성Pacific Northwest 소프트웨어 품질 회의의 계속.IEEE Press, 1998년 5월
  3. ^ 에스멜리오글루와 엘 압펠바움자동 테스트 생성, 실행 및 보고서 작성Pacific Northwest 소프트웨어 품질 회의의 계속.IEEE Press, 1997년 10월
  4. ^ A. Howe, A. von Mayrhauser 및 R.T. 므라즈AI 계획상의 문제로서 테스트 케이스 생성을 실시합니다.자동 소프트웨어 엔지니어링, 4:77-106, 1997.
  5. ^ Atif M. Memon, Martha E. Polock, 그리고 Mary Lou Soffa.자동 계획을 사용한 계층형 GUI 테스트 케이스 생성IEEE 트랜스소프트, Eng., vol. 27, No. 2, 2001, 페이지 144-155, IEEE 프레스.
  6. ^ J. 쾰러, B.Nebel, J. Hoffman, Y.디모풀로스.계획 그래프를 ADL 부분 집합으로 확장합니다.컴퓨터 공학 강의 노트, 1348:273, 1997.
  7. ^ a b c d D. J. Kasik과 H. G. G. George.초보 사용자 테스트 스크립트를 자동으로 생성합니다.M. J. 타우버, V. 벨로티, R. 제프리스, J. D.맥킨레이, J. 닐슨 편집자, 컴퓨터 시스템의 인적 요소에 관한 회의의 진행: Common Ground, 244-251페이지, 뉴욕, 1996년 4월 13-18일자, ACM Press.[1]
  8. ^ L.R. 케플GUI 테스트의 블랙 아트.Dobb 박사의 소프트웨어 도구 저널, 19(2):40, 1994년 2월.
  9. ^ M. L. Hammontree, J. J. Hendrickson, B.W. 헨슬리그래피컬 사용자 인터페이스에 대한 조사 및 테스트를 위한 통합 데이터 캡처 및 분석 도구입니다.P. 바우어스펠트, J. 베넷, G에서요Lynch, 편집자, 컴퓨터 시스템의 인적 요소에 관한 회의의 진행, 431-432페이지, 뉴욕, 뉴욕, 미국, 1992년 5월.ACM 프레스