이 기사는 다음에서 복제되었습니다.
https://www.cnblogs.com/simple1025/p/11149838.html
질문 : 인터페이스 테스팅을 요약하는 아이디어는 작년 모집에서 나왔습니다. 모든 인터뷰는 인터페이스 테스팅에 대해 몇 가지 질문을 할 것입니다. "천명의 독자의 눈에 천 개의 햄릿이있다"라고 말할 수 있으며, 모든 테스터가 가지고 있습니다. 인터페이스 테스트에 대한 이해가 다르기 때문에 작년 해당 단계의 채용 프로세스로 인해 서버 인터페이스 테스트 및 사용 사례 분석의 주요 요점을 순차적으로 분류하고 보완 및 보관했으며이 문서를 가지고 있습니다. 환영합니다. 읽는 친구는 제안을합니다.
서버 측 인터페이스 테스트의 경우 일반적으로 요청 및 응답 매개 변수 확인, 비즈니스 로직 또는 비즈니스 규칙 확인, 데이터베이스 작업 확인과 같은 기능에서 테스트를 시작합니다. 기능이 정상화되면 필요에 따라 안전 관련 검사, 성능 테스트 및 일련의 확장 테스트 (예 : 이력 버전과의 호환성 테스트, 인터페이스 시간 초과 확인 및 디자인 합리성 확인)가 수행됩니다. 사용 사례 디자인도 이러한 측면에서 분석 및 설계됩니다. , 다음 마인드 맵은 요약 테스트 초점 방향입니다.
세부 사항은 다음과 같습니다.
입력 용
입력은 주로 인터페이스의 입력 매개 변수를 참조합니다. 일반적인 테스트에서는 먼저 정상 입력 매개 변수와 비정상 입력 매개 변수를 고려합니다. 비정상 조건에는 매개 변수 이상 및 데이터 이상이 포함됩니다. 사용 사례 디자인은 동일합니다. 클래스 구분 및 경계 값 분석
A. 일반 입장
정상적인 입력 매개 변수는 잘 이해됩니다. 즉, 인터페이스 디자인 문서의 입력 표준에 따라 정상 매개 변수를 입력하면 인터페이스 디자인 문서의 합의 된 조건에 따라 응답이 정상적으로 반환됩니다.
B. 비정상적인 매개 변수
매개 변수 예외는 다음과 같습니다. 매개 변수가 비어 있음, 더 많거나 적은 매개 변수, 잘못된 매개 변수
C. 비정상적인 데이터
데이터 이상 : 데이터 유형 오류, 널이 아닌 매개 변수가 비어 있음, 길이가 설계에 맞지 않음, 사전 범위에없는 데이터, 잘못된 멤버, 특수 또는 민감한 문자, 상관 관계가있는 비정상 매개 변수 데이터 등
로직 처리 용
인터페이스 테스트 전에 R & D는 일반적으로 인터페이스 디자인 문서 또는 비즈니스 관련 디자인 도면 및 순서도를 제공합니다. 비즈니스 프로세스의 처리 로직을 위해 입력 매개 변수의 제한 조건, 이벤트의 작업 대상 및 비즈니스 상태에서 전환 할 수 있습니다.
A. 제한 조건 분석
수치 제한 : 사전, 레벨, 산업 관련 제한, 수량 제한, 점수 제한 등
상태 제한 : 유효 | 유효하지 않음, 온라인 | 오프라인, 검게 처리됨 | 흰색 등
관계 제한 : 존재 또는 존재하지 않음, 구속력 또는 구속력 해제 등
권한 제한 : 관리자, 일반 사용자 등
B. 객체 분석
객체 분석은 주로 합법적이고 불법적 인 객체에 대한 작업입니다. 예를 들어 은행 카드 사용자가 카드를 재충전하면 다음과 같이 존재할 수 있습니다. 사용자 A는 사용자 A가 아닌 다른 카드를 사용하여 재충전하고 사용자 A는 자신의 카드를 사용하여 재충전하고 카드가 만료되었습니다. ; 사용자 A는 자신의 카드를 사용하여 충전하고, 카드가 블랙리스트에 올랐거나 분실되었습니다.
C. 상태 전이 분석
예를 들어, 결제 서비스의 경우 첫 번째 결제가 성공하고 주문이 취소 된 후 주문이 환불됩니다. 결제가 실패하면 결제가 실패한 것입니다. 상태 간 전환이 정상입니까? 정상적인 업무 운영이 원활하게 수행되지 않으면 상태가 어떻게 표시됩니까? 제어 가능, 비정상 상태 유무, 빈 상태 업무 처리 방법 등
D. 타이밍 분석
일부 복잡한 활동에서 활동은 지정된 순서로 일련의 작업에 의해 수행됩니다. 이러한 작업은 작업 흐름을 형성합니다. 예상 결과를 기다리기 위해이 순서로 실행 된 다음 실행 중에 발생하는 다른 분기 작업이 수행됩니다. 프로그램은 무엇을 할 것인가
예를 들어, Zebra 주차 위험 통제 사업에서 차량이 역에 들어간 후 돌아 서고 고속 사업에 들어 가지 않으면 어떻게해야합니까?
출력용
예외를 고려할 때 일반적으로 정상적인 상황과 잘못된 상황을 생각하지만 모든 오류 코드를 포함하지는 않을 수 있습니다. 인터페이스 정의에서 반환 된 오류 코드는 네트워크 예외, 잘못된 규칙 및 잘못된 사용 사례와 같은 사용 사례의이 부분을 보완하는 데 도움이 될 수 있습니다. 매개 변수, 잘못된 비즈니스 ID, 잘못된 작업, 서버 예외 등은 더 많은 사용 사례를 설계하기 위해 오류 코드의 값을 추가합니다.
출력을 기반으로 한 이러한 종류의 디자인 사용 사례는 프런트 엔드와 백 엔드가 정상적으로 결과를 출력하는지, 프롬프트가 친숙한 지, 민감한 정보가 나타나는지 등을 확인할 수 있습니다.
데이터베이스 운영
A. 데이터베이스 작업이 빈번한 지, 데이터베이스 쓰기 중 CPU를 많이 차지하는지, 데이터베이스 쓰기 완료 후 프로세스 해제 여부
B. 업무용 데이터 저장 정상 여부, 중복 데이터 저장 여부, 왜곡 된 문자 유무, 로그 데이터 저장 정상 여부
C. 데이터 업데이트가 정상인지, 특히 시간 필드인지, 시간이 24 시간 형식인지 여부
D. 데이터 삭제 및 백업이 정상인지 여부
안전
민감한 정보의 암호화 여부 (예 : 은행 계좌 번호, 비밀번호, 이체 금액)
성능 관련
A. 어떤 상황에서 인터페이스가 동시성이고, 동시성 시나리오는 무엇이며, 어떤 상황에서 동시성이 문제를 일으키는가
B. 최대 동시성, 응답 시간, 처리량, 리소스 소비
인터페이스 시간 초과
인터페이스는 일반적으로 반환되므로 인터페이스가 반환되지 않으면 어떻게됩니까? 따라서 인터페이스 타임 아웃 이후의 처리도 고려해야 할 테스트의 일부입니다. 타임 아웃이 제대로 처리되지 않으면 프로세스가 차단되거나 타임 아웃 이후 인터페이스 반환이 수신되어 논리적 혼란을 초래할 수 있습니다.
과거 버전과의 호환성 분석
사용되지 않는 프로토콜 또는 인터페이스이며 코드는 주석 처리되지 않았습니다. 특정 상황에서 사용되지 않는 프로토콜 또는 이전 버전의 인터페이스가 트리거되어 사용자가 함수를 사용하거나 호출 한 후 예기치 않은 문제와 손실이 발생할 수 있습니다.
동일한 시스템에있는 서로 다른 서비스 간의 인터페이스가 서로 호출 할 때 새 인터페이스가 과거 인터페이스의 영향을 받는가, 특히 새 인터페이스와 이전 인터페이스가 모두 특정 기능을 처리하고 비즈니스 비 호환성 문제가 있는지 여부
이를 위해서는 테스터가 오랜 시간 동안 시스템을 테스트해야하므로 이러한 종류의 시나리오를 생각할 수 있습니다. 리팩토링 된시기와 버전, 해당 인터페이스가 폐기되었으며 해당 인터페이스가 추가되었으며 어떤 시나리오가 기록을 트리거하는지 명확하게 알 수 있습니다. 인터페이스의 특정 규칙
합리적인 인터페이스 디자인
인터페이스 필드가 중복되는지 여부, 인터페이스가 호출자가 예상하는 정보를 반환하는지 여부, 인터페이스 정의가 모든 호출자의 요구 사항을 충족하는지 여부, 인터페이스가 호출하기 편리한 지 여부, 인터페이스가 확장 가능한지 여부, 인터페이스 매개 변수가 사용하기 편리한 지 여부 및 인터페이스의 비즈니스 규칙이 올바른지 여부 , 인터페이스는 전체 서비스의 사용이 그 효과를 가질 것입니다
저자 : simplesally 출처 : https : //www.cnblogs.com/simple1025/ :이 기사는 저자 및 블로그 Park에 속합니다. 재 인쇄 및 추천을 환영합니다. 그러나이 섹션에서 선언 한 저자의 동의 없이는 반드시 유지되어야하며 분명히 기사 페이지에 있어야합니다. 위치는 원래 링크를 제공하며 그렇지 않으면 법적 책임을 추구 할 권리가 있습니다.