애플리케이션 테스트 관리 1

애플리케이션 테스트

01. 테스트 개념

1) 테스트(Test)의 개념

• 테스트는 구현된 소프트웨어를 대상으로 오류를 찾아내는 작업
• 소프트웨어나 시스템이 사용자가 요구하는 기능의 동작과 성능, 사용성, 안전성 등을 만족하는지 확인하기 위하여 소프트웨어의 결함을 찾아내는 활동
• 테스트 중인 소프트웨어 제품 또는 서비스의 품질에 대한 정보를 이해 관계자에게 제공하기 위해 수행된 평가라고 할 수 있음
• 테스트의 주요 목적은 소프트웨어 결함을 탐지하여 결함을 발견하고 수정하는 것
• 테스트는 관련 소프트웨어나 장비들이 설계 및 개발을 안내하는 요구사항을 충족해야 함
• 테스트는 모든 종류의 입력에 정확하게 응답하며, 수용 가능한 시간 내에 그 기능을 수행하며 충분히 사용 가능한지 평가함
• 의도된 환경에서 설치 및 실행할 수 있으며, 이해 관계자가 원하는 일반적인 결과를 달성하는지를 평가함

2) 테스트의 필요성

1. 오류 발견 관점
   • 잠재된 오류를 발견하고 이를 수정하여 올바른 프로그램을 개발하는 활동
2. 오류 예방 관점
   • 프로그램 실행 전에 코드 리뷰, 인스펙션 등을 통해 오류를 사전에 발견하는 예방 차원의 활동
3. 품질 향상 관점
   • 사용자의 요구사항 및 기대 수준을 만족하도록 반복적인 테스트를 거쳐 제품의 신뢰도를 향상시키는 품질 보증 활동

3) 테스트 관련 용어

1. 디버그(Debug)
   • 디버그 또는 디버깅(Debugging)은 컴퓨터 프로그램의 논리적인 오류를 찾아내는 과정을 말함
   • 테스트는 오류를 찾는 것이고, 디버그는 찾아낸 오류를 수정하는 것
2. 디버거(Debugger)
   • 디버그를 돕는 도구
   • 디버거는 디버깅을 하려는 코드에 중단점을 지정하여 프로그램 실행을 중단하고, 코드를 단계적으로 실행하여 저장된 값을 확인할 수 있도록 지원함
3. 워크스루(Walk-Through)
   • 소프트웨어 생명주기의 각 단계마다 산출된 명세서를 가지고 오류를 찾아내는 비정형 검토회의
   • 검토회의 전에 요구사항 명세서를 미리 배포하여 사전에 검토한 후 짧은 검토회의를 통해 오류를 조기에 검출하는 데 목적을 두는 요구사항 검토 방법
   • 조사 대상 자체를 집중적으로 파헤치는 테스트와는 달리, 조사 대상이 다른 부분에 어떤 영향을 미치는가에 초점을 맞추므로 조사하는 기능의 문제점뿐만 아니라, 시스템 전반에 걸친 문제점을 찾아내서 시스템을 전체적으로 안정화시키는 것을 목적으로 하는 방법
4. 정형 기술 검토(FTR)의 검토 지침
   • 오류 검출에 초점을 도구 해결책은 나중으로 미룸(제품 검토의 집중성)
   • 검토를 위한 자료를 사전에 배포하여 검토하도록 함(사전 준비성)
   • 의견을 제한하되 충분히 받아드림(의제의 제한성)
   • 안건을 세우면 고수함(안건 고수성)
   • 논쟁과 반박을 제한함(논쟁 반박의 제한성)
   • 문제 영역을 공개함(문제 공개성)
   • 참가자의 수를 제한함(참이 인원의 제한성)
   • 발견된 오류를 문서화함(문서성)

4) 테스트의 원칙

1. 테스트는 계획 단계부터 해야 함
   • 테스트는 결함의 발견이 목적이긴 하지만 개발 초기 이전 단계인 계획 단계에서부터 할 수 있다면 결함을 더 예방할 수 있음
   • 생명주기 단계마다 적절한 테스트를 실시함
2. 결함을 밝히는 활동
   • 테스트로 소프트웨어의 잠재적인 오류는 줄일 수 있지만 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타냄
3. 개발자가 테스트하지 않음
   • 개발자가 자신이 개발한 소스 코드에 대해서는 자신이 테스트를 할 경우 결함을 발견하는 것이 쉽지 않음
   • 개발자 자신은 최대한 노력해서 에러 없이 프로그램을 개발하였기 때문에 자신의 잘못된 부분을 인지하기 어려움
4. 효율적인 결함 제거 법칙 사용
   • 효율적으로 결함을 발견, 가시화, 제거, 예방의 순서로 하여 정량적으로 관리할 수 있어야 함
   • 낚시의 법칙
     • 소프트웨어 제품의 결함이 특정 기능, 모듈, 라이브러리에서 결함이 많이 발견된다는 것
   • Pareto(파레토)의 법칙
     • 소프트웨어 제품에서 발견되는 전체 결함의 80%는 소프트웨어 제품의 전체 기능 중 20%에 집중되어 있음
5. 완벽한 테스트는 불가능함
   • 단순한 소프트웨어라도 테스트 케이스의 수는 무한대로 발생되기 때문에 완벽한 테스트는 불가능함
   • 테스트를 통해서 100% 검출한다는 것은 불가능함
   • 여러 가지 테스트 방법을 사용하여도 검출하지 못하는 오류가 있음
   • 오류는 있지만 발견되지 않으면서 존재하는 에러를 잠재적 오류라고 함
   • 오류를 많이 찾아내는 테스트가 성공적인 테스트
   • 무한 경로, 무한 입력값, 무한 시간이 소요되어도 완벽한 테스트를 할 수 없기 때문에 위험 분석과 우선순위를 고려해야 함
6. 결함 집중(Defect Clustering)을 고려함
   • 소프트웨어 결함은 대부분 소수의 특정한 모듈에 집중되어 있음
7. 살충제 패러독스(Pesticide Paradox)를 고려함
   • 동일한 테스트 케이스로 반복 실행하면 더 이상 새로운 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 점검하고 개선해야 함
8. 오류-부재의 궤변(Absence of Errors Fallacy)을 고려함
   • 사용자의 요구사항을 만족하지 못한다면 오류를 발견하고 제거해도 품질이 높다고 할 수 없음
   • 테스트는 오류를 100% 없애는 것이 목적이 아니라 일정 수준 이하로 줄이는 것이 목적

---

02. 테스트 프로세스

1) 일반적인 테스트 프로세스

1. 테스트 계획
   • 테스트 목적과 범위를 정의함
   • 대상 시스템의 구조를 파악함
   • 테스트의 일정을 정의함
   • 종료 조건을 정의함
   • 조작 및 비용을 산정함
2. 테스트 분석 및 디자인
   • 테스트 목적과 원칙을 검토함
   • 요구사항을 분석함
   • 위험 분석 및 우선순위를 결정함
   • 테스트 데이터를 준비함
   • 테스트 환경 및 도구를 준비함
3. 테스트 케이스 및 시나리오 작성
   • 테스트 케이스를 작성함
   • 테스트용 스크립트를 작성함
   • 테스트 케이스를 검토하고 확인함
   • 테스트 시나리오를 작성함
4. 테스트 수행
   • 초기 데이터를 준비함
   • 테스트를 수행함(단위 -> 통합 -> 시스템 -> 인수 -> 설치 테스트)
   • 결함 리포팅을 작성함
5. 테스트 결과 평가 및 리포팅
   • 테스트 결과를 정리함
   • 테스트 프로세스를 재검토함
   • 테스트 결과를 평가함
   • 테스트 결과를 리포팅함

2) 테스트 수행 절차

1. 단위 테스트(코드 테스트, 모듈 테스트, 프로그램 설계 테스트)
   • 원시 프로그램의 모듈(함수, 프로시저, 독립적인 루틴 등)을 대상으로 화이트박스 테스트를 실시하는 방법
   • 모듈의 기능 수행 여부를 판정하고 내부에 존재하는 논리적인 오류를 검출
2. 통합 테스트(결합 테스트, 구조 설계 테스트)
   • 단위테스트를 성공적으로 실시한 후에 단위별(모듈별)로 결합하면서 오류를 찾는 방법으로 가장 오류가 많이 발견되는 테스트이고 프로그램만을 대상으로 테스트함
   • 모듈 간의 인터페이스 연계를 검증하고 오류를 확인함
   • 모듈 간의 상호작용 및 연계 동작이 제대로 기능하는지 점검함
3. 시스템 테스트
   • 단위, 통합 검사를 수행한 후 소프트웨어 단위로 테스트함
   • 프로그램 전체가 정상적으로 작동하는지 점검함
4. 인수 테스트(사용자 참여 테스트)
   • 사용자 요구분석 명세서에 나타난 사항을 모두 충족하는지 판단함
   • 시스템이 예상되는 대로 동작하고 있는지 점검함
5. 설치 테스트
   • 개발된 소프트웨어를 대상으로 테스트하는 것이 아닌 목표 시스템(사용자 컴퓨터)에 설치하여 사용될 때 외부적인 하드웨어나 소프트웨어와의 관계 상태의 오류가 있는가를 테스트함

---

03. 테스트 기법

1) 테스트 분석 기법

1. 동적 분석 테스트
   • 프로그램의 실행을 요구하는 테스트
   • 화이트박스 테스트와 블랙박스 테스트가 있음
2. 정적 분석 테스트
   • 프로그램 실행 없이 소스 코드의 구조를 분석하여 논리적으로 검증하는 테스트
   • 인스펙션, 코드 테스트, Walk-Through 등이 있음

2) 테스트 실행 기법

1. 화이트박스 테스트
   • 프로그램의 내부를 보면서 테스트를 수행함
   • 투명 상자 안에 내용을 볼 수 있듯이 프로그램 소스를 직접 보면서 오류를 찾아내는 방법
   • 모듈의 내부 구현을 자세히 테스트함
   • 산출물의 각 기능별로 적절한 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 점검함
2. 블랙박스 테스트
   • 프로그램의 외부 사용자 요구사항 명세를 보면서 테스트함
   • 불투명 상자는 박스 안에 내용을 볼 수 없듯이 프로그램의 동작만으로 오류를 찾아내는 방법

3) 테스트 설계 기법

1. 구조 기반 설계 테스트
   • 소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
   • 구문 기반 테스트, 결정 기반 테스트, 조건 기반 테스트, 조건 결정 기반 테스트, 변경 조건 결정 기반 테스트, 멀티 조건 기반 커버리지 테스트 등이 있음
2. 명세 기반 설계 테스트
   • 주어진 명세를 빠짐없이 테스트 케이스로 구현하고 있는지 확인하는 테스트
   • 동등(균등) 분할 테스트, 경계값 분석 테스트, 결정 테이블 테스트, 정형 명세 기반 테스트, 유스케이스 테스트, 유한 상태 기계 기반 테스트, 페어와이즈 테스트, 직교 배열 테스트 등이 있음
3. 경험 기반 설계 테스트
   • 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한 직관과 기술 능력을 기반으로 수행하는 테스트