답변.

통합 수동 테스트는 소프트웨어 생명 주기의 중요한 단계로, 모듈 테스트 후에 수행됩니다. 그 목적은 개별 모듈 또는 시스템 구성 요소가 서로 올바르게 상호작용하는지 확인하는 것입니다.

문제의 역사: 처음에 소프트웨어 테스트는 단계적으로 수행되었습니다: 먼저 개별 모듈(단위 테스트)을 확인한 다음 전체 시스템을 확인했습니다. 그러나 실제로는 대부분의 치명적인 오류가 모듈 간의 경계에서 발생하는 것이 밝혀졌습니다. 그래서 통합 테스트가 필요해졌으며, 이는 서로 다른 시스템의 부분 간의 동작 불일치를 수동으로 식별합니다.

문제: 주된 어려움은 모듈 간의 상호 작용 시나리오를 충분히 다루지 않거나 잊혀진 상호 의존성입니다. 이는 '보이지 않는' 버그로 이어집니다: 격리된 테스트에서는 모든 것이 올바르게 작동하지만, 통합 후에는 실패가 발생합니다(예: API와 데이터베이스 간의 데이터 처리 오류).

해결책: 올바른 통합 수동 테스트 조직에는 다음이 포함됩니다:

시스템 아키텍처 분석 및 구성 요소 간의 상호작용 맵 작성.
사용자 시나리오 및 경계 데이터 기반의 통합 테스트 케이스 개발.
부분적인 실패를 모델링(예: 하나의 서비스 실패)하고 전체 시스템의 반응 평가.
결과 문서화 및 버그 간의 의존성 기록.

주요 특징:

최신 아키텍처 다이어그램 유지.
시스템 부품 간의 모든 숨겨진 및 명시적 의존성 고려.
모듈의 경계에서 데이터 전송 및 변환 시나리오에 특별한 주의.

함정 질문들.

통합 수동 테스트와 시스템 수동 테스트의 차이는 무엇인가요?

통합 테스트는 특정 모듈 간의 연결 테스트에 초점을 맞추고, 시스템 테스트는 비즈니스 기능의 관점에서 전체 시스템을 검증합니다.

통합 테스트에서 실제 외부 서비스를 사용해야 하나요, 아니면 에뮬레이터로 충분한가요?

중요한 통합의 경우 실제 환경이 바람직하지만, 에뮬레이터(mock/stub)로 시작할 수 있습니다. 최종 테스트는 PROD 환경에 최대한 가까운 곳에서 수행되어야 합니다.

모든 통합 오류를 자동화만으로 식별할 수 있나요?

아니요: 일부 결함은 테스트자가 데이터 교환의 비즈니스 논리에서 명백하지 않은 문제를 보거나 자동화에서 제외된 사용자 시나리오를 통해 수동으로만 발견됩니다.

일반적인 오류 및 안티 패턴

통합 포인트의 명확한 목록이 없음.
환경을 분리하지 않고 테스트를 수행함.
통합 테스트 케이스의 세부 정보 부족.

생활 사례

부정적 사례

결제 모듈과 주문 모듈 간의 통합 테스트가 모든 다른 테스트가 끝난 후에만 수행되었고 별도의 문서 없이 진행되었습니다.

장점:

테스트 케이스 준비에 대한 시간 절약.
복잡한 조정 없이 빠르게 테스트 시작.

단점:

중복 청구와 관련된 심각한 버그가 프로덕션으로 유출됨.
마지막 순간 발견된 오류 수정을 위한 릴리스 지연.

긍정적 사례

통합 시나리오는 처음부터 기록되었고, 테스트 데이터는 사용자 작업의 실제 문제에 최대한 가깝게 설정되었습니다.