테스트

Waterfall model

마치 윗 물이 가득 차야 아래로 쏟아지는 폭포처럼, 한 단계가 완전히 완료되면 다음 단계로 넘어가는 개발 방식을 말한다.

• 문제점
  - 특정 단계에서 발생한 문제를 찾는 데에 걸리는 시간은, 해당 단계에서 멀어질수록 늘어난다.
  - 예를 들어, 구현 단계에서 발생한 문제를 테스트 단계에서 찾아내는 데에 걸리는 시간보다
  - 설계 단계에서 발생한 문제를 테스트 단계에서 찾아내는 데에 걸리는 시간이 훨씬 더 오래 걸린다.

V 모델

V 모델은 소프트웨어 개발 생명 주기에서 개발 단계와 테스트 단계를 병행하며 진행하는 개발 방식이다.

그림에서 왼쪽은 개발 과정이고, 오른쪽은 이에 대응하는 테스트 단계이다.

1. 요구사항 분석(Requirements Analysis)

   • 설명: 고객의 요구사항 분석하고 기능적 요구사항과 비기능적 요구사항 정의
   • 대칭 테스트: 인수 테스트(Acceptance Testing)
     - 목적: 소프트웨어가 고객의 요구사항을 충족하는지 최종적으로 검증

2. 시스템 설계(System Design)

   • 설명: 시스템의 전체 아키텍처를 설계하고 모듈 간의 상호작용과 데이터 흐름을 정의
   • 대칭 테스트: 시스템 테스트(System Testing)
     - 목적: 전체 시스템이 올바르게 작동하는지, 기능 및 성능 요구사항을 모두 만족하는지 검증

3. 상세 설계(Detailed Design)

   • 설명: 각 모듈의 내부 설계를 정의하고, 세부적인 로직과 데이터 구조를 설계
   • 대칭 테스트: 통합 테스트(Integration Testing)
     - 목적: 설계된 모듈들이 상호작용하며 제대로 통합되어 작동하는지 검증

4. 구현(Implementation)

   • 설명: 상세 설계를 바탕으로 코드를 작성하여 실제 소프트웨어를 개발
   • 대칭 테스트: 유닛 테스트(Unit Testing)
     - 목적: 각 모듈이 개별적으로 잘 동작하는지, 내부 로직이 올바르게 구현되었는지 검증

애자일 방법론(Agile Methodology)

• 작은 단위의 반복적인 개발 주기를 통해 소프트웨어를 지속적으로 개선해 나가는 것을 목표로 한다.

• 짧은 주기의 스프린트(sprint)를 통해 개발, 테스트, 피드백을 반복하며 점진적으로 제품을 개선한다.

단위 테스트 정의와 대상

개발자는 여러 테스트 단계 중 단위 테스트에 가장 관심을 기울여야 한다.

• 빠르게 수행하고
  - 테스트 코드 실행 시간이 너무 길면 안된다.

• 격리된 방식으로
  - 테스트끼리 서로 영향을 끼치면 안된다(다른 테스트 때문에 특정 테스트가 동작하지 않는다거나).

• 작은 코드 조각(단위)을 검증하고

• 자동화된 코드

테스트 환경과 테스트 코드

• 화이트박스 테스트
  - 코드 내부를 들여다보고 테스트
  - 구문/조건/분기 커버리지

• 블랙박스 테스트(추천)
  - 내부를 모르는 상태에서 입/출력 테스트
  - 경계값 분석, 동등 클래스 분할 테스트

A-A-A 테스트

Arrange-Act-Assert

• Arrange 준비
  - 테스트 대상을 검증하기 위해서 필요한 것을 준비
  - 가짜 데이터, 객체 생성, API 호출 등

• Act 실행
  - 테스트 대상 코드를 실행

• Assert 단언
  - 실행한 코드가 기대했던 예상대로 동작하는 지 확인

무엇을 테스트해야 하는가: Right-BICEP

• Right
  - 결과가 올바른가?
• B
  - 모든 경계(boundary) 조건이 CORRECT한가?
• I
  - 역(inverse) 관계를 확인할 수 있나?
  - 예를 들면, add한 다음 delete를 하면 원래대로 돌아가야 한다거나...
• C
  - 다른 수단을 사용해서 결과를 교차 확인(cross-check)할 수 있나?
  - 예를 들면, 내가 구현한 sort 알고리즘이 다른 sort 알고리즘(bubble sort 라던가...)과 같은 결과가 나와야 함.
• E
  - 에러 조건(error condition)을 강제로 만들 수 있나?
  - 소프트웨어가 오류 상황에서 올바르게 동작하는지 확인
  - 예를 들어,
  - 메모리가 부족할 때
  - 디스크 공간이 부족할 때
  - 기타 등등
• P
  - 성능(performance) 특성이 한도 내에 있나?

좋은 테스트: A-TRIP

• A : 자동적(Automatic)
  - 단위 테스트는 실행과 결과에 대한 확인이 자동화 되어야 한다.
• T : 철저함(Through)
  - 해당 기능의 문제가 될 경우의 수를 모두 철저하게 테스트한다.
• R : 반복 가능(Repeatable)
  - 순서 상관없이 반복 실행 가능하며, 반복해서 같은 결과가 나와야 한다.
• I : 독립적(Independent)
  - 다른 테스트/외부 환경에 독립적 (의존성이 없어야 한다).
• P : 전문적(Professional)
  - 테스트 코드도 진짜 코드다!

코드 커버리지 테스트

코드 커버리지는 소프트웨어의 테스트를 논할 때 얼마나 테스트가 충분한가를 나타내는 지표 중 하나다. 말 그대로 코드가 얼마나 커버되었는가이다. 소프트웨어 테스트를 진행했을 때 코드 자체가 얼마나 실행되었냐는 것이다.

출처: https://ko.wikipedia.org/wiki/%EC%BD%94%EB%93%9C_%EC%BB%A4%EB%B2%84%EB%A6%AC%EC%A7%80

Java의 경우 코드 커버리지의 도구로 JaCoCo, Cobertura, Clover 등이 있다.