글
테스트는 가장 유명한 품질 향상 활동이다.
- 단위 테스트는 한명의 프로그래머나 팀에 의해서 작성되고 보다 완벽한 시스템으로부터 고립되어 테스트된 완벽한 클래스나 루틴, 또는 작은 프로그램을 실행시키는 것이다
- 컴포넌트 테스트는 여러 프로그래머 또는 프로그래밍 팀의 작업에 필요하고, 보다 완벽한 시스템으로부터 고립되어 테스트된 클래스, 패키지, 작은 프로그래머 또는 다른 프로그램의 요소들을 실행시키는 것이다.
- 통합테스트는 여러프로그래머 또는 프로그래밍 팀에 의해서 작성된 두개 이상의 클래스, 패키지, 컴포넌트 또는 서브 시스템의 결합을 실행시키는 것이다.
- 회귀테스트는 이전에 통과했던 테스트 집합을 가지고 소프트웨어에 있는 결함을 찾기 위해서 이전에 실행했던 테스트 케이스를 반복하는 것이다.
- 시스템 테스트는 다른 소프트웨어와 하드웨어 시스템과의 통합을 포함한 최종 환경에서 소프트웨어를 실행시키는 것이다. 이 테스트는 보안, 성능, 자원 손실, 시간문제, 그리고 저수준 통합에서는 테스트될수 없는 다른 문제들을 테스트한다.
테스트는 내부를 볼수 있는 whitebox와 내부를 볼수 없는 blackbox로 분류된다. 테스트는 오류를 발견하기 위한 방법이고 디버깅은 이미 발견된 오류의 원인을 진단하고 수정하는 방법이다. 테스트의 결과는 품질의 지표이고
이것을 해결하려고 해야 한다.
개발자 테스트에 대한 바람직한 접근 방법
- 각각의 연관된 요구사항들이 구현되었는지를 보장하기 위해서 테스트를 하라.
- 각각의 연관된 설계 사항들이 구현되었는지를 보장하기 위해서 테스트를 하라.
- 요구사항과 설계의 테스트에 상세 테스트 케이스를 추가하기 위해서 '기초 테스트'를 사용하라
- 지금까지 또는 이전 프로젝트에서 발견한 오류의 목록에 대한 체크리스트를 사용하라
테스트 케이스를 먼저 작성하고 개발해야 하는 이유
- 코드를 작성하기 전에 테스트 케이스를 작성하면 코드를 작성한 후에 테스트 케이스를 작성하는 것보다 더 적은 노력이 든다
- 테스트 케이스를 먼저 작성하면 결함을 미리 발견할수 있으며, 보다 쉽게 수정할수 있다
- 테스트 케이스를 먼저 작성하면 코드를 작성하기 전에 최소한 요구사항과 설계에 대해서 좀 더 생각하게 되며, 이는 더 좋은 코드를 만든다.
- 테스트 케이스를 먼저 작성하면 코드가 작성되기 전에 요구사항에 있는 문제를 조기에 노출시킨다. 왜냐하면 요구사항이 잘못되어 있으면 테스트 케이스를 작성하기가 어렵기 때문이다
- 만약 수행해야 하는 테스트 케이스을 저장해 놓는다면, 처음뿐만 아니라 나중에도 테스트 할수 있다
개발자 테스트의 한계
- 개발자 테스트는 "깨끗한 테스트"가 되기 쉽다.
- 개발자 테스트는 테스트 커버리지를 낙관적으로 바라 보는 경향이 있다
- 개발자 테스트는 보다 정교한 테스트 커버리지를 하지 않는다.
테스트 하는데 나쁜 데이터
- 너무 적은 혹은 전혀 없는 데이터
- 너무 많은 데이터
- 틀린 종류의 데이터 - 타당하지 않은 것-
- 잘못된 크기의 데이터
- 초기화되지 않은 데이터
좋은 데이터 - 프로그램에 있는 오류를 찾으려고 할때, 정상적인 경우가 오류를 포함할수 있다는 사실을 간과하기 쉽다. 그래서
- 예정된 케이스, 일반적이고 예상된 값
- 최소한의 정상적인 구성
- 최대한 정상적인 구성
- 이전 데이터와의 호환
전형적인 오류 분류
- 대두분의 오류가 발생하는 범위는 상당히 제한되어 있다
- 많은 오루들이 구현의 도메인 밖에 있다
- 대부분의 구현 오류들이 프로그램의 잘못이다.
- 오타오류(typo)는 굉장히 많이 발생하는 문제이다.
- 설계를 잘못 이해하는 것은 프로그램의 오류에 대한 연구에서 계속 나타나는 주제이다.
- 대부분의 오류들은 수정하기 쉽다
- 자신이 속한 조직의 오류에 대한 경험을 측정하는 것은 좋은 생각이다.
이 글은 스프링노트에서 작성되었습니다.
RECENT COMMENT