모든 개발 테스트에서 인터페이스 테스트는 필수 항목입니다. 효과적이고 완전한 인터페이스 테스트는 새로운 기능의 개발 품질을 보장할 수 있을 뿐만 아니라 개발이 기능 논리를 수정할 때 반환할 수 있는 능력을 가질 수 있으며 우아한 리팩토링의 전제 조건이기도 합니다. 인터페이스 테스트를 작성할 때 따라야 하는 원칙은 무엇입니까? 테스트 코드의 구조는 어떤 모습이어야 합니까? 인터페이스 테스트를 위한 실용적인 팁은 무엇입니까? 이 기사는 인터페이스 테스트에 대한 저자의 실용적인 요약을 공유합니다.
일선 개발 학생은 온라인 버그 또는 오류를 다소 유발했을 수 있습니다. 또한 이러한 시나리오에 직면하여 특정 기능을 개발할 때 학생이 코드를 리팩토링하여 온라인 버그 또는 오류를 일으킵니다. 특정 기능에 관해서는 다른 기능이 영향을 받을 것을 두려워하여 공용 논리를 수정해야 하므로 코드가 매우 보기 흉하게 복사되고 이를 지원하기 위해 별도의 논리가 다시 작성됩니다.
위의 상황은 모두 기능 개발이든 로직 리팩토링이든 코드 개발의 품질을 보장하는 방법에 대한 핵심 문제를 포함합니다. 모두가 알고 있는 확신의 수단은 테스트입니다. 첫 번째는 새 기능의 논리가 올바른지 확인하기 위한 새 기능 테스트이고, 두 번째는 원래 비즈니스 기능의 논리가 올바른지 확인하기 위한 회귀 테스트입니다. 일반적으로 테스트에는 수동 테스트와 자동 테스트의 두 가지 방법이 있습니다. 테스트 기술 및 도구의 지속적인 개발로 수동 테스트의 비율이 점차 줄어들고 점차 자동 테스트로 대체됩니다. 자동화된 테스트는 지속 가능하고 반복 가능하며 심지어 AI를 지원합니다.
테스트 레이어
다음 다이어그램과 같이 테스트도 계층화됩니다.
시스템에서 자동 테스트는 일반적으로 단위 테스트, 모듈 테스트 및 인터페이스 테스트로 나뉩니다.
단위 테스트
현재 내 애플리케이션 코드는 기본적으로 스프링 프레임워크의 인터페이스 지향 프로그래밍 모델을 기반으로 하며 단위 테스트가 약화되었습니다. 단위 테스트의 요구 사항은 기본적으로 단일 클래스의 단일 메서드 테스트이며 현재 모드에서는 작성 비용이 너무 높습니다. 물론 도구이거나 상대적으로 응집력 있고 복잡한 논리(예: 알고리즘 논리)인 경우 논리의 정확성을 보장하기 위해 단위 테스트를 사용해야 합니다.
모듈 테스트
모듈이 많은 비교적 큰 시스템의 경우 각 모듈 기능의 정확성을 보장하기 위해 모듈 테스트 계층을 설정할 수 있습니다. 그러나 현재 시스템 개발 트렌드는 마이크로서비스 아키텍처이기 때문에 모듈 테스트 계층이 그다지 필요하지 않으며 인터페이스 테스트 계층으로 커버할 수 있습니다.
인터페이스 테스트
개인적으로 정확히는 진입 테스트라고 해야 할 것 같은데, 이 레이어는 시스템 진입부터 시작되는 통합 테스트입니다. 응용 프로그램 항목은 일반적으로 HSF(분산 RPC 서비스 프레임워크) 서비스, 메시지 및 시간 지정 작업입니다.
개발에는 수만 가지의 테스트 방법이 있으며 인터페이스 테스트는 필수 불가결합니다. 우리 응용 프로그램의 인터페이스 테스트가 유효하고 적용 범위가 완료되면 새로운 기능의 개발 품질을 보장할 수 있을 뿐만 아니라 기능 논리를 수정할 때 반환할 수 있습니다. 코드 리팩토링의 전제이기도 합니다. 동시에 테스트 가능성은 합리적인 코드 구조의 지표이기도 한데, 테스트 스크립트를 작성하기 어렵거나 테스트할 수 없는 코드 조각이 발견되면 현재 코드 구조가 비합리적이며 테스트가 필요함을 의미합니다. 리팩토링. 다음으로 인터페이스 테스트의 효율성에 대해 주로 이야기하겠습니다.
두 가지 테스트 원칙
기본 원리들:
-
자동화: 인터페이스 테스트는 사람의 참여가 필요하지 않은 비대화형 자동 실행입니다.
-
독립성: 인터페이스 테스트는 서로 의존해서는 안 됩니다.
-
반복 가능: 인터페이스 테스트는 환경에 관계없이 반복적으로 수행할 수 있습니다.
-
인터페이스 테스트는 BCDE 원칙을 준수하여 인터페이스 제공 품질을 보장합니다.
-
경계: 경계 테스트.
-
수정: 올바른 입력, 올바른 예상 출력.
-
설계: 요구 사항 및 설계 문서에 따라 테스트 논리를 작성합니다.
-
오류: 입력이 잘못되었습니다. 출력이 예상됩니다.
-
데이터 준비: 데이터 준비는 db에 직접 삽입하는 것이 아니라 시스템 서비스를 통해 수행됩니다.
-
테스트 가능성: 테스트할 수 없는 코드는 합리적인 구조로 재구성해야 합니다.
-
커버리지: 인터페이스 테스트는 모든 UC를 커버해야 하며 동시에 코드 커버리지와 분기 커버리지는 특정 표준에 도달해야 하며 새로운 코드를 커버해야 합니다.
-
연속성: 코드 수정으로 인해 기존 인터페이스 테스트가 실패하는 경우 코드 문제를 수정하거나 코드 논리를 테스트해야 합니다.
-
시간 요구 사항: 인터페이스 테스트는 프로젝트가 출시되기 전에 완료되어야 하며 프로젝트가 출시된 후에는 추가되어서는 안 됩니다.
위의 기본 원칙은 모든 레이어의 자동화된 테스트 케이스에 적용되어야 합니다.인터페이스 테스트를 작성할 때 위의 원칙 외에도 따라야 할 다른 원칙이 있습니다.먼저 그림을 보겠습니다.
시스템의 관점에서 항목 호출을 분석하려면 HSF 서비스를 예로 들어 보겠습니다.
-
주변 시스템은 당사 시스템에서 제공하는 서비스를 호출합니다.
-
시스템은 분기 논리를 포함하는 코드 논리 묶음을 실행합니다.
-
시스템이 실행되는 동안 외부 HSF 서비스에 의존하여 호출하고 반환 값을 가져옵니다.
-
시스템 실행 시 DB 쿼리나 랜딩 데이터에 의존하고, 캐시 쿼리나 랜딩 데이터에 의존한다.
-
시스템 실행 중에 메시지가 외부로 전송됩니다.
-
HSF 실행 결과를 상위 시스템으로 반환합니다.
효과적인 인터페이스 테스트의 핵심 원칙은 모든 항목을 다루고 모든 종속성을 모의하고 실행 프로세스 중에 남은 흔적을 확인하는 것입니다.요약은 다음과 같습니다.
-
항목 적용 범위: 인터페이스 테스트 사례는 HSF 서비스 항목, 메시지 항목 및 예약된 작업 항목을 포함해야 합니다.
-
모의에 의존: 기본 원칙 중에는 반복성의 원칙이 있습니다. 즉, 인터페이스 테스트는 환경에 종속될 수 없으며 외부 종속성은 모의가 필요합니다. 그러나 db 종속성의 경우 완전히 모킹하는 것은 권장하지 않으며, 한편으로는 모킹 비용이 높고 다른 한편으로는 SQL 및 테이블 제약 논리가 다루어지지 않을 수 있습니다.
-
완전한 검증: 효과적인 인터페이스 테스트에는 완전한 검증이 있어야 하며 검증 없는 인터페이스 테스트는 의미가 없습니다. 실행 중 남겨진 흔적이 비즈니스에 영향을 미치는 한 인터페이스 테스트의 유효성을 보장하기 위해 완전한 검증이 수행되어야 합니다.
-
HSF 인터페이스 반환 값 검증: 시나리오 및 인터페이스 합의에 따라 HSF 반환 매개변수 검증을 수행합니다.
-
DB 검증: 착륙 데이터의 정확성을 검증합니다.
-
캐시 확인: 캐시에 저장된 데이터의 정확성을 확인합니다.
-
HSF 종속 입력 매개변수 검증: 모의 도구를 통해 HSF 호출에 종속된 입력 매개변수를 획득하고 입력 매개변수 검증을 수행합니다.
-
메시지 검증: 모의 도구를 통해 보낸 메시지 객체를 획득하고 메시지 본문 검증을 수행합니다.
세 가지 테스트 코드 구조
테스트 코드를 작성할 때 비즈니스 코드를 작성할 때와 마찬가지로 코드의 가독성, 확장성 및 재사용 가능성도 고려해야 합니다. 동시에 시스템의 비즈니스 특성에 따라 현재 시스템에 적합한 테스트 컴포넌트를 테스트 프레임워크 기반으로 패키징하여 테스트 코드 작성의 효율성을 높이고 테스트 코드 구조를 표준화할 수 있다.
인터페이스에 대한 테스트 코드의 대략적인 구조는 다음과 같습니다.
1 시험 준비
데이터 준비에 따라 다름
대부분의 테스트에는 구성 데이터 또는 비즈니스 데이터(예: 환불은 결제 데이터에 의존해야 함)일 수 있는 데이터 종속성이 있습니다.
-
구성 데이터: 구성 파일을 정의하여 구성을 초기화할 수 있습니다.
-
비즈니스 데이터: 이 유형의 데이터는 데이터를 직접 삽입하여 생성해서는 안 되며 비즈니스 서비스를 호출하여 생성해야 합니다.
모의에 의존하다
외부 종속성의 경우 실제 호출을 피하기 위해 종속 서비스를 모의 처리해야 합니다.
인터페이스 테스트 항목 준비
인터페이스에 대한 입력 매개변수를 준비하십시오.
2 테스트 실행
인터페이스 메서드를 호출하여 비즈니스 로직을 실행합니다.
3 테스트 검증
-
반환 매개변수 확인: 인터페이스의 반환 매개변수를 확인합니다.
-
DB : DB의 랜딩 데이터를 확인합니다.
-
캐시 데이터 확인: 캐시에 저장된 데이터를 확인합니다.
-
메시지 확인: 외부로 전송된 메시지 개체를 확인합니다.
-
외부 HSF 호출 확인: 외부 HSF 호출의 입력 매개변수를 확인합니다.
네 가지 실용적인 팁
1 실행 효율성
인터페이스 테스트는 실행 효율성이 관건인데 인터페이스 테스트를 3분 이상 실행해 결과를 보면 개발자의 인터페이스 테스트 작성 의욕이 크게 떨어진다. 테스트 실행 효율성 향상을 위해 제안하는 솔루션은 다음과 같습니다.
-
스프링 부트 적용과 같은 시작 테스트 컨텍스트를 최소화하고 스프링을 시작하십시오.
-
h2와 같은 메모리 내 데이터베이스 사용
-
미들웨어 종속성 모의
2 테스트 프레임워크 선택
테스트 프레임워크의 경우 구성 파일을 통해 데이터 준비를 제공할 수 있는 testng 기반의 테스트 프레임워크를 선택하는 것이 좋습니다. 적합한 것을 찾을 수 없는 경우 testng를 기반으로 직접 패키징할 수 있습니다.
3 인터페이스 테스트 범위
시나리오의 무결성은 테스트 케이스의 적용 범위에 영향을 미치며, 한편으로는 개발자가 비즈니스 시나리오의 입력 및 테스트 경험을 기반으로 정상 및 비정상 상황을 열거해야 합니다. 멱등성 테스트, 경계값 테스트, 매개변수 부정확 테스트 등과 같은 테스트가 필요한 포인트
동시에 커버리지 도구를 사용하여 인터페이스에서 다루지 않는 코드 또는 분기 로직을 보고 대상 시나리오 커버리지 테스트를 수행합니다. 내 경험상 전체 분기 범위, 특히 특이한 분기가 매우 중요합니다.
다섯 가지 요약
시스템의 안정적인 온라인 운영을 위해서는 품질 보증 조치가 필수적입니다. 많은 자동화된 보증 수단이 있지만 인터페이스 테스트는 여전히 가장 기본적이고 중요한 보증 수단 중 하나입니다. 인터페이스 테스트의 적용 범위와 효율성을 지속적으로 보장할 수 있다면 온라인 버그 발생이 크게 줄어들고 개발자가 코드를 리팩토링할 동기가 더 커질 것입니다.
마지막으로 제 글을 읽어주신 모든 분들께 감사드립니다 호혜는 항상 필요합니다 아주 귀한 것은 아니지만 필요하시면 가져가셔도 됩니다:
이 재료는 [소프트웨어 테스팅] 친구를 위한 가장 포괄적이고 완전한 준비 창고가 될 것입니다.이 창고는 또한 수만 명의 테스트 엔지니어와 함께 가장 어려운 여정을 통과했으며 도움이 되기를 바랍니다! 파트너는 아래 작은 카드를 클릭할 수 있습니다. 받다