테스트 시스템의 성능은 제조 라인의 생산성과 비용에 상당한 영향을 미칠 수 있습니다. 느린 테스트 시스템은 값비싼 복제가 필요하거나 테스트 적용 범위를 감소시킬 수 있으며, 둘 모두 품질에 영향을 미칠 수 있습니다. 테스트 소프트웨어 성능을 최적화하면 테스트 시간에서 큰 이득을 얻고 더 적은 수의 테스트 스테이션을 사용하여 보다 철저한 테스트를 제공할 수 있습니다.
이 문서에서는 NI TestStand 소프트웨어로 개발된 테스트 스테이션의 성능을 최적화하기 위한 몇 가지 모범 사례를 제공합니다. 하나의 솔루션이 모든 테스트 시스템에서 작동하는 것은 아니라는 점을 기억해야 합니다. 어떤 접근 방식은 특정 테스트 시스템의 성능을 저하시키는 반면 다른 테스트 시스템의 성능은 증가시킵니다. 시스템에 대한 변경 사항을 구현하기 전후에 잠재적인 이점과 단점을 평가할 수 있도록 테스트 결과를 벤치마킹할 필요가 있습니다.
TestStand에는 성능에 영향을 줄 수 있는 몇 가지 설정 옵션이 있습니다. 다음 섹션에서는 이러한 옵션에 대해 설명합니다.
시퀀스 추적은 통과, 실패, 에러 또는 건너뛰기 등 현재 작업에 대한 즉각적인 피드백과 상태를 제공합니다. 그러나 시퀀스 추적은 실행 속도를 감소시켜 성능에 영향을 미칩니다. 다음 접근 방식은 시퀀스 추적의 이점을 그대로 유지하면서 실행 속도를 향상시키는 데 도움이 될 수 있습니다.
시퀀스 추적이 활성화되었을 때 성능을 향상시키려면 추적 속도를 빠르게 설정하여 각 단계 사이에 추가 지연이 발생하지 않도록 해야 합니다. 스테이션 옵션 대화 상자의 실행 탭을 사용하여 구성 ≫ 스테이션 옵션을 사용하여 액세스할 수 있는 추적을 설정합니다.
가장 빠른 속도로 설정된 경우에도, 각 단계가 실행된 후 실행 보기 창을 업데이트하기 위해, 추적이 단계당 몇 밀리초의 오버헤드를 추가합니다. 가장 빠른 성능을 얻으려면 추적을 완전히 비활성화할 수 있습니다. 그러나 시퀀스 추적을 비활성화하는 경우 시퀀스가 실행될 때 실행 보기가 업데이트되지 않습니다.
추적의 유용성과 성능 사이의 균형을 맞추려면 시퀀스 호출 추적 설정을 사용하여 특정 서브시퀀스에서 추적을 비활성화합니다. 이 접근 방식을 사용하려면 테스트를 논리 그룹으로 구성하고 각 그룹에 대해 서브시퀀스를 만드십시오. 예를 들어, 모바일 디바이스의 테스트 시퀀스에서 셀룰러 데이터, 사용자 입력 및 오디오 시스템과 같은 각 구성 요소에 대한 테스트는 각각 별도의 시퀀스로 구현될 수 있습니다. 각 구성 요소의 SequenceCall 단계의 경우 시퀀스 호출 내에서 추적을 비활성화합니다.
이러한 방식으로 테스트 시퀀스를 구성하면 각 하위 단계를 추적하는 성능 오버헤드 없이 최상위 시퀀스에 시퀀스 추적을 사용할 수 있습니다. 또한 이 접근 방식은 각 서브시퀀스를 비동기식으로 호출할 수 있기 때문에 병렬 테스트에 쉽게 적용할 수 있습니다. 테스트 시퀀스 병렬화에 대한 자세한 내용은 병렬 테스트를 통한 테스트 성능 향상 섹션을 참조하십시오.
추적이 비활성화된 시퀀스 호출 단계를 사용하여 성능 향상 및 실행 상태 확인
TestStand를 사용하면 코드 모듈이 메모리에 로드되거나 메모리에서 언로드되는 시기를 설정할 수 있으며, 이는 테스트 시퀀스의 메모리 사용과 실행 속도에 상당한 영향을 미칠 수 있습니다. 메모리에 더 오래 유지되도록 모듈을 설정하면 서브시퀀스 실행 시 모듈을 다시 로드할 필요가 없으므로 실행 시간이 향상됩니다. 그러나 너무 많은 모듈을 메모리에 유지할 경우 어플리케이션 메모리 제한이나 사용 가능한 물리적 메모리를 초과할 수 있으며, 이로 인해 실행이 느려질 수도 있습니다.
이상적으로는 메모리 절약을 위해 코드 모듈을 언로드하는 대신 테스트 시스템을 개선하여 메모리 제한을 늘릴 수 있습니다. 예를 들면 다음과 같습니다.
메모리 사용이 여전히 문제가 되는 경우, 로드/언로드 옵션을 단계 레벨 또는 시퀀스 파일 레벨에서 설정할 수 있습니다. 대부분의 테스트 시스템에서는 시퀀스 파일을 열 때 미리 로드 또는 실행을 시작할 때 미리 로드 옵션을 시퀀스 파일이 닫힐 때 언로드 옵션과 결합하여 최적의 성능을 얻을 수 있습니다.
목표 | 최적의 설정 |
실행 시간 최대화 | 시퀀스 파일을 열 때 미리 로드를 사용하고 시퀀스 파일이 닫힐 때 언로드를 사용하여 시퀀스가 닫힐 때까지 모듈을 메모리에 유지합니다. 모듈을 메모리에 로드된 상태로 유지하면 서브시퀀스 호출의 속도가 빨라집니다. |
메모리 사용 감소 | 더 이상 사용하지 않게 되는 즉시 메모리에서 모듈을 제거하려면 동적 로드 및 단계 실행 후 언로드를 사용합니다. 그러나 단계가 실행될 때마다 모듈을 다시 로드해야 하기 때문에 성능이 저하됩니다. 이 설정에는 코드 모듈이 언로드될 때 코드 모듈 내의 글로벌 데이터가 손실될 수 있는 등의 추가적인 위험이 있습니다. |
파일 포맷은 대용량 시퀀스 파일을 로드할 때 속도와 성능에 영향을 미칠 수 있습니다. TestStand를 사용하면 시퀀스를 다음과 같은 파일 포맷으로 저장할 수 있습니다. INI, XML 및 2진.
새 시퀀스 파일에 사용할 포맷을 지정하려면
기존 시퀀스 파일의 포맷을 변경하려면:
가장 빠른 시퀀스 파일 로드를 위해 2진 파일 포맷 사용
검색 디렉토리 설정은 시퀀스 파일과 코드 모듈이 상대 경로로 지정될 때 로드 시간에 직접 영향을 미칩니다. 검색 디렉토리 설정은 테스트의 초기 로드 및 실행의 성능과 모듈이 동적으로 로드되는 경우 후속 반복의 성능에 영향을 미칩니다. 검색 디렉토리 설정 대화 상자를 사용하여 검색 디렉토리를 보고 편집합니다. 설정 ≫ 검색 디렉토리를 선택하여 검색 디렉토리 편집 대화 상자를 엽니다.
코드 모듈 상대 경로를 해결할 때 TestStand는 다음 절차를 사용합니다.
TestStand는 검색 디렉토리 목록을 확인하여 코드 모듈 파일에 대한 상대 경로를 해결
각 검색 디렉토리에 대해 하나의 경로만 계산되므로, 이 프로세스는 일반적으로 성능에 큰 영향을 주지 않습니다.
그러나 검색 디렉토리에 검색 서브디렉토리 옵션이 있는 경우, 지정된 경로 내의 모든 서브디렉토리에 대해 프로세스가 반복됩니다. 경로에 큰 디렉토리 계층구조가 포함된 경우, 이 옵션은 성능에 심각한 영향을 미칠 수 있습니다. 또한 계층구조 내에 같은 이름의 파일이 여러 개 있을 경우, 잘못된 파일을 로드할 수 있습니다. 이러한 이유로, 추가 검색 디렉토리에 이 옵션을 사용하지 마십시오. 대신 모든 코드 모듈 경로가 기본 검색 디렉토리의 상대 경로를 사용하여 지정되었는지 확인하십시오.
검색 디렉토리 순서를 더욱 최적화하려면 다음 지침을 사용하십시오.
테스트 시스템의 디렉토리 구조를 설계할 때, 코드 모듈을 시퀀스 파일 경로 아래의 디렉토리 또는 특정 코드 모듈 위치에 저장하는 것을 고려하십시오.
TestStand는 다양한 개발 환경의 코드 모듈을 호출하여 테스트 단계를 수행할 수 있습니다. 이러한 코드 모듈과 개발 환경의 설정은 성능에 큰 영향을 미칠 수 있습니다. 어떤 코드 모듈 환경에서도 필요한 데이터만 코드 모듈 안과 밖으로 전달함으로써 더 나은 성능을 얻을 수 있습니다. 코드 모듈에서 액세스하거나 수정하지 않는 대량의 데이터가 전달되지 않도록 하십시오.
컴파일된 코드 모듈(예: .NET 어셈블리 또는 C/C++ DLL)은 릴리스 버전이 아닌 DLL의 디버그 버전을 사용할 때 성능을 저하시킬 수 있습니다. 일반적으로 개발자들은 개발 중에 디버그 DLL을 사용하여 모듈에서 문제를 쉽게 찾고 수정합니다. 테스트 시퀀스를 배포할 준비가 되면 릴리스 DLL로 전환하여 성능을 향상시키십시오.
LabVIEW VI는 직접 실행되기 때문에, LabVIEW 개발 환경이나 LabVIEW 런타임 엔진에서 실행할 수 있습니다. 개발 환경에서 LabVIEW VI를 실행할 때는 디버깅 기능을 사용하여 코드 모듈 문제를 해결할 수 있지만 실행 속도는 느려집니다. 생산 테스트의 경우 LabVIEW 런타임 엔진을 사용하여 VI를 호출합니다. LabVIEW 어댑터 대화상자를 사용하여 LabVIEW 코드를 실행하는 데 사용되는 LabVIEW 서버를 설정할 수 있습니다.
LabVIEW 코드의 로드 시간을 더욱 최적화하려면 코드 모듈 VI를 PPL(패키지 프로젝트 라이브러리)로 빌드할 수 있습니다. PPL에는 코드 모듈 Vi의 모든 VI 의존성의 컴파일된 버전이 포함되어 있기 때문에 LabVIEW는 의존성을 메모리에 더 빨리 로드할 수 있습니다. 또는 TestStand Deployment Utility를 사용하여 코드를 배포하는 경우 배포 프로세스의 일부로 Vi에 대한 PPL을 생성할 수 있습니다.
TestStand Deployment Utility와 함께 PPL을 사용하는 방법에 대한 자세한 내용은 LabVIEW 패키지 프로젝트 라이브러리를 사용하여 테스트 프로그램 파일 설정 도움말 항목을 참조하십시오.
병렬 테스트를 활용하여 여러 테스트를 동시에 완료함으로써 테스트 속도를 향상시킬 수 있습니다. TestStand는 단일 UUT의 테스트를 병렬화하거나 여러 UUT를 동시에 테스트하는 데 도움이 되는 기능을 제공합니다.
단일 UUT를 테스트할 때 시스템의 여러 부분을 동시에 테스트할 수 있습니다. 예를 들어 모바일 디바이스의 테스트 시퀀스를 고려하십시오. 셀룰러 데이터, 사용자 입력 및 오디오 시스템과 같은 각 구성 요소에 대한 테스트는 각각 별도의 서브시퀀스로 구현될 수 있습니다. 각 시퀀스를 순차적으로 호출하는 대신 비동기식으로 호출하는 시퀀스 호출 단계를 설정하여 테스트 속도를 높일 수 있습니다.
시퀀스 호출을 비동기식으로 실행하도록 지정하려면:
새 스레드에서 시퀀스를 호출하면 UUT의 여러 부분을 동시에 테스트할 수 있음
비동기 시퀀스 호출을 설정할 때 새 스레드 사용과 새 실행 사용 간의 차이를 고려하십시오.
새 스레드 | 새 실행 |
호출자와 동일한 결과 수집 및 리포트 공유 | 자체 결과 수집 및 리포트 제공 |
직접 실행됨 | 프로세스 모델 입력 포인트를 사용하여 실행 가능 |
호출자와 시퀀스 파일 글로벌 값 공유 | 시퀀스 파일 글로벌 값의 새 복사본 제공 |
호출자와 함께 종료 또는 일시 중단됨 | 독립적으로 종료 또는 일시 중단됨 |
일반적으로 테스트 시퀀스 내에서 관련 테스트에 새 스레드 옵션을 사용해야 합니다. 새로운 실행을 사용하는 것이 테스트 시퀀스와 독립적으로 실행되어야 하는 상태 모니터 같은 보다 독립적인 기능에 더 적합합니다.
새 스레드 또는 실행을 사용할지 여부를 선택하는 방법에 대한 자세한 내용은 새 실행 또는 새 스레드에서 시퀀스를 실행할 시기를 참조하십시오.
보고 또는 데이터베이스 로깅을 위한 비동기 서브시퀀스 결과를 얻으려면 시작 시퀀스 끝에 있는 대기 단계를 사용하여 비동기 시퀀스 호출이 완료될 때까지 기다립니다. 서브시퀀스 스레드가 완료되면 TestStand는 비동기 서브시퀀스의 결과를 대기 단계 결과에 첨부하여 리포트 생성 및 데이터베이스 로깅에 사용할 수 있도록 합니다. 시퀀스 실행 또는 스레드에서 대기하려면 컨트롤에 대해 대기에서 실행 또는 스레드를 선택하고 대기할 실행 또는 스레드를 지정합니다. 이 대기를 추가하면 스레드 전에 호출 시퀀스가 완료될 경우 실행이 지연될 수 있으므로 새 스레드 결과가 필요할 때만 이 방법을 사용하십시오.
대기 단계를 사용하여 비동기 시퀀스 호출 결과 가져오기
TestStand는 테스트 시퀀스에서 비동기 호출을 사용하는 것 외에도 병렬 및 배치 프로세스 모델을 사용하여 여러 UUT를 병렬로 테스트할 수 있습니다. 이러한 프로세스 모델은 각각 별도의 UUT에서 테스트 시퀀스를 실행하는 다중 실행을 생성합니다. 현재 스테이션 또는 개별 테스트 시퀀스 파일의 프로세스 모델을 변경할 수 있습니다.
병렬 및 배치 프로세스 모델을 사용하여 여러 UUT를 동시에 테스트
병렬 테스트를 통해 테스트 시간을 향상시키는 방법에 대한 데모는 TestStand에 포함된 병렬 테스트 전략 데모를 참조하십시오.
병렬 프로세스 모델은 UUT의 테스트를 서로 다른 시간에 시작하고 마칠 수 있도록 하는 반면, 배치 프로세스 모델은 모든 UUT에서 동시에 테스트 시퀀스를 시작하고 마칠 수 있도록 설계되었습니다.
배치 프로세스 모델에서는 각 배치 테스트를 동시에 시작하고 종료하는 것 외에도 배치 동기화 단계 및 설정을 사용하여 배치의 UUT 간 테스트를 추가로 동기화할 수 있습니다. 모든 UUT에 대해 테스트의 특정 부분을 동시에 실행해야 하는 경우, 단계 설정을 사용하여 단일 단계에 대해 동기화 섹션을 정의하거나, 배치 동기화 단계 타입을 사용하여 여러 단계에 대해 동기화 섹션을 정의할 수 있습니다.
배치 동기화를 사용하여 배치의 모든 UUT에 대해 테스트의 특정 부분이 동기화되는지 확인
배치 동기화 섹션의 모든 타입에 대해 모든 소켓은 함께 섹션을 시작하고 종료합니다. 순차적으로 또는 단일 스레드에서만 실행되도록 동기화를 추가로 설정할 수 있습니다.
배치 동기화에 대한 자세한 내용은 동기화 단계 타입 – 배치 동기화 예제를 참조하십시오.
여러 UUT를 병렬로 테스트할 때 사용 가능한 테스트 하드웨어는 성능 병목 현상을 일으킬 수 있습니다. 공유 하드웨어 리소스를 사용할 때 리소스 충돌을 방지하기 위해 지정된 시간에 하나의 스레드만 공유 하드웨어 리소스에 액세스하는지 확인하십시오. 일반적으로 잠금 세팅 또는 단계 타입을 사용하여 공유 리소스를 예약합니다. 그러나 여러 개의 스레드가 테스트를 완료하기 위해 단일 리소스를 기다리는 경우, 병렬 테스트의 잠재적 개선 사항 중 많은 부분이 실현되지 않을 것입니다. 이를 완화하려면 다음 접근 방식을 사용하십시오.
자동 예약 단계 타입을 사용하면 테스트 시간과 하드웨어 사용률을 최적화하기 위해 어떤 순서로든 실행할 수 있는 테스트 세트를 설정할 수 있습니다. 병렬 또는 배치 프로세스 모델을 사용하여 자동 예약 섹션을 실행할 때, 각 소켓은 예약된 리소스가 필요 없는 첫 번째 섹션을 실행합니다. 이러한 이유로, 동일한 테스트를 실행할 때마다 실행 순서가 달라질 수 있습니다.
실행 순서가 중요하지 않은 경우 자동 스케줄러를 사용하여 하드웨어 사용률 최적화
테스트의 실행 순서가 중요하지 않은 경우 이 접근 방식을 사용하십시오. 테스트에서 테스트 결과를 특정 순서로 표시해야 하는 경우, 자동 예약을 사용하지 마십시오.
TestStand와 함께 제공되는 Execution Profiler 도구는 어떤 테스트 하드웨어가 테스트 시스템의 실행 속도를 제한하고 있는지 식별하는 데 유용합니다. 도구 ≫ 프로파일 실행을 사용하여 Sequence Editor에서 프로파일러를 시작합니다.
프로파일러를 통해 각 하드웨어 리소스가 얼마나 활성 상태인지 확인할 수 있으므로, 테스트 시스템에 하드웨어를 추가했을 때의 영향에 대해 정보에 입각한 결정을 내릴 수 있습니다. 아래의 예제 프로파일에서 DMM은 충분히 활용되지만 스코프는 66%만 활용됩니다. 이 프로파일에 기초하여 두 번째 DMM을 추가하거나, 채널이 더 많은 DMM을 추가하면 이 시퀀스의 테스트 시간이 개선될 것입니다.
Execution Profiler를 사용하여 테스트 설정에서 어느 리소스에 잠재적인 병목 현상이 발생할지 시각화할 수 있음
가장 효율적인 방법으로 하드웨어와 인터페이스하는 경우, 테스트 시간을 단축할 수 있습니다. 이 섹션에서는 성능을 개선하기 위해 하드웨어 참조 및 측정 기법을 관리하기 위한 고려사항에 대해 설명합니다.
주어진 하드웨어 설정에는 테스트 효과를 감소시킬 수 있는 몇 가지 공통 인자가 있습니다. 예를 들어 오실로스코프를 사용하여 신호의 상승 시간, 하강 시간, RMS 및 피크 값을 측정할 수 있습니다. 오실로스코프를 프로그래밍하여 전체 웨이브폼을 캡처하고 웨이브폼을 테스트 시스템으로 전송한 다음 데이터에 대한 후처리를 수행하여 원하는 측정을 추출하면 전송되는 데이터의 양이 많아져서 성능 저하가 발생할 수 있습니다. 성능도 통신 버스의 지연 시간에 영향을 받기 때문에, 계측기가 LAN이나 시리얼 연결같이 대기 시간이 높은 버스를 사용하는지, PCI나 PXI 같이 대기 시간이 낮은 버스를 사용하는지 고려해야 합니다.
상승 시간을 측정하고, 수집을 트리거하고, 계측기에서 상승 시간을 다시 읽어 들이고, 각 측정에 대해 반복하도록 오실로스코프를 설정한 다음, 각 측정에 대해 오실로스코프를 다시 설정하고 트리거해야 합니다. 이 옵션은 느리고 비효율적인 경향이 있습니다.
최신 오실로스코프에는 대체로 여러 개의 측정 채널이 있다는 점을 고려하여 다음 단계를 수행하여 테스트를 더 빠르게 실행하십시오.
하드웨어에 대한 세션을 자주 열고 닫으면 성능이 저하될 수 있습니다. 디바이스와의 통신을 초기화할 때, 드라이버는 대체로 통신 및 설정을 확인하기 위해 대량의 데이터를 전송합니다. 이러한 이유로 하드웨어에 접근하기 위해 테스트 내내 사용되는 세션 핸들을 유지하면서 테스트당 한 번만 하드웨어를 초기화하는 것이 가장 좋습니다.
테스트에서 한 번만 하드웨어를 초기화하려면 여타 테스트 코드보다 먼저 실행되는 ProcessSetup 프로세스 모델 콜백을 사용하십시오. 병렬 및 배치 프로세스 모델의 경우 ProcessSetup은 테스트 소켓 수와 관계없이 한 번만 실행됩니다. 참조를 정리하려면 모든 테스트가 완료된 후 한 번 실행되는 ProcessCleanup 콜백을 사용할 수 있습니다. 프로세스 모델 콜백 작성 및 사용에 대한 자세한 내용은 NI TestStand에서 콜백 사용을 참조하십시오.
프로세스 모델 콜백에서 열린 하드웨어 세션에 액세스하려면 콜백 시퀀스와 MainSequence 간에 공유되는 파일 글로벌 변수를 사용하십시오. 또는 activeX 객체를 사용하여 하드웨어 세션 수명을 자동으로 관리할 수 있는 세션 관리자를 사용할 수 있습니다. 세션 관리자 사용에 대한 자세한 내용은 세션 관리자 예제를 참조하십시오.
결과 수집이 시스템 성능에 미치는 영향을 최적화하는 방법에는 여러 가지가 있습니다.
내장된 결과 프로세서의 경우 테스트 시퀀스가 끝날 때가 아니라 시퀀스가 실행될 때 로깅을 수행하도록 즉시 옵션을 선택할 수 있습니다. 이 세팅의 사용 여부를 선택할 때 이러한 이점과 단점을 고려하십시오.
즉시 로깅의 이점:
즉시 로깅의 단점:
즉석 로깅의 이점을 얻기 위해 속도 저하가 허용될 경우 즉시 세팅을 조정하여 성능에 미치는 영향을 줄일 수 있습니다. 이러한 설정에 액세스하려면:
성능을 향상시키려면 처리 간격 및/또는 최대 결과 수를 늘려 TestStand 로그의 결과 빈도를 줄이십시오.
결과 생성에 걸리는 시간을 줄이기 위해, 결과 데이터를 오프라인 결과 파일에 기록할 수 있습니다. 이 파일은 TestStand가 리포트를 생성하거나 데이터베이스에 로그하는 데 필요한 모든 정보를 포함하고 있는 빠르고 컴팩트한 원시 결과 포맷입니다. 이 파일은 원시 결과 데이터만 포함하고 있기 때문에 처리하는 데 시간이 덜 걸리므로 테스트 처리량을 개선할 수 있습니다.
오프라인 결과 처리 유틸리티를 사용하여 원시 결과 파일을 테스트 리포트로 처리하거나 데이터를 데이터베이스에 기록합니다. 이 유틸리티는 별도의 유틸리티이기 때문에 테스트와 별개로 실행할 수 있으므로, 나중에 또는 다른 컴퓨터에서 결과를 처리할 수 있습니다. 즉각적인 리포트 생성보다 테스트 시스템 성능이 중요한 상황에서는 이 유틸리티를 사용하십시오. 자세한 내용은 TestStand 오프라인 결과 처리 유틸리티 도움말을 참조하십시오.
일부 네트워크 데이터 전송 메커니즘은 다른 메커니즘보다 빠르지만 하드 드라이브에 로컬로 저장된 데이터는 네트워크 위치에 저장된 데이터보다 빠르게 기록됩니다. 예를 들어, MSMQ (Microsoft Message Queue)를 사용하여 데이터베이스와 통신하면 로컬 중간 데이터 파일이 생성되어 네트워크를 통해 전송됩니다. 이는 원격 데이터베이스에 직접 쓰는 것보다 일반적으로 더 빠르고 안전합니다. TestStand는 MSMQ를 사용하기 위한 기본적인 기능을 제공하지 않지만, 이러한 타입의 통신을 구현하기 위해 타사 도구를 사용할 수 있습니다.
고려해야 할 또 다른 인자는 시스템에 로깅하는 데이터의 양입니다. 기록된 데이터의 양이 증가함에 따라 성능은 감소합니다. 필요한 데이터만 기록하려면 특정 단계 또는 시퀀스에 대한 결과 기록을 비활성화할 수 있습니다.
결과 기록 옵션(단계 ≫ 프로퍼티 ≫ 실행 옵션)을 선택 취소하여 개별 단계에 대한 기록 결과를 제외할 수 있습니다. 또한 시퀀스 프로퍼티 대화 상자의 모든 단계에 대해 결과 기록 비활성화 세팅을 사용하여 결과 기록을 제외하도록 전체 시퀀스를 설정할 수 있습니다.
생산 환경에서는 UUT가 어떤 테스트에 실패했는지 구체적으로 알 필요는 없습니다. UUT가 테스트에 실패했다는 사실만 알면 됩니다. 이 경우 시스템 리소스를 확보하지 못한 첫 번째 실패 시 테스트를 종료한 후 나중에 보다 상세한 고장 분석 결과를 얻을 수 있습니다.
테스트에 따라, 일부 실패는 다른 실패보다 더 심각할 수도 있습니다. 특정 단계가 실패할 경우에만 테스트를 종료할 수 있습니다. 개별 단계 또는 시퀀스에 대한 장애 동작을 설정할 수 있습니다.
특정 단계의 고장에 대한 테스트를 종료하려면:
특정 시퀀스의 모든 고장에 대한 테스트를 종료하려면:
또한 이 세팅을 특정 테스트 스테이션에 대해 설정할 수 있습니다. 예를 들어, 양산 테스트 머신에서 조기 종료하는 동시에 생산 라인 밖에서 진단 머신에 대한 전체 테스트를 완료할 수 있습니다. 테스트 실패 시 종료되도록 특정 테스트 시스템을 설정하려면: