용어 목록 > 통합 테스트 (Integration Testing)

통합 테스트 (Integration Testing)

쉽게 풀면

자동차를 만들 때 엔진, 바퀴, 브레이크를 각각 따로 시험해서 잘 작동한다고 확인했다고 해도, 이걸 하나로 조립했을 때 문제없이 굴러간다는 보장은 없습니다. 엔진의 출력과 바퀴의 크기가 안 맞을 수도 있고, 브레이크 신호가 엔진 제어 장치와 충돌할 수도 있습니다. 소프트웨어도 마찬가지입니다.

각 기능을 담당하는 모듈 하나하나는 단위 테스트로 검증했더라도, 로그인 모듈과 결제 모듈을 연결했을 때 데이터가 올바르게 주고받아지는지는 별도로 확인해야 합니다. 이렇게 여러 모듈이 "합쳐졌을 때"의 동작을 검증하는 과정이 통합 테스트입니다.

왜 중요한가

소프트웨어시스템이 마이크로서비스나 다양한 외부 API로 구성되는 경우가 많아지면서, 개별 모듈의 정확성만으로는 전체 시스템의 신뢰성을 보장할 수 없게 되었습니다. 통합 테스트는 모듈 간 인터페이스 불일치, 데이터 형식 오류, 네트워크 지연 등 단위 테스트로는 잡아내기 어려운 문제를 발견하는 단계로서, 소프트웨어공학 논문에서 시스템 검증 방법론을 설명할 때 핵심적으로 다뤄집니다.

어떤 절차인가

통합 테스트는 단위 테스트를 통과한 모듈을 실제로 이어 붙인 상태에서 모듈 사이의 약속(인터페이스)이 지켜지는지 확인하는 단계입니다. 전형적인 절차는 다음과 같습니다.

1. 결합할 모듈과 그 사이의 인터페이스(함수 호출, API, 메시지, 데이터베이스 접근)를 정합니다.
2. 정상 흐름과 예외 흐름(오류 응답, 시간 초과, 재시도)을 시나리오로 설계합니다.
3. 아직 없는 모듈은 임시 대역으로 채웁니다. 상위 모듈을 대신하는 것이 드라이버, 하위 모듈을 대신하는 것이 스텁입니다.
4. 시나리오를 실행하고, 실패하면 어느 인터페이스에서 어긋났는지 좁혀 갑니다.

결합 순서에 따라 네 가지 전략이 흔히 구분됩니다.

• 빅뱅: 모든 모듈을 한 번에 결합합니다. 빠르지만 실패 원인을 찾기 어렵습니다.
• 상향식: 하위 모듈부터 쌓아 올립니다. 상위 모듈이 없는 동안 드라이버가 필요합니다.
• 하향식: 상위 모듈부터 시작하고 하위는 스텁으로 둡니다.
• 샌드위치(혼합): 위와 아래에서 동시에 결합해 가운데에서 만납니다.

언제 쓰고 무엇을 얻나

통합 테스트가 잡아내려는 것은 모듈 하나만 볼 때는 보이지 않는 결함입니다. 예를 들어 자료형이나 단위가 서로 다르게 가정된 경우, 호출 순서나 상태 공유가 어긋난 경우, 외부 서비스 응답이 늦거나 실패하는 경우가 여기에 속합니다.

• 얻는 것: 인터페이스 결함의 조기 발견, 결합 후 동작에 대한 증거, 장애 상황에서 시스템이 어떻게 행동하는지에 대한 확인.
• 비용: 단위 테스트보다 느리고, 테스트 환경(데이터베이스, 외부 서비스 대역)을 준비해야 하며, 실패했을 때 원인 모듈을 가리기 어렵습니다.
• 그래서 실무에서는 빠른 단위 테스트를 많이, 통합 테스트를 그보다 적게 두는 구성이 권장되어 왔습니다(콘이 널리 알린 ‘테스트 피라미드’).

논문에는 이렇게 적는다

통합 테스트를 보고할 때는 재현할 수 있게 다음을 적습니다.

• 대상: 결합한 구성 요소와 인터페이스의 목록, 결합 전략.
• 환경: 소프트웨어 버전, 테스트 데이터, 실제 외부 서비스를 썼는지 대역(mock)을 썼는지.
• 시나리오: 정상 흐름과 예외 흐름의 수와 선정 기준.
• 결과: 통과·실패 건수, 발견한 결함의 종류(인터페이스, 자료 형식, 시간 초과 등), 실행 시간.
• 한계: 테스트 커버리지 수치가 높아도 통합 시 생기는 문제가 모두 걸러졌다는 뜻은 아니라는 점, 테스트 환경과 실제 운영 환경의 차이.

논문에서는 이렇게 쓰입니다

실제 논문에서

이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.

예시 문장

아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.

이 문장은 먼저 함수 하나하나가 올바르게 동작하는지 확인한 다음, 여러 구성 요소를 실제로 연결한 상태에서 데이터가 잘 오가는지까지 검증했다는 뜻입니다.

분산시스템 연구에서는 여러 서비스가 네트워크를 통해 상호작용할 때 발생할 수 있는 장애와 예외 상황까지 포함해 통합 테스트를 설계하는 경우가 흔합니다.

조금 더 깊게 보면

통합 테스트는 접근 방식에 따라 하위 모듈부터 점진적으로 결합해나가는 상향식(bottom-up), 상위 모듈부터 시작해 하위 모듈을 임시 대역(스텁)으로 대체해가는 하향식(top-down), 전체를 한 번에 결합하는 빅뱅 방식 등으로 나뉩니다. 실제 모듈이 아직 준비되지 않은 부분은 스텁이나 목(mock) 객체로 대체해 테스트를 진행하기도 하며, 이런 전략 선택이 오류 발견 시점과 디버깅 난이도에 영향을 미칩니다.

주의할 점

통합 테스트는 단위 테스트보다 범위가 넓어서 오류가 발생했을 때 정확히 어느 모듈이 원인인지 찾기가 더 어렵습니다. 그래서 보통 단위 테스트로 개별 부품의 정확성을 먼저 확인한 뒤, 그 위에 통합 테스트를 쌓는 방식으로 진행하며, 테스트 커버리지만 높다고 해서 통합 시 발생하는 문제까지 전부 걸러진다고 착각해서는 안 됩니다.

헷갈리기 쉬운 용어

참고 문헌

1. Myers, G. J. (1979). The Art of Software Testing. Wiley.
2. Beizer, B. (1990). Software Testing Techniques (2nd ed.). Van Nostrand Reinhold.
3. Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley.
4. Sommerville, I. (2016). Software Engineering (10th ed.). Pearson.

표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.

관련 용어