17. 소프트웨어 시험

 

DO-178B 이전에는 품질이 시험을 통해서 개선될 수 있다는 암묵적인 철학을 가지고 있었다. 그것은 실제로 감탄할 만한 철학이다. 하지만 약간의 흰머리가 있는 경험많은 항공전자 엔지니어에게 물어보면 “시험은 평가할 수 있고 간접적으로 품질을 개선할 수는 있지만 품질 자체를 개선하지는 않는다.”라는 말을 듣게 될 것이다. 그리고 그것은 DO-178B의 핵심이다. 시험(또한 “검증”으로 불리는)은 각 시스템의 “정확성”을 평가하는 정확성 프로세스의 일부이고 그 평가는 요구사항, 설계 그리고 구현을 개선할 수 있다.

역주) 역자에게는 시험이 품질을 높일 수 없다는 말이 처음에는 잘 이해가 되지 않았다. 시험을 해서 버그를 잡게 되면 그 만큼 품질이 좋아지는 게 아닌가? 하지만 이제는 그 의미를 좀 구분할 수 있을 것 같다. 버그를 잡는 것은 현재 구현된 품질 수준에서 잘못된 부분들을 찾아냄으로써 현재 수준의 최대치를 만들어 주는 것이라면 품질을 개선한다는 것은 현재의 품질 수준을 어떤 식으로든 더 높인다는 의미이다. 이는 버그를 잡는다고 얻을 수 있는 부분이 아니다. 품질을 개선한다는 것은 시험과는 또 다른 부분이라고 할 수 있다. 이런 관점에서 저자의 말을 이해하도록 하자.

 

다음 페이지의 테이블에서 보여지는 것처럼 네 가지 시험 카테고리가 있다. DO-178B는 당신이 이 정도 수준으로 모든 검증 시험을 수행하는 것 그리고 완전하게 통합된 소프트웨어 레벨에서 시험을 함으로써 코드를 완벽하게 커버하는 것을 선호한다. 우리가 그것을 할 수 있다면 이상적이다. 우리는 레벨 A, B 그리고 C에 대해서 그것을 수행한 것을 본적이 없다. 레벨 D에 대해서는 그것을 수행할 기회가 있다. 그 이유는 레벨 D에 대해서는 당신이 보여줄 책임이 있는 모든 것은 시스템 요구사항과 상위레벨 요구사항과 관련된 소프트웨어 요구사항을 가지고 있고 이들 기능을 실행하는 시험을 수행했다는 것을 보여주는 것이다. 당신은 레벨 D에서의 구조적 커버리지 분석은 말할 것도 없고 강건성 시험을 수행할 필요가 없다.

 

레벨 D에서는 하위레벨 요구사항에 대한 시험이나 구조적 커버리지를 보여줄 필요가 없다. 더 상위 레벨의 위험성과 비교해서 레벨 D에 대해서는 간단한 시험을 요구한다는 점이 레벨 D와 C 사이에 큰 갭이 존재하는 이유이다. 심지어 레벨 A에 대해서는 DO-178B는 모든 시험이 최고의 레벨로 수행되기를 기대한다.

 

“박스를 개봉”하지 않고서 단지 관련된 출력을 체크하기 위해서 입력을 실행하는 것으로 검증의 모든 특성을 달성할 수 있을까? 보통 전체 구조에 대해서 에러를 확인할 수 있는 30 ~ 40% 정도가 설계되고 개발된 상태라면 코드의 구조를 어떻게 보여줄 수 있을까? 시스템 레벨에서는 에러를 쉽게 잡아낼 수 없고 따라서 좀 더 하위레벨 시험이 되어야 한다.

 

소프트웨어 시험   시험 카테고리:   1. 기능 시험: 모든 요구사항 2. 정상범위 시험: “화창한 날” 조건 3. 강건성 시험: “비오는 날” 조건 4. 구조적 커버리지: 모든 코드를 커버     시험의 네 가지 카테고리   하나의 블랙박스(기능시험) 세 개의 화이트박스 시험 사이의 중복에 신경쓸 것 상대적인 크기에 유의: 비율

 

기능 시험은 “박스”의 기능과 소프트웨어 대부분의 기능을 시험한다.

 

다음 레벨은 당신이 설계한 기능인 정상범위 시험이다. 일부는 실제로 소프트웨어를 실행한다. 즉 소프트웨어 레벨 시험에서 수행하는 것이다. 시뮬레이션 혹은 알고리즘으로 당신이 원하는 대로 동작하는지를 확인할 수도 있다. 정상적인 운용 조건에서 의도된 대로 동작하는가?

 

다음 레벨은 강건성 시험인데 실제 수행 중에 거의 일어나지는 않지만 혹시 발생할 지 모르는 시나리오가 만들어진다. 이는 소프트웨어가 망가지거나 비 정상적인 조건하에서 소프트웨어가 어떻게 동작하는지를 결정하는 “비오는 날”의 조건이다. “정상적인 구동 조건하에서는 발생하지 않을 것들”이라고 할 수 있는 에러를 주입하는 것을 포함한다. 그래서 예를 들면 여러 범위의 값들, 영역을 벗어나는 값들, 경계값들 그리고 스트레스 시험을 수행할 에러들을 주입한다. 그리고 코드를 따라가면서 코드의 일부를 캡처하고 기능, 정상 그리고 강건성 시험을 수행하면서 기능의 구조를 캡처하게 된다.

역주) DO-178에서의 시험은 위의 네 가지가 핵심이다. 아마도 마지막의 구조적 커버리지를 빼고는 이름만으로도 무엇을 말하는 지 이해가 될 것이다. 결론적으로 위의 네 가지 시험 각각의 결과가 제출되어야 한다. 따라서 각각의 시험 케이스와 결과가 문서 혹은 데이터로 나와야 한다는 말이다. 일반적으로 알고 있는 시험과는 약간 개념이 다른 부분들이 있으므로 실제 진행할 때에는 각각의 시험이 정확하게 무엇을 요구하는 지 파악하는 것이 중요하다. (참고 포스팅: 12. DO-178과 소프트웨어 검증 프로세스 (Section 6.0))

 

이들 시험이 잘 수행된다면 당신은 복잡도에 따라서 70 ~ 80% 정도의 소프트웨어 커버리지를 쉽게 얻을 수 있어야 한다. 만약 제대로 된 요구사항이 작성되지 않았거나 혹은 하위레벨 기능 설명과 설계가 적절하지 않다면 당신은 좋은 시험 혹은 커버리지를 가질 수 없을 것이고 따라서 당신은 다시 되돌아가서 추가적인 활동들을 수행함으로써 요구사항과 기능 시험을 개선해야 할 것이다. 더 나아가 당신이 레벨 A, B 그리고 C에 대해서 코드 분석과 검증이라는 지루한 반복의 구조적 커버리지 시험을 수행해야 하기 때문에 작업은 더 비싼 비용이 들게 된다. 따라서 DO-178B는 당신이 모의할 수 있고 실제 환경 조건에서 검증하게 되는 상위레벨에서 검증 시험을 수행하면서도 가능한 더 많은 커버리지를 얻기를 원한다.

 

구조적 커버리지는 당신이 요구사항을 얼마나 잘 썼고 그것을 시험해 왔는지에 대한 분석이다. 그 이상 다른 것은 없다. 당신이 ”나는 단지 소프트웨어의 100% 커버리지를 달성했고 시스템 레벨에서 모든 시험을 수행했다.”라고 말하는 지점이 검증과 시험의 진출 기준이다. 그것은 이상적인 시나리오다.

 

이제 당신은 멈출 수 있다. 사실상 무수히 많은 조건들이 있고 표면적으로는 당신이 영원히 시험할 수도 있다는 점 때문에 아직 남은 조건들의 추가적인 시험을 진행할 필요는 없다.

역주) 다시 한번 말하자면 소스코드에 대한 커버리지 시험은 요구사항 기반으로 시험을 해서 100%를 달성하는 것이 목표이다. 레벨 A, B, C에 따라서 100%에 대한 대상이 일부 다르긴 하지만 기본적인 형태는 동일하다. 따라서 일단 100%를 달성하게 되면 추가적인 시험을 할 필요가 없다. 아마도 추가적인 시험에는 단위시험을 생각할 수 있는데 앞서 말한 대로 DO-178에서는 단위시험에 대해서는 신경쓰지 않는다. 그런데 현실적으로 커버리지 100%를 달성하는 게 쉽지 않다. 더구나 레벨 A인 경우에는 정말 어렵다. 이론적으로는 100%를 채우지 못하는 일부분에 대해서는 분석, 검토 등의 리포트로 대신할 수 있다. 물론 DER이 인정할 수 있는 내용이어야 한다. (참고 포스팅: 4. DO-178과 커버리지 분석(Coverage Analysis))

 

이전 버전의 문서인 DO-178A는 이런 수준의 시험을 강조하지 않았다. “기능 시험과 정상 범위 그리고 강건성 시험을 수행하라. 그런 후 이전에 시험되지 않은 구조를 시험하기 위해 추가적인 시험을 통해서 구조적 커버리지 분석을 수행하라.”라고 말했다. 이것은 당신이 두 세트의 시험을 가졌다는 것을 의미했다. 단위시험은 당신이 소프트웨어 수행을 주관하기 때문에 모든 구조적 커버리지를 만족할 수 있다. 많은 기업들이 비용이 적게 드는 구조적 커버리지 시험 “업체”로 아웃소싱을 통해서 분리된 구조적 커버리지 시험에 대한 유혹을 받았고 실제로 그렇게 해왔다. 하지만 이런 시험 형태는 문제점을 거의 발견하지 못하며 따라서 그 코드는 실제로 DO-178B에서 원하는 것처럼 “커버하지” 못한다. 코드에 대한 분리된 구조적 커버리지 시험은 실제 환경에 대해서 왜 그것이 거기에 있어야 하는지에 대해서는 거의 신경 쓰지 않고 단지 코드가 작성된 대로 실행한다.

 

DO-178B의 구조적 커버리지는 시험이 아니라 분석이다. 일단 다른 시험들이 얼마나 잘 만들어 졌는지를 당신이 분석했다면 당신은 커버되지 않은 부분들을 추가하고 채운 것이다. 그리고 당신의 모든 시험 커버리지 리포트를 분석했기 때문에 구조적 커버리지 시험을 하나도 수행하지 않는 것이 당신의 핵심 목표이고 당신은 이미 완료한 것이다. “구조적 커버리지”라는 것을 듣게 되더라도 걱정하지 마라. 왜냐하면 언제 시험을 멈추어야 하는지를 안다는 것은 당신에게 이득이 되기 때문이다. 당신은 진출 기준을 획득한 것이다.

 

이런 질문을 받은 적이 있다. “저는 생각할 수 있는 모든 기능 시험을 작성했습니다. 그리고 강건성 시험을 만들기 위해 데이터 기반으로 시나리오를 만들었구요. 그것은 제가 소프트웨어 혹은 시스템이 그것을 다룰 수 있는지를 보기 위해 정상적인 운영 범위 밖에서 코드를 실행하려고 한다는 의미입니다. 그런데도 저는 여전히 100%를 달성하지 못했습니다. 저는 어찌할 바를 모르겠네요. 무엇을 빼먹은 거죠?”

 

먼저, 당신의 요구사항으로 돌아가라. 당신이 100% 혹은 그와 근접한 결과를 얻지 못한 이유는 당신이 시험 케이스를 작성하기에 좋은 요구사항을 가지지 않았기 때문이다. 함수로 연결되는 더 상세한 요구사항을 작성하고 모든 하위레벨 요구사항이 존재하는지, 추적가능한지, 검증가능한지를 확인하라. 코드가 거기 있어야 하고 그것을 포함하는 요구사항이 있어야 한다. 따라서 그 함수에 기반한 더 많은 요구사항 기반 시험을 추가함으로써 당신의 부족한 부분을 채워라.

역주) “당신이 100% 혹은 그와 근접한 결과를 얻지 못한 이유는 당신이 시험 케이스를 작성하기에 좋은 요구사항을 가지지 않았기 때문이다.”라는 말에 주목하자. 이 말의 의미는 요구사항이 제대로 작성되지 않아서 시험 케이스가 누락되거나 잘못 작성되었다는 뜻이다. 이 경우 요구사항을 추가하거나 수정해야 한다. 그런 후 다시 시험 케이스를 작성하고 시험을 수행해서 100%가 나오는 지를 다시 확인해야 한다. 사실 실전에서는 이런 과정이 반복된다. 한 번에 모든 것이 완벽하게 될 수 없다는 점은 여러분이 더 잘 알고 있을 것이다.

 

강건성 시험은 얼마나 많이 해야 충분할까? 여기에는 적절한 기준이 없다. 강건성 시험은 주로 요구사항과 구현(코드) 모두에 의해서 결정되기 때문에 언제나 그래왔던 것처럼 불행히도 DO-178B는 다소 모호하다. 만약 DO-178B가 모든 것을 망라하는 문서였다면 그것은 모든 타입의 시스템, 설계 그리고 구현을 기술해야 할 것이고 그러면 수 천 페이지의 길이가 되었을 것이다. 그 최종 결과는 아무도 그것을 따르지 않는 것은 말할 것도 없고 그 누구도 읽어보지조차 않을 것이다. 따라서 DO-178B는 이러한 주관적인 이슈들에는 다소 모호해야 하며 강건성 시험이 그 중 하나이다.

역주) DO-178의 이러한 모호함이 금방 와 닿지는 않을 것이다. 무책임한 변명같이도 들릴 지 모르겠다. 하지만 DO-178을 계속 접하다 보면 어느 순간 이 모호함이 선명하게 이해되는 지점이 생길 것이다. 역자의 경험으로는 그렇다. 다른 분들도 같은 경험을 할 수 있을 것이다.

 

적절한 강건성 시험은 소프트웨어를 “파괴하는” 시험을 구분하는 것으로 시작하며 이런 것들이 강건성 시험이다. 이런 식으로 당신은 FAA의 감사자에게 당신이 실제로 강건성 시험을 만들었고 그 결과를 가지고 있다는 것을 증명할 수 있다.

 

두 번째로 10% 혹은 30%와 같은 식으로 강건성 시험을 해야 하는 것은 아니다. 당신은 그저 요구사항과 코드에 적절하게만 그것들을 기술하면 된다. 따라서 잠재적 경계값, 에러값, 최소/최대값 등과 같은 모든 요구사항이 기술되었는지 확인하라. 그런 다음 소스코드를 리뷰하고 더 나아가서는 그런 시험을 구분하라. 이러한 것들이 당신의 강건성 시험이다. “이 시스템에서는 당신은 30개의 강건성 시험, 50개의 기능 시험 그리고 25개의 정상 동작 조건의 시험을 해야 한다.”와 같은 규정은 없다. 서로 다른 많은 시스템과 소프트웨어로 보자면 그런 식의 언급은 불가능한 것이다. 당신의 시스템내에서 어떤 요구사항과 모듈은 많은 강건성 시험을 가질 것이고 반면에 다른 것들은 몇 개 없을 수도 있다는 점이 실질적으로 확인된다. 그리고 이들은 모두 당신의 단일 시스템 내에 있다. 블랙 박스 시험과 화이트 박스 시험은 정상범위 시험, 기능 시험, 그리고 강건성 시험과 관련되는 데 그 중에서도 기능 시험은 중복되는 경향이 있다. 이들 영역에는 일정 분량의 반복과 중복이 있을 것이다. 중복은 좋은 것이다. 당신의 DER은 완전함을 보장하기위해서 그런 중복을 리뷰할 것이다. 중복이 없다면 그것은 확실히 당신이 어떤 시험을 누락하고 있는 것이다.

역주) 여기서 말하는 중복에 대해서는 앞서 살펴본 네 가지 시험에 대한 그림에서 이미 확인한 바가 있다.

 

소프트웨어의 일부는 그런 시험으로 동작하지 않을 것이다. 그런 부분들은 분석될 수 있고 그런 후 추가적인 구조적 커버리지 시험을 더할 수 있다. 그것은 하나의 단위 시험과 같은 것이고 단지 그 코드를 실행하려고 하는 것이지만 독립적으로 개발된다.

 

블랙박스 시험과 화이트박스 시험의 차이점은 무엇인가? 간단히 말하자면 블랙박스 시험은 당신이 박스 내부를 볼 수 없을 때이다. 입력과 출력은 알지만 내부의 활동은 알지 못한다.

 

요구사항은 박스가 무엇을 수행해야 하는지를 명시하기 때문에 당신은 출력이 무엇인지를 안다. 화이트박스 시험은 구현을 리뷰하고 입력을 선택하며 이들 입력에 대한 피드백을 확인하는 것이다. 혹은 박스의 실제 동작 내에서 점퍼를 추가하거나 에러가 없는 모의 데이터를 입력할 수 있다.

 

입력의 조합으로 쉽게 접근할 수 없는 함수로 들어갈 수도 있다. 하지만 하나의 함수 혹은 모듈셋으로 들어갈 수 있고 생성되어야 하는 입력을 강제하기도 하는 등 그런 형태로 소프트웨어 함수를 실행한다. 우리는 이런 접근방식을 좋아하지는 않으며 최소화하고 싶지만 때로는 다른 방법이 없다.

역주) 블랙박스 시험과 화이트박스 시험에 대해서는 흔히들 들어 봤을 것이다. 용어만으로도 대충 의미도 파악이 될 것이다. DO-178에서 이 두가지를 특별히 구분해서 신경 쓰는 것은 아니고 결국은 커버리지 100%를 달성하기 위해서 필요한 시험을 적용하는 것이다. 일반적으로 기능시험을 블랙박스 시험이라고 하며 단위시험과 같이 소스 내부를 직접 손대야 하는 경우는 화이트박스 시험이라고 한다. 일반적으로 블랙박스 시험이 우선적으로 진행되고 그것만으로 만족하지 못하는 경우 화이트박스 시험까지 진행하게 된다.

 

블랙박스 vs 화이트박스   블랙박스 구현은 신경쓰지 않음 “박스 내부를 볼 수” 없음 요구사항으로부터 시험 케이스가 나옴     화이트박스 구현에 의존적 구현을 리뷰하고 사용해야 함 “박스 내부를 봐야”만 함 구현으로부터 시험 케이스가 나옴

 

우리는 상위레벨 스펙, 소프트웨어 요구사항, 하위레벨 및 설계 데이터로부터 소프트웨어를 작성한다. 화이트박스 시험이 커버하는 하위레벨 기능은 소프트웨어가 상위레벨 스펙으로부터 개발되었을 때 명확하지 않았던 영역이다. 그것들 역시 코드를 작성하고 시험할 필요가 있다. 그것은 많은 방식 중 일대일 상관관계이다.

 

일부 요구사항은 하드웨어/소프트웨어 통합 시험 플랫폼에서 시험될 수 있다. 그것은 박스상에서 시험될 수 있다는 의미이고 당신의 타겟 플랫폼을 상징한다. 그것이 실제 박스일 필요는 없다. 마더보드 혹은 에뮬레이터가 될 수 있다. 하지만 하드웨어의 상호작용이 가능해야 한다.

 

그 시험은 하드웨어의 기능에 달려있다. 당신은 비타겟 환경(호스트, 시뮬레이터 등)에서 그것을 시뮬레이션하고는 “그것은 같은 방식으로 동작할 것입니다.”라고 말할 수 없다. 타이밍이 다를 수 있다. 따라서 하드웨어/소프트웨어 통합 시험이 중요하다. 소프트웨어 통합 시험은 상호간에 의존하는 소프트웨어 기능을 시험하는 것이지만 타겟 플랫폼에서 수행할 필요는 없다. 그래서 그것은 소프트웨어/소프트웨어 통합이다.

 

하위레벨 요구사항 시험은 일반적으로 설계 혹은 아키텍처에 대한 고려사항에 특화된 시험이며 우리가 만들어내는 검증 시험의 종류이다. 우리는 이들 요구사항들이 얼마나 많이 커버되었는지를 조사한다. 우리는 아직 코드를 측정하지 않고 있다. 단지 “내가 작성한 요구사항을 얼마나 잘 커버하고 있는가? 예를 들면 425개의 요구사항이 있고 나는 다양한 카테고리로 1,500개의 시험을 작성했다. 나는 이들 425개 각각을 커버하고 있다.” 혹은 “나는 1,500개의 시험 조건을 기준으로 425개 중 25개를 커버하지 못하고 있다. 나는 그 25개의 조건을 커버하기위해서 또 다른 60 ~ 80개의 시험을 추가할 것이며 그것들에 대한 추적성을 직접 연결할 것이다.”라고 물으면서 그것을 살펴보고 있다. 이것은 요구사항이 완료되지 않았을 지도 모르기 때문에 수행된다. 또한 나는 시험이 완료되었는지를 확실하게 하기 위해 이전으로 돌아가서 요구사항을 추가한다. 기억하자. DO-178B는 융통성을 가지고 있고 합리적이다. 당신이 어떤 과정을 거치는가에 대한 부분보다 목적지로의 도착에 더 관심을 가진다. 그리고 그 목적지는 안전하고 결정론적인 소프트웨어이다. 재사용 가능하고 유지가 용이하며 비용대비 효과적이기를 희망하지만 DO-178B는 이런 특성들에는 관심이 적다.

역주) DO-178에서 커버리지는 반드시 요구사항을 모두 커버해야 한다고 말했다. 사실 이것이 한 번에 완성되는 일은 거의 없다. 수 없이 많은 반복이 필요하다. 저자의 말처럼 DO-178은 그 과정과 방법에 대해서는 일일이 간섭하지 않는다. 따라서 각자 최선의 방법을 찾아서 진행하면 된다. 결과만 제대로 나오면 되는 것이다. 그런데 이 말이 그 과정에 대해서는 DER이 신경도 안 쓴다는 의미는 아니다. 어떤 방법을 사용하든 신경쓰지는 않지만 그 과정에 문제가 없는지에 대해서는 확인을 한다. 한마디로 눈속임으로 결과만 만들어서는 아무 소용이 없다는 말이다. DO-178을 진행하다 보면 실무자 입장에서는 결과를 얻는 것이 최종 목표이기 때문에 그 과정 하나하나까지 챙겨야 하는 것은 정말 번거롭고 힘든 일이다. 그래서 과정에 대한 부분을 소홀히 진행할 가능성이 높은데 힘들더라도 반드시 챙겨야 하는 부분이라는 점을 명심하자.

 

스케쥴 관점에서 요구사항이 시작된 후에 검증팀이 추적성을 책임지고 그 다음에 또한 시험이 시작되는 것을 추천한다. 30명의 시험을 담당하는 엔지니어가 모두 필요한 것이 아니다. 요구사항을 확인하고 당신과 함께 그것을 리뷰하고 그들이 어떤 부분을 검증할 지를 고려하는 두 사람이 있을 수 있다. 그들은 “이것을 정말로 시험할 수 있나? 요구사항 작성을 멈추어라…..우리는 이것을 시험할 수 없을 수도 있다. 이 요구사항을 수정하지 않으면 우리는 문제가 생길 것이다.”라는 식으로 고려할 필요가 있다.

 

따라서 가능한 일찍 시험 조건을 작성하기 시작하라. 그 시점에는 코드가 없을 수도 있고 아마도 동작하는 박스(그 박스는 분명히 DO-254를 준수하면서 병렬로 개발되고 있을 것이다.) 조차도 없을 것이다. 하지만 검증팀과 함께 분석은 수행할 수 있다. 요구사항 작성자와는 독립적으로 떨어져 있다는 것을 확실히 하라. 그 시점에 당신이 적절한 요구사항과 시험을 가지고 있다고 느껴야 한다.

 

또한 “소프트웨어의 얼마만큼을 커버했는가?”라고 물어라. 만약 3,000라인 이상의 코드가 있다면 툴이 사용되어야 할 것이다. 당신은 그것을 수동으로 하려고 하지는 않는다. 기능, 정상, 강건성 시험을 기반으로 당신은 92%의 코드를 커버했을 수 있다. 혹은 78%를 커버했을 수 있다. 기억하라. 양호하다 혹은 정확하다라고 할 수 있는 매직넘버는 없다. 단지 그 단계에서 “대부분”의 코드를 커버했어야 한다.

역주) 커버리지가 몇 %가 되는 것이 잘한 것인지, 못한 것인지 판단할 수 있는 기준은 없다. 요구사항 기반의 시험에서 최대한의 커버리지가 나오면 좋은 것이다. 나머지 모자란 부분은 채우는 작업의 양이 그만큼 줄어들 수 있는 것이다. 그런 면에서 다시 한 번 말하지만 요구사항이 제대로 작성되는 것이 중요하다. 그래야 자연스럽게 시험이 잘 작성되는 것이고 커버리지도 그 만큼 올라갈 가능성이 높아진다.

 

DO-254의 세계에서 툴은 아직 우리가 기대하는 것 만큼은 성숙한 상태가 아니다. 1990년대 초에 나타난 DO-178B 틀들은 오늘날 완벽하지는 않지만 상당히 개선되었다. (기억하라, 완벽한 툴 같은 건 세상에 없다) 하나의 툴이 당신에게 필요한 모든 기능을 가지지는 못할 것이기 때문에 여러 가지 툴이 사용되어야 할 지 모른다. 툴판매처의 브로셔는 때때로 그들이 제공할 수 있는 것 이상을 말하는 경우가 있기 때문에 당신의 환경에서 어떤 부분을 충족하는지를 조심스럽게 조사해야 한다.

역주) 이 책이 DO-178C가 나오기 전에 작성되었다는 점을 유의하자. 약 2002 ~ 2003년경으로 상당히 오래 전에 작성된 내용이다. 툴은 계속해서 발전하고 있고 이제는 저자의 말처럼 성숙하지 않다고 말하기 보다는 오히려 툴이 없으면 DO-178이든 DO-254든 제대로 수행할 수 없는 상황이라고 해야 할 것이다.

 

당신은 코드의 일부가 절대 요구사항을 가지고 있지 않다는 것을 알게 될 지 모른다. 요구사항이 추가되면 시험은 불충분한 상태가 되는 것이고 추가적인 작업이 필요하게 된다. 그 후 다시 측정해보면 더 높은 %의 커버리지를 달성했을 수도 있다. 이러한 과정은 프로젝트의 가장 비용이 많이 드는 특성 중 하나이다. 그것은 전체 예산의 35 ~ 50% 정도 된다. 가능하다면 35%에 가깝게, 많으면 40%를 유지하라. 당신은 시험으로 품질을 향상시키려고 하지는 않지만 요구받은 모든 것을 수행했다는 기능성을 증명한다. 품질은 정확성, 리뷰 그리고 분석과 같은 라이프사이클내의 다른 활동들로부터 온다. 구조적 커버리지는 비록 그것이 유용하긴 하지만 아마도 에러를 발견하는데 있어서 가장 비효율적이고 비싼 방법일 것이다. 그것은 단지 당신이 도달했다고 말하는 분석일 뿐이다.

 

구조적 커버리지 시험 자체에 기반한 에러 숫자를 살펴보라. 당신은 적은 수의 에러에 대해서 많은 비용을 지불했을 것이다. 하지만 그런 에러들은 발견되었어야 하는 중요한 것들이었다.

 

DO-178B 소프트웨어 시험: 검증 그리고 간접적인 품질 향상   시험은 문제점을 발견하기에 비용이 많이 소요되는 단계이다   품질 개선의 불충분한 방법 단지 “시험”이 아닌 “정확성” 구조적 커버리지는 매우 비효율적이다….하지만 필요하다 통합된 소프트웨어에 대해서 수행되었을 때 가장 높은 품질이 가능 단위시험은 현실세계가 아니다. 많은 가정이 있다

 

“어떻게 구조적 커버리지 시험의 추적성을 보여줄 수 있나요?”와 같은 질문을 종종 받게 된다. 구조적 커버리지는 당신이 개발하는 시험으로부터 당신이 커버하는 코드 세그먼트까지 가리킬 수 있어야 한다. 그 이전의 요구사항으로까지 연결할 필요는 없다. 왜냐하면 당신의 시험은 이미 그것들과의 추적성을 가지고 있기 때문이다. 요구사항에 기반한 현재의 시험은 코드 함수로의 추적성을 가진다. 당신은 아마 각 시험과 코드의 라인 하나하나를 연결하기를 원하지는 않을 것이다. 따라서 요구사항의 연결고리에서 더 상위레벨의 시험은 더 가치가 있다. 왜냐하면 더 현실적이기 때문이다. 당신이 코드레벨에서 모든 것을 시험한다면, 그리고 코드를 기반으로 시험케이스를 작성한다면 당신은 통합 시험 레벨에서만큼 많은 에러들을 잡을 수 없을 것이다.

 

기능 시험 = 요구사항   어떤 요구사항? 소프트웨어 요구사항 상위레벨 요구사항 하위레벨 요구사항   시험 방법 = 시연이 아닌 “시험”, 조사 혹은 분석

 

DO-178B는 우리가 작성하고 수행하고자 하는 기능의 커버리지를 보장할 것을 요구한다. 거기에는 어떤 영역에서는 상위레벨 그리고 하위레벨 요구사항과 분석을 포함한다. 하지만 가능한 그것들에 대한 시험을 많이 개발하라. 시험이야 말로 진정으로 결정론적이 될 수 있는 유일한 방법이다. 이전의 군 소프트웨어 시험 표준과 같은 다른 표준에서는 또한 조사에 대해서도 강조하고 있다. 받아들일 수 있는 시험 방법으로 분석과 시연도 있다. 하지만 스스로에게 물어보라. 조사, 시연 그리고 분석이 유일한 방법이라면 일관성있는 시험을 객관적이고 결정론적으로 개발할 수 있을까? 당신은 논쟁하고 심사숙고할 수는 있겠지만 그 답은 변하지 않는다. “그럴 수 없다”이다. 조사, 시연 그리고 분석은 일관성있게 수행하기가 어렵다. 따라서 DO-178B는 검증을 수행하기 위한 적절한 방법으로써 시험을 강조한다.

 

시험은 다른 플랫폼에서 수행될 수도 있지만 그런 방식으로 물리적인 증명을 하는 것이다. 분석과 시연은 일회성이며 수동으로 진행된다. 또한 수정이 있으면 매번 반복될 필요가 있다.

역주) DO-178에서는 증거를 보여주는 것이 중요하다. 아마 앞부분에서 “유죄추정의 법칙”이라고 설명한 부분이 기억날 지 모르겠다. 오죽했으면 이런 말이 소개되겠는가? 그런데 증거를 보여주는 방법을 특정하지는 않는다. 시험이 가장 적절하다는 것이고 추천되기는 하지만 만약 시험을 할 수 없는 경우라면 위에서 나온 조사(Inspection), 시연(Demonstration), 분석(Analysis) 중 어떤 것으로도 가능하다. 중요한 것은 그 결과를 DER이 납득할 수 있느냐이다. 참고로 그 외의 다른 어떤 방법도 제시할 수 있다. 여기서 제시된 4가지뿐만 아니라 자신만의 독자적인 방법을 제시할 수도 있다는 말이다. 물론 DER이 OK해야 한다는 전제가 있긴 하지만 DO-178이 이런 식의 융통성을 허용한다는 점을 이해하면 실전에서 막히는 부분이 생겼을 때 다른 방식으로도 생각해볼 수 있는 여지가 생기는 것이다.

 

블랙박스 시험을 더 많이 수행할 수 있다면 더 좋은 결과를 얻을 수 있다. 블랙박스 시험에 기반한 커버리지가 높아질수록 FAA와 DER 그리고 시험의 품질과의 당신의 신용도는 더 나아진다. 핵심은 항공기에 실제로 사용되는 것이 무엇이냐이다.

역주) 블랙박스 시험을 이야기하는 것은 결국 소스기반이 아닌 요구사항 기반의 시험을 강조하는 것이다. 실제로 DO-178 인증을 받기 위해서는 반드시 요구사항 기반의 시험이 가장 중심이 되어야 한다. FAA도 DER도 그것을 가장 우선적으로 확인하게 된다.

 

동치 클래스   예시 1: 24.0 ~ 28.0 vdc의 유효 전압 범위 질문: 24.0과 28.0 사이의 가능한 값들을 모두 시험해야 하나? 경계는 무엇인가? 얼마나 많은 범위내의 전압값을 시험해야만 하는가?   예시 2: 사인함수 질문: 사인함수는 어디에서 오는가? 당신이 소스코드를 가지고 있는가? 당신은 그것을 신뢰하는가? 당신은 FAA가 검증없이 그것을 신뢰할 것이라고 생각하는가?

 

동치 클래스는 시험의 분량을 최소화한다. 24 ~ 28V 유효 범위에서 동일한 동작을 하는 함수가 있다고 하자. 당신은 25, 26, 27 그리고 27.6V와 같은 것들을 일일이 시험할 필요가 없기 때문에 대폭 비용을 줄이는 차원에서도 시험 케이스의 많은 항목을 제거하라. 24.1과 27.9 사이의 값을 선정하고 시험과 기능성에서 동등함을 보여라. 당신은 그들 사이의 모든 점을 시험하지는 않을 것이다. 하지만 24와 28이라는 경계에서는 할 필요가 있다. 그리고 우리는 그 유효한 경계 바로 위와 아래에서 강건성을 확인할 것이다. 그것이 강건성 시험이다.

 

동치 클래스는 매번 같은 결과로 같은 시험의 반복을 제거한다. 어떤 범위가 있을 때 당신은 모든 값을 시험할 필요가 없다.

역주) “Equivalence Class”의 번역을 “동치 클래스”라는 어려운 용어로 번역을 해서 그렇지 개념은 어려운 게 아니다. 결국 어떤 범위가 있다면 그 범위내에서 대표값을 선정해서 시험하라는 것이다. 완벽하게 한다고 그 범위 내의 모든 값을 시험하는 것은 시간낭비일 뿐이다. 다만 여기서 유의해야 할 부분이 양쪽의 경계값과 범위 밖의 값에 대해서도 시험을 해야 한다는 점이다. 그것이 “Robustness Test”, 즉 강건성 시험이다.

 

다음으로 사인함수가 있고 그것에 대한 소스코드가 없다고 생각해보자. 그것은 바이너리 라이브러리 함수를 통해서 컴파일러에 의해 포함된 함수일 뿐이고 나는 단지 그것을 사용할 뿐이라면 어떨까? 그 값을 신뢰할 수 있을까? 이 경우에 사인함수는 범위내에서 선택된 입력이 예상값을 제공하는 것을 보여주는 등가값을 사용해서 쉽게 시험된다. 경계점에서 시험 케이스가 만들어 질 수 있고 이제 사인함수는 360도 범위 전체에 대해서 커버된다. 하지만 모든 각도를 시험할 필요는 없다. 점근선과 음수값을 포함한 여러 개의 값을 시험하고 등치에 의해서 전체 함수가 검증된다는 것을 보여라. FAA는 이런 식으로 동작하고 검증된다는 것을 신뢰할 필요가 있다. 많은 라이브러리들이 이제는 인증 자격을 갖춘 제품으로 나오고 있다.

 

동치 클래스   Y = sin(X) 당신은 소스코드를 가지고 있지 않기 때문에 처음부터 다시 작성해야 한다. 맞나? 아니다! 동치 클래스가 있다.

 

최초의 “인증받은(qualified)” 컴파일러는 Ada였다. 1980년대 후반에 나타난 “qualified” 혹은 “certified”된 컴파일러라는 용어는 DoD에 의해서 사용되었는데 Ada에 지정되었다. 자신들의 컴파일러를 자세히 조사한 Ada 제작사는 코드의 벤치마크셋을 생성했으며 컴파일 후의 정확한 출력을 알았다. 출력에 대해 수행하는 시험이 있었고 그것은 매우 깔끔하게 조사되었다. 만약 당신의 Ada 컴파일러가 인증을 받을 필요가 있다면 당신은 같은 종류의 벤치마크 코드를 실행해야 한다. 만약 동일한 결과를 얻는다면 당신은 인증을 받았다는 것을 보여주는 것이 된다.

역주) 우선 용어부터 정리하자. 사실 역자에게는 Ada(‘에이다’라고 읽는다고 함)라는 언어가 잘 와닿지 않는다. C, C++, Java와 같은 프로그래밍 언어라고는 하는데 한번도 본적이 없고 이름도 처음 들어본다. 그런데 Ada가 DO-178에서는 대표적인 언어로 자주 이야기된다. 아마 지금은 C가 그 자리를 대체하고 있는 것 같고 앞으로 C++도 상당히 영향력을 가지게 될 것 같다. 일단 프로그래밍 언어 중 하나이다.   이 Ada에 사용되는 컴파일러가 최초의 인증을 받았다고 저자가 소개하고 있다. 여기서 ‘qualified’라는 단어와 ‘certified’라는 단어가 구분해서 사용되고 있다. 앞에서 아래와 같은 표가 나온 적이 있다. 컴파일러는 툴이므로 아래 용어 설명을 기준으로 인증을 받았다는 것에 대해서 ‘qualified’를 쓰고 있는 것이다. 이런 구분에 익숙해질 필요가 있다.     용어   “Certified”: 전체 시스템이 인증을 받는 것으로 내부 구성품들은 각각 서로 다른 인증 레벨을 가질 수 있다. “Certifiable”: 시스템 내부의 하나의 구성품이 시스템에 포함되어 인증을 받기 전에 가장 높은 인증 상태를 획득하는 것 “Qualified”: 툴에 대한 인증으로 툴 자체가 항공기에 탑재되는 것이 아니므로 “인증”이 필요없음 “Compliant”: FAA와는 다른 조직, 예를 들면 군이나 비 상업용 항공전자분야를 통한 인증   저자가 컴파일러의 인증(qualified)에 대해서 설명하고 있지만 역자의 판단으로는 컴파일러의 인증(qualified)에 대해서는 신경쓰지 않는 게 정신건강에 좋지 않을까 싶다. 어차피 컴파일러 인증을 받는 것은 현실적으로 거의 불가능에 가깝고 굳이 인증을 받지 않고 진행하는 것이 일반적이기 때문이다. 뒤에서 바로 그런 내용이 나온다. 그냥 이런 게 있다 정도로만 이해하고 넘어가자. 참고로 앞으로 나오는 ‘qualified’, ‘certified’는 모두 우리말로는 ‘인증’으로 번역할 예정이다. 영어를 구분해서 이해를 하는게 가장 정확하겠지만 내용을 이해하는 데에는 크게 지장없다고 판단되므로 착오 없으시기 바란다. (참고 포스팅: 4. DO-178 인증과 준용)

 

확실히 실행시간 라이브러리는 같은 형태로 검증되고 인증될 필요가 있다. 하지만 컴파일러 인증은 100% 정확하지는 않다. 컴파일러 벤치마크가 잠재적인 소스코드 생성의 무한대 범위를 커버할 수는 없다. DO-178B는 이것을 인지하고 정확하지 않은, 예술적인 과학의 형태를 보이는 것 때문에 간단히 무시한다. 당신은 DO-178B에서 인증받은 컴파일러에 대한 인정을 받을 수 없다. 당신은 여전히 DO-178B가 요구하는 시험의 완전한 보완을 통해서 바이너리와 같은 컴파일러의 출력물을 완전하게 시험해야 한다.

 

또한 라이브러리에 대한 인증 패키지가 있다. 대부분의 경우에 있어서 당신은 소스코드를 가지고 있지 않을 것이며 단지 컴파일러가 제공하는 라이브러리내의 바이너리만을 가질 것이다. 따라서 당신은 일반적으로는 소스코드를 리뷰하고, 기능 시험, 구조적 커버리지 분석 그리고 DO-178B 가이드라인의 Section 6에서 요구하는 다른 모든 검증활동들을 수행해야 한다. 그러나 FAA는 많은 경우에 있어서 기존에 존재하는 COTS 소프트웨어가 충분히 높은 품질을 가지고 있고, 사실 처음부터 어떤 라이브러리 기능을 지속적으로 리뷰하는 것보다 더 안전할 지 모른다는 것을 알고 있다. 하지만 리뷰나 커버할 소스코드를 가지고 있지 않다면 DO-178B를 어떻게 준수할 수 있을까? 당신의 기능을 검증하기 위해 대체 준수방법과 함께 동치 클래스를 사용하라. 그리고 가능한 항목들에 대해서 그런 방식의 시험을 수행하라. 당신은 그것이 의도된 대로 동작한다는 것을 보여왔다. 당신은 여전히 코드상에서 시험을 수행하지만 처음부터 완전히 새롭게 라이브러리를 작성하는 것 보다는 작업량이 적은 대안을 가지고 있기 때문에 일반적으로 DO-178B에 의해서 요구되는 모든 활동들을 피하기 위한 대체 준수 방법을 사용한다. DO-178B는 항공우주회사들의 중요한 입력을 받아서 작성되었고 이들 회사들은 이치에 맞지 않는 것을 다시 작성하는 데에 돈을 낭비하는 것을 옹호하지도 원하지도 않는다는 것을 명심하라.

역주) 상용제품을 COTS라고 표기한다. DO-178에서 COTS를 사용하는 것은 COTS의 안전성을 믿는다는 의미이다. 이런 믿음만으로 넘어가면 좋겠지만 그 믿음을 증명할 수 있는 증빙을 보여야 한다. DO-178에서는 그것을 많은 비용을 들여서 증빙을 구매하거나 그렇지 않으면 직접 시험해서 보여주어야 한다. 사실 DO-178의 어려운 점은 바로 이런 점들이라고 할 수 있다. (참고 포스팅: 26. DO-178과 COTS의 사용 (1))   참고로 마지막 문장에 음미할 만한 부분이 나온다. 바로 DO-178을 항공우주 관련 회사들이 주도적으로 만들었다는 점이다. 회사의 목적은 이윤이므로 이 가이드라인을 만들 때 그 부분이 아주 중요한 고려사항이었을 것이라는 점은 충분히 짐작할 수 있다. 실제로 그 점이 충분히 반영된 것이 지금의 DO-178 가이드라인인 것이 사실이다.

 

동치 클래스   고려사항: Y = sin(X) 컴파일러제공 수학 라이브러리로부터 옴 당신은 소스코드를 가지고 있지 않음 문제없음: 대체 준수방법으로 동치 클래스를 통해서 포괄적인 시험 점근선에서의 경계값을 시험 여러 개의 대표 값을 시험 “동치 클래스를 통한 포괄적인 시험 유효성”을 주장하고 얻음

 

정상 범위 시험   화이트박스 시험, 예를 들면 소스코드를 오픈 정상 동작 조건 정상 범위값 동치 클래스 예시: 사인함수   주의: 대다수의 정상 범위 시험 케이스들은 기능 시험을 통해서 커버되어야 함 왜? 상세한 하위레벨 요구사항

 

정상 범위 시험은 시스템의 정상 동작 조건을 고려한다. 시험 케이스의 수를 줄이기 위해서 동치 클래스를 사용하면서도 여전히 전체 기능을 커버한다. 소프트웨어의 많은 부분이 단지 정상 시험 케이스를 구동하는 것으로 커버될 수 있다. 하드웨어의 전원을 켜고 전원이 인가되는 과정을 시험하면서 시스템이 살아서 연결되었다는 반응을 얻는 것 만으로도 동작되는 모든 부분을 검증하게 되면 소스 코드의 20 ~ 30%를 통과하게 될 것이다.

 

기능 시험은 상위레벨과 하위레벨 요구사항을 커버하기 때문에 정상 범위 시험 케이스는 기능 시험을 통해서 커버되어야 한다. 정상 범위의 추가적인 일부분을 커버하기 위해 기능 시험으로 커버되지 않는 부분을 위한 약간의 시험이 더 추가될 수 있다.

역주) DO-178의 커버리지 100%를 달성하기 위한 전략적인 방법이 설명되고 있다. 먼저 기능시험으로 상위레벨, 하위레벨 요구사항을 시험하면 100%까지는 아니더라도 상당부분이 달성될 수 있으며 나머지 누락되는 부분을 위한 추가적인 시험을 수행하는 형태를 제안하고 있다. 사실 이 부분은 사용하는 툴에 많이 의존하기 때문에 툴에서 이런 식의 지원이 가능한지도 확인하는 것이 중요하다. 많이 사용하는 툴의 경우에는 대부분 이런 접근이 가능하도록 지원하고 있다. (참고 포스팅: 12. DO-178과 소프트웨어 검증 프로세스 (Section 6.0))

 

강건성 시험   화이트박스 시험, 예를 들면 소스코드를 오픈 비정상 동작 조건 경계값 경계의 어느 부분? 근접하고 넘어서는 경계! 경계에서는 비트레벨의 정확도 예시: 24 ~ 28vdc 요구사항

 

강건성 시험은, 반대로 시스템의 잘못된 조건하에서 보게 될 수 있는 일반적인 시나리오를 생성하는 영역이다. 예를 들면, 당신이 절대 접하지 않을 잘못된 입력, 손상된 데이터와 경계값과 같은 것이다. 하지만 만약 그것이 발생한다면?

 

만약, 소위 파티셔닝 같은 것이 존재한다면 일부 시험은 특별히 중요하게 된다. 우리가 입력값을 넣는다고 하더라도 예들 들면 전원이나 전등 시스템 혹은 비디오/오디오 장비와 같은 것들을 망가뜨릴 수 있는 정도로 전기 시스템상에 부하를 줄 수는 없다. 하지만 우리는 실질적으로 발생할 수 있는 모든 시나리오들을 시도해봐야 하며 문제가 발생하는지를 확인해야 한다. 파티셔닝은 충분한 양의 강건성 시험이 필요하다.

 

다시 각 데이터 항목의 경계값을 살펴보고 경계 지점과 그것을 넘어서는 지점을 검증하라. 왜 데이터 사전과 Fault Tree와 같은 것들을 만드는가? 그러면 우리가 정상 데이터 동작 범위와 설명을 더 쉽게 조사할 수 있기 때문이다. 정상 범위 다음에는 시스템에 미치는 영향을 검증하기 위해 정상 범위 조건을 벗어나서 검증될 필요가 있다.

 

1999년으로 돌아가 보면 비행 명령어가 꼬여버린 것 때문에 화성으로 보내진 한 대의 탐사장비를 1억 2천 5백만달러의 손실과 함께 잃어버린 적이 있었다. 그 이유는 단순히 단위 문제였다. 한 개발자는 인치 단위를 사용했고 반면에 다른 사람들은 미터 단위를 사용했다. 내부의 항목들은 서로 통신할 필요가 있었다. 그 에러는 코드 리뷰, 데이터 리뷰 그리고 아키텍처 리뷰에서 잡혔어야 했다. 만약 데이터 사전이 있었다면 정확한 단위를 유지하기 위해 별도의 변경함수가 필요하다는 것이 명확해졌을 것이다.

 

정상범위 및 강건성 시험 동안에, 특히 강건성 시험 동안에 에러가 잡혔다면 재앙은 피할 수 있었을 것이다. 따라서 앞서 수행된 것들은 나중에 이어지는 것들을 상당부분 줄여줄 수 있다.

 

커버리지는 소프트웨어 에러에 대한 최종 방어이다. 우리는 구조적 커버리지를 방어라는 개념보다는 하나의 분석이라고 부르고 싶다. 그것은 당신이 어떤 부분을 수행했는지, 어느 시점에 수행했는지에 대한 정도를 표시하며 모든 기능을 커버한다. 코드의 각 항목이 해당 기능을 적절하게 수행하는지가 증명된다.

 

레벨 C에 대해서 statement가 커버된다. 레벨 B에 대해서는 statement에 더해서 decision이 커버될 필요가 있다. 레벨 A에 대해서는 statement, decision, 그리고 MCDC가 커버되어야 한다. 그것은 완전함에 대한 측정이다. 모든 것이 완전하다면 추가적인 요구사항이나 시험이 필요하지 않다는 것을 알려주게 된다.

 

그래서 DO-178B와 DO-254내에서의 시험은 다른 표준과 비교해서 전체 라이프사이클 단계내에서 가장 유별나게 다른 특성이다. 그것은 당신의 전체 개발 자금 중 30 ~ 45%를 쉽게 소비할 것이다. 이 챕터에서 설명한 대로 수행한다면 당신은 비용과 항공전자 장비의 시험에 대한 스케쥴 문제를 최소화하면서 잘 진행하면서도 보다 더 안전한 제품을 전달함으로써 경쟁자들보다 한 단계 앞서 있도록 만들어 줄 것이다.

역주) DO-178에서 요구하는 시험은 역자가 지금까지 경험한 개발 과정과 비슷한 듯 하면서도 많이 다른 것이 사실이다. 개념이나 철학적인(?) 관점으로 이해해야 할 부분이 많다는 느낌도 든다. 그러면서도 저자의 마지막 말이 과장으로 들리지 않는 것은 시험 과정과 결과가 실제로 제품의 안전성을 담보하는 데 상당히 객관적이고 확실한 증거가 될 수 있다고 동의하기 때문이다. 항공전자 소프트웨어의 항공기 탑재를 위한 안전성을 확보하는 것이 정말 쉽지 않다는 점을 다시 한 번 느끼게 된다.