페이퍼요약 - 소프트웨어 블랙 박스 장치 by He

제목: 소프트웨어 블랙 박스 장치: 소프트웨어 크래쉬 진단 및 사용 패턴 기반 유지보수 테스팅의 실용적 방법(Software Black Box Mechanism: A Pragmatic Method for Software Crash Diagnosis and Usage Maintenance Testing)

저자: Zhonglin He 외 3인, University of Ulster, 영국

문서유형: IEEE 컨퍼런스 페이퍼(총 8페이지), 1997

 

효과적인 유지보수 활동을 위해 비행기의 블랙 박스 장치의 원리를 소프트웨어에 적용한 방법을 제안

---

소프트웨어 유지보수에 블랙 박스 장치의 원리 적용

• 소프트웨어 유지보수 단계는 소프트웨어 생명 주기에서 가장 긴 시간을 차지한다. 일차 출시 시점의 소프트웨어 품질은 소프트웨어 개발 프로세스에서의 품질 활동에 의해 보장되지만 유지보수가 제대로 되지 않는 경우 소프트웨어 품질이 점차 저하된다.
• 소프트웨어 제품을 제대로 유지보수하려면 소프트웨어 유지보수 활동에 필요한 적절한 정보가 제공되어야 한다. 예를 들어, 소프트웨어 크래쉬(crashes, 비정상적 멈춤)가 발생한 경우 어떤 모듈에서 크래쉬가 발생했는지, 관련된 다른 모듈들은 어떤 것들인지, 크래쉬 발생 당시 어떤 순서로 관련된 모듈들이 호출되었는지 등의 정보를 알아야 한다. 또한 소프트웨어 유지보수에서 사용 패턴에 기반한 테스팅(software maintenance usage testing)을 수행하려면 소프트웨어가 주로 사용되는 방식을 반영한 테스트 케이스를 생성해야 하고, 이를 위해서는 소프트웨어의 실제 사용 패턴(software usage)에 대한 정보를 얻어야 한다.
• 항공 산업에서는 블랙 박스(the black box)를 장착하여 충돌 분석을 위한 관련 패러미터를 강제적으로 레코딩하는데, 본 논문은 소프트웨어에 이 원리를 적용한 방법을 제안한다. 즉, 소프트웨어 블랙 박스 장치를 소프트웨어의 각 버전에 포함하여 소프트웨어 유지보수 테스팅과 디버깅에 사용되는 데이터를 실시간으로 수집하고, 크래쉬나 기타 문제 발생 시 이 블랙 박스를 제조자(개발자)에게 제공하여 발생 문제에 대한 정보를 제공한다.
• 개발자는 블랙 박스 데이터를 분석하여 소프트웨어 크래쉬 진단(software crash diagnosis), 소프트웨어 사용 패턴 기반 유지보수 테스팅(software usage maintenance testing), 회귀 테스트 케이스 집합의 확장 등에 필요한 정보를 얻는다. 

소프트웨어 유지보수 테스팅(Software maintenance testing) 특성

• 소프트웨어 출시 시점에 가용한 단위(모듈)테스트 케이스, 통합 테스트 케이스, 시스템 테스트 케이스, 승인 테스트 케이스 들의 모음이 회귀 테스팅 케이스 집합이 된다. 시스템이 고객에게 전달된 이후로 변경이 된 경우에는 이 회귀 테스트 케이스 집합이 유용하게 활용되지만, 변경이 없는 상태에서 새로 발견된 문제점이나 크래쉬(system crashes)의 원인을 찾는 것이라면 기존 테스트 케이스들이 도움이 되지 않을 수도 있다.
• 소프트웨어 유지보수 테스팅은 다양한 상황에 맞게 적절한 접근 방법을 정해야 한다. 소프트웨어의 새로운 문제점(New software problems)이나 크래쉬(software crashes)는 소프트웨어의 사용 패턴(usage)과 관련된 문제점으로 여겨지므로 소프트웨어 사용 패턴 기반 테스팅(the software usage testing)을 적용하는 것이 바람직하다. 

소프트웨어 사용 패턴 기반 테스팅(Software usage testing)

• 클린룸 소프트웨어 공학 접근법(the Cleanroom Software Engineering Approach)에서 Harlan Mills에 의해 제안됨
• 클린룸 방법론(the Cleanroom methodology)에서는 시스템 레벨에서의 인증 테스트(the certification test)가 유일하게 수행되는 테스트이며, 이 때 독립적인 통계학적 사용 패턴 테스팅(the independent statistical usage testing)을 적용한다.
• 전통적인 커버리지 기반 테스팅(coverage testing)보다 사용 패턴 기반 테스팅(usage testing)이 더 효과적이라는 근거는 아래 설명된 아담의 연구 결과에 기반한다.
• 소프트웨어가 고객에게 인도된 이후 유지보수가 시작되고 바로 이 시기에 시스템의 실제 사용 패턴 정보를 수집할 수 있게 되므로, 소프트웨어 사용 패턴 기반 테스팅은 소프트웨어 유지보수 테스팅 방법으로 적용될 때 더 효과적이다.

아담의 연구(the Adam’s study)

운영 체제, 언어 컴파일러, 데이터베이스 시스템 등을 포함한 9개의 대규모 IBM 소프트웨어 제품에서 데이터 수집 하여 분석한 결과 두 가지 결론을 내림

1) 조사된 다양한 소프트웨어 제품들의 장애율 분포(the failure rate distributions)가 균일

2) 장애율의 평균고장시간(MTTF: mean time to failure)이 5000년부터 19개월 사이에 큰 차이가 나게 퍼져 있음. 평균고장시간(MTTF)을 나타낸 아래 그래프에서 보이듯이 33.29%의 에러는 5000년의 MTTF를 가지고 0.51%의 에러는 19개월의 MTTF을 가진다.

 

아담의 연구에 따르면 높은 장애율을 가지는 2%~5%의 에러만 제거하여도 소프트웨어 제품이 자신의 생명 주기 동안 무결점에 가까운 상태로 가동될 수 있다. 평균고장시간(MTTF)이 5000년이나 되는 매우 낮은 장애율(very low failure rate)을 가진 33.29%의 에러를 발견하기 위해 커버리지 테스팅을 하는 것 보다 주로 사용되는 부분에 집중한 사용 패턴 기반 테스팅(usage testing)을 통해 높은 장애율의 에러(the high failure rate errors)를 발견하고 수정하는 편이 시스템의 평균고장시간(MTTF)에 긍정적인 영향을 미칠 수 있다.

소프트웨어 유지보수 테스팅 유형

본 논문에서 관심을 가지는 소프트웨어 유지보수 테스팅 프로세스에는 아래와 같은 세 가지 활동이 있다. 

1) 변경 전 테스팅(Pre-modification testing): 변경이나 수정이 가해지기 이전에 새로운 문제점이나 크래쉬를 찾기 위해 수행. 변경 전 테스팅 활동으로 아래와 같은 것들이 있다.

• 크래쉬 테스팅(crash testing): 크래쉬가 발생한 모듈 위치를 파악하고 해당 크래쉬를 유발한 일련의 입력값(the sequence of input)들을 찾는다.
• 사용 패턴 기반 테스팅(Usage testing): 크래쉬는 아니지만 기타 다른 장애를 초래하는 문제점들을 찾는다. 

2) 변경 후 테스팅(Post-modification testing): 소프트웨어에 변경이나 수정이 가해진 후 제거하고자 하는 결함이 제대로 제거되었는지 변경/수정으로 인해 새로운 결함이 나타나지는 않는지 확인하기 위해 수행. 변경 후 테스팅에 관련된 테스팅 활동으로 아래와 같은 것들이 있다.

• 크래쉬 테스팅(crash testing): 소프트웨어 크래쉬를 유발하는 모든 결함이 제거되었는지 확인
• 사용 패턴 기반 테스팅(usage testing): 크래쉬 외의 다른 문제점들이 관련 소프트웨어 결함을 제거함으로써 모두 해결되었는지 확인
• 신규 기능성 테스팅(new functionality testing): 소프트웨어 추가된 신규 기능을 위한 테스트 케이스를 생성하고 이를 이용해 소프트웨어를 테스트 한다.
• 회귀 테스팅(regression testing): 지금까지 축적된 테스트 케이스의 전부 또는 일부를 사용해 변경이 소프트웨어의 다른 부분에 의도하지 않은 영향을 주지 않는 것을 확인한다.

3) 회귀 테스트 케이스 집합의 확장(Expanding the regression test set)

• 회귀 테스트 케이스 집합은 나중에 새롭게 생성된 테스트 케이스들을 포함하여 지속적으로 업데이트해 나가야 한다.
• Tct가 현재 크래쉬 테스트 케이스 집합, Tut가 현재 사용 패턴 기반 테스트 케이스 집합, Tnf가 현재 신규 기능 테스트 케이스 집합, RT(0)가 소프트웨어가 처음 출시되었을 때의 회귀테스트 케이스 집합, RT(i)가 현재 회귀 테스트 케이스 집합, RT(i+1)가 다음 회귀 테스트 케이스 집합 이라고 가정했을 때, 아래와 같은 식으로 표현할 수 있다.

RT(i+1)=RT(i) È Tct È Tut È Tnf

제안된 소프트웨어 블랙 박스 장치

• 소프트웨어 블랙 박스 장치는 고객 사이트에서 실시간으로 소프트웨어 사용 패턴과 크래쉬 데이터(software usage and crash data)를 수집하는 것을 가능하게 한다.

• 소프트웨어 블랙 박스 장치는 소프트웨어 블랙 박스 데이터 파일(the software black box files)과 블랙 박스 데이터 수집을 위한 소프트웨어 코드로 구성된다. 블랙 박스 데이터 파일은 사용자의 하드 디스크에 저장되며 블랙 박스 소프트웨어 코드는 블랙 박스 장치가 데이터를 수집할 대상인 고객의 소프트웨어에 통합된다.
• 소프트웨어 블랙 박스 데이터 파일은 시스템 파일(a system file), 모듈 파일(a module file), 크래쉬 파일(a crash file)의 세가지 유형이 있다. 시스템 파일은 소프트웨어 시스템 레벨의 일반적인 정보를 담고 있으며, 모듈 파일은 각 모듈에 관련된 모든 정보를 담고 있고, 크래쉬 파일은 발생한 모든 크래쉬에 대한 데이터(예, 크래쉬 발생에 관련된 모듈명, 크래쉬를 유발한 일련의 모듈 실행 순서 등)를 포함하고 있다. 이 세 파일의 데이터 구조가 아래 표와 같다(여기 제안된 데이터 레코드 외에도 개발자의 필요에 따라 여러 다른 정보 수집을 위한 레코드를 자유롭게 추가 가능)
• 소프트웨어 개발자(제조자)는 수집된 블랙 박스 데이터의 조회 및 분석을 지원하는 소프트웨어 도구를 활용한다. 또한 이런 도구들의 분석 결과를 테스트 케이스 생성 도구 같은 다른 소프트웨어 도구에서 자동으로 읽어 들여(importing) 활용하는 것도 가능하다.

 

시스템 파일	모듈 파일	크래쉬 파일
Struct black_box_system_file { //개발자가 해당 소프트웨어 버전을 생성한 날짜와 시간 date&time copy_date_and_time;   // 소프트웨어가 처음 사용된 날짜와 시간 date&time start_date_and_time;   //소프트웨어가 마지막 사용된 날짜와 시간 date& time last_date_and_time;   // 지난번에 크래쉬가 발생했는지 여부 bool crashed_system_execution;   //크래쉬 없이 소프트웨가 성공적으로 사용된 횟수 counter system_call_complete;   //크래쉬가 있었던 소프트웨어 사용 횟수 counter system_call_crashed;   //축적된 소프트웨어 실행 시간 date&time accumulated_execution_time;   //사용자의 소프트웨어 라이센스 기간(만기 여부 확인에 사용) date&time licensed_time; };	Struct black_box_module_file { //모듈 식별 필드 module_id module_identification;   //모듈이 마지막으로 호출된 시간 date&time module_call_time;   //모듈이 호출되었지만 호출한 모듈에 리턴 값을 주지 못했는지 여부 bool uncompleted_module_call;   //성공적인 호출 횟수 counter module_call_complete;   //비성공적인 호출 횟수 counter module_call_uncomplete;   //이 모듈에서 크래쉬가 발생한 횟수 counter module_call_crashed; };	Struct black_box_crash_file { //모듈 식별 필드 module_id module_identification;   //모듈이 마지막으로 호출된 시간 date&time module_call_time; };

블랙 박스 데이터 분석

• 소프트웨어 블랙 박스 데이터 분석은 문제가 보고되었을 때, 크래쉬가 발생되었을 때, 신규 버전 출시가 되기 전에 수행되거나 또는 일정 주기마다 정기적으로 수행될 수 있다.
• 분석을 위해 소프트웨어 개발자 측은 고객에게 블랙 박스 데이터 파일을 요청하고 수령한다. 수령한 블랙 박스 데이터 파일을 분석하여 효과적인 소프트웨어 유지보수 활동을 위한 소프트웨어 메트릭, 소프트웨어 시스템 크래쉬, 소프트웨어 사용 패턴 등에 대한 정보를 얻는다.
• 다양한 소프트웨어 측정 데이터(메트릭)이 소프트웨어 블랙 박스 데이터로부터 추출될 수 있는데, 대표적으로 아래와 같은 것들이 있다.

 

1) 소프트웨어 실행의 축적된 시간(Accumulated time of software execution: ATE): 소프트웨어가 사용자에 의해 사용된 시간이 얼마나 오래되었는지 블랙 박스의 시스템 파일을 분석하여 확인

2) 소프트웨어 크래쉬 발생 횟수(Number of software crashes: NSC): 모든 크래쉬 이력이 기록된 블랙 박스의 크래쉬 파일을 분석하여 건수 집계

3) 평균고장시간(The mean time to failure: MTTF): 소프트웨어 실행의 축적된 시간(ATE)과 발생한 크래쉬 횟수(NSC)를 알면 아래 식을 이용해 평균고장시간(MTTF)을 계산할 수 있다.

MTTF = ATE / NSC

4) 소프트웨어 제품 신뢰성(Software product reliability): 특정 가동 횟수(a number of runs) 동안에 장애 발생 없이 가동될 확률 또는 일정 시간 주기 동안에 장애 발생 없이 가동될 확률로 소프트웨어 제품 신뢰성을 정의

5) 소프트웨어 크래쉬에 관여한 모듈(Modules involved in the software crashes): 크래쉬 발생 전에 호출되어 크래쉬 때문에 호출한 모듈에 제대로 리턴 값을 주지 못한 모든 모듈을 지칭. 블랙 박스의 모듈 파일을 확인하여 알아낼 수 있다.

6) 크래쉬가 발생한 모듈(Modules in which the software crashes happened): 위와 마찬가지로 블랙 박스의 모듈 파일을 분석하여 소프트웨어 크래쉬가 발생된 모듈을 식별 가능하다.

7) 소프트웨어 크래쉬 이력(History of the software crashes): 크래쉬가 발생할 때마다 블랙 박스의 크래쉬 파일에 기록되므로, 이 파일을 분석하면 크래쉬 직전까지의 모듈 실행 순서(The sequence of module executions before a crash)라든지 어떻게 크래쉬가 발생하게 되었는지를 알 수 있다. 이런 분석을 통해 소프트웨어 결함 진단 및 수정에 도움이 되는 정보를 수집한다.

8) 소프트웨어 크래쉬 분포(The software crash distribution): 모든 크래쉬 파일을 조사하여 얻을 수 있는 크래쉬 분포는 유지보수 단계의 크래쉬 테스팅에서 크래쉬를 재현하고 위치를 식별하는 테스트 케이스를 생성하는 기초 자료가 된다.

9) 사용 패턴 분포(The software usage distribution): 모든 모듈 파일을 조사하여 얻을 수 있는 소프트웨어 사용 패턴 분포는 소프트웨어 사용 패턴 기반 유지보수 테스팅(Software usage maintenance testing)의 테스트 케이스를 생성하는 기초 자료가 된다.