애플리케이션 테스트
- 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
애플리케이션 테스트의 기본 원리
완벽한 테스트 불가능
- 소프트웨어의 잠재적인 결함을 줄일 수 있지만 소프트웨어에 결함이 없다고 증명할 수는 없음
파레토 법칙(Pareto Principle)
- 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙
살충제 패러독스(Pesticide Paradox)
- 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상
테스팅은 정황(Context) 의존
- 정황(Context)에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 함
오류-부재의 궤변(Absence of Errors Fallacy)
- 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없는 것
테스트와 위험은 반비례
- 테스트를 많이 하면 할수록 미래에 발생할 위험을 줄일 수 있음
테스트의 점진적 확대
- 테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야 함
테스트의 별도 팀 수행
- 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함
애플리케이션 테스트의 분류
프로그램 실행 여부에 따른 테스트
정적 테스트
- 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트
- 종류: 워크스루, 인스펙션, 코드 검사 등
동적 테스트
- 프로그램을 실행하여 오류를 찾는 테스트
- 종류: 블랙박스 테스트, 화이트박스 테스트
테스트 기반(Test Bases)에 따른 테스트
명세 기반 테스트
- 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트
- 종류: 동등 분할, 경계 값 분석 등
구조 기반 테스트
- 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
- 종류: 구문 기반, 결정 기반, 조건 기반 등
경험 기반 테스트
- 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트
- 종류: 에러 추정, 체크 리스트, 탐색적 테스팅
시각에 따른 테스트
검증(Verification) 테스트
- 개발자의 시각에서 제품의 생산 과정을 테스트 하는 것
확인(Validation) 테스트
- 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것
목적에 따른 테스트
- 회복(Recovery) 테스트
- 안전(Security) 테스트
- 강도(Stress) 테스트
- 성능(Performance) 테스트
- 구조(Structure) 테스트
- 회귀(Regression) 테스트
- 병행(Parallel) 테스트
화이트박스 테스트(White Box Test)
- 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
화이트박스 테스트의 종류
기초 경로 검사(Base Path Testing)
- 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
제어 구조 검사(Control Structure Testing)
조건 검사(Condition Testing)
- 프로그램 모듈 내에 있는 논리적 조건을 테스트
루프 검사(Loop Testng)
데이터 흐름 검사(Data Flow Testing)
- 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시
화이트박스 테스트의 검증 기준
문장 검증 기준(Statement Coverage)
- 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계
분기 검증 기준(Branch Coverage)
- 모든 조건문에 대해 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계
조건 검증 기준(Condition Coverage)
- 개별 조건식의 결과가 Ture인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계
분기/조건 기준(Branch/Condition Coverage)
- 분기 검증 기준과 조건 검증 기준을 모두 만족하는 설계
블랙박스 테스트(Black Box Test)
- 각 기능이 완전히 작동되는 것을 입증하는 테스트
블랙박스 테스트의 종류
동치 분할 검사(Equivalence Partitioning Testing, 동치 클래스 분해)
- 타당한 입력 자료와 타당하지 않는 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인
경계값 분석(Boundary Value Analysis)
- 입력 조건의 경계값을 테스트 케이스로 선정하여 검사
원인-효과 그래프 검사(Cause-Effect Graphing Testing)
- 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사
오류 예측 검사(Error Guessing)
비교 검사(Comparison Testing)
- 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트
개발 단계에 따른 애플리케이션 테스트
-
애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것을 V-모델이라고 한다.
-
소프트웨어 개발 단계: 요구사항 -> 분석 -> 설계 -> 구현 -> (테스트 단계)
-
테스트 단계: (소프트웨어 개발 단계) -> 단위 테스트 -> 통합 테스트 -> 시스템 테스트 -> 인수 테스트
단위 테스트(Unit Test)
통합 테스트(Integration Test)
- 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
시스템 테스트(System Test)
- 개발된 소프트웨어가 완벽하게 수행되는가를 점검하는 테스트
인수 테스트(Acceptance Test)
- 사용자의 요구사항을 충족하는지에 중점을 두고 테스트
인수 테스트의 종류
사용자 인수 테스트
운영상의 인수테스트
- 시스템 관리자가 시스템 인수 시 수행하는 테스트 기법
계약 인수 테스트
규정 인수 테스트
- 정부 지침, 법규 등 규정에 맞게 개발되었는지 확인
알파 테스트
- 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법
베타 테스트
- 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법
통합 테스트
- 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트
통합 테스트의 종류
비점진적 통합 방식
- 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법
- 종류: 빅뱅 통합 테스트 방식
점진적 통합 방식
- 모듈 단위로 단계적으로 통합하면서 테스트
- 종류: 하향식 통합 테스트, 상향식 통합 테스트, 혼합식 통합 테스트
하향식 통합 테스트(Top Down Integration Test)
- 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트
- 깊이 우선 통합법이나 넓이 우선 통합법을 사용
하향식 통합 테스트 절차
- 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁(Stub)으로 대체
- 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체
- 모듈이 통합될 때마다 테스트를 실시
- 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트를 실시
스텁(Stub)
- 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
상향식 통합 테스트(Bottom Up Integration Test)
- 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
상향식 통합 테스트 절차
- 하위 모듈들을 클러스터(Cluster)로 결합
- 상위 모듈에서 데이터의 입-출력을 확인하기 위해 더미 모듈인 드라이버(Driver)를 작성
- 통합된 클러스터 단위로 테스트
- 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고 드라이버는 실제 모듈로 대체
혼합식 통합 테스트
- 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식
- 샌드위치식 통합 테스트 방법이라고도 함
회귀 테스팅(Regression Testing)
- 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트
애플리케이션 테스트 프로세스
- 개발된 소프트웨어가 사용자의 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차
애플리케이션 테스트 프로세스 순서
- 테스트 계획
- 테스트 분석 및 디자인
- 테스트 케이스 및 시나리오 작성
- 테스트 수행
- 테스트 결과 평가 및 리포팅
- 결함 추적 및 관리
결함 관리 프로세스
- 에러 발견
- 에러 등록
- 에러 분석
- 결함 확정
- 결함 할당
- 결함 조치 검토 및 승인
테스트 케이스
- 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 테스트 항목에 대한 명세서
테스트 시나리오(Test Scenario)
- 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스를 묶은 집합
테스트 오라클(Test Oracle)
- 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법
테스트 오라클의 특징
제한된 검증
- 테스트 오라클을 모든 테스트 케이스에 적용할 수 없음
수학적 기법
- 테스트 오라클의 값을 수학적 기법을 이용하여 구할 수 있음
자동화 기능
- 테스트 대상 프로그램의 실행, 결과 비교, 커버리지 측정 등을 자동화 할 수 있음
테스트 오라클의 종류
참(True) 오라클
- 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공
샘플링(Sampling) 오라클
- 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공
추정(Heuristic) 오라클
- 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리
일관성 검사(Consistent) 오라클
- 애플리케이션에 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과값이 동일한지를 확인
테스트 자동화
- 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함으로써 쉽고 효율적으로 테스트를 수행
테스트 유형에 따른 테스트 자동화 도구의 종류
- 정적 분석 도구
- 테스트 실행 도구
- 성능 테스트 도구
- 테스트 통제 도구
-
스크립트 언어를 사용하여 테스트를 실행하는 도구
-
데이터 주도 접근 방식: 스프레드시트에 테스트 데이터를 저장하고, 이를 읽어 실행
-
키워드 주도 접근 방식: 스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 저장하여 실행
- 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인하는 도구
- 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구
- 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구
테스트 하네스(Test Harness)
- 테스트를 지원하기 위해 생성된 코드와 데이터를 의미
테스트 하네스의 구성 요소
테스트 드라이버(Test Driver)
- 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
테스트 스텁(Test Stub)
- 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구
테스트 슈트(Test Suites)
- 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
테스트 케이스(Test Case)
- 사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서
테스트 스크립트(Test Script)
목 오브젝트(Mock Object)
- 사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체
테스트 수행 단계별 테스트 자동화
테스트 계획
테스트 분석/설계
테스트 수행
- 테스트 자동화
- 정적 분석
- 동적 분석
- 성능 테스트
- 모니터링
테스트 관리
결함 관리
결함(Fault)
- 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것
결함 관리 프로세스
- 결함 관리 계획
- 결함 기록
- 결함 검토
- 결함 수정
- 결함 재확인
- 결함 상태 추적 및 모니터링 활동
- 최종 결함 분석 및 보고서 작성
결함 상태 추적
결함 관리 측정 지표
결함 추적 순서
- 결함 등록(Open)
- 결함 검토(Reviewed)
- 결함 할당(Assigned)
- 결함 수정(Resolved)
- 결함 조치 보류(Deferred)
- 결함 종료(Closed)
- 결함 해제(Clarified)
결함 분류
- 시스템 결함
- 기능 결함
- GUI 결함
- 문서 결함
결함 심각도
- 애플리케이션에 발생한 결함이 전체 시스템에 미치는 치명도를 나타내는 척도
결함 우선순위
결함 관리 도구
- Mantis
- Trac
- Redmine
- Bugzilla
애플리케이션 성능
- 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도
애플리케이션 성능 측정 지표
처리량(Throughput)
- 일정 시간 내에 애플리케이션이 처리하는 일의 양
응답 시간(Response Time)
- 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
경과 시간(Turn Around Time)
- 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간
자원 사용률(Resource Usage)
- 애플리케이션이 의뢰한 작업을 처리하는 동안의 자원 사용률
성능 테스트 도구
- 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검하는 도구
종류
시스템 모니터링(Monitoring) 도구
- 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
종류
복잡도(Complexity)
- 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도
시간 복잡도
- 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것
점근 표기법의 종류
빅오 표기법
세타 표기법
오메가 표기법
빅오 표기법으로 표현한 최악의 알고리즘 시간 복잡도
O(1)
O(logn)
O(n)
O(nlogn)
O(n^2)
- 삽입 정렬, 쉘 정렬, 선택 정렬, 버블 정렬, 퀵 정렬
O(2^n)
순환 복잡도(Cyclomatic Complexity)
- 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도
계산 방법
방법1. 순환 복잡도는 제어 흐름도의 영역 수와 일치하므로 영역 수를 계산한다.
방법2. V(G) = E - N + 2 (E는 화살표 수, N은 노드의 수)
애플리케이션 성능 개선
소스 코드 최적화
- 나쁜 코드(Bad Code)를 배제하고 클린 코드(Clean Code)로 작성하는 것
클린 코드
- 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드, 즉 잘 작성된 코드
나쁜 코드
- 프로그램의 로직(Logic)이 복잡하고 이해하기 어려운 코드
스파게티 코드
외계인 코드
- 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
클린 코드 작성 원칙
- 가독성
- 단순성
- 의존성 배제
- 중복성 최소화
- 추상화
소스 코드 최적화 유형
클래스 분할 배치
- 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고, 크기를 작게 작성함
느슨한 결합(Loosely Coupled)
- 인터페이스 클래스를 이용하여 추상화된 자료 구조와 메소드를 구현함으로써 클래스 간의 의존성을 최소화
소스 코드 품질 분석 도구
정적 분석 도구
- 작성한 소스 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인하는 코드 분석 도구
- 종류: pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura
동적 분석 도구
- 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
- 종류: Avalanche, Valgrind