검증과 확인

Verification and Validation

• 우리가 제품을 제대로 만들고 있는가?
• 주로 검사와 리뷰를 통해 이루어진다.

• 우리가 올바른 제품을 만들고 있는가?
• 주로 테스트를 통해 이루어진다.

정적 시스템 표현 분석을 통해 문제를 발견하는 과정(정적 검증)

• 구현 전 검사 가능

• 요구사항, 설계, 코드, 문서 등

소프트웨어의 실행을 통해 문제를 발견하는 과정(동적 검증)

• 요구사항 명세(Requirement Specification)
• 소프트웨어 아키텍처(Software Architecture)
• UML 설계 모델(UML Design Model)
• DB 스키마(DB Schema)
• 프로그램

• 시스템 프로토타입(System Prototype)
• 프로그램

• 고객의 실제 요구사항과의 일치 여부
• 성능, 사용성 등 비기능적 특성

• 버그와 결함을 발견하기 위해 개발 중에 시스템을 테스트
• 개발자가 단위 테스트(Unit Test)와 통합 테스트(Integration Test)를 수행

• 별도의 테스트 팀이 사용자가 사용하기 전 시스템의 완전한 버전을 테스트
• 시스템의 전체 버전을 테스트하여 모든 기능이 통합되어 제대로 동작하는지 확인한다.

• 시스템 사용자 또는 잠재적 사용자가 자신만의 환경에서 시스템을 테스트
• 이 단계에서는 사용자의 실제 사용 시나리오를 기반으로 소프트웨어를 테스트한다.

• 개별 프로그램 단위나 객체 클래스를 테스트
• 객체나 메서드의 기능 테스트에 중점을 둔다.

• 여러 개의 개별 단위를 결합하여 컴포넌트를 테스트
• 컴포넌트 테스트는 컴포넌트 인터페이스 테스트에 중점을 둔다.

• 시스템의 일부 또는 모든 컴포넌트를 결합하여 시스템을 테스트
• 컴포넌트 상호작용 테스트에 중점을 두어야 함

• 테스트 객체의 외부 관점에서 테스트 케이스 도출
• 유효한 입력과 무효한 입력을 선택하고 올바른 출력을 결정
• 테스트 객체 내부 구조에 대한 지식이 없다.

• 프로그램 구조에 따라 테스트 케이스를 도출한다.
• 프로그램에 대한 지식을 사용하여 추가적인 테스트 케이스를 식별

입력 데이터 영역을 여러 개의 하위 집합(분할)으로 나누고, 각 분할에서 대표적인 값을 선택하여 테스트하는 기법

• Partition 1: 0, 5 (유효하지 않은 값)
• Partition 2: 6, 10 (유효한 값)
• Partition 3: 11, 14 (유효하지 않은 값)

• 시퀀스에 최소한 하나의 요소가 존재한다.
• T`FIRST < = L < = T`LAST

• Found = TRUE이면, T(L) = Key
• Found = FALSE이면, T에 Key가 존재하지 않는다.