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

본 발명은 어플리케이션을 테스트하기 위한 소프트웨어에 관한 것으로, 특히 그러한 테스트 소프트웨어에서 예상 결과와 실제 결과의 약하게 결합되는 비교에 관한 것이다. 소프트웨어 개발의 생명 주기에서 주요한 단계는 설계 국면, 코딩 국면, 코드 완료 국면, 알파 국면, 베타 국면, 및 최종적으로 시장 배포이다. 설계 국면 동안에, 소프트웨어 제품의 고객 문제가 제기되고 소프트웨어 제품의 기능이 정의된다. 일반적으로, 기능적 스펙의 완료는 설계 국면의 종료를 나타낸다. 코딩 국면은 이미 시작되었을 수도 있다. 코드 완료 국면은 코드가 저작되었지만 반드시 디버깅될 필요가 없는 때에 도달된다. 알파 국면은 제품이 안정되어 있는 때, 즉 대부분의 주요한 버그들이 발견된 시점을 나타낸다. 베타 국면에서, 제품이 이상적으로는 모든 주요한 버그가 없고, 단지 남아있는 버그는 실질적으로 해가 없는 것이어야 한다. 제품이 최종 품질 확인 체크 리스트를 통과할 때, 시장에 배포될 준비가 된다. 아무도 동작하지 않는 소프트웨어를 원하지 않으므로, 테스팅은 생명 주기의 중요한 부분으로서, 수 개의 양태에 걸칠 수 있다. 소프트웨어 테스트는 테스트 케이스(또는, 더 가능성있게는 테스트 케이스의 세트)를 고안하고, 입력으로서 테스트 케이스를 가지는 소프트웨어를 운영하며, 입력으로서 테스트 케이스를 가지는 소프트웨어의 성능이 예상된 결과를 산출하는지를 체크하는 것을 포함한다. 소프트웨어 테스팅은 인간에 의해 수동으로 수행될 수도 있으며, 또는 자동화된 소프트웨어 테스팅이라 하는 프로그램 방식으로 수행될 수도 있다. 이상적으로는, 소프트웨어의 테스팅은 소프트웨어의 생명 주기에서 가능한 한 빨리 시작해야 한다. 그러나, 일반적으로는, 설계 국면이 완료될 때까지는 예상 결과가 결정될 수 없으므로, 소프트웨어는 설계 국면이 완료될 때까지는 전혀 테스트 될 수 없다. 통상, 코딩 국면 동안에, 개발자는 그 코드를 저작하면서 그 코드를 수동으로 테스트한다. 자동화된 소프트웨어 테스팅은 통상 개발 프로세스에서 훨씬 더 늦게까지 시작할 수 없다. 종종, 수행되는 유일한 테스팅은 개발자가 코딩하면서 수동으로 테스트하는 개발자에 의해 수행된다. 그러나, 그 자신의 작업을 테스트하는 개발자는 코드에 그다지 열정적으로 관여하지 않은 일부 사람들이 찾는 버그를 무시할 가능성이 있다. 또한, 개발자의 테스팅의 범주는 통상 그 코드의 기능, 및 제한된 개수의 다른 소프트웨어 어플리케이션과 그 코드의 통합으로 제한된다. 이들 단점에 대처하기 위해, 다수의 소프트웨어 개발 회사는 종종 적어도 부분적으로는 자동화된 테스팅 기술을 이용하여 소프트웨어를 테스트하는 분리된 소프트웨어 테스팅 그룹을 가지고 있다. 통상, 테스팅 그룹은 테스트 케이스를 저작하고 운용함으로써 특징 및 어플리케이션에 걸친 복잡한 상호작용들을 테스트한다. 일반적으로, 제품 생명주기에서 테스팅 그룹을 일찍, 심지어는 설계 국면과 같이 일찍 관여시키는 것은, 기능적 세부사양(specification)의 불일치의 식별, 테스트-난이 영역의 식별 등을 포함하여 다수의 장점을 얻을 수 있는 것으로 알려져 있다. 그러나, 일반적으로, 특징의 정의, 구현 및 사용자 인터페이스(UI) 튜닝에 있어서의 계속되는 변화에 직면하여 각 테스트 케이스를 현재로 유지하는데 요구되는 노력은 이러한 접근법을 비실용적이 되도록 한다. 그러므로, 테스트 케이스를 저작하고 및 운용하는 것은 통상 제품 개발의 마지막에서 발생하는 다급한 문제이다. 테스팅 및 특히, 자동화된 테스팅은 영원히 시간적으로 뒤처지는 경향이 있다. 소프트웨어 제품의 생명 주기에서 가능한 한 빨리, 이상적으로는 설계 국면 동안에, 테스트 케이스를 저작하고 자동화된 테스팅을 채용하는 방법이 있다면 도움이 될 것이다. 한 벌의 테스트 케이스의 개발은 그것이 발생할 때마다 일종의 도전이다. 어플리케이션의 특정 특징을 테스트하기 위해서는, 다수의 테스트 세트가 저작되어야 한다. 예를 들면, 어플리케이션은 마우스, 키보드, 디지타이저, 액세스가능 소프트웨어를 통해, 또한, 프로그램적으로, 특징과의 다수의 상호작용 모드들을 허용한다. 그러므로, 특징에 대한 광범위한 테스트를 제공하기 위해, 한 벌의 테스트는, 마우스를 통해(사용자처럼 텍스트를 타이핑하는 것) 특징과 상호작용하는 테스트 세트, 키보드를 통해 특징과 상호작용하는 하나의 세트, 디지타이저를 통해 특징과 상호작용하는 하나의 세트, 디폴트 액션을 유발하고 다르게는 액세스가능 어플리케이션(accessibility application)을 흉내내는, 액세스가능 소프트웨어를 통해 특징과 상호작용하는 하나의 세트, 어플리케이션의 코딩 모델을 통해 특징과 상호작용하는 하나의 세트, 등을 포함한다. 생성된 한 벌의 테스트 케이스가 특징 또는 어플리케이션의 광범위한 테스트를 제공했던 것을 확인하고 또한 그 광범위한 테스트를 제공하기 위해 저작되어야 하는 전체 테스트 케이스의 개수를 감소하는 방법이 있다면 도움이 될 것이다. 또한, 이들 각 테스트 세트 각각에서 로직의 다수 또는 모두는 다른 테스트 세트의 로직과 동일하고, 통상 결과 처리의 검증의 다수 또는 모두 또한 동일하다. 그러므로, 다수의 테스트는 동일하거나, 매우 거의 동일하고, 단지 실행 옵션을 변화시킨다. 예를 들면, 전술한 모든 복수 형태의 입력에 대하여, 예상된 결과는 거의 동일하다. 그러므로, 이들 입력 소스 각각에 대한 테스트 케이스를 저작하는 것은, 통상 각 입력 소스에 대한 테스트를 실행하기 위한 분리된 방법을 저작하고, 나머지 테스트 스크립트의 대부분을 복사하는 것을 필요로 한다. 사소한 변동을 가지는 동일한 테스트를 반복적으로 저작하는 것은 지루하고 시간 소비되는 일이다. 이러한 중복적인 코딩을 제거하거나 상당히 감소시키며, 저작되어야 하는 테스트 케이스의 전체 개수를 줄이는 방법이 있다면 도움이 될 것이다. 테스트 케이스를 운용하는 실제 결과가 예상 결과와 일치하는지를 판정하기 위해(결과 검증 또는 검증이라 불림) 저작되는 코드는 종종 테스트 케이스 내에 포함된다. 특정 결과 검증의 세부 사항을 변경하거나 새로운 결과 검증을 추가하는 것은, 통상 각 테스트 케이스의 변형을 필요로 한다. 검증 코드가 테스트 케이스와 분리되어 있고, 테스트 케이스가 이해되기 더 용이하도록 하며, 검증 코드가 재사용하고 유지하는 것이 더 용이하게 한다면 도움이 될 것이다. 실행 세부사항은 테스트 케이스에 하드-코딩되어, 설계 국면이 테스트 케이스가 저작되기 이전에 완료되는 것을 필요로 한다. 테스트 케이스가 소프트웨어 개발 생명 주기에서 더 일찍 저작될 수 있도록 특정 실행 세부사항의 측면에서 보다는 사용자 액션의 측면에서 테스트 케이스를 정의하는 방법이 있다면 도움이 될 것이다. 어플리케이션을 테스트하는 것은 어플리케이션의 초기 개발에서 중대한 단계이다. 어플리케이션에 변형을 구현할 때도 어플리케이션을 테스트하는 것은 매우 중요하다. 개발자, 과학자, 제조자 등은 테스트 국면에 많은 노력을 기울인다. 그러한 테스트는 어플리케이션이 특정 자극에 예상되는 방식으로 반응하는 것을 보장하는데 도움을 준다. 테스팅은 통상 테스트 결과의 실행 및 테스트 케이스 실행의 결과의 검증을 통해 완성된다. 테스트 케이스는 통상 자극을 어플리케이션에 가한다. 테스트 케이스는 또한 어플리케이션이 예상되는 방식으로 응답했는지 및 예상하지 않은 방식으로 응답하지 않았는지를 검증해야 한다. 이해를 위해, 테스트는 전체 어플리케이션 상태의 많은 부분을 검증하여, 자극이 예상된 결과를 유발했고 예상치 않은 결과를 유발하지 않았다는 것을 보장해야 한다. 테스트 케이스는 통상 어플리케이션의 특정한 기능 또는 양태를 테스트하는 목적으로 실행된다. 마찬가지로, 테스트 케이스의 결과의 검증은 테스트 되려는 기능에 촛점을 둔다. 그러나, 테스트 케이스의 실행은 어플리케이션 상태의 다른 양태에 영향을 미치거나 변경할 수 있다. 그러한 양태는 테스트 케이스의 목적에 벗어나는 것으로 보일 수 있다. 이들 벗어난 양태는 다수일 수 있으며, 테스트 케이스를 개발하는 테스터가 이들의 전부 또는 심지어 대부분을 수량화 하거나 지정하는 것은 어려울 수 있다.