소프트웨어 테스트

Yuzu·2023년 2월 2일
0

소프트웨어를 배포하기 전 해당 소프트웨어가 정상적으로 작동하는가에 대한 검증 단계

  • QA에서 진행, 자동화 처리

테스트 종류

총 테스트 단계

빌드를 올바르게 수행할 수 있는가, Did we build it right? (1,2)
빌드된 소프트웨어가 정상적으로 작동하는가, Did we build the right thing?(3)

1. 유닛 테스트 (Unit, 단위)

Do our objects do the right thing?
Are they convenient to work with?

  • 소프트웨어를 함수 및 클래스 단위로 분해하여 테스트하는 방식
  • 테스트 가능하게(Testable), 모듈화하여 하나하나 독립적으로 테스트
  • 가장 많은 수의 테스트

ex) 계산기에서 덧셈만 테스트

2. 통합 테스트 (Integration)

Does our code work against code we can't change?

  • 모듈들을 조합하여(단위 테스트들을 모아서) 테스트를 구성 (상향식 통합 테스트)
    ex) 계산기에서 덧셈과 뺄셈을 동시에 테스트
  • or 모듈이 있는 것을 가정하고 테스트 (하향식 통합 테스트)
    ex) 3 layer architecture 중 서비스 모듈을 테스트를 해야할 시 하위 모듈(여기서는 데이터 액세스 모듈)을 stub(가상의 모듈)으로 만들어 테스트. 상위 모듈을 테스트 하기 위해 하위 모듈을 있는 것처럼 속여서 상위 모듈만 테스트 하는 것

3. 인수 테스트 (Acceptance)

Automated

  • 통합 테스트와 비슷하지만 실제 환경을 가정하고 테스트
  • 알파 테스트: 폐쇄적인 환경에서 개발자가 통제를 하여 테스트를 진행
  • 베타 테스트: 개방적인 환경에서 비교적 자유롭게 테스트를 진행

코드 커버리지

테스트가 코드를 얼마나 커버하는지에 대한 정도

1. 함수 (function)

총 함수중에 몇 개의 함수가 실행되는지, 기본 테스트로 테스트들을 포괄하는 개념

함수 커버리지(%) = 실행된 함수 개수 / 총 함수 개수 * 100

2. 구문 (statement)

코드의 하나의 구문이 실행되는 정도, Javascript 에서 하나의 구문은 보통 세미 콜론(;)으로 구분

구문 커버리지(%) = 실행된 구문 수 / 전체 구문 수 * 100

3. 조건 (condition)

if 내의 조건들이 true와 false를 가지는 정도
ex) if (a > 0 || b < 0) 이라는 조건이 있을 때, 전체 조건으로 나올 수 있는 경우의 수는 a > 0이 true 일 때와 false, b < 0이 true 일 때와 false 를 조합하여 총 4개(조합 별로 25%)

조건 커버리지(%) = 각 조건마다 true or false 한번의 개수 / (전체 조건 수 ^ 2) * 100

4. 분기 (branch)

조건으로 인하여 나뉘게 되는 실행 경로, 조건이 많을수록 분기 커버리지의 전체 양이 늘어남

분기 커버리지(%) = 실행된 분기 수 / 총 분기의 개수 * 100

역사

Gelperin과 Hetzel의 진화적 테스팅 모델

  1. 디버깅 지향 시대 (debugging-oriented period)
    테스팅을 하는 주 목적은 버그를 제거하는 것 (디버깅 = 테스팅)
  2. 증명 지향 시대 (demonstration-oriented period)
    소프트웨어의 요구사항을 포함 + 디버깅
  3. 파괴 지향 시대 (destruction-oriented period)
    오류를 찾아내는 것 + 디버깅
  4. 평가 지향 시대 (evaluation-oriented period)
    소프트웨어의 개발 생명 주기(waterfall 등의 방법론에 의해)에 포함
    검토 활동인 테스트의 중요성이 부각된 시대
  5. 예방 지향 시대 (Prevention-oriented Period)
    소프트웨어 개발 전반적인 부분(설계, 디자인, 구현 등)에서 생기는 문제들을 미리 찾아내기 위함, 빌드와 품질 검증

최근 동향 (TDD 개발 방법론)

  • 기존 Waterfall 방식: 설계 → 개발 → 테스트 코드 작성
  • TDD: 테스트 코드 작성 → 개발 → 리팩토링 (테스트 주도 개발, 테스트가 곧 설계)

테스트를 하는 이유

  1. 소프트웨어 품질 검증 및 보장
    버그 해결, 기존 명세대로 프로그램이 개발이 되어 있는지, 사용자의 요구사항을 충족 했는지(인수 테스트)
  2. 유지보수시 Human Error 방지
    자동화 테스트 코드가 통과되지 않는다면 실수가 어디서 발생했는지 잡아내어 수정

자동화의 중요성

  1. 수동(Manual) 테스트
    개발자 및 사용자가 직접 테스트하는 것
    주로 사용성을 검증할 수 있는 UI 및 UX 테스트에서 수행
    직관적으로 쉽게 테스트를 실행, 실행 속도도 느리고 시간도 오래 걸려서 자주 실행하기가 힘들고 부정확할 확률이 높음
  2. 자동(Automatic) 테스트
    시스템 테스트를 최대한 자동화하여 휴먼 에러를 줄이고, 정확하고 반복적으로 실행될 수 있도록 하여 생산성을 높이고 시스템을 안정적으로 운영할 수 있게 함
  3. 단위 테스트의 자동화 = 필수
    개발자가 테스트 코드를 작성하여 코드로 코드를 테스트
    빌드 전에 단위 테스트를 자동을 수행하는 스크립트를 통해 자동화를 한다.
    빌드 혹은 컴파일 하기 전, 원격 저장소에 코드가 올라가기 전에 검사하여 안정적으로 코드를 관리
profile
냐하

0개의 댓글