Integration Testing이란 무엇인가요?

Integration Testing의 개념은 몇 가지 의문을 제기합니다. 첫 번째는 Integration Testing이 필요한지 여부입니다. 이에 대한 답은 적어도 부분적으로는 해당 회사에 따라 달라집니다. 대중과의 상호 작용이 제한적인 조직은 Integration Testing이 필요하지 않을 수 있습니다.

그러나 대중과 광범위하게 협력하는 모든 기업에게 Integration Testing은 점점 더 중요해지고 있습니다. 새로운 소프트웨어 애플리케이션과 툴을 출시하는 기술 기업이라면 Integration Testing이 더욱 중요합니다.

좋은 첫인상을 남길 수 있는 기회는 두 번 다시 오지 않는다는 격언이 있습니다. 현대 기업에도 동일한 개념이 적용됩니다. 그들 대부분은 사용자들을 끌어들이고, 이들을 정기 구독자나 소비자로 전환한 뒤, 성공적이고 수익성 있는 관계를 지속적으로 유지하기 위해 필사적으로 노력하고 있습니다. 이러한 회사는 블록버스터급 새 프로그램이나 앱을 공개할 때 많은 실수를 할 여유가 없습니다.

소비자는 해당 기술이 설치부터 다른 프로그램 및 시스템과의 상호 작용 방식에 이르기까지 광고된 대로 작동할 것으로 기대합니다. 이러한 이유로 많은 조직에서 Integration Testing은 비즈니스 수행의 필수 단계입니다.

요컨대 Integration Testing의 목표는 부품과 시스템이 안정적으로 함께 작동하는지 확인하는 것입니다. 그러나 PR 관점에서 볼 때 Integration Testing의 또 다른 목표는 현대적인 맥락에서 비즈니스를 안정적으로 수행할 수 있는 책임감 있는 회사로서 조직의 정체성을 보호하는 것입니다.

통합 테스트라는 용어는 특정 "폭포(waterfall)" 방법론을 설명하기 위해 시간이 지남에 따라 개발되었습니다. 이전에는 소프트웨어 모듈과 관련 프로젝트가 진공 상태에서 만들어졌기 때문에 QA 팀은 소프트웨어 시스템에 도입하기 전에 코드베이스의 일부를 개별적으로 테스트하고 테스트 결과를 분석해야 하는 상당한 수고를 감수해야 했습니다.

Integration Testing은 테스트 케이스의 생성 및 평가를 통해 수행됩니다. 첫 번째 단계는 서로 다른 모듈이 상호 작용하는 애플리케이션 내의 영역인 통합 지점을 성공적으로 식별하는 것입니다. 통합 지점이 설정되면 이를 중심으로 테스트 사례가 디자인됩니다. 이러한 테스트 케이스는 다양한 입력 시나리오, 실제 상황 및 예상되는 결과에 따라 통합 지점이 어떻게 작동하는지 보여주기 위해 만들어집니다.

테스트 커버리지에서 수집한 데이터를 사용하여 프로젝트 이해관계자는 모든 프로젝트 데이터가 저장되는 코드베이스에 필요한 조정을 수행할 수 있습니다.

Integration Testing에 사용되는 테스트 케이스는 개발자가 몇 가지 특정 운영 영역에 초점을 맞출 수 있도록 도와줍니다.

Integration Testing의 전체적인 복잡성을 높이는 또 다른 측면은 종속성입니다. 종속성은 모듈 및/또는 구성 요소 간에 존재하는 관계입니다. 일반적인 종속성에서는 하나의 구성 요소가 작동하려면 관련 구성 요소가 먼저 필요에 따라 작동해야 합니다. 프로그램 실행에서 발생할 수 있는 문제를 해결하려고 할 때 이러한 종속성을 고려해야 합니다.

Integration Testing을 수행할 때 수행하는 개별 테스트 단계에는 표준 순서가 있습니다. 이러한 순서가 지정된 시퀀스를 통해 개발자는 다양한 코드를 구조화된 방식으로 체계적으로 평가할 수 있기 때문입니다. 테스트 순서는 일반적으로 가장 단순한 개별 구성 요소를 먼저 검사하여 나중에 작동에 부정적인 영향을 미치기 전에 하위 수준 모듈의 버그를 수정하는 것으로 시작됩니다. 그런 다음 테스트는 더 정교한 통합으로 이동하여 성능을 평가합니다.

버그를 조기에 감지하는 것 외에도 일반적인 테스트 시퀀스는 논리적 진행을 사용하여 코드의 데이터 흐름을 모방함으로써 구성 요소 상호 작용이 올바른 순서로 테스트되는지 확인합니다. 또한 테스트 순서는 낮은 수준의 모듈과 관련된 덜 중요한 테스트에 우선순위를 낮게 지정하여 개발자가 가장 필수적인 작업에 집중할 수 있도록 합니다.

기존 테스트 시퀀스에서는 테스트 형식을 다음 순서로 검사합니다.

1. 개별 함수를 평가하는 단위 테스트.
2. Integration Testing을 통해 구성 요소가 상호 작용하는 방식을 확인합니다.
3. 전체 시스템의 전반적인 기능을 결정하기 위한 시스템 테스트.
4. 사용자관점에서 기능을 확인하는 수락 테스트.

Integration Testing은 이 표준 시퀀스의 초기 테스트 단계가 아닙니다. Integration Testing은 개별 구성 요소 간의 상호 작용에 대한 테스트가 이미 단위 테스트를 통해 수행되었기 때문에 프로세스에서 수행되는 위치에 나타납니다. 그다음 단계인 시스템 테스트는 규모 확장의 관점을 한층 더 넓혀, 테스트 담당자가 전체 시스템을 보다 거시적인 시각에서 바라보고 모든 요소가 얼마나 잘 작동하는지를 평가할 수 있도록 합니다.

Integration Testing 기법에는 다양한 유형이 있지만, 소프트웨어 시스템을 평가하는 데 가장 많이 사용되는 기법은 다음과 같습니다.

하향식 접근 방식은 Integration Testing의 두 가지 주요 유형 중 하나입니다. 서브 모듈과 서브 루틴을 평가하기 전에 메인 모듈과 그 작동에 중점을 둡니다. 이 접근 방식의 가장 강력한 특성 중 하나는 하위 수준 모듈이 완전히 식별되기 전에도 프로세스 초기에 사용할 수 있다는 것입니다. 테스터는 플레이스홀더(스텁이라고 함)를 하위 수준 모듈 대신 사용할 수 있습니다.

Integration Testing의 또 다른 주요 예는 테스트 시퀀스의 순서를 전환하는 상향식 Integration Testing입니다. 상향식 접근 방식에서는 서브 모듈과 서브 루틴이 가장 먼저 평가됩니다. 그런 다음 이 접근 방식은 메인 모듈을 테스트하는 단계로 넘어갑니다. 그리고 상향식 Integration Testing에서는 상위 수준의 구성 요소가 아직 정의되지 않았을 때, 상위 구성 요소를 대신하는 임시 모듈인 드라이버를 사용한다는 점에서, 상향식 Integration Testing는 필요 시 스텁을 사용하는 하향식 테스트와 유사합니다.

통합(샌드위치 통합이라고도 함)은 하향식 방법과 상향식 방법을 결합합니다. 혼합 통합의 가장 큰 장점은 하향식 테스트와 상향식 테스트를 정반대의 방식으로 제한하는 강제 프로세스 순서를 극복할 수 있다는 점입니다. 혼합 통합을 사용하면 사용자의 필요에 따라 메인 모듈 또는 하위 모듈 및 하위 루틴으로 테스트를 시작할 수 있습니다.

통합 테스트를 수행하는 또 다른 주요 방법은 Integration Testing를 사용하는 것입니다. 여기에서 시스템 내에 존재하는 모든 개별 장치, 구성 요소 및 모듈은 마치 단일 장치인 것처럼 한 번에 통합되고 함께 테스트됩니다. 빅뱅 테스트는 시스템이 모든 다양한 부품과 함께 작동할 때 빠른 답을 제공할 수 있습니다.

그러나 이러한 형태의 테스트는 제한적입니다. 이 과정에서 시스템이 예상대로 작동하지 않는다는 사실이 드러나더라도, 빅뱅 테스트 방식은 어떤 개별 구성 요소들이 제대로 협력하지 못하고 있는지를 밝혀내지 못합니다.

다음은 널리 사용되는 몇 가지 Integration Testing 방법입니다. 이들 모두는 소프트웨어 회사의 필요에 따라 적절한 방법론이 될 수 있으므로, 여기에서는 알파벳순으로 나열되어 있습니다.

• API Integration Testing: 애플리케이션 프로그래밍 인터페이스(API)는 컴퓨팅의 필수적인 부분으로, 소프트웨어 애플리케이션이 서로 상호 작용하고 데이터를 성공적으로 공유할 수 있도록 합니다. API 테스트는 시스템 내의 여러 API가 함께 작동하는 방식을 확인하는 소프트웨어 테스트 수단입니다. 목표는 이러한 API가 마치 하나의 조직화된 단위의 일부인 것처럼 완벽하게 작동하는 것입니다. API가 서로 원활하게 작동할수록 전체 시스템의 운영이 더 원활해집니다.

• Integration Testing: 소프트웨어 개발 프로세스의 필수적인 부분인자동화된 테스트는 소프트웨어 구성 요소가 함께 작동하는 방식을 평가하는 또 다른 방법입니다. 이 Integration Testing 프로세스는 전문 테스트 툴 및 스크립트의 작업을 기반으로 테스트 케이스를 실행합니다. 이러한 방식으로 배포가 발생하기 전에 통합 문제를 감지하고 수정할 수 있습니다. 또한 자동화되기 때문에 전체 시스템의 효율성과 민첩성이 더 향상됩니다. 자동화된 테스트는 지속적 통합의 핵심 요소이며, 지속적으로 업데이트되는 코드 변경을 위해 공유 리포지토리에 의존하는 DevOps 관행입니다.

• 블랙박스 테스트: 블랙박스 비유는 블랙박스의 내부 작동(컴퓨터 코드 또는 보고된 회사 수익과 같은 기타 운영 측면 포함)이 완전히 이해되지 않아도 되는 모든 상황에 적용할 수 있습니다. 블랙박스 Integration Testing의 경우, 테스트 담당자는 각 모듈 내에서 사용된 구체적인 코드까지 자세히 들여다보기를 원하지 않으며, 대신 시스템, 구성 요소, 모듈이 조화롭게 작동하는지에 대한 보다 간단하고 신속한 답을 선호합니다.

• 엔드투엔드 테스트: 이름에서 알 수 있듯이 엔드투엔드 테스트(E2E 테스트라고도 함)는 테스트 담당자가 전체 시스템의 기능을 처음부터 끝까지 확인할 수 있는 방법을 제공합니다. 그 외에도 E2E 테스트는 실제 테스트 시나리오를 모방하고 테스트할 단위를 결정하는 테스트 계획을 포함하여 Integration Testing을 위한 단계를 설정할 수 있습니다. E2E 테스트는 일반적으로 Integration Testing 프로세스의 후반부, 즉 Integration Testing이 완료된 후 사용자 수용 테스트 전에 수행됩니다.

• Functional Testing: 모든 소프트웨어 테스트 유형 중에서 시스템의 순수한 기능을 파악하는 데 가장 중점을 두는 것은 Fuctional Integration Testing(FIT)입니다. FIT는 다양한 모듈 또는 구성 요소가 필요에 따라 상호 작용할 수 있는지 검증하며, 소프트웨어 개발 수명 주기 초기에 결함이 본격적인 문제로 발전하기 전에 이를 찾아낼 수 있다는 점에서 유용합니다. 테스트 담당자는 일반적으로 단위 테스트가 수행된 후 전체 시스템 테스트가 시작되기 전에 Functional Testing을 수행합니다.

• 회귀 테스트: 또 다른 테스트 프레임워크는 회귀 테스트를 통해 제공되며, 이는 통합 과정 중 이루어진 변경 사항이 시스템의 다른 부분에 의도치 않은 오류를 발생시켰는지를 사후에 확인하는 테스트 환경의 역할을 합니다. 새로운 온라인 결제 수단과 같은 기능이 도입될 때, 회귀 테스트는 기존에 정상적으로 작동하던 시스템에 영향을 주지 않도록 보장하는 데 활용됩니다.

• 화이트박스 테스트: 블랙박스 테스트와는 정반대로, 화이트박스 테스트는 테스트 담당자가 문제 영역을 정확히 찾아내고 이를 디버깅하기 위한 코드 수정까지 수행하기를 원한다고 가정합니다. 이 접근 방식은 시간이 훨씬 더 많이 소요될 가능성이 높지만, 테스트 과정에서 관련 코드를 직접 검토하는 것을 포함합니다. “화이트박스”라는 표현은 시스템 내부 동작에 대한 투명한 이해를 바라는 이러한 접근 방식을 반영한 것이며, 실제로 테스트 담당자가 추구하는 바를 더 정확히 설명하려면 “클리어박스”라는 표현이 더 적절할 수도 있습니다.

여기에서도 마찬가지로, 이 마켓플레이스 틈새 시장은 수많은 Integration Testing 툴과 프레임워크에 의해 제공됩니다. 다음은 가장 인기 있는 몇 가지 예입니다.

• Citris: Citris는 오픈 소스 Java 프레임워크를 사용하여 Java의 방대한 사용자 기반(세계에서 가장 인기 있는 프로그래밍 언어 중 하나)에 서비스를 제공합니다. Citris는 API 사용량(예: 트랜잭션)을 관리하고 테스트 메시지를 생성할 수 있습니다.

• Katalon: Katalon Studio의 자동화 테스트 소프트웨어는 오픈 소스 프레임워크인 Selenium을 통합하고 있으며, 이는 브라우저 기반 툴로서 테스트 담당자가 JavaScript, NodeJS, Python 등 다양한 프로그래밍 언어로 테스트 스크립트를 작성할 수 있게 해줍니다.

• Postman: Postman은 API Integration Testing을 잘 수행합니다. 또한 이 툴은 협업을 가능하게 하고 자동화를 수용하는 면에서도 뛰어납니다. 또한 사용자는 해당 테스트를 컬렉션에 넣거나 저장하지 않고도 테스트를 작성할 수 있습니다. 테스트 담당자는 Postman에서 요청하고 해당 URL을 수신합니다.

• SoapUI: SoapUI는 웹 애플리케이션을 테스트하고 Integration Testing을 실행할 수 있는 오픈 소스 툴을 제공합니다. 이를 통해 테스트 담당자는 테스트 사례 생성을 지원하고 사용자가 테스트 데이터로 쉽게 작업할 수 있도록 하는 그래픽 인터페이스를 얻을 수 있습니다.

귀사의 필요가 프론트엔드 또는 백엔드 평가 및 개선이든, Integration Testing은 이제 비즈니스가 최고 효율성과 최대 수익성을 발휘하며 운영되기 위해 필수적인 연결 상태의 성공 여부를 평가할 수 있는 수단을 제공합니다.

앞서 언급했듯이, 다양한 통합 테스트 방식이 존재하며, 이는 소프트웨어 개발자들이 모든 가능한 요구와 관련 구성에 맞는 Integration Testing 방법을 식별하고 개발하기 위해 노력해온 결과입니다. 그리고 대부분의 소프트웨어 개발 회사는 이러한 테스트의 필요성을 이해하고 있기 때문에 효과가 있습니다. 일부 추정에 따르면 DevOps 업무에 종사하는 기업 중 약 70%가 이미 어떤 형태로든 Integration Testing을 사용하고 있다고 합니다.

그렇다면 비즈니스에 적합한 통합 툴은 무엇일까요? 수요가 활발한 시장 덕분에, 회사의 요구에 잘 부합하는 통합 테스트 방법을 충분히 찾아낼 수 있을 가능성이 높습니다. 그러한 필요가 정확히 무엇인지 파악하기 위해, 잘 알려진 고전 격언 하나를 떠올려 보시길 권합니다. “너 자신을 알라.” 격언치고는, 포스트모던 시대에도 여전히 유용한 조언입니다.