AE Wiki

소프트웨어 테스트 프로세스

11 min read

결함을 식별하고 소프트웨어 산출물의 품질을 평가하는 일련의 활동 (IEEE Standard for Software and System Test Documentation, 2008)

SW 테스팅을 수행하기 위한 절차/방법, 도구/장비, 인력의 통합. 테스트 기법이 “어떻게(HOW) 결함을 찾을 것인가”라면, 프로세스는 “언제(WHEN) 무엇을(WHAT) 누가 어떻게 조직할 것인가”를 다룬다.

테스트 프로세스 — 7개 활동

ISO/IEC/IEEE 29119 기준 7개 활동. 선형이 아니라 PDCA 사이클로 반복된다.

#활동의미
1Test Planning테스트 목표·범위·전략·일정 계획
2Test Monitoring and Control계획 대비 진척·이슈 모니터링, 시정 조치
3Test AnalysisTest Basis 분석, 테스트 조건·우선순위 도출
4Test Design테스트 케이스·프로시저 설계
5Test Implementation테스트 스위트·데이터·환경 구축
6Test Execution케이스 실행, 결과 기록·비교
7Test Completion종료 조건 확인, 보고서·테스트웨어 보관

PDCA 관점 매핑

PDCA테스트 활동산출물
P (Plan)테스트 계획 수립, Feature 선정테스트 계획서
P (Plan)테스트 케이스·절차 개발, 환경 준비테스트 설계 명세서, 테스트 절차서
D (Do)테스트 준비·실행, 결과 판정테스트 로그/일지, 결함·문제점 보고서
C / A (Check)결과 분석·평가, 대책 수립·시정 권고테스트 요약 보고서/결과서

테스트 계획 (Test Plan)

테스트 목표를 정의하고 대상·범위를 결정하여 계획서를 작성·검토.

능력 수준 1 기본 항목

  • 테스트 대상 (test items)
  • 테스트 범위 (test scope)
  • 테스트 방법 (test approach)
  • 테스트 설계 기법 (test design techniques)
  • 테스트 데이터 요구사항
  • 테스트 환경 요구사항
  • 테스트 결과물 (test deliverables)

능력 수준 2 이상 추가 항목

  • 목표 및 목표 달성 방안
  • 계획 작성 책임자
  • 제약 사항, 관련 위험
  • 스케줄·마일스톤·목표일
  • 주요 의존성
  • 시간·인원·재료/장비·예산

→ 프로세스 능력 수준 기준 상위 레벨일수록 정량적 관리 항목이 추가됨.

테스트 베이시스 (Test Basis)

테스트 케이스를 작성하기 위한 근거 산출물 (used as the basis for designing and implementing test cases — ISO/IEC/IEEE 29119)

“어떤 활동/산출물을 근거로 테스트를 수행할 것인가?”

V-Model 좌측 각 산출물이 우측 테스트의 베이시스가 된다.

V-Model 좌측 산출물대응 테스트 베이시스로 사용되는 레벨
요구사항 정의서인수 테스트 베이시스
요구사항 분석서시스템 테스트 베이시스
아키텍처 설계서통합 테스트 베이시스
상세 설계서단위 테스트 베이시스

→ 추적성과 일관성을 통해 베이시스 산출물과 테스트 케이스 간 양방향 연결이 유지되어야 한다.

테스트 케이스 (Test Case)

특정한 요구사항이 제대로 구현되었는지 검증하기 위하여 테스트 조건, 입력 값, 예상 출력 값, 실제 수행한 결과를 기록하는 것

필수 항목

  • 입력값
  • 테스트 절차
  • 예상 출력값
  • 예상 출력값과 실제 출력값의 비교
  • 일치 여부 판정 → Pass / Fail (결함)

작성 시점 — V-Model 매핑

테스트 케이스는 테스트 실행 직전이 아니라 베이시스 산출물이 작성되는 시점에 함께 작성한다. 작성 과정 자체가 베이시스 품질을 개선한다 (모호성 발견).

V-Model 좌측테스트 케이스
요구사항 정의인수 테스트 케이스
요구사항 분석시스템 테스트 케이스
상위설계통합 테스트 케이스
상세설계단위 테스트 케이스

→ V-Model의 Shift Left 원칙과 결이 같음. 산출물 명세서와 테스트 케이스의 왕복이 곧 검토 과정.

테스트웨어 주요 용어

용어정의
Testware소프트웨어 테스트 수행에 필요한 모든 산출물. 문서·도구·데이터·환경 포함
Test Suite특정 테스트 목표를 위해 함께 실행되는 테스트 케이스의 집합 (예: 회원가입 TC 모음)
Test Scenario사용자 실제 행동 기반으로 여러 TC를 묶은 흐름 (예: 회원가입 → 로그인 → 결제)
Test Data테스트 중 사용되는 데이터. 입력값·예상 결과·파일·DB 등 포함

테스트 커버리지

테스트 케이스 수행 시 테스트 대상을 몇 %나 실행했는지 알려주는 지표

2가지 축

유형의미주 사용 기법
요구사항 커버리지TC가 요구사항을 얼마만큼 실행했는지 측정블랙박스 (소프트웨어 테스팅)
소스코드 커버리지TC가 소스코드를 얼마만큼 실행했는지 측정화이트박스 (소프트웨어 테스팅)

계산

Coverage = (Exercised items / Total items) × 100%

예시:

  • 요구사항: 전체 30개 중 15개 테스트 → 50%
  • 문장 커버리지: 전체 문장 중 40% 실행
  • 결정 커버리지: 전체 if 문의 60% 참/거짓 평가

테스트 실행 — 결함 추적 및 기록

Test Execution 활동의 핵심 부산물은 검출된 결함의 추적·기록이다. 개발자와 테스터 간 결함 전달 사이클:

  1. 개발자가 SW를 테스터에게 전달
  2. 테스터가 테스트 케이스 실행 → 결함 검출 → 개발자에게 수정 요청
  3. 개발자가 결함을 수정 후 테스터에게 재전달 → 테스터 검증(Verified)

결함은 발견 → 수정 → 재확인 절차를 거치며 생명주기 8상태(Open / Review / Assigned / Resolved / Verified / Closed / Reopen / Deferred)로 관리된다. 결함 관리 활동 전반(결함 유형 taxonomy, 처리 유형 4종 Fixed/Duplicated/Won’t fix/Invalid, 이슈 추적 도구 Redmine·JIRA)은 결함 관리 참조.

→ A-SPICE에서는 SUP.9 Problem Resolution Management로 프로세스화.

테스트 종료 조건 (Test Exit Criteria)

수행된 작업의 완료 기준 — 완료하기 위해 요구되는 업무, 정보 등

테스트 레벨별 예시

테스트 레벨종료 조건
컴포넌트 / 통합 테스트90% 이상 컴포넌트 테스트 완료, 90% 이상 설계 단위 호출 커버리지, 승인된 버전의 테스트 종료 보고서
시스템 테스트유스케이스 커버리지 100%, 유스케이스 시나리오 커버리지 90% 이상, 승인된 시스템 테스트 종료 보고서
인수 테스트예측 신뢰도 90% 이상, 예측된 미해결 결함 5개 이하, 승인된 인수 테스트 종료 보고서

→ 프로세스 단계별 종료 조건의 일반화는 ETVX 개념 (→ ETVX).

ISO 26262의 테스트 결과 평가

ISO 26262 Part 6에서 요구하는 테스트 평가 기준:

  • 테스트 성공과 요구사항 커버리지 측정
  • 테스트 결과와 “예상 결과”의 일치
  • 소프트웨어 안전 요구사항의 커버리지 달성
  • 소프트웨어 안전 요구사항과 실행된 테스트 케이스의 추적 결과

→ 일반 SW 테스트와 달리 안전 요구사항(SWSR) 기반 양방향 추적이 필수.

테스트 원리 7가지

  1. 테스트는 결함이 존재함을 밝히는 활동 — 결함이 없다는 증명은 불가
  2. 완벽한 테스트는 불가능 — 전수 테스트는 입력·경로 조합의 폭발로 불가
  3. 테스트는 개발 초기에 시작 — V-Model Shift Left
  4. 결함 집중 (Defect Clustering) — 소수 모듈에 결함이 몰림 (파레토 법칙)
  5. 살충제 패러독스 — 동일 TC 반복 시 새로운 결함 발견 불가, TC 갱신 필요
  6. 테스트는 정황(Context)에 의존적 — 안전필수 SW와 게임의 테스트는 다름
  7. 오류 부재의 궤변 — 결함이 없어도 사용자 요구에 맞지 않으면 쓸모 없음 (Validation 관점)

그래프 뷰

백링크