728x90
728x170
07. 애플리케이션 테스트 관리
(1) 애플리케이션 테스트
애플리케이션 테스트
- 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
- 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인(Validation)하고, 소프트웨어가 기능을 정확히 수행하는지 검증(Verification)한다.
애플리케이션 테스트의 기본 원리
기본 원리 | 설명 |
완벽한 테스트 불가능 | 소프트웨어의 잠재적인 결함은 줄일 수 있지만, 소프트웨어에 결함이 없다고 증명할 수는 없음. |
파레토 법칙 (Pareto Principle) |
애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙 |
살충제 패러독스 (Pesticide Paradox) |
동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상 |
테스팅은 정황(Context) 의존 | 소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황(Context)에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 함. |
오류-부재의 궤변 (Absence of Errors Fallacy) |
소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없는 것 |
테스트와 위험은 반비례 | 테스트를 많이 하면 할수록 미래에 발생할 위험을 줄일 수 있음. |
테스트의 점진적 확대 | 테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야 함. |
테스트의 별도 팀 수행 | 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함. |
(2) 애플리케이션 테스트의 분류
프로그램 실행 여부에 따른 테스트
정적 테스트 | - 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트 - 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위해 사용함. - 종류 : 워크스루, 인스펙션, 코드 검사 등 |
동적 테스트 | - 프로그램을 실행하여 오류를 찾는 테스트 - 소프트웨어 개발의 모든 단계에서 테스트를 수행함. - 종류 : 블랙박스 테스트, 화이트박스 테스트 |
*워크스루(Walkthrough, 검토 회의)
- 소프트웨어 개발자가 모집한 전문가들이 개발자의 작업 내역을 검토하는 것
- 소프트웨어 검토를 위해 미리 준비된 자료를 바탕으로 정해진 절차에 따라 평가한다.
- 오류의 조기 검출을 목적으로 하며, 발견된 오류는 문서화한다.
*인스펙션(Inspection)
- 워크스루를 발전시킨 형태
- 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하고, 이를 개선하기 위한 방법을 제시한다.
테스트 기반(Test Bases)에 따른 테스트
명세 기반 테스트 | - 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트 - 종류 : 동등 분할, 경계 값 분석 등 |
구조 기반 테스트 | - 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 - 종류 : 구문 기반, 결정 기반, 조건 기반 등 |
경험 기반 테스트 | - 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트 - 사용자의 요구사항에 대한 명세가 불충분하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적임. - 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅 |
시각에 따른 테스트
검증(Verification) 테스트 | - 개발자의 시각에서 제품의 생산 과정을 테스트하는 것 - 제품이 명세서대로 완성됐는지를 테스트함. |
확인(Validation) 테스트 | - 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것 - 사용자가 요구한대로 제품이 완성됐는지, 제품이 정상적으로 동작하는지를 테스트함. |
목적에 따른 테스트
회복(Recovery) 테스트 | 시스템에 여러 가지 결함을 주어 실패하도록 한 후, 올바르게 복구되는지를 확인하는 테스트 |
안전(Security) 테스트 | 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트 |
강도(Stress) 테스트 | 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트 |
성능(Performance) 테스트 | 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트로, 소프트웨어의 응답 시간, 처리량 등을 테스트 |
구조(Structure) 테스트 | 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트 |
회귀(Regression) 테스트 | 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트 |
병행(Parallel) 테스트 | 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트 |
(3) 테스트 기법에 따른 애플리케이션 테스트
화이트박스 테스트(White Box Test)
- 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
- 모듈 안의 작동을 직접 관찰한다.
- 원시 코드(모듈)의 모든 문장을 한 번 이상 실행함으로써 수행된다.
화이트박스 테스트의 종류
기초 경로 검사 (Base Path Testing) |
- 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법 - 대표적인 화이트박스 테스트 기법 |
제어 구조 검사 (Control Structure Testing) |
- 조건 검사(Condition Testing) : 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법 - 루프 검사(Loop Testing) : 프로그램의 반복(Loop) 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법 - 데이터 흐름 검사(Data Flow Testing) : 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법 |
화이트박스 테스트의 검증 기준(=커버리지)
문장 검증 기준 (Statement Coverage) |
소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계함. |
분기 검증 기준 (Branch Coverage) |
소스 코드의 모든 조건문이 한 번 이상 수행되도록 테스트 케이스를 설계함. |
조건 검증 기준 (Condition Coverage) |
소스 코드의 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계함. |
분기/조건 검증 기준 (Branch/Condition Coverage) |
소스 코드의 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계함. |
구문 커버리지 = 문장 커버리지 (Statement Coverage) |
- 프로그램 내의 모든 명령문을 적어도 한 번 수행함. - 조건문 결과와 관계없이 구문 실행 개수로 계산 |
결정 커버리지 = 선택 커버리지(Decision Coverage) = 분기 커버리지(Branch Coverage) | - (각 분기의) 결정 포인트 내의 전체 조건식이 적어도 한 번은 참(T)과 거짓(F)의 결과를 수행함. - 구문 커버리지를 포함. |
조건 커버리지 (Condition Coverage) |
- (각 분기의) 결정 포인트 내의 각 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행함. - 구문 커버리지를 포함. |
조건/결정 커버리지 (Condition/Decision Coverage) |
전체 조건식뿐만 아니라 개별 조건식도 참 한 번, 거짓 한 번 결과가 되도록 수행하는 테스트 커버리지 |
변경 조건/결정 커버리지 (Modified Condition/ Decision Coverage) |
개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 커버리지 |
다중 조건 커버리지 (Multiple Condition Coverage) |
결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장하는 커버리지 |
블랙박스 테스트(Back Box Test)
- 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트로, 기능 테스트라고도 한다.
- 사용자의 요구사항 명세를 보면서 테스트한다.
- 주로 구현된 기능을 테스트한다.
- 소프트웨어 인터페이스를 통해 실시된다.
블랙박스 테스트의 종류
동치 분할 검사 (Equivalence Partitioning Testing, 동치 클래스 분해) |
- 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 기법 - 동등 분할 기법이라고도 함. |
경계값 분석 (Boundary Value Analysis) |
입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법 |
원인-효과 그래프 검사 (Cause-Effect Graphing Testing) |
입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음, 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법 |
오류 예측 검사 (Error Guessing) |
과거의 경험이나 확인자의 감각으로 테스트하는 기법 |
비교 검사 (Comparison Testing) |
여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법 |
예제 : A 애플리케이션에서 평가점수에 따른 성적 부여 기준이 다음과 같을 때, 동치 분할 검사와 경계값 분석의 테스트 케이스를 확인하시오.
<동치 분할 검사>
- 동치 분할 검사는 입력 자료에 초점을 맞춰 테스트 케이스를 만들어 검사하므로 평가점수를 입력한 후 점수에 맞는 성적이 출력되는지 확인한다.
<경계값 분석>
- 경계값 분석은 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하므로, 평가점수의 경계값에 해당하는 점수를 입력한 후 올바른 성적이 출력되는지 확인한다.
(4) 개발 단계에 따른 애플리케이션 테스트
개발 단계에 따른 애플리케이션 테스트
- 소프트웨어 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 로 분류된다.
- 이렇게 분류된 것을 테스트 레벨이라고 한다.
- 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것을 V-모델이라고 한다.
단위 테스트(Unit Test)
- 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것
- 인터페이스, 외부적 I/O, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등을 검사한다.
- 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 수행한다.
- 구조 기반 테스트와 명세 기반 테스트로 나뉘지만, 주로 구조 기반 테스트를 시행한다.
통합 테스트(Integration Test)
- 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
- 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류를 검사한다.
시스템 테스트(System Test)
- 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
- 기능적 요구사항과 비기능적 요구사항으로 구분하여 각각을 만족하는지 테스트한다.
인수 테스트(Acceptance Test)
- 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법
- 개발한 소프트웨어를 사용자가 직접 테스트한다.
- 인수 테스트는 다음과 같이 6가지의 종류로 구분해서 테스트한다.
테스트 종류 | 설명 |
사용자 인수 테스트 | 사용자가 시스템 사용의 적절성 여부를 확인함. |
운영상의 인수 테스트 | - 시스템 관리자가 시스템 인수 시 수행하는 테스트 기법 - 백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검 등을 확인함. |
계약 인수 테스트 | 계약상의 인수/검수 조건을 준수하는지 여부를 확인함. |
규정 인수 테스트 | 소프트웨어가 정부 지침, 법규, 규정 등 규정에 맞게 개발되었는지 확인함. |
알파 테스트 | - 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법 - 테스트는 통제된 환경에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 기록함. |
베타 테스트 | - 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법 - 실업무를 가지고 사용자가 직접 테스트 |
(5) 통합 테스트
통합 테스트(Integration Test)
- 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
- 종류
비점진적 통합 방식 | - 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법 - 종류 : 빅뱅 통합 테스트 방식 |
점진적 통합 방식 | - 모듈 단위로 단계적으로 통합하면서 테스트하는 방법 - 종류 : 하향식 통합 테스트, 상향식 통합 테스트, 혼합식 통합 테스트 |
*빅뱅 통합 테스트
- 모듈 간의 상호 인터페이스를 고려하지 않고, 단위 테스트가 끝난 모듈을 한꺼번에 결합시켜 테스트하는 방법
- 주로 소규모 프로그램이나 프로그램의 일부만을 대상으로 테스트 할 때 사용됨.
하향식 통합 테스트(Top Down Integration Test)
- 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
- 깊이 우선 통합법이나 넓이 우선 통합법을 사용한다.
- 깊이 우선 통합법 : 주요 제어 모듈을 중심으로 해당 모듈에 종속된 모든 모듈을 통합하는 것
- 넓이 우선 통합법 : 구조의 수평을 중심으로 해당하는 모듈을 통합하는 것
- 하향식 통합 테스트 절차
- 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁(Stub)으로 대체한다.
- 스텁(Stub) : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
- 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체된다.
- 모듈이 통합될 때마다 테스트를 실시한다.
- 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트를 실시한다.
- 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁(Stub)으로 대체한다.
상향식 통합 테스트(Bottom Up Integration Test)
- 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법
- 상향식 통합 테스트 절차
- 하위 모듈들을 클러스터(Cluster)로 결합한다.
- 상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버(Driver)를 작성한다.
- 테스트 드라이버(Test Driver) : 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
- 통합된 클러스터 단위로 테스트한다.
- 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고, 드라이버는 실제 모듈로 대체된다.
혼합식 통합 테스트
- 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식
- 샌드위치(Sandwich)식 통합 테스트 방법이라고도 한다.
회귀 테스트(Regression Testing)
- 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트
- 이미 테스트된 프로그램의 테스팅을 반복하는 것
- 회귀 테스트는 수정한 모듈이나 컴포넌트가 다른 부분에 영향을 미치는지, 오류가 생기지 않았는지 테스트하여 새로운 오류가 발생하지 않음을 보증하기 위해 반복 테스트한다.
(6) 애플리케이션 테스트 프로세스
애플리케이션 테스트 프로세스
- 개발된 소프트웨어가 사용자의 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차
테스트 계획 | 프로젝트 계획서, 요구 명세서 등을 기반으로 테스트 목표를 정의하고 테스트 대상 및 범위를 결정함. |
↓ | |
테스트 분석 및 디자인 | 테스트의 목적과 원칙을 검토하고 사용자의 요구 사항을 분석함. |
↓ | |
테스트 케이스 및 시나리오 작성 |
테스트 케이스를 작성하고, 검토하고 확인한 다음 테스트 시나리오를 작성함. |
↓ | |
테스트 수행 | 테스트 환경을 구축한 후, 테스트를 수행함. |
↓ | |
테스트 결과 평가 및 리포팅 |
테스트 결과를 비교 분석하여 테스트 결과서를 작성함. |
↓ | |
결함 추적 및 관리 | 테스트한 후, 결함 발생 위치나 종류 등 결함을 추적하고 관리함. |
결함 관리 프로세스
에러 발견 | 에러가 발견되면 테스트 전문가와 프로젝트팀이 논의함. |
↓ | |
에러 등록 | 발견된 에러를 결함 관리 대장에 등록함. |
↓ | |
에러 분석 | 등록된 에러가 실제 결함인지 아닌지를 분석함. |
↓ | |
결함 확정 | 등록된 에러가 실제 결함이면 결함 확정 상태로 설정함. |
↓ | |
결함 할당 | 결함을 해결할 담당자에게 결함을 할당하고, 결함 할당 상태로 설정함. |
↓ | |
결함 조치 | 결함을 수정하고, 수정이 완료되면 결함 조치 상태로 설정함. |
↓ | |
결함 조치 검토 및 승인 | 수정이 완료된 결함에 대해 확인 테스트를 수행하고, 이상이 없으면 결함 조치 완료 상태로 설정함. |
(7) 테스트 케이스 / 테스트 시나리오 / 테스트 오라클
테스트 케이스(Test Case)
- 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수 했는지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서
- 테스트 케이스를 미리 설계하면 테스트 오류 방지, 테스트 수행에 필요한 인력, 시간 등의 자원 낭비를 줄일 수 있다.
테스트 시나리오(Test Scenario)
- 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스를 묶은 집합
- 테스트 케이스를 적용하는 구체적인 절차를 명세한다.
- 테스트 순서에 대한 구체적인 절차, 사전 조건, 입력 데이터 등이 설정되어 있다.
테스트 오라클(Test Oracle)
- 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참값을 대입하여 비교하는 기법 및 활동
- 결과를 판단하기 위해 테스트 케이스에 대한 예상 결과를 계산하거나 확인한다.
- 테스트 오라클의 특징
제한된 검증 | 테스트 오라클을 모든 테스트 케이스에 적용할 수 있음. |
수학적 기법 | 테스트 오라클의 값을 수학적 기법을 이용하여 구할 수 있음. |
자동화 기능 | 테스트 대상 프로그램의 실행, 결과 비교, 커버리지 측정 등을 자동화 할 수 있음. |
테스트 오라클의 종류
참(True) 오라클 | - 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클 - 발생된 모든 오류를 검출할 수 있음. |
샘플링(Sampling) 오라클 | 특정한 몇몇 테스트 케이스의 입려 값들에 대해서만 기대하는 결과를 제공하는 오라클로, 전수 테스트가 불가능한 경우 사용 |
추정(Heuristic) 오라클 | 특정 테스트 케이스 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클 |
일관성 검사(Consistent) 오라클 | 애플리케이션에 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클 |
(8) 테스트 자동화 도구
테스트 자동화
- 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함으로써 쉽고 효율적으로 테스트를 수행할 수 있도록 한 것
- 테스트 유형에 따른 테스트 자동화 도구의 종류
- 정적 분석 도구
- 테스트 실행 도구
- 성능 테스트 도구
- 테스트 통제 도구
정적 분석 도구(Static Analysis Tools)
- 프로그램을 실행하지 않고 분석하는 도구
- 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함 등을 발견하기 위해 사용된다.
테스트 실행 도구(Test Execution Tools)
- 스크립트 언어를 사용하여 테스트를 실행하는 도구
- 테스트 데이터와 테스트 수행 방법 등이 포함된 스크립트를 작성한 후 실행한다.
- 방식
- 데이터 주도 접근 방식 : 스프레드시트에 테스트 데이터를 저장하고, 이를 읽어 실행하는 방식
- 키워드 주도 접근 방식 : 스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 저장하여 실행하는 방식
성능 테스트 도구(Performance Test Tools)
- 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인하는 도구
테스트 통제 도구(Test Control Tools)
- 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구
- 종류 : 형상 관리 도구, 결함 추적/관리 도구 등
테스트 하네스 도구(Test Harness Tools)
- 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구
- 테스트 하네스(Test Harness)
- 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분
- 테스트를 지원하기 위해 생성된 코드와 데이터를 의미함.
테스트 하네스의 구성 요소
테스트 드라이버 (Test Driver) |
테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구 |
테스트 스텁 (Test Stub) |
제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈 |
테스트 슈트 (Test Suites) |
테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합 |
테스트 케이스 (Test Case) |
사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서 |
테스트 스크립트 (Test Script) |
자동화된 테스트 실행 절차에 대한 명세서 |
목 오브젝트 (Mock Object) |
사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체 |
테스트 수행 단계별 테스트 자동화 도구
테스트 단계 | 자동화 도구 | 설명 |
테스트 계획 | 요구사항 관리 | 사용자의 요구사항 정의 및 변경 사항 등을 관리하는 도구 |
테스트 분석 / 설계 | 테스트 케이스 생성 | 테스트 기법에 따른 테스트 데이터 및 테스트 케이스 작성을 지원하는 도구 |
테스트 수행 | 테스트 자동화 | 테스트의 자동화를 도와주는 도구로, 테스트의 효율성을 높임. |
정적 분석 | 코딩 표준, 런타임 오류 등을 검증하는 도구 | |
동적 분석 | 대상 시스템의 시뮬레이션을 통해 오류를 검출하는 도구 | |
성능 테스트 | 가상의 사용자를 생성하여 시스템의 처리 능력을 측정하는 도구 | |
모니터링 | CPU, Memory 등과 같은 시스템 자원의 상태 확인 및 분석을 지원하는 도구 | |
테스트 관리 | 커버리지 분석 | 테스트 완료 후, 테스트의 충분성 여부 검증을 지원하는 도구 |
형상 관리 | 테스트 수행에 필요한 다양한 도구 및 데이터를 관리하는 도구 | |
결함 추적/관리 | 테스트 시 발생한 결함 추적 및 관리 활동을 지원하는 도구 |
(9) 결함 관리
결함(Fault)
- 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것
- 사용자가 예상한 결과와 실행 결과 간의 차이나 업무 내용과의 불일치 등으로 인해 변경이 필요한 부분도 모두 결함에 해당된다.
결함 관리 프로세스
결함 관리 계획 | 전체 프로세스에 대한 결함 관리 일정, 인력, 업무 프로세스 등을 확보하여 계획을 수립함. |
↓ | |
결함 기록 | 테스터는 발견된 결함을 결합 관리 DB에 등록함. |
↓ | |
결함 검토 | 테스트, 프로그램 리더, 품질 관리(QA) 담당자 등은 등록된 결함을 검토하고, 결함을 수정할 개발자에게 전달함. |
↓ | |
결함 수정 | 개발자는 전달받은 결함을 수정함. |
↓ | |
결함 재확인 | 테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행함. |
↓ | |
결함 상태 추적 및 모니터링 활동 |
결함 관리 DB를 이용하여 프로젝트별 결함 유형, 발생률 등을 한눈에 볼 수 있는 대시보드 또는 게시판 형태의 서비스를 제공함. |
↓ | |
최종 결함 분석 및 보고서 작성 |
발견된 결함에 대한 정보와 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리를 종료함. |
결함 상태 추적
- 테스트에서 발견한 결함은 지속적으로 상태 변화를 추적하고 관리해야 한다.
- 발견된 결함에 대해 결함 관리 측정 지표의 속성 값들을 분석하여 향후 결함이 발견될 모듈 또는 컴포넌트를 추정할 수 있다.
- 결함 관리 측정 지표
결함 분포 | 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정 |
결함 추세 | 테스트 진행 시간에 따른 결함 수의 추이 분석 |
결함 에이징 | 특정 결함 상태로 지속되는 시간 측정 |
결함 추적 순서
결함 등록(Open) | 테스터와 품질 관리(QA) 담당자에 의해 발견된 결함이 등록된 상태 |
↓ | |
결함 검토(Reviewed) | 등록된 결함이 테스터, 품질 관리(QA) 담당자, 프로그램 리더, 담당 모듈 개발자에 의해 검토된 상태 |
↓ | |
결함 할당(Assigned) | 결함을 수정하기 위해 개발자와 문제 해결 담당자에게 결함이 할당된 상태 |
↓ | |
결함 수정(Resolved) | 개발자가 결함 수정을 완료한 상태 |
↓ | |
결함 조치 보류(Deferred) | 결함의 수정이 불가능해 연기된 상태로, 우선순위, 일정 등에 따라 재오픈을 준비중인 상태 |
↓ | |
결함 종료(Closed) | 결함이 해결되어 테스터와 품질 관리(QA) 담당자가 종료를 승인한 상태 |
↓ | |
결함 해제(Clarified) | 테스터, 프로그램 리더, 품질 관리(QA) 담당자가 종료 승인한 결함을 검토하여 결함이 아니라고 판명한 상태 |
결함 분류
시스템 결함 | 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함 |
기능 결함 | 애플리케이션의 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함 |
GUI 결함 | 사용자 화면 설계에서 발견된 결함 |
문서 결함 | 기획자, 사용자, 개발자 간의 의사소통 및 기록이 원할하지 않아 발생된 결함 |
결함 심각도
- 어플리케이션에 발생한 결함이 전체 시스템에 미치는 치명도를 나타내는 척도
- High, Medium, Low 또는 치명적(Critical), 주요(Major), 보통(Normal), 경미(Minor), 단순(Simple) 등으로 분류된다.
결함 우선순위
- 발견된 결함 처리에 신속성을 나타내는 척도
- 결함의 중요도와 심각도에 따라 설정되고, 수정 여부가 결정된다.
- 결정적(Critical), 높음(High), 보통(Medium), 낮음(Low) 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류된다.
결함 관리 도구
Mantis | - 결함 및 이슈 관리 도구 - 소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 추적도 가능한 도구 |
Trac | 결함 추적은 물론 결함을 통합하여 관리할 수 있는 도구 |
Redmine | 프로젝트 관리 및 결함 추적이 가능한 도구 |
Bugzilla | - 결함 신고, 확인, 처리 등 결함을 지속적으로 관리할 수 있는 도구 - 결함의 심각도와 우선순위를 지정할 수도 있음. |
(10) 애플리케이션 성능 분석
애플리케이션 성능
- 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도
- 애플리케이션 성능 측정 지표
처리량 (Throughput) |
일정 시간 내에 애플리케이션이 처리하는 일의 양 |
응답 시간 (Response Time) |
애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간 |
경과 시간 (Turn Around Time) |
애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간 |
자원 사용률 (Resource Usage) |
애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률 |
성능 테스트 도구
- 애플리케이션의 성능을 테스트하기 위해 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검하는 도구
- 부하(Load) 테스트 : 애플리케이션에 일정 시간 동안 부하를 가하면서 반응을 측정하는 테스트
- 스트레스(Stress) 테스트 : 부하 테스트를 확장한 테스트로, 애플리케이션이 과부하 상태에서 어떻게 작동하는지 테스트
- 종류
도구명 | 도구 설명 | 지원 환경 |
JMeter | HTTP, FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구 | Cross-Platform |
LoadUI | - 서버 모니터링, Drag & Drop 등 사용자의 편리성이 강화된 부하 테스트 도구 - HTTP, JDBC 등 다양한 프로토콜 지원 |
Cross-Platform |
OpenSTA | HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구 | Windows |
시스템 모니터링(Monitoring) 도구
- 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
- 종류
도구명 | 도구 설명 | 지원 환경 |
Scouter | - 단일 뷰 통합/실시간 모니터링, 튜닝에 최적화된 인프라 통합 모니터링 도구 - 애플리케이션의 성능을 모니터링/통제하는 도구 |
Cross-Platform |
Zabbix | 웹기반 서버, 서비스, 애플리케이션 등의 모니터링 도구 | Cross-Platform |
(11) 복잡도
복잡도(Complexity)
- 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말
- 시스템 또는 소프트웨어를 어느 정도의 수준까지 테스트해야 하는지 또는 개발하는 데 어느 정도의 자원이 소요되는지 예측하는 데 사용된다.
시간 복잡도
- 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것
- 시간 복잡도는 알고리즘의 실행 시간이 하드웨어적 성능이나 프로그래밍 언어의 종류에 따라 달라지기 때문에, 시간이 아닌 명령어의 실행 횟수를 표기한다.
- 이러한 표기법을 점근 표기법이라고 한다.
- 시간 복잡도는 알고리즘의 실행 시간이 하드웨어적 성능이나 프로그래밍 언어의 종류에 따라 달라지기 때문에, 시간이 아닌 명령어의 실행 횟수를 표기한다.
- 시간 복잡도가 낮을수록 알고리즘의 실행 시간이 짧고, 높을수록 실행 시간이 길어진다.
- 점근 표기법의 종류
빅오 표기법 (Big-Ο Notation) |
- 알고리즘의 실행시간이 최악일 때를 표기하는 방법 - 입력값에 대해 알고리즘을 수행했을 때, 명령어의 실행 횟수는 어떠한 경우에도 표기 수치보다 많을 수 없음. |
세타 표기법 (Big-Θ Notation) |
- 알고리즘의 실행시간이 평균일 때를 표기하는 방법 - 입력값에 대해 알고리즘을 수행했을 때, 명령어의 실행 횟수의 평균적인 수치를 표기함. |
오메가 표기법 (Big-Ω Notation) |
- 알고리즘의 실행시간이 최상일 때를 표기하는 방법 - 입력값에 대해 알고리즘을 수행했을 때, 명령어의 실행 횟수는 어떠한 경우에도 표기 수치보다 적을 수 없음. |
빅오 표기법으로 표현한 최악의 알고리즘 시간 복잡도
$O(1)$ | - 입력값(n)에 관계 없이 일정하게 문제 해결에 하나의 단계만을 거침. - 예) 스택의 삽입(Push), 삭제(Pop) |
$O(log_{2}n)$ | - 문제 해결에 필요한 단계가 입력값(n) 또는 조건에 의해 감소함. - 예) 이진 트리(Binary Tree), 이진 검색(Binary Search) |
$O(n)$ | - 문제 해결에 필요한 단계가 입력값(n)과 1:1의 관계를 가짐. - 예) for문 |
$O(nlog_{2}n)$ | - 문제 해결에 필요한 단계가 $n(log_{2}n)$ 번 만큼 수행됨. - 예) 힙 정렬(Heap Sort), 2-Way 합병 정렬(Merge Sort) |
$O(n^{2})$ | - 문제 해결에 필요한 단계가 입력값(n)의 제곱만큼 수행됨. - 예) 삽입 정렬(Insertion Sort), 쉘 정렬(Shell Sort), 선택 정렬(Selection Sort), 버블 정렬(Bubble Sort), 퀵 정렬(Quick Sort) |
$O(2^{n})$ | - 문제 해결에 필요한 단계가 2의 입력값(n) 제곱만큼 수행됨. - 예) 피보나치 수열(Fibonacci Sequence) |
순환 복잡도(Cyclomatic Complexity)
- 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도
- 맥케이브 순환도(McCabe's Cyclomatic) 또는 맥케이브 복잡도 메트릭(McCabe's Complexity Metrics) 라고도 한다.
- 제어 흐름도 이론에 기초를 둔다.
- 제어 흐름도 G에서 순환 복잡도 V(G)는 다음과 같은 방법으로 계산할 수 있다.
- [방법 1] 순환 복잡도는 제어 흐름도의 영역 수와 일치하므로 영역 수를 계산한다.
- [방법 2] V(G) = E - N + 2 (E : 화살표 수, N : 노드 수)
예제 : 제어 흐름도가 다음과 같을 때, 순환 복잡도(Cyclomatic Complexity)를 계산하시오.
- 순환 복잡도는 다음 두 가지 방법으로 구할 수 있다.
- (방법 1) 제어 흐름도에서 화살표로 구분되는 각 영역의 개수를 구하면 4이다.
- (방법 2) 순환 복잡도 = 화살표의 수 - 노드의 수 + 2 = 11 - 9 + 2 = 4
(12) 애플리케이션 성능 개선
소스 코드 최적화
- 나쁜 코드(Bad Code)를 배제하고, 클린 코드(Clean Code)로 작성하는 것
- 클린 코드(Clean Code) : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드, 즉 잘 작성된 코드
- 나쁜 코드(Bad Code)
- 프로그램의 로직(Logic)이 복잡하고 이해하기 어려운 코드
- 대표적인 나쁜 코드
- 스파게티 코드 : 코드의 로직이 서로 복잡하게 얽혀 있는 코드
- 외계인 코드 : 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
- 나쁜 코드로 작성된 애플리케이션의 코드를 클린 코드로 수정하면 애플리케이션의 성능이 향상된다.
클린 코드 작성 원칙
가독성 | - 누구든지 코드를 쉽게 읽을 수 있도록 작성함. - 코드 작성 시 이해하기 쉬운 용어를 사용하거나 들여쓰기 기능 등을 사용함. |
단순성 | - 코드를 간단하게 작성함. - 한 번에 한 가지를 처리하도록 코드를 작성하고, 클래스/메소드/함수 등을 최소 단위로 분리함. |
의존성 배제 | - 코드가 다른 모듈에 미치는 영향을 최소화함. - 코드 변경 시, 다른 부분에 영향이 없도록 작성함. |
중복성 최소화 | - 코드의 중복을 최소화함. - 중복된 코드는 삭제하고, 공통된 코드를 사용함. |
추상화 | 상위 클래스/메소드/함수에서는 간략하게 애플리케이션의 특성을 나타내고, 상세 내용은 하위 클래스/메서드/함수에서 구현함. |
소스 코드 최적화 유형
- 클래스 분할 배치 : 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고, 크기를 작게 작성함.
- 느슨한 결합(Loosely Coupled) : 인터페이스 클래스를 이용하여 추상화된 자료 구조와 메소드를 구현함으로써 클래스 간의 의존성을 최소화함.
소스 코드 품질 분석 도구
- 소스 코드의 코딩 스타일, 코드에 설정된 코딩 표준, 코드의 복잡도, 코드에 존재하는 메모리 누수 현상, 스레드 결함 등을 발견하기 위해 사용하는 분석 도구
- 정적 분석 도구와 동적 분석 도구로 나뉜다.
정적 분석 도구 | - 작성한 소스 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인하는 코드 분석 도구 - 종류 : pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등 |
동적 분석 도구 | - 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구 - 종류 : Avalanche, Valgrind 등 |
소스 코드 품질 분석 도구의 종류
도구 | 설명 | 지원 환경 |
pmd | 소스 코드에 대한 미사용 변수, 최적화되지 않은 코드 등 결함을 유발할 수 있는 코드를 검사함. | Linux, Windows |
cppcheck | C/C++ 코드에 대한 메모리 누수, 오버플로우 등 분석 | Windows |
SonarQube | 중복 코드, 복잡도, 코딩 설계 등을 분석하는 소스 분석 통합 플랫폼 | Cross-Platform |
checkstyle | - 자바 코드에 대해 소스 코드 표준을 따르고 있는지 검사함. - 다양한 개발 도구에 통합하여 사용 가능함. |
Cross-Platform |
ccm | 다양한 언어의 코드 복잡도를 분석함. | Cross-Platform |
cobertura | 자바 언어의 소스 코드 복잡도 분석 및 테스트 커버리지를 측정함. | Cross-Platform |
Avalanche | - Valgrind 프레임워크 및 STP 기반으로 구현됨. - 프로그램에 대한 결함 및 취약점 등을 분석함. |
Linux, Android |
Valgrind | 프로그램 내에 존재하는 메모리 및 쓰레드 결함 등을 분석함. | Cross-Platform |
728x90
그리드형(광고전용)
'Certificate > DPE' 카테고리의 다른 글
[정보처리기사 실기] 11. 응용 SW 기초 기술 활용 (1) | 2022.03.05 |
---|---|
[정보처리기사 실기] 10. 프로그래밍 언어 활용 (4) | 2022.03.04 |
[정보처리기사 실기] 09. 소프트웨어 보안 구축 (0) | 2022.03.03 |
[정보처리기사 실기] 08. SQL 응용 (0) | 2022.03.02 |
[정보처리기사 실기] 06. 화면 설계 (0) | 2022.02.28 |
[정보처리기사 실기] 05. 인터페이스 구현 (0) | 2022.02.27 |
[정보처리기사 실기] 04. 서버 프로그램 구현 (0) | 2022.02.27 |
[정보처리기사 실기] 03. 통합 구현 (0) | 2022.02.26 |