■ 소프트웨어 테스트 정의
구현된 으용 애플리케이션이나 시스템이 사용자가 요구하는 기능의 동작과 성능, 사용성, 안전성 등을 만족하는지 확인하기위해 소프트웨어의 결함을 찾아내는 활동
■ 소프트웨어 테스트의 필요성
오류 발견 관점 / 오류 예방 관점 / 품질 향상 관점
■ 소프트웨어 SW 테스트 7가지 원칙 [ 완 존 초 집 살 정 오 ]
(1) 테스팅은 결함이 있다는 것을 증명하는 것이다.
(2) 완벽한 테스팅은 불가능하다.
(3) 테스팅은 가능한 초기에 시작해야 한다. / 조기 테스팅으로 시간과 비용을 절약할 수 있다.
(4) 살충제 패러독스 : 동일한 테스트 케이스로 반복 실행하면 더이상 새로운 결함을 발견할 수 없다.
(5) 결함집중(Defect Clustering) : 출시 전 테스팅에서 발견하는 대부분의 결함은 소수의 모듈에 집중되어 발생하는 경향을 보이며, 운영상 장애의 대부분 역시 소수의 모듈에서 발생한다. (파레토랑 다른거- 숫자가 없음)
(6) 테스트는 정황(Context)에 의존적이다. : 애플리케이션 테스트는 소프트웨어 특징, 테스트환경, 테스트 역량 등 정황 (Context)에 따라 테스트 결과가 달라지므로, 정황에 따라 테스트를 다르게 수행해야함.
(7) 오류-부재의 궤변 : 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없음.
■ 파레토 법칙 (Pareto 법칙)
전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 의미, 애플리케이션 결함의 대부분은 소수의 특정한 모듈에서 집중되어 존재한다는 의미 <-> 롱테일법칙
■ 애플리케이션(소프트웨어) 테스트 분류
프로그램 실행여부에 따른 TEST
- 정적 테스트 (인스펙션, 코드검사, 워크스루 등) : 명세서나 소스 코드를 대상으로 분석하는 테스트
+ 애플리케이션을 실행하지 않고, 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함을 발견하지 위해 사용하는 도구 ------> 정적 분석 도구
* 인스펙션(Inspection) : 정형기술검토(FTR)의 분류는 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
- 동적 테스트 (화이트,블랙박스 테스트)
■ 블랙박스 테스트 [ 동 경 원 오 비 ] - 명세 기반 기법
[ 정의 ] 소스코드 참조 없이 외부에 드러난 인터페이스만을 이용하여 검사하는 기법
동치분할 / 경계 값 분석 / 원인효과 그래프 / 오류예측 검사 / 비교검사
- 동등분할(동치분할) 기법: 입력값의 범위를 유사한 특징을 갖는 동등그룹으로 나누고, 각 그룹마다 대표 값을 선정하는 테스트기법
- 경계 값 분석 : 경계의 유효한 값과 경계에서 가장 가까운 유효하지 않은 값을 테스트 데이터로 선택하는 테스트 기법
- 원인 효과 그래프 : 입력값을 원인으로, 효과를 출력값으로 선정하는 테스트 기법
- 의사결정 테이블 테스팅 기법 : 생성될 수 있는 결과를 테이블로 나열하여 가능한 모든 조합을 테스트하는 기법
- 도메인 테스트 : 입력변수들 간에 상관관계가 존재하는 경우 그 관계에 따라 영역을 분할하고 테스트 케이스를 도출하는 방법
■ 화이트박스 테스트 [ 기 제 조 루 데 ] - 구조 기반 기법 / NCS - [ 제 데 루 ]
기초 경로검사 / 제어구조검사- (조건검사 / 루프 검사 / 데이터 흐름 검사 )
*기본경로검사 : 순환복잡도(Cyclomatic Complexity)를 통해 독립적인 경로의 수를 찾아 테스트하는 기법
- Tom McCabe에 의해 개발
- 순환복잡도는 [V(G) = P + 1] 공식 → P는 분기문이다.
■ 그레이박스 테스트 (Gray-box Test)
소프트웨어의 내부 구조의 일부만 알고 수행하는 테스트로 블랙박스 테스트 + 화이트 박스 테스트가 혼합된 방식
테스트 기반(종류)에 따른 테스트
- 명세기반 테스트 : 명세를 테스트케이스로 만들어 Test
- 구조기반 테스트 : 내부의 논리 흐름에 따라 test
- 경험기반 테스트 : 유사 SW나 기술들의 test
* 구조기반 기법 종류
구문 커버리지
결정 커버리지
조건 커버리지
조건/결정 커버리지
변경조건/결정 커버리지
다중조건 커버리지
*경험기반 테스트 (기술에서의 경험, 직관, 테스트의 기술 능력으로부터 테스트케이스를 추출하는 기법)
탐색적 기법 / 오류 추정 기법 / 체크리스트 기법 / 분류 트리 기법
시각에 따른 테스트
- 검증 (Verification/ 개발자 시각,명세)
- 확인(Validation / 사용자시각, 요구사항 동작)
목적에 따른 테스트
- 회복테스트 (Recovery Test) : 여러 결함을 주고 -> 복구여부
- 안전테스트 (Securit Test): 불법침입 -> 시스템 보호 여부
- 강도테스트 (Stress Test) : 과도한 정보량 -> 정상 실행 여부
- 성능테스트 (Performance Test) : SW 응답시간 , 처리량 test
- 구조테스트 (Structure Test) : SW 내부 논리 경로, 소스코드 복잡성
- 회귀테스트 (Regression Test) : SW 왼료된 후 소프트웨어 변경이 발생할 때, 수정코드가 새로운 결함이 있는지 확인
- 병행테스트 (Paraller Tets) : 변경 VS 기존 결과 비교
통합테스트 (점진적 통합방식)
- 하향식 통합테스트 | 상향식 통합테스트 | 혼합식 통합테스트
■ 통합 테스트 종류
- 상향식 통합 테스트 (Bottom up) : ↑ 가장 하부의 모듈부터 통합
(최하위 레벨의 모듈 또는 컴포넌트들이 하위모듈 기능을 수해하는 클러스터로 결합 -> 더미 모듈인 [드라이버 Driver] 작성 -> 통합된 클러스터 단위 테스트 -> 테스트 완료 후 각 클러스터들은 프로그램의 위쪽으로 결합)
- 하향식 통합 테스트 (Top-down) : ↓ 가장 상부의 모듈부터 통합
(더미모듈인 [스텁 Stub]을 개발 -> 깊이-우선 방식 또는 너비-우선 방식에 따라, 하위 모듈인 스텁이 한번에 하나씩 실제모듈로 대체 -> 테스트 수행)
* Stub : 스텁은 다른 프로그래밍 기능을 대리하는 코드이다. 스텁은 기존 코드를 흉내 내거나, 아직 개발되지 않은 코드를 임 시로 대치하는 역할을 수행한다.
- 혼합식 통합 테스트 : 하위 수준에서는 상향식 통합, 상위수준에서는 하향식 통합 사용하여 최적의 테스트를 지원하는 방식, 샌드위치(Sandwich)식 통합 테스트 방법이라고도 함.
- 백본 테스트
- 빅뱅 테스트 : 모든 테스트 모듈을 동시에 통합
- 회귀 테스팅(Regression Testing): 통합 테스트가 완료 된 후 변경된 모듈이나 컴포넌트가 있을 경우, 다른 부분에 영향을 미치는 지 테스트하여 새로운 오류 여부를 확인하는 테스트
+ 기능 추가나 오류를 수정한 소프트웨어가 수정에 의해 새로이 유입된 오류가 없는지 확인하는 반복 테스트
인수테스트 (Acceptance Test)
- 알파테스트 (개발자와 함께 통제된 환경에서 테스트) : 새로운 하드웨어와 소프트웨어의 프로토타입이 운영되는 과정에서 상품으로 출시하기 전 개발인력이 성능을 확인하는 테스트
- 베타테스트 (개발자 제어 없어, 주기적보고): 선발된 잠재 고객으로 하여금 일정 기간 무료로 사용하게 한 후에 나타난 여러가지 오류를 수정, 보안하는 테스트
■ 테스트오라클 [ 참 샘 추 일 ] : 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 에상 결과를 결정하는 근거- -
[ 정 의 ] 테스트 결과가 참인지, 거짓인지 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동이다.
- 참오라클 : 모든 테스트 케이스 입력 값에 의한 결과값의 확인, 발생된 오류를 모두 검출 가능
- 샘플링 오라클 : 특정한 몇 개의 입력값에 대해서만 기대 결과를 제공 / 전 범위가 테스트가 불가한 경우 사용
- 추정(휴리스틱 Heuristic)오라클: 특정 입력 값에 대해 올바른결과 제공, 나머지는 휴리스틱(추정)으로 처리하는 오라클
- 일관성(Consistent) 검사 오라클 : 애플리케이션 변경이 있을 때, 수행 전과 후의 결과 값이 동일한지 확인하는 오라클
■ 테스트 환경 구축
- 하드 웨어 기반의 테스트 환경 구축
- 소프트웨어 기반의 테스트 환경 구축
- 가상 시스템 기반의 테스트 환경 구축
■ 애플리케이션 통합테스트
- 통합테스트 목적: 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 동일한 구조와 기능으로 구현된 것인지 확인하기 위함
■ 테스트 자동화 도구 유형
[ 사 용 이 유 ] 사람이 반복적으로 수행하던 테스트 절차를 자동화 도구를 사용함으로써 휴면에러를 줄이고 테스트의 정확성을 유지하면서 테스트의 품질을 향상시킬 수 있다.
[ 유 형 ]
- 정적 분석 도구 (Static Analysis Tools) : 애플리케이션을 실행하지 않고 분석하는 방법 / 소스 코드 분석 (소스 코드에 대한 코딩표준, 코딩 스타일, 코드 복잡도 및 남은 결함 등을 발견하기 위해 사용)
- 테스트 실행 도구 (Test Execution Tools) : 스크립트 언어를 사용하여 테스트를 실행하는 방법
- 성능 테스트 도구 (Performance Test Tools): 애플리케이셔의 처리량, 응답시간, 경과시간, 자원사용률 등 다야야한 조건에 대해 가상의 사용자를 생성해 테스트를 수행하여 목표 달성여부를 확인하는 도구
- 테스트 통제 도구 (Test Control Tools) : 테스트 계획 및 관리, 테스트 수행, 결함관리 등을 수행하는 도구 / 종류로는 형상관리도구, 결함/추적 관리 도구 등
- 테스트 장치 (= Test Harness) / 테스트 하네스 도구 (Test Harness Tools) : 테스트가 실행 될 환경을 시물레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트 되도록 하는 도구
* 테스트하네스 : 시스템 및 시스템 컴포넌트를 시험하는 환경의 일부분으로 시험을 지원하는 목적하에 생성된 코드와 데이터. 시험 드라이버 (test driver)라고도 하며 일반적으로 단위 시험이나 모듈 시험에 사용하기 위해 코드 개발자가 만든다.
[네이버 지식백과] 테스트 하네스 [test harness, 試驗-] (IT용어사전, 한국정보통신기술협회)
| 테스트 하네스 구성요소 [ 드 스 슈 케 스 목 ] |
설명 |
| 테스트 드라이버 (Test Driver) | 상향식 테스트에 필요 |
| 테스트 스텁 (Test Stub) | 하향식 테스트에 필요 |
| 테스트 슈트 (Test Suites) | 여러 테스트 케이스의 집합 |
| 테스트 케이스 (Test Case) | 테스트 상황을 테스트하기 위해 개발된 입력값, 실행 사전조건, 예상 결과, 실행 사후 조건들의 집합 |
| 테스트 스크립트(Test Script) | 테스트 절차 명세, 자동화 된 것 |
| 목 오브젝트 (Mock Object) | 사용자의 행위를 조건부로 사전에 입력하고, 그 상황에 예정된 행위를 수행하는 객체 |
- 테스트 자동화 도구 : 휴먼 에러 (Human Error)줄이고, 테스트 소요비용과 시간 절감
■ 테스트케이스 및 시나리오 작성 절차 시 수행되는 활동
테스트 케이스 작성/ 테스트용 스크립트 작성 / 테스트 케이스 검토 / 테스트 시나리오 작성
■ 소스코드 품질 분석 도구
- 정적 분석 도구 : 소스 코드 실행시키지 않고 코드 자체만으로 코딩 표준 준수여부, 코딩 스타일 적정 여부, 잔존 결함 발견 여부 확인하는 코드 분석 도구이다. 종류) pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura
(1) 구조 검사도구 : 소프트웨어의 내부 구조를 검사할 수 있는 도구
(2) 데이터 분석 도구 : 소프트웨어의 내부 데이터 흐름을 분석할 수 있는 도구
(3) 순서 검사도구 : 소프트웨어의 실행 순서를 분석할 수 있는 도구
- 동적 분석 도구 : 실행시켜 코드에 존재하는 메모리 누수현황을 발견, 스레드 결함을 분석하기 위한 도구
종류) Avalanche, Valgrind 등
■ 테스트 도구 사용시 장점
- 반복되는 테스트 데이터 재입력 작업의 자동화를 통해 시간 절약
- 사용자 요구 기능에대한 일관적인 검증에 유리
- 테스트 결과 값에 대한 객관적인 평가기준 제공
- 테스트 결과의 통계 작업과 그래프 등 다양한 표시 형태 제공을 통해 테스팅 관련 정보에 접근이 용이
- UI가 없는 서비스의 경우에도 정밀한 테스트 가능
■ 테스트 결과 분석 - 소프트 웨어 결함
- 에러 / 오류 : 일반적으로 개발자들이 프로그램 코드 또는 기타 작업 산출물 작성시 결함 발생됨
- 결함/결점/버그 : 에러 또는 오류의 원인으로 소프트웨어 제품에 포함되어있는 결함을 말함, 이를 제거하지 않으면 제품이 실패하거나 문제가 발생할 수 있다.
- 실패 / 문제 : SW제품에 포함된 결함이 실행될 때 발생되는 현상
■ 테스트 결함 관리 (결함 추적 관리활동) [ 단 통 시 인 ]
단위 테스트 -> 통합 테스트 -> 시스템 테스트 -> 인수 테스트
- 단위 시험 : 분리하여 시험 가능한 소프트웨어 모듈의 기능을 확인하는 활동
- 통합 시험 : 모듈을 결합하여 하나의 시스템으로 구성 시 테스트 수행
- 시스템 시험 : 통합 모듈에 대한 시스템적(비기능적) 테스트, 신뢰성, 견고성, 성능, 안전성 등의 비기능적 요구사항도 테스트
- 인수 시험 : 사용자의 만족 여부를 테스트하는 품질 테스트를 수행
* V 모델 (폭포수 개발 모델에 근간을 두고 있음)
| 요구사항 분석 <----------------------------------------------------> 인수 테스트 기능명세 분석 <----------------------------------------------> 시스템 테스트 확인 (Validation)(사용자 시각) 시스템 설계 <------------------------------------> 통합 테스트 개발 <-------------------------> 단위 테스트 검증(Verification) (개발자 시각) 테스트 계획 및 설계----------------> <---------------- 테스트 수행 |
■ 결함조치 상태 (= 오류 목록 상태)
(1) 열린 [Open] : 오류가 보고 되었지만 아직 분석되지 않은 상태
(2) 할당된 [Assigned] : 수정을 위해 오류를 개발자에게 할당한 상태
(3) 연기된 [Deffered] : 낮은 우선순위로 오류 수정을 연기한 상태
(4) 종료된 [Closed] : 재 테스트시 오류가 발견되지 않은 상태
(5) 수정된 [Fixed] : 개발자가 오류를 수정한 상태
(6) 분류된 [Classified] : 보고된 오류를 관계자들이 확인했을 때 오류가 아니라고 확인한 생태
■ 결함 상태 추적(결함 관리 측정 지표) [ 분 추 에 ]
결함 분포 / 결함 추세 / 결함 에이징 (등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정하여 분석)
■ 결함관리 프로세스
에러 발견 -> 에러 등록 -> 에러 분석 -> 결함 확정 -> 결함 할당 -> 결함 조치 -> 결함 검토 및 승인
■ 테스트 산출물 4가지 [ 결 계 시 케 ]
테스트 결과서 / 테스트 계획서 / 테스트 시나리오 / 테스트 케이스
■ 소프트웨어 테스트 산출물 상세
- 테스트 계획서
- 테스트 케이스 (Test Case): 테스트를 위한 설계 산출물, 테스트 항목을 위해 테스트 케이스의 집합을 명세화한 문서
+ 요구사항을 준수하는지 검증하기 위해 테스트 조건, 입력 값, 예상 출력 값 및 수행한 결과 등의 테스트 조건을 명세한 것
+ 명세기반 테스트의 설계 산출물
+ 명세 기반 테스트의 설계 산출물로 설계된 입력값, 실행조건, 기대결과로 구성된 테스트 항목의 명세서
+ 비지니스 수행 커버리지 측정의 도구로 사용하기 위해 테스트 전의 입력 값과 테스트 후의 기댓값들의 집합
-테스트 시나리오 : 테스트 실행을 위한 동작 순서를 기술한 문서 / 여러 테스트 케이스의 집합
**한 번 더 정확히 : 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스들을 묶은 집합으로, 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서이다.
- 테스트 결과서 : 테스트 결과를 정리한 문서로 테스트 프로세스를 리뷰, 테스트 결과를 평가하고 리포팅하는 문서
- 테스트 슈트 : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트케이스의 집합
■ 테스트 커버리지 (Test Coverage)
주어진 테스트 케이스에 의해 수행되는 소프트웨어 테스트 범위를 측정하는 테스트 품질 측정 기준
소프트웨어의 소스코드가 얼마만큼 테스트가 되었는 가를 나타내는 지표
■ 테스트 커버리지 종류
- 기능 기반 커버리지
- 라인 커버리지
- 코드 커버리지 (Code Coverage)
(1) 구문(Statement) 커버리지 : 코드 구조 내 모든 구문에 대해 한 번 이상 수행하는 테스트 커버리지
(2) 조건 커버리지 (Condition) : 모든 개별 조건식에 대해 수행하는 테스트 커버리지
* 각 개별 조건식이 참 한 번, 거짓 한 번을 갖도록 테스트 케이스를 만드는 방법
(3) 결정 커버리지(=분기 커버리지) (Desicion) : 모든 분기문에 대해 수행하는 테스트 커버리지
* 프로그램에 있는 분기를 최소한 한 번은 실행하기 하는 테스팅 방법
(4) 변형 조건/결정 커버리지 (Modified Condition Decision)
* 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주는 테스트 커버리지
-> 전체 조건식 뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행하는 커버리지 테스트 유형
(5) 다중조건 커버리지 (Multiple Condition)
* 결정 포인트 내 있는 모든 개별 식 조건의 모든 조합을 고려한 커버리지
■ 결함 심각도 분류 : 치명적 (Critical) 결함, 주요 (Major) 결함, 보통(Normal), 경미한 (Minor)
■ 결함 우선순위 표현 : 결정적 (Critical), 높음 (High), 보통 (Medium) , 낮음(Low)
■ 애플리케이션 성능 분석 측정 지표 [ 처 응 경 자 ]
- 처리량 : 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션 수
- 응답시간 : 사용자 입력후 애플리케이션 응답 출력이 개시될 때까지의 시간
- 경과시간 : 사용자가 요구를 입력한 시점부터 결과의 출력이 완료할 떄까지 걸리는 시간
- 자원 사용률 : 애플리케이션이 트랜잭션을 처리하는 동안 사용하는 CPU, 메모리, 네트워크 사용량을 의미
■ 성능분석 도구
- 성능/부하/스트레스 (Performance/Load/Stress) 점검 도구
- 모니터링 (Monitoring) 도구
■ 애플리케이션 성능 저하 원인
(1) 데이터베이스 연결 및 쿼리 실행시
- DB Lock : 대량의 데이터 조회, 과도한 업데이트, 인덱스 생성시 발생하는 현상 / 요청한 작업은 락이 해제될때까지 대기하거나 타임아웃됨
- 불필요한 데이터베이스 패치 (DB fetch)
- 연결 누수 (Connection Leak) / 부적절한 커넥션 풀 크기(Connection Pool Size)
(2) 내부 로직으로 인한 성능저하
(3) 잘못된 환경 설정이나 네트워크 문제로 인한 성능 저하 원인
■ 나쁜코드 (Bad Code)
작성자 외 다른 개발자가 로직을 이해하기 어려운 코드
ex) 스파게티 코드, 외계인 코드 (아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램 코드)
■ 클린코드 (Clean Code)
잘 작성되어 가독성이 높고, 단순하고, 의존성을 줄이고, 중복을 최소화하여 깔끔하게 정리된 코드 , 버그를 찾기 쉬움
■ 클린코드 작성 원칙 [ 가 단 의 중 추 ]
가독성 / 단순성 / 의존성 / 중복성 / 추상화
■ 코드리팩토링에 대해서 설명 (2020.3회출제)
소프트웨어를 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법으로 소프트웨어를 보다 이해하기 쉽고 수정하기 쉽도록 만드는 기법
* 리팩토링 기법 : 메소드 정리 / 객체간 기능 이동 / 데이터 구성 / 조건문 단순화 / 일반화
* 메소드 정리기법유형 : inline Method(메소드합침) / Extract Method(별도의 메소드로 뽑아냄) / Extract Class / Parameterize Method
* 객체간 기능 이동 기법유형
- Move Merhod : 메소드가 자신이 속한 클래스보다 다른 클래스의 기능을 더 많이 사용 시
- Move Field : 필드가 자신이 속한 클래스보다 다른 클래스에서 더 많이 사용시
- Extract Class : 두 클래스가 처리해야할 기능이 하나의 클래스에 들어가 있을 때 클래스 분해
■ STAF
서비스 호출, 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크
■ xUnit
자바, C++, .Net 등 다양한 언어를 지원하는 단위 테스트 프레임워크
■ 셀레니움 Selenium
다양한 브라우저 지원 및 개발 언어를 지원하는 웹 애플리케이션 테스트 프레임워크
■ Fitnesse
웹 기반 테스트 케이스 설계, 실행 결과 확인 등을 지원하는 테스트 프레임워크
■ 애플리케이션 테스트와 디버깅의 차이점
테스트는 알려지지 않은 에러를 발견하기 위한 활동,
디버깅은 이미 알고 있는 에러의 수정을 위해 원인을 파악하는 활동
'자격증 > 정보처리기사' 카테고리의 다른 글
| [정보처리기사_실기] Chapter 9. 소프트웨어 개발 보안 구축 (0) | 2020.10.11 |
|---|---|
| [정보처리기사_실기] Chapter 8. SQL 응용 (0) | 2020.10.11 |
| [정보처리기사_실기] Chapter 6. 화면 설계 (0) | 2020.10.11 |
| [정보처리기사_실기] Chapter 5. 인테페이스 구현 (0) | 2020.10.11 |
| [정보처리기사_실기] Chapter 4. 서버프로그램 구현 (0) | 2020.10.10 |