STUDYLOG

JSTL

• 자바서버 페이지 표준 태그 라이브러리(JavaServer Pages Standard Tag Library)
• html 코드 내에 java코드인 스크립틀릿을 대체하여 사용
• xml 데이터 처리와 조건문, 반복문, 국제화와 지역화와 같은 일을 처리하기 위한 JSP 태그 라이브러리를 추가하여 JSP사양을 확장
• JSP 페이지 내에서 자바코드를 바로 사용하지않고 로직을 내장하는 효율적인 방법 제공

JSTL의 태그

• <c:set>

  <c:set var ="변수이름" value="값" scope="영역">값</c:set>

  • 변수명에 값을 할당. <%=  %>
  • 변수가 저장되는 영역 설정(page / request / session / application -> 생략가능. 생략 시 기본값 : page)
• <c:out>
  • 값을 출력
• <c:if> : if문
• <c:choose> : switch
• <c:when> : choose의 하위태그. switch에서 case. 조건이 true인 경우
• <c:otherwise> : choose의 하위태그. switch에서 default. 조건이 false인 경우
• <c:forEach> : for문
  

  <c:foreach items="${리스트가 받아올 배열이름}" var="for문 내부에서 사용할 변수" varStatus="상태용 변수">
   
     // 반복해서 표시할 내용 혹은 반복할 구문
   
  </c:foreach>

EL

• 표현언어(Expression Language)
• $와 {}를 사용하여 값을 표현. 값으로 표현되는 것만 와야함.
• ${name}

MAC 주소

• 컴퓨터간 데이터를 전송하기 위해 있는 컴퓨터의 물리적 주소
• IP 주소간의 통신은 각 라우터 hop에서 일어나는 MAC주소 끼리 통신하는 연속적인 과정 
• 컴퓨터는 자신의 IP와 MAC주소는 알지만 통신하고자 하는 상대방의 MAC주소는 모른다. 
• ARP : 네트워크 단에서 IP주소로 MAC주소를 알아오게 하는 기능을 가진 프로토콜
• 데이터링크계층

MAC 주소 확인하는 법

• cmd -> ipconfig/all -> 물리적주소 확인
• cmd -> getmac -v -> 물리적주소 확인

1. 단위테스트(Unit Test)

• 테스트가 가능한 최소 단위로 나누어진 소프트웨어(모듈, 프로그램, 객체,클래스 등) 내에서 결함을 찾고 그 기능을 검증하는 것
• 구현 단계에서 각 모듈이 구현된 후에 단위 테스트를 수행
• 모듈을 단독적으로 실행할 수 있는 환경이 필요
  • 테스트 드라이버(Test driver)
  • 테스트 스텁(Test stub)

1) 테스트 드라이버

• 테스트 대상이 되는 모듈을 호출하여 준비한 테스트 데이터를 제공하고 모듈의 실행결과를 받는 모듈
• 이란적으로 상향식 테스트에서 아직 통합되지 않은 상위 컴포넌트의 동작을 시뮬레이션 하기 위해 사용
  1. 테스트 케이스가 저장되어 있는 파일이나 데이터베이스로부터 하나의 테스트케이스를 읽는다.
  2. 읽은 테스트 케이스를 입력 인자로 사용하여 테스트 대상이 되는 모듈을 호출
  3. 모듈의 실행 결과를 저장하고 다음 테스트 케이스를 읽는다. 경우에 따라서는 테스트 드라이버가 테스트 오라클 역할을 수행할 수 있다.
     즉, 실행 결과가 원하는 결과인지를 판별하여 프로그램에 오류가 검출되었는지를 판별하는 기능을 수행할 수있다.
  4. 2-3 과정을 더 이상 실행할 테스트 케이스가 없을 때까지 반복하여 수행

2) 테스트 스텁

• 호출되는 모듈의 개발이 완료되지 않은 경우, 호출하는 모듈을 시험하기 위해 생성한 더미 모듈
• 함수와 헤더 등의 코드 루틴만 정의하고 내부 코드는 제한적으로 구현하거나 구현하지 않는 경우가 많음
• 테스트 스텁을 이용하여 실제 모듈 사용 시에 발생하기 어려운 경우를 강제적으로 만들어 테스트할 수 있음

2. 통합 테스트(Integration Test)

• 모듈을 통합하는 과정에서 수행되는 테스트
• 모듈 간의 상호 작용이 올바르게 되는 지를 검사하는 테스트
• 통합테스트에서 오류가 발생되는 경우
  • 개별적인 모듈에 대한 테스트가 불충분하여 오류가 발생
    • 제한된 상황만을 고려하여 작성한 테스트 드라이버/스텁으로 인해 실제 모듈과 통합하는 과정에서 오류가 발생
  • 개별 모듈에서 동일한 전역 변수를 사용하는 등으로 인해 모듈 간의 예기치 못한 상호 작용이 발생하여 오류 발생

1) 통합 전략

• 빅뱅통합
  • 개별적인 모듈에 대해 단위테스트를 수행한 후에 전체 시스템에 대해 한번에 통합테스트를 수행
  • 단시간에 테스트가 가능하나 오류가 발생했을 경우 오류가 발생한 모듈 및 원인을 찾기가 매우 어려움
• 점진적 테스트
  • 한번에 모듈들을 통합하지 않고 점진적으로 모듈들을 통합하면서 테스트
  • 하향식 통합, 상향식 통합, 샌드위치 통합방식이 있음

2-1) 하향식 통합

• 시스템을 구성하는 모듈들의 계층 구조에서 가장 상위에 있는 모듈부터 시작하여 하위에 있는 모듈들을 점진적으로 통합하는 방식
• 상위 모듈을 테스트할 때, 하위 모듈을 대치할 테스트 스텁이 필요
  1. 가장 상위 모듈을 테스트 하기 위해 하위 모듈을 테스트 스텁으로 대치한 후 테스트 수행
  2. 깊이 우선방식이나 너비 우선 방식을 사용하여 테스트 스텁을 한번에 하나씩 실제 모듈로 대치.
     추가된 모듈이 호출하는 하위모듈을 테스트 스텁으로 대치한 후 회귀 테스트 수행
  3. 깊이 우선, 너비 우선

2-2) 하향식 통합 장/단점

• 장점
  • 설계상의 오류를 빨리 발견할 수 있음
• 단점
  • 많은 수의 테스트 스텁이 필요하고 만약 테스트 스텁을 구현할 때 비용이 많이 소요되는 경우에는 효과적이지 않음
  • 블랙박스 테스트만을 사용하는 경우에는 하위 모듈이 충분하게 테스트가 이루어지지 않을 수 있다.

3-1) 상향식 통합

• 하위 모듈을 먼저 통합하고 상위에 있는 모듈들을 통합하는 방식으로 테스트 드라이버 필요
• 클러스터 또는 빌드 : 특별한 기능을 제공하는 하위의 모듈들의 모임
  1. 하위 모듈을 클러스터링한 후에 테스트 드라이버를 작성하여 테스트 수행
  2. 클러스터를 테스트한 후에 테스트 드라이버를 제거하고 결합
  3. 위 과정을 시스템이 완전히 통합 될 때까지 반복하여 수행

3-2) 상향식 통합 장/단점 

• 장점
  • 하위에 있는 모듈들을 충분하게 테스트할 수 있음
  • 테스트 스텁을 제공하는 비용이 들지 않음
• 단점
  • 설계 오류를 조기에 발견하지 못함

4) 샌드위치 통합

• 상향식 통합 방식과 하향식 통합방식을 절충하여 통합

SW품질

1. 품질(Quality)

• 우수한 정도, 목적에 대한 적합성
• 어떤 실체가 지니고 있는 명시적 요구 및 묵시적 요구를 만족시키는 능력에 관계되는 특성의 총체

2. SW품질(Quality)

• 소프트웨어 제품이 명시된 조건하에서 사용될 때 명시적/암묵적 필요를 만족시키는 능력
• 품질 = 제품에 대한 품질 + 프로세스에 대한 품질

SW테스트

• 테스트는 프로그램이나 시스템이 자신이 해야 되는 일을 수행하는 확신을 주는 과정
• 컴퓨터 소프트웨어를 실행하여 그 결과가 올바른지를 판단하는 과정
• 결함을 발견할 목적으로 프로그램을 실행하는 과정
• 테스트는 소프트웨어 품질을 측정하고 개선하기 위한 테스트웨어를 공학화하여 사용하고 유지하기 위한 또 다른 라이프사이클 프로세스

결함(defect)

• 소프트웨어가 제품 사양에 명시된 대로 작동하지 않는 경우
• 소프트웨어가 제품 사양에서 하지말아야한다고 하는 기능을 수행하는 경우
• 소프트웨어가 제품 사양에서 언급하지 않은 것을 수행하는 경우
• 소프트웨어가 제품사양에서 언급하지 않았지만 해야 할 일을 수행하지 않는 경우
• 소프트웨어가 이해하기 어렵거나, 사용하기 어렵거나, 느리거나, 테스터의 눈에 일반 사용자가 옳지 않게 사용할 것으로 보이는 경우

Error, Fault, Failure

1. (hunman) Error(오류), Mistake -> 개발자의 실수

• 사용자 요구사항을 잘못 파악하거나 이해하여 발생하는 실수
• 타이핑 실수(typo)
• 프로그램 명령어를 잘못 이해하여 코딩

2. Fault(결함), Defect

• 에러가 표현된 것
• 에러로 인한 프로그램 내 잘못된 스텝, 로직 등

3. Failure(오작동)

• 결함의 실행으로 예상과 다른 결과
• 오작동은 결함에 의해 발생하지만, 결함이 있다고 해서 반드시 오작동이 발생하는 것은 아님(내재적결함)

SW테스트 고려사항

• 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹에 의해서 수행되어야 한다.
• 오류가 발견되지 않을 거이란 가정하에서 테스트 계획을 쉷해서는 안된다. 최대한 버그를 많이 잡는다.
• 타당한 경우 뿐만 아니라 타당하지 않고 예상하지 못한 경우들에 대해서도 테스트를 수행하라.
• 프로그램의 어떤 부분에 오류가 남아있을 확률은 이미 발견된 오류의 수에 직접적으로 비례한다.

master

• 배포가능한 상태 관리

hotfix

• master브랜치로부터 생성
• 출시한 버전에 버그가 발생하여 수정해야할 경우 사용
• develop 브랜치에서 수정하기에는 시간과 안정성 문제 때문에 바로 배포가 가능한 master 브랜치에서 직접 브랜치를 생성하여 수정한 후 master브랜치에 병합

develop

• 기능 개발을 위해 사용

release

• develop 브랜치에서 배포할 준비가 되면 release 브랜치 생성
• release 브랜치에서 배포가능한 상태가 되면 master 브랜치에 병합하고, delvelop 브랜치에도 병합
• 명명 규칙 : release-x.x  ex) release-1.7

feature

• 새로운 기능 개발 및 버그 수정 필요할 때마다 develop 브랜치에서 생성
• 완료 후 develop 브랜치에 병합
• 병합 후 더 이상 필요하지 않은 feautre 브랜치는 삭제
• 명명 규칙 : feature/xxx  ex) feature/login

HTTP(Hypertext Transfer Protocol)
- 하이퍼텍스트 전송규약
- 클라이언트와 서버간 데이터를 전송하는 프로토콜
- HTTP 통신할 때 보내는 데이터는 HTTP 패킷이라한다.
- 패킷의 구조 = 헤더+ 바디
- 헤더 : 클라이언트 정보, 브라우저 정보, 접속할 url 등 클라이언트 정보 담는다.
- 바디 : 특정 데이터를 담아 서버에게 요청을 보낸다. 메소드 방식에 따라 사용 방법 달라진다.

GET방식

• 클라이언트의 데이터의 파라미터를 url 뒤에 붙여 보낸다.
• ex) www.abcd.com/topic?id=1234&name=val   key : id , name / value : 1234, val
• 요청을 전송할 때 필요한 데이터를 쿼리스트링을 통해 전송
• ?를 사용하여 파라미터 작성. &를 사용하여 여러개의 파라미터 구분
• url에 파라미터를 전송하기 때문에 헤더에 포함되며 바디영역 사용하지않는다.
• 보통 서버로부터 정보를 조회할 때 사용
• 보안에 취약. 캐시 가능
• 브라우저 히스토리에 남는다.
• url에 데이터를 보내기 때문에 대용량 데이터 전송하기 힘들다.
• url 포함 255자까지 가능
• idemptent : 여러번 적용하더라도 결과값이 바뀌지않는다.
• 서버에서 데이터를 가져와 보여주는 것. 서버 상태변화 없다. select에 가깝다.

POST방식

• 데이터 전송을 기반으로 한 요청 메소드
• url에 붙이지 않고, 바디 영역에 데이터를 보낸다.
• 데이터 전송양 제한 없으며 대용량 데이터 보내는데 적합.
• 서버의 상태나 데이터를 변경시킬 때 사용. create에 가깝다.
• 생성, 수정, 삭제에 사용가능
• 캐시불가능
• 브라우저 히스토리에 남지 않는다.
• non-idempotent : 결과값이 바뀌는 유형의 개발에 적합