▶ 049 애플리케이션 테스트
애플리케이션 테스트
애플리케이션에 잠재되어 있는 결함을 찾아내는 행위, 절차
- 고객의 요구사항을 만족시키는지 확인(Validation)하고, 기능을 정확히 수행하는지 검증(Verification)
＊Validation : 사용자 입장
＊Verification : 개발자 입장
☞ 소프트웨어의 분류
- 상용 소프트웨어 : 보통의 사용자들이 공통적으로 필요로 하는 기능을 제공하는 소프트웨어
> 산업 범용 소프트웨어 : 시스템 소프트웨어, 미들웨어, 응용 소프트웨어
> 산업 특화 소프트웨어 : 특정 분야에서 요구하는 기능만을 구현한 소프트웨어
- 서비스 제공 소프트웨어 : 특정 사용자가 필요로 하는 기능만을 구현해 제공하는 소프트웨어
> 신규 개발 소프트웨어 : 새로운 서비스를 제공하기 위해 개발된 소프트웨어
> 기능 개선 소프트웨어 : 기능을 개선하기 위해
> 추가 개발 소프트웨어 : 새로운 기능을 추가하기 위해
> 시스템 통합 소프트웨어 : 업무기능이나 데이터 등을 통합하여 개발된 소프트웨어
애플리케이션 테스트의 필요성
- 프로그램 실행 전에 오류를 발견하여 예방
- 제품의 신뢰도 향상
- 단순한 오류 뿐만 아니라 새로운 오류의 유입도 예방
- 최소한의 시간과 노력으로 많은 결함 발견 가능
애플리케이션 테스트의 기본 원리
- 완벽한 소프트웨어 테스팅은 불가, 결함은 줄일 수는 있지만 결함이 없다고 증명할 수는 없음
- 결함은 대부분 특정 모듈에 집중되어 있음
- 테스트 케이스를 지속적으로 보완 및 개선
- 정황에 따라 테스트를 다르게 수행
- 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없음
- 테스트와 위험은 반비례
- 테스트는 작은 부분에서 시작해 점점 확대해 진행
- 개발자와 관계없는 별도의 팀에서 테스트 수행
▶ 050 애플리케이션 테스트의 분류
프로그램 실행 여부에 따른 테스트
정적 테스트 |
프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트 - 소프트웨어 개발 초기에 결함 발견 가능, 개발 비용 낮음 ex) 워크스루, 인스펙션, 코드검사 등 |
동적 테스트 |
프로그램을 실행하여 오류를 찾는 테스트 - 소프트웨어 개발의 모든 단계에서 테스트를 수행할 수 있음 ex) 블랙박스 테스트, 화이트박스 테스트 |
＊워크스루, 인스펙션 : 참고 ▶028 인터페이스 요구사항 검증
테스트 기반(Test Bases)에 따른 테스트
명세 기반 테스트 |
사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트 - 종류 : 동등 분할, 경계 값 분석 등 |
구조 기반 테스트 |
소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 - 종류 : 구문 기반, 결정 기반, 조건 기반 등 |
경험 기반 테스트 |
유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트 - 사용자 요구사항에 대한 명세게 부족하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적 - 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅 |
＊테스트 케이스 : 참고 ▶039 단위 모듈 테스트, ▶055 테스트 케이스
시각에 따른 테스트
- 검증(Verification) 테스트 : 개발자의 시각에서 제품의 생산 과정을 테스트하는 것, 제품이 명세서대로 완성 되었는지
- 확인(Validation) 테스트 : 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것. 사용자가 요구한대로 완성되었는지
목적에 따른 테스트
회복(Recovery) 테스트 | 시스템에 여러 결함을 주어 실패하도록 한 후 올바르게 복구되는지 확인 |
안전(Security) 테스트 | 시스템에 설치된 시스템 보호 도구가 불법적인 칩입으로부터 시스템을 보호할 수 있는지 확인 |
강도(Stress) 테스트 | 시스템에 과도한 정보량이나 빈도 등을 부과해 과부하 시 소프트웨어가 정상적으로 실행되는지 확인 |
성능(Performance) 테스트 | 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단, 응답시간, 처리량 등 테스트 |
구조(Structured) 테스트 | 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가 |
회귀(Regression) 테스트 | 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인 |
병행(Parallel) 테스트 | 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력해 결과를 비교 |
▶ 051 테스트 기법에 따른 애플리케이션 테스트
화이트박스 테스트(White Box Test)
모듈안의 내용을 볼 수 있어 내부의 논리적인 경로를 테스트하는 방식
모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방식
- 구조 기반 테스트
- 테스트 과정의 초기에 적용
- 모듈 안의 작동을 직접 관찰
- 분기점 부분들을 수행함으로써 논리적 경로 제어
화이트박스 테스트의 종류
기초 경로 검사 | - 대표적인 화이트박스 테스트 기법 - 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법 |
제어 구조 검사 | - 조건 검사(Condition Testing) : 프로그램 모듈 내에 있는 논리적 조건을 테스트 - 루프 검사(Loop Testing) : 프로그램의 반복구조에 초점을 맞춰 테스트 - 데이터 흐름 검사(Data Flow Testing) : 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 |
화이트박스 테스트의 검증 기준
- 문장 검증 기준(State Coverage) : 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계
- 분기 검증 기준(Branch Coverage) : 소스 코드의 모든 조건문이 한 번 이상 수행되도록 테스트 케이스 설계
- 조건 검증 기준(Condition Coverage) : 소스 코드의 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
- 분기/조건 기준 : 소스 코드의 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
☞ 검증 기준(Coverage)의 종류
- 문장 검증 기준, 분기 검증 기준 등은 모두 코드 커버리지에 해당
- 기능 기반 커버리지 : 실제 테스트가 수행된 기능의 수 / 전체 기능 수
- 라인 커버리지 : 테스트 시나리오가 수행한 소스 코드의 라인 수 / 전체 소스 코드의 라인수
- 코드 커버리지 : 소스 코드의 구문, 분기, 조건 등의 구조 코드 자체가 얼마나 테스트 되었는지를 측정하는 방법
블랙박스 테스트(Black Box Test)
소프트웨어의 각 기능이 완전히 작동되는 것을 입증하는 테스트, 기능 테스트라고도 함
- 사용자의 요구사항 명세서를 보면서 테스트, 주로 구현된 기능을 테스트
- 명세 기반 테스트, 경험 기반 테스트
- 테스트 과정의 후반부에 적용
블랙박스 테스트의 종류
- 동치 분할 검사(동등 분할 기법) : 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사하는 방법
- 경계값 분석 : 입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법
- 원인-효과 그래프 검사 : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석한 다음 효용성이 높은 테스트 케이스를 선정해 검사하는 기법
- 오류 예측 검사 : 과거의 경험이나 확인자의 감각으로 테스트하는 기법
- 비교 검사 : 여러 버전의 프로그램에 동일한 테스트 자료를 제공해 동일한 결과가 출력되는지 테스트하는 기법
▶ 052 개발 단계에 따른 애플리케이션 테스트
개발 단계에 따른 애플리케이션 테스트
단위 테스트, 통합 테스트, 시스템 테스트, 인스 테스트로 분류
- V-모델 : 애플리케이션 테스트와 소프트웨어 개발 단계를 연결해 표현한 것
1. 단위 테스트(Unit Test) / 참고 ▶039 단위 모듈 테스트
코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트
- 화이트박스 테스트, 블랙박스 테스트 사용
- 주로 구조 기반 테스트 사용
2. 통합 테스트(Integration Test)
단위 테스트가 완료된 모듈들을 결합 해 하나의 시스템으로 완성시키는 과정에서의 테스트
3. 시스템 테스트(System Test)
개발된 소프트웨어가 해당 시스템에서 완벽하게 수행되는가를 테스트
- 기능적 요구사항과 비기능적 요구사항 각각을 만족하는지 테스트
4. 인수 테스트(Acceptance Test)
개발한 소프트웨어가 사용자의 요구사항을 충족하는가를 테스트
- 사용자가 직접 테스트
• 인수 테스트의 종류
- 사용자 인수 테스트 : 사용자가 시스템 사용의 적절성 여부 확인
- 운영상의 인수 테스트 : 시스템 관리자가 백업/복원 시스템, 재난 복구, 사용자 권리 등 테스트
- 계약 인수 테스트 : 계약상의 인수/검수 조건을 준수하는지 여부 확인
- 규정 인수 테스트 : 규정에 맞게 개발되었는지 확인
- 알파 테스트 : 개발자 앞에서 사용자가 행하는 테스트 기법, 통제된 환경에서 검사
- 베타 테스트 : 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법, 개발자에 의해 제어되지 않은 환경에서 검사
▶ 053 통합 테스트
통합 테스트(Integration Test)
단위 테스트 후 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
• 비점진적 통합 방식
모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법
- 소규모 프로그램에 유리, 단시간 내 테스트 가능
- 오류 발견 및 장애 위치 파악 및 수정 어려움
ex) 빅뱅 통합 테스트 방식
• 점진적 통합 방식
모듈 단위로 단계적으로 통합하면서 테스트하는 방법
- 하향식, 상향식, 혼합식 통합 방식이 있음
- 오류 수정 용이
하향식 통합 테스트
프로그램의 상위에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
- 깊이 우선 통합법, 넓이 우선 통합법 사용
- 테스트 초기부터 사용자에게 시스템 구조 보여줄 수 있음
- 상위 모듈에서는 테스트 케이스를 사용하기 어려움
- 스텁(Stub) 사용
＊스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구, 시험용 모듈
프로그램의 하위에서 상위 모듈 방향으로 통합하면서 테스트하는 기법
- 클러스터(Cluster)와 드라이버 사용, 스텁 사용 안함
혼합식 통합 테스트
상향식, 하향식통합을 혼합해 테스트, 샌드위치식 통합 테스트라고도 함
회귀 테스팅(Regression Testing)
이미 테스트된 프로그램의 테스팅을 반복하는 것
통합테스트로 인해 변경과 오류가 있는지 다시 한번 확인하는 테스트
