1. 애플리케이션 테스트 케이스 설계하기
애플리케이션 테스트
-
개요 : 애플리케이션에 잠재되어 있는 결함을 찾아내는 활동
-
필요성
-
오류 발견
-
오류 예방
-
품질 향상
-
-
원리
-
완벽한 테스팅은 불가능
-
결함 집중(파레토의 법칙)
-
살충제 패러독스(Presticide Paradox)
-
태스팅은 정황(Context)에 의존
-
오류-부재의 궤변(Absence of Errors Fallacy)
-
테스트와 위험은 반비례
-
테스트의 점진적 확대
-
개발자와 관계없는 별도의 팀에서 수행
-
-
테스트 프로세스
-
테스트 계획 : 테스트 목표를 정의하고 테스트 대상 및 범위를 결정
-
테스트 분석 및 디자인 : 테스트 목적과 원칙을 검토하고 사용자의 요구사항을 분석
-
테스트 케이스 및 시나리오 작성 : 테스트 케이스를 작성하고 검토 및 확인한 후 테스트 시나리오 작성
-
테스트 수행 : 테스트 환경을 구축한 후 테스트 수행
-
테스트 결과 평가 및 리포팅 : 테스트 결과를 비교 분석하여 테스트 결과서를 작성
-
결함 추적 및 관리 : 결함 발생 위치, 종류 등 결함을 추적하고 관리
-
-
테스트 산출물
-
테스트 계획서 : 테스트 목적, 범위, 일정, 수행 절차, 대상 시스템 구조, 조직의 역할 및 책임 등 테스트 수행을 계획한 문서
-
테스트 케이스 : 사용자의 요구사항을 얼마나 준수하는지 확인하기 위한 입력 값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서
-
테스트 시나리오 : 테스트를 수행할 여러 개의 테스트 케이스의 동작 순서를 기술한 문서
-
테스트 결과서 : 테스트 결과를 비교, 분석한 내용을 정리한 문서
-
애플리케이션 테스트 분류
-
프로그램 실행 여부에 따른 테스트
구분 | 설명 |
정적 테스트 | 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트 |
종류 : 위크스루, 인스팩션, 코드 검사 등 | |
동적 테스트 | 프로그램을 실행하여 오류를 찾는 테스트 |
종류 : 블랙박스 테스트, 화이트박스 테스트 |
-
테스트 기법에 따른 테스트
구분 | 설명 |
화이트박스 테스트 | 원시 코드의 논리적인 모든 경로를 테스트 하여 테스트하여 테스트 케이스를 설계하는 방법 |
종류 : 기초 경로 검사, 제어 구조 검사(조건, 루프, 데이터 흐름) | |
블랙박스 테스트 | 각 기능이 완전히 작동되는 것을 입증하는 테스트, 기능 테스트라고도 함 |
종류 : 동치 분할 검사, 경계값 분석, 원인-효과 그래프 검사, 오류 예측 검사, 비교 검사 |
-
테스트 기반에 따른 테스트
구분 | 설명 |
명세 기반 테스트 | 사용자의 요구사항에 대한 명세를 테스트 케이스로 만들어 확인하는 테스트 |
종류 : 동등 분할, 경계 값 분석 등(블랙박스 테스트) | |
구조 기반 테스트 | 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 |
종류 : 구문 기반, 결정 기반, 조건 기반 등(화이트박스 테스트) | |
경험 기반 테스트 | 테스터의 경험을 기반으로 수행하는 테스트 |
종류 : 에러 추정, 체크 리스트, 탐색적 테스팅 |
-
시각에 따른 테스트
구분 | 설명 |
검증(Verifcation) | 개발자의 시각에서 제품의 생산 과정을 테스트, 명세서대로 완성 됬는지 테스트 |
확인(Validation) | 사용자의 시각에서 생산된 제품의 결과를 테스트, 요구사항과 동작을 테스트 |
목적에 따른 테스트
구분 | 설명 |
회복(Recovery) | 시스템에 결함을 주어 실패를 유도한 뒤 정상적으로 복귀하는지 확인 |
안전(Security) | 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인 |
강도(Stress) | 시스템에 과도한 정보량을 부과하여 과부하 시에도 정상적으로 동작하는지 확인 |
성능(Performance) | 실시간 성능이나 전체적인 효율성을 진단, 응답시간, 처리량 등을 테스트 |
구조(Structure) | 시스템 내부의 논리적인 경로, 소스 코드의 복잡도를 평가 |
회귀(Regression) | 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인 |
병행(Parallel) | 변경된 소프트웨어와 기존 소프트웨어에 동일한 테이터를 입력하여 결과를 비교 |
V 모델
-
개요 : 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현
-
테스트 단계
분류 | 설명 |
단위 테스트 (Unit Testing) |
모듈이나 컴포넌트에 초점을 맞춰 테스트 |
통합 테스트 (Integration Testing) |
단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트 |
시스템 테스트 (System Testing) |
개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트 |
인수 테스트 (Acceptance Testing) |
개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트 |
테스트 케이스(Test Case)
-
개요 : 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지 확인하기 테스트 항목에 대한 명세서
-
작성 순서
-
테스트 계획 검토 및 자료 확보 : 시스템 요구사항과 기능 명세서를 검토하고 테스트 대상 시스템 정보 확보
-
위험 평가 및 우선순위 결정 : 결함의 위험 정도에 따른 우선순위를 결정
-
테스트 요구사항 정의 : 사용자 요구사항이나 테스트 대상을 재검토, 테스트 특성/조건 등을 분석
-
테스트 구조 설계 및 테스트 방법 결정 : 테스트 케이스의 형식과 분류 방법 결정, 테스트 절차, 장비, 도구 등을 결정
-
테스트 케이스 정의 : 테스트 케이스 작성
-
테스트 케이스 타당성 확인 및 유지 보수 : 테스트 케이스의 유용성을 검토
-
테스트 시나리오(Test Scenario)
-
개요 : 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서
-
유의 사항
-
여러 개의 시나리오로 분리하여 작성
-
사용자의 요구사항과 설계 문서 등을 토대로 작성
-
식별자 번호, 순서 번호, 테스트 데이터, 테스트 케이스, 예상 결과, 확인 등을 포함해서 작성
-
테스트 오라클(Test Oracle)
-
개요 : 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동
-
종류
-
참(True) 오라클 : 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클, 모든 오류를 검출 가능
-
샘플링(Sampling) 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클
-
휴릭스틱(Heuristic) 오라클 : 샘플링 오라클을 개선한 오라클, 특정 입력 값에 대해 기대하는 결과를 제공하고 나머지 값들에 대해 휴리스틱(추정)으로 처리하는 오라클
-
일관성 검사(Consistent) 오라클 : 애플리케이션의 변경이 있을 때, 수행 전·후의 결과 값이 동일한지 확인하는 오라클
-
2. 애플리케이션 통합 테스트하기
통합 테스트
-
개요 : 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
-
통합 테스트 방법
방식 | 설명 |
비점진적 통합 방식 | 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법 |
방식 : 빅뱅 통합 테스트 방식 | |
점진적 통합 방식 | 모듈 단위로 단계적으로 통합하면서 테스트하는 방법 |
방식 : 하향식, 상향식, 혼합식 통합 방식 |
하향식 통합 테스트(Top Down Integration Test)
-
개요 : 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트 하는 기법
-
통합법
깊이 우선 통합법 | 넓이 우선 통합법 |
주요 제어 모듈을 중심으로 종속된 모든 모듈을 통합 | 구조의 수평을 중심으로 해당하는 모듈을 통합 |
※ 통합 순서 : A1→A2→A3→A4→A5→A6→A7→A8→A9 |
-
절차
-
주요 제어 모듈은 작성된 프로그램을 사용하고, 아직 작성되지 않은 하위 제어 모듈은 스텁(Stub)으로 대체
-
깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 하위 모듈인 스텁이 한 번에 하니씩 실제 모듈로 대체
-
모듈이 통합될 때마다 테스트를 실시
-
새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트를 실시
-
상향식 통합 테스트(Bottom Up Integration Test)
- 개요 : 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트 하는 기법
-
절차
-
하위 모듈들을 클러스터(Cluster)로 결합
-
상위 모듈에서 데이터의 입·출력을 확인하기 위해 더미 모듈인 드라이버(Driver)를 작성
-
통합된 클러스터 단위로 테스트
-
테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합, 드라이버는 실제 모듈로 대체
-
회귀 테스팅(Regresstion Testing)
-
개요 : 이미 테스트된 프로그램의 테스팅을 반복하는 것
-
테스트 케이스 선정
-
모든 애플리케이션의 기능을 수행할 수 있는 대표적인 테스트 케이스를 선정
-
변경에 의한 파급 효과가 높은 부분이 포함된 테스트 케이스를 선정
-
실제 수정이 발생한 모듈 또는 컴포넌트에서 시행하는 테스트 케이스를 선정
-
테스트 자동화 도구
-
개요 : 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용
-
장점
-
반복적인 작업을 자동화함으로써 인력 및 시간을 절약
-
사용자의 요구 기능에 대한 일관적인 검증
-
테스트 결과에 대한 객관적인 평가 기준 제공
-
테스트 결과를 그래프 등 다양한 표시 형태로 제공
-
UI가 없는 서비스도 정밀 테스트가 가능
-
-
단점
-
테스트 자동화 도구의 사용 방법에 대한 교육 및 학습이 필요
-
자동화 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력이 필요
-
상용 도구의 경우 고가의 추가 비용이 필요
-
-
도구 유형
유형 | 설명 |
정적 분석 도구 (Static Analysis Tools) |
프로그램을 실행하지 않고 분석하는 도구 |
테스트 실행 도구 (Test Execution Tools) |
스크립트 언어를 사용하여 테스트를 실행하는 방법 |
데이터 주도 접근 방식 : 스프레드시트에 테스트 데이터를 저장하고, , 이를 읽어 실행하는 방식 | |
키워드 주도 접근 방식 : 스프레드시트에 테스트를 키워드와 테스트 데이터를 지정하여 실행하는 방식 | |
성능 테스트 도구 (Performance Test Tools) |
가상의 사용자를 만들어 테스트를 수행, 성능의 목표 달성 여부를 확인하는 도구 |
테스트 통제 도구 (Test Control Tools) |
형상 관리 도구, 결함 추적/관리 도구 등 |
테스트 하네스 (Test Harness) |
애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경, 테스트를 지원하기 위해 생성된 코드와 데이터 |
결함 관리
-
개요 : 애플리케이션 테스트에서 발견된 결함을 처리하는 것
-
프로세스
-
결함 추이 분석 : 테스트 완료 후 발견된 결함을 분석하여 향후 어떤 모듈 또는 컴포넌트에서 결함이 발생할지 추정하는 작업
결함 관리 측정 지표 | 설명 |
결함 분포 | 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정 |
결함 추세 | 테스트 진행 시간에 따른 결함 수의 추이 분석 |
결함 에이징 | 특정 결함 상태로 지속되는 시간 측정 |
-
결함 식별
-
단계별 결함 유입 분류
-
기획 시 유입되는 결함 : 사용자 요구사항 표준 미준수로 인한 테스트 불가능 등
-
설계 시 유입되는 결함 : 설계 표준 미준수로 인한 테스트 불가능 등
-
코딩 시 유입되는 결함 : 코딩 표준 미준수로 인한 기능의 불일치/불완전 등
-
테스트 부족으로 유입되는 결함 : 테스트 수행 시 테스트 완료 기준의 미준수 등
-
-
결함 심각도별 분류 : 결함이 얼마나 치명적인지를 나타내는 척도
-
결함 우선순위 : 발견된 결함 처리에 대한 신속성을 나타내는 척도
-
3. 애플리케이션 성능 개선하기
애플리케이션 성능 분석
-
성능 측정 지표
지표 | 설명 |
처리량(Throughput) | 일정 시간 내에 애플리케이션이 처리하는 일의 양 |
응답 시간(Response Time) | 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간 |
경과 시간(Turnaround Time) | 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간 |
자원 사용률(Resource Usage) | 애플리케이션에 의뢰한 작업을 처리하는 동안의 CPU, 메모리, 네트워크 등의 자원 사용률 |
-
성능 분석 도구
도구 | 설명 |
성능 테스트 도구 | 애플리케이션에 부하나 스트레스를 가하여 성능 측정 지표를 점검하는 도구 |
종류 : JMeter, LoadUI, OpenSTA | |
시스템 모니터링 도구 | 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인, 분석하는 도구 |
종류 : Scouter, Zabbix |
애플리케이션 성능 저하 원인 분석
-
데이터베이스 락(DB Lock)
-
불필요한 데이터베이스 패치(DB Fetch)
-
연결 누수(Connection Leak)
-
부적절한 커넥션 풀 크기(Connection Pool Size)
-
불필요한 Commit이 자주 발생
-
웹 애플리케이션의 인터넷 접속 불량
-
대량의 파일 업로드/다운로드
-
정상적으로 처리되지 않은 오류
-
외부 호출이 장시간 수행되거나 타임아웃 발생
-
네트워크 장비 간 데이터 전송 실패 및 전송 지연
애플리케이션 성능 개선
-
개요 : 나쁜 코드(Bad Code)를 배제하고, 클린 코드(Clean Code)로 작성하는 것
-
나쁜 코드(Bad Code) : 로직(Logic)이 복잡하고 이해하기 어려운 코드
-
클린 코드(Clean Code) : 가독성이 높고, 단순하여 이해하기 쉬운 코드
-
소스 코드 품질 분석 도구
분류 | 설명 |
정적 분석 도구 | 소스 코드를 실행시키지 않고 코드 자체만으로 결함 여부를 확인하는 코드 분석 도구 |
종류 : pmd, cppcheck, SonarQube, Checkstyle, ccm, cobertura 등 | |
동적 분석 도구 | 애플리케이션을 실행하여 코드에 존재하는 결함 여부를 확인하는 코드 분석 도구 |
종류 : Avalanche, Valgrind 등 |
'2020 정보처리기사' 카테고리의 다른 글
[정보처리기사 실기] 소프트웨어 개발보안 구축 (0) | 2020.07.13 |
---|---|
[정보처리기사 실기] SQL 응용 (0) | 2020.07.11 |
[정보처리기사 실기] 화면 설계 (0) | 2020.07.07 |
[정보처리기사 실기] 인터페이스 구현 (0) | 2020.07.07 |
[정보처리기사 실기] 서버 프로그램 구현 (0) | 2020.07.02 |