1. 테스트 개념
-
소프트웨어 테스트 정의
- 소프트웨어 실행 후 그 결과가 올바른지 판단하는 과정
- 에러 발견이 목적
- 소프트웨어 품질을 측정하고 개선하기 위한 과정
- 오류가 존재함을 보일수 있지만
오류가 없음을 보일 수 없음.
-
소프트웨어 오류의 원인
- 요구 사항 오류
- 설계 오류
- 코딩 오류
- 기타 오류
- 문서, 코딩 표준 미반영
- 미흡한 테스트 프로세스
-
Beizer의 소프트웨어 테스트 진화 과정
-
Level 1 Debugging-oriented
- 디버깅에 중점
- 오류를 찾기위한 노력 x
-
Level 2 Demonstration-oriented
- 동작함을 입증
하기 위해 테스트 진행
- 동작함을 입증
-
Level 3 Destruction-oriented
- 오류가 존재함을 입증
하기 위해 테스트 진행
- 오류가 존재함을 입증
-
Level 4 Evaluation-oriented
- 전체 개발 단계에서 오류를 발견
하기 위해 테스트 진행
- 전체 개발 단계에서 오류를 발견
-
Level 5 Prevention-oriented
- 오류를 사전에 방지
- 프로그램 개발 전에 테스트가 용이하도록 설계
-
-
테스트 용이성
=> 프로그램이 얼마나 손쉽게 테스트 가능한지를 나타내는 특성
(=이단 관제 안분운)-
이해용이성
- 설계 정보가 잘 조직화되어 쉽게 접근 가능하도록 하여
소프트웨어를 더욱 잘 이해할 수 있도록 설계
- 설계 정보가 잘 조직화되어 쉽게 접근 가능하도록 하여
-
단순성
- 가능한 한 단순하게 설계
- 시스템이 단순할수록 효율적으로 테스트 수행
- 가능한 한 단순하게 설계
-
관찰가능성
- 내부 상태를 쉽게 파악할 수 있도록 설계
-
제어용이성
- 제어하기 용이하도록 설계
- 테스트 자동화에 도움
-
안정성
- 소프트웨어 변경이 자주 발생하지 않게 설계
-
분할용이성
- 문제가 발생된 곳을 고립시킴으로써
독립적으로 모듈을 테스트 할 수 있도록 설계
- 문제가 발생된 곳을 고립시킴으로써
-
운영용이성
- 오작동하여도 테스트 작업을 계속할 수 있도록 설계
-
1-1. 테스트목적
테스트의 목적
-
결함 검출 , 품질 평가 , 프로세스 개선
-
결함의 검출과 제품 품질 개선
- 테스트는 결함을 검출하기 위한 목적으로 수행
- 검출된 결함을 제거함으로써 소프트웨어 품질을 개선하는 것이 목표
- 테스트는 결함을 검출하기 위한 목적으로 수행
-
품질 평가와 의사 결정 지원
- 테스트 결과를 바탕으로 성능, 신뢰성, 보안성 등의
다양한 소프트웨어 품질 특성에 대한 충족 수준을 평가하고,
품질 평가 결과를 바탕으로 소프트웨어 제품에 대한 의사 결정을 수행
- 테스트 결과를 바탕으로 성능, 신뢰성, 보안성 등의
-
개발 프로세스 개선 지원
-
소프트웨어 개발 과정 중 어떤 단계에서 결함이 발생하는지 분석하고,
그러한 결함이 왜 검출되지 않았는지 파악함으로써 개발 프로세스 개선- Ex) 검출된 결함 중에서 요구사항 관련 결함이 많다면
요구분석 단계의 프로세스와 결함 검출 방법을 개선
- Ex) 검출된 결함 중에서 요구사항 관련 결함이 많다면
-
-
1-2. 오류, 결함, 장애
- 장애(Failure)
- 프로그램의 실행 결과와 요구사항에 명시된 결과에 차이가 있음
- 소프트웨어를 구성하는 요소에 부족한 점이 있어서 발생
- 프로그램의 실행 결과와 요구사항에 명시된 결과에 차이가 있음
- 결함(Defect)
- 장애를 유발할 수 있는 문제
- 결함이 있다고 해서 반드시 장애가 발생하는 것은 아님
- 에러에 의해 발생되며 장애의 원인
- 장애를 유발할 수 있는 문제
-
오류(Error)
- 결함을 생기게 한 개발자의 행위
- 사용자의 요구사항을 잘못 파악·이해하여 발생하는 실수,
오탈자나 프로그램 명령어를 잘못 이해하여 코딩하는 경우 - 버그 => X
-
결함(Defect) 유형
-
누락(Omission)
- 요구 명세에 명시된 요구사항이 시스템의 구현에 반영되지 않은 결함
- 기능적인 것뿐만 아니라 성능 등 품질 요소도 포함
-
부정확한(Incorrect) 구현
- 요구 명세에 명시된 요구사항이 소프트웨어에 부정확하게 반영된 결함
- 기능적인 것뿐만 아니라 성능 등 품질 요소도 포함
-
비관련(Extraneous) 결함
- 요구 명세와 관련되지 않은 구현
- 직접적인 장애를 유발하지 않을 수 있지만 다른 결함을 초래하는 원인
-
-
개발 단계별 결함
-
소프트웨어를 개발하는 각 단계에서 오류를 범할 수 있으므로
각 단계의 산출물에는 결함이 존재할 가능성ㅇ -
결함을 제거하지 않고 개발을 지속하게 되면 진행된 상황에 따른 비용이 높아짐.
-
비용을 최소화하기 위해서는 각 개발 단계에 존재하는 결함을
최대한 빨리 검출하고 제거 -
수정 비용은 각 단계별로 계속 증가
요구분석 < 설계 < 코딩 < 단위 테스팅 < 인수 테스팅 < 유지 보수
-
-
테스팅, 디버깅, 재테스팅
- 테스트와 디버깅의 차이점
-
테스팅
-
실제 동작과 요구사항과의 차이를 확인하는 작업
-
알려지지 않은 결함을 발견하는 것
-
장애(Failure)가 있을 때 내부에 결함이 존재한다고 판단
- 장애 발생을 확인하여 소프트웨어 결함이 있음을 간접적으로 판단
-
테스팅의 결과는 결함을 검출한 테스트 케이스와 테스트 환경
-
어떤 환경에서 어떤 입력값을 사용하였을 때 예상되는 결과와 실제 출력 결과 등을 기록하지만
이 결함이 소프트웨어의 어떤 모듈에서 발생하였고 이를 해결하기 위하여
소스코드를 어떻게 수정해야 하는지 관여 X
-
-
디버깅
-
테스팅을 통하여 결함의 존재를 확인한 후에 수행되며
결함의 위치를 파악하고 제거하는 것을 목적 -
이미 알고 있는 오류를 수정하는 작업
-
시스템 내부 관련자가 수행
-
에러 타입을 식별 -> 에러를 수정
-
-
재테스팅
- 코드를 수정하고 나면 실제로 결함이 제거되었는지 확인하는 작업
1-3. 테스트와 품질
-
테스트와 품질 평가
-
ISO의 품질 특성 분류를 바탕으로 진행하며
요구사항 명세는 대표적으로
기능 요구사항과 품질 요구사항을 포함- 기능 요구 사항에 중점을 둔 테스트는 기능(Functional) 테스트
- 품질 요구 사항에 초점을 둔 테스트는 비기능(Non-Functional) 테스트
-
- ISO 25010 품질 평가
- 기신사호 성보유이
주특성 설명 기능 적합성 요구되는 기능을 만족시키는 능력 신뢰성 규정된 조건에서 규정된 기간동안 오작동 없이 의도된 기능을 수행하는 능력 사용성 사용자가 이해하고 배우기 쉬운 정도 호환성 다른 시스템과의 상호 연동 능력 성능 효율성 적절한 자원의 사용 및 적정한 반응시간 정도 보안성 정보 및 데이터를 보호하는 능력 유지보수성 유지보수의 용이성 이식성 다양한 플랫폼에서 운영 될수 있는 능럭
- 기신사호 성보유이
-
테스트와 품질 보증
V&V(Verification and Validation) 와 품질 보증
-
V&V
검증(Verification)과 확인(Validation)의 약어로서
소프트웨어 품질 보증을 위한 핵심 개념
정형 방법 : 모델 체킹과 정확성 증명
테스팅 : 동적 테스팅과 정적 테스팅
V&V 분석 : 시뮬레이션과 평가
-
검증(Verification)
- 개발 과정에서 수행한 활동의 적합성 검사에 초점
- 요구사항 명세서가 구조 설계 및 상세 설계의 결과물에
적절하게 반영되었는지를 조사하는 추적성 확인
-
확인(Validation)
- 결과물의 적합성에 초점
- 동작하는 소프트웨어가 요구사항에 충족하는지 확인
-
-
품질 보증
- 의도한 목적에 적합한 품질의 소프트웨어 제품을 개발하였는지,
프로세스가 적합한지에 대한 확신을 주기 위하여 수행되는 다양한 활동
- 의도한 목적에 적합한 품질의 소프트웨어 제품을 개발하였는지,
-
- 광범위성
- 테스트 < V&V < 품질보증
- 테스트 < V&V < 품질보증
2. 테스트 기본 용어
2-1. 테스트 대상과 테스트 레벨
-
테스트 대상(Test item)
결함을 검출하려는 대상- 전체 시스템의 일부분을 먼저 테스트한 후에
각 부분을 통합하여 전체를 대상으로 테스트를 수행
- 전체 시스템의 일부분을 먼저 테스트한 후에
-
테스트 레벨
=> 레벨 테스트-
(소프트웨어 테스트 단계 순서 : 단위 - 통합 - 시스템 - 인수 테스트)
-
컴포넌트/단위 테스트 : 부분을 대상으로 한 테스트
-
통합 테스트 : 시스템을 구성하는 각 부분의 연결에 초점을 둔 테스트
-
시스템 테스트 : 전체 소프트웨어를 대상으로 한 테스트
-
-
2-2. 피처와 테스트 유형
-
피처
(Feature)-
테스트하고자 하는 관점
-
테스트 계획을 수립할 때 식별되어 테스트 범위로 기술
-
테스트 설계 활동에서 피처가 구체화되며
이를 기준으로 테스트 케이스 및 테스트 절차 개발
-
2-3. 테스트 설계 기법
-
정적 테스트
실행하지 않고 테스트를 수행하는 방식
대표적인 방법으로 리뷰와 정적 분석
-
리뷰(Review)
-
각 개발 단계별로 해당 단계의 산출물이 품질 목표에 부합하는지 점검하거나
산출물에 존재하는 결함을 검출하려는 목적으로,
산출물로 검사하는 방법 -
요구사항 단계가 종료된 시점에
고객으로부터 받은 요구사항이 누락되지 않고
요구사항 단계에서 정확하게 반영되었는지 검토하는 활동
-
-
정적 분석(Static analysis)
-
소스 코드를 대상으로 결함으로 판단할 수 있는 특정한 패턴이 소스 코드에 있는지 분석
- ex). 변수를 초기화하지 않고 그 값에 접근하려고 하는 패턴은 결함이라고 볼 수 있으므로
소스 코드를 분석하여 초기화하지 않고 사용되는 변수를 파악하여 결함을 검출
- ex). 변수를 초기화하지 않고 그 값에 접근하려고 하는 패턴은 결함이라고 볼 수 있으므로
-
장점 : 자동화 도구를 활용함으로써 테스트를 자동으로 수행가능
-
단점 : 결함이 아닌 문제를 결함으로 보고하는 오검지(False positive)
-
-
정적 테스트의 장점
-
실행 환경 필요 X
(=경제적) -
소스 코드가 작성되기 이전에 산출물에 대한 테스트 가능
-
-
-
동적 테스트
소프트웨어를 실행하는 방식으로 테스트
입력에 대한 기대 결과를 명시
실행하여 기대 결과와 다른 결과가 발생하는 경우 결함이 있다고 판단-
명세 기반 방법
-
프로그램의 내부 논리 구조를 참조하지 않고
사용자의 요구 명세나 설계 정보 등을 이용하여 테스트 케이스를 개발 -
시스템의 명세 정보를 얻을 수 있는 한
적용 대상에 제한이 없으며
테스트 전 과정에 걸쳐 사용.
-
-
구조 기반 방법
-
(= 구조적 테스트, 화이트박스 테스트, 글래스 테스트 )
-
제어 흐름이나 자료 흐름 정보를 이용하여 테스트 케이스를 설계
-
내부 구조 정보를 기반으로 테스트 케이스를 설계
-
-
경험 기반 테스트
-
테스트 케이스 설계를 바탕으로 테스트를 수행하지 않고
도메인에 대한 테스터의 경험,직관, 테스트 결과를 활용하여 테스트
- 오류 추정
- 탐색적 테스트
-
-
동적 테스트의 장점과 단점
-
장점 : 소스 코드가 제공되지않은 경우에도 수행가능
-
단점 : 소프트웨어 실행 환경 필요
-
-
2-4. 테스트 케이스
-
특정 경로를 실험해 보거나 특정 요구 사항을 준수하는지를 확인하기 위한 목적으로 사용
- 확인을 위해 개발된 입력값, 실행 사전 조건, 예상 결과 및 실행 사후 조건을 포함한 내용의 집합
-
하나의 테스트 프로시저로 여러 개의 테스트 케이스를 실행가능
-
요구사항에서 명시하지 않은 입력도 테스트 케이스 가능
-
필수조건은 예상되는 결과를 미리 정의해두는 것
2-5. 테스트 절차
(= 테스트 프로시저)
- 테스트를 준비하고 실행하고 결과를 관찰하고 기록하는 절차를 정의
- 디버깅에 많은 도움
- 테스트 환경 구축
- 준비된 입력값을 테스트 대상에 입력
- 테스트를 객관적이고 효율적으로 수행하려면 이러한 과정을 명시적으로 정의하고 기록
2-6. 테스트 환경
-
컴포넌트ㆍ단위 테스트의 경우
컴포넌트 자체가 독립적으로 실행될 수는 없어서
사용자ㆍ환경으로부터의 입력을 대상 컴포넌트에 전달하기 위한 다른 모듈이 필요- 테스트 대상 컴포넌트가 다른 컴포넌트를 이용하거나 호출한다면 피호출 컴포넌트가 필요
- 테스트 드라이버
- 테스트 스텁
- 테스트 대상 컴포넌트가 다른 컴포넌트를 이용하거나 호출한다면 피호출 컴포넌트가 필요
-
테스트 도구도 테스트 환경으로 간주
-
실제 환경과 최대한 유사한 환경에서 테스트를 수행 필요
