1. 소프트웨어 테스트(Software Test)의 개요
정의: 노출되지 않은 결함을 발견하기 위해 소프트웨어를 실행하여 요구사항과 실제 결과의 차이를 확인하고 품질을 평가하는 활동입니다.
목적: 결함 예방 및 발견, 품질 수준 측정, 의사결정 지원, 사용자 신뢰도 확보.
2. 소프트웨어 테스트의 7가지 원리 (Principles)
테스트의 효율성을 극대화하기 위해 테스터가 반드시 숙지해야 할 기본 법칙입니다.
| 원리 | 설명 |
| 결함이 존재함 | 테스트는 결함이 없음을 증명하는 것이 아니라, 결함이 있음을 보여주는 활동임. |
| 완벽한 테스트 불가능 | 모든 입력값과 조건의 조합을 테스트하는 것은 산술적으로 불가능함 (Risk 기반 집중). |
| 조기 테스트 (Early Testing) | SDLC 초기 단계에 테스트를 시작할수록 결함 제거 비용(Cost)이 기하급수적으로 감소함. |
| 결함 집중 (Defect Clustering) | 파레토 법칙($80:20$)에 따라 특정 모듈에 대부분의 결함이 집중되어 나타남. |
| 살충제 패러독스 | 동일한 테스트 케이스를 반복하면 더 이상 새로운 결함을 찾을 수 없음 (지속적 갱신 필요). |
| 정황 의존 (Context Dependent) | 도메인의 특성(예: 제어 시스템 vs 전자상거래)에 따라 테스트 방식은 달라야 함. |
| 오류-부재의 궤변 | 사용자의 요구사항을 만족하지 못한다면, 결함이 하나도 없더라도 무의미한 소프트웨어임. |
3. 블랙박스 테스트와 화이트박스 테스트 비교
테스트 대상의 내부 구조(코드) 가시성 여부에 따라 구분됩니다.
| 비교 항목 | 블랙박스 테스트 (Black-box) | 화이트박스 테스트 (White-box) |
| 테스트 관점 | 사용자 관점 (기능/명세 중심) | 개발자 관점 (로직/구조 중심) |
| 테스트 대상 | 입출력 값, 인터페이스, 기능 요구사항 | 소스 코드, 제어 흐름, 경로, 조건 |
| 테스트 기법 | 동등 분할, 경계값 분석 등 | 구문 커버리지, 결정 커버리지 등 |
| 수행 단계 | 주로 시스템 테스트, 인수 테스트 | 주로 단위 테스트, 통합 테스트 |
| 지식 요구 | 소스 코드에 대한 지식 불필요 | 프로그래밍 언어 및 내부 구조 지식 필수 |
4. 테스트 기법의 분류 (명세, 구조, 경험 기반)
테스트 케이스를 도출하는 근거에 따른 분류입니다.
가. 명세기반 테스트 (Specification-based / Black-box)
정의: 요구사항 명세서나 설계를 바탕으로 테스트 케이스를 도출합니다.
주요 기법:
동등 분할 (Equivalence Partitioning): 입력 범위를 유사한 그룹으로 나누어 대표값 테스트.
경계값 분석 (Boundary Value Analysis): 입력 범위의 경계(최소/최대)에서 결함 발생 확률이 높음을 이용.
결정 테이블 (Decision Table): 복잡한 논리적 조건과 행위의 조합을 테이블화하여 검증.
상태 전이 (State Transition): 객체의 상태 변화와 이벤트에 따른 동작 확인.
나. 구조기반 테스트 (Structure-based / White-box)
정의: 소프트웨어 내부 구조나 소스 코드의 논리적 경로를 바탕으로 수행합니다.
주요 기법 (커버리지):
구문 커버리지 (Statement): 모든 코드가 한 번 이상 실행되는지 확인.
결정 커버리지 (Decision): 전체 조건식의 결과(True/False)가 최소 한 번씩 실행되는지 확인.
조건 커버리지 (Condition): 조건식 내부의 개별 조건들이 각각 T/F가 되는지 확인.
다. 경험기반 테스트 (Experience-based)
정의: 테스터의 지식, 숙련도, 유사 도메인 경험을 바탕으로 직관적으로 수행합니다.
주요 기법:
오류 추정 (Error Guessing): 과거 사례를 바탕으로 결함이 생길 법한 상황을 추측.
탐색적 테스트 (Exploratory): 테스트 설계와 실행을 동시에 진행하며 테스트 대상 학습.
체크리스트 (Checklist): 경험적으로 축적된 확인 항목 리스트를 활용.
5. 기술사적 제언: 테스트 자동화와 품질 가시성 확보
테스트 자동화의 균형: 단순 반복적인 회귀 테스트(Regression Test)는 자동화하되, 신규 기능이나 복잡한 로직은 탐색적 테스트와 같은 전문가의 직관을 병행해야 합니다.
Shift-Left 전략: 구현 단계 이후의 테스트에만 매몰되지 않고, 요구사항 분석 단계에서의 **'정적 테스트(인스펙션, 워크쓰루)'**를 강화하여 결함 예방율을 높여야 합니다.
테스트 지표 관리: 코드 커버리지뿐만 아니라 결함 밀도(Defect Density), 테스트 진척률 등을 대시보드화하여 프로젝트의 **'품질 가시성'**을 확보하는 거버넌스 수립이 필요합니다.
댓글 없음:
댓글 쓰기