소프트웨어 공학 - Chpater 8. 소프트웨어 테스팅

소프트웨어 공학을 공부하면서 만든 정리 자료다.

기준은 한티 미디어 소프트웨어 공학 제 10판이다.

• 소프트웨어 테스팅 목차
  • 개발 테스팅
  • 테스트 주도 개발
  • 릴리스 테스팅
  • 사용자 테스팅

Program Testing

• 테스팅의 목적
  • 프로그램이 의도대로 수행되는지 보여주기 위해서 (검증 테스팅)
  • 프로그램을 사용하기 전에 결함을 발견하기 위해서 (결함 테스팅)
• 검증 테스팅
  • 시스템의 예상된 사용을 반영하는 테스트 케이스 집합을 이용하여 시스템이 정확하게 수행되는 것을 기대한다.
• 결함 테스팅
  • 결함을 드러낼 수 있도록 설계
  • 결함 테스팅의 테스트 케이스는 의도적으로 모호할 수 있으며, 시스템이 정상적으로 어떻게 사용되는지를 반영할 필요가 없다
• 프로그램 테스팅 (Program Testing)
  • (인위적인) 데이터로 이용하여 프로그램을 실행시키고 실행 결과를 점검
• 테스팅의 한계
  • 소프트웨어의 결함이 없다는 것이나 모든 환경에서 명세대로 동작할 것이라는 것은 보여줄 수는 없다.
  • 테스팅은 오류의 존재를 밝힐 수 있지만 오류가 없음을 보일 수는 없다.

Program Testing Goals

• 검증 테스팅 (Validation Testing)
  • 소프트웨어가 고객의 요구사항에 맞는지 보여준다.
  • 요구사항 마다 적어도 하나의 테스트가 있어야 하면 시스템이 정확하게 수행되는 것을 기대한다.
• 결함 테스팅 (Defect Testing)
  • 소프트웨어의 결함(버그)에 의해 제대로 동작하지 않는 경우를 찾는다.
  • 테스트 케이스 (Test Case) 는 결함(Defect)를 드러낼 수 있도록 설계된다.

Verification vs Validation

• 소프트웨어 검증 및 확인 (V&V) 프로세스
  • Verification & Validation
• 확인 (Validation)
  • 올바른 제품을 만들고 있는가?
  • 소프트웨어가 고객의 기대에 맞는지 보여준다
  • 명세를 따르는 것을 넘어 고객이 기대하는 것을 제공하는지 확인
• 검증 (Verfication)
  • 제품을 올바르게 만들고 있는가?
  • 소프트웨어가 기능적 / 비기능적 요구사항 명세에 맞는지 점검 (Spec 이 일치한지)
• 검증과 확인 프로세스의 목표
  • 소프트웨어 시스템이 “목적에 맞는다” 는 확신을 세우는 것
  • 시스템이 의도된 사용을 위해 충분히 괜찮아야 한다는 것을 의미
  • 요구되는 확신의 수준은 시스템의 목적, 사용자의 기대, 시스템의 현재 시장 환경에 좌우
    • 소프트웨어 목적 : 소프트웨어의 중요가 클수록 신뢰성 있는 것이 더 중요해짐
    • 사용자 기대 : 초기에 비해 업데이트 되는 후기 버전에 대한 신뢰성이 더 높음
    • 시장 환경 : 경쟁 제품, 지불 가격, 일정 등에 고려되여 신뢰성 수준에 영향

Inspections and Testing

• 소프트웨어 인스펙션(검사)
  • 요구사항, 설계, 소스코드를 분석하고 검사하여 문제를 찾는 것
  • 프로그램을 실행시키지 않는 정적(Static) V&V 기술
  • 주로 소스코드를 대상으로 하지만 소프트웨어의 어떤 표현이라도 검사 가능
• 소프트웨어 테스팅
  • 프로그램을 실행시켜 동작을 관찰하는 동적 (Dynamic) V&V 기술

A model of the software Testing Process

Testing Process

• 테스트 케이스 (Test Case)
  • 무엇을 테스트 하는지, 테스트 입력 : 예상출력
  • 테스트 데이터 : 시스템을 테스트하기 위한 입력
  • 테스트 결과 : 테스트 데이터 입력에 따른 출력
• 인스펙션의 장점
  • 테스팅 중에는 오류가 다른 오류들을 가릴 수 있다(Mask). 그러나 인스펙션은 정적 프로세스 이므로 오류간의 상호작용과 무관하여, 인스펙션은 한번에 여러 오류를 발견할 수 있다.
  • 추가적인 비용 없이 시스템의 불완전한 버전을 검사할 수 있다. 불완전한 프로그램을 테스트 하려면 추가 코드가 필요하다.
  • 인스펙션은 결함을 찾는 것뿐만 아니라 표준 준수, 이식성 (Portability), 유지 보수성 (Maintainability) 등 프로그램의 폭넓은 품질 속성을 검토할 수 있다.
• 인스펙션(정적)과 테스팅(동적)은 상호 보완적이다.
  • 인스펙션이 결함을 발견하는데 테스팅보다 효과적이다.
  • 그러나 인스펙션이 테스팅을 대체할 수는 없다.
  • 시스템 컴포넌트 간 상호작용, 타이밍, 시스템 성능 문제 때문에 발생하는 결함을 발견하는데에는 인스펙션은 적합하지 않다

Stages of Testing

• 전형적인 상용 소프트웨어 시스템의 테스팅 3단계
  • 개발 테스팅 (Development Testing)
    • 버그와 결함을 찾기 위해 개발 중에 테스팅
    • 시스템 설계자와 프로그래머가 수행
  • 릴리스 테스팅 (Release Testing)
    • 시스템이 이해당사자들의 요구사항에 만족되는지 시스템의 완성된 버전을 테스팅
    • 별도의 테스팅 팀이 수행 (사용자에게 릴리스 하기 전)
  • 사용자 테스팅 (User Testing)
    • 시스템의 인수 여부를 결정
    • (잠재적) 사용자들이 자신의 환경에서 시스템을 테스팅
• 테스트 계획 수립
  • 테스팅 프로세스의 모든 활동들의 계획을 세우고 자원을 배분하는 것과 관련
  • 테스팅 프로세스를 정의하고 인력 및 시간 가용성을 고려하는 것을 포함

Test Automation 테스트 자동화

• 자동화된 테스팅
  • 개발 중인 시스템이 테스트 될 때마다 실행되는 프로그램
  • 테스트 주도 개발 (TDD)을 위해서는 자동화된 테스팅이 필수
• 회귀 테스팅 (Regression Testing)
  • 프로그램의 변경으로 새로운 버그가 생기지 않았는지 점검하기 위하여 이전에 수행한 테스트를 다시 실행

개발 테스팅의 분류

• 단위 (Unit) 테스팅
  • 모듈의 기능을 테스트
  • 테스트 드라이버 (Test Driver) / 스텁 (Stub) 필요
• 통합 (Integration) 테스팅
  • 모듈 간의 상호작용을 테스트
  • 모듈 통합 방법
    • 빅뱅 테스트
    • 하향식 통함
    • 상향식 통합
• 시스템 (System) 테스팅
  • 시스템의 기능을 테스트
  • 요구사항이 만족되는지 테스트 GoF Design Patterns

Catalog of Design Patterns

Testing Process

• GoF 패턴의 3가지 유형
  • Creational Patterns
    • 객체를 생성하는데 관련된 패턴들
    • 객체가 생성되는 과정에 유연성을 높이고 코드의 유지가 쉬워진다.
  • Structural Patterns
    • 프로그램의 구조에 관련된 패턴들
    • 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 많이 활용될 수 있는 패턴들
  • Behavioral Patterns
    • 반복적으로 사용되는 객체들의 상호작용을 패턴화 해 놓은 것

Catalog of Design Patterns

• Composite
  • 부분-전체 구조 (Part-whole-Hierarchy)를 표현하기 위하여 객체들을 트리구조로 구성
  • 이를 통하여 사용자가 개별적 객체나 복합적 객체를 동일하게 다룰 수 있다.
• Decorator
  • 한 객체에 대해서 동적으로 책임사항들 (Responsibilities)을 덧붙일 수 있다.
  • 이를 통하여 기능 확장을 위한 서브클래싱 (Subclassing) 과 같은 효과를 거둘 수 있다.
• Facade
  • 서브 시스템 안의 여러 인터페이스들에 대하여 통합된 인터페이스를 제공
  • 제공되는 인터페이스를 통하여 서브시스템의 기능을 쉽게 사용할 수 있다.
• Factory Method
  • 생성되는 객체에 대한 결정을 서브클래스가 할 수 있도록 객체 생성 인터페이스를 제공
• Flyweight
  • 수많은 작은 객체들에 대해서 효율적인 공유 기능을 제공
• Interpreter
  • 특정 언어에 관한 문법 표현을 정의
  • 정의된 표현은 해당 언어의 문장을 해석하는데 이용된다.
• Iterator
  • 자료구조의 내부적 표현과 상관없이 저장되어 있는 자료요소들을 순차적으로 접근할 수 있는 방법을 제공
• Mediator
  • 객체들의 상호작용을 캡슐화하는 객체를 정의
  • 이를 통하여 객체들 간의 커플링을 줄일 수 있으며, 각 상호 작용을 독립적으로 변경할 수 있다.
• Memento
  • 객체 지향의 캡슐화 원칙을 어기지 않으면서, 객체의 내부 상태 정보들을 찾아내어 외부 객체화함
  • 객체화된 상태 정보는 원 객체의 상태 복구에 이용할 수 있다.
• Observer
  • 한 객체의 상태에 변화가 일어나면 해당 객체의 상태에 관심 있는 모든 다른 객체들에게 자동으로 변화가 발생한 사실을 알려준다.
  • 즉 객체들간의 일-대-다 (One-to-many) 관계를 표현
• Prototype
  • 원형 (Prototypical) 객체를 복사하는 방식으로 객체를 생성
  • 이를 통하여 생성하는 객체의 종류를 동적으로 지정할 수 있다.
• Proxy
  • 특정 객체에 대한 접근을 관리하기 위하여 해당 객체의 대리자 (Surrogate)를 만듦
• Singleton
  • 특정 클래스의 객체가 단 하나만 생성되도록 보장하며, 그 객체에 대한 전역 접근이 가능하도록 해준다.
• State
  • 객체의 상태정보가 변함에 따라 마치 객체의 클래스가 변하는 것처럼 객체의 행동도 바뀌도록 해준다
• Strategy
  • 알고리즘을 객체화하여 여러 알고리즘을 동적으로 교체 가능하도록 한다.
  • 알고리즘을 이용하는 클라이언트 코드와는 상관없이 알고리즘을 다양하게 바꿀 수 있음
• Template Method
  • 연산에 있어서 전체 알고리즘의 윤곽만 기술한 다음 알고리즘의 특정 부분의 구현을 서브클래스로 맡김
  • 이를 통하여 전체 알고리즘의 구조를 변화시키지 않으면서 서브클래스가 알고리즘의 특정 부분을 쉽게 변경시킬 수 있다.
• Visitor
  • 자료구조 내에 있는 객체 요소들에게 특정 연산을 수행하고자 원할 때 이용
  • Visitor 는 연산 수행의 대상이 되는 객체들의 클래스를 바꾸지 않고도 새로운 연산을 추가할 수 있도록 도와준다.

개발 테스팅

• 개발 테스팅
  • 시스템을 개발하는 팀에 의해 수행되는 모든 테스팅 활동을 포함
• 개발 테스팅의 3단계
  • 단위 테스팅
    • 개별 프로그램 단위 또는 객체 클래스가 테스트
    • 객체나 메서드의 기능을 테스트 하는 것에 집중
  • 컴포넌트 테스팅
    • 여러 개별 단위가 복합 컴포넌트를 생성하기 위하여 통합
    • 컴포넌트 기능에 접근하는 컴포넌트 인터페이스를 테스트하는 것에 집중
  • 시스템 테스팅
    • 시스템의 어느 정도 또는 모든 컴포넌트들을 통합하여 시스템이 전체로서 테스트
    • 컴포넌트의 상호 작용을 테스트하는 것에 집중
• 개발 테스팅
  • 테스팅의 목표가 소프트웨어의 버그를 발견하는 것에 있는 결함 테스팅 프로세스를 지칭
  • 문제를 찾아 고치기 위해 프로그램을 변경하는 프로세스인 디버깅과 중첩된다

Unit Testing

• 단위 테스팅에서는 개별적인 컴포넌트를 테스트
  • 함수, 메서드. 클래스 등의 기능을 테스트
  • 메서드 또는 객체 클래스와 같은 프로그램 컴포넌트를 테스팅하는 프로세스
• 단위 테스팅의 일반적인 지침 (Guideline)
  • 클래스의 모든 오퍼레이션을 테스트
  • 객체가 가질 수 있는 모든 상태를 거치도록 테스트
    • 모든 상태 전이 순서를 테스트
  • 상속된 오퍼레이션은 사용되는 모든 곳에서 테스트 해야함
    • 클래스 상속은 테스팅의 복잡도를 높임
  • JUnit 등의 테스트 자동화 프레임 워크 사용
• 컴포넌트를 분리하여 테스트하기 위해 모형 객체 (Mock Object) 필요

Choosing Unit Test Cases 단위 테스트 케이스 선정

• 효과적인 단위 테스트 케이스란
  • 컴포넌트가 예상 (명세, Specification) 대로 동작하는 것을 보여주어야 한다
  • 결함 (Defect)을 찾아야 할 경우, 테스트 케이스에 의해 밝혀져야 한다
• 효과적인 테스트 케이스 선정을 위한 전략
  • 동등 분할 (Equivalence Partition) -> 분할 테스팅
    • 공통 특성을 가진 입력 그룹을 식별하여 각 그룹별로 테스트 케이스를 선정
  • 가이드라인 기반
    • 프로그래머가 자주 범하는 오류를 찾아내기 위한 테스트 케이스 선정
  • 코드 커버리지 (Code Coverage)
    • 소스 코드 중 테스트가 된 비율
    • 문장 (State) 커버리지, 결정 또는 분기 (Decision or Branch) 커버리지, 조건 (Condition) 커버리지 등

Partition Testing

• 동등 분할 (Equivalence Partition)
  • 입력 데이터 또는 출력 결과를 공통 특징을 가진 그룹으로 분할
    • 양수 / 0 / 음수, 자릿수, 데이터 개수, 정상 / 오류
• 분할 테스팅 (Partition Testing) -> 블랙 박스 / 화이트 박스 모두 가능
  • 입력과 출력 분할을 식별
  • 각 분할에서 테스트 케이스를 선정
  • 일반적으로 분할의 경계와 분할의 중간점을 선정

Testing Guidelines

• 시퀀스 (배열, 리스트 등) 테스팅 지침
  • 원소가 하나인 시퀀스로 테스트
  • 테스트마다 서로 다른 크기를 가지는 시퀀스 사용
  • 시퀀스의 첫 번째, 중간, 마지막 원소를 접근하도록 테스트
  • 길이가 0인 시퀀스 (원소가 없는)로 테스트
• 테스트 케이스 설계의 일반적인 지침
  • 모든 오류 메시지가 생성되도록 입력 값을 선택
  • 버퍼 오버플로우가 일어나도록 입력을 선정
  • 같은 입력 또는 같은 입력 순서를 여러 번 반복
  • 유효하지 않은 출력이 생성되도록 함
  • 계산 결과를 너무 크거나 너무 작게 되도록 함
• 경로 테스팅
  • 컴포넌트나 프로그램의 모든 독립적인 실행 경로를 수행하는 것을 목표로 하는 테스팅 전략

Black Box & White Box Testing

• 블랙 박스 테스팅
  • 테스트 케이스를 선정하기 위하여 시스템 (테스팅 대상)의 명세만을 사용
  • 코드나 시스템 내부에 대한 지식을 사용하지 않고 테스트 케이스 선정
  • 기법 : 동등 분할
• 화이트 박스 테스팅 (a.k.a Structural Testing)
  • 알고리즘, 소스코드 등 시스템의 내부 구조를 고려하여 테스트 케이스 선정
  • 기법 : 문장 커버리지, 분기 커버리지, 단순 경로

Component Testing

• 컴포넌트 테스팅 (컴포넌트 인터페이스 테스팅)
  • (복합) 컴포넌트를 테스팅하는 것은 컴포넌트 인터페이스 또는 인터페이스가 명세에 따라 동작한다는 것을 보여주는데 집중
  • 컴포넌트의 테스팅은 컴포넌트의 인터페이스를 테스트하는데 중점
    • 개별 객체의 단위 테스트는 완료되었다고 가정
    • 컴포넌트 인터페이스 오류는 복합 컴포넌트를 구성하는 객체들 간의 상호작용 오류에 기인
• 인터페이스 유형
  • Parameter 매개변수 인터페이스
    • 데이터의 참조 또는 어떤 경우 함수의 참조가 한 컴포넌트에서 다른 컴포넌트로 전달되는 인터페이스
  • Shared Memory 공유 메모리 인터페이스
    • 메모리 블록이 컴포넌트 간에 공유되는 인터페이스
  • Procedure 프로시저 인터페이스
    • 다른 컴포넌트들에 의해 호출될 수 있는 프로시저들의 집합을 한 컴포넌트에 모아놓은 인터페이스
  • Message Passing 메시지 전달 인터페이스
    • 한 컴포넌트가 다른 컴포넌트에 메시지를 전달하여 서비스를 요청하는 인터페이스

Interface Errors 인터페이스 에러

• 인터페이스 오용 (Misuse)
  • 호출 사용법 관련 오류
  • EX : 매개변수 유형 오류, 매개변수 순서 오류 등
• 인터페이스 오해 (Misunderstanding)
  • 인터페이스 명세를 잘못 이해
  • EX : 이진 탐색 함수에 정렬되지 않은 배열을 전달
• 타이밍 (Timing) 오류
  • 공유 메모리나 메시지 전달 인터페이스를 사용하는 경우 일어남
  • EX : 생산자 / 소비자 의 속도 또는 타이밍 오류

Interface Testing Guidelines

• 인터페이스 오류를 발견하기 위한 테스팅 지침
  • 매개변수 값이 범위의 극단(경계)에 있게 테스트를 설계
  • 포인터나 레퍼런스를 사용할 경우 Null 객체가 전달되는 경우를 테스트
  • 고의적으로 컴포넌트가 실패하도록 테스트를 설계
  • 메시지 전달 시스템에서 스트레스 (Stress) 테스팅을 사용 -> 인스펙션으로 불가
    • 타이밍 문제를 발견하는 효과적 방법
  • 공유 메모리를 이용하는 경우 컴포넌트들이 활성화되는 순서가 바뀌도록 테스트를 설계 -> 인스펙션으로 불가
• 인터페이스 오류를 찾는데는 인스펙션 (Inspection) (리뷰 포함) 이 더 효과적일 수 있다

System Testing

• 시스템 테스팅
  • 재사용 컴포넌트, 기성품 시스템, 다른 팀에서 개발한 컴포넌트를 통합하여 완전한 시스템을 테스트
• 시스템 구성요소들의 상호작용을 테스팅하는데 중점
  • 시스템의 창발적 (Emergent) 특성을 테스트
  • 계획된 창발적 행동 / 예기치 못한 창발적 행동
• 유스케이스 기반 테스팅이 효과적
  • 요구사항에서 작성한 유스케이스 시나리오 -> 시스템 테스팅에 사용
  • 유스케이스 시나리오 표현 : 시퀀스 다이어그램, 액티비티 다이어그램, 자연어 등
  • 기본 (Basic) 흐름, 대안 (Alternative) 흐름, 예외 (Exceptional) 흐름을 고려
• 점증적 통합과 테스팅
  • 시스템 테스팅은 서로 다른 컴포넌트들의 통합, 즉 통합하여 생성된 시스템을 테스팅하는 것과 관련
  • 통합과 테스팅에는 하나의 컴포넌트를 통합하고 시스템을 테스트하고, 또 다른 컴포넌트를 통합하고 다시 테스트하는 것을 반복하는 점증적 접근법이 항상 사용되어야 한

Test-driven Development

• 테스트 주도 개발 (TDD)
  • 테스팅과 코드 개발을 중첩시키는 프로그램 개발 접근법
  • 점증적인 접근법으로 증분 (Increment) 의 테스트를 작성하고 코드를 개발
  • 애자일 기법인 XP에서 시작됨
    • 테스트 우선 개발
    • Test First Development
• TDD 프로세스 단계
  1. 증분을 위한 기능 식별
  2. 테스트를 작성하여 자동화된 테스트로 구현
  3. 이전의 모든 테스트와 함께 추가한 테스트를 실행 (실패 시 4)
  4. 증분의 기능을 구현하고 테스트를 다시 실행
  5. 모든 테스트를 통과하면 다음 증분을 개발

Test-driven Development

• 테스트 주도 개발의 장점
  • 코드 커버리지 (Code Coverage) : 모든 코드와 연관된 테스트가 있음
  • 회귀 테스팅 (Regression Testing) : 모든 테스트를 실행
  • 단순화된 디버깅 :　문제를 지역화 (Localize) 하기 쉬움
  • 시스템 문서화 : 테스트를 보면 코드를 이해하기 쉬움
• 회귀 테스팅
  • 시스템을 변경한 후 변경과 관련된 테스트뿐만 아니라 기존에 성공한 모든 테스트를 실행
  • 변경으로 인하여 새로운 버그가 생기지 않았고 새로운 코드가 기존 코드와 문제업이 동작하는지 검사
  • JUnit 등 자동화된 테스팅 필요

Release Testing

• 릴리스 테스팅은 시스템 테스팅의 한 형태
• 릴리스 테스팅과 시스템 테스팅의 구분
  • 개발팀이 아닌 별도의 팀이 테스팅 해야 함
  • 시스템이 요구사항을 만족시키는 것을 점검
  • 시스템이 사용하기에 충분하다는 것을 확인
  • 시스템 테스팅은 결함 테스팅에 중점
• 블랙 박스 테스팅 프로세스 <- 릴리스 테스팅의 일반적 방법
  • 테스트 케이스를 시스템 명세를 이용하여 작성
  • 시스템의 기능만 고려하고 구현은 고려하지 않음

Tip) 블랙 박스 테스팅 (명세) 과 화이트 박스 테스팅 (내부 구조) 차이를 알자

Requirements based & Scenario Testing

• 요구사항 기반 테스팅
  • 검증 테스팅 (시스템이 요구사항을 제대로 구현했는지 테스팅)
  • 추적 가능성 (Traceability) 기록 관리
• 시나리오 테스팅
  • 시스템을 사용하는 전형적인 시나리오를 만들어 테스트 케이스를 개발하는데 사용
  • 유스케이스 시나리오
  • 한 시나리오 내에서 여러 요구사항을 테스팅 -> 요구사항의 조합 점검

Performance Testing

• 성능 테스팅 (성능 테스트)
  • 시스템이 의도된 부하를 처리할 수 있는지 확인하기 위하여 설계되어야 한다
  • 시스템의 운영 프로파일을 반영하여 트랜잭션 유형의 비율에 따라 테스트
  • 시간 당 처리량 (Throughput, TPS, Transaction per Second), 응답 시간 (response Time) 등을 측정
• 스트레스 테스팅 (Stress Testing)
  • 시스템의 최대 설계 부하를 초과하는 요청을 생성하여 테스트
• 스트레스 테스팅의 목적
  • 시스템의 장애 행동을 관찰
  • 시스템의 결함 (Defect) 을 발견

User Testing 사용자 테스팅

• 사용자 테스팅
  • 사용자나 고객이 입력을 제공하고 시스템 테스팅에 관한 의견을 내는 테스팅 프로세스의 한 단계
• 릴리스 테스팅 후에도 사용자 테스트는 필수적
  • 사용자 운영환경이 시스템의 신뢰성, 성능, 사용성, 견고성 등에 영향
• 사용자 테스팅의 유형
  • (Alpha Testing) 알파 테스팅
    • 사용자가 개발자와 함께 개발자 사이트에서 테스트 (개발자 존재)
    • 현실적인 테스트를 설계할 수 있도록 사용자들이 정보 제공
  • (Beta Testing) 베타 테스팅
    • 고객 또는 큰 규모의 사용자 그룹이 시스템을 사용해보고 문제점 피드백 (개발자 없음)
    • 다양한 설정과 운영 환경에서 사용되는 시스템을 테스트 하는데 효과적
  • (Acceptance Testing) 인수 테스팅
    • 시스템의 인수를 결정하기 위해 고객의 환경에서 고객의 데이터를 이용
    • XP 에서는 별도의 인수 테스팅이 없을 수 도 있음
• 인수 테스팅의 6 단계 1, 인수 기준 정의
  1. 인수 테스팅 계획 수립
  2. 인수 테스트 유도
  3. 인수 테스트 실행
  4. 테스트 결과 타협
  5. 시스템 거부 / 인수