테스트

테스트란

- 시험할 소프트웨어에 테스트 케이스를 주어 실행시킨 후 시스템의 동작이 예상한 대로 실행되는지 확인하는 것 

- SW 개발은 인간 중심의 활동이며 지적 활동

    - 오류가 발생하기 쉬움

    - 개발 과정에서의 2번 실수 - 결함 발생, 테스트 오류

- 결함을 낮추는 방법

    - 처음부터 결함 방지 : 인스펙션, 정적 분석

    - 유입된 결함을 식별하고 제거 : 테스트, 디버깅

# 검증 : 제품을 올바르게 구축하고 있는가

# 확인 : 올바를 제품을 만들고 있는가

# 버그 : 문제, 결함 또는 난이도를 나타내는 데 일반적으로 사용되는 용어

# 오류 : 개발자가 잘못하여 설계나 코딩에 실수한 것

# 결함 : 시스템 고장을 일으키게 한 오류의 결과

    코드 또는 문서에 오류가 있다고 선언된 것

# 고장 : 시스템이 원하는 작업을 수행할 수 없는 상황이나 현상

## 고장이 발견된다고 해서 반드시 결함으로 발겨노디지 않을 수 있음

## 오류가 있으나 고장을 일으키지 않을 수 있음

테스트 원리

- 테스트는 오류를 발견하려고 프로그램을 실행시키는 것

- 완벽한 테스트는 불가능

- 테스트는 창조적인 일이며 힘든 일

- 테스트는 오류 유입을 방지

- 테스트는 구현과 관계없는 독립된 팁에 의해 수행

 

테스트 작업 과정

1. 테스트에 의해 무엇이 점걸할 것인지 정함 (신뢰도, 기능 등)

2. 테스트 방법을 결정 (블랙박스, 화이트박스, 자동화 도구 등)

3. 테스트 케이스를 개발(실행 조건)

4. 테스트의 예상되는 올바른 결과 작성(올바른 판단 기준을 테스트)

5. 테스트 케이스로 실행(테스트 하니스 : 일부 기능 점검을 위한 변경 프로그램)

테스트 케이스

- 결함을 잘 드러내는 좋은 테스트 케이스를 찾는 것이 중요

- 결함을 검사할 수 있는 입력 필요

- 시험 조건, 테스트 데이터, 예상 결과 포함

- 테스트 케이스 명세서

블랙박스 테스트

- 내부 경로에 대한 지식을 보지 않고 테스트 대상의 기능이나 성능을 테스트

- SW 입출력에 중점 - 요구 사항 및 사양 기반

- 장점 : 

    - 기술적 배경 필요 X (사용자 입장)

    - 테스트와 개발자 독립적으로 작업

    - 크고 복잡한 프로그램에 효과적

- 단점 :

    - 기술적 지식 없으면 테스트할 시나리오 가능한 테스트 조건 무시

    - 모든 입출력 테스트 완료가 쉽지 않음

- 동등 분할 기법:

    - 동등 클래스 : 시스템의 동작이 같을 것으로 예상되는 입력들 그룹으로 구성 

    예 ) age <= 17, age >= 61, 18 <=age<=60

- 경곗값 분석 : 

    - 입력값의 경계선에 중점을 두는 테스트 방법

    - 동치 클래스의 경계에서 문제를 발생하는 특수한 값이 존재

    - 동치 클래스의 경계에 있는 값을 테스트 입력으로 선택

    예) 하나의 입력값 X에 대한 테스트 케이스 : 조건 min<= X <= max, 케이스 min-1, min,min + 1, max-1, max, max+1

- 원인과 결과 그래프

    - 입력 조건의 조합을 체계적으로 선택하는 테스트 기법

    - 노드와 기호로 표시

    - 노트 : 원인(입력 조건), 결과(출력 조건)

    - 기호 : ^(and), v(or), ~(not)

 

- 결정 테이블

    - 원인 결과 그래프로부터 테스트 케이스를 만들 때 사용

    - 각각의 결과들에 대해 조건의 조합을 표에 나열

화이트 박스 테스트

- 모듈의 논리적인 구조를 체계적으로 점검 ; 구조적 테스트

- 테스트 수행 과정

1. 원시 코드를 통해 애플리케이션의 구조를 이해 - 논리 흐름도

2. 검증 기준(커버리지)을 정함

3. 테스트 경로와 선택 조건 탐색

4. 각 경로를 구동시키는 테스트 데이터를 준비

5. 프로그램 수행 결과 비교

 

# 논리 흐름도 : 모듈 내의 제어 흐름을 간선으로 표시한 그래프 

검증 기준(test coverage)

- 프로그램의 테스트 커버 기준 결정

    - 문장 커버리지 : 각 라인이 적어도 한 번 실행되는지를 검증

    - 분기 커버리지 : IF문에는 T/F 두 가지 분기

    - 경로 커버리지 : 모든 실행 경로를 테스트 하는 기준

        경로가 복잡한 프로그램 테스트 용이

# 경로 커버리지 : 최대 커버리지를 보장 : 2개의 분기

- 4가지 테스트 케이스가 필요

- 기본 경로 테스트

    - 싸이클로메틱 복잡도(CC) 개수만큼 테스트 케이스 도출

    - 메케이브가 정의한 메트릭

    - 원시 코드의 복잡도를 정량적으로 평가

    - 얼마나 많은 논리적인 경로를 가지고 있는지 계산

    - 순환 복잡도 계산 공식

- 독립적 경로 정의

    - 순환 복잡도가 3이므로 3개의 경로에 해당하는 테스트 케이스 생성

     (1): 1 2 3 8 ,(2): 1 2 4 5 6 8, (3): 1 2 4 5 7 8

 

- 상태 기반 테스트

    - 같은 입력에 대해 시간에 따라 상태 값이 달라 다른 동작 결과를 출력하는 시스템에 대해 테스트 케이스를 선택하는 방법

    - 상태를 저장하는 소프트웨어는 상테 머신으로 모델링

- 상테 모델 : 무엇이 상태 변화를 일으키는지 이벤트에 대한 반응으로 어떤 액션을 취하는지 나타냄

- 상태 모델 구성 요소 :

    - 상태 : 시스템의 과거 입력에 대한 영향을 표시

    - 트랜지션 : 이벤트에 대한 반응으로 시스템이 하나의 상태에서 다른 상태로 어떻게 변해가는지를 나타냄

    - 이벤트 : 시스템에 대한 입력

    - 액션 : 이벤트에 대한 출력

- 상태 기반 테스트 케이스

    - 상태와 트렌지션에 집중

    - 상태 모델 예시 (예금 계정)

통합 테스트

- 모듈의 인터페이스 결합을 테스트

- 여러 개발 팀에서 개발한 각각의 단위 모듈을 대상

- 모듈 - 모듈 간의 결합을 테스트

- 용어 : 

    - 드라이버 : 시험 대상 모듈을 호출하는 간이 SW(상위 모듈 역할)

    - 스텁 : 시험 대상 모듈이 호출하는 또 다른 모듈(하위 모듈 역할)

- 빅뱅 통합 : 한 번에 모든 모듈을 모아 통합

    - 장점 : 

        일정에 대한 관리 편함

        통합을 위하여 스텁을 구성할 필요가 없음

    - 단점 : 

        오류의 위치와 원인을 찾기 어려움

        단위 테스트에 많은 시간과 노력이 듦

            - 준비해야 할 드라이버/스텁 수가 많음

        개발 진도를 예측하기 어려움

- 하향식 통합(top-down) : 시스템 구조상 최상위에 있는 모듈부터 통합

    - 장점 :

        중요한 모듈의 인터페이스를 조기에 테스트

        스텁을 이용하여 시스템 모습을 일찍 구현 가능

        개발자 입장에서 용이

    - 단점 : 

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

        테스트 케이스 작성 및 실행이 어려움

    - 중요 기능이 마지막에 구현되는 것이 특징

- 상향식 통합(bottom-up)

    - 시스템 구조상 최하위에 있는 모듈부터 통합

    - 장점 : 

        - 점증적 통합 방식

            오류 발견이 쉬움

            하드웨어 사용 분산

        - 하위층 모듈을 상위층보다 더 많이 테스트

    - 단점 : 

        초기에 시스템의 뼈대가 갖추어지지 않음

        상위층의 중요한 인터페이스가 마지막에 가서야확인 가능

        의뢰자에게 시스템을 시험해 볼 기회를 충분히 제공하지 못함

- 연쇄식 통합(threads)

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

        - 입력, 출력

        - 어느 정도의 기본 기능을 수행하는 모듈

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

    - 장점

        - 초기에 시스템의 골격이 형성 - 사용자 의견을 빨리 확인 가능

        - 시스템을 나누어 개발하기 쉬움

    - 단점

        - 스레드의 구성이 복잡해짐

시스템 테스트

- 컴포넌트 통합 후 수행하는 테스트 기법

- 전체 시스템의 기능 요구와 비기능 요구를 만족하는지 확인

- 기능 테스트 : 

    - 기능적 요구와 시스템의 차이를 발견하기 위한 테스트

    - 사용자와 관련되어 있으며 오류를 유발할 가능성이 많은 테스트를 선정

    - 사용사례 모델을 검토하고 오류를 일으킬만한 유스케이스 인스턴스를 찾아냄

    - 테스트 케이스

        - 일반적인 사례 : 티켓 구매

        - 예외적인 사례 : 시간 초과, 잔돈 없음, 고장, 취소

- 성능 테스트 : 시스템의 여러 측면을 체크하기 위한 목적

    - 작업 부하 : 시스템이 처리하고 생성하는 작업의 양

    - 처리량: 트랜젝션의 수, 시간 당 처리하는 메일 수

    - 반응 시간 : 시스템 요구를 처리하는데 걸리는 총 시간

    - 효율성 : 주어진 작업을 처리하기 위한 CPU시간과 메모리 같은 자원의 양의 비율

        - 자원 효율성 : 시스템에 의해 사용되는 자원의 비율을 측정

- 성능 테스트 방법 : 

    - 스트레스 테스트 : 시스템 처리능력의 몇 배의 작업 부하를 처리하고 견딜 수 있는지 측정

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

    - 보안 테스트 : 시스템의 보안 취약점을 찾아내려는 목적

    - UI 테스트 : 기능, 성능, 보안 테스트와 목적이 다름 : 인간 공학적인 목적

        - 보고 느끼는 UI에 대한 결함

        - 데이터 입력과 출력 디스플레이에 대한 결함

        - 엑터 - 시스템 사이의 동작 결함

        - 오류 처리에 대한 결함

        - 문서와 도움말에 대한 결함

인수 테스트

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

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

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

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

- 인수 테스트 유형

    - 알파 테스트 : 선택된 사용자가 개발 환경에서 시험하는 것

    - 베타 테스트 : 선택된 사용자가 외부 환경인 고객의 사용 환경에서 시험하는 것(필드 테스트)