인터페이스 테스트란 무엇입니까? 유형 및 예

⚡ 스마트 요약

인터페이스 테스트는 연결된 두 소프트웨어 시스템이 데이터를 올바르게 교환하는지 확인하는 과정입니다. 웹 서버, 애플리케이션 서버, 데이터베이스 서버 간의 연결을 포함하여 애플리케이션이 보내는 모든 요청과 관련된 오류 처리를 모두 검증합니다.

  • 🔗 정의: 인터페이스는 API, 웹 서비스 또는 메시지 큐와 같이 두 구성 요소를 연결하는 모든 연결을 의미합니다.
  • 🧭 두 부분: 테스트는 웹 서버와 애플리케이션 서버 간의 연결 및 애플리케이션 서버와 데이터베이스 서버 간의 연결을 대상으로 합니다.
  • 📄 실제 예제: XML 입력과 JSON 출력은 게시된 형식 사양에 따라 유효성 검사를 거칩니다.
  • 🧪 테스트 유형 : 워크플로, 예외 상황, 성능 및 부하, 그리고 각 시스템을 개별적으로 테스트합니다.
  • 🛠️ 압형: API 클라이언트와 서비스 가상화는 사용자가 클릭할 수 있는 인터페이스가 없을 때 요청을 처리합니다.
  • 🔍 범위 경계: 인터페이스 테스트는 연결 상태에 초점을 맞춘 통합 테스트의 하위 유형입니다.trac그 자체로.

웹 서버, 애플리케이션 서버 및 데이터베이스 서버 간의 인터페이스 테스트

인터페이스 테스트란 무엇입니까?

인터페이스 테스트 이는 서로 다른 두 소프트웨어 시스템 간의 통신이 올바르게 이루어지는지 검증하는 소프트웨어 테스트 유형으로 정의됩니다.

두 구성 요소를 연결하는 것을 인터페이스라고 합니다. 컴퓨터 세계에서 인터페이스는 API, 웹 서비스 등 무엇이든 될 수 있습니다. 이러한 연결 서비스 또는 인터페이스를 테스트하는 것을 인터페이스 테스트라고 합니다.

인터페이스는 실제로 장치와 사용자 간의 통신을 가능하게 하는 명령, 메시지 및 기타 속성 세트로 구성된 소프트웨어입니다.

중요한 점은 인터페이스에는 단점이 있다는 것입니다.tract: 합의된 요청 형식, 합의된 응답 형식, 합의된 오류 코드 세트 및 합의된 타임아웃. 인터페이스 테스트 연습에는 다음이 포함됩니다.trac양측에서 변경 사항이 발생하더라도 다른 팀에 조용히 영향을 미치지 않습니다. 대부분의 트래픽이 화면에 도달하지 않기 때문에 발견된 결함은 다른 사용자에게 보이지 않습니다. 블랙 박스 테스트 사용자 인터페이스만을 통해 수행됩니다.

인터페이스 테스트를 수행하는 방법

인터페이스 테스트에는 다음 두 가지 주요 부문에 대한 테스트가 포함됩니다.

  1. 웹 서버 및 애플리케이션 서버 인터페이스
  2. 애플리케이션 서버 및 데이터베이스 서버 인터페이스.

위에서 언급한 시나리오의 경우 인터페이스 테스트는 다음과 같이 수행됩니다.

  • 서버가 제대로 실행되고 있는지 확인하세요
  • 오류는 적절하게 처리되거나 애플리케이션에서 수행된 쿼리에 대해 오류 메시지를 반환합니다.
  • 중간에 웹 서버 연결이 재설정될 때의 결과를 확인하세요.

아래 다이어그램은 브라우저와 웹 서버, 웹 서버와 애플리케이션 서버, 그리고 애플리케이션 서버와 데이터베이스 서버 간의 통신을 하나의 체인으로 보여줍니다.

웹 서버, 애플리케이션 서버 및 데이터베이스 서버 체인 전반에 걸친 인터페이스 테스트

실제로 테스터는 해당 과정을 한 단계씩 순차적으로 진행합니다. 각 단계는 먼저 유효한 요청으로 시작하고, 그 다음에는 형식이 잘못된 요청으로 진행하며, 마지막으로는 최종 목적지에 의도적으로 접근할 수 없도록 하여 성공 경로와 실패 경로 모두를 동일한 시스템에 기록합니다. 테스트 사례.

인터페이스 테스트의 예

임의의 xyz 애플리케이션에 대해 인터페이스가 다음과 같다고 가정해 봅시다. XML 파일을 입력으로 받아 결과를 반환합니다. JSON 파일을 출력 형식으로 사용합니다. 이 애플리케이션의 인터페이스를 테스트하려면 XML 파일 형식과 JSON 파일 형식에 대한 사양만 있으면 됩니다.

이러한 명세를 활용하여 샘플 입력 XML 파일을 생성하고 인터페이스에 입력할 수 있습니다. 그런 다음 입력(XML) 및 출력(JSON) 파일이 요구 사항을 충족하는지 검증하는 것이 인터페이스 테스트입니다.

이 예시에서 무엇이 필요 없는지 주목해 보세요. 화면도 필요 없고, 프런트엔드 빌드도 필요 없고, 인터페이스 내부 코드에 대한 지식도 필요 없습니다. 두 가지 형식 명세만 있으면 테스트를 작성할 수 있으므로, 인터페이스 테스트는 사용자 인터페이스가 존재하기 훨씬 전에 시작할 수 있습니다.

인터페이스 테스트를 수행하는 이유

인터페이스 테스트가 완료되었습니다

  • 최종 사용자나 고객이 특정 소프트웨어 제품을 사용할 때 문제가 발생하지 않도록 하기 위해
  • 최종 사용자가 일반적으로 액세스하는 응용 프로그램 영역을 식별하고 사용자 친화성을 확인합니다.
  • 시스템 간에 통신이 전파되는 동안 보안 요구 사항을 확인하려면
  • 솔루션이 애플리케이션 서버와 웹 사이트 간의 네트워크 장애를 처리할 수 있는지 확인하려면

비용적인 측면도 고려해야 합니다. 요청 형식의 결함은 두 시스템을 연결하는 과정에서는 저렴하게 수정할 수 있지만, 하위 시스템에 이미 잘못된 데이터가 저장된 후에는 비용이 많이 듭니다.

인터페이스 테스트 유형

인터페이스 테스트 중 인터페이스에 대해 수행되는 다양한 유형의 테스트에는 다음이 포함될 수 있습니다.

  • 워크 플로우 : 이는 인터페이스 엔진이 예상대로 표준 작업 흐름을 처리하도록 보장합니다.
  • 예외적인 경우 - 예상치 못한 값: 이는 테스트 시 날짜, 월, 일을 반대로 입력하는 경우를 고려한 것입니다.
  • 성능, 부하 및 네트워크 테스트: 대용량 인터페이스는 더 많은 것을 요구할 수 있습니다. 부하 테스트 인터페이스 엔진 및 연결 인프라에 따라 저용량 인터페이스보다
  • 개별 시스템: 여기에는 각 시스템을 개별적으로 테스트하는 것이 포함됩니다. 예를 들어, 소매점의 청구 시스템과 재고 관리 시스템은 별도로 작동할 수 있어야 합니다.

첫 번째 항목은 충분히 가깝습니다. 워크플로 테스트 시나리오를 재사용하기 위해, 그리고 마지막 항목은 다음과 겹칩니다. 모듈 테스트왜냐하면 자체적으로 고장나는 시스템은 연결되는 순간 다시 고장나기 때문입니다.

인터페이스 테스트 전략

인터페이스 테스트 전략은 구현 방식에 관계없이 공통 테스트를 사용하여 인터페이스를 테스트하는 방법입니다. abs를 사용할 수 있습니다.trac인터페이스 테스트 전략의 각 구현에 대해 테스트 케이스를 생성하고 테스트 케이스의 구체적인 인스턴스를 만듭니다. 기본/절대trac테스트 케이스는 구현에 구애받지 않는 테스트를 수행하는 반면, 구체적인 테스트는 테스트할 객체를 인스턴스화하고 구현별 테스트를 수행합니다.

그 구조의 장점은 재사용성입니다. 동일한 인터페이스의 세 번째 구현이 등장할 때, 절대적인 이점은 재사용성입니다.tract suite는 변경 없이 그대로 실행되며, 인스턴스화 코드만 작성하면 됩니다. 동일한 아이디어가 더 큰 규모로 적용됩니다. 구성 요소 테스트공유된 구성 요소가 있는 곳tract suite는 해당 조건을 충족한다고 주장하는 모든 구성 요소에 대해 실행됩니다.

인터페이스 테스트 도구

인터페이스에는 화면이 없기 때문에 툴링은 요청을 직접 구성하고 원시 응답을 검증해야 합니다. 팀은 일반적으로 세 가지 범주의 툴을 조합하여 사용합니다.

  • API 클라이언트 및 요청 생성기: 같은 도구 Postman, SoapUIInsomnia와 Hoppscotch는 REST, SOAP 또는 GraphQL 호출을 보내고, 이를 재사용 가능한 컬렉션으로 저장하며, 상태 코드, 헤더 및 응답 본문을 검증합니다.
  • Code-레벨 테스트 라이브러리: 기존 테스트 스위트 내에서 실행되는 라이브러리를 사용하면 인터페이스 검사가 단위 테스트와 함께 실행되고 모든 빌드에서 실행되므로 최신 상태를 유지할 수 있습니다.
  • 로드 및 프로토콜 도구: 다음과 같은 도구 JMeter 볼륨에서 동일한 인터페이스를 구동하는데, 이것이 기능 검사를 다음과 같이 바꾸는 것입니다. 성능 시험 연결의.
  • 서비스 가상화 및 모의 테스트: 반대쪽 끝을 대신하는 짧은 연결 부품을 사용하면 다른 쪽을 사용할 수 없거나, 완료되지 않았거나, 반복적으로 호출하기에는 비용이 너무 많이 드는 경우에도 한쪽을 테스트할 수 있습니다.

클라이언트 선택보다는 커버리지가 더 중요합니다. 어떤 클라이언트를 선택하든, 요청 모음은 코드와 함께 버전 관리 시스템에 저장되어야 하므로 인터페이스 변경 사항과 테스트 변경 사항이 동일한 커밋에 포함되어야 합니다. 더 넓은 범주에 대한 자세한 내용은 해당 섹션에서 다룹니다. API 테스트.

인터페이스 테스트 체크리스트 및 모범 사례

간단한 체크리스트를 사용하면 릴리스 전반에 걸쳐 인터페이스 적용 범위를 정확하게 유지할 수 있습니다. 애플리케이션 전체가 아닌 각 연결에 대해 이 체크리스트를 확인하세요.

  • 와tract 먼저: 요청 및 응답 스키마가 데이터 유형과 선택적 필드를 포함하여 게시된 사양과 필드별로 일치하는지 확인하십시오.
  • 경계 값: 빈 페이로드, 최대 길이 필드, 예상치 못한 문자 집합 및 역순 날짜 형식을 전송하십시오.
  • 오류 경로: 모든 오류가 스택 트레이스 대신 의미 있는 코드와 메시지를 반환하는지 확인하십시오. trac혹은 조용한 성공.
  • 타임아웃 및 재시도: 요청 도중 연결을 중단하고 호출자가 트랜잭션을 중복하지 않고 안전하게 재시도하는지 확인합니다.
  • 보안 : 링크의 인증, 권한 부여 및 암호화를 확인하고 오류 메시지에 내부 정보가 유출되지 않는지 확인하십시오.
  • 데이터 일관성: 기록을 반대편에서 다시 읽어 전송 중에 잘리거나, 재인코딩되거나, 순서가 바뀌지 않았는지 확인하십시오.
  • 음량: 동시 부하 상태에서 트래픽이 가장 많은 호출을 반복하고 연결 풀 고갈 여부를 확인합니다.

다음 세 가지 사항을 실천하면 체크리스트를 반복적으로 사용할 수 있습니다. 첫째, 인터페이스는 화면보다 변경 사항이 더 미미하므로 테스트 스위트를 자동화하고 모든 빌드에서 실행하십시오. 둘째, 인터페이스 결함은 스크린샷으로는 재현하기가 거의 불가능하므로 모든 오류에 대해 전체 요청 및 응답을 로그에 기록하십시오. 셋째, 다른 테스트 스위트에서 생성된 테스트 데이터와 독립적으로 유지하여 오류가 발생했을 때 누락된 레코드가 아닌 인터페이스 자체의 결함을 지적할 수 있도록 하십시오.

이러한 점검 사항들은 앞서 설명한 더 광범위한 계획 안에 자연스럽게 포함됩니다. 소프트웨어 테스트 유형그리고 그것들은 동일한 연결이 처음부터 끝까지 실행되기 전에 실행됩니다. 시스템 테스트.

인터페이스 테스트와 통합 테스트

두 용어는 서로 반대되는 개념이라기보다는 관련이 있습니다. 인터페이스 테스트는 통합 작업의 일부로서 연결 자체에 집중하는 부분입니다. 아래 표는 각 측면의 강조점을 보여줍니다.

인터페이스 테스트 통합 테스팅
구성 요소 또는 시스템 간의 인터페이스 테스트와 관련된 통합 테스트 유형 인터페이스와 통합 구성 요소 또는 시스템 간의 상호 작용에서 결함을 노출하기 위해 수행되는 테스트입니다.
집중력이 단점이다.tract — 요청 형식, 응답 형식, 오류 코드 및 시간 초과 포커스는 구성 요소들이 결합된 후 나타나는 결합된 동작에 있습니다.
사양이 존재하는 즉시 실행 가능하며, 최종 끝 부분은 스텁 처리됩니다. 참여 구성 요소들을 함께 구축하고 배포해야 합니다.
오류는 연결 부분 중 하나에서 발생합니다. 고장은 조립된 그룹 내의 어느 구성 요소에서든 발생할 수 있습니다.

이 분야에 처음 접하는 사람은 누구나 아래 설명된 주변 수준들을 쉽게 이해할 수 있을 것입니다. 통합 테스트 일반적으로 소프트웨어 테스팅 서론에서 언급된 용어는 표준에서 유래한 것입니다. 소프트웨어 공학 연습 과정에서 그렇습니다. 브라우저 기반 시스템의 경우, 동일한 연결이 결국 다시 사용됩니다. 웹 애플리케이션 테스트.

자주 묻는 질문

일반적으로 통합 테스트를 담당하는 QA 엔지니어는 양쪽 시스템 개발자와 협력합니다. 서비스 중심 제품의 경우, 화면 탐색 능력보다는 요청 구성 능력이 더 중요하기 때문에 전담 API 테스터가 이 역할을 맡습니다.

확인할 수 있는 출력 결과가 없고, 자유롭게 호출할 수 없는 타사 엔드포인트가 있으며, 테스트 데이터가 양쪽에 모두 존재해야 하고, 사양이 예고 없이 변경되는 경우가 있습니다. 스텁과 버전 관리되는 요청 모음을 사용하면 이러한 문제들을 대부분 해결할 수 있습니다.

둘은 상당히 겹치는 부분이 많습니다. API는 인터페이스의 한 종류이므로, API 테스트 인터페이스 테스트는 해당 특정 기술에 적용됩니다. 인터페이스 테스트는 API를 포함하지 않는 파일 전송, 메시지 큐 및 데이터베이스 링크도 포함합니다.

아니요. 이름은 같지만 대상이 다릅니다. 인터페이스 테스트는 시스템 간 연결을 확인하고, 사용자 인터페이스 테스트는 화면, 컨트롤 및 레이아웃을 확인합니다. 이 둘을 혼동하면 서버 측 연결이 테스트되지 않은 상태가 됩니다.

요청 및 응답 사양에 대한 합의가 이루어지는 즉시, 일반적으로 두 시스템 모두 개발이 완료되기 전에 원격 시스템을 스텁 처리합니다. 이를 통해 테스트 스위트를 조기에 실행할 수 있으며, 두 시스템 모두 가동된 후에는 동일한 테스트 스위트를 재사용할 수 있습니다.

적어도 하나의 양성 테스트와 하나의 음성 테스트를 거친 문서화된 엔드포인트의 비율, 실제로 발생한 선언된 오류 코드의 비율, 그리고 인터페이스 결함의 수ping 후속 단계로 넘어갑니다. 검사 건수만으로는 많은 것을 알 수 없습니다.

머신 러닝은 스키마를 읽고 사람이 건너뛸 수 있는 경계 및 부정 페이로드를 생성한 다음, 실패한 응답을 클러스터링하여 하나의 근본 원인이 여덟 번 보고되는 것을 방지합니다. 또한 기존 요청과 더 이상 일치하지 않는 스키마 변경 사항을 표시합니다.

네. 스키마나 샘플 페이로드가 주어지면 요청 빌더, 어설션 및 스텁 응답을 신속하게 생성합니다. 하지만 생성된 어설션은 제공된 스키마나 페이로드의 정확성에 따라 결과가 달라지기 때문에 명세는 여전히 사람이 제공해야 합니다.trac그 뒤에 t가 있습니다.

이 게시물을 요약하면 다음과 같습니다.