[CSTS] 1장 테스트 개요: 테스트의 목적 오류 결함 장애 테스트 디버깅재테스팅

테스트의 목적

시스템이 정해진 요구사항을 만족하는지 확인하고 주어진 표준 등을 준수하는지 검증하기 위해 수행된다.

• 결함 검출, 품질 평가, 프로세스 개선

결함의 검출과 제품 품질 개선

• 테스트는 결함을 검출하기 위한 목적으로 수행된다.
• 검출된 결함을 제거함으로써 소프트웨어의 품질을 개선한다.

품질 평가와 의사 결정 지원

• 품질을 평가하기 위한 목적으로 테스트를 수행한다.
• 테스트 결과를 바탕으로 성능, 신뢰성, 보안성 등의 다양한 소프트웨어 품질 특성에 대한 충족 수준을 평가한다.
• 평가를 바탕으로 소프트웨어 제품에 대한 의사 결정을 수행한다.

개발 프로세스 개선 지원

• 소프트웨어 개발 과정 중 어떤 단계에서 결함이 발생하는지 분석한다.
• 결함이 왜 검출되지 않았는지 파악함으로써 개발 프로세스 개선에 도움을 준다.
  • 예시: 검출된 결함 중 요구사항 관련 결함이 많다면 요구분석 단계의 프로세스 개선이 필요하며, 요구분석 단계에서의 결함 검출 방법도 개선이 필요하다.

문제

소프트웨어 테스트에 관한 설명 중에서 올바른 것은 무엇인가?

1. 프로그램의 오류를 발견하고 결함을 제거함으로써 프로그램의 품질을 높이는 활동이다.
2. 테스트는 프로그램에 결함이 존재하지 않음을 보여주기 위한 목적으로 수행한다.
3. 타당하지 않고 예상하지 못한 경우들에 대해서는 테스트를 수행하지 않아도 된다.
4. 프로그램을 가장 잘 이해하는 개발자가 직접 테스트를 수행하는 것이 효과적이다.

 

오류, 결함, 장애

오류, 결함, 장애의 개념

오류(Error)

• 사용자의 요구사항을 잘못 파악하거나 잘못 이해하여 발생하는 실수 또는 오타(typo)
• 프로그램 명령어를 잘못 이해하여 코딩하는 경우

결함(Defect)

• 소프트웨어 내에 장애를 유발할 수 있는 문제를 말한다.
  • 누락, 부정확함, 비관련
• 결함이 있다고 해서 반드시 장애가 발생하는 것은 아니다.

장애(Failure)

• 소프트웨어가 요구사항과 다르게 동작하는 경우
• 프로그램의 실행 결과와 요구사항에 명시된 결과에 차이가 있는 경우
• 소프트웨어를 구성하는 요소에 부족한 점이 있어 발생된 것
  • 부정확한 구현, 필요한 기능이 미포함된 경우

결함 유형

누락(Omission)

• 요구 명세에 명시된 요구사항이 시스템의 구현에 반영되지 않은 결함
• 누락 결함에는 기능뿐만 아니라 성능, 보안, 안전, 신뢰도 등 품질 요소에 관한 누락도 포함된다.

부정확함(Incorrect)

• 요구 명세에 명시된 요구사항이 소프트웨어에 부정확하게 반영된 결함

비 관련(Extraneous)

• 요구 명세와 관련되지 않은 구현
  • 예시: 소스코드에서 어떤 부분이 요구 명세에 언급된 기능·품질 등과 무관하다면 비관련 결함에 해당한다. 비관련 결함은 당장 직접적인 장애를 유발하지 않을 수도 있다. 하지만 시스템 기능·품질에 기여하지 않는 무의미한 코드가 존재한다면 이는 불필요한 분석·테스트·관리를 유발하고 결국에는 다른 결함을 초래하는 원인이 될 수 있다.

개발 단계별 결함

• 결함은 소스 코드를 포함하여 소프트웨어 동작의 장애를 유발할 수 있는 모든 개발 산출물에 존재할 수 있다.
• 소스코드 작성하는 구현 단계가 아니라 설계 명세서의 부정확한 설계의 결함이 존재할 수 있다.
• 소프트웨어를 개발하는 각 단계에서 오류를 범할 수 있으므로 각 단계의 산출물에는 결함이 존재할 가능성이 있다.
• 각 단계에서 적절하게 검출하여 제거하지 않으면 이후 단계를 거쳐 소스코드에 영향을 미치며 결국에는 장애를 유발할 수 있다.
• 발생한 시점에 제거되지 않고 이후 개발 단계에 그대로 전달되면 이 결함을 제거하기 위해 더 많은 비용이 소요된다.
  • 결함 해결 비용: 요구분석 0.1 ~ 0.2 / 설계 0.5 / 코딩 1 / 단위 테스팅 2 / 인수 테스팅 5 / 유지보수 20
    • 요구분석 < 설계 < 코딩 < 단위 테스팅 < 인수 테스팅 < 유지보수
• 각 개발 단계의 결과물을 테스트하여 해당 산출물에 존재하는 결함을 최대한 빨리 검출하고 제거해야 한다.

테스트, 디버깅, 재테스팅

디버깅은 테스팅과 다른 개념으로 혼동하여 사용하면 안 된다.

테스팅

• 소프트웨어의 실제 동작과 요구사항과의 차이를 확인
• 결함의 존재 여부를 알 수 없는 상황에서 결함 발견을 목적으로 프로그램을 실행(동적 테스트)
• 소프트웨어에 장애가 있을 때 테스팅에서 해당하는 프로그램 내부에 결함이 존재한다고 추측
• 장애 발생을 확인하여 소프트웨어에 결함이 있음을 간접적으로 판단
• 예상되는 결과와 실제 출력 결과 등을 기록하지만, 이 결함이 소프트웨어의 어떤 모듈에서 발생하였고 이를 해결하기 위해 어떤 코드를 수정해야 하는지에 대해 관여하지 않음

디버깅

• 테스팅을 통해 결함의 존재를 확인한 후에 수행
• 결함의 위치를 파악하고 이를 제거하는 목적
• 테스팅에서 발견된 결함을 알게 되면 디버깅에서는 해당 결함과 관련된 소스코드 위치를 찾는다
• 결함의 위치를 찾아내면 해당 결함을 제거하기 위해 소스코드를 수정한다

재테스팅

• 개발자가 결함을 제거하기 위해 코드를 수정하면 실제로 결함이 제거되었는지 확인하는 절차
• 결함을 검출한 테스트 케이스를 이용해 테스팅을 다시 수행한다

테스트의 현실/실제

완벽한 테스트의 비현실성

• 간단한 소프트웨어인 경우에도 무한한 입력값을 가질 수 있다.
• 무한한 입력값, 무한 시간, 코드 내 무한 경로 등을 모두 고려해 모든 조합을 테스트하는 것은 현실적으로 불가능하다.
• 프로그램 테스트 기술의 한계(다익스트라)
  • 프로그램 테스트는 결함이 있음을 보일 수 있지만, 결함이 없음을 보일 수는 없다.
• 주어진 인력과 시간을 바탕으로 최대한 효과적이고 효율적인 테스트를 수행할 수 있도록 체계적인 테스트가 수행되어야 한다.
• 테스트 전략을 수립함으로써 한정된 비용과 일정 내에서 테스트의 효과를 최대화해야 한다.

문제

완벽한 소프트웨어 테스트는 불가능하다. 다음 중 그 이유를 가장 잘 설명한 것은?

1. 테스트 조직이 작아 할당할 수 있는 테스터가 적기 때문이다.
2. 테스트 지식이 부족하고 테스트 전략과 계획의 완성도가 낮기 때문이다.
3. 개발 일정 대신 테스트 일정을 줄여 결과적으로 충분한 테스트 일정을 확보하지 못하기 때문이다.
4. 무한 입력값, 무한 시간, 코드 내 무한 경로 등을 모두 고려해 테스트할 수 없기 때문이다.

테스트의 진화 과정 (겔퍼린(Gelperin)과 헤첼(Hetzel)의 소프트웨어 테스트 개념의 진화 과정 5 레벨)

• 레벨 1(Debugging-oriented, ~1956): 우연히 발견된 결함을 수정하는 디버깅에 중점을 두며 프로그램의 결함을 찾기 위한 별도의 노력을 기울이지 않는다.
• 레벨 2 (Demonstration-oriented, 1957~1978): 프로그램이 올바르게 동작한다는 사실을 입증하기 위해 테스트를 수행한다. 따라서 결함을 찾을 확률이 높은 테스트 케이스를 설계하기보다는 시스템의 정상 작동을 증명하는 데 초점이 맞추어진 테스트 케이스를 설계하는 경향이 있다.
• 레벨 3 (Destruction-oriented, 1979~1982): 프로그램에 결함이 존재함을 보여주기 위해 테스트를 수행한다. 프로그램이 잘 작동하지 않는다는 사실을 보여주려는 의도로 테스트 케이스를 설계하므로 프로그램의 결함을 발견하는 테스트 케이스가 그렇지 못한 테스트 케이스보다 훨씬 더 가치 있다는 인식이 있다.
• 레벨 4 (Evaluation-oriented, 1983~1987): 레벨 3의 테스트가 실제 프로그램 코드에 있는 결함을 발견하는 것에 초점을 맞춘다면 레벨 4의 테스트는 소프트웨어 개발 전 단계에서 발생하는 결함을 발견하는 개념으로 확장한다. 따라서 코딩이 완료된 후에 테스트를 시작하는 것이 아니라 요구사항 분석, 설계, 구현 등 소프트웨어 개발 생명 주기 전 과정에서 테스트를 수행한다.

• 레벨 5 (Prevention-oriented, 1988~): 테스트는 결함을 검출하는 것뿐만 아니라 결함이 발생하지 않도록 예방하는 활동이 된다. 예방 중심의 테스트로 개발 초기부터 결함이 유입되지 않도록 하기 위해 모든 개발 프로세스에서의 활동이 포함된다.

소프트웨어 테스트의 원리

테스팅은 결함이 존재함을 밝히는 활동이다.

• 다익스트라의 프로그램 테스트 기술의 한계: 프로그램 테스트는 결함이 있음을 보일 수 있지만, 결함이 없음을 보일 수는 없다.
• 결함이 없음을 증명할 수는 없으므로 테스트는 결함이 존재함을 밝히는 활동으로 수행되어야 한다.

완벽한 테스팅은 불가능하다.

• 무한한 입력값, 무한 시간, 코드 내 무한 경로 등을 모두 고려해 모든 조합을 테스트하는 것은 현실적으로 불가능하다.

초기에 테스팅을 시작한다.

• 결함 발견 시점이 빠를수록 수정 비용이 줄어든다.
• 소프트웨어 개발 생명 주기 전 단계에서 테스팅이 포함되어야 한다.

결함 집중(파레토 법칙)

• 소프트웨어 결함은 모듈에 집중적으로 분포하는 특성이 있다.
• 대다수의 결함이 적은 수의 모듈에 집중되어 있다.

살충제 패러독스

• 동일한 테스트 케이스를 사용하면 더 이상 결함이 발견되지 않는다.
• 테스트 케이스를 주기적으로 점검 및 개선하여 새로운 테스트 케이스를 작성함으로써 동일한 테스트 케이스를 반복 수행하는 것을 방지해야 한다.

테스팅은 정황에 의존적이다.

• 다양한 테스트 대상 소프트웨어 제품에 대해 하나의 테스트 방법이 적절하지 않다.
• 테스트 대상 소프트웨어의 성격과 목적에 따라 적절한 테스트 방법이 달라져야 한다.

오류 부재의 궤변

• 결함이 없는 것이 성공적인 테스트의 기준이 아니다.
• 요구사항을 만족하지 않는다면 결함이 없다고 해도 품질이 높은 소프트웨어라고 할 수 없다.