답변.

수동 통합 테스트는 다양한 모듈, 서비스 또는 외부 시스템 간의 상호 작용을 자동 스크립트 없이 수동으로 검증하는 프로세스입니다.

질문 배경:

IT 제품의 발전 초기에는 모든 시스템이 모놀리틱하게 구축되었지만, 기업의 규모와 외부 서비스의 수가 증가함에 따라 통합 테스트가 중요한 문제로 대두되었습니다. 테스터들은 데이터와 작업이 시스템 간에 올바르게 전달되는지 확인하기 위해 어떤 방법을 사용해야 하는지 고민하게 되었습니다. 예를 들어, 성공적인 결제가 청구 및 회계 시스템 모두에 반영되는지 확인하는 것입니다.

문제:

가장 큰 어려움은 완전한 기능 환경이 부족하다는 것입니다. 통합은 외부 서비스, 불안정한 API 또는 외부 제약 조건에 의존할 수 있습니다. 또한, 각 통합 연결점에서 수동 테스트는 매우 노동 집약적일 수 있으며, 수행 단계의 순서에서 실수를 하거나 중요한 연쇄 결과를 놓치는 것이 쉽습니다.

해결책:

테스트 환경에서 "목(mock)/스텁(stub)"을 사용하여 테스트의 반복성을 보장합니다.
테스트 케이스를 구조화하고 메시지, 로그, 상태에 대한 단계별 확인을 작성합니다.
우선 경계 사례, 타임아웃, 호출 통합의 재시도, 시스템의 오류에 대한 반응을 확인합니다.

주요 특징:

통합되는 양측의 비즈니스 논리를 이해해야 합니다.
비동기성과 상태 전송의 오류를 고려해야 합니다.
부분 오류에 대한 회복력을 지원해야 합니다.

함정 질문.

테스트 더블(test doubles)이란 무엇이며 수동 통합 테스트 시에 왜 필요합니까?

테스트 더블은 통합 구성 요소를 모방한 것입니다(예: mock, stub, fake). 수동 테스트 시 실제 외부 시스템에 접근할 수 없거나 호출에 비용이 발생할 때 시나리오를 연습할 수 있도록 필요합니다.

행복 경로(happy path)만 테스트 케이스가 커버된 경우 통합이 테스트되었다고 볼 수 있습니까?

아니요. 반드시 엣지 케이스를 테스트해야 합니다: 연결 오류, 잘못된 데이터 형식, 타임아웃, 예기치 않은 응답 등입니다.

데이터 전송/수신만 검사하면 충분합니까, 아니면 다른 것을 더 확인해야 합니까?

데이터의 내용의 정확성, 데이터 변환 및 다양한 오류의 경우 시스템의 동작을 검사하는 것이 중요합니다.

일반적인 오류 및 반패턴

자신의 부분 시스템만 작업하고 파트너 측의 동작을 검토하지 않음.
부정적인 시나리오를 무시함.
로그를 분석하지 않거나 통합 오류 기록을 축적하지 않음.

실생활 예

부정적인 케이스

테스터가 CRM과 청구 시스템 간의 통합을 오직 성공적인 주문 추가에 대해서만 테스트합니다. 동기화 오류 및 거래 누락을 확인하지 않습니다.

장점:

주요 시나리오를 신속하게 커버합니다.

단점:

통합 오류가 실제 데이터에서만 발견될 것입니다.

긍정적인 케이스

테스터가 인터넷 연결을 끄고 켜는 시나리오, 잘못된 토큰을 사용하는 테스트 세트를 만듭니다. 양쪽의 로그를 검증합니다.