✅ 1. 통합 테스트란?
- 소프트웨어의 각 모듈 간 연결이 잘 되는지 확인하는 과정!
- 개별 단위 테스트 후, 모듈들을 조합하여 수행하는 테스트임.
🏗 2. 통합 테스트 수행 방법
📌 1) V-모델
🔹 개발 단계를 검증하고 수행해야 테스트를 시각화한 모델
🔹 단계별로 검증하면서 개발 결과를 확인하는 방식
📌 2) 단위 테스트
🔹 소프트웨어의 최소 단위(모듈/컴포넌트)를 개별적으로 테스트하는 과정
🔹 기능 수행 여부 및 논리적 오류 발견
🔹 화이트박스 테스트(코드를 직접 분석하며 테스트) 진행
📌 3) 통합 테스트
🔹 단위 테스트가 끝난 모듈을 연결하여 오류를 찾는 과정
🔹 소프트웨어의 전체적인 동작을 검증
📌 진행 방식
✅ 비점증적(빅뱅) 방식: 한 번에 모든 모듈을 통합해 테스트
✅ 점증적 방식: 단계별로 모듈을 추가하면서 테스트
📌 점증적 방식 종류
1️⃣ 상향식(상승식) 통합: 최하위 모듈부터 상위 모듈로 단계별 테스트
2️⃣ 하향식(하향식) 통합: 최상위 모듈부터 하위 모듈로 단계별 테스트
📉 3. 하향식(Top Down) 통합
🔹 최상위 모듈부터 하위 모듈로 이동하면서 테스트
🔹 메인 제어 모듈이 먼저 동작해야 하므로, 하위 모듈은 stub을 사용하여 테스트
✅ stub: 상위 모듈 테스트를 위해 최소한의 기능만 가진 가짜 모듈
📌 하위 모듈 통합 방식
✔️ 깊이 우선 방식: 하위 모듈이 촘촘히 있는 부분을 우선 탐색
✔️ 너비 우선 방식: 같은 레벨의 모듈을 우선적으로 통합
✔️ stub을 실제 모듈로 교체하며 점진적으로 테스트
✔️ 전체 통합 후 회귀 테스트(기존 기능이 잘 동작하는지 확인) 진행
🏗 4. 상향식(Bottom Up) 통합 테스트
🔹 하위 모듈부터 상위 모듈로 하나씩 연결하면서 테스트를 수행하는 방식
🔹 하위 모듈을 묶어(클러스터화) 테스트 진행
🔹 상위 모듈이 아직 없을 경우, Driver(더미 모듈) 을 사용
✅ Driver 역할
- 테스트 시 아직 없는 상위 모듈의 역할을 대신하는 가짜 모듈
- 상위 모듈과 연결되었을 때 데이터를 주고받을 수 있도록 함
📌 진행 방식
1️⃣ 하위 모듈을 우선적으로 테스트
2️⃣ 테스트가 끝난 모듈부터 차례로 상위 모듈과 연결
3️⃣ Driver를 하나씩 실제 모듈로 교체
4️⃣ 최종적으로 모든 모듈이 연결된 상태에서 전체적인 테스트 진행
✔️ Driver와 Stub 차이
- Stub: 상위 모듈이 테스트할 때 하위 모듈을 대신함
- Driver: 하위 모듈이 테스트할 때 상위 모듈을 대신함
🔁 5. 회귀 테스트 (Regression Test)
🔹 소프트웨어 수정 후 기존 기능이 정상 동작하는지 확인하는 테스트
🔹 기존 코드 변경으로 인해 발생할 수 있는 의도치 않은 오류를 방지
📌 회귀 테스트 선정 기준
✔️ 애플리케이션의 주요 기능을 수행하는 대표적인 테스트 케이스
✔️ 변경된 기능이 다른 부분에 미치는 영향을 고려하여 테스트 추가
✔️ 실제 수정된 모듈 또는 컴포넌트부터 테스트 수행
💻 6. 시스템 테스트
🔹 전체 시스템이 실제 환경에서 제대로 동작하는지 확인하는 테스트
🔹 환경적 장애를 최소화하기 위해 실제 운영 환경과 유사한 환경에서 진행
🔹 기능적 요구사항, 비기능적 요구사항으로 구분
🏆 7. 인수 테스트 (Acceptance Test)
🔹 사용자가 직접 테스트하여 요구사항이 충족되었는지 확인하는 과정
🔹 인수 테스트 통과 시 소프트웨어를 공식적으로 받아들이고 프로젝트 종료
📌 종류
✅ 알파(Alpha) 테스트: 개발자가 있는 환경에서 사용자가 직접 테스트
✅ 베타(Beta) 테스트: 실제 운영 환경과 유사한 환경에서 테스트
⚙ 8. 테스트 자동화 도구
🔹 반복적인 테스트를 자동화하여 비용 절감 및 효율성 향상
🔹 수동 테스트보다 빠르고 정확한 결과 제공
📌 자동화 도구의 기능
✔️ 테스트 계획: 요구사항 관리
✔️ 테스트 분석: 테스트 케이스 생성
✔️ 테스트 수행: 자동화, 정적 분석, 동적 분석, 성능 테스트, 모니터링
✔️ 테스트 관리: 커버리지 측정, 결함 관리
📌 장점
✅ 반복적인 테스트 자동화 가능
✅ 사용자 요구 기능의 일관성 유지
✅ 테스트 결과의 객관적인 평가 가능
✅ UI 없는 서비스도 정밀한 테스트 가능
📌 단점
❌ 도구 사용법에 대한 학습 필요
❌ 유지보수 비용이 추가적으로 발생할 수 있음
⚙ 9. 테스트 자동화 도구 유형
🔍 ① 정적 분석 도구 (Static Analysis Tools)
🔹 애플리케이션을 실행하지 않고 코드를 분석하는 도구
🔹 코드 표준, 스타일, 중복된 코드, 결함 등을 찾는 데 사용
🚀 ② 테스트 실행 도구 (Test Execution Tools)
🔹 테스트를 자동 실행하는 도구 (스크립트 기반)
🔹 데이터 접근 방식에 따라 두 가지 유형이 있음
📌 데이터 접근 방식
✔️ 데이터 주도 접근: 데이터 파일(시트)을 읽어와 테스트 실행
✔️ 키워드 주도 접근: 키워드(수행 동작)와 데이터 파일을 조합하여 실행
⚡ ③ 성능 테스트 도구
🔹 애플리케이션이 목표 성능을 달성했는지 확인
🔹 테스트 대상: 처리량, 응답 속도, 경과 시간, 자원 사용률
✅ 보통 시스템 테스트 단계에서 수행
📊 ④ 테스트 통제 도구
🔹 테스트 계획 및 결함 추적을 위한 도구
🔹 다른 테스트 도구와 연계하여 요구사항 & 품질 관리 가능
🏗 ⑤ 테스트 하네스 (Test Harness)
🔹 테스트를 수행하기 위한 코드 및 데이터의 총칭
🔹 단위 또는 모듈 테스트를 위해 개발자가 작성하는 코드
📌 구성 요소
✔️ Test Suites: 테스트 케이스의 모음
✔️ Test Case: 입력값, 실행 조건, 기대 결과
✔️ Test Script: 자동화된 테스트 실행 절차
✔️ Mock Object: 예상된 사용자 행동을 미리 입력한 객체
🔍 10. 소프트웨어 결함 정의
📌 소프트웨어에서 발생할 수 있는 문제 유형
|
용어
|
정의
|
|
오류 (Error)
|
결함의 원인 (주로 휴먼 에러)
|
|
결함 (Defect) / 결점 (Fault) / 버그 (Bug)
|
오류가 원인이 되어 제품에 포함되는 완전하지 못한 부분
|
|
실패 (Failure) / 문제 (Problem)
|
결함으로 인해 예상치 못한 결과 발생
|
📝 2. 테스트 보고서 작성
✅ 테스트 완료 후 결과 문서화 필수
📌 보고서에 포함해야 할 내용
- 📈 테스트 성공률
- 📊 테스트 커버리지
- ❗ 결함 수량 및 심각도
- 🔎 테스트 결과 분석 및 개선 방향
🛠 3. 결함 관리 (Defect Management)
🔹 테스트 중 발견된 결함을 체계적으로 관리하는 활동
🔹 결함 추적 시스템을 활용하여 해결
📌 결함 발생 주요 원인
✔️ 개발 기획 오류
✔️ 설계 문제
✔️ 코드 결함
✔️ 테스트 부족
🏷️ 결함 심각도(Severity) 기준
|
등급
|
|
🔥 치명적(Critical)
|
|
⚠️ 주요(Major)
|
|
🔹 보통(Normal)
|
|
✏️ 경미(Minor)
|
|
💡 단순(Simple)
|
🔥 결함 우선순위(Priority) 기준
|
등급
|
|
🚨 결정적(Critical)
|
|
⚡ 높음(High)
|
|
⏳ 보통(Medium)
|
|
📝 낮음(Low)
|
🔄 4. 결함 관리 프로세스
📌 결함 처리 흐름
1️⃣ 계획(Plan)
2️⃣ 기록(Record)
3️⃣ 검토(Review)
4️⃣ 수정(Fix)
5️⃣ 재확인(Retest)
6️⃣ 보고(Report)
📊 결함 관리 지표
✔️ 결함 분포 - 특정 모듈 또는 컴포넌트에 집중된 결함 수
✔️ 결함 추세 - 테스트 진행 기간 동안 발생한 결함 수 변화
✔️ 결함 에이징(Aging) - 해결되지 않고 남아 있는 결함 지속 시간
📌 결함 처리 상태
|
상태
|
설명
|
|
🟢 등록 (Open)
|
발견된 결함이 DB에 기록됨
|
|
🔍 검토 (Reviewed)
|
적절한 조치(할당, 보류, 해결) 선택
|
|
📌 할당 (Assigned)
|
결함을 담당 개발자에게 배정
|
|
🛠 수정 (Resolved)
|
개발자가 결함을 수정 완료
|
|
⏳ 보류 (Deferred)
|
일정상 우선순위가 낮아 수정이 연기됨
|
|
✅ 종료 (Closed)
|
수정이 완료되어 최종 승인됨
|
|
❌ 해제 (Clarified)
|
결함이 아니라고 판단되어 취소됨
|
🎯 5. 테스트 커버리지 (Coverage)
🔍 테스트 커버리지 정의
- 테스트 케이스가 소프트웨어의 어느 범위까지 검증했는지를 측정하는 기준
- 정확성과 신뢰성을 향상시키는 역할
📌 기능 기반 커버리지
- 애플리케이션의 모든 기능을 설정하고 실제 테스트된 기능 수를 측정
- 100% 커버리지를 목표
- UI가 많은 시스템의 경우 화면 단위로 측정
📄 라인(Line) 커버리지
- 소스 코드의 총 라인 수 대비 테스트된 라인 수를 측정
- 단위 테스트에서 특히 중요한 기준
🛠 6. 코드(Code) 커버리지 유형
🔹 코드 테스트의 철저한 수행 여부를 평가하는 기준
|
유형
|
|
📝 구문(Statement) 커버리지
|
|
🔀 결정(Decision) 커버리지
|
|
⚖️ 조건(Condition) 커버리지
|
|
🔄 조건/결정 커버리지
|
|
🎯 변형 조건/결정 커버리지 (MC/DC)
|
|
🧩 다중 조건 커버리지
|
'정처기' 카테고리의 다른 글
| 애플리케이션 테스트 케이스 설계 (0) | 2025.02.19 |
|---|---|
| 제품 소프트웨어 버전 관리 (0) | 2025.02.18 |
| 제품 소프트웨어 매뉴얼 작성 (0) | 2025.02.18 |
| 제품 소프트웨어 패키징 (0) | 2025.02.18 |
| 연계 모듈 구현 (1) | 2025.02.18 |