KR102166753B1 - 자동화된 반도체 디바이스 테스트를 위한 테스트 계획을 컴파일하기 위해 사용되는 개발 환경 내에 편집 및 갱신 기능 구현 - Google Patents

Abstract

자동화된 디바이스 테스트를 위한 테스트 절차를 디버그하는 방법이 개시된다. 그 방법은 제 1 디버깅 세션 중에 수정된 적어도 하나의 수정된 테스트 절차를 갱신하기 위한 명령을 수신하는 것 및 테스트 계획을 위한 상태 정보를 세이브하는 것을 포함하는데, 위 상태 정보는 중단점 엔트리 위치에 관한 정보를 포함하고, 위 수정된 테스트 절차는 위 테스트 계획 내에서 호출된다. 그 방법은 위 테스트 계획의 실행을 유예하는 것 및 위 수정된 테스트 절차를 언로드하는 것을 후속적으로 포함한다. 그것은 또한 컴파일된 파일을 산출하기 위해 위 수정된 테스트 절차를 컴파일하는 것 및 이후에 위 컴파일된 파일을 사용하여 위 테스트 계획 내에 위 테스트 절차를 재로드하는 것을 포함한다. 끝으로, 그것은 제 2 디버깅 세션 내에서 위 수정된 테스트 절차의 실행을 재개하는 것 및 위 제 2 디버깅 세션 중에 위 중단점 엔트리 위치에 대응하는 중단점에서 위 실행을 중단하는 것을 포함한다.

Description

자동화된 반도체 디바이스 테스트를 위한 테스트 계획을 컴파일하기 위해 사용되는 개발 환경 내에 편집 및 갱신 기능 구현{IMPLEMENTING EDIT AND UPDATE FUNCTIONALITY WITHIN A DEVELOPMENT ENVIRONMENT USED TO COMPILE TEST PLANS FOR AUTOMATED SEMICONDUCTOR DEVICE TESTING}

본 발명의 실시예는 일반적으로는 자동화된 디바이스 테스트(automated device testing)에 관련되고 더욱 구체적으로는 자동화된 디바이스 테스트를 위한 테스트 절차를 디버그하는 사용자 친화적이고 효율적인 방법 및 시스템에 관련된다.

자동화된 테스트 장비(Automated Test Equipment: ATE)는 디바이스, 반도체 웨이퍼 또는 다이(die) 등등에 대한 테스트를 수행하는 임의의 테스트 어셈블리(testing assembly)일 수 있다. 신속히 측정을 수행하는 자동화된 테스트를 실행하고 이후에 분석될 수 있는 테스트 결과를 생성하기 위해 ATE 어셈블리가 사용될 수 있다. ATE 어셈블리는 계측기(meter)에 커플링된(coupled) 컴퓨터 시스템부터, 전자 부품 및/또는 반도체를 자동으로 테스트하는 것이 가능한 많은 상이한 테스트 기구와 맞춤식 전용 컴퓨터 제어 시스템을 포함할 수 있는 복잡한 자동화된 테스트 어셈블리까지 임의의 것일 수 있다. 자동 테스트 장비(Automatic Test Equipment: ATE)는 전기적 칩 제조(electrical chip manufacturing) 분야 내에서 흔히 사용된다. ATE 시스템은 디바이스가 설계된 바와 같이 기능하게 하기 위해 디바이스를 테스트하는 데에 쓰이는 시간의 양을 줄일 뿐만 아니라 주어진 디바이스 내의 흠 있는 컴포넌트의 존재를 그것이 소비자에게 도달하기 전에 판정하는 진단 툴(diagnostic tool)로서의 역할도 한다.

디바이스 또는 제품을, 가령 생산 후에, 테스트하는 데에 있어서, 무엇보다도 높은 제품 품질, 디바이스 또는 제품 성능의 추정, 제조 프로세스에 관한 피드백 그리고 끝으로 높은 소비자 만족을 달성하는 것이 중대하다. 디바이스 또는 제품의 올바른 기능을 보장하기 위해서 대개 복수의 테스트가 수행된다. 테스트 프로세스는 비용이 많이 들기 때문에, 디바이스의 성능을 보장하는 것 외에, 테스트 속도와 처리량(throughput)을 최대화하는 것이 또한 중요하다.

테스트 계획(test plan) 또는 테스트 프로그램(test program)은 ATE 시스템 상에서 반도체 디바이스 테스트를 수행하는 데에 필요한 모든 사용자 정의(user-defined) 데이터 및 제어 흐름을 포함한다. 더욱 구체적으로, 테스트 계획은 디바이스 사양을 만족시키는 테스트 조건, 테스트 조건과 테스트 알고리즘의 조합 및 테스트 흐름(test flow)이 테스터 소프트웨어(tester software)의 언어로 기술된 프로그램이다. 테스트 프로그램 내의 주 제어 흐름(main control flow)은, DUT에 적용될 개별적인 테스트의 시퀀스(sequence)와, 테스트가 적용될 순서(이는 개별적인 테스트의 결과에 달려 있음)를 지시하는(dictate) 것으로서, 테스트 프로그램 흐름(test program flow)으로 지칭된다.

테스트 프로그램이 DUT를 위해 기록되는 경우, 일반적으로 그 프로그램의 주요(predominant) 부분은 디바이스 테스트를 위한 "데이터"이고, 나머지는 프로그램 코드인데, 이는 테스트 방법론 그 자체를 실현한다. 데이터는 DUT 의존적(DUT-dependent)이다(가령, 전력 공급 조건, 신호 전압 조건, 타이밍 조건 등등). 테스트 코드는 지정된 디바이스 조건을 테스터 하드웨어(tester hardware) 상으로 로드하는(load) 방법과, 또한 데이터 로깅(data-logging) 등등과 같은 사용자 지정(user specified) 목표를 실현하기 위해 필요한 것으로 이루어질 수 있다. ATE 프레임워크(framework)는 사용자로 하여금 DUT 테스트 프로그래밍의 작업(task)을 수행하게 하는 하드웨어 독립적 테스트 및 테스터 객체 모델(hardware-independent test and tester object model)을 제공할 수도 있다.

테스트 방법론은 디바이스 테스트 품질 및 테스터 생산성에서 중요한 요소이므로, 그것은 종종 최종 사용자로부터는 감싸여 있다(encapsulated). 이 구분(separation)은 시스템의 더 안전한 동작을 초래한다. 또한, 테스트 코드의 재사용가능성을 증가시키기 위해, 그러한 코드는 임의의 디바이스 특정적(device-specific) 데이터(가령, 핀 명칭(pin name), 자극 데이터(stimulus data) 등등) 또는 디바이스 테스트 특정적(device-test-specific) 데이터(가령, DC 유닛의 조건, 측정 핀, 타겟 핀의 개수, 패턴 파일의 명칭, 패턴 프로그램의 어드레스 등등)와는 무관해야 한다. 만약 테스트를 위한 코드가 이들 유형의 데이터와 컴파일되는 경우, 테스트 코드의 재사용가능성은 감소할 것이다. 따라서, 임의의 디바이스 특정적 데이터 또는 디바이스 테스트 특정적 데이터는 코드 실행 시간 중 입력으로서 외부적으로 테스트 코드가 이용가능하게 되어야 한다.

종래의 ATE 테스터 소프트웨어에서, "테스트 클래스"(test class)는 특정한 유형의 테스트를 위한 테스트 데이터 및 코드의 구분(및, 따라서 코드의 재사용 가능성)을 실현한다. 그러한 테스트 클래스는 테스트의 별개의 인스턴스들(디바이스 특정적 및/또는 디바이스 테스트 특정적 데이터를 기준으로 하여서만 서로 상이함)을 위한 "템플릿"(template)으로 간주될 수 있다. 테스트 클래스는 전형적으로는 테스트 계획 파일 내에 지정된다. 각 테스트 클래스는 전형적으로는 특정 유형의 디바이스 테스트 또는 디바이스 테스트를 위한 셋업(setup)을 구현한다. 예를 들어, 테스터 소프트웨어는 기능적 테스트, AC 파라미터적(parametric) 테스트 및 DC 파라미터적 테스트를 구현하기 위해 샘플 테스트 클래스를 제공할 수 있다. 따라서, 테스트 클래스는 테스트를 위한 템플릿이다. 디바이스 의존적 테스트 조건은 테스트 클래스 자체 내에 기술되지 않는다. 테스트 시스템을 사용하여 테스트를 실행하기 위한 알고리즘만이 기술된다.

테스트 클래스는 해당 테스트의 특정한 인스턴스(instance)를 위한 옵션을 지정하기 위해 사용되는 파라미터를 제공함으로써 사용자로 하여금 클래스 작동(class behavior)을 구성하게 한다. 예를 들어, 기능적 테스트를 구현하기 위한 테스트 클래스는 테스트되고 있는 DUT 상에서 실행할 테스트 패턴을 지정하기 위한 파라미터를 제공할 수 있다. 또한 그것은 테스트를 위한 레벨 및 타이밍 조건을 지정하기 위한 파라미터를 제공할 수 있다. 이들 파라미터에 대해 상이한 값들을 지정하는 것은 사용자로 하여금 기능적 테스트의 상이한 인스턴스들을 생성해내게 한다. 하나의 실시예에서, 테스트 클래스는 C++과 같은 종래의 프로그래밍 언어(programming language)로 개발된다.

어드밴테스트 사(Advantest Corporation)의 T2000 시스템 소프트웨어(T2000 System Software)와 같은 테스터 소프트웨어 시스템은 전형적으로 컴파일러(compiler)를 포함하는데, 이는 테스터 시스템의 프로그래밍 언어, 가령 OPENSTAR 테스트 프로그래밍 언어(OPENSTAR Test Programming Language)("OTPL")로 기록된 테스트 계획을 컴파일한다. OTPL은 테스트 실행 시퀀스 및 대응하는 피사용 테스트 조건을 기술하기 위해 사용될 수 있다. OTPL이 테스트 계획을 기술할 수 있으나, 그것은 전형적으로는 어떠한 테스트 알고리즘도 기술하지 않는다. T2000과 같은 시스템 내의 테스트 알고리즘은, 예컨대, 앞서 논의된 바와 같이 테스트 클래스 내에서 C++ 언어를 사용하여 기술될 수 있다.

ATE의 대부분의 사용자는 자신의 테스트 클래스를 준비하기 위해 개발 환경, 가령 마이크로소프트 개발자 스튜디오(Microsoft Developers Studio)("MDS")를 사용한다. 전형적으로, 사용자들은 테스터 소프트웨어 시스템의 개발자들로부터 플러그인을 제공받을 것이어서 그들은 동일한 환경 내에서 테스트 계획을 편집하고 만들어낼 수 있다. 그러므로, 사용자는 자신이 선택한 개발 환경 내로부터 테스트 클래스 및 테스트 계획을 작성하고 디버깅(debugging)을 수행하는 것이 가능하다. MDS와 같은 개발 환경은 전형적으로 디버깅 프로젝트를 위한 "편집 및 계속"(Edit and Continue) 특징을 제공할 수 있다. "편집 및 계속"은 프로그램이 중단 모드(break mode) 내에 있는 동안 사용자가 소스 코드에 대해 변경을 행할 수 있게 하는 시간 절약(time-saving) 특징이다. "계속" 또는 "단계"와 같은 실행 명령(execution command)을 선택함으로써 프로그램의 실행이 재개되는 경우, 편집 및 계속" 동작은 어떤 제약을 갖고서 코드 변경을 자동으로 적용한다. 이는 사용자로 하여금 멈추고, 전체 프로그램을 재컴파일하며(recompile), 디버깅 세션(debugging session)을 재시작해야 하는 것 대신에, 디버깅 세션 중에 코드에 대한 변경을 행하게 한다.

전형적인 개발 환경, 가령 MDS 내에서 이용가능한 "편집 및 계속" 특징은 다만 그 특징을 온전히 이용할 사용자의 능력을 제한하는 여러 제약을 가진다. 우선, 그것은 모든 유형의 코드와 관련하여 사용될 수는 없다. 예를 들어, 그것은 64 비트 코드를 디버그하는 경우 디버깅 환경 내에서 사용될 수 없다. 결과적으로, 성능상 이유로 64 비트 테스트 클래스 및 테스트 계획을 개발하는 테스터 소프트웨어의 많은 사용자가 이 특징을 이용할 수 없다.

더욱 중요하게는, 종래의 "편집 및 계속" 특징은 허용되는 코드 변경의 유형에 대해 다양한 제약을 가진다. 예를 들어, 한 가지 단점은 그 특징을 사용하는 경우에 종래의 개발 환경은 상대적으로 사소한 코드 변경이 행해지게 할 뿐이라는 것이다. 전형적으로, 바뀐 코드 섹션(code section)은 재컴파일되고, 바뀐 코드에 대응하는 실행 메모리(execution memory)의 작은 부분은 스왑 아웃되고(swapped out) 새로운 코드를 사용하여 생성된 메모리의 새 블록으로 대체된다. 그 후에, 적절한 명령어 포인터가 이에 따라 설정된다.

그 특징은, 종래의 시스템 내에 설계된 것과 같이, 로드된(loaded) 메모리의 상대적으로 작은 섹션만 바꿀, 코드에서의 사소한 변경(가령 구문론적(syntactical) 변경)을 행하는 것보다 더 복잡한 무언가를 요구할 어떠한 복잡한 코드 변화도 다룰 수 없다. 결과적으로, 그것은 ATE를 위한 테스트 클래스의 개발자에게 그다지 유용하지 않다. 만약 사용자가 테스트 클래스의 준비에서 어떠한 상당한 오류라도 저지르거나 테스트 계획이 실행되고 있는 동안에 어떠한 다른 이유로든 테스트 클래스를 대체할 필요가 있는 경우, 그는 전형적으로는 테스트 계획을 중지하고 우선 그것을 언로드(unload)해야 한다. 이후에, 개발자는 테스트 클래스를 편집하고 재컴파일하며 재링크할(relink) 필요가 있다. 그리고, 그는 코드 내의 원래의 지점(point)에 돌아가기 전에 테스트 계획을 재로드하고(reload) 그것을 처음부터 재시작할 필요가 있다. 그러한 작업 흐름(work flow)은 시간이 걸리고 오류가 생기기 쉽다.

이에 따라, 필요한 것은 사용자로 하여금 전체 테스트 계획을 언로드하기 및 재로드하기와 같은, 디버깅 중에 테스트 클래스에 대한 변경을 행하는 경우에 현재 요구되는 모든 단계를 수동으로 수행할 필요 없이 테스트 계획의 실행 중에 테스트 클래스에 대해 변경을 행하게 하는 자동화된 방법 및 시스템이다. 이는 개발자들로 하여금 그들이 종래의 시스템을 사용하여서 하게 되었던 것보다도 상당히 더 효율적이고 덜 오류가 생기는 방식으로 테스트 클래스를 준비하고 디버그하게 한다.

이 목표를 성취하기 위해서, 본 발명의 실시예는 테스터 소프트웨어 시스템 내에 편집 및 갱신 기능성을 제공한다. 디버깅 동안, 사용자는 시스템이 중지되게 하는 테스트 클래스 소스 코드 내 중단점(breakpoint)을 설정할 수 있다. 사용자는 소스 코드를 편집할 수 있다(이로써 편집 및 갱신 세션(edit and update session)을 개시함). 그리고 상태 정보는 저장되고 편집된 테스트 클래스는 언로드된다. 이후에, 편집 및 갱신 절차는 테스트 클래스의 편집된 버전(version)을 재컴파일하고 원래의 버전을 새로 컴파일된 버전로써 교체할(swap) 것이다. 그리고 편집된 테스트 클래스는 재실행되고, 사용자가 디버깅을 그만둔 곳과 동일한 중단점으로 도로 자동으로 되돌려지며, 이전에 저장된 상태 정보가 복원된다(restored). 그리고 테스트 계획은 새로 편집된 코드로 계속될 수 있다.

자동화된 디바이스 테스트를 위한 테스트 절차를 디버그하는 방법이 개시된다. 위 방법은 제 1 디버깅 세션 중에 수정된 적어도 하나의 수정된 테스트 절차(modified test procedure)를 갱신하기 위한 명령(command)을 수신하는 단계와, 테스트 계획을 위한 상태 정보를 세이브하는(saving) 단계를 포함하는데, 위 상태 정보는 중단점 엔트리 위치(breakpoint entry location)에 관한 정보를 포함하고, 위 수정된 테스트 절차는 위 테스트 계획 내에서 호출된다(invoked). 위 방법은 위 테스트 계획의 실행을 유예하는 단계와, 위 수정된 테스트 절차를 언로드하는 단계를 후속적으로 포함한다. 그것은 또한 컴파일된 파일(compiled file)을 산출하기 위해 위 수정된 테스트 절차를 컴파일하는 단계와, 이후 위 컴파일된 파일을 사용하여 위 테스트 계획 내에 위 테스트 절차를 재로드하는 단계를 포함한다. 끝으로, 그것은 제 2 디버깅 세션 내에서 위 수정된 테스트 절차의 실행을 재개하는 단계와, 위 제 2 디버깅 세션 중에 위 중단점 엔트리 위치에 대응하는 중단점에서 위 실행을 중단하는 단계를 포함한다.

다른 실시예에서, 컴퓨터 판독가능 저장 매체(computer-readable storage medium)가 개시된다. 위 컴퓨터 판독가능 저장 매체는 컴퓨터 시스템에 의해 실행되는 경우 위 컴퓨터 시스템으로 하여금 자동화된 디바이스 테스트를 위한 테스트 절차를 디버그하는 방법을 수행하게 하는 컴퓨터 실행가능 명령어가 거기에 저장되어 있다. 이 방법은 제 1 디버깅 세션 중에 수정된 적어도 하나의 수정된 테스트 절차를 갱신하기 위한 명령을 수신하는 단계와, 테스트 계획을 위한 상태 정보를 세이브하는 단계를 포함하는데, 위 상태 정보는 중단점 엔트리 위치에 관한 정보를 포함하고, 위 수정된 테스트 절차는 위 테스트 계획 내에서 호출된다. 그 방법은 위 테스트 계획의 실행을 유예하는 단계와, 위 수정된 테스트 절차를 언로드하는 단계를 후속적으로 포함한다. 그것은 또한 컴파일된 파일을 산출하기 위해 위 수정된 테스트 절차를 컴파일하는 단계와, 이후 위 컴파일된 파일을 사용하여 위 테스트 계획 내에 위 테스트 절차를 재로드하는 단계를 포함한다. 끝으로, 그것은 제 2 디버깅 세션 내에서 위 수정된 테스트 절차의 실행을 재개하는 단계와, 위 제 2 디버깅 세션 중에 위 중단점 엔트리 위치에 대응하는 중단점에서 위 실행을 중단하여, 이로써, 앞서 세이브된 상태 정보를 복원하는 단계를 포함한다.

다른 실시예에서, 자동화된 디바이스 테스트를 위한 테스트 절차를 디버그하는 시스템이 개시된다. 위 시스템은 내부에 저장된 개발 환경을 포함하는 메모리를 포함하되, 위 개발 환경은 테스트 프로그램을 디버그하도록 동작가능하고(operable), 위 개발 환경은 디버거(debugger)를 포함한다. 위 시스템은 또한 위 메모리에 커플링된 프로세서를 포함하되, 위 프로세서는 상기 개발 환경에 따라 (a) 테스트 계획을 위한 상태 정보를 세이브하고(위 상태 정보는 중단점 엔트리 위치에 관한 정보를 포함하고, 수정된 테스트 절차가 위 테스트 계획 내에서 호출됨), (b) 위 테스트 계획의 실행을 유예하며, (c) 위 테스트 계획으로부터 위 수정된 테스트 절차를 언로드하고, (d) 위 수정된 테스트 절차를 컴파일하며(위 컴파일은 위 수정된 테스트 절차와 연관된 컴파일된 파일을 생성함), (e) 위 컴파일된 파일을 사용하여 위 테스트 계획 내에 위 수정된 테스트 절차를 재로드하고, (f) 디버깅 세션 내에서 위 수정된 테스트 절차의 실행을 재개하며, (g) 위 디버깅 세션 중에 위 중단점 엔트리 위치에 대응하는 중단점에서 위 실행을 중단하게 동작하도록 구성된다. 앞서 세이브된 상태 정보는 이후에 복원된다.

첨부된 도면과 더불어 이하의 상세한 설명은 본 발명의 본질 및 이점의 더 나은 이해를 제공할 것이다.

비슷한 참조 번호가 유사한 구성요소를 나타내는 첨부된 도면의 그림 내에 본 발명의 실시예들이 한정으로서가 아니라 예로서 보여진다.
도 1은 본 발명의 하나의 실시예에 따라 본 발명의 자동화된 테스트 시스템의 실시예가 구현될 수 있는 예시적인 컴퓨터 시스템이다.
도 2a는 본 발명의 하나의 실시예에 따라 본 발명의 실시예가 구현될 수 있는 예시적인 자동화된 테스트 장비 장치에 대한 도식적인 블록 다이어그램(block diagram)이다.
도 2b는 도 2a의 자동화된 테스트 장비 장치의 하나의 실시예의 더욱 상세한 도식적인 블록 다이어그램이다.
도 3은 상이한 테스트 인스턴스들이 단일의 테스트 클래스로부터 생성될 수 있는 방식에 관한 다이어그램을 보여준다.
도 4는 테스트 계획 내 테스트 클래스의 유효확인(validation) 및 실행을 보여주는 예시적인 소프트웨어 프로세스의 블록 다이어그램이다.
도 5는 본 발명의 하나의 실시예에 따라 편집 및 갱신 기능성의 구현을 보여주는 예시적인 소프트웨어 프로세스의 블록 다이어그램이다.
도 6은 본 발명의 하나의 실시예에 따라 사용자가 편집 및 갱신 기능성을 위한 다양한 설정을 셋업하게 하는 화면상 그래픽 사용자 인터페이스 구성 다이얼로그 박스(on-screen graphical user interface configuration dialog box)를 보여준다.
도 7은 본 발명의 하나의 실시예에 따라 편집 및 갱신 세션의 라이프사이클(lifecycle)을 보여주는 블록 다이어그램이다.
도 8은 동시적 흐름 항목(concurrent flow item) 내의 분기 흐름(branch flow)의 일부인 흐름 항목 내에서의 편집 및 갱신 절차의 호출(invocation)을 보여주는 흐름 다이어그램(flow diagram)이다.
도 9는 본 발명의 하나의 실시예에 따라 편집 및 갱신 기능성을 구현하기 위한 예시적인 컴퓨터 제어된 프로세스(computer controlled process)의 흐름도(flowchart)를 묘사한다.

본 개시의 다양한 실시예들에 대한 언급이 이제 상세히 이루어질 것인데, 첨부된 도면에 이의 예들이 보여진다. 이 실시예들과 함께 기술되나, 그것들은 그 개시를 이 실시예들에 한정하고자 의도된 것이 아님이 이해될 것이다. 반대로, 그 개시는 부기된 청구항에 의해 정의되는 바와 같은 그 개시의 사상 및 범주 내에 포함될 수 있는 대안, 수정 및 균등물을 포섭(cover)하고자 의도된 것이다. 나아가, 본 개시의 이하의 상세한 설명에서, 본 개시의 철저한 이해를 제공하기 위해서 많은 구체적인 세부사항이 개진된다. 다만, 본 개시는 이 구체적인 세부사항 없이 실시될 수 있다는 점이 이해될 것이다. 다른 경우, 본 개시의 양상들을 불필요하게 모호하게 하지 않도록 잘 알려진 방법, 절차, 컴포넌트 및 회로는 상세히 기술되지 않았다.

후속하는 상세한 설명의 몇몇 부분은 컴퓨터 메모리 내의 데이터 비트에 대한 동작의 절차, 로직 블록, 처리 및 다른 상징적 표현의 측면에서 제시된다. 이들 설명 및 표현은 데이터 처리 기술의 당업자에 의해 그의 성과의 실체를 다른 당업자에게 가장 효과적으로 전달하기 위해 사용되는 수단이다. 본 출원에서, 절차, 로직 블록, 프로세스 또는 유사한 것은 원하는 결과로 이어지는 자기 부합적인 일련의 단계 또는 명령어(a self-consistent sequence of steps or instructions)인 것으로 여겨진다. 그 단계는 물리적 양의 물리적 조작을 활용하는 것이다. 반드시 그런 것은 아니지만 대체로, 이 양들은 컴퓨터 시스템 내에 저장, 전송, 조합, 비교 및 그렇지 않으면 조작될 수 있는 전기(electrical) 또는 자기(magnetic) 신호의 형태를 취한다. 이 신호들을 트랜잭션, 비트, 값, 요소, 심볼, 기호, 샘플, 픽셀 또는 유사한 것으로 지칭하는 것은 주로 일반적인 용법상 때때로 편리하다고 드러났다.

그러나, 이들 용어 및 유사한 용어 전부는 적절한 물리적 양들과 연관될 것이며 이 양들에 적용되는 편리한 라벨에 불과하다는 점에 유념하여야 한다. 이하의 논의로부터 명백한 바와 같이 별도로 명확히 언급되지 않는 한, 본 개시를 통틀어, "수신하기"(receiving), "세이브하기"(saving), "유예하기"(suspending), "언로드하기"(unloading), "컴파일하기"(compiling), "재로드하기"(reloading), "재개하기"(resuming), "연관시키기"(associating), "실행하기"(executing), "제거하기"(removing), "릴리즈하기"(releasing), "예비하기"(reserving), "설정하기"(setting), "액세스하기"(accessing), "해방하기"(freeing), "제어하기"(controlling), "추가하기"(adding), "판정하기"(determining), "식별하기"(identifying) 또는 유사한 것과 같은 용어를 활용하는 논의는 컴퓨터 시스템 또는 유사한 전자 컴퓨팅 디바이스 또는 프로세서(가령, 도 1의 시스템(110))의 액션 및 프로세스(가령, 도 9의 흐름도(900))를 나타낸다는 점이 인식된다. 컴퓨터 시스템 또는 유사한 전자 컴퓨팅 디바이스는 컴퓨터 시스템 메모리, 레지스터, 또는 다른 그러한 정보 저장, 송신 또는 디스플레이 디바이스 내에 물리적 (전자적) 양으로서 표현되는 데이터를 조작하고 변형시킨다.

본 문서에서 기술되는 실시예들은 하나 이상의 컴퓨터 또는 다른 디바이스에 의해 실행되는, 프로그램 모듈과 같은, 어떤 형태의 컴퓨터 판독가능 저장 매체(computer-readable storage medium) 상에 상주하는 컴퓨터 실행가능 명령어(computer-executable instructions)의 일반적인 맥락에서 논의될 수 있다. 한정이 아니라 예로서, 컴퓨터 판독가능 저장 매체는 비일시적(non-transitory) 컴퓨터 판독가능 저장 매체 및 통신 매체를 포함할 수 있고, 비일시적 컴퓨터 판독가능 매체는 일시적인 전파 신호(propagating signal)를 제외한 모든 컴퓨터 판독가능 매체를 포함한다. 일반적으로, 프로그램 모듈은 특정한 작업을 수행하거나 특정한 추상적 데이터 유형을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등등을 포함한다. 프로그램 모듈의 기능성은 다양한 실시예에서 원하는 바와 같이 조합되거나 분산될 수 있다.

컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성(volatile) 및 비휘발성(non-volatile), 탈착가능(removable) 및 비탈착가능(non-removable) 매체를 포함한다. 컴퓨터 저장 매체는 랜덤 액세스 메모리(Random Access Memory: RAM), 판독 전용 메모리(Read Only Memory: ROM), 전기적 소거가능 프로그램가능 ROM(Electrically Erasable Programmable ROM: EEPROM), 플래시 메모리(flash memory) 또는 다른 메모리 기술, 콤팩트 디스크 ROM(Compact Disk ROM: CD-ROM), 디지털 다기능 디스크(Digital Versatile Disk: DVD) 또는 다른 광학 스토리지(optical storage), 자기 카세트, 자기 테이프, 자기 디스크 스토리지(magnetic disk storage) 또는 다른 자기 저장 디바이스, 또는 원하는 정보를 저장하는 데에 사용될 수 있고 그 정보를 색출하기(retrieve) 위해 액세스될 수 있는 임의의 다른 매체를 포함하나 이에 한정되지 않는다.

통신 매체는 컴퓨터 실행가능 명령어, 데이터 구조 및 프로그램 모듈을 구현화할 수 있고, 임의의 정보 전달 매체를 포함한다. 한정이 아니라 예로서, 통신 매체는 유선 네트워크(wired network) 또는 직접 유선 연결(direct-wired connection)과 같은 유선 매체와, 음향(acoustic), 무선 주파수(Radio Frequency: RF), 적외선(infrared) 및 다른 무선 매체와 같은 무선 매체를 포함한다. 위의 것들 중 임의의 것의 조합이 컴퓨터 판독가능 매체의 범주 내에 또한 포함될 수 있다.

도 1은 본 개시의 실시예를 구현할 수 있는 시스템 제어기(system controller)를 위한 컴퓨팅 시스템(110)의 예의 블록 다이어그램이다. 예를 들어, 컴퓨팅 시스템(110)은, 하나의 실시예에서, 테스터 시스템의 제어기를 구현할 수 있다. 컴퓨팅 시스템(110)은 컴퓨터 판독가능 명령어를 실행할 수 있는 임의의 단일 또는 다중 프로세서 컴퓨팅 디바이스 또는 시스템을 대략적으로 나타낸다. 컴퓨팅 시스템(110)의 예는 워크스테이션, 랩톱, 클라이언트측 단말, 서버, 분산 컴퓨팅 시스템, 또는 임의의 다른 컴퓨팅 시스템 또는 디바이스를 한정 없이 포함한다. 그것의 가장 기본적인 구성에서, 컴퓨팅 시스템(110)은 적어도 하나의 프로세서(114) 및 시스템 메모리(116)를 포함할 수 있다.

프로세서(114)는 데이터를 처리하는 것 또는 명령어를 해석하고 실행하는 것이 가능한 임의의 유형 또는 형태의 처리 유닛(processing unit)을 전반적으로 나타낸다. 어떤 실시예에서, 프로세서(114)는 소프트웨어 애플리케이션 또는 모듈로부터 명령어를 수신할 수 있다. 이 명령어는 프로세서(114)로 하여금 본 문서에서 기술되고/되거나 보여진 예시적 실시예 중 하나 이상의 기능을 수행하게 할 수 있다.

시스템 메모리(116)는 데이터 및/또는 다른 컴퓨터 판독가능 명령어를 저장하는 것이 가능한 임의의 유형 또는 형태의 휘발성 또는 비휘발성 저장 디바이스 또는 매체를 전반적으로 나타낸다. 시스템 메모리(116)의 예는 RAM, ROM, 플래시 메모리, 또는 임의의 다른 적합한 메모리 디바이스를 한정 없이 포함한다. 필수적인 것은 아니지만, 어떤 실시예에서 컴퓨팅 시스템(110)은 (가령, 시스템 메모리(116)와 같은) 휘발성 메모리 유닛도 (가령, 일차적 저장 디바이스(primary storage device)(132)와 같은) 비휘발성 저장 디바이스도 포함할 수 있다.

컴퓨팅 시스템(110)은 프로세서(114) 및 시스템 메모리(116) 외에도 하나 이상의 컴포넌트 또는 구성요소를 또한 포함할 수 있다. 예를 들어, 도 1의 실시예에서, 컴퓨팅 시스템(110)은 메모리 제어기(118), 입출력(Input/Output: I/O) 제어기(120) 및 통신 인터페이스(122)를 포함하는데, 이들 각각은 통신 인프라스트럭처(communication infrastructure)(112)를 통하여 상호연결될 수 있다. 통신 인프라스트럭처(112)는 컴퓨팅 디바이스의 하나 이상의 컴포넌트 간의 통신을 가능하게 할 수 있는 임의의 유형 또는 형태의 인프라스트럭처를 전반적으로 나타낸다. 통신 인프라스트럭처(112)의 예는 (산업 표준 아키텍처(Industry Standard Architecture: ISA), 주변 컴포넌트 상호연결(Peripheral Component Interconnect: PCI), PCI 익스프레스(PCI Express: PCIe), 또는 유사한 버스와 같은) 통신 버스 및 네트워크를 한정 없이 포함한다.

메모리 제어기(118)는 메모리 또는 데이터를 다루는 것 또는 컴퓨팅 시스템(110)의 하나 이상의 컴포넌트 간의 통신을 제어하는 것이 가능한 임의의 유형 또는 형태의 디바이스를 전반적으로 나타낸다. 예를 들어, 메모리 제어기(118)는 통신 인프라스트럭처(112)를 통하여 프로세서(114), 시스템 메모리(116) 및 I/O 제어기(120) 간의 통신을 제어할 수 있다.

I/O 제어기(120)는 컴퓨팅 디바이스의 입력 및 출력 기능을 코디네이트하기(coordinating) 및/또는 제어하기가 가능한 임의의 유형 또는 형태의 모듈을 전반적으로 나타낸다. 예를 들어, I/O 제어기(120)는 프로세서(114), 시스템 메모리(116), 통신 인터페이스(122), 디스플레이 어댑터(126), 입력 인터페이스(130) 및 저장 인터페이스(134)와 같은, 컴퓨팅 시스템(110)의 하나 이상의 구성요소 간의 데이터의 전송을 제어하거나 가능하게 할 수 있다.

통신 인터페이스(122)는 예시적 컴퓨팅 시스템(110) 및 하나 이상의 추가적인 디바이스 간의 통신을 가능하게 할 수 있는 임의의 유형 또는 형태의 통신 디바이스 또는 어댑터를 대략적으로 나타낸다. 예를 들어, 통신 인터페이스(122)는 컴퓨팅 시스템(110) 및 사설(private) 또는 공용(public) 네트워크(추가적인 제어 시스템을 포함함) 간의 통신을 가능하게 할 수 있다. 통신 인터페이스(122)의 예는 (네트워크 인터페이스 카드(network interface card)와 같은) 유선 네트워크 인터페이스, (무선 네트워크 인터페이스 카드와 같은) 무선 네트워크 인터페이스, 모뎀(modem), 그리고 임의의 다른 적합한 인터페이스를 한정 없이 포함한다. 하나의 실시예에서, 통신 인터페이스(122)는 인터넷과 같은 네트워크로의 직접 링크(direct link)를 통하여 원격 서버로의 직접 연결(direct connection)을 제공한다. 통신 인터페이스(122)는 임의의 다른 적합한 연결을 통해 그러한 연결을 간접적으로 제공할 수도 있다.

통신 인터페이스(122)는 외부 버스 또는 통신 채널을 통하여 컴퓨팅 시스템(110) 및 하나 이상의 추가적인 네트워크 또는 저장 디바이스 간의 통신을 가능하게 하도록 구성된 호스트 어댑터(host adapter)를 또한 나타낸다. 호스트 어댑터의 예는 소형 컴퓨터 시스템 인터페이스(Small Computer System Interface: SCSI) 호스트 어댑터, 범용 직렬 버스(Universal Serial Bus :USB) 호스트 어댑터, IEEE(전기 및 전자 엔지니어 협회(Institute of Electrical and Electronics Engineers)) 1394 호스트 어댑터, 직렬 고급 기술 부착(Serial Advanced Technology Attachment: SATA) 및 외부 SATA(External SATA: eSATA) 호스트 어댑터, 고급 기술 부착(Advanced Technology Attachment: ATA) 및 병렬 ATA(Parallel ATA: PATA) 호스트 어댑터, 파이버 채널(Fibre Channel) 인터페이스 어댑터, 이더넷(Ethernet) 어댑터, 또는 유사한 것을 한정 없이 포함한다. 통신 인터페이스(122)는 컴퓨팅 시스템(110)으로 하여금 분산 또는 원격 컴퓨팅에 관여하게 할 수도 있다. 예를 들어, 통신 인터페이스(122)는 원격 디바이스로부터 명령어를 수신하거나 실행을 위해 원격 디바이스로 명령어를 보낼 수 있다.

도 1에 예시된 바와 같이, 컴퓨팅 시스템(110)은 디스플레이 어댑터(126)를 통하여 통신 인프라스트럭처(112)에 커플링된 적어도 하나의 디스플레이 디바이스(124)를 또한 포함할 수 있다. 디스플레이 디바이스(124)는 디스플레이 어댑터(126)에 의해 전해지는 정보를 시각적으로 디스플레이할 수 있는 임의의 유형 또는 형태의 디바이스를 전반적으로 나타낸다. 유사하게, 디스플레이 어댑터(126)는 디스플레이 디바이스(124) 상의 디스플레이를 위한 그래픽, 텍스트(text) 및 다른 데이터를 전하도록 구성된 임의의 유형 또는 형태의 디바이스를 전반적으로 나타낸다.

도 1에 예시된 바와 같이, 컴퓨팅 시스템(110)은 입력 인터페이스(130)를 통하여 통신 인프라스트럭처(112)에 커플링된 적어도 하나의 입력 디바이스(128)를 또한 포함할 수 있다. 입력 디바이스(128)는 입력(컴퓨터로 생성된 것이든 아니면 인간에 의해 생성된 것이든)을 컴퓨팅 시스템(110)에 제공할 수 있는 임의의 유형 또는 형태의 입력 디바이스를 전반적으로 나타낸다. 입력 디바이스(128)의 예는 키보드(keyboard), 포인팅 디바이스(pointing device), 음성 인식 디바이스(speech recognition device), 또는 임의의 다른 입력 디바이스를 한정 없이 포함한다.

도 1에 예시된 바와 같이, 컴퓨팅 시스템(110)은 저장 인터페이스(134)를 통하여 통신 인프라스트럭처(112)에 커플링된 일차적 저장 디바이스(132) 및 백업 저장 디바이스(backup storage device)(133)를 또한 포함할 수 있다. 저장 디바이스(132 및 133)는 데이터 및/또는 다른 컴퓨터 판독가능 명령어를 저장할 수 있는 임의의 유형 또는 형태의 저장 디바이스 또는 매체를 전반적으로 나타낸다. 예를 들어, 저장 디바이스(132 및 133)는 자기 디스크 드라이브(가령, 소위 하드 드라이브), 플로피 디스크 드라이브, 자기 테이프 드라이브, 광학 디스크 드라이브, 플래시 드라이브, 또는 유사한 것일 수 있다. 저장 인터페이스(134)는 저장 디바이스(132 및 133)와 컴퓨팅 시스템(110)의 다른 컴포넌트 간에 데이터를 전송하기 위한 임의의 유형 또는 형태의 인터페이스 또는 디바이스를 전반적으로 나타낸다.

하나의 예에서, 데이터베이스(140)는 일차적 저장 디바이스(132) 내에 저장될 수 있다. 데이터베이스(140)는 단일의 데이터베이스 또는 컴퓨팅 디바이스의 일부를 나타낼 수 있거나 그것은 다수의 데이터베이스 또는 컴퓨팅 디바이스를 나타낼 수 있다.

도 1을 참조하여 계속하면, 저장 디바이스(132 및 133)는 컴퓨터 소프트웨어, 데이터, 또는 다른 컴퓨터 판독가능 정보를 저장하도록 구성된 탈착가능 저장 유닛으로부터 판독하고/하거나 이에 기록하도록 구성될 수 있다. 적합한 탈착가능 저장 유닛의 예는 플로피 디스크, 자기 테이프, 광학 디스크, 플래시 메모리 디바이스, 또는 유사한 것을 한정 없이 포함한다. 저장 디바이스(132 및 133)는 컴퓨터 소프트웨어, 데이터, 또는 다른 컴퓨터 판독가능 명령어가 컴퓨팅 시스템(110) 내에 로드되게 하기 위한 다른 유사한 구조 또는 디바이스를 또한 포함할 수 있다. 예를 들어, 저장 디바이스(132 및 133)는 소프트웨어, 데이터, 또는 다른 컴퓨터 판독가능 정보를 판독 및 기록하도록 구성될 수 있다. 저장 디바이스(132 및 133)는 컴퓨팅 시스템(110)의 일부일 수도 있거나 다른 인터페이스 시스템을 통해 액세스되는 별개의 디바이스일 수 있다.

많은 다른 디바이스 또는 서브시스템이 컴퓨팅 시스템(110)에 연결될 수 있다. 역으로, 도 1에 예시된 컴포넌트 및 디바이스 전부가 본 문서에 기술된 실시예를 실시하기 위해 존재할 필요는 없다. 앞서 언급된 디바이스 및 서브시스템은 도 1에 도시된 것과는 상이한 방식으로 상호연결될 수도 있다. 컴퓨팅 시스템(110)은 임의의 개수의 소프트웨어, 펌웨어 및/또는 하드웨어 구성을 사용할 수도 있다. 예를 들어, 본 문서에 개시된 예시적 실시예는 컴퓨터 판독가능 매체 상의 컴퓨터 프로그램(컴퓨터 소프트웨어, 소프트웨어 애플리케이션, 컴퓨터 판독가능 명령어 또는 컴퓨터 제어 로직으로 지칭되기도 함)으로서 인코딩될 수 있다.

컴퓨터 프로그램을 포함하는 컴퓨터 판독가능 매체는 컴퓨팅 시스템(110) 내에 로드될 수 있다. 그리고 컴퓨터 판독가능 매체 상에 저장된 컴퓨터 프로그램의 전부 또는 일부분은 시스템 메모리(116) 및/또는 저장 디바이스(132 및 133)의 여러 부분 내에 저장될 수 있다. 프로세서(114)에 의해 실행되는 경우, 컴퓨팅 시스템(110) 내에 로드된 컴퓨터 프로그램은 프로세서(114)로 하여금 본 문서에서 기술되고/되거나 보여진 예시적 실시예의 기능을 수행하고/하거나 이를 수행하는 수단이게 할 수 있다. 추가적으로 또는 대안적으로, 본 문서에서 기술되고/되거나 보여진 예시적 실시예는 펌웨어 및/또는 하드웨어로 구현될 수 있다.

예를 들어, 테스트 계획을 행하기 위한 컴퓨터 프로그램이 컴퓨터 판독가능 매체 상에 저장되고 이후 시스템 메모리(116) 및/또는 저장 디바이스(132 및 133)의 여러 부분 내에 저장될 수 있다. 프로세서(114)에 의해 실행되는 경우, 컴퓨터 프로그램은 프로세서(114)로 하여금 동시적 테스트 환경 내의 다수의 테스트 코어 간에 리소스를 공유하기 위해 요구되는 기능을 수행하고/하거나 이를 수행하는 수단이게 할 수 있다.

몇몇 개발 환경에서 발견되는 종래의 편집 및 계속 기능성은 여러 가지 제약을 가진다. 우선, 그것은 모든 유형의 코드와 관련하여 사용될 수는 없다. 예를 들어, 그것은 64 비트 코드를 디버그하는 경우 디버깅 환경 내에서 사용될 수 없다. 결과적으로, 성능상 이유로 64 비트 테스트 클래스 및 테스트 계획을 개발하는 테스터 소프트웨어의 많은 사용자가 이 특징을 이용할 수 없다.

둘째, 허용되는 코드 변경의 유형에 대한 제약이 있다. 예를 들어, 한 가지 단점은 그 특징을 사용하는 경우에 종래의 개발 환경은 상대적으로 사소한 코드 변경이 행해지게 할 뿐이라는 것이다. 전형적으로, 바뀐 코드 섹션은 재컴파일되고, 바뀐 코드에 대응하는 실행 메모리의 작은 부분은 스왑 아웃되고 새로운 코드를 사용하여 생성된 메모리의 새 블록으로 대체된다. 그 후에, 적절한 명령어 포인터가 이에 따라 설정된다.

그 특징은, 종래의 시스템 내에 설계된 것과 같이, 어떠한 복잡한 코드 변화도 다룰 수 없다. 결과적으로, 그것은 ATE를 위한 테스트 클래스의 개발자에게 그다지 유용하지 않다. 만약 사용자가 테스트 클래스의 준비에서 어떠한 상당한 오류라도 저지르거나 테스트 계획이 실행되고 있는 동안에 어떠한 다른 이유로든 테스트 클래스를 대체할 필요가 있는 경우, 그는 전형적으로는 테스트 계획을 중지하고 우선 그것을 언로드해야 한다. 그리고, 그는 코드 내의 원래의 지점에 돌아가기 전에 테스트 계획을 재로드하고 그것을 처음부터 재시작할 필요가 있을 것이다. 그러한 작업 흐름은 시간이 걸리고 오류가 생기기 쉽다.

이에 따라, 본 발명의 실시예는 사용자로 하여금 앞서 논의된 단계 모두를 수동으로 수행할 필요 없이 테스트 계획의 실행 중에 테스트 클래스에 대해 변경을 행하게 하는 자동화된 방법 및 시스템을 제공한다. 이는 개발자들로 하여금 그들이 종래의 시스템을 사용하여서 하게 되었던 것보다도 상당히 더 효율적이고 덜 오류가 생기는 방식으로 테스트 클래스를 준비하고 디버그하게 한다.

이 목표를 성취하기 위해서, 본 발명의 실시예는 테스터 소프트웨어 시스템 내에 편집 및 갱신 기능성을 제공한다. 디버깅 동안, 사용자는 시스템이 중지되게 하는 테스트 클래스 소스 코드 내 중단점을 설정할 수 있다. 사용자는 소스 코드를 편집할 수 있다(이로써 편집 및 갱신 세션을 개시함). 그리고 상태 정보는 저장되고 편집된 테스트 클래스는 언로드된다. 이후에, 편집 및 갱신 절차는 테스트 클래스의 편집된 버전을 재컴파일하고 원래의 버전을 새로 컴파일된 버전과 교체할 것이다. 그리고 편집된 테스트 클래스는 재실행되고 사용자가 디버깅을 그만둔 곳과 동일한 중단점으로 도로 자동으로 되돌려지며 이전에 저장된 상태 정보가 복원된다. 그리고 테스트 계획은 새로 편집된 코드로 계속될 수 있다.

본 발명의 실시예를 사용하여, 개발자는 테스트 클래스에 대해 상당한 변경을 행할 수 있고 그저 사소한 편집을 구현하는 것으로 한정되지 않는다. 사실, 본 발명의 하나의 실시예는 파일의 사소한 섹션만이 아니라 전체 테스트 클래스 파일을 변경하는 것을 지원한다.

도 2a는 본 발명의 하나의 실시예에 따라 편집 및 갱신 절차의 실시예가 구현될 수 있는 자동화된 테스트 장비(Automated Test Equipment: ATE) 장치에 대한 도식적인 블록 다이어그램이다. 하나의 실시예에서, 시스템 제어기(201)는 하나 이상의 링크된(linked) 컴퓨터를 포함한다. 예를 들어, 어드밴테스트 사의 T2000 테스터 군(family)과 같은 테스트 시스템은 컴퓨터들의 네트워크를 사용할 수 있다. 다른 실시예에서, 시스템 제어기는 종종 오직 단일 컴퓨터를 포함한다. 시스템 제어기(201)는 전체적인 시스템 제어 유닛이고, 사용자의 주된 테스트 계획을 행하는 것을 포함하여 모든 사용자 레벨 테스트 작업을 달성하는 것을 책임지는 ATE를 위한 소프트웨어를 구동한다(run). 그러한 테스터 소프트웨어의 하나의 예는 T2000 시스템 소프트웨어이다. 전형적으로, T2000과 같은 테스터 소프트웨어는 컴파일러를 포함하는데, 이는 테스터 시스템의 프로그래밍 언어, 가령 OPENSTAR 테스트 프로그래밍 언어(OPENSTAR Test Programming Language)("OTPL")로 기록된 테스트 계획을 컴파일한다.

통신기 버스(communicator bus)(215)는 시스템 제어기 및 테스터 하드웨어 간 고속 전자 통신 채널을 제공한다. 통신기 버스는 백플레인(backplane), 모듈 연결 인에이블러(module connection enabler), 또는 시스템 버스(system bus)로 지칭될 수도 있다. 물리적으로, 통신기 버스(215)는 전기적, 광학적 등등일 수 있는 빠른 고대역폭(high-bandwidth) 이중화 연결 버스(duplex connection bus)이다. 하나의 실시예에서, 통신기 버스(215)는 TCP/IP 프로토콜을 사용할 수 있다. 시스템 제어기(201)는 통신기 버스(215)를 거쳐 발신되는 명령을 통해 테스터 하드웨어를 프로그램함으로써 DUT(211 내지 214)를 테스트하기 위한 조건을 셋업한다.

테스터 하드웨어(202)는 테스트 자극(test stimulus)을 피테스트 디바이스(Device Under Test: DUT)(211 내지 214)에 제공하고 그 자극에 대한 DUT의 응답을 측정하며, 그것을 예기되는 응답에 대해 비교하는 데에 필요한 전자 및 전기 부품과 커넥터의 복합 세트(complex set)를 포함한다.

도 2b는 도 2a의 자동화된 테스트 장비 장치의 하나의 실시예의 더욱 상세한 도식적인 블록 다이어그램이다. 도 2b에 예시된 실시예에서, 테스터 하드웨어(202)는 다수의 사이트 제어기(270)를 포함할 수 있는데, 각 사이트 제어기는 다수의 DUT에 연결된다. 각 사이트 제어기는 디바이스 테스트에서 사용되는 컴퓨터이다. 테스트 계획 프로그램은 DUT(290)를 위한 디바이스 테스트를 수행하는 과정에서 테스트 모듈(280)을 제어하는 사이트 제어기 상에서 실행될 수 있다. 사이트 제어기(270)는 통신기 버스(215)를 통해서 사이트 제어기를 제어하는 시스템 제어기에 연결된다. 몇몇 실시예에서, 테스트 개발자는 사이트 제어기를 직접적으로 동작시킬 수 없으나, 대신에 개발자에 의해 수행되는 동작은 통신기 버스(215)를 통하여 사이트 제어기를 제어하는 시스템 제어기(201) 상에서 처리된다.

사이트 제어기(270) 및 테스트 모듈(280)은, 하나의 실시예에서, 고속 광학 버스를 통하여 연결될 수 있다. 버스 스위치(285)는 사이트 제어기를 테스트 모듈과 연결하기 위한 매트릭스 구조(matrix structure)를 가진다. 버스 스위치(285)를 사용하는 것은 사이트 제어기로 하여금 임의의 테스트 모듈(280)과 연결되게 하고, 버스 연결을 구성하는 데에서 융통성(flexibility)을 허용한다.

디바이스 테스트에 요구되는 테스트 모듈(280)은 전형적으로 테스트 시스템 테스트 헤드(test system test head) 내에 장착된다(mounted). 테스트 모듈 구성은 목표로 된 디바이스(targeted device)에 적응될(adapted) 수 있다. 디바이스 테스트에 요구되는 테스트 모듈(280)의 세트는 테스트 사이트(test site)라 불린다. 각 테스트 사이트(295)는 사이트 제어기에 의해 제어된다. 많은 애플리케이션을 위한 다양한 유형의 테스트 모듈이 있을 수 있다. 몇몇 예시적인 유형의 모듈은 동기 발생기 모듈(sync-generator module), 동기 매트릭스 모듈(sync-matrix module), 디바이스 전력 공급 모듈(device power supply module), 아날로그 모듈(analog module), RF 모듈 및 디지털 모듈(digital module)이다.

도 3은 상이한 테스트 인스턴스들이 단일의 테스트 클래스로부터 생성될 수 있는 방식에 관한 다이어그램을 보여준다. 앞서 상세히 논의된 바와 같이, 테스트 클래스는 해당 테스트의 특정한 인스턴스를 위한 옵션을 지정하기 위해 사용되는 파라미터를 제공함으로써 사용자로 하여금 클래스 작동을 구성하게 한다. 예를 들어, 기능적 테스트를 구현하기 위한 테스트 클래스는 테스트되는 DUT 상에서 실행될 테스트 패턴을 지정하기 위한 파라미터를 제공할 수 있다. 또한 그것은 테스트를 위한 레벨 및 타이밍 조건을 지정하기 위한 파라미터를 제공할 수 있다. 이들 파라미터에 대해 상이한 값들을 지정하는 것은 사용자로 하여금 기능적 테스트의 상이한 인스턴스들을 생성하게 한다.

T2000과 같은 테스터 소프트웨어 시스템에서, 앞서 논의된 바와 같이, 테스트 계획은 OTPL과 같은 테스트 프로그래밍 언어로 기술될 수 있다. OTPL은 테스트 실행 시퀀스 및 대응하는 피사용 테스트 조건을 기술하기 위해 사용될 수 있다. OTPL이 테스트 계획을 기술할 수 있으나, 그것은 전형적으로는 어떠한 테스트 알고리즘도 기술하지 않는다. T2000과 같은 시스템 내의 테스트 알고리즘은, 예컨대, 앞서 논의된 바와 같이 테스트 클래스 내에 C++ 언어를 사용하여 기술될 수 있다.

테스트 계획은 OTPL을 사용하여 개발되고 테스트 클래스는 C++을 사용하여 개발되는 T2000 테스터 소프트웨어의 맥락 내에 발명의 논의가 있으나, 본 발명은 이 실시예에 한정되지 않는다. 상이한 프로그래밍 언어를 사용하는 다른 유형의 테스터 소프트웨어가 다른 실시예에서 활용될 수 있다. 본 발명의 교시는 부기된 청구항에 의해 정의된 바와 같은 개시의 사상 및 범주 내에 포함될 수 있는 대안, 수정 및 균등물을 포섭할 수 있다는 점이 통상의 기술자에게 이해될 것이다.

도 3으로부터의 예에서, 테스트 클래스(310)는 테스트 "TestTypeX"의 세 개의 별개의 인스턴스를 생성하기 위해 사용될 수 있다. 세 개의 인스턴스인 인스턴스1(320), 인스턴스2(340) 및 인스턴스3(350) 각각은 테스트의 각 인스턴스를 위한 별개의 세트의 파라미터 데이터를 수신한다. 예를 들어, 인스턴스1(320)은 파라미터 데이터(330)를 수신하나, 나머지 인스턴스는 자기 자신의 세트의 파라미터를 수신한다.

도 4는 테스트 계획 내 테스트 클래스의 유효확인 및 실행을 보여주는 예시적인 소프트웨어 프로세스의 도식적인 블록 다이어그램이다.

하나의 실시예에서, 사용자는 다양한 테스트 클래스 및 다른 일반적 특성을 위한 필수 파라미터에 관한 모든 정보를 프리헤더 파일(pre-header file)(410) 내에 입력한다. 파라미터에 관한 정보는 파라미터의 명칭, 그것의 허용된 값, 그것의 유형 등등을 포함할 수 있다.

종래의 테스터 시스템에서, 테스터 시스템 소프트웨어는 생성된 소스 코드에의 포함을 위해 적절한 파라미터가 이용가능함을 확인하기 위한 메커니즘을 제공할 수 있다. 테스터 시스템 소프트웨어는 테스트 클래스 개발자로 하여금 그 개발자가 지시한(designate) 테스트 클래스의 공용 메소드(method)와 속성(attribute)이 그 클래스를 파라미터로 나타내는(parameterize) 데에 요구되는 것임을 테스트 클래스마다의 텍스트 기반 소스 파일(text-based source file per test class) 내에 완전히 지정하게 하는 방법을 제공한다. 그것의 메소드 및 속성을 텍스트 파일 내에 지정하는 것은 테스터 소프트웨어로 하여금 적절한 파라미터가 이용가능한지를 쉽게 판정하게 하는데, 이는 변환 단계(translation phase) 중 테스트 계획의 오류 체크 및 유효확인을 가능하게 한다. 종래의 ATE 시스템에서, 이 텍스트 기반 서술은 테스트 클래스를 위한 프리헤더 파일 내에 임베드되는데(embedded), 이는 테스트 클래스의 메소드 및 속성을 판정하기 위해 테스터 소프트웨어 내의 컴파일러에 의해 사용된다. 또한, 그것은 테스트 클래스를 위한 헤더를 생성하는 것을 위해 컴파일러에 의해 사용된다. 하나의 실시예에서, 테스트 클래스를 위한 헤더는, 테스트 클래스 그 자체와 유사하게, C++과 같은 종래의 프로그래밍 언어로 되어 있을 수도 있다. 생성된 C++ 헤더 파일은 테스트 클래스 C++ 코드를 최종적으로 컴파일하기 위해 사용되는 것이다.

논의된 바와 같이, 프리헤더 파일은 직접적으로 프리헤더 파일로부터 테스트 클래스 선언 C++ 헤더 파일(415)을 자동으로 생성하기 위해 테스터 시스템 소프트웨어에 의해 사용된다. 생성된 C++ 헤더 파일은 테스트 클래스 C++ 코드(435)를 최종적으로 컴파일하기 위해 사용되는 것이다. C++ 테스트 클래스 코드(435)는 테스터 시스템 소프트웨어(420) 내에서의 실행을 위해 로드될 수 있는 이진(binary) DLL 파일로 컴파일된다.

유효확인 단계(validation phase) 중에, 테스터 시스템 소프트웨어(420)("테스터 운영 시스템"(tester operating system)이라고 지칭되기도 함)는 오류에 대해서 테스트 계획 작성자(test plan author)에 의해 개발된 테스트 계획 OTPL 코드(450)를 읽어들이고 분석한다. 프리헤더 파일(410)은 테스트 클래스 및 테스트 클래스에 의해 필요로 되는 파라미터를 기술하기 위해 테스터 운영 시스템(420)에 의해 사용된다. 테스트 클래스를 기술함으로써, 프리헤더 파일은 테스터 시스템 소프트웨어(420)로 하여금 적절한 파라미터가 테스트 클래스의 다양한 인스턴스에 넘겨지고 있음을 유효확인하게(validate) 한다.

그리고 OTPL 코드(450)는 이진 DLL 테스트 클래스 파일(475)과 함께 테스터 시스템 소프트웨어(420) 내에 로드된다. 하나의 실시예에서, OTPL 코드(450)가 유효확인이 된 후, 테스트 계획 코드(450)는 이어서 테스트 클래스를 인스턴스화하며(instantiate) 테스트 클래스 인스턴스화를 위한 적절한 파라미터를 판정하기 위해 프리헤더 파일(410)로부터의 정보를 사용한다. 테스터 운영 시스템(420)은 프리헤더 파일(410) 내에 제공되는 정보에 기반하여 다양한 테스트 클래스를 위한 파라미터를 파퓰레이트할(populate) 수 있다. 예를 들어, 도 4에서, 테스터 운영 시스템은 OTPL 코드(450) 내에서 인스턴스화된 어떤 테스트 클래스를 위해 파라미터로서 사용될 수 있는 패턴 목록(490) 및 패턴(495)을 읽어들일 수 있다. 그리고 테스트 계획(425)은 테스터 시스템 소프트웨어(420)에 의해 실행된다.

도 5는 본 발명의 하나의 실시예에 따라 편집 및 갱신 기능성의 구현을 보여주는 예시적인 소프트웨어 프로세스의 블록 다이어그램이다.

하나의 실시예에서, 블록(501)에서, 사용자는 개발 환경, 가령 비주얼 스튜디오(Visual Studio)를 기동하고(launch) 사용자가 애플리케이션을 사용하여 디버그하기를 원하는 테스트 클래스 프로젝트(test class project)를 로드한다. 블록(502)에서, 사용자는 테스터 시스템 소프트웨어(Tester System Software)("TSS")를 시작한다. TSS가 시작된 후, 사용자는 503에서 테스트 계획 또는 테스트 프로그램을 로드한다. 그리고 사용자는 디버깅 세션을 시작하기 위해 블록(504)에서, 테스트되고 있는 DUT에 연결될 수 있는 사이트 제어기에 디버거를 접속한다(attach). 사용자는 또한 그가 디버그하기를 원하는 테스트 클래스의 메소드 내에 중단점을 설정한다. 예를 들어, 사용자는 블록(508)에 도시된 바와 같이 흐름항목2(FlowItem2)(519)를 포함하는 메소드 중 하나인 "preExec()"라 불리는 메소드 내에 중단점을 설정할 수 있다. 흐름항목(519)을 포함하는 다른 예시적인 메소드들은 각각 블록(509) 및 블록(510)에서의 "execute()" 및 "postExec()"이다.

그리고 사용자는 블록(505)에서 테스트흐름을 실행할 것이다. 제 1 흐름 항목인 흐름항목1(FlowItem1)은 블록(518)에서 우선 실행된다. 그러나, 블록(519)에서의 흐름항목2의 실행 중에, 디버거는 블록(508)에서 preExec() 내의 중단점에서 중단될 것이고, 소스 코드는 디버깅 환경의 코드 윈도우(code window) 내에서 가시적일 수 있다. 이 지점에서, 코드에 대해 편집이 행해질 필요가 있는 지점에 사용자가 도달할 때까지 사용자는 코드를 거쳐 한 단계씩 나아갈(single step) 수 있다. 사용자는 테스트 클래스 프로젝트와 연관된 동일한 파일 또는 다른 파일 내에서 코드에 대해 편집을 행할 수 있다. 하나의 실시예에서, 편집을 행하는 것 대신에, 사용자는 단지 디버거를 그만두고 실행을 계속할 수도 있다.

만약 편집이 행해지는 경우에는, 편집을 완료한 후, 사용자는 블록(516)에서 편집 및 갱신 절차(edit and update procedure)를 호출할 수 있다. 예를 들어, 사용자는 흐름 항목2를 실행하는 경우에 preExec() 내부의 메소드 "AAA()"에서 편집 및 갱신을 호출할 수 있다. 하나의 실시예에서, 편집 및 갱신 절차가 호출되는 경우, 디버그되고 있는 전체 테스트 클래스 메소드, 즉 preExec(), execute() 및 postExec()의 실행은 테스터 운영 시스템이 블록(511)에서 유예되기 전에 완료될 것이다. 다른 실시예에서, 편집 및 갱신 절차는 테스트 흐름 항목 내의 나머지 메소드의 실행을 마치지 않고 곧바로 유예할 수 있다. 이 실시예에서, 사용자는 임의의 나머지 테스트 클래스 코드를 실행하는 것을 즉시 건너뛰어(skip) 나가고 이후 테스트 클래스의 재빌드하기(rebuilding)와 재로드하기를 허용하기 위해 테스트 계획의 실행을 유예할 수 있다.

하나의 실시예에서, 편집 및 갱신 절차는 그것이 호출되었던 라인(line)을 추적할 수 있어서, 그것은 테스트 클래스가 갱신되고 재로드된 후 사용자를 동일한 라인(이하에서는 "현재 라인"으로 지칭됨)으로 복귀시킬 수 있다.

블록(512)에서, 디버거는 블록(504)에서 그것이 접속되었던 사이트 제어기로부터 분리된다(detached). 사이트 제어기(270)는 전형적으로는 테스트 클래스가 실행되고 있는 곳이다. 시스템 제어기(201)는 전형적으로는 개발 환경이 구동되는 곳이다. 따라서, 사용자는 전형적으로는 사이트 제어기(270) 상에 시스템 제어기(201)로부터의 원격 디버깅 세션을 구현하고 있다.

디버거는 블록(512)에서 사이트 제어기로부터 분리되고, 발효된(effected) 테스트 클래스는 언로드된다. 도 5의 예에서, 흐름항목2(519)와 연관된 어떠한 테스트 클래스든, 그리고 그것으로부터 상속되는(inherit) 어떠한 다른 클래스든 언로드될 필요가 있을 것이다. 이는 만약 그 절차가 어떤 발효된 "기반"(base) 클래스에 관해서 메모리를 변경할 것인 경우, 그것은 또한 기반 테스트 클래스에 종속하는 다른 "파생된"(derived) 클래스에 관해서 메모리를 변경할 필요가 있기 때문이다. 따라서, 편집 및 갱신 절차는 우선 모든 파생된 테스트 클래스를 식별할 필요가 있다. 다음으로, 기반 테스트 클래스 및 기반 테스트 클래스에 의존하는 모든 파생된 테스트 클래스는 언로드될 것이다. 테스트 클래스들은 이 시기(stage)에 DLL들이기 때문에, 그것들이 편집되고 갱신될 수 있기 전에 그것들은 언로드될 필요가 있다. 발효된 테스트 클래스 DLL들을 언로드하지 않고, 실행가능한 테스트 계획(이는 그것의 유예된 상태(suspended state) 내에 있음)은 여전히 그것들에 대한 핸들(handle)을 가지는데, 이는 그것들에 기록이 되는 것을 막는다.

블록(513)에서, 편집 및 갱신 절차는 개발 환경의 코드 윈도우 내에서 수정된 소스 테스트 클래스 파일을 세이브하고 이어서 새로운 DLL을 생성하기 위해 테스트 클래스 프로젝트를 컴파일한다. 새 DLL은 시스템 제어기(201)로부터 사이트 제어기(270)에게로 송신된다. 수정된 기반 테스트 클래스를 위한 DLL 외에도, 파생된 테스트 클래스를 위한 DLL이 생성되어 사이트 제어기(270)에 송신될 필요가 또한 있을 것이다.

만약 테스트 클래스 프로젝트가 성공적으로 컴파일되는 경우, 갱신된 테스트 클래스 DLL은 단계(514)에서 도로 재로드될 것이다. 대안적으로, 하나의 실시예에서, 갱신된 테스트 클래스 DLL을 편집된 테스트 클래스 파일로부터 생성하는 대신, 테스트 클래스 파일의 새 버전이 시스템 제어기(201) 상에서 생성되어 컴파일되고 이후에 사이트 제어기(270)에게로 송신될 수 있어서, 그것은 TSS 내에 도로 재로드될 수 있다. 테스트 클래스 DLL을 재로드하는 것은 새 테스트 클래스 DLL을 사용하여 원래 설정되었던 동일한 테스트 파라미터 값으로써 디버그되고 있는 테스트 클래스의 테스트 인스턴스를 파퓰레이트하는 것을 포함한다. 추가로, 그것은 또한 모든 파생된 테스트 클래스의 인스턴스를 파퓰레이트하는 것도 의미한다.

블록(515)에서, 디버거는 이전 디버그 세션에서 디버그되고 있었던 동일한 사이트 제어기로 도로 접속된다. 편집 및 갱신 절차는, 하나의 실시예에서, 편집 및 갱신 절차가 개시되었던 때에 명령어 포인터(instruction pointer)가 정지되었던 "현재 라인"에서 중단점을 설정할 것이다. 도 5의 예에서, 중단점은 메소드 AAA()에서 설정될 것이다. 설정될 수 있었던 더 이전의 중단점 대신에 편집 및 갱신 프로세스가 호출되었던 코드 내 현재 라인으로 사용자가 복귀될 수 있도록 이전의 디버그 세션에서 사용되었던 다른 중단점은 일시적으로 불능화될(disabled) 것이다. 상이한 실시예에서는, 테스트 클래스를 편집하는 동안 현재 라인이 제거되었을 수 있기에 중단점을 제어하는 다른 방식이 제공될 수 있다. 예를 들어, 사용자는 테스트 클래스 코드 내의 현재 라인 전 가장 가까운 라인으로 복귀될 수 있다. 또는 사용자는 현재 라인을 포함하는 함수의 처음으로 복귀될 수 있다.

이후에, 갱신된 테스트 클래스와 연관된 흐름 항목인 흐름 항목2는 TSS에 의해 재실행되고 그 실행은 현재 라인에서, 즉 메소드 AAA()에서 디버거 내에서 중단될 것이다. 그리고 편집 및 갱신 절차는 사용자에 의해 설정된 일시적으로 불능화된 중단점 전부를 복원할 것이다. 그 후, 편집 및 갱신 프로세스는 블록(517)에서 끝난다. 편집 및 갱신 세션은 전형적으로는 실행할 편집 및 갱신 절차를 사용자가 선택하는 시점부터, 편집 및 갱신이 호출되었던 때에 사용자가 멈췄던 지점부터 또는 그 지점 가까이에서 그 디버그된 흐름 항목이 재실행되려는 참인 시점까지 지속되는 것으로 정의될 수 있다.

편집 및 갱신 프로세스가 종료한 후, 만약 사용자가 실행을 계속하기로 택한 경우 TSS는 흐름의 실행을 재개한다. 따라서, 사용자는 블록(519)에서 흐름 항목2를, 그리고 블록(520)에서 흐름 항목3을 실행하는 것을 마치기로 택할 수 있다.

흐름이 실행되는 것이 마쳐진 후, 사용자는 블록(506)에서 TSS를 중지하기로 택하고 블록(507)에서 개발 환경을 닫아버리기(shut down)로 택할 수 있다.

앞서 논의된 바와 같이, 편집 및 갱신 기능성의 이점 중 하나는 테스터 소프트웨어 시스템의 사용자로 하여금 전체 테스트 계획이 재로드될 것을 요구하지 않고 또 테스트 클래스 수정을 달성하기 위해 수동으로 일련의 단계를 거쳐갈 부담을 사용자에게 지우지 않고 디버깅 환경에서 자신의 테스트 클래스 코드를 편집하고 자신의 테스트를 재구동하게(re-run) 한다는 것이다. 또한, 테스트 클래스 DLL이 언로드되기 때문에, 종래의 "편집 및 계속" 절차와 달리, 사용자는 테스트 클래스의 코드에 대해 훨씬 더 상당한 변경을 행하고 몇몇 경우에는 심지어 전체 테스트 클래스 코드를 대체하는 융통성을 가진다.

또한, 테스트 계획의 유예를 허용함으로써, 테스트 클래스는 언로드되고 재로드될 수 있으며, 사용자는 사용자가 편집을 행하기 시작했고 편집 및 갱신 절차를 호출했던 때에 그가 정지하였던 곳인 코드 내의 동일한 라인에서 코드를 디버깅하는 것을 재개하도록 복귀될 수 있다. 비교하면, 편집 및 갱신 절차를 사용하지 않고 테스트 클래스를 갱신하고자 하는 사용자라면 테스트 클래스를 편집하기 위해 완전히 테스트 계획의 실행을 취소할 필요가 있을 것이다. 테스트 계획의 실행이 취소되는 경우, 사용자는 준비 상태(ready state)로 복귀되는데, 이는 테스트 계획의 처음부터 실행을 시작하는 것을 수반한다. 테스트 계획의 처음부터 실행하는 것은, 특히 사용자가 갱신한 흐름 항목이 테스트 계획의 끝 쪽이었던 경우에, 상대적으로 번거로울 것이다. 다른 한편으로는, 편집 및 갱신 절차는 사용자로 하여금 단지 편집된 테스트 클래스의 처음에서 시작하고 편집 및 갱신 절차가 호출되었던 때에 사용자가 실행하고 있던 테스트 흐름 항목 내의 현재 라인으로 복귀하게 한다.

더욱이, 편집 및 갱신 기능성을 사용하는 것은 유리하게도 테스터 상태가 유지되게끔 하는데, 테스트 계획이 취소되는 것이 아니라 그저 유예되어 있기 때문이다. 만약 테스트 계획이 취소되고 처음부터 실행이 시작될 필요가 있는 경우, 테스터 상태는 시스템이 결정론적(deterministic)이지 않으면 유지되지 않을 수 있다. 예를 들어, 만약 사용자가 디바이스를 디버그하고 있는 경우, 테스트 중 디바이스 상태에서의 작은 변화, 가령 디바이스의 가열(heating up) 또는 냉각(cooling down)은 테스트으로 하여금 상이한 결과를 산출하게 할 수 있다. 그러므로, 테스트 중에 DUT가 어떻게 작동하는지(behave)에 따라 사용자는 결코 실제로 특정한 흐름 항목으로 돌아오지 않을 수 있다. 테스트 계획 내의 사용자의 위치(location)가 결코 변하지 않고, 테스트 계획은 그저 유예되며, 테스트 클래스가 도로 재로드된 후 사용자는 테스트 계획 내의 종전과 동일한 위치로 복귀되기 때문에 편집 및 갱신 기능성을 사용하는 것은 이 문제를 방지한다. 앞서 논의된 바와 같이, TSS는 디버깅 세션 도중에 테스트 클래스 코드에 대해 수정을 행하고 테스트 계획을 언로드하지 않고서 계속해서 디바이스를 테스트할 능력을 사용자에게 제공한다.

도 6은 본 발명의 하나의 실시예에 따라 사용자가 편집 및 갱신 기능성을 위한 다양한 설정을 셋업하게 하는 화면상 그래픽 사용자 인터페이스 구성 다이얼로그 박스를 보여준다. 도 6에 도시된 바와 같은 구성 다이얼로그 박스 내에서 코드 갱신 모드(Code Update Mode)라는 라벨(680)이 있는 라디오 버튼 그룹(radio button group)은 사용자가 편집 및 갱신(edit and update)(605), 종래의 "편집 및 계속"(edit and continue)(615) 또는 하나도 안 함(none)(640) 중에서 택하게 하기 위해 세 개의 라디오 버튼을 제공할 수 있다. 하나도 안 함(640) 옵션은 사용자로 하여금 갱신이 행해지는 경우 편집된 코드를 디버그하는 것을 계속하게 한다. 물론, 앞서 언급된 바와 같이, "편집 및 계속"이 그것의 다양한 제약, 가령 64 비트 환경으로 인해 사용될 수 없는 상황에서, "편집 및 계속" 라디오 버튼은 불능화될 것이고 따라서 그러한 구성에서 선택될 수는 없다.

하나의 실시예에서, 편집 및 갱신은 구성 다이얼로그 박스 내의 옵션(610)을 선택함으로써 디버그 명령에 의해 호출될 수 있다. 이는 사용자가 디버그 기능, 가령 단계 실행(step execution), 연속적 실행(continuous execution) 등등을 사용하여 개발 환경 내에서 테스트 클래스를 실행하는 경우마다 편집 및 갱신이 자동으로 호출될 것임을 의미한다. 달리 말하면, 만약 디버그 중인 현재의 테스트 클래스 또는 그것의 파생적 테스트 클래스에 관련된 어떠한 코드 변경이라도 있으면, 사용자가 테스트 실행을 계속하기 위해 임의의 디버그 명령을 사용하는 경우 편집 및 갱신이 자동으로 호출될 것이다.

하나의 실시예에서, 사용자는 중단점 엔트리 모드(breakpoint entry mode)(690)를 선택하도록 허용될 수도 있다. 중단점 엔트리 모드는 사용자로 하여금 디버깅의 제어가 사용자에게 복귀될 지점을 선택하게 한다. 만약 사용자가 현재 라인(current line) 옵션(615)을 선택하는 경우, 일단 디버거가 정지되고 모든 다른 중단점이 일시적으로 불능화되면 현재 라인으로의 중단점이 추가될 것이다. 흐름 항목이 재실행되는 경우, 이 중단점이 마주치게 될(hit) 것이고 일시적으로 불능화된 중단점 전부를 재가능화(re-enabling)한 후 도로 사용자에게 제어가 주어질 것이다.

만약 사용자가 현재 라인 대신에, 현재 함수의 처음(beginning of current function) 옵션(620)을 선택하는 경우, 현재 라인을 포함하는 함수의 시작 중괄호(opening brace)에 중단점이 추가될 것이다. 이 중단점에서 중단점이 마주치게 된 후, 편집 및 갱신 세션의 시작에서 일시적으로 불능화되었던 모든 다른 중단점은 가능화될(enabled) 것이다.

만약 사용자가 임의의 이전의 중단점(any previous breakpoints) 옵션(625)을 선택하는 경우, 테스트 클래스가 재로드된 후, 편집 및 갱신이 호출된 이전의 디버그 세션에서 사용자가 설정한 모든 중단점은 가능화될 것이다. 또한, 어떠한 추가적인 중단점도 추가되지 않을 것이다. 흐름 항목이 재시작되는 경우, 모든 중단점이 가능화되었으므로, 만약 중단점을 포함하는 어떠한 라인이든 실행되면, 흐름 항목의 실행은 거기에서 정지될 것이다.

앞서 논의된 바와 같이, 편집 및 갱신 세션은 전형적으로는 실행할 편집 및 갱신 절차를 사용자가 선택하는 시점부터 디버그된 흐름 항목이 재실행되려고 하는 시점까지 지속하도록 정의될 것이다. 도 7은 본 발명의 하나의 실시예에 따라 편집 및 갱신 세션의 라이프사이클을 보여주는 블록 다이어그램이다. 도 7에 보여진 바와 같이, 편집 및 갱신 세션은 하나보다 많은 디버그 세션에 의해 중첩될(overlapped) 수 있다.

도 7에서, 편집 및 갱신 세션(725)은 두 개의 디버그 세션(710 및 745)에 의해 중첩된다. 테스트 클래스 DLL은 두 개의 디버그 세션(710 및 745) 사이에서 컴파일되고 재로드된다. 디버그 세션(710)이 단계(705)에서 시작한 후 편집 및 갱신 세션(725)은 단계(715)에서 호출된다. 디버그 세션(710)은 단계(720)에서 종료하고(exit) 단계(780)에서 사이트 제어기로부터 분리된다. 디버거가 분리된 후, 수정된 기반 클래스 및 그것의 파생적 클래스는 730에서 컴파일되고 재로드된다. 재로드에 이어서, 디버그 세션(745)이 단계(785)에서 사이트 제어기에 접속되고 사용자에 의해 선택된 중단점에 도달될 때까지 수정된 기반 클래스가 735에서 재구동된다. 그 지점에서, 편집 및 갱신 프로세스는 740에서 완료되고 TSS는 테스트 흐름의 실행을 재개할 수 있다. 전형적으로 사용자는 어느 때든 단 하나의 편집 및 갱신 세션을 호출하도록 되어 있다는 점에 유의하여야 한다.

하나의 실시예에서, 테스트 클래스 작성자는 동시적인 흐름 항목 내의 분기 흐름의 일부인 흐름 항목 내에서 편집 및 갱신 절차를 사용하도록 허용된다. 다수의 흐름 아이템이 병렬로 실행 중인 구성에서 테스트 클래스 코드를 디버그하는 경우, 디버그되고 있는 것을 제외한 모든 흐름 실행은 완료될 것이고 다음 스케줄링된 흐름 항목 실행(들)은 편집 및 갱신 세션이 끝날 때까지 시작되지 않을 것이다. 달리 말해, 디버거가 중단점을 마주치는 경우 병렬로 진행되고 있던 모든 흐름 실행이 우선 완료될 것이나, 편집 및 갱신 프로세스가 끝날 때까지는 어떠한 다른 스케줄링된 흐름 항목도 실행되기 시작하지 않을 것이다. 동시적인 분기 내에서 실행되고 있는 테스트 클래스를 위해 편집 및 갱신을 사용하는 것은 다른 분기가 전체적인 현재 흐름 항목의 실행을 완료한 후에만 수정된 DLL의 재로드하기를 초래할 것이다.

도 8은 동시적 흐름 항목 내의 분기 흐름의 일부인 흐름 항목 내에서의 편집 및 갱신 절차의 호출을 보여주는 흐름 다이어그램이다. 도 8의 단계 1은 P(801) 및 A(803)도 정지된 동안 흐름 항목 Y(802)와 연관된 테스트 클래스 내의 중단점에서 사용자가 멈춘 시점을 예시한다. TSS는 디버그되고 있는 Y(802)-Z(804) 분기, 즉 중단점이 맞닥뜨려진(encountered) 분기의 흐름 실행을 유예하고, 디버거에 의해 또한 정지되었던 다른 동시적인 스레드(thread)를 재개할 것이다. 다른 분기(즉, P(801) 분기 및 A(803)-B(805) 분기)는 현재 실행되는 흐름 항목을 완료하도록 허용될 것이다.

도 8의 단계 2는 Y(802)가 아직 완료되지 않았으나 그것의 테스트 클래스 DLL(들)이 재빌드되고 재로드되도록 하기 위해 유예되는 동안 개시되어 있는 편집 및 갱신 동작의 결과로서 P(801) 및 A(803)이 실행을 완료한 지점을 예시한다.

도 8의 단계 3은 다른 분기의 흐름 항목 B(805)가 실행되기 시작하는 동안 편집 및 갱신 절차가 완료되었고 Y(802)가 재실행된 후의 지점을 예시한다. 하나의 실시예에서, 다른 동시적인 분기 내의 흐름 항목들, 가령 P(801) 및 A(803)은 언로드-컴파일-재로드 테스트 클래스 사이클 후 재테스트되지 않는데 사용자가 편집 및 갱신 절차를 개시하였으나 디버그되고 있는 활성 스택(active stack) 내에 그것들이 있지 않기 때문이다. TSS가 "편집 및 갱신"을 호출한 흐름 항목을 재실행하기 시작하는 경우, TSS는 이들 다른 분기의 실행을 그것들의 각자의 유예 지점부터 계속할 것이다.

하나의 실시예에서, 편집 및 갱신 절차는 테스터의 상태를 보존하도록 안전한 방식으로 모든 오류 조건을 다루도록 구성된다. 예를 들어, 만약 편집 및 갱신 프로세스가 어떠한 이유(가령, 편집된 테스트 클래스 코드를 컴파일하는 경우에 발생하게 된 컴파일 오류(compilation error))로든 인터럽트되는(interrupted) 경우, 사용자는 컴파일 오류를 고친 후 자발적으로 편집 및 갱신 세션을 계속하기를 원할 수 있다. 대안적으로, 만약 수리(fix)는 테스트 계획 파일이 수정될 것을 요구하고 따라서 테스트 계획의 재로드하기를 요구한다는 점을 사용자가 인지하는 경우 사용자는 세션을 중단시키기를 원할 수 있다. 그러므로, 사용자는 편집 및 갱신 세션을 시작하고 진행 중인(ongoing) "편집 및 계속" 세션을 계속하거나 아니면 중단시킬 능력을 제공받는다.

사용자가 편집 및 갱신 동작을 중단시키고 전체 테스트 계획을 재로드하기로 결정한다면, 또는 알람(alarm)이나 예기치 않은 예외(unexpected exception)가 발생하게 되는 경우에 TSS가 진행 중인 세션을 중단시킨다면, 시스템 상태는 중단시키기가 일어나는 시간에 달려 있을 것이다. 예를 들어, 만약 중단시키기가 유예 상태에 진입하기 전에 일어나는 경우(즉 TSS가 테스트 계획 실행을 재개하였으나 모든 흐름 실행 분기가 유예되기 전임), 테스트 계획 실행은 취소될 것이고 편집 및 갱신 동작도 취소될 것이다. 디버거는 이 경우에 사이트 제어기에 여전히 접속되어 있을 것이고 더 오래된 테스트 클래스 DLL은 여전히 로드되어 있을 것이다. 이전에 불능화된 중단점은 재가능화될 것이고, 사용자가 이 테스트 클래스를 디버그하기 위해서, 사용자는 흐름 항목을 재실행할 필요가 있을 것이다. 유사하게, 다른 상황에서는, 편집 및 갱신 동작이 중단되는 때에 따라, 시스템 소프트웨어는 일관된 테스터 상태를 유지하기 위해 요구되는 모든 필요한 부기(bookkeeping) 단계를 수행하도록 구성된다.

전형적으로, 흐름 항목은 활성 DUT의 세트(set)로써 시작된다. 하나의 실시예에서, 사용자는 편집 및 갱신을 호출하기 전에 테스트 클래스 코드 내에서 명시적으로 몇몇 DUT를 거부하거나(reject) 아니면 몇몇 DUT를 홀드 상태(hold state)에 둘 수 있다. TSS가 흐름 항목을 재실행하기 시작하는 경우, TSS는 다시 그 항목을 도로 어떤 측정가능한 DUT 상태로 보류할 것이다. 따라서, 흐름 항목을 재실행하는 경우, 테스트 클래스 코드에 의해 명시적으로 거부된 DUT를 제외하고, 이전의 실행에서 사용된 동일한 세트의 DUT가 사용될 것이다.

도 9는 본 발명의 하나의 실시예에 따라 편집 및 갱신 기능성을 구현하기 위한 예시적인 컴퓨터 제어된 프로세스의 흐름도(900)를 묘사한다.

단계(901)에서, 사용자는 테스트 클래스 코드를 편집하고 편집 및 갱신 절차를 호출한다.

단계(902)에서, 앞서 도 5와 관련하여 논의된 바와 같이 그 절차는 기반 클래스 및 기반 테스트 클래스에 종속하는 모든 파생된 테스트 클래스를 식별한다. 이후에, 단계(902)에서, 테스트 계획이 유예되고 상태 정보가 저장된다. 예를 들어, 하나의 실시예에서, 사용자가 편집 및 갱신 절차를 호출한 라인을 포함하는 상태 정보가 저장된다. 하나의 실시예에서, 테스트 계획은 나머지 테스트 클래스(이로부터 편집 및 갱신 기능성이 호출되었음)의 실행을 마친 후 유예될 수 있다. 다른 실시예에서, 사용자는 임의의 나머지 테스트 클래스 코드를 실행하는 것으로부터 즉시 건너뛰어 나가고 테스트 계획의 실행을 유예할 수 있다.

단계(904)에서, 디버거는 사이트 제어기(270)로부터 분리되고 발효된 기반 및 파생 테스트 클래스는 언로드된다.

단계(906)에서, 편집 및 갱신 절차는 개발 환경의 코드 윈도우 내에서 수정된 소스 테스트 클래스 파일을 세이브하고 이후 하나 이상의 새 DLL을 생성하기 위해 테스트 클래스 프로젝트를 컴파일한다. 새 DLL(들)은 시스템 제어기(201)로부터 사이트 제어기(270)에게로 송신된다. 수정된 기반 테스트 클래스를 위한 DLL 외에도, 파생된 테스트 클래스를 위한 DLL이 생성되어 사이트 제어기(270)에 송신될 필요도 있을 것이다.

만약 테스트 클래스 프로젝트가 성공적으로 컴파일되는 경우, 갱신된 테스트 클래스 DLL은 단계(908)에서 도로 재로드될 것이고 이전 디버그 세션에서 디버그되고 있던 동일한 사이트 제어기에 도로 디버거가 접속된다. 테스트 클래스 DLL을 재로드하는 것은 원래 설정되었던 동일한 테스트 파라미터 값으로써 그리고 새로운 테스트 클래스 DLL을 사용하여 디버그되고 있는 테스트 클래스의 테스트 인스턴스를 파퓰레이트하는 것을 포함한다. 추가로, 그것은 또한 모든 파생된 테스트 클래스의 인스턴스를 파퓰레이트하는 것도 의미한다.

단계(910)에서, 편집 및 갱신 절차는, 하나의 실시예에서, 이전의 디버그 세션에서 사용되었던 모든 중단점을 일시적으로 불능화하여서 사용자는 편집 및 갱신 프로세스가 호출되었던 코드의 인근에 또는 코드 내의 현재 라인에 복귀될 수 있다. 단계(912)에서, 절차는 편집 및 갱신 절차가 개시되었던 때에 명령어 포인터가 정지된 "현재 라인"에서 중단점을 설정할 것이다. 상이한 실시예에서, 앞서 상술한 바와 같이 사용자가 복귀되는 중단점을 제어하기 위한 다른 방식이 제공될 수 있다.

이후에, 갱신된 테스트 클래스와 연관된 흐름 항목은 TSS에 의해 단계(914)에서 테스트 클래스 인스턴스의 처음부터 재실행된다. 단계(916)에서, 그 실행은 디버거 내에서 현재 라인이나 사용자가 중단점 엔트리 모드 선택(690)을 통해 복귀하기로 이전에 택했던 다른 위치에서 중단될 것이다. 단계(918)에서, 이어서 편집 및 갱신 절차는 사용자에 의해 설정되었던 모든 일시적으로 불능화된 중단점을 복원할 것이다. 그 후, 편집 및 갱신 프로세스는 끝난다.

앞의 개시는 특정 블록 다이어그램, 흐름도 및 예를 사용하여 다양한 실시예를 개진하나, 본 문서에서 기술되고/되거나 보여진 각각의 블록 다이어그램 컴포넌트, 흐름도 단계, 동작 및/또는 컴포넌트는, 개별적으로 및/또는 집합적으로, 광범위한 하드웨어, 소프트웨어, 또는 펌웨어(또는 이들의 임의의 조합) 구성을 사용하여 구현될 수 있다. 추가로, 많은 다른 아키텍처가 동일한 기능성을 달성하기 위해 구현될 수 있기 때문에 다른 컴포넌트 내에 포함된 컴포넌트의 어떠한 개시든 예로 간주되어야 한다.

본 문서에 기술되고/되거나 보여진 프로세스 파라미터 및 단계의 시퀀스는 단지 예로서 주어진다. 예를 들어, 본 문서에 보여지고/지거나 기술된 단계가 특정한 순서로 도시되거나 논의될 수 있으나, 이들 단계는 반드시 보여지거나 논의된 순서로 수행될 필요가 있는 것은 아니다. 본 문서에 기술되고/되거나 보여진 다양한 예시적 방법은 본 문서에 기술되거나 보여진 단계 중 하나 이상을 생략하거나, 개시된 것 외에 추가적인 단계를 포함할 수도 있다.

다양한 실시예가 온전히 기능적인 컴퓨팅 시스템의 맥락에서 본 문서에 기술되고/되거나 보여졌으나, 이 예시적 실시예 중 하나 이상은 다양한 형태로 프로그램 제품으로서 배포될 수 있는데, 실제로 그 배포를 수행하기 위해 사용되는 컴퓨터 판독가능 매체의 특정한 유형에는 상관없다. 본 문서에 개시된 실시예는 어떤 작업을 수행하는 소프트웨어 모듈을 사용하여 구현될 수도 있다. 이들 소프트웨어 모듈은 스크립트(script), 배치(batch) 또는 다른 실행가능 파일(컴퓨터 판독가능 저장 매체 상에 또는 컴퓨팅 시스템 내에 저장될 수 있음)을 포함할 수 있다. 이들 소프트웨어 모듈은 컴퓨팅 시스템을 본 문서에 개시된 예시적 실시예 중 하나 이상을 수행하도록 구성할 수 있다. 본 문서에 개시된 소프트웨어 모듈 중 하나 이상은 클라우드 컴퓨팅 환경(cloud computing environment) 내에 구현될 수 있다. 클라우드 컴퓨팅 환경은 인터넷을 통하여 다양한 서비스 및 애플리케이션을 제공할 수 있다. 이 클라우드 기반 서비스(가령, 서비스로서의 소프트웨어(software as a service), 서비스로서의 플랫폼(platform as a service), 서비스로서의 인프라스트럭처(infrastructure as a service) 등등)는 웹 브라우저 또는 다른 원격 인터페이스를 통해 액세스가능할 수 있다. 본 문서에 기술된 다양한 기능은 원격 데스크톱 환경 또는 임의의 다른 클라우드 기반 컴퓨팅 환경을 통해 제공될 수 있다.

앞의 서술은 설명의 목적으로 특정 실시예를 참조하여 기술되었다. 다만, 위의 예시적인 논의는 철저하거나 발명을 개시된 정밀한 형태로 한정하도록 의도된 것이 아니다. 위 교시를 고려할 때 많은 수정 및 변화가 가능하다. 발명의 원리 및 그것의 실제적인 적용을 가장 잘 설명하여서 다른 당업자로 하여금 고려되는 특정한 사용에 적합할 수 있는 다양한 수정과 함께 발명 및 다양한 실시예를 가장 잘 활용할 수 있게 하기 위해서 실시예들이 채택되어 기술되었다.

발명에 따른 실시예가 이와 같이 기술된다. 본 개시는 특정한 실시예로 기술되었으나, 발명은 그러한 실시예에 의해 한정되는 것으로 해석되어서는 안 되고, 오히려 아래의 청구항에 따라 해석되어야 한다는 점이 인식되어야 한다.

Claims (21)

1. 자동화된 디바이스 테스트(automated device testing)를 위한 테스트 절차를 디버그하는 방법으로서,
   제 1 디버깅 세션(debugging session) 동안에 수정된 적어도 하나의 수정된 테스트 절차(modified test procedure)를 갱신하기 위한 명령을 수신하는 단계와,
   테스트 계획(test plan)을 위한 상태 정보를 세이브하는(saving) 단계 - 상기 상태 정보는 중단점 엔트리 위치(breakpoint entry location)에 관한 정보를 포함하고, 상기 수정된 테스트 절차는 상기 테스트 계획 내에서 호출됨 - 와,
   상기 테스트 계획의 실행을 유예하는 단계와,
   상기 테스트 계획으로부터 상기 수정된 테스트 절차를 언로드하는(unloading) 단계와,
   상기 수정된 테스트 절차와 연관된 컴파일된 파일(compiled file)을 산출하기 위해 상기 수정된 테스트 절차를 컴파일하는 단계와,
   상기 컴파일된 파일을 사용하여 상기 테스트 계획 내에 상기 수정된 테스트 절차를 재로드하는(reloading) 단계와,
   제 2 디버깅 세션 내에서 상기 수정된 테스트 절차의 실행을 재개하는 단계와,
   상기 제 2 디버깅 세션 동안에 상기 중단점 엔트리 위치에 대응하는 중단점에서 상기 실행을 중단하는 단계를 포함하는
   방법.
   
2. 제 1 항에 있어서,
   상기 재개하는 단계는
   상기 제 1 디버깅 세션 동안에 설정된 이전 중단점을 소거하는 단계와,
   상기 수정된 테스트 절차 내에 상기 중단점 엔트리 위치에 대응하는 중단점을 설정하는 단계와,
   상기 제 2 디버깅 세션 동안에 상기 중단점 엔트리 위치에 대응하는 상기 중단점에서 실행이 중단된 후 상기 이전 중단점을 복원하는 단계를 더 포함하는
   방법.
   
3. 제 1 항에 있어서,
   상기 재로드하는 단계는
   상기 컴파일된 파일을 시스템 제어기(system controller)로부터 사이트 제어기(site controller)로 전송하는 단계 - 상기 시스템 제어기는 상기 사이트 제어기에 통신가능하게 커플링되고(communicatively coupled), 상기 시스템 제어기는 상기 사이트 제어기를 제어함 - 와,
   상기 컴파일된 파일을 사용하여 상기 테스트 계획 내에서 상기 수정된 테스트 절차와 연관된 테스트 인스턴스를 인스턴스화하는(instantiating) 단계와,
   상기 제 1 디버깅 세션 동안에 원래 설정된 파라미터 값으로써 상기 테스트 계획 내에서 상기 테스트 인스턴스를 파퓰레이트하는(populating) 단계를 더 포함하는
   방법.
   
4. 제 1 항에 있어서,
   상기 수정된 테스트 절차는 기반 테스트 절차(base test procedure) 및 상기 기반 테스트 절차에 종속하는 적어도 하나의 파생된 테스트 절차(derived test procedure)를 포함하는
   방법.
   
5. 제 4 항에 있어서,
   상기 언로드하는 단계 전에 상기 기반 테스트 절차에 종속하는 상기 적어도 하나의 파생된 테스트 절차를 식별하는 단계를 더 포함하는
   방법.
   
6. 제 1 항에 있어서,
   상기 유예하는 단계 전에 상기 수정된 테스트 절차를 실행하여 완료하는 단계를 더 포함하는
   방법.
   
7. 제 1 항에 있어서,
   상기 중단점 엔트리 위치는 현재 라인(current line), 현재 함수의 시작, 그리고 임의의 이전 중단점을 포함하는 그룹으로부터 선택되는
   방법.
   
8. 제 1 항에 있어서,
   상기 제 2 디버깅 세션 동안에 상기 중단점 엔트리 위치에 대응하는 상기 중단점으로부터 상기 테스트 계획을 실행하여 완료하는 단계를 더 포함하는
   방법.
   
9. 제 1 항에 있어서,
   상기 수정된 테스트 절차가 수정되고 디버그 명령(debug command)이 실행되는 경우에 자동으로 상기 수정된 테스트 절차를 갱신하기 위해 상기 명령을 호출하는 단계를 더 포함하는
   방법.
   
10. 제 1 항에 있어서,
    분기 흐름 항목(branch flow items)을 동시적으로(concurrently) 실행하는 중에 테스트 절차가 상기 수정된 테스트 절차와 병렬로 구동 중인지 판정하는 단계와,
    상기 수정된 테스트 절차가 상기 유예하는 단계에 후속하는 유예된 상태 내에 있는 동안, 병렬로 구동 중인 상기 테스트 절차를 실행하여 완료하는 단계와,
    상기 수정된 테스트 절차가 실행되고 있는 동안, 상기 분기 흐름 항목을 동시적으로 실행하는 중에 추가의 테스트 절차의 실행을 유예하는 단계를 더 포함하는
    방법.
    
11. 컴퓨터 시스템에 의해 실행되는 경우 상기 컴퓨터 시스템으로 하여금 자동화된 디바이스 테스트를 위한 테스트 절차를 디버그하는 방법을 수행하게 하는 컴퓨터 실행가능 명령어가 저장된 비일시적(non-transitory) 컴퓨터 판독가능 저장 매체로서, 상기 방법은
    제 1 디버깅 세션 동안에 수정된 적어도 하나의 수정된 테스트 절차를 갱신하기 위한 명령을 수신하는 단계와,
    테스트 계획을 위한 상태 정보를 세이브하는 단계 - 상기 상태 정보는 중단점 엔트리 위치에 관한 정보를 포함하고, 상기 수정된 테스트 절차는 상기 테스트 계획 내에서 호출됨 - 와,
    상기 테스트 계획의 실행을 유예하는 단계와,
    상기 테스트 계획으로부터 상기 수정된 테스트 절차를 언로드하는 단계와,
    상기 수정된 테스트 절차와 연관된 컴파일된 파일을 산출하기 위해 상기 수정된 테스트 절차를 컴파일하는 단계와,
    상기 컴파일된 파일을 사용하여 상기 테스트 계획 내에 상기 수정된 테스트 절차를 재로드하는 단계와,
    제 2 디버깅 세션 내에서 상기 수정된 테스트 절차의 실행을 재개하는 단계와,
    상기 제 2 디버깅 세션 중에 상기 중단점 엔트리 위치에 대응하는 중단점에서 상기 실행을 중단하는 단계를 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
12. 제 11 항에 있어서,
    상기 방법은
    상기 제 1 디버깅 세션 동안에 설정된 이전 중단점을 소거하는 단계와,
    상기 수정된 테스트 절차 내에 상기 중단점 엔트리 위치에 대응하는 중단점을 설정하는 단계와,
    상기 제 2 디버깅 세션 동안에 상기 중단점 엔트리 위치에 대응하는 상기 중단점에서 실행이 중단된 후 상기 이전 중단점을 복원하는 단계를 더 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
13. 제 11 항에 있어서,
    상기 방법은
    상기 컴파일된 파일을 시스템 제어기로부터 사이트 제어기로 전송하는 단계 - 상기 시스템 제어기는 상기 사이트 제어기에 통신가능하게 커플링되고, 상기 시스템 제어기는 상기 사이트 제어기를 제어함 - 와,
    상기 컴파일된 파일을 사용하여 상기 테스트 계획 내에서 상기 수정된 테스트 절차와 연관된 테스트 인스턴스를 인스턴스화하는 단계와,
    상기 제 1 디버깅 세션 동안에 초기에 설정된 파라미터 값으로써 상기 테스트 계획 내에서 상기 테스트 인스턴스를 파퓰레이트하는 단계를 더 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
14. 제 11 항에 있어서,
    상기 수정된 테스트 절차는 기반 테스트 절차 및 상기 기반 테스트 절차에 종속하는 적어도 하나의 파생된 테스트 절차를 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
15. 제 14 항에 있어서,
    상기 방법은
    상기 언로드하는 단계 전에 상기 기반 테스트 절차에 종속하는 상기 적어도 하나의 파생된 테스트 절차를 식별하는 단계를 더 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
16. 제 11 항에 있어서,
    상기 방법은
    상기 유예하는 단계 전에 상기 수정된 테스트 절차를 실행하여 완료하는 단계를 더 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
17. 제 11 항에 있어서,
    상기 중단점 엔트리 위치는 현재 라인, 현재 함수의 시작, 그리고 임의의 이전 중단점을 포함하는 그룹으로부터 선택되는
    비일시적 컴퓨터 판독가능 저장 매체.
    
18. 제 11 항에 있어서,
    상기 방법은
    상기 제 2 디버깅 세션 중에 상기 중단점 엔트리 위치에 대응하는 상기 중단점으로부터 상기 테스트 계획을 실행하여 완료하는 단계를 더 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
19. 제 11 항에 있어서,
    상기 방법은
    상기 수정된 테스트 절차가 수정되고 디버그 명령이 실행되는 경우에 자동으로 상기 수정된 테스트 절차를 갱신하기 위해 상기 명령을 호출하는 단계를 더 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
20. 제 11 항에 있어서,
    상기 방법은
    분기 흐름 항목을 동시적으로 실행하는 중에 테스트 절차가 상기 수정된 테스트 절차와 병렬로 구동 중인지 판정하는 단계와,
    상기 수정된 테스트 절차가 상기 유예하는 단계에 후속하는 유예된 상태 내에 있는 동안, 병렬로 구동 중인 상기 테스트 절차를 실행하여 완료하는 단계와,
    상기 수정된 테스트 절차가 실행되고 있는 동안, 상기 분기 흐름 항목을 동시적으로 실행하는 중에 추가의 테스트 절차의 실행을 유예하는 단계를 더 포함하는
    비일시적 컴퓨터 판독가능 저장 매체.
    
21. 자동화된 디바이스 테스트를 위한 테스트 절차를 디버그하는 시스템으로서,
    메모리 - 상기 메모리는 상기 메모리 내에 저장된 개발 환경을 포함하되, 상기 개발 환경은 테스트 프로그램(test program)을 디버그하도록 동작가능하고(operable), 상기 개발 환경은 디버거(debugger)를 포함함 - 와,
    상기 메모리에 커플링된 프로세서를 포함하되, 상기 프로세서는 상기 개발 환경에 따라
    테스트 계획을 위한 상태 정보를 세이브 - 상기 상태 정보는 중단점 엔트리 위치에 관한 정보를 포함하고, 수정된 테스트 절차가 상기 테스트 계획 내에서 호출됨 - 하고,
    상기 테스트 계획의 실행을 유예하며,
    상기 테스트 계획으로부터 상기 수정된 테스트 절차를 언로드하고,
    상기 수정된 테스트 절차를 컴파일 - 상기 컴파일은 상기 수정된 테스트 절차와 연관된 컴파일된 파일을 생성함 - 하며,
    상기 컴파일된 파일을 사용하여 상기 테스트 계획 내에 상기 수정된 테스트 절차를 재로드하고,
    디버깅 세션 내에서 상기 수정된 테스트 절차의 실행을 재개하며,
    상기 디버깅 세션 중에 상기 중단점 엔트리 위치에 대응하는 중단점에서 상기 실행을 중단하게 동작하도록 구성된
    시스템.

Images