TestStand 시스템 배포 모범 사례

테스트 시스템은 일반적으로 많은 구성요소와 파일이 포함된 복잡한 시스템입니다. 테스트가 생산 시스템에서 원활하게 실행되려면 이 모두가 올바르게 배포되어야 합니다. 이 문서에서는 제품 테스트에 사용되는 소프트웨어 구성요소만 다룹니다.

배포에 포함되어야 하는 많은 요소로 구성된 TestStand 시스템

TestStand 테스트 시스템의 주요 구성요소로는 테스트 코드, 테스트 프레임워크 파일, 드라이버 및 런타임 엔진이 있습니다.

테스트 코드

테스트 코드는 실제 테스트를 구현하고자 생성한 시퀀스 파일 및 코드 모듈로 구성됩니다. 테스트 코드를 배포할 때는 코드 모듈의 필수 의존성이 모두 포함되어 있는지, 호출자가 파일을 찾을 수 있도록 디스크의 올바른 위치에 파일이 배포되어 있는지 확인해야 합니다. 일반적으로 테스트 코드에는 참조할 파일과 함께 시퀀스 파일이 하나 이상 포함됩니다. 

시퀀스 파일

시퀀스 파일은 호출하는 코드 모듈, 시퀀스 파일 의존성 및 프로퍼티 로더 파일과 같은 보조적 파일에 따라 달라집니다. TestStand 배포 유틸리티를 사용하여 시퀀스 파일을 분석하고 이러한 의존성을 열거할 수 있습니다. TestStand 표현식으로 지정된 프로퍼티 파일과 같이 동적으로 참조된 의존성 또는 테스트 문서처럼 내부적으로 참조된 파일은 TestStand 배포 유틸리티에서 인식되지 않습니다.

가능하면 시퀀스 파일 경로 아래의 서브디렉토리에 특정 시퀀스 파일에 대한 의존적인 파일을 전부 저장해야 합니다. 이러한 구조에는 다음과 같은 이점이 있습니다.

• 현재 시퀀스 파일 관련 경로를 통해 파일을 참조할 수 있으므로, 시퀀스 파일과 의존성을 다른 위치에 복사해도 경로가 유효한 상태로 유지됩니다.
• 의존성 디렉토리를 전체적으로 배포할 수 있으므로, 동적으로 호출된 내부 의존성을 훨씬 쉽게 추적할 수 있습니다.

또한, 코드 모듈 자체의 의존성도 고려해야 합니다. 이러한 의존성을 배포하는 프로세스는 모듈 타입에 따라 다릅니다.

LabVIEW 코드 모듈

LabVIEW코드 모듈에는 VI, LabVIEW 클래스 멤버 호출, 익스프레스 VI 호출 및 프로퍼티 노드 호출이 포함됩니다. LabVIEW 개발 시스템이 설치되지 않은 시스템에서 LabVIEW 코드 모듈을 실행하려면 VI 코드 모듈의 모든 의존성이 동일한 LabVIEW 버전에 저장되어 있는지 확인해야 합니다. 또한, LabVIEW 개발 시스템과 함께 제공되는 의존적인 VI가 LabVIEW 설치의 vi.lib 또는 instr.lib 디렉토리에 있는 것과 마찬가지로 배포에도 포함되어 있어야 합니다. 다음 접근 방식을 사용하면 앞서 언급한 두 조건을 모두 충족할 수 있습니다.

• 모든 코드 모듈 VI에 대한 LabVIEW 소스 배포를 생성하고 vi.lib, instr.lib 및 user.lib을 제외하는 옵션이 선택되어 있지 않은지 확인하십시오. 소스 VI와 소스 배포의 VI 간 상호 링크를 방지하려면 파일을 새로운 프로젝트 라이브러리에 추가해야 합니다.
• 소스 파일에 대해 하나 이상의 PPL(묶음 프로젝트 라이브러리)을 생성하십시오. PPL은 모든 VI와 각각의 의존성을 포함하는 단일 컴파일 파일입니다. 이 접근 방식을 사용하면 배포된 PPL을 업데이트된 버전으로 대체하여 기존 배포를 업데이트할 수 있습니다.

*PPL에는 DLL인 의존성 또는 PPL로 이미 컴파일된 VI가 포함되지 않습니다.

TestStand 배포 유틸리티를 통해 LabVIEW 코드 모듈을 호출하는 시퀀스 파일을 배포하여 이 프로세스의 대부분을 자동으로 핸들링할 수 있습니다. TestStand 배포 유틸리티는 모든 VI를 단일 LabVIEW 버전으로 저장하며, LabVIEW ADE의 일부인 필수 의존성을 포함합니다. 배포 유틸리티는 선택적으로 PPL (묶음 프로젝트 라이브러리)을 생성할 수 있습니다. 더 자세한 정보는 LabVIEW 묶음 프로젝트 라이브러리에 VI 배포하기를 참조하십시오.

C/C++ DLL 의존성

일반적으로 의존적인 DLL은 빌드 디렉토리에 복사되거나 필수 런타임 엔진에 포함된 시스템 DLL이 됩니다. 가능하면 DLL 또는 기타 바이너리를 Windows 시스템 디렉토리에 직접 배포하지 말고, 이러한 의존성을 설치하는 소프트웨어를 결정하여 배포에 포함시켜야 합니다. 추가 소프트웨어 배포에 대한 자세한 정보는 아래의 드라이버 및 런타임 섹션을 참조하십시오.

.NET Dependency

관리되지 않는 C/C++ DLL과 마찬가지로 관리되는 .NET DLL은 ADE 없이 실행될 수 있는 컴파일된 코드입니다. C/C++ DLL과 달리 .NET Assembly는 GAC(전역 어셈블리 캐시)에서 의존적인 어셈블리를 참조할 수 있습니다. 여기에는 드라이버 또는 런타임 소프트웨어와 함께 설치되는 어셈블리뿐만 아니라, 고유한 자체 코드도 포함될 수 있습니다.

.NET Assembly를 만들 때 참조된 어셈블리에 대해 ‘로컬 복사’ 프로퍼티를 사용하여 어셈블리 옆에 복사본을 포함할 수 있습니다. 이렇게 하면 어셈블리 및 의존성을 포함하는 폴더를 배포하여 .NET Dependency가 배포되도록 할 수 있습니다.

테스트 프레임워크 파일

테스트 코드뿐만 아니라 TestStand 프레임워크 파일도 배포해야 합니다. 배포에 TestStand 런타임을 포함하면 해당 파일의 기본 버전이 시스템에 설치됩니다. 그러나 이러한 구성요소 버전을 사용자 정의한 경우 테스트 시스템 배포에 이를 포함해야 합니다. 

TestStand 설정 파일

TestStand 설정 파일은 TestStand의 로컬 설치 셋팅을 저장합니다.  이러한 파일은 테스트 시스템의 동작을 설명하고 유도합니다. TestStand 설정 파일은 <TestStand Application Data>\Cfg 디렉토리에 있습니다.

TestStand에 포함된 설정 파일 및 각 파일에 저장되는 정보에 대한 자세한 내용은 설정 파일 도움말 토픽을 참조하십시오.

TestStand 구성요소

TestStand 구성요소는 테스트 시스템의 상위 레벨 실행을 구현하고 TestStand 아키텍처의 모듈화를 개선하기 위해 테스트 시퀀스에서 분리된 기능입니다. TestStand 구성요소는 로그인 및 로그아웃 기능, 리포트 작성, 데이터베이스 로깅 및 시리얼 번호 입력과 같은 기능을 구현합니다. 이러한 파일은 <TestStand>\Components 디렉토리에 있습니다.

TestStand 구성요소 디렉토리의 아이템에 대한 자세한 내용은 구성요소 디렉토리 도움말 토픽을 참조하십시오.

TestStand 사용자 인터페이스

시퀀스 편집기는 개발 컴퓨터에서만 사용할 수 있으므로, 배포된 컴퓨터에서 시퀀스를 실행하려면 하나 이상의 사용자 인터페이스를 배포해야 합니다. 사용자 인터페이스는 필요에 따라 단순하게, 또는 고도로 사용자 정의할 수 있습니다. TestStand에는 <TestStand Public>/UserInterfaces에서 배포할 수 있는 사용자 인터페이스 어플리케이션이 포함되어 있습니다.

배포된 컴퓨터에서 사용할 TestStand 사용자 인터페이스 생성에 대한 구체적인 정보는 NI TestStand 사용자 인터페이스 개발 관련 모범 사례 문서를 참조하십시오.

드라이버 및 런타임 엔진

생산 시스템에서 시퀀스 및 테스트 코드를 실행하려면 필수 런타임 엔진(런타임) 및 하드웨어 드라이버가 모두 설치되어 있는지 확인해야 합니다. DLL, VI 및 시퀀스 파일과 같은 소프트웨어 구성요소를 실행하려면 런타임 엔진이 필요합니다. 테스트 시스템에서 사용하는 하드웨어 구성요소에는 드라이버가 있어야 합니다. TestStand 엔진 및 지원 파일이 포함된 TestStand 런타임을 배포해야 합니다. 

TestStand 배포 유틸리티를 사용하여 배포하는 경우 코드 모듈에서 참조하는 필수 드라이버 및 런타임 버전을 감지하여 포함하도록 선택할 수 있습니다. 런타임을 포함하지 않는 경우, TestStand 배포 유틸리티는 배포에 포함되어야 하는 버전을 나타내는 정보성 로그 메시지를 제공합니다.

소프트웨어 라이센스

배포된 컴퓨터에 적합한 소프트웨어 라이센스를 사용할 수 있는지 확인해야 합니다. 배포된 각 컴퓨터에는 반드시 기본 배포 라이센스가 있어야 합니다. 이 라이센스로 시퀀스 실행은 가능하지만, 개발은 불가능합니다. LabVIEW 및 LabWindows/CVI 런타임 같은 런타임 엔진에는 대체로 라이센스 요구 사항이 없습니다. 배포하는 추가 구성요소에 대한 문서를 참조하여 필요한 배포 라이센스를 얻었는지 확인해야 합니다. 배포된 어플리케이션에서 라이센스를 필요로 하는 모든 NI 제품 리스트는 NI 소프트웨어 배포 및 디버그 라이센스의 배포 라이센스 섹션 도움말 토픽을 참조하십시오.

다수의 생산 컴퓨터로 배포하는 경우 NI는 볼륨 라이센스를 제공하여 중앙 라이센스 서버를 통해 라이센스를 관리할 수 있도록 지원합니다. 볼륨 라이센스 옵션에 대한 자세한 정보는 소프트웨어용 볼륨 라이센스 프로그램 페이지를 참조하십시오.

테스트 시스템 배포에 포함해야 하는 일련의 파일을 정의했다면 메커니즘을 선택하여 생산 컴퓨터에 파일을 배포해야 합니다. 다음 섹션에서는 아래와 같은 배포 메커니즘에 대해 설명합니다.

• NI 패키지 기반 배포
• 설치 프로그램 기반 배포
• 네트워크 드라이브 배포

NI 패키지 기반 배포

NI 패키지는 배포에 속한 모든 파일을 단일 파일로 통합하는 메커니즘을 제공하며, 이를 통해 NI 패키지 관리자를 사용하여 생산 컴퓨터의 올바른 위치에 배포하고 추출할 수 있습니다. TestStand 배포 유틸리티를 사용하여 배포의 모든 파일을 포함하는 패키지를 만들 수 있습니다. 패키지 기반 배포의 경우 배포에 필요한 드라이버 및 구성요소는 패키지의 의존성으로 참조되지만, 패키지 자체에는 포함되지 않습니다. 

생산 컴퓨터에 패키지를 설치할 때 NI 패키지 관리자는 이러한 의존성을 감지하여 패키지를 다운로드하고 설치할 수 있도록 지원합니다. 또한, SystemLink 소프트웨어로 생성한 NI 패키지를 포함하여 조직 내에 NI 패키지의 저장소를 제공할 수 있습니다. SystemLink를 사용하여 패키지 기반 배포를 관리하는 방법에 대한 자세한 정보는 SystemLink로 시스템을 설정하고 소프트웨어를 배포하는 방법을 참조하십시오.

각 NI 패키지는 단일 구성요소이므로, 업데이트된 버전 번호로 새로운 패키지 버전을 생성하여 패키지 기반 배포를 업데이트할 수 있습니다. 새로운 버전이 테스트를 거치고 검증되면 기존 파일 전송 또는 SystemLink를 통해 생산 컴퓨터에 배포할 수 있게 됩니다.

설치 프로그램 기반 배포

파일을 배포하는 또 다른 방법은 배포의 필수 구성요소를 모두 갖춘 설치 프로그램을 생성하는 것입니다. 구성요소는 테스트 스테이션 컴퓨터에 복사해서 설치할 수 있습니다. 패키지와 달리 설치 프로그램은 설치 프로그램 내에 필요한 드라이버와 구성요소를 포함할 수 있습니다. 이러한 구성요소를 포함하면 디스크에서 설치 프로그램이 차지하는 용량이 훨씬 늘어나지만, 드라이버 및 런타임 엔진이 항상 포함되어 사용 가능해집니다. TestStand 배포 유틸리티를 사용하면 Microsoft 설치 프로그램 기술에 대한 직접적인 지식 없이도 TestStand 시스템용 설치 프로그램을 생성할 수 있습니다. TestStand 배포 유틸리티는 다음과 같은 기능을 제공합니다.

• <TestStand> 디렉토리 또는 <Desktop> 디렉토리와 같은 타겟 컴퓨터의 특정 디렉토리에 파일을 배포합니다.
• MAX (Measurement and Automation Explorer)에서 생성하는 하드웨어 설정을 가져옵니다.
• 드라이버 및 런타임을 포함한 추가 구성요소를 포함할 수 있습니다. 
•  기존 배포에 업데이트를 적용하기 위한 패치 설치 프로그램을 생성할 수 있습니다.

TestStand 배포 유틸리티에서 사용 가능한 기능에 대한 자세한 내용은 TestStand 도움말의 TestStand 배포 유틸리티로 설치 프로그램 만들기 토픽을 참조하십시오. 대부분의 경우 TestStand 배포 유틸리티는 사용자 정의된 배포 설치 프로그램을 만드는 데 필요한 기능을 제공합니다. 배포 설치 프로그램의 동작을 추가로 제어해야 하는 경우 타사 도구를 사용하여 설치 프로그램을 생성할 수 있습니다. 필요한 경우를 설명하는 자세한 정보는 타사 도구로 설치 프로그램 만들기를 참조하십시오.

TestStand 배포 유틸리티를 통해 업데이트된 구성요소만 포함하는 패치 설치 프로그램을 생성하여 기존 설치 프로그램에 업데이트를 적용할 수 있습니다. 패치 설치 프로그램 생성에 대한 자세한 정보는 배포 패치하기 도움말 토픽을 참조하십시오. 이 밖에도 테스트 코드, TestStand 구성요소, 드라이버 및 런타임 엔진을 위한 별도의 설치 프로그램을 두는 등 설치 프로그램을 여러 개 생성하여 배포를 모듈화하는 방안도 고려하십시오. 이런 접근 방식을 통해 변경 사항이 있는 설치 프로그램만 업데이트하고 배포할 수 있습니다.

설치 프로그램은 자동으로 올바른 위치에 파일을 배치하고 필요한 드라이버 및 런타임 엔진을 포함할 수 있으므로, 효과적인 설치 프로그램을 생성하면 시스템 배포가 간편해집니다. 그러나 설치 프로그램 기반 배포는 각 테스트 컴퓨터로 옮겨져 설치되어야 하기 때문에, 적은 수의 테스트 컴퓨터에서 사용되는 배포에 가장 적합합니다. 

네트워크 드라이브 배포

네트워크 드라이브 배포 아키텍처를 사용하면 설치 프로그램에 통합하지 않고도 네트워크 드라이브를 통해 파일을 테스트 스테이션 컴퓨터와 직접 공유할 수 있습니다. 네트워크 드라이브의 파일에 대한 접근은 소스 코드 제어 솔루션으로 관리 가능합니다. 이를 통해 테스트 개발자는 공유 저장소에서 파일을 생성하고 업데이트할 수 있게 됩니다. 테스트가 완료되면 이러한 파일은 생산 컴퓨터로 복사되거나 네트워크 위치에서 곧바로 사용됩니다. 

공유 저장소를 통해 개발, 준비, 생산 컴퓨터 간 파일을 공유하는 네트워크 드라이브 배포 전략

새로운 테스트 코드를 개발할 때는, 개발 중인 코드가 테스트 및 검증을 마칠 때까지, 배포된 시스템에서 절대 사용되지 않아야 합니다. 일반적으로 테스트 하드웨어에 접근할 수 있는 생산 컴퓨터는 준비 테스터로 지정되며, 테스트 시스템 시험판을 검증하고 테스트하는 데 사용됩니다. 준비 테스터에서 테스트 시스템이 검증되면 생산 컴퓨터에 배포할 수 있습니다.

배포된 코드를 검증하는 최선의 방법은 테스트 스테이션에 업데이트를 적용하는 빈도에 따라 달라집니다.

업데이트를 자주 해야 하는 경우, CI/CD (연속 통합 및 전달) 전략을 통해 코드를 적절하게 테스트하고 검증하면서 테스트 컴퓨터에서 최신 코드를 사용할 수 있습니다. CI/CD 전략을 사용하면 테스트 코드에 대한 업데이트를 만들고, 테스트 및 배포하는 절차의 대부분을 자동화하여 오버헤드를 최소한으로 줄일 수 있습니다. Jenkins와 같은 타사 도구를 사용하여 이러한 자동화 타입을 구현 가능합니다. 

환경이 보다 철저하게 제어되는 경우에는 일반적으로 검증 요구 사항이 매우 엄격하므로, 테스트 시스템 업데이트가 자주 진행되지 못합니다. 이러한 테스트 시스템에서는 개발자가 변경하고 새로운 기능을 테스트에 추가할 수 있는 별도의 저장소 또는 트렁크를 정의하십시오. 최신 테스트 시스템 버전이 완성되고 검증되면 개발자는 생산 컴퓨터에서 사용할 버전별 트렁크 분기를 생성하게 됩니다. 검증을 거친 코드가 변경되지 않도록 소스 코드 컨트롤 내에서 이 분기를 잠가두어야 합니다. 새로운 분기가 완성되고 검증되면 코드가 포함된 최신 버전의 분기를 생성하십시오.

테스트 코드를 배포하기 위해 생산 컴퓨터는 버전별 코드의 복사본을 획득합니다. 이 복사본은 변경되지 않도록 읽기 전용으로 유지되어야 합니다. 검증을 거친 파일이 더 확실히 변경되지 않도록 하려면 테스트 시퀀스에 코드를 추가하여 모든 파일의 체크섬을 검증하면 됩니다. 이 방법에 대한 자세한 정보는 TestStand 시스템의 확인 및 검증을 위한 모범 사례 문서를 참조하십시오.

네트워크 드라이브 배포로 드라이버 및 런타임 엔진 배포하기

네트워크 드라이브 기반 접근 방식을 택한 경우 별도의 메커니즘을 사용하여 테스트 컴퓨터에 필요한 드라이버와 런타임을 설치해야 합니다. 런타임 엔진 및 드라이버는 다음과 같은 메커니즘을 통해 배포할 수 있습니다.

• 필요한 소프트웨어가 포함된 설치 프로그램을 만듭니다. TestStand 배포 유틸리티는 런타임 엔진 및 드라이버가 포함된 설치 프로그램을 생성할 수 있습니다.
• 필요한 모든 드라이버 및 런타임이 설치된 시스템을 기반으로 시스템 이미지를 생성합니다.

최선의 방법은 시스템 업데이트 빈도에 따라 달라집니다. 대부분의 경우 여러 접근 방식을 조합하여 사용하게 됩니다. 다음은 드라이버 및 런타임 배포 전략을 선택하는 일반적인 시나리오입니다.

• 업데이트가 드문 시스템의 경우, 이미지 생성은 일반적으로 긍정적인 ROI를 갖습니다. 이미지를 업데이트할 필요 없이 테스트 시스템에 소규모 업데이트를 계속 구현할 수 있습니다.
• 보다 자주 업데이트되는 시스템의 경우, 필요한 드라이버 및 런타임을 포함한 테스트 시스템용 설치 프로그램을 작성하십시오.

테스트 시스템 파일에 대한 접근 전략

네트워크 드라이브 배포를 사용하면, 파일 스토리지를 관리하는 데 다음 중 하나의 방법을 활용할 수 있습니다.

• 네트워크 드라이브에서 직접 파일에 접근하십시오.
• 타사 도구를 사용하여 로컬 파일이 드라이브와 동기화되도록 네트워크 드라이브에서 로컬로 파일을 복사하십시오.
  
  

네트워크 드라이브에서 직접 파일에 접근하기

네트워크 드라이브에서 직접 파일에 접근하면 네트워크 드라이브의 파일을 업데이트할 때 모든 테스트 컴퓨터에 업데이트가 적용된다는 장점이 있습니다. 그러나 네트워크 드라이브에서 직접 파일에 접근한다는 것은 테스트 스테이션의 작동이 공유 드라이브의 가용성 및 네트워크 연결에 달려 있다는 뜻입니다. 둘 중 하나를 사용할 수 없는 경우, 제조 운영자가 테스트 스테이션에서 테스트 파일을 실행할 수 없게 되어, 생산 라인이 중단되는 결과가 초래될 수 있습니다. 따라서 IT 부서와 협력하여 공유 드라이브와 네트워크 모두에 대한 가동 시간 요구 사항을 충족할 수 있도록 해야 합니다. 예를 들어, 서버 중복성 기능을 사용하여 공유 드라이브의 가동 시간 요구 사항을 충족하는 방법도 있습니다. 

공유 드라이브를 사용하여 TestStand 설정 파일 및 구성요소를 저장하려면 TestStand 환경 기능을 사용해야 합니다. 이를 통해 TestStand 디렉토리의 위치를 지정할 수 있습니다. 이렇게 하려면, 해당 디렉토리의 네트워크 드라이브 위치를 포함한 환경 파일(tsenv)을 생성하면 됩니다. 환경 파일을 생성하고 사용하는 방법에 대한 자세한 내용은 TestStand 환경 도움말 토픽을 참조하십시오.

각 테스트 스테이션에 로컬로 파일 복사하기

모든 배포 파일의 로컬 복사본을 생성하도록 선택할 수도 있습니다. 이 방법에는 다음과 같은 장점이 있습니다.

• 테스트 스테이션에서 영구적인 네트워크 연결 없이 테스트를 실행할 수 있습니다.
• 테스트 시스템 파일의 로드 시간을 단축할 수 있습니다.

그러나 이 방법을 사용하면 추가적인 노력을 들여 모든 테스트 스테이션에서 파일을 복사해야 합니다. 또한, 테스트를 실행하기 전에 모든 테스트 시스템에 최신 파일이 있는지 확인해야 합니다.

추가 도구를 만들어 테스트 스테이션을 시작하고 최신 상태가 아닌 파일을 다운로드할 때마다 공유 드라이브와 일치하는 테스트 스테이션의 파일 버전을 자동으로 비교할 수 있습니다.

고급 NI TestStand 개발자에게 유용한 항목을 다루는 TestStand 고급 아키텍처 시리즈의 추가 문서를 보려면 클릭하십시오.