자동차의 전자제어장치(ECU) 수가 많아지고 그에 따른 개발 과정과 기능안전성에 대한 국제 규격인 ISO 26262의 충족이 필수 요구사항으로 대두되고 있다. ISO 26262에서는 최신 개발방법 및 테스트 방법을 적용하도록 하고 있다. 그러나 표준의 특성상 어떻게 적용해야 하는지 설명은 부족한 측면이 있다. 이 글은 그 중에서도 소프트웨어 테스팅 측면에서 표준을 어떻게 적용해야 하는지를 살펴본다.

글│노 경 현 <khroh@tqms.co.kr> 테스팅 전문가(ISTQB), 자동차 분야 CMMI 및 ISO 26262 컨설팅 ㈜티큐엠에스

ISO 26262 Part 6에서는 그림 1과 같이 테스트 레벨별로 수행해야하는 테스트 방법 및 지표를 규정하고 있다. 이에 각 테스트 방법 및 지표별로 어떻게 적용해야 할지 살펴본다.

소프트웨어 단위 테스팅 방법

소프트웨어 테스트는 구현된 코드의 내부를 분석해 수행하는 화이트 박스 테스트(White Box Test)와 코드 내부가 아닌 기능 명세를 기반으로 수행하는 블랙 박스 테스트(Black Box Test)로 구분할 수 있다. 단위 테스팅은 이 중에서 화이트 박스 테스트 방법으로 구현된 코드를 참조한다. 여기서 단위는 소스코드의 그룹으로 안전 기능과 관련된 단일 함수 또는 관련된 함수의 그룹, 함수들을 포함하는 하나의 파일이 될 수 있다. ISO 26262 Part 6, 9항에서는 구현된 소프트웨어 각 단위가 단위 설계 명세를 충족하고 요구되지 않는 기능을 포함하지 않는 것을 입증하기 위해 소프트웨어 단위 테스팅을 수행하도록 규정하고 있다. ASIL(Automotive Safety Integrity Levels) 등급별로 적용해야 하는 테스트 방법은 표 1과 같다.
ASIL 등급별로 표시된 ++ 표시는 해당 등급별로 반드시 적용해야 하는 테스트 방법이며, + 표시는 해당 등급별로 권장되는 테스트 방법이다. 가장 높은 등급인 ASIL D 등급에서는 명시된 모든 테스트 방법을 사용해 단위 테스트를 수행해야 한다.

요구사항 기반 테스트
요구사항 기반 테스트는 모든 ASIL 등급에서 필수적으로 적용되는 방법이다. 단위 테스트를 수행할 때 개념 단계에서 도출되는 기능안전 요구사항에 기반하며 추적 가능해야 한다. 이를 위해서는 기능안전 요구사항별로 식별자를 부여해 각 단위 테스트 항목별로 추적성을 부여해야 한다.

인터페이스 테스트
인터페이스 테스트는 모든 ASIL 등급에서 안전 관련 기능이 구현된 단위에서 필수적으로 수행돼야 한다. 인터페이스는 소프트웨어 관련 단위 사이의 인터페이스, 해당 소프트웨어 단위와 하드웨어의 인터페이스 검증을 포함한다. 인터페이스 테스트는 주로 인터페이스에 포함된 변수들을 대상으로 한다. 인터페이스 테스트를 수행하기 위해서는 구현된 단위의 인터페이스와 직접 연결되는 단위가 있어야 한다. 다른 방법으로는 인터페이스 테스트에 필요한 정보를 발생시켜 주는 시뮬레이터를 사용할 수 있다. 시뮬레이터를 만드는 작업이 필요하지만 다른 단위와 관계없이 해당 단위의 인터페이스를 확인할 수 있는 장점이 있다.

결함 주입 테스트
결함 주입 테스트는 임의적으로 결함을 주입해 안전 기능의 견고성을 검증하는 방법이다. 임의적인 결함 주입 방법에는 결함을 발생시키는 변수 값 및 CPU 레지스터 값 생성, 코드 뮤테이션 적용 등을 사용할 수 있다. 결함 주입 테스트를 통해 안전 기능이 예상치 못한 상황에서도 적절하게 통제해 견고성을 유지하는 것을 검증할 수 있다.

자원 사용량 테스트
자원 사용량 테스트는 단위 테스트가 실행될 때 사용되는 CPU, 메모리 등의 자원이 어느 정도 소비되는지 검증한다. 일부 자원은 소프트웨어 단위 테스트가 타깃 보드에서 실행될 때, 또는 타깃 프로세서의 에뮬레이터가 자원 사용량 테스트를 지원하는 경우 적절하게 수행될 수 있다.

모델과 코드의 백-투-백 비교 테스트
소프트웨어 개발 시 모델 기반 개발을 통해 개발의 효율성과 품질을 높일 수 있다. 모델은 개발하려는 단위의 기능을 UML과 같이 그래픽으로 표현하고 상용 툴에서는 자동으로 코드를 생성 및 검증하는 기능을 제공한다. 이 때 단위 기능을 시뮬레이션 할 수 있는 경우 모델과 코드에서의 단위 기능과 결과를 서로 비교할 수 있다.


소프트웨어 단위 테스팅 테스트 케이스 도출 방법

테스트 케이스를 개발하는 것은 테스트 활동에 있어서 테스트 설계에 해당한다. 테스트 케이스는 테스트 대상을 동작시키고 그 반응이 올바른지, 명세와 일치하는지 확인하기 위해 필요하다. 테스트를 효과적으로 수행하기 위해 적합한 테스트 케이스 설계는 필수적이다. 일반적으로 테스트 케이스 식별자, 테스트 사전 조건, 테스트 수행 절차, 테스트 기대 결과로 구성된다. ASIL 등급에 따라 표 2와 같은 테스트 케이스 도출 방법을 사용하도록 하고 있다.

요구사항 분석
요구사항 분석은 테스트 케이스 도출 시 모든 ASIL 등급에서 필수적으로 수행해야 한다. 기능안전 요구사항에 대한 분석은 단위 테스트 방법의 요구사항 기반 테스트뿐만 아니라, 다른 테스트 방법에서 기본적인 테스트 케이스 도출 방법이 된다.

동등 클래스 생성 및 분석
동등 클래스 생성 및 분석은 입력 값과 출력 값 영역을 상호 독립적인 집합으로 나누어 각 동등 집합의 대표 값을 선택해서 테스트 케이스를 도출하는 것이다. 입력 값과 조건을 분석하면 테스트 케이스를 설계할 수 있다. 예를 들어 0부터 3000 이상의 입력 값에 대해서 유효한 동등 클래스 1개, 유효하지 않은 동등 클래스 4개를 생성하여 각 클래스를 대표하는 값을 하나씩 선정하는 경우 전체 5개의 테스트 케이스를 설계할 수 있다(그림 2).

경계 값 분석
경계 값 분석은 일반적으로 입력 값의 경계 값 근처에서 에러가 발생할 확률이 높기 때문에, 이를 방지하기 위한 테스트 케이스 도출 방법이다. 입력 조건이 값의 범위라면 범위의 끝부분의 유효한 값과 그 보다 위와 아래의 유효하지 않은 값으로 테스트 케이스를 도출하고, 입력 조건이 테이블이나 일렬 리스트와 같은 정렬된 집합이라면 집합 중 첫째 원소와 마지막 원소에 근거해서 테스트 케이스를 도출한다. 예를 들면 그림 3과 같은 경우에 동등 클래스의 경계 값을 근거로 해 테스트 케이스를 도출할 수 있다.

에러 추정
에러 추정은 이전에 수행했던 경험과 전문가적인 지식에 기반해 테스트 케이스를 도출하는 것이다. 이 방법은 요구사항 분석, 동등 클래스 생성 및 분석, 경계 값 분석이 안전 기능 사항에 대한 명세를 기반으로 하는 것을 보완해 다루기 어려운 특별한 테스트 케이스를 도출하기에 유용하다. 가능한 오류를 모두 나열하고 이런 유형의 결함 또는 오류를 공격할 수 있도록 테스트 케이스를 개발하는 것이 효과적이다.

소프트웨어 단위 테스트 케이스의 완전성 확인

시스템 또는 소프트웨어의 구조가 테스트 케이스에 의해 테스트된 정도를 커버리지라고 하며 특정 구조의 종류에 대해서 커버된 백분율로 표시한다. 단위 테스트에서는 표 3과 같은 구조 커버리지를 사용해서 테스트 케이스가 적절하게 도출했는지 검증하게 된다. 커버리지별로 달성해야 하는 목표치는 제품 특성에 따라 정하게 된다. 구조 커버리지 지표를 사용해 요구사항 기반 테스트 케이스에서 간과된 부분, 요구사항의 부적절, 사용되지 않는 코드(dead code), 비활성화 된 코드 또는 의도하지 않은 기능들을 파악할 수 있다. 일반적으로 구조 커버리지는 적절한 소프트웨어 툴을 사용해 측정할 수 있으며, 이를 지원하는 오픈 소스 테스팅 툴 또는 사용 툴이 존재한다. 커버리지에는 구문 커버리지, 분기 커버리지, MC/DC 커버리지가 있는데, 이 중에서 MC/DC 커버리지가 가장 넓은 커버리지 범위를 가진다. ASIL 등급이 높을수록 넓은 커버리지를 요구해 ASIL D에서는 분기 커버리지와 MC/DC 커버리지가 필수 사항이다.

구문 커버리지
구문 커버리지는 테스트 케이스를 통해 실행된 구문이 몇 퍼센트인지 측정한다. 그림 4와 같은 경우 구문 커버리지를 사용한다면 foo(0,0,0,0,0), foo(1,1,1,1,1)과 같이 전체 문장을 한 번씩 실행하도록 테스트 케이스를 도출하고 구문 커버리지를 측정한다.



분기 커버리지
분기 커버리지는 테스트 케이스를 통해서 수행되는 분기점(참, 거짓)에서 최소한 참(True)이 한 번, 그리고 거짓(False)이 한 번의 값을 갖는지 측정해 퍼센트로 표현한다. 그림 5와 같은 경우는 3번 라인과 7번 라인의 분기점별로 커버리지를 측정한다. 3번 라인에서는 foo(0,0,0,0,0), foo(1,1,1,1,1) 일 때 참과 거짓을 각각 실행하고, 7번 라인에서는 foo (1,1,1,1,1), foo(1,2,1,2,1) 일 때 참과 거짓을 실행하도록 테스트 케이스를 도출해 분기 커버리지를 측정할 수 있다.

MC/DC(변경 조건/결정 커버리지)
MC/DC 커버리지는 각 개별 조건식이 다른 개별 조건식에 무관하게 전체 조건식의 결과에 독립적으로 영향을 주도록 한 것이다. MC/DC 커버리지는 구문 커버리지와 분기 커버리지보다 넓은 범위의 커버리지를 가진다.

소프트웨어 통합 테스팅 방법

소프트웨어 통합 테스팅에서는 소프트웨어 아키텍처 설계의 준수, 하드웨어와 소프트웨어의 인터페이스 명세 준수, 기능성, 사용량의 적절성 등을 검증하게 된다. 통합 테스팅 방법은 표 4와 같이 단위 테스팅에서 적용된 방법과 동일한 방법을 사용한다. 이 때 요구사항 기반 테스트의 기반 문서는 아키텍처 레벨이 된다. 결함 주입 테스트는 안정성 메커니즘을 시험하기 위해 임의로 결함을 주입하게 된다. 자원 사용량 테스트는 평균과 최대 프로세서 성능, 최소 또는 최대 실행 시간, RAM 용량 등이 요구사항을 수행하기에 적합한지 검증하게 된다. 모델과 코드의 백-투-백 비교 테스트는 모델이 소프트웨어 컴포넌트의 기능을 시뮬레이션 할 수 있어야 한다.



소프트웨어 통합 테스팅의 테스트 케이스 도출 방법

소프트웨어 통합 테스팅에서 테스트 케이스를 도출할 때 사용하는 방법은 표 5와 같다. 동등 클래스 생성 및 분석은 선택된 각 클래스별로 대표적인 테스트 값과 같은 입력과 출력의 분할에 기초해서 식별할 수 있다. 경계 값 분석은 범위 값의 경계에 있는 변수 또는 값들에 적용된다. 에러 추정 시험은 기존의 시험 결과에서 교훈점과 전문가적인 판단을 통해서 수집된 데이터에 기초할 수 있다. 경험적인 테스팅 방법이 여기에 포함될 수 있다.

소프트웨어 통합 테스트 케이스의 완전성 확인

소프트웨어 통합 테스트 케이스 도출이 적절한지 평가하기 위해 소프트웨어 아키텍처 레벨의 요구사항 커버리지 지표를 사용한다. 함수 커버리지는 도출된 통합된 테스트 케이스를 실행했을 때 전체 소프트웨어 함수 대비 실행된 함수의 비율을 말하며 이를 통해 검증하게 된다. 호출 커버리지는 소프트웨어 함수 호출이 어느 정도 실행되었는지 비율을 측정하는 것이다. ASIL C와 D에서는 두 가지 지표를 모두 사용해야 한다. 함수나 함수 호출은 적어도 한 번 이상은 실행돼야 한다.

ISO 26262에서는 기능안전 관련 제품 개발 수명주기로 V 모델을 사용하고 있다. V 모델은 개발뿐만 아니라 테스팅을 통한 검증을 하나의 축으로 요구한다. ISO 26262에 대응하기 위해서는 개발뿐만 아니라 테스팅도 ASIL 등급에 따라 적절하게 수행돼야 한다. 이를 위해서는 각 테스팅 방법 및 커버리지에 대해서 충분히 이해하고 적용할 수 있어야 한다. 지금까지 ISO 26262 Part 6에 명시된 소프트웨어 단위 테스팅 및 통합 테스팅 방법, 그리고 커버리지 지표를 살펴봤다. 지면 관계상 각 방법에 대해서 좀 더 자세히 다루지 못한 관계로 다음을 기약하기로 한다.