결함·위험·모니터링·테스트 오라클 | 정보처리기사 필기

핵심 범위

결함 관리는 발견부터 종료까지 상태와 책임을 추적한다. 위험 기반 테스트는 중요한 영역에 테스트 노력을 우선 배분하고, 테스트 모니터링은 진행과 품질 상태를 확인한다. 테스트 오라클은 실제 결과의 옳고 그름을 판단하는 기준이다.

영향은 작아도 출시 직전 화면 오탈자는 우선순위가 높을 수 있고, 영향은 크지만 매우 드문 내부 기능은 우선순위가 다르게 결정될 수 있다.

등록 → 분석·분류 → 수정 → 재시험 → 종료

재시험에서 문제가 남아 있으면 다시 열 수 있다. 중복, 수정 연기, 재현 불가 등의 상태도 별도로 관리할 수 있다.

Cannot Reproduce는 현재 자료와 환경에서 재현하지 못했다는 뜻이다. 제품에 결함이 없다는 확정 판정과 구분하며, 빌드·설정·입력·로그·빈도 등 재현 근거를 보완한다.

위험은 일반적으로 발생 가능성 × 영향으로 평가한다. 결제, 개인정보, 핵심 업무처럼 위험이 높은 기능에는 더 이른 시점에 더 많은 테스트를 배정한다.

위험 기반 테스트는 낮은 위험 기능을 무조건 제외한다는 뜻이 아니라 우선순위와 깊이를 조정하는 방식이다.

구분	의미
모니터링	계획 대비 실행률, 통과율, 결함, 커버리지, 위험 상태를 수집·평가
통제	결과에 따라 일정, 인력, 범위, 우선순위를 실제로 조정
완료 보고	수행 결과, 미해결 결함, 미시험 범위, 잔여 위험을 정리

숫자 하나만으로 완료를 판단하지 않고 종료 기준과 위험을 함께 확인한다.

요구 커버리지는 시험한 고유 요구 수를 전체 대상 요구 수로 나눈다. 여러 케이스가 같은 요구를 검증해도 그 요구는 한 번만 센다. 케이스 실행률과 요구 커버리지는 다른 지표다.

요구사항, 업무 규칙, 독립 계산 결과, 기존 시스템 등이 기대 결과의 근거가 될 수 있다. 프로그램이 오류 없이 실행됐다는 사실만으로 결과가 옳다고 판정할 수는 없다.

자동 비교는 모든 필드의 완전한 문자열 일치를 항상 요구하는 것이 아니다. 고정되어야 하는 값은 정확히 비교하고 시간·난수 등 가변 값은 명세된 범위나 관계로 검증한다.

결함 밀도는 검출한 고유 결함 수를 코드 규모로 나눈 지표다. 예를 들어 2 KLOC에서 결함 6개를 찾았다면 3개/KLOC다. 비교할 때 결함 집계와 코드 규모의 기준을 맞춘다.