‘시스템의 명세까지 완벽하게 옳다고 확신할 수는 없고, 테스트 시스템이 프로그램을 완전히 테스트 할 수 없다. 왜냐하면 테스트 시스템 그 자체도 맞다고 증명할 수 없기 때문이다.’ - Zohn Manaa

‘프로그램 테스트는 결함이 있음을 보여줄 뿐, 결함이 없음을 증명할 수는 없다’ - Dahl, Dijkstra, Hoare

… 즉, 사람이 만드는 실수라는 말은 시스템과 관련되어 있는 모든 관련자가 만들어 내는 실수가 시스템에 영향을 준다는 것을 의미한다.

테스트는 일반적으로 다음과 같이 네 단게로 나뉜다 컴포넌트 테스트 - 단위, Unit 테스트 통합 테스트 - 컴포넌트 사이의 인터페이스를 테스트 시스템 테스트 - 개발된 시스템이 제대로 작동하는지에 확인(Verification) 인수 테스트 - 고객이 시스템을 검수(Validation)

• jUnit, Ant, Mock, HttpUnit, jUnitPert

즉, 스텁은 해당 컴포넌트에 개발자나 테스터가 쉽게 접근할 수 있는데 그 다음 프로세스를 수행할 부분이 아직 개발되지 않았거나, 접근 가능한 컴포넌트만 테스트하고 싶을 때 사용하는 것이다.

각각의 단계에서 작성된 산출물들이 각 테스트 단계와 어떤 연관성이 있는지를 보여주는 것이 바로 V-Model이다.

블랙 박스 테스트는 결과만을 갖고 수행하는 테스트이기 때문에 실제 요구사항의 명세와 같은지를 확인하는 명세 기반(Specification based) 테스트라고 한다

화이트 박스 테스트는 소스 내부의 구조를 분석하는 테스트이기 때문에 구조 기반(Structure based) 테스트라고 한다.

경계 값 분석은 말 그대로 최소 입력 값, 최대 입력 값을 예측하여 그 경계에 있는 값을 도출해 내는 것이다.

Pair Programming은 두 명의 개발자가 같이 개발하여 디버그하고, 리뷰하는 개발 방식이라고 할 있다.

• PMD, FindBugs, CheckStyle

Continuous Integration(지속적인 통합, CI)의 장점 결함을 초기에 찾을 수 있다 프로그램을 토압하는데 소요되는 시간을 단축시킬 수 있다 자동화된 일일 빌드가 가능하다 테스트 코드가 작성되어 있다면, 자동화된 일일 테스트를 할 수 있다. 완벽하지는 않지만 개발 진척도를 점검하기 위한 좋은 참고 자료가 된다 *AntHill, Hudson

기본적으로 성능 테스트를 하는 주된 이유는 다음과 같다. 오픈 시 안정성 보장 시스템의 병목 구간 사전 발견 및 조치 시스템의 오류 사적 확인 각종 아키텍처의 검증 오픈될 시스템이 허용할 수 있는 최대 사용자 예상

웹에서 트랜잭션은 크게 두 가지로, 요쳥(Request) 기준 트랜잭션과 사용자(User) 트랜잭션으로 나뉜다. 요청 기준 트랜잭션은 하나의 요청을 하나의 트랜잭션으로 보는 것이다. 즉 JSP나 Servelet을 한 번 호출하여 결과가 리턴되면 한 트랜잭션이 처리된 것이다. 사용자 트랜잭션은 WAS나 서버의 기준이 아닌 사용자 기준으로 트랜잭션을 보는 것이다. 다시 말하면 사용자가 클릭을 한 번 하고, 모든 데이터가 처리되어 화면에 표시되었을 때를 의미한다.

TPS는 Transaction Per Second의 약자로 초당 처리 트랜잭션 수를 의미한다.

• JMeter, Grinder, Faban

보안테스트는 악의적이거나 적대적인 입력에 대응할 수 있도록 정의되어 있는 요구사항을 만족시키는지 확인하고, 근거를 제공하는 것이다

보안 테스트에 사용되는 데이터 종류 Base 8 : 8진수 기준 Base 16 : 16진수 기준 Base 36 : 0~9, A~Z로 이루어진 36진수 Base 64 : 0~9, A~Z, a~z, +, /로 이루어진 64진수 URL 인코딩 : %와 16진수가 결합된 형태 MD5 : 정확히 128비트의 데이터를 생성하는 방식 SHA1 : 정확히 160비트의 데이터를 생성하는 방식

• CAL9000, Burp Suite, WebGoat