[소프트웨어공학] Verification & Validation

Verification (검증)

주어진 단계의 제품이 이전 단계에서 온 사양을 충족하는지 여부를 결정하는 프로세스
-> 이전의 단계가 현재와 일치하는지 검증

Validation (확인)

요구사항 준수를 보장하기 위해 개발 종료 시 소프트웨어를 평가하는 프로세스

목표

• 품질 좋은 소프트웨어 개발
• 소프트웨어 제품에서 오류 및 결함을 찾기

요구사항

• 모든 사항을 확인해야 한다.
• 검증 결과는 바이너리가 아닐 수 있다.
• 검증은 객관적이거나 주관적일 수 있다.
• 내재적 품질도 검증해야 한다.

V & V 활동의 분류

• error : 엔지니어의 실수
• Fault : 사용자에게 정확한 서비스 제공이 불가능한 상태
• Failure : 발견되지 않은 오류, 사용자가 실수를 했는데 정상적으로 작동

Static 활동 - 소스코드 실행 X

• 시스템 동작을 관찰하지 않음
• 시스템 결함을 찾지 않음
• 결함이 직접 탐지됨

dynamic

• 시스템 동작이 관찰됨
• 실패의 존재를 결정
• 실패의 부재가 아니라 결함의 존재를 나타낸다.
• 실제 결함은 "디버깅" 활동으로 식별된다.
• 실패가 없다고 해서 결함이 없는 것은 아니다. (고장이 안난다고 해서 결함이 없다고 말할 수 X)
• 테스트(dynamic testing)

3가지 종류

• Review
• Walkthrough
• Inspection

Reviews
일반적으로 각 단계의 종료시점에 실시
검토판이나 패널을 위한 자료 발표로 구성

• Informal review : 내부 검토
• Formal review : 고객 또는 스폰서와 검토

Walkthrough : 산출물을 검토자에게 보내서 상세하게 살펴봄

• 단계별 또는 라인별 제품 상세 검사
• 3 또는 5명의 참가자와 몇 시간 회의
• 수정 작업이 아닌 error 발견에 집중 -> 개발자의 실수를 찾는데 포커스
• 수작업으로 제품 시뮬레이션 실행

Inspection :

• 단계별 또는 라인별 제품 상세 검사
• 조직 측면에서 walkthrough과 유사하다.
• error 유무 확인
• 잘 알려진 error 유형은 미리 분류되어 있다.

Software testing

Dynamic verification activities (Dynamic 활동)
목적

• 실제 결과와 예상되는 동작 간의 불일치 확인
• 정확성, 신뢰성, 성능 등에 대한 높은 보증을 제공하기 위해

기본 테스트 질문

• 어떤 경우 테스트를 해야하나?
  • 어떤 테스트 데이터를 사용해야 하나?
  • 소프트웨어의 어떤 측면을 테스트해야 하나?
• 출력이 올바른가?
  • 사양을 충족하는가
  • 고객의 요구를 충족하는가
• 언제 테스트를 중지할 수 있는가?
  • 충분한 수의 결함을 발견했는가?
  • 제품을 만족스럽게 커버했는가?
• 얼마나 잘했는지?
  • 높은 보증을 제공하는가?

모든 입력 조건 테스트

: 가능한 모든 입력 조건을 사용하여 프로그램을 테스트하는 것은 불가능하다.
테스트를 통해 오류가 없음을 보장할 수 없다.
발견되지 않은 오류가 없는 경우 합리적인 수준의 신뢰성을 확보할 수 있는 소수의 테스트 케이스 설계

Q : 올바른 원칙을 선택하라
테스팅은 프로그램의 정확성을 증명하기 위한 목적으로 프로그램을 실행하는 과정이다. (X)
자명하지 않은 모듈이나 시스템을 완전히 테스트하는 것이 가능하다. (X)
테스팅는 창의력과 노력을 필요로 한다. (O)
테스팅를 통해 오류 발생을 방지할 수 있다. (X) -> 또 다른 에러를 유발할 수 있음
테스팅는 여러 독립적인 테스터가 수행하는 것이 가장 좋다. (O) -> 내가한 개발은 내가 테스트

테스트 절차

• 테스트 프로세스 계획
• 테스트 목표 및 목표 정의: 규칙 중지
• 테스트 케이스 설계
• 테스트 준비
• 테스트 케이스 실행
• 테스트 결과 평가
• 소프트웨어 분석
• 프로세스 개선

Test Cases
2가지 문제:
1. 프로그램이 해야할 것을 하지 않는 경우
2. 프로그램이 하지 말아야 할 것을 하는 경우
Test Case는 valid하고 예상되는 입력 조건뿐만 아니라 invalid하고 예기치 않음에 대해서도 작성되어야 한다.
test case는 input + expected result

테스트 케이스 명세는 다음으로 구성되어야 한다.

• 테스트 케이스 식별자
• 테스트 항목
• 입력 사양
• 출력 사양
• 환경적 필요 및 특별 절차 요구 사항

테스트 오라클

• 테스트 오라클은 테스트 실행 동작을 검증하기 위한 메커니즘이다.

Unit Testing 기법

test case 선택 기준
Structural

• Path selection criteria
• Data selection criteria
• Error-oriented criteria

Functional

• 휴리스틱 사용

Structural vs Functional

Structural (White box)

• 소프트웨어 구조/구현에 따른 테스트 케이스 선정
• 실제 기능을 고려하지 않고 프로그램이 해야 할 일을 하는지 판단할 수 없음

Functional (Black box)

• 기능 사양에 따른 테스트 케이스 선정
• 의도된 기능을 고려하지 않고 프로그램이 해야 할 일을 하는지 판단할 수 없음.

Structural testing

: 소프트웨어 구조를 다루는 목적에 따라 구동되는 Dynamic testing

• Path selection criteria
• Data selection criteria
• Error-oriented criteria

Path Selection Criteria

• 테스트할 명령문 및 분기 순서 선택에 포커스
• 소프트웨어 흐름 구조를 커버하는 것을 목표로 테스트
• structural flow graphs에 기반
  • Control Flow Coverage : Statement Coverage, Branch Coverage 등
  • Data Flow Coverage

Control Flow Coverage : Statement Coverage

: 프로그램의 제어 구조를 충분히 커버하도록 경로(paths)를 선택함으로써 테스트 케이스가 개발된다.

테스트 케이스 선택을 가이드하는데 사용됨
모든 문장이 실행되어야 함

• 정확성을 보장한다고 해서 100% 문장 범위를 달성하는 것은 아님
• 그러나 100% 문장 범위 미만은 프로그램에 테스트되지 않은 코드가 있음을 의미한다.

Branch (Decision) Coverage

: 개발 소스의 각 분기문이 수행되었는지 확인하는 테스트 커버리지

테스트 케이스 선택을 가이드하는데 사용됨
모든 브랜치가 실행되어야 함

• If-then, if-then-else statement
  • True and False branches
• Case statement
  • each branch and others or default
• “while”, “repeat” and “for” statements
  • 루프 본문에 한 번 이상 들어가고 종료해야한다.

Data Flow Coverage

: 프로그램 변수 선언과 사용을 추적하는 테스트 커버리지

테스트 케이스 선택을 가이드하는데 사용됨
변수 선언 후 사용됐는지 테스트함
All-Defs : 각 용도의 정의에 도달함
All-Uses : 모든 각 정의에 대해 사용됨
All-DU-Paths : 정의부터 사용까지 경로

Error-Oriented Criteria

Error-Oriented Testing
: 프로그래밍 프로세스에서 인적 오류가 발생하는지 여부를 평가하는 데 초점을 맞춘 테스팅
1. Condition Coverage
2. Mutation Coverage

1. Condition Coverage
: 결정의 각 조건은 가능한 모든 결과를 적어도 한 번은 취해야 한다.
Condition/Decision Coverage
: 각 조건의 참 또는 거짓은 적어도 한 번 테스트된다.
MC/DC Coverage
Modified Condition / Decision Coverage
: Condition/Decision Coverage + 각 결정에서 조건은 결과에 독립적으로 영향을 미친다.

2. Mutation Coverage
: 대체 프로그램 (돌연변이)은 원래 프로그램을 구문적으로 수정하여 (자동으로) 생성된다.

• Red fish = 실제 프로그램 faults(알 수 없는 인구)
• Blue fish = 시드 faults (돌연변이)
• 적정성 : 잡은 Blue fish 수, Red fish 추정

• 샘플 돌연변이
  • 논리적 커넥터 교체
  • 관계 연산자 교체
  • 문장 삭제
  • 단항 연산자 삽입
  • 배열 참조 교체
  • 산술 연산자 대체

Functional (Black Box) Testing

: 기능적 요구 사항을 명세하는 문서를 기반으로 한 테스트
Exhaustive testing
: 입력, 기능 등의 가능한 모든 조합을 테스트
Random testing
: 임의로 선택된 입력 도메인으로 부터 하위 집합 테스트를 선택하여 테스트

Functional Testing Heuristics
: 목표는 지정된 각 소프트웨어 기능을 테스트하는 것
Heuristics

• equivalence partitioning
  • Input/output domain coverage
• boundary value coverage 
• special value coverage

Equivalence Partitioning (동치분할)

• 모듈 인터페이스 및 기능 기반
• 입력과 기능 간의 관계에서 테스트 데이터 도출
• 입력 도메인이 동등한 처리를 받는 데이터의 하위 집합으로 분할된다.
• 출력 공간 분할도 고려될 수 있다.

Input Domain Coverage

• 모듈 인터페이스에 기반
• 입력 특징으로부터 테스트 데이터 구동
• 입력 조건의 범위에 대해 기능을 테스트하는지 확인한다.

Boundary Value Coverage : 경계값 관점에서 테스트 데이터를 만들자

• 모듈 인터페이스에 기반
• 범위의 경계 특성으로부터 테스트 데이터 도출
  • 입력 조건이 값의 범위를 지정하는 경우: 예: [-1.0, +1.0]
    • 경계 테스트
    • 경계 바로 바깥쪽을 테스트
  • 입력 조건이 값의 수를 지정하는 경우: 예: 1..255
    • 최대값 및 최소값 테스트
    • 최소값보다 작은 값과 최대값을 초과하는 값을 테스트
• 순서가 지정된 세트의 경우 첫 번째 요소와 마지막 요소에 포커스를 맞춘다.

Special Value Coverage : 테스트할 기능에 따라

• 알고리즘 특성 및 잘 알려진 민감 값에서 테스트 데이터 도출

SDLC에서 테스팅

1. 고객의 니즈
2. 요구사항
3. 설계
4. 코드
5. Unit Testing
6. Integration Testing
7. System Testing
8. Acceptance Testing

Unit Testing
요구사항과 비교하는 단위 테스트
Integration Testing
컴포넌트 인터페이스의 일관성을 보장하기 위한 소프트웨어 컴포넌트의 체계적인 결합 및 테스트
System Testing
통합 하드웨어 및 소프트웨어 시스템 테스트
Acceptance Testing
소프트웨어 시스템 또는 시스템이 고객 요구 사항을 충족하는지 입증하기 위한 테스트
Regression Testing
수정 후 재시험

Unit Testing
: 단일 유닛 또는 모듈을 실행하기 위해 수행되는 유닛 테스트
Integration Testing

• 시스템의 요소가 결합됨에 따라 테스트가 필요하다.
• 잘 테스트된(올바른) 모듈의 통합으로 인해 오류가 발생할 수 있다.
  • 인터페이스의 잘못된 사용
  • 관련 모듈의 동작에 대한 잘못된 가설
  • 불량 드라이버/스텁 사용
• 테스트 접근 방식
  • Non-incremental : 모든 요소가 한 번에 결합되어 테스트된다.
  • Incremental : 요소가 점진적으로 추가되고 테스트된다.

Regression Testing

: 이전 버전에서 상속된 이전 기능의 유효성을 다시 확인하기 위함
새로운 버전 배포할 때마다 테스팅한다.

• 수정 사항이 올바르게 작동하고,
• 프로그램의 수정되지 않은 부분은 수정으로 인해 부정적인 영향을 받지 않아야 한다

Object-Oriented Software 테스팅

• System testing
  • 사용자 관점에서 애플리케이션 평가
  • 애플리케이션의 동작에서 테스트 케이스 개발 도출
• Unit testing
  • 클래스의 데이터와 메소드에 대한 액세스
  • 클래스에 있는 모든 메소드와 인터페이스 기능을 보장하는 것으로 구성
  • 캡슐화를 처리하는 실행 환경 필요

예제 시스템을 테스팅하기

• Outline method
  • 관련 정보를 그룹화하는 유용한 툴
• Use cases method 
  • 액터 시나리오에 초점

유즈 케이스의 테스트 케이스

• 유즈 케이스
  • 요구사항 문서화를 위한 효과적인 메커니즘
  • 액터의 관점에서 애플리케이션의 동작 설명
  • 테스트 케이스로 쉽게 번역
  • 종종 성능 및 부하 테스트와 관련된 정보를 생략합니다.

유즈 케이스의 4개 섹션

• 메인헤더 : 고유한 아이디와 간단한 설명
• 성공보증서 : 성공시 최종상태
• 주요 성공 시나리오 : 모든 단계가 정상적으로 완료되고 복구가 필요하지 않은 가장 간단한 시나리오
• 확장 : 주요 성공 시나리오의 한 단계에서 분기되는 대체 과정

Non-Functional Testing

• 소프트웨어 시스템 또는 시스템이 요구 사항에 지정된 비기능적 기능을 충족하는지 확인하기 위한 테스트

테스트 기술

• 보안 테스트 (Security Testing)
  • 시스템이 승인되지 않은 사람의 접근을 적절하게 통제하고 있습니까? (데이터 및 소프트웨어 액세스)
• 정확도 테스트 (Accuracy Testing)
  • 결과가 이론적 정확성에 가깝습니까?
• Performance Testing
  
  • 시스템이 모든 조건에서 응답 시간, 처리량 및 저장 요구 사항을 충족합니까?
•  Load/Stress Testing (과부하)
  • 시스템은 여러 동시 인터럽트와 같은 높은 부하와 스트레스에서 제대로 작동합니까?
• Volume Testing
  
  • 시스템이 장기간에 걸쳐 최대 데이터를 관리할 수 있습니까?