인터페이스 테스트란 무엇입니까? 유형 및 예
⚡ 스마트 요약
인터페이스 테스트는 연결된 두 소프트웨어 시스템이 데이터를 올바르게 교환하는지 확인하는 과정입니다. 웹 서버, 애플리케이션 서버, 데이터베이스 서버 간의 연결을 포함하여 애플리케이션이 보내는 모든 요청과 관련된 오류 처리를 모두 검증합니다.
인터페이스 테스트란 무엇입니까?
인터페이스 테스트 이는 서로 다른 두 소프트웨어 시스템 간의 통신이 올바르게 이루어지는지 검증하는 소프트웨어 테스트 유형으로 정의됩니다.
두 구성 요소를 연결하는 것을 인터페이스라고 합니다. 컴퓨터 세계에서 인터페이스는 API, 웹 서비스 등 무엇이든 될 수 있습니다. 이러한 연결 서비스 또는 인터페이스를 테스트하는 것을 인터페이스 테스트라고 합니다.
인터페이스는 실제로 장치와 사용자 간의 통신을 가능하게 하는 명령, 메시지 및 기타 속성 세트로 구성된 소프트웨어입니다.
중요한 점은 인터페이스에는 단점이 있다는 것입니다.tract: 합의된 요청 형식, 합의된 응답 형식, 합의된 오류 코드 세트 및 합의된 타임아웃. 인터페이스 테스트 연습에는 다음이 포함됩니다.trac양측에서 변경 사항이 발생하더라도 다른 팀에 조용히 영향을 미치지 않습니다. 대부분의 트래픽이 화면에 도달하지 않기 때문에 발견된 결함은 다른 사용자에게 보이지 않습니다. 블랙 박스 테스트 사용자 인터페이스만을 통해 수행됩니다.
인터페이스 테스트를 수행하는 방법
인터페이스 테스트에는 다음 두 가지 주요 부문에 대한 테스트가 포함됩니다.
- 웹 서버 및 애플리케이션 서버 인터페이스
- 애플리케이션 서버 및 데이터베이스 서버 인터페이스.
위에서 언급한 시나리오의 경우 인터페이스 테스트는 다음과 같이 수행됩니다.
- 서버가 제대로 실행되고 있는지 확인하세요
- 오류는 적절하게 처리되거나 애플리케이션에서 수행된 쿼리에 대해 오류 메시지를 반환합니다.
- 중간에 웹 서버 연결이 재설정될 때의 결과를 확인하세요.
아래 다이어그램은 브라우저와 웹 서버, 웹 서버와 애플리케이션 서버, 그리고 애플리케이션 서버와 데이터베이스 서버 간의 통신을 하나의 체인으로 보여줍니다.
실제로 테스터는 해당 과정을 한 단계씩 순차적으로 진행합니다. 각 단계는 먼저 유효한 요청으로 시작하고, 그 다음에는 형식이 잘못된 요청으로 진행하며, 마지막으로는 최종 목적지에 의도적으로 접근할 수 없도록 하여 성공 경로와 실패 경로 모두를 동일한 시스템에 기록합니다. 테스트 사례.
인터페이스 테스트의 예
임의의 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 — 요청 형식, 응답 형식, 오류 코드 및 시간 초과 | 포커스는 구성 요소들이 결합된 후 나타나는 결합된 동작에 있습니다. |
| 사양이 존재하는 즉시 실행 가능하며, 최종 끝 부분은 스텁 처리됩니다. | 참여 구성 요소들을 함께 구축하고 배포해야 합니다. |
| 오류는 연결 부분 중 하나에서 발생합니다. | 고장은 조립된 그룹 내의 어느 구성 요소에서든 발생할 수 있습니다. |
이 분야에 처음 접하는 사람은 누구나 아래 설명된 주변 수준들을 쉽게 이해할 수 있을 것입니다. 통합 테스트 일반적으로 소프트웨어 테스팅 서론에서 언급된 용어는 표준에서 유래한 것입니다. 소프트웨어 공학 연습 과정에서 그렇습니다. 브라우저 기반 시스템의 경우, 동일한 연결이 결국 다시 사용됩니다. 웹 애플리케이션 테스트.

