테스트 드라이버와 테스트 스텁의 개념 이해 (테스트 하네스에 포함)
출처 : [네이버 지식백과] 단위 테스트 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 한빛아카데미(주))
출처 : [네이버 지식백과] 통합 테스트 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 한빛아카데미(주))
단위 테스트
단위 테스트(unit test)는 프로그램의 기본 단위인 모듈을 테스트하여 모듈 테스트(module test)라고도 한다. 구현 단계에서 각 모듈의 개발을 완료한 후 개발자가 명세서의 내용대로 정확히 구현되었는지를 테스트한다. 즉 개별 모듈이 제대로 구현되어 정해진 기능을 정확히 수행하는지를 테스트한다. 화이트박스 테스트와 블랙박스 테스트를 모두 사용할 수 있지만 모듈 내부의 구조를 구체적으로 들여다볼 수 있는 화이트박스 테스트 같은 구조적 테스트를 주로 시행한다.
단위 테스트가 개발된 모듈만 테스트하기 때문에 쉬울 것 같지만, 시스템은 수많은 모듈이 서로 정보를 주고받으며 연결되어 있다. 즉 테스트할 모듈을 호출하는 모듈도 있고, 테스트할 모듈이 호출하는 모듈도 있다. 따라서 한 모듈을 테스트하려면 그 모듈과 직접 관련된 상위 모듈과 하위 모듈까지 모두 존재해야 정확히 테스트할 수 있다.
그러나 하나의 모듈을 테스트할 때 상위나 하위 모듈이 개발이 안 된 경우도 있다. 이때 상위나 하위 모듈이 개발될 때까지 기다릴 수는 없으므로 가상의 상위나 하위 모듈을 만들어 사용해야 한다. 상위 모듈의 역할을 하는 가상의 모듈을 테스트 드라이버(test driver)라 하고 그 역할은 테스트할 모듈을 호출하는 것이다. 즉 필요한 데이터를 인자를 통하여 넘겨주고, 테스트가 완료된 후 그 결과 값을 받는 역할을 해준다.
반대로 하위 모듈의 역할을 하는 모듈을 테스트 스텁(stub)이라고 한다. 스텁 모듈은 테스트할 모듈이 호출할 때 인자를 통해 받은 값을 가지고 수행한 후 그 결과를 테스트할 모듈에 넘겨주는 역할을 한다. 따라서 드라이버와 스텁 모듈은 테스트할 때 필요한 기능만 제공할 있도록 단순히 구현한다.
[그림 8-23]은 드라이브와 스텁 모듈이 테스트 대상과 맺는 관계를 보여준다.
단위 테스트를 수행하면 다음과 같은 오류를 발견할 수 있다.
• 잘못 사용한 자료형
• 잘못된 논리 연산자
• 알고리즘 오류에 따른 원치 않는 결과
• 틀린 계산 수식에 의한 잘못된 결과
• 탈출구가 없는 반복문의 사용
통합 테스트
목차
단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트가 통합 테스트(integrationtest)이다. 실제 업무에서는 단위 모듈이 개별적으로 존재하는 것이 아니고 여러 모듈이 유기적 관계를 맺고 있으므로 이러한 모듈들을 결합한 형태로 테스트를 수행해봐야 한다. 이때 주로 확인하는 것은 '모듈 간의 상호작용이 정상적으로 수행되는가'이다. 즉 모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지를 체크한다.
개별 모듈을 테스트하는 단위 테스트에서는 오류가 발견되지 않았어도, 모듈을 통합하면 상호 간의 인자나 공유 데이터 구조 등에서 오류가 발생할 수 있다. 또 단위 테스트 시 가상의 드라이버와 스텁 모듈을 만들어 테스트를 잘 수행했더라도, 상당히 제한적인 여건에서 테스트를 수행한 것이다. 그러므로 실제 모듈 통합 시에는 다른 결과가 나올 수도 있다. 실제 개발에서는 모듈 간의 상호작용과 인터페이스에서 많은 오류가 발생하는 것을 볼 수 있다. 그러므로 통합 테스트가 필요한데, 그 방법에는 모듈 통합을 한꺼번에 하는 방법과 점진적으로 하는 방법이 있다.
모듈 통합을 한꺼번에 하는 방법으로는 빅뱅(big-bang) 테스트를 들 수 있다. 빅뱅 테스트는 단위 테스트가 끝난 모듈을 한꺼번에 결합하여 수행하는 방식이다. 이 방법은 소규모 프로그램이나 프로그램의 일부를 대상으로 하는 경우가 많고 그만큼 절차가 간단하고 쉽다. 그러나 한꺼번에 통합하면 오류가 발생했을 때 어떤 모듈에서 오류가 존재하고 또 그 원인이 무엇인지 찾기가 매우 어렵다.
모듈 통합을 점진적으로 하는 방법은 모듈 통합을 한꺼번에 하는 방법의 문제를 극복하는 방법으로, 완성된 모듈을 기존에 테스트된 모듈과 하나씩 통합하면서 테스트한다. 문제가 발생하면 바로 직전에 통합하여 테스트한 모듈에서 오류가 발생했다고 짐작할 수 있으므로 오류를 찾기가 쉽다. 점진적 통합 방식은 가장 상위에 있는 모듈부터 테스트하는지, 가장 하위에 있는 모듈부터 테스트하는지에 따라 하향식 기법과 상향식 기법으로 나뉜다.
1. 점진적 모듈 통합 방법 : 하향식 기법
하향식(top-down) 기법은 시스템을 구성하는 모듈의 계층 구조에서 맨 상위의 모듈부터 시작하여 점차 하위 모듈 방향으로 통합하는 방법이다.
[그림 8-24]의 예에서 맨 상위 모듈 A를 모듈 B와 통합하여 테스트한다. 그다음으로 모듈 C를 먼저 선택할지, 아니면 B 아래에 있는 모듈 E를 먼저 선택할지 결정해야 한다. 이때 모듈 C를 먼저 선택하는 방식을 넓이 우선(breadth first) 방식이라 하고 모듈 E를 먼저 선택하는 방식을 깊이 우선(depth first) 방식이라 한다.
넓이 우선 방식으로 테스트하면 (A, B)→(A, C)→(A, D)→(A, B, E)→(A, B, F)→(A, C, G)와 같이 같은 행에서는 옆으로 가며 통합 테스트를 한다. 반면, 깊이 우선 방식에 따라 테스트하면 (A, B)→(A, B, E)→(A, B, F)→(A, C)→(A, C, G)→(A, D) 순으로 통합하며 테스트한다. 즉 하위 방향으로 내려가면서 통합하지만, 같은 행에서는 옆이 우선이 아니라 그 아래 모듈을 먼저 통합하여 테스트한다. 또한 하향식 방식에서는 상위 모듈부터 테스트를 수행하기 때문에 단위 테스트에서 설명한 스텁 모듈이 필요하다.
일반적으로 모듈의 종속 관계에서 상위 모듈은 시스템 전체의 흐름을 관장하고, 하위 모듈은 각 기능을 구현하는 형태로 구성되어 있다. 그러므로 하향식 기법을 이용하면 프로그램 전체에 영향을 줄 수 있는 오류를 일찍 발견하기가 쉽다. 그러나 하위 모듈이 임시로 만든 스텁들로 대체되어 결과가 완전하지 않을 수도 있고 스텁 수가 많으면 스텁을 만드는 데 시간과 노력이 많이 들 수 있다. 따라서 모듈 간의 인터페이스와 시스템의 동작이 정상적으로 잘되고 있는지를 빨리 파악하고자 할 때 하향식 기법을 사용하는 것이 좋다.
2. 점진적 모듈 통합 방법 : 상향식 기법
상향식(bottom-up) 기법은 하향식 기법과는 반대로 가장 말단에 있는 최하위 모듈부터 테스트를 시작한다. 하향식에서 스텁이 필요했다면, 상향식에서는 상위 모듈의 역할을 하는 테스트 드라이버가 필요하다. 이 드라이버는 하위 모듈을 순서에 맞게 호출하고, 호출할 때 필요한 매개 변수를 제공하며, 반환 값을 전달하는 역할을 한다.
[그림 8-24]에서 상향식 기법을 이용하여 테스트하는 순서는 다음과 같다. 우선 가장 말단(레벨 3)에 있는 모듈 E와 F를 모듈 B에 통합하여 테스트한다. 그다음 모듈 G를 모듈 C에 통합하여 테스트한다. 마지막으로 모듈 B, C, D를 모듈 A에 통합하여 테스트한다.
상향식 기법의 장점은 최하위 모듈들을 개별적으로 병행하여 테스트할 수 있기 때문에 하위에 있는 모듈들을 충분히 테스트할 수 있다는 것이다. 또한 정밀한 계산이나 데이터 처리가 요구되는 시스템 같은 경우에 사용하면 좋다. 그러나 상위 모듈에 오류가 발견되면 그 모듈과 관련된 하위의 모듈을 다시 테스트해야 하는 번거로움이 생길 수 있다.
'ITPE > SE' 카테고리의 다른 글
소프트웨어 테스팅 국제표준 - ISO 29119 (0) | 2021.02.19 |
---|---|
CMMI (0) | 2018.04.12 |
TOC-Thinking Process (0) | 2018.04.06 |