1. 결함 없는 시스템을 위한 관문, 소프트웨어 테스트의 개요
정의: 설정된 요구사항을 만족하는지 확인(Verification)하고, 사용자 관점에서 올바른 제품이 구현되었는지 타당성을 입증(Validation)하는 일련의 활동.
필요성: 잠재적 결함 조기 발견을 통한 수정 비용 절감 및 시스템 가동 후 발생할 수 있는 장애 리스크 최소화.
2. 가. 몽키 테스트(Monkey Test)와 회귀 테스트(Regression Test) 비교
두 테스트는 테스트의 '의도성'과 '수행 시점' 측면에서 뚜렷한 차이를 보입니다.
| 비교 항목 | 몽키 테스트 (Monkey Test) | 회귀 테스트 (Regression Test) |
| 핵심 개념 | 임의의 무작위 데이터를 입력하여 시스템의 비정상 종료나 에러를 찾아내는 기법 | 소프트웨어 변경(수정/추가) 후, 기존 기능에 부작용(Side Effect)이 없는지 확인하는 기법 |
| 수행 목적 | 예측하지 못한 비정상 케이스 탐지 및 강건성(Robustness) 확인 | 수정으로 인한 새로운 결함 유입 방지 및 기존 기능의 무결성 유지 |
| 테스트 케이스 | 별도의 시나리오나 케이스 없이 무작위 수행 | 기존에 사용했던 테스트 케이스 중 핵심 항목 재사용 |
| 수행 시점 | 주로 개발 후반부, 스트레스 테스트 단계 | 기능 수정, 패치, 업그레이드 직후 매번 수행 |
| 자동화 여부 | 툴을 이용한 자동화가 일반적 | 반복적 수행이 많아 자동화 효율이 매우 높음 |
3. 나. 통합 테스트 계획서에 포함되어야 할 주요 사항
단위 테스트가 완료된 모듈 간의 인터페이스와 비즈니스 흐름을 검증하기 위한 상세 전략이 포함되어야 합니다.
| 주요 항목 | 상세 내용 | 비고 |
| 1. 테스트 목적 및 범위 | 통합 대상 모듈 범위, 인터페이스 유형, 테스트 수행의 최종 목표 정의 | 범위 크립 방지 |
| 2. 테스트 환경 구성 | HW/SW 사양, 네트워크 설정, 테스트용 DB 및 데이터 생성 방안 | 실제 환경 유사도 |
| 3. 테스트 조직 및 R&R | 개발팀, 품질팀, 현업 사용자 등 역할 분담 및 연락 체계 | 책임 소재 명확화 |
| 4. 테스트 전략 및 기법 | 빅뱅, 상향식(Stub), 하향식(Driver), 백본 통합 등 적용 방식 선정 | 리스크 기반 접근 |
| 5. 일정 및 자원 계획 | 단계별 수행 일정, 투입 인력(M/M), 가용 테스트 도구 리스트 | 자원 최적화 |
| 6. 합격/불합격 판정 기준 | 결함 심각도별 수용 한계치, 테스트 커버리지 목표(예: 95% 이상) | Go/No-Go 기준 |
| 7. 결함 관리 및 보고 | 결함 관리 도구(Jira 등), 결함 생명주기, 일일/주간 보고 절차 | 추적성 확보 |
| 8. 리스크 및 제약사항 | 일정 지연 가능성, 데이터 보안 제약, 인력 이탈 등에 대한 대응 방안 | 컨틴전시 플랜 |
4. 통합 테스트 수행 시 고려사항: 인터페이스 무결성
데이터 정합성: 모듈 간 데이터 송수신 시 포맷 변환 오류 및 데이터 유실 여부를 중점 점검.
성능 및 부하: 개별 모듈에서는 발견되지 않던 성능 병목이 통합 환경에서 나타날 수 있으므로 임계치 모니터링 병행.
환경 일관성: 개발 환경과 테스트 환경의 설정 차이로 인한 '환경 오류'를 결함으로 오인하지 않도록 형상 관리 철저.
5. 기술사적 제언: 테스트 자동화와 지속적 품질 관리(CQ)
CI/CD 파이프라인 연계: 회귀 테스트는 자동화 스크립트를 통해 CI/CD 과정에 내재화함으로써 개발자가 코드를 커밋할 때마다 즉각적인 피드백을 받도록 설계해야 함.
리스크 기반 테스트(RBT): 모든 기능을 테스트할 수 없으므로, 비즈니스 영향도가 높고 결함 발생 빈도가 높은 영역에 테스트 자원을 집중하는 전략적 접근 필요.
결언: 테스트는 결함이 없음을 증명하는 것이 아니라 '결함이 있음을 발견'하는 과정임. 기술사는 몽키 테스트의 유연함과 회귀 테스트의 정교함을 조화시켜 소프트웨어의 회복 탄력성(Resilience)을 확보해야 함.
댓글 없음:
댓글 쓰기