Software Engineering : Verificatin, Validation, and Test

ParkIsComing·2022년 12월 12일
0
post-thumbnail

Sw test의 정의

Sw가 정해진 요구를 만족하는지 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동화된 방법을 동원하여 검사하고 평가하는 일련의 과정

Verification, Validation, and Test

Validation

  • dynamic diagram (state, sequence, communication diagram)
  • implementation diagrams (component, deployment diagram)

Review

-> static test

static test

1) review
2) static analysis

test

-> dynamic test

Test case

들어가야 하는 것

  • (사전조건)
  • input
  • expected result
  • (사후조건)

Quality attribute and test

  1. 기능 테스트 : 기능성
  2. 비기능 테스트 : 신뢰성 / 사용성 / 효율성 / 유지보수 / 이식성

Error / Fault / Failure

  1. 오류 = error
    • 개발자 실수
    • 사용자 요구사항을 잘못 이해해 생긴 실수
    • ~~실수
  2. fault = defect = bug
    • 오류가 표현된 것
  3. 장애 (fail, failure)
    • 결함의 실행으로 예상과 다른 결과
    • 실행 결과 != 요구사항에 명시된 결과
  • 테스트가 프로그램의 결함이 있는 부분을 실행한다고 반드시 오작도 발생하는 건 x

Testing & Debugging

  • testing
    • find failure that are caused by bugs
    • 문제를 찾는다
  • debugging
    • identifies the root cause of a bug
    • repairs the code
    • check that the defect is fixed correctly
    • 문제의 원인을 찾는다.
  • confirmation testing
    • ensure the fix resolves the observed failure
    • fix가 failure을 해결했는지 확인 (by test engineer)
  • testers -> test
  • programmers -> debug

Test level & Test processes

Test level

단위 테스트 (component testing)

  • 구현된 모듈 테스트-
  • 방법: white-box

통합 테스트 (integration testing)

  • 모듈, 컴포넌트 사이의 인터페이스 및 상호연동하는 동작을 테스트
  • 개발자가 아닌 제3자의 테스트 필요

시스템 테스트 (system testing)

  • 분석 단계의 요구사항에 따라 개발되었는지 검사
  • using requirement spec.
  • 기능 테스트 & 비기능 테스트

인수 테스트 (acceptance testing)

  • 완성된 시스템이 사용자 요구사항을 만족하는지 테스트

Test process

  • 테스트는 단일 활동이 아닌 프로세스
  • multi-layer test process
    • 조직 테스트 프로세스
    • 테스트 관리 프로세스
      • 테스트 계획
      • 테스트 모니터링 / 제어
      • 테스트 종료
    • 동적 테스트 프로세스
      • 테스트 설계 및 구현
      • 테스트 환경 설정 및 유지
      • 테스트 실행
      • 결함 보고

test activity

  • 테스트 계획(plan)

    • output : 테스트 계획서
  • 테스트 설계(design)

    • 테스트 모델 구축
    • 테스트 항목 정의
    • output: 테스트 설계 명세서
  • 테스트 생성(generation)

    • 테스트 케이스 작성 / 선정
    • output: 테스트 케이스 명세서
  • 테스트 실행&분석

    • output: 테스트 결과 문서

테스트 계획

  • 프로젝트 테스트 계획
  • 개별 테스트 계획
    • 단계별 테스트 계획
    • (유형) 테스트 계획

❗테스트 분석 & 설계

  • 정적 테스트 (실행x)

    • review (수동)
      • walkthrough
      • inspections
      • 비공식적 리뷰
      • 기술적 리뷰
    • 정적 분석 (자동/도구)
  • 동적 테스트 (실행o)

    • 명세 기반 테스트(black box / behavioral, specification-based)
      • equivalence partitioning
      • boundary value analysis
      • pair-wise test
      • 상태 전이
      • 결정 테이블
    • 구조 기반 테스트 (white box / structure based)
      • 구문 커버리지 (statement coverage)
      • 결정 커버리지 (decision coverage)
      • 조건 커버리지 (condition coverage)
      • 조건/결정
      • 다중 조건
    • 경험 기반 테스트

    test documentation

  • organization test documentation

  • test management documentation

  • dynamic test documentation

  • test management documenatation

    principles of test

    7 testing principles

  1. testing shows presence of defects

    • 결함이 존재함을 밝히지만 결함이 없다는 것은 증명 불가
  2. exhaustive testing is impossible

    • 완벽한 테스팅 불가능
    • 리스크 분석과 우선순위에 따른 테스팅이 필요
  3. early testing

  4. defect clustering
    :결합 집중현상

  5. pesticide paradox
    : 동일한 테스트 케이스를 동일한 테스트를 반복하면 결함 찾기 어려움.

  6. testing is context dependent
    : 테스팅은 context에 따라 다르게 진행

  7. absence-of-errors fallacy
    : 결함수정을 많이 한다고 사용자/고객의 만족도가 높아지는 건 아님

sw 아키텍처 설계 원칙

  1. 추상화 수준의 계층적 구조
  2. 소프트웨어 컴포넌트의 크기 제한
  3. 인터페이스 크기 제한
    4. 각 컴포넌트의 높은 응집력
    5. 컴포넌트 간 낮은 결합력
  4. 적절한 스케쥴링
  5. 최소한의 인터럽트

Testing Capability Level

Test Maturity level

  • 레벨 1: performed, initial
    • 디버깅을 테스트로 인식
  • 레벨 2: managed
    • 디버깅과 테스트가 구분됨
  • 레벨3 : defined
    • sw 개발 생명주기 & 통합된 표준 테스트 프로세스가 정의됨
  • 레벨4 : quantitatively managed, measured
    • 단계별로 진행되는 v&v 작업을 통한 측정 데이터 수집으로 품질이 측정됨
  • 레벨5 : optimizing
    • 지속적인 개선
    • 결함예방 & 품질제어

Static Test (building product right?)

  • 코드 또는 작업 산출물을 실제로 실행하지 않고 평가.
  • 소스코드와 설계에서 결함을 발견(실행만 안 함)
  • 그래서 정적 테스트이다.
  • 작업 산출물의 일관성, 내부 품질을 향상시킴
  • verification 활동
  • 안전 최우선 시스템과 보안 테스트에서 중요
  • 장점
    1. 동적 테스트 실행전, sw 개발 수명 주기 초반 적용 - > 조기발견 가능 - >비용절감/기간단축
    2. 동적 테스트로 발견하기 어려운 결함 발견
      ex) 결함이 있는 경로로 드물게 실행되거나 접근하기 어려운 경우
    3. 요구사항 불일치, 애매모호함, 누락, 모순, 부정확, 중복 식별 --> 결함 예방 /장애 감소 -> 총 품질 비용 감소
    4. 리뷰에 참여하는 팀원 간의 의사소통 개선

review (사람/수동)

  • 산출물 리뷰
  • 이른 개발 단계에서 산출물로부터 결함을 효과적으로 발견
  • 결함이 필드 운용 단계에서 발생하는 것 방지

💥walkthrough (informal)

  • 작성자에 의한 진행 및 제어
  • 완성된 결과물이 아닌 중간산출물 리뷰 -> 조기결함 찾아냄
  • 표준이나 규정 준수 평가
  • 품질 개선을 위한 다른 방법 / 해결책 도출
  • 관리자는 참여 금지
  • 목적 : 시스템 이해, 결함 발견

💥inspections (formal)

  • 훈련된 리더에 의한 진행 및 제어 (구조적, 절자차적)
  • 단계
    1. 요구사항 분석 단계
    2. 설계 단계
    3. 구현 단계
    4. 테스트 단계
  • 목적 : 결함 발견

💥static analysis (도구)

  • 정적 테스트가 발견하기 쉬운 결함 유형
    • 요구사항 불일치, 애매모호함, 누락, 모순, 부정확
    • 설계 결함
    • 코드 결함, 코드 품질 관련 결함
    • 잘못된 인터페이스 명세
    • 보안 취약점
    • 대부분의 유지보수성 결함
    • 초기화되지 않은 변수
    • free 이후 사용
    • 0으로 나눔
    • double free
    • null pointer difference
    • unreachable call

💥sw 설계 품질 측정

sw 설계 metric

  • 복잡도 : V(G) = L-N+2 = 분기(두군데 이상으로 가는 노드) + 1
  • L: 그래프에서 EDGE의 수
  • N : NODE의 수

런타임 오류 가능성 검사

  • 모든 RTE를 검출하는 건 불가능
  • 오탐률(false alarm)과 미탐률이 낮아야

Review

dynamic test

Black-box test

  • 코드의 내용은 보지 않고 입력 값에 대한 실행 결과가 올바른 출력인지 테스트하기 때문에 블랙박스 테스트
  • 요구사항 등 명세서 기반으로 테스트 케이스 선정

💥equivalence partitioning(동치분할)

  • 여러 가능한 input에 대해 같은 output을 갖는 값들을 하나의 equivalence class로 구분하고 class별로 input 선택
  • 주관적 / 직관적
  • valid equivalence class : 유효한 입력 데이터
  • invalid equivalence class :유효하지 않은 입력데이터(입력되면 안되는)

💥boundary value analysis

  • 동치분할의 경계 부분에서 결함 발견될 확룔 높음
  • 따라서 경계값에서 테스트 데이터 선정
  • (-) : 주관적인 분할

decision table

  • 입력 condition의 모든 조합에 대한 시스템의 action을 고려해 테스트 케이스 도출

state-based testing

  • 테스트 대상 시스템의 behavior, 즉 이전의 이력을 반영하는 상태 및 그 변화를 잘 표현
  • 상태 / 전이 / 이벤트 /조건 / 액션 으로 구성
  • state / transition coverage

💥pair-wise test

  • 2개 요소의 모든 조합을 구성

White-box test

💥statement coverage

  • 실행된 구문이 전체 구문의 몇 %인지 측정

💥decision coverage (=branch coverage)

  • 실행된 결정 포인트 내의 전체 조건식이 최소한 참 한번, 거짓 한번의 값을 갖는지 측정
  • 결정 커버리지 = (테스트케이스에 의해 실행된 분기수) / (전체분기수) * 100

💥condition coverage

  • 전체 조건식의 결과와 관계없이 각 개별 조건식이 참 한번, 거짓 한번을 모두 갖도록 개별 조건식을 조합

condition/decision coverage

  • 전체 조건식의 결과가 참 한번 거짓 한번 & 각 개별조건식의 결과가 참 한번 거짓 한번

💥MC/DC coverage

  • 변경 조건/결정 커버리지

  • 각 개별조건식이 다른 개별 조건식에 무관하게 전체 조건식의 결과에 독립적으로 영향을 주도록 함

  • 개별 조건식 n개 -> 최소 테스트 케이스 수는 n+1개

0개의 댓글