1장 테스트 개요 - 1.3 테스트의 현실/실제

1.3 테스트의 현실/실제

1. 완벽한 테스트의 비현실성
2. 테스트의 진화 과정
3. 테스트 원칙

---

1.3.1 완벽한 테스트의 비현실성

어느 코드에 결함이 있는지 알 수 없기 때문에 결함을 검출하기 위해서는 많은 수의 테스트 케이스 필요

But 무한한 입력값이 필요하고 모든 조합을 테스트하는 것은 현실적으로 불가능

So 주어진 인력과 시간을 바탕으로 최대한 효과적&효율적으로 테스트를 수행할 수 있도록 체계적으로 해야함

 

1.3.2 테스트의 진화 과정

겔퍼린과 헤첼의 소프트웨어 테스트 개념의 진화 과정

 

레벨1

Debugging-oriented, ~1956년

테스트와 디버깅에 뚜렷한 차이가 없는 레벨

우연히 발견된 결함을 수정하는 디버깅에 중점을 두고 프로그램의 결함을 찾기 위한 별도의 노력은 없음

 

레벨2

Demonstration-oriented, 1957~1978

프로그램이 올바르게 동작한다는 사실을 입증하기 위한 테스트

시스템의 정상 작동을 증명하는 테스트 케이스

 

레벨3

Destruction-oriented, 1979~1982

프로그램에 결함이 존재함을 보여주기 위한 테스트

프로그램의 결함을 발견하는 테스트 케이스가 가치 있음

 

레벨4

Evaluation-oriented, 1983~1987

소프트웨어 개발 전(all) 단계에서 발생하는 결함을 발견하는 개념으로 확장

코딩 완료 후 테스트 시작이 아닌, 개발 초기 단계뿌터 지속적으로 평가

 

레벨5

Preventaion-oriented, 1988~

결함을 사후 발견하는 것이 아닌, 아예 결함이 발생하지 않도록 사전에 방지

개발 초기부터 테스트가 용이하도록 시스템을 설계

 

1.3.3 테스트 원칙

G.J.마이어스, The Art of Sortware Testing

• 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹이 수행
• 결함이 발견되지 않으리라는 가정하에 테스트 계획을 수립해서는 안 된다 - 겔퍼린과 헤첼의 레벨3
• 타당한 경우 + 타당하지 않은 경우 모두 테스트를 수행
• 프로그램의 어떤 부분에 결함이 남아 있을 확률은 그 부분에서 이미 발견된 결함의 수에 비례 - 결함이 많이 발생한 부분을 중점적으로 테스트
• 테스트 케이스를 체계적으로 관리 - 기존에 만들었던 테스트 케이스를 재사용하는 것이 바람직
• 각각의 테스트 결과를 철저히 점검