소프트웨어 테스트

왜 배우는가: 소프트웨어 테스트는 결함을 줄이고 품질 근거를 확보하는 핵심 활동이라 실무에서 항상 계획·수행된다. 테스트 원리, 블랙박스·화이트박스 비교, 기법 적용 문항이 여러 회차에 걸쳐 반복 출제되므로 개념을 정확히 잡아야 한다.

출제 이력: 제139회 2교시 4번, 제139회 3교시 4번, 제134회 3교시 2번, 제133회 4교시 2번, 제96회 4교시 5번, 제87회 4교시 1번

1. 한 줄 정의와 핵심 키워드

소프트웨어 테스트는 소프트웨어가 요구사항을 만족하는지 확인하고 결함을 찾기 위해 실행하거나 검토하여 결과를 평가하는 활동이다.

핵심 키워드는 다음과 같다.

• 결함: 명세와 다르게 동작하는 소프트웨어의 문제 상태다. 원인은 코드, 설계, 요구사항 어디에도 있을 수 있다.
• 검증과 확인: 검증은 제품을 올바르게 만들었는지, 확인은 올바른 제품을 만들었는지 보는 활동이다.
• 테스트 케이스: 입력값, 실행 조건, 기대 결과를 묶은 시험 단위다.
• 테스트 오라클: 실행 결과가 맞는지 판정하는 기준이다. 명세가 기준 역할을 한다.
• 블랙박스 테스트: 내부 구조를 보지 않고 명세의 입출력으로 시험한다.
• 화이트박스 테스트: 내부 로직과 코드 구조를 기준으로 경로를 시험한다.
• 커버리지: 시험이 대상 코드나 명세를 얼마나 덮었는지 나타내는 비율이다.

2. 개념 풀이

쉬운 말로 하면 만든 소프트웨어를 실제로 써 보면서 틀린 곳을 찾는 일이다. 사람이 실수하면 코드에 결함이 남고, 테스트는 그 결함이 사용자에게 도달하기 전에 드러내는 장치다.

정식 정의는 ISO/IEC/IEEE 24765 같은 용어 표준에서 확인한다. 테스트는 소프트웨어나 구성요소를 실행하거나 분석하여 요구된 조건을 충족하는지 판단하는 활동으로 정리된다. 답안에서는 이 정의를 기준으로 목적, 대상, 방법을 차례로 설명한다.

테스트의 본질은 검증과 확인으로 나뉜다. 검증은 산출물이 명세를 따르는지 보고, 확인은 사용자 요구를 충족하는지 본다. 같은 실행이라도 목적에 따라 판정 기준이 달라진다.

테스트는 크게 동적 테스트와 정적 테스트로 나뉜다. 동적 테스트는 프로그램을 실행하여 입력에 대한 출력을 본다. 정적 테스트는 실행 없이 코드나 문서를 검토한다. 동적 분석은 유닛, 통합, 시스템, 인수 테스트 단계에서 쓰인다는 설명이 일반적이다.

이 중 블랙박스 테스트는 명세 기반으로 입출력만 검사한다. 기능 동작을 확인하며 유닛부터 인수 테스트까지 여러 수준에 적용된다. 화이트박스 테스트는 구조 기반으로 내부 경로를 골라 입력을 정한다. 두 방식은 관점이 다르므로 상호 보완 관계이며, 한쪽만으로는 결함 전체를 덮기 어렵다.

경험 기반 테스트는 테스트 인력의 지식과 경험으로 케이스를 도출한다. 대상 시스템과 도메인에 대한 지식이 중요하며, 주로 블랙박스 방식으로 수행된다.

테스트 오라클은 기대 결과를 제공한다. 오라클이 없으면 실행은 가능해도 결과가 맞는지 판정할 수 없다. 따라서 명세가 명확할수록 테스트의 판정 품질이 올라간다.

테스트의 목적은 결함을 찾는 것이며, 결함이 없음을 증명하는 것이 아니다.

3. 등장 배경과 필요성

초기 소프트웨어는 규모가 작아 개발자가 직접 실행해 보는 수준으로 충분했다. 시스템이 커지고 여러 모듈이 얽히면서 결함의 조합을 사람이 모두 확인할 수 없게 됐다. 그 결과 시험을 독립된 활동으로 계획하고 기록하는 체계가 필요해졌다.

결함 비용의 관점도 중요하다. 결함은 발견 시점이 늦을수록 수정 비용과 영향 범위가 커진다. 요구사항이나 설계 단계의 결함이 운영 단계에서 드러나면 재설계와 재시험이 함께 필요하다. 따라서 개발 초기부터 테스트를 계획하는 조기 테스팅이 권장된다.