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

 

01. 애플리케이션 테스트 케이스 설계

 

애플리케이션 테스트: 결함을 찾기 위해 애플리케이션을 작동시키는 일련의 행위와 절차

 

결함: 소프트웨어 개발 활동을 수행함에 있어서 시스템이 고장을 일으키게 하고, 오류가 있을 경우 발생한다.

 

애플리케이션의 기본 원리

1. 살충제 패러독스(Pesticide Paradox): 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없다.

2. 테스팅은 정황(Context)에 의존: 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행해야 한다.

3. 오류-부재의 궤변(Absence of Errors Fallacy): 사용자의 요구사항을 만족하지 못하는 오류를 발견하고 그 오류를 제거하였다고 해도, 품질이 높다고 말할 수 없다.

4. 결함 집중(Defect Clustering): 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다. 결함은 발생한 모듈에서 계속 추가로 발생할 가능성이 높다.

5. 파레토의 법칙: 전체 결함의 80%는 전체 모듈 20% 내에서 발견된다.

 

테스트 케이스: 소프트웨어가 목표하는 보장성을 만족할 수 있도록 가능한 많은 결함을 발견할 수 있어야 한다.

 

테스트 케이스 구성 항목

- 식별자 번호

- 사전(테스트)조건

- 테스트 데이터

- 수행 절차

- 예상 결과

 

테스트 단계에 의한 분류

1. 모듈(단위) 테스트: 하나의 모듈만을 테스트

2. 통합 테스트: 시스템 모듈 간의 상호 인터페이스에 관한 테스트

3. 인수 테스트: 사용자의 요구사항을 만족하는지를 확인하는 테스트

4. 시스템 테스트: 시스템이 초기의 목적에 부합하는지에 대한 테스트

 

테스트 목적에 의한 분류

1. 기능 테스트: 주어진 입력에 대해 기대되는 출력 제공 여부 테스트

2. 성능 테스트: 응답 시간, 처리량, 메모리 활용도, 처리 속도 등을 테스트

3. 스트레스 테스트: 정보의 과부하 시, 반응 정도를 테스트

4. 복잡도 테스트: 논리 경로의 복잡도 평가 테스트

 

테스트에 대한 시각에 대한 분류

1. 검증(Verification): 개발자의 시각에서 점검

2. 확인(Validation): 사용자의 시각에서 점검

 

테스트 기법에 의한 분류

1. 블랙박스 테스트: 외부 명세서를 기준으로 그 기능과 성능을 테스트

2. 화이트박스 테스트: 내부의 논리적 구조를 테스트

 

프로그램 실행 여부에 따른 분류

1. 정적 테스트: 프로그램을 실행하지 않고 분석하는 테스트 ex) 인스펙션, 워크스루, 코드 검사

2. 동적 테스트: 프로그램을 실행하여 결함을 발견하는 테스트 ex) 화이트박스 테스트, 블랙박스 테스트

 

모듈 테스트(Unit Test, 단위 테스트)

: 설계의 최소 단위인 모듈에 초점을 두고 검사하는 단계이다.

: 화이트박스 테스트 기법이 적용된다.

: 가동기(Driver, 드라이버)와 가짜 모듈(Stub, 스텁)들이 필요하다.

 

테스트 하네스: 특정 환경에서 테스트를 하기 위해 만든 소프트웨어 코드와 데이터이다. ex) 테스트 드라이버, 테스트 스텁

 

통합 테스트(Integration Test)

: 모듈들을 하나로 결합하여 시스템으로 완성하는 과정에서의 테스트

: 시스템을 구성하는 모듈 사이의 인터페이스와 결합을 테스트

: 동시식, 하향식(스텁, Stub), 상향식(드라이버, Driver), 연쇄식 등이 있다.

 

시스템 테스트(System Test)

: 사용자의 모든 요구를 하나의 시스템으로서 완벽하게 수행하기 위해서는 다양한 테스트들이 필요하다.

- 외부 기능 테스트: 외부 명세의 충족성을 테스트

- 내부 기능 테스트: 사용자의 상세 기능 요구를 테스트

- 부피 테스트: 상당량의 데이터를 처리해 보도록 여건을 조성

- 스트레스 테스트(민감성 테스트): 다양한 스트레스를 가해 보는 것

- 성능 테스트: 응답 속도, 처리량, 처리 속도 등을 테스트

- 호환성 테스트: 기존 소프트웨어와 호환성

- 신뢰성 테스트: 오류를 발생시키고 고장을 내는 정도를 테스트

- 복구 테스트: 자체 결함이나 하드웨어 고장, 데이터의 오류로부터 어떻게 회복하느냐를 평가

- 보수 용이성 테스트

 

인수 테스트(Acceptance Testing, 검증 테스트)

: 사용자측 관점에서 소프트웨어가 사용자의 요구를 충족시키는가를 두고 테스트한다.

1. 알파 테스트: 개발자의 장소에서 사용자가 개발자 앞에서 행하는 기법

2. 베타 테스트: 최종 사용자가 여러 명의 사용자 환경에서 테스트를 수행. 개발자는 일반적으로 참석하지 않는다.

 

테스트 시나리오(테스트 조건, 테스트 가능성)

: 테스트할 수 있는 모든 기능을 말한다. 여러 개의 테스트 케이스들의 집합을 수행하기 위한 동작 순서를 기술한 문서.

 

테스트 시나리오 작성 절차

1. 요구사항 문서 리딩

2. 사용자 행동 및 목표 파악

3. 다양한 테스트 시나리오 나열

4. 추적성 매트릭스 생성

5. 생성된 시나리오 검토

 

테스트 지식 체계(ISO/IEC 29119): 소프트웨어 테스팅을 위한 국제 표준으로 검증 및 확인 활동 중에서 동적 테스팅에 대한 절차와 기법 등을 다룬다.

 

테스트 오라클(Test Oracle)

: 테스트의 결과가 참인지 거짓인지를 판단하기 위해 사전에 정의된 참값을 입력하여 비교하는 기법 및 활동

 

테스트 오라클의 종류

1. 참(True) 오라클: 모든 입력값에 대해 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클

2. 샘플링 오라클: 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해 주는 오라클

3. 휴리스틱(Heuristic) 오라클: 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클

4. 일관성 검사 오라클: 수행 전과 후의 결과의 값이 동일한지 확인하는 오라클

 

블랙박스 테스트

: 외부 명세로부터 직접 테스트하여 데이터를 선정하는 방법

 

블랙박스 테스트 기법

1. 동등 분할(균등 분할, 동치 분할): 입력 조건을 중심으로 입력 조건에 타당한 값과 그렇지 못한 값을 설정하여 각 동등 클래스 내의 임의의 값을 테스트 사례로 선정한다.

2. 경계값 분석: 중간값보다는 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값에서 테스트 사례를 선정한다.

3. 원인-결과 그래프 기법: 외부 명세에 의한 입련 조건과 그 입력으로 발생되는 출력을 논리적으로 연결시킨 그래프로 표현하여 테스트 사례를 유도해 낸다.

4. 오류 추측 기법: 감각과 경험으로 찾아내는 일련의 보충적 테스트 기법이다.

5. 비교 검사 기법: 똑같은 기능의 소프트웨어를 개발하여 비교한다.

 

화이트박스 테스트

: 프로그램 내의 모든 논리적 구조를 파악하거나, 경로들의 복잡도를 계산하여 테스트 사례를 만든다.

: 소프트웨어 형상의 구조를 이용한다.

 

화이트박스 테스트 기법

1. 기초 경로 테스트(구조 테스트, 복잡도 테스트): McCabe에 의해 제안되었으며, 상세 설계 및 원시 코드를 기초로 논리 흐름도를 작성하며, 프로그램의 논리적 복잡도를 측정한다.

2. 루프 테스트: 프로그램 반복 구조에 국한해서 실시하는 기법이다. 발견 가능한 오류는 초기화 결함, 인덱싱 및 증가 결함, 루프의 경계선에서 나타나는 경계 결함 등

3. 조건 테스트: 모듈 내에 포함된 논리적 조건을 검사하여 테스트 사례를 설계하는 방법이다. 

4. 데이터 흐름 테스트: 변수 정의의 위치와 변수들의 사용에 따라 검사 경로를 선택하는 방법이다.

 

화이트박스 테스트 검증 기준

- 문장 검증 기준: 모든 구문

- 분기 검증 기준: 모든 조건

- 조건 검증 기준: 모든 조건문의 참, 거짓

- 분기/조건 기준: 모든 조건과 조건문의 참, 거짓

 

 

02. 애플리케이션 통합 테스트와 성능 개선

 

결함 관리: 테스트 수행 후 발생한 결함들이 다시 발생하는 것을 방지하기 위해 결함을 추적하고 관리하는 활동

 

결함 관리 상용 도구

- HP QC: HP의 품질관리 프로그램

- IBM Clear Quest: IBM에서 제작

- JIRA: 아틀래시안에서 제작

 

결함 관리 오픈 소스 도구

- Bugzilla

- Trac

- Mantis

 

테스트 자동화 도구: 테스트에 포함되는 여러 과정들을 자동적으로 지원하여 생산성 및 일관성을 향상시킬 수 있다.

- QTP: HP의 툴

- Rational Robot: IBM의 툴

- Selenium: 오픈소스 웹 자동화 툴. 모든 종류의 웹 브라우저들을 지원

 

테스트 장치 구성요소 

- 테스트 드라이버

- 테스트 스텁

- 테스트 슈트

- 테스트 케이스

- 테스트 스크립트

- 목 오브젝트

 

통합 테스트

: 단위 테스트(모듈 테스트)가 끝난 모듈들을 하나로 결합하여 시스템으로 완성하는 과정에서의 테스트이다.

: 시스템을 구성하는 모듈 사이의 인터페이스와 결합을 테스트하며, 시스템 전체의 기능과 성능을 테스트한다.

1. 빅뱅 통합(비점진적 통합, 차분 통합 검사): 모든 모듈이 한꺼번에 결합되어 하나로 테스트

2. 하향식 통합: 검사 제어 소프트웨어로 Stub(스텁)을 사용. 새로운 오류가 발생하지 않음을 보장하기 위해 회귀 테스트를 실시한다.

3. 상향식 통합: 검사 제어 소프트웨어로 Driver(드라이버)를 사용

4. 연쇄식 통합: 중심을 이루는 기능을 처리하는 모듈의 최소 집합이 제일 먼저 구현되고 통합된다. 샌드위치형 통합으로 우선적으로 통합을 시도할 중요 모듈을 선정하여 중요 모듈로부터 쌍방향으로 통합을 진행한다.

 

애플리케이션 성능: 최소한의 자원을 사용하여 사용자가 요구한 많은 기능을 신속하게 처리할 수 있는 정도

 

애플리케이션의 성능을 측정하기 위한 지표

- 처리량

- 응답 시간: 요청/응답

- 경과 시간: 입/출력

- 자원 사용률

 

성능 테스트 도구

- JMeter: 다양한 프로토콜 지원

- LoadUI: 서버 모니터링을 지원하는 UI 강화

- OpenSTA: HTTP, HTTPS 지원

 

성능 테스트 종류

1. 부하 테스트: 부하를 순차적으로 증가시키면서 비정상 상태가 발생하는 임계점을 찾아낸다.

2. 스트레스 테스트: 시스템의 최고 성능 한계를 측정하기 위한 테스트

3. 스파이크 테스트: 갑자기 부하가 증가하거나 줄어들었을 때 정상적인 반응하는지 확인하기 위한 테스트

4. 내구성 테스트: 긴 시간동안 테스트 진행

 

소스 코드 최적화

: 실행 시간이나 메모리를 줄이는 것

: 크기가 작고 보다 빠르며 기억장소 요구량이 작은 코드로 개선하는 것

 

코드 리팩토링

: 내부 구조를 변경하는 것으로 프로그램의 가치를 상승시킨다.

: 코드 스멜(Code Smell)을 고치고 다듬는 과정이다.

 

코드 스멜: 읽기 어려운 코드, 중복된 로직과 복잡한 조건을 가진 프로그램

 

외계인 코드: 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램

 

소스 코드 품질 분석 도구

: 소프트웨어 검증, 테스팅 등의 품질 관련한 부분이 중요해지고 있어 사용하게 된다.

- 정적 분석 도구

1. cppcheck: C++

2. pmd: 결함 유발 코드

3. checkstyle: Java

- 동적 분석 도구

1. Valgrind: 메모리, 스레드 결함

2. Avalanche: 결함, 취약점 분석

 

 

 

 

 

참고. 2023 에듀윌 정보처리기사 실기 기본서