목표

• 구문 커버리지를 설명할 수 있다
• 결정 커버리지를 설명할 수 있다
• 구문 및 결정 커버리지의 가치를 설명할 수 있다

화이트박스 테스팅은 테스트 대상의 내부 구조를 기반으로 한다.

모든 테스트 레벨에 적용 가능하다.

단위(컴포넌트)테스트 레벨에서 가장 일반적으로 사용되는 것이 화이트박스 테스트 기법이다.

구문 테스팅과 결정 테스팅의 가치

구문 커버리지(from 구문 테스팅) : 코드의 실행 가능한 구문을 실행하여 커버리지 측정.

100% 구문 커버리지를 달성하기 위해서는, 코드에 존재하는 모든 실행 가능한 구문을 최소한 한 번씩은 테스트했다는 것을 보장한다.

다른 테스트에 의해 실행되지 않은 코드의 결함을 식별하는데 도움이 된다.

결정 커버리지(from 결정 테스팅) : 코드에 존재하는 결정문을 실행하고 결과에 따라 실행되는 코드를 테스트

100% 결정 커버리지를 달성하기 위해서는, 모든 결정 로직(if문)을 테스트했다는 것을 보장한다.

다른 테스트가 참/거짓 결과 모두를 테스트하지 않은 코드의 결함을 발견하는데 도움이 된다.

100% 결정 커버리지는 100% 구문 커버리지를 보장하지만, 반대의 경우는 성립하지 않는다. (구문 테스팅은 결정 테스팅보다 커버리지가 낮다. 결정 커버리지가 더 세다)

목표 

• 동등 분할을 적용해서 테스트 케이스를 도출할 수 있다
• 경계 값 분석을 적용해서 테스트 케이스를 도출할 수 있다
• 결정 테이블 테스팅을 적용해서 테스트 케이스를 도출할 수 있다
• 상태 전이 테스팅을 적용해서 테스트 케이스를 도출할 수 있다
• 유스케이스에서 테이트 케이스를 도출할 수 있다

1. 동등 분할 (명세를 봤더니, 분할할 수 있다) _ Equivalence Partitioning

• 모든 변수는 동일한 방식으로 처리된다는 가정으로 파티션에 데이터를 분할한다 
• 유효한 값과 비유효한 값 모두에 대해 동등 분할을 구성할 수 있다
• 유효값 : 컴포넌트나 시스템에 입력되는 값이다. 유효한 값을 포함하는 동등한 파티션을 '유효 동등 분할'이라고 한다.
• 비유효값 : 컴포넌트나 시스템이 거부하는 값이다. 유효하지 않은 값을 포함하는 동등한 파티션을 '비유효 동등 분할'이라고 한다. 

동등 분할 기법으로 100% 커버리지를 달성하기 위해서는,

식별한 모든 분할(비유효 분할 포함)의 각 분할에 최소 한 개의 값을 사용해 테스트 케이스를 작성한다.

동등 분할은 모든 테스트 레벨에 적용할 수 있다.

2. 경계값 분석 (명세를 봤더니, 단위 기반으로 경계가 나뉘어진다) _ Boundary Value Analysis

• 단위를 항상 먼저 보기!!!
• 숫자 또는 연속 데이터로 구성된 경우에만 적용할 수 있다
• 모든 테스트 레벨에 적용할 수 있다

똑같은 문제를 가지고, 동등 분할과 경계값 분석을 각각 적용시켜

100% 커버리지를 달성하기 위해서는 경계값 분석의 테스트 케이스가 더 많다. 즉 더 강한 기법이 된다. 

=> 경계값 커버리지가 100%가 되면, 동등 분할 커버리지가 100%가 된다.

테스트 셋(Test Set)의 커버리지가 높으려면, 입력값이 영역에 골고루 분포 되있어야 한다.

3. 결정 테이블 테스팅 (명세를 봤더니, binary Condition이다) _ Decision Table Testing

• 복잡한 비즈니스 규칙을 기록하기에 좋은 방법이다
• 테스터는 시스템의 조건(주로 입력)과 예상 동작(주로 출력)을 식별한다
• 장점은 모든 조건 조합을 식별하는 데 도움이 될 수 있다
• 요구사항의 누락된 부분을 찾는 데 도움이 되고, 모든 테스트 레벨에 적용할 수 있다

4. 상태 전이 테스팅 (명세를 봤더니, 상태 전이 다이어그램이 있다) _ State Transition Testing 

• 임베디드 S/W, 메뉴 기반 application(키오스크)에 주로 사용된다
• 비즈니스 시나리오를 모델링하거나 화면 탐색을 테스팅하는 데 적합하다
• 상태 다이어그램에는 상태, 전이, 이벤트, 액션이 있다
  • 상태 : 하나 또는 그 이상의 이벤트를 기다리는 시스템의 독립적인 모드
  • 전이 : 이벤트에 의해 현 상태에서 다른 상태로의 이동 또는 변경
  • 이벤트 : 상태의 전이를 유발하는 요인
  • 액션 : 상태 전이와 함께 시스템 또는 소프트웨어가 동작하는 행위나 출력
• 상태 전이 테스팅을 통해서 상태 coverage와 전이 coverage를 예측한다
• 상태 전이 다이어그램 : 일반적으로 유효한 전이만 보여주며, 비유효 전이는 표시하지 않는다
• 상태 전이 테이블 : 상태 간의 모든 유효 전이와 잠재적인 비유효 전이뿐만 아니라, 유효 전이와 관련된 이벤트, 결과 초지를 보여준다
• 테스트 프로시저 : 테스트 프로시저는 테스트의 실행 순서이다
  • 테스트는 상태의 일반적인 순서를 커버하거나, 모든 상태를 실행하거나, 모든 상태 전이를 실행하거나, 특정한 상태 전이 순서를 실행하거나 또는 불가능한 상태 전이를 테스트하도록 설계할 수 있다
  • 프로시저 하나로 모든 테스트가 가능하다. 그러나, 결과를 보고 동작 정의가 어렵기 때문에  몇 개를 하나의 프로시저로 묶을 지 고려해야 한다

5. 유스케이스 테스팅 (명세를 봤더니, 유스케이스 Diagram이 있다) _ UseCase Testing

• 유스케이스 : 소프트웨어 항목 간의 상호작용(인터페이스)을 설계하는 특정 방법이다. 소프트웨어 기능에 대한 요구사항을 통합한다. 유스케이스는 액터와 대상 간의 관계이다.
• 설계는 정의한 동작(기본, 예외 또는 대안, 오류 처리)을 실행도록 테스트를 설계한다
• 테스트케이스는 유스케이스에 정의된 기본 및 확장 시나리오의 커버리지를 보장하고, 오류 처리를 수행하기 위해 작성된다

목표 

• 블랙박스 테스트 기법, 화이트박스 테스트 기법, 경험 기반 테스트 기법의 특성과 공통점 및 차이점을 설명할 수 있다

테스트 기법의 목적은 테스트 컨디션, 테스트 케이스, 테스트 데이터 식별을 지원하는 것이다.

테스트 기법의 종류에는 블랙박스, 화이트박스, 경험 기반의 테스트 기법이 있다.

1. 블랙 박스 : 명세를 기반으로 테스트 케이스(TC)를 만든다.
   • 명세 기반 기법, 행위기법 또는 행위 기반 기법이라고 한다
   • 적절한 명세를 분석하는 걸 기반으로 한다
   • 기능 테스팅과 비기능 테스팅 모두에 적용이 가능하다
   • 테스트 대상의 내부 구조를 고려하지 않고, 입력과 출력에 집중한다
2. 화이트 박스 : 구조를 기반으로 테스트 케이스를 만든다. 
   • 구조 기법 또는 구조 기반 기법이라고 한다
   • 아키텍처, 내부 구조, 코드, 세부 설계를 분석하는 걸 기반으로 한다
   • 테스트 대상의 내부 구조와 처리에 집중한다
3. 경험 기반 : 지식/경험 기반으로 테스트 케이스를 만든다.
   • 개발자, 테스터, 사용자의 경험을 활용하여 테스트를 설계/구현/실행
   • 블랙박스와 화이트박스 기법을 결합하여 사용

목표

• 작업 산출물 리뷰 프로세스 활동을 요약할 수 있다(시험 위주로, 중요도 = 0.5)
• 공식 리뷰의 다양한 역할과 책임을 인식할 수 있다
• 서로 다른 리뷰 유형의 차이를 설명할 수 있다
• 작업 산출물에 리뷰 기법을 적용해 결함을 식별할 수 있다
• 리뷰 성공 요소를 설명할 수 있다(시험 위주로, 중요도 = 0.5)

시험 위주로 설명하자면, 리뷰 유형은 크게 [1.비공식 리뷰], [2.워크쓰루], [3.기술 리뷰], [4.인스펙션] 으로 분류한다.

2,3,4는 공식 리뷰이다. 그 중 공식적인 특징이 가장 강한 것은 인스펙션이다.

리뷰 프로세스에는

'계획 -> 리뷰 착수 -> 개별 리뷰 -> 이슈 논의 및 분석 -> 수정 및 보고' 단계로 이루어져 있다.

이런 리뷰 프로세스를 바탕으로 한다는 것은 가장 공식적인 Inspection이 된다.

리뷰 프로세스를 원활히 이해하고자, 한 가지의 상황을 가정한다.

테스터와 개발자와 영업직 사원이 각각 한 명씩 있다.

관리자는 이들에게

어떤 세부 가이드가 따로 없이, 리뷰 문서의 p.11~p.20를  7일의 기한동안, 업무시간 중 리뷰활동에 2시간을 할당하여 결함을 알아오라고 한다. (계획)

이들은 각자 잠재적 결함을 5개씩 발견해온다. (리뷰 착수, 개별 리뷰)

그리고 7일째가 되어서 각자의 이슈를 논의한다. 각자가 알아온 이슈 중에서 중복되는 결함도 있고, 실질적인 결함이 아닌 것도 있다. 이를 간추려서 최종적으로 각자 2개의 결함(2+2+2, 총 6개)을 발견한 것이 된다. (이슈 논의 및 분석)

수정이 필요한 결함에 대해 보고를 하고, 리뷰한 작업 산출물에서 발견한 결함을 저자가 수정한다.

보고를 하면서 총 6개의 결함을 6시간동안 발견한 것이므로, '조직의 퍼포먼스는 1시간 당 1개의 결함을 발견할 수 있다' 는 메트릭을 수집할 수 있게 된다. (수정 및 보고)

리뷰에서의 역할과 책임(위의 상황에 대입하여 역할들을 매칭해보는 것이 이해에 도움이 된다)

1. 저자 : 리뷰 대상 작업 산출물 작성, 결함이 발견되면 수정
2. 관리자 : 
   • 리뷰 계획 담당, 실행 결정, 인력/예산/시간 할당, 메트릭 수집, 결과가 만족스럽지 않다면 제어 결정
   • 관리자는 리뷰 회의(이슈 논의 및 분석)에 참석하지 않는다
3. 촉진다 : (가장 중요) 저자와 결함을 발견한 사람과의 충돌은 실무에서도 흔히 일어날 수 있다. 이를 중재하기 때문에 '중재자'라고도 한다.
   • 리뷰 회의 진행 시 효과적인 회의 진행을 보장한다
   • 필요한 경우 다양한 관점들에 대한 중재가 필요하다
   • 많은 경우 리뷰의 성공 여부에 결정적인 역할을 하는 사람
4. 리뷰 리더 : 전반적으로 리뷰에 대한 책임을 지는 사람. 참여자를 결정하고 언제 어디서 진행할지 결정한다.
5. 검토자 : 다양한 관점을 대표할 수 있기 때문에 일반적으로 여러 명이다. 
   • 해당 주제에 대한 전문가, 프로젝트 참여자, 작업 산출물에 관심 있는 사람 등이 참여 가능하다
   • 리뷰 대상 작업 산출물의 잠재적 결함을 식별한다
6. 서기, 기록자 :
   • 회의가 진행되는 동안, 새로운 잠재결함/ 쟁점/ 결정 사항 등을 기록한다
   • 개별 리뷰 활동에서 발견한 잠재 결함을 수집한다

크게 4가지 리뷰 유형으로 나눌 수 있고, 비공식 리뷰, 워크 쓰루, 기술 리뷰, 인스펙션에 대해 설명할 수 있어야 한다.

모든 리뷰의 주요 목적은 잠재적 결함 발견이 공통적이다.

1. 비공식 리뷰

• 새로운 아이디어나 해결책 도출, 소소한 문제의 빠른 해결을 목표로 한다.
• 비공식이므로, 위에서 언급한 프로세스를 기반으로 하지 않는다.
• 검토자에 따라 성과가 달라질 수 있다.
• 애자일에서 매우 일반적으로 사용된다.

2. 워크 쓰루

• 아이디어 교환, 참여자(관심 있는 사람 등) 교육, 합의 도출을 목표로 한다.
• 필요에 따라, 선택적으로 리뷰 회의 전 개별 준비를 한다. 
• 리뷰 회의는 일반적으로 작업 산출물의 저자가 주도한다. (원래는 촉진자가 주도하지만, 워크쓰루만 저자가 주도한다)
• 서기 참여 필수
• 시나리오, 드라이 런, 시뮬레이션의 형태로 수행할 수 있다. (제일 윗사람한테 보고하기 전의 예행 연습으로 간주할 수 있다)

3. 기술 리뷰(어려운 기술들에 대해서만 리뷰 활동)

• 합의 도출, 새로운 아이디어 도출을 목표로 한다. -> 이 점에서 워크쓰루와 헷갈릴 수 있지만, 워크쓰루는 누구나 참여할 수 있게 하여 참여자를 교육할 수 있다는 점과 차이가 드러난다. (=기술리뷰는 참여자 교육이 목표가 아님)
• 다른 리뷰들과 다르게 굉장히 기술적인 것을 리뷰함.
• '리뷰 대상이 기술적이냐, 기술적이지 않냐'에 따라서 기술리뷰와 인스펙션으로 구분할 수 있다.
• 검토자는 이미 기술 수준이 띄어난 전문가들만 참여가 가능하다.
• 리뷰 회의 전 개별 준비가 필요
• 이상적으로 훈련된 촉진자가 주도한다.(그러나 워크쓰루는 저자가 주도한다)

4. 인스펙션(가장 공식적, 일반적)

• 규칙 및 체크리스트를 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행
• 명확하게 정의된 역할 참여 (낭독자, 검토자, 서기(필수), 촉진자 주도)
• 리뷰 회의 전 개별 준비 필요 
• 명시된 시작 및 종료 조건을 사용
• 잠재적인 결함 로그 및 리뷰 보고서 작성
• 전체 SW 개발 프로세스를 개선하기 위해 메트릭(측정 지표)을 수집하고 사용

목표 

• 다양한 적정 테스팅 기법으로 확인할 수 있는 S/W 작업 산출물 유형을 인식할 수 있다
• 정적 테스팅의 가치를 설명할 수 있다
• 정적 기법과 동적 기법의 차이를 설명할 수 있다

정적 테스팅이란 시스템을 구동하지 않고 테스팅 하는 것을 말한다.

[1. 리뷰] 와 [2. 정적 분석 도구]로 분류할 수 있으며, '정적 분석 도구'는 수동으로 하기 어려운 경우 사용한다.

정적 테스팅의 목적은 테스팅의 일반적인 목적인 아래와 동일하다.

• 요구사항, 사용자 스토리, 설계, 소스코드와 같은 작업 산출물 평가
• 결함 발견과 예방 

리뷰의 중요성은 여러 도메인에서 일반화 되고 있다.

기존 옛날 방식으로 작업을 진행하는 것보다 2배수의 능력있는 인력을 초기에 도입하여 리뷰를 진행함으로써 개발 비용과 시간을 줄일 수 있다는 걸 시사한다. -> 정적 테스팅 효과

적절한 정적 분석 도구가 존재하는 공식 구조를 사용하는 작업 산출물에 효율적으로 적용이 가능하다.

- 코드 또는 모델

- 요구사항과 같은 자연어로 작성된 작업 산출물을 평가하는 도구로 적용 가능

** 리뷰 같은 경우 기본적으로 모든 테스트 베이시스에 적용이 가능하고, 정적 분석 도구는 코드와 모델에만 적용 가능하다

위의 내용을 바탕으로, 정적 테스팅의 효과는

1. 동적 테스팅보다 효율적이고,
2. 개발 생산성 향상,
3. 테스팅 비용 및 기간 단축
4. 수명 주기 전반에 걸친 총 품질 비용 감소
5. 팀원 간의 의사소통 개선 등이 있다.

※ 나올 확률이 높은, 정적 테스팅으로 발견하기 쉬운 결함

주로 결함이 아닌 것은? 이라는 문제로 출제된다.

1. 리뷰를 통한, 요구사항 결함

2. 리뷰 or 정적 분석 도구를 통한, 설계 결함(ex. 비효율적 알고리즘/ DB 구조/ 높은 결합도/ 낮은 응집도)

3. 정적 분석 도구를 통한, 

• 코딩 결함 ( 리뷰로도 가능하지만, 거의 정적 분석 도구로 사용)
• 표준과의 차이 (코딩 룰,language 컨벤션,에 맞춰 짜야 한다)
• 잘못된 인터페이스 명세
• 보안 취약점
• 테스트 베이시스 추적성, 불충분한 커버리지 또는 부정확성
• 유지보수성 결함(잘못된 모듈화, 낮은 재사용성, 분석하거나 수정하기 어려운 코드)

정적 테스팅과 동적 테스팅의 차이

- 두가지 테스팅 모두 품질을 평가하고, 가능한 빨리 결함을 식별하는 것이다.

- 각자 테스팅을 통해 발견하는 결함의 유형이 서로 다르기 때문에 상호 보완적이다.

• 정적 테스팅 : 직접 결함을 식별하고, 일관성/ 내부 품질 향상에 집중한다.
• 동적 테스팅 : 소프트웨어를 구동하여 식별하고, 외부에 보이는 동작에 집중한다.

'스프링부트와 AWS로 혼자 구현하는 웹서비스' 책을 보며 실습을 하면서 해결되지 않는 문제가 하나 있었다. 

분명 코드를 다시 검토해보기도 하고, 저자의 github을 아예 복붙하는 방법도 해봤다. 원래는 Logged in as: [내 이름]이 떠야 하는데, 내 이름이 아닌 User라고 떴다. 아래는 책과 똑같은 코드이다.

값은 잘 받아오는 것을 디버깅하여 확인하였기 때문에 mustache파일에 문제가 있다고 생각하였지만 전혀 다른 부분은 없었다. 그러다가 같은 문제를 겪은 분이 있는 걸 알았다. 

https://github.com/saechimdaeki/Spring_boot_AWS/issues/2 👍 

WindowOs환경에서는 userName으로 값을 주고받을 시 윈도우 사용자명이 출력되기 때문에 내 이름이 나오지 않았던 것이다!

user에서 내 이름이 뜬 걸 확인할 수 있다!

이 단원을 공부하기에 앞서 간략히 알아야 하는 명령에 대해서 정리를 하였다.

<파일 검색하는 데 사용되는 명령어>

locate :: 파일명으로 파일 위치 찾기

find :: 디렉토리 트리 내에서 파일 검색하기

<파일 검색 결과를 처리하는 데 사용되는 명령어>

xargs :: 표준 입력으로부터 인자 목록을 만들고 실행하기

touch :: 파일 시간을 변경하기, stat :: 파일이나 파일 시스템 상태 표시하기

> locate

• locate bin/zip → bin/zip 문자열이 포함된 결과를 보여줄 것이다.
• locate zip | grep bin → zip과 bin 문자열이 포함된 결과가 출력될 것이다.

*grep 명령어 : 특정 파일에서 지정한 문자열이나 정규표현식을 포함한 행을 출력해주는 명령어이다(내가 원하는 문자열이 있는 라인을 찾을 수 있다)

| 파이프를 사용하면, grep 명령어를 여러 개 사용할 수 있다.

> find

locate는 오로지 파일명에 근거하여 파일을 찾을 수 있지만, find는 다양한 속성에 근거하여 주어진 디렉토리를 검색하여 파일을 찾는다. find의 훌륭한 점은 특정조건에 부합하는 파일을 찾아낼 수 있다(조건을 상세하게 설정가능하다)

1. 파일 형식에 따른 조건 지정

• find ~ type d | wc -l → 디렉토리 검색으로 제한, 디렉토리 개수 출력
• find ~ type f | wc -l  → 파일 검색으로 제한, 파일 개수 출력

2. 파일 크기, 파일명 검색 조건 지정

• find ~ -type f -name "*.JPG" -size +1M | wc -l  → 와일드카드 패턴 *.JPG와 일치하며, 1MB보다 큰 파일 검색, 개수 출력

*       :: test를 말한다. find의 명령어의 test는 훨씬 더 많다. 더 많은 test는 find의 man페이지를 확인하면 볼 수 있다.

* +, -, (생략) ::

+ → 지정한 파일 크기보다 큰 파일로 검색한다.

- → 지정한 파일 크기보다 작은 파일로 검색한다.

(생략) → 지정한 파일 크기와 정확히 일치하는 파일로 검색한다.

>연산자

모든 테스트들조차도 테스트 간의 논리적인 관계를 설명하기 위한 더 나은 방법이 필요할 수도 있다.

1. -and :: 연산자를 기준으로 양쪽 테스트 조건이 모두 참인 경우에 검색된다. 아무런 연산자를 입력하지 않는다면 기본값으로 -and가 적용된다. 줄여서 -a로 적을 수도 있다.
2. -or :: 양쪽 테스트 중 하나라도 참인 경우에 검색된다. 줄여서 -o로 적을 수도 있다.
3. -not :: 연산자 다음에 나오는 테스트가 거짓인 경우에 검색된다. -!로 적을 수도 있다.
4. ( ) :: 테스트와 연산자를 하나로 조합하여 표현한 내용을 하나로 그룹화할 때 사용된다. 명령어의 가독성을 높이기 위해 사용하기도 한다. 보통 백슬래쉬와 괄호와 함께 사용한다.

예를 들어서, 디렉토리 내의 모든 파일과 하위 디렉토리가 안전한 권한을 가지고 있는지 확인해야 할 경우, 

→ 해당 파일들의 퍼미션인 0600으로 설정되어 있는지, 해당 디렉토리의 퍼미션이 0700으로 설정되어 있는지에 대해 확인할 필요가 있다.

→ 이를 논리연산자를 사용하여 판단할 수 있다.

• find ~ \( -type f -not -perm 0600 \) -or \( -type d -not -perm 0700 \)

잘못 설정된 파일과 디렉토리를 찾는 것인데, 왜 -and가 아닌 -or로 연결되어 있을까? find명령어가 파일과 디렉토리를 모두 탐색하면서 지정된 테스트에 대한 일치 여부를 하나하나 계산하기 때문이다.

expr1 -operator expr2_[연산자 로직]

• -operator가 -and일 경우 : expr1이 참이면, expr2가 실행한다 / expr1이 거짓이면, expr2가 실행하지 않는다.
• -operator가 -or일 경우 : expr1이 참이면, expr2는 실행하지 않는다/ expr1이 거짓이면, expr2는 실행한다.

왜 이런 로직으로 작동할까? 검색 성능을 개선하기 위해서이다.

> 액션

find명령의 결과 목록 출력은 유용하지만, 정말로 하고자 하는 것은 해당 목록에 있는 항목들을 동작하는 것이다.

액션에는 미리 정의된 액션과 사용자 지정의 액션이 있다.

미리 정의된 액션에는 -ls, -print, -delete, -quit 등이 있다.

• find ~ → 홈 디렉토리에 잇는 모든 파일 및 하위 디렉토리 목록을 보여준다. 사실 이는 -print 액션이 함축된 것이다. 별도의 액션 언급이 없으면 기본값으로 -print액션이 실행된다. (= find ~ -print)
• find ~ -type f -name '*.BAK' -delete → 사용자의 홈 디렉토리에 있는 모든 파일에 대하여 .BAK으로 끝나는 파일명을 검색하고, 해당 파일을 찾게 되면 모두 삭제된다.
• find ~ -type f -and -name '*.BAK' -and -delete → -and연산자는 언급되지 않으면 기본값으로 수행된다.
  1. -delete 는 find ~ type f와 -name '*.BAK'의 결과가 참인 경우에 수행된다.
  2. -name '*.BAK'은 find ~ -type f의 결과가 참인 경우에 수행된다.
  3. -type f는 항상 수행된다. -and관계에서 첫 번째 표현이기 때문이다.

사용자 지정의 액션은 임의의 명령어를 실행할 수도 있다. 대표적으로 -exec 액션을 활용한 명령이 있다.

-exec command { } ;

command자리에는 명령어의 이름이 들어가고, { }의 기호에는 현재 경로명에 대한 심볼릭 링크를 표시한다. 세미콜론은 명령어의 끝을 말해주는 구획 기호로 꼭 필요하다. 중괄호와 세미콜론은 Shell에서 특수한 의미로 사용되기 때문에 반드시 인용되거나 확장되어야 한다.

* 심볼릭 링크 :: 링크를 연결하여 원본 파일을 직접 사용하는 것과 같은 효과를 내는 링크이다. 심볼릭 링크를 따로 연결하는 방법은 타 블로그 주소를 첨부해놓겠다. 

https://qjadud22.tistory.com/22

• find ~ -type f -name 'foo*' -ok ls -l '{}' ';' → 사용자 정의 액션을 대화식으로 실행하는 것도 가능하다 -ok 액션을 -exec자리 대신에 넣으면 지정된 명령을 실행하기 전, 사용자에게 확인 메시지를 뜬다. 'y'를 입력하면 출력되고, 'n'를 입력하면 출력되지 않는다.

-exec 액션을 사용하면, 일치하는 파일이 발견될때마다 지정된 명령을 매번 실행한다. 이런 반복성을 효율적으로 수행하기 위한 대안법이 2가지가 있다. 하나는 xargs라는 외부 명령어를 사용하는 것이고, 다른 하나는 find가 가진 새로운 기능을 활용하는 것이다. 

위의 명령은 기존에 예제로 했던 명령이다. 이 예제는 일치하는 파일이 발견될 때마다 ls 명령을 실행한다.

여기서 ';' 대신에 + 기호를 사용한다. 그러면 원하는 명령이 한 번에 실행될 수 잇도록 검색 결과들을 인자 목록으로 묶어주는 find의 기능이 활성화된다. 결과는 동일하지만, 여기서는 ls 명령이 한 번 실행된 것이다.

xargs 명령어를 사용해도 똑같은 결과를 얻을 수 있게 된다. xargs 명령은 표준 입력으로부터 입력을 받아서 지정한 명령어를 위한 하나의 인자 목록으로 변환한다.

> touch명령어

보통 파일이 수정된 시간을 갱신하거나 설정할 때 사용하지만 파일명 인자가 존재하지 않는 파일이라면 새로운 빈 파일을 만든다.

Spring Security ::

막강한 인증(Authentication)과 인가(Authorization, 권한 부여) 기능을 가진 프레임워크이다. 보안을 위한 표준이라고 할 수 있다. 인증과 인가의 의미 차이가 없는 줄 알았는데 공부를 하면서 아주 큰 차이가 있다는 것을 알았다.

인증(Authentication) _ 해당 사용자가 본인이 맞는지를 확인하는 절차를 의미한다.

인가(Authorization) _ 인증된 사용자가 요청한 자원에 접근 가능한지를 결정하는 절차를 의미한다. '인증된 사용자' 단어에서 알 수 있듯이, [인증]에서 성공될 시에 [인가]로 넘어갈 수 있다.

"인증 → 인가" , 인증과 인가를 위해 principal을 아이디로, credential을 비밀번호로 사용하는 credential 기반의 인증방식을 사용한다.

principal :: 보호받는 resource에 접근하는 대상

credential :: resource에 접근하는 대상의 비밀번호

OAuth ::

OAuth는 사용자가 요청권한이 있는지를 확인하는 인가(Authorization) 프로토콜이다. 

위키백과의 사전적 정의에 따르면, 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 어플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는(접근 위임을 위한) 개방형 표준이다.

> OAuth에 관련된 용어 

• 사용자(user) _ 서비스 제공자와 소비자를 사용하는 계정을 가지고 있는 개인을 말한다.
• 소비자(consumer) _ Opne API를 이용하여 개발된 OAuth를 사용하여 서비스 제공자에게 접근하는 웹사이트 또는 어플리케이션을 의미한다.
• 서비스 제공자 (service provider) _ OAuth를 통해 접근을 지원하는 웹 어플리케이션(Open API를 제공하는 서비스이다. 대표적인 예시로 'Google', 'Naver', 'Kakao'..)
• 소비자 비밀번호(consumer secret) _ 서비스 제공자에게 소비자가 자신임을 인증하기 위한 키를 말한다.   
• 요청 토큰(request token) _ 소비자가 사용자에게 접근권한을 인증받기 위해 필요한 정보가 담겨있으며 후에 접근 토큰으로 변환된다.
• 접근 토큰(access token) _ 인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해서 보호된 자원에 접근하기 위한 키를 포함한 값이다.

> OAuth의 인증방식 = 인증 과정을 '타 서비스에게 위임'하는 인증 방식이다.

OAuth의 인증은 소비자와 서비스 제공자 사이에서 일어난다.

1. 소비자가 서비스제공자에게 요청토큰을 요청한다.
2. 서비스제공자가 소비자에게 요청토큰을 발급해준다.
3. 소비자가 사용자를 서비스제공자로 이동시킨다. 여기서 사용자 인증이 수행된다.
4. 서비스제공자가 사용자를 소비자로 이동시킨다.
5. 소비자가 서비스제공자에게 접근토큰을 요청한다.
6. 서비스제공자가 접근토큰을 발급한다.
7. 발급된 접근토큰을 이용하여 소비자에게 사용자 정보에 접근한다.

'위임한다'는 뜻 그대로 사용자가 서비스 제공자에 직접 로그인하는 것은 아니다. 웹 사이트(소비자)에 접속한 사용자의 정보는 여전히 내 웹 사이트에서 관리해야 한다. 

서비스 제공자(구글, 카카오..)가 해주는 일은 사용자가 '소셜 로그인' 기능을 통해 서비스 제공자에게 전송된 계정 정보가 유효한지(예를 들어, 구글 아이디 및 비밀번호가 일치하는지)를 확인한 후에 유효하다면 서비스 제공자가 가진 사용자의 정보 중 일부(유저 이름, 프로필 이미지 등)를 소비자(웹 서비스, 어플리케이션)에게 제공해주는 '인증' 과정만을 처리해주는 것이다.

>승인된 리디렉션 URI

'스프링 부트와 AWS로 혼자 구현하는 웹서비스' 책으로 실습을 하면서 이 부분에 대해서 제대로 이해를 하지 못하였다.

1. 서비스에서 파라미터로 인증 정보를 주었을 때 인증이 성공하면 구글에서 리다이렉트할 URL입니다.

2. 사용자가 별도로 리다이렉트 URL을 지원하는 Controller를 만들 필요가 없습니다. 시큐리티에서 이미 구현한 상태입니다.

이 두가지 부분에 대해서 이해를 하지 못했다. 공부를 하면서 추측하건대, 2번은 Controller에서 PostMapping 구현을 말하는 것이다.

실습을 하면서 궁금했던 부분이기에 서비스 제공자가 아닌 구글로 특정 지어 설명할 것이다.

구글 계정으로 로그인하는 서비스를 만들기 위해서 구글 클라우드 플랫폼에서 프로젝트(OAuth 클라이언트)를 생성하였다. 이 때, 구글에서 'clientID'와 '승인된 리디렉션 URI 지정'을 제공해준다. 

• client ID

서비스를 사용하면서 [구글 로그인]을 누르면, 구글 인증 페이지가 뜨는데, 이는https://accounts.google.com/o/oauth2/auth URL에서 제공한다. 이를 단순히 이 링크를 주소창에 치면

다음과 같은 에러 페이지가 뜨는 것을 확인할 수 있다. 이 에러가 난 이유는 우리가 구글 로그인 기능을 사용하기 위해서 Google 인증 서버 페이지에 접속한다는 것은 특정 웹사이트에서 구글 계정을 사용한 OAuth인증을 사용하고 싶다는 것을 의미한다. 그런데 주소창에 바로 인증 서버 페이지 주소를 입력하면 어떤 웹 사이트에서 OAuth인증을 요청하는지 알 수 없기 때문에 오류가 발생한 것이다. 

이 때, '어떤 웹 사이트에서 OAuth 인증을 요청하는가'를 Google 인증 서버에 알려주기 위해 사용하는 것이 '클라이언트 ID'이다. 웹서비스를 프로젝트로 등록하고, 등록할 때에 웹 사이트의 URL 정보를 제공했기 때문에 서버에 구글의 클라이언트 ID만 등록해주면, 구글에서 어떤 웹 사이트에서 OAuth 인증을 요청하는지를 자체적으로 식별할 수 있게 된다.

• 승인된 리디렉션 URI

OAuth를 사용하기 위해서는 구글 인증 서버에 client ID 이외에도 많은 추가 정보들을 제공해줘야 하지만, 그 중 중요한 정보가 리디렉션 URI이다. 

웹 사이트 사용자가 구글 인증 서버에 올바른 계정 정보를 입력하면, 구글에서는 이 정보가 유효한지 판단한 후에 유효하다면 해당하는 유저의 정보를 웹서비스로 전송해야 한다. 그래야 웹 서비스에서도 현재 로그인한 사용자가 어떤 사용자인지 식별할 수 있으며, 자체적으로 유저 정보를 관리할 수 있기 때문이다. 그러면, 구글 유저 정보를 웹 서비스의 특정 URL로 전송해줘야 하는데 이 URL이 바로 리디렉션 URL이다. 구글은 인증이 끝나면 리디렉션 URL로 로그인을 한 구글 계정 정보를 POST로 전송해준다.

Open ID ::

OAuth는 권한 관리를 위한 프로토콜이라면, OpenID는 인증을 위한 프로토콜이라고 할 수 있다. Open ID 프로토콜에 대한 정의는 OAuth 2.0 프로토콜의 상위계층에서 인증을 담아내는 프로토콜이라고 한다. 즉, OAuth API에 OpenID API가 포함되어 있다고 생각하면 되고, 실제로 그렇기도 하다.

Open ID프로토콜을 통해 인증이 완료되면,  ID Token이 발급된다. 

ID Token은 JWT 형식으로 구성된 최종사용자(End-user)의 인증 정보를 담고 있는 보안 토큰이다. ID Token의 주요 claim으로는 [iss], [sub], [aud], [exp], [iat]들로 구성되어 있다.

• iss _ ID Token을 발급한 ID Provider를 말한다(예를 들어, 구글/카카오/페이스북..)
• sub _ Client 측에서 End-user를 식별할 수 있는 고유한 식별자를 말한다
• aud _ ID Token이 어떤 Client를 위해 발급된 것인지를 나타낸다.
• exp _ 만료시점, iat _ 발급시점 

> 왜 ID Token으로 Authentication을 해줘야 할까?

위키백과에서 Open ID와 OAuth에 대해 설명할 때, OAuth로 인증하는 과정을 pseudo-authentication으로 칭하며, OAuth를 Authentication 수단으로 사용할 시에 보안 결함이 발생할 수 있다고 설명한다. 

공부를 하면서 추가적으로 ID Token과 Access Token에 대해서 비교하는 글을 많이 보았고, 심지어 나도 정리하면서 두 개념 사이에서 헷갈린다는 생각이 많이 들었기 때문에 이에 대해서 다음 포스트에 더 정리할 예정이다.

• 출처

https://mangkyu.tistory.com/76
https://ko.wikipedia.org/wiki/OAuth
https://velog.io/@jakeseo_me/Oauth-2.0%EA%B3%BC-OpenID-Connect-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%A0%95%EB%A6%AC
https://6991httam.medium.com/oauth%EB%9E%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-openid-8c46a65616e6
https://velog.io/@piecemaker/OAuth2-%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90
https://nordicapis.com/what-is-openid-connect/