2과목 - 소프트웨어 개발
4장. 애플리케이션 테스트 관리
49. 애플리케이션 테스트
애플리케이션 테스트의 개념
- 애플리케이션 테스트는 개발된 소프트웨어를 확인하고 검증하는 것
- 확인 (Validation) : 사용자 입장에서, 고객의 요구사항에 맞게 구현되었는지 확인
- 검증 (Verification) : 개발자 입장에서, 명세서에 맞게 잘 만들어졌는지 점검
- 소프트웨어의 분류
- 상용 소프트웨어 : 보통의 사용자들이 공통적으로 필요로 하는 기능 제공
- 산업 범용 소프트웨어 : 시스템 소프트웨어 / 미들웨어 / 응용 소프트웨어
- 산업 특화 소프트웨어 : 특정 분야에서 요구하는 기능만을 구현
- 서비스 제공 소프트웨어 : 판매하려는 것이 아닌 특정 사용자가 필요로 하는 기능만을 제공
- 신규 개발 소프트웨어
- 기능 개선 소프트웨어
- 추가 개발 소프트웨어
- 시스템 통합 소프트웨어
- 상용 소프트웨어 : 보통의 사용자들이 공통적으로 필요로 하는 기능 제공
애플리케이션 테스트의 필요성
- 테스트를 통해 실행 전에 오류 발견하여 예방 가능
- 프로그램이 사용자의 요구사항을 만족시키는지 반복적으로 테스트하므로 제품 신뢰도 향상
- 최소한의 시간과 노력으로 많은 결함을 찾을 수 있음
애플리케이션 테스트의 기본 원리
- 잠재적인 결함을 줄일 수는 있지만 결함이 없다고 증명할 수는 없음
- 애플리케이션의 결함은 대부분 특정 모듈에 집중되어 있음
- 파레토 법칙 : 애플리케이션의 20%에 해당하는 코드에서 전체 80% 결함이 발견
- 살충제 패러독스를 방지하기 위해 테스트 케이스를 지속적으로 보완 및 개선
- 살충제 패러독스 : 동일한 테스트 케이스로 동일한 테스트 반복 시 더 이상 결함이 발견되지 않음
- 오류-부재의 궤변 (Absence of Errors Fallacy)
- 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없음
- 테스트는 작은 부분에서 시작하여 점점 확대하며 진행
50. 애플리케이션 테스트의 분류
프로그램 실행 여부에 따른 테스트
- 정적 테스트
- 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트
- 개발 초기에 결함을 발견할 수 있어 개발 비용을 낮출 수 있음
- ex) 워크스루 / 인스펙션 / 코드 검사 등
- 동적 테스트
- 프로그램을 실행하여 오류를 찾는 테스트로 개발의 모든 단계에서 테스트 수행 가능
- ex 블랙박스 테스트 / 화이트박스 테스트
테스트 기반 (Test Bases)에 따른 테스트
- 명세 기반 테스트
- 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인
- 구조 기반 테스트
- 소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인
- 경험 기반 테스트
- 유사 소프트웨어나 기술 등에 대한 테스터 경험을 기반으로 수행
시각에 따른 테스트
- 검증 (Verification) 테스트
- 개발자 시각에서 제품이 명세서대로 완성됐는지 테스트
- 확인 (Validation) 테스트
- 사용자 시각에서 요구한대로 제품이 완성됐는지 테스트
목적에 따른 테스트
- 회복 (Recovery) 테스트
- 시스템에 여러가지 결함을 주어 올바르게 복구되는지 확인
- 안전 (Security) 테스트
- 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인
- 강도 (Stress) 테스트
- 과부하 시에도 소프트웨어가 정상적으로 실행되는지 확인
- 성능 (Performance) 테스트
- 소프트웨어의 실시간 성능이나 전체적인 효율성 진단
- 구조 (Structure) 테스트
- 소프트웨어 내부 논리적인 경로, 소스 코드의 복잡도 등을 평가
- 회귀 (Regression) 테스트
- 소프트웨어 변경 또는 수정된 코드에 새로운 결함이 없음을 확인
- 병행 (Parallel) 테스트
- 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교
51. 테스트 기법에 따른 애플리케이션 테스트
화이트박스 테스트 (White Box Test)
- 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스 설계
- 설계된 절차에 초점을 둔 구조적 테스트로 테스트 과정 초기에 적용
- 원시 코드의 모든 문장을 한 번 이상 실행함으로써 수행
화이트박스 테스트의 종류
- 기초 경로 검사
- 대표적인 화이트박스 테스트 기법
- 절차적 설계의 논리적 복잡성을 측정할 수 있는 테스트 기법
- 제어 구조 검사
- 조건 검사 (Condition Testing) : 모듈 내에 있는 논리적 조건을 테스트
- 루프 검사 (Loop Testing) : 프로그램의 반복 구조에 초점을 맞춰 실시
- 데이터 흐름 검사 (Data Flow Testing) : 프로그램에서 변수 사용 위치에 초점을 맞춰 실시
화이트박스 테스트의 검증 기준
- 테스트 케이스들이 테스트에 얼마나 적정한지 판단하는 기준
- 문장 검증 기준 (Statement Coverage) : 모든 구문이 한 번 이상 수행되도록 설계
- 분기 검증 기준 (Branch Coverage) : 모든 조건문이 한 번 이상 수행되도록 설계
- 조건 검증 기준 (Condition Coverage) : 모든 조건문에 대해 True인 경우와 False인 경우가 한 번 이상 수행되도록 설계
- 분기/조건 기준 (Branch/Condition Coverage) : 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 Trud/False 한 번 이상씩 수행되도록 설계
- 검증 기준 (Coverage) 종류
- 기능 기반 커버리지 : 실제 테스트가 수행된 기능 수 / 전체 기능 수
- 라인 커버리지 : 테스트 시나리오가 수행한 코드의 라인 수 / 전체 코드의 라인 수
- 코드 커버리지 : 소스 코드의 구조 코드 자체가 얼마나 테스트 되었는지 측정
블랙박스 테스트 (Black Box Test)
- 각 기능이 완전히 작동되는 것을 입증하는 테스트
- 요구사항 명세서를 보면서 테스트하는 것으로, 주로 구현된 기능을 테스트
- 부정확하거나 누락된 기능, 인터페이스 오류 등을 발견하기 위해 사용되며 테스트 과정의 후반부에 적용
블랙박스 테스트의 종류
- 동치 분할 검사 (Equivalence Partitioning Testing)
- 입력 자료에 초점을 맞춰 검사 (= 동등 분할 기법)
- 경계값 분석 (Boundary Value Analysis)
- 입력 조건의 중간값보다 경계값에서 오류 발생 확률이 높다는 점을 이용, 입력 조건의 경계값을 테스트 케이스로 선정
- 원인-효과 그래프 검사 (Cause-Effect Graphing Testing)
- 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석하여 효용성이 높은 테스트 케이스 선정
- 오류 예측 검사 (Error Guessing)
- 과거 경험이나 확인자의 감각으로 테스트
- 비교 검사 (Comparision Testing)
- 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트
52. 개발 단계에 따른 애플리케이션 테스ㅡ
개발 단계에 따른 애플리케이션 테스트
- 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류
- 소프트웨어의 개발 단계에서부터 테스트를 수행하므로 요구 분석의 오류나 인터페이스 오류도 발견 가능
- V-모델
- 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현
- 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현
단위 테스트 (Unit Test)
- 단위 테스트는 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것
- 사용자 요구사항을 기반으로 한 기능성 테스트를 최우선
- 분류
- 구조 기반 테스트 : 화이트박스 테스트 시행
- 명세 기반 테스트 : 블랙박스 테스트 시행
통합 테스트 (Integration Test)
- 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
- 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류 검사
시스템 테스트 (System Test)
- 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검
- 실제 사용 환경과 유사하게 만든 테스트 환경에서 테스트 수행
- 분류
- 기능적 요구사항 : 명세서 기반의 블랙박스 테스트 시행
- 비기능적 요구사항 : 구조적 요소에 대한 화이트박스 테스트 시행
인수 테스트 (Acceptance Test)
- 개발한 소프트웨어가 사용자 요구사항을 충족하는지에 중점을 두고 사용자가 직접 테스트
53. 통합 테스트
통합 테스트 (Integration Test)
- 비점진적 통합 방식
- 단계적으로 통합하는 절차 없이 모든 모듈이 결합되어 있는 프로그램 전체를 테스트
- 규모가 작은 소프트웨어에 유리
- 전체 프로그램을 대상으로 하기 때문에 오류 발견 및 수정이 어려움
- 점진적 통합 방식
- 모듈 단위로 단계적으로 통합하면서 테스트하기 때문에 오류 수정에 용이
- 하향식 / 상향식 / 혼합식 통합 방식
하향식 통합 테스트 (Top Down Integration Test)
- 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
- 깊이 우선 통합법이나 넓이 우선 통합법 사용
- 테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있음
- Stub : 일시적으로 필요한 조건만을 갖고 있는 시험용 모듈
상향식 통합 테스트 (Bottom Up Integration Test)
- 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
- Driver : 이미 존재하는 하위 묘듈과 존재하지 않는 상위 모듈 간의 인터페이스 역할
혼합식 통합 테스트
- 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합 사용
회귀 테스팅 (Regression Testing)
- 이미 테스트된 프로그램의 테스팅을 반복하는 것
- 통합 테스트로 인해 변경된 모듈에 새로운 오류가 있는지 확인
54. 애플리케이션 테스트 프로세스
애플리케이션 테스트 프로세스
- 개발된 소프트웨어가 사용자 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차
- 테스트 계획
- 테스트 목표를 정의하고 테스트 대상 및 범위 결정
- 테스트 시작 및 조료 조건을 정의하고 테스트 계획서 작성
- 테스트 분석 및 디자인
- 사용자 요구사항 분석
- 테스트에 대한 리스크 분석 및 우선순위 결정
- 테스트 케이스 및 시나리오 작성
- 테스트용 스크립트 작성
- 테스트 수행
- 테스트 환경 구축 후 테스트 수행
- 테스트 결과 평가 및 리포팅
- 테스트 결과를 비교 분석하여 결함을 중점적으로 테스트 결과서 기록
- 결함 추적 및 관리
- 에러/오류 : 결함이 원인이 되는 것으로 사람에 의해 발생할 수 있는 실수
- 결함/결점/버그 : 에러/오류로 인해 제품에 발생한 결함으로 제거하지 않으면 제품에 문제 발생
55. 테스트 케이스 / 테스트 시나리오 / 테스트 오라클
테스트 케이스 (Test Case)
- 가장 이상적인 테스트 케이스를 설계하려면 시스템 설계 시 작성
- 테스트 오류를 방지할 수 있고 테스트 수행에 필요한 인력 및 시간 낭비를 줄일 수 있음
테이스 케이스 작성 순서
- 테스트 계획 검토 및 자료 확보
- 위험 평가 및 우선순위 결정
- 테스트 요구사항 정의
- 테스트 구조 설계 및 테스트 방법 결정
- 테스트 케이스 정의
- 테스트 케이스 타당성 확인 및 유지 보수
테스트 시나리오
- 테스트 케이스를 적용하는 순서에 따라 여러 테스트 케이스를 묶은 집합
- 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서
테스트 오라클
- 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법
- 특징
- 제한된 검증 : 모든 테스트 케이스에 적용할 수는 없음
- 수학적 기법 : 테스트 오라클의 값을 수학적 기법을 이용하여 구할 수 있음
- 자동화 기능
테스트 오라클의 종류
- 참 (True) 오라클
- 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공
- 발생된 모든 오류 검출 가능
- 주로 항공기, 은행 등 미션 크리티컬한 업무에 사용
- 샘플링 (Sampling) 오라클
- 특정한 몇몇 케이스의 입력 값들에 대해서만 기대하는 결과를 제공
- 일반적인 업무, 게임 등에 사용
- 추정 (Heuristic) 오라클
- 샘플링 오라클을 개선하여 나머지 입력 값들에 대해서는 추정으로 처리
- 일반적인 업무, 게임 등에 사용
- 일관성 검사 (Consistent) 오라클
- 애플리케이션 변경 시 테스트 케이스 수행 전과 후의 결과 값이 동일한지 확인
56. 테스트 자동화 도구
테스트 자동화의 개념
- 테스트 자동화 도구를 사용함으로써 휴먼 에러를 줄이고 테스트 정확성을 유지하며, 테스트 품질 향상 가능
테스트 자동화 도구의 장단점
- 장점
- 반복적인 작업을 자동화함으로써 인력 및 시간 절약
- 사용자 요구사항을 일관성 있게 검증
- 테스트 결과에 대한 객관적인 평가 기준 제공
- 단점
- 사용 방법에 대한 교육 및 학습 필요
- 자동화 도구를 단계별로 적용하기 위한 시간과 비용 필요
테스트 자동화 수행 시 고려사항
- 재사용 및 측정이 불가능한 테스트 프로그램은 제외
- 반드시 프로젝트 초기에 테스트 엔지니어의 투입 시기 계획
테스트 자동화 도구의 유형
- 정적 분석 도구 (Static Analysis Tools)
- 프로그램을 실행하지 않고 분석하는 도구
- 테스트를 수행하는 사람이 작성된 코드를 이해하고 있어야 분석 가능
- 테스트 실행 도구 (Test Execution Tools)
- 스크립트 언어를 사용하여 테스트 실행
- 데이터 주도 접근 방식
- 다양한 테스트 데이터를 동일한 테스트 케이스로 반복하여 실행 가능
- 키워드 주도 접근 방식
- 키워드 (테스트를 수행할 동작)을 이용하여 테스트 정의 가능
- 성능 테스트 도구 (Performance Test Tools)
- 애플리케이션 처리량, 응답 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트 수행
- 테스트 통제 도구 (Test Control Tools)
- 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구
- ex) 형상 관리 도구, 결참 주적/관리 도구
- 테스트 하네스 도구 (Test Harness Tools)
- 테스트가 실행될 환경을 시뮬레이션하여 모듈이 정상적으로 테스트되게 함
57. 결함 관리
결함 (Fault)의 정의
- 소프트웨어 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 경우
결함 관리 프로세스
- 결함 관리 계획 : 전체 프로세스에 대한 결함 관리 일정, 인력 등을 확보하여 계획 수립
- 결함 기록 : 발견된 결함을 결함 관리 DB에 기록
- 결함 검토 : 등록된 결함을 검토하고 수정할 개발자에게 전달
- 결함 수정 : 전달받은 결함 수정
- 결함 재확인 : 개발자가 수정한 내용을 확인하고 다시 테스트 부여
- 결함 상태 추적 및 모니터링 활동
- 최종 결함 분석 및 보고서 작성
결함 상태 추적
- 테스트에서 발견된 결함은 지속적으로 상태 변화를 추적하고 관리해야함
결함 추적 순서
- 결함 등록 (Open) : 테스터와 QA 담당자에 의해 발견된 결함이 등록된 상태
- 결함 검토 (Reviewed) : 등록된 결함이 검토된 상태
- 결함 할당 (Assigned) : 결함을 수정하기 위해 개발자와 문제 해결 담당자에게 결함이 할당된 상태
- 결함 수정 (Resolved) : 개발자가 결함 수정 완료한 상태
- 결함 조치 보류 (Deferred) : 결함의 수정이 불가능해 연기된 상태
- 결함 종료 (Closed) : 결함이 해결되어 종료를 승인한 상태
- 결함 해제 (Clarified) : 종료 승인한 결함을 검토하여 결함이 아니라고 판명한 상태
결함 분류
- 시스템 결함 : 주로 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함
- 기능 결함 : 애플리케이션 기획, 설계 단계에서 유입된 결함
- GUI 결함 : 사용자 화면 설계에서 발생된 결함
- 문서 결함 : 의사소통 및 기록이 원할하지 않아 발생된 결함
결함 심각도
- 결함이 전체 시스템에 미치는 치명도를 나타내는 척도
- High : 더 이상 프로세스를 진행할 수 업도록 만드는 결함
- Medium : 시스템 흐름에 영향을 미치는 결함
- Low : 시스템 흐름에는 영향을 미치지 않는 결함
결함 우선순위
- 발견된 결함 처리에 대한 신속성을 나타내는 척도
- 결함의 심각도가 높으면 우선순위도 높지만 반드시 그런 것은 아님
58. 애플리케이션 성능 분석
애플리케이션 성능
- 애플리케이션 성능이란 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도
- 성능 측정 지표
- 처리량 (Throughput) : 일정 시간 내 애플리케이션이 처리하는 일의 양
- 응답 시간 (Response Time) : 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
- 경과 시간 (Turn Aroung Time) : 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간
- 자원 사용률 (Resource Usage) : 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량 등
시스템 모니터링 (Monitoring) 도구
- 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
- 성능 저하의 원인 분석, 시스템 부하량 분석 등 시스템을 안정적으로 운영할 수 있는 기능 제공
59. 애플리케이션 성능 개선
소스 코드 최적화
- 나쁜 코드를 배제하고 클린 코드로 작성하는 것
- 클린 코드 (Clean Code) : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료하게 잘 작성된 코드
- 나쁜 코드 (Bad Code) : 로직이 얽혀 있는 스파게티 코드나 복잡하고 이해하기 어려운 코드
- 클린 코드 작성 원칙
- 가독성 : 누구든지 코드를 쉽게 읽을 수 있도록 작성
- 단순성 : 한 번에 한 가지를 처리하도록 코드 작성
- 의존성 배제 : 코드 변경 시 다른 부분에 영향이 없도록 작성
- 중복성 최소화 : 중복된 코드는 삭제하고 공통된 코드 사용
- 추상화
소스 코드 최적화 유형
- 클래스 분할 배치
- 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고 크기를 작게 작성
- 느슨한 결합 (Loosely Coupled)
- 인터페이스 클래스를 이용하여 추상화된 자료 구조와 메소드 구현
- 클래스 간 의존성 최소화
- 코딩 형식 준수
- 좋은 이름 사용
- Naming Rule
- 적절한 주석문 사용
소스 코드 품질 분석 도구
- 정적 분석 도구
- 작성한 코드를 실행하지 않고 코딩 스타일이나 결함 등을 확인
- 개발 초기의 결함을 찾는데 사용되고, 개발 완료 시점에서는 코드의 품질을 검증하는 차원에서 사용
- 동적 분석 도구
- 작성한 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석
