소프트웨어 테스트

소프트웨어 테스트()는 주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정이다. 소프트웨어 테스트는 또한 소프트웨어에 대한 객관적이고 독립적인 시각을 제공하여 사업주체가 소프트웨어 구현의 위험성을 올바로 이해하도록 한다. 시험 기술에는 프로그램이나 응용 프로그램을 실행하여 소프트웨어 버그를 찾는 절차를 포함되나 이에 국한되지는 않는다.

 개요 
 소프트웨어 결함이 어떻게 일어나는가 
ISTQB는 소프트웨어 결함이 다음의 과정을 통해 일어난다고 언급한다:
인간은 코드, 소프트웨어, 시스템, 또는 문서 안에 결함을 만들어내는 오류(실수)를 범할 수 있다. 결함 코드가 실행되면 시스템은 바라던 결과에 대해 실패하거나, 바라지 않던 결과로 인해 실패할 수 있다. 소프트웨어, 시스템, 문서 안의 결함은 실패로 이어질 수 있지만 모든 결함이 그러한 것은 아니다.환경이 바뀌면 결함은 실패로 바뀔 수 있다. 환경 속의 이러한 변화의 예는 새로운 하드웨어 플랫폼에서 실행되거나, 소스 데이터가 바뀌거나 다른 소프트웨어와 상호 작용하는 것을 들 수 있다.

 모든 결함을 찾는 것은 불가능하다 
소프트웨어 테스트의 문제는 단순 제품 이상의 것을 테스트할 때 전반적인 입력, 사전 대비가 가능하지 않다는 것이다. 이는 소프트웨어 제품 안의 결함 수가 매우 많으며 드물게 일어나는 결함의 경우 테스트 동안 찾아내기 힘들다는 것을 뜻한다.

 역사 
테스트와 디버깅을 구별하는 것은 1979년 글렌포드 J 마이어스(Glenford J. Myers)가 처음 사용한 것이다.
 1956년까지 - 디버깅 지향until 1956 it was the debugging oriented period, when testing was often associated to debugging: there was no clear difference between testing and debugging. 
 1957-1978년 - 증명 지향From 1957-1978 there was the demonstration oriented period where debugging and testing was distinguished now - in this period it was shown, that software satisfies the requirements. 
 1979-1982년 - 파괴 지향The time between 1979-1982 is announced as the destruction oriented period, where the goal was to find errors. 
 1983-1987년 - 평가 지향1983-1987 is classified as the evaluation oriented period: intention here is that during the software lifecycle a product evaluation is provided and measuring quality. 
 1988-2000년 - 보존 지향From 1988 on it was seen as prevention oriented period where tests were to demonstrate that software satisfies its specification, to detect faults and to prevent faults. 
 2000년 - 전진 - 초기 고객 간섭 (베타 테스팅)

 같이 보기 
 정적 코드 분석
 결함 추적
 모델 기반 테스트

 각주 

 외부 링크