AE Wiki

소프트웨어 테스팅

21 min read

정상 조건 및 비정상 조건(결함/버그) 사이의 차이점을 발견하기 위하여 소프트웨어 항목을 분석하고, 분석된 항목의 특성을 평가하는 프로세스 (IEEE Std 829)

결함을 발견하려는 의도를 가지고 프로그램을 실행하는 프로세스 (Glenford Myers)

검증과 확인의 동적(Dynamic) 기법의 본체. 테스트를 수행하기 위한 절차·산출물·종료 조건 등 조직 관점 활동은 소프트웨어 테스트 프로세스에서 별도로 다룬다.

품질 정의

정의자정의
W.E. Deming고객의 요구를 만족시키는 것
J.M. Juran품질은 사용 목적에 일치되는 정도
P.B. Crosby품질은 고객 요구사항(기대)에 대한 적합도
미국 국방부요구되는 기능을 발휘할 수 있는 SW 특성의 정도
Roger S. PressmanSW가 기능, 성능 및 만족도에서 명시되고 내재된 요구사항을 얼마나 충족하는가

→ 프로세스 품질과 제품 품질 두 관점으로 확보.

Error / Defect / Failure 용어

용어의미예시 (Speed = Distance/Time)
Error결함의 원인. 사람(개발자/분석가)에 의한 실수Didn’t think about the case of <time=0>
Defect (Fault, Bug)실패/고장의 원인. 제품에 포함된 결점There is no code for handling when <time=0>
Failure (Problem)결함이 실행될 때 발생하는 현상<Divide by Zero Exception> happened

안전 관점과의 비교: 결함 전파와 소프트웨어 안전 확보의 “Mistake → Fault → Error → Failure”는 ISO 26262 기능 안전 관점의 전파 모델. 위 표의 정의(IEEE/Myers)는 테스팅 관점이며 Error의 위치가 다르다 (테스팅에서 Error는 사람의 실수, 안전에서 Error는 시스템의 잘못된 상태).

Testing vs Debugging

구분테스팅디버깅
목적알려지지 않은 결함의 발견이미 알고 있는 결함의 수정
담당자시스템 내부 관련자, 외부 제3자(테스팅 팀)시스템 내부 관련자
주요 작업Fault DetectionFault Location → Identification → Correction

품질 향상 순서: 테스팅(결함 발견) → 디버깅(결함 수정) → 재테스팅(조치 확인) + 회귀 테스트(부작용 확인). → 회귀 테스트.

단계별 테스팅 활동

V-Model 우측에 매핑:

단계대상담당자환경방법
단위 테스팅단위 모듈(함수 등)개발자개발 환경White Box
통합 테스팅통합 모듈(인터페이스 등)개발자개발 환경Gray Box (W+B)
시스템 테스팅통합된 SW (기능/비기능)테스터(제3자)실제와 유사 환경Gray Box
인수 테스팅최종 SW (출시 예정)사용자, 고객실제 환경Black Box

단위 테스팅 상세

  • 목적: 설계된 모듈이 정확히 구현되었는지 확인 (요구사항 부합성)
  • 테스트 대상: 수행 기능(블랙박스) + 코드 내부 표현(화이트박스) + 경계 조건
  • 완료 시점: 개발자가 더 이상의 오류가 없다고 판단할 때
  • A-SPICE 매핑: SWE.4 Software Unit Verification

시스템 테스팅 상세

  • 수행 주체: 테스터(제3자)
  • 테스트 대상: SW 요구사항 명세서 기반 기능 요구사항 + 비기능 요구사항(보안/성능/신뢰성/UX) + 기능 안전 요구사항
  • 테스트 형상 고정: 고객 전달 직전 단계이므로 결함을 발견해도 수정만 하고 배포는 하지 않는다 — 테스트 중 형상 변경을 금지해 재현성·평가 타당성을 확보

인수 테스팅 상세

  • 위치: 실제 사용자 운영 환경. 인수 테스팅 통과 시 프로젝트 종료
  • 알파 테스트: 개발 조직 내부에서 사용자 역할로 수행하는 테스트 (제어된 환경)
  • 베타 테스트: 선별된 실제 사용자가 본인 환경에서 수행 (비제어 환경)
  • A-SPICE 매핑: VAL.1 Validation

블랙박스 / 화이트박스

구분블랙박스화이트박스
관점출력 값에만 초점모든 독립 경로 수행
TC 추출 원천요구사항 명세서, 설계서프로그램 소스 코드
별칭명세 기반 테스팅구조 기반 테스팅
구조입력 → Black Box → 출력입력 → 로직 → 출력

테스트 기법

“어떤 테스트를 수행해야 하는가?”(Methods for test)에 답하는 ISO 26262 Table 7/10/14의 5가지 기법. 블랙박스 관점이며 단위·통합·임베디드 SW 테스트 모두에 적용. ASIL별 권장도는 ISO 26262 테이블 참조.

1. 요구사항 기반 테스트 (Requirements-based Test)

요구사항 명세서를 Test Basis로 TC 도출. 모든 ASIL·모든 검증 단계에서 ++ 권장.

2. 인터페이스 테스트 (Interface Test)

인터페이스에 오류가 없음을 검증하기 위한 테스트

  • 단위 수준: 모듈 입력의 올바른 처리 여부 검증 (유효 입력값 + 비유효 입력값). 테스트 드라이버·스텁 필요.
  • 통합 수준: 다른 모듈과의 연계를 위한 출력 검증.

절차: (1) 대상 인터페이스 식별 → (2) 입력값 생성 → (3) 테스트 결과 확인.

3. 결함 주입 테스트 (Fault Injection Test)

설계의 안전 메커니즘이 올바로 동작하는지 확인하기 위해 임의의 결함을 주입하는 테스트

주입 방식 2가지:

  • 컴파일 시간 결함 주입 — 변수 값·소스코드 변경
  • 실시간(런타임) 결함 주입 — CPU 레지스터·메모리 값 변경

고려 사항:

  • 결함 주입을 위해 시스템·모듈 수정이 필요할 수 있음
  • 안전 메커니즘이 부적절하면 다른 모듈로 오류가 전파될 수 있음
  • 노력이 많이 드므로 ASIL 등급이 높은 부분에 집중

수행 절차 (6단계):

  1. 테스트 대상 모듈 선정 — 요구사항 추적표 기반, ASIL 등급 기준
  2. 결함 유형 식별 — 주입 시점(컴파일/실시간) + 주입 방식 분류
  3. 테스트 케이스 식별 — 결함 주입 전 상태 식별
  4. 결함 주입 테스트 실행
  5. 결함 주입 후 안전 메커니즘 동작 상태 식별 — 외부 시스템·SW·HW 결함에 대한 안전 메커니즘 동작 확인 + 내부 관련 값 변경으로 유사 상황 생성
  6. 시험 결과 분석 — 정상 상태와 결함 주입 후 상태의 데이터 비교

→ 결함 전파와 소프트웨어 안전 확보의 결함 감지 메커니즘 검증용.

4. 백투백 테스트 (Back-to-Back Test)

두 개 이상의 테스트 대상에 동일한 입력값으로 실행하여 결과를 비교 분석하는 테스트 기법

주 사용 예:

  • SW 모델과 소스코드 — Model-based Design 환경에서 생성된 자동 코드 검증
  • 시뮬레이터와 실제 타깃 보드 — 실행 환경 차이 검출

ISO 26262 Table 7 항목명: “Back-to-back comparison test between model and code, if applicable”.

5. 리소스 사용량 평가 (Resource Usage Evaluation)

CPU 부하, 메모리 사용량, 스택 깊이 등 자원 사용량 평가. 단위 테스트는 ASIL D에서 강력 권장, 통합 테스트는 ASIL B부터 강력 권장.

블랙박스 테스팅 기법

1. 신택스 테스팅 (Syntax Testing)

입력 값을 적합(Valid)/부적합(Invalid)으로 분류하여 TC 작성.

예: 사용자 이름 = “2자리 이상 8자리 이하 한글” → “홍길동”(적합), “흥”(길이 부족), “홍길동99”(숫자 포함) 등.

2. 동등 분할 (Equivalence Partitioning)

입력 값의 범위가 정해져 있을 때 각 범위의 대푯값으로 TC 작성.

예: 점수 범위 0-69(F), 70-79(C), 80-89(B), 90-100(A) → 각 범위에서 50, 75, 85, 95 사용.

3. 경계 값 분석 (Boundary Value Analysis)

입력 값의 경계 값(주요 오류 대상)으로 TC 작성.

기준 예시:

  • 범위가 A~B: A-1, A, A+1, B-1, B, B+1
  • MAX/MIN 명시: MAX, MAX+1, MIN, MIN-1
  • 배열/리스트: 첫 요소(Array[0])와 마지막 요소(Array[N-1])

4. 의사결정 테이블 (Decision Table)

입출력이 True/False일 때 모든 경우의 수에 대해 TC 작성.

예: 로그인 (ID T/F × PW T/F) = 4개 경우.

5. 페어와이즈 (Pairwise)

입력 파라미터 쌍(pair)의 각 개별 조합이 최소 한 번 나타나도록 TC 구성. 전수 조합을 포기하는 대신 2개 파라미터 조합까지는 완전 커버.

예: 3개 파라미터 × 각 2개 값 → 전수 조합 2³=8개, 페어와이즈 4개.

동작모드반복설정이퀄라이저
순차한곡Off
순차전체Live
랜덤한곡Live
랜덤전체Off

수작업 도출은 어려워 도구 활용이 권장됨 (예: Microsoft PICT).

6. 에러 추정 (Error Guessing)

과거의 경험이나 발견된 오류를 기반으로 TC를 식별하는 기법

사용 시점:

  • 요구사항 관련 산출물이 없거나 품질이 낮은 경우
  • 다른 기법을 보완하는 경우

기능 안전 적용: HARA로 식별한 해저드 목록이나 HAZOP Guide Word를 활용해 TC 도출. 과거 결함 DB와 결합 시 효과 극대화.

화이트박스 테스팅 — 커버리지

Coverage = (Number of coverage items exercised / Total number) × 100%

커버리지 포함 관계 (강한 → 약한)

All Path > Multiple Condition > MC/DC > Condition/Decision
        > Condition & Decision > Statement > Function

화이트박스 기법 7종

기법정의비율
함수 (Function)호출된 함수 / 전체 함수가장 낮은 커버리지. 단위 테스팅 100% 필수
문장 (Statement)실행된 문장(;로 끝나는 명령) / 전체 문장ISO 26262 Table — ASIL A/B 강력 권장
결정 (Decision)분기문 전체가 참 1번 + 거짓 1번 / 전체 분기분기(Branch) 커버리지. ASIL B/C/D 권장
조건 (Condition)&&/|| 전후 각 개별 조건이 참/거짓 1번 / 전체 조건전체 조건식 결과와 무관하게 개별 평가
조건/결정 (C/D)Condition + Decision 동시 만족
MC/DC각 조건이 독립적으로 결정 결과를 변경ASIL C/D 강력 권장
다중 조건 (Multiple Condition)모든 조건 조합
경로 (Basis Path)독립 경로 모두 수행가장 강한 구조 커버리지

각 커버리지 산출 공식과 특성

함수 (Function) — 테스트한 함수 / 전체 함수. 가장 낮은 강도. 단위 테스트에서 100% 쉽게 달성, 시스템 레벨에선 100%여도 완성도 보장 못함.

구문 (Statement) — 테스트한 구문 / 전체 구문 (구문 = ;로 끝나는 명령). 언어 기본 구성 단위 검증. 시스템이 복잡할수록 100% 달성 어려움.

결정/분기 (Decision/Branch) — 테스트한 Decision 수 / 전체 Decision 수. 분기문의 참·거짓을 한 번씩 테스트. 100% 달성 최대 TC 수 = 전체 조건문 수 × 2.

조건 (Condition) — 테스트한 조건 수 / (전체 조건 수 × 2). 연산자(&&/||/!) 없는 개별 Boolean 표현식마다 참·거짓 발생. 전체 식 결과와 무관하게 개별 평가.

조건/결정 (Condition/Decision) — 테스트한 condition/decision 수 / 전체 condition/decision 수. Condition과 Decision의 상호 보완 (어느 한쪽 100%가 다른 쪽 100%를 보장하지 않음).

MC/DC (Modified Condition/Decision) — 개별 조건이 전체 결정 결과에 영향을 미치는 조합을 강제. C/D의 한계(논리 오류 미검출) 보완. 최소 TC 수 = 개별 조건 수 + 1.

다중 조건 (Multiple Condition, MCC) — 모든 입출력 경우의 수 조합. 가장 강한 테스트. TC 수 = 2^(개별 조건 수).

Condition vs Decision 한계

Z = A && B 의 진리표:

#ABZ
1TTT
2TFF
3FTF
4FFF
  • TC {2, 3}: Condition 100% (A·B 각각 T/F 모두 나타남) / Decision 50% (Z=F만)
  • TC {1, 4}: Condition 100% (A·B 각각 T/F 모두) / Decision 100% (Z=T, F 모두)

→ Condition 100% ≠ Decision 100%. 반대 방향도 성립. 두 커버리지가 서로를 보장하지 못하므로 C/D 커버리지로 함께 측정.

MC/DC 개선 배경

C/D 커버리지도 개발자의 논리 오류(예: &&를 ||로 잘못 코딩)를 발견하지 못할 수 있음. MC/DC는 각 개별 조건이 단독으로 전체 결과를 바꾸는 경우를 강제해 논리 오류 검출력을 확보.

MC/DC vs MCC 강도 비교

기법최소 TC 수n=4n=10
MC/DCn + 1511
MCC2^n161,024

MC/DC의 효과성: 전수 테스트(MCC) 대비 약 94%의 결함 검출. ASIL D에서 MC/DC를 강력 권장하는 근거.

도구 지원: C용 테스트 도구는 MC/DC 자동 생성 가능. Java 계열 도구는 MC/DC 계산을 지원하지 않는 경우가 있음.

ISO 26262 구조적 커버리지 요건

Basis Path Coverage (Tom McCabe)

순환 복잡도 V(G)를 활용한 경로 테스팅의 4단계.

단계 1. Flow Graph 작성

플로우 그래프 구조 요소:

  • Sequence
  • Selection (If, else)
  • Iteration (While)

소스 코드의 제어 흐름을 노드(Node)와 엣지(Edge)로 표현. Predicate Node = 조건 노드.

단계 2. 순환 복잡도 계산

  • V(G) = R (영역 수)
  • V(G) = E - N + 2
  • V(G) = P + 1

단계 3. 독립 경로 정의

V(G)개의 독립 경로를 도출.

단계 4. 테스트 케이스 작성

각 경로를 수행할 입력 값을 결정.

예시 — 성적 관리 프로그램 (V(G)=3)

경로 1: 1-2-3-2-4-5-6-8 → 입력 (70, 75) 후 (80) → "PASS"
경로 2: 1-2-3-2-4-5-7-8 → 입력 (60, 65) 후 (50) → "FAIL"
경로 3: 1-2-4-5-6-8     → 입력 (70, 90, 80) 후 없음 → "PASS"

시스템 검증 vs 소프트웨어 검증

테스트 항목과 환경에 따른 두 검증의 구분.

테스트 항목

구분포함 범위
시스템 검증하드웨어적 요소 포함
SW 검증소스코드 수준 검증 포함

테스트 환경

구분환경
시스템 검증HW + SW 통합 환경, 서브 시스템 간 통합 환경 → HIL 활용
SW 검증테스트 보드, 에뮬레이터, 가상 환경 → SIL / PIL / HIL 적극 활용

In-the-Loop 환경 (MIL / SIL / PIL / HIL)

테스트 환경의 특정 요소(모델·프로세서·SW·HW·차량)가 실제 테스트 흐름(loop) 안에서 연동되어 검증되는 방식. 단계가 올라갈수록 실차에 가까워진다.

약어명칭대상
MILModel-in-the-Loop모델 수준(Simulink 등)에서 제어 로직 검증
SILSoftware-in-the-LoopPC 환경에서 SW만 시뮬레이션 모델로 검증
PILProcessor-in-the-Loop타깃 프로세서에 코드를 올려 동작 검증
HILHardware-in-the-Loop실 하드웨어(ECU 등)와 시뮬레이터 결합 검증

→ V-Model 우측에서 단계가 올라갈수록 시스템 검증에 가까워진다. ISO 26262는 단위/통합 단계는 MIL~HIL 선택, SW 테스팅 단계는 최소 HIL 이상을 요구.

테스트 환경 주요 용어

용어정의
테스트 하네스 (Test Harness)테스트를 실행·제어하기 위해 필요한 도구·스크립트·HW·SW의 집합
테스트 환경 (Test Environment)테스트 수행에 필요한 HW·SW·펌웨어·절차·문서·데이터·도구·지원 요소의 조합
테스트 드라이버 (Test Driver)테스트 대상을 호출하고 입력값 전달·결과 수집하는 임시 모듈 (상향식 통합 시 상위 대체)
테스트 스텁 (Stub)테스트 대상이 호출하는 하위 모듈을 단순화해 제공하는 임시 모듈 (하향식 통합 시 하위 대체)

→ 드라이버·스텁 상세는 통합 방식 3종 참조.

A-SPICE 프로세스 매핑

단계A-SPICEA-SPICE 페이지 참조
단위 테스팅 (정적+동적)SWE.4 Software Unit VerificationBP1-7
통합 테스팅SWE.5 Software Integration and Integration TestBP1-9
인수 테스팅 (요구사항 기반)SWE.6 Software Qualification TestBP1-7
사용자 환경 검증VAL.1 Validation(사용자/고객 관점)

같이 보기

그래프 뷰

백링크