Wanna be a thinker

목차

1. 전제

2. 진화

    2.1. HTTP/0.9

    2.2. HTTP/1.0

    2.3. HTTP/1.1

    2.4. HTTP/2.0

    2.5. HTTP 보안 도입

    2.6. HTTP를 이용한 애플리케이션

1. 전제

HTTP는 확장성 있는 프로토콜이다.

2. 진화

2.1. HTTP/0.9  "원 라인 프로토콜" 1989 - 1991

    - 팀 버너스 리가 제네바의 CERN사에서 개발했다.

    - 인터넷 상의 하이퍼텍스트 시스템, TCP/IP 위에 4개의 빌딩 블록으로 구성

        (1) HTML : 하이퍼 텍스트 문서를 표현하는 텍스트 형식의 언어

        (2) HTTP

        (3) WorldWideWeb : 최초의 브라우저

        (4) HTTPD의 초기 버전 : 웹서버

    - 요청은 한 줄로 구성되고, 오직 GET 메소드만 존재했다.

    - 응답은 파일 내용 자체로 구성되었다.

    - 헤더가 없었다.

        (1) 오직 HTML 문서의 교환만 가능했다.

        (2) 문제 발생 시, 상태/오류 코드가 없었기 때문에 문제와 설명을 기재한 HTML 파일로 응답을 보냈었다.

2.2. HTTP/1.0  "확장성 만들기" 1991 - 1996

    - 헤더에 프로토콜 버전 정보가 추가되었다.

    - 응답에 상태코드를 전송했다.

        (1) 요청의 성공/실패를 확인할 수 있게 되었다.

        (2) 결과에 대한 동작을 추가할 수 있게 되었다.

    - HTTP 헤더가 추가되었다.

        (1) 요청/응답에 부가되어 메타데이터의 전송을 허용했다.

        (2) 프로토콜의 유연성, 확장성이 향상되었다.

        (3) Content-Type 헤더 덕분에 HTML 외의 리소스도 전송할 수 있게 되었다.

2.3. HTTP/1.1  "표준 프로토콜" 1997

    - 모호함을 명확히, 개선사항 도입

    - 커넥션을 재사용 할 수 있게 했다.

        : HTML 내에 포함된 리소스를 표시하기 위해 커넥션을 재활용하여 시간을 절약했다.

    - 파이프라이닝이 추가되었다.

        : 첫번째 요청에 대한 응답이 끝나기 전, 새 요청을 가능할 수 있게 하여 커뮤니케이션의 지연을 낮추었다.

    - 청크된 응답을 지원했다.

    - 추가적인 캐시 제어 메커니즘을 도입했다.

    - 컨텐츠 협상을 도입했다.

        : 서버, 클라이언트 간 교환하려는 가장 적합한 언어/인코딩, 타입 등 컨텐츠에 대한 동의를 가능케 했다.

    - Host 헤더가 추가되었다.

        : 동일 IP 주소에 다른 도메인을 호스트하는 기능인 서버 코로케이션을 가능하게 하여,

        개인은 서버 호스팅 업체로부터 서버를 대여하여 사용할 수 있게 되었다.

2.4. HTTP/2.0

    - 구글이 2010년에 실험한 프로토콜인 SPDY를 기반으로 한 HTTP이다.

    - 응답성 향상, 전송된 데이터의 중복 문제를 해결했다.

    - HTTP/1.1과의 차이

        (1) Text가 아닌 Binary 프로토콜이다.

        (2) 다중화 된 프로토콜로 병렬 요청이 동일한 연결을 통해 처리 가능하게 되었다.

        (3) 헤더를 압축하여 전송된 데이터의 중복, 오버헤드를 제거하였다.

        (4) 서버 푸시라는 메커니즘을 도입하여 서버가 클라이언트의 캐시에 데이터를 채울 수 있게 되었다.

2.5. HTTP 보안 도입

    - 회사 넷스케이프 커뮤니케이션에 의해 SSL이 개발되고, 이후 TLS로 진화했다.

    - TLS는 암호화된 전송 계층으로 서버와 클라이언트 간 메세지 인증을 암호화한다.

2.6. HTTP를 이용한 애플리케이션

    - 2000년 이후 HTTP를 이용한 새로운 패턴인 (REST) API가 도입되었다.

    - 기본적 HTTP/1.1 메소드로 특정 URI에 접근하는 것으로 작동하여

    서버나 브라우저의 갱신 없이 데이터의 조회나 갱신을 허용했다.

    - 2010년 이후 보편화되었다.

출처 : developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

목적

HTTP에 대한 전체상을 이해합니다.

목차

1. 정의

2. 특징

3. HTTP 기반 시스템의 구성 요소

    3.1. 클라이언트

    3.2. 서버

    3.3. 프록시

4. HTTP로 제어할 수 있는 것

    4.1. 캐시

    4.2. origin 제약완화

    4.3. 인증

    4.4. 프록시, 터널링

    4.5. 세션

5. HTTP 흐름

6. HTTP 메시지

    6.1. 요청의 구성 요소

    6.2. 응답의 구성 요소

1. 정의

HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

2. 특징

- 웹상에서의 메시지(요청, 응답)를 통한 데이터 교환의 기초이다.

- 전송 프로토콜인 TCP나 TLS(암호화된 TCP)를 통해 메시지를 전송한다.

- HTTP 프로토콜은 애플리케이션 계층에 속한다.

- 서버, 클라이언트 구조이다.

3. HTTP 기반 시스템의 구성요소

3.1. 클라이언트

- HTML 문서 요청 후, 추가적으로 다음 리소스들을 요청하여 혼합한다.

    - 실행할 스크립트인 HTML

    - 이미지, 비디오 등 하위 리소스

    - 레이아웃 정보를 담은 CSS

3.2. 서버

- 클라이언트의 요청에 대한 문서를 제공한다.

- 논리적으로 단일 컴퓨터지만, 부분적으로 문서를 생성하는 서버들의 집합일 수 있다.

- 여러 개의 서버를 동일 머신 위에서 호스팅 할 수 있다.

- HTTP/1.1과 Host 헤더로 동일한 IP 주소를 공유할 수 있다.

3.3. 프록시

- 애플리케이션 계층에서 클라이언트와 서버 사이에 위치하는 컴퓨터로, 다음 기능을 수행한다.

    - 캐싱

    - 필터링

    - 로드 밸런싱

    - 인증

    - 로깅

4. HTTP로 제어할 수 있는 것

4.1. 캐시

    - 서버 : 캐시의 대상, 기간을 프록시와 클라이언트에게 지시할 수 있다.

    - 클라이언트 : 저장된 문서를 무시하도록 중간 캐시 프록시에게 지시할 수 있다.

4.2. origin 제약완화

    - 보안을 위한 origin 제약을 HTTP 헤더로 완화할 수 있다.

4.3. 인증

    - HTTP의 WWW-Authenticat 또는 유사 헤더, 쿠키를 사용한 특정 세션 설정

    - 특정 사용자만이 접근할 수 있도록 할 수 있다.

4.4. 프록시, 터널링

    - 실제 주소를 숨길 수 있다.

4.5. 세션

5. HTTP 흐름

서버와 클라이언트 간 통신의 흐름

1) TCP 연결

2) HTTP 메시지 전송

3) 서버에 의해 전송된 응답을 읽어들임

4) 연결을 닫거나 다른 요청들을 위해 재사용

6. HTTP 메시지

6.1. 요청의 구성 요소

    1) HTTP 메소드

    2) 요청할 리소스의 경로

    3) HTTP 프로토콜 버전

    4) 요청 헤더

    5) (전송할 리소스)

6.2. 응답의 구성 요소

    1) HTTP 프로토콜 버전

    2) 상태 코드

    3) 상태 메시지

    4) 응답 헤더

    5) (전송받은 리소스)

출처 : developer.mozilla.org/ko/docs/Web/HTTP/Overview

테스트를 자동화한다고 했을 때, 자동과 수동의 경계는 어떻게 될까?

한 칼럼에서 읽은 내용을 정리했다.

"테스트 자동화"라고 하면 일반적 인식으로는 PT의 기능 요건에 한정된다.

테스트는 공정에 따라, 종류에 따라 분류할 수 있다.

(1) 공정

- 개발자 담당 : PT(Program Test), IT(Integration Test), ST(System Test)

- 고객 담당 : 수입 테스트, OT(Operation Test), BT(Beta Test)

(2) 종류

- 기능 요건 : 기능 테스트

- 비기능 요건: 성능 테스트, 조작성 테스트, 보안 테스트

테스트 자동화 시, 필요한 상황 인식

1) 현 시스템은 어떤 단계의 테스트까지 진행할 필요가 있는가?

2) 그 중 어떤 테스트를 자동화 할 것인가?

3) 자동화 할 수 없는 부분은 어느 타이밍에 확인할 것인가?

테스트 툴 추천

1) Selenium Web Driver

- 화면 조작계 시험의 자동화 툴

- 간단한 스크립트를 작성하여 사용

- 화면 표시 내용과 기대치를 비교한 검증이 가능

2) Apache JMeter

- 부하 시험용 툴

3) OWASP ZAP

- 보안 테스트 툴

참고 : qiita.com/gevanni/items/ff9a27936a1a6df28b9a

1. 목적

결합시험 사양서를 어떻게 작성해야 하는지 이해하자.

2. WHAT

결합시험 사양서 작성법에 대해 이해한다.

3. WHY

올바른 관점으로 결합시험을 수행하기 위해서이다.

4. HOW

  4.1. 결합시험이란?

  - 복수의 모듈을 조합 시, 정상 동작 하는지를 확인한다.

  - 확인 관점

    1) 모듈간 인터페이스를 확인

    2) 모듈 전체 조합 후 동작을 확인

  4.2. 결합시험의 종류

    4.2.1. 인터페이스 테스트

    인터페이스 규격, 연계 종류, 연계 방법 등 요건에 맞게 테스트 한다.

    - 모듈 간 연계를 위해 규격화된 정보를 확인한다.  ex) 매개변수 갯수, 타입 / 형식 / 문자코드, 개행코드

    - 연계 방법에는 파일 연계, API 연계가 있으므로 요건에 맞게 테스트한다.

    - 요건에 따라 시스템 내부, 시스템 간, 외부 시스템과의 연계를 테스트한다.

    4.2.2. 업무 시나리오 테스트

    4.2.3. 예외처리 테스트

    4.2.4. 부하 테스트

    - 대량의 Access나 DB내 대량의 데이터에 대한 CRUD를 대상으로 한다.

    - 관점은 다음 두 가지가 있다.

      1) 처리가 제 시간 내에 이루어 지는가?

      2) 시스템을 계속 가동할 수 있는가?

    4.2.5. 보안 테스트

  4.3. 결합시험 시나리오를 작성하는 Point

    4.3.1. 업무 종류, 업무 흐름을 의식한다.

    - 업무를 고려하면 기능간 연계를 확인하기 쉽다.

    - 단점으로는 정상계 기능만 의식하기 쉽다.

    4.3.2. 업무상, 시스템상의 이레귤러를 고려한다.

    - 이레귤러의 고려는 시스템의 품질을 좌우한다.

    - 업무상의 이레귤러를 고려한다.

    ex) 계좌 잔액이 부족하기 때문에 결제 승인을 거부한다.

    - 시스템상의 이레귤러를 고려한다.

    ex) Access량이 많아서 서버가 다운되었을 때의 예외처리

  4.4. 요약

    1) 시험관점 설정

    2) 업무 흐름, 이레귤러를 의식한 시험항목 작성

참고 : kabblog.net/417/

개요

단체 시험이 끝난 복수의 모듈을 결합하여 동작시킨다.

목표

모듈 간 인터페이스에 관한 버그를 검출하는 것이다.

목적

사양대로 동작함을 증명하여 성과물의 품질을 보증한다.

장단점

단체 시험의 약점인 결합부의 확인이 가능하지만,

버그의 원인 특정이 어렵다는 단점이 있다.

관점

1. 기능 요건

  1.1. 정상 패턴 확인

  1.2. 이레귤러 패턴 확인

2. 비기능 요건

  2.1. 성능 확인

  2.2. 조작성 확인

  2.3. 보안 확인

대표적 수법

1. TopDown

가짜 하위 모듈인 '스터브(Stub)'를 이용하여, 상위 모듈의 인터페이스를 확인한다.

2. BottomUp

가짜 상위 모듈인 '드라이버(Driver)'를 이용하여, 하위 모듈의 인터페이스를 확인한다.