고성능 컴퓨팅 애플리케이션 테스트

Testing high-performance computing applications

대규모 병렬 슈퍼컴퓨터에서 실행되는 고성능 컴퓨팅 애플리케이션은 다중 스레드 다중 프로세스 모델을 사용하여 설계된 동시 프로그램들로 구성된다.신청서는 다양한 병렬화 정도를 가지는 다양한 구조(스레드, 로컬 프로세스, 분산 프로세스 등)로 구성될 수 있다.고성능 동시 프로그램은 순차 프로그램과 달리 설계 패턴, 모델 및 원칙이 유사하지만 일반적으로 비결정적 행동을 나타낸다.버그의 확률은 다양한 병렬 구조들 사이의 상호작용의 수에 따라 증가한다.레이스 조건, 데이터 레이스, 교착 상태, 누락된 신호 및 라이브 록은 일반적인 오류 유형이다.null

과제들

병렬 프로그램은 명시적 병렬과 암묵적 병렬의 두 가지 일반적인 범주로 나눌 수 있다.프로세스 생성, 통신 및 동기화를 위해 정의된 병렬 언어 구조를 사용하여 응용프로그램을 명시적으로 병렬로 만든다.도구를 사용하거나 컴파일러를 병렬로 병렬화하여 직렬 프로그램을 병렬로 변환하면 암묵적으로 병렬로 된다.두 범주 모두 똑같이 버그가 발생하기 쉽다.null

하이젠벅스

동시 애플리케이션은 기본 운영 체제에서 가능한 모든 스레드 스케줄에서 올바르게 실행되어야 한다.그러나 전통적인 시험 방법은 주로 하이젠벅스[1] 문제 때문에 거의 벌레를 감지하지 못한다.하이젠버그(Heisenbug)는 동기화 요청이나 지연 문과 같은 일부 구문을 추가하여 디버거를 통해 분리하고 프로브하려고 할 때 변경되거나 사라지는 오류다.null

비반복성

스케줄러의 예측불허 행태로 또 다른 이슈가 발생한다.시스템 부하 차이가 스케줄러 동작에 영향을 미친다.이러한 행동은 수동으로 변경할 수 없다.이러한 자유주의에 대항하기 위해서, 프로그램은 다양한 실행 환경에서 여러 번 실행되어야 한다.그래도 벌레가 번식할 수 있다는 보장은 없다.대부분의 경우 프로그램이 제대로 실행되고, 특정 조건이 일치해야 버그가 보인다.결과적으로, 동시 프로그램의 반복성이 오류를 감지하는 주요 장애 요인이 된다.예를 들어, 다음을 고려하십시오.null

공허하게 하다 나사산1(공허하게 하다 *t) {    mutex_lock(a);    mutex_lock(b);    // 일을 좀 하다    .    .    .    mutex_mutex(b);    mutex_mutex(a); } 
공허하게 하다 실2(공허하게 하다 *t) {    mutex_lock(b);    mutex_lock(a);    // 일을 좀 하다    .    .    .    mutex_mutex(a);    mutex_mutex(b); }

분명히, 이것은 교착상태를 유발하는 문제를 가지고 있다.그러나 일부 프로그램 실행에서 교착 상태를 유발할 수 있는 반면 다른 프로그램 실행에서는 성공적으로 실행될 수 있다.null

프로브 효과

프로브 효과는 동기화 문제에 직면한 병렬 프로그램에 지연 상태를 삽입할 때 병렬 프로그램에서 나타난다.이 효과는 하이젠버그와 마찬가지로 문제를 모호하게 할 수 있는 행동 변화를 변화시킨다.탐침 효과의 원인을 탐지하는 것은 병렬 응용 시험에서 큰 도전이다.
Probe 효과와 Heisenbugs의 주요 차이점은 시험 중 동시 응용 프로그램에 추가 지연 문 및/또는 동기화 요청이 추가될 때 Haisenbugs가 나타나는 반면, 개발자가 동기화가 불량한 동시 응용 프로그램에 지연 문을 추가할 때 프로브 효과가 나타난다.null

테스트 전략

순차적 프로그램과 동시적 프로그램의 차이는 시험 전략의 차이로 이어진다.순차적 프로그램에 대한 전략은 동시 적용에 적합하도록 수정할 수 있다.특화된 전략도 개발됐다.일반적으로 시험에는 시험 사례 설계와 프로그램이 예상 결과를 산출하는지 확인하는 것이 포함된다.따라서 응용프로그램을 실행하고 기능시험, 화이트박스, 블랙박스, 그레이박스시험 등의 시험방법에 의거하여 사양, 기능 등의 오류를 검출한다.[2]정적 분석은 데이터 흐름 분석, 제어 흐름 분석, 사이클로믹 복잡성, 스레드 이스케이프 분석, 정적 슬라이싱 분석 등의 방법을 사용하여 고성능 소프트웨어의 오류를 감지하는 데도 사용된다.기능 테스트 전에 정적 분석을 사용하면 시간을 절약할 수 있다.그것은 '오류란 무엇인가'를 감지할 수 있고 오류 소스를 찾을 수 있다.정적 분석 기법은 동기화 부족, 부적절한 동기화, 교착 상태 발생 예측 및 랑데부 요청의 대기 후 오류와 같은 문제를 탐지할 수 있다.null

세부사항:

결정론적 스케줄링/복제 가능한 테스트

일정 수립의 미지속성은 두 가지 출처를 가지고 있다.[1]null

1. 시간 슬라이싱
스케줄러는 동일한 시간 간격으로 컨텍스트를 전환한다.이 간격은 개별 프로세서, 메모리 캐시 계층 상태 및 시스템 로드의 속도에 따라 달라진다.같은 프로세서에서도 같은 부하에서는 시스템 클럭의 주파수의 사소한 변화로 간격이 약간 달라진다.
2. 페이지 결함
스케줄러는 페이지 오류가 발생하면 프로그램을 일시 중단하여 시스템이 페이지를 가져오는 동안 다른 스레드가 진행되도록 한다.페이지 결함의 발생은 실행 중인 다른 프로세스에 따라 결정되므로, 컨텍스트 스위치의 타이밍이 불확실해진다.

동시 프로그램을 반복할 수 있도록 외부 스케줄러를 사용한다.테스트 중인 프로그램은 이 스케줄러에 호출을 추가하기 위해 계측된다.이러한 호출은 모든 동기화 요청 전뿐만 아니라 각 스레드의 시작과 끝에서 이루어진다.이 스케줄러는 각 스레드와 연결된 세마포어를 유지하여 실행 스레드를 선택적으로 차단하여, 주어진 시간에 하나의 스레드만 실행 준비가 되어 있다.따라서 반복성을 달성하기 위해 병렬 비결정적 응용을 직렬 실행 시퀀스로 변환한다.스케줄러의 스케줄링 결정 횟수는 다음과 같다.

(N * K / P)*{(N + P)!}
어디에
N = 스레드 수
K = 잠재적 컨텍스트 스위치 지점
P = 사전 허용 컨텍스트 스위치의 예산

피드백 방향 테스트

결정론적 스케줄링을 사용하여 보다 정확한 결과를 얻기 위해 대체 접근방식을 선택할 수 있다.동시 프로그램에서 적절히 배치된 몇 가지 선책은 데이터 레이스와 관련된 버그를 감지할 수 있다.[1]벌레는 군집 안에서 발견된다.하나의 버그가 존재하면 동일한 코드 영역에서 더 많은 버그가 발생할 가능성이 높다.따라서 시험 프로세스의 각 통과는 버그가 있는 코드의 섹션을 식별한다.다음 패스는 이들 구간을 중심으로 스케줄러 호출을 추가해 보다 면밀하게 점검한다.문제가 있는 장소들을 다른 순서로 실행할 수 있게 하면 예상치 못한 행동이 드러날 수 있다.null

타이밍 관련 테스트

이 전략은 응용 프로그램이 Probe Effect에 취약하지 않도록 보장한다.Probe Effect를 유발하는 오류의 출처는 작업 생성 문제부터 동기화 및 통신 문제까지 다양할 수 있다.타이밍 관련 시험 요건:[3]

  • 지연 기간은 변경되어야 함
  • 지연 지점은 적절한 프로그램 위치를 포함해야 함
  • 프로브 효과를 유도하려면 지연 문을 삽입, 제거 또는 재배치해야 함

입력 데이터 세트당 테스트 사례 수:

nC1 + nC1 + … + nC1 = 2n -1
여기서 n = 총 동기화, 프로세스 생성 및 통신 호출 수입니다.null

이 방정식은 기하급수적인 순서를 가지고 있다.시험 사례의 수를 줄이기 위해 결정론적 실행 방법(DET) 또는 다중 실행 방법(Multiple Execution Method)을 사용한다.다음과 같은 다양한 문제를 처리해야 한다.

  • 지연실행
지연의 추가는 간단한 일이다.일반적인 수면() 문장은 지연을 삽입하는 데 사용할 수 있다.
  • 지연을 삽입할 위치 결정
삽입 위치를 지연점이라고 한다.타이밍 관련 테스트 사례의 목적은 동기화, 통신 및 스레드 생성 오류를 감지하는 것이므로, 지연 문장은 이들 문장의 바로 앞에 추가된다.

이점

  • 동기화 요청을 주문할 필요 없이 여러 프로세서에서 쉽게 구현
  • 동시성 그래프를 생성할 필요 없음
  • 고장 감지에 더 효과적
  • 정적 분석으로 인해 총 테스트 사례 수는 적지만 코드 적용 범위는 더 많다.

모든 두 경로 테스트

이 방법은 시험할 경로를 결정하기 위해 정의-사용 쌍의 개념을 적용한다.null

검증전략

소프트웨어 검증은 소프트웨어가 올바르게 작동하고 있으며 의도된 작업을 설계대로 수행하고 있음을 증명하는 과정이다.null

시험계산

알려진 결과를 생성하기 위해 시스템에 입력을 제공한다.이 입력-결과 쌍은 이전의 경험적 결과 및/또는 수동 계산에서 얻을 수 있다.[4]이는 모든 관련 모듈이 통합되어야만 수행할 수 있는 시스템 수준의 시험이다.더구나 벌레가 존재한다는 것만 보여준다.곤충의 수, 위치, 자연에 관한 상세한 정보를 제공하지 않는다.null

대칭 검정

이 테스트들은 주로 과학적 시뮬레이션에 사용된다.시뮬레이션의 결과는 종종 예측할 수 없다.이러한 시뮬레이션은 과학적 법칙을 설명하려고 하기 때문에 이론의 대칭은 시뮬레이션에 의해 존중되어야 한다.따라서 대칭선을 따라 입력 조건을 변화시킨 다음 얻은 결과와 외부에서 파생된 결과를 비교함으로써 버그의 존재를 탐지할 수 있다.[4]null

그림 1 : 데이터 분포

과학적 계산에서 대부분의 데이터는 시뮬레이션 조건의 중심 영역에 위치한다.따라서 실시간 실험 데이터로는 경계값 검사를 수행하기 어렵다.따라서 시뮬레이션의 중심(예를 들어 그림 1의 데이터 값 10)은 경계 조건을 효과적으로 테스트하기 위해 경계 중 하나로 이동된다.null

병렬 구현 테스트

병렬 구현 시험은 보통 메시지 전달과 같은 분산 메모리 프로그래밍 모델을 사용하는 애플리케이션에 사용된다.이러한 시험은 종종 프로세서의 정규 그리드를 사용하는 프로그램에 적용된다.[4][clarification needed]null

글로벌 합계

많은 병렬 데이터베이스는 분산 병렬 처리를 사용하여 쿼리를 실행한다.합계 등의 집계 함수를 실행하는 동안 다음과 같은 전략을 사용한다.[5]

  • 연결된 디스크 파티션에 있는 데이터를 사용하여 로컬에서 각 프로세서에서 동시에 부분 합계를 계산하십시오.
  • 최종 결과를 얻으려면 이 로컬 하위 결과를 추가하십시오.

최종 결과는 각 프로세서가 로컬 결과를 독립적으로 반올림할 때 일부 반올림 오류를 포함할 수 있다.한 가지 테스트는 그러한 오류가 발생하지 않는지 확인하는 것이다.이를 위해서는 총합이 분해에 독립적이라는 것을 보여야 한다.대체 합계 계획은 합산을 위해 모든 개별 값을 하나의 프로세서로 보내는 것이다.이 결과는 일관성을 보장하기 위해 분산된 결과와 비교할 수 있다.null

도구들

마이크로소프트 체스

이 도구는 결정론적 스케줄링을 사용하여 비결정성을 제거한다.이전에 실행된 스케줄 경로를 추적하고 새로운 스케줄 경로가 실행될 때마다 이를 보장한다.[1][clarification needed]null

참조

  1. ^ a b c d Thomas Ball; Sebastian Burckhardt; Peli de Halleux; Madanlal Musuvathi; Shaz Qadeer (May–June 2011). "Predictable and Progressive Testing of Multithreaded Code". IEEE Software. 28 (3): 75–83. doi:10.1109/MS.2010.64.
  2. ^ a b The Art of Software Testing, Second Edition. John Wiley and Sons. 2004. p. 256. ISBN 978-0-471-46912-4.
  3. ^ Cheer-Sun Yang; Lori L. Pollock (1997). "The Challenges in Automated Testing of Multithreaded Programs". Proceedings of the 14th International Conference on Testing Computer Software: 157–166. CiteSeerX 10.1.1.52.8791.
  4. ^ a b c Stephen Booth; David Henty (2004). "Verification strategies for high performance computing software". "Software Engineering for High Performance Computing System (HPCS) Applications" W3S Workshop - 26th International Conference on Software Engineering. Vol. 2004. pp. 24–26. doi:10.1049/ic:20040413. ISBN 0-86341-418-4.
  5. ^ Korth, Henry. Database System Concepts. McGraw-Hill.