19. 시험 그리고 툴

 

만약 우리가 예를 들어서, Motorola 68332 혹은 power PC에 대해서 크로스 컴파일한다면 PC상에서 모든 것을 시험할 수 있을까? 아니, 그럴 수 없다. 사실 당신은 심지어 레벨 D에 대해서조차도 모든 것을 실제 타겟 바이너리로 시험해야 한다. 하지만 PC 혹은 시뮬레이터상에서 바이너리를 시험하는 것은 만약 프로세싱이나 출력이 하드웨어와 관련된다면 유효하지 않다. 그래서 만약 그것이 타이밍 관련, 비트 관련, 스택 관련, BSP 혹은 운영체제 관련된 출력 혹은 독립적인 IO라면 우리는 실제 하드웨어상에서 시험해야 한다.

 

하지만 우리에겐 하나의 작은 경품이 주어진다. 알고리즘, 로직 결정 그리고 예외 처리에 대해서는 타겟 플랫폼의 결과와 시험 플랫폼이 동등하다는 것을 보여주는 한 하드웨어상에서 시험할 필요는 없다. 그 경우 우리는 시뮬레이터상에서 시험할 수 있다. 하지만 DO-178B를 작성한 산업계는 돈을 낭비하고 싶지 않아서, 예를 들면 만약 그 시험이 RAM을 망가뜨릴 수 있다면 실제 하드웨어에서 시험해서는 안된다. 그렇지 않으면 그것은 실제로 망가지게 된다. 파괴적인 시험조차도 아무것도 망가뜨려서는 안된다. 하지만 그 외의 모든 것은 만약 하드웨어와 관련된다면 반드시 하드웨어에서 시험되어야 한다.

역주) DO-178은 기본적으로 실제 하드웨어에서의 결과를 보여주어야 한다. 그래야 가장 정확한 것이 되고 DER이 받아들일 수 있다. 그런데 현실은 그게 쉽지 않다. 아니, 거의 불가능하다. 어차피 하드웨어는 거의 마지막 단계에서 나온다. 하지만 시험은 중간중간 계속된다. 그래서 시험을 어떻게 진행하고 어떤 결과를 어떻게 보여줄 지 전략적으로 잘 선택해야 한다. DO-178이 무조건 하드웨어에서의 시험을 요구하는 것은 아니므로 충분히 융통성있게 진행할 수 있다. 대신 그 융통성에 대해서는 DER과의 사전 합의가 필요할 수 있다.

 

시험을 위한 많은 툴이 있다. 그들 가운데 선택하는 것에는 각각 장점과 단점을 가지고 있다. 장점과 단점과 함께 툴에 대해서 살펴보자. 모든 사람들이 하나의 시험툴로 DO-178B의 모든 요구사항을 지원할 수 있는 이상적인 툴을 원한다. 하지만 하나의 툴이 디버깅, 시스템 레벨에서의 시험, 모든 요구사항에 대한 시험 그리고 모든 구조적 커버리지를 분석할 수 있게 하는 것은 지금까지 발견하지 못했다. 우리는 당신의 objective를 달성하기 위해 아래의 리스트에서 적어도 두개의 툴을 필요로 할 것이라고 믿는다.

툴, 장점 & 단점   디버거 에뮬레이터 시뮬레이터 시스템 시험 환경 단위시험툴 I/O 시뮬레이션/캡처(GPS, ARINC, 1553, 등) 구조적 커버리지 툴(Instrumenter 포함)

 

디버거는 훌륭하다. 프로그램 카운터를 소스코드 어느 라인에든 설정하고 모든 조건, 단일 스텝을 거치고 훌륭한 구조적 커버리지를 얻는다. 하지만 실제로 커버되는 것은 무엇인가? 그렇게 많지 않다. 당신은 단지 컴파일러가 컴파일을 수행했고 디버거가 동작했다는 것을 증명할 뿐이다. 대부분의 디버거는 구조적 커버리지를 수집하지 않고 합치지도 않으며 당신은 하드웨어와 관련된 시험에 대해서 신뢰할 수 없을 것이다. 그리고 대부분의 디버거는 시험 케이스 부분의 자동화와 스크립팅에 취약하다.

 

에뮬레이터는 훌륭하며 하드웨어 관련된 동작을 모의하는데 더 나은 작업을 제공하지만 일반적으로 자동화되어 있지 않다. 일반적으로 에뮬레이터를 이용해서 많은 스크립팅을 할 수는 없다. 그리고 모든 IO에 대해서 하드웨어적인 완전한 신뢰를 얻을 수는 없다.

 

명령셋 시뮬레이터는 자동화, 일괄처리 능력 그리고 일괄처리 언어를 가진 강력한 툴이다. 당신은 모든 것을 모의할 수 있는데 특히 명령어 시뮬레이터가 있다. 하지만 하드웨어 IO에 대해서 신뢰할 수 있는가? 그럴 수 없다. 당신은 일부 훌륭한 구조적 커버리지 툴과 연결할 수 있고 일부는 심지어 내장된 구조적 커버리지 분석 능력을 제공하기도 한다.

 

시스템 시험 환경은 DO-178B가 정말 관심을 가지는 부분인 전체적인 시험에 대한 것이다. 하지만 거기에는 한 가지 문제가 있다. 도달하기 어려운 조건에서도 모든 것을 확인하기 위한 하위레벨 명령을 제공할 수 있는가? 일반적으로 그렇지 않다. 그리고 대부분의 시스템 시험툴이 그렇듯이 자동화된 구조적 커버리지 능력을 가지고 있지 않다.

역주) 에뮬레이터, 시뮬레이터는 하드웨어와 동일한 환경을 만들 수 없다는 약점이 있고 타겟 시험 환경은 아무리 잘 갖추어 지더라도 소스코드의 깊은 부분까지 하나하나 시험할 수는 없다는 약점이 있다. 실전에서는 이런 각각의 약점을 고려해서 적절한 시험방법을 선택하게 된다.

 

단위시험은 굉장하지만 때때로 비동기적인, 현실 세계 환경에서 소프트웨어를 구동하는 것이 아니기 때문에 DO-178B의 신뢰를 얻기가 어렵다. 사실적인 프로세싱을 갖추기 위해 지금까지 스텁(stub)과 드라이버만이 추가된다.

 

시험 케이스 생성기는 어떤 시험 케이스를 사용할지 알아내는 데 도움을 준다. 1553 혹은 GPS와 같은 것을 실행한다면 IO 시뮬레이션이 필요하다. 그리고 당신은 구조적 커버리지 툴이 매우 필요하다.

 

만약 당신이 1,000라인 이상의 소스코드를 가지고 있다면 수동으로 소스코드를 출력하고 색깔이 있는 연필로 구조적 커버리지를 확인하는 작업을 하는 것을 원하지 않는다. 하지만 구조적 커버리지에 대한 신뢰를 얻기 위해 구조적 커버리지 툴과 다른 시험을 수행하는 툴을 어떻게 연결할 지를 결정하라. DO-178B 시험과 커버리지 분석에 도움을 얻기 위해 VectorCAST와 같은 다목적 툴의 사용을 적극적으로 고려하라. 기능 시험, 정상범위 시험 그리고 강건성 시험을 수행하고 모든 가능한 branch의 80 ~ 85%를 커버하라. 그런 다음 나머지 구조의 10 ~ 15%를 수행하라. 10 ~ 15%는 어떤 부분인가? 바로 툴이 커버되지 않았다고 하는 부분이다.

 

유명한 소프트웨어 시험툴   VectorCAST 가장 빠른 성장, 항공전자 특화됨, 매우 증명된   GCover Green Hills사의 커버리지 분석이 포함된 통합툴   IPL 전통적인 커버리지툴이자 초기에 개발된 툴 중 하나   Logiscope 전통적인 커버리지툴   CodeTest 에뮬레이터 기반   LDRA 현대적인 분석/커버리지   Rational   풀패키지 제품, 하지만 IBM에 인수된 이후 지원이 줄어듦

 

좋은 툴이 무엇일까? 위에 보이는 모든 것은 항공전자 프로젝트에서 성공적으로 사용되어왔다. 우리는 일반적으로 VectorCAST와 GCover를 사용한다. 다른 제조사들도 DO-178B에 인증가능한(qualifiable) 좋은 툴을 만들고 있지만 그들 모두 장단점과 서로 다른 가격 구조를 가지고 있다. 툴인증은 중요하다. 어떤 툴이 하나의 케이스에서 잘 동작한다는 것을 증명해왔다는 것이 당신이 그것을 완전하게 그리고 올바르게 사용해왔다는 것을 의미하는 것은 아니며 따라서 여전히 각 프로젝트에 대한 툴인증을 다시 받아야 한다. 더 많은 정보에 대해서는 이 책의 툴인증 챕터를 참고하라. 하지만 두 가지 타입이 있다는 것을 기억하자. 바로 개발툴 인증과 시험툴 인증이다. 개발툴 인증은 그 출력이 실제로 항공기에 탑재되는 툴이며 개발툴 인증은 상당히 어렵고 비용이 많이 든다. 시험툴은 항공기에 탑재되는 다른 소프트웨어를 평가하는 툴이며 인증을 받는 것은 일반적으로 그렇게 어렵지는 않다. 하지만 만약 당신이 판매자로부터 툴인증 데이터를 구매(비용지불에 대한 계획)할 수 있고 받아들일 수 있다는 것을 보여주기 위해 당신의 환경에서 툴인증을 재실행할 수 있는 것 만으로도 상당한 도움이 된다.

역주) 지금까지 역자가 직, 간접적으로 접해본 툴은 Vector Software, LDRA, SureSoft 그리고 RAPITA System의 툴이다. Vector Software의 VectorCAST는 짧은 기간이었지만 실제 사용해봤고 다른 툴은 들어보기만 했는데 관심을 가지고 계속해서 관련 정보를 챙겨보고 있다. 일단 VectorCAST와 LDRA, SureSoft의 툴은 한컴MDS와 모아소프트, 슈어소프트를 통해서 무료교육을 받을 수 있다는 장점이 있고 기술지원이 양호하므로 최소한 우리나라에서는 좋은 선택지가 될 것으로 보인다. 그런데 이러한 툴의 선정에서 함께 고려해야 할 부분이 바로 툴인증이다. 현실적으로 국내에서 DO-178 인증을 받으면서 툴인증을 받기는 거의 불가능하다. 대신 툴인증의 히스토리를 가지고 있는 툴을 구매함으로써 간접적으로나마 툴인증을 받는 방법을 택하는 게 그나마 최선이다. 그런 관점에서도 위의 툴은 선택지가 될 수 있다. 참고로 위에서 저자가 설명한 부분은 DO-178C가 나오기 전의 내용이어서 지금의 툴인증과는 일부 다른 부분이 있다. 하지만 기본적인 개념에서는 거의 유사하므로 일단 지금은 이런 정도로만 이해하고 넘어가자. (참고 포스팅: 33. 툴인증(Tool Qualification) (Section 12.2))

 

Instrumentation 툴 프로세스 플로우   툴 한 개의 가격으로 두 가지 툴을 지원 1. Instrumenter_Tool 2. Coverage_Results_Parser

 

자동화된 코드 커버리지에서 instrumentation이라 불리는 프로세스는 일반적으로 소스코드에 적용된다. 위에서 보여지는 것처럼 instrumentation의 의미는 커버리지 분석을 수행하기 위해서 두가지 툴이 필요하다는 것인데, 따라서 구조적 커버리지 툴 제공업체는 당신에게 하나의 가격으로 두 가지 툴을 제공한다. 소스코드가 instrumenter를 통해서 실행되고 그것은 이어지는 실행에서 커버리지 데이터가 기록되도록 하는 특별한 구성체를 당신의 소스 코드에 추가한다. 당신은 재컴파일하고 시험을 재실행하고 모든 pass/fail 결과가 예상대로 통과하는지를 체크한다. 그런 후 시험을 실행하는 동안 추가되었던 instrumented 코드는 구조적 커버리지를 결정하기 위해 툴로부터의 출력을 통해서 특별한 테이블과 커버리지 데이터를 증가시킨다.  두 번째 툴은 첫 번째 툴에 의해서 생성된 기록된 커버리지 결과를 파싱하고 커버리지에 대한 다양한 등급의 정보를 제공한다. VectorCAST와 같은 툴은 DO-178B의 각각의 위험레벨에 대한 커버리지 결과를 보여주며 어떤 구조들이 커버되었는지, 커버되지 않고 남아 있는지를 보여준다.

 

기억하라. 당신은 DO-178B에서 “D”가 “determinism”을 의미한다고 생각할 수 있다. 위에서 설명된 것처럼 instrumentation을 통해서 코드를 변경하는 툴에 관해서 FAA는 어떤 생각을 하고 있을까? 당신은 이 instrumented 코드를 항공기에서 실행할 예정인가? 그 답은 “아니다”이다. Instrumented 코드는 더 느리게 실행되기 때문에 필요한 응답 타이밍을 가질 수 없을 것이다. 당신은 실제로 그것을 신뢰하지 않으며 FAA도 마찬가지일 것이다. 따라서 당신은 이런 식으로 시험할 수 있는가? 확실히 그런 instrumentation 툴은 어떤 식으로든 승인을 받아야 한다. 그렇다. 수백 건의 항공전자 프로젝트들이 인증을 받아왔다. 따라서 그것은 무엇을 의미하는가? 흠, 당신은 그것을 사용할 수 있다. 하지만 당신은 시험을 두 번 수행해야 하고 그것은 두 배의 작업량이다. 그 시험은 모든 시험을 통과하고 실패한 부분은 수정되었다는 것을 증명하기 위해 instrumenter 없이 한 번 수행해야 한다. 그런 다음 동일한 시험의 pass와 fail을 증명하기 위해 다시 수행하지만 그러면서도 구조적 커버리지를 얻는다. 커버리지 결과를 모으는 단계에서는 모든 것이 20 ~ 30% 느려지기 때문에 타이밍에 대한 시험은 하지 못할 것이다. 그래서 이에 대해서는 적절한 방법으로 설명을 하게 된다. FAA는 합리적이고 DO-178B 역시 마찬가지다. 만약 그것이 오직 타이밍때문에 실패하는 것이라는 점을 스스로 확신할 수 있다면 당신은 그에 따라서 그 실패를 문서화할 수 있고 그것은 통과할 수 있다. 주석을 달고 그것이 그런 조건임을 확인시켜라. QA, DER 혹은 독립된 리뷰어가 그것을 살펴보게 하고 그 평가를 확인하라.

역주) 내용도 복잡하고 설명도 복잡하고 번역은 더욱 더 복잡하다. 직접 수행해 보면 되는 것들을 짧은 글로 설명하려고 하니 더 복잡해졌다. 다시 한번 말하지만 VectorCAST와 같은 툴교육을 직접 받아보면서 궁금한 점을 문의해 보시기 바란다. 한컴MDS와 같은 무료교육을 하는 곳을 추천한다.

 

Instrumentation이 코드를 변경하는가? 그렇다. 그리고 당신은 코드에 instrumentation이 남는 것을 원하지 않을 것이다. 만약 당신이 instrument를 한다면 그것이 다른 동작을 수행하지 않는다는 것을 증명하기위해 instrumenter를 인증받아야 한다.

 

DO-178B에서 구조적 커버리지 요구사항은 DO-178을 준수하기 위해 발생하게 되는 가장 비싼 추가 작업이라는 점은 의심의 여지가 없다. 구조적 커버리지는 당신의 시험 예산 중 반을 가볍게 사용하게 만들 수 있고 실제로 많은 회사들이 실제 코드 개발 자체에 대한 것 보다도 커버리지 분석과 시험 케이스에 더 많은 돈을 사용한다. 따라서 제대로 된 것을 구입하고 그것을 효과적으로 사용하는 법을 배우거나 그런 것을 하는 업체에 아웃소싱을 주고 당신의 시험 전략에 대해서 일찍 DER의 승인을 얻어라. 그러면 당신은 성공적인 인증의 길을 잘 유지하게 된다.

역주) 구조적 커버리지 분석을 위해서 툴을 직접 구매해서 자체적으로 모든 것을 진행할 지(물론 판매처의 컨설팅을 받기는 하겠지만) 아니면 아예 외부업체에 아웃소싱을 맡길지는 항상 고민스러운 부분이다. 당장 소요되는 비용을 어떻게 판단해야 할지, 향후 소요되는 비용은 또 어떻게 판단해야 할지도 명확하지 않다. 결국은 회사의 현재 상황에 대한 판단, 회사의 정책과 의지의 문제가 아닌가 싶다. 이런 거시적인 검토가 없이 현장의 개발자에게만 맡기는 것은 임시방편일 뿐이다. 물론 그런 ‘거시적인’ 검토가 불가능한 현실이라면 가장 ‘근시적인’ 현재 진행 중인 프로젝트의 일정과 상황에 가장 적합한 방법을 선택하는 수 밖에 없을 것이다.