정보처리기사 실기 7장. 애플리케이션 테스트 관리_1
7-1. 애플리케이션 테스트
• 애플리케이션 테스트
애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
‣ Validation : 사용자 입장에서 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인
‣ Verification : 개발자 입장에서 소프트웨어가 기능을 정확히 수행하는지 검증(점검)
• 애플리케이션 테스트의 기본 원리
| 완벽한 테스트 불가능 | 소프트웨어의 잠재적인 결함을 줄일 수 있지만, 소프트웨어에 결함이 없다고 증명할 수 없음 |
| 파레토 법칙 (Pareto Principle) |
애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙 |
| 살충제 패러독스 (Pesticide Paradox) |
동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않음 |
| 테스팅은 정황(context) 의존 | 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 함 예) 소프트웨어의 특징, 테스트 환경, 테스터의 역량 |
| 오류-부재의 궤변 (Absence of Errors Fallacy) |
소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 할 수 없음 |
| 테스트와 위험은 반비례 | 테스트틀 많이 할수록 미래에 발생할 위험을 줄일 수 있음 |
| 테스트의 점진적 확대 | 테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야함 |
| 테스트의 별도 팀 수행 | 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함 |
7-2. 애플리케이션 테스트의 분류
• 프로그램 실행 여부에 따른 테스트
| 정적 테스트 | 동적 테스트 |
| 프로그램을 실행하지 않고, 명세서나 소스 코드를 대상으로 분석하는 테스트 |
프로그램을 실행하여 오류를 찾는 테스트 |
| 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위해 사용 |
소프트웨어 개발의 모든 단계에서 테스트를 수행 |
| 워크스루, 인스펙션, 코드 검사 등 | 블랙박스 테스트, 화이트박스 테스트 |
✓ 워크스루 (Walkthrough, 검토 회의)
소프트웨어 개발자가 모집한 전문가들이 개발자의 작업 내역을 검토하는 것
‣ 소프트웨어 검토를 위해 미리 준비된 자료를 바탕으로 정해진 절차에 따라 평가함
‣ 오류의 조기 검출을 목적으로하며 발견된 오류는 문서화함
✓ 인스펙션 (Inspection)
소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하고, 개선하기 위한 방법을 제시
‣ 워크스루를 발전시킨 형태
• 테스트 기반(Test Bases)에 따른 테스트
| 명세 기반 테스트 | 구조 기반 테스트 | 경험 기반 테스트 |
| 사용자의 요구사항에 대한 명세를 테스트 케이스로 만들어 구현하고 있는지 확인 |
소프트웨어의 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인 |
유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 확인 |
| 사용자의 요구사항의 명세가 불충분하거나 테스트 시간에 제약이 있는 경우 효과적 |
||
| 동등 분할, 경계 값 분석 등 | 구문 기반, 결정 기반, 조건 기반 등 | 에러 추정, 체크 리스트, 탐색적 테스팅 |
• 시각에 따른 테스트
| 확인(Validation) 테스트 | 검증(Verification) 테스트 |
| 사용자의 시각에서 생산된 제품의 결과를 테스트 | 개발자의 시각에서 제품의 생산 과정을 테스트 |
| 사용자가 요구한대로 제품이 완성됐는지, 제품이 정상적으로 동작하는지 테스트 |
제품이 명세서대로 완성됐는지 테스트 |
• 목적에 따른 테스트
| 회복(Recovery) 테스트 | 시스템에 여러가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트 |
| 안전(Security) 테스트 | 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트 |
| 강도(Stress) 테스트 | 과도한 정보량이나 빈도등을 부과하여 과부하에도 소프트웨어가 정상적으로 실행되는지 확인하는 테스트 |
| 성능(Performance) 테스트 | 실시간 성능이나 전체적인 효율성을 진단하는 테스트로, 소프트웨어의 응답시간, 처리량 등을 테스트 |
| 구조(Structure) 테스트 | 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트 |
| 회귀(Regression) 테스트 | 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트 |
| 병행(Parallel) 테스트 | 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력해 결과를 비교하는 테스트 |
7-3. 테스트 기법에 따른 애플리케이션 테스트
• 화이트박스 테스트 (White Box Test)
원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
‣ 모듈 안의 작동을 직접 관찰
‣ 원시 코드(모듈)의 모든 문장을 한 번 이상 실행
- 화이트박스 테스트의 종류
| 기초 경로 검사 (Base Path Testing) |
테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법 | |
| 대표적인 화이트 박스 테스트 기법 | ||
| 제어 구조 검사 (Control Structure Testing) |
조건 검사 (Condition Testing) |
프로그램 모듈 내에 있는 논리적 조건을 테스트 |
| 루프 검사 (Loop Testing) |
프로그램의 반복 구조에 초점을 맞춘 테스트 | |
| 데이터 흐름 검사 (Data Flow Testing) |
변수의 정의와 변수 사용의 위치에 초점을 맞춘 테스트 | |
- 화이트박스 테스트의 검증 기준
| 문장 검증 기준 (Statement Coverage) |
소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계 |
| 분기 검증 기준 (Branch Coverage) |
소스코드의 모든 조건문에 대해 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계 |
| = 결정 검증 기준 (Decision Coverage) | |
| 조건 검증 기준 (Condition Coverage) |
소스코드의 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트케이스를 설계 |
| 분기/조건 기준 (Branch/Condition Coverage) |
분기 검증 기준과 조건 검증 기준을 모두 만족하는 설계 |
| 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트케이스 설계 |
• 블랙박스 테스트 (Black Box Test, 기능 테스트)
각 기능이 완전히 작동되는 것을 입증하는 테스트
‣ 사용자의 요구사항 명세를 보면서 테스트
‣ 소프트웨어 인터페이스를 통해 실시
‣ 구현된 기능을 테스트
- 블랙박스 테스트의 종류
| 동치 분할 검사 (Equivalence Partitioning Testing) |
프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 기법 |
| = 동치 클래스 분해, 동등 분할 기법 | |
| 경계값 분석 (Boundary Value Analysis) |
입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용해 입력 조건의 경계값을 테스트케이스로 선정해 검사하는 기법 |
| 원인-효과 그래프 검사 (Cause-Effect Graphing Testing) |
입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트케이스를 선정하여 검사하는 기법 |
| 오류 에측 검사 (Error Guessing) |
과거의 경험이나 확인자의 감각으로 테스트하는 기법 |
| 비교 검사 (Comparison Testing) |
여러 버전의 프로그램에 동일한 테스트 자료를 제공해 동일한 결과가 출력되는지 테스트하는 기법 |