테스트 목적
- 결함의 검출과 제품 품질 개선
- 품질 평가와 의사 결정 지원
- 개발 프로세스 개선 지원
- 정해진 요구사항을 만족하는지 확인, 주어진 표준을 준수하는지 검증하기 위해 수행
오류, 결함, 장애
오류 human error
- 사람에 의해 발생되는 실수 (코딩 및 타이핑 실수)
- 요구사항을 제대로 파악하지 못한 실수 (요구사항 불이행)
- 결함을 생기게 한 개발자의 행위
결함 fault, defect
- 에러로 발생한 잘못된 로직
- 소프트웨어 내에 장애를 유발할 수 있는 문제 (부정확한 구현, 필요한 기능 미포함)
- 누락, 비관련, 부정확한 구현으로 분류
장애 failure
- 요구사항과 다르게 동작
- 소프트웨어를 구성하는 요소에 부족한 점이 있어서 발생
결함의 유형
누락
- 요구사항이 시스템의 구현에 반영되지 않은 결함
- 성능, 보안, 안전, 신뢰도 등 품질 요소에 관한 누락
부정확한 구현
- 요구사항이 소프트웨어에 부정확하게 반영된 결함
- 성능, 보안, 안전, 신뢰도 등 품질 요소에 관한 누락
비관련
- 요구 명세와 관련되지 않은 구현
- 직접적인 장애를 유발하지 않지만 불필요한 분석, 테스트, 관리의 노력을 유발
개발 단계별 결함
결함을 검출하여 제거하지 않으면 다음 단계에 영향을 끼쳐 장애를 유발
제거되지 않고 개발로 전달되면 제거를 위해 더 많은 비용 소요
테스팅, 디버깅, 재테스팅
테스팅
- 실제 동작과 요구사항과의 차이를 확인
- 동적 테스트 : 결함의 존재 여부를 모르고 발견을 목적으로 프로그램 실행
- 장애가 있을 때 결함이 존재한다고 추측
- 테스팅의 결과는 결함을 검출한 테스트 케이스와 테스트 환경
- 어떤 모듈에서 발생했고, 해결하기 위해 소스 코드를 어떻게 수정해야하는지에는 관여하지 않음
디버깅
- 결함의 존재를 확인한 후에 결함의 위치를 파악하고 제거를 목적으로 진행
- 결함 제거를 위해 소스코드 수정
재테스팅
- 실제로 결함이 제거되었는지 확인
테스트의 현실/실제
완벽한 테스트의 비현실성
- 다익스트라 : 프로그램 테스트는 결함이 있음을 보일 수 있지만, 결함이 없음을 보일 수 없다.
- 동적테스트 : 테스트의 한계를 고려해서 테스트 케이스를 설계 - 동등 분할, 경곗값 분석, 조합 테스트 등
- 위험 기반 테스트 방법 : 위험 분석을 바탕으로 테스트할 범위 선정
테스트의 진화과정
갤퍼린과 헤첼 5레벨
- 레벨 1 : 테스트, 디버깅에 차이X / 우연히 발견된 결함을 수정하는 디버깅에 중점
- 레벨 2 : 시스템의 정상 작동을 증명하는 데 초점이 맞추어진 테스트 케이스를 설계하는 경향이 있음
- 레벨 3 : 결함이 존재함을 보여주기 위한 테스트, 의도적으로 테스트 케이스 설계, 결함을 발견한 테스트 케이스가 그렇지 못한 테스트 케이스보다 가치 있음
- 레벨 4 : 소프트웨어 개발 전 단계에서 발생하는 결함을 발견하는 개념으로 확장, 개발 초기 단계부터 지속적 리뷰
- 레벨 5 : 결함 발생을 사전에 방지, 테스트 케이스를 미리 설계, 테스트 주도 개발(TDD)
테스트 원칙
마이어스 원칙
- 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹이 수행
- 결함이 발견되지 않으리라는 가정하에 테스트 계획을 수립하면 안됨 (갤퍼린과 헤첼 레벨 3)
- 타당한 경우뿐만 아니라 타당하지 않고 예상하지 못한 경우도 테스트 수행 (정수형에 문자열 입력 등)
- 프로그램의 어떤 부분에 결함이 남아있을 확률은 그 부분에서 이미 발견된 결함의 수에 비례 (파레토 법칙8020), 결함이 많이 발생한 곳에 집중하는 것이 좋음
- 테스트 케이스를 체계적으로 관리 (수정 후에도 원래의 테스트케이스 확인)
- 각각의 테스트 결과를 철저하게 점검
테스트와 품질
테스트와 품질 평가
| 기능 적합성 | 요구되는 기능을 만족시키는 능력 |
| 성능 효율성 | 적절한 자원의 사용 및 적정한 반응시간 정도 |
| 호환성 | 다른 시스템과의 상호 연동 능력 |
| 사용성 | 사용자가 이해하고 배우기 쉬운 정도 |
| 신뢰성 | 규정된 조건에서 규정된 기간 동안 오동작 없이 의도된 기능을 수행하는 소프트웨어의 능력 |
| 보안성 | 정보 및 데이터를 보호하는 능력 |
| 유지보수성 | 소프트웨어 유지보수의 용이성 |
| 이식성 | 다양한 플랫폼에서 운영될 수 있는 소프트웨어의 능력 |
- 기능 테스트 : 기능 요구사항에 중점을 둔 테스트
- 비기능 테스트 : 품질 요구사항에 초점을 둔 테스트
각 품질 특성을 테스트하는 방법도 모두 다름
- 유형 테스트 : 각 품절 특성 별로 수행되는 테스트 (성능 테스트, 보안 테스트, 신뢰성 테스트 등)
테스트와 품질 보증
V&V(verification and validation)
- 검증은 개발 과정에서 수행한 활동의 적합성 검사에 초점, 결과물에 적절하게 반영되었는지 조사하는 추적성 확인
- 확인은 결과물의 적합성에 초점, 소프트웨어가 주어진 요구사항을 충족하는지 확인
- 요구사항 평가, 인터페이스 분석, 추적성 분석, 심각성 분석
V&V는 정형방법, 테스팅, V&V 분석으로 분류
- 정형방법 : 모델체킹, 정확성 증명
- 테스팅 : 동적 테스팅과 정적 테스팅
- V&V 분석 : 시뮬레이션, 평가
품질 보증
- 프로그램 요구사항과 시스템 요구사항이 이해관계자 요구사항과 부합하는지
- 소프트웨어 요구사항이 시스템 요구사항에 부합하는지
- 프로세스와 표준 및 절차가 프로세스 요구사항에 부합하는지
- 프로세스 활동의 수행이 프로세스, 표준 및 절차에 부합하는지
- 소프트웨어가 소프트웨어 요구사항에 부합하는지
테스트 기본 용어
테스트 대상과 테스트 레벨
테스트 대상
- 결함을 검출하려는 대상 소프트웨어
- 규모가 클 수록 전체 테스팅이 어려움, 부분 테스트 후에 통합하여 전체 테스트 수행이 효과적
- 시스템 테스트 : 전체 소프트웨어를 대상으로 한 테스트
- 단위/컴포넌트 테스트 : 부분을 대상으로 한 테스트
- 통합 테스트 : 각 부분의 연결에 초점을 둔 테스트
피처와 테스트 유형
피처
- 테스트하고자 하는 측면, 관점
- 다양한 측면, 관점의 소프트웨어에 대한 기대, 요구는 요구분석 단계를 거쳐 요구사항 명세서에 기록
- 테스트 계획을 수립할 때 식별되어 테스트 범위로 기술되고 테스트 설계 활동을 통해 피처가 구체화
테스트 설계 기법
대상을 실행하지 않고 테스트를 수행하는 방법(리뷰, 정적 분석)
정적 테스트
- 해당 단계의 산출물이 품질 목표에 부합하는지 점검하거나 산출물에 존재하는 결함을 검출하려는 목적
- 소스 코드를 대상으로 결함으로 판단할 수 있는 특정한 패턴이 소스 코드에 있는지 분석
- 실행 환경을 필요로 하지 않음
- 소스 코드 작성 전 요구분석 단계, 구조 설계 단계, 상세 설계 단계 등에서 수행
- 자동화 도구 사용 - 테스트 자동으로 수행 가능 / 결함이 아닌 문제를 결함으로 보고하는 오검지 발생 가능
동적 테스트
- 소프트웨어를 실행하는 방식으로 테스트를 수행해서 결함을 검출
- 명세 기반 방법 :내부 논리 구조를 참조하지 않고 요구 명세나 설계 정보를 이용하여 테스트케이스를 개발. 대상 시스템의 명세 정보를 얻을 수 있는 한 대상에 제한이 없음. 컴포넌트 테스트, 통합 테스트, 시스템 테스트 및 인수 테스트 등 전 과정에 걸쳐 사용 가능.
- 구조 기반 방법 : 프로그램의 제어 흐름이나 자료 흐름 정보를 이용해서 테스트 케이스를 설계하는 방법. 내부 구조 정보로 테스트 케이스를 설계. 구조적 테스트, 화이트박스 테스트, 글래스 박스 테스트라고 함
- 경험 기반 테스트 : 테스트 케이스 설계를 바탕으로 테스트를 수행하지 않고 도메인에 대한 테스터의 경험, 기존 테스트 결과, 테스터의 직관으로 주로 활용하여 테스트를 수행. 오류 추정, 탐색적 테스트
- 실행 가능한 소프트웨어가 필요. 소스 코드는 사용되지 않음.
- 소프트웨어 실행 환경 요구
테스트 절차
- 준비된 테스트 케이스의 입력값을 실제 테스트 대상에 입력해서 테스트 대상을 실행
- 준비, 실행, 결과 관찰, 기록
- 테스트 절차는 검출된 결함을 재연할 때도 사용
- 문서로 기록하는 대신 자동화 도구가 해석하고 실행하는 언어로 작성한 것을 테스트 스크립트라고 함
테스트 환경
- 컴포넌트, 단위 테스트의 경우 대상이 일부분(컴포넌트 또는 모듈), 컴포넌트 자체가 독립적으로 실행될 수 없음 -> 드라이버와 스텁 사용
- 테스트 실행 시 사용될 수 있는 다양한 테스트 도구도 테스트 환경으로 간주
- 시스템이 동작하는 실제 환경과 최대한 유사한 환경에서 테스트를 수행
테스트 기본 용어 요약
- 테스트 대상, 피처, 테스트 방법, 테스트 케이스, 테스트 절차, 테스트 환경 개념 간의 관계
- 하나의 테스트 대상에 복수 개의 피처 가능
- 피처 : 기능 피처, 비기능 피처(성능, 보안 등) / 피처에 초점을 둔 테스트가 유형 테스트
- 테스트 설계 기법 : 정적 테스트, 동적 테스트
- 정척 테스트 : 리뷰, 정적 분석
- 동적 테스트 : 명세 기반 테스트, 구조 기반 테스트, 경험 기반 테스트
- 동적 테스트 시 복수 개 테스트 케이스 설계
- 테스트 케이스는 피처(테스트 대상의 측면, 관점)에 따라 결정
- 테스트 절차 : 복수 개의 테스트 케이스가 특정 환경에서 수행되도록 순서를 정함
'CSTS' 카테고리의 다른 글
| 6. 소프트웨어 생명 주기 모델과 테스트 (0) | 2021.02.26 |
|---|---|
| 5. 위험 기반 테스트 (1) | 2021.02.25 |
| 4. 품질 특성과 비기능 테스트 (2) | 2021.02.24 |
| 3. 소프트웨어 개발 단계와 테스트 (0) | 2021.02.23 |
| 2. 테스트 분류와 테스팅 방법 (0) | 2021.02.21 |
