KR20060050387A

KR20060050387A - 자동화된 테스트 케이스 실행에 대하여 약하게 결합되는자동화된 테스트 케이스 검증

Info

Publication number: KR20060050387A
Application number: KR1020050073367A
Authority: KR
Inventors: 아담 엠. 울리치; 마이클 디. 갈라처; 마이클 제이 헌터
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-09-29
Filing date: 2005-08-10
Publication date: 2006-05-19
Also published as: EP1650664A3; RU2390826C2; AU2005203492B2; JP4961123B2; EP1650664A2; JP2006099742A; AU2005203492A1; US20060075303A1; CN100507870C; BRPI0503443A; US7823132B2; CA2517036A1; CN1755646A; KR101122852B1; RU2005126693A; MXPA05009207A

Abstract

어플리케이션에 적용되는 액션의 시스템적인 결과를 검증하고 어플리케이션의 예상 상태를 언제라도 또는 요구시 제공하기 위한 시스템 및 방법으로서, 검증 매니저는 어플리케이션의 예상 어플리케이션 상태와 현재 어플리케이션 상태를 결정하고, 검증 매니저와 통신 상태에 있는 테스트 케이스는 액션을 실행하며, 검증 매니저는 예상 어플리케이션 상태와 현재 어플리케이션 상태를 비교한다.

테스트 케이스, 개발 설계 프로세스, 프로그램 테스트, 검증 매니저

Description

자동화된 테스트 케이스 실행에 대하여 약하게 결합되는 자동화된 테스트 케이스 검증{AUTOMATED TEST CASE VERIFICATION THAT IS LOOSELY COUPLED WITH RESPECT TO AUTOMATED TEST CASE EXECUTION}

도 1은 테스트 케이스 실행에 대하여 약하게 결합되는 테스트 케이스의 양태(aspect)들이 구현되는 컴퓨팅 환경의 예를 도시한 블록도.

도 2는 본 발명의 일 실시예에 따라 테스트 케이스 실행과 약하게 결합된 테스트 케이스 검증을 위한 시스템의 블록도.

도 3A-3B는 본 발명의 일 실시예에 따라 테스트 케이스 실행에 대하여 약하게 결합되는 테스트 케이스 검증을 위한 방법의 흐름도.

도 4는 본 발명의 다른 실시예에 따라 테스트 케이스 실행에 대하여 약하게 결합되는 테스트 케이스 검증을 위한 시스템의 블록도.

<도면의 주요 부호에 대한 간단한 설명>

36 : 예상 상태

35 : 비교기

37 : 현재 상태

32 : 예상 상태 발생기

30 : 검증 매니저

20 : 테스트 케이스

10 : 어플리케이션

31 : 데이터베이스

본 발명은 어플리케이션을 테스트하기 위한 소프트웨어에 관한 것으로, 특히 그러한 테스트 소프트웨어에서 예상 결과와 실제 결과의 약하게 결합되는 비교에 관한 것이다.

소프트웨어 개발의 생명 주기에서 주요한 단계는 설계 국면, 코딩 국면, 코드 완료 국면, 알파 국면, 베타 국면, 및 최종적으로 시장 배포이다. 설계 국면 동안에, 소프트웨어 제품의 고객 문제가 제기되고 소프트웨어 제품의 기능이 정의된다. 일반적으로, 기능적 스펙의 완료는 설계 국면의 종료를 나타낸다. 코딩 국면은 이미 시작되었을 수도 있다. 코드 완료 국면은 코드가 저작되었지만 반드시 디버깅될 필요가 없는 때에 도달된다. 알파 국면은 제품이 안정되어 있는 때, 즉 대부분의 주요한 버그들이 발견된 시점을 나타낸다. 베타 국면에서, 제품이 이상적으로는 모든 주요한 버그가 없고, 단지 남아있는 버그는 실질적으로 해가 없는 것이어야 한다. 제품이 최종 품질 확인 체크 리스트를 통과할 때, 시장에 배포될 준비가 된다.

아무도 동작하지 않는 소프트웨어를 원하지 않으므로, 테스팅은 생명 주기의 중요한 부분으로서, 수 개의 양태에 걸칠 수 있다. 소프트웨어 테스트는 테스트 케이스(또는, 더 가능성있게는 테스트 케이스의 세트)를 고안하고, 입력으로서 테스트 케이스를 가지는 소프트웨어를 운영하며, 입력으로서 테스트 케이스를 가지는 소프트웨어의 성능이 예상된 결과를 산출하는지를 체크하는 것을 포함한다. 소프트웨어 테스팅은 인간에 의해 수동으로 수행될 수도 있으며, 또는 자동화된 소프트웨어 테스팅이라 하는 프로그램 방식으로 수행될 수도 있다. 이상적으로는, 소프트웨어의 테스팅은 소프트웨어의 생명 주기에서 가능한 한 빨리 시작해야 한다. 그러나, 일반적으로는, 설계 국면이 완료될 때까지는 예상 결과가 결정될 수 없으므로, 소프트웨어는 설계 국면이 완료될 때까지는 전혀 테스트 될 수 없다. 통상, 코딩 국면 동안에, 개발자는 그 코드를 저작하면서 그 코드를 수동으로 테스트한다. 자동화된 소프트웨어 테스팅은 통상 개발 프로세스에서 훨씬 더 늦게까지 시작할 수 없다.

종종, 수행되는 유일한 테스팅은 개발자가 코딩하면서 수동으로 테스트하는 개발자에 의해 수행된다. 그러나, 그 자신의 작업을 테스트하는 개발자는 코드에 그다지 열정적으로 관여하지 않은 일부 사람들이 찾는 버그를 무시할 가능성이 있다. 또한, 개발자의 테스팅의 범주는 통상 그 코드의 기능, 및 제한된 개수의 다른 소프트웨어 어플리케이션과 그 코드의 통합으로 제한된다.

이들 단점에 대처하기 위해, 다수의 소프트웨어 개발 회사는 종종 적어도 부분적으로는 자동화된 테스팅 기술을 이용하여 소프트웨어를 테스트하는 분리된 소프트웨어 테스팅 그룹을 가지고 있다. 통상, 테스팅 그룹은 테스트 케이스를 저작 하고 운용함으로써 특징 및 어플리케이션에 걸친 복잡한 상호작용들을 테스트한다. 일반적으로, 제품 생명주기에서 테스팅 그룹을 일찍, 심지어는 설계 국면과 같이 일찍 관여시키는 것은, 기능적 세부사양(specification)의 불일치의 식별, 테스트-난이 영역의 식별 등을 포함하여 다수의 장점을 얻을 수 있는 것으로 알려져 있다. 그러나, 일반적으로, 특징의 정의, 구현 및 사용자 인터페이스(UI) 튜닝에 있어서의 계속되는 변화에 직면하여 각 테스트 케이스를 현재로 유지하는데 요구되는 노력은 이러한 접근법을 비실용적이 되도록 한다. 그러므로, 테스트 케이스를 저작하고 및 운용하는 것은 통상 제품 개발의 마지막에서 발생하는 다급한 문제이다. 테스팅 및 특히, 자동화된 테스팅은 영원히 시간적으로 뒤처지는 경향이 있다. 소프트웨어 제품의 생명 주기에서 가능한 한 빨리, 이상적으로는 설계 국면 동안에, 테스트 케이스를 저작하고 자동화된 테스팅을 채용하는 방법이 있다면 도움이 될 것이다.

한 벌의 테스트 케이스의 개발은 그것이 발생할 때마다 일종의 도전이다. 어플리케이션의 특정 특징을 테스트하기 위해서는, 다수의 테스트 세트가 저작되어야 한다. 예를 들면, 어플리케이션은 마우스, 키보드, 디지타이저, 액세스가능 소프트웨어를 통해, 또한, 프로그램적으로, 특징과의 다수의 상호작용 모드들을 허용한다. 그러므로, 특징에 대한 광범위한 테스트를 제공하기 위해, 한 벌의 테스트는, 마우스를 통해(사용자처럼 텍스트를 타이핑하는 것) 특징과 상호작용하는 테스트 세트, 키보드를 통해 특징과 상호작용하는 하나의 세트, 디지타이저를 통해 특징과 상호작용하는 하나의 세트, 디폴트 액션을 유발하고 다르게는 액세스가능 어 플리케이션(accessibility application)을 흉내내는, 액세스가능 소프트웨어를 통해 특징과 상호작용하는 하나의 세트, 어플리케이션의 코딩 모델을 통해 특징과 상호작용하는 하나의 세트, 등을 포함한다. 생성된 한 벌의 테스트 케이스가 특징 또는 어플리케이션의 광범위한 테스트를 제공했던 것을 확인하고 또한 그 광범위한 테스트를 제공하기 위해 저작되어야 하는 전체 테스트 케이스의 개수를 감소하는 방법이 있다면 도움이 될 것이다.

또한, 이들 각 테스트 세트 각각에서 로직의 다수 또는 모두는 다른 테스트 세트의 로직과 동일하고, 통상 결과 처리의 검증의 다수 또는 모두 또한 동일하다. 그러므로, 다수의 테스트는 동일하거나, 매우 거의 동일하고, 단지 실행 옵션을 변화시킨다. 예를 들면, 전술한 모든 복수 형태의 입력에 대하여, 예상된 결과는 거의 동일하다. 그러므로, 이들 입력 소스 각각에 대한 테스트 케이스를 저작하는 것은, 통상 각 입력 소스에 대한 테스트를 실행하기 위한 분리된 방법을 저작하고, 나머지 테스트 스크립트의 대부분을 복사하는 것을 필요로 한다. 사소한 변동을 가지는 동일한 테스트를 반복적으로 저작하는 것은 지루하고 시간 소비되는 일이다. 이러한 중복적인 코딩을 제거하거나 상당히 감소시키며, 저작되어야 하는 테스트 케이스의 전체 개수를 줄이는 방법이 있다면 도움이 될 것이다.

테스트 케이스를 운용하는 실제 결과가 예상 결과와 일치하는지를 판정하기 위해(결과 검증 또는 검증이라 불림) 저작되는 코드는 종종 테스트 케이스 내에 포함된다. 특정 결과 검증의 세부 사항을 변경하거나 새로운 결과 검증을 추가하는 것은, 통상 각 테스트 케이스의 변형을 필요로 한다. 검증 코드가 테스트 케이스 와 분리되어 있고, 테스트 케이스가 이해되기 더 용이하도록 하며, 검증 코드가 재사용하고 유지하는 것이 더 용이하게 한다면 도움이 될 것이다.

실행 세부사항은 테스트 케이스에 하드-코딩되어, 설계 국면이 테스트 케이스가 저작되기 이전에 완료되는 것을 필요로 한다. 테스트 케이스가 소프트웨어 개발 생명 주기에서 더 일찍 저작될 수 있도록 특정 실행 세부사항의 측면에서 보다는 사용자 액션의 측면에서 테스트 케이스를 정의하는 방법이 있다면 도움이 될 것이다. 어플리케이션을 테스트하는 것은 어플리케이션의 초기 개발에서 중대한 단계이다. 어플리케이션에 변형을 구현할 때도 어플리케이션을 테스트하는 것은 매우 중요하다. 개발자, 과학자, 제조자 등은 테스트 국면에 많은 노력을 기울인다. 그러한 테스트는 어플리케이션이 특정 자극에 예상되는 방식으로 반응하는 것을 보장하는데 도움을 준다. 테스팅은 통상 테스트 결과의 실행 및 테스트 케이스 실행의 결과의 검증을 통해 완성된다.

테스트 케이스는 통상 자극을 어플리케이션에 가한다. 테스트 케이스는 또한 어플리케이션이 예상되는 방식으로 응답했는지 및 예상하지 않은 방식으로 응답하지 않았는지를 검증해야 한다. 이해를 위해, 테스트는 전체 어플리케이션 상태의 많은 부분을 검증하여, 자극이 예상된 결과를 유발했고 예상치 않은 결과를 유발하지 않았다는 것을 보장해야 한다.

테스트 케이스는 통상 어플리케이션의 특정한 기능 또는 양태를 테스트하는 목적으로 실행된다. 마찬가지로, 테스트 케이스의 결과의 검증은 테스트 되려는 기능에 촛점을 둔다. 그러나, 테스트 케이스의 실행은 어플리케이션 상태의 다른 양태에 영향을 미치거나 변경할 수 있다. 그러한 양태는 테스트 케이스의 목적에 벗어나는 것으로 보일 수 있다. 이들 벗어난 양태는 다수일 수 있으며, 테스트 케이스를 개발하는 테스터가 이들의 전부 또는 심지어 대부분을 수량화 하거나 지정하는 것은 어려울 수 있다.

어플리케이션 상태의 많은 부분을 검증하는 테스트 케이스 코드를 저작하는 것은 다양한 이유로 인해 문제가 있는 것으로 증명되었다. 비교적 단순한 어플리케이션에 대해서도, 어플리케이션을 광범위하게 테스트하기 위해서는 광대한 개수의 테스트 케이스가 요구된다. 길고 상세한 검증 코드를 각 테스트 케이스에 추가하는 것은, 불가능한 태스크는 아니더라도, 위압적이 될 것이다. 또한, 테스트 케이스의 유지보수는 통상 테스트 케이스 생성만큼(이것보다 크지는 않음) 노동-집약적이고 시간 소모적인 것이다. 어플리케이션이 변경되는 경우, 검증 코드뿐만 아니라 테스트 케이스도 변경되어 어플리케이션과 계속되는 호환성을 보장하여야 한다. 각 테스트 케이스에 길고, 광범위한 검증 코딩을 추가하는 것은 가능할지라도, 그러한 유지보수가 실용적이지 못하도록 한다.

그러므로, 방대하고, 지루하며, 시간 소모적인 검증 코드가 각 테스트 케이스에 저작될 것을 필요로 하지 않고, 어플리케이션에 적용되는 테스트 케이스의 결과를 광범위하게 검증할 필요가 있다. 셋업, 실행, 및 유지 보수를 위해 최소한의 명확한 조치를 필요로 하는 검증에 대한 필요성이 또한 존재한다.

테스트 케이스 구현의 검증은 테스트 케이스와 분리된 전용의 검증 매니저(verification manager)에 의해 완료될 수 있다. 테스트 케이스는 어떠한 검증도 포함할 필요는 없으며, 실제로 테스터는 수행되고 있는 모든 검증을 알 필요조차도 없다. 검증 매니저는, 각 테스트 케이스가 액션 결과의 특정한 검증을 제공하지 않고 액션을 실행할 수 있도록, 하나 이상의 테스트 케이스를 검증하는데 이용될 수 있다.

전용의 검증 매니저에 있어서, 검증이 더 광범위할 수도 있다. 검증 매니저는 예상 상태 발생기의 큰 라이브러리를 이용하여 테스트 케이스의 결과를 더 광범위하게 검증할 수 있다. 라이브러리에 포함된 각각의 예상 상태 발생기는 어플리케이션의 다양한 별도의 상이한 구성요소들에 촛점을 둘 수 있다. 하나의 예상 상태 발생기는, 테스터가 테스트 케이스의 목적에 특히 관련되어 있는 것으로 간주하는 어플리케이션의 양태에 촛점을 둘 수도 있다. 제2 예상 상태 발생기는 테스터가 테스트 케이스의 목적에 벗어나 있거나 관련이 없는 것으로 간주하는 어플리케이션의 양태에 촛점을 둘 수도 있다. 그러므로, 테스트 케이스 내에 포함된 검증에 촛점을 두는 대신, 라이브러리는 모든 테스트 케이스에 대하여 광범위한 검증을 가능하게 한다.

검증 매니저는 지정된 어플리케이션 속성의 예상 값과 이들 동일한 속성의 실제 값을 비교함으로써 테스트 케이스 결과를 검증할 수도 있다. 이러한 비교를 수행할 때, 검증 매니저는 현재 어플리케이션 상태 및 예상 어플리케이션 상태가 실질적으로 정렬되지 않는 인스턴스를 결정할 수 있을 것이다. 결국, 검증 매니저 는 임의의 테스트 실패에 대하여 테스트 케이스, 테스트 케이스 실행자, 또는 임의의 다른 지정된 실체에 통신할 수도 있다.

검증 프로세스는, 테스트 케이스가 예컨대 그래픽 어플리케이션을 호출하여 청색 직사각형을 그릴 때 파일 메뉴 상의 버튼 상태가 검증되어 있는 상태를, 심지어 알지 못하도록 하여 완료될 수도 있다. 이러한 광범위한 검증을 얻을 때, 테스터에게는 적절한 파라미터를 가지는 액션을 실행하는 것 이외에 어떠한 액션도 필요하지 않다.

또한, 검증이 업데이트 되거나 변경되는 경우에 테스트 케이스의 유지보수는 최소화되거나 제거된다. 예를 들면, 어플리케이션이 업데이트되거나 변경되는 경우, 검증 매니저 또는 예상 상태 발생기는 마찬가지로 어플리케이션의 계속되는 일치를 보장하도록 개정(revision)을 필요로 한다. 검증이 테스트 케이스와 분리되어 있으므로, 테스크 케이스는 어떠한 유지보수도 필요로 하지 않는다.

또한, 테스트 케이스가 어플리케이션의 특정 컴포넌트의 실패를 가져오는 경우, 동일한 실패의 통지를 연속적으로 수신하지 않고 추가 테스트 케이스가 실행될 수 있다. 이러한 능력은 실패를 고려하여, 어플리케이션을 계속 테스트할 기회를 제공한다.

예시된 실시예에 대한 이하의 상세한 설명뿐만 아니라, 상기 요약 내용은 첨부된 도면을 참조하여 읽을 때 더 잘 이해된다. 본 발명을 예시할 목적으로, 본 발명의 예로 든 구성이 도면에 도시되어 있다. 그러나, 본 발명은 개시된 특정 방법 및 수단으로 제한되지 않는다.

<실시예>

개요

본 발명의 실시예에서, 검증 프로세스는 테스트 케이스와 분리된다. 예상 상태 발생기라고 하는 각각의 검증 요소(element)는 검증 매니저라고 하는 전용의 디바이스에 저장될 수도 있다. 각각의 검증 프로세스를 개별적인 테스트 케이스와 분리시킴으로써, 각 테스트 케이스는 각 테스트 케이스에서 검증 코드를 복사할 필요없이 더욱 종합적으로 검증될 수 있다. 또한, 검증 매니저는 각각이 서로 독립적으로 동작하고 각각이 어플리케이션의 하나 이상의 컴포넌트의 예상된 상태를 계산하는 다수의 예상 상태 발생기를 포함할 수도 있다. 검증은 오프라인으로, 즉 테스트 케이스 실행 및/또는 온라인 이외의 시간에, 또는 테스트 실행 동안에 완료될 수도 있다.

예상 상태 발생기는 로컬 검증 프레임워크에 내장되거나, 런타임에 다이나믹하게 로딩되어 인에이블되고 디스에이블되는 개별적인 오브젝트일 수도 있다. 그러한 예상 상태 발생기는 데이터베이스 또는 네트워크 로케이션으로부터 로딩될 수도 있다. 실질적으로, 예상 상태 발생기는 검증 프레임워크에 플러그-인 될 수도 있다.

검증을 개별적인 테스트 케이스로부터 분리하는 것은 어플리케이션의 더 광범위한 테스팅을 가능하게 한다. 또한, 전용의 검증 매니저를 가지는 것은 검증 코드가 각 테스트 케이스에 포함되는 것을 요구하지 않고 검증되도록 한다. 검증 코드가 각 테스트 케이스에 포함되지 않으므로, 검증 알고리즘이 어플리케이션의 변형에 대응하여 변경되는 경우, 그러한 변경은 테스트 케이스에 영향을 미치지 않는다. 그러므로, 검증을 테스트 케이스와 분리하는 것은 테스트 케이스에 대한 요구되는 유지보수를 감소시킬 수도 있다.

컴퓨팅 환경의 예

도 1 및 이하의 설명은 본 발명의 실시예가 구현될 수 있는 적절한 컴퓨팅 환경의 간단한 일반적인 설명을 제공하려는 것이다. 그러나, 핸드헬드 컴퓨팅 디바이스, 휴대용 컴퓨팅 디바이스 및 모든 종류의 다른 컴퓨팅 디바이스가 본 발명과 관련한 사용을 위해 상정될 수 있다는 것은 자명하다. 일반 목적 컴퓨터가 이하에 설명되어 있지만, 이것은 단지 하나의 예에 불과하다. 본 발명은 네트워크 서버 상호운용성 및 상호작용을 가지는 씬 클라이언트(thin client) 상에서 동작가능할 수도 있다. 그러므로, 본 발명의 실시예는 매우 적거나 최소의 클라이언트 리소스가 관련되는 네트워킹되고 호스팅되는 서비스의 환경, 예를 들면, 클라이언트 디바이스가 월드 와이드 웹에 대한 브라우저 또는 인터페이스로만 기능하는 네트워킹된 환경에서 구현될 수 있다.

반드시 요구되지는 않지만, 본 발명은 개발자 또는 테스터에 의해 이용하기 위해 어플리케이션 프로그래밍 인터페이스(API)를 통해 구현되거나, 하나 이상의 컴퓨터(예를 들면, 클라이언트 워크스테이션, 서버 또는 다른 디바이스)에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터-실행가능 명령의 일반적인 컨텍스트로 기재되는 네트워크 브라우징 소프트웨어 내에 포함될 수도 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정의 추상적인 데이터 타입을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트(component), 데이터 구조 등을 포함한다. 통상, 프로그램 모듈의 기능은 다양한 실시예에서 원하는 대로 조합되거나 분산될 수 있다. 또한, 본 기술분야의 숙련자라면 본 발명이 다른 컴퓨터 시스템 구성으로 실시될 수 있다는 것을 잘 알고 있을 것이다. 본 발명으로 이용하기에 적합한 다른 공지된 컴퓨팅 시스템, 환경, 및/또는 구성으로는, 퍼스널 컴퓨터(PC), 자동 현금 입출금 장치, 서버 컴퓨터, 핸드헬드 또는 랩탑 디바이스, 멀티-프로세서 시스템, 마이크로프로세서-기반 시스템, 프로그램가능한 소비자 전자장치, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 등을 포함하고, 이들로 제한되지 않는다. 본 발명의 실시예는 태스크들이 통신 네트워크 또는 다른 데이터 송신 매체를 통해 링크되는 원격 처리 디바이스에 의해 수행되는 분산 컴퓨팅 환경에서도 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 디바이스를 포함하는 로컬 및 원격 컴퓨터 저장 매체 모두에 배치될 수 있다.

따라서, 도 1은 상기 명백하게 된 바와 같이, 컴퓨팅 시스템 환경(100)이 단지 적절한 컴퓨팅 환경의 하나의 예에 불과하고 본 발명의 이용이나 기능의 범주에 관해 어떠한 제한을 암시하려고 하는 것은 아니지만, 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템 환경(100)의 예를 예시하고 있다. 컴퓨팅 환경(100)은 예로 든 오퍼레이팅 환경(100)에 예시된 컴포넌트의 임의의 하나 또는 조합에 관련하여 어떠한 의존성 또는 요구조건을 가지고 있는 것으로서 해석되어서는 안 된다.

도 1을 참조하면, 본 발명을 구현하기 위한 시스템 예는 컴퓨터(110) 형태의 범용 컴퓨팅 디바이스를 포함한다. 컴퓨터(110)의 컴포넌트는 처리 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 처리 유닛(120)에 결합시키는 시스템 버스(121)를 포함하며, 이에 한하지 않는다. 시스템 버스(121)는 메모리 버스 또는 메모리 컨트롤러, 주변장치 버스, 및 다양한 버스 아키텍쳐들 중 임의의 것을 이용하는 로컬 버스를 포함하는 수 개의 타입의 버스 구조 중 하나가 될 수 있다. 예를 들어, 그러한 아키텍쳐는 ISA 버스, MCA 버스, EISA 버스, VESA 로컬 버스, 메자닌(Mezzanine) 버스로도 알려진 PCI 버스를 포함하며, 이에 한하지 않는다.

컴퓨터(110)는 통상 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 가용한 매체가 될 수 있고, 휘발성 및 비휘발성 매체, 소거형 및 비소거형 매체를 모두 포함한다. 예를 들어, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함하며, 이에 한하지 않는다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보 저장을 위한 임의의 방법이나 기술로 구현되는 휘발성 및 비휘발성, 소거형 및 비소거형 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 다른 자기 저장장치 디바이스, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 임의의 다른 매체를 포함하며, 이에 한하지 않는다. 통신 매체는 통상 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터를 반송파와 같은 변조 데이터 신호 또는 다른 전송 메카니즘으로 실시하고, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 정보를 신호로 인코딩하는 것과 같은 방식으로 설정되거나 변경되는 하나 이상의 특징을 구비하는 신호를 의미한다. 예를 들면, 통신 매체는 유선 네트워크 또는 직접-유선 접속과 같은 유선 매체 및 음향, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함하며, 이에 한하지 않는다. 상기의 임의의 조합도 컴퓨터 판독가능한 매체의 범주내에 든다.

시스템 메모리(130)는 ROM(131) 및 RAM(132)와 같은 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 기동중(during start-up)과 같이 컴퓨터(110) 내의 요소간의 정보 전달을 도와주는 기본 루틴을 포함하는 기본 입출력 시스템(133, BIOS)은 통상 ROM(131)에 저장된다. RAM(132)은 통상 처리 유닛(120)에 즉시 액세스 가능하거나 이것에 의해 현재 동작되고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 예를 들면, 도 1은 오퍼레이팅 시스템(134), 어플리케이션 프로그램(135), 다른 프로그램 모듈(136) 및 프로그램 데이터(137)를 포함하고, 이들로 제한되지는 않는다. RAM(132)은 다른 데이터 및/또는 프로그램 모듈을 포함한다.

컴퓨터(110)는 다른 소거형/비소거형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예로서, 도 1은 비소거형 비휘발성 자기 매체에 기록하거나 판독하는 하드 디스크 드라이브(141), 소거형 비휘발성 자기 디스크(152)에 기록하거나 판독하는 자기 디스크 드라이브(151), 및 CD ROM 또는 다른 광학 매체와 같은 소거형 비휘발성 광 디스크(156)에 기록하거나 판독하는 광 디스크 드라이브(155) 를 나타낸다. 예로 든 오퍼레이팅 환경에서 이용될 수 있는 다른 소거형/비소거형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM, 등을 포함하며, 이에 한하지 않는다. 하드 디스크 드라이브(141)는 통상 인터페이스(140)와 같은 비소거형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 통상 인터페이스(150)와 같이 소거형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

전술한 도 1에 예시된 드라이브 및 관련 컴퓨터 저장 매체는 컴퓨터(110)에 대해 컴퓨터 판독가능한 명령, 데이터 구조, 프로그램, 모듈 및 데이터의 저장을 제공한다. 도 1에서, 예를 들면, 하드 디스크 드라이브(141)는 오퍼레이팅 시스템(144), 어플리케이션 프로그램(145), 다른 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로서 도시되어 있다. 이 때, 이들 컴포넌트들은 오퍼레이팅 시스템(134), 어플리케이션 프로그램(135), 다른 프로그램 모듈(136) 및 프로그램 데이터(137)와 동일하거나 또는 상이할 수도 있다. 오퍼레이팅 시스템(144), 어플리케이션 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 다른 복제물이라는 것을 나타내도록 다른 숫자가 주어진다. 사용자는 키보드(162), 마이크로폰(163), 및 통상 마우스, 트랙볼 또는 터치 패드로 지칭되는 포인팅 디바이스(161)와 같은 입력 디바이스를 통해 컴퓨터(110)에 명령과 정보를 입력한다. 다른 입력 디바이스(도시 생략)는 마이크로폰, 조이스틱, 게임 패드, 새털라이트 디쉬(satellite dish), 스캐너 등을 포함할 수 있다. 이들 및 다 른 입력 디바이스들은 시스템 버스(121)에 결합되는 사용자 입력 인터페이스(160)를 통해 처리 유닛(120a-f)에 종종 접속되고, 병렬 포트, 게임 포트 또는 범용 직렬 버스(USB)와 같은 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다.

모니터(191) 또는 다른 타입의 디스플레이 디바이스는 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터(191)뿐만 아니라, 컴퓨터는 출력 주변장치 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196)와 같은 다른 주변장치 출력 디바이스를 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워킹 된 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 디바이스 또는 기타의 공통 네트워크 노드일 수 있고, 단지 메모리 저장 디바이스(181)만이 도 1에 예시되어 있지만, 통상 퍼스널 컴퓨터(110)와 관련하여 상기 설명한 구성요소들 중 다수 또는 모두를 포함한다. 도 1에 도시된 논리적 접속은 로컬 영역 네트워크(LAN, 71) 및 와이드 영역 네트워크(WAN, 173)를 포함하지만, 다른 네트워크/버스를 포함할 수도 있다. 그러한 네트워킹 환경은 사무실, 기업-와이드 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.

LAN 네트워킹 환경에서 이용되는 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워킹 환경에서 이용되는 경우, 컴퓨터(110)는 통상 모뎀(172) 또는 인터넷과 같이 WAN(173)을 통한 통신을 확립하기 위한 다른 수단을 포함한다. 내부 또는 외부에 존재하는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 다른 적절한 메커니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워킹된 환경에서, 컴퓨터(110)에 관련하여 도시된 프로그램 모듈, 또는 그 일부는 원격 메모리 저장 디바이스에 저장될 수 있다. 예로서, 도 1은 메모리 디바이스(181) 상에 상주하는 것으로서 원격 어플리케이션 프로그램(185)을 예시하고 있다. 도시된 네트워크 접속은 예로 든 것이며 컴퓨터들 간의 통신 링크를 확립하는 다른 수단이 이용될 수 있다는 것은 자명하다.

당업자라면, 컴퓨터(110) 또는 다른 클라이언트 디바이스는 컴퓨터 네트워크의 일부로서 채용될 수 있다는 것을 이해할 수 있을 것이다. 이러한 측면에서, 본 발명은 임의의 개수의 메모리 또는 저장 유닛, 및 임의의 개수의 저장 유닛 또는 볼륨에 걸쳐 발생하는 임의의 개수의 어플리케이션 및 프로세스와 관련된다. 본 발명의 실시예는 원격 또는 로컬 저장장치를 가지는, 네트워크 환경에 채용되는 서버 컴퓨터 및 클라이언트 컴퓨터를 가지는 환경에 적용할 수도 있다. 본 발명은 프로그래밍 언어 기능, 해석 및 실행 성능을 가지는 단독 컴퓨팅 디바이스에 적용될 수도 있다.

테스트 케이스 실행에 대하여 약하게 결합되는 테스트케이스 검증을 위한 시스템 및 방법

도 2는 본 발명의 일 실시예에 따른 테스트 케이스 실행에 대하여 약하게 결합되는 테스트 케이스 검증을 위한 테스트 검증 시스템(1)의 블록도이다. 시스템(1)은 도 1과 관련하여 상기한 바와 같은 컴퓨터(110)일 수 있는 컴퓨터 상에 상주한다. 시스템(1)은 이하, 즉 검증 매니저(30), 테스트 케이스(20), 비교기(35), 예상되는 어플리케이션 상태 데이터 구조(36), 현재 어플리케이션 상태 데이터 구조(37), 및 데이터베이스(31) 중 하나 이상을 포함할 수 있다. 시스템은 테스트되는 어플리케이션(10)을 포함한다. 어플리케이션(10)은 임의의 프로세스, 머신, 제조 또는 물질의의 조합, 및 그 개량물 일 수 있다. 어플리케이션(10)은 임의의 프로그램, 소프트웨어, 하드웨어, 디바이스, 메커니즘 또는 재료(material), 또는 임의의 그 개량물일 수 있다. 예를 들면, 어플리케이션(10)은 임의의 컴퓨팅 시스템 상에서 운용되는 소프트웨어 프로그램일 수 있다. 또한, 예를 들면, 어플리케이션(10)은 디바이스가 문 손잡이의 강도, 복원력, 또는 동작성을 테스트하기 위해 문 손잡이를 망치로 두드리는 문 테스팅 메커니즘, 문 손잡이가 부착되는 문, 문에 부착된 힌지, 힌지가 부착되는 문 프레임, 등일 수 있다. 어플리케이션(10)은 최초로 개발중인 것, 이전 어플리케이션의 업데이트된 버전, 엔드 사용자가 일부 방식으로 변형한 이전에-배포된 어플리케이션, 등일 수 있다.

어플리케이션(10)은 테스트 케이스(20a, b, c, ..., f, 등)로 도 2에 나타낸 바와 같이, 하나 이상의 테스트 케이스에 의해 테스트된다. 테스트 케이스(20a-f)는 통합 또는 기능적 테스팅을 위해 호출된다. 통합 테스팅은 2개 이상의 상호작동 컴포넌트가 연계하여, 함께 작동하며 서로에게 영향을 주는 방식을 테스트한다. 기능적 테스팅에서, 테스트 케이스는 테스트 케이스의 특정 기능적 행태에 촛점을 둔다.

일반적으로, 각 테스트 케이스(20a-f)는 어플리케이션(10)에 적용될 잘-정의된 파라미터를 가지는 잘-정의된 조치를 포함한다. 테스트 케이스(20a-f) 각각은 어플리케이션(10)에 의해 실행되는 하나 이상의 단계를 포함한다. 각 테스트 케이스(20a-f)는 어플리케이션(10)에 적용되는 하나 또는 일련의 테스트들 일 수도 있다. 테스트 케이스(20a-f)는 예를 들면, C, C#, C++, 파스칼, 객체-지향 언어 등과 같은 임의의 적절한 프로그래밍 언어로 저작될 수 있다. 테스트 케이스(20a-f) 또는 테스트 케이스(20a-f)의 조합은 예를 들면, 그래픽 어플리케이션이 다양한 색상의 다른 형태를 포함하는 문서 상에 청색 직사각형을 묘화하도록 호출한다. 테스트 케이스(20a-f)는 컴퓨터 프로그래밍 언어와 무관할 수 있다. 예를 들면, 테스트 케이스(20a)는 문에 부착된 문 손잡이에 4 피트 위 및 30도 각도로 걸린 10파운드 망치(maul)의 수동 해제를 요구한다. 그래픽 어플리케이션, 문 손잡이 어플리케이션, 및 본 명세서 전체에 걸쳐 제공된 임의의 다른 예는 출원서의 청구 범위를 전혀 제한하지 않으며, 단시 이해를 용이하게 하도록 기재된 예시적 실시예에 불과하다는 것은 자명하다.

도 2에 도시된 테스트 케이스(20a-f)는 어플리케이션(10)의 다른 양태를 테스트 할 수도 있다. 테스트 케이스(20a-f)는 단지 잠재적인 테스트 케이스를 나타내며, 어플리케이션(10)을 테스트하는데 임의의 개수의 테스트 케이스(20a-f)가 있을 수 있다. 또한, 각 테스트 케이스(20a-f)는 동시에 또는 다른 시간에 실행될 수 있다. 또한, 예를 들면 테스트 케이스(20a)는 테스트 케이스(20e)가 10회 운용되는 동안에 1회 실행될 수도 있다. 또한, 테스트 케이스(20a-f)는 테스터에 의해 실행될 수도 있다. 다른 실시예에서, 테스트 케이스는 테스트 케이스 실행자 또는 유사한 디바이스에 의해 실행될 수도 있다.

본 발명의 일 실시예에서, 테스트 케이스(20a-f)는 검증 매니저(30)와 직접 통신될 수도 있다. 본 발명의 다른 실시예에서, 테스트 케이스(20a-f)는 검증 매니저(30)와 통신하는 다른 서브루틴을 호출할 수도 있다. 테스트 케이스(20a-f)는 검증이 완료되는 방법을 모를 수도 있다. 예를 들면, 다수의 테스트 케이스(20a-f)가 청색 직사각형을 필요로 하는 경우, 청색 직사각형을 묘화하는 서브 루틴이 저작될 수 있다. 이러한 서브루틴은 검증 매니저(30)와 통신할 수 있다. 이러한 서브루틴을 이용하는 테스트 케이스(20a-f)는 서브루틴이 청색 직사각형을 묘화하는 것을 알 수도 있지만, 반드시 서브루틴이 검증 매니저(30)와 통신하고 있다는 것을 알 필요는 없을 수도 있다.

검증 매니저(30)는 예상 상태 발생기(32t-z), 비교기(35), 및 예상되는 어플리케이션 상태 및 현재 어플리케이션 상태 데이터 구조(36, 37)를 포함한다. 각 예상 상태 발생기(32t, u, ..., z, 등)와 같은 예상 상태 발생기는 하나 이상의 특정 컴포넌트, 데이터 포인트, 또는 속성과 연관된다. 예를 들면, 테스트 케이스(20a-f)의 하나, 일부 또는 모두가 어플리케이션(10)이 특정 위치에 청색 직사각형을 묘화하도록 요구하는 그래픽 어플리케이션을 테스팅하는 것과 관련하여, 예상 상태 발생기(32t-z)는 어플리케이션 상태의 다른 컴포넌트(component)에 촛점을 둘 수도 있다. 예상 상태 발생기(32t)는 직사각형의 색상에 촛점에 촛점을 둘 수도 있다. 예상 상태 발생기(32u)는 직사각형의 위치에 촛점을 둘 수도 있다. 예상 상태 발생기(32v)는 새롭게 묘화된 청색 직사각형과 동일한 문서 상에서 삼각형의 위치와 같이, 테스트 케이스(20a-f)의 운용으로부터의 다소 불명확한 결과에 촛점 을 둘 수도 있다. 다르게는, 예상 상태 발생기(32u, 32v)는 문서 상의 모든 형태의 위치와 관련된 하나의 예상 상태 발생기(도시되지 않음)와 조합되거나, 이것으로 대체될 수 있다. 예상 상태 발생기(32w)는 새로운 문서를 열라는 옵션과 같이, 툴 바상의 관련없는 옵션의 상태(status)에 촛점을 둘 수도 있다.

또한, 예를 들면, 테스트 케이스(20a-f)가 망치로 문 손잡이를 때림으로써 문(door)에 부착된 문 손잡이(doorknob)를 개별적으로 또는 집합적으로 테스트하는 경우, 예상 상태 발생기(32t)는 문 손잡이의 회전 능력에 촛점을 둘 수도 있다. 예상 상태 발생기(32u, 32v)는 문에 부착된 상부 및 하부 힌지에 촛점을 두거나, 힌지의 상태에 관한 단일의 예상 상태 발생기(도시 생략)에 조합되거나 이것으로 대체될 수 있다. 예상 상태 발생기(32w)는 문 손잡이를 둘러싸는 문의 나무 부분에 촛점을 둘 수도 있다. 다른 예상 상태 발생기는 어플리케이션(10)의 다른 영역에 촛점을 둘 수도 있다.

모든 예상 상태 발생기(32t-z)는 하나 이상의 테스트 케이스(20a-f)가 어플리케이션(10)에 적용되거나 예상 상태 발생기(32t-z) 중 단지 하나 또는 일부가 호출되는 경우에 호출될 수 있다. 일 실시예에서, 예상 상태 발생기(32t-z)는 테스트 케이스(20a-f)와 무관하게 운용되고 따라서 약하게 결합된다. 이와 같이, 테스트 케이스(20a-f)는 검증 매니저에게 테스트 케이스(20a-f)의 어플리케이션 동안에 어느 예상 상태 발생기(32t-z)가 호출되어야 하는지를 지정할 필요가 없다. 그러면, 테스트 케이스(20a-f)는 검증 메커니즘을 포함하지 않을 수 있다. 실제, 테스트 케이스(20a-f)는 임의의 검증이 발생했는지를 인식하지 못할 수도 있다. 검증 매니저(30)는 테스트 케이스(20a-f)의 결과를 검증하는 책임을 가지고 있고, 테스트 케이스(20a-f)의 목적은 어플리케이션(10)에 특정 파라미터를 가지는 자극을 가하는 것으로 제한될 수도 있다.

그러나, 당업자라면, 테스트 케이스는 실시예와 일치하여, 검증 코딩을 포함할 수 있다는 것을 이해할 수 있을 것이다. 이것은 테스트 케이스(20a-f)를 운용하는 목적이 특정 문제가 수정되었는지를 결정하는 경우에 특히 적용될 수 있다. 다른 실시예에서, 테스트 케이스(20a-f)는 호출될 하나 이상의 예상 상태 발생기(32t-z)를 지정하거나, 특정의 다른 예상 상태 발생기(32t-z)가 이용되지 않도록 지정할 수 있다.

테스트 케이스(20a-f)로부터 검증의 분리로, 테스트 케이스(20a-f)에 대한 검증이 더 광범위하게 될 수도 있다. 검증 매니저(30)는 이전에 개별적인 테스트 케이스의 일부였던 예상 상태 발생기(32t-z)를 포함할 수도 있다. 예를 들면, 검증 매니저(30)는 청색 정사각형, 적색 원, 황색 삼각형, 또는 타원을 묘화하고, 풀-다운 메뉴 상의 옵션을 이용하며, 마우스 또는 키보드의 이용을 통해 다양한 사용자 입력에 대응하는 등 그래픽 어플리케이션의 능력을 테스트하도록 설계된 종래 기술에 따른 테스트 케이스(20a-f)의 예상 상태 발생기(32t-z)를 포함할 수도 있다. 이들 테스트 케이스 각각은 테스트 케이스의 액션의 목적에 촛점을 둔 특정 검증을 포함할 것이다. 예상 상태 발생기(32)를 포함하는 전용의 검증 매니저(30)에 있어서, 그래픽 어플리케이션에서 청색 직사각형을 묘화하기 위한 테스트 케이스(20a-f)는 더 광범위하게 검증될 수 있다. 검증 매니저(30)는 청색 직사각형, 적색 정사각형, 황색 삼각형, 풀-다운 메뉴, 마우스 및 키보드에 의한 입력, 등에 특정되는 예상 상태 발생기(32)를 요구할 수도 있다. 청색 직사각형을 묘화하기 위해 요구되는 테스트 케이스(20a-f)는 예상 상태 발생기(32t-z)를 호출하여 어플리케이션(10)에 대한 테스트 케이스(20a-f)의 명백한 영향 및 그렇게 명백하지 못한 영향을 체크할 수도 있다. 테스터는 예를 들면, 청색 직사각형이 묘화된 경우에 적색 원이 검증되고 있다는 것을 알지 못할 수도 있다. 테스트 결과가 적색 원이 테스트 케이스(20a-f)에 의해 영향을 받지 않은 상태로 유지되고 이것이 예상된 결과였던 것이 사실인 경우, 테스터 및/또는 테스트 케이스는 적색 원이 검증되었다는 것을 알지 못할 수도 있다. 그러나, 적색 원이 예상치 않게 약간 이동한다면, 검증 매니저(30)는 테스터에게 예상하지 않은 결과가 발생했다고 경고할 수 있다.

마찬가지로, 테스트 케이스(20a-f)가 망치로 문에 달린 문 손잡이를 때리는 것에 관한 것인 경우, 검증 프로세스는 문 손잡이 상에 대한 테스트 결과뿐만 아니라, 문, 문 프레임, 힌지 등에 대한 테스트 결과도 포함할 수도 있다.

또한, 테스트 케이스(20a-f)의 검증은 어플리케이션(10)이 변경되고, 업데이트되는 등의 경우 크게 영향을 받지 않을 수도 있다. 어플리케이션(10)이 동작하는 방식을 변경할 수 있는 어플리케이션(10)의 새로운 버전이 생성될 수도 있다. 따라서, 테스트 케이스(20)는 변경할 필요가 있을 수도 있다. 예를 들어, 그래픽 어플리케이션을 테스트하기 위한 테스트 케이스(20a-f)는 청색 직사각형의 묘화를 위해 호출하는 방법에 있어서 개정을 필요로 할 수도 있다. 또한, 예를 들면, 문 에 달린 문 손잡이를 테스트하기 위한 테스트 케이스(20a-f)는 테스팅 될 새로운 문 손잡이가 이전 버전보다 더 큰 복원력을 가지고 있는 경우 망치의 무게와 높이를 변경할 필요가 있다. 그러나, 예상 상태 발생기(32) 각각은 변경될 필요가 없을 수도 있다. 그래픽 어플리케이션 예에서, 예상 상태 발생기(32)는 어플리케이션(10)이 변경되기 전과 동일한 방식으로 새로운 청색 정사각형 및 기존의 적색 원, 황색 삼각형 및 타원의 위치를 계속해서 체크할 수도 있다. 마찬가지로, 예상 상태 발생기(32)는 새로운 문 손잡이가 추가되고 테스트 케이스(10)가 변경되기 전과 동일한 방식으로 문 손잡이, 문, 힌지 및 문 프레임을 검증할 수도 있다.

예상 상태 발생기(32t-z)는 검증 매니저(30)를 통해 데이터베이스(31)와 통신할 수도 있다. 데이터베이스(31)는 예상 상태 발생기가 테스트 케이스(20)로부터 어플리케이션(10)의 예상 상태를 더 잘 결정할 수 있도록 예상 상태 발생기(32)에 정보를 제공할 수도 있다. 예를 들면, 테스트 케이스(20a-f)는 망치로 문에 부착된 문 손잡이를 치는 것에 관한 것일 수도 있다. 예상 상태 발생기(32a)는 문에 부착된 1/8인치 두께이고 2-인치 길이인 황동 힌지에 대한 테스트 케이스의 영향을 결정한다. 이를 행함에 있어서, 예상 상태 발생기(32a)는 데이터베이스(31)에 질의하여, 예를 들면, 황동의 인장강도에 관한 정보를 검색할 수도 있다. 다른 실시예에서, 각 예상 상태 발생기(32)는 검증 매니저(30)와 무관하게, 하나 이상의 데이터베이스(31)와 통신 상태에 있을 수도 있다. 다르게는, 각 예상 상태 발생기(32)는 연결될 수 있는 컴포넌트(pluggable component)으로부터 정보를 검색하거나 수신할 수도 있다.

예상 상태 발생기(32t-z)는 비교기(35)와 통신 상태에 있을 수도 있다. 도 2에 도시된 바와 같이, 비교기(35)는 검증 매니저(30)의 일부일 수도 있다. 그러나, 당업자라면, 비교기(35)는 검증 매니저 외부에 배치될 수 있다는 것을 잘 알고 있을 것이다. 이 경우, 비교기는 검증 매니저(30) 및/또는 예상 상태 발생기(32)와 통신 상태에 있을 수도 있다. 비교기(35)는 예상 상태 데이터 구조(36)와 실제 상태 데이터 구조(37)를 비교할 수도 있다.

더 구체적으로는, 하나 이상의 테스트 케이스(20a-f)가 이제 막 실행되려고 할 때, 테스트 케이스(20a-f) 또는 테스트 실행자는 검증 매니저(30)에게 통지할 수도 있다. 검증 매니저(30)는 어플리케이션의 현재의 글로벌 상태를 스냅샷(snapshot)할 수도 있다. 즉, 검증 매니저는 어플리케이션의 속성의 현재 값의 메모리에 복사본을 만들 수도 있다. 그 후, 검증 매니저(30)는 현재의 테스트 케이스(20)의 예상 상태 발생기(32)가 실행되도록 통지할 수도 있다. 일 실시예에서, 테스트 케이스(20a-f)에 관한 예상 상태 발생기(32)에게만 통지될 수도 있다. 다른 실시예에서, 모든 예상 상태 발생기(32)에 통지될 수 있다.

실행될 액션 및 액션의 파라미터, 및 현재 글로벌 상태의 검증 매니저의 스냅샷에 기초하여, 각 예상 상태 발생기(32)는 어플리케이션(10) 상에서 테스트 케이스(20a-f)의 장래 실행으로부터 어플리케이션의 컴포넌트에 관한 그 예상 출력 상태를 계산한다. 예를 들면, 어플리케이션(10)이 그래픽 어플리케이션이고, 테스트 케이스(20a-f)가 집합적으로 청색 직사각형의 묘화를 요구하는 경우, 각 예상 상태 발생기(32)는 이 액션과 관련하여 그 예상 어플리케이션 상태를 결정한다. 예상 상태 발생기(32t)는 결과가 직사각형을 포함해야 한다는 것을 결정할 수도 있다. 예상 상태 발생기(32u)는 직사각형이 청색이어야 한다는 것을 결정할 수도 있다. 예상 상태 발생기(32v)는 직사각형으로부터 떨어진 적색 원에 촛점을 두고, 그 예상 상태가 테스트 케이스(20)에 의해 변경되지 않고 유지되어야 한다고 결정할 수도 있다. 각 예상 상태 발생기는 이러한 예상 컴포넌트 상태를 검증 매니저(30)에 통신하고, 검증 매니저(30)는 데이터를 비교기(35)의 예상 어플리케이션 상태 데이터 구조(36)에 배치할 수도 있다. 이와 같이, 검증 매니저(30)는 테스트 케이스(20a-f)의 실행에 앞서서 글로벌 예상 어플리케이션 상태를 가지고 있을 수도 있다. 또한, 이것은 글로벌 예상 어플리케이션 상태가 언제라도 또는 요구시에 결정될 수도 있다는 것을 의미한다. 테스트 케이스(20a-f)의 실행으로부터의 예상 결과는 결정적(deterministric)이다. 다른 예상 결과는 비결정적 결과가 수락가능하다고 예상 상태 발생기(32t-z)가 이해한다면, 비결정적일 수도 있다.

테스트 케이스(20)의 완료시, 검증 매니저(30)는 어플리케이션의 속성의 현재 값의 메모리에 다른 스냅샷을 취하거나 복사를 할 수도 있다. 이러한 스냅샷은 어플리케이션의 현재 글로벌 상태를 보여줄 수도 있다. 속성의 현재 값은 현재의 어플리케이션 상태 데이터 구조(37)에 저장될 수도 있다. 그 후, 비교기(35)는 예상 어플리케이션 상태 데이터 구조(36)와 현재 어플리케이션 상태 데이터 구조(37)를 비교한다. 임의의 불일치는 추가 주의가 허가될 수도 있는 영역을 나타낸다. 다른 실시예에서, 데이터 구조(35, 36)는 비교를 수행하기 위한 적절한 수단에 전송될 수도 있다. 예를 들면, 비교는 XML(eXtensible Markup Language)의 이용을 통해 완료될 수도 있다.

예상 및 현재 어플리케이션 상태 데이터 구조(36, 37)간의 불일치는 테스터에게 경고하여, 결국 다른 결론으로 나타날 수도 있다. 예상 및 현재 어플리케이션 상태간의 불일치는 어플리케이션(10)이 적절한 방식으로 작용하지 않고 있는 영역을 나타낼 수도 있다. 예를 들면, 그러한 경우에, 소스 코드의 디버깅 또는 재료(material)의 구조를 변경하는 것이 요구될 수도 있다. 즉, 예를 들면, 테스트 케이스(20a-f)가 결과적으로 청색 정사각형의 묘화로 되어 있었지만, 대신에 테스트 케이스(20a-f)가 결국 적색 정사각형을 묘화하게 된 경우, 테스터는 어플리케이션(10)을 고쳐 테스트 케이스(20a-f)를 다시 실행하게 될 수도 있다. 테스터가 어플리케이션을 개발하는 사람이 아니라면, 테스터는 버그-추적 시스템에 버그를 로깅하거나, 이메일을 전송하거나, 개발자의 사무실에 걸어가거나, 또는 일부 다른 통지 시스템을 이용하여 올바르지 않은 동작(적색 사각형)을 개발자에게 통지할 수도 있다. 또한, 예를 들면, 테스트 케이스(20a-f)가 계속해서 동작하는 문 손잡이가 되기로 되었지만, 그 대신 문손잡이를 치는 망치가 문손잡이를 문에서 떨어뜨린 경우, 테스터는 더 강한 체결구(fastener)를 이용하여 문손잡이를 문에 고정시키고자 할 수도 있다. 다르게는, 테스터가 문을 제조하지 않는 경우라면, 테스터는 문 제조자에게 더 강한 체결기가 이용되도록 추천할 수도 있다.

불일치는 예상 상태 발생기(32)의 예상 어플리케이션 상태가 비현실적이었다는 것을 나타낼 수도 있다. 그러한 경우에, 예상 상태 발생기(32)로의 변경이 허가될 수도 있다. 예를 들면, 테스트 되는 어플리케이션(10)이 그래픽 어플리케이 션일 수도 있다. 하나 이상의 테스트 케이스(20a-f)는 마우스를 이용하여 직사각형을 묘화하는 것을 포함할 수도 있다. 그러면, 하나 이상의 예상 상태 발생기(32)는 완전한 직사각형이 묘화되는 것을 기대할 수도 있다. 마우스로 완전한 직사각형을 묘화하는 것이 어플리케이션(10)에서 현실적인 가능성이 없는 경우, 비교기(30)는 결과적인 직사각형의 불완전함으로 인해 테스트가 실패했다는 것을 나타낼 수도 있다. 그러면, 테스터는 적용가능한 예상 상태 발생기(32)에 한계치를 부가하여, 실질적으로 직사각형이지만 완전히 완벽하지는 않은 직사각형을 포함하는 예상 어플리케이션 상태를 허용할 수도 있다.

일 실시예에서, 예상 상태 발생기(32)는 테스트 케이스(20a-f)에 대해 요구되는 액션 및 파라미터뿐만 아니라, 현재 어플리케이션 상태에 기초하여 예상 상태를 결정할 수도 있다. 이것은 검증 메니저(30)가 이전 테스트 케이스의 실패를 고려하고, 그 실패에 기초하여 예상 상태를 결정할 수 있도록 한다. 예를 들면, 테스트 케이스(20a-f)는 문에 부착된 문 손잡이를 망치로 때리는 것에 관한 것일 수도 있다. 테스트 케이스를 실행할 때 문에 붙은 힌지가 손상된 경우, 장래의 테스트 케이스(20a-f)에 대한 힌지의 검증은 이전 손상에 기초하여 실패를 나타내지 않을 수도 있다. 그 대신, 검증 매니저(30)는 이전 손상을 고려하여, 힌지의 예상 상태를 결정할 수도 있다.

도 3a는 약하게-결합된 검증을 수행하는 방법 예의 흐름도를 도시하고 있다. 검증 방법(200)은 단계 205에서, 테스트 케이스(20a-f)로 시작할 수도 있다. 다른 실시예에서, 테스트 케이스 실행자는 시작 이벤트를 검증 매니저에게 전송하거나 검증 매니저(30)를 호출할 수도 있다. 이러한 시작 이벤트 또는 호출로부터, 검증 매니저(30)는 현재의 테스트 케이스(20)를 통지받는다. 테스트 케이스(20a-f)는 액션의 파라미터를 포함하여 어플리케이션(20a-f)에 부여될 잘-정의된 액션을 포함할 수도 있다. 통지시, 현재 글로벌 상태를 스냅샷 할 수도 있다. 단계 210에서, 검증 매니저(30)는 검증 매니저(30)는 어느 예상 상태 발생기(32)가 현재의 테스트 케이스(20a-f)에 포함되는지를 판정하여, 적용 가능한 예상 상태 발생기(32)에 통지할 수도 있다. 다르게는, 검증 매니저(30)는 계류 중인 테스트 케이스(20a-f)를 모든 예상 상태 발생기(32)에게 통지할 수도 있다. 단계 215에서, 예상 상태 발생기(32)는 테스트 케이스(20a-f)의 적용가능한 액션 및 파라미터를 검토할 것이다. 그 컴포넌트 또는 컴포넌트들의 속성의 현재 값에 기초하여, 예상 상태 발생기는 테스트 케이스(20)의 완료시 예상되는 예상 컴포넌트 상태를 계산할 수도 있다. 그 후, 각 통지된 예상 상태 발생기(32)는 그 예상 컴포넌트 상태를 검증 매니저(30)에 전송할 수도 있다. 이러한 데이터는 비교기(35)의 예상 어플리케이션 상태 데이터 구조(36)에 저장될 수도 있다. 모든 적용가능한 예상 상태 발생기(32)가 예상 컴포넌트 상태 데이터로 보고된 경우, 검증 매니저(30)는 (단계 220에서) 글로벌 예상 어플리케이션 상태를 가질 것이다. 그 후, 검증 매니저(30)는 단계 225에서 테스트 케이스(20a-f) 또는 테스트 실행자에게, 테스트 케이스(20)가 실행될 수 있다는 것을 통지할 수도 있다. 따라서, 제어가 다시 테스트 케이스(20a-f)(또는 테스트 실행자)에 되돌려진다. 단계 230에서, 테스트 케이스(20a-f)가 실행될 수도 있다.

도 3b는 도 3a의 흐름도에 이어진다. 단계 235에서, 테스트 케이스(20a-f)가 실행되고, 글로벌 스냅샷을 업데이트 할 수도 있다. 테스트 케이스(20)의 완료시, 검증 매니저(30)는 단계 240에서, 테스트 케이스(20a-f)가 완료되었다는 것을 통지받을 수도 있다. 단계 245에서, 검증 매니저(30)는 현재 어플리케이션 상태의 스냅샷을 취할 수도 있다. 이러한 스냅샷은 어플리케이션에 대한 테스트 케이스의 실제 결과를 반영할 수도 있다. 이러한 스냅샷은 어플리케이션의 속성의 값을 나타낼 수도 있다. 검증 매니저(30)는 단계 250에서, 스냅샷을 현재 어플리케이션 상태 데이터 구조(37)에 저장할 수도 있다. 그 후, 검증 매니저(30)는 단계 255에서, 예상 어플리케이션 상태 데이터와 현재 어플리케이션 상태 데이터를 비교하고, 단계 260에서, 전체 비교 결과 또는 속성의 예상 및 현재 값이 실질적으로 동일하지 않은 임의의 결과들을 보고할 수도 있다. 본 발명의 다른 실시예에서, 예상 및 현재 상태의 스냅샷은 테스트 케이스의 운용 동안에 완료될 수도 있다. 즉, 단계 210 내지 260의 모두 또는 일부는 테스트 케이스 내에서 복수회 실행될 수도 있다.

예상 상태 데이터 구조(36)와 현재 상태 데이터 구조(37)의 비교는 검증 매니저(30)내에서 완료될 수도 있다. 다르게는, 데이터 구조는 비교가 XML로 완료되도록 XML로 나열(serialize out)될 수도 있다. 그러한 경우에, XML은 데이터 구조(36, 37)를 비교하고, 결과를 검증 매니저(30), 테스트 케이스(20) 또는 테스트 실행자에게 보낼 수도 있다. 본 발명의 다른 실시예에서, 비교기(35)는 테스트 케이스 실행 과정에서 분리될 수도 있다. 이러한 분리는 예상 및 현재 어플리케이션 상태간의 비교가 테스트 케이스 실행과 무관한 시간에 완료될 수 있게 한다. 그러 한 이벤트에서, 예상 및 현재 상태 데이터는 데이터베이스 또는 다른 데이터 저장소에 저장되거나, 컴퓨터 메모리에 저장될 수도 있다.

본 발명의 일 실시예에서, 검증 매니저(30)는 개별적인 검증의 결과를 통지하거나, 예상 및 현재 어플리케이션 상태 데이터가 다른 인스턴스에만(즉, 오류가 있었던 경우) 통지할 수도 있다. 통지는 테스트 케이스가 실행하는 것을 종료한 후 일부 시간이 지나서 발생하고, 테스트 케이스와 완전히 무관한 경로를 지날 수도 있다. 예를 들면, 비교기(35)는 검증 결과를 지정된 연락처(contact)에 이메일로 보낼 수도 있다.

동일한 테스트 케이스(20a-f)가 다시 실행되는 경우 또는 다른 테스트 케이스(20a-f)가 실행되는 경우, 도 3a-3b에 도시된 방법(200)의 모든 단계들이 요구되지 않을 수도 있다. 예를 들면, 검증 매니저(30)는 비교기(35)에 계류 중인 테스트 케이스(20)를 위한 예상 상태 데이터 구조를 포함할 수도 있다. 그렇다면, 검증 매니저(30)는 테스트 케이스(20a-f)가 실행되기에 앞서서, 예상 상태 발생기(32)로부터 예상 컴포넌트 상태 데이터를 획득할 필요가 없을 수도 있다. 그러므로, 방법(200)의 모든 단계들이 테스트 케이스(20a-f)가 실행될 때마다 완료될 필요는 없다.

도 4는 본 발명의 대체 실시예에 따라 테스트 케이스에 대하여 약하게 결합되는 테스트 케이스 검증에 대한 시스템 예의 블록도이다. 이러한 대체 실시예에서, 하나 이상의 테스트 케이스(20a-f)가 어플리케이션(10)에 적용될 수도 있다. 전술한 바와 같이, 테스트 케이스(20a-f)는 통합 테스트 케이스 또는 기능적 테스 트 케이스일 수도 있다. 일반적으로, 각 테스트 케이스(20a-f)는 어플리케이션(10)에 잘 정의된 파라미터(well-defined parameter)로 잘 정의된 자극(stimulus)이 가해지도록 한다. 테스트 케이스(20a-f) 각각은 어플리케이션(10)에 의해 실행되는 하나의 단계 또는 다수의 단계들을 포함할 수도 있다. 각 테스트 케이스(20a-f)는 어플리케이션(10)이 작용하는 하나 또는 일련의 테스트이다. 검증 매니저(30)는 예상 및 현재 어플리케이션 상태 데이터 구조(36, 37)를 가지는 비교기를 포함할 수도 있다. 전술한 바와 같이, 비교기(35)는 검증 매니저(30)와 분리되고 통신 상태에 있다. 또한, 예상 상태 발생기(32x-z)는 검증 매니저(30)와 분리될 수도 있다. 예상 상태 발생기(32)는 검증 매니저(30)와 통신 상태에 있을 수도 있다. 예상 상태 발생기(32)와 검증 매니저(30)의 기능은 도 2와 관련하여 설명된 것과 유사하거나 동일할 수도 있다. 각 예상 상태 발생기(32t-z)가 촛점을 두는 컴포넌트는 어플리케이션(10)내의 데이터 포인트일 수도 있다. 데이터 포인트는 속성값이고, 따라서 각 예상 상태 발생기(32t-z)는 검증 매니저(30)에게 테스트 케이스 실행에 앞서 예상 속성값을 제공할 수도 있다. 또한, 예상 상태 발생기(32)는 다른 예상 상태 발생기(32)를 포함할 수도 있다. 예상 상태 발생기(32)는 검증 매니저(30)와 통신 상태에 있을 수도 있다. 또한, 예상 상태 발생기(32)는 플러그가능한 컴포넌트인 하나 이상의 데이터베이스(31a-b)와 통신 상태에 있을 수도 있다.

예를 들면, 테스트 케이스(20a-f)가 문에 부착된 문 손잡이를 망치로 때리는 것에 관한 것인 경우, 예상 상태 발생기(32x)는 문에 부착된 힌지의 예상 상태를 결정할 수도 있다. 이를 행함에 있어, 예상 상태 발생기(32x)는 힌지의 하부 부분에 대해 보고하도록 예상 상태 발생기(32x₁)에 요청할 수도 있다. 마찬가지로, 예상 상태 발생기(32x)는 힌지의 상부 부분에 대해 보고하도록 예상 상태 발생기(32x₂)에 요청할 수도 있다. 예상 상태 발생기(32x)는 예상 상태를 결정할 때 데이터를 조합하고, 조합된 데이터를 적절한 시간에, 검증 매니저(30)에 통신할 수도 있다. 또한, 예상 상태 발생기(32x)가 문에 부착된 1/8인치 두께 및 2-인치 길이를 가지는 황동 힌지에 대한 테스트 영향을 결정하는 경우, 예상 상태 발생기(32x)는 데이터베이스(31a)에 질의하여, 예를 들면 황동의 인장강도에 관한 정보를 검색할 수도 있다.

여기에 설명된 다양한 기술들이 하드웨어 또는 소프트웨어와 관련하여, 또는 적절한 경우에 양쪽의 조합으로 구현될 수 있다. 그러므로, 본 발명의 방법 및 장치, 또는 특정 양태 및 그 일부는 플로피디크스, CD-ROM, 하드 드라이브 또는 임의의 다른 머신-판독가능한 저장 매체와 같은 실체적인 매체로 실시되는 프로그램 코드(즉, 명령)의 형태를 취하고, 프로그램 코드가 컴퓨터와 같은 머신에 의해 로딩되어 실행되는 경우 머신은 본 발명을 실시하기 위한 장치가 된다. 프로그램가능한 컴퓨터 상에서 프로그램 코드 실행의 경우에, 컴퓨팅 디바이스는 일반적으로 프로세서, 프로세서에 의해 판독가능한 저장 매체(휘발성 및 비휘발성 메모리 및/또는 저장 요소를 포함함), 적어도 하나의 입력 디바이스, 및 적어도 하나의 출력 디바이스를 포함한다. 예를 들면 데이터 처리 API 등의 이용을 통한 본 발명의 도메 인-특정 프로그래밍 모델 양태의 생성 및/또는 구현을 이용하는 하나 이상의 프로그램은 양호하게는, 컴퓨터 시스템과 통신하는 하이 레벨 절차 또는 객체 지향 프로그래밍 언어로 구현된다. 그러나, 프로그램(들)은 원하는 경우, 어셈블리 또는 기계어로 구현된다. 임의의 경우에, 언어는 컴파일링되거나 해석된 언어이고, 하드웨어 구현과 조합된다.

본 발명이 다양한 도면의 양호한 실시예로 설명되었지만, 다른 실시예가 이용되거나 본 발명의 동일한 기능을 수행하기 위해 본 발명에서 벗어나지 않고 기재된 실시예에 변형 및 추가가 가능하다는 것은 자명하다. 전체 명세서에 걸쳐, 2개의 주요 예들이 제공되었는데, 그 하나는 가상의 그래픽 어플리케이션을 다루는 것이고 다른 하나는 문에 부착된 문 손잡이를 다루는 것이다. 이들 특정 예들은 이해를 돕기 위해 제공되었다. 본 발명은 그래픽 어플리케이션이나 문에 부착된 문 손잡이와 관련된 어플리케이션으로 제한되는 것은 아니다. 더구나, 본 발명은 임의의 프로세스, 머신, 제조, 물질의 조합(composition of matter), 프로그램, 소프트웨어, 하드웨어, 디바이스, 메커니즘 또는 요소(material), 또는 그 임의의 개선과 관련한 임의의 어플리케이션에 관련된 임의의 테스트에 포함될 수 있다. 그러므로, 본 발명은 임의의 일 실시예로 제한되지 않고, 첨부된 특허청구범위에 따라 그 범위와 범주가 결정되어야 한다.

검증 매니저는 지정된 어플리케이션 속성의 예상 값과 이들 동일한 속성의 실제 값을 비교함으로써 테스트 케이스 결과를 검증할 수도 있다. 이러한 비교를 수행할 때, 검증 매니저는 현재 어플리케이션 상태 및 예상 어플리케이션 상태가 실질적으로 정렬되지 않은 인스턴스를 결정할 수 있을 것이다. 결국, 검증 매니저는 임의의 테스트 실패에 대하여 테스트 케이스, 테스트 케이스 실행자, 또는 임의의 다른 지정된 실체에 통신할 수도 있다.

Claims

어플리케이션에 적용되는 액션의 복수 결과를 검증하기 위한 시스템으로서,

상기 어플리케이션에 액션을 적용한 예상 결과를 계산하고, 예상 어플리케이션 상태를 업데이트하기 위한 예상 상태 발생기; 및

현재 어플리케이션 상태를 유지하고, 상기 예상 어플리케이션 상태와 상기 현재 어플리케이션 상태를 비교하기 위한 검증 매니저

를 포함하는 검증 시스템.
제1항에 있어서,

상기 예상 상태 발생기는 상기 액션의 실행에 앞서서 상기 예상 어플리케이션 상태를 결정하는 검증 시스템.
제1항에 있어서,

상기 예상 상태 발생기는 요구에 따라 예상 어플리케이션 상태를 결정하는 검증 시스템.
제1항에 있어서,

상기 검증 매니저에게 예상 컴포넌트 상태를 통신하기 위한 예상 상태 발생기를 더 포함하는 검증 시스템.
제4항에 있어서,

상기 예상 상태 발생기는 상기 검증 매니저의 외부에 존재하는 검증 시스템.
제4항에 있어서,

상기 예상 상태 발생기와 통신하는 컴포넌트 데이터베이스를 더 포함하고, 상기 컴포넌트 데이터베이스는 상기 컴포넌트의 예상 컴포넌트 상태를 결정할 때 상기 예상 상태 발생기를 활용하는 검증 시스템.
제1항에 있어서,

상기 액션을 실행하기 위해 상기 검증 매니저와 통신하고 있고 이것과 독립적인 테스트 케이스를 더 포함하는 검증 시스템.
제1항에 있어서,

상기 액션은 자극; 및 파라미터를 포함하는 검증 시스템.
제1항에 있어서,

상기 액션은 기능적 테스트 및 통합 테스트 중 적어도 하나인 검증 시스템.
제1항에 있어서,

예상 어플리케이션 상태 데이터 구조 및 현재 어플리케이션 상태 데이터 구조를 더 포함하는 검증 시스템.
제10항에 있어서,

상기 예상 어플리케이션 상태 데이터 구조는 예상 상태 발생기로부터 수신된 정보를 포함하는 검증 시스템.
제10항에 있어서,

상기 현재 어플리케이션 상태 데이터 구조는 상기 검증 매니저로부터 수신된 정보를 포함하는 검증 시스템.
제1항에 있어서,

상기 검증 매니저는 상기 예상 어플리케이션 상태와 상기 현재 어플리케이션 상태를 오프라인으로 비교하는 검증 시스템.
제1항에 있어서,

상기 예상 어플리케이션 상태와 상기 현재 어플리케이션 상태를 온라인으로 비교하는 검증 시스템.
제1항에 있어서,

상기 예상 상태 발생기는 데이터베이스 및 네트워크 로케이션 중 적어도 하나로부터 로딩되는 검증 시스템.
제1항에 있어서,

상기 검증 매니저는 상기 예상 어플리케이션 상태와 상기 현재 어플리케이션 상태의 비교의 통지를 제공하는 검증 시스템.
제16항에 있어서,

상기 통지는 오프라인으로 완료되는 검증 시스템.
데이터 구조를 그 위에 저장한 컴퓨터-판독가능 매체로서,

어플리케이션 상에 구현되는 액션에 기초하여, 상기 어플리케이션의 예상 어플리케이션 상태를 나타내는 데이터를 포함하는 검증 매니저에 저장된 제1 데이터 필드; 및

상기 액션을 적용한 후 상기 어플리케이션의 현재 어플리케이션 상태를 나타내는 데이터를 포함하는 상기 검증 매니저에 저장된 제2 데이터 필드를 포함하고,

상기 액션은 상기 검증 매니저와 독립적인 테스트 케이스에 의해 정의되고 적용되는 컴퓨터 판독가능 매체.
제18항에 있어서,

복수의 컴포넌트 디바이스는 상기 어플리케이션의 각 컴포넌트와 관련하여 상기 제1 및 제2 데이터 필드에 데이터를 제공하는 컴퓨터 판독가능 매체.
어플리케이션에 적용되는 액션의 결과를 검증하는 방법으로서,

상기 어플리케이션의 현재 어플리케이션 상태를 저장하는 단계;

상기 어플리케이션에 적용될 액션으로부터 예상 어플리케이션 상태를 계산하는 단계;

상기 예상 어플리케이션 상태를 저장하는 단계;

상기 액션을 실행하는 단계;

상기 어플리케이션의 상기 현재 어플리케이션 상태를 업데이트하는 단계; 및

상기 어플리케이션의 상기 예상 어플리케이션 상태와 상기 어플리케이션의 상기 현재 어플리케이션 상태를 비교하는 단계

를 포함하는 검증 방법.
제20항에 있어서,

초기 현재 상태의 복사본을 생성하는 단계를 더 포함하는 검증 방법.
제20항에 있어서,

상기 액션을 상기 어플리케이션의 컴포넌트에 적용하는 결과로서 예상되는 예상 컴포넌트 상태를 수신하는 단계를 더 포함하는 검증 방법.
제22항에 있어서,

상기 예상 컴포넌트 상태는 예상 어플리케이션 상태 데이터 구조에 저장되는 검증 방법.
제22항에 있어서,

상기 예상 컴포넌트 상태는 예상 상태 발생기에 의해 결정되는 검증 방법.
제24항에 있어서,

상기 예상 상태 발생기는 상기 검증 매니저 외부에 배치되는 검증 방법.
제20항에 있어서,

상기 예상 및 현재 어플리케이션 상태가 실질적으로 동일하지 않은 경우에 상기 테스트 케이스에 통지하는 단계를 더 포함하는 검증 방법.
제20항에 있어서,

상기 비교 단계는 XML을 이용하여 완료되는 검증 방법.
제20항에 있어서,

상기 어플리케이션의 현재 어플리케이션 상태를 저장하는 단계는 상기 액션 이 적용된 후 완료되는 검증 방법.
제20항에 있어서,

상기 예상 어플리케이션 상태를 저장하는 단계는 상기 액션이 완료되기 이전에 완료되는 검증 방법.
단계를 수행하기 위한 컴퓨터 실행가능 명령을 가지는 컴퓨터-판독가능 매체로서, 상기 단계는,

어플리케이션에 적용될 액션으로부터 예상 어플리케이션 상태를 계산하는 단계;

상기 액션을 실행하는 단계;

상기 어플리케이션의 현재 어플리케이션 상태를 결정하는 단계; 및

상기 어플리케이션의 상기 예상 어플리케이션 상태 및 상기 어플리케이션의 상기 현재 어플리케이션 상태를 비교하는 단계

를 포함하는 컴퓨터 판독가능 매체.
제30항에 있어서,

상기 어플리케이션의 컴포넌트에 상기 액션을 적용한 결과로서 예상되는 예상 컴포넌트 상태를 수신하는 단계를 수행하기 위한 컴퓨터 실행가능 명령을 더 구비하는 컴퓨터 판독가능 매체.
제31항에 있어서,

상기 예상 컴포넌트 상태를 예상 어플리케이션 상태 데이터 구조에 저장하는 단계를 수행하기 위한 컴퓨터 실행가능 명령을 더 구비하는 컴퓨터 판독가능 매체.
제31항에 있어서,

상기 예상 어플리케이션 상태가 상기 현재 어플리케이션 상태와 실질적으로 동일하지 않은 경우에 통지를 제공하는 단계를 수행하기 위한 컴퓨터 실행가능 명령을 더 구비하는 컴퓨터 판독가능 매체.