For Me

어플에 데이터를 입력한 후에 내용들이 잘 들어갔는지 확인하기 위한 작업이다

인텔리제이 기주으로 오른쪽 상단에 돋보기 모양이 있는데 이것을 클릭

여기서 [Device File Explorer]을 입력한다.

그 후에 내가 확인할 파일을 찾아서 그 파일안의 저장한 데이터파일의 이름을 찾는다

그리고 더블클릭이 아닌 마우스 오른쪽 버튼을 클릭해서 Save As..를 클릭

그후에는 확인하고싶은 곳에다가 파일을 저장해주면된다.

그냥 파일을 열려고 하면 파일이 열리지 않아서 프로그램의 도움을 받아서 열어보려고 한다.

위의 링크에서 원하는 사양을 다운로드 받아준다.

여기서 [데이터베이스 열기]를 클릭해주고 앞에서 저장한 파일을 찾아서 열어준다.

위에서 SQL실행을 클릭해주고 SQL구문을 입력해주면 내가 저장한 데이터를 확인할수있다.

여기서 추가로 where절과 같은 구문들을 추가해주면

내가 원하는 조건의 데이터만 출력이 가능하다.

수업듣다 다운로드한 파일을 보고싶어서 파일을 열었는데 파일이 열리지 않았다. 

아래의 오류뜨면서 불가.

왠지 모르겟지만 JDK가 없다고 한다.

컴퓨터 상에는 JDK가 있으니 인식이 안되는 것으로 생각했다.

검색하다 제일 하단에 관련 내용이 있었다. 

[file] - [Project Structure...] 에 들어가면 

아래와 같이 뜨는데 SDK를 클릭해서 JDK를 설정해 주면 된다.

처음에 들어갔을때 JDK가 없어서 No SDK로 되어있었다.

그러면 정상 작동한다

참고한 곳

내가 설치하면서 뭔가를 빠트린지는 모르겠지만 오류가 떠서 해결했다.

구글링 최고.

방법

[file]-[setting]-[Appearence&Behavior]-[Android SDK]-[SDK Tools]-[Google Play Lisence Library]

요런 라이선스 문제가 생겼다.

그냥 해결했다는? 라이선스와 관련된 파일 하나 다운로드 해주기

내가 가능했던 코드를 기록하기. 

이 기능을 구현하기 위해서 나도 다른 곳에서 찾아보곤 했다.

로그아웃의 기능을 구현하기 위해서는 로그인으로 인해 생긴 "세션"을 없애는 작업을 하면 된다고 한다.

코드

@RequestMapping(value = "logoutAf.do", method = RequestMethod.GET)
	public String logoutAf(HttpSession session){
		logger.info("MemberController logoutAF() " + new Date());
		session.invalidate();
		
		return "redirect:/hello.do";
	}

로그인된 화면에서 "로그아웃"을 눌렀을 때, 위의 코드를 사용했다.

데이터 베이스까지 이동하지 않고 Controller에서 세션을 지워주었다.

여기서 사용된 객체인 

invalidate()

직역하면 "무효화하다"라는 뜻을 가진다. 실제로도 로그아웃을 할때 위에서는 세션을 지워준다고 이야기했지만, 실제로는 사용된 세션을 무효화되는 것이라 실제로는 남아있다고 한다.

참고 자료 : https://blog.naver.com/zino1187/110025698379

merge를 배우면서 같이 배웠는거. merge는 하다 꼬여서 다시 해보기로 하고 git bass를 해보기로 했다.

정말 간단하게 말하자면 git bash는 source tree라는 git에 커밋,푸시,풀 등을 해주는 같은 '기억형상장치' 역할을 한다.

이것을 사용하려면 git을 다운로드 해야한다.

https://git-scm.com/

나는 언제했는지는 기억도 나지 않지만 뭐 있으니까 사용해야지ㅎ

+) 리눅스는 기존의 terminal을 사용해도 되지만 window는 git bash를 사용하면 좋다고 한다.

사용을 하기 전에 클론을 받을 위치의 파일에 들어간다.(폴더를 새로만들어도 가능)

마우스 오른쪽을 누르면 이런 창이 뜨는데 git bash here을 클릭해준다.

여기서 잠깐 GUI는 source tree와 같은 초보자가 명령이나 작업을 이해하기 쉽게 히스토리를 시각화하여 도와주는 도구이다.

그럼 아래와 같은 창이 뜨게 되는데 

나는 클론을 받을 계획이니 git clone과 파일의 주소를 입력해주면 

오른쪽과 같은 창이 되며, 내가 지정했던 폴더에 파일이 클론된다.

내가 보려고 추가해놓기

https://shxrecord.tistory.com/179 : git bass로 commit, push 하기

<참고 출처>

https://parkjh7764.tistory.com/39

** 수업 중간 오픈북 테스트에 대한 설명내용 정리 **

* 어플리케이션 배포 : 로컬(혹은 개발서버)에서 개발된 어플리케이션 마일스톤을 실제 운영 서버에 올려서 구동하는 작업

* 배포(jspmvc의 예) : 프로젝트를 build해서 .jar파일 혹은 .war 파일 한개로 만들어서 <-(maven) 이거를 서버 머신에 이미 설치된 was환경 (JRE,  ApacheTomcat,...)에 넣어서 구동

* Maven : 프로젝트 객체 모델이라는 개념을 바탕으로 프로젝트 의존성 관리, 라이브러리 관리, 프로젝트 생명주기 관리 기능 등을 제공하는 프로젝트 관리 도구 (그 외 Gradle이란 것도 있다.)

* WhtieBox Test

    : 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법 (테스트 과정 초기 적용)

  # 테스트 종류

    - 기초 경로 검사 : 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법

    - 제어 구조 검사

        1, 조건 검사 : 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법

        2, 루프 검사 : 반복 (loop) 구조게 초점을 맞춰 실시하는 테스트 케이스 설계 기법

        3, 데이터 흐름 검사 : 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

* BlackBox Test

    : 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트로, 기능 테스트

(테스트 과정 후반에 적용)

    - 동치 분할 검사 : 조건에 맞는 입력 자료와 맞지 않은 자료를 균등하게 검사

    - 경계값 분석 : 중간값이 아닌 경계값을 테스트 케이스로 선정

    - 오류 예측 검사 : 테스터의 경험과 감각으로 보충적 데이터 확인 

* 테스트 케이스 설계 : 특정 요구사항에 준하는지 확인하기 위해 입력값, 실행조건, 예상결과를 묶어 놓은 집합을 어떻게 할지 정의

* 테스트 자동화 도구의 장점

   - 반복적인 작업을 자동화, 인력 및 시간 절감

   - 향상된 테스트 품질 보장

   - 사용자의 요구사항 등을 일관성 있게 거머증

*소스코드 보안 약점

    - XSS(Cross Site Script) : 검증되지 않은 외부 입력 값에 의해 사용자 브라우저에서 악의적인 스크립트가 실행될 수 있는 보안 약점

*어플리케이션 성증 저하 운인

   - DB에 필요 이상의 많은 데이터를 요구하여 response 받는다.

   - 불필요한 커밋을 자주 발생

   - 데이터 손실이 발생할 경우

* 클린코드(소스코드의 최적화)의 작성원칙

   - 가독성, 단순성

   - 추상화

   - 의존성의 배제

* 릴리즈(release) : 운영서버에 배포가 모두 끝난 직후 EndUser가 실제 어플리케이션을 사용할 수 있는 단계(==OPEN)

white&black box test 출처 : https://sw-ko.tistory.com/400

배포관련 더 참고할 것 : https://dev-luna-archive.tistory.com/4

                              https://onlyfor-me-blog.tistory.com/177 (cmd에서 자바파일 컴파일 방법)

## 수업 중간 시험 전 수업 내용 + 시험(오픈북) 문제 내용 ##

* 통합 테스트 : 프로젝트 전체가 가지고 있는 기능/비기능 요구사항을 제대로 준수해 개발되었는지 전체적으로 테스트 실행

* 유닛테스트 : 요구사항 한 개가 가지고 있는 다양한 로직들을 작은 단위로 쪼개서 단위별로 테스트(단위테스트

   >> 요구사항 기능 1개를 전체 테스트 해봄

* 통합 기능 테스트의 목적 : (테스트를 개발 과정 중 어느 타이밍에서든 한다.)

    - 테스트를 수행하기 전 명확한 목표의식을 가지기 위해

    - 테스트 범위를 명확하게 식별

       ex) 페이징이 안된다면 어떠한 행동을 했을 때 어떠한 반응을 하는지, 이미지와 설명이 있으면 최고

    - 테스트 간에 의사 소통을 원활하게 한다

* Junit : java 언어로 구현된 프로그램의 텥스트를 수행할 수 있는 유닛 테스트 도구들

* 테스트 원칙 

   - 단위 테스트를 수행해 보니 지난번 외주 직원이 개발한 유통 모듈에서 계속하여 오류가 발생하고 있다. 타 모듈에 비해 유통 모듈의 오류 발생률이 상대적으로 높다.

  +) 결함 집중의 원칙 : 시스템 자체가 가지고 있는 여러기능(모듈)들 중 에러나 결함은 특정 모듈에서 집중적으로 발생 

  +) 테스팅은 결함이 존재함을 밝힌다 : 결함이 발견되지 않았더라도 해당 소프트웨어에 결함이 없다고 증명된 것은 아니다.

  +) 살충제 패러독스 : 동일한 테스트 케이스로 테스트를 반복하면 새로운 결함을 발견하지 못할 것(새로운 테스트 케이스 추가하기)

  +) 테스트 정황 의존적 : 테스트는 테스팅 되는 대상에 따라 다른 방법으로 접근하는 것 필요

  +) 오류-부재의 궤변 : 개발된 시스템이 사용성이 지나치게 낮거나 처음 요구사항을 만족하지 못한다면, 결함을 모두 제거 했다 하더라도 품질이 높다고 볼 수 없다. 

* 단위 테스트 : (메소드 한개)에 정해진 input 여러종류를 넣었을 때, output이 예상한 대로 나오는가 (input들은 테스트 데이터)

* 단위 테스트 수행해서 일어나는 일 2가지 : pass or fail

   - fail 일 때 : 테스트 케이스를 불합격 처리, 결함 등록 (프로젝트 상황실 솔루션, 이슈트래킹, es) redmine, jira)한다.

* 단위 테스트 결함 관리 절차 : 단위테스트 수행 도중 발생하는 결함을 등록하고, 조치된 결함을 재테스트 하는 단위 테스트 절차 

* 결함 : application테스트 도중 예상치 목한 결과, 오동작, 오류화면

*Reopen : 결함을 개발자가 수정 완료했다 보고 -> 테스트(QA) 재 테스트를 하였으나 결함이 그대로 존재함. 그래서 개발자에게 다시 돌려보냄

* GIT이라는 형상관리시스템에서 commit과 push의 차이

  - commit : 파일 및 디렉토리에 대한 변경 사항을 git의 인덱스에 기록한다.  

  - push : 로컬 인덱스 및 오브젝트 변경 정보를 사용하여 원격 저장소를 업데이트

깃에 대한 내용 출처 : https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=eleccom&logNo=130087427451 

추가한 테스트 원칙 출처 : https://eehoeskrap.tistory.com/15 >>똑같이 적지 않아 더 자세히 보고싶으면 참조하기

한 프로젝트를 맡게 된다면 꼭 알아야 할것.

## 수업 중간 테스트 전 수업 내용##

* 요구사항 확인 : 시스템이 가져야할 기능이나 만족해야 할 조건

   중요1 >> 제시하는 고객이나 사용자의 요구사항 도출

   중요2 >> 시스템 개발 측에서 어떻게 요구사항 도출을 유도하고 해당 요구사항을 시스템 개발 과정에 사용할지

* 프로젝트 수행의 4단계

    분석 -> 설계 -> 구현 -> 런칭

* 현행 시스템 분석 작업의 목적 : 개발하고자 하는 시스템의 개발범위 및 이행 방향성 설정

 ++) 시각적으로 표현 할 수 있으면 좋음.

* 현행 업무 관련 자료 수집 : 목표 업무 프로세스 정의서

* 현행 업무 관련 자료 수집 시 파악하려는 자료 : 업무지침, 메뉴얼, 업무관련 인터뷰, 이전 시스템 개발 산출물

    >> "목표 업무 프로세스 정의저" 매우 중요

    >> 산출물 : 문서, 코드, 실행파일...

* 개발 기술 환경 결정을 위한 고려사항 : 운영체제, DBMS, 웹 어플리케이션 서버,....

* 업무개선 작업(Pi) : 업무의 불편사항 등 개선점을 도출, 개선된 업무로 신규 시스템의 요건 정의하는 작업

* 에일리언 코드 : 특정 기능을 담당하는 개발자가 퇴사(외 이유로) 기능 관련 문서나 주석이 없어 코드나 함수를 전혀 분석할 수 없는 상황의 코드

*현생 시스템 관련 자료를 수집하기 위하여 분류한 기준

   1, 요구사항 변경 기준

   2, 개발팀과 사용자간 커뮤니케이션 용이 여부

   3, 하드웨어 및 네트워크 

* 요구사항의 분류

   >>나누는 기준 : EndUSER가 실제 사용감을 느끼는 기능인가

* 제품요구사항(비기능적)

   - 사용성 :  사용자가 어떻게 쉽게 사용할 수 있는가

   - 효율성 

        1, 성능 : 특정 기능이 특정시간 내에 실행

        2, 공간 : 특정 기능 수행시 메모리를 최대 얼마까지 사용할 수 있는가

   - 신뢰성 : 특정 기능 실행시 실패할 가능성이 몇 %보다 낮아야 하는가

   - 이식성 : 다양한 플래폼 위에서 작동하는가

* 요구사항 도출 계획 작성 시 프로젝트 관리 측면 고려사항

   1, 요구사항 변경기준

   2, 개발팀과 사용자간 커뮤니케이션 용이 여부

   3, 요구 명세에 대한 객관적 판단

 * 정형 명세 : 요구사항을 기술하여 명세하는 방법을 수학과 논리학에 기반하여 자연 언어가 내포하는 애매모호함, 불확실성을 제거하는 명세기법

* 요구사항 개발 프로세스의 프름

    도출 -> 분석 -> 명세 -> 확인

*인수테스트 : TurnKey 프로젝트에서 최종 개발 완료하여 런칭 전 client(고객)과 수행하는 최종 인수 통합 테스트

*프로토 타이핑 : 새로운 요구사항을 도출하기 위한 수단, sw요구사항에 대해 소프트웨어 엔지니어가 해석 한 것을 확인하기 위한 수단으로 많이 사용하는 요구사항 확인 기법

제품 요구사항 출처 : https://ee-22-joo.tistory.com/2