- 본 글은 무기체계 소프트웨어의 동적시험을 소개하는 글이며, ‘방위사업청 매뉴얼 제2020-8호’에 참고하여 작성하였다.
동적시험
- 소프트웨어를 실제 하드웨어(Target)에 탑재한 상태에서 소프트웨어통합시험절차서에 기술된 시험절차에 따라 요구사항기반으로 소프트웨어 코드 실행률(Coverage)을 점검하는 것을 말한다.
- 동적 시험을 수행함으로서 소스코드의 구조적 결함뿐 아니라 통합된 소프트웨어의 기능적 결함을 함께 검출하고, 요구사항 기반으로 설계된 소프트웨어 통합시험 절차서의 시험 충분성을 검증한다.
- 소프트웨어를 실제 하드웨어(타겟)에 탑재한 상태에서 수행한다. 타겟에서 테스트를 수행하는 이유는 타겟 환경의 경우 하드웨어에 사양(레지스터리 등)에 의해서 호스트 환경과 다른 결과를 얻을 수 있기 때문이다.
- 동적시험 커버리지 종류(문장, 분기, MC/DC) 커버리지를 100% 목표로 채워야 하며, 예외사항(방어코드, 협의된 코드 등)은 커버리지에서 제외할 수 있다.
- 고신뢰 소프트웨어인 항공 시스템의 경우, DO-178과 감항 인증 관점에서 Control Coupling, Data Coupling 문서를 요구할 때 단위 시험만을 통하여 커버리지를 태운다.
- 동적 시험 끝난 뒤, 동적시험 결과서와 커버리지 미달성 사유서(존재하는 경우)를 작성해야 한다.
무기체계 소프트웨어에서 Top-down(하향식) 테스팅
- 무기체계 소프트웨어에서 동적시험은 Top-down 테스팅으로 수행된다. 가장 상위 수준의 컴포넌트들의 기능 먼저 테스트하는 통합 시험 수행 후 단위 시험을 수행하는 방법이다. 테스트된 컴포넌트는 하위 수준의 컴포넌트를 테스트하는데 사용된다. 가장 하위 레벨의 컴포넌트를 테스트 할 때까지 해당 절차가 반복된다.
- 무기체계 소프트웨어에서는 요구사항 기반 시험(통합 테스팅)을 통하여 커버리지를 빠르게 확보하고, 부족한 커버리지는 단위시험을 하여 확보하거나 동적시험 미달성 보고서를 작성한다.
동적시험 추세 현황
- 22.07 기준으로 동적시험 추세 현황이다. (모든 동적시험 수행 현황이 아님을 강조 드립니다.)
- 동적시험은 요구사항 기반 시험으로만 동적 시험을 진행하려고 하는 추세다.
- 윈도우 GUI 프로젝트들은 과거 C++ MFC 프로젝트 대신 생산성이 좋은 C# 프로젝트로 대체하여 개발하는 사례가 많아지고 있다.
- 윈도우 환경에서 수행되는 소프트웨어(Visual Studio MFC, C#) 프로젝트들은 윈도우 환경에서 요구사항 기반 시험만을 수행하고, 채우지 못한 커버리지는 동적시험 미달성 보고서를 작성한다.
- 타겟 환경에 탑재되어 수행되는 대규모 임베디드시스템 소프트웨어 프로젝트들은 타겟 환경에서 요구사항 기반 시험만을 수행하고, 채우지 못한 커버리지는 호스트(윈도우 또는 리눅스) 환경에서 동적시험을 수행한다.
- 타겟 환경에 탑재되어 수행되는 소규모 임베디드시스템 소프트웨어 프로젝트들은 타겟 환경에서 요구사항 기반 시험 후, 동적시험 미달성 보고서를 작성한다.
- 타겟에서 수행하는 단위시험은 호스트에서 수행하는 단위시험 보다 2배 많은 공수(타겟에 탐침코드가 삽입된 코드 수행 후 커버리지 불러오기에 많은 시간 소요)가 소요되고 구조기반 시험 환경 설정이 어려우므로(타겟 메모리 환경 고려 필요), 개발자에게 많은 부담이 간다. 단위 시험을 수행하면 동적시험 미달성 보고서를 적게 작성할 수 있지만, 단위 시험 수행에 공수가 많이 소요되므로 상황에 따라 선택해야 한다.
동적시험 종류
1. 요구사항 기반 시험
- 소프트웨어 요구사항 명세서에 정의된 요구사항들을 통합된 소프트웨어로 수행한다.
- 명세의 오류나 기능적 결함을 검출하고 수행하여 측정된 코드 실행률을 점검한다.
- 요구사항 기반으로 코드 실행률을 점검하는 grey box 테스팅이다.
- 요구사항 기반 시험만으로는 소스 코드상의 방어코드 및 소스 코드의 확장성 등의 부수적인 문제로 인하여 코드 실행률의 목표값 100%를 달성하기 어렵다.
- Top-Down(하향식) 방식을 적용하여 요구사항 기반 시험 후 목표값 미충족 부분에 한해 구조기반 시험을 수행 해야한다.
- 요구사항기반 시험 절차는 다음과 같다.
- 요구사항 정의서와 같은 기술 문서를 분석하여, 소프트웨어 통합시험 절차서 작성
- 소프트웨어 통합시험절차서에 기술된 시험절차에 따라 통합 시험 수행(입력 값 생성)
- 타겟기반으로 테스팅을 수행하여 출력 값 확인
2. 단위 시험(구조 기반 시험)
- 소스 코드의 내부 구조를 분석하고 변수값을 제어하여 함수의 동작을 확인하는 White-Box 시험으로 소스 코드의 구조적 결함을 검출한다.
- 요구사항 기반 시험에서 채우지 못한 커버리지는 단위 시험을 통하여 채운다.
- 목표값 미달시 시험대상 소프트웨어 소스 코드를 수정하거나 또는 필요한 조치를 취한 후 재시험하여 목표값 달성 여부를 확인한다.
- 방어 코드(Defensive Code), 무한 반복문 등 소프트웨어 신뢰성 시험 도구의 한계로 인하여 목표값을 달성 할 수 없는 경우에는 동적시험 미달성 분석 보고서를 작성해야 한다.
방사청 ‘무기체계 SW 메뉴얼 관점’에서의 단위 시험
- 방사청 무기체계 SW 메뉴얼에서는 요구사항 기반 시험 이후 커버리지가 타지 않는 부분에 대해서 단위 시험 수행을 명시하지 않는다. SW 신뢰성 향상을 위해서, 미달성 보고서 작성을 줄이기 위해서 회사에서는 단위 시험을 수행할 것을 권고한다.
- 구조기반(단위) 시험 여부는 협의에 따라 다르다. 개발자가 소프트웨어통합시험계획서(STP)를 작성할 때 단위 시험 방향성이 결정된다. 사업 관리 기관에 따라서 단위 시험을 요구하는 경우도 있다.
- 한화시스템 측에서는 요구사항 기반 시험으로만 동적 시험을 진행하려고 하는 상황이다.
동적시험 대상
- 자동 생성 코드는 동적시험 대상이다.
- 무한 반복문은 분기문을 벗어날 수 없으므로 커버리지를 태울 수 없다.
- 신뢰성 시험에서는 디버그 모드에서 값을 변수의 값을 변경하여 커버리지를 태우면 안된다.
- 요구사항 기반 동적시험 커버리지가 높다는 것은, 예외 처리 및 방어 코드(if 구문만 있고 else 구문이 없음, switch case 문의 default 문 없음)가 없는 것을 의미한다. 이는 프로그램 안전성
- 소스 코드 형상이 변경된다면(수정이 발생된다면) 정적 시험 및 동적 시험을 다시 수행해야 한다.
- asm 코드는 동적시험 제외 대상으로 동적시험 미달성 사유서에 작성한다.
동적시험 커버리지 종류
- 커버리지: 소프트웨어 테스트가 충분히 수행되어는가를 나타내는 지표 중 하나로서 말 그대로 테스트를 진행했을 때 코드 자체가 얼마나 실행되었나를 비율로 표현한 것이다.
문장(Statement) 커버리지
- 코드 실행률의 가장 기본적인 수준에 해당되는 것으로 시험대상 소프트웨어 소스 코드내의 문장 중 동적시험간 적어도 한 번 이상 시험된 문장의 비율(%)을 의미한다.
분기(Branch) 커버리지
- 시험대상 소프트웨어 소스 코드내의 분기문 중 동적시험간 참(True), 거짓(False)이 적어도 한 번 이상 시험된 비율(%)을 의미한다.
MC/DC(Modified Condition/Decision Coverage) 커버리지
- 가장 높은 수준의 코드 실행률로써 시험대상 소프트웨어 소스 코드내 분기문에 있는 모든 조건식 중 개별 조건식의 독립적인 변화가 분기문의 참, 거짓에 영향을 미치는 모든 조합에 대해 동적시험간 적어도 한 번 이상 시험된 비율(%)을 의미한다.
ex) OR 연산자 기준 설명
조건 A가 T로 고정이고 조건 B가 T 또는 F로 변경 된다면, 이는 결과에 영향을 미치지 않는다.
조건 B가 T로 고정이고 조건 A가 T 또는 F로 변경 된다면, 이는 결과에 영향을 미친다.
조건 A가 F로 고정이고 조건 B가 T 또는 F로 변경 된다면, 이는 결과에 영향을 미친다.
조건 B가 F로 고정이고 조건 A가 T 또는 F로 변경 된다면, 이는 결과에 영향을 미치지 않는다.
따라서 조건 A와 조건 B가 T인 경우는 MC/DC 커버리지의 테스트케이스가 될 수 없다.
ex) AND 연산자 기준 설명
조건 A가 T로 고정이고 조건 B가 T 또는 F로 변경 된다면, 이는 결과에 영향을 미친다.
조건 B가 T로 고정이고 조건 A가 T 또는 F로 변경 된다면, 이는 결과에 영향을 미친다.
조건 A가 F로 고정이고 조건 B가 T 또는 F로 변경 된다면, 이는 결과에 영향을 미치지 않는다.
조건 B가 F로 고정이고 조건 A가 T 또는 F로 변경 된다면, 이는 결과에 영향을 미치지 않는다.
따라서 조건 A와 조건 B가 F인 경우는 MC/DC 커버리지의 테스트케이스가 될 수 없다.
출처: https://m.blog.naver.com/PostView.nhn?blogId=suresofttech&logNo=220636029506&proxyReferer=https%3A%2F%2Fwww.google.com%2F
https://m.blog.naver.com/shiftspace/220561755364
함수 호출 커버리지
- 호출 함수의 수를 전체 실행 가능한 함수의 수로 나누어 백분률로 표현한 것
함수 커버리지
- 실행된 함수의 수를 전체 실행 가능한 함수의 수로 나누어 백분률로 표현한 것
시험 기준 설정 방법
- 결함의 발생빈도, 영향성 및 제어가능성을 평가한 후 수준별로 코드실행률과 시험종류를 설정한다.
- 체계/사업 특성에 따라 관련 국제 표준(MIL-STD-882E, DO-178, IEC 61508, ISO 26262 등)을 적용하여 개발할 경우에는 해당 표준을 따를 수 있으며, 주체계 운영과 직접적인 관련이 없는 장비(예: 지원장비, CBT(Computer based training) 등)는 동적시험을 제외할 수 있다. 세부 설정 기준
- S: 문장(Statement), B: 분기(Branch), M: MC/DC(Modified Condition/Decision Coverage)
결함 영향도
- (한등급간 차이 10배 수준)
결함 발생빈도
- (한등급간 차이 10배 수준)
결함 제어 가능성
- (한등급간 차이 10배 수준)
Comments powered by Disqus.