what is integration testing
통합 테스트 란 무엇입니까 : 통합 테스트 예제로 배우기
통합 테스트는 통합되었을 때 모듈 / 구성 요소를 테스트하여 예상대로 작동하는지 확인하기 위해 수행됩니다. 즉, 제대로 작동하는 모듈을 개별적으로 테스트하기 위해 통합시 문제가 없습니다.
블랙 박스 테스트 기법을 사용하여 대규모 애플리케이션을 테스트하는 관점에서 이야기 할 때 서로 밀접하게 결합 된 여러 모듈의 조합을 포함합니다. 이러한 유형의 시나리오를 테스트하기 위해 통합 테스트 기술 개념을 적용 할 수 있습니다.
이 시리즈에서 다루는 자습서 목록 :
튜토리얼 # 1 : 통합 테스트 란 무엇입니까? (이 튜토리얼)
튜토리얼 # 2 : 증분 테스트 란?
튜토리얼 # 3 : 구성 요소 테스트 란?
튜토리얼 # 4 : 지속적인 통합
튜토리얼 # 5 단위 테스트와 통합의 차이점
튜토리얼 # 6 : 상위 10 가지 통합 테스트 도구
학습 내용 :
- 통합 테스트 란 무엇입니까?
- 통합 테스트가 필요한 이유
- 장점
- 도전
- 통합 테스트 유형
- 테스트 통합 접근 방식
- GUI 애플리케이션 통합 테스트
- 통합 테스트 시작 단계
- 통합 테스트를위한 진입 / 종료 기준
- 통합 테스트 사례
- 통합은 화이트 박스 또는 블랙 박스 기술입니까?
- 통합 테스트 도구
- 시스템 통합 테스트
- 통합 테스트와 시스템 테스트의 차이점
- 결론
- 추천 도서
통합 테스트 란 무엇입니까?
통합 테스트의 의미는 매우 간단합니다. 단위 테스트 모듈을 하나씩 통합 / 결합하고 결합 된 단위로 동작을 테스트합니다.
이 테스트의 주요 기능 또는 목표는 장치 / 모듈 간의 인터페이스를 테스트하는 것입니다.
우리는 일반적으로 '단위 테스트'후에 통합 테스트를 수행합니다. 모든 개별 유닛이 생성되고 테스트되면 'Unit Tested'모듈을 결합하고 통합 테스트를 시작합니다.
이 테스트의 주요 기능 또는 목표는 장치 / 모듈 간의 인터페이스를 테스트하는 것입니다.
개별 모듈은 먼저 개별적으로 테스트됩니다. 모듈이 단위 테스트를 마치면 모든 모듈이 통합 될 때까지 하나씩 통합되어 조합 동작을 확인하고 요구 사항이 올바르게 구현되었는지 여부를 검증합니다.
여기서 우리는 통합 테스트가주기가 끝날 때 발생하는 것이 아니라 개발과 동시에 수행된다는 것을 이해해야합니다. 따라서 대부분의 경우 모든 모듈은 실제로 테스트 할 수 없으며 여기에 존재하지 않는 것을 테스트하는 데 어려움이 있습니다!
통합 테스트가 필요한 이유
통합 테스트는 복잡하고 약간의 개발과 논리적 기술이 필요하다고 생각합니다. 사실입니다! 그렇다면이 테스트를 테스트 전략에 통합하는 목적은 무엇입니까?
몇 가지 이유가 있습니다.
- 실제로 응용 프로그램이 개발되면 더 작은 모듈로 분할되고 개별 개발자에게 1 개의 모듈이 할당됩니다. 한 개발자가 구현 한 로직은 다른 개발자와 상당히 다르기 때문에 개발자가 구현 한 로직이 기대에 맞는지 확인하고 규정 된 기준에 따라 올바른 값을 렌더링하는 것이 중요합니다.
- 한 모듈에서 다른 모듈로 이동할 때 데이터의 얼굴이나 구조가 변경되는 경우가 많습니다. 일부 값이 추가되거나 제거되어 이후 모듈에서 문제가 발생합니다.
- 모듈은 또한 일부 타사 도구 또는 API와 상호 작용하며 해당 API / 도구에서 허용되는 데이터가 정확하고 생성 된 응답도 예상 한대로 테스트되어야합니다.
- 테스트의 매우 일반적인 문제 – 잦은 요구 사항 변경! :) 개발자가 단위 테스트없이 변경 사항을 배포하는 경우가 많습니다. 이때 통합 테스트가 중요해졌습니다.
장점
이 테스트에는 몇 가지 장점이 있으며 그 중 몇 가지가 아래에 나열되어 있습니다.
- 이 테스트는 통합 모듈 / 구성 요소가 제대로 작동하는지 확인합니다.
- 테스트 할 모듈을 사용할 수있게되면 통합 테스트를 시작할 수 있습니다. 스텁과 드라이버를 동일하게 사용할 수 있으므로 테스트를 수행하기 위해 다른 모듈을 완료 할 필요가 없습니다.
- 인터페이스와 관련된 오류를 감지합니다.
도전
다음은 통합 테스트와 관련된 몇 가지 과제입니다.
#1) 통합 테스트는 시스템이 제대로 작동하는지 확인하기 위해 둘 이상의 통합 시스템을 테스트하는 것을 의미합니다. 통합 링크를 테스트해야 할뿐만 아니라 환경을 고려한 철저한 테스트를 통해 통합 시스템이 제대로 작동하는지 확인해야합니다.
통합 시스템을 테스트하는 데 적용 할 수있는 다른 경로와 순열이있을 수 있습니다.
#두) 통합 테스트 관리는 데이터베이스, 플랫폼, 환경 등과 같은 몇 가지 요인으로 인해 복잡해집니다.
#삼) 새로운 시스템을 레거시 시스템과 통합하는 동안 많은 변경과 테스트 노력이 필요합니다. 두 개의 레거시 시스템을 통합하는 동안에도 동일하게 적용됩니다.
# 4) 서로 다른 두 회사에서 개발 한 두 개의 서로 다른 시스템을 통합하는 것은 시스템 중 하나에서 변경 사항이 발생하는 경우 시스템 중 하나가 다른 시스템에 어떤 영향을 미치는지 확실하지 않기 때문에 큰 도전입니다.
시스템을 개발하는 동안 영향을 최소화하기 위해 다른 시스템과의 통합 가능성 등과 같은 몇 가지 사항을 고려해야합니다.
통합 테스트 유형
다음은 장단점과 함께 테스트 통합 유형입니다.
빅뱅 접근 방식 :
빅뱅 접근 방식은 모든 모듈을 한 번에 통합합니다. 즉, 모듈을 하나씩 통합하는 데는 적합하지 않습니다. 시스템이 예상대로 작동하는지 한 번 통합되지 않았는지 확인합니다. 완전히 통합 된 모듈에서 문제가 발견되면 어떤 모듈이 문제를 일으켰는지 파악하기가 어려워집니다.
빅뱅 접근 방식은 시간이 걸리는 결함이있는 모듈을 찾는 데 시간이 많이 소요되는 프로세스이며, 결함이 발견되면 나중에 결함이 발견되므로 수정하는 데 많은 비용이 듭니다.
빅뱅 접근 방식의 장점 :
- 소규모 시스템에 적합한 접근 방식입니다.
빅뱅 접근 방식의 단점 :
- 문제를 일으키는 모듈을 감지하기가 어렵습니다.
- 빅뱅 접근 방식은 테스트를 위해 모든 모듈을 모두 함께 요구하므로 설계, 개발, 통합에 대부분의 시간이 걸리므로 테스트 시간이 줄어 듭니다.
- 테스트는 한 번만 수행되므로 중요한 모듈 테스트를 격리 할 시간이 없습니다.
통합 테스트 단계 :
- 통합 준비 테스트 계획.
- 통합 테스트 시나리오 및 테스트 사례를 준비합니다.
- 테스트 자동화 스크립트를 준비합니다.
- 테스트 케이스를 실행하십시오.
- 결함을보고하십시오.
- 결함을 추적하고 다시 테스트합니다.
- 통합 테스트가 완료 될 때까지 재 테스트 및 테스트가 계속됩니다.
테스트 통합 접근 방식
테스트 통합을 수행하는 데는 기본적으로 두 가지 접근 방식이 있습니다.
- 상향식 접근 방식
- 하향식 접근.
접근 방식을 테스트하기 위해 아래 그림을 고려해 보겠습니다.
상향식 접근 방식 :
이름에서 알 수 있듯이 상향식 테스트는 애플리케이션의 가장 낮은 단위 또는 가장 안쪽 단위에서 시작하여 점차 위로 올라갑니다. 통합 테스트는 가장 낮은 모듈에서 시작하여 점차적으로 애플리케이션의 상위 모듈로 진행됩니다. 이 통합은 모든 모듈이 통합되고 전체 애플리케이션이 단일 장치로 테스트 될 때까지 계속됩니다.
이 경우 모듈 B1C1, B1C2 & B2C1, B2C2는 단위 테스트를 거친 가장 낮은 모듈입니다. 모듈 B1 및 B2는 아직 개발되지 않았습니다. 모듈 B1 및 B2의 기능은 모듈 B1C1, B1C2 & B2C1, B2C2를 호출한다는 것입니다. B1과 B2는 아직 개발되지 않았기 때문에 B1C1, B1C2 & B2C1, B2C2 모듈을 호출 할 프로그램이나 '자극기'가 필요합니다. 이러한 자극 프로그램은 드라이버 .
간단히 말해서 드라이버 호출 함수가 존재하지 않는 경우 최하위 모듈의 함수를 호출하는 데 사용되는 더미 프로그램입니다. 상향식 기술을 사용하려면 테스트중인 모듈의 인터페이스에 테스트 케이스 입력을 공급하는 모듈 드라이버가 필요합니다.
이 접근 방식의 장점은 프로그램의 가장 낮은 단위에 중대한 오류가있는 경우이를 감지하기 쉽고 수정 조치를 취할 수 있다는 것입니다.
단점은 마지막 모듈이 통합되고 테스트 될 때까지 기본 프로그램이 실제로 존재하지 않는다는 것입니다. 결과적으로 더 높은 수준의 설계 결함은 마지막에만 감지됩니다.
하향식 접근 방식
이 기술은 최상위 모듈에서 시작하여 점차 하위 모듈로 진행됩니다. 상단 모듈 만 분리 된 상태에서 단위 테스트를 거칩니다. 그 후 하단 모듈이 하나씩 통합됩니다. 이 과정은 모든 모듈이 통합되고 테스트 될 때까지 반복됩니다.
숙련 된 pdf를위한 html5 인터뷰 질문 및 답변
그림의 맥락에서 테스트는 모듈 A에서 시작하고 하위 모듈 B1과 B2는 하나씩 통합됩니다. 이제 여기에서 하위 모듈 B1 및 B2는 실제로 통합에 사용할 수 없습니다. 따라서 최상위 모듈 A를 테스트하기 위해 ' 스텁 ”.
'스텁'은 최상위 모듈의 입력 / 요청을 수락하고 결과 / 응답을 반환하는 코드 조각이라고 할 수 있습니다. 이렇게하면 하위 모듈이 존재하지 않더라도 상위 모듈을 테스트 할 수 있습니다.
실제 시나리오에서 스텁의 동작은 보이는 것처럼 간단하지 않습니다. 모듈이라고 불리는 복잡한 모듈과 아키텍처의 시대에, 대부분의 경우 데이터베이스에 연결하는 것과 같은 복잡한 비즈니스 로직이 포함됩니다. 결과적으로 스텁 생성은 실제 모듈만큼 복잡하고 시간이 걸립니다. 어떤 경우에는 Stub 모듈이 자극 된 모듈보다 더 큰 것으로 판명 될 수 있습니다.
스텁과 드라이버는 모두 '존재하지 않는'모듈을 테스트하는 데 사용되는 더미 코드입니다. 함수 / 메소드를 트리거하고 예상되는 동작과 비교되는 응답을 반환합니다.
다음과 같은 차이점을 결론 지겠습니다. 스텁 및 드라이버 :
스텁 | 운전사 |
---|---|
하향식 접근 방식에 사용 | 상향식 접근 방식에 사용 |
최상위 모듈이 먼저 테스트됩니다. | 가장 낮은 모듈이 먼저 테스트됩니다. |
낮은 수준의 구성 요소를 자극합니다. | 더 높은 수준의 구성 요소를 자극합니다. |
하위 수준 구성 요소의 더미 프로그램 | 상위 레벨 구성 요소 용 더미 프로그램 |
유일한 변화는이 세상에서 상수입니다. 그래서 우리는“ 샌드위치 테스트 ”는 하향식 및 상향식 접근 방식의 기능을 결합합니다. 운영 체제와 같은 거대한 프로그램을 테스트 할 때 효율적이고 더 많은 신뢰를 높일 수있는 몇 가지 기술이 필요합니다. 샌드위치 테스트는 여기에서 매우 중요한 역할을합니다. 여기서 하향식 및 상향식 테스트가 동시에 시작됩니다.
통합은 중간 계층에서 시작하여 동시에 위아래로 이동합니다. 그림의 경우 테스트는 B1 및 B2에서 시작되며 한 암은 상위 모듈 A를 테스트하고 다른 암은 하위 모듈 B1C1, B1C2 및 B2C1, B2C2를 테스트합니다.
두 접근 방식이 동시에 시작되기 때문에이 기술은 약간 복잡하고 특정 기술 세트와 함께 더 많은 사람이 필요하므로 비용이 추가됩니다.
GUI 애플리케이션 통합 테스트
이제 블랙 박스 기법에서 통합 테스트를 내포하는 방법에 대해 이야기 해 보겠습니다.
우리 모두는 웹 애플리케이션이 다 계층 애플리케이션이라는 것을 이해합니다. 사용자가 볼 수있는 프런트 엔드가 있고, 비즈니스 로직이있는 중간 계층이 있고, 일부 유효성 검사를 수행하고, 일부 제 3 자 API를 통합하는 중간 계층이 더 있습니다. 데이터 베이스.
통합 테스트 예 :
아래 예를 확인해 봅시다:
나는 광고 회사의 소유자이며 다른 웹 사이트에 광고를 게시합니다. 월말에 내 광고를 본 사람과 내 광고를 클릭 한 사람이 몇 명인지 알고 싶습니다. 게재 된 광고에 대한 보고서가 필요하며 이에 따라 고객에게 비용을 청구합니다.
GenNext 소프트웨어 저를 위해이 제품을 개발했으며 아래는 아키텍처였습니다.
양파 – 모든 입력이 제공되는 최종 사용자가 볼 수있는 사용자 인터페이스 모듈.
BL – 모든 계산 및 비즈니스 특정 방법을 포함하는 비즈니스 로직 모듈입니다.
발 – 입력의 정확성에 대한 모든 유효성 검사를 포함하는 유효성 검사 모듈입니다.
CNT – 사용자가 입력 한 입력과 관련된 모든 정적 콘텐츠를 포함하는 콘텐츠 모듈입니다. 이러한 내용은 보고서에 표시됩니다.
에 – Engine 모듈 인이 모듈은 BL, VAL 및 CNT 모듈에서 오는 모든 데이터를 읽고 SQL 쿼리를 추출하여 데이터베이스에 트리거합니다.
스케줄러 – 사용자 선택 (월별, 분기 별, 반기 별 및 연간)에 따라 모든 보고서를 예약하는 모듈입니다.
DB – 데이터베이스입니다.
이제 전체 웹 애플리케이션의 아키텍처를 단일 단위로 보았으므로이 경우 통합 테스트는 모듈 간의 데이터 흐름에 초점을 맞출 것입니다.
여기에 질문은 다음과 같습니다.
- BL, VAL 및 CNT 모듈은 UI 모듈에 입력 된 데이터를 어떻게 읽고 해석합니까?
- BL, VAL 및 CNT 모듈이 UI에서 올바른 데이터를 수신하고 있습니까?
- BL, VAL 및 CNT의 데이터는 어떤 형식으로 EQ 모듈로 전송됩니까?
- EQ는 어떻게 데이터를 읽고 쿼리를 추출합니까?
- 쿼리가 올바르게 추출 되었습니까?
- 스케줄러가 보고서에 대한 올바른 데이터를 얻습니까?
- EN이 데이터베이스에서받은 결과 세트가 정확하고 예상대로입니까?
- EN이 BL, VAL 및 CNT 모듈로 응답을 다시 보낼 수 있습니까?
- UI 모듈이 데이터를 읽고 인터페이스에 적절하게 표시 할 수 있습니까?
현실 세계에서 데이터 통신은 XML 형식으로 이루어집니다. 따라서 사용자가 UI에 입력하는 데이터는 XML 형식으로 변환됩니다.
이 시나리오에서 UI 모듈에 입력 된 데이터는 3 개의 모듈 BL, VAL 및 CNT에 의해 해석되는 XML 파일로 변환됩니다. EN 모듈은 3 개의 모듈에 의해 생성 된 결과 XML 파일을 읽고 여기에서 SQL을 추출하고 데이터베이스에 쿼리합니다. EN 모듈은 또한 결과 집합을 수신하여 XML 파일로 변환 한 다음 결과를 사용자가 읽을 수있는 형식으로 변환하여 표시하는 UI 모듈로 다시 반환합니다.
중간에는 EN 모듈에서 결과 집합을 수신하고 보고서를 생성 및 예약하는 스케줄러 모듈이 있습니다.
그렇다면 통합 테스트는 어디에 있습니까?
글쎄, 정보 / 데이터가 올바르게 흐르는 지 여부를 테스트하는 것은 통합 테스트가 될 것입니다.이 경우 XML 파일의 유효성을 검사합니다. XML 파일이 올바르게 생성 되었습니까? 정확한 데이터가 있습니까? 데이터가 한 모듈에서 다른 모듈로 올바르게 전송되고 있습니까? 이 모든 것들은 통합 테스트의 일부로 테스트됩니다.
XML 파일을 생성하거나 가져오고 태그를 업데이트하고 동작을 확인하십시오. 이것은 테스터가 일반적으로 수행하는 일반적인 테스트와는 매우 다르지만 테스터의 응용 프로그램에 대한 지식과 이해에 가치를 더할 것입니다.
다른 몇 가지 샘플 테스트 조건은 다음과 같습니다.
- 메뉴 옵션이 올바른 창을 생성합니까?
- 창에서 테스트중인 창을 호출 할 수 있습니까?
- 모든 창에 대해 응용 프로그램이 허용해야하는 창에 대한 함수 호출을 식별합니다.
- 창에서 응용 프로그램이 허용해야하는 다른 기능에 대한 모든 호출 식별
- 되돌릴 수있는 통화 식별 : 호출 된 창을 닫으면 호출 한 창으로 돌아갑니다.
- 되돌릴 수없는 통화 식별 : 호출 창이 표시되기 전에 호출 창이 닫힙니다.
- 다른 창에 대한 호출을 실행하는 다양한 방법을 테스트합니다. – 메뉴, 버튼, 키워드.
통합 테스트 시작 단계
- 애플리케이션의 아키텍처를 이해합니다.
- 모듈 식별
- 각 모듈의 기능 이해
- 데이터가 한 모듈에서 다른 모듈로 전송되는 방식을 이해합니다.
- 데이터가 시스템에 입력되고 수신되는 방식 이해 (응용 프로그램의 진입 점 및 종료점)
- 테스트 요구 사항에 맞게 응용 프로그램을 분리하십시오.
- 테스트 조건 식별 및 생성
- 한 번에 하나의 조건을 취하고 테스트 케이스를 기록하십시오.
통합 테스트를위한 진입 / 종료 기준
참가 기준 :
- 통합 테스트 계획 문서가 서명되고 승인되었습니다.
- 통합 테스트 케이스가 준비되었습니다.
- 테스트 데이터가 생성되었습니다.
- 단위 테스트 개발 된 모듈 / 컴포넌트의 수가 완료되었습니다.
- 모든 중요 및 높은 우선 순위 결함이 닫힙니다.
- 통합을 위해 테스트 환경이 설정되었습니다.
종료 기준 :
- 모든 통합 테스트 케이스가 실행되었습니다.
- 중요 및 우선 순위 P1 및 P2 결함이 열리지 않습니다.
- 테스트 보고서가 준비되었습니다.
통합 테스트 사례
통합 테스트 케이스는 주로 모듈 간 인터페이스, 통합 링크, 데이터 전송 이미 단위 테스트를 거친 모듈 / 구성 요소로서의 모듈 간, 즉 기능 및 기타 테스트 측면은 이미 다루었습니다.
따라서 주요 아이디어는 두 개의 작업 모듈을 통합 할 때 예상대로 작동하는지 테스트하는 것입니다.
Linkedin 애플리케이션에 대한 통합 테스트 사례의 예에는 다음이 포함됩니다.
- 로그인 페이지와 홈 페이지 사이의 인터페이스 링크 확인, 즉 사용자가 자격 증명을 입력하고 로그인 할 때 홈 페이지로 이동해야합니다.
- 홈페이지와 프로필 페이지, 즉 프로필 페이지 사이의 인터페이스 링크를 확인하면 열립니다.
- 네트워크 페이지와 연결 페이지 사이의 인터페이스 링크를 확인합니다. 즉, 네트워크 초대 페이지에서 수락 버튼을 클릭하면 클릭하면 연결 페이지에 수락 된 초대가 표시됩니다.
- 알림 페이지 사이의 인터페이스 링크를 확인하고 축하 버튼을 말합니다. 즉, 축하 버튼을 클릭하면 새 메시지 창으로 이동합니다.
이 특정 사이트에 대해 많은 통합 테스트 케이스를 작성할 수 있습니다. 위의 네 가지 사항은 테스트에 포함 된 통합 테스트 케이스를 이해하기위한 예일뿐입니다.
통합은 화이트 박스 또는 블랙 박스 기술입니까?
통합 테스트 기술은 블랙 박스뿐만 아니라 화이트 박스 기법 . 블랙 박스 기법 테스터는 시스템에 대한 내부 지식이 필요하지 않습니다. 즉, 코딩 지식이 필요하지 않은 반면 화이트 박스 기술은 애플리케이션에 대한 내부 지식이 필요합니다.
이제 통합 테스트를 수행하는 동안 데이터베이스에서 데이터를 가져오고 필요에 따라 데이터를 제공하는 두 개의 통합 웹 서비스 테스트를 포함 할 수 있습니다. 즉, 웹 사이트의 새로운 기능을 통합하는 동안 테스트 할 수있는 반면 화이트 박스 테스트 기술을 사용하여 테스트 할 수 있습니다. 블랙 박스 기법을 사용합니다.
따라서 통합 테스트가 블랙 박스 또는 화이트 박스 기술이라는 것은 구체적이지 않습니다.
통합 테스트 도구
이 테스트에 사용할 수있는 몇 가지 도구가 있습니다.
다음은 도구 목록입니다.
- 합리적 통합 테스터
- 길게 끄는 것
- 증기
- 테시
위의 도구에 대한 자세한 내용은이 자습서를 확인하십시오.
시스템 통합 테스트
시스템 통합 테스트는 완전한 통합 시스템 .
모듈 또는 구성 요소는 구성 요소를 통합하기 전에 단위 테스트에서 개별적으로 테스트됩니다.
모든 모듈이 테스트되면 모든 모듈을 통합하여 시스템 통합 테스트가 수행되고 시스템 전체가 테스트됩니다.
통합 테스트와 시스템 테스트의 차이점
통합 테스트는 단위 테스트 된 하나 또는 두 개의 모듈이 테스트를 위해 통합되고 통합 모듈이 예상대로 작동하는지 확인하기 위해 수행되는 테스트입니다.
시스템 테스트는 시스템 전체 즉, 모든 모듈 / 구성 요소가 함께 통합되어 시스템이 예상대로 작동하고 통합 모듈로 인해 문제가 발생하지 않는지 확인합니다.
결론
이것은 통합 테스트와 화이트 박스 및 블랙 박스 기술 모두에서 구현에 관한 것입니다. 관련 사례를 통해 명확하게 설명했으면합니다.
테스트 통합은 첫 번째 단계에서 모든 모듈을 모두 통합하기 위해 둘 이상의 모듈이 통합 될 때 결함을 쉽게 찾을 수 있도록하므로 테스트주기의 중요한 부분입니다.
초기 단계에서 결함을 찾는 데 도움이되므로 노력과 비용도 절약됩니다. 통합 모듈이 예상대로 제대로 작동하는지 확인합니다.
통합 테스트에 대한이 유익한 튜토리얼이 개념에 대한 지식을 풍부하게했기를 바랍니다.