테스트의 모든것

SoapUI의 스크립트 어설션은 어설션의 구현 및 관리를 매우 쉽게 해주는 가장 많이 사용되는 어설 션 기술 중 하나입니다. 테스트 개발자에게 프로그래밍 제어를 제공하여 테스트 흐름을 프로그래밍 방식으로 제어하고 유효성을 검사할 수 있습니다. 따라서 이러한 상황을 처리하기 위해 SoapUI는 Groovy 스크립트를 사용하여 유효성 검사를 구현하는 기능을 제공합니다. 스크립트를 사용하여 어설 션을 구현하면 테스트 개발자에게 다음과 같은 확장 기능이 제공됩니다. 능력 기술 사전 및 사후 작업 스크립팅은 TestCase 전후에 특정 작업을 수행 할 수있는 자유를 제공합니다. 동적 응답 처리 스크립팅은 동적으로 변경되는 API의 응답을 처리하고 유효성을 검사하는 기능을 제공합니다. 사용자 지정 어설 ​​션 스크..

Rest Architectural 스타일은 Restful 서비스의 일부를 핵심 개념 요소로 정의합니다. 예를 들어 서버에 Rest 요청을 하는 동안 서버가 반환하는 정보를 Resource 라고합니다. RESTful 웹 서비스의 핵심 개념 요소를 간략히 요소 예 자원(Resource) 클라이언트가 요청할 수있는 서버에 저장된 정보. 날씨 정보이거나 직원 세부 정보 일 수 있습니다. 리소스 식별자(Resource Identifier) 이제 리소스가 정의되었으므로 리소스를 고유하게 식별해야합니다. 이것은 실제로 완전한 URL입니다. 표현(Representation) 리소스는 실제 데이터입니다. 이제이 데이터는 XML, HTML 또는 간단한 텍스트로 표현 될 수 있습니다. 그것이 표현이라고 불리는 것입니다. 표..

REST는 Representation State Transfer를 의미합니다. REST는 Roy Fielding 이 제시 한 일련의 제약 조건입니다. 이러한 제약은 모든 이론적 논의에서 이해하기 어렵다는 것을 알 수 있습니다. REST 제약(Constrains) 1) 클라이언트 – 서버 아키텍처 스타일(Client – Server Architecture style) 이것은 REST 아키텍처 스타일의 첫 번째 제약 조건입니다. 이 제약에 따라 애플리케이션은 클라이언트 – 서버처럼 모델링 되어야 합니다. 이와 관련하여 애플리케이션에는 데이터와 별도의 UI가 있어야 합니다. 프런트 엔드 (UI)와 백 엔드 (데이터베이스)를 처리하는 별개의 구성 요소가 있어야 합니다. 클라이언트-서버 아키텍처에 대한 이전 장에..

HTTP 요청과 마찬가지로 HTTP 응답도 동일한 구조를 갖습니다. 상태 라인(Status Line) 0 개 이상의 헤더 요청의 선택적 본문 응답 상태 라인(Response Status Line) 상태 라인은 세 부분으로 구성 HTTP 프로토콜 버전 상태 코드(Status Code) 이유 구문(Reason Phrase) Weather Rest 웹 서비스 예제에서 페이지를 아래로 스크롤하여 응답 섹션을 볼 수 있습니다. 응답 섹션에서 첫 번째 줄은 상태 줄(Status Line)이라고 합니다. 아래 이미지와 같이 : 상태 표시 줄 에 다음 정보 가 있음을 분명히 알 수 있습니다. HTTP 프로토콜 버전 (HTTP / 1.1) 상태 코드 : 200 상태 메시지 : OK 응답 헤더(Response Header..

HTTP 요청(HTTP Request)이란 무엇입니까? HTTP 요청은 한 컴퓨터가 무언가를 전달하기 위해 다른 컴퓨터로 보내는 정보 패킷입니다. 핵심적으로 HTTP 요청은 클라이언트가 서버로 보내는 이진 데이터 패킷입니다. HTTP 요청은 다음과 같은 부분을 포함 요청(Request) 라인 요청에 0 개 이상의 요청 헤더 요청의 선택적(optional) 본문(body) HTTP 요청의 다른 부분을 이해하기 위해 데모 목적으로 만든 이 Test Weather REST 웹 서비스를 사용하겠습니다. 리소스 URL : http://restapi.demoqa.com/utilities/weatherfull/ 매개 변수 : city ​​/ cityName = city / 도시 이름은 URL 끝에 있는 매개 변수 쿼..

클라이언트 서버 아키텍처를 이해하기 위해 작은 예를 들어 보겠습니다. 오늘 우리 도시의 날씨 데이터를 가져와야 한다고 가정해 보겠습니다. 이렇게 하려면 우리 도시의 기상 조건을 아는 사람에게 물어봐야 합니다. 컴퓨터를 아직 사용할 수 없다고 가정하면 일반적으로 그날의 신문을 보거나 라디오를 들을 수 있습니다. 이 과정에는 두 명의 다른 참가자가 있습니다. 첫 번째는 날씨에 대한 정보를 원하는 당신입니다. 두 번째는 정보를 제공하는 라디오 또는 신문입니다. 이 두 참가자의 이름을 지정하면 특정 정보를 소비하고자 하는 소비자. 또한 클라이언트-서버 컨텍스트에서 클라이언트라고 합니다. 정보를 제공하는 제공자. 또한 클라이언트-서버 컨텍스트에서 서버라고 합니다. 컴퓨터 시대에 클라이언트와 서버는 먼 거리상 분리..

문제 설명 우리는 종종 회사 또는 팀에서 다른 서버를 만납니다. 이는 개발 서버, 프로덕션 서버 또는 테스트 서버 일 수 있습니다. 모든 서버에는 서로 다른 유형의 요청 API가 있습니다. 컬렉션에 많은 요청이 포함될 수 있다는 것을 알고 있으므로 URL이 변경되면 어떻게 됩니까? 예를 들어 서버 요청 URL을 변경합니다. 서버를 관리하는 팀이 요청 API를 변경하여 알려 주면 우리 앞에 많은 어려움이 있습니다. 요청을 성공적으로 실행하려면 이제 모든 요청을 변경해야합니다. 300 개의 요청에 대해 300 번 변경해야합니다. 이것은 순전히 시간과 자원 낭비입니다. 하지만 이런 일이 많이 발생하기 때문에 Postman에는 몇 초 안에이 문제를 처리 할 수있는 기능이 있으며 요청을 다시 사용하는 것이 좋습니..

Authorization(권한부여/인가)란 무엇입니까? 권한 부여의 의미는 서버의 보안 리소스 에 액세스 할 수 있는가? 라는 질문으로 볼 수 있습니다 . 대답이 '예'인 경우 기술적 인 측면 에서 리소스에 액세스 할 수있는 권한 이 있다고 말할 수 있습니다 . 대답이 아니요 이면 리소스에 액세스 할 수있는 권한 이 없다고 말할 수 있습니다 . 예를 들어 휴대 전화에 본인과 자매의 지문을 추가했다고 가정 해 보겠습니다. 귀하와 귀하의 자매는 동일한 휴대 전화를 열 수 있습니다. 즉, 귀하와 귀하의 자매 만이 휴대 전화를 열고 데이터를 볼 수있는 권한이 있습니다 . 마찬가지로 많은 API 가있을 수 있지만 회사 또는 프로젝트에서. 모든 사람이 모든 API에 액세스 할 필요는 없습니다. 권한이 있는 사람 만..

POST 요청이란 무엇입니까? POST는 HTTP와 유사한 GET request로서, 이것은 클라이언트가 주어진 엔드 포인트에 데이터를 게시하고 있음을 지정합니다. POST 요청은 요청 본문 내부의 추가 정보를 서버에 보내야 할 때 사용되는 방법입니다. POST 요청을 보낼 때 일반적으로 업데이트, 삭제 또는 추가 와 같은 서버에서 일부 수정을 하게 됩니다. POST 요청의 전형적인 예 중 하나는 로그인 페이지입니다. 처음으로 가입 할 때 Facebook과 같은 개인 정보를 서버에 보냅니다. 서버는 동일한 세부 정보로 새 계정을 만들고 해당 계정은 Facebook 서버에 영구적으로 추가 됩니다. 방금 서버에 새 리소스를 만들었습니다. POST 요청은 매우 널리 사용되며 양식 제출이나 민감한 정보를 서버로..

Parameters in Request(요청의 매개 변수)는 무엇입니까? 요청 매개 변수는 서버에 추가 데이터를 보내는 데 사용되는 URL의 일부입니다. 간단한 URL을 분석해 보겠습니다. https://www.bing.com/search?q=QA 이 URL에서 요청 매개 변수는 URL의 "q = QA"부분으로 표시됩니다. 요청 매개 변수는 물음표 (?)로 시작합니다. 요청 매개 변수는 "Key = Value" 데이터 형식을 따릅니다 . 이 예에서 "q" 는 키이고 "QA" 는 값입니다. 서버는 URL에서 요청 매개 변수를 읽고 요청 매개 변수에 따라 응답을 보냅니다. 이 예에서 Bing은 QA에 대한 검색 결과를 반환합니다. 당신의 QA을 DemoQA로 값 변경하는 경우 당신은 DemoQA에 대한 결과..