[정보처리] 어플리케이션 테스트

 

어플리케이션에 잠재되어있는 결함을 찾아내는 일련의 행위 또는 절차

 

 

기본원리

• 파레토 법칙 Pareto principle
  어플의 20%에 해당하는 코드에서 전체 결함의 80%가 발견됨
• 살충제 패러독스 Pesticide paradox
  동일한 테스트케이스로 동일한 테스트를 반복하면 더이상 결함이 발견되지 않음
• 오류-부재의 궤변 Absence of Errors Fallacy
  소프트웨어의 모든 결함을 제거하더라도 사용자의 요구사항을 만족하지 못하면
  해당 소프트웨어는 품질이 좋다고 말할 수 없음

 

 

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

1. 정적 테스트 (실행 X)
   - 명세서나 소스코드를 대상으로 분석하는 테스트
   - 소스코드의 코딩 표준, 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위해 사용
2. 동적 테스트 (실행 O)
   - 소프트웨어 개발의 모든 단계에서 테스트 수행
   - ex) 화이트박스 테스트, 블랙박스 테스트

 

 

시각에 따른 테스트

1. 검증 테스트 Verification
   - 개발자의 시각에서 제품 생산 과정을 테스트
   - 제품이 명세서대로 완성됐는지
2. 확인 테스트 Validation
   - 사용자의 시각에서 생산된 제품의 결과를 테스트
   - 요구한대로 제품이 완성됐는지, 정상 작동 하는지

 

 

기반에 따른 테스트

1. 명세 기반 테스트
   - 사용자 요구사항에 대한 명세를 빠짐없이 구현
   - ex) 동등분할, 경계값 분석
2. 구조 기반 테스트
   - 소프트웨어 내부의 논리 흐름에 따라 테스트케이스를 작성하고 확인함
   - ex) 구문기반, 결정기반, 조건기반
3. 경험 기반 테스트
   - 유사 소프트웨어나 기술에 대한 테스터의 경험을 기반
   - 유저 요구사항 명세가 불충분 하거나 테스트 시간에 제약이 있을 때
   - ex) 에러추정, 체크리스트, 탐색적 테스팅

 

 

목적에 따른 테스트

1. 회복 테스트 Recovery
   시스템에 여러 결함을 주어 실패하도록 한 후 잘 복구되는지 확인
2. 안전 테스트 Security
   시스템 보호도구가 불법침입으로부터 시스템을 보호할 수 있는지 확인
3. 강도 테스트 Stress
   시스템이 과부하시에도 소프트웨어가 정상적으로 실행되는지
4. 성능 테스트 Performance
   소프트웨어의 실시간 성능이나 전체적인 효율성 진단
5. 구조 테스트 Structure
   소프트웨어 내부의 논리적인 경로, 소스코드의 복잡도 등을 평가
6. 회귀 테스트 Regression
   소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 입증하는
7. 병행 테스트 Parallel
   변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과 비교

 

---

 

 

 

화이트박스 테스트

모듈의 소스코드를 오픈시킨 상태에서 소스코드의 논리적인 모든 경로를 테스트하여 테스트케이스를 설계하는 방법

- 모듈 안의 작동을 직접 관찰할 수 있음

- 소스코드의 모든 문장을 한번 이상 실행함으로써 수행

 

▶ 종류

1. 기초 경로 검사 (대표적)
   테스트 케이스 설계자가 절차적인 설계의 논리적 복합성을 측정할 수 있게 해주는 테스트 기법
2. 제어구조 검사
   - 조건검사 Condition : 프로그램 모듈 내의 논리적 조건을 테스트
   - 루프검사 Loop : 프로그램의 반복구조에 초점을 맞춰 실시
   - 데이터 흐름검사 Data Flow : 변수의 정의와 사용위치에 초점을 맞춰 실시

 

▶ 검증기준 Coverage

1. 문장(구문) 검증 기준 Statement
   소스코드의 모든 문장이 한 번 이상 수행되도록
2. 분기(결정) 검증 기준 Branch(Decision)
   소스코드의 모든 조건문에 대해 조건식 결과가 T/F인 경우가 한 번 이상 수행되도록
3. 조건 검증 기준 Condition
   소스코드 조건문에 포함된 개별 조건식 결과가 T/F인 경우가 한 번 이상 수행되도록
4. 분기(결정) /  조건 기준
   분기기준과 조건기준을 모두 만족하는 설계
   조건문이 T/F인 경우에 따라 조건기준의 입력 데이터를 구분

 

 

블랙박스 테스트

소프트웨어가 수행할 특정 기능을 알기위해 각 기능이 완전히 작동하는 것을 입증하는 테스트

- 유저의 요구사항 명세를 보면서 테스트함

- 주로 구현된 기능을 테스트함

 

▶ 종류

1. 동치분할검사(=동등분할기법 =동치클래스분해) Equivalence Paritioning
   프로그램의 입력조건에 타당한 입력자료와 타당하지 않은 입력자료의 개수를 균등하게하여 테스트케이스를 정하고,
   해당 입력자료에 맞는 결과가 출력되는지 확인하는 기법
2. 경계값 분석 Boundary Value
   입력조건의 중간값보다 경계값에서 오류가 발생할 확률이 높다는 점을 이용하여
   입력조건의 경계값을 테스트케이스로 선정하는 검사기법
3. 원인-효과 그래프 검사 Cause-Effect Graphing
   입력 데이터 간의 관계와 출력에 미치는 상황을 체계적으로 분석한 다음
   효용성이 높은 테스트케이스를 선정하여 검사
4. 오류 예측 검사 Error Guessing
   과거의 경험이나 확인자의 감각으로 테스트
5. 비교검사 Comparison
   여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법

 

---

 

▶ 개발 단계에 따른 어플리케이션 테스트

 

 

단위 테스트 Unit

• 코딩 직후 소프트웨어 설계의 최소단위인 모듈·컴포넌트에 초점
• 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선 수행
• 구조기반 테스트와 명세기반 테스트로 나뉨(주로 구조)
• 인터페이스, 외부적 I/O, 자료구조, 독립적 기초경로, 오류처리경로, 경계조건 등을 검사

 

 

 

통합 테스트 Integration

- 단위테스트가 완료된 모듈을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트

- 모듈 간 또는 컴포넌트 간의 상호작용 오류를 검사

1. 비점진적 통합 방식
   - 절차없이 모든 모듈이 미리 결합되어있는 프로그램 전체를 테스트
   - ex) 빅뱅 통합 테스트
2. 점진적 통합 방식
   모듈 단위로 단계적으로 통합하면서 테스트
   - ex) 하향식 · 상향식 · 혼합 통합 테스트

 

 

 

시스템 테스트

- 개발된 소프트웨어가 해당 컴퓨터에서 완벽하게 수행되는가를 점검

- 기능적 요구사항과 비기능적 요구사항으로 나뉨

 

 

 

 

인수 테스트

- 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 사용자가 직접 테스트

1. 알파 테스트
   통제된 환경에서 개발자 앞에서 사용자가 테스트
2. 베타 테스트
   선정된 최종 사용자가 여러명의 사용자 앞에서 진행
   실업무를 가지고 사용자가 직접 테스트함

---

 

하향식 통합 테스트

프로그램의 상위모듈에서 하위모듈 방향으로 통합하면서 테스트

 

절차:

1. 주요 제어모듈은 작성된 프로그램을 사용하고, 주요 제어모듈의 종속모듈은 스텁으로 대체함
2. 깊이 우선 또는 넓이 우선 등의 통합방식에 따라 하위모듈인 스텁들이 한번에 하나씩 실제 모듈로 교체됨
3. 모듈이 통합될 때 마다 실시
4. 새로운 오류가 발생하지 않음으로 보증하기 위해 회귀테스트 실시

▶ 스텁: 일시적으로 필요한 조건만을 가지는 실험용 모듈

 

 

상향식 통합 테스트

프로그램의 하위모듈에서 상위모듈 방향으로 통합하면서 테스트

 

절차:

1. 하위모듈들을 클러스터로 결합
2. 상위모듈에서 데이터의 입출력을 확인하기위해 더미모듈인 드라이버를 작성
3. 통합된 클러스터 단위로 테스트
4. 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고, 드라이버는 실제 모듈로 대체됨

▶ 테스트 드라이버: 테스트 대상의 하위모듈을 호출, 파라미터 전달, 모듈 테스트 수행 후 결과를 도출하는 도구