통합 테스팅(Integration Testing)에 대해 알아보니..

통합 테스팅(Integration Testing)에 대해 알아보았습니다.

 

통합 테스팅은 소프트웨어 수명주기 내의 테스트 레벨 중 하나로, 개별적으로 검증된 모듈이나 컴포넌트들을 결합하여, 이들 간의 인터페이스와 상호 작용이 올바르게 동작하는지를 검증하는 단계입니다.

 

 

1. 통합 테스팅의 개념 및 목적

• 개념: 통합 테스팅은 단위 테스트를 마친 개별 모듈들이 서로 결합되어 하나의 시스템이나 서브시스템을 이루었을 때, 각 모듈 간에 데이터가 올바르게 전달되고 상호 작용하는지, 인터페이스가 문제없이 작동하는지를 검증하는 절차입니다.
• 목적:
  • 모듈 간의 연결 및 인터페이스 오류를 조기에 발견하기
  • 데이터 흐름 및 상호 작용에서 발생할 수 있는 결함을 확인하기
  • 시스템 전체의 안정성을 확보하고, 후속 시스템 테스트나 사용자 수용 테스트 단계에서 발생할 리스크를 줄이기

2. 통합 테스팅의 주요 방법 및 접근 방식

통합 테스팅은 여러 가지 방법론으로 진행할 수 있으며, 대표적인 접근 방식은 다음과 같습니다.

2.1. 빅뱅(Big Bang) 통합

• 설명: 모든 모듈을 한 번에 결합하여 테스트를 진행하는 방식입니다.
  
  

빅뱅 통합 테스트의 실제 예시

전자상거래 웹사이트 개발 프로젝트 예시

시나리오:

• • 개발 모듈: 전자상거래 웹사이트는 여러 기능 모듈로 구성됩니다. 예를 들어,
    • 상품 관리 모듈: 상품 등록, 수정, 삭제 및 목록 보기 기능을 담당
    • 주문 관리 모듈: 주문 생성, 주문 확인 및 주문 수정 기능을 담당
    • 결제 처리 모듈: 결제 승인, 환불 처리 등의 기능을 제공
    • 사용자 계정 모듈: 회원 가입, 로그인 및 프로필 관리 기능을 담당

빅뱅 통합 과정:

• 1. 개별 모듈 개발 및 단위/컴포넌트 테스트: 각 모듈은 독립적으로 개발되어 단위 테스트와 컴포넌트 테스트를 통해 자체 기능이 정상적으로 동작하는지 확인됩니다. 예를 들어, 상품 관리 모듈은 자체 테스트를 통해 상품 등록 시 올바른 데이터 저장을 검증합니다.
  2. 모든 모듈 일괄 통합: 모든 모듈이 개발 완료되면, 빅뱅 방식으로 전체 시스템에 한 번에 결합합니다. 이는 모든 모듈을 동시에 실제 운영 환경과 유사한 테스트 환경에 배포하는 것을 의미합니다.
  3. 전체 시스템 통합 테스트 진행:
     • 인터페이스 점검: 예를 들어, 주문 관리 모듈이 사용자 계정 모듈과 결제 처리 모듈과 데이터를 주고받을 때, 데이터 형식이나 값의 불일치가 있는지를 검증합니다.
     • 실제 업무 시나리오 검증: 사용자 관점에서 상품을 선택하고 주문을 생성한 후, 결제까지 진행되는 전체 프로세스의 흐름을 테스트합니다. → 이때, 모듈 간 연결 오류 혹은 데이터 전달 문제로 인해 결제 승인 과정에서 오류가 발생할 수 있습니다.
  4. 문제점 및 어려움:
     • 오류 추적의 어려움: 모듈이 한꺼번에 통합된 후 문제가 발생하면, 어느 모듈 간의 인터페이스 오류인지, 어떤 데이터가 잘못 전달되었는지 파악하기 어려운 경우가 많습니다.
     • 디버깅 복잡도: 모든 모듈이 동시에 작동하므로, 단일 모듈의 단위 테스트에서는 발견되지 않았던 상호작용 문제나 결함이 드러날 수 있으며, 이를 수정하기 위해 복잡한 디버깅 절차가 필요합니다.

실제 사례 예시 요약:

• 상황: 전자상거래 웹사이트에서 주문 생성 시, 주문 관리 모듈이 정상적으로 주문 정보를 생성하여 결제 처리 모듈에 전달했어야 하지만, 통합 후 예상과 달리 결제 모듈에서 주문 정보의 형식이 맞지 않는다는 오류가 발생함.
• • 원인: 각 모듈은 단독으로는 제대로 동작했으나, 인터페이스와 데이터 포맷에 대한 정의가 각 모듈 개발 시 약간씩 상이하게 구현되었기 때문입니다.
  • 대응: QA팀과 개발팀이 모여 인터페이스 명세서를 재검토하고, 통합 테스트에서 발견한 데이터 불일치를 수정한 후, 전체 시스템이 다시 빅뱅 테스트 환경에서 검증되었습니다.

빅뱅 통합 테스트는 모든 모듈을 한 번에 결합하여 전체 시스템의 동작을 확인할 수 있다는 장점이 있으나, 문제 발생 시 원인적인 부분을 파악하기 어렵고 디버깅이 복잡할 수 있는 단점도 가지고 있습니다. 전자상거래 시스템 예시를 통해 볼 때, 각 모듈은 독립 테스트에서 통과했더라도, 모듈 간 인터페이스나 데이터 교환의 미세한 불일치가 큰 문제로 나타날 수 있음을 알 수 있습니다.

• 특징:
  • 초기 설정이 간단하나, 오류 발생 시 그 원인을 파악하기 어려울 수 있습니다.

2.2. 점진적 통합(incremental integration)

• 설명: 모듈들을 순차적으로 결합하여 테스트하는 방식입니다. 이 방식에는 여러 전략이 있습니다.
  • 상향식(Bottom-Up) 통합: 하위 모듈부터 먼저 통합한 후, 상위 모듈을 점차 추가하면서 테스트합니다.
    

상향식 통합의 실제 예시 – 은행 거래 시스템

시나리오 개요: 은행 거래 시스템은 여러 계층의 모듈로 구성되어 있습니다. 가장 낮은 수준에는 데이터 액세스 및 기본 기능을 제공하는 모듈들이 있고, 위로 올라갈수록 비즈니스 로직과 사용자 인터페이스가 포함됩니다. 상향식 통합에서는 다음과 같은 순서로 통합이 진행됩니다

 

1. 하위 모듈(저수준 컴포넌트) 통합

• • • 개별 모듈 예시:
      • 계좌 관리 모듈(Account Management Module): 계좌 생성, 조회, 잔액 업데이트 등 기본 기능을 구현합니다.
      • 트랜잭션 처리 모듈(Transaction Processing Module): 입출금, 이체 등의 거래 데이터를 기록하고 처리하는 기능을 담당합니다.
      • 로그 관리 모듈(Logging Module): 각 거래 내역과 시스템 이벤트를 기록합니다.
    • 단계 설명: 각 모듈은 먼저 단위 테스트를 통해 독립적으로 검증된 후, 계좌 관리 모듈과 트랜잭션 처리 모듈 같이 가장 기본적인 하위 기능들을 결합합니다.
      
      예를 들어, ‘계좌 관리’와 ‘입출금’ 기능을 함께 통합하여, 입금 시 계좌 잔액이 올바르게 업데이트 되고, 거래 내역이 기록되는지를 테스트합니다.
      
      

2. 중간 모듈 통합

• • • 예시 모듈 추가:
      • 계좌 서비스 모듈(Account Service Module): 하위 모듈(계좌 관리, 트랜잭션 처리)을 사용하는 비즈니스 로직을 포함합니다. 예를 들어, 여러 거래를 종합하여 계좌 상태를 갱신하거나, 예외 상황(잔액 부족 등)을 처리합니다.
    • 단계 설명: 하위 모듈들이 이미 통합된 상태에서, 계좌 서비스 모듈을 추가하고, 상호 연계된 기능(예: 다수의 입출금 거래 처리 후 잔액 정확성 검증)을 점진적으로 통합합니다.
      
      이때, 하위 모듈들은 이미 테스트되어 있으므로, 계좌 서비스 모듈의 비즈니스 로직에 집중하여 통합 테스트를 수행합니다.
      
      

3. 최상위 모듈 통합

• • • 예시 모듈 추가:
      • 고객 인터페이스 모듈(Customer Interface Module): 최종 사용자(고객)와 직접 상호 작용하는 웹/모바일 UI나 API 계층입니다.
    • 단계 설명: 최하위와 중간 모듈이 모두 통합되고 안정성이 확보되면, 최상위 모듈인 고객 인터페이스를 추가합니다. 이때는 실제 사용자 시나리오—예를 들어, 고객이 로그인하여 계좌 조회, 입금/출금 및 거래 내역 확인을 하는 전체 흐름이 올바르게 작동하는지를 통합 테스트를 통해 검증합니다.

상향식 통합 방식의 장점

• • • 문제 원인 파악 용이: 낮은 단계부터 통합해 가기 때문에, 문제가 발생하면 어느 계층에서 발생했는지 비교적 빠르게 파악할 수 있습니다.
    • 안정성 확보: 각 단계별로 기능을 확인하며 추가하기 때문에, 상위 모듈이 완성되기 전에 하위 기본 기능들이 확실히 검증됩니다.
    • 단계적 검증: 전체 시스템을 한꺼번에 통합하는 것보다 단계별로 진행해 오류를 미리 수정할 수 있어, 최종 시스템의 품질과 신뢰성을 높입니다.
    
    
    
  • 하향식(Top-Down) 통합: 상위 모듈부터 결합하며, 하위 모듈은 모의 드라이버나 스텁을 활용하여 점진적으로 추가하면서 테스트합니다.

모의 드라이버와 스텁은 테스트 환경에서 실제 모듈 대신 임시로 사용되는 가짜 코드들입니다.

각각의 역할은 다음과 같이 쉽게 이해하실 수 있습니다.

• 스텁(Stub): 스텁은 테스트하고자 하는 모듈이 호출하는 하위 모듈(또는 외부 시스템)이 아직 개발 중이거나 사용할 수 없을 때, 그 역할을 대신하는 간단한 코드입니다.
  
  예를 들어, 사용자 인증 모듈을 테스트할 때 데이터베이스가 준비되지 않았다면, 미리 정해진 응답을 돌려주는 스텁을 만들어서 인증 모듈이 정상적으로 데이터를 받아 처리하는지 확인할 수 있습니다.
  
  예를 들어, 사용자 인증 모듈을 테스트하는 상황을 생각해봅니다. 이 모듈은 보통 데이터베이스에 저장된 사용자 정보를 확인해야 하지만, 개발 초기 데이터베이스가 완성되지 않았다고 가정해보겠습니다. 이 경우, 실제 데이터베이스 대신에 스텁을 만들어서 정해진 조건에 따라 인증 결과를 반환할 수 있습니다.
  
  

예시: 사용자 인증 스텁 (Java 코드 예시)

// 실제 데이터베이스 대신 사용할 스텁 클래스
public class UserAuthDBStub {
    // 실제 데이터베이스 쿼리 대신 미리 정의된 조건으로 인증을 처리한다.
    public boolean validateCredentials(String username, String password) {
        // 예시: 특정 사용자명과 패스워드가 입력되면 성공으로 처리
        if(username.equals("testUser") && password.equals("test1234")) {
            return true;
        }
        return false;
    }
}

// 인증 모듈에서 스텁을 이용하는 경우
public class UserAuthentication {
    private UserAuthDBStub dbStub;

    public UserAuthentication() {
        // 실제 DB 대신 스텁 객체를 주입
        this.dbStub = new UserAuthDBStub();
    }

    public boolean authenticate(String username, String password) {
        // 스텁을 통해 미리 정의된 응답을 받음
        return dbStub.validateCredentials(username, password);
    }

    // 테스트를 위해 main 메서드 작성
    public static void main(String[] args) {
        UserAuthentication auth = new UserAuthentication();
        if(auth.authenticate("testUser", "test1234")) {
            System.out.println("인증 성공!");
        } else {
            System.out.println("인증 실패!");
        }
    }
}

 

UserAuthDBStub은 데이터베이스 대신 사용되는 스텁으로, 지정된 사용자 정보에 대해서만 인증을 성공시키도록 구현되어 있습니다. 이를 통해 실제 데이터베이스 연결 없이도 사용자 인증 로직을 독립적으로 테스트할 수 있습니다.

 

 

• 드라이버(Driver): 드라이버는 테스트 대상이 되는 모듈을 호출하는 상위 모듈(또는 테스트를 시작하는 코드)이 아직 완성되지 않았을 때, 해당 모듈을 대신 호출해 주는 역할을 합니다.
  
  예를 들어, 하나의 함수나 모듈을 독립적으로 테스트하고자 할 때, 이를 호출하는 프로그램이 없는 상태라면 드라이버를 만들어 해당 함수나 모듈을 실행시키고 그 결과를 확인할 수 있도록 합니다.
  
  

드라이버는 테스트 대상 모듈을 호출할 상위 모듈이 아직 완성되지 않았을 때, 단독으로 해당 모듈을 실행하여 결과를 확인하기 위해 사용됩니다. 예를 들어, 계산기 모듈의 기능을 테스트하고 싶은데, 이 모듈을 호출할 UI나 다른 상위 시스템이 아직 준비되지 않은 상황이라고 가정해보겠습니다.

예시: 계산기 모듈 드라이버 (Java 코드 예시)

// 테스트 대상이 되는 계산기 클래스
public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }
    
    public int subtract(int a, int b) {
        return a - b;
    }
    
    // 추가적인 메서드들...
}

// 계산기 모듈을 테스트하기 위한 드라이버 클래스
public class CalculatorDriver {
    public static void main(String[] args) {
        Calculator calc = new Calculator();
        
        // 드라이버 코드에서 직접 메서드를 호출하여 결과를 출력
        int sum = calc.add(5, 3);
        System.out.println("5 + 3 = " + sum);

        int diff = calc.subtract(10, 4);
        System.out.println("10 - 4 = " + diff);
    }
}

위 예시에서 CalculatorDriver는 상위 시스템이 준비되지 않은 상황에서, Calculator 모듈의 기능(덧셈, 뺄셈 등)을 직접 호출하여 결과를 확인할 수 있도록 도와줍니다. 이를 통해 모듈 단위의 기능 검증이 가능해지며, 나중에 상위 시스템이 완성되었을 때 큰 수정 없이 통합할 수 있습니다.

 

쉽게 말해, 스텁은 “내가 필요한 데이터를 대신 줄게요” 라는 역할을 하고,

드라이버는 “내가 대신 호출해서 테스트해볼게요” 라고 생각하시면 됩니다.

이러한 임시 코드들은 전체 시스템이 완성되기 전에 개별 모듈이나 컴포넌트를 독립적으로 테스트할 수 있도록 도와줍니다.

하향식(Top-Down) 통합의 실제 예시 – 레스토랑 주문 처리 시스템

시나리오 개요:

한 레스토랑의 주문 처리 시스템은 여러 계층으로 구성되어 있습니다. 전체 시스템은 다음과 같이 계층별 모듈로 나눌 수 있습니다.

1. 최상위: 고객 인터페이스(UI) 모듈
   • 실제 주문을 받는 웹/모바일 인터페이스.
2. 중간 계층: 주문 관리 및 컨트롤 모듈
   • 고객으로부터 받은 주문을 처리하고, 하위 모듈에 전달하는 역할.
3. 하위 계층:
   • 결제 처리 모듈: 실제 결제 승인을 수행 (아직 개발 중일 수 있음).
   • 주방 통보 모듈: 주문 내용을 주방 시스템으로 전달하여 조리 작업을 시작함.

통합 과정

1. 최상위 모듈부터 시작:
   • UI 모듈 개발: 레스토랑 주문 시스템의 사용자 인터페이스를 먼저 구현합니다. 고객은 이 인터페이스를 통해 메뉴를 선택하고 주문을 제출할 수 있습니다.
   • 주문 관리 모듈 연동: UI 모듈은 고객의 주문 정보를 상위 주문 관리 모듈로 전달합니다. 이때, 주문 관리 모듈은 이미 구현되어 있어 주문 데이터를 수집하고, 이후 처리할 준비를 마칩니다.
2. 하위 모듈의 임시 대체:
   • 결제 처리 모듈 스텁 사용: 아직 결제 처리 모듈이 완전히 구현되지 않은 상황에서, 주문 관리 모듈은 결제 요청을 보내야 합니다.
     
     이때 스텁을 사용해, "결제 성공" 같은 미리 정의된 응답을 반환하도록 합니다. → 이를 통해 상위 모듈이 결제 처리 결과에 따라 적절히 동작하는지 테스트할 수 있습니다.
     
     
   • 주방 통보 모듈 스텁 사용: 마찬가지로, 실제 주방 통보 모듈이 개발되지 않았다면, 스텁을 사용해 "주방에 주문 전송 완료"라는 응답을 설정합니다.
     
     
3. 점진적 모듈 구현 및 교체:
   • 결제 처리 모듈 실제 구현: 개발이 진행되면서 결제 처리 모듈이 실제 구현됩니다.
     
     이때 스텁을 실제 모듈로 교체하여, 상위 모듈과 통합된 후 실제 결제 과정을 검증합니다.
     
     
   • 주방 통보 모듈 실제 구현: 이후 주방 통보 모듈도 구현되고, 스텁 대신 실제 모듈이 기능하게 됩니다.
     
     
   • 전체 통합 테스트: 각 하위 모듈이 실제 기능으로 교체되면, 전체 시스템이 처음부터 끝까지 올바르게 작동하는지 종합 테스트를 실시합니다.

이 방식의 장점

• 조기 검증: 최상위 계층의 핵심 비즈니스 로직과 흐름을 우선 검증할 수 있어, 전체 시스템의 큰 그림이 올바른지 확인할 수 있습니다.
  
  
• 문제 원인 파악 용이: 단계별로 하위 모듈을 추가하면서 통합하므로, 문제가 발생했을 때 어느 계층에서 발생했는지 쉽게 추적할 수 있습니다.
  
  
• 스텁 활용: 아직 개발 중인 하위 모듈 자리에 스텁을 사용하여 상위 모듈의 기능을 미리 검증할 수 있어, 개발이 지연되더라도 테스트를 지속할 수 있습니다.
  
  

결론

하향식(Top-Down) 통합은 상위 모듈부터 시작하여 하위 모듈들을 점진적으로 통합하는 접근 방식입니다.

예를 들어, 레스토랑 주문 처리 시스템에서는 고객 인터페이스와 주문 관리 모듈이 먼저 통합된 후, 결제 처리와 주방 통보 모듈이 스텁으로 대체된 상태에서 테스트가 이루어집니다.

이후 하위 모듈이 구현되고 스텁이 실제 모듈로 교체되면서 전체 시스템의 기능을 점진적으로 완성하게 됩니다.

 

 

• 혼합형(Mixed 또는 Sandwich) 통합: 상향식과 하향식 전략을 동시에 적용하여 중간 계층에서 만나 통합하는 방식입니다.

• 특징:
  • 각 단계별 테스트 결과를 점검할 수 있어 결함의 원인을 빠르게 파악할 수 있습니다.

혼합형 통합 방식의 특징

1. 동시 진행:
   • 최상위(예, 사용자 인터페이스, 컨트롤러)와 최하위(예, 데이터 액세스, 외부 서비스) 모듈을 동시에 통합합니다.
   • 아직 완성되지 않은 계층에는 스텁이나 드라이버를 사용하여 상위와 하위 개발 팀이 병행해 작업할 수 있습니다.
2. 중앙 계층에서의 만남:
   • 상위 모듈의 통합 테스트 결과와 하위 모듈의 통합 테스트 결과가 중간 계층(비즈니스 로직 등)에서 만나 전체 시스템의 흐름을 검증하게 됩니다.
3. 문제 원인 파악의 유리함:
   • 상단과 하단이 각각 별도로 통합된 상태에서 중앙 부분으로 합쳐지기 때문에, 문제가 발생하면 어느 계층에서 오류가 발생했는지 비교적 쉽게 추적할 수 있습니다.

실제 예시: 온라인 쇼핑몰 시스템

시나리오 개요: 온라인 쇼핑몰 시스템은 다음과 같이 계층화되어 있습니다.

• 최상위 계층 (프레젠테이션/컨트롤 계층): 웹/모바일 사용자 인터페이스, 검색 및 쇼핑 카트
• 중간 계층 (비즈니스 로직 계층): 주문 처리, 결제 승인, 재고 관리 등 핵심 비즈니스 로직
• 최하위 계층 (데이터 액세스 및 외부 연동 계층): 데이터베이스 접근, 외부 결제 게이트웨이, 물류 연동 등

혼합형 통합 진행 단계:

1. 하향식(Top-Down) 통합 – 최상위 계층부터:
   • 사용자 인터페이스와 컨트롤러: UI 개발이 완료되면, 상위 계층에서는 아직 완성되지 않은 비즈니스 로직 계층 대신 스텁(Stub)을 사용하여, 예를 들어 “더미 주문 처리 결과”를 반환하도록 구현합니다.
2. 상향식(Bottom-Up) 통합 – 최하위 계층부터:
   • 데이터 액세스 및 외부 연동 모듈: 데이터베이스 접근 및 외부 결제 모듈 같은 하위 모듈은 개별 단위 테스트 후에 상향식으로 통합되며, 실제 데이터를 처리하는지 검증합니다.
   • 해당 계층은 자체적으로 통합 테스트를 수행하여 올바른 데이터 흐름을 보장합니다.
3. 중간 계층(비즈니스 로직) 통합:
   • 최상위와 최하위 계층이 각각 통합된 상태에서, 핵심 비즈니스 로직을 담당하는 중간 계층을 개발 및 통합합니다.
   • 중간 계층은 상위 계층에서 전달받은 주문 요청을 실제 하위 계층 모듈과 통신하여 주문 처리, 결제 승인, 재고 업데이트 작업을 수행합니다.
   • 이제 상위 계층의 스텁이 실제 중간 계층의 구현으로 대체되고, 하위 계층 또한 점진적으로 실제 모듈로 교체됩니다.
4. 종합 통합 테스트:
   • 모든 계층이 완전히 통합되면, 실제 사용자 시나리오(예, 상품 검색 → 주문 생성 → 결제 승인 → 주문 확인)를 통해 전체 시스템의 기능과 데이터 흐름을 종합적으로 테스트합니다.

예시 요약: 예를 들어, 고객이 웹사이트에서 상품을 선택하고 "구매하기"를 누르면, 최상위 계층에서는 주문을 받아 비즈니스 로직 계층(초기에는 스텁 사용)이 주문을 처리하는데, 동시에 하위 계층에서는 데이터베이스 접근과 외부 결제 서비스와의 연동이 점진적으로 통합됩니다.

최종적으로 모든 계층이 실제 연결되어 주문 처리와 결제 승인 과정이 원활하게 이루어지는지를 확인하게 됩니다.

# 최상위 계층,중간 계층,최하위 계층을 쉽게 구분할수 있는 방법

 

1. 계층별 역할을 이해하기

• 최상위 계층 (Presentation Layer 또는 UI 계층)
  • 주요 역할: 사용자와 직접 상호작용하는 부분입니다.
  • 예시: 웹사이트의 화면, 모바일 앱의 인터페이스, 데스크탑 애플리케이션의 창 등
  • 비유: 건물의 정면이나 입구처럼, 사용자(방문자)가 가장 먼저 접하는 부분입니다.
• 중간 계층 (Business Logic 또는 Application Layer)
  • 주요 역할: 실제 비즈니스 규칙과 처리를 담당하는 부분입니다.
  • 예시: 주문 처리, 계산, 데이터 검증 로직, 서비스 제공 로직 등
  • 비유: 건물의 중앙층에 있는 운영사무소나 관리실처럼, 모든 처리를 총괄하고 지시하는 역할을 합니다.
• 최하위 계층 (Data Access Layer 또는 Persistence Layer)
  • 주요 역할: 데이터 저장, 검색, 외부 시스템과의 통신 등 핵심 데이터에 접근하는 부분입니다.
  • 예시: 데이터베이스, 파일 시스템, 외부 API 연동 등
  • 비유: 건물의 지하 창고나 기계실처럼, 내부의 중요한 데이터를 보관하고 관리하는 역할이라 할 수 있습니다.

2. 쉽게 구분하는 팁

2.1. 사용자와의 직접적 상호작용 여부

• 최상위 계층:
  • 질문: "이 부분은 사용자가 직접 보고, 클릭하거나 입력하나요?"
  • 대답: 그렇다면 최상위 계층입니다.

2.2. 비즈니스 로직(처리 및 결정)을 담당하는가?

• 중간 계층:
  • 질문: "이 부분은 실제로 비즈니스 룰을 적용해 결정을 내리거나 프로세스를 실행하나요?"
  • 대답: 그렇다면 중간 계층입니다.

2.3. 데이터 저장 및 외부 자원과의 연결인가?

• 최하위 계층:
  • 질문: "이 부분은 데이터를 읽거나 쓰고, 외부 시스템(데이터베이스, API 등)과 연결되나요?"
  • 대답: 그렇다면 최하위 계층입니다.

3. 간단한 도식화

   ---------------------
   |   최상위 계층      | (사용자 인터페이스)
   ---------------------
            │
            ▼
   ---------------------
   |   중간 계층        | (비즈니스 로직)
   ---------------------
            │
            ▼
   ---------------------
   |   최하위 계층      | (데이터 처리 및 저장)
   ---------------------

 

 

위 도식은 각 계층의 역할 및 구분을 한눈에 보여줍니다.

4. 비유를 통한 이해

• 최상위 계층:
  • 사용자와 직접 만나는 '전면' 혹은 '입구'
• 중간 계층:
  • 모든 운영을 총괄하는 '중앙 관리실'
• 최하위 계층:
  • 핵심 데이터를 보관하는 '저장고' 또는 '기계실'

이러한 비유를 기억하시면, 시스템 계층을 실제 건물의 구조에 비추어 쉽게 구분하고 이해할 수 있습니다.

이처럼 각 계층의 역할과 사용자, 비즈니스 로직, 데이터 처리를 기준으로 질문을 던지며 구분하면 쉽게 외워 사용할 수 있습니다.

3. 통합 테스팅의 진행 과정

통합 테스팅은 일반적으로 단위 테스트가 완료된 후에 실시하며, 다음과 같은 단계로 진행됩니다.

1. 통합 계획 수립:
   • 각 모듈 간의 인터페이스, 데이터 흐름, 의존성을 분석하고, 통합 테스팅 전략(빅뱅, 상향식, 하향식 등)을 결정합니다.
   • 통합 테스팅에 필요한 드라이버나 스텁의 요구사항을 정의합니다.
2. 통합 환경 구성:
   • 모듈들이 결합되어 테스트할 수 있도록 테스트 환경을 설정합니다.
   • 필요한 데이터베이스, 서버, 네트워크 구성 등도 미리 준비합니다.
3. 테스트 케이스 작성:
   • 각 인터페이스와 모듈 간 통신, 데이터 전달, 연계 로직 등을 점검할 수 있는 테스트 케이스를 상세하게 작성합니다.
4. 테스트 실행 및 결과 분석:
   • 계획한 순서에 따라 모듈들을 결합하고, 각 단계별로 테스트를 수행합니다.
   • 발견된 결함에 대해 원인 분석 후, 수정 및 재테스트를 진행합니다.
5. 문서화 및 피드백:
   • 테스트 결과, 발견된 결함, 개선 사항 등을 문서화하여, 후속 단계(시스템 테스트 등)로 전달합니다.

4. QA 엔지니어가 주의해야 할 사항

QA 엔지니어께서는 통합 테스팅 단계에서 다음 사항들에 특히 주의하셔야 합니다.

• 모듈 간 인터페이스 검증: 각 모듈이 올바른 방식으로 연결되어 데이터를 주고받는지, 정의된 인터페이스를 준수하는지 꼼꼼히 검증해야 합니다.
• 점진적 접근 관리: 상향식, 하향식 등 선택한 통합 전략에 따라 단계별 결합 시 발생할 수 있는 오류나 불일치 문제를 체계적으로 관리합니다.
• 드라이버 및 스텁 관리: 완성되지 않은 모듈을 대신하여 사용하는 드라이버나 스텁의 정확성을 확인하고, 추후 실제 모듈로 대체될 시 문제가 발생하지 않도록 주의합니다.
• 환경 설정 및 데이터 준비: 통합 테스트 환경이 실제 운영환경과 유사하게 구성되어야 하며, 테스트 데이터가 적절하게 마련되어야 합니다.
• 자동화 회귀 테스트: 모듈 추가나 변경에 따른 기존 통합 테스트 결과가 유지되는지 자동화된 회귀 테스트를 마련하여 신속하게 검증할 수 있도록 해야 합니다.

5. 실제 적용 사례

예를 들어, 전자상거래 사이트 개발 시 개별 결제, 상품 등록, 주문 처리 모듈을 별도로 단위 테스트한 후, 상향식 통합 방식으로 통합 테스팅을 진행한 사례가 있습니다.

• 각 모듈이 결합된 후, 상품 주문 시 결제 및 재고 감소, 주문 확인 등이 올바르게 이루어지는지 테스트하였습니다.
• 발견된 문제점은 모듈 간 데이터 포맷 불일치와 인터페이스 호출 오류였으며, 이에 대해 수정 후 재테스트를 실시하여 전체 프로세스의 안정성을 확보하였습니다.

# 통합 테스팅 단계에서 QA 엔지니어가 특히 주의해야 할 사항과 실제 사례

1. QA 엔지니어가 주의해야 할 점

1.1. 모듈 간 인터페이스 정확성 확인

• 명세 준수: 개별 모듈이 서로 연결될 때 지정된 인터페이스(메서드, API, 데이터 포맷 등)가 정확하게 구현되었는지 확인해야 합니다.
• 데이터 교환 검증: 각 모듈이 전달하는 데이터의 형식, 값, 범위 등이 정의된 요구사항에 부합하는지 꼼꼼히 검증할 필요가 있습니다.

1.2. 통합 전략 및 단계에 따른 관리

• 통합 방식에 따른 접근: 상향식, 하향식 또는 혼합형 등 선택한 통합 전략에 맞추어 단계별 결합 시 발생할 수 있는 문제를 체계적으로 관리해야 합니다.
• 드라이버와 스텁의 적절한 사용: 완성되지 않은 모듈을 대신할 드라이버(Driver)나 스텁(Stub)이 올바르게 동작하는지, 그리고 실제 모듈로 대체될 경우 문제가 없도록 확인합니다.

1.3. 테스트 환경의 구성 및 데이터 준비

• 환경 일관성: 통합 테스트 환경이 실제 운영 환경과 최대한 유사하도록 구성되어야 합니다. 이는 서버, 네트워크, 데이터베이스 등 모든 외부 의존성이 포함됩니다.
• 테스트 데이터: 정확한 테스트 데이터를 마련하여, 모듈 간 데이터 흐름 및 상호작용이 정확하게 검증될 수 있도록 준비합니다.

1.4. 자동화 및 회귀 테스트의 중요성

• 자동화 테스트 도구 활용: 통합 테스트가 반복적으로 진행될 수 있으므로, 기존 통합 케이스에 대한 자동화 회귀 테스트 체계를 구축하여 코드 변경 시 전체 시스템이 여전히 안정적으로 작동하는지 신속하게 확인해야 합니다.
• 테스트 케이스 관리: 연결된 각 모듈의 상호작용에 대한 테스트 케이스를 면밀히 작성하고, 변경 사항이 발생할 때마다 이를 업데이트하여 일관성을 유지해야 합니다.

1.5. 팀 간 커뮤니케이션 및 문서화

• 정기 리뷰: 개발팀과 QA팀 및 관련 부서가 정기적으로 만나, 모듈 간 통합 시 발생할 수 있는 문제의 원인과 해결 방안을 공유하는 것이 중요합니다.
• 문서 관리: 인터페이스 명세, 통합 테스트 케이스, 테스트 결과 및 발견된 결함들을 체계적으로 문서화하여, 추후 문제 분석 및 개선 방안을 마련하고 변경 관리에 활용해야 합니다.

 

 

2. 실제 적용 사례

사례: 전자상거래 웹사이트 통합 테스트

상황: 한 대형 전자상거래 기업에서는 상품 등록, 결제 처리, 주문 확인 등 여러 모듈이 개별적으로 단위 테스트를 통과한 후, 이들 모듈을 결합하는 통합 테스트를 진행하였습니다.

문제 발생:

• 인터페이스 불일치: 주문 처리 모듈과 결제 처리 모듈 사이 인터페이스에서 데이터 포맷 불일치 문제가 발견되었습니다. 결제 모듈은 주문 정보의 특정 필드를 다른 형식으로 전달받아야 하는데, 실제로는 예상과 다르게 전달되면서 결제 승인 과정에서 오류가 발생하였습니다.
• 드라이버/스텁 문제: 초기 테스트 시, 개발 중인 최신 주문 모듈 대신 임시 스텁을 사용했는데, 이 스텁이 실제 모듈과 완벽하게 대체되지 않아 통합 후 실제 주문 데이터 처리 과정에서 예외 상황이 발생했습니다.

QA 대응:

• 재검토 및 수정: QA팀은 인터페이스 명세서를 다시 확인하고, 주문 처리와 결제 모듈 간의 데이터 포맷을 재정의하였습니다. 이후, 양 모듈이 동일한 표준을 따르도록 개발팀과 협의하여 코드를 수정하였습니다.
• 드라이버 및 스텁 교체: 임시 스텁을 실제 모듈과 유사한 동작을 보장하는 모의 객체(Mock)로 대체한 후, 통합 테스트를 재실시하여 문제를 해결하였습니다.
• 자동화 회귀 테스트: 이후 동일 인터페이스를 사용하는 기능들에 대해 자동화 회귀 테스트를 추가하여, 앞으로 유사한 문제가 재발하지 않도록 시스템 전반의 안정성을 확보했습니다.

결과: 이러한 조치들을 통해 전자상거래 시스템의 통합 과정에서 발생할 수 있는 유사 문제들을 조기에 발견하고 수정함으로써 최종 시스템의 신뢰성과 안정성을 크게 향상시킬 수 있었습니다.

 

통합 테스팅 단계에서는 모듈 간의 인터페이스와 데이터 흐름, 환경 설정 등이 전체 시스템에 미치는 영향을 꼼꼼히 검증하는 것이 매우 중요합니다.

QA 엔지니어는 이를 위해 테스트 환경 구성, 포괄적 테스트 케이스 작성, 자동화 회귀 테스트, 그리고 팀 간 원활한 커뮤니케이션 및 문서 관리를 철저하게 진행해야 합니다.

실제 사례에서도 보듯, 초기 통합 단계에서 발견된 문제를 신속하게 조치함으로써 후속 테스트 및 운영 단계에서 발생할 리스크를 크게 줄일 수 있습니다.

---

통합 테스팅은 단위 테스트 이후 여러 모듈들이 함께 작동하는지를 검증하는 중요한 단계입니다.

각 모듈 간의 연결과 데이터 흐름, 인터페이스의 정확한 동작을 검증함으로써, 시스템 전체의 안정성과 품질을 보장할 수 있습니다.

QA 엔지니어는 체계적인 통합 전략 수립, 환경 구성, 세밀한 테스트 케이스 작성 및 자동화 회귀 테스트 도구 활용 등을 통해 통합 테스팅 과정에서 발생할 수 있는 다양한 이슈를 효과적으로 관리하실 수 있도록 노력해야 합니다.