정보처리기사 실기 요약 - 7장. 애플리케이션 테스트 관리

01. 애플리케이션 테스트

 

1) 애플리케이션 테스트: 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차

 

2) 애플리케이션 테스트의 기본 원리

- 완벽한 테스트 불가능: 소프트웨어에 아예 결함이 없다고 증명할 수 없음.

- 파레토 법칙: 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙

- 살충제 패러독스: 동일한 테스트 케이스로 동일한 테스트를 반복하면 더이상 결함이 발견되지 않는 현상

- 오류-부재의 궤변: 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 안됨

 

02. 애플리케이션 테스트의 분류

 

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

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

     - 인스펙션, 워크스루, 코드 검사 등

- 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트

     - 블랙박스 테스트(기능 테스트): 각 기능이 완전히 작동되는 것을 입증하는 테스트

          - 동치 분할 검사(Equivalence Partitioning Testing, 동치 클래스 분해): 타당한 입력 자료와 타당하지 않은 입력 자료를 균등하게 입력 후 맞는 결과가 출력되는지 검사

          - 경계값 분석(Boundary Value Analysis): 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법

          - 원인-효과 그래프 검사(Cause-Effect Graphing Testing): 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석해 효용성이 높은 케이스를 선정

          - 오류 예측 검사(Error Guessing): 과거의 경험이나 확인자의 감각으로 테스트하는 기법

          - 비교 검사(Comparison Testing): 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 나오는지 테스트

- 화이트박스 테스트: 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법

     - 기초 경로 검사(Base Path Testing): 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 기법

     - 제어 구조 검사(Control Structure Testing): 조건 검사, 루프 검사, 데이터 흐름 검사

     - 문장 검증 기준(Statement Coverage): 모든 구문이 한 번 이상 수행되도록

     - 분기 검증 기준(Branch Coverage): 모든 조건문이 한 번 이상 수행되도록

     - 조건 검증 기준(Condition Coverage): 모든 조건문의 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록

     - 분기/조건 기준(Branch/Condition Coverage): 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록

 

2) 테스트 기반에 따른 테스트

- 명세 기반 테스트: 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하는지

- 구조 기반 테스트: 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인

- 경험 기반 테스트: 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트

 

3) 시각에 따른 테스트

- 검증(Verification) 테스트: 개발자의 시각에서 제품의 생산 과정을 테스트하는 것

- 확인(Validation) 테스트: 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것

 

4) 목적에  따른 테스트

- 회복, 안전, 강도, 성능, 구조, 회귀, 병행 테스트

 

03. 개발 단계에 따른 애플리케이션 테스트

 

1) 단위 테스트: 모듈이나 컴포넌트에 초점을 맞춰 테스트

 

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

- 비점진적 통합 방식: 단게적으로 통합하는 절차  없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트

- 점진적 통합 방식: 모듈 단위로 단계적으로 통합하면서 테스트하는 방법

     - 하향식 통합 테스트: 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법

          ① 주요 제어 모듈은 작성된 프로그램을 사용하고, 종속 모듈들은 스텁(Stub)으로 대체

          ② 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체됨

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

          ④ 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트 실시

     - 상향식 통합 테스트: 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법

          ① 하위 모듈들을 클러스터(Cluster)로 결합함

          ② 상위모듈에서 더미 모듈인 드라이버를 작성

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

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

     - 혼합식 통합 테스트: 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트 지원

 

3) 시스템 테스트: 개발된 소프트웨어가 완벽하게 수행되는가를 점검하는 테스트

 

4) 인수 테스트: 사용자의 요구사항을 충족하는지에 중점을 두고 테스트

 

04. 애플리케이션 테스트 프로세스

 

1) 애플리케이션 테스트 프로세스: 개발된 소프트웨어 사용자의 요구대로 만들어졌는지, 결함이 없는지 등을 테스트하는 절차

 

05. 테스트 케이스/테스트 시나리오/테스트 오라클

 

1) 테스트 케이스: 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 테스트 항목에 대한 명세서

 

2) 테스트 시나리오: 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스를 묶은 집합

 

3) 테스트 오라클: 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참값을 대입하여 비교하는 기법

     - 종류: 참 오라클, 샘플링 오라클, 추정 오라클, 일관성 검사 오라클

 

05. 테스트 자동화 도구

 

1) 테스트 자동화: 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함

 

2) 정적 분석 도구: 프로그램을 실행하지 않고 분석하는 도구

 

3) 테스트 실행 도구: 스크립트 언어를 사용하여 테스트를 실행하는 도구

 

4) 성능 테스트 도구: 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인하는 도구

 

5) 테스트 통제 도구: 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구

 

6) 테스트 하네스 도구: 테스트가 실행될 환경을 시뮬레이션하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구

 

06. 결함 관리

 

1) 결함: 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 것

 

2) 결함 상태 추적

- 결함 관리 측정 지표: 결함 분포, 결함 추세, 결함 에이징

 

3) 결함 분류: 시스템 결함, 기능 결함, GUI 결함, 문서 결함

 

4) 결함 우선 순위: 발견된 결함 처리에 신속성을 나타내는 척도

 

07. 애플리케이션 성능 분석

 

1) 애플리케이션 성능: 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도

- 처리량(Throunghput): 일정 시간 내에 애플리케이션이 처리하는 일의 양

- 응답 시간(Response Time): 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간

- 경과 시간(Time Around Time): 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간

- 자원 사용률(Resource Usage): 애플리케이션이 의뢰한 작업을 처리하는 동안의 자원 사용률

 

2) 성능 테스트 도구: 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검하는 도구

 

3) 시스템 모니터링 도구: 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구

 

08. 복잡도

 

1) 시간 복잡도: 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것

- 빅오 표기법: 알고리즘의 실행 시간이 최악일 때를 표기하는 방법

- 세타 표기법: 알고리즘의 실행 시간이 평균일 때를 표기하는 방법

- 오메가 표기법: 알고리즘의 실행 시간이 최상일 때를 표기하는 방법

 

09. 애플리케이션 성능 개선

 

1) 소스 코드 최적화: 나쁜 코드를 배제하고, 클린 코드로 작성하는 것

- 나쁜 코드: 스파게티 코드, 외계인 코드

 

2) 클린 코드 작성 원칙

- 가독성: 누구든지 코드를 쉽게 읽을 수 있도록 작성함

- 단순성: 코드를 간단하게 작성함

- 의존성 배제: 코드가 다른 모듈에 미치는 영향을 최소화함

- 중복성 최소화: 코드의 중복을 최소화함

- 추상화: 상위에서는 간략하게 애플리케이션의 특성을 나타내고 상세 내용은 하위에서 구현함

 

3) 소스 코드 최적화 유형

- 클래스 분할 배치: 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고 크기를 작게 작성

- 느슨한 결합: 추상화된 자료 구조와 메소드를 구현함으로써 클래스 간의 의존성을 최소화

 

4) 소스 코드 품질 분석 도구

- 정적 분석 도구: 작성한 소스 코드를 실행하지 않고 분석

- 동적 분석 도구: 작성한 소스 코드를 실행하여 분석