sonumb

프로그램 테스트의 종류 본문

개발자 이야기/Software Engineering

프로그램 테스트의 종류

sonumb 2022. 1. 6. 11:49

Prelude: 누가 내 테스트를 옮겼을까?

요즘 테스트 추세로는 대개 유닛테스트가 기본이지만, 리그레션 테스트는 선택적인 듯한 느낌이다.

이유가 여러 가지 있겠지만, 리그레션 테스트를 위한 구축/유지하는 비용이 막대하다.

  • 테스트 정책 수립
  • 테스트 프레임워크 구축
    • 테스트 전용 인터프리터 개발 및 유지 보수
    • 테스트 케이스 유지 보수

위의 두 가지만 하더라도, 테스트 전략을 위한 전문가와 프레임워크 구축을 위한 개발자가 필요하다.

더군다나, 테스트 대상에 따라서 테스트 프레임워크를 따로 구축해야 하는 가능성이 매우 높다. (범용성이 떨어짐..)

.

큰 비용...

그러나 장기적인 관점에서 바라본다면, 그리 큰 비용은 아닐 것이다. (error가 defect가 되는 순간 그 댓가는... 생각만해도 끔찍하다.)

 

.

그런데, 막대한 자금을 보유한 대규모 회사의 소프트웨어임에도 불구하고, 해결된 문제가 상위 버전에서 재발생하는 것을 종종 보곤한다. 그런 것을 보면, 브랜치/태깅 정책과 리그레션 테스트가 소홀히 다뤄지는 것이 아닌가라는 생각이 든다.
(애플의 사파리에서 한글 입력 시, 한글이 씹히는 버그가 대표적이다. 내 기억으론 어느 시점에 해결되었다가, 특정 코드네임에서 되살아난 버그. 2016년도 쯤에 되살아난 것 같다. 그때 이후로 지금은 아이맥의 사파리를 암호 저장용도 외에 안 쓴다. 지금은 해결되었는지 잘 모르겠다.)

 

여튼 테스트가 아주 중요하다.

 

생각보다 중요하다. 따라서, 테스트를 분류하고 실행해야하며, 기본적인(최소한의) 전략을 세우고 대응을 해야 한다.

 

(✅ 퍼온 내용외에 중요한 테스트가 하나 더 있으니, "Stress 테스트" 이다. 내용은 위키피디아를 참고바란다.

[https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%8A%B8%EB%A0%88%EC%8A%A4_%ED%85%8C%EC%8A%A4%ED%8A%B8] )

...

...

위키피디아 내용 중, 금융에 관한 섹션을 읽다보니 생각나는게 있는데...

모기지 프라임이다.

채권을 세로로 쪼개서 판다는 그 금융 상품.

모든 채무자가 돈을 갚지 못한다는 극단적인 스트레스 테스트를 했으면, 모기지 프라임 사태의 충격의 규모가 작아지지 않았을까 생각해 본다.

.

진짜 끄읏~

 

아래는 테스트의 종류 및 설명에 대해 퍼온글이다.

테스트의 종류

출처: http://priceless.tistory.com/283


1. Full Test Suite

단위 테스트 케이스 + 통합 테스트 케이스 + 시스템 테스트 케이스

2. 단위 테스트(Unit Test)

개발자 자신이 스스로 작성한 소스코드를 테스트함. 비공식적. 함수 하나, 클래스, 컴포넌트가 그 단위가 될 수 있다. 소스코드를 디버깅 도구를 이용하여 한 줄씩 추적해보는 방법이 시간이 많이 걸리지만 장기적으로는 더 효율적일 수 있다.

3. 시스템 테스트(System Test)

결함을 찾아내기 위해 소프트웨어를 실행시켜서 테스트를 수행하는 작업, 테스트 조직에서 담당, 요구사항기술서를 토대로 테스트 계획서를 작성하여 테스트 케이스를 만든다.

4. 스모크 테스트(Smoke Test)

전자 회로 기판에 전원을 넣었을 때 기판에서 연기가 나는지 확인하는 테스트에서 유래함. 시스템의 안정성 및 주요 기능이 제대로 작동하는지를 확인. 모든 버그를 찾는 것이 아니라 제품의 안정성을 유지하기 위함

5. 화이트/블랙박스 테스트(White/Black BoxTest)

5.1. 화이트박스 테스트

모듈 안의 작동을 관찰하여 소스코드에 있는 각각의 라인이 제대로 수행되는지를 철저하게 시험

  • Statement coverage : 원시 코드의 모든 문장을 한 번 이상 수행한다.
  • Decision coverage : 선택 문장의 모든 조건을 최소한 한 번 씩 테스트한다.
  • Loop coverage : 모든 루프를 완벽히 테스트한다.

5.2. 블랙박스 테스트

소스코드 안을 들여다 보지 않고 모듈이 요구 사항에 맞게 기능이 잘 동작 하는지 점검하는 테스트

6. 포지티브/네거티브 테스트 (Positive/Negative Test )

Normal/Abnormal Test 이라고도 한다.

6.1. 포지티브 테스트

정상적인 값을 입력했을 때 정상적인 결과가 나오는지를 테스트하는 것

6.2. 네거티브 테스트

정상적이지 않은 값을 입력할 때나 비정상적으로 시스템을 조작할 때를 테스트하는 것, 보통 사용자들은 소프트웨어를 정상적으로만 이용하지 않기 때문에 네거티브 테스트가 잘 되어 있는 제품의 품질이 더 높다.

7. 회귀 테스트(Regression Test)

프로그램 수정후 과거에 고쳤던 버그가 다시 살아나는 것을 회귀버그라고 하고 그버그를 찾는 테스틀 회귀 테스트라고 한다. 매 사이클마다 전체 테스트 케이스를 다 점검하는 것이 원칙이다.

반응형