반응형

정적 테스트(Static Test)

개발된 프로그램을 돌려보지 않고, 명세서나 코드만을 보고 테스트를 하는 방법이다. 말그대로 정적인 테스트이다.

정적테스트안에서 화이트 박스 / 블랙 박스 테스트로 나눌 수 있다.


정적 화이트박스 테스트(Static WhiteBox Test)


프로그램을 실행하지 않고 소프트웨어의 설계, 코드나 구조 등에서 상세하게 버그를 찾을 수 있는 방법이다.

테스트하는 방법으로는 동료검토(Peer Reviews), 워크스루(Walk throughs), 검사(Inspections) 등이 있다.

이 테스트를 하기 위해서 일반적으로 데이터 참조오류, 데이터 선언 오류, 연산 오류, 비교 오류, 제어흐름 오류, 파라미터 오류, 입출력 오류 등과 같은 코드 검토 체크리스트를 사전에 정해놓고 검사한다.

 

정적 블랙박스 테스트(Static BlakBox Test)

프로그램의 소스코드를 파악할 수도 없고, 실행시키지도 않는 상태에서 수행하는 검사이다. 따라서 프로그램 명세서에 대한 테스트가 이에 해당한다.

제품 개발의 방향을 잡아주는 개발 명세서의 완결성, 정확성, 정밀성, 일관성, 연관성, 실행 가능성, 코드와의 무관성, 테스트가능성 등을 판단하는 작업이다.

기획팀에서 만든 프로젝트 기획문서를 보고 리뷰를 하면서 개선사항, 문제가 될만한 부분들, 구현가능성, Validation 체크 등에 대한 사항들을 기획팀에 많이 피드백을 준다

 


동적 테스트(Dynamic Test)

정적테스트와 달리 개발된 프로그램을 돌려보면서 테스트를 하는 방법이다.  직접 실행하면서 개발이 잘 되었는지, 특정한 상황에 대해 오류가 발생하지는 않는지 검사를 한다.


동적 화이트박스 테스트(Dynamic Whitebox Test)

쉽게 말하면 , 프로그램을 돌리면서 소스코드를 확인하는 방법이다.

코드의 역할과 작동 방법을 관찰하여 테스트에서 배재할 대상이나, 중점적으로 보아야 할 영역, 테스트 접근 방법등을 결정한다.

코드의 근본적인 구조를 관찰하고 이를 사요하여 테스트를 설계하고 수행한다는 측면에서 구조적 테스팅(Structual Test)이라고도 불린다.

소프트웨어를 제어하면서 직접 테스트를 진행한다.


동적 화이트 박스 vs 디버깅

가만히 살펴보면 디버깅과 동적 화이트박스 테스트가 뭐가 다른지 혼란스러울 수 있다.

동적 화이트 박스 테스트의 목표는 버그 발견.

디버그의 목표발견된 버그에 대한 수정.

하지만 버그가 발생하는 곳, 원인을 분리하려는 영역에서는 중복된다고 볼 수 있다.


동적 블랙박스 테스트(Dynamic BlackBox Test)

동적 화이트박스 테스트가 소스코드를 분석하며 프로그램을 돌리는 방식이였다면, 블랙박스 테스트는 소스코드의 구조는 배제한체 그저 프로그램을 실행하며, 사용자의 입장에서 테스트를 진행하는 방식으로 볼 수 있다.

실제 수행하며 테스트하는 의미로 동작 테스트(Behavioral test)라고도 한다.

테스트 케이스를 설계하고 이에 따라 테스트를 수행해보면서 문제점을 발견한다.

여러가지 상황에 대해 프로그램이 정상적으로 동작하는지, 오류처리는 제대로 되는지에 대한 테스트를 수행하는데,

당연히 이 세상에 존재하는 모든 입력값이나 상황들을 조합해서 테스트를 할 수 없기 때문에 상황에 따라 ‘적당한’  테스트 케이스를 설계하는것이 필수적이다.

그 기법으로는 동등분할(Equivalence partitioning), 경계값 분석(Boundary condition),  실패를 위한 상태 테스트(반복, 스트레스, 부하) 등이 있다.

반응형

+ Recent posts