• 소프트웨어 개발은 인간 중심의 지적 활동이라 오류가 발생하기 쉬움
• 결함을 낮추는 방법
  • 방지: 인스펙션, 정적 분석
  • 식별/제거: 테스트, 디버깅
• 테스트 정의: 테스트 케이스로 소프트웨어를 실행시킨 후 예상대로 동작하는지 확인

---

검증(Verification) vs 확인(Validation)

• 검증(Verification): “제품을 올바르게 구축하고 있는가?” → 과정
• 확인(Validation): “올바른 제품을 만들고 있는가?” → 결과
  

---

1. 테스트 기초

1.1 버그, 오류, 결함, 고장

• 버그(Bug): 문제/결함/난이도를 가리키는 일반 용어
• 오류(Error): 개발자가 설계/코딩에서 실수한 것
• 결함(Fault/Defect): 오류의 결과로 시스템 고장을 유발하는 상태(코드/문서의 오류 선언)
• 고장(Failure): 시스템이 원하는 작업을 수행할 수 없는 현상

1.2 테스트 원리

• 테스트는 오류를 발견하려고 프로그램을 실행시키는 것이다
• 완벽한 테스트는 불가능하다
• 테스트는 창조적이고 힘든 일이다
• 테스트는 오류의 유입을 방지할 수 있다
• 테스트는 구현과 관계없는 독립된 팀이 수행되어야 한다

  원래는 구현과 관련없는 QA엔지니어가 와서 한다. 즉, 선입견 없이 테스트한다..

1.3 테스트 작업 과정

1. 테스트로 무엇을 점검할지 정함
2. 테스트 방법 결정
3. 테스트 케이스 개발
4. 예상되는 올바른 결과 작성
5. 테스트 케이스로 실행

1.4 테스트 단계

• 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트
• 추가로 리그레션(Regression) 테스트가 반복적으로 수행됨
• 리그레션 테스트는 시스템이 설치된 후 유지보수 단계에서 이루어지는 테스트 작업
  • 수정이 이루어진 부분과 그에 의한 영향을 시험해보는 작업으로 구성

개발자는 단위테스트는 해야한다.
유닛 = 함수, 클래스, 컴포넌트 등등..

1.5 테스트 케이스(Test Case)

• 결함을 검사할 수 있는 입력
• 구성: 시험조건 + 테스트 데이터 + 예상 결과
• 테스트 케이스 명세서 형태로 관리
  

---

2. 블랙박스 테스트(Black-box)

• 내부 경로 지식 없이 기능/성능을 테스트
  • 요구사항/사양 기반
    

장점

단점

2.1 동등 분할(Equivalence Partitioning)

• 시스템 동작이 같을 것으로 예상되는 입력들의 구성을 동등 클래스로 분류
• 예: AGE: ≤ 17 / 18~60 / ≥ 61

2.2 경곗값 분석(Boundary Value Analysis)

• 동치 클래스 경계에서 문제가 잘 발생하는 특수 값 존재
• 경계값 중심으로 테스트 입력 선택(효율 높음)
• 예: min-1, min, min+1, 중간값,max-1, max, max+1
• 변수 개수 n이면 → 6n+1개의 케이스!

2.3 원인-결과 그래프(Cause-Effect Graph)

• 입력 조건 조합을 체계적으로 선택하는 기법
• 노드와 기호로 표시
  - 노드: 원인(입력조건), 결과(출력조건)
  - 기호: ∧(and), ∨(or), ~(not)
  

결정 테이블(Decision Table)

• 결과별로 조건 조합을 나열하는 방식
• 표기: x(don’t care), 0(false), 1(true)
  

---

3. 화이트박스 테스트(White-box)

• 모듈의 논리 구조를 체계적으로 점검하는 구조적 테스트

테스트 과정

1. 원시코드로 구조 이해(논리 흐름도)
2. 검증 기준(커버리지) 정함
3. 각 경로를 구동시키는 테스트 데이터 준비

3.1 논리 흐름의 표현

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

3.2 검증 기준

검증 기준: 테스트 데이터를 선택하기 위하여, 테스트 실행이 프로그램의 어떤 기준을 커버하는지 먼저 결정하여 한다.

문장 커버리지

• 각 라인이 1회 이상 실행되는지 검증

분기 커버리지

• IF의 True/False 각 분기가 한 번 이상 실행되는지 확인

경로 커버리지

• 모든 실행 경로 테스트하는 기준

• TestCase_01:
  A=50,B=60
  (C>100: true, A>45: true)

• TestCase_02:
  A=55,B=40
  (C>100: false, A>45: true)

• TestCase_03:
  A=40,B=65
  (C>100: true, A>45: false)

• TestCase_04:
  A=30, B=30
  (C>100: false, A>45: false)
  

  경로 커버리지

루프 테스트

---

4. 상태 기반 테스트(State-based)

• state-less system:
  같은 입력에 대해 같은 동작을 보이며 동일한 결과를 생성하는 시스템
  - 배치 처리 시스템
  - 계산 중심 시스템
  - 하드웨어로 구성된 회로
• 대부분의 시스템의 동작이 상태(state)에 의해 좌우됨 → statefull system
• 상태 기반 테스팅은 이러한 상태 변화에 따른 동작을 검증하는 테스트 기법이다.

4.1 상태머신

• 상태 모델 구성요소
  - 상태(state): 과거 입력의 영향을 반영
  - 트랜지션(transition): 이벤트에 따른 상태 변화
  - 이벤트(event): 시스템에 대한 입력
  - 액션(action): 이벤트에 대한 출력
  

  예금 계좌의 상태 모델

4.2 테스트 케이스 선택

---

5. 통합 테스트(Integration Test)

• 모듈 간 인터페이스 결합을 테스트
  • 여러 팀이 개발한 단위 모듈을 대상으로 모듈-모듈 결합을 확인
• 모듈의 결합 순서에 따라 방법이 다름
  • 빅뱅(big-bang)
  • 하향식(top-down)
  • 상향식(bottom-up)
  • 연쇄식(threads)

테스트 드라이버와 스텁

• 드라이버(Driver): 시험 대상 모듈을 호출하는 간이 SW → 상향식 통합
• 스텁(Stub): 시험 대상 모듈이 호출하는 또 다른 모듈을 대신하는 간이 SW → 하향식 통합

5.1 빅뱅 통합

• 모든 모듈을 한 번에 모아 통합

장점

• 일정 관리 편함
• 스텁 불필요

단점

• 오류 위치/원인 찾기 어려움
• 단위 테스트 부담 큼
• 드라이버/스텁 수 많음
• 진도 예측 어려움
  

5.2 하향식 통합

• 최상위 모듈부터 통합
• 최상위 층의 모듈에 대한 들아ㅣ버와 스텁을 작성한 후 통과되면 스텁을 대상 모듈로 교체한다.
• 이때 테스트 대상 모듈이 호출하는 모듈은 스텁을 작성하여 통합 테스트한다.

장점

• 중요한 인터페이스 조기 테스트
• 스텁으로 시스템 모습 조기 구현
• 개발자 입장에서 용이

단점

• 입출력 모듈이 하위에 있어 테스트 케이스 작성/실행 어려움
• 중요 기능이 마지막에 구현됨
  

5.3 상향식 통합

• 최하위 모듈부터 통합
• 스텁이 필요없고 드라이버가 필요하다.
• 최하층을 구동하는 드라이버를 준비하여 통합한 후, 통과되면 드라이버 대신에 개발된 모듈로 대체한 후 이를 구동하는 드라이버로 통합시켜 나간다.

장점

• 점증적 통합
  • 오류 발견 쉬움
  • 하드웨어 사용 분산
• 하위층을 더 많이 테스트

단점

• 초기에 시스템 뼈대가 없음
• 상위층 중요한 인터페이스 확인이 늦음
• 의뢰자에게 시험 기회 제공 어려움
  

5.4 연쇄식 통합(Threads)

• 특정 기능을 수행하는 최소 단위(thread)부터 통합(입력/출력/기본 기능 모듈)
• 상대적으로 중요한 모듈부터 개발

장점

• 초기에 시스템 골격 형성
  • 사용자 의견을 빨리 확인
• 시스템을 나누어 개발하기 쉬움

단점

• 스레드의 구성이 복잡해질 수 있음
  • 드라이버와 스텁 작성에서 오류가 발생할 수 있음

---

6. 시스템 및 인수 테스트

시스템 테스트(System Test)

• 컴포넌트 통합 후 수행하는 테스트 기법
• 종류
  • 기능 테스트
  • 성능 테스트
  • 보안 테스트
  • 사용성(UI) 테스트
  • 인수 테스트
  • 설치 테스트

6.1 기능 테스트

• 기능 요구와 시스템의 차이를 발견하기 위한 테스트
• 사용자와 관련되어 오류 유발 가능성이 많은 테스트를 선정
• 사용사례 모델 검토 후 오류 유발 가능 유스케이스 인스턴스 탐색
• 테스트 케이스: 일반 사례 + 예외 사례

기능 테스트 케이스 작성 과정

승차권 판매기 유스케이스와 티켓 구입을 위한 유스케이스

티켓 정상 구매 테스트 케이스

6.2 성능 테스트

• 시스템의 여러 측면을 테스트한다.
• workload(작업부하)
  • 시스템이 처리하고 생성하는 작업의 양
• throughput(처리량)
  • 트랜잭션의 수
  • 시간당 처리하는 메일 수
• response time(반응시간)
  • 시스템 요구를 처리하는데 걸리는 총 시간
• 효율성
  • 주어진 작업 처리를 위한 CPU시간과 메모리와 같은 작원의 양을 측정
• 자원 효율성
  • 시스템에 의하여 실제 사용되는 자원의 비율을 측정

스트레스 테스트

• 시스템 처리능력의 몇 배의 작업부하를 처리하고 견딜 수 있는지 측정
• 성능 테스트는 정상적인 사용 환경에서 시스템의 성능을 측정하는데 사용

시뮬레이션

• 성능 테스트를 위한 방법으로 시뮬레이션을 사용하기도 한다.

6.3 보안 테스트

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

정적 분석

침입 테스트

랜덤 테스트

6.4 UI 테스트

• 기능/성능/보안과 목적이 다름
  • 인간공학적 목적
• 테스트 목적
  • 보고 느끼는 UI에 대한 결함
  • 데이터 입력과 출력 디스플레이에 대한 결함
  • 액터-시스템 사이의 동작 결함
  • 오류 처리에 대한 결함
  • 문서와 도움말에 대한 결함

6.5 인수 테스트(Acceptance Test)

• 시스템을 당장 사용할 수 있도록 모든 준비가 되었는지 확인
• 개발자를 제외한 의뢰자 또는 대리인이 수행
• 요구분석서 기반, 실제 업무 절차대로 수행

알파 테스트와 베타 테스트

• 알파 테스트: 선택된 사용자가 개발 환경에서 시험
• 베타 테스트: 선택된 사용자가 외부 환경에서 시험(필드 테스트)

---