KR20160004283A

KR20160004283A - 상호작용적 그래픽 사용자 인터페이스로부터의 테스트 클래스 프리헤더의 자동화된 생성

Info

Publication number: KR20160004283A
Application number: KR1020157031198A
Authority: KR
Inventors: 마크 엘스톤; 안칸 프라마닉; 레온 첸; 찬드라 핀잘라
Original assignee: 주식회사 아도반테스토
Priority date: 2013-04-30
Filing date: 2014-02-05
Publication date: 2016-01-12
Also published as: US9785526B2; WO2014178930A1; US20140324378A1; KR102141262B1; CN105143895B; CN105143895A

Abstract

자동화된 테스트 장비(Automated Test Equipment: ATE)를 사용하여 테스트를 수행하기 위한 방법이 제시된다. 그 방법은 그래픽 사용자 인터페이스를 사용하여 테스트 클래스에 관한 정보를 획득하는 것을 포함한다. 또한, 그것은 자동으로 제 1 헤더 파일을 생성하는 것을 포함하는데, 제 1 헤더 파일은 테스트 클래스에 관한 정보를 포함한다. 다음으로, 그것은 테스터 운영 시스템을 사용하여 실행되도록 동작가능한 테스트 계획 내에 제 1 헤더 파일을 임포트하는 것을 포함하는데 테스트 계획은 테스트 클래스의 인스턴스를 포함한다. 그것은 자동으로 제 1 헤더 파일로부터 제 2 헤더 파일을 생성하는 것을 더 포함하는데, 제 2 헤더 파일은 테스트 클래스를 위한 헤더 파일이다. 그 방법은 테스터 운영 시스템을 사용하여 테스트 계획을 유효확인하는 것을 또한 포함한다. 끝으로, 그 방법은 테스트 계획 및 컴파일된 모듈을 실행을 위해 테스터 운영 시스템 상에 로드하는 것을 포함하는데, 컴파일된 모듈은 테스트 클래스의 컴파일된 변환이다.

Description

상호작용적 그래픽 사용자 인터페이스로부터의 테스트 클래스 프리헤더의 자동화된 생성{AUTOMATED GENERATION OF A TEST CLASS PRE-HEADER FROM AN INTERACTIVE GRAPHICAL USER INTERFACE}

본 발명의 실시예는 일반적으로는 자동화된 디바이스 테스트(automated device testing)에 관련되고 더욱 구체적으로는 자동화된 디바이스 테스트를 위한 테스트 계획 및 테스트 클래스를 생성하는 사용자 친화적이고 자동화된 방법에 관련된다.

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

디바이스 또는 제품을, 가령 생산 후에, 테스트하는 데에 있어서, 무엇보다도 높은 제품 품질, 디바이스 또는 제품 성능의 추정, 제조 프로세스에 관한 피드백 그리고 끝으로 높은 소비자 만족을 달성하는 것이 중대하다. 디바이스 또는 제품(테스트 용어로는 피테스트 디바이스(Device Under Test)("DUT")로 흔히 지칭됨)의 올바른 기능을 보장하기 위해서 대개 복수의 테스트가 수행된다. 복수의 테스트는 전형적으로는 사용자에 의해 ATE 시스템 내에 로드되는(loaded) 테스트 계획(test plan)의 일부이다. 테스트 계획은 DUT에 대해 테스트를 행하기 위한 청사진으로서 작용한다. 복수의 테스트는 테스트 흐름(test flow) 내에서 컴파일될(compiled) 수 있는데 테스트 흐름은 디바이스 또는 제품을 테스트하기 위한 하나 이상의 테스트를 포함하는 상이한 테스트 그룹들로 구분될 수 있다. 예를 들어, 반도체 디바이스는 접촉(contact) 테스트, 전류-전압(current-voltage) 테스트, 로직(logic) 테스트, 빠르기(speed) 테스트, 응력(stress) 테스트 및 기능적 테스트를 포함하는 테스트 흐름으로써 테스트될 수 있다.

전형적인 ATE 시스템에서, 사용자는 애플리케이션 프로그래밍 인터페이스(application programming interface)를 사용함으로써 주어진 테스트 계획을 위해 테스트 클래스를 개발할 수 있다. 테스트 계획이 로드되는 경우, ATE 시스템 제어기는 테스트 흐름 내의 모든 노드가 사용자의 기대에 따라 적절히 구성될 수 있는지를 판정하기 위해 테스트 클래스의 유효확인 분석(validation analysis)을 수행한다. 테스트 계획을 유효확인하기(validate) 위해서, ATE 시스템 제어기는 테스트 클래스를 위한 프리헤더 파일(pre-header file)이 필요하다. 각각의 테스트 클래스를 위한 프리헤더 파일은 무엇보다도 유효확인을 수행하기 위해서 테스트 클래스 및 그것의 다양한 파라미터를 ATE 시스템 제어기에 기술한다. 프리헤더 파일은 또한 테스트 클래스 그 자체를 위한 C++ 헤더 파일을 생성하기 위해 사용되는데, 이는 사용자에 의해 개발된 테스트 클래스 및 테스트 계획 작성자(test plan author)에 의해 개발된 테스트 계획 간 공통의 정의적인 가교(common definitional bridge)를 제공한다.

종래의 ATE 시스템에서, 프리헤더 파일을 생성하는 것은 번거로운데 이는 사용자가 전형적으로는 수동으로 프리헤더 파일을 위한 프로그램 코드를 개발하여야 하기 때문이며, 이는 사용자가 프리헤더 파일을 위해 요구되는 특수한 포맷(format) 또는 구문(syntax)을 익혀야 하므로 과도하게 시간이 걸린다. 또한, 코드 구문이 사용자 친화적이지 않고, 오히려 낮은 머신 레벨(machine level)에 있기에, 그 프로세스는 오류가 생기기 쉽다.

이에 따라, 필요한 것은 그래픽 사용자 인터페이스(Graphical User Interface: GUI)를 사용자에게 제공하여 사용자로 하여금 자신의 테스트 클래스의 파라미터를 GUI와 인터페이스하기 위한 간단한 드래그 앤 드롭(drag and drop) 절차로써 정의할 수 있게 하고, 이로써, 프리헤더 파일의 자동화된 개발을 가능하게 하는 ATE 시스템이다.

하나의 실시예에서, 자동화된 테스트 장비(Automated Test Equipment: ATE)를 사용하여 테스트를 수행하는 방법이 제시된다. 위 방법은 그래픽 사용자 인터페이스를 사용하여 적어도 하나의 테스트 클래스에 관한 정보를 획득하는 단계를 포함한다. 또한, 그것은 자동으로 제 1 헤더 파일을 생성하는 단계를 포함하는데, 위 제 1 헤더 파일의 내용은 적어도 하나의 테스트 클래스에 관한 위 정보를 포함한다. 다음으로, 위 방법은 테스터 운영 시스템(tester operating system)을 사용하여 실행되도록 동작가능한(operable) 테스트 계획 내에 위 제 1 헤더 파일을 임포트하는(importing) 단계를 포함하는데 위 테스트 계획은 위 적어도 하나의 테스트 클래스의 인스턴스를 포함한다. 그것은 또한 자동으로 위 제 1 헤더 파일로부터 제 2 헤더 파일을 생성하는 단계를 포함하는데, 위 제 2 헤더 파일은 위 적어도 하나의 테스트 클래스를 위한 헤더 파일이고, 위 제 2 헤더 파일 및 위 적어도 하나의 테스트 클래스는 공통의 프로그래밍 언어를 사용하여 준비된다. 위 방법은 또한 위 테스터 운영 시스템을 사용하여 위 테스트 계획을 유효확인하는(validating) 단계를 포함한다. 끝으로, 위 방법은 위 테스트 계획 및 적어도 하나의 컴파일된 모듈(compiled module)을 실행을 위해 위 테스터 운영 시스템 상에 로드하는(loading) 단계를 포함하는데, 위 적어도 하나의 컴파일된 모듈 각각은 위 적어도 하나의 테스트 클래스 중 각 테스트 클래스의 컴파일된 변환(compiled translation)이고, 위 제 2 헤더 파일은 위 적어도 하나의 컴파일된 모듈을 생성하기 위해 사용된다.

다른 실시예에서, 컴퓨터 시스템에 의해 실행되는 경우 위 컴퓨터 시스템으로 하여금 자동화된 테스트 장비(Automated Test Equipment: ATE)를 사용하여 테스트를 수행하는 방법을 수행하게 하는 컴퓨터 실행가능 명령어가 저장된 컴퓨터 판독가능 저장 매체가 개시된다. 위 방법은 그래픽 사용자 인터페이스를 사용하여 적어도 하나의 테스트 클래스에 관한 정보를 획득하는 단계를 포함한다. 또한, 그것은 자동으로 제 1 헤더 파일을 생성하는 단계를 포함하는데, 위 제 1 헤더 파일의 내용은 적어도 하나의 테스트 클래스에 관한 위 정보를 포함한다. 다음으로, 위 방법은 테스터 운영 시스템을 사용하여 실행되도록 동작가능한 테스트 계획 내에 위 제 1 헤더 파일을 임포트하는 단계를 포함하는데 위 테스트 계획은 위 적어도 하나의 테스트 클래스의 인스턴스를 포함한다. 그것은 또한 자동으로 위 제 1 헤더 파일로부터 제 2 헤더 파일을 생성하는 단계를 포함하는데, 위 제 2 헤더 파일은 위 적어도 하나의 테스트 클래스를 위한 헤더 파일이고, 위 제 2 헤더 파일 및 위 적어도 하나의 테스트 클래스는 공통의 프로그래밍 언어를 사용하여 준비된다. 위 방법은 또한 위 테스터 운영 시스템을 사용하여 위 테스트 계획을 유효확인하는 단계를 포함한다. 끝으로, 위 방법은 위 테스트 계획 및 적어도 하나의 컴파일된 모듈을 실행을 위해 위 테스터 운영 시스템 상에 로드하는 단계를 포함하는데, 위 적어도 하나의 컴파일된 모듈 각각은 위 적어도 하나의 테스트 클래스 중 각 테스트 클래스의 컴파일된 변환이고, 위 제 2 헤더 파일은 위 적어도 하나의 컴파일된 모듈을 생성하기 위해 사용된다.

하나의 실시예에서, 자동화된 테스트를 수행하는 시스템이 제시된다. 위 시스템은 내부에 저장된 테스터 운영 시스템을 포함하는 메모리를 포함한다. 그것은 또한 복수의 피테스트 디바이스(Devices Under Test: DUTs)에 연결되도록 동작가능한 통신관련 인터페이스(communicative interface)를 포함한다. 또한, 위 시스템은 위 메모리 및 위 통신관련 인터페이스에 커플링된 프로세서를 포함한다. 위 프로세서는 위 테스터 운영 시스템에 따라 (a) 그래픽 사용자 인터페이스를 사용하여 적어도 하나의 테스트 클래스에 관한 정보를 획득하고, (b) 자동으로 제 1 헤더 파일을 생성하며(위 제 1 헤더 파일의 내용은 위 정보를 포함함), (c) 위 테스터 운영 시스템을 사용하여 실행되도록 동작가능한 테스트 계획 내에 위 제 1 헤더 파일을 임포트하고(위 테스트 계획은 위 적어도 하나의 테스트 클래스의 인스턴스를 포함하고, 위 테스트 계획은 복수의 피테스트 디바이스(DUTs) 상에서 행해질 테스트를 정의하도록 동작가능함), (d) 자동으로 위 제 1 헤더 파일로부터 제 2 헤더 파일을 생성하며(위 제 2 헤더 파일은 위 적어도 하나의 테스트 클래스를 위한 헤더 파일이고, 위 제 2 헤더 파일 및 위 적어도 하나의 테스트 클래스는 공통의 프로그래밍 언어를 사용하여 준비됨), (e) 위 테스터 운영 시스템을 사용하여 위 테스트 계획을 유효확인하고, (f) 위 테스트 계획 및 적어도 하나의 컴파일된 모듈을 실행을 위해 위 테스터 운영 시스템 상에 로드하게(위 적어도 하나의 컴파일된 모듈 각각은 위 적어도 하나의 테스트 클래스 중 각 테스트 클래스의 컴파일된 변환이고, 위 제 2 헤더 파일은 위 적어도 하나의 컴파일된 모듈을 생성하기 위해 사용됨) 동작하도록 구성된다.

하나의 실시예에서, 자동화된 테스트 장비(Automated Test Equipment: ATE)를 사용하여 테스트를 수행하는 방법이 개시된다. 위 방법은 그래픽 사용자 인터페이스를 사용하여 적어도 하나의 테스트 클래스에 관한 정보를 획득하는 단계를 포함한다. 위 방법은 또한 자동으로 헤더 파일을 생성하는 단계를 포함하는데, 위 제 1 헤더 파일의 내용은 위 정보를 포함한다. 위 그래픽 사용자 인터페이스는 디스플레이 편집기 윈도우(display editor window) 및 텍스트 편집기 윈도우(text editor window)를 포함하는데, 위 디스플레이 편집기 윈도우 내에서 행해진 변경은 위 텍스트 편집기 윈도우에서의 대응하는 변경에 자동으로 맵핑되며, 또한 위 텍스트 편집기 윈도우 내에서 행해진 변경은 위 디스플레이 편집기 윈도우에서의 대응하는 변경에 자동으로 맵핑된다.

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

비슷한 참조 번호가 유사한 구성요소를 나타내는 첨부된 도면의 그림 내에 본 발명의 실시예들이 한정으로서가 아니라 예로서 보여진다.
도 1은 본 발명의 하나의 실시예에 따라 본 발명의 자동화된 테스트 시스템의 실시예가 구현될 수 있는 컴퓨터 시스템이다.
도 2(a)는 본 발명의 하나의 실시예에 따라 본 발명의 실시예가 구현될 수 있는 자동화된 테스트 장비 장치에 대한 도식적인 블록 다이어그램(block diagram)이다.
도 2(b)는 도 2(a)의 자동화된 테스트 장비 장치의 하나의 실시예의 더욱 상세한 도식적인 블록 다이어그램이다.
도 3은 상이한 테스트 인스턴스들이 단일의 테스트 클래스로부터 생성될 수 있는 방식에 관한 다이어그램을 보여준다.
도 4는 테스트 계획 내 테스트 클래스 인스턴스화(instantiation)의 예를 보여준다.
도 5는 프리헤더 파일의 기본 구조를 보여준다.
도 6은 본 발명의 하나의 실시예에 따라 코드 뷰(code view) 및 디자인 뷰(design view) 간에 전환하기 위한 GUI를 보여준다.
도 7은 본 발명의 하나의 실시예에 따라 프리헤더 편집기를 위한 예시적인 디자인 뷰 모드를 보여준다.
도 8은 본 발명의 하나의 실시예에 따라 자동화된 테스트 시스템을 위한 그래픽 사용자 인터페이스를 사용하는 프리헤더 파일의 생성 및 기능을 보여주는 예시적인 소프트웨어 프로세스의 도식적인 블록 다이어그램이다.
도 9는 본 발명의 하나의 실시예에 따라 그래픽 사용자 인터페이스를 사용하여 프리헤더 파일을 생성하고, 실행가능 DLL을 생성하기 위해 테스트 클래스를 컴파일하며 프리헤더 파일 및 컴파일된 테스트 클래스를 사용하여 테스트 계획을 실행하는 예시적인 컴퓨터 제어된 프로세스(computer controlled process)의 흐름도(flowchart)를 묘사한다.

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

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

그러나, 이들 용어 및 유사한 용어 전부는 적절한 물리적 양들과 연관될 것이며 이 양들에 적용되는 편리한 라벨에 불과하다는 점에 유념하여야 한다. 이하의 논의로부터 명백한 바와 같이 별도로 명확히 언급되지 않는 한, 본 개시를 통틀어, "생성하기"(generating), "임포트하기"(importing), "유효확인하기"(validating), "로드하기"(loading), "인스턴스화하기"(instantiating), "실행하기"(executing), "식별하기"(identifying), "배분하기"(allocating), "연관시키기"(associating), "액세스하기"(accessing), "판정하기"(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은 본 개시의 실시예를 구현할 수 있는 컴퓨팅 시스템(110)의 예의 블록 다이어그램이다. 예를 들어, 컴퓨팅 시스템(110)은, 하나의 실시예에서, 테스터 시스템의 제어기를 구현할 수 있는데, 프리헤더 파일을 생성하기 위해 사용되는 그래픽 사용자 인터페이스가 제어기 상에서 구동된다(run). 컴퓨팅 시스템(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)는 단일의 데이터베이스 또는 컴퓨팅 디바이스의 일부를 나타낼 수 있거나 그것은 다수의 데이터베이스 또는 컴퓨팅 디바이스를 나타낼 수 있다. 예를 들어, 데이터베이스(140)는 컴퓨팅 시스템(110)의 일부분 및/또는 (아래의) 도 2의 예시적 네트워크 아키텍처(200)의 부분을 나타낼(이에 저장될) 수 있다. 대안적으로, 데이터베이스(140)는 컴퓨팅 시스템(110) 및/또는 네트워크 아키텍처(200)의 부분과 같은, 컴퓨팅 디바이스에 의해 액세스되는 것이 가능한 하나 이상의 물리적으로 별개인 디바이스를 나타낼(이에 저장될) 수 있다.

도 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)로 하여금 동시적 테스트 환경 내의 다수의 테스트 코어 간에 리소스를 공유하기 위해 요구되는 기능을 수행하고/하거나 이를 수행하는 수단이게 할 수 있다.

프리헤더 파일을 생성하는 종래의 방법은 수동으로 코드를 기록하는 것을 수반하였는데, 이는 다양한 이유로 문제가 있었다. 우선, 프리헤더 파일을 준비하기 위해서, 사용자는 프리헤더를 정의하기 위한 적절한 구문에 관한 기능적 지식을 가지는 것이 필요하였다. 둘째, 그 프로세스가 수동이었기 때문에, 그것은 오류가 생기기 쉬웠다. 본 발명의 실시예는 사용자로 하여금 GUI 내에서 사용자 친화적인 드래그 앤 드롭 절차를 사용하여 자신의 테스트의 파라미터를 정의하게 하고, 이로써, 프리헤더 파일의 개발을 가능하게 하는 그래픽 사용자 인터페이스(Graphical User Interface: GUI)를 제공함으로써 이 문제점들을 다룬다.

도 2(a)는 본 발명의 하나의 실시예에 따라 동시적인 테스트 시스템(concurrent test system)의 실시예가 구현될 수 있는 자동화된 테스트 장비(Automated Test Equipment: ATE) 장치에 대한 도식적인 블록 다이어그램이다. 하나의 실시예에서, 시스템 제어기(201)는 하나 이상의 링크된(linked) 컴퓨터를 포함한다. 예를 들어, 어드밴테스트 사(Advantest Corporation)의 T2000 테스터 군(family)과 같은 테스트 시스템은 컴퓨터들의 네트워크를 사용할 수 있다. 다른 실시예에서, 시스템 제어기는 종종 오직 단일 컴퓨터를 포함한다. 시스템 제어기(201)는 전체적인 시스템 제어 유닛이고, 사용자의 주된 테스트 계획을 행하는 것을 포함하여 모든 사용자 레벨 테스트 작업을 달성하는 것을 책임지는 ATE를 위한 소프트웨어를 구동한다. 그러한 테스터 소프트웨어의 하나의 예는 T2000 시스템 소프트웨어(T2000 System Software)("TSS")이다. 전형적으로, TSS와 같은 테스터 소프트웨어는 컴파일러(compiler)를 포함하는데, 이는 테스터 시스템의 프로그래밍 언어, 가령 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)를 포함한다. 하나의 실시예에서, 테스터 하드웨어(202)는 다수의 사이트 제어기를 포함할 수 있는데, 각 사이트 제어기는 다수의 DUT에 연결된다. 각 사이트 제어기는 디바이스 테스트에서 사용되는 컴퓨터이다. 테스트 계획 프로그램은 사이트 제어기 상에서 실행될 수 있다. 사이트 제어기는 시스템 제어기에 연결되고 사용자에 의해 수행되는 테스트 동작은 통신기 버스(215)를 통해서 사이트 제어기를 제어하는 시스템 제어기 상에서 처리된다.

도 2(b)는 도 2(a)의 자동화된 테스트 장비 장치의 하나의 실시예의 더욱 상세한 도식적인 블록 다이어그램이다. 도 2(b)에 예시된 실시예에서, 테스터 하드웨어(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)이다.

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

테스트 프로그램이 DUT를 위해 기록되는 경우, 일반적으로 그 프로그램의 주요(predominant) 부분은 디바이스 테스트를 위한 "데이터"이고, 나머지는 프로그램 코드(program code)인데, 이는 테스트 방법론 그 자체를 실현한다. 데이터는 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)로 개발된다.

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

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

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

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

도 4는 테스트 계획 내의 테스트 클래스 인스턴스화의 예를 보여준다. 예시적인 OTPL 소스 파일로부터의 도 4의 발췌(테스트 인스턴스 "FuncTest1"이 있음)를 고려하시오. 시스템 제어기(201)의 OTPL 프로세서는 도 4 내의 FuncTest1의 선언이 적법한지를 판정하기 위해서 "MyFunctionalTest" 테스트 클래스가 무엇을 수반하는지를 알 필요가 있다. "MyFunctionalTest"를 알고서 그 언어 내에 빌드하는 것보다는, "MyFunctionalTest" 클래스가 무엇을 수반하는지의 정의가 프리헤더 파일 내에 OTPL의 프리헤더 부언어로 지정될 수 있다.

도 4에 도시된 바와 같이, "MyFunctionalTest"는 "PListParam" 및 "TestConditionParam"을 포함하는 멤버를 갖는 C++ 클래스이다. OTPL 컴파일러는 도 4 내의 "FuncTest1"의 선언이 적법함을 인지하기 위해서 "MyFunctionalTest"의 멤버에 대해 알 필요가 있다. 또한, "FuncTest1"을 위한 C++ 객체 선언을 생성하기 위해서, 클래스 "MyFunctionalTest"를 위한 C++ 헤더가 구축될(constructed) 필요가 있다. 이는 OTPL 컴파일러가 또한 "MyFunctionalTest" 클래스의 임의의 기반 클래스, 그것의 멤버의 명칭 및 다른 그러한 정보에 대해 알 것을 요구한다.

프리헤더 파일 및 프리헤더 부언어는 OTPL 컴파일러에게 그것이 OTPL 선언의 적법성(legality)을 인지하기도 하고 OTPL 선언에 대응하는 C++ 헤더 및 객체 선언을 생성하기도 하기 위해 필요로 하는 정보를 제공한다. 또한, 프리헤더 및 OTPL의 프리헤더 부언어는 테스트 클래스를 위한 C++ 헤더 파일의 생성을 가능하게 한다. 또한, 도 4의 코드 내에 도시된 파라미터, 가령 min, max 및 patList1 등등은 그것의 프리헤더 파일 내의 각 테스트 클래스를 위해 지정된 파라미터의 세트에 대비되어 유효확인이 된다.

도 5는 예로서 OTPL 프리헤더 파일을 사용하여 프리헤더 파일의 기본 구조를 보여준다. 프리헤더 파일은 두 개의 주된 섹션을 포함한다. 제 1 섹션(550)은 테스트 클래스를 위한 OTPL 맞춤화를 포함할 수 있는데, 이는 테스트 클래스의 명칭, 그것의 C++ DLL 명칭(만약 필요한 경우), 다양한 자동 코드 생성 특징을 지원하기 위한 옵션, 그리고 테스트 클래스 파라미터 정의 섹션과 같은 사양을 포함한다.

프리헤더 파일은 앞서 논의된 바와 같이 OTPL 컴파일러에 의해 생성된 C++ 코드를 실행가능한 테스트 클래스로 컴파일하기 위해 C++ 헤더 파일을 생성하는 데에 사용된다. 따라서, 원하는 기능성을 얻기 위해서, C++로 기록된 테스트 클래스 확장 코드(test class extension code)가 요구될 수 있다. 프리헤더 파일 내의 제 2 섹션(560)은 이전의(즉 OTPL 맞춤화) 섹션 내의 사양의 결과로서 자동으로 생성되는 것을 넘어서 테스트 클래스 C++ 코드를 확장하는 것을 지원하도록 C++로 되어 있는 테스트 클래스 특정적(test-class-specific) 테스트 클래스 확장 코드를 위한 것이다. OTPL 컴파일러는 제 1 섹션만으로부터 유효한 C++ 테스트 클래스 헤더를 아마도 생성할 수 있으므로 이 섹션은 필수적이지 않을 수 있다는 점에 유의하여야 한다.

세 유형의 파일이 전형적으로 도 5의 ATE 시스템 내의 테스트 클래스 개발 중에 생성된다. 첫째는 C++ 소스 파일이다. 멤버 함수와 같은 테스트 클래스 함수가 C++ 소스 파일 내에 구현된다. 테스트 클래스 개발자는 전형적으로 테스트 알고리즘에 따라 C++ 소스 파일을 생성한다.

둘째 유형의 피생성 파일은 C++ 헤더 파일이다. 테스트 클래스는 전형적으로 C++ 헤더 파일 내에 그것의 멤버 데이터 및 멤버 함수와 함께 선언된다. 테스트 클래스 내의 데이터 멤버 명칭 및 멤버 함수 명칭은 전형적으로 C++ 헤더 파일 내에 정의된다. 테스트 클래스 헤더 파일은 앞서 논의된 바와 같이 전형적으로 OTPL 프리헤더 파일로부터 생성되는데, 이의 예시적 구조가 도 5에서 보여진다. 따라서, 테스트 클래스 개발자는 헤더 파일을 생성하지 않는데, 그것은 OTPL 컴파일러에 의해 테스트 클래스 프리헤더 파일로부터 자동으로 생성된다.

셋째 유형의 파일은 OTPL 프리헤더 파일이다. OTPL 프리헤더 파일은 OTPL 테스트 계획 파일 내에 임포트된다. 전형적으로, 테스트 클래스 개발자는 우선 프리헤더 파일을 생성한다. 테스트 클래스 파라미터 정의는 또한 대체로 프리헤더 파일 내에 기술된다. 종래의 시스템에서 테스트 클래스 프리헤더 파일은 사용자가 파일을 생성하기 위한 구문에 친숙하고 또한 수동으로 코드를 기록할 것을 요구하는 스크래치(scratch)로부터 전형적으로 생성되었다.

하나의 실시예에서, 생성되는 파일의 세 유형에는 또한 자연스러운 순서가 있다. 프리헤더 파일은 그것이 C++ 헤더 파일(이는 다음에 생성됨)을 생성하는 데에 사용되기에 우선 생성된다. 끝으로, C++ 헤더 파일은 컴파일 중 C++ 소스 파일 내의 소스 코드에 의해 소비되고 테스트 클래스 DLL이 생성된다.

본 발명의 실시예는 드래그(drag), 드롭(drop) 및 다른 상호작용적인 동작을 사용하여 GUI와 상호작용함(interacting)으로써 프리헤더 파일을 정의하는 데에 사용될 수 있는 그래픽 사용자 인터페이스를 포함하는 테스트 클래스 프리헤더 편집기(test class pre-header editor)를 테스트 클래스 개발자에게 제공함으로써 이 문제를 다룬다. 하나의 실시예에서, 이 프리헤더 편집기는 예를 들면 마이크로소프트 비주얼 스튜디오(Microsoft Visual Studio)와 같은 상업적인 통합 개발 환경(Integrated Development Environment: IDE)를 위한 플러그인(plug-in)으로서 사용자에게 제공될 수 있다. 프리헤더 편집기는 테스트 클래스 프리헤더 파일을 생성하는 작업에서 테스트 클래스 개발자에게 도움을 주고, 유리하게도 그 프로세스를 더 쉽고 더 빠르며 덜 오류가 생기게 한다.

하나의 실시예에서, 프리헤더 편집기는 그래픽 사용자 인터페이스를 통해 테스트 클래스 개발자로부터 테스트 클래스에 관한 기본 정보를 획득하고 프리헤더를 생성한다. 이는 개발자에게서 테스트 클래스 파라미터의 구문, 유형 및 특성을 기억하는 부담을 경감시킨다.

또한, 하나의 실시예에서, 프리헤더 편집기는 프리헤더의 두 개의 상이한 뷰(view)들을 제공하여 그것을 편집하는 작업에서 도움이 될 수 있다. 우선, 디자인 뷰(design view)가 제공될 수 있는데, 이는 사용자에게 프리헤더 파일의 모든 요소에 대한 액세스를 허용하여 사용자가 단순히 그러한 요소에 대한 값을 채워야 하게 하는 GUI이다.

둘째, 코드 뷰(code view)가 제공될 수 있는데, 이는 사용자로 하여금 프리헤더의 텍스트(text)를 직접 편집하게 하는 프리헤더 파일의 단순한 직접적 텍스트성 표현(direct textual representation)이다.

하나의 실시예에서, 사용자는 선호되는 어느 뷰이든 이와 함께 작업하고, 원하는 경우 그것들 사이에서 전환해도 무방하다. 프리헤더 편집기는 그 뷰들의 동기화(synchronization)을 관리하여, 사용자를 자유롭게 코딩의 작업에 집중하도록 둔다. 도 6은 본 발명의 하나의 실시예에 따라 코드 뷰 및 디자인 뷰 간에 전환하기 위한 GUI 제공 인터페이스(GUI provided interface)를 보여준다. 일단 프리헤더 파일이 IDE 내에 로드되었다면, 사용자는 사용자가 디자인 뷰(650) 및 코드 뷰(660) 간에 쉽게 전환하게 하는, 드롭 다운 메뉴(drop down menu) 내의 두 개의 콘텍스트 메뉴 항목(context menu item)들 중에서 쉽게 택할 수 있다.

하나의 실시예에서, 편집기가 테스트 클래스를 개발하기 위해 사용되는 것과 동일한 IDE에 대한 플러그인이므로 편집기는 테스트 클래스 개발과 동일한 환경 내에서 프리헤더 파일을 생성한다.

다른 실시예에서, 디자인 편집기의 GUI는 사용자로 하여금 프리헤더 파일을 생성하는 데에 사용되는 다양한 속성에 대한 값을 선택하거나 입력하게 한다. 앞서 언급된 바와 같이, 사용자가 디자인 편집기 내에서 변경을 행하는 경우, 텍스트성 프리헤더 파일은 그 변경과 함께 자동으로 갱신된다. 그러나, 디자인 뷰 내에서 프리헤더 파일에 대해 행해진 변경을 세이브하는 경우, 편집된 버전은 구문 및 의미론적(semantic) 오류에 대해 체크된다. 만약 어떠한 오류라도 있는 경우, 테스트 클래스 헤더 파일은 생성되지 않을 것이다.

프리헤더 편집기의 코드 뷰에서, 프리헤더 파일 내용은 IDE 내 텍스트 편집기에 도시된다. 변경을 행한 후 프리헤더 파일을 세이브하는 경우, 프리헤더 파일은 구문 및 의미론적 오류에 대해 체크되고, 그러한 오류는 만일 있다면 통상적인 IDE 오류 로깅(logging) 메커니즘을 통해 디스플레이된다. 코드 뷰 내에 있는 동안 오류가 있으면, 편집은 사용자가 파일을 세이브하는 것을 막지 않지만, 디자인 뷰는 그것 내에 구문 오류가 있는 프리헤더에 대해서는 더 이상 동작하지 않을 것이다. 프리헤더 편집기는 코드 편집기 정보가 어떠한 오류도 없이 세이브될 때마다 테스트 클래스 C++ 헤더 파일을 자동으로 생성할 것이다.

또한, 하나의 실시예에서, 편집기는 직접 프리헤더 파일로부터 테스트 클래스 선언 C++ 헤더 파일을 자동으로 생성할 수 있다. 프리헤더 파일이 코드 뷰 내로부터든 디자인 뷰로부터든 세이브되는 경우, 테스트 클래스 C++ 헤더 파일은 만약 어떠한 구문 및 의미론적 오류도 없다면 자동으로 생성된다. C++ 헤더 파일은 사용자에 의해 개발된 테스트 클래스 및 테스트 계획 작성자에 의해 개발된 테스트 계획 간 공통의 정의적인 가교를 제공한다.

도 7은 본 발명의 하나의 실시예에 따라 프리헤더 편집기를 위한 예시적인 디자인 뷰 모드를 보여준다. 편집기 내의 필드는 각 카테고리가 별도의 탭(tab) 내에 디스플레이되는 세 개의 카테고리로 그룹핑될(grouped) 수 있다. 도 7에 예시된 바와 같이, 첫째 카테고리(750)는 테스트 클래스 파라미터를 지정하는 필드를 포함하여 파라미터를 입력하기 위한 것일 수 있다. 둘째 카테고리(760)는 테스트 클래스에 대한 일반적인 정보, 예컨대 테스트 클래스 명칭, 기반 테스트 클래스 명칭 등등을 지정하는 필드를 포함하여 일반적 특성을 위한 것일 수 있다. 마지막 카테고리(770)는 테스트 클래스 확장 코드를 지정하는 필드를 포함하여, C++ 맞춤화를 위한 것일 수 있다.

도 7에 디스플레이된 바와 같은 파라미터 카테고리 내에는, 파라미터 정보를 디스플레이하는 두 개의 그리드 컨트롤(grid control)들이 있다. 파라미터 정보(Parameters Info)(780)는 모든 파라미터를 위한 정보를 포함할 수 있다. 파라미터 속성(Parameter Attributes)(780)은 파라미터 정보(780) 그리드 내에서 선택된 파라미터에 대응하는 더 구체적인 정보를 포함할 수 있다. 하나의 실시예에서, 편집기 내의 각 파라미터는 사용자가 바꾸도록 허용될 수 있는 디폴트(default) 값으로써 사전정의된다.

파라미터 정보(780) 그리드는 다른 기반 테스트 클래스 프리헤더로부터 상속되는(inherited) 파라미터(785)를 도시할 수도 있다. 파라미터(795)는 비록 도시되었으나 흐릿하게 되어(dimmed out) 편집될 수 없다. 그러나, 파라미터(795)를 도시함으로써, 그것은 사용자로 하여금 다른 기반 테스트 클래스로부터 상속된 파라미터를 시각적으로 검토하게 하는데, 이로써 사용자가 임의의 충돌하는 똑같은 파라미터 명칭을 고르는 것을 막는다. 그러므로, GUI는 프리헤더 파일을 생성하는 프로세스를 덜 오류가 생기게 한다.

하나의 실시예에서, 파라미터 카테고리(750)는 쉽게 파라미터를 추가하거나 삭제하기 위한 "삽입"(Insert) 및 "삭제"(Delete) 버튼(720)을 포함할 수도 있다.

하나의 실시예에서, 편집기의 GUI는 또한 사용자로 하여금 파라미터 그룹, 가령 도 7의 파라미터 그룹(730)의 속성을 정의하게 할 것이다. 파라미터 그룹은 사용자로 하여금 개별적인 파라미터의 그룹을 단일 개체(entity)로서 취급하게 하는 데이터 구조처럼 작용한다.

따라서 그래픽 사용자 인터페이스의 디자인 뷰는 프리헤더 코드를 자동으로 생성하는 데에 이후에 사용될 수 있는 파라미터 정보를 입력하도록 사용자에게 템플릿을 제공한다.

도 8은 본 발명의 하나의 실시예에 따라 자동화된 테스트 시스템을 위한 그래픽 사용자 인터페이스를 사용하는 프리헤더 파일의 생성 및 기능을 보여주는 예시적인 소프트웨어 프로세스의 도식적인 블록 다이어그램이다.

하나의 실시예에서, 사용자는 그래픽 사용자 인터페이스(805)를 사용하여 프리헤더 편집기 내에 다양한 테스트 클래스, 다른 일반적 특성 및 테스트 클래스 확장 코드를 위한 필수 파라미터에 관한 모든 정보를 입력한다. 파라미터에 관한 정보는 파라미터의 명칭, 그것의 허용된 값, 그것의 유형 등등을 포함할 수 있다. 앞서 논의된 바와 같이, 사용자는 프리헤더 편집기의 디자인 뷰나 아니면 코드 뷰를 통해 이 정보를 입력할 수 있다.

편집기는 텍스트성 프리헤더 파일(810)을 자동으로 생성한다. 앞서 논의된 바와 같이, 사용자가 편집기의 디자인 뷰 내에서 변경을 행하는 경우, 텍스트성 프리헤더 파일은 어떠한 오류도 없으면 그 변경과 함께 자동으로 갱신된다.

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

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

그리고 OTPL 코드(850)는 이진 DLL 테스트 클래스 파일(875)과 함께 테스터 시스템 소프트웨어(820) 내에 로드된다. 하나의 실시예에서, OTPL 코드(850)가 유효확인된 후, 테스트 계획 코드(850)는 이어서 테스트 클래스를 인스턴스화하고 테스트 클래스 인스턴스화를 위한 적절한 파라미터를 판정하기 위해 프리헤더 파일(810)로부터의 정보를 사용한다. 테스터 운영 시스템(820)은 프리헤더 파일(810) 내에 제공되는 정보에 기반하여 다양한 테스트 클래스를 위한 파라미터를 파퓰레이트할(populate) 수 있다. 예를 들어, 도 8에서, 테스터 운영 시스템은 OTPL 코드(850) 내에서 인스턴스화된 어떤 테스트 클래스를 위해 파라미터로서 사용될 수 있는 패턴 목록(890) 및 패턴(895)을 읽어들일 수 있다. 이런 방식으로, 프리헤더 파일은 테스트 클래스를 파라미터로 나타내기(parameterization)를 가능하게 한다. 그리고 테스트 계획(825)은 테스터 시스템 소프트웨어(820)에 의해 실행된다.

도 9는 본 발명의 하나의 실시예에 따라 그래픽 사용자 인터페이스를 사용하여 프리헤더 파일을 생성하고, 실행가능 DLL을 생성하기 위해 테스트 클래스를 컴파일하며 프리헤더 파일 및 컴파일된 테스트 클래스를 사용하여 테스트 계획을 실행하는 예시적인 컴퓨터 제어된 프로세스의 흐름도를 묘사한다. 그러나, 발명은 흐름도(900)에 의해 제공되는 설명에 한정되지 않는다. 오히려, 다른 기능적 흐름이 본 발명의 범주 및 사상 내에 있다는 점은 본 문서에서 제공되는 교시로부터 관련 업계(들)의 숙련된 자에게 명백할 것이다. 흐름도(900)는 앞서 기술된 예시적인 실시예를 계속 참조하여 기술될 것이지만, 그 방법은 그 실시예들에 한정되지는 않는다.

단계(902)에서, 프리헤더 편집기의 디자인 뷰의 그래픽 사용자 인터페이스(805)는 테스트 클래스 파라미터와, 테스트 클래스에 관한 다른 일반적 정보, 가령 테스트 클래스 명칭, 기반 테스트 클래스 명칭 등등과, 임의의 테스트 클래스 확장 코드에 관해 테스트 클래스 작성자로부터 정보를 획득한다.

단계(904)에서, 편집기는 사용자에 의해 입력된 정보에 기반하여 그래픽 편집기(graphical editor)의 디스플레이 뷰로부터 프리헤더 텍스트 파일(810)을 직접 생성한다.

단계(906)에서, 편집기는 또한 프리헤더 파일(810)로부터 테스트 클래스 선언 C++ 헤더 파일(815)을 직접적으로 및 자동으로 생성할 수 있다.

단계(908)에서, 프리헤더 파일로부터의 파라미터적(parametric) 및 다른 정보를 사용하여 테스터 운영 시스템(820)에 의해 유효확인이 수행된다. 다양한 테스트 클래스(835)에 대응하는 컴파일된 DLL 파일(875)과 더불어 유효확인된 테스트 계획이 테스터 시스템 소프트웨어(820) 내에 로드된다.

테스트 계획은 전형적으로 테스트 클래스로부터 별개로 및 독립적으로 개발될 수 있다는 점에 유의하여야 한다. 더욱 구체적으로, 프리헤더는 테스트 클래스 아티팩트(test class artifact)이다. 테스트 클래스 및 그것의 프리헤더를 사용하는 테스트 계획은 차후의 시기에 개발될 수 있다. 따라서, 단계(908)에서의 유효확인 시기(validation stage)는 프리헤더 파일 생성으로부터 차후의 그리고 별개의 시기에서 수행될 수 있다.

단계(910)에서, 테스트 계획은 컴파일된 DLL 파일(875)을 사용하여 테스터 시스템 소프트웨어(820)에 의해 실행된다. 그러나, 실행 전에, 테스트 계획 내의 테스트 클래스는 인스턴스화되고 프리헤더 파일 내에 지정된 파라미터로써 파퓰레이트된다. 따라서, 모든 테스트 클래스 인스턴스는 또한 고유한 세트의 파라미터(이로써 각각이 인스턴스화됨)를 사용하여 테스트 계획 내 테스트 흐름의 일부로서 실행된다.

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

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

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

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

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

Claims

자동화된 테스트 장비(Automated Test Equipment: ATE)를 사용하여 테스트를 수행하는 방법으로서,
그래픽 사용자 인터페이스(graphical user interface)를 사용하여 적어도 하나의 테스트 클래스(test class)에 관한 정보를 획득하는 단계와,
자동으로 제 1 헤더 파일을 생성하는 단계 - 상기 제 1 헤더 파일의 내용은 상기 정보를 포함함 - 와,
테스터 운영 시스템(tester operating system)을 사용하여 실행되도록 동작가능한(operable) 테스트 계획(test plan) 내에 상기 제 1 헤더 파일을 임포트하는(importing) 단계 - 상기 테스터 운영 시스템은 시스템 제어기 상에 설치되고, 상기 테스트 계획은 상기 적어도 하나의 테스트 클래스의 인스턴스를 포함하며, 상기 테스트 계획은 상기 시스템 제어기에 통신가능하게 커플링된(communicatively coupled) 복수의 피테스트 디바이스(Devices Under Test: DUTs) 상에서 행해질 테스트를 정의하도록 동작가능함 - 와,
자동으로 상기 제 1 헤더 파일로부터 제 2 헤더 파일을 생성하는 단계 - 상기 제 2 헤더 파일은 상기 적어도 하나의 테스트 클래스를 위한 헤더 파일이고, 상기 제 2 헤더 파일 및 상기 적어도 하나의 테스트 클래스는 공통의 프로그래밍 언어를 사용하여 준비됨 - 와,
상기 테스터 운영 시스템을 사용하여 상기 테스트 계획을 유효확인하는(validating) 단계와,
상기 테스트 계획 및 적어도 하나의 컴파일된 모듈(compiled module)을 실행을 위해 상기 테스터 운영 시스템 상에 로드하는(loading) 단계 - 상기 적어도 하나의 컴파일된 모듈 각각은 상기 적어도 하나의 테스트 클래스 중 각 테스트 클래스의 컴파일된 변환(compiled translation)이고, 상기 제 2 헤더 파일은 상기 적어도 하나의 컴파일된 모듈을 생성하기 위해 사용됨 - 를 포함하는
방법.
제 1 항에 있어서,
상기 제 1 헤더 파일로부터의 상기 정보로써 상기 적어도 하나의 테스트 클래스를 인스턴스화하는(instantiating) 단계와,
상기 테스트 계획을 실행하는 단계를 더 포함하는
방법.
제 1 항에 있어서,
상기 정보는 테스트 클래스 파라미터 정의를 포함하는
방법.
제 1 항에 있어서,
상기 정보는 상기 적어도 하나의 테스트 클래스를 식별하는 정의를 포함하는
방법.
제 1 항에 있어서,
상기 정보는 상기 적어도 하나의 테스트 클래스를 위한 확장 코드(extension code)를 포함하는
방법.
제 1 항에 있어서,
상기 그래픽 사용자 인터페이스는 제 1 윈도우 및 제 2 윈도우를 포함하고, 상기 제 1 윈도우는 복수의 테스트 클래스 파라미터를 위한 정보를 디스플레이하도록 동작가능하며, 상기 제 2 윈도우는 상기 제 1 윈도우 내에서 선택된 테스트 클래스 파라미터에 대응하는 정보를 디스플레이하도록 동작가능한
방법.
제 6 항에 있어서,
상기 복수의 테스트 클래스 파라미터는 디폴트 값(default value)으로 초기화되고, 또한 상기 복수의 테스트 클래스 파라미터를 위한 값은 사용자에 의해 편집되도록 동작가능한
방법.
제 1 항에 있어서,
사용자가 상기 정보를 상기 그래픽 사용자 인터페이스의 그래픽 편집기(graphical editor) 내에 입력 및 세이브하는 것에 응답하여 구문(syntax) 및 의미론적(semantic) 오류에 대해 자동으로 체크하는 단계를 더 포함하는
방법.
제 1 항에 있어서,
상기 그래픽 사용자 인터페이스는
텍스트 편집기 모드(text editor mode)와,
디스플레이 편집기 모드(display editor mode)를 포함하는
방법.
제 9 항에 있어서,
상기 디스플레이 편집기 모드 내에서 행해진 변경을 상기 텍스트 편집기 모드와 자동으로 동기화하는 단계를 더 포함하고, 상기 텍스트 편집기 모드 내에서 행해진 변경을 상기 디스플레이 편집기 모드와 자동으로 동기화하는 단계를 더 포함하는
방법.
컴퓨터 시스템에 의해 실행되는 경우 상기 컴퓨터 시스템으로 하여금 자동화된 테스트 장비(Automated Test Equipment: ATE)를 사용하여 테스트를 수행하는 방법을 수행하게 하는 컴퓨터 실행가능 명령어가 저장된 컴퓨터 판독가능 저장 매체로서, 상기 방법은
그래픽 사용자 인터페이스를 사용하여 적어도 하나의 테스트 클래스에 관한 정보를 획득하는 단계와,
자동으로 제 1 헤더 파일을 생성하는 단계 - 상기 제 1 헤더 파일의 내용은 상기 정보를 포함함 - 와,
테스터 운영 시스템을 사용하여 실행되도록 동작가능한 테스트 계획 내에 상기 제 1 헤더 파일을 임포트하는 단계 - 상기 테스터 운영 시스템은 시스템 제어기 상에 설치되고, 상기 테스트 계획은 상기 적어도 하나의 테스트 클래스의 인스턴스를 포함하며, 상기 테스트 계획은 상기 시스템 제어기에 통신가능하게 커플링된 복수의 피테스트 디바이스(Devices Under Test: DUTs) 상에서 행해질 테스트를 정의하도록 동작가능함 - 와,
자동으로 상기 제 1 헤더 파일로부터 제 2 헤더 파일을 생성하는 단계 - 상기 제 2 헤더 파일은 상기 적어도 하나의 테스트 클래스를 위한 헤더 파일이고, 상기 제 2 헤더 파일 및 상기 적어도 하나의 테스트 클래스는 공통의 프로그래밍 언어를 사용하여 준비됨 - 와,
상기 테스터 운영 시스템을 사용하여 상기 테스트 계획을 유효확인하는 단계와,
상기 테스트 계획 및 적어도 하나의 컴파일된 모듈을 실행을 위해 상기 테스터 운영 시스템 상에 로드하는 단계 - 상기 적어도 하나의 컴파일된 모듈 각각은 상기 적어도 하나의 테스트 클래스 중 각 테스트 클래스의 컴파일된 변환이고, 상기 제 2 헤더 파일은 상기 적어도 하나의 컴파일된 모듈을 생성하기 위해 사용됨 - 를 포함하는
컴퓨터 판독가능 저장 매체.
제 11 항에 있어서,
상기 방법은
상기 제 1 헤더 파일로부터 선택된 상기 정보로써 상기 적어도 하나의 테스트 클래스를 인스턴스화하는 단계와,
상기 테스트 계획을 실행하는 단계를 더 포함하는
컴퓨터 판독가능 저장 매체.
제 11 항에 있어서,
상기 정보는 테스트 클래스 파라미터 정의, 상기 적어도 하나의 테스트 클래스를 식별하는 정의, 상기 적어도 하나의 테스트 클래스를 위한 확장 코드로 이루어진 그룹으로부터 선택된
컴퓨터 판독가능 저장 매체.
제 11 항에 있어서,
상기 그래픽 사용자 인터페이스는
텍스트 편집기 모드와,
디스플레이 편집기 모드를 포함하는
컴퓨터 판독가능 저장 매체.
제 14 항에 있어서,
상기 방법은
상기 디스플레이 편집기 모드 내에서 행해진 변경을 상기 텍스트 편집기 모드와 자동으로 동기화하는 단계와,
상기 텍스트 편집기 모드 내에서 행해진 변경을 상기 디스플레이 편집기 모드와 자동으로 동기화하는 단계를 더 포함하는
컴퓨터 판독가능 저장 매체.
제 11 항에 있어서,
사용자가 상기 정보를 상기 그래픽 사용자 인터페이스의 그래픽 편집기 내에 입력 및 세이브하는 것에 응답하여 구문 및 의미론적 오류에 대해 자동으로 체크하는 단계를 더 포함하는
컴퓨터 판독가능 저장 매체.
제 11 항에 있어서,
상기 그래픽 사용자 인터페이스는 제 1 윈도우 및 제 2 윈도우를 포함하고, 상기 제 1 윈도우는 복수의 테스트 클래스 파라미터를 위한 정보를 디스플레이하도록 동작가능하며, 상기 제 2 윈도우는 상기 제 1 윈도우 내에서 선택된 테스트 클래스 파라미터에 대응하는 정보를 디스플레이하도록 동작가능한,
컴퓨터 판독가능 저장 매체.
자동화된 테스트를 수행하는 시스템으로서,
내부에 저장된 테스터 운영 시스템을 포함하는 메모리와,
복수의 피테스트 디바이스(Devices Under Test: DUTs)에 연결되도록 동작가능한 통신관련 인터페이스(communicative interface)와,
상기 메모리 및 상기 통신관련 인터페이스에 커플링된 프로세서를 포함하되, 상기 프로세서는 상기 테스터 운영 시스템에 따라
그래픽 사용자 인터페이스를 사용하여 적어도 하나의 테스트 클래스에 관한 정보를 획득하고,
자동으로 제 1 헤더 파일을 생성 - 상기 제 1 헤더 파일의 내용은 상기 정보를 포함함 - 하며,
상기 테스터 운영 시스템을 사용하여 실행되도록 동작가능한 테스트 계획 내에 상기 제 1 헤더 파일을 임포트 - 상기 테스트 계획은 상기 적어도 하나의 테스트 클래스의 인스턴스를 포함하고, 상기 테스트 계획은 상기 복수의 피테스트 디바이스(DUTs) 상에서 행해질 테스트를 정의하도록 동작가능함 - 하고,
자동으로 상기 제 1 헤더 파일로부터 제 2 헤더 파일을 생성 - 상기 제 2 헤더 파일은 상기 적어도 하나의 테스트 클래스를 위한 헤더 파일임 - 하며,
상기 테스터 운영 시스템을 사용하여 상기 테스트 계획을 유효확인하고,
상기 테스트 계획 및 적어도 하나의 컴파일된 모듈을 실행을 위해 상기 테스터 운영 시스템 상에 로드 - 상기 적어도 하나의 컴파일된 모듈 각각은 상기 적어도 하나의 테스트 클래스 중 각 테스트 클래스의 컴파일된 변환이고, 상기 제 2 헤더 파일은 상기 적어도 하나의 컴파일된 모듈을 생성하기 위해 사용됨 - 하게 동작하도록 구성된
시스템.
자동화된 테스트 장비(Automated Test Equipment: ATE)를 사용하여 테스트를 수행하는 방법으로서,
그래픽 사용자 인터페이스를 사용하여 적어도 하나의 테스트 클래스에 관한 정보를 획득하는 단계와,
자동으로 헤더 파일을 생성하는 단계 - 상기 헤더 파일의 내용은 상기 정보를 포함함 - 를 포함하되,
상기 그래픽 사용자 인터페이스는 디스플레이 편집기 윈도우 및 텍스트 편집기 윈도우를 포함하고, 또한 상기 디스플레이 편집기 윈도우 내에서 행해진 변경은 상기 텍스트 편집기 윈도우에서의 대응하는 변경에 자동으로 맵핑되며, 또한 상기 텍스트 편집기 윈도우 내에서 행해진 변경은 상기 디스플레이 편집기 윈도우에서의 대응하는 변경에 자동으로 맵핑되는
방법.