KR20030087977A - 테스트 실행 시스템의 동작 방법 및 피시험 장치 테스트용테스트 실행 시스템 및 테스트 실행 시스템 제공 제품 - Google Patents

테스트 실행 시스템의 동작 방법 및 피시험 장치 테스트용테스트 실행 시스템 및 테스트 실행 시스템 제공 제품 Download PDF

Info

Publication number
KR20030087977A
KR20030087977A KR10-2003-0029410A KR20030029410A KR20030087977A KR 20030087977 A KR20030087977 A KR 20030087977A KR 20030029410 A KR20030029410 A KR 20030029410A KR 20030087977 A KR20030087977 A KR 20030087977A
Authority
KR
South Korea
Prior art keywords
test
procedure
measurement
execution system
list
Prior art date
Application number
KR10-2003-0029410A
Other languages
English (en)
Inventor
숫톤크리스토퍼케이
Original Assignee
애질런트 테크놀로지스, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 애질런트 테크놀로지스, 인크. filed Critical 애질런트 테크놀로지스, 인크.
Publication of KR20030087977A publication Critical patent/KR20030087977A/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31912—Tester/user interface
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Human Computer Interaction (AREA)
  • Theoretical Computer Science (AREA)
  • Debugging And Monitoring (AREA)
  • Tests Of Electronic Circuits (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

계층적 테스트 실행 시스템은 프로시저, 테스트, 측정 및 데이터포인트 레벨을 포함한다. 프로시저는 테스트의 순서화된 리스트이고, 테스트는 동일한 테스트 알고리즘을 공유하여 동일한 소프트웨어 코드를 공유하는 프로시저의 측정 그룹이고, 측정은 테스트용 구성 혹은 셋업이며 테스트에 파라메터를 제공하고, 데이터포인트는 하나의 측정이 다수의 결과를 낳는 경우 하나의 결과를 선택하는 부가적인 파라메터를 포함하는 측정의 서브세트이다. 테스트 실행 시스템은 개시된 후 모델 리스트를 표시하고 사용자는 테스트될 모델을 선택한다. 그런 다음 프로그램은 선택된 모델에 대응하는 테스트 소프트웨어를 업로드하고 사용자에게 프로시저의 리스트 및 설명을 나타낸다. 사용자는 프로시저들 중 하나를 선택하고 프로그램은 테스트 소프트웨어로부터 선택된 프로시저를 검색하고 그것을 프로시저에 의해 결정된 테스트, 측정 및 데이터포인트로 확장한다. 테스트 실행 시스템은 테스트, 측정 및 데이터포인트를 루핑하면서, 결과를 생성하고 그에 대응하는 데이터 구조체를 계속적으로 생성한다.

Description

테스트 실행 시스템의 동작 방법 및 피시험 장치 테스트용 테스트 실행 시스템 및 테스트 실행 시스템 제공 제품{METHOD AND APPARATUS FOR GENERATING ELECTRONIC TEST AND DATA STRUCTURE}
테스트 개발, 인증 테스팅(qualification testing) 및 제조 테스팅(manufacturing testing)을 포함하는 테스트 시스템은 제품의 수명 사이클의 여러 단계(phase)에 걸쳐 복잡한 전자 제품 장치를 테스트하는 데 이용된다. 이들 복잡한 전자 제품 장치는 다수의 독립 파라메터에 대해 테스트되고 다수의 상이한 모델 패밀리의 일부이다. 상이한 제품, 테스트될 상이한 파라메터 및 제품 모델 패밀리의 수가 많기 때문에, 테스트 엔지니어는 잘못된 변경 또는 코드로 인해 테스트 시스템이 오작동을 일으키지 않도록 하면서 테스트 시스템을 끊임없이 변경하여야 한다.
종래 기술의 테스트 프로그램은 테스트를 설계하기가 어려운데 그 이유는 테스트 엔지니어가 개별 테스트, 테스트 리스트 또는 테스트 알고리즘과 같은 테스트 프로그램의 개별 부분을 설계 또는 변경할 경우 전체 테스트에 초점을 맞추어야 하기 때문이다. 종래 기술의 시스템에 있어서, 테스트 프로시저는 테스트 알고리즘내로 통합되고, 그에 따라 테스트 프로시저를 변경하는 동안 잘못 입력된 커맨드에 테스트 알고리즘이 민감해질 수 있다. 더 나아가, 종래 기술의 프로그램은 테스트를 설계하기가 어려운데 그 이유는 그들이 데이터 테이블을 이용하기 때문이다. 이것은 테스트 엔지니어가 테스트 프로그램에 사용될 모든 파라메터를 생성하고 이 데이터 테이블에 입력하도록 요구한다. 이것은 또한 테스트 엔지니어가 데이터를 구조화하기 위해 지루하고 긴 프로시저를 수행하도록 요구하는데, 여기서 각 데이터포인트에 대한 파라메터는 테이블에 입력되어야 한다. 데이터 입력 프로세스의 지루함과 추상성, 및 데이터 테이블 방법에서의 집중적인 프로그래머의 입력에 대한 요구는 에러를 야기할 수 있다.
또한, 테스트 시퀀싱은 구조화 프로그램(structured programs)으로 통합된 매우 큰 대량(large bulky) 테스트 알고리즘으로 설계된 테스트 시스템을 사용하는 경우, 고정되어 있어(rigid) 인플렉시블(inflexible)할 수 있다. 이것은 올바른 테스트 프로시저 변경 또는 입력으로 인해, 테스트 엔지니어가 테스트 시스템 알고리즘을 재기록 또는 디버깅하는데 소비하는 시간을 증가시킨다. 또한, 테스트의 일부는 테스트 엔지니어에 의해 쉽게 재사용될 수 없는데 그 이유는 그들이 보다 큰 구조화 프로그램으로 작성되기 때문이다. 이렇게 테스트 시스템 코드를 재사용할 수 없기 때문에, 재사용할 수 없는 새로운 테스트 시스템 코드를 재기록 또는 재입력하는 시간이 증가된다.
본 발명은 본 기술 분야를 진보시키고, 테스트가 실행되는 경우 재사용가능 부분으로부터 테스트를 생성하고 이어서 커스텀 데이터(custom data)를 생성하는 테스트 실행 시스템을 제공함으로써 위에서 언급한 문제를 극복하는 데 도움을 준다.
일반적으로, 본 발명에 따른 테스트 실행 시스템은 다음과 같이 기능하는 방법 및 소프트웨어 프로그램을 포함한다. 이 시스템은 사용자에게 테스트 소프트웨어가 이용가능한 모델 리스트를 제시하고, 사용자는 테스트될 모델을 선택하며, 그런 다음 프로그램은 선택된 모델에 대응하는 테스트 소프트웨어를 업로드하고, 그런 다음 이 프로그램은 업로드된 소프트웨어에 프로시저의 리스트 및 설명을 요구하고, 이들을 사용자에게 제시하며, 프로그램은 사용자가 프로시저들 중 하나를 선택하는 동안 중단되고, 프로시저가 선택된 경우, 프로그램은 소프트웨어로부터 선택된 프로시저를 검색하고, 프로시저의 규정(prescription)에 따라, 프로시저 소프트웨어 객체를 이하에서 자세히 설명될 테스트, 측정 및 데이터포인트로 확장한다. 그 후, 테스트 실행 시스템은 테스트, 측정 및 데이터포인트를 루핑(looping)하면서, 데이터 구조체를 계속적으로 생성한다.
본 발명은 테스트 실행 시스템과는 별개이고 분리되어 별개인 피시험 장치(DUT)를 전자적으로 테스트하는 테스트 실행 시스템을 동작시키는 방법을 제공한다. 이 방법은 다수의 테스트와 하나의 프로시저를 포함하되, 각 테스트는 테스트 알고리즘을 규정하는 소프트웨어 코드를 포함하고, 프로시저는 순서화된 테스트리스트를 나타내는 데이터를 포함하는 단계와, 순서화된 리스트에 의해 결정된 테스트들 중 사전 결정된 테스트들을 결합함으로써 프로시저를 확장하는 단계와, DUT에 대한 프로시저를 실행하고 사전결정된 테스트의 결과를 포함하는 데이터 구조체를 생성하는 단계를 포함한다. 바람직하게, 이 프로시저는 하나 이상의 측정 리스트를 포함하되, 각 측정은 특정 테스트를 위한 구성을 포함하고, 프로시저의 확장 단계는 리스트 내의 측정을 특정 테스트와 연관된 측정 콜렉션에 부가하는 단계를 포함한다. 바람직하게, 프로시저, 테스트 및 측정은 소프트웨어 객체로서 구현된다. 바람직하게, 각 테스트는 테스트 객체를 포함하고, 프로시저는 프로시저 객체를 포함하며, 각 측정은 측정 객체를 포함하고, 측정 객체는 테스트 파라메터를 테스트 객체에 전달한다. 바람직하게, 프로시저는 데이터포인트 리스트를 포함하되, 각 데이터포인트는 특정 측정에 대한 다수의 결과들 중 하나와 연관되고, 프로시저의 확장 단계는 데이터포인트를 특정 측정과 연관된 데이터포인트 콜렉션에 부가하는 단계를 포함한다. 바람직하게, 프로시저의 확장 단계는 프로시저에 의해 결정된 특정 측정과 연관된 데이터포인트 객체의 콜렉션에 데이터포인트 객체를 부가하는 단계와, 프로시저에 의해 결정된 특정 테스트와 연관된 측정 객체의 콜렉션에 측정 객체를 부가하는 단계 및 사전결정된 테스트 객체를 프로시저 객체에 부가하는 단계를 포함한다. 바람직하게, 프로시저의 확장 단계는 소스트웨어 객체를 생성하는 단계를 더 포함한다. 바람직하게, 실행 단계는 테스트, 측정 및 데이터포인트의 결과를 포함하는 데이터 테이블을 생성하면서 테스트, 측정 데이터포인트를 루핑하는 단계를 포함한다. 바람직하게, 각 테스트 및 프로시저는 소프트웨어 객체를 포함하고, 프로시저의 확장 단계는 사전결정된 테스트 객체를 프로시저 객체에 부가하는 단계를 포함한다. 바람직하게, 이 방법은 테스트가 가능한 모델 리스트를 디스플레이하는 단계와, 모델들 중 하나를 선택하는 더 단계를 포함하고, 저장 단계는 선택된 모델과 연관된 테스트 및 프로시저를 저장하는 단계를 포함한다. 바람직하게, 저장 단계는 선택된 모델과 연관된 DLL 파일을 로드하는 단계를 더 포함한다. 바람직하게, 이 방법은 DLL 파일로부터 이용가능한 프로시저 리스트를 검색하는 단계와, 그 리스트를 디스플레이하는 단계 및 프로시저를 선택하는 단계를 포함한다. 바람직하게, 이 방법은 이용가능한 프로시저의 리스트를 디스플레이하는 단계와 프로시저를 선택하는 단계를 더 포함한다.
본 발명은 테스트 실행 시스템과는 분리되어 별개인 피시험 장치(DUT)를 테스트하는 테스트 실행 시스템을 제공한다. 이 시스템은 각 테스트가 테스트 알고리즘을 규정하는 소프트웨어 코드를 포함하고 프로시저는 순서화된 테스트 리스트를 나타내는 데이터를 포함하는 다수의 테스트와 하나의 프로시저를 저장하는 전자 메모리와, 순서화된 리스트에 의해 결정된 테스트들 중 사전 결정된 테스트들을 결합함으로써 프로시저를 확장하고 그 프로시저를 DUT 상에 실행하여 테스트 결과를 생성하는, 메모리와 통신하는 프로세와, 프로세서와 통신하고 테스트 결과를 포함하는 데이터 구조체를 포함하는 그래픽 사용자 인터페이스(GUI)를 포함한다. 바람직하게, 프로시저는 하나 이상의 측정 리스트를 포함하는데, 각 측정은 특정 테스트를 위한 구성을 포함하고, 프로시저가 확장되는 경우, 프로세서는 리스트 내의 측정들을 특정 테스트와 연관된 측정 콜렉션에 부가한다. 바람직하게, 프로시저는데이터포인트 리스트를 포함하는데, 각 데이터포인트는 특정 측정에 대한 다수의 결과들 중 하나와 연관되고, 프로시저가 확장되는 경우, 프로세서는 데이터포인트를 특정 측정과 연관된 데이터포인트의 콜렉션에 부가한다. 바람직하게, GUI는 테스트가 가능한 모델 리스트를 포함하는 메뉴를 더 포함한다. 바람직하게, 데이터 구조체는 테이블 또는 계층적 트리로 구성된 그룹으로부터 선택된다.
본 발명은 테스트 실행 시스템과는 분리되어 별개인 피시험 장치(DUT)에 대한 테스트를 제어하는 테스트 실행 시스템을 제공하는 제품을 제공한다. 이 제품은, 프로세싱 유닛이 각 테스트가 테스트 알고리즘을 규정하는 소프트웨어 코드를 포함하고 프로시저가 순서화된 테스트 리스트를 나타내는 데이터를 포함하는 다수의 테스트 및 하나의 프로시저를 메모리로 로드하고, 순서화된 리스트에 의해 결정된 테스트들 중 사전결정된 테스트들을 결합함으로써 프로시저를 확장하고, DUT 상에 프로시저를 실행하여 사전결정된 테스트의 결과들을 포함하는 데이터 구조체를 생성하도록 지시하는 인스트럭션과, 이 인스트럭션을 저장하는 프로세싱 유닛에 의해 판독가능한 매체를 포함한다. 바람직하게, 이 프로시저는 하나 이상의 측정 리스트를 포함하는데, 각 측정은 특정 테스트를 위한 구성을 포함하고, 확장 인스트럭션은 리스트 내의 측정을 특정 테스트와 연관된 측정 콜렉션에 부가하도록 지시하는 인스트럭션을 포함한다. 바람직하게, 이 프로시저는 데이터포인트 리스트를 포함하는데, 각 데이터포인트는 특정 측정의 다수의 결과들 중 하나와 연관되고, 확장 인스트럭션은 데이터포인트를 특정 측정과 연관된 데이터포인트 콜렉션에 부가하도록 하는 인스트럭션을 포함한다. 바람직하게, 각 테스트는 테스트 소프트웨어 객체를 포함하고, 프로시저는 프로시저 소프트웨어 객체를 포함하고, 각 측정은 측정 객체를 포함하며, 각 데이터포인트는 데이터포인트 소프트웨어 객체를 포함하고, 확장 인스트럭션은 데이터포인트 객체를 프로시저에 의해 결정된 특정 측정과 연관된 데이터포인트 객체의 콜렉션에 부가하고, 그 측정 객체를 프로시저에 의해 결정된 특정 테스트와 연관된 측정 객체의 콜렉션에 부가하며, 사전결정된 테스트 객체를 프로시저 객체에 부가하도록 지시하는 인스트럭션을 포함한다.
본 발명은 테스트 엔지니어가 복잡한 테스트를 개별적으로 고려될 수 있으며 상호작용이 쉽게 이해될 수 있는 조작이 용이한 유닛으로 분해할 수 있도록 해준다. 본 발명은 보다 효율적으로 데이터 구조체를 생성할 수 있도록 해주는데 그 이유는 테스트 객체가 측정 및 데이터포인트를 조직적이고 논리적인 방식으로 일관되게 생성하기 때문이다. 위에서 설명한 본 발명 장점 및 다른 장점은 도면과 연계한 바람직한 실시예의 설명을 읽음으로써 보다 잘 이해될 수 있다.
도 1은 본 발명의 바람직한 실시예의 주된 하드웨어 구성 요소의 블록도,
도 2는 테스트 시스템 및 관련 인터페이스 객체의 블록도,
도 3은 커스텀 데이터 구조체 구성 요소의 계층에 관한 블록도,
도 4는 테스트 소프트웨어의 방법, 베이스 Exec(202) 프로그램과의 상호작용 및 그들이 호출되는 순서를 예시적으로 도시하는 개략도,
도 5는 본 발명에 따른 테스트 실행 프로그램의 바람직한 실시예의 흐름도,
도 6은 도 5의 확장 테스트 객체 방법의 실시예의 흐름도,
도 7은 본 발명에 의해 생성된 데이터 구조체의 두 개의 실시예를 도시하는, 본 발명에 따른 전형적인 그래픽 사용자 인터페이스를 예시하는 도면.
도면의 주요 부분에 대한 부호의 설명
100 : 컴퓨터 시스템101 : 메모리
102 : 마이크로프로세서104 : 입력 장치
106 : 출력 장치108 : DUT
206 : 테스트 소프트웨어 객체214 : 플러그-인
304 : 프로시저 객체312 : 측정 객체
320 : 파라메터 객체328 : 사양 객체
본 발명은 전자 테스트 시스템에서 커스텀 데이터 구조체(custom data structures)를 생성하는 방법 및 장치를 제공한다.
본 발명은 전자 테스트 실행 프로그램(electronic test executive program)에 관한 것이다. 도 1은 본 발명에 따라 테스트 실행 프로그램을 실행하는 컴퓨터 시스템(100)을 도시한다. 컴퓨터 시스템(100)은 메모리(101), 마이크로프로세서(102), 입력 장치(104) 및 출력 장치(106)를 포함한다.메모리(101)는 경로(110)를 통해 마이크로프로세서(102)에 접속된다. 메모리(101)는 판독 전용 메모리(ROM)와 같은 비휘발성 메모리 또는 랜덤 액세스 메모리(RAM)와 같은 휘발성 메모리일 수 있다. 입력 장치(104)는 경로(112)를 통해 마이크로프로세서(102)에 접속된다. 입력 장치(104)는 키보드, 마우스, 조이스틱 또는 사용자가 데이터를 입력하할 수 있도록 해주는 임의의 다른 장치 및 소프트웨어 드라이버일 수 있다.
바람직한 실시예에서, 본 발명의 테스트 실행 프로그램은 인스트럭션으로서 메모리(101)에 저장된다. 당업자라면 이 인스트럭션은 마이크로프로세서(102)에 의해 판독가능하고 실행가능한 컴퓨터 소프트웨어 및/또는 펌웨어로서 저장될 수 있음을 알 수 있을 것이다. 테스트 실행 프로그램에 의해 실행된 테스트 결과는 출력 장치(106) 상에 디스플레이된다. 출력 장치(106)는 디스플레이이고 애플리케이션이 사용자에게 이미지를 디스플레이할 수 있도록 해주는 연관된 드라이버이다. 당업자라면 디스플레이는 종래의 음극선 모니터 또는 액정 디스플레이(LCD)일 수 있음을 알 수 있을 것이다. 실제 사용되는 디스플레이는 본 발명의 목적에는 중요하지 않다.
마이크로프로세서(102)는 본 발명의 테스트 실행 프로그램을 실행한다. 마이크로프로세서(102)는 경로(116)를 통해 피시험 장치(DUT)(108)와 통신한다. 마이크로프로세서(102)는 전선(118)을 통해 테스트 장비(117)를 제어한다. 마이크로프로세서(102)가 경로(116) 및 전선(118)을 통해 수신한 신호는 메모리(101)에 저장된다.
당업자라면 본 발명은 도 1과 동일한 개괄적 구성을 갖는 임의의 전자 장치로 구현될 수 있음을 알 수 있을 것이다. 이들 전자 장치는 컴퓨터 시스템, 하드웨어에 내장된 논리 회로 및 전자 분석기를 포함하나 여기에 제한되지 않는다.
이하에서 보다 자세히 설명되는 바와 같이, 테스트될 각 DUT는 테스트 실행 소프트웨어에 의해 테스트될 수 있는 장치 그룹 중 하나이다. 이러한 각 장치는 본 명세서에서 "모델"로 지칭된다. 당업계에 알려진 바와 같이, 모델의 특성은 어떤 종류의 테스트가 모델에 행해질 지를 결정한다. 예를 들어, 오실로스코프는 소정 특성의 전기적 구성 요소들을 갖고 있는데, 이들 각각은 각 구성 요소들이 적절히 동작하는지를 결정하기 위해 테스트될 필요성이 있는 것에 의해 결정되는 테스트 프로시저를 구비한다. 이들 일반화된 테스트는 본 명세서에서 프로시저로 지칭된다. 종래 기술에 있어서, 예를 들어 오실로스코프용 테스트가 설계되었을 때마다, 테스트 엔지니어는 그 특정 오실로스코프에 대해 테스트를 완전히 규정한 테스트 알고리즘을 생성하였다. 그런 다음 테스트 엔지니어는 알고리즘에 대한 모든 입력 데이터를 제공한 데이터 테이블을 생성하였다. 오실로스코프에 대한 설계 파라메터가 변경되었을 경우, 테스트 알고리즘 및 데이터 테이블도 변경되어야 했다. 이하에서 보다 분명히 설명되는 바와 같이, 본 발명에 따른 테스트 실행 시스템에 있어서, 테스트 알고리즘 및 데이터 테이블은 본 발명에 따른 시스템에 의해 계속해서 생성된다.
본 발명에 따른 테스트 실행 시스템(100)은 일반적으로 다음과 같이 기능한다. 그것은 테스트 소프트웨어가 이용가능한 모델 리스트를 제시하고 사용자는 테스트될 모델을 선택하며, 그런 다음 프로그램은 선택된 모델에 대응하는 테스트 소프트웨어를 업로드하고, 그런 다음 프로그램은 업로드된 소프트웨어에 프로시저의 리스트 및 설명을 요구하고 이것들을 사용자에게 제시하며, 프로그램은 사용자가 프로시저들 중 하나를 선택하는 동안 잠시 중단되고, 프로시저가 선택된 경우, 프로그램은 소프트웨어로부터 선택된 프로시저를 검색하고 그것을 이하에서 설명될 테스트, 측정 및 데이터포인트로 확장한다. 그 후, 테스트 실행 시스템은 테스트, 측정 및 데이터포인트를 루핑하면서 데이터 구조체를 계속해서 생성한다.
본 발명에 따른 소프트웨어 프로그램은 도 2 내지 도 5에 도시되어 있고, 이하에서 설명될 것이다. 본 발명에 따른 프로그램의 핵심은 그것이 계층적이라는 것인데, 즉 그것은 다수의 레벨을 포함하되 각 레벨은 그것이 포함하는 하위 레벨로 분기한다. 바람직하게, 이 계층은 프로시저, 테스트, 측정 및 데이터포인트 레벨을 포함하는 네 개의 레벨 계층이다. 프로시저는 순서화된 테스트 리스트이고, 프로시저들은 "턴-온", "최종" 및 "환경적"과 같은 명칭을 가진다. 테스트는 동일한 테스트 알고리즘, 따라서 동일한 소프트웨어 코드를 공유하는 프로시저에서의 측정 그룹이다. 테스트는 "진폭 정확성" 및 "고조파 왜곡"과 같은 명칭을 가진다. 측정은 테스트를 위한 구성 또는 셋업이고 테스트에 파라메터를 제공한다. 측정들은 "레인지=10 볼트", "주파수=100 KHz" 및 "고조파=3"과 같은 명칭을 가진다. 데이터포인트는 하나의 측정이 다수의 결과를 낳는 경우 하나의 결과를 선택하는 부가적인 파라메터를 포함하는 측정의 서브세트(subset)이다. 데이터포인트는 "채널=1" 및 "피크"와 같은 명칭을 가진다. 계층은 바람직하게 소프트웨어에서 네개 객체의 트리로서 구현될 수 있고, 이들 각각의 객체는 계층 레벨들 중 하나에 매핑된다. 객체들의 상호작용은 계층 레벨 간의 관계를 반영하는 포인터에 의해 통제된다.
본 발명을 상세하게 설명하기에 앞서, 본 명세서에 사용될 용어를 규정하는 것이 도움이 될 것이다. 본 명세서에서 테스트 소프트웨어라는 용어는 특정 제품을 테스트하기 위해 테스트 개발자에 의해 제공된 코드 구성 요소(206)를 의미한다. 입력 장치라는 용어는 키보드, 노브(knob), 스핀 콘트롤, 마우스, 조이 스틱, 터치 패드 또는 롤러 볼 및 다른 종래의 입력 장치를 의미한다. 스트링이라는 용어는 대개 사람이 판독가능한 텍스트 내의 문자로 구성된 데이터 구조체를 의미한다.
구성 요소 객체 모델(COM)이라는 용어는 구성 요소 아키텍쳐에 독립적이고 플랫폼에 독립적이며, 일반적으로 사용되는 함수 및 서비스를 캡슐화하는 범용의 객체 지향 수단(object-oriented means)을 의미하는 컴퓨터 언어를 의미한다. COM은 이름, 반환 유형 및 인터페이스 방법의 파라메터를 규정한다. 객체라는 용어는 소프트웨에 객체를 의미하고, "객체 지향 프로그래밍"으로 알려진 프로그램 유형에서 일반적으로 알려진 바와 같이, 인터페이스로 수집된 함수 또는 방법 세트의 특정 인스턴스(specific instance)이며 각 객체는 이것과 관련된 데이터를 가진다. 방법은 메시지가 특정 객체에 전달되는 경우 실행되는 코드를 메시지가 수행하는 동작이다. 객체에 대한 모든 통신은 메시지를 통해 이루어진다. 메시지는 객체에 대한 인터페이스를 규정한다. 클래스는 무엇이 객체가 될 것인가를 규정한다. 클래스로부터 객체를 생성한다는 것은 클래스의 인스턴스를 생성한다는 것을 의미한다. 클래스의 인스턴스는 실제 객체이다. 클래스는 객체의 청사진이다. 객체는 특정 클래의 유일한 개별 인스턴스이다. 인터페이스라는 용어는 특성의 규정된 콜렉션이고 클래스에 의해 구현될 수 있는 방법이다. 인터페이스는 본질적으로 인터페이스를 구성하는 함수들에 대한 포인터 테이블이다. 포인터는 데이터 또는 코드에 대한 간접 참조이고, 어드레스와 유사하다. 콜렉션은 객체에 대한 참조 리스트 또는 어레이이다. COM 하의 각 인터페이스는 수적으로 유일하다. 클래스는 하나 이상의 다른 클래스로부터 파생될 수 있는데, 이것은 상속(inheritance)으로서 알려져 있다.
COM은 인터페이스 상속을 지원하는데, 이것은 인터페이스가 다른 인터페이스로부터 파생되고, 베이스 인터페이스의 이진 서명(binary signature)을 상속할 수 있다는 것을 의미한다. 방법의 명칭과 파라메터의 결합은 대개 그것의 서명으로 지칭된다. 임명(delegation)은 파생된 객체 가 베이스 객체의 인스턴스를 생성 또는 예시한다는 것을 의미한다. 파생된 객체는 대체되는 새로운 행위(behaviors) 및 방법에 대한 코드를 포함하고, 변경되지 않은 방법 호출에 대한 통로(pass through)로서 작용한다. 컴퓨터 플랫폼이라는 용어는 소프트웨어 오프레이팅 시스템 및/또는 윈도우TMNTTM애플리케이션과 같은 오픈 하드웨어를 의미한다. 다이나믹 링크 라이브러리(DLL)라는 용어는 요청에 따라 로드될 수 있고 작동시에 링크될 수 있으며 그 후, 코드가 더 이상 필요하지 않을 경우 언로드될 수 있는 컴퓨터 플랫폼용 실행가능 코드 모듈을 의미한다. 테스트 소프트웨어는 DLL 파일들에 포함되어 있으며, 따라서 그들은 독립적으로 개발될 수 있고 전달될 수 있다.
본 발명의 특징은 테스트 및 프로시저 구성에 도움이 되는 객체 모델을 포함하는 COM 인터페이스이다. 본 발명은 테스트 개발자에 의해 특별히 설계된 파라메터를 사용함으로써 효율적이고 정확한 테스트 루틴 개발을 촉진한다. 또한, 본 발명의 객체 특성(nature) 때문에, 파라메터는 새로운 테스트 프로시저에 대한 예비 파라메터를 생성하지 않고도 새로운 테스트 프로시저에 대해 쉽게 변경될 수 있고 재사용될 수 있다.
본 발명에 따른 소프트웨어 프로그램은 생산적이고, 효율적이며 현재유통되고 있는 프로그래밍 언어인 비주얼 베이직TM프로그램밍 언어를 사용하여 가장 쉽게 개발될 수 있다. 이러한 표준 프로그래밍 언어는 테스트 개발자가 복잡한 테스트 프로시저를 쉽고 효율적으로 구성할 수 있도록 해준다.
특정 모델용 테스트 소프트웨어는 DLL 파일 내에 패키지된다. 테스트 조작자가 다른 제품 모델 패밀리를 선택하는 경우, 이 테스트 소프트웨어 DLL은 참조되지 않고, 언로드되며 다른 테스트 소프트웨어 DLL이 로드된다. 테스트 소프트웨어 및 본 발명에 의해 공유되는 데이터 객체는 Exec3Objects.DLL이라는 이름의 DLL 파일 내에 규정된다. 이 파일은 대개 데이터 객체 및 테스트 인터페이스에 대한 클래스 규정을 포함하고, 그것은 인벤션 코드(invention code)를 거의 또는 전혀 포함하지 않는다. 바꾸어 말하면, Exec3Objects.DLL은 Exec3와 테스트 소프트웨어간의 인터페이스를 규정하는 순 가상 베이스 클래스(pure virtual base classes)를 포함한다. 실제 테스트 소프트웨어 클래스는 비주얼 베이직TMIMPLEMENTSTM키워드를 사용하여 이들 베이스 클래스로부터 파생된다. 본 명세서에 있어서 "부가(add)"라는 용어가 하나의 객체를 또 다른 객체에 부가하는 상황에서 사용되는 경우, 이 함수는, 포인터를 사용하여 하나의 객체가 또 다른 객체에 포함되어 있다는 것을 나타내는 방식 또는 실제로 다른 코드 내에 코드를 포함하는 방식과 같이 당업계에게 알려진 임의의 방식으로 수행될 수 있다.
도 2는 본 발명에 따른 테스트 실행 프로그램(200)의 바람직한 실시예의 블록도이다. 이 프로그램은 바람직하게 시스템(200)이 다른 컴퓨터 시스템에 의해 개시되고 외부적으로 모니터링되게 해주는 인터페이스(210)를 포함하는데, 이것은 바람직하게 ActiveXTMCOM 인터페이스(210)이다. Exec 객체(202)는 데이터 객체와 테스트 인터페이스의 클래스 규정을 포함하고, 본질적으로 프로그램을 조작하기 위한 인터페이스를 제공한다. 동작 동안, 현 테스트 객체(308)(도 3) 및 측정 객체(312)는 Exec 객체(202)에 의해 참조된다. 도 3에 자세히 도시되어 있는 테스트 소프트웨어 객체(206)는 특정 제품을 테스트하기 위해, 테스트 개발자에 의해 기록된 코드 구성 요소를 포함한다. 본 설명에 있어서, 테스트 소프트웨어 객체라는 용어는 테스트 객체라는 용어와는 구별된다. 모델 패밀리와 테스트 소프트웨어 객체(206) 간에 일 대 일 대응이 존재한다. 시스템(200)은 시스템(200)과 다른 시스템, 즉 장치 교정 검증 시스템(equipment calibration verification system) 또는 예를 들어 ExcelTM인 데이터베이스와 같은 다른 소프트웨어 시스템 간의 인터페이스인 플러그-인(214)도 포함한다.
본 발명의 바람직한 ActiveXTM인터페이스의 메인/루트 객체는 그것의 애플리케이션 객체이다. 이 객체에 대한 설명은 본 발명의 애플리케이션 실행가능 파일로 시작할 것이다. 애플리케이션 객체는 본 발명의 구성 초기화 파일 및 본 발명의 "모델" 메뉴에 나열된 테스트 소프트웨어 이름인 모델 패밀리 스트링을 포함한다. 그것을 셋팅하게 되면 본 발명은 새로운 테스트 소프트웨어를 로드될 것이다. 능동 테스트 프로시저의 이름도 애플리케이션 객체에 포함된다. 그것을 셋팅하게 되면 본 발명은 테스트 프로시저를 로드하고 확장한다. 특정 모델용 테스트 소프트웨어는 DLL 파일 내에 패키지된다. 테스트 조작자가 다른 모델 패밀리를 선택하는 경우, 이 테스트 소프트웨어 DLL은 참조되지 않고, 언로드되며 다른 테스트 소프트웨어 DLL이 로드된다. 테스트 소프트웨어 및 본 발명에 의해 공유되는 데이터 객체의 클래스 규정은 Exec3Objects.DLL라는 이름의 DLL 파일 내에 규정된다. 실제 테스트 소프트웨어 및 플러그-인 클래스는 바람직하게 비주얼 베이직TMIMPLEMENTSTM키워드를 사용하여 이들 베이스 클래스로부터 파생된다.
도 3은 테스트 소프트 객체(206)를 세부적으로 도시한다. 본 발명의 계층적 구조는 블록도 형태로 도시되어 있다. 일 예에서, 테스트 소프트웨어(206)는 테스트 개발자가 특정 장치의 패밀리를 테스트하기 위해 생성한 제품 모델 패밀리 파일에 대응한다. 테스트 소프트웨어 DLL 패키지는 전형적으로 하나의 비주얼 베이직TM프로젝트이며 개정 제어(revision control) 하에서 유지될 수 있다. 계층 구조의 상단은 프로시저 객체(304)이다. 이 프로시저 객체(304) 층은 실행될 테스트 객체(308)(테스트 소프트웨어(206)와 혼동되지 않음)의 순서화된 리스트, 시퀀스 또는 스크립트(306)이다. 각 테스트 객체(308)는 측정 객체(312) 및 데이터포인트 객체(316)의 콜렉션(310)을 포함한다. 테스트 소프트웨어 DLL 파일은 이들 프로시저 객체(304)를 규정한다. 테스트 조작자는 실행될 프로시저 객체(304)의 서브세트를 선택할 수 있다. 본 발명은 프로시저 객체(304)를 실행한다. 본 발명은 프로시저 객체(304)를 코드로서가 아닌 입력 데이터로 본다. 프로시저 객체(304)는 중요한 코드를 포함하고 있지 않으며 관련 변수, 커스텀 데이터 구조, COM 객체의 그룹, 또는 특성-전용(property-only)(또는 코드레스(code-less)) 비주얼 베이직TM클래스로서 간주될 수 있다.
바람직하게 프로시저 객체(304)는 COM 객체의 구조체로서 테스트 소프트웨어 DLL로부터 전달된다. 테스트 개발자는 이 COM 객체의 구조체를 구성하는 코드를 기록함으로써 프로시저 객체(304)를 규정한다. 프로시저 객체(304) 이름은 테스트 조작자에게 프로시저를 식별해주고 테스트 객체(308)의 콜렉션을 포함한다. 본 발명은 프로시저 객체들(304)을 소유하고 이 객체들은 테스트 소프트웨어 초기화에서 테스트 개발자 공급 코드(test developer-supplied code)에 의해 생성된다. 본 발명의 제 2 층은 테스트 객체(308) 층이다. 테스트 객체(308) 층은 동일한 테스트알고리즘을 공유하여 동일한 테스트 소프트웨어 코드를 공유하는 측정 객체들(312)의 그룹이다. 프로시저를 실행하기 위해, 본 발명은 각 측정 및 데이터포인트마다 테스트를 반복적으로 호출한다. 본 발명에 있어서 테스트 객체(308)는 데이터가 아닌 코드이다. 테스트 개발자는 비주얼 베이직TM클래스 모듈을 테스트 소프트웨어 객체(206)에 입력함으로써 테스트를 구현한다. 테스트 개발자가 이 클래스에 부여하는 코드는 테스트 알고리즘을 파라미터-구동 방식(parameter-driven way)으로 구현해야 한다. 그런 다음, 프로시저 규정 코드에, 테스트 개발자는 코드 테스트 소프트웨어 객체(206)를 삽입하여 이 클래스의 인스턴스를 생성하고 그것을 프로시저 객체(304)에 부가한다. 테스트 소프트웨어 객체(206)는 테스트 객체(308)를 소유한다.
테스트 객체(308) 이름은 테스트 조작자에 의해 수행될 측정을 식별한다. 테스트 객체(308)는 테스트 초기화 방법 코드, 측정 초기화 방법 코드 및 결과 획득 방법 코드도 포함한다. 각 테스트는 개별 비주얼 베이직TM클래스 파일로 구현되어야 하고, 구현 키워드를 사용하여 테스트 인터페이스를 참조해야 한다. 테스트 객체는 측정 객체(312)의 콜렉션(310)을 포함한다.
본 발명의 제 3 층은 측정 객체(312) 층이다. 측정 객체(312)는 테스트 객체(308)에 대한 구성 또는 셋업이다. 테스트 객체(308) 내의 각 측정은 상이한 셋업 또는 구성 파라메터를 가질 수 있다. 테스트 객체(308)는 파라메터로 구동되고 테스트 객체(308)는 측정 객체(312)로부터 그들의 파라메터를 얻는다. 본 발명은측정 객체(312)를 프로시저 객체(304)에서 테스트 객체(308)로 전달될 데이터로 본다. 테스트 개발자는 새로운 측정 객체(312)를 생성하고 그것을 프로시저 객체(304)의 테스트 객체(308)에 부가함으로써 테스트 객체(308)에 대한 측정 객체(312)를 규정한다. 측정 클래스는 본 발명에 의해 이미 규정되어 있어서, 테스트 개발자는 측정 객체(312)를 단지 생성하고 사용하기만 하면 된다. 측정은 또한 테스트 실행의 단계(phase)이다.
측정 객체(312)는 하나의 측정에 대한 파라메터 객체(320)의 콜렉션(318), 및 하나의 측정으로부터의 다수 결과들 중에서 선택하는 데이터포인트 객체(316)의 콜렉션(314)을 포함한다. 측정 객체(312) 이름은 조작자에게 측정을 식별해준다. 측정 객체(312)는 측정 객체(312)의 이름도 포함한다.
본 발명의 제 4 층은 데이터포인트 객체(316) 층이다. 데이터포인트 객체(316) 층은 하나의 측정이 다수의 결과를 발생시키는 경우 하나의 결과를 선택하는 파라메터 객체(324)의 콜렉션(322)을 보유하는 측정 객체(312)의 서브세트이다. 하나의 측정은 논리적으로 이치에 맞도록 하나 이상의 데이터포인트를 테스트 개발자에게 반환할 수 있다. 하나의 측정에 대한 다수의 데이터포인트의 몇몇 예는 스펙트럼 분석기 스위프(spectrum analyzer sweep) 또는 장치의 각 채널의 최소 및 최대 값이다. 각 데이터포인트 객체(316)의 결과를 획득하는 것도 테스트 실행 단계이다. 이곳이 데이터가 획득되는 곳이다. 데이터포인트 획득 단계로부터 측정 단계를 분리하는 것이 의미가 없는 경우, 테스트 개발자는 데이터포인트 획득 단계 동안 전체 측정을 하는 테스트를 기록할 수 있다.
데이터포인트 객체(316)는 하나의 데이터포인트용 파라메터 객체(324)를 포함한다. 이 정보는 하나의 측정이 다수의 결과를 생성하는 경우 특정 결과를 선택한다. 이 이름은 조작자에게 데이터포인트를 식별해주고 측정에서 하나의 데이터포인트 객체(316)만이 존재하는 경우 공백이 될 수 있다. 각 측정 객체(312)는 데이터포인트 객체(316)의 콜렉션(314)을 가진다. 데이터포인트 객체(316)는 파라메터 객체(324)의 콜렉션(322)을 포함한다. 데이터포인트 객체(316)는 데이터포인트 객체(316)의 이름도 포함하고 있으며 각 파라메터 객체(324)의 설명을 연결함으로써 자동으로 생성될 수 있다. 그것은 이름에 값을 할당함으로써 덮어쓰기가 될 수 있다. 각 측정 내에서, 각 데이터포인트 이름은 유일하여야 하며 콤마 기호를 포함해서는 안된다. 각 데이터포인트 객체(316) 내에는 사양 객체(specification objects)(328)의 콜렉션(326)이 존재한다. 테스트 소프트웨어 객체(206)는 데이터포인트 객체(316)를 소유한다.
파라메터 객체(324)는 하나의 테스트 파라메터 셋팅을 포함하고 측정 구성 파라메터를 프로시저에서 테스트로 전달한다. 파라메터 객체(324)는 "주파수"와 같은 특정 파라메터 및 1.0E+7과 같은 값을 포함한다. 파라메터 객체(324)는 부울 값(Boolean value)을 포함하는데 그것이 참일 경우 파라메터는 측정 및 데이터포이트 이름에는 나타나지 않을 것이다. 부울 값이 거짓으로 설정되는 경우, 파라메터는 나타날 것이다.
테스트 소프트웨어 객체(206)는 조작자가 본 발명의 메뉴의 테스트 소프트웨어 항목을 클릭하는 경우 본 발명이 호출할 도시 방법(show method)을 포함한다.테스트 소프트웨어 객체(206)는 테스트 조작자가 모델 패밀리를 변경하는 경우 본 발명이 호출하는 방법을 포함한다. 전자 테스트 시스템(100)은 각 테스트 프로시저를 나열하는 방식으로, 이용가능한 프로시저 리스트를 디스플레이할 것이다. 모델은 테스트 초기화 소프트웨어가 스트링을 부가해야 하는 콜렉션이며, 스트링 중 하나는 유효 모델 번호이다.
또한, 테스트 소프트웨어 객체(206)는 하나의 프로시저에 대한 세부사항을 얻기 위해 호출하는 프로시저 확장 방법 및 프로시저 와해(collapse) 방법을 포함한다. 이 프로시저 확장 방법은 도 3에 도시된 객체를 생성한다. 또한, 테스트 소프트웨어 객체(206)는 프로시저를 시작하고 종료하는 경우 본 발명이 호출하는 프로시저 초기화 방법 및 프로시저 디-초기화(de-initialization) 방법을 포함한다.
도 4를 참조하면, 테스트 소프트웨어(206)의 방법 및 이 방법의 실행 순서가 개략적으로 도시되어 있다. 이 도면에 있어서, 바깥 다각형은 Exec 객체(202)를 나타내고, 가운데 박스는 TestSw.DLL 코드로서 도시되는 테스트 소프트웨어(206)를 나타낸다. 좌측 부분(362)은 "CTestSw"로 불리는 클래스에서의 세 가지 방법을 도시한다. 가운데 박스는 "CTestFlatness"로 불리는 테스트 클래스(364)의 한 예를 도시한다. 다른 테스트(366)도 대개 포함되는데, 하나만 완전하게 도시되어 있다. 각 테스트는 도시된 방법을 가진다. 이 방법은 Exec 객체(202)가 그들을 호출할 순서에 따라 좌측에서 우측으로 배열된다. 다음은 시퀀스의 각 단계를 설명한다.
먼저 Exec(202)는 TestSwlnit를 호출한다. 이것은 Exec(202)가 TestSw DLL을 로드한 직 후 발생한다. Exec(202)는 테스트될 수 있는 모델 리스트, 프로시저 이름 리스트, 및 DUT 및 테스트 시스템을 나타내는 객체에 대한 참조를 포함하는 정보를 테스트 소프트웨어(206)로부터 획득하기 위해 TestSwlnit를 호출한다. 그런 다음, 조작자가 프로시저를 선택하고 난 후, Exec(202)는 ProcExpand를 호출한다. ProcExpand는 Test, Meas 및 프로시저의 세부사항을 규정하는 Dp 객체의 구조를 구축한다. 도 4 및 다음의 테이블에 있어서, Proc는 프로시저 객체이고, Meas는 측정 객체이며 Dp는 데이터포인트 객체이다. 객체의 이러한 구조가 Exec 객체에 반환되는 경우, 그것은 선택된 프로시저를 조작작에게 디스플레이한다. 조작자가 프로시저를 시작하는 경우, Exec 객체는 Proclnit를 호출한다. Proclnit 코드는 테스트 시스템 I/O 등을 초기화한다.
이 시스템은 테스트 단계(364)로 들어간다. Exec(202)는 제 1 테스트에서 Testlnit 방법을 호출한다. 이 방법에 있어서, 바람직하게, 테스트 시스템 및 DUT는 사전설정되고, 테스트에서의 모든 측정에 대해 공통적인 셋업이 수행된다. 이 방법의 통과 파라메터는 바람직하게 어드레스, 슬롯 등에 대한 특성을 갖는 DUT 객체에 대한 참조 사항(reference)를 포함한다. 그 후, Exec(202) 프로그램은 테스트의 Measlnit, ResultsGet 및 MeasDelnit 방법을 각 측정마다 한번씩 호출하는 루프로 들어간다. Measlnit 통과 파라메터는 하나의 Meas 객체를 포함한다. 이 Meas 객체는 ProcExpand 방법에서 테스트 개발자에 의해 생성되고 프로시저에 부가되었다. Meas 객체는 측정의 구성을 규정하는 다수의 파라메터 객체를 포함할 수 있다. 그러므로, Measlnit 방법의 코드는 전형적으로 테스트 시스템 및 DUT를 구성하기 위해 이들 측정 파라메터 값을 사용할 것이다.
Exec(202)는 ResultsGet를 호출하고, 그것을 현 측정의 데이터포인트의 콜렉션에 전달한다. 이들 Dp 객체는 ProcExpand 방법에서 생성되고 프로시저에 부가된 객체이다. 각 Dp에 대해, ResultGet 방법은 바람직하게 Exec의 ResultPost 방법으로 "되호출(calls back)"된다. ResultPost로 보내진 통과 파라메터는 바람직하게 Exec 객체에 의해 상세히 비교될 측정된 데이터포인트 값을 포함한다. Exec(202)는 다음 측정을 위해 Measlnit을 호출하기 전에 MeasDelnit를 호출한다. 모든 측정이 실행된 경우, Exec(202)는 다음 테스트로 이동하기 전에 TestDelnit를 호출한다. 위의 객체들은 일반적으로 프로시저가 완료되거나 또는 Exec가 TestSw(206)의 ProcDelnit 방법을 호출하여 중단될 때까지 루핑된다. 이와 유사하게, ProcCollapse 방법이 호출되어 또 다른 프로시저를 변경하고, TestSwDelnit 방법이 호출되어 TestSw 객체를 언로드한다.
테스트를 호출하여 데이터 구조체를 생성하는 프로세스 및 테스트 소스트웨어의 예는 다음과 같다. 테스트 소프트웨어는 바람직하게 비주얼 베이직TM(VB)으로 작성되고 이하에서 설명되는 소프트웨어 코드는 VB 코드이다. 클래스 모듈 이름은 "C"로 시작되고 접두사 "C"를 포함하지 않는 파일 이름에 저장된다. 이러한 설명에 있어서, 클래스, 프로그램 및 서브프로그램은 대문자로 시작되고, 변수들에는 로마자가 사용된다. 바람직하게, 테스트 소프트웨어는 후속하는 클래스 파일을 포함한다. CTestSw(TestSw.cls)는 TestSwlnit, ProcExpand 및 Proclnit 방법이 구현되는 클래스이다. 이 클래스는 TestSw와 Exec 객체 간의 초기 인터페이스이고 따라서 모듈 이름은 "CTestSw"이며, 이 모듈은 Exec 객체에 의해 규정된 ITestSw 인터페이스를 구현하여야 한다. 클래스 파일 CDutE1234(DutE1234.cls) 및 CTestSystemE1234(TestSystemE1234.cls)는 DUT 및 TestSystem을 나타낸다. 바람직하게, 코드는 VB 구현 키워드를 사용하기 때문에 클래스는 Exec 객체에 의해 규정된 IDut 및 ITestSystem 클래스로부터 파생된다. 클래스 파일은 또한 CTestAmplitudeAccuracy(TestAmplitudeAccuracy.cls) 및 CTestFlatness(TestFlatness.cls)와 같은 하나 이상의 테스트를 포함할 것이다. 클래스 파일은 FFT(FFTMath.bas)와 같은, 테스트 소프트웨어(206) 프로젝트에 특유한 하나 이상의 부가적인 파일도 포함할 것이다.
테스트 시스템은 조작자가 어느 프로시저가 실행되어야 하는 지를 선택하도록 해준다. 일단 선택되면, 테스트 시스템은 방법, ProcExpand를 호출하고, 그것의 예는 이하에서 주어진다. 테스트 시스템은 선택된 프로시저를 테스트 소프트웨어 코드에 의해 채워지는 비어있는 프로시저 객체(Proc)로서 전달한다. 프로시저 객체는 바람직하게 두 단계로 생성된다. 첫째, TestSw ProcExpand 방법은 테스트 객체를 생성하고 부가한다. 둘째, 그것은 각 개별 테스트의 ProcExpand 방법을 호출하여 그들의 측정 및 데이터포인트에 부가한다. 이 기술은 프로시저 생성 코드와 테스트 코드를 보다 근접하게 연관시킨다.
진폭 정확성 테스트(CTestAmplitudeAccuracy)의 예가 이제 주어질 것이다. 이 테스트에 대한 TestSw.cls에서의 ProcExpand 방법은 표 1에 주어져 있다.
라인 번호는 코드 부분이 아니지만, 후속하는 주석을 참조하기 위해 제공된다.
라인(1) : 방법 이름은 "Itest-"의 접두사가 붙여짐에 유의해야 하는데, 그 이유는 이것이 VB가 외부 인터페이스를 구현하는 방법에 이름을 부가하는 방법이기 때문이다. 통과 파라메터는 Exec(202)(도 2) 객체 셋팅에 액세스를 부여하는 객체 인 Exec--와 코드에 의해 확장되는 프로시저인 Proc--를 포함한다.
라인(2) : 이 라인은 Proc.Name을 체크하여 이 테스트가 현 프로시저에 포함되어야 하는지를 결정한다.
라인(3) : 진폭 정확성 테스트 객체는 ITest 인터페이스를 구현한 파생된 클래스를 New-ing함으로써 생성된다.
라인(4) : 진폭 정확성 테스트의 ProcExpand 방법은 이 테스트에 대한 세부 사항(다음에서 설명됨)을 실행하기 위해 호출된다.
라인(5) : 테스트는 프로시저의 테스트 콜레션에 부가된다.
아래의 표 2에서, TestAmplitudeAccuracy.cls의 ProcExpand 방법의 예가 도시되어 있고, 위의 ProcExpand 방법으로부터 호출된다.
이 예는 다음의 측정치를 이용해 프로시저를 구성한다.
레인지=1Vp; 주파수=1kHz
레인지=1Vp; 주파수=1MHz
레인지=100mVp; 주파수=1kHz
레인지=100mVp; 주파수=1MHz
레인지=10mVp; 주파수=1kHz
레인지=10mVp; 주파수=1MHz
또한 각 측정은 다음의 데이터포인트를 가진다.
Ch=1
Ch=2
Ch=3
라인 번호는 코드 부분이 아니지만, 후속하는 주석을 참조하기 위해 제공된다.
라인(2) : 이 라인은 제 1 측정 파라메터, "Range" 값을 반복하는 루프를 시작한다. VB의 "For Each v In Array()"은 임의적인 시퀀스 값을 스텝핑(stepping)하는 바람직한 방법이다. 이것은 여러 유형의 변수를 요구한다. 작업을 용이하게 하는 다른 프로그래밍 기법에서와 같이, For/Next 루프는 스텝 사이즈가 일정한 경우 사용될 수 있다.
라인(4) : 이 라인은 제 2 측정 파라메터, "Freq" 값을 반복하는 내부 루프를 시작한다.
라인(5) : 이 라인은 Meas 객체를 생성하고 구성하는 코드 블록을 시작한다. m_colMeases는 테스트의 Meas 객체의 콜렉션이다. NewMeasBegin 방법은 다음 몇몇 라인에서 액세스되는 새로운 Meas 객체를 NewMeasEnd 상태일 때까지 생성한다. (m_colMeases 콜렉션은 외부 Meases 특성의 테스트에 대한 내부 등가물(the internal-to-the-test equivalent)이다.)
라인(7) : Params.Add 방법이 호출되어 파라메터를 측정에 부가한다. 파라메터 이름은 "Range"이고, 그것의 단위는 "Vp"이며, 그것의 값은 포 루프 변수(For loop variable)로부터 할당된다. 이와 유사한 방식으로, 다음 라인은 "Freq"로 불리는 제 2 파라메터를 부가한다. 파라메터 값을 Hz 및 Volts와 같은 기본적인 단위로 유지하는 것이 최상이다. Exec(202)는 파라메터 값들을 디스플레이하는 경우 엔지니어링 포맷을 적용할 것이다. 파라메터에 대해 이러한 구조를 적용하게 되면 결과 대 임의의 파라메터(results vs. any parameter)를 좌표로 나타내기가 보다 쉬워질 것이다.
라인(10) : 이 라인은 각 Meas에 대해 3개의 Dps를 생성하는 For/Next 루프를 시작한다.
라인(11) : NewDpBegin은 다음 몇몇 라인에서 참조되는 Dp 객체를 NewDpEnd 상태일 때까지 생성한다.
라인(12) : 하나의 파라메터가 현 Dp에 부가된다.
라인(13) : 하나의 Spec이 Dp에 부가된다. SpecAdd 방법의 통과 파라메터는 단위(Units), 고객 한계(Customer limits), 제품 한계(Production limits), 마지널한계(Marginal limits) 및 타겟(또는 아이디얼) 값을 포함한다. 마지막 항목, "###0.00"은 포맷 스트링이다(VB Format() 함수를 참조). 이 한계들이 측정 파라메터의 상이한 값에 따라 변경되는 경우, 이 한계를 계산하는 코드는 여기에 삽입될 수 있다. 테스트 실행 동안, Spec은 이후에 부가될 수도 있다.
라인(14) : NewDpEnd 방법은 Dp를 Meas 객체의 Dp 콜렉션에 부가한다.
라인(17) : NewMeasEnd 방법은 Meas를 Test 객체의 Meases 콜렉션에 부가한다.
이러한 것들은 모두 18개의 데이터포인트에 대한 프로시저 규정 코드를 생성하기 위해 필요한 것들이다. ProcExpand가 반환되는 경우, Exec(202)는 이들 6개의 측정을 디스플레이할 것인데, 이들 각각은 3개의 Dp를 가지고 있다. 조작자가 테스트를 시작하는 경우, Exec(202)는 이 테스트에서 방법을 6번 호출하는데, 그것을 매번 상이한 측정 객체에 전달할 것이다. Exec(202)가 호출하는 방법은 다음에 설명된다.
도 4에 나타낸 바와 같이, 조작자가 프로시저를 시작하는 경우, Testlnit는 Exec(202)가 호출할 테스트의 제 1 방법이다. 전형적으로, 소프트웨어 개발자는 TestSystem을 초기화하고, DUT를 초기화하며 테스트에 공통적인 임의의 구성을 셋업하는 코드를 부가할 것이다. 각 측정에 대해 Measlnit를 호출하기 전에, Testlnit는 한번만 호출된다. 도 4에 도시되어 있고, 이하에서 보다 자세히 설명되는 바와 같이, Exec(202)는 제 1 테스트의 Testlnit를 호출하기 전에 TestSw.cls의 Proclnit 방법을 호출한다. Proclnit는 I/O 경로를 개방하고 모든 테스트에 공통적인 다른 항목들을 초기화하기 위한 바람직한 지점이다. Testlnit의 예는 표 3에 주어져 있다.
앞서와 마찬가지로, 라인 번호는 코드 부분이 아니지만, 후속하는 주석을 참조하기 위해 제공된다.
라인(1) : Exec(202)는 Testlnit 방법에 몇몇 객체를 전달한다. 즉 Exec는 Exec 셋팅에 대한 액세스를 제공하는 객체이다. TestSystem 및 Dut는 TestSwlnit 동안 생성되고 Exec(202)에 제공되는 객체이며, 이는 이후에 설명될 것이다. Exec(202)는 TestSystem(206) 및 DUT가 Exec에 의해 규정된 ITestSystem 및 IDUT 클래스로부터 파생되는 객체임을 기대한다. 파생된다는 것은, 이들이 바람직하게 ITestSystem 및 IDut의 방법 및 특성을 구현하도록 기록된다는 것을 의미한다. 그런 다음 테스트 개발자는 필요하고 객체 지향 프로그램에 공통적인 부가적인 방법 및 특성을 부가할 수 있다.
라인(2 - 4) : 이 프로젝트에서, Exec의 IDut 베이스 클래스는 "Range" 및"Preset"과 같은 특성 및 방법을 부가함으로써 확장되었다. 이와 유사하게, Exec의 ITestSystem은 "Preset" 방법 및 "Hookup" 방법을 포함하도록 확장되었다. VB로부터 이들 확장된 방법을 액세스하기 위해, 변수를 파생된 클래스로 딤(Dim)하는 것이 바람직하다. 그런 다음 그것을 Exec(202)가 전달된 객체 참조에 셋팅(Set)하는 것이 바람직하다.
라인(5 및 6) : 이들 라인은 테스트 시스템을 구성한다. Preset 및 Hookup은 개발자가 TestSystem1234.cls 파일에서 CTestSystemE1234 클래스에 부가하는 방법이다. 이 파일은 이후에 설명된다.
라인(7) : DUT는 개발자가 DutE1234.cls 파일에 부가한 방법을 호출함으로써 사전설정된다.
Testlnit가 일단 완료되면, 도 4에 나타낸 바와 같이, Exec(202)는 프로시저의 각 측정에 대해 Measlnit, ResultsGet 및 MeasDelnit 방법을 호출할 것이다. 바람직하게, Measlnit 방법은 측정을 설정하고 시작한다. Measlnit 서브프로그램의 예가 표 4에 주어져 있다.
라인 번호는 코드 부분이 아니지만, 후속하는 주석을 참조하기 위해 제공된다.
라인(1) : Meas 객체가 부가된 상태에서, Measlnit에 대한 통과 파라메터는 Testlnit와 동일하다. 이 Meas 객체는 ProcExpand에서 보다 먼저 생성된 Meas 객체들 중 하나이다.
라인(2 - 4) : 위에 있는 Testlnit 서브프로그램(표 3)에 이어지는 주석을 참조하라.
라인(5 및 6) : 이들 라인은 측정 파라메터 값을 구해서 그것을 DUT 및 TestSystem을 설정하기 위해 사용한다. Meas.Params는 Meas 객체에 부가된 모든 파라메터 객체의 VB 콜렉션이다. 파라메터 이름은 키로서 사용되기 때문에, Meas.Params("Range")는 Range용 Param 객체에 대한 참조부를 복귀시킨다. 이 Param이 어디에 부가되었는지를 알기 위해 ProcExpand의 라인(7)을 다시 참조하라.
라인(7 및 8) : 이들 라인은 Exec 객체(202)의 몇몇 유틸리티 방법을 호출한다. Wait는 특정된 몇 초간 대기한다.
라인(9) : StartMeasurement는 개발자가 DUT 객체에 부가한 또 다른 방법이다.
Measlnit를 완료한 후, Exec(202)는 ResultsGet 방법을 호출하고 데이터포인트 콜렉션에 전달한다. 콜렉션의 각 Dp마다, 소프트웨어 코드는 측정 결과를 취득하고 Exec.ResultPost를 호출함으로써 그것을 Exec(202)에 보낸다. ResultsGet의 예는 표 5에 도시되어 있다.
여기서도, 라인 번호는 코드 부분이 아니지만, 후속하는 주석을 쉽게 참조하기 위해 제공된다.
라인(1) : Dp의 부가, Dp 객체의 콜렉션인 상태에서, ResultsGet에 대한 통과 파라메터는 Measlnit와 동일하다. 이들 Dp 객체는 ProcExpand 초기에 생성되었다.
라인(3 및 4) : 위의 Testlnit 서브프로그램(표 3)에 이어지는 주석을 참조하라.
라인(5 및 7) : 이 루프는 DUT가 Measlnit에서 시작된 측정을 마치도록 대기한다. 바람직하게, Wait가 0초라 할지라도, Wait는 어떠한 루프에라도 포함되어야 한다. Wait는 VB의 DoEvents와 동일한데, 그 이유는 그것은 Exec의 사용자 인터페이스가 조작자에 응답하도록 해주기 때문이다. 조작자가 테스트를 중단하는 경우, Wait는 에러를 야기할 것이다.
라인(8 - 10) : 테스트 코드는 VB의 Err.Raise 이벤트를 사용하여 측정 에러를 전달할 수 있다. eeTestError는 Exec(202)에 의해 규정된 에러 수이다. 에러가 발생하는 경우, Exec(202)는 테스트 결과에 Err.Description 스트링을 로그할 것이다. 조작자가 "Stop on Error"를 선택하는 경우 Exec는 테스트를 중지할 수도 있다.
라인(11) : 이 라인은 콜렉션의 각 Dp를 반복하는 For/Next 루프를 시작한다. 당신의 테스트가 단지 단일 공백 Dp일거라고 예상되는 경우, 루프는 필요하지 않게 되고, Dp는 "Dps(1)"로 참조될 수 있다.
라인(12) : 지역 변수(local variable) nCh는 각 Dp의 파라메터에서 발견되는 채널 번호이다. Meas 객체와 같이, Dp 객체는 하나 이상의 파라메터를 가질 수 있다.
라인(13 및 14) : 이 IF는 소프트웨어 코드가 아마도 DUT 옵션으로 인해 "Not Applicable"인 Dp를 어떻게 처리하느냐에 관한 일 예이다. 생략된 채널에 대해, 이 코드는 ResultType=rtNotApplicable과 함께 Exec.ResultPost를 호출한다.이것은 Exec(202)가 Dp를 완전히 무시해도 된다는 것을 말해준다.
라인(16) : 개발자가 Dut 클래스에 부가한 방법은 마커(marker)를 판독하기 위해 호출된다.
라인(17 및 18) : 이 IF는 양호한 실행인 적절한 측정에 대해 체크를 하는데, 그 이유는 끊어진 케이블과 같은 실수로 인해 임의의 결과 데이터베이스의 통계적 분포가 왜곡되는 것을 막아 주기 때문이다. Exec.ResultPost는 ResultType=rtError와 함께 호출되어 Exec(202)에게 Dp가 에러임을 알려주고, Exec는 그것을 대부분 spec 실패로 간주할 것이다. 이 방법은 보통 잔여 Dp에 에러가 발생하지 않았음에도, 잔여 Dp에 이러한 사실을 알려준다.
라인(20) : 이 라인은 Exec.ResultPost를 호출함으로써 측정된 결과를 Exec(202)에 보낸다. Exec(202)는 사양 한계(specification limits)에 대해 측정된 결과를 체크하고, 그것을 로그하며 그것을 임의의 Exec Plug-ins으로 보낼 것이다. 여기에 도시되어 있지는 않지만, ResultPost는 두 개의 부가적이고, 선택적인 통과 파라메터, 즉 AtValue 및 AtUnits를 가지고 있다. 이들은 한계에 비교되지 않는 부가적인 Dp 정보를 로그하는 데 사용될 수 있다.
이어서, 우리는 다른 TestSw.cls 코드를 설명한다. Exec(202)는 테스트 개발자에 의해 작성된 TestSw DLL을 로드한 후 바로 TestSwlnit를 호출한다. TestSwlnit의 하나의 목적은 테스트에 이용가능한 모델 리스트, 프로시저 이름 리스트 및 DUT와 테스트 시스템을 나타내는 객체에 대한 참조를 포함하는 정보를 테스트 소프트웨어(206)에서 Exec(202)로 전달하는 것이다. TestSwlnit 방법은 바람직하게 소프트웨어를 초기화하지만, 임의의 테스트 시스템 I/O 또는 Dut I/O는 초기화하지 않는데, 그 이유는 조작자가 장치 어드레스를 입력하거나 변경할 기회를 아직 가지고 있지 않기 때문이다. TestSwlnit의 예가 표 6에 주어져 있다.
앞에서와 마찬가지로, 라인 번호는 코드 부분이 아니지만, 후속하는 주석을 참조하기 위해 제공된다.
라인(1) : TestSystem, Dut 및 Procs는 이 방법에 있어서 중요한 통과 파라메터들이다. 그들은 Exec(202)가 TestSwlnit를 호출하는 경우 Nothing이 될 것이고, 테스트 개발자의 코드는 이들 객체를 생성(또는 New)하거고 그들을 Exec에 복귀시킨다.
라인(2 및 3) : 특정 모델 번호 리스트는 모델 콜렉션에 부가된다. Exec(202)는 이들을 Dut 일련 번호 입력 형태인 드롭 다운 박스로 디스플레이될 것이다.
라인(4 및 5) : 이들 라인은 TestSystem 객체를 생성한다. 이 경우에 있어서, 이것은 Exec의 ITestSystem으로부터 파생된, TestSystemE1234.cls 파일의 클래스로부터 생성되며, 이는 이후에 설명될 것이다.
라인(8) : 이것은 Dut 객체를 생성하고 참조를 Exec에 복귀시킨다.
라인(9) : 이것은 새롭고, 비어있는 프로시저 콜렉션을 생성한다.
라인(10 - 15) : 이것은 각 프로시저에 대한 Proc 객체를 생성하고 그것을 Procs 콜렉션에 부가한다. 사용자가 프로시저를 선택하는 경우, Exec(202)는 선택된 Proc 객체에 대한 ProcExpand를 호출할 것이다.
조작자가 프로시저의 실행을 시작하는 경우, Exec(202)는 Proclnit를 호출한다. 위에서 언급한 바와 같이, 이것은 테스트 시스템 및 Dut에서 장치에 대한 I/O 경로를 개방하기에 좋은 지점이다. Proclnit의 예가 표 7에 주어져 있다.
위의 코드는 개발자가 TestSystemE1234.cls에서 작성한 Proclnit 방법을 호출한다. 이 방법은 I/O 경로를 개방하기 위해 각 장치의 .Address 특성을 사용한다.
TestSystemE1234.cls 클래스 파일은 Exec에 의해 규정된 ITestSystem 인터페이스를 구현하는 "커스텀(custom)" 테스트 시스템 객체를 규정한다. ITestSystem 인터페이스는 Exec(202)가 테스트 장비 등을 도큐먼트(document)하기 위해 필요로 하는 모든 특성들을 포함하고 있다. 후속하는 표 8의 예에 있어서, TestSystemE1234 서브프로그램은 몇몇 방법 즉, Preset, Hookup, Amplitude, TestSystemlnit, Proclnit 등을 부가함으로써 TestSystem 클래스를 확장한다.
앞서와 마찬가지로, 라인 번호는 코드 부분이 아니지만, 후속하는 주석을 참조하기위해 제공된다.
라인(1) : Implements 구문은 이 클래스가 Exec에 의해 규정된 ITestSystem 클래스로부터 파생된다는 것을 말해준다.
라인(2 - 6) : 이들 라인은 Exec의 ITestSystem 인터페이스가 요구하는 특성들을 지원하는 몇몇 변수들을 규정한다. 규칙에 따라, 그들은 "m_" 접두사를 가지는데, 그 이유는 그들의 범주는 "모듈 프라이빗(module private)"이기 때문이다. m_sName이라는 변수는 테스트 시스템의 이름을 저장하기 위한 스트링이다. 그들은 프라이빗인데 그 이유는 그들은 퍼블릭(public) 특성(아래 참조)을 통해 액세스되기 때문이다.
라인(4) : m_colDevices는 테스트 시스템의 각 장치마다 Device 객체의 콜렉션이다. 이 모듈과는 무관하게, 그것은 Deives 특성을 통해 참조된다.
라인(7 - 12) : 이것은 ITestSystem의 .Name 특성에 대한 특성 Get/Let 방법이다. 이것은 바람직하게 모든 테스트 프로그램마다 카피되는 보일러판(boiler-plate) 코드이다. 이 코드가 포함되지 않는 경우, 모듈이 더 이상 ITestSystem 인터페이스를 구현하지 않기 때문에 VB는 불평(complain)할 수도 있다.
라인(13 - 16) : Preset 방법은 개발자가 TestSystem 클래스를 확장하고 커스텀화하기 위해 부가할 수 있는 방법의 일 예이다. 이 예에 있어서, Preset은 HpibWrite을 호출하고, 우리가 맡고 있는 개발자 작성 서브(sub)는 I/O 함수를 호출한다. Preset이 테스트로부터 어떻게 호출되는지를 알아보기 위해 TestAmplitudeAccuracy.cls의 Testlnit 방법(표 3)을 다시 참조하라.
라인(18 - 20) : 진폭 특성은 신호 진폭을 설정한다. 그것이 어떻게 호출되는지를 알아보기 위해 TestAmplitudeAccuracy.cls의 Measlnit 방법을 다시 참조하라.
라인(22) : 이것은 TestSystemlnit의 시작이고, TestSw DLL이 먼저 로드되는 경우 TestSw.cls의 TestSwlnit로부터 호출되는 방법이다. 이것의 목적은 TestSystem용 장치 객체를 생성하는 것이다.
라인(24 - 26) : 이들 라인은 테스트 시스템의 일부 장치에 대해 CDevice 객체를 생성하고 그것을 TestSystem.Devices 콜렉션에 부가한다.
라인(40 - 43) : 이 TestSystem Proclnit 방법은 TestSw.cls(표 7)의 Proclnit 방법으로부터 호출된다. 그것은 각 Device 객체의 Address 특성을 사용하여, 테스트 시스템의 I/O를 개방한다. HpibOpen 함수 및 id3325 변수는 다른 곳에 규정된다. 당업자가 알 수 있는 바와 같이, 대응 ProcDelnit 방법은 I/O 경로를 폐쇄한다.
이 예에 있어서, CTestSystemE1234는 TestSw와 동일한 VB 프로젝트에 존재하여, 동일한 .DLL에 존재한다. TestSystem 코드를 별개의 VB 프로젝트로 이동시킬 수 있다. 이것은 하나 이상의 TestSw 프로젝트가 동일한 TestSystem을 사용할 경우에 바람직하다.
표 9에 있어서, Exec(202)에 의해 규정된 IDut 인터페이스를 구현하는 "커스텀" 피시험 장치 객체를 규정하는 DutE1234.cls 클래스 파일이 도시되어 있다. 이 IDut 인터페이스는 Exec(202)가 DUT를 도큐먼트하기 위해 필요한 모든 특성들을 포함한다. 이 예는 Range, StartMeasurement 및 ReadMarkerMax와 같은 몇몇 방법을 부가함으로써 DUT 클래스를 확장하다.
앞에서와 마찬가지로, 라인 번호는 코드 부분이 아니지만, 후속하는 주석을 참조하기 위해 제공된다.
라인(1) : Implements 구문은 이 클래스가 Exec에 의해 규정된 IDut 클래스로부터 파생된다는 것을 말해준다.
라인(2 - 4) : 이들 라인은 Exec의 IDut 인터페이스가 요구하는 특성들을 지원하는 몇몇 변수들을 규정한다. 규칙에 따라, 그들은 "m_" 접두사를 가지는데, 그 이유는 그들의 범주는 "모듈 프라이빗"이기 때문이다. m_sAddress라는 변수는 테스트의 어드레스를 저장하기 위한 스트링이다. 그들은 프라이빗인데 그 이유는그들은 퍼블릭 특성을 통해 액세스되기 때문이며, 이는 여기서 자세히 설명되지 않는다.
라인(6 - 17) : 이들 방법은 개발자가 DUT 클래스를 확장하고 커스텀화하기 위해 부가하는 방법의 일 예이다. 이들 방법은 HpibWrite를 호출하고, 우리가 맡을 수 있는 개발자 작성 서브는 I/O 함수를 호출한다. 이들 방법들이 어떻게 사용되는지는 위에서 설명되었다.
당업자라면 위의 자세한 예시들을 통해 본 발명을 전체적으로 이해할 수 있을 것이다. 또한, 본 발명은 도 5 및 도 6으로 요약된다. 도 5는 본 발명의 소프트웨어 방법의 핵심적인 요소를 도시하는 일반화된 흐름도이고, 도 6은 본 발명의 예시적인 테스트 확장 프로세스를 예시하는 일반화된 흐름도이다. 단계(502)에서, 테스트 실행 시스템(100)이 개시된다. 일반적으로, 개시 프로세스 동안 시스템의 몇몇 일반적 셋업이 존재한다. 조작자가 테스트를 시작할 준비가 된 경우, 단계(504)에서, 조작자는 테스트 소스트웨어(206)가 이용가능한 여러 디스플레이 모델을 나타내는 디스플레이를 활성화시키고, 단계(506)에서 이용가능한 모델들 중 하나를 선택한다. 시스템(100)은 DLL 형태의 테스트 소프트웨어 객체(206)를 로드한다. 이 점에 있어서, 구성 정보는 단계(510)에 입력될 수 있다. 바람직하게 시스템(100)에 의해 자동적으로 이루어질 지라도, 조작자는 단계(512)에서 프로시저 리스트의 디스플레이를 활성화시킬 수 있다. 조작자는 단계(514)에서 프로시저를 선택하고, 그런 다음 시스템은 선택된 프로시저를 확장하기 위해 프로세스(500)로 들어간다. 먼저, 테스트 소프트웨어는 단계(516)에서 테스트 루프로 들어가고, 단계(518)에서 제 1 테스트가 선택된 프로시저에 존재하는 지를 결정하고, 그렇지 않을 경우, 프로그램은 단계(534)로 전진하여, 테스트 리스트 상에 다른 테스트가 존재하는 지를 결정하고, 다른 테스트가 존재하는 경우, 단계(518)로 되돌아간다. 테스트가 선택된 프로시저에 존재하는 경우, 시스템은 단계(528)에서 테스트 객체를 생성하고 그런 다음 단계(530)에서 테스트 객체를 확장한다. 방법(530)은 이하에서 자세히 설명될 것이다. 확장된 테스트 객체는 단계(532)에서 프로시저 객체에 부가된다. 시스템은 더 이상의 테스트가 존재하지 않을 때까지 이용 가능한 테스트를 순환할 것이고, 여기서 프로시저 객체는 채워지고 시스템은 프로시저를 실행하기 위해 단계(540)로 진행하되, 그렇지 않을 경우 조작자에 의해 지시받게 된다. 프로시저를 실행하는 동안, 테스트 결과는 생성되고 커스텀 데이터 구조체는 도 4에 도시되고 위에서 설명한 바와 같이, 결과가 알려지는 대로 Exec(202)에 생성된다.
도 6은 프로시저의 일부인 테스트의 예시적인 확장부(530)의 흐름도이다. 이것은 두 개의 상이한 유형의 파라메터, 즉 Range 및 Frequency가 존재하는 위 예를 통해 주어지되, 각 Range 파라메터는 다수의 Frequency 파라메터를 포함한다. 이 예에 있어서, 테스트 확장 방법(530)은 위의 예에서 몇몇 레인지들 중 하나인 제 1 레벨 파라메터 객체(320)를 탐색한다. 이 테스트에 있어서 파라메터 레인지는 몇몇 제 2 레벨 파라메터 주파수를 가지며, 테스트 시스템은 단계(608)에서 내부 루프로 들어간다. 레인지 및 주파수의 각 조합에 대해, 단계(612)에서 측정 객체를 생성하고, 그런 다음 단계(614)에서 현 파라메터를 측정 객체에 부가한다.이 예에 있어서, 몇몇 데이터포인트 파라메터(324), 즉 각 측정에 대한 채널들이 존재하기 때문에, 시스템은 단계(616)에서 데이터포인트 루프로 들어간다. 데이터포인트 루프에 있어서, 데이터포인트 객체는 단계(620)에서 생성되고, 데이터 포인트 및 데이터포인트에 대한 사양은 단계(622 및 625)에 각각 부가된다. 데이터포인트 객체는 단계(626)에서 측정 객체에 부가되고, 시스템은 다음 데이터포인트를 위해 단계(616)로 진행한다. 데이터포인트 루프는 더 이상의 데이터포인트가 존재하지 않을 때까지 반복되는데, 이 예에서는 세 개 채널의 각각에 대해 세 번 반복될 것이다. 모든 데이터포인트가 처리된 경우, 시스템은 측정 객체를 단계(630)에서 테스트 객체 측정 콜렉션에 부가하고, 다음 제 2 레벨 파라메터를 위해 단계(606)로 이동하고, 레인지 및 주파수의 결합에 대한 또 다른 측정 객체를 생성하고, 데이터포인트 루프를 반복하며, 측정 객체를 그 결합에 대한 테스트 객체 콜렉션에 부가한다. 모든 주파수가 주어진 레인지 파라메터에 대해 처리된 경우, 단계(604)에서 레인지 파라메터는 증가되고, 위에서 설명한 바와 같이 시스템은 측정 객체를 생성하도록 진행하고 측정 객체를 데이터포인트 객체로 채운다. 모든 제 1 레벨 파라메터가 처리된 경우, 시스템은 단계(604)에서 이것을 인식하고 도 5의 방법(532)으로 진행한다.
테스트 실행 프로그램을 실행하는 컴퓨터 시스템(100)(도 1)의 모든 입력 및 출력은 그래픽 사용자 인터페이스(GUI)를 통해 제어된다. 도 7은 본 발명의 테스트 실행 프로그램(200)에 따라 출력 장치(106)에 의해 디스플레이되는 GUI(700)를 예시한다. 특히, 이것은 위 예의 테스트 소프트웨어(206)의 실행으로부터 전형적으로 야기될 수 있는 예시적인 데이터 구조체의 두 개의 실시예를 도시한다. 일 실시예에서, 데이터 구조체는 표(714)의 형태이다. 이들 양 구조체 및 GUI(700)의 또 다른 특징은 이하에서 설명될 것이다.
GUI(700)는 테스트를 제어하는 데 사용되는 버튼(701)을 포함한다. 사용자의 편의를 위해, 본 발명의 바람직한 실시예에 따라 버튼(701)은 버튼에 의한 기능을 나타내고 테이프 레코더형 버튼과 같은 형태를 가지는 표시(indicia)를 가지고 있다. 바람직한 실시예에서, 이들 버튼은 중단 버튼(702), 재시작 테스트 버튼(703), 재시작 측정 버튼(704), 일시 중지 버튼(705), 실행 버튼(706), 스킵 측정 버튼(707) 및 스킵 테스트 버튼(708)을 포함한다. 당업자라면, 테이프 레코더 기호가 이 실시예에 사용었지만, 버튼(701)을 식별하기 위해 어떠한 표시라도 사용될 수 있다는 것을 알 수 있을 것이다.
바람직한 실시예에서 GUI(700)의 우측 면적(714)은 테스트 결과를 표로 디스플레이한다. 바람직한 실시예에서, 데이터 표(714)는 개별 테스트의 결과(740)를 디스플레이하는 일련의 행(715) 및 열(716)을 포함한다. 열(717)은 특정 데이터포인트에 대해 테스트가 실행된 시간을 나타낸다. 열(718)은 테스트의 상태를 디스플레이한다. 열(719)은 또한 테스트의 이름을 디스플레이한다. 예를 들어, 도시된 테스트는 위에서 자세히 설명한 진폭 정확성 테스트이다. 열(720)은 테스트 동안 취해진 측정 파라메터를 나타낸다. 예를 들어, 레인지=5Vp, 주파수=1kHz가 그것이다. 열(721)은 테스트 중인 데이터포인트를 디스플레이하는데, 그것은 이경우에 있어서는 채널, 예컨대 ch=1 또는 ch=2이다. 열(723)은 +0.2와 같은 사양을 디스플레이한다. 열(724)은 1kHz와 같은 파라메터 주파수의 값을 디스플레이한다.
버튼(725)은 디스플레이된 테스트 결과의 필터링을 용이하게 하여 사용자가 모든 테스트 결과의 일부분을 볼 수 있게 해준다. 바람직한 실시예에서, 버튼(725)은 올(all) 버튼, 마지널 통과 버튼(marginal pass button) 및 실패 버튼을 포함한다. 그러나, 당업자라면, 데이터를 보기 위해 어떠한 부가적인 방법이라도 부가될 수 있다는 것을 알 수 있을 것이다. 면적(730)은 실행되는 프로시저의 진행 상태를 나타내는 진행 바(progress bar)를 디스플레이한다.
바람직한 실시예에서, GUI(700)의 좌측은 트리(709) 형태의 데이터 구조체를 예시하고, 프로시저, 테스트, 측정 및 데이터포인트의 계층을 포함한다. 테스트 트리(709)는 프로시저, 테스트, 측정 및 데이터포인트의 상태를 각각 나타내는 아이콘(713,710,711,712)을 포함한다. 이 아이콘은 통과, 실패, 마지널(marginal) 및 미테스트된(not-yet tested) 상태를 나타낸다. 바람직한 실시예에서, "웃는 얼굴"은 통과를 나타내고, "놀란 얼굴"은 마지널 통과를 나타내고, "찌푸린 얼굴"은 실패를 나타낸다. 프로시저용 아이콘(713)은 전체 프로시저의 상태를 나타낸다. 각 테스트에 대한 아이콘은 개별적인 테스트의 상태를 나타내지만, 프로시저에 대한 아이콘은 최소의 최적 결과를 조장하는 알고리즘에 의해 결정된다. 그러므로, 하나의 테스트가 실패하는 경우, 프로시저는 실패한다.
GUI(700)는 메뉴 바(750)도 포함한다. 메뉴 바(750)는 테스트 실행 프로그램(200)을 제어용 메뉴 옵션 리스트를 디스플레이한다. 메뉴 바(750)는 파일 메뉴(751), 모델 메뉴(752), DUT 메뉴(753), 셋팅 메뉴(754), 플러그-인 메뉴(755)및 도움말 메뉴(756)를 포함한다. 파일 메뉴(751)는 테스트 실행 프로그램에 사용되는 파일들을 열고 닫는 옵션 리스트를 포함한다. 모델 메뉴(752)는 프로시저가 이용가능한 모델 패밀리 리스트를 디스플레이한다. DUT 메뉴(753)는 DUT를 식별하는 DUT 모델, 일련 번호, 옵션 및 다른 정보를 입력하기 위한 스크린을 디스플레이한다. 셋팅 메뉴(754)는 테스트 실행 프로그램 셋팅을 보고 변경하는 메뉴를 디스플레이한다. 플러그-인 메뉴(755)는 시스템이 인터페이스되는 플러그-인에 대한 사용자 인터페이스를 디스플레이한다. 도움말 메뉴(756)는 테스트 실행 프로그램에서 이용가능한 도움말 기능의 리스트를 디스플레이한다.
위에서 주어진 예시들은 본 발명을 단지 예시일뿐, 본 발명을 제한하지는 않는다는 것을 이해해야 된다. 위에서 설명한 바와 같이, 본 발명의 방법에 있어서, 테스트들은 파라메터에 의해 구동된다. 즉, 임의의 테스트의 형태는 테스트를 구성하는 파라메터에 의해 구동된다. 이러한 이유 때문에, 시스템은 특정 테스트를 구성하는 특정 파라메터로 가장 잘 설명될 수 있다. 그러나, 일반적으로 본 발명은 테스트 객체를 생성하고 채우기 위해 하나 이상의 측정 객체 루프와, 필요한 경우 하나 이상의 데이터 포인트 루프로 들어가서, 프로시저가 실행되는 경우 커스텀 데이터 구조체를 생성할 것이다. 측정 루프의 수와, 데이터포인트 루프의 존재 여부와, 또한 데이터포인트 루프의 수는 특정 테스트에서 측정된 특정 파라메터에 의해 결정된다. 이것은 테스트가 파라메터에 의해 구동된다는 것을 의미한다.
위의 설명으로부터, 본 발명의 시스템에 의해 테스트 개발자가 테스트될 장치를 분석하고 그 테스트를 계층적 방식으로 구성하게 된다. 그러나, 그렇게 되면, 복귀(return)는 커진다. 일단 본 발명의 시스템이 단기간 동안 사용해 보면, 여러 장치를 테스트하는 데 사용되는 파라메터의 수는 범위(scope) 면에서 종래의 장치 수보다 훨씬 더 제한된다는 것을 알 수 있다. 프로시저를 구성하는 테스트, 측정 및 데이터 포인트의 콜레션은 신속하게 축적되고, 그 후, 새로운 장치가 개발됨에 따라, 새로운 장치용 프로시저는 축적된 소프트웨어 객체의 콜렉션 가운데에서 쉽게 구성될 수 있다.
본 발명의 특징은, 테스트 알고리즘이 어렵지 않게 구성될 수 있다는 것이다. 이 테스트 알고리즘은 여러 측정과 데이터포인트 객체를 결합하고, 그런 다음 테스트를 확장 및 결합하여 프로시저를 확장함으로써 테스트를 개발하는 프로세로부터 탈피한다. 관련 특징은 테이터 구조체가 별개로 구성될 필요가 없다는 것이다. 오히려, 데이터 구조체는 테스트가 실행되는 경우 연속적으로 생성된다.
도면에 도시되어 있고 본 명세서에서 설명한 특정 실시예들은 예시적 목적이고 본 발명을 제한하는 것으로 해석되어서는 안되며, 이하의 청구항에서 설명될 것이다. 또한, 당업자라면 본 발명의 개념을 벗어나지 않고서, 설명된 특정 실시예를 다수 사용할 수 있고 변경할 수 있다는 것이 분명하다. 인용된 방법들은 다수의 인스턴스들에 있어서 상이한 순서로 수행될 수 있고, 또는 등가 구조체 및 프로세스는 설명된 여러 구조체 및 프로세서를 대신할 수 있다. 따라서, 본 발명은 모든 새로운 특징 및 본 명세서에서 설명한 본 발명이 나타내고 소유하고 있는 특징들의 새로운 결합들을 포함하는 것으로 해석되어야 한다.
본 발명에 따르면, 종래 기술의 테스트 프로그램은 테스트를 설계하기가 어려운데 그 이유는 테스트 엔지니어가 개별 테스트, 테스트 리스트 또는 테스트 알고리즘과 같은 테스트 프로그램의 개별 부분을 설계 혹은 변경할 경우 전체 테스트에 초점을 맞추어야 하기 때문이다. 또한, 종래 기술의 시스템에 있어서, 테스트 프로시저는 테스트 알고리즘 내로 통합되고, 따라서 테스트 프로시저를 변경하는 동안 잘못 입력된 커맨드에 테스트 알고리즘이 민감해질 수 있다. 이러한 단점을 해결하기 위해, 본 발명은 개별 프로시저, 테스트, 측정 및 데이터포인트 레벨을 포함하는 계층적 테스트 실행 시스템을 제공한다.

Claims (24)

  1. 테스트 실행 시스템과는 분리되어 별개인 피시험 장치(DUT)를 전자적으로 테스트하는 상기 테스트 실행 시스템을 동작시키는 방법에 있어서,
    다수의 테스트 및 프로시저를 전자적으로 저장하는 단계- 상기 각 테스트는 테스트 알고리즘을 규정하는 소프트웨어 코드를 포함하고 상기 프로시저는 상기 테스트의 순서화된 리스트를 나타내는 데이터를 포함함- 와,
    상기 순서화된 리스트에 의해 결정된 상기 테스트들 중 사전결정된 테스트들을 결합함으로써 상기 프로시저를 확장하는 단계와,
    상기 DUT 대해 상기 프로시저를 실행하고 상기 사전결정된 테스트들의 결과를 포함하는 데이터 구조체를 생성하는 단계를 포함하는
    테스트 실행 시스템의 동작 방법.
  2. 제 1 항에 있어서,
    상기 프로시저는 하나 이상의 측정 리스트를 포함하고, 상기 각 측정은 특정 테스트를 위한 구성을 포함하고, 상기 확장 단계는 상기 리스트 내의 상기 측정을 상기 특정 테스트와 연관된 측정의 콜렉션에 부가하는 단계를 포함하는
    테스트 실행 시스템의 동작 방법.
  3. 제 2 항에 있어서,
    상기 각 테스트는 테스트 객체를 포함하고, 상기 프로시저는 프로시저 객체를 포함하며, 상기 각 측정은 측정 객체를 포함하고 상기 측정 객체는 테스트 파라메터를 상기 테스트 객체에 전달하는
    테스트 실행 시스템의 동작 방법.
  4. 제 2 항에 있어서,
    상기 프로시저는 데이터포인트 리스트를 포함하고, 상기 데이터포인트의 각각은 특정 측정에 대한 다수의 결과들 중 하나와 연관되며, 상기 확장 단계는 상기 데이터포인트를 상기 특정 측정과 연관된 데이터포인트의 콜렉션에 부가하는 단계를 포함하는
    테스트 실행 시스템의 동작 방법.
  5. 제 4 항에 있어서,
    상기 각 테스트는 테스트 객체를 포함하고, 상기 프로시저는 프로시저 객체를 포함하며, 상기 각 측정은 측정 객체를 포함하고, 상기 각 데이터포인트는 데이터포인트 객체를 포함하고, 상기 확장 단계는, 상기 데이터포인트 객체를 상기 프로시저에 의해 결정된 특정 측정과 연관된 데이터포인트 객체의 콜렉션에 부가하는 단계와, 상기 측정 객체를 상기 프로시저에 의해 결정된 특정 테스트와 연관된 측정 객체의 콜렉션에 부가하는 단계와, 상기 사전결정된 테스트 객체를 상기 프로시저 객체에 부가하는 단계를 포함하는
    테스트 실행 시스템의 동작 방법.
  6. 제 5 항에 있어서,
    상기 확장 단계는 상기 객체를 생성하는 단계를 더 포함하는
    테스트 실행 시스템의 동작 방법.
  7. 제 6 항에 있어서,
    상기 실행 단계는 상기 테스트, 측정 및 데이터포인트를 루핑하면서 상기 테스트, 측정 및 데이터포인트의 결과를 포함하는 상기 데이터 구조체를 생성하는
    테스트 실행 시스템의 동작 방법.
  8. 제 1 항에 있어서,
    상기 각 테스트 및 상기 프로시저는 소프트웨어 객체를 포함하고, 상기 확장 단계는 상기 사전결정된 테스트 객체를 상기 프로시저 객체에 부가하는 단계를 포함하는
    테스트 실행 시스템의 동작 방법.
  9. 제 8 항에 있어서,
    상기 확장 단계는 상기 소프트웨어 객체를 생성하는 단계를 더 포함하는
    테스트 실행 시스템의 동작 방법.
  10. 제 1 항에 있어서,
    테스트가 가능한 모델 리스트를 디스플레이하는 단계와, 상기 모델 중 하나를 선택하는 단계를 더 포함하고, 상기 저장 단계는 상기 선택된 모델과 연관된 테스트 및 프로시저를 저장하는 단계를 포함하는
    테스트 실행 시스템의 동작 방법.
  11. 제 10 항에 있어서,
    상기 저장 단계는 상기 선택된 모델과 연관된 DLL 파일을 로드하는 단계를 포함하는
    테스트 실행 시스템의 동작 방법.
  12. 제 11 항에 있어서,
    상기 DLL 파일로부터 이용가능한 프로시저 리스트를 검색하는 단계와, 상기 리스트를 디스플레이하는 단계 및 상기 프로시저를 선택하는 단계를 더 포함하는
    테스트 실행 시스템의 동작 방법.
  13. 제 1 항에 있어서,
    이용가능한 프로시저 리스트를 디스플레이하는 단계와 상기 프로시저를 선택하는 단계를 더 포함하는
    테스트 실행 시스템의 동작 방법.
  14. 테스트 실행 시스템과는 분리되어 별개인 피시험 장치(DUT)를 테스트하는 상기 테스트 실행 시스템에 있어서,
    다수의 테스트 및 프로시저를 저장하는 전자적 메모리- 상기 각 테스트는 테스트 알고리즘을 규정하는 소프트웨어 코드를 포함하고 상기 프로시저는 상기 테스트의 순서화된 리스트를 나타내는 데이터를 포함함- 와,
    상기 메모리와 통신하는 프로세서로서, 상기 순서화된 리스트에 의해 결정된 상기 테스트들 중 사전결정된 테스트들을 결합함으로써 상기 프로시저를 확장하고 상기 DUT에 대해 상기 프로시저를 실행하여 테스트 결과를 생성하는 프로세서와,
    상기 프로세서와 통신하고 상기 테스트 결과를 포함하는 데이터 구조체를 포함하는 그래픽 사용자 인터페이스(GUI)를 포함하는
    테스트 실행 시스템.
  15. 제 14 항에 있어서,
    상기 프로시저는 하나 이상의 측정 리스트를 포함하고, 상기 각 측정은 특정 테스트를 위한 구성을 포함하며, 상기 프로세서는 상기 프로시저를 확장하는 경우 상기 리스트 내의 상기 측정을 상기 특정 테스트와 연관된 측정의 콜렉션에 부가하는
    테스트 실행 시스템.
  16. 제 15 항에 있어서,
    상기 프로시저는 데이터포인트 리스트를 포함하고, 상기 각 데이터포인트는 특정 측정에 대한 다수의 결과들 중 하나와 연관되며, 상기 프로세서는 상기 프로시저를 확장하는 경우, 상기 데이터포인트를 상기 특정 측정과 연관된 데이터포인트의 콜렉션에 부가하는
    테스트 실행 시스템.
  17. 제 14 항에 있어서,
    상기 GUI는 테스트가 가능한 모델 리스트를 포함하는 메뉴를 더 포함하는
    테스트 실행 시스템.
  18. 제 14 항에 있어서,
    상기 메모리는 상기 모델들 중 선택된 모델과 연관된 DLL 파일을 저장하는
    테스트 실행 시스템.
  19. 제 14 항에 있어서,
    상기 GUI는 선택된 모델에 이용가능한 프로시저 리스트를 포함하는 메뉴를 포함하는
    테스트 실행 시스템.
  20. 제 14 항에 있어서,
    상기 데이터 구조체는 계층적 트리인
    테스트 실행 시스템.
  21. 테스트 실행 시스템과 분리되어 별개인 피시험 장치(DUT)에 대한 테스트를 제어하는 테스트 실행 시스템을 제공하는 제품에 있어서,
    프로세싱 유닛이,
    다수의 테스트 및 하나의 프로세서를 메모리 내에로 로드하고- 상기 각 테스트는 테스트 알고리즘을 규정하는 소프트웨어 코드를 포함하고 상기 프로시저는 테스트의 순서화된 리스트를 나타내는 데이터를 포함함 -,
    상기 순서화된 리스트에 의해 결정된 테스트들 중 사전결정된 테스트들을 결합함으로써 상기 프로시저를 확장하고,
    상기 DUT 상에 대해 프로시저를 실행하여 상기 사전결정된 테스트의 결과를 포함하는 데이터 구조체를 생성하도록 지시하는
    인스트럭션과,
    상기 인스트럭션을 저장하는, 상기 프로세싱 유닛에 의해 판독가능한 매체를 포함하는
    테스트 실행 시스템을 제공하는 제품.
  22. 제 21 항에 있어서,
    상기 프로시저는 하나 이상의 측정 리스트를 포함하고, 상기 각 측정은 특정 테스트를 위한 구성을 포함하고, 상기 확장 인스트럭션은 상기 리스트 내의 상기 측정을 상기 특정 테스트와 연관된 측정의 콜렉션에 부가하도록 하는 인스트럭션을 포함하는
    테스트 실행 시스템을 제공하는 제품.
  23. 제 22 항에 있어서,
    상기 프로시저는 데이터포인트 리스트를 포함하고, 상기 각 데이터포인트는 특정 테스트에 대한 다수의 결과들 중 하나와 연관되며, 상기 확장 인스트럭션은 상기 데이터포인트를 상기 특정 측정과 연관된 데이터포인트의 콜렉션에 부가하도록 하는 인스트럭션을 포함하는
    테스트 실행 시스템을 제공하는 제품.
  24. 제 23 항에 있어서,
    상기 각 테스트는 테스트 객체를 포함하고, 상기 프로시저는 프로시저 객체를 포함하며, 상기 각 측정은 측정 객체를 포함하고, 상기 각 데이터포인트는 데이터포인트 객체를 포함하며, 상기 확장 인스트럭션은 상기 데이터포인트 객체를 상기 프로시저에 의해 결정된 특정 측정과 연관된 데이터포인트 객체의 콜렉션에 부가하도록 하고, 상기 측정 객체를 상기 프로시저에 의해 결정된 특정 테스트와 연관된 측정 객체의 콜렉션에 부가하도록 하는 인스트럭션을 포함하는
    테스트 실행 시스템을 제공하는 제품.
KR10-2003-0029410A 2002-05-09 2003-05-09 테스트 실행 시스템의 동작 방법 및 피시험 장치 테스트용테스트 실행 시스템 및 테스트 실행 시스템 제공 제품 KR20030087977A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/141,719 2002-05-09
US10/141,719 US8225152B2 (en) 2002-05-09 2002-05-09 Method and apparatus for generating electronic test and data structure

Publications (1)

Publication Number Publication Date
KR20030087977A true KR20030087977A (ko) 2003-11-15

Family

ID=29249823

Family Applications (1)

Application Number Title Priority Date Filing Date
KR10-2003-0029410A KR20030087977A (ko) 2002-05-09 2003-05-09 테스트 실행 시스템의 동작 방법 및 피시험 장치 테스트용테스트 실행 시스템 및 테스트 실행 시스템 제공 제품

Country Status (5)

Country Link
US (1) US8225152B2 (ko)
EP (1) EP1361446A3 (ko)
JP (1) JP2003330748A (ko)
KR (1) KR20030087977A (ko)
TW (1) TW200306496A (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100892141B1 (ko) * 2007-01-09 2009-04-09 어니컴 주식회사 휴대용 장치의 자동 검증 방법 및 그 장치

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7165240B2 (en) * 2002-06-20 2007-01-16 International Business Machines Corporation Topological best match naming convention apparatus and method for use in testing graphical user interfaces
US7386579B2 (en) * 2003-11-12 2008-06-10 Siemens Product Life Cycle Management Software Inc. System, method, and computer program product for storing test results in a database
US20050107990A1 (en) * 2003-11-19 2005-05-19 Monk John M. Distributed testing system having framework for adding measurements and physical agents
US20050149785A1 (en) * 2003-12-19 2005-07-07 Hassan Mohamed A. Apparatus and method for testing a flash memory unit using stress voltages
US20050138497A1 (en) * 2003-12-19 2005-06-23 Hassan Mohamed A. Apparatus and method for testing a flash memory unit
JP2005300324A (ja) * 2004-04-09 2005-10-27 Agilent Technol Inc 被試験対象デバイスの測定データ解析方法、プログラム、および測定データ解析システム
US7533312B2 (en) 2004-07-29 2009-05-12 Agilent Technologies, Inc. System and method for testing of electronic circuits
US7398514B2 (en) 2004-09-29 2008-07-08 Microsoft Corporation Test automation stack layering
CN100347682C (zh) * 2004-12-08 2007-11-07 上海科泰世纪科技有限公司 自动化测试构建方法
US8325188B1 (en) * 2005-07-21 2012-12-04 Cadence Design Systems, Inc. Method and system for implementing a waveform viewer
US20070179970A1 (en) * 2006-01-31 2007-08-02 Carli Connally Methods and apparatus for storing and formatting data
US7743090B1 (en) 2006-02-08 2010-06-22 Federal Home Loan Mortgage Corporation (Freddie Mac) Systems and methods for infrastructure validation
US7478305B2 (en) * 2006-03-27 2009-01-13 Sapphire Infotech, Inc. Method and apparatus for interactive generation of device response templates and analysis
US7526681B2 (en) * 2006-08-07 2009-04-28 Sap Portals Israel Ltd. Software testing framework
US10001977B1 (en) * 2009-06-05 2018-06-19 The Mathworks, Inc. System and method for identifying operations based on selected data
CN102169183A (zh) * 2010-12-10 2011-08-31 北京空间飞行器总体设计部 一种基于测试原子的卫星自动化测试方法
TW201314442A (zh) * 2011-09-30 2013-04-01 Askey Technology Jiangsu Ltd 手持式電子產品的讀寫測試方法
US20140006867A1 (en) 2012-06-29 2014-01-02 National Instruments Corporation Test Executive System With Process Model Plug-ins
CN102833015B (zh) * 2012-07-27 2014-08-27 北京空间飞行器总体设计部 一种卫星自动化测试系统公共软件接口确定方法
US10436838B2 (en) * 2017-03-23 2019-10-08 Intel Corporation Automated semiconductor platform testing
US10977163B1 (en) * 2017-04-28 2021-04-13 EMC IP Holding Company LLC Test management system and method for an integrated computing system
US10732213B2 (en) 2017-08-14 2020-08-04 Rohde & Schwarz Gmbh & Co. Kg Method for measuring beam steering characteristics and measurement system
JP6986910B2 (ja) * 2017-09-12 2021-12-22 東京エレクトロン株式会社 電圧印加装置および出力電圧波形の形成方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5206582A (en) * 1988-05-18 1993-04-27 Hewlett-Packard Company Control system for automated parametric test equipment
US6029257A (en) * 1996-12-06 2000-02-22 Intergraph Corporation Apparatus and method for testing computer systems
US6128759A (en) 1998-03-20 2000-10-03 Teradyne, Inc. Flexible test environment for automatic test equipment
US6211513B1 (en) * 1998-10-30 2001-04-03 Avaya Technology Corp. Automated test system and method for device having circuit and ground connections
US6463552B1 (en) * 1998-12-07 2002-10-08 Lsi Logic Corporation Scripting method and apparatus for testing devices
US6662217B1 (en) * 1999-01-19 2003-12-09 Microsoft Corporation Distributed and automated test administration system for administering automated tests on server computers over the internet
US6839650B2 (en) 2001-11-19 2005-01-04 Agilent Technologies, Inc. Electronic test system and method

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100892141B1 (ko) * 2007-01-09 2009-04-09 어니컴 주식회사 휴대용 장치의 자동 검증 방법 및 그 장치

Also Published As

Publication number Publication date
JP2003330748A (ja) 2003-11-21
EP1361446A2 (en) 2003-11-12
US8225152B2 (en) 2012-07-17
EP1361446A3 (en) 2006-01-18
TW200306496A (en) 2003-11-16
US20030212938A1 (en) 2003-11-13

Similar Documents

Publication Publication Date Title
KR20030087977A (ko) 테스트 실행 시스템의 동작 방법 및 피시험 장치 테스트용테스트 실행 시스템 및 테스트 실행 시스템 제공 제품
US6839650B2 (en) Electronic test system and method
US5910895A (en) Low cost, easy to use automatic test system software
US6681351B1 (en) Easy to program automatic test equipment
US7055138B2 (en) Test executive system with tree structure for summarizing results
US6442515B1 (en) Process model generation independent of application mode
WO2007053634A2 (en) Functional testing and verification of software application
US8843841B2 (en) System and method for interactive instrument operation and automation
US6745140B2 (en) Electronic test system with test results view filter
US6823272B2 (en) Test executive system with progress window
KR20070001832A (ko) 자동 테스트 장비에 대한 테스트를 실시하는 방법 및컴퓨터 프로그램
EP1012615B1 (en) System for storing and searching named device parameter data in a test system for testing an integrated circuit
US6594599B1 (en) System, work station and method for testing a product and generating a statistical model that predicts the processibility of making like products
US8527964B2 (en) Measurement project analyzer
US20030212522A1 (en) Externally controllable electronic test program
US7050921B2 (en) Electronic test program with run selection
Klinger Reusable test executive and test programs methodology and implementation comparison between HP VEE and LabView
US20030093718A1 (en) Electronic test program with selectable specifications
US10180440B1 (en) Method for automating instrument tests

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid