반응형
본문에 오류가 있을 수 있음을 감안하고 봐주시길 바랍니다.
# 문제 풀이 중 오답노트 하면서 나온 내용을 정리한 것
애플리케이션 테스트: 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차이다. 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인(Validation)하고 소프트웨어가 기능을 정확히 수행하는지 검증(Verification)한다.
| 기본 원리 | 설명 |
| 완벽한 테스트 불가능 | 소프트웨어의 잠재적인 결함을 줄일 수 있지만 소프트웨어에 결함이 없다고 증명할 수 없음 |
| 파레토 법칙(Pareto Principle) | 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙(결함 집중) |
| 살충제 패러독스 (Pesticide Paradox) |
동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상 |
| 테스팅은 정황(Context) 의존 | 소프트웨어의 특징, 테스트 환경, 테스트의 역량 등 정황(Context) 에 따라 테스트 결과가 달라질 수 있으므로 정황에 따라 테스트를 다르게 수행해야 함 |
| 오류-부재의 궤변 (Absence of Errors Fallacy) |
소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없는 것 |
| 테스트와 위험은 반비례 | 테스트를 많이 하면 할수록 미래에 발생하는 위험을 줄일 수 있음 |
| 테스트의 점진적 확대 | 테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야 함 |
| 테스트의 별도 팀 수행 | 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함 |
| 브룩스의 법칙(Brooks's Law) | 일정이 지연되고 있는 소프트웨어 프로젝트에 새로운 인력을 추가하면 프로젝트는 오히려 더 지연된다는 법칙 |
| 보헴의 법칙(Boehm's Law / 결함 수정 비용의 법칙) |
소프트웨어 생명주기(SDLC)에서 결함을 늦게 발견할수록 그것을 수정하는 비용은 기하급수적으로(눈덩이처럼) 커진다. |
시각에 따른 테스트
- 검증(Verification) 테스트: 개발자 시각에서 제품의 생산 과정을 테스트하는 것, 제품이 명세서대로(기능, 비기능 요구사항) 완성됐는지를 테스트한다.
- 확인(Validation) 테스트: 사용자의 시각에서 생성된 제품의 결과를 테스트하는 것, 사용자가 요구한대로 제품이 완성됐는지 및 제품이 정상적으로 동작하는지를 테스트한다.
목적에 따른 테스트
- 회복(Recovery) 테스트: 시스템에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트
- 안전(Security) 테스트: 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트
- 강도(Stress) 테스트: 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트
- 성능(Performance) 테스트: 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트로 소프트웨어의 응답 시간·처리량 등을 테스트
- 구조(Structure) 테스트: 소프트웨어 내부의 논리적인 경로·소스 코드의 복잡도 등을 평가하는 테스트
- 회귀(Regression) 테스트: 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트
- 병행(Parallel) 테스트: 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트
프로그램 실행 여부에 따른 테스트
- 정적 테스트: 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트, 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위해 사용한다. (종류: 워크스루, 인스펙션, 코드 검사 등)
- 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트, 소프트웨어 개발의 모든 단계에서 테스트를 수행함(종류: 블랙박스 테스트, 화이트박스 테스트)
테스트 기반(Test Bases)에 따른 테스트
- 명세 기반 테스트: 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트(종류: 동등 분할, 경계 값 분석 등)
- 구조 기반 테스트: 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트(종류: 구분 기반, 결정 기반, 조건 기반 등)
- 경험 기반 테스트: 유사 소프트웨어나 기술 등에 대한 테스트의 경험을 기반으로 수행하는 테스트, 사용자의 요구사항에 대한 명세가 불충분하거나 테스트 시간에 제약이 있는 경우에 수행(종류: 에러 추정, 체크 리스트, 탐색적 테스팅)
화이트박스 테스트(White-Box Test): 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로(논리 흐름도)를 테스트하여 테스트케이스를 설계하는 방법이다. 모듈 안의 작동을 직접 관찰하며 원시 코드(모듈)의 모든 문장을 한 번 이상 실행함으로써 수행된다. 모듈 안의 작동을 직접 관찰한다.
- 화이트박스 테스트의 종류
| 종류 | 내용 |
| 기초 경로 검사 (Base Path Testing) |
· 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법 · 기초 경로는 수행 가능한 모든 경로를 의미 |
| 제어 구조 검사 (Control Structure Testing) |
· 조건 검사(Condition Testing): 프로그램 모듈 내에 있는 논리적인 조건을 테스트하는 테스트 케이스 설계 기법 · 루프 검사(Loop Testing): 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법 · 데이터 흐름 검사(Data Flow Testing): 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법 |
- 화이트박스 테스트의 검증 기준
| 검증 기준 | 내용 |
| 문장 검증 기준 (Statement Coverage) |
소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계함 # 구문 검증 기준이라고도 함 |
| 결정 검증 기준 (Decision Coverage) |
소스 코드의 모든 조건문에 대해 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계함 # 한번은 True, 남은 한번은 False, 분기 검증 기준이라고도 함 |
| 조건 검증 기준 (Condition Coverage) |
소스 코드의 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False 인 경우가 한 번이상 수행되도록 테스트 케이스를 설계함 |
| 조건/결정 검증 기준 (Condition/Decision Coverage) |
결정 검증 기준과 조건 검증 기준을 모두 만족하는 설계로 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계함 |
| 변경 조건/결정 검증 기준 (Modified Condition/Decision Coverage) |
조건/결정 검증 기준을 향상시킨 검증 기준으로 개별 조건식이 다른 개별 조건식의 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 테스트 케이스를 설계함 # MC/DC라고도 함 |
| 다중 조건 검증 기준 (Multiple Condition Coverage) |
소스 코드의 조건문에 포함된 모든 개별 조건식의 모든 조합을 고려하도록 테스트 케이스를 설계함 |
블랙박스 테스트(Black-Box Test): 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 것으로 기능 테스트라고도 한다. 사용자의 요구사항 명세서를 보면서 테스트한다. 주로 구현된 기능을 테스트하며 소프트웨어 인터페이스를 통해 실시된다.
| 종류 | 내용 |
| 동치 분할 검사 (Equivalence Partitioning Testing) |
프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정의하고 해당 입력 자료에 맞는 결과가 출력되었는지를 확인하는 기법 |
| 경계값 분석 (Boundary Value Analysis) |
입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법 (예: 99, 100, 101) |
| 원인-효과 그래프 검사 (Cause-Effect Graphing Testing) |
입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법 |
| 오류 예측 검사(Error Guessing) | 과거의 경험이나 확인자의 감각으로 테스트하는 기법 |
| 비교 검사(Comparison Testing) | 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법 |
반응형
'정보처리기사' 카테고리의 다른 글
| [정보처리기사 요약 7-3] S/W 결함 관리부터 소스 코드 품질 분석까지 정리 (1) | 2026.02.27 |
|---|---|
| [정보처리기사 요약 7-2] 애플리케이션 테스트 레벨과 V-모델 정리 (0) | 2026.02.27 |
| [정보처리기사 요약 6] UI 시나리오 문서 요건부터 ISO/IEC 9126 품질 특성 (0) | 2026.02.27 |
| [정보처리기사 요약 5-2] 모듈 연계(EAI/ESB) 및 웹 서비스(REST/SOAP) 정리 (0) | 2026.02.26 |
| [정보처리기사 요약 5-1] 시스템 인터페이스 요구사항 및 연계 기술 정리 (ft. 미들웨어 종류) (0) | 2026.02.26 |