[정처기 실기] 애플리케이션 테스트 관리 (1)

 

* 애플리케이션 테스트: 개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능, 성능, 사용성, 안정성 등을 만족하는지 확인하고 소프트웨어의 잠재된 결함을 찾아내는 것.

 

* 애플리케이션 테스트의 기본 원리:

- 완벽한 테스트는 불가능: 완벽하게 테스팅 하려는 시도는 불필요한 시간과 자원낭비. 잠재적 결함은 줄일 수 있지만 결함이 없다고 증명할 수 없음.

 

- 파레토 법칙: 결함집중. 20%의 모듈에서 80%의 결함이 발견됨

 

- 살충제 패러독스: 동일한 테스트 케이스를 방복하면 결함이 발견되지 않기 때문에 테스트 케이스의 정기적 개선이 필요.

 

- 테스팅은 정황에 의존: 소프트웨어의 성격에 맞게 테스트해야함. 소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황에 따라 테스트 결과가 달라질 수 있으므로 고려하여 테스트 실시.

 

- 오류-부재의 궤변: 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 결함이 없어도 품질이 높다고 할 수 없다.

 

- 테스트와 위험은 반비례: 테스트를 많이 할수록 미래의 위험을 줄일 수 있다.

 

- 테스트의 점진적 확대: 테스트는 작은 부분에서 시작하여 점점 확대하며 진행.

 

- 테스트의 별도 팀 수행: 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함

 

* 소프트웨어 테스트 프로세스:

- 테스트 계획 - 테스트 분석 및 디자인 - 테스트 케이스 및 시나리오 작성 - 테스트 수행 - 테스트 결과 평가 및 리포팅

 

* 소프트웨어 테스트 산출물:

- 테스트 계획서:

테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행절차, 테스트 일정, 종료 조건 정의 등 테스트 수행을 계획한 문서

 

- 테스트 케이스:

테스트를 위한 설계 산출물로 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행조건, 기대 결과로 구성된 테스트 항목의 명세서.

 

- 테스트 시나리오:

테스트 수행을 위한 여러 개의 테스트 케이스의 집합으로 테스트 케이스의 동작 순서를 기술한 문서이며 테스트 절차를 명세한 문서

 

- 테스트 결과서:

테스트 결과를 정리한 문서로 테스트 프로세스를 리뷰, 결과 평가, 리포팅 하는 문서

 

 

* 프로그램 실행 여부에 따른 테스트

- 정적 테스트: 프로그램을 실행하지 않고 명세서, 소스코드를 대상으로 분석.

• 워크스루 Walk Through: 회의 전 검토 자료를 배포하여 짧은 시간동안 회의를 진행. 리뷰를 통해 오류를 검출, 문서화하는 기법.
• 인스펙션 Inspection: 개발자 외 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적인 기법.
• 동료 검토 Peer Review: 2~3녕이 진행하는 리뷰 형태. 이해관계자들이 설명을 들으면서 결함을 발견하는 방식.

- 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트. 개발의 모든 단계에서 사용.

 

 

 

* 테스트 종류에 따른 분류:

- 명세 기반 테스트: 프로그램 요구사항 명세서를 기반으로 테스트

- 구조 기반 테스트: 소프트웨어 내부 논리 흐름에 따라 테스트

- 경험 기반 테스트: 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로한 직관, 기술 능력을 기반으로 테스트

 

 

* 테스트 시각에 따른 분류:

- Verification 검증:

• 개발자의 시각에서 명세서대로 완성됐는지 테스트.
• 생산 과정을 테스트. 

- Validation 확인:

• 사용자의 시각에서 제품이 제대로 동작하는지 테스트
• 결과를 테스트.

 

* 테스트 기법에 따른 분류:

1. 화이트박스 테스트

: 논리적인 모든 경로를 테스트하여 테스트 케이스 설계. 원시코드(모듈)의 모든 문장을 한 번 이상 수행. 구조 기반 테스트.

 

- 화이트박스 테스트의 종류:

• 기초 경로 검사 Base Path Testing: 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트.
• 제어 구조 검사 Control Structure Testing: 
• - 조건 검사 : 프로그램 모듈 내에 있는 논리적 조건을 테스트
• - 루프 검사: 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트
• - 데이터 흐름 검사: 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

 

- 화이트박스 테스트의 검증 기준:

• 문장 검증 기준 Statement Coverage: 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계.
• 분기 검증 기준 Branch Coverage : 결정 검증 기준 Decision Coverage. 소스 코드의 모든 조건문에 대해 조건식의 결과가 true / false 의 경우가 한번 이상 수행되도록 설계
• 조건 검증 기준 Condition Coverage: 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True / False 경우가 한 번 이상 수행되도록 설계
• 분기/조건 기준 Branch/Condition Coverage: 분기 검증 기준, 조건 검증 기준 모두 충족. 조건문이 True / False 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계

 

2. 블랙박스 테스트

: 각 기능이 작동되는 것을 입증하는 테스트. 기능 테스트. 명세 기반 테스트.

 

- 블랙박스 테스트의 종류:

• 동치(동등) 분할 테스트 Equivalence Partitioning Testing: 데이터를 그룹핑하여 대표값 테스트 케이스를 도출하여 테스트. 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 나눠 테스트.
• 경계값 분석 테스트 Boundary Value Analusis: 등가 분할 후, 경계값 부분에서 오류 발생 확률이 높기에 경계값을 포함하여 테스트 케이스 설계.
• 결정 테이블 테스트 Decision Table Testing: 요구사항의 논리와 발생조건을 테이블 형태로 나열하여 조건과 행위를 모두 조합하여 테스트하는 기법
• 상태 전이 테스트 State Transition Testing: 테스트 대상,시스템이나 객체의 상태를 구분하여 이벤트에 의해 어떤 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 기법
• 유스케이스 테스트 Use Case Testing: 시스템이 실제 사용되는 유스케이스로 모델링되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행
• 분류 트리 테스트 Classification Tree Method Testing: SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 수행
• 페어와이즈 테스트 Pairwise Testing: 테스트 데이터값 간에 최소한 한 번씩을 조합하는 방식. 기능적 범위를 모든 조합에 비해 상대적으로 적은 양의 테스트 세트를 구성하기 위한 기법
• 원인-효과(결과) 그래프 검사 Cause-Effect Graphing Testing: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석, 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
• 비교 테스트 Comparison Testing: 여러 버전의 프로그램에 동일한 테스트 자료를 제공, 같은 결과가 출력되는지 테스트.
• 오류 예측 테스트 Error Guessing: 과거의 경험이나 확인자의 감각으로 테스트

 

 

* 개발 단계에 따른 애플리케이션 테스트: 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것을 V-모델 이라고 한다.

 

- 소프트웨어 생명 주기의 V-모델:

 요구사항 - 분석 - 설계 - 구현 - 단위테스트 - 통합 테스트 - 시스템 테스트 - 인수 테스트

 

* 테스트 레벨 종류:

- 단위 테스트 Unit Test: 모듈이나 컴포넌트에 초점을 맞춰 테스트. 주로 구조기반 테스트 시행.

- 통합 테스트 Integraion Test: 단위 테스트가 완료된 모듈들을 통합하여 테스트

- 시스템 테스트 System Test: 통합된 단위 시스템의 기능이 완벽하게 수행되는지 확인

- 인수 테스트 Acceptance Test: 요구사항을 만족시키는지 확인 테스트

• 알파 테스트: 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법. 통제된 환경.
• 베타 테스트: 선정된 사용자가 여러명의 사용자 앞에서 행하는 테스트. 실업무를 갖고 사용자가 직접 테스트.

 

* 통합 테스트 Integration Test: 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트

- 비점진적 통합 방식: 단계적 절차 없이 모든 컴포넌트 통합. ex) 빅뱅 통합 테스트

- 점진적 통합 방식: 모듈 단위로 단계적으로 통합하며 테스트. ex) 상향식 통합, 하향식 통합

 

* 점진적 통합 방식의 종류:

 

1. 하향식 통합 테스트 Top Down Integration Test: 상위 모듈에서 하위모듈 방향으로 통합 테스트.

- 주요 제어 모듈의 종속 모듈들은 스텁Stub으로 대체한다.

- 깊이 우선방식 또는 넓이 우선 방식에 따라 하위 모듈인 스텁들이 한번씩 실제 모듈로 교체된다.

- 모듈이 통합될때마다 테스트 실시.

- 새 오류가 발생하지 않음을 보증하기 위한 회귀 테스트 실시.

• 스텁Stub: 제어 모듈이 호출하는 더미 모듈. 일시적으로 필요한 조건만을 갖고 있는 시험용 모듈.

 

2. 상향식 통합 테스트 Bottom Up Integration Test: 하위 모듈에서 상위 모듈 방향으로 통합.

- 하위 모듈들을 클러스터로 결합.

- 상위 모듈에서 데이터 입출력을 확인하기 위한 드라이버 작성

- 통합된 클러스터 단위로 테스트

- 테스트 완료시 클러스터는 프로그램 구조의 상위로 이동하여 결합하고 드라이버는 실제 모듈로 대체

• 클러스터 Cluster: 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹
• 테스트 드라이버 Test Driver: 테스트 대상의 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행 후 결과를 도출하는 도구.

 

* 애플리케이션 테스트 프로세스:

- 테스트 계획 - 테스트 분석 빛 디자인 - 테스트 케이스 및 시나리오 작성 - 테스트 수행 - 테스트 결과 평가 및 리포팅 - 결함 추적 및 관리

 

* 결함 관리 프로세스:

- 에러 발견 - 에러 등록 - 에러 분석 - 결함 확정 - 결함 할당 - 결함 조치 - 결함 조치 검토 및 승인