소프트웨어 테스트(software testing)는 테스트 대상의 품질과 속성을 평가하는 활동이다.[1][2] ISO/IEC/IEEE 29119-1:2022는 테스트를, 하나 이상의 테스트 항목이 지닌 속성을 찾아내고 평가하기 쉽게 하려고 하는 활동의 집합으로 정의한다.[1] ISTQB 용어집은 테스트를 소프트웨어 개발 생명주기 안에서 컴포넌트나 시스템, 그리고 관련 작업 산출물의 품질을 평가하는 프로세스로 정의한다.[2]
테스트의 목적
ISTQB CTFL 강의계획서는 테스트가 흔히 노리는 목적으로 아래 아홉 가지를 든다.[3]
테스트 원칙
Dijkstra는 1972년 튜링상 강연 “The Humble Programmer”에서, 프로그램 테스트는 버그가 있다는 것을 보이는 데는 아주 효과적일 수 있어도 버그가 없다는 것을 보이는 데는 턱없이 모자라다고 말했다.[4]
CTFL 강의계획서는 테스트의 일곱 원칙을 둔다.[3]
- 테스트는 결함이 있다는 것을 보여 줄 수 있을 뿐, 결함이 없다는 것을 증명하지는 못한다.
- 아주 단순한 경우가 아니면 모든 것을 테스트할 수는 없다.
- 일찍 테스트하면 시간과 비용을 아낀다.
- 찾은 결함은 대개 적은 수의 컴포넌트에 몰려 있다.
- 같은 테스트를 여러 번 되풀이하면 새 결함을 찾는 효과가 차츰 줄어든다(tests wear out).
- 테스트는 맥락에 따라 달라진다.
- 명시된 요구사항을 모두 꼼꼼히 테스트하고 찾은 결함을 다 고쳐도, 사용자의 요구와 기대를 채우지 못하는 시스템이 나올 수 있다(absence-of-defects fallacy).[3]
CTFL 강의계획서 2018 V3.1은 다섯째 원칙을 살충제 역설(pesticide paradox)이라 불렀고, v4.0.1은 tests wear out이라 부른다.[3][5]
테스트와 디버깅
CTFL 강의계획서에 따르면 동적 테스트는 결함 때문에 생기는 장애를 일으키고, 정적 테스트는 테스트 대상에서 결함을 곧바로 찾는다.[3] ISTQB 용어집은 디버깅(debugging)을 컴포넌트나 시스템에서 failure의 원인을 찾아 분석하고 없애는 프로세스로 정의한다.[6] CTFL 강의계획서에 따르면 동적 테스트가 장애를 일으킨 뒤의 디버깅은 대개 장애를 재현하고, 원인인 결함을 진단하고, 그 결함을 고치는 순서로 간다. 고친 뒤에는 확인 테스트로 문제가 풀렸는지 보고, 회귀 테스트로 다른 곳에 failure가 생기지 않았는지 볼 수 있다.[3]
정적 테스트와 동적 테스트
정적 테스트(static testing)는 테스트 대상을 실행하지 않고, 동적 테스트(dynamic testing)는 실행한다.[1][3] V&V 전반에서 정적 기법과 동적 기법을 나누는 방식은 검증과 확인에서 다룬다.
CTFL 강의계획서에 따르면 정적 테스트는 사람이 살펴보는 리뷰와 도구를 쓰는 정적 분석으로 이루어진다. 정적 테스트는 요구사항 명세나 테스트 계획서처럼 실행할 수 없는 작업 산출물에도 쓸 수 있지만, 동적 테스트는 실행할 수 있는 산출물에만 쓸 수 있다. 정적 테스트는 소프트웨어 개발 생명주기의 가장 이른 단계에서 결함을 찾을 수 있고, 도달할 수 없는 코드처럼 동적 테스트로는 찾지 못하는 결함도 찾는다. 유지보수성처럼 코드 실행과 상관없는 품질 특성도 잴 수 있다.[3]
같은 강의계획서는 정적 테스트로 찾기가 더 쉽거나 더 싼 결함으로 다음을 든다.[3]
테스트 기법의 분류
테스트 기법은 블랙박스(명세 기반), 화이트박스(구조 기반), 경험 기반의 세 갈래로 나뉜다.[3][7] CTFL 강의계획서에 따르면 갈래마다 다음에 바탕을 둔다.[3]
테스트 레벨
테스트 레벨(test level)은 함께 조직하고 관리하는 테스트 활동의 묶음이고, 레벨마다 테스트 프로세스의 한 인스턴스다. 강의계획서는 다섯 레벨을 든다.[3]
- 컴포넌트 테스트(단위 테스트): 컴포넌트를 따로 떼어 테스트한다.
- 컴포넌트 통합 테스트: 컴포넌트 사이의 인터페이스와 상호작용을 테스트한다.
- 시스템 테스트: 시스템 전체의 동작과 기능을 테스트한다.
- 시스템 통합 테스트: 시스템과 다른 시스템, 외부 서비스 사이의 인터페이스를 테스트한다.
- 인수 테스트: 확인(validation)과, 시스템이 사용자의 업무 요구를 채워 배포할 준비가 됐음을 보이는 데 초점을 둔다.[3]
테스트 기준의 정의와 개발 단계와의 대응은 V 모델에서 다룬다.