애플리케이션 테스트
- 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인(Validation)하고 소프트웨어가 기능을 정확히 수행하는지 검증(Verification)한다.
애플리케이션 테스트의 기본 원리
- 완벽한 테스트 불가능: 애플리케이션 테스트는 소프트웨어의 잠재적인 결함을 줄일 수 있지만 소프트웨어에 결함이 없다고 증명할 수는 없다.
- 결함 집중: 애플리케이션의 결함은 대부분 개발자의 특성이나 애플리케이션의 기능적 특징 때문에 특정 모듈에 집중되어있다. 파레토 법칙을 적용하기도 한다.
* 파레토 법칙: 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다.
- 살충제 패러독스: 애플리케이션 테스트에서는 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상이 발생한다. 살충제 패러독스를 방지하기 위해서 테스트 케이스를 지속적으로 보완 및 개선해야 한다.
- 테스팅은 정황(Context) 의존: 애플리케이션 테스트는 소프트웨어 직틍, 테스트 환경, 테스터 역량 등 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 한다.
- 오류-부재의 궤변(Absence of Errors Fallacy): 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키기 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없다.
- 테스트와 위험은 반비례
- 테스트의 점진적 확대
- 테스트의 별도 팀 수행
애플리케이션 테스트의 분류
- 프로그램 실행 여부에 따른 테스트, 테스트 기반에 따른 테스트, 시각에 따른 테스트, 목적에 따른 테스트
프로그램 실행 여부에 따른 테스트
: 애플리케이션을 테스트 할 때 프로그램의 실행 여부에 따라 정적 테스트와 동적 테스트로 나뉜다.
- 정적 테스트: 워크스루, 인스펙션, 코드 검사 등
- 동적 테스트: 블랙박스 테스트, 화이트박스 테스트
테스트 기반에 따른 테스트
- 명세 기반 테스트: 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트
- 동등 분할
- 경계 값 분석
- 구조 기반 테스트: 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
- 구문 기반
- 결정 기반
- 조건 기반
- 경험 기반 테스트: 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트, 경험 기반 테스트는 사용자의 요구사항에 대한 명세가 불충분하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적이다.
- 에러 추정
- 체크 리스트
- 탐색적 테스팅
시각에 따른 테스트
- 검증(Verification) 테스트: 개발자의 시각에서 제품의 생산 과정을 테스트하는 것, 제품이 명세서대로 완성됐는지를 테스트
- 확인(Validation) 테스트: 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것, 사용자가 요구한대로 제품이 완성됐는지, 제품이 정상적으로 동작하는지를 테스트
목적에 따른 테스트
- 회복(Recovery) 테스트: 시스템에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트
- 안전(Security) 테스트: 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트
- 강도(Stress) 테스트: 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트
- 성능(Performance) 테스트: 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트로, 소프트웨어의 응답 시간, 처리량 등을 테스트
- 구조(Structure) 테스트: 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트
- 회귀(Regression) 테스트: 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트
- 병행(Parallel) 테스트: 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트
테스트 기법에 따른 애플리케이션 테스트
화이트박스 테스트
- 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
- 테스트 과정의 초기에 적용
- 모듈 안의 작동을 직접 관찰
- 원시 코드(모듈)의 모든 문장을 한 번 이상 실행함으로써 수행됨
화이트박스 테스트의 종류
- 기초 경로 검사: 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법, 테스트 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용된다
- 제어 구조 검사:
- 조건 검사: 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법
- 루프 검사: 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
- 데이터 흐름 검사: 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
화이트박스 테스트의 검증 기준
: 테스트 케이스들이 테스트에 얼마나 적정한 지를 판단하는 기준
- 문장 검증 기준: 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계
- 분기 검증 기준: 소스 코드의 모든 조건문이 한 번 이상 수행되도록 테스트 케이스 설계
- 조건 검증 기준: 소스 코드의 모든 조건문에 대해 조건의 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
- 분기/조건 기준: 소스 코드의 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
블랙박스 테스트
- 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트 (a.k.a 기능 테스트)
- 사용자의 요구사항 명세를 보면서 테스트하는 것으로, 주로 구현된 기능을 테스트한다.
- 소프트웨어 인터페이스에서 실시되는 테스트
- 테스트 과정의 후반부에 적용된다.
블랙박스 테스트의 종류
- 동치 분할 검사: 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사하는 방법 (a.k.a 동등 분할 기법)
- 경계값 분석: 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법
- 원인-효과 그래프 검사: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
- 오류 예측 검사: 과거의 경험이나 확인자의 감각으로 테스트하는 기법 (a.k.a 데이터 확인 검사)
- 비교 검사: 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법
개발 단계에 따른 애플리케이션 테스트
- 소프트웨어의 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류된다.
단위 테스트
- 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것
| 테스트 방법 | 테스트 내용 | 테스트 목적 |
| 구조 기반 테스트 | 프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트 시행 | 제어 흐름, 조건 결정 |
| 명세 기반 테스트 | 목적 및 실행 코드 기반의 블랙박스 테스트 시행 | 동등 분할, 경계값 분석 |
통합 테스트
- 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트를 의미
- 통합 테스트는 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류를 검사한다.
시스템 테스트
- 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
- 환경적인 장애 리스크를 최소화하기 위해서는 실제 사용 환경과 유사하게 만든 테스트 환경에서 테스트를 수행해야함
| 테스트 방법 | 테스트 내용 |
| 기능적 요구사항 | 요구사항 명세서, 비즈니스 절차, 유스케이스 등 명세서 기반의 블랙박스 테스트 시행 |
| 비기능적 요구사항 | 성능 테스트, 회복 테스트, 보안 테스트, 내부 시스템의 메뉴 구조, 웹 페이지의 네비게이션 등 구조적 요소에 대한 화이트박스 테스트 시행 |
인수 테스트
- 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법
- 개발한 소프트웨어를 사용자가 직접 테스트
- 인수테스트에 문제가 없으면 사용자는 소프트웨어를 인수하게 되고, 프로젝트는 종료된다.
| 테스트 종류 | 테스트 내용 |
| 사용자 인수 테스트 | 사용자가 시스템 사용의 적절성 여부를 확인한다. |
| 운영상 인수 테스트 | 시스템 관리자가 시스템 인수 시 수행하는 테스트 기법, 백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검 등을 확인한다. |
| 계약 인수 테스트 | 계약상의 인수/검수 조건을 준수하는지 여부를 확인한다. |
| 규정 인수 테스트 | 소프트웨어가 정부 지침, 법규, 규정 등 규정에 맞게 개발되었는지를 확인한다. |
| 알파 테스트 | 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법, 테스트는 통제된 환경에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 기록한다. |
| 베타 테스트 | 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법 |
'IT Study > 정보처리기사' 카테고리의 다른 글
| 2020 정보처리기사 (10-2장. 응용 SW 기초 기술 활용) (0) | 2020.09.29 |
|---|---|
| 2020 정보처리기사 (10-1장. 응용 SW 기초 기술 활용) (0) | 2020.09.28 |
| 2020 정보처리기사 (9장. 소프트웨어 개발 보안 구축) (0) | 2020.09.23 |
| 2020 정보처리기사 (7-2장. 애플리케이션 테스트 관리) (0) | 2020.09.21 |
| 2020 정보처리기사 (6장. 화면 설계) (0) | 2020.09.18 |
댓글