페이퍼요약 - 분산 실시간 시스템 테스팅의 본질적 이슈 by SCHUTZ

제목: 분산 실시간 시스템 테스팅의 본질적 이슈(Fundamental Issues in Testing Distributed Real-Time Systems)

저자: WERNER SCHÜTZ, 프랑스

문서유형: 페이퍼(총 29페이지), 1994년

 

분산 하드리얼타임 시스템의 테스팅(특히 테스트 실행)에 있어 직면하는 이슈들을 6가지 측면에서 고찰한 자료

---

실시간 시스템(Real-Time Systems)

• 기능적 요구사항(functional requirements) 뿐만 아니라 데드라인(deadlines)으로 불리는 시간적 요구사항(temporal requirements)도 준수해야 하는 시스템. 그 정확성(correctness)이 컴퓨테이션의 논리적 결과뿐만 아니라 해당 결과가 생성되는 시점에도 의존한다.
• 실시간 시스템은 주변 환경과 밀접하게 연결되어 상호작용한다. 주변 환경의 자극(a stimulus)에 의해 컴퓨테이션(a computation)이 시작되며 데드라인 전에 완료되어야 한다.
• 실시간 데이터(Real-time data)는 시간 경과에 따라 무효화된다(invalidated). 만약 컴퓨테이션이 오래된(유효기간이 지난) 데이터를 기반으로 하는 경우 부정확한 결과가 생성될 수도 있다.
• 하드리얼타임시스템(A hard real-time system)은 명세된 데드라인 이내에 반드시 응답(responses)이 발생해야 하는 실시간 시스템으로 그렇지 못한 경우 심각한 결과가 초래된다.

분산 시스템(Distributed Systems)

• 네트워크로 상호연결된 통제 노드가 여러 장소에 존재. 각 노드는 CPU, 로컬 메모리, 네트워크 액세스, 로컬 클락(local clock), 기타 주변 장치로 구성된 자급자족의 컴퓨터
• 각 노드는 일련의 프로세스/작업을 타 노드와 동시에(concurrently) 실행시킬 수 있으며, 프로세서(또는 프로세스)들은 공통 임무를 달성하기 위해 커뮤니케이션 하거나 동기화(synchronize) 될 수 있음
• 분산 시스템은 중앙집중식(centralized) 순차(sequential) 시스템 보다 테스팅이 훨씬 어려우며 특히 아래와 같은 문제가 대두된다.
  - 복잡도(complexity) 증가
  - 관측(observation)과 모니터링(monitoring)의 어려움
  - 재현 불가능한(non-reproducible) 시스템 동작
  - 동기화된 글로벌 클락 결여로 인해 명확하게 글로벌 상태(global state)를 정의하기 어려움

이슈 1: 테스트 단계 구성(Organization)

• 복잡도가 높은 오늘날의 애플리케이션 개발은 체계적이고 일관성 있는 단계(phases)로 구성된 개발 방법론에 의해 이루어지며, 테스트 활동들도 명확한 단계로 구성되어 개발 방법론에 포함되어 있다.
• 실시간 시스템 개발 방법론인 DARTS(Design Approach for Real-Time Systems)에서는 시스템을 먼저 한 무리의 태스크(concurrent processes) 및 태스크간 인터페이스로 구조화하고, 그 다음 단계에서는 각각의 태스크를 모듈 및 모듈간 인터페이스로 분해한다. 결과적으로 각 모듈에 대한 ‘모듈(단위)테스트’ 단계가 존재하며, 이어서 각 태스크에 대한 ‘태스크통합테스트’ 단계가 나오고, 그 다음에는 ‘시스템통합테스트’ 단계가 이어진다. 이 테스트들은 대부분이 호스트(개발 시스템)에서 수행된다. 최종적으로는 ‘시스템테스트’가 수행되고(가능하면 독립적인 테스트 팀에 의해 수행됨), 그 후에는 사용자(고객)에 의한 ‘승인테스트’가 타겟 시스템에서 수행된다.
• 분산 시스템의 테스팅은 각 개별 프로세스의 기능적 요구사항뿐만 아니라 프로세스(또는 노드)의 인터액션(interaction)이나 동기화(synchronization)를 고려해야 하므로 한층 더 복잡함. 즉, 분산성(distributedness)에 의해 도입된 추가적인 복잡성이 기존 테스트 활동 구성에 영향을 미침(예, 필요한 테스트 단계의 수가 증가)

이슈 2: 관측성(Observability)

• 테스트에서는 시스템 동작의 정확성(correctness) 또는 적절성(appropriateness)을 판단해야만 하며 그러기 위해서는 각 테스트 실행 시 시스템이 ‘무엇’을 ‘어떻게’ 하는지를(심지어 ‘언제’ 하는지도) 관측(모니터) 해야만 한다. 또한 시스템뿐만 아니라 시스템의 환경도 관측가능성(observability)이 요구될 수 있는데, 그 이유는 시스템 동작의 정확성이 종종 주변 환경이 어떤 상태인지(또는 무슨 일이 일어나고 있는지)와 연관하여 평가되기 때문이다.
• 테스터가 관측하고자 하는 것으로 입력 값, 중간 값이나 변수(intermediate values or variables), 출력 값을 들 수 있는데, 그 중 입/출력 값의 관측은 대개의 경우 크게 문제가 되지 않는다(시간적 속성이 중요시 될 때는 관측이 문제가 됨). 중간 변수의 관측을 위해서는 원하는 변수의 값을 출력해주는 추가적인 출력문(auxiliary output statements)을 소스 코드에 삽입하거나 또는 사전 정의된 지점(breakpoints)에서 프로그램 실행을 중단시켜 사용자가 내부 변수를 검토할 수 있도록 허용하는 대화형 디버거(interactive debugger)를 이용하는 방법이 대표적이다.
• 하지만 여러 장소에 통제 노드가 위치하는 분산 시스템에서는 추가적인 출력문에 의한 코드 변경이 실행에 영향을 주어 시스템 동작을 크게 달라지게 만들 수 있고, 대화형 디버거도 통제 노드 간의 커뮤니케이션 지연이나 동기화된 글로벌 클락의 부재 등의 이유로 적용이 어려움. 즉, 관측으로 인해 시스템 동작이 달라지는 Probe Effect이 초래될 수 있는데, 이는 타이밍(timing)이나 동기화(synchronization)가 중요시되는 분산 실시간 시스템에서 특히 문제가 된다. 

이슈 3: 재현성(Reproducibility)

• 동일한 입력 데이터를 가지고 반복적으로 실행했을 때 프로그램이 동일한 결과를 생성하면 테스트 실행이 재현가능(reproducible)하다고 함. 에러를 수정하기 위해서 그리고 회귀 테스팅(소프트웨어가 변경된 후에 기 실행된 테스트를 재실행)을 위해서 꼭 필요한 속성
• 비실시간 순차 프로그램에서 재현성(Reproducibility)은 난수생성기(a random number generator) 등이 사용될 때를 제외하고는 거의 문제가 되지 않으나 분산/실시간 시스템에서는 어려운 문제가 됨
• 분산 시스템에서는 하드웨어, 소프트웨어, 운영체제에 존재하는 불확정성(nondeterminism) 때문에 그 동작이 재현불가능(non-reproducible) 할 수 있는데, 대표적인 불확정성으로 아래를 들 수 있다.
  - 경쟁 상황(race condition)에 놓일 수 있는 동시 활동(concurrent activities)들의 결과값이 CPU 로드, 네트워크 트래픽, 커뮤니케이션 프로토콜의 불확정성, 탐사 효과(Probe Effect) 유/무 등의 여러 요인에 영향을 받아 결정됨. 이 요인들의 영향을 사전에 아는 것이 불가능하므로 시스템의 동작이 예측가능(predictable) 하지 못함
  - 시스템 동작을 결정하게 되는 이벤트의 타입과 타이밍에 대한 충분한 사전 지식이 결여됨(예, 동기화 이벤트, 타임 액세스, 비동기 인터럽트)
• 시스템의 시간적 동작(temporal behavior)을 추가적으로 준수하여 재현해야 하는 실시간 시스템에서는 특정 작업 시퀀스(또는 이벤트 시퀀스)를 재생하는 것뿐만 아니라 해당 시퀀스의 발생 시간(the time of occurrence)의 재생도 필수적이다. 즉, 실시간 시스템 재현을 위해서는 더 많은 정보가 기록되고 시뮬레이션 되어야만 한다(Replay에 기록된 시간 정보를 사용)

이슈 4: 호스트/타겟 접근법(Host/Target Approach)

• 실시간 시스템이 임베디드 시스템으로 전개되는 경우가 많아서(즉, 더 큰 시스템이나 기계의 내부에 설치되어 통제 역할을 담당) 실시간 소프트웨어 개발에는 두 가지 타입의 컴퓨터 시스템(호스트 시스템과 타겟 시스템)이 관여하게 된다.
• 호스트 시스템(host system)은 실시간 소프트웨어를 개발 및 구축하는데 사용되는 전통적인 컴퓨터 시스템으로 표준 운영 체제, (그래픽 기능을 가진) 터미널을 통한 사용자 인터페이스, 타겟 시스템에서 실행 가능한 머신 코드를 생성하는 크로스 컴파일러(또는 크로스 어셈블러)를 포함한다. 호스트 시스템 환경에서는 원하는 소프트웨어 개발 및 테스팅 도구 활용이 가능하다.
• 타겟 시스템(target system)은 실시간 소프트웨어가 최종적으로 올라가 실행되는 시스템으로 종종 공간, 무게, 비용의 제약을 가지므로 시스템 리소스를 최대한 효율적으로 사용하도록 맞춤 제작된다. 따라서 소프트웨어 개발 도구가 지원되지 않으며, 운영 체제는 실시간 작업을 적시에 수행하는데 필요한 가장 필수적인 기능만을 제공한다. 타겟 시스템은 종종 아날로그-디지털 전환기 같은 특별 I/O 기기를 통한 입출력(I/O)을 지원한다.
• 호스트 시스템과 타겟 시스템 모두에서 테스트가 수행되어야 하므로, 어떤 테스트 단계를 어떤 시스템 상에서 수행할지 그리고 각 테스트 단계에서 소프트웨어의 어떤 측면이 테스트 되는지를 명확히 정의해야 한다. 일반적으로 아래와 같은 테스팅 구분이 이루어진다.
  - (기능적) 단위 테스팅과 일차적인 통합 테스팅은 호스트 시스템 상에서 수행 됨
  - 통합 테스트를 완성하는 것과 시스템 테스팅 수행은 타겟 시스템 상에서 이루어짐. 이 단계에서는 소프트웨어의 논리적 정확성뿐만 아니라 성능과 타이밍 특성을 테스트하는 것이 가능함
• 성능 테스트와 시스템의 시간적 동작을 평가하기 위한 테스트는 타겟 시스템 상에서 수행되는 경우에 의미 있는 결과가 산출되지만, 타겟 시스템 상에서는 가용한 테스트 지원이 거의 없으며 있다 하더라도 테스터와 시스템 간의 상호작용이 대개 머신 언어 수준에서 지원되므로 테스트 생산성에 심각한 영향을 준다.

 

이슈 5: 환경 시뮬레이션(Environment Simulation)

• 타겟 시스템 테스트를 위해 널리 사용되는 도구로 시스템의 환경 모델을 구현한 환경 시뮬레이터(Environment Simulator)가 있음
• 환경 시뮬레이터는 테스트 런 동안에 시스템에게 입력을 제공하고 시스템으로부터 나온 출력을 받아들임으로써 실시간 시스템의 (물리적) 환경의 동작을 흉내 내는 기기 또는 시스템이다. 환경 시뮬레이터는 받아들인 출력 데이터를 기준으로 하여 새로운 입력 데이터 집합을 계산해 낸다(즉, 온라인 테스트 데이터 생성).
• 대개의 경우 안전이나 비용 문제 때문에 테스팅 동안에 실 환경을 사용하는 것이 불가능하며 대신 시뮬레이션된 환경이 사용됨. 시뮬레이션 환경은 실 세상에서는 자주 나타나지 않는 드문 이벤트 상황(예, 화학 프로세스의 비상 처리)에서의 시스템 동작을 테스트 하는 것을 가능하게 하고, 테스터가 환경에 대한 더 많은 통제를 할 수 있어 테스트 실행과 관측을 용이하게 함. 하지만 환경 시뮬레이터의 동작이 실 환경(the real environment)의 동작과 최대한 동일해야만 의도한 테스트 목표를 달성 할 수 있다.
• 환경 시뮬레이터는 실시간 시스템 테스팅을 위한 유용한 도구이지만 애플리케이션에 한정된 도구이다 보니 개별 프로젝트 기준으로 매번 개발되어야 하는 것이 어려운 점이다. 즉, 도구 개발이 개발 방법론에 포함되어 있어야만 하고, 어떤 단계(들)에서 환경 시뮬레이터가 사용될지 결정해야 하므로 테스트 구성에도 영향을 준다.

이슈 6: 대표성(Representativity) 또는 테스트 커버리지(Test Coverage)

• 테스트 단계 중에 최소한 부분적으로라도 대표성 있는(현실적인) 입력 데이터로 시스템이 테스트되어야 함(예, 고객 승인테스트에서 운영 프로파일을 기반으로 입력 데이터를 뽑아냄)
• 대부분의 경우 완전한 테스팅(exhaustive testing)이 불가능하므로 예상되는 실 세계 시나리오(real-world scenarios) 중 얼마나 많은 것이 테스트 시나리오로 커버되었는지를 측정하는 테스트 커버리지(Test Coverage) 개념을 도입
• 위에서 언급된 환경 시뮬레이션(Environment Simulation)의 원칙도 대표성을 가진 테스트 런(test runs)을 달성하는데 부분적으로 도움이 됨. 즉, 실시간 시스템과 그 환경 간의 밀접한 연결 관계 때문에 오프라인 테스트 데이터 생성(테스트 실행 전에 많은 양의 입력 데이터를 한꺼번에 준비하는 방식)으로는 현실적인 테스트 입력 시퀀스(realistic test input sequences) 생성에 한계가 있음. 환경 시뮬레이터는 온라인 테스트 데이터 생성을 제공하므로(테스트 실행에 따라 시스템으로부터 나온 결과를 받아 새로운 입력 데이터를 생성) 비용 효과적으로 테스트 커버리지를 개선하는데 기여할 수 있음