소프트웨어 공학 10(테스트)

• 테스트
  • 소프트웨어 개발은 인간 중심의 활동이며 지적 활동
  • 오류가 발생하기 쉬운 활동
  • 내가 만든 모듈이 잘 동작하는지 테스트
    
• 결함을 낮추는 방법
  • 방지: 인스펙션, 정적 분석
  • 식별하고 제거: 테스트, 디버깅
    
• 테스트
  • 시험할 소프트웨어에 테스트 케이스를 주어 실행시킨 후 시스템의 동작이 예상한 대로 실행되는지 확인하는 것
    ## 검증과 확인
• 검증(verification)
  • “제품을 올바르게 구축하고 있는가?”
    
• 확인(validation)
  • “올바른 제품을 만들고 있는가?”

테스트 기초

• 결함 (bug, fault, 실수)
  • lower level of a system
  • 문제, 결함 또는 난이도를 나타내는 데 일반적으로 사용되는 용어
  • working여부와 관계없이 잘못된 부분이 잠재되어있는 경우
    • 잠재된 잘못에 의해 차이가 발생
  • fault가 있어도 답이 제대로 나올 수 있음
• 오류 (error, 차이)
  • intermediate level of system
  • 결함으로부터 발생한 올바른 결과와의 차이
  • 수행결과과 정답결과가 차이가 있는 경우
• 고장 (failure)
  • full system level
  • 오류로부터 초래되는, 시스템이 원하는 작업을 수행할 수 없는 상황
  • 요구사항을 만족하지 못함
  • 사고, 시스템이 다운과 같은 case
    

테스트 작업 과정

1. 테스트에 의하여 무엇을 점검할 것인지 정한다

2. 테스트 방법을 결정한다.

3. 테스트 케이스를 개발한다.

4. 테스트의 예상되는 올바른 결과를 작성한다.

5. 테스트 케이스로 실행시킨다.

테스트 케이스

• 결함을검사할수있는입력
• 시험조건, 테스트 데이터, 예상 결과
• 테스트 케이스 명세서

블랙박스 테스트

• 내부경로에 대한 지식을 보지 않고 테스트 대상의 기능이나 성능을 테스트
  • 요구사항 및 명세에 기반
  • 기능테스팅 (functional testing)
• <=> 화이트박스 테스트
  • 내부에 대한 지식을 테스트하는 것
  • 단위 테스팅을 주로 화이트 박스 테스트를 진행

동치 클래스 분할 기법

• 동치 클래스 (equivalence class)
  • 시스템의 동작이 같을 것으로 예상되는 입력
  • 동치 클래스내 대표값(들)만을 가지고 테스팅 => 경계값 분석

a) AGE <= 17
b) AGE >= 61
c) 18 <= AGE <= 60

• 정상/비정상 분해

  • 정상적인 입력 범위를 대표하는 동치클래스
  • 비정상적인 입력 범위를 대표하는 동치클래스

• 입력데이터 값의 범위에 따라 다른 방법으로 처리되는 경우

  • 동작이 같은 것으로 예상되는 값들을 grouping
  • 예) 입력문자의 범위 => 3개 동치클래스: 일반문자, 숫자, 특수문자

• 하나의 ‘정상적' 동치클래스에 대하여 하나 이상의 비정상적인 동치클래스를 탐색

• 같은 출력결과를 내는 입력값을 탐색

  • 예) 투자 회수율 결정 프로그램의 경우 => 출력이 ‘흑자회수‘, ‘적자회수‘, ‘본전'에 대한 입력값을 구분

경계값 분석

• 동치 클래스의 경계에서 문제를 발생하는 특수한 값이 존재
• 동치 클래스 경계에 있는 값을 가진 테스트 케이스는 높은 효율을 가짐
  • 경계의 왼쪽에 하나, 오른쪽에 하나, 경계값 자체 하나
• 동치클래스의 경계에 있는 값을 테스트 입력으로 선택
  • <예> 하나의 입력 값 X에 대한 테스트 케이스
    • 입력값 조건: min ≤ X ≤ max
    • 케이스: min-1, min, min+1, max-1, max, max+1

• 입력값이 2개인 경우 한가지를 고정시키고 +1, 0, -1 테스트
• 이후 고정시켰었던 입력값을 +1, 0, -1 테스트(다른 하나는 고정)
  • 위 그림은 총 12개의 테스트 케이스

원인과 결과 그래프

• 입력 조건의 조합을 체계적으로 선택하는 테스트 기법
  • 어떤게 동작하기 위해 필요한 조건식을 포함한 그래프
  • $E_1$ 의 경우 ~$(C_1 ∨ C_2)$라면 동작
• 노드와 기호로 표시
• 노드: 원인(입력조건), 결과(출력 조건)
• 기호: ∧(and), ∨(or), ~(not)
  <예>

결정 테이블

• 각각의 결과들에 대하여 조건의 조합을 나열
• <예>
  • x: don’t care
  • 0: false
  • 1: true

화이트 박스 테스팅

• 모듈의 논리적인 구조를 체계적으로 점검 – 구조적 테스트
• 논리의 흐름(경로) 테스팅

• 테스트과정

1. 원시 코드를 통해 애플리케이션의 구조를 이해 – 논리흐름도 (logic-flow diagram)
2. 검증 기준 (커버리지)을 정한다.
3. 각 경로를 구동시키는 테스트 데이터를 준비

논리 흐름도 (Logic-flow Diagram)

• 모듈 내의 제어흐름을 간선으로 표시한 그래프
  • 노드: 모듈내의 모든 세그먼트
  • 간선: 제어 흐름

• if else의 경우 왼쪽으로가면 T(if), 오른쪽으로 가면 F(else)
• 조건문이 단일조건인 경우는 위와 같음

• 복합 조건문일 경우 분해를 해야함
• 위 그림
  • 1 : x>0
  • 2 : x<101
    • 1번이 틀리면 바로 빠져나옴
    • 2번은 1번이 맞다면 체크하는데 1번은 맞는데 2번은 틀리면 빠져나옴
    • 1, 2가 모두 만족 시 3으로 이동

• 1. 변수 선언(int low = 0; ~ int r = 1;)
• 2. low <= high
• 3. r == -1
     • 복합 조건
     • 이 2개가 만족하지 않는다면 바로 12번(return r;)
• 4. int mid
• 5. a[mid] > value
     • 조건문
     • 6. 조건문이 True(high = mid -1)
     • 7. 조건문이 False
          • else if 와 else로 또 조건문 분기
          • 조건문의 마무리 = 10번
• 11. while문의 끝부분

🔥로직 조건(조건문)에 집중해서 블럭화 해서 표현하기

테스트 커버리지

• 테스트를 어느 정도 완벽히 수행할 것인가의 기준

  • 모든 테스트를 다 수행하는 것은 어려움

• 노드 커버리지

  • 논리 흐름 그래프의 각 노드가 테스트 케이스에 의하여 적어도 한 번씩 방문되어야 하는 검증기준
    • 노드가 한번이라도 커버된 적이 있다면 마무리
  • 프로그램 문장 100% 커버

• 간선(분기) 커버리지

  • 논리 흐름 그래프의 각 간선이 테스트 케이스에 의하여 적어도 한 번씩 방문되어야 하는 검증기준
    • 각 조건(분기)에서 T, F를 커버해야함
  • 모든 분기점 테스트(Branch coverage)

• 기본경로 커버리지

  • 모든 기본 경로가 적어도 한 번씩 방문되어야 하는 검증기준
  • 간선 커버리지의 50%

• 모든경로 커버리지

  • 모든 가능한 경로를 적어도 한 번씩 테스트하는 검증기준
  • 현실적으로 불가능

기본 경로 테스팅

• 시작 노드에서 종료 노드까지의 서로 다른 경로로 cycle은 한번만 허용
• 독립적인 논리 흐름을 검사하는 테스트 케이스를 생성
  • (예) Remove 함수에 대한 논리흐름 그래프와 테스트 케이스
• 싸이클로매틱 복잡도가 2-3-4-9-10, 4-5-6-8, 5-6-7-8, 전체
  • 총 4개

싸이클로매틱 복잡도(Cyclomatic Complexity)

• 싸이클로매틱 복잡도
  • 원시 코드의 복잡도를 정량적으로 평가하는 방법
  • 기본경로의 개수의 기준
    • 기본 경로가 복잡도 만큼 생긴다는 것을 예측

• 싸이클로매틱 복잡도 계산 3가지 방법
  • Region 개수 +1 : 논리 흐름 그래프는 이차원 평면을 여러 영역으로 나누며, 이 중 폐쇄된 Region 개수에 1을 더한 값
  • Edge 개수 – Node 개수 + 2P (P: # of connected components)
  • 단일조건식(참과 거짓으로 판별되는 원자적 조건) 개수 +1 :

• 기본경로의 도출
  • CC = 3 이므로 기본경로의 개수는 최소 3
    • 경로 1: 1-2-3-8
    • 경로 2: 1-2-4-5-6-8
    • 경로 3: 1-2-4-5-7-8

• 첫 줄발은 가장 긴 것으로 잡기
• 바텀 업으로 가장 마지막에 나왔던 분기에서 부터 변경

+ 노드 커버리지 + 1-2-7-9는 없어도 됨

상태 기반 테스팅

• 같은 입력에 대해 같은 동작을 보이며 동일한 결과를 생성하는 시스템(state-less system)을 대상
  • 배치 처리 시스템
  • 계산 중심 시스템
  • 하드웨어로 구성된 회로

• 시스템의 동작은 시스템의 상태에 의해 좌우됨
  • 복잡하거나 무거운 시스템의 상태 변화도
  • 입력은 같은데 상태에 따라 출력이 달라지기 때문

• 상태 모델 구성요소
• 상태–시스템의과거입력에대한영향을표시
• 트랜지션 – 이벤트에 대한 반응으로 시스템이 하나의 상태에서 다른 상태로 어떻게 변해가는지를 나타냄  이벤트–시스템에대한입력
• 액션–이벤트에대한출력

검증 기준(coverage)

• 모든 트랜지션

  • 테스트 케이스 집합이 상태 그래프의 모든 트랜지션을 점검
  • 1번 state -> 1번 state 이동에 대한 test(화살표 하나하나 테스트)
  • 트랜지션 = edge

• 모든 트랜지션쌍

  • 테스트 케이스 집합이 모든 이웃 트랜지션의 쌍을 점검
  • 유입(incoming)과 방출(outgoing) 트랜지션 쌍을 의미
  • 한 노드에 들어온거 부터 나간것을 점검
  • 유입의 수 * 방출의 수 만큼 테스트

• 트랜지션 트리

  • 테스트 케이스 집합이 모든 단순경로를 만족시키는 기준
  • 기본경로 커버리지랑 동일(복잡)

🔥 단위(모듈) 테스트 -> 통합 테스트 -> 시스템 테스트

• 화이트 박스는 모듈에서만 사용
• 블랙 박스는 모든 테스트에서 사용 가능

통합 테스트

• 모듈의 인터페이스 결합을 테스트
  • 여러 개발팀에서 개발한 각각의 단위 모듈을 대상
  • 모듈-모듈 간의 결합을 테스트

• 모듈의 결합 순서에 따라 방법이 다름
  • 빅뱅(big-bang)
  • 하향식(top-down)
  • 상향식(bottom-up)
  • 연쇄식(threads)
    • 하향, 상향, 연쇄 암기

• 용어(중요)
  • 드라이버: 시험 대상 모듈을 호출하는 간이 소프트웨어
    • A -> B 호출
      • B를 테스트하기 위해 호출해주는 모듈 A
  • 스텁:시험 대상 모듈이 호출하는 또 다른 모듈
    • A -> B 호출
      • A가 호출될때 호출되는 모듈 B(통합되는 과정에서 아직 합쳐지진 못함)

하향식 통합

• 시스템 구조상 최상위에 있는 모듈부터 통합
  • 사람에게 가까운 부분(ui)을 상위 모듈, 사람에게 먼 부분(db, os)을 하위 모듈
• 제일 위(대부분 ui)가 driver가되어 아래 모듈(stub)을 호출하는 방식

• 장점
  • 중요한 모듈의 인터페이스를 조기에 테스트
  • 스텁을 이용하여 시스템 모습을 일찍 구현가능
  • 개발자 입장에서 용이함

• 단점
  • 입출력 모듈이 상대적으로 하위에 있음

• 테스트 케이스 작성 및 실행이 어려움
• 중요 기능이 마지막에 구현됨
  • driver -> test하려는 모듈 -> stub

상향식 통합

• 시스템 구조상 최하위에 있는 모듈부터 통합
• 장점
  • 점증적 통합 방식
    • 오류 발견이 쉬움
    • 하드웨어 사용 분산
  • 하위층 모듈을 상위층보다 더 많이 테스트
• 단점
  • 초기에 시스템의 뼈대가 갖추어 지지 않음
  • 상위층의 중요한 인터페이스가 마지막에 가서야 확인 가능
  • 의뢰자에게 시스템을 시험해 볼 기회를 충분히 제공하지 못함

연쇄식 통합

• 특정 기능을 수행하는 모듈의 최소 단위(thread)로 부터 시작

  • 입력, 출력
  • 어느 정도의 기본 기능을 수행하는 모듈

• 상대적으로 중요한 모듈부터 개발

  • 상향식과 하향식의 절충안

• 장점

  • 초기에 시스템의 골격이 형성
  • 사용자 의견을 빨리 확인 가능
  • 시스템을 나누어 개발 하기 쉽다

시스템 및 인수 테스팅

• 컴포넌트 통합 후 수행하는 테스트 기법
• 요구사항, 요구분석 내용과 일치하는지 확인
  • 요구사항
    • 기능적 요구사항
    • 비기능적 요구사항

기능 테스트

• 요구사항 중 기능적 요구사항 테스팅
• 잘 작동하는지 테스트
• use case를 만족하는지 테스트

성능 테스트, 보안 테스트, 사용성 테스트

• 요구사항 중 비기능적 요구사항을 테스팅
• 주로 성능 테스트를 많이함

성능 테스트

• 작업 부하(workload)
  • 시스템이 처리하고 생성하는 작업의 양
• 처리량(throughput)
  • 트랜잭션의수
  • 시간당 처리하는 메일 수
• 반응 시간(response time)
  • 시스템 요구를 처리하는데 걸리는 총 시간
• 효율성
  • 주어진 작업 처리를 위한 CPU시간과 메모리 같은 자원의 량의 비율
• 자원효율성
  • cpu 메모리 등등의 효율성

테스트 방법

• 스트레스 테스트

  • 시스템 처리능력의 몇 배의 작업부하를 처리하고 견딜 수 있는지 측정
  • 강도를 높여 어느 강도까지 견디는지 테스트

• 성능테스트

  • 정상적인 사용 환경에서 시스템의 성능을 측정하는데 사용
  • 시뮬레이션을 이용한 테스팅 가능

• 보안테스트

  • 시스템의 보안 취약점을 찾아내려는 목적

UI 테스트

• ui 테스트

인수 테스트

• 시스템을 당장 사용할수 있도록 모든 준비가되어 있는지 확인 개

• 발자를 제외한 의뢰자 또는 대리인이 테스트 수행

• 시스템 요구분석서를 기반으로 한 테스트 수행

• 실제업무절차를 따라 테스트 수행

• 테스트유형

  • 알파테스트
    • 선택된 사용자가 개발 환경에서 시험하는 것
    • 넘기기 직전에 하는 것
  • 베타테스트
    • 선택된 사용자가 외부 환경에서 시험하는 것(필드 테스트)