2-4 애플리케이션 테스트 관리

애플리케이션 테스트

 

1. 테스트 개념

 

개념	구현된 S/w 대상으로 오류 찾아내는 작업 s/w나 시스템이 사용자가 요구하는 기능의 동작/성능/사용성/ 안정성 등 만족하는지 확인 위해 s/w 결함 찾아내는 활동 품질 정보를 이해 관계자에게 제공하기 위해 수행된 평가 목적은 결함 탐지, 수정 관련 s/w나 장비들이 설계/개발 안내 요구사항 충족 모든 종류 입력에 정확하게 응답, 수용 가능한 시간 내에 기능 수행, 충분히 사용 가능한지 평가 의도된 환경에서 설치, 실행할 수 있으며, 이해 관계자가 원하는 일반적인 결과 달성하는지 평가
필요성	오류 발견 관점 오류 예방 관점(코드 리뷰, 인스펙션) 품질 향상 관점
테스트 관련 용어	디버그(Debug/Debugging) 컴퓨터 프로그램 논리적인 오류 찾아내는 과정 디버거(Debugger) 디버그 돕는 도구 디버깅하려는 코드에 중단점 지정하여 실행 중단, 코드 단계적으로 실행하여 저장된 값 확인 워크스루(walk-through) s/w 생명주기 각 단계마다 산출된 명세서로 오류 찾아내는 비정형 검토 회의 조사하는 기능 문제점, 시스템 전반의 문제점 찾아내어 시스템을 전체적으로 안정화 정형 기술 검토(FTR) 검토 지침 제품 검토 집중성(오류 검출에 초점) 사전 준비성 의제 제한성 안건 고수성 논쟁 반박의 제한성 문제 공개성 참가 인원의 제한성 문서성
테스트 원칙	테스트는 계획 단계부터 해야 함(생명주기 SDLC 단계마다 실시) 결함을 밝히는 활동 개발자가 테스트하지 않음

 

 

테스트 원칙

낚시의 법칙	특정 기능, 모듈 , 라이브러리에서 결함 많이 발견
Pareto의 법칙	전체 결함의 80%는 소프트웨어 제품 전체 기능 중 20%에 집중
완벽한 테스트는 불가능	위험 분석/우선 순위 고려
결함 집중 (Defect Clustering)	대부분 소수 특정 모듈에 집중
살충제 패러독스 (Pesticide Paradox)	동일한 테스트 케이스 반복 실행 시 새 결함 발견 어려우므로 주기적인 점검/개선 필요
오류-부재의 궤변 (Absence of Errors Fallcacy)	사용자 요구사항 만족하지 못하면 오류 제거해도 품질 높은게 아니며 테스트는 오류 100% 제거 아닌 일정 수준 이하로 줄이는 것이 목적
Long tail 법칙	사소해 보이는 80% 다수가 20% 소수 핵심보다 뛰어난 가치 창출

 

2. 테스트 프로세스

 

 

테스트 수행 절차(단통시인설)

단위 테스트	사용자 요구사항에 대한 단위 모듈, 서브 루틴 등 테스트하는 단계 코드 테스트, 모듈 테스트, 프로그램 설계 테스트
통합 테스트 (Integration)	단위 테스트 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간 상호작용 검증하는 테스트 단계 결합 테스트, 구조 설계 테스트
시스템 테스트	통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지 검증하는 테스트 단계
인수 테스트	계약상 요구사항 만족했는지 확인하기 위한 테스트 단계 사용자 참여 테스트
설치 테스트

 

 

3. 테스트 기법

 

 

분석 기법	동적 분석 프로그램 실행 요구 화이트 박스/블랙박스 테스트 정적 분석 소스 코드 구조 분석하여 논리적으로 검증 인스펙션: 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류 찾아내는 공식적 검토 코드 테스트 wlak-through
실행 기법	화이트 박스 프로그램 내부 보며 수행 블랙 박스 외부 사용자 요구사항 명세 보며 테스트
설계 기법	구조 기반 설계 s/w 내부 논리 흐름에 따라 작성 구문/결정/조건/조건 결정/변경 조건 결정/멀티 조건 기반 명세 기반 설계 주어진 명세를 테스트 케이스로 구현하는지 확인 동등 분할/경계값 분석/결정 테이블/정형 명세/유스케이스/유한 상태 기계/페어 와이즈/직교 배열 테스트 경험 기반 설계 유사 s/w나 유사 기술 평가에서 테스터 경험 토대로 한 직관, 기술 능력 기반
자동화 기법	설계 자동화 실행/모니터링 자동화 관리 자동화

 

 

단위 테스트

 

1. 단위 테스트

 

개념	원시 프로그램 모듈/컴포넌트 대상으로 화이트박스 테스트 실시 모듈 기능 수행 여부 판정하고 내부에 존재하는 논리적인 오류 검출
수행 방법	화이트 박스 테스트 단위 테스트 가장 기본적 방법 모듈 내부 소스 보며 테스트 테스트 케이스 다양화 메소드 기반 테스트 단위 모듈 외부로 공개된 메소드 기반 테스트 메소드에 매개 변수(파라미터)를 다르게 호출하며 테스트 화면 기반 테스트 사용자가 직접 데이터 입력하여 수행 화면 연계 서비스 컴포넌트, 비즈니스 컴포넌트 및 공통 컴포넌트 묶어 참여 화면 보며 준비된 시나리오로 테스트 드라이버와 스터브 활용 모듈 개발 안된 경우 드라이버: 사용자 화면 없을 시 스터브: 서비스/비즈니스/공통 컴포넌트 등 하위 모듈 개발 안 되었을 경우

 

 

 

2. 테스트 실행 기법

 

	화이트 박스 테스트	블랙 박스 테스트
개념	기본적 방법 소스 코드 모든 문장 한번 이상 수행 테스트케이스 다양화 프로그램 소스 직접 보며 오류 발견 모듈 내부 구현 자세히 테스트(논리적 경로 테스트)	외부 사용자 요구사항 명세 보며 테스트 프로그램 동작만으로 오류 발견 주로 구현된 기능 테스트 입력/출력에 의해 기능 테스트
종류	기초 경로 테스트(Base Path Testing, Structure Testing) 루프 테스트(Loop) 데이터 흐름 테스트(Data Flow)  조건(Condition coverage)	동등(균등) 분할(Equivalence Partitioning) 경계값 테스트(Boundary Value Analysis) 오류 예측(Error Forecast) 원인 결과 그래프(Cause and Effect Graphing) 비교 테스트(Compare Testing)
발견 가능 오류	세부적 논리 구조 상 반복문 수행 경로	부정확하거나 빠진 오류 인터페이스 자료 구조 상 성능 시작과 종결 상

 

 

테스트 상세 내용

기초 경로 테스트	화이트 박스 테스트 유형 중 하나로 수행 가능한 모든 경로 테스트 흐름 도표 작성 복잡도(McCabe Cyclomatic)  = 간선으로 막힌 영역 + 1
경계값 분석 (Boundary Value Analysis)	범위 경계 집중 검사 2-value: 경계에 있는 값/ 바로 위, 아래 중 하나의 값 3-value: 경계에 있는 값/ 경계 바로 위의 값/ 경계 바로 아래의 값
비교 테스트	블랙 박스 테스트 유형 중 하나로 여러 버전 프로그램에 같은 입력값 넣어 동일한 결과 데이터 나오는지 비교
동등(균등) 분할 (Equivalence Partitioning)	검사 사례를 정상적/잘못된 데이터 50%씩 정해서 입력 정상 데이터-정상 결과/오류 데이터-오류 메시지 출력 및 조치 확인
결정 테이블 (Decision table)	어떤 결정 위해 생각할 수 있는 복잡한 모든 조건, 각 조건에 대해 취해야할 행동 모두 열거한 테이블을 모두 대입하여 검사
정형 명세 기반 (Formal Specification base)	주기적 테스트 수행으로 오해의 소지 없앰
유스케이스 (Usecase)	프로그램 흐름 따라 테스트 시나리오 기반으로 테스트

 

 

 

3. 단위 디버깅

 

개념	단위 테스트로 논리적 오류 발견되었을 때 수행하는 과정 오류 발생 소스 코드 흐름 따라가며 변숫값 변화, 조건식 수행 과정 파악 IDE 도구 이용하여 디버깅
자동화 도구	Junit: Java 기반 CppUnit: C+ 기반 Unitest: python 기반

 

 

 

 

 

Reference

https://book.naver.com/bookdb/book_detail.naver?bid=17134434 

이기적 정보처리기사 필기 기본서