개발에 있어 테스트가 중요하다는 것은 이제 개발자가 아닌 동료들도 알고있다. 소프트웨어는 일상에서 뗄 수 없는 관계이고, 이런 서비스를 만들고 제공하는 입장에서 SW 결함으로 인한 문제가 발생한다면 꽤나 치명적이다. 모든 프로그램이나 인간이 완벽하지 않기 때문에, 테스트를 통해 프로그램에 오류가 있음을 검증하고 이로 인해 발생가능한 문제들을 최대한 방지해야 한다.

일반적인 테스트 관련 개념의 정리와 TDD, 내가 자주 사용하는 Java(+ Spring)의 테스팅 기법으로 나누어 포스팅할 예정.

소프트웨어 테스트 개요

테스트 정의

  • 소프트웨어를 실행하여 결과가 올바른지 판단하는 과정
  • 노출되지 않은 숨어있는 결함(Fault)을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차
  • 오류 발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정
  • 개발된 소프트웨어의 결함과 문제를 식별하고 품질을 평가하며 품질을 개선하기 위한 일련의 활동
  • SW의 동작과 성능, 안정성이 요구되는 수준을 만족하는지 확인하기 위한 결함을 발견하는 메커니즘

소프트웨어 오류의 원인

  • 요구사항 오류
  • 설계 오류
  • 코딩 오류
  • 기타 오류
  • 오류 분포

테스트 용이성(Testability)

아키텍처를 구성하는 요소들이 얼마나 테스트에 적합한가를 나타내는 품질 속성

  • 제어 용이성 : 프로그램을 제어하기 용이하도록 설계 -> 제어 용이성이 높을수록 테스트를 자동화할 수 있는 부분이 많아진다.
  • 관찰 가능성 : 프로그램 내부 상태를 쉽게 파악할 수 있도록 설계
  • 단순성 : 시스템 구조 등을 가능한 한 단순하게 설계
  • 분할 용이성 : 테스트할 대상 영역을 제어하여 문제가 발생된 곳을 고립시킴으로써 독립적으로 모듈을 테스트 할 수 있도록 설계
  • 운영 용이성 : 프로그램이 오작동해도 테스트 작업을 계속할 수 있도록 설계
  • 안정성 : 테스트 동안에 소프트웨어 변경이 자주 발생되지 않도록 설계
  • 이해 용이성 : 소프트웨어 설계 정보가 잘 조직화되어 쉽게 접근 가능하도록 하여 소프트웨어를 잘 이해할 수 있도록 설계

객체지향 패러다임의 SOLID 원칙과 비슷한 내용이라고 이해됨.

테스트 구성도 및 구성요소

테스트 구성도

테스트 구성요소

| 과정 | 구성요소 | 특징 및 설명 | |—|—|—| | 테스트 준비 | Test Basis | - 시스템 요구사항이 기록된 모든 문서
- Test Case 생성 시 사용되는 기초 자료
- 기능, 요구사항, 제약 사항 명시를 기록 | | | Test Suite | - Test Case의 집합, Test Case간 사전/사후 조건 연관 관계 | | | Test Case | - 테스트를 수행하기 위한 입려규 값, 사전 조건 등을 입력하고, 예상 결과까지 기록하여 결과가 올바른지 확인 | | | Test Script | - 테스트에 대한 절차 명세 | | 테스트 수행 | Test Bed | - 테스트를 수행하기 위해 필요한 모든 지원 요소를 포함하는 환경 | | | Test Target | - 테스트 수행의 대상이 되는 컴포넌트, 시스템 | | | Test Harness | - 테스트 수행을 위해 필요한 Stub과 Driver로 구성된 테스트환경
- 시험을 지원하는 목적 하에 생성된 코드와 데이터 | | | Test Driver | - 컴포넌트나 시스템을 제어하거나 호출하는 테스트 도구
- 상향식(Bottom-up) 테스트에서 아직 통합되지 않은 상위 컴포넌트 동작을 시뮬레이션하는 모의 모듈 | | | Test Stub | - 하향식(Top-Down) 테스트에서 사용하는 모듈
- 테스트 대상과 협력 구동하는 컴포넌트가 개발되지 않은 시점에서 필요한 테스트 진행을 위해 생성하는 더미(Dummy) 컴포넌트 | | 테스트 결과 | Test log | - 테스트 실행에 대한 관련 세부 항목의 시간 순서에 따른 기록 | | | Tes Report | - 테스트 활동과 결과를 다루는 문서
- 완료 조건에 대비하여 상응하는 테스트 항목을 평가 | | | Incident Report | - 테스트 중에 일어난, 조사를 요구하는 모든 이벤트 보고서
- 테스트 활동 수행 중 발생한 문제점 |

소프트웨어 테스트 분류

개발 단계별 테스트 분류

위 다이어그램은 V&V모델 또는 V다이어그램이라고 부름 V&V는 개발 단계별 산출물의 단계 초기에 설정된 조건의 만족 여부(Verification)와 구현된 S/W가 사용자 요구사항 및 기대치를 만족하는지(Validation) 검증 및 확인하는 활동

각 테스트 단계는 좌측 분석, 설계, 구현 단계와 대칭관계에 있다고 본다. 이 중, 우측의 테스트 분야를 떼서 단계별로 살펴보자.

단위 테스트

구현 단계에서 각 모듈이 구현된 후에 단위 테스트를 수행, 모듈이 단독적으로 실행할 수 있는 환경이 필요. 개발된 각각의 모듈을 테스트. 내가 작성한 코드를 테스트하는 코드의 형태를 취한다.

단위 테스트에 관련해서는 TDD와 함께 좀 더 자세하게 설명하겠다.

장점

  • 코드를 “어떻게” 작성하는지 생각하는데에 도움을 준다.
  • 단위 테스트를 하다보면 함수나 메소드를 더 작게 만들게되는 경향이 있으며, 이것은 코드를 이해하고 테스트하기 쉽게 만들어주고 이렇게 작아진 함수나 메소드는 코드를 변화시키는 것 또한 쉽도록 한다. (단일 책임의 원칙이 생각남)

통합 테스트

단위 테스트가 완료된 모듈 간의 상호작용(인터페이스)이 올바르게 되는지 테스트.

  • 개별적인 모듈에 대한 테스트가 불충분하게 수행된 경우를 보완
  • 제한된 상황만을 고려한 Test Driver / Test Stib 때문에 실제 모듈과 통합하는 과정에서 오류가 발생하는지 확인
  • 전역 변수 등으로 인해 모듈간의 예기치 못한 상호작용 때문에 발생하는 부작용으로 인한 오류 발생을 확인

종류

  1. 빅뱅 테스트 : 모든 컴포넌트를 다 만들고 통합하여 테스트하는 방식
  2. 하향식 통합(Top-Down) : 가장 상위 모듈을 테스트하기 위해 하위 모듈들을 Test Stub으로 대치 후 테스트를 수행하는 방법
    • 장점
      • 설계상의 오류를 빨리 발견할 수 있음
    • 단점
      • Test Stub이 필요하기 떄문에 비용이 많이 소요될 수 있음
      • Black Box 테스트만 사용하는 경우 하위 모듈이 충분하게 테스트되지 않을 가능성이 있음
  3. 상향식 통합(Bottom-Up) : 하위 모듈을 먼저 테스트하고 상위에 있는 모듈들을 통합하는 방식
    • 장점 : 하위에 있는 모듈을 충분하게 테스트할 수 있고, Test Stub 비용이 들지 않음.
    • 단점 : 설계 오류를 조기에 발견하지 못함.
  4. 샌드위치 통합 : 특정 테스트 대상 모듈을 중심으로 상하위 임시 모듈을 연결하여 통합하는 방법

시스템 테스트

전체 시스템에 대한 초기의 목적을 만족하는가를 확인하는 테스트. 통합 테스트가 완료된 후에 완전한 시스템에 대해 시슽메 명세에 따라 개발되었는지를 검증하기 위해 수행하는 테스트. 시스템의 기능 측면에서뿐만 아니라 사용성, 견고성, 신뢰성, 성능, 안전성, 보안성과 같은 비기능적 요구사항을 시스템이 만족하는지도 검증.

인수테스트

사용자의 요구사항을 만족하는가를 확인하는 테스트.실제 사용자 환경에서 테스트하며, 시스템 테스트에서 사용한 테스트 시나리오들을 이용할 수 있다.

  1. 알파 테스트 : 사용자에 의해 테스트가 수행되지만 개발자 환경에서 통제된 상태로 수행
  2. 베타 테스트 : 소프트웨어를 일정 수의 사용자들이 사용하고 피드백을 받음. 보통 개발자는 참여하지 않음.

테스트 케이스 생성별 구분

Black Box 테스트

기능 요구사항 등 프로그램 외부 명세를 보면서 테스트하는 기법. 상세한 기능 요구사항이 요구됨.

White Box 테스트

프로그램 내부 로직을 보면서 테스트. 프로그램 구현 및 내부 구조 이해를 위한 지식이 요구됨.

기타 구분별 테스트 유형

프로그램 실행 여부

  • 동적 테스트 : 프로그램을 실행하며 소프트웨어 시스템의 기능 테스트와 자원 사용 및 성능 확인 등 비기능 테스트를 겸한다. 모든 레벨에서 테스트 가능하며, 블랙박스 또는 화이트박스 테스트로 수행.
  • 정적 테스트 : 코드를 실행하지 않고 테스트하는 기법으로 리뷰와 같은 수동적 기법과 정적 분석과 같은 자동화된 기법이 있다. 정적 테스트는 개발 프로세스 초기에 개발 산출물들에 대해 결함을 발견함으로써 개발 비용을 낮추는데에 도움이 된다.

품질 특성에 따른 분류

  • 기능 테스트 : 기능 요구사항 검증
  • 사용성 테스트 : 소프트웨어를 쉽게 사용할 수 있는 정도, 편의 기능 제공 정도를 측정하고 검증 확인하는 테스트
  • 성능 테스트 : 시스템에 부하를 주면서 응답시간, 처리량, 속도 등 성능지표 추이를 측정
  • 스트레스 테스트 : 복합데이터 또는 대량의 데이터를 이용한 고부하 장기 테스트
  • 회복 테스트 : 문제가 발생했을 때 복귀 능력 검증
  • 보안 테스트 : 외부의 침입이나 해킹에 대응하는 능력 검증

    접근 방법

  • 탐색적 테스트 : 테스트 엔지니어의 경험, 지식과 직관에 기초한 테스트. 소프트웨어 시스템 분석을 위한 문서가 제대로 준비되어 있지 않은 경우 시스템 테스트에 유용
  • 위험기반 테스트 : 리스크 분석과 결정된 우선순위에 따른 테스팅

기타

  • 설치/업그레이드 테스트 : 소프트웨어 제품의 설치 또는 제거, 이전 버전에서 업그레이드 확인.
  • 회귀 테스트 : 앞 단계에서 정상적으로 수행된 테스트를 Refactoring된 시스템에 대해서 다시 테스트를 수행함으로써 변경에 의한 영향을 검증

참고