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

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

 

완벽한 테스트 불가능

결함 집중(Defect Clustering)

파레토 법칙 : 20%의 코드에서 전체 결함의 80%가 발생한다.

살충제 패러덕스(Pesticide Paradox)

반복된 동일한 테스트는 더 이상 결함을 발견하지 못한다.

테스트는 지속적으로 수정 보완이 이루어져야 한다.

테스팅은 정황(Context) 의존

환경에 따라 테스트 결과는 달라질 수 있으니 정황을 달리하여 테스트를 실행해야 한다.

오류-부재의 궤변(Absence of Errors Fallacy)

요구사항을 만족시키지 못하면 품질이 높다고 말할 수 없다.

테스트와 위험은 반비례

테스트의 점진적 확대

테스트의 별도 팀 수행

 

애플리케이션 테스트 분류

 

정적 테스트 : 프로그램 실행 X, 소스코드, 명세서로 분석, 테스트

(ex 워크스루, 인스펙션, 코드검사)

동적 테스트 : 프로그램 실행 O, 개발 모든 단계에서 수행

(ex 화이트박스검사, 블랙박스검사)

 

명세기반 테스트 : 사용자 요구사항에 대한 명세를 테스트 케이스로 구현했는지 여부

(ex 동등 분할, 경계값 분석)

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

(ex 구문기반, 결정기반, 조건 기반

경험기반 테스트 : 테스터의 경험을 기반으로 수행, 요구사항 불충분, 시간제약시 사용

(ex 에러 추정, 체크 리스트, 탐색적 테스팅)

 

검증(Verification) : 개발자 시각에서 제품 생산 과정 테스트

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

회복(Recovery) 테스트 : 고의로 결함을 준 후 복구 과정 테스트

안전(Security) 테스트 : 시스템 보호 도구가 안전한지 테스트

강도(Stress) 테스트 : 과도한 부하를 걸어 시스템이 정상 작동하는지 테스트

성능(Performance) 테스트 : 응답시간,처리량을 통해 실시간 성능과 전체적인 효율성 테스트

구조(Structure) 테스트 : 내부 논리 구조와 소스 코드 복잡도 평가

회귀(Regression) 테스트 : 수정된 코드 결함 유무 테스트

병행(Parallel) 테스트 : 변경 전후 소프트웨어에 동일한 입력값을 넣어 결과를 비교

 

 

테스트 기법에 따른 애플리케이션 테스트

 

화이트박스 테스트(White Box Test)

 

모듈의 원시코드를 오픈하여 프로시저 설계의 제어구조(데이터 흐름, 루프, 조건)를 기반으로 설계된 절차에 초점을 둔 구조적 테스트(테스트 과정의 초반부에 실행)

 

종류

기초경로 검사 : 설계의 논리적 복잡성을 측정, 실행 경로의 기초를 정의

제어구조 검사 : 조건검사(Condition Testing) 모듈 내 논리적 조건 테스트

루프검사(Loop Testing)　반복(loop)구조를 초점으로 테스트

데이터흐름검사(DataFlow Testing) 변수정의 및 사용위치를 초점으로 테스트

 

검사기법 검증 기준

검사기법이 얼마나 테스트에 적당한지 판단하는 기준

 

문장검증 기준(Statement Coverage) 소스의 모든 구문이 한 번 이상 수행

분기검증 기준(Branch Coverage)　소스코드의 모든 조건문이 한 번 이상 수행

조건검증 기준(Condition Coverage)　모든 조건문 중 조건이 True인 경우, False인 경우

한 번 이상 수행

분기/조건 기준(Branch/Condition Coverage)　모든 조건문이 포함하는 개별 조건식의 결과 가 True와 False인 경우 한 번 이상 수행

 

블랙박스 테스트(Black Box Test)

사용자 요구사항 명세를 보며 소프트웨어 인터페이스에서 구현된 기능을 위주로 테스트

(테스트 후반부에 진행)

 

종류

동치분할 검사 : 입력 자료에 초점을 맞춘 테스트 케이스

(타당한 입력값, 비적합 입력값 결과 비교)

경계값 분석 검사 : 오류가 많은 경계값에 초점을 맞춘 테스트 케이스

원인효과 그래프 검사 : 입력데이터 간의 관계 및 출력 상황 분석하여 테스트 케이스 선정

오류 예측 검사 : 경험과 감각으로 테스트하는 기법

다른 기법으로는 못 찾는 오류 검출하는 보충적 검사기법(데이터 확인 검사)

비교 검사 : 여러 버전의 프로그램에 동일한 테스트 자료 제공 후 동일 결과 여부 확인

 

 

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

 

 

단위 테스트(Unit Test)

코딩 완료후 설계의 최소 단위인 모듈이나 컴포넌트에 초점 맞추어 테스트

사용자의 요구에 맞추어 기능성을 최우선

 

구조기반 테스트(화이트 박스 테스트) 제어흐름, 조건결정

명세기반 테스트(블랙 박스 테스트) 동등분할, 경계값 분석

 

 

통합 테스트(Integration Test)

검사 완료된 모듈들을 결합하여 하나의 완성된 시스템으로 생성

모듈 간 컴포넌트 간 상호작용 요류 검사

 

비점진적 통합 방식 : 모든 모듈이 미리 결합되어 있는 프로그램 테스트

규모가 작은 소프트웨어, 단시간 테스트

오류 발견 및 수정이 어렵다

(빅뱅 통합 테스트 : 단위테스트가 끝난 후 모듈을 모두 결합시켜 테스트)

 

점진적 통합 방식 : 모듈 단위 단계적 통합 방식, 오류 수정 용이

인터페이스와 관련된 오류 완전 테스트

 

1) 하향식 통합 테스트 (Top Down Integration Test)

 

주요모듈 기준, 상위 모듈에서 하위 모듈로 통합

깊이 우선 통합법( 아래로 종속된 모듈 먼저 통합 )

넓이 우선 통합법( 같은 레벨의 모듈 먼저 통합 )

 

개발을 진행하며 테스트를 병행한다.

테스트에 필요한 하위모듈이 개발되지 않아 임시품이 필요함

이를 스텁(stub)이라 한다.

 

개발하며 스텁을 실제 모듈로 교체

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

보증을 위해 회귀테스트(Regression Test) 실시

*회귀테스트 : 이미 테스트 된 프로그램의 테스팅을 반복하는 것

 

2) 상향식 통합 테스트(Bottom up Integration Test)

 

하위 모듈에서 상위 모듈로 테스트 진행

종속 모듈의 그룹인 클러스터(Cluster) 사용

 

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

입출력 확인을 위한 더미 상위 모듈(드라이버)를 결합

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

클러스터는 상위로 이동, 드라이버는 실제 모듈로 교체

 

3) 혼합식 통합 테스트

 

하위 수준에서는 상향식, 상위수준에서는 하향식

샌드위치 통합 테스트 방법

 

 

시스템 테스트(System Test)

개발된 소프트웨어가 해당 시스템에서 완벽히 수행되는가 체크

실제 사용 환경과 유사한 테스트 환경에서 테스트 수행 (환경적 장애 리스트)

 

기능적 요구사항 : 요구사항 명세서, 비즈니스 절차, 유스케이스 (사용자 중심)

(명세서 기반 블랙박스 테스트)

비기능적 요구사항 : 성능, 회복, 보안, 내부 시스템의 메뉴구조, 웹페이지의 네비게이션 등

( 구조적 요소에 대한 화이트 박스 테스트 시행 )

 

 

인수테스트(Acceptance Test)

 

개발한 소프트웨어가 사용자 요구를 충족하는지 테스트

사용자가 직접 테스트한다.

문제없으면 사용자가 소프트웨어를 인수하고 프로젝트는 종료된다.

 

사용자 인수 테스트 : 사용자가 인수하여 시스템의 적절성 확인

(요구 충족 여부)

운영상 인수 테스트 : 시스템관리자가 시스템 인수하여 수행하는 테스트

(백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검)

계약 인수 테스트 : 계약상의 조건을 준수하는지 여부

규정 인수 테스트 : 소프트웨어가 정부 규정 및 지침에 맞게 개발되었는지 여부

알파 테스트 : 사용자가 개발자와 개발자의 장소에서 테스트( 통제된 환경, 함께 오류기록 )

베타 테스트 : 선정된 최종 사용자가 여러 명 앞에서 테스트

실업무 사용자가 테스트, 제어되지 않은 환경에서 시행, 개발자에게 오류보고

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

 

 

테스트가 이루어지는 절차

 

1) 테스트 계획 : 테스트 계획서 작성

2) 테스트 분석 및 디자인 : 사용자의 요구사항 분석

3) 테스트 케이스 및 시나리오 작성

 

테스트 케이스 : 사용자 요구사항의 준수 정도, 제대로 작동하는지 확인하는 명세서

명세기반 테스트의 설계 산출물

 

1) 테스트 계획 검토 및 자료확보

2) 위험 평가 및 우선순위 결정

3) 테스트 요구사항 정의 : 사용자 요구사항, 테스트 대상 재검토

4) 테스트 구조 설계 및 테스트 방법 결정

5) 테스트 케이스 정의 : 입력값, 실행 조건 예상 결과 기술

6) 테스트 케이스 타당성 확인 및 유지보수

 

테스트 시나리오 : 여러 개의 테스트 케이스의 동작 순서 기술

 

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

결과를 비교하는 기법

 

제한된 검증 : 모든 테스트 케이스에 적용 불과

수학적 기법 : 참값은 수학적 기법으로 구한다.

자동화 가능 : 테스트 프로그램 실행, 결과비교, 커버리지 측정을 자동화

 

종류

참(True) 오라클 : 모든 테스트 케이스 결과 제공, 모든 오류 검출

샘플링(Sampling) 오라클 : 특정 테스트 케이스 결과 제공

추정(Heuristic) 오라클 : 특정 테스트 케이스 결과 제공, 나머지는 추정

일관성(Consistent) 오라클 : 애플리케이션 변경이 있을 때, 테스트 케이스 수행 전 과 후의 결과가 동일한지 확인하는 오라클

 

 

테스트 자동화

반복적인 수행 절차를 스크립트로 구현한 자동화 도구 ( 휴먼에러 줄이고 정확성 유지 )

 

테스트 하네스 도구 : 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경

 

-테스트 드라이버 : 테스트 대상의 하위모듈 호출, 파라미터 전달, 모듈 테스트 후 결과 도출

-테스트 스텁(Test Stub) : 일시적인 필요조건만을 가진 테스트용 모듈

-테스트 슈트(Test Suites) : 테스트대상 컴포넌트,모듈,시스템에 사용되는 테스트케이스집합

-테스트 케이스 : 사용자 요구사항을 정확히 준수했는지 확인을 위한 테스트 항목 명세서

(입력값, 실행조건, 기대결과)

-테스트스크립트 : 자동화된 테스트 실행절차 명세서

-목 오브젝트(Mock Object) : 사전에 사용자 행위를 조건부로 입력해두면

상황에 맞는 예정된 행위를 수행하는 객체

 

4) 테스트 수행

 

5) 테스트 결과 평가 및 리포팅 : 테스트 결과서 작성

 

6) 결함 추적 및 관리

결함 추적 및 파악 관리 프로세스

 

에러 발견

에러 등록 : 에러결함 관리 대장

에러 분석 : 결함인지 아닌지 분석

결함 확정 : 결함 확인 (확정상태)

결함 할당 : 확정된 결함을 담당자에게 할당 (할당 상태)

결함 조치 : 담당자는 수정 조치 (조치 상태)

결함 조치 검토 및 승인 : 다시 테스트 수행 (완료 상태)

 

 

결함 처리 프로세스

 

결함 관리 계획

결함 기록

결함 검토

결함 수정

결함 재확인

결함 상태 추적 및 모니터링 활동

최종결함 분석 및 보고서 작성

 

결함 상태 추적

 

발견된 결함은 상태를 지속적으로 추적해야한다.

결함 관리 측정 지표의 속성값들을 분석하면 향후 결함이 발견될 컴포넌트와 모듈을 추정가능

 

결함 관리 측정 지표

결함분포 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수

결함추세 : 테스트 진행 시간에 따른 결함 수의 추이

결함에이징 : 특정 결함 상태로 지속되는 시간 측정

 

 

---

 

참고자료

2021 시나공 정보처리기사 실기