KR20090084905A

KR20090084905A - 그래픽 유저 인터페이스 테스팅을 위한 방법 및 시스템

Info

Publication number: KR20090084905A
Application number: KR1020097010995A
Authority: KR
Inventors: 말콤 알라스데어 쿠드웰; 이안 제럴드 크래그스; 제임스 클리브 스튜어트
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2006-12-21
Filing date: 2007-11-08
Publication date: 2009-08-05
Also published as: WO2008074569A1; US8225140B2; GB0625577D0; US20080155514A1

Abstract

그래픽 유저 인터페이스 (GUI) 테스팅을 위한 방법과 시스템이 제공된다. 상기 방법은 테스트 중에 있는 GUI (204)에 테스트 스텝(208,222)을 적용하는 단계와 상기 테스트 스텝이 적용될 테스트 중에 있는 GUI (204)내에서 컨트롤 발견하는 단계를 포함한다. 모델(210)은 새로운 컨트롤이 발견될 때 테스트 중인 GUI (204)의 컨텐츠의 표시들로 동적으로 형성된다. 상기 방법은 디펜던트 컨트롤들의 컬렉션(a collection of dependent controls)을 발견하는 단계와 상기 GUI 모델(210) 내에 컨트롤들의 컬렉션을 상기 컨트롤들의 일반화된 패턴(a generalized pattern)으로서 표시하는 단계를 포함한다. 상기 방법은 테스트 스텝을 상기 모델(210)과 동시에 상기 테스트 중인 GUI (204)에 적용하고 상기 테스트 중인 GUI (204)와 상기 모델(210)으로부터 상기 테스트 스텝의 결과들을 비교한다. 만일 상기 모델에 테스트 스텝이 적용되고 상기 컨트롤의 표시가 상기모델에 제공되지 않도록 결정된다면, 상기 모델(210)에 상기 컨트롤의 표시를 추가하기 위해 형성 규칙(212)(a building rule)을 실행된다.

Description

그래픽 유저 인터페이스 테스팅을 위한 방법 및 시스템{METHOD AND SYSTEM FOR GRAPHICAL USER INTERFACE TESTING}

이 발명은 그래픽 유저 인터페이스(GUI) 테스팅 분야에 관한 것으로서, 특히, 테스트될 GUI가 완성되기 전의 GUI테스팅에 관한 것이다.

GUI를 위한 테스팅의 자동화는 어렵다. 그 이유는 통상적으로 이용 가능한 스펙 정보(specification information available)는 거의 없고, GUI의 개발기간 동안 그리고 소프트웨어 제품 발표들 사이 모두에서 긴급한 변경이 반복적으로 일어나는 경향이 있기 때문이다. GUI에 기초한 테스트의 자동화는 그 어떠한 것이라도 개발과 유지에 비용이 많이 드는 경향이 있어서, 비용효과적인 관점에서는 별 실익이 없었다(marginal). 종종 GUI 개발은 다른 콤포넨트들과 인터페이스들에 의해서 제한을 받는 데(gated), 그래서 개발 사이클에 지연이 발생하고, 이것은 테스팅 시간을 제한한다.

자동화된 GUI 테스팅은 현재는 사용자에 의해서 취해진 스텝들(steps)을 기록함에 의해서 달성된다. 이 스텝들은, 예를 들어 링크들, 버튼들(buttons)등을 클릭하고 데이터를 엔트리 필드(entry fields), 체크박스(checkbox) 등에 입력하는 것을 포함할 수 있다. 테스트 도구들은 이러한 스텝들을 기록하는데, 테스트중 서 로 영향을 미치는(interacted with) 페이지들의 개별 엘리멘트들("widgets")의 기록과 함께 기록한다.

GUI 페이지는 페이지 컨텐츠(page content)를 암호화 하는 네스티드(nested) HTML(hypertext mark-up language) 태그를 반영하는 위젯들(widgets)의 계층구조(hierarchy)를 가지고 있다. 통상적으로 하나의 페이지는 수백개의 엘리멘트들(elements)을 가지고 있는데, 이들 중 상당 수는 사용자의 눈에 보이지 않는 것들이다. 이들은, 예를 들어 프레임들(frames), 양식들(forms), 테이블들(tables), 문서들(documents), 레이블들(lables)들은 체크박스들(checkboxes)과 링크들(links)과 엔트리필드들(entryfields) 등을 서로 포함한다. 로 복잡한 계층구조를 이루고 있다.

위젯에 대한 상세한 사항들(the widget detailes)은 보통 GUI 테스트 리플레이 툴(a GUI test replay tool)에 의해서 하나의 맵(a map)에 저장되며, 이것은 엘리멘트들의 계층구조를 디스플레이하기 위해서 그리고 스크립트들(scripts)이 리플레이 될 때 페이지 상에서 그들을 찾기 위해서 사용될 수 있다. 이 맵은 기록 프로세스 동안 작성되며 일단 기록되면 변경되지 않을 것으로 기대된다.

테스트 중인 페이지들은 종종 개발 툴들(development tools)을 사용하여 생성되는데, 이 때문에 이들은 복잡하게 되어, 종종 많은 여분의 눈에 보이지 않는 네스티드 테이블 층(many extra invisible layers of nested tables)들을 갖게 된다. 이 때문에 또한 이들은 변경되기 쉽다. 개발자가 작업을 할 때마다 하나의 페이지가 재생성될 수 있고, 각각의 재생성에서, 그 순서와 컨텐츠는, 자동 소프트웨 어가 관련된 경우, 인지(recognition)를 넘어서 변경될 수 있다.

어느 것이던지 페이지들이 변경되는 경우는 언제나, 테스트 툴의 맵(the test tool’s map)은 재생성되거나 그렇지 않으면 유지되어야 한다. 링크(a link)가 버튼(a button)과 스왑(swap)되는 경우, 레이블들(labels)이 그들을 컨트롤하기 보다 그들의 컨트롤 아래로 들어가기 위해 스왑(swap)되는 경우, 컨트롤들을 포함하는 프레임들(frames), 폼들(forms), 테이블들 등 눈에 보이지 않는 계층구조(the invisible hierarchy)가 층들을 추가하거나 혹은 잃는 경우, 종종 그러한 변경들은 리 매핑(the re-mapping)을 매우 어렵게 한다. 만일 맵(the map)이 유지될 수 없다면, 기록된 테스트 스크립트들(the recorded test scripts)은 실패하게 될 것이다. 왜냐하면 그들은 데이터 입력 등을 클릭하기 위해 요구된 컨트롤들을 발견할 수 없기 때문이다.

레코딩이 기록된 위젯들(recorded widgets)에 기초한다는 사실은 테스팅을 액션들의 레코딩들에 기초하도록 제한한다. 맵에 그들을 기록하기 위해서 위젯들과 첫 번째 상호 대화(interacting) 없이는 위젯들을 사용하는 스크립트들을 만들어내는 테스트 툴들을 사용하는 것이 가능하지 않다. 이것은 샘플 페이지들이 개발로부터 이용 가능할 때까지 테스터들(testers)이 스크립트들을 효과적으로 기록하지 못하도록 한다.

테스트 케이스들을 많이 수집하여 유지하는 것은 페이지에 위젯들의 매핑을 유지해 나가는 문제들 때문에 실제로 매우 어려운 일이다. 이것들을 유지하기 위해 노력하는 것보다 테스트 스크립트들을 재기록하는 것이 종종 더 빠르다. 수백 혹은 수천의 테스트 스크립트들이 주어진다고 할 때, 이들을 유지하는데 들어가는 노력은 GUI 테스팅에 심각한 제한이 될 수 있다. 종종 GUI 테스트들은 이러한 유지 문제들 때문에 매우 제한된 범위 내에서 자동화된다.

문제의 GUI에 접근하지 않고, GUI 컨텐츠의 모델을 작성하여 유지하는 것이 본 발명의 목적이다.

본 발명의 첫 번째 목적은 GUI 테스팅을 위한 방법을 제공하는 것이다. 이 방법은 테스트 중에 있는 GUI에 테스트 스텝을 적용하는 단계 ; 상기 테스트 스텝이 적용될 테스트 중에 있는 GUI 내에서 컨트롤을 발견하는 단계 ; 새로운 컨트롤이 발견될 때 테스트 중인 GUI 컨텐츠의 모델을 동적으로 형성(building)하는 단계 ; 및 테스트 중에 있는 GUI의 컨트롤들을 상기 모델에서 표시하는 단계를 포함한다.

상기 방법은 디펜던트 컨트롤들의 컬렉션(a collection of dependent controls)을 발견하는 단계와, 상기 컨트롤들의 컬렉션을 상기 모델에서 표시하는 단계와 상기 컨트롤들의 일반화된 패턴(a generalized pattern)으로서 컨틀롤들의 컬렉션을 상기 모델에서 표시하는 단계를 포함할 수 있다.

상기 방법은 GUI 컨텐츠의 상기 모델에 테스트 스텝을 적용하는 단계와 ; 테스트 중에 있는 GUI 및 상기 모델로부터 나온 상기 테스트 스텝의 결과들을 비교하는 단계를 포함할 수 있다.

만일 상기 모델에 테스트 스텝을 적용하는 단계에서 상기 테스트 스텝이 적용될 컨트롤의 표시가 상기 모델에 제공되지 않도록 결정된다면, 상기 방법은 상기 모델에 상기 컨트롤의 표시를 추가하기 위해 형성 규칙(a building rule)을 실행하는 단계를 포함할 수 있다.

상기 방법은 테스트 중인 GUI 내에서 발견되는 컨트롤들과 테스트 중인 GUI 내에서 발견되지 않는 가상 컨트롤들(virtual controls)의 표시들(representations)을 상기 모델 내에 제공하는 단계를 더 포함할 수 있다. 상기 방법은 상기 모델 내에 컨트롤들과 가상 컨트롤들의 표시들을 위해서 컨텐츠 데이터를 형성하여 유지하는 단계를 포함할 수 있다. 상기 방법은 상기 가상 컨트롤들로부터 테스트 중인 GUI 내에서 발견된 컨트롤들의 표시들을 구별하기 위해 비지빌리티 플래그(visibility flag)를 제공하는 단계를 포함하는 것이 더 바람직할 수 있다.

상기 모델 내에서 컨트롤의 표시는 개별 컨트롤 속성들(properties)을 포함하도록 확장된 컨트롤의 클래스 형식(in the form of a class of control)으로 될 수 있다.

상기 방법은 GUI의 실제 사용자의 행위(behavior)를 에뮬레이트(emulate)하기 위해서 다수의 테스트 규칙들을 발생시키는 단계를 포함할 수 있고, 이 테스트 규칙들은 새로운 규칙이 시작되기 전에 완료되어야 하는 임의로 선택된 원자 액션들(randomly selected atomic actions)과 인터럽트 될 수 있는 비 원자 액션들(non- atomic actions)을 포함할 수 있다.

본 발명의 두 번째 목적은 GUI 테스팅 시스템을 제공하는 것이다. 이 시스템은 테스트 중인 GUI에 테스트 스텝을 적용하기 위한 테스트 엔진(a test engine) ; 테스트 중인 GUI에서 새로운 컨트롤이 발견될 때 테스트 중인 GUI의 컨텐츠의 모델을 동적으로 형성하는 수단을 포함한다.

상기 테스트 엔진은 상기 모델에 테스트 스텝을 적용할 수 있고 테스트 중인 GUI 및 상기 모델로부터 상기 테스트 스텝의 결과들을 비교하는 수단을 포함한다.

상기 모델을 동적으로 형성하는 수단(The means for dynamically building the model)은 테스트 스텝이 적용될 컨트롤의 표시가 상기 모델 내에 제공되지 않았다고 테스트 스텝이 결정하는 경우 실행되는 형성 규칙들(building rules)을 포함할 수 있다.

상기 시스템은 GUI의 실제 사용자의 행위(behavior)를 에뮬레트(emulate)하기 위해서 다수의 테스트 규칙들을 발생시키는 수단을 포함할 수 있고, 이 테스트 규칙들은 새로운 규칙이 시작되기 전에 완료되어야 하는 임의로 선택된 원자 액션들(randomly selected atomic actions)과 인터럽트 될 수 있는 비원자 액션들(non- atomic actions)을 포함한다.

본 발명의 세번째 목적은 테스트 중인 GUI 모델을 제공하는 것이다. 이 모델은 테스트 중인 GUI 내에서 발견되는 컨트롤들의 표시들과 테스트 중인 GUI 내에서는 발견되지 않지만 상기 모델에 구조(structure)를 제공하는 가상 컨트롤들의 표시들을 포함한다.

상기 모델은 상기 모델 내 컨트롤들의 일반화된 패턴으로서(as a generalized pattern of the controls in the model) 상기 모델 내 컨트롤들의 컬렉션을 표시하는 것을 포함할 수 있다.

상기 모델 내 컨트롤들의 표시들은 가상 컨트롤들과 테스트 중인 GUI 내에서 발견된 컨트롤들의 표시들을 구별하기 위해서 비지빌리티 플래그를 포함할 수 있다

상기 모델 내 컨트롤의 표시는 개별 컨트롤(the individual control)의 속성들을 포함하기 위해서 확장된 컨트롤의 클래스 형식일 수 있다.

본 발명의 네 번째 목적은 컴퓨터 판독 가능 매체에 저장된 컴퓨터 프로그램 제품을 제공하는 것이다. 이 제품은 다음의 단계들을 수행하는 컴퓨터 판독 가능 프로그램 코드 수단을 포함한다. 이 단계들은 테스트 중에 있는 GUI에 테스트 스텝을 적용하는 단계 ; 상기 테스트 스텝이 적용될 테스트 중에 있는 GUI 내에서 컨트롤을 발견하는 단계 ; 새로운 컨트롤이 발견될 때 테스트 중에 있는 GUI의 컨텐츠의 모델을 동적으로 형성하는 단계 ; 및 테스트 중에 있는 GUI의 컨트롤들을 상기 모델에 표시하는 단계를 포함한다.

첨부한 도면들을 참조하여 본 발명의 실시 예들을 아래에서 설명한다. 이들은 본 발명의 예들로서만 설명하는 것이며, 본 발명이 여기에 한정되는 것은 아니다.

제 1도는 선행기술에 공지된 GUI 테스트 시스템의 블록도이다.

제 2도는 본 발명에 따른 GUI 테스트 시스템의 블록도이다.

제 3도는 본 발명에 따른 방법의 흐름도이다.

제 1도를 참조하면, 종래의 GUI 테스팅 시스템(100)은 테스트 중인 GUI(104) 상에서 테스트들(tests)을 실행하는 테스트 엔진(102)을 포함하는 것을 볼 수 있다.

GUI(104)는 보통 다수의 페이지를 갖는 데, 각 페이지는 사용자와 상호 대화(be interacted with)할 수 있는 개별 엘리멘트들(위젯들(widgets)이라 부른다)의 계층구조를 갖는다. 예를 들어, 위젯들의 계층구조는 프레임들(frames), 폼들(forms), 테이블들(tables), 라벨들(labels), 네스티드 라벨들(nested lables), 체크박스들(checkboxes), 링크들(links), 엔트리필드들(entryfields) 등을 포함할 수 있다.

종래 테스팅에서, 테스트 엔진(102)은 테스트 중인 GUI(104) 상에서 GUI 명령들(GUI commands)의 목록들의 형식으로 테스트 스크립트들(108)을 실행한다. 이 GUI 명령들은 GUI(104)와 상호 대화하는 사용자에 의해서 취해질 수 있는 스텝들을 표시하는 자동화된 명령들이다. 테스트 엔진(102)은 취해진 스텝들과 상호 대화가 있었던 GUI 페이지들의 위젯들을 기록한다.

종래의 GUI 테스팅 시스템(100)에서, 맵(109)이 생성되고 테스트 엔진(102)에 의해서 저장된다. 맵(109)은 GUI 페이지들 내의 위젯들의 계층구조를 표시한다. 맵(109)은 테스트 스크립트들(108)이 실행될 때 GUI 페이지들 상에서 위젯들을 발견하기 위해 사용된다. 맵(109)은 GUI 페이지들의 위젯들 계층구조들 기록이 되도록 설계된다.

동적 GUI 컨텐츠 모델

GUI들을 테스팅하는 방법과 GUI 테스팅 시스템이 GUI 페이지 컨텐츠 모델(GUI 모델이라한다)내에서 제공된다. GUI 페이지들의 컨텐츠를 판독함으로서 동적으로 형성된다. 이 GUI 모델은 테스트들을 체크하고 실행하는데 양쪽 다 기초로서 사용된다. 제공된 GUI를 검사하고(inspecting) 나서 GUI 모델이 형성되기 때문에 테스팅이 시작되기 전에 실제 GUI에 관한 이전 지식은 요구되지 않는다.

제 2도를 참조하면, 에이젼트(206)를 통해서 테스트 중인 GUI(204) 상에서 테스트들을 실행하는 테스트 엔진(202)이 제공된다. 이 테스트 엔진(202)은 또한 실제 GUI (204)의 테스팅 동안 GUI 모델(210)을 동적으로 형성한다. 테스트 엔진(202)은 실제 GUI (204) 뿐만 아니라 GUI 모델(210) 상에서도 테스트들을 실행한다.

GUI 모델(210)은 GUI 형성 규칙들(212)을 포함한다. 이 규칙들은 GUI 모델(210) 내에 존재하지 않는 컨트롤에 대하여 테스트가 적용되었을 때 실행된다. GUI 형성 규칙들(212)은 상기 컨트롤에 적용되는 테스트의 다음 인스턴스(the next instance)에서, GUI 모델(210)이 사용될 수 있도록 GUI 모델(210)에 미싱 컨트롤(the missing control)을 추가하기 위해 실행된다.

GUI 모델(210)은 테스트 중인 GUI (204)의 페이지들의 발견된 컨텐츠(the discovered contents)의 모델이다. GUI 모델(210)은, 예를 들어 발견된 컨트롤들의 목록으로 단순히 이루어져 있을 수 있다.

GUI 모델(210)은 실제 GUI(204) 및 파생 혹은 추론된 컨트롤들(derived or inferred controls) 양자 모두를 위한 데이터의 내부 모델(들)(internal model(s)) 혹은 목록(들)을 포함할 수 있다. 따라서, GUI 모델(210)은 실제 GUI (204)의 페이지 상에서 발견된 컨트롤들 및 상기 페이지의 실제 일부는 아니지만 컨트롤들의 유용한 표시들(a useful representation of controls)인 가상의 컨트롤들 양자 모두를 포함한다.

예를 들어, 상기 페이지는 라벨 및 엔트리필드 위젯을 포함할 수 있다. 이것은 상기 라벨로부터의 이름과 상기 엔트리필드 위젯인 컨트롤을 사용하여 라벨 붙은 엔트리필드로 모델링 될 수 있다. 이 라벨이 붙은 엔트리필드는 상기 페이지의 실제 엘리멘트는 아니지만 작업이 진행중인 페이지의 엘리멘트들을 참조하는 데는 매우 유용하다.

종래의 테스팅에서, 테스트 엔진(202)은 테스트 스크립트들(208)을 테스트 중인 GUI(204) 상에서 수행되어야 하는 GUI 명령들의 목록들의 형태로 실행한다. 추가로 혹은 선택적으로 모델에 기초한 테스팅(model-based testing)이 수행될 수도 있다.

사용자 상호 대화 형식의 데이터 모델(220)은 GUI (204)에 의해서 처리되는 데이터 및 객체들의 앱스트랙트 모델(an abstract model)의 형태로 수동으로 형성될 수 있다. 이것은 GUI 모델(210)과는 별도로 되어 있다. 모델에 기초한 테스팅은 데이터 모델 규칙들(222)을 사용할 수 있다. 이 규칙들은 데이터 모델(220)에서 기대하는 결과들(expected outcomes)을 가져오는 생성(create), 갱신(update), 삭제(delete)등과 같은 임의적 액션들(random actions)이다. 규칙들(222)은 테스팅 동안 임의로 선택되는 테스트 스텝들을 위한 명령들의 시퀀스들(sequences of instructions)이다. 규칙들(222)은 종래의 비 GUI 모델에 기초한 테스팅(non-GUI model-based testing)에서처럼, 행위(the behavior)에 관한 시나리오들(scenarios) 및 테스트 종류들(test aspects)을 실행하기 위해 사용된다.

따라서, GUI 모델(210)과 데이터 모델 (220) 양자 모두는 GUI (204)의 테스팅 동안 사용된다. GUI 모델(210)은 페이지 컨텐츠를 풀기 위해서 그리고 그 페이지 상의 컨트롤들을 발견하기 위해서 사용되고, 데이터 모델(210)은 어떤 데이터가 이용 가능한 지 그리고 그 데이터가 표시하는 것들로 무엇을 할 수 있는 지를 결정하기 위해서 사용된다.

테스트 엔진 (202)은 GUI (204) 및 GUI 모델(210) 상에서 실행되는 테스트들의 메시지들, 보고서들, 로그들(logs) 등을 생성한다.

테스트 스크립트들(208) 및 데이터 모델 규칙들(222)은 타입, 이름, 및 컨트롤들의 위치와 그 컨트롤에 적용할 연관된 데이터 혹은 액션들을 규정하는 컨트롤들(251)의 형태의 명령들을 실행한다. GUI (204) 및 GUI 모델(210)은 위젯 인스턴스들(252)로 복귀한다. GUI 모델(210)은 실제 컨트롤들(254) 및 앱스트렉트 혹은 가상의 컨트롤들(255)을 저장한다.

만일 GUI (204)에 변경이 발생하면, GUI 모델(210)은 몇 분 내에 재생성되거나, 혹은 테스팅 동안 동적으로 갱신될 수 있다. 이렇게 함으로서 GUI (204)를 테스트할 수 있도록 하기 위해 요구되는 리드 타임(the lead time)을 대단히 감소시킬 수 있어 테스트들을 자동화하는데 통상적으로 소비되는 시간과 노력을 절약하게 해 준다. 이러한 기술을 사용하는 툴들(tools)은 모든 GUI (204)에 적용될 수 있다.

GUI 모델(210)은 실제 GUI를 조사(explore)하기 위해 사용될 수 있는데, 이 모델이 만들어 지면, 그 컨텐츠의 다양한 특성(various aspects)에 관한 디스크립션들(descriptions)을 로그(log)하는 것이 가능하다. 이 때문에 테스팅이 계속 진행되는 동안 전체 GUI (204)로부터 데이터를 자동적으로 수집하여 검사하는 것이 가능하게 된다.

테스트 스크립트들(208) 혹은 데이터 모델 규칙들(222)은 GUI 모델(210)을 통해서 이용 가능한 GUI 동작 부분들을 테스트하고 이들을 실제 GUI (204)와 비교하여 변경들(changes), 예상치 못했거나 흥미로운 특징들(unexpected or interesting features), 혹은 기대와 다른 행위(behavior different from expectations)를 보고하도록 한다. 임의로 선택된 데이터 모델 규칙들(222)은 테스트 중인 GUI (204)와 GUI 모델(210) 양자 모두에서 동작들(operations)을 시도해 볼 수 있고, 그 다음 그 결과들을 비교해 볼 수 있다. 만일 그 결과들이 다르면, 실제 GUI (204) 혹은 GUI 모델(210) 중 어느 하나에 예상치 못한 행위가 있었거나 혹은 변경이 발생되었을 수 있다. 불일치들(discrepancies), 흥미로운 특징들(interesting features), 혹은 에러들(errors)이 검출되었을 때는 언제나 테스트 엔진 (202)은 그 이유들을 기록하고 이벤트의 심각성에 따라 작업을 중단시킬 수 있다.

이러한 기술은 자동화된 테스팅을 즉시 시작되게 하여 GUI (204)가 테스팅 을 위해 이용가능하게 해주고, 약간의 제한조건들(some restrictions)이 있는 상태에서, GUI (204)가 완성되기 전에 테스팅을 시작할 수 있게 한다. 만일 GUI (204)가 심각하게 변경되었다 하더라도, GUI 모델(210)은 아주 작은 노력으로 짧은 시간 내에 다시 생성될 수 있다.

GUI 모델(210)은 테스팅 동안 확인될 수 있는 링크들을 클릭킹 하는 것에 관한 액션들(actions)을 위해서 HTML 규칙들과 같은 빌트인 행위(some built-in behavior)를 포함할 수 있다. GUI 모델(210)은 글로벌화(globalization), 접근성(accessibility), 스타일(style), 국제 및 기업 표준들의 준수(conformance with international and company standards), 등과 같은 특별한 상황(particular aspects)을 위해 확인될 수 있다. GUI 모델(210)의 상황들은 메시지들, 테스트들, 컨트롤 이름들의 목록들(lists of control names) 등과 같은 검사(inspection)를 위해서 출력될 수 있다.

GUI 모델(210)을 형성하려면 테스트 엔진 (202)이 테스트 중인 GUI (204)의 모든 패널들을 방문하는 것이 필요하다. GUI 모델(210)이, 일부 컨트롤들이 깨어진 상태일 수 있는, 부분적으로 구축된 GUI (204)에 대해서도 완전하다는 것을 보증하는 것은 어렵다. 테스팅이 매우 중요한 때인, 개발의 초기 단계들에 크게 혹은 급격히 변화하는 GUI(204)를 위해서 GUI 모델 (204)을 반복적으로 재형성하는 것은 시간 소모적이 될 수 있다.

GUI 모델(210)을 형성하도록 설계된 형성 규칙들 (212)을 GUI (204)를 조사하고 테스트하는 테스트 규칙들(222)과 함께 실행되도록 허용하면, GUI 모델(210) 은 GUI가 테스트 중이라도 동적으로 형성될 수 있다. 테스트 규칙들(222)은 그들의 요구된 컨트롤들이 동작을 시작하는(act on) 것을 발견하면 동작한다. 형성 규칙들(212)은 빈 패널(an empty panel) 혹은 새 컨트롤이 발견되면 언제든지 동작한다. 이전에 발견된 패널이 다시 발견되면, 형성 규칙들 (212)은 테스트 중인 그 패널의 변경에 대해서 확인하고, GUI 모델(210)을 갱신하며, 그리고 나서 모든 변경 내용을 보고할 수 있다.

테스팅이 시작될 때 GUI 모델(210)은 비어있다. GUI 모델(210)은 컨트롤들과 페이지들이 발견됨에 따라 테스팅 동안 동적으로 형성된다. GUI 모델(210)을 메모리 내에 형성하는(populate) 형성 규칙들 (212)은 어느 때라도 임의로 선택될 수 있을 때 동작을 시작한다. 형성 규칙들 (212)는 현재 디스플레이된 GUI 패널에 관한 정보를 판독하고 그 패널 컨텐츠를 표시하기 위해, 컨텐츠를 GUI 모델(210)에 추가한다. 특정 컨트롤들(specific controls)에 관하여 동작을 개시하는 테스트 규칙들 (222)은 전술한 형성규칙들 (212)이 실행되고 난 후에라야 활성화된다. 왜냐하면 이들은 자신들이 선택되도록 하기 위해서는 발견된 컨트롤들에 의존하기 때문이다.

GUI 모델(210)이 링크들과 컨트롤들을 사용함에 따라, 테스팅 동안, 형성 규칙들(212)은 임의로 선택되거나 혹은 GUI 모델(210)의 현재 부분(currently part)이 아닌 패널들의 발견에 의해서 시작될(triggered) 수 있다. 따라서, 새로운 패널들의 표시는 이들이 방문 되고 알려진 패널들이 주기적으로 확인됨에 따라 GUI 모델(210)에 추가된다. 제 3도를 참조하면, 플로 다이어 그램(300)은 GUI 내의 컨트 롤을 위하여 테스트 규칙들과 형성 규칙들을 실행하는 방법을 보여준다.

테스트는 단계 (301)에서 시작되고, 단계(302)에서 임의로 선택된 테스트 규칙이 테스트 중인 GUI 및 GUI 모델에 적용된다. 단계(303)에서 상기 테스트 규칙이 적용될 컨트롤이 GUI 모델 내에서 발견되는 지를 결정한다. 상기 컨트롤이 발견되지 않으면, 형성 규칙이 단계 (304)에서 실행되고 상기 컨트롤은 GUI 모델 내에 추가된다. 그 다음 테스트 규칙을 다시 시도하기 위해 루프 (306)를 통해 단계 (302)로 복귀한다.

만일 상기 컨트롤이 발견되면, 단계(307)에서 상기 컨트롤이 변경되었는지를 결정한다. 상기 컨트롤이 변경되었다면, 형성 규칙이 단계 (304)에서 실행되고 상기 컨트롤은 GUI 모델 내에서 수정된다. 그 다음 테스트 규칙을 다시 시도하기 위해 루프(306)를 통해 단계 (302)로 복귀한다.

만일 상기 컨트롤이 변경되지 않았다면, 단계 (308)에서 상기 테스트 규칙이 GUI 및 GUI 모델에 관하여 수행된다. 단계(309)에서 상기 컨트롤이 정확하게 실행되었는지 결정한다. 만일 정확하게 실행되지 않았다면, 단계 (310)에서 보고서가 생성된다. 만일 상기 컨트롤이 정확하게 실행되었다면, 그 다음은 다른 테스트 규칙을 적용하기 위해 루프(311)를 통해 복귀한다.

GUI 모델 내 컨트롤들의 수집

GUI에서 일반 사용자들이 알고 있는 액션들은 일반적으로 컨트롤들의 수집활동에 관여한다. 이들 액션들은 단순히 엔트리필드를 포함하는 라벨들(labels)일 수 도 있고, 혹은 체크박스(checkbox) 및 하이퍼링크(hyperlink)를 포함하는 테이블 로우(table row)에서와 같은 여러 컨트롤들의 더 복잡한 컬렉션일 수도 있다.

종래의 테스트 툴들은 보통 사용자에게는 의미 없는 이름들을 갖고 있는 위젯들의 관점에서 그들의 맵들(maps)을 기록한다. 이들은 재생(replay) 동안 컨트롤을 발견하기 위해서 전체 페이지 계층구조로부터 속성들의 조합들을 보통 사용한다. 이 때문에 문제의 컨트롤의 검출이 페이지의 다른 콤포넨츠 내의 작은 변화들에 대하여 민감하게 된다.

만일 GUI 모델이 오직 개별 컨트롤들 및 필드들의 관점에서만 동작을 한다면, 여러 컨트롤들에 걸칠 수 있는 효과들을 검출하거나 예측하는 것이 가능하지 않게 된다. 만일 이것이 사실이면, 그 모델은 어떤 컨트롤들이 수집의 일부로서 출현하거나 사라질 때(예를 들어, 테이블 로우(a table row)가 삭제되었을 때), 실패할 수 있으며, 그리고 그 모델은 이러한 행위(this behavior)를 기대하지 않게 된다.

패널에서 컨트롤들의 컬렉션들(nested collections)을 자동적으로 확인함으로서, GUI 모델이 컨트롤 컬렉션들에 의해서 표시된 객체들(objects)을 위한 GUI액션들을 정확히 표시하도록 하는 것이 가능하게 된다.

GUI 모델의 컨트롤 계층구조 내 객체 타입들(object types)의 모든 반복된 시퀀스들 및 모든 명시된 패턴들을 확인함으로써 컨트롤 컬렉션들(control collections)을 인지하는 것이 가능하다. 전체 GUI 모델에 걸쳐 패턴들을 인지하는 것이 가능하다 할지라도 컬렉션들은 통상적으로 하나의 페이지를 차지한다(span).

패턴을 인지하면, 그 패턴은 와일드 카드 형식의 템플릿(a template in a wildcarded form)로 저장될 수 있다. 이 경우 라벨들 및 이름들 같은 구체적 속성들은 무시되고 컨트롤들의 인지에 필요한 최소한의 정보만 저장된다.

GUI 모델에서 패턴 접근 방식을 사용하는 것의 장점은 유지(maintenance)가 대단히 단순하게 되어, 패턴들을 단순히 유지하거나 추가하는 단계로 구성된다. 이는 전체 혹은 부분 페이지 컨텐츠의 맵들 보다 훨씬 더 짧고 더 간단하다. 또한, 패턴들이 빌드들(builds), 릴리스들(releases) 및 프로젝트들(projects) 사이에서 다시 사용될 수 있다. 예를 들어 , 라벨이 붙은 엔트리필드를 위한 패턴은 여러 다른 GUI페이지 들상의 엔트리필드들로 적용될 수 있다.

컨트롤들의 패턴들 혹은 컬렉션들은 테스트들이 실행되는 동안 동적으로 검출된다. 패턴들의 충분한 컬렉션이 빌트업(built up)되면, 테스트 중인 GUI에 대한 변경들에도 불구하고 테스트들은 계속 실행될 좋은 기회를 갖게 된다. 테스트 중인 페이지들에서 검출되지 않은 패턴들은 아무런 문제를 일으키지 않으며, 테스팅에서 검출은 되었으나 사용되지 않은 패턴들에 대해서도 비슷하다.

패턴들은 더 추상적 수준들(more abstract levels)의 계층구조에서 빌트업 될 수 있다. 따라서, 하나의 완전한 페이지는 엔트리필드 등 및 ‘Add’라 불리우는 버튼(a button)을 포함한다면, 새로운 레코드를 생성하기 위한 데이터 엔트리 페이지를 표시하는 것으로 인식될 수 있다. 다른 예에서, 하나의 페이지는 트위스트들(twists)(링크들의 목록들을 확장하거나 혹은 축소하기 위한 아이콘들)과 링크들을 포함하면, 네비게이션 프레임으로 인식될 수 있다. 일단 추상화의 이러한 수 준에서(at this level of abstraction)작업이 진행되면, 일반 목적의 GUI 모델들이 작성될 수 있고 테스트 스크립트들이 많은 수의 페이지들 혹은 제품들에 적용될 수 있다.

실패한 스크립트들을 사용자가 디버그할 수 있도록 로우 위젯들(row widgets)과 나란히 ‘컬렉션-컨트롤들’을 프린트하거나 디스플레이하는 것은 유용할 수 있다. 또한 페이지 컨텐츠를 비교하기 위해서 ‘컬렉션-컨트롤들’만을 사용하는 것도 유용하다. 왜냐하면 이들은 변경에 대하여 더 보호될 수 있기 때문이다.

비지빌리티 플래그들(visibility flags)

GUI 모델은 페이지 상에 직접적으로 실제 존재하는 ‘실제(real)’ 컨트롤들과 페이지 상에 실제 발생되지는 않지만 테스트 스크립트들 및 참조하는 데이터 모델 규칙들에 유용한 ‘파생(derived)’ 컨트롤들(테이블 로우들(table rows), 라벨이 붙은 엔트리필드들(labeled entryfields) 등) 양자 모두 포함하는 것이 필요하다. 이를 달성하는 한가지 방법은 모든 컨트롤들을 GUI 모델에 추가하되, 페이지 상에 발생하는 것을 실제 발견하도록 기대하는 컨트롤들이 어떤 것인지 그리고 이용 가능할 때 실제 컨트롤들보다 우선하여 사용할 컨트롤들이 어떤 것인 지를 알려주는 것을 확실히 가능하도록 ‘파생’ 컨트롤들에 표시하는 것이다.

GUI를 테스트할 때 컨트롤들의 작은 서브세트(a small subset)만 어떤 한 시기에(at any one time) 볼 수 있다. GUI 모델이, 동작을 시작할 수 있는(to act on) 이용 가능한 컨트롤들이 어떤 것인지를 모델 규칙들이 결정할 수 있도록, 테스 트 중인 GUI 상에서 현재 볼 수 있는 컨트롤들의 동일 세트(the same set)로 항상 복귀하는 것과, 테스트 중인 GUI 내의 변경들을 검출하기 위해 사용될 수 있는 것은 중요하다.

이 정보들을 추적하는 것은 어려울 수 있다. 왜냐하면 많은 수의 컨트롤들이 존재할 수 있고 그들의 상태가 테스팅 동안 계속적으로 변화되기 때문이다.

모델에서, 통상적으로 컨트롤을 표시하는 각 소프트웨어 객체(object)에서 각 컨트롤에 대하여 플래그를 사용하여, 위젯이 보여지는지를 기록하고 표시하는 것이 가능하다.

GUI 모델은 보여질 것이 현재 기대되는 컨트롤들의 세트를 생성하도록 요구되었을 때 ‘비지블’ 플래그가 현재(currently) 세트된 컨트롤들만 리턴(return)시킨다.

실제 GUI 에서 각 컨트롤은 컨트롤들 ‘비지빌리티’를 표시하는 플래그를 포함하는 GUI 모델의 소프트웨어에 의해서 표시된다. 링크 등을 사용하여 네비게이션을 하는 동안 일어나는 GUI 모델의 페이지 컨텐츠에 포함된 모든 위젯들의 플래그들의 세팅은 그 페이지가 ‘비지블(visible)’ 혹은 ‘인비지블(invisible)’이 되도록 한다. 하이퍼링크들(hyperlinks), 버튼들(buttons) 등을 사용하는 동작들은 컨트롤들의 관련 컬렉션들을 위한 플래그들을 세트 하는데, 실제 컨트롤들이 GUI의 다른 엘리멘트들을 비지블(visible) 혹은 인비즈블(invisible), 하게 하는 것, 즉 링크를 클릭킹 하는 것이 현재 페이지의 컨텐츠를 인비지블로 하고 다른 페이지의 컨텐츠를 비즈블로 하는 것과 동일한 방법으로 한다.

테스트 액션들이 GUI 모델로부터 비지블 컨트롤을 요구할 때 ‘비지블’을 표시하기 위해 세트된 플래그를 갖는 것들만 리턴 된다. 이와 같은 방법으로, GUI 모델은 실제 GUI와 마찬가지로 모든 컨텐츠의 동일 서브세트를 항상 리턴 시킨다.

위젯 클래스들

GUI의 모델을 형성할 때, 모델이 되는 컨트롤들의 많은 특징들은 동일하다. GUI 모델을 만드는 것은 큰 프로그램이 요구될 수 있고, 그래서 에러가 발생하기 쉽다. 컨트롤들을 기술하는 데 필요한 소프트웨어를 최소화 하기 위해, 일반 목적의 위젯 타입(general purpose widget type)이 정의될 수 있고 그리고 나서 개별 컨트롤 타입들의 속성들을 포함하기 위해 확장될 수 있다.

GUI 컨트롤들의 일반 속성들을 갖는 위젯의 템플릿(a template) 혹은 클래스가 만들어진다. 이것은 그 다음에 개별 컨트롤 타입의 세부내용(specifics)을 추가하도록 확장된다. 하나의 예로서 위젯 클래스는 이름, 비지빌리티 플래그, 퍼미션들(permissions), ‘클릭’ 방법 등을 포함할 수 있다. 구체적 컨트롤들은 이들 속성들을 가질 수 있고 이에 더하여 하이퍼링크들에 의한 페이지들의 로딩 혹은 엔트리 필드들에 데이터를 입력하는 것과 같은 구체적인 컨트롤 행위(some control specific behavior)를 가질 수 있다.

따라서, 컨트롤들은 최소한의 코딩을 사용하여 모델이 만들어질 수 있다. 이렇게 함으로서 GUI 모델의 작성과 그 후의 GUI 모델의 유지관리의 문제들을 최소화 할 수 있다.

데이터 모델 테스트 규칙들

자동화된 테스팅이 실행될 때는 언제나 액션들 및 데이터의 동일 시퀀스들을 방문한다. 테스팅, 특히 GUI 테스팅의 대부분의 형식들(most forms)에 대하여, 테스트들이 발견하기를 바라는 문제들은 액션들의 시퀀스들과 데이터의 변동들(variations)과 관련되어 있다. 이들 문제들은 종래의 기록된 GUI 테스트들을 재 실행하는 것에 의해서는 통상적으로 발견되지는 않는다. 데이터 중심의 자동화된 테스트들(data driven automated tests)의 성능은 약간 더 나아질 뿐이다(only slightly better). 이러한 타입의 테스팅의 잇점과 대비한 비용의 효과는 그와 같이 제한된 효과 때문에 별로없다(marginal).

이상적으로, 테스트 툴은 다수의 사용자들과 비슷한 행위를 발생시켜야 한다. 즉, 시퀀스, 데이터, 및 상태 관련 문제들(state related problems)을 검출해야 한다. 임의로 선택된 규칙들, 임의적 원자 액션들을 취하는 것(즉, 링크들, 버튼들 등을 클릭하는 것), 그리고 시나리오들(예를 들어, 퍼블리시(publish) 혹은 삭제 동작(delete operation))을 실행하는 것의 혼합을 사용함으로써, 테스팅은 실제 사용자들의 행동을 에뮤레이트(emulate)할 수 있다. 이것과 임의로 발생된 데이터를 조합 함으로서 테스팅은 실제 사용자들의 액션과 비슷하게 될 수 있다.

데이터 모델 테스트 규칙들은 원자적 액션들을 만들어 내는 어떤 것과 특정 시나리오들을 표시하는 시퀀스들을 만들어 내는 어떤 것으로 구성된다. 이 시퀀스들은 원자적 액션들의 목록들로부터 형성될(built up) 수 있다. 동작 동안 이 데이 터 모델은 임의로 규칙들을 선택한다.

시나리오들을 위한 규칙들은 ‘원자적(atomic)’이 되거나, 즉 새로운 규칙이 실행되기 전에 완료되어야 하거나, 혹은 ‘비 원자적(non-atomic)’, 즉 시퀀스 내의 다양한 점들에서 인터럽트 될 수 있다. 원자적 접근은 구체적 혹은 긴 시나리오들이 완료되는 것을 확실히 하는데 유용하다. 인터럽트가 가능한 시나리오들은 사용자들이 통상적으로 잘못된 버튼을 클릭하거나 부분적으로 완료된 동작을 취소하는 결정을 할 수 있기 때문에 더 현실적인 행위(more realistic behavior)를 만들어 낼 수 있다.

개별 컨트롤들과 관련된 규칙들의 선택은 컨트롤의 이용 가능성에 의존하도록 만들어진다. 따라서 ‘적용(apply)’버튼을 클릭하는 규칙은 적용버튼을 포함하는 패널이 GUI에 표면화될 때까지 선택되지 않을 것이다.

규칙들의 시퀀스들을 위해, 규칙을 선택하는 방법은 세 가지가 있다 :

a) 규칙에 의해서 요구된 모든 컨트롤들을 현재 ‘표면화(surfaced)’되게, 즉 현재 패널 상에서 보이게 하는 경우이다. 이 경우는 새로운 패널들로 진행(navigate)하지 않은, 혹은 테스트 된 패널 상에 새로운 컨텐츠를 생성하는 시퀀스들에 대해서만 유용하다.

b) 시퀀스의 각 단계 전에 요구된 컨트롤이 시작되었는 지를 조사함(checking)에 의한 경우이다. 이 경우는 동적이다. 즉, GUI의 다수의 패널들에 걸친 단계들의 시퀀스를 계속할 수 있고 더욱이 다른 규칙들 혹은 액션들에 의해서 발견되거나 표면화될 수 있는 시퀀스 내의 다음 컨트롤의 출현을 기다릴 수 있다.

c) 시퀀스가 실제 GUI 내에서 완료될 수 있을지를 결정하기 위해 모델 내의 동작을 미리 테스팅 함에 의한 경우이다. 이 경우는 여러 패널들에 걸쳐있는 테스트 시퀀스들을 위해서 더 유용하고 GUI 모델이 적어도 부분적으로 완료되어 있을 때만 적용한다

본 발명은 전부 하드웨어로 실시될 수도 있고, 전부 소프트웨어로 실시될 수도 있으며, 혹은 하드웨어와 소프트웨어 요소들을 모두 포함하여 실시될 수도 있다. 본 발명의 바람직한 한 실시 예에서, 본 발명은 소프트웨어로 구현되는데, 이 소프트웨어는 펌웨어, 상주 소프트웨어, 마이크로 코드 등을 포함할 수 있지만, 여기에 한정하는 것은 아니다.

본 발명은 컴퓨터 프로그램 제품의 형태로도 실시될 수 있다. 이 컴퓨터 프로그램 제품은 컴퓨터 이용 가능한 혹은 컴퓨터 판독 가능한 매체로부터 접근될 수 있다. 이 매체는 컴퓨터 혹은 어떠한 명령 실행 시스템에 의한 혹은 관련한 사용을 위한 프로그램 코드를 제공한다. 본 발명의 상세한 설명의 목적을 위하여, 컴퓨터 사용 가능한 혹은 판독 가능한 매체는 명령실행 시스템, 장치, 혹은 디바이스에 의한 혹은 관련한 사용을 위한 프로그램을 포함, 저장, 통신, 전송 혹은 전달할 수 있는 어떠한 장치일 수 있다.

매체는 전자, 자기, 광, 전자기, 적외선, 혹은 반도체 시스템(혹은 장치 혹은 디바이스) 혹은 전달(propagation)매체 일 수 있다. 컴퓨터 판독 가능 매체의 예들로는 반도체 혹은 고체 상태 메모리, 자기 테이프, 착탈 가능 컴퓨터 디스켓, RAM, ROM, 강성 마그네틱 디스크(a rigid magnetic disk) 및 광 디스크 등이 있다. 광디스크들의 현재 예들에는 CD-ROM, CD-R/W 및 DVD가 있다.

본 발명의 범위를 벗어남이 없이 위에서 설명한 내용에 대하여 개선과 변경을 하는 것이 가능하다.

Claims

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법에서,

테스트 중인 GUI (204)에 테스트 단계를 적용하는 단계 ;

테스트 단계를 적용할 테스트 중인 GUI(204)에서 컨트롤을 발견하는 단계 ;및

새로운 컨트롤이 발견됨에 따라 테스트 중인 GUI (204)의 컨텐츠의 모델(210)을 동적으로 형성하는 단계를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법.
제 1항에서, 종속적인 컨트롤들의 컬렉션을 발견하는 단계와 컨트롤들의 상기 컬렉션을 상기 모델(210)에 표시하는 단계를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법.
제 2항에서, 상기 컨트롤들의 일반화된 패턴(generalized pattern)으로서 컨트롤들의 컬렉션을 상기 모델(210)에 표시하는 단계를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법.
제 1항 내지 제 3항 중 어느 한 항에서, GUI (204)의 컨텐츠의 모델(210)에 테스트 단계를 적용하는 단계 ;

테스트 중인 GUI(204) 및 모델(210)으로부터 나온 테스트 단계의 결과들을 비교하는 단계를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법
제 4항에서, 테스트 단계를 상기 모델(210)에 적용하는 단계가 테스트 단계가 적용될 컨트롤의 표시를 상기 모델(210)에 제공되지 않도록 결정한다면, 상기 컨트롤의 표시를 상기 모델(210)에 추가하기 위하여 형성 규칙(212)를 실행하는 단계를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법.
상기 항들 중 어느 하나에서, 테스트 중인 GUI (204)에서 발견된 컨트롤들 및 테스트 중인 GUI (204)에서 발견되지 않는 가상의 컨트롤들의 표시들(254, 255)을 상기 모델(210)에 제공하는 단계를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법.
제 6항에서, 상기 모델(210) 내의 컨트롤 (254) 및 가상 컨트롤(255)의 표시들을 위한 컨텐츠 데이터를 형성하고 유지하는 단계를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법
제 6항 또는 제 7항에서, 테스트 중인 GUI(204) 내에서 발견된 컨트롤들 (254)의 표시들을 가상 컨트롤들 (255)와 구별하기 위하여 비지빌리티 플래그를 제공하는 단계를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법.
상기 항들 중 어느 한 항에서, 상기 모델(210) 에 컨트롤의 표시가 개별 컨트롤의 속성들을 포함하기 위해 확장된 컨트롤의 클래스(a class) 형태로 되는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법.
상기 항들 중 어느 한 항에서, GUI (204)의 실제 사용자의 행위를 에뮬레이트 하기 위해 다수의 테스트 규칙들(222)를 발생시키는 단계를 포함하되, 상기 테스트 규칙들(222)는 새로운 규칙이 시작되기 전에 완료되어야 하는 임의로 선택된 원자적 액션들 및 인트럽트 될 수 있는 비원자적 액션들을 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 방법.
그래픽 사용자 인터페이스(GUI) 테스팅을 위한 시스템에서,

테스트 중인 GUI(204)에 테스트 단계를 적용하기 위한 테스트 엔진(202) ;

새로운 컨트롤이 테스트 중인 GUI (204) 내에서 발견됨에 따라 테스트 중인 GUI (204)의 컨텐츠의 모델(210)을 동적으로 형성하기 위한 수단을 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 시스템
제 11항에서, 테스트 엔진 (202)는 테스트 단계를 상기 모델(210)에 적용하고 테스트 중인 GUI (204) 및 상기 모델(210)으로부터 나온 테스트 단계의 결과들을 비교하는 수단을 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 시스템
제 11항 또는 제 12항에서, 상기 모델(210)을 동적으로 형성하기 위한 수단은 테스트 단계가 적용될 컨트롤의 표시가 상기 모델(210) 에 제공되지 않았다고 테스트 단계가 결정을 내리면 실행되는 형성 규칙들 (212)를 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 시스템
제 11항 내지 제 13항 중 어느 한 항에서, GUI (204)의 실제 사용자의 행위를 에뮬레이트 하기 위해 다수의 테스트 규칙들(222)를 발생시키는 수단을 포함하되, 상기 테스트 규칙들(222)는 새로운 규칙이 시작하기 전에 완료되어야 할 임의로 선택된 원자적 액션들 및 인트럽트 될 수 있는 비 원자적 액션들을 포함하는

그래픽 사용자 인터페이스(GUI) 테스팅을 위한 시스템
테스트 중인 그래픽 사용자 인터페이스(GUI)의 모델(210)에서,

테스트 중인 GUI (204)에서 발견된 컨트롤들(254)의 표시들 ; 및

테스트 중인 GUI (204)내에서는 발견되지 않지만 상기 모델(210)에 구조(structure)를 제공하는 가상 컨트롤들(255)의 표시들을 포함하는

테스트 중인 그래픽 사용자 인터페이스(GUI)의 모델(210)
제 15항에서, 상기 모델(210)에 컨트롤들의 일반화된 패턴으로서 컨트롤들의 컬렉션을 상기 모델(210)에 표시하는 것을 포함하는

테스트 중인 그래픽 사용자 인터페이스(GUI)의 모델(210)
제 15항 또는 제 16항에서, 컨트롤들의 상기 표시들은 테스트 중인 GUI (204)에서 발견된 컨트롤들의 표시들을 상기 가상 컨트롤들과 구별하기 위해 비지빌리티 플래그를 포함하는

테스트 중인 그래픽 사용자 인터페이스(GUI)의 모델(210)
제 15항 내지 제 17항 중 어느 한 항에서, 상기 모델(210)에 컨트롤의 표시는 개별 컨트롤의 속성들을 포함하기 위해 확장된 컨트롤의 클래스 형태로 되는

테스트 중인 그래픽 사용자 인터페이스(GUI)의 모델(210)
컴퓨터 판독 가능 저장 매체에 저장된 컴퓨터 프로그램 제품에서,

테스트 단계를 테스트 중인 GUI (204)에 적용하는 단계 ;

상기 테스트 단계가 적용될 테스트 중인 GUI (204)에 컨트롤을 발견하는 단계 ;

새로운 컨트롤이 발견됨에 따라 테스트 중인 GUI (204)의 컨텐츠의 모 델(210)을 동적으로 형성하는 단계 ; 및

테스트 중인 GUI (204)의 상기 컨트롤들을 상기 모델(210)에 표시하는 단계들을 수행하기 위한 컴퓨터 판독 가능 프로그램 코드 수단을 포함하는

컴퓨터 판독 가능 저장 매체 상에 저장된 컴퓨터 프로그램 제품.