수테크📱⌚️👀

1.3. 테스팅의 일반적인 원리

• 원리 1. 테스팅은 결함이 존재함을 밝히는 것 (Testing shows presence of defects)
  • 잠재적으로 존재하는 결함 줄임
  • But, 결함이 없다고 증명할 수는 없음
• 원리 2. 완벽한 테스팅 (Exhaustive testing)은 불가능 (Exhaustive testing is impossible)
  • 한 프로그램 내에 내부 조건이 많음
  • 입력이 가질 수 있는 모든 값의 조합이 무수히 많음
  • 이벤트 발생시 발생 순서에 대한 조합도 무수히 많음
  • 리스크에 따라 테스트 강도 높게 수행 -> 실제 완벽은 불가
• 원리 3. 개발 초기에 테스팅 시작 (Early testing)
  • 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근
  • 요구사항 분석서와 설계서 등의 개발 산출물 분석 후 테스트 케이스 도출
  • 다 만들고 테스트 결과가 엉망이 나오면 유지보수 비용이 장난 아니겠쥐~
• 원리 4. 결함 집중 (Defect clustering)
  • 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임
  • 결함의 집중은 운영상의 장애를 초래
    • 복잡한 구조의 모듈
    • 다른 모듈과 다량의 상호작용을 하는 모듈 (자꾸 호출하다 보면 결함 나오기 쉬움)
    • 개발 난이도가 높거나 최신 기술을 사용한 모듈
    • 크기가 큰 모듈
    • 경험이 미흡한 팀에서 개발한 모듈
    • 새롭게 개발한 모듈
• 원리 5. 살충제 패러독스 (Pesticide paradox)
  • 동일한 테스트 케이스로 동일한 테스트를 반복하면 결함으로 찾기 어려워짐
  • 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선
• 원리 6. 테스팅은 정황(Context)에 의존적 (Testing is context dependent)
  • 테스팅은 정황(context)과 도메인에 따라 다르게 진행
  • 모든 테스트에 적용되어야 하는 것
    • 테스트 프로젝트 기획
    • 표준적인 기법적용
    • 독립적인 테스트 환경
    • 효율적/효과적 테스트 팀 조직
    • 정식 리포팅 등
• 원리 7. 오류-부재의 궤변 (Absence-of-errors fallacy)
  • 개발된 소프트웨어가 사용자 요구수준을 만족하지 않는다면 버그를 수정하는 것은 의미가 없음

1.2 테스팅이란 무엇인가?

• 테스팅
  • 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘
    • 정상 동작 여부 확인
    • 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인
    • 개발 프로젝트의 리스크 정보를 정량적 수치로 의사결정권자에게 전달
  • 초기 개발 산출물 -> 리뷰
  • 테스트 케이스 작성 과정(결함 예방 활동)
  • 다양한 테스팅 활동

• 테스팅의 일반적인 목적
  • 남아있는 결함 발견
  • 명세 충족 확인
  • 사용자 및 비즈니스의 요구 충족
  • 결함 예방
  • 품질 수준에 대한 자신감 획득과 정보 제공
  • 비즈니스 리스크를 감소시키는 정보에 근간한 조언 제공
  • 개발 프로세스 점검, 이슈 제기
  • 논리적 설계의 구현 검증
  • 시스템과 소프트웨어가 적절히 동작함을 확인

• 관점에 따른 테스팅의 목적
  • 개발 과정 - 결함을 찾고 수정하기 위해 가능한 많은 장애 상황 재연
  • 인수 테스팅 - 예상대로 시스템이 동작하는지 확인, 요구사항 확인
  • 소프트웨어 품질 - 출시하는 것의 리스크를 관련자에게 전달
  • 유지보수 테스팅 - 변경에 대해 새로운 결함의 유입을 확인(반복 테스트)
  • 운영 테스팅 - 신뢰성 또는 가용성 같은 시스템 특성을 평가
  • 테스팅은 문서의 리뷰와 함께 정적 분석에 의한 테스트 포함

1.1. 테스팅이란 무엇인가?

1.1.1 SW 시스템 관점에서 테스팅의 필요성

• SW 관점에서 테스팅
  • 비즈니스 어플리케이션에서 소비자 제품에 이르기까지 폭넓게 생활의 많은 부분에 사용 -> 비중은 계속 증가
  • 금전적인 손실, 시간 낭비, 비즈니스의 이미지 손상, 그리고 부상이나 사망에 이르기까지 다양하고 심각
  • 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요

1.1.2 소프트웨어 결함의 원인

• 소프트웨어 결함
  • 오류(error) - 인간의 행위, 실수
    • 코드 작성, 소프트웨어나 시스템 또는 문서 작성시 결함을 만드는 오류
  • 결함(defect) - 요구된 기능의 부정확한 처리를 말하며 이것으로 인해 고장 또는 장애를 발생시키는 원인이 됨
    • 시간적인 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 수많은 시스템 상호간의 연동
    • 결함은 장애의 원인
    • But, 모든 결함이 장애를 발생시키는 것은 아님
  • 장애(failure) - 코드에 존재하는 결함의 실행 또는 환경적 조건에 의해 부정확하게 처리되는 것을 의미함
    • 결함 + 환경적인(방사, 전자기장, 물리적 오염 등) 조건

1.1.3 SW 개발, 유지보수, 운영 시 테스팅의 역할

• 테스팅
  • 개발 초기의 요구사항 분석 단계부터 리뷰와 정적분석(문서 정도로 생각)을 통해 정적으로 시작 -> 각각의 개발단계에 대응하는 테스트 레벨별
  • 컴포넌트, 통합 테스팅은 개발 조직 중심으로 수행
  • 시스템이 갖춰진 이후의 테스팅은 독립적인 테스트 조직 중심
  • 테스트 레벨에 따른 테스트
    • 소프트웨어 품질을 높이고, 결함 발생 가능성을 최소화
  • 유지보수 활동으로 변경 및 단종되거나 가능성을 최소화
    • 변경된 환경에 대해 운영 테스팅(리그레션 테스팅)
    • 변경으로 인한 결함과 장애를 예방
  • 계약상 요구조건 및 산업에 특화된 표준 만족

1.1.4 테스팅과 품질

• 품질 특성 및 향상
  • ISO/IEC 9126 소프트웨어 제품 품질
    • 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성
  • 품질 향상 -> 테스팅이 결함을 찾아내고, 발견된 결함 수정
  • 품질 보증(Quality Assurance)
    
    • 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보
    • 발견된 결함의 근본 원인 이해를 통해 프로세스 개선
    • 결함의 재발 방지
  • 개발 표준이나 교육 훈력 그리고 결함 분석

1.1.5 테스팅, 얼마나 해야 충분한가?

• 적절한 테스팅 정도
  • 리스크 수준을 고려
  • 프로젝트 제약 사항
    • 기술적인 내용
    • 비즈니스
    • 제품
    • 프로젝트 리스크
    • 시간
    • 비용
  • 테스팅은 테스트된 SW나 시스템을 다음 단계로 전달하는 데 있어 프로젝트 이해관계자들이 릴리즈 결정(출시)을 내릴 수 있도록 충분한 정보 제공 (맨날 유지보수할 수는 없자나...)

1. 자바스크립트란
   네이버, 구글과 같은 웹 페이지를 동적으로 만들기 위해 개발된 프로그래밍 언어
   
   
2. 라이브러리와 프레임워크의 차이는?
   1) 라이브러리 : 개발자가 특정 기능을 수행할 수 있도록 제공하는 도구 모음, 필요할 때 호출해서 사용할 수 있다. Numpy, Pandas 등이 있음
   2) 프레임워크 : 전체 애플리케이션 개발을 위한 기본 구조를 제공, 개발자가 그 틀 안에서 필요한 코드를 작성
   
   
3. 자바스크립트의 타입 분류?
   1) 원시 타입 자료형 : 프로그램이 실행되는 도중에 단 하나의 값만 가지는 SYMBOL형 : BigInt, 문자, boolean, null, undefined
   2) 비원시 타입 자료형 : 한 번에 여러 개의 값을 가지는 타입 : 객체, 함수, 배열
   
   
4. Infinity와 Nan에 대해서 설명?
   1) Infinity : 무한대를 나타내는 값으로, 어느 숫자든지 0으로 나누는 경우 반환되는 값이기도 하다
   2) NaN : 숫자가 아니라는 의미를 가지고 있고 문자열을 숫자로 나누는 것과 같이 부정확한 연산을 할 경우 반환되는 값같은 경우이다
   
   
5. null과 undefined의 차이에 대해서 설명?
   1) null : 오직 null 값만 포함하는 자료형으로 사용되고 존재하지 않거나 알 수 없는 값을 나타낼 때 사용
   2) undefined : 변수에 값이 할당되지 않은 상태일 때 자동으로 undefined 값이 할당됨!
   
   
6. === 연산자와 == 연산자의 차이점?
   1) === 연산자 : 두 값과 두 변수의 자료형까지 같은지를 비교하는 연산자
   2) == 연산자 : 두 값의 자료형은 비교하지 않고, 오직 값이 일치하는지를 비교하는 연산자
7. let과 var의 차이점 +const?
   1) let
   - 재할당 가능 여부 : 가능
   - 스코프 : 블록 스코프
   - 호이스팅 : 선언만 호이스팅되며 TDZ 적용
   - 초기화 필수 여부 : 선택
   - 추천 상황 : 값이 변경될 가능성이 있을 때
   
   2) var
   - 재할당 가능 여부 : 가능
   - 스코프 : 함수 스코프
   - 호이스팅 : 선언과 초기화 모두 호이스팅됨
   - 초기화 필수 여부 : 선택
   - 추천 상황 : 사용 비추천(오래된 방식)
   
   3) const
   - 재할당 가능 여부 : 불가능
   - 스코프 : 블록 스코프
   - 호이스팅 : 선언만 호이스팅되며 TDZ 적용
   - 초기화 필수 여부 : 선언 시 반드시 초기화 필요
   - 추천 상황 : 값이 변경되지 않아야 할 때
   
   
   
8. 호이스팅이란?
   아직 선언되지 않은 함수나 변수를 해당 스코프의 맨 위로 끌어올려서 사용하는 것처럼 보이게 하는 js의 동작 방식
   
   
9. 구조분해할당이란?
   배열 요소나 객체의 프로퍼티를 분해해서 그 값들을 각각의 변수에 할당하는 자바스크립트 표현식('...'기호를 사용)
   
   
10. spread와 rest
    1) spread
    - 특정 배열의 요소나 객체의 프로퍼티 값을 펼치는 역할을 한다
    - 동일한 코드를 여러 번 작성해야 하는 과정에서 코드를 더욱 간단하게 작성할 수 있다
    - 순서에 상관없이 여러 번 반복해서 사용할 수 있다
    
    2) rest
    - 특정 부분을 하나의 배열이나 객체로 묶는 역할을 하는 문법
    - 객체에서 rest는 구조 분해 할당과 함께 사용되며, 원하는 값들을 꺼내고 나머지 값을 별도로 묶어서 할당할 수 있다
    - rest 문법은 spread와는 다르게 순서에 상관없이 여러번 작성할 수 없고, 항상 맨 마지막에 작성해야 하기 때문에 주의해서 작성해야 한다
    
    
11. promise 객체란?
    - js에서 특정 작업을 비동기로 처리할 때 사용하는 객체
    - 프로미스 객체는 객체 생성 시 인수로 excutor라는 실행 함수를 전달하고, 실행 함수에는 매개변수로 resolve와 reject라는 콜백함수를 전달한다 
    - 프로미스 객체가 생성됨과 동시에 excutor가 실행되고, excutor에서 원하는 작업이 처리된다
    - 프로미스 객체의 excutor는 작업 처리의 성고 여부에 따라 성공했을 경우 resolve, 실패했을 경우 reject가 호출된다
    
    
12. async & await란?
    1) async
    - "비동기 작업을 약속(Promise)하는 함수"를 표시하는 간판 같은 역할입니다.
    - 간판(async)을 보면 "이 함수는 나중에 결과를 줄 거야"라고 알 수 있습니다.
    - 함수에 async를 붙이면 자동으로 Promise를 반환합니다.
    - 비동기 작업을 포함하고 있는 프로미스 객체를 반환하는 함수에 작성하는 키워드이기때문에, async를 작성하면 코드를 더 직관적으로 해석할 수 있다
    
    2) await
    - async 함수 안에서만 사용할 수 있는 키워드로, 비동기 작업(Promise)이 끝날 때까지 기다렸다가 그 결과를 반환합니다.
    - await는 마치 식당에서 음식이 나올 때까지 기다리는 손님과 같은데, 손님은 음식을 기다리지만, 음식이 나올 때까지 다른 사람과 대화를 할 수도 있음(비동기 작업)
    
    
13. JSON이란?
    - 데이터를 텍스트 형식으로 저장하고 교환하기 위해 사용하는 가볍고 읽기 쉬운 데이터 포맷
    - 웹 애플리케이션에서 클라이언트와 서버 간 데이터를 주고받을 때 사용
    - JSON은 JavaScript 문법을 기반으로 하지만, Python, Java, C++, PHP 등 거의 모든 프로그래밍 언어에서 사용 가능
    - 키-값 쌍으로 데이터를 표현
    
    
14. DOM이란?
    - 자바스크립트는 DOM을 통해 웹 페이지 요소에 접근할 수 있다
    - DOM을 사용하면 HTML 문서를 동적으로 수정, 추가, 삭제하고 사용자와 상호작용할 수 있습니다.
    - 주요 객체: document, Node, 요소 노드 등
    - 주요 메서드: getElementById, querySelector, createElement, appendChild 등
    - DOM은 웹 페이지를 트리 구조로 표현하며, JavaScript를 통해 동적으로 조작할 수 있는 인터페이스입니다.
    
    
15. 로컬 스토리지란?
    - 웹 브라우저의 데이터를 저장할 수 있는 저장소와 같은 기능
    - 로컬 스토리지를 사용하면 사용자가 브라우저를 종료하더라도 기존에 웹 페이지 내에서 저장한 데이터를 계속 유지할 수 있다
    - 로컬 스토리지는 텍스트 데이터만 저장할 수 있기 때문에 객체 혹은 배열 형태의 데이터를 로컬 스토리지에 저장하려면 데이터를 문자열로 변환해야 한다
    - JSON 객체에는 특정 문자열을 자바스크립트 객체로 변환하는 JSON.parse(), 특정 객체를 JSON 형태로 변환하는 JSON.stringify() 메서드가 있다 

1. jUnit : assertArray / asertThrows
2. checkStyle : 코딩 스타일 정량
3. Doxygen : 의존성 분석(다이어그램)

# 1. JUnit 한단계 더 나아가기

예외가 발생하는지 확인하고 그 메세지를 exception에 저장해서 우리가 원하는 에러 문자와 일치하는지까지 확인하기!

@Test
	void testDivide() throws Exception {
//		assertEquals(0.5, calculator.divide(2.0, 4.0));
		assertThrows(Exception.class, () -> 
			calculator.divide(4, 0), "0 예외 처리 발생"
		);
		// calculator.divide(4, 0)실행 시, Exception 여부만 확인
	}	
	
	// 여부만 확인하는게 아니라 문자가 나오는지 확인
	@Test
	public void testDevide_exception() throws Exception {
		Exception exception = assertThrows(Exception.class, () -> 
		calculator.divide(4, 0), "0 예외 처리 발생"
		);
		
		assertEquals("Divide Error", exception.getMessage());
	}

정적 분석 코드 돌리기  : SonarQube(java는 무료) - pmd, checkstyle

1. 개인적인 폴더 내에서 eclipse, Intellij에서 돌리면 SonarLint

2. git에 통체로 올렸을때는 SonarQube(서버) 회사 전체 내부의 코드를 볼 수 있음 

3. Jenkins CI/CD에서 build할때 SonarQube 사용할 수도 있음

JUnit은 단위 테스트를 위한 도구이고 웹/앱에서는 그렇게 필수적이지는 않다!!  

# assertArray 사용!!

package com.calc;

import static org.junit.jupiter.api.Assertions.assertArrayEquals;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

import java.util.Arrays;

import org.junit.jupiter.api.Test;

class CalculatorTest_format {

	Calculator calculator = new Calculator();
	
	// assertEquals : 개별 요소 검증
	
	@Test
	void testParseInput_individualCheck() throws Exception {
		String[] result = calculator.parseInput("2 + 3");
		assertEquals("2", result[0]);
		assertEquals("+", result[1]);
		assertEquals("3", result[2]);
	}
	
	// assertEquals : List 로 검증
	@Test
	void testParseInput_listCheck() throws Exception {
		String[] result = calculator.parseInput("2 + 3");
		assertEquals(Arrays.asList("2", "+", "3"), Arrays.asList(result));
	}
	
	// assertEquals
	@Test
	void testParseInput_array() throws Exception {
		String[] result = calculator.parseInput("2 + 3");
		assertArrayEquals(new String[] {"2", "+", "3"}, result, "배열이 예상 값과 다릅니다");
	}
	
	// null, empty 처리 여부 확인
	@Test
	void testParseInput_nullAndEmpty() throws Exception {
		Exception nullException = 
				assertThrows(Exception.class, () -> 
						calculator.parseInput(null));
		assertEquals("null은 입력 불가", nullException.getMessage());
	}
}

# checkStyle 적용하기

# doxygen (의존관계 파악 분석하고 시각화하지만 간략함)

의존성 분석

• 개요
  • 함수 변수의 호출관계를 분석하는 도구
  • 도구가 추구하는 방향에 따라 패키지 클래스(파일) 함수 단위로 표현
• 목적
  • 아키텍처 구조에서 서브 시스템 간의 의존이  적절한지 확인
    • 서브 시스템 레이어에서 각 레이어 간 호출관계
    • 서브 시스템 레벨에서 각 레벨 간 호출 관계
    • 원형의존성(상호 참조)관계
  • 객체지향에 특화되어, 추상화와 구제촤의 정도를 확인 

https://www.doxygen.nl/download.html#google_vignette

# graphvie(Doxygen의 분석 결과를 좋게 시각화 하는 도구, 산출물 제출에 용이함)

https://graphviz.org/download/

# 아키텍처(Architecture)

- 건물의 뼈대뿐 아니라 특성을 결정짓는 기본 구조를 일컫는 말(모든 기술 분야에 적용할 수 있고 종류도 다양함)

- 대형 프로젝트가 복잡성의 문제를 해결하는 방법

• 개발할 소프트웨어의 전체 구조를 가장 먼저 생각
• 소프트웨어의 구조를이루는각 구성요소를 찾음
• 각 구성요소 간의 명확한 관계를 설정
• 일정한 규칙을 따름    

- 소프트웨어 아키텍처 : 상위 수준에서 소프트웨어 구성요소들 간의 관계로 구성된 전체적인 구조를 설계하는활동...   

#  소프트웨어 아키텍처의 역할

• 여러 이해관계자 간의 공통의 의사소통 수단(어느정도의 what과 how가 다 담겨져 있다! 고객 요구 사항에 맞게 가고 있는지..)
• 시스템품질 속성의 사용또는 억제 기준  (소프트웨어 품질 속성 8가지를 사용해서 아키텍처가 어떤 정도의 수준인지, 유지보수 & 재사용 가능하도록 만들도록 함..)
• 변경에 대한 원인 파악 및 유연한 대처가 가능 
• 재사용 가능한 소프트웨어 구성 요소 확보 수단 
  
  

# 아키텍처 설계 시 고려 사항

• 모든 이해관계자 사이의 의사소통 도구로 활용할 수 있어야 함
• 구현에 대한 제약 사항(개발 비용, 기간, 조직의 역량 등)을 정의해야 함
• 모든 이해관계자의 품질요구사항을 반영해 우선순위에 따라 시스템 품질 속성을결정해야 함 (성능 사용성, 보안성, 안정성, 검증 가능성, 변경 용이성 등)
• 특정 문제 영역에 적합한 소프트웨어의 구성 요소를 표준화하고 패턴화해 재사용할 수 있도록 설계해야 함

# 아키텍처 품질 속성 : 시스템 품질 속성

• 가용성(Availability) : 시스템이 실패 없이 운용될수 있는 확률로 시스템이 장애 발생 없이 서비스를 제공할 수 있는 능력
• 변경 용이성(Modifiability): 사용자가 새로운 요구사항을 요청했을 때
• 성능(Performance) : 사용자 요청과 같은 이벤트가 발생했을 때 얼마나 빠르고 효율적으로 기능을 수행할 수 있는 가를 말함
• 보안성 : 허용되지 않은 접근에 대응할 수 있는 능력
• 사용성 : 시스템을사용할 때 발생할 수 있는 여러 가지 상황을 극복할 수 있도록 이를 반영해 아키텍처 설계 작업을 해야 함
• 테스트 용이성  : 테스트 비용을 줄이기 위해서는 앜키텍처 설계부터 테스트를 고려해야 함

# 아키텍처 품질속성 : 아키텍처 품질속성

• 개념적 무결성 : 시스템 설계는 전체 시스템을 나타내는설계와 세부 구성 요소 설계로 나뉨
• 정확성과 완전성 : 정확성과 완전성은 사용자가 요구하는 기능을 충족시키는 정도를 말하며 오구분석명세와 일치하는 정도를 나타냄(요구사항 명세에 있는 내용을 다 포함 해야함 / 필요 없는 내용 넣을 필요 없음)
• 개발 용이성(구축 가능성) : 전체 시스템을 적절한 모듈로 분할한 후 알맞게 분배 해 개발함으로써 정해진 기간 내에 개발을 완성할 수 있고 개발 과정 중에도 쉽게 변경 할 수 있는 능력을 말함 

# 아키텍처의 4 + 1 관점(View)

- 이해 관계자 별로 관점이 다름(QA, 기획자, 개발자....)

- 시스템을 이루는 요소의 집합과 그들의 연관 관꼐를 추상적으로 표현한 것!

# UI / UX

- UI(User Interface) : 사용자와 컴퓨터 사이에서 의사소통을 할 수 있도록 만들어진매게체(화면구성을 어떻게 배치할지)

- UX(User Experience) : 사용자가 어떤 시스템, 제품 서비스를직/간접적으로 사용하면서 느끼고 생각하게 되는 총체적인 경험(어떤 이유로 소비자가 떠나갈까.. 이런느낌)

# 연관 관계 vs 의존관계

- 연관 관계(Association)

- 소유 한다의 의미 (has a)  -> 높은 결합도

- 결합도가 높아서 잘 사용 안함..

- 1:1, 1:N, N:M 관계가 많다...

- 0..* => 0..n과 같은 의미

- 상속도 같은 메서드를사용하니까 실선으로(연관 관계)표시

- 의존관계(Dependency)

- 사용 한다의 의미 (uses a) -> 낮은 결합도

- 호출(call)한다의 관계

# 클래스 타입

- 경계 클래스(Boundary Class)

- 시스템 외부의 액터와 상호 작용하는 클래스

- 사용자 인터페이스를 제어하는 역할

- 시스템의 입력과 출력을 담당 

- Controller의 역할!!

-  제어 클래스(Control Class)

- 경계 클래스와 엔티티 클래스 사이에 중간 역할

- 시스템 내부에서 컨트롤하는 역할 / 시스템 그 자체

- 시스템의 실질적인기능 

- Service의 역할!!

- 엔티티 클래스(Entity Class)

- 시스템에서 유지 및 추적해야 할 정보를 저장하는 클래스(DB와 연결되는 클래스)

- 사용 사례에서 반복되어 나오는 용어

- 명사 추출법을 통해서 추출할 수 있다 

# 소프트웨어 구현

- 개별 소프트웨어 단위를 실행 가능한 형태로 구현하고 이를 문서화하는 활동으로 프로그래밍이라고도 함

# 프로그래밍의 이해

• 주요 용어
  • 프로그램 : 컴퓨터로 해결하기 위해 작성하는 명령어들의 모임
  • 프로그래밍 : 프로그램을 작성하는 과정
  • 프로그래머 : 프로그램을 작성하는 사람 또는 작업
• 프로그래밍 언어 : 프로그램을 작성할 때 사용하는 언어 

# 고급 언어와 저급 언어

- 저급 언어 : 하드웨어 지향의 기계 중심 언어 ex) 기계어, 어셈블리어

- 고급 언어 : 사람이 이해하기 쉬운 일상 언어와 기호를 사용한 인간 중심의 언어 ex) C, C++, 자바, 파이썬...

# 빌드(Build)

- 소스코드를 실행 가능한 독립적인 소프트웨어로 만드는 과정(컴파일 -> 링크 -> 패키징 -> 테스트)

- 컴파일(Compile) : 소스 파일을 컴파일러를 통해 기계어로 변환하는 과정

- 링크(Link) : 여러 개의 개별적인 컴파일 결과물(모듈, 라이브러리 등)을 연결하여 실행 가능한 파일을 만드는 과정

- 패키징 (Packaging) : 컴파일 및 링크된 결과물을 실행 가능한 형테로 묶는 과정(리소스 파일(이미지, 설정 파일 등)을 포함하여 배포 가능한 형식으로 압축)

- 테스트 : 빌드된 결과물이 의도한 대로 작동하는지 검증하는 과정(주로 기능 테스트를 수행)

# 빌드 도구 : Maven

- Java 빌드 관리 도구

- 사용 목적

1. 모두가 동일한 바이너리를 생성하기 위해서(같은 폴더 구조를 가지기 위해서!!)
2. 정형화된 소스코드 구조를 사용하기 위해서
3. 라이브러리 의존성을 관리하기 위해서
4. 다른 도구와 쉽게 연동하기 위해서

- 일반적인 사용 방법

1. 팀의 AA(Application Architect)가 Maven 구조 생성 및 의존성 관리
2. pom.xml파일에 라이브러리 의존성 및 플러그인 관리(QA의 경우, 품질 관련 플러그인 설정)
3. 개발 팀원은 정해진 패키지에서 소스코드 개발 

# 라이프사이클과 단계

1. 라이프사이클
   1. clean : 이전 빌드에서 생성된 산출물을 삭제하는 기능
   2. default : 프로젝트 빌드/배포와 관련된 기능
   3. site : 프로젝트의 사이트 문서 생성과 관련된 기능
2. default 의 단계
   1. validate : 정상적은 프로젝트이고 필요한 모든 정보가 준비되었는지 확인
   2. compile : 프로젝트의 소스코드를 컴파일
   3. test : 컴파일한 소스코드를 단위 테스트 프레임워크를 이용해 테스트
   4. package : JAR와 같이 지정된 포맷으로 패키징
   5. verify : 패키지가 품질 수준을 만족하는지 검증
   6. install : 패키지를 로컬 저장소에 설치
   7. deploy : 최종 패키지를 원격 저장소로 복사
3. Maven 명령

mvn clean package site pmd:pmd jdepend:generate

# Git 소개

- 버전 관리의 대표 도구

- 목적 : 버전 관리와 협업 커뮤니케이션

- 일반적인 사용 방법

1. 별도의 저장소 운영 서버 사용
   1. Git: GitHub, BitBuket, GitLab, Giblit
   2. 통합 저장소 : SCMManager
2. 클라이언트는 Core나 별도의 확장 도구 사용
   1. Eclipse/Intelli J 계열 / VS Code 플러그인 : 기본포함
   2. Tortoise 시리즈
   3. Sourcetree 

실습

1. github에서 저장소 하나 생성 (junit4 프로젝트 fork)

2. github 저장소 (원격) >> local(컴퓨터)에 복제 (git clone)

> 파일 하나 수정

> 수정된 파일 commit

> 로컬 == 원격 동일하게 세팅!

3. eclipse 프로젝트 (maven)

# 품질(Quality) 정의

- 물건이 얼마나 좋은지, 나쁜지를 나타내는 정도

- 품질은 모든 제품에서 가장 중요한 요소이며, 소프트웨어 제품도 예외는 아님

- 명시적, 묵시적요구를 만족시키는 제품 또는서비스의 능력에 관한 특성

(고객의 요구를 만족시키는 것 / 품질은 사용 목적에 일치되는 정도 / 품질은 고객 요구사항에 대한 적합도)

# 소프트웨어 품질의 정의

1.    IEEE
   1. 소프트웨어가 필요한 속성을 보유하고 있는 정도
   2. 사용자의 기대 수준을 만족할 수 있는 정도를 결정하는 소프트웨어의 특성
2. United States Department of Defense (DoD 미 국방부)
   1. 개발된 소프트웨어가 사용자의 요구사항을 만족할 수 있는 능력
3. Roger S.Pressman
   1. 소프트웨어가 기능 성능 및 만족도에 있어서 명시된 요구사항 및 내재된 요구사항을 얼마나 충족하는 가를 나타내는소프트웨어 특성의 총체

# 품질 높은 소프트웨어란?

=> 사용자가 원하는 소프트웨어 + 정상 동작하는 소프트웨어 + 완성도가 높은 소프트웨어

[개발자 관점]  프로그램에 결함이 없고 사용자의 요구를 정의한 요구분석 명세서대로 만든 소프트웨어

# 소프트웨어 품질(Software Quality)

• 제품(Product) 품질
  • 제품 자체가 가지는 품질
  • 완성된 소프트웨어가 운용될 환경에 올려져 최종 시스템이 완성되었을 때, 소비자가 요구하는 바에 얼마나 부합하는지를 나타내는 품질
•  프로세스(Process) 품질
  • 소프트웨어를 개발하기 위해 필요한모든 개발 활동이 계획을 준수하여 개발하였는가를 나타내는 품질
  • 그 활동이 효과적인지에 대해 검토(Review) 및 감사(Audit) 활동을 통해 확인

#   소프트웨어 제품 품질 특정

- 소프트웨어 제품품질이 가져야하는 세부 속성 

- ISO 25010(과거 ISO 9126)에 소프트웨어 품질 특성 정의

• 기능성 : 요구되는 기능을 만족시키는 능력
• 신뢰성 : 규정된 환경에서 결함 없이 의도된 기능 및 작업을 수행하는 능력
• 사용성 : 사용자가 이해하고 배우기 쉬운 정도
• 효율성 : 적절한자원의 사용 및 적정한 반응시간 정도
• 유지보수성 : 소프트웨어의 수정 및 변경의 용이성
• 이식성 : 지원하는 다양한 환경에서 운영될 수 있는 능력
• 상호운영성 : 다른 시스템과의 상호 연동 능력
• 보안성 : 정보 및 데이터를 보호하는 능력
• + 안전성

# 소프트웨어 제품 품질 수준 알기 : V & V

• Verification (검증)
  • 제품이 올바르게 생성되고 있는가? (Are we building the product right?)
  • 소프트웨어가 정확한 요구사항에 부함하여 구현되었음을 보장하는활동
  • 요구사항 명세서에 맞게 올바른 방법으로 제품을 만들고 있음을 보장
  • 완성도가 높은 + 정상 동작하는 제품!!!
• Validation (확인)
  • 올바른 제품을 생성하고 있는가? (Are we building the right product?)
  • 소프트웨어가 고객이 의도한 요구사항에 따라 구현되었음을 보장하는 활동
  • 고객이 의도한 환경이나 사용 목적에 맞게 올바른제품을 만들고 있음을 보장
  • 사용자가 원하는 제품!!!

#   V모델에서의 V & V

- 개발 생명주기의 각 단계와 그에 상응하는 소프트웨어 테스트 단계를 매핑한 모델 : V 모델

- 소프트웨어 개발 프로세스로 폭포수 모델의 확장된 형태 중 하나로, 개발 생명주기의 각 단계와 그에 상응하는 소프트웨어 시험 각 단계의 관계를 나타냄

# 소프트웨어 테스트

- 정상 조건 및 비정상 조근(즉, 결함/버그) 사이의 차이점을 발견하기 위하여 소프트웨어 항목을 분석하고, 분석된 항목의 특성을 평가하는 프로세스

=> 결함의 발견을 목적으로 소프트웨어를 분석하는 활동

# Error, Defect, Failure 용어 정의

1. 에러 (Error) : 결함의 원인으로 사람(SW 개발자, 분석가 등)에 의하여 생성된 실수가 주를 이룸
2. 결합(Defect, Fault), 버그(Bug) : 실패 / 고장 또는 문제의 원인으로 제품에 포함된 결점
3. 실패 / 고장(Failure), 문제(Problem) : 제품의 결함(Defect)이 있는 부분이 실행될때 발생되는 현상

예시...

Input : Distance, Time
Output : Speed = Distance / Time

1. 에러(Error)
Didn't think about the case of <time=0>

2. 결함(Defect, Fault) 
There is no code for handling when <time=0>

3. 실패/고장(Failure)
<Divide by Zero Exception> happened

#  소프트웨어 테스트 종류

1. 정적(Static)인 방법
   1. 소프트웨어를 실행하지 않고 결함을 발견
   2. 여러 참가자들이 모여 소프트웨어를 검토하여 결함을 찾아내거나 정적 검증 도구 이용
   3. 소프트웨어 개발 중에 생성되는 모든 산출물들에 대해서 적용 가능
   4. 프로젝트가 시작할때부터 끝날때까지 수행 가능
   5. 대표적인 방법
      1. 동료 검토(Peer Review)
         1. 인스텍션(Inspection)
         2. 워크스루(Walk-through)
         3. 데스크체크(Desk Check)
      2. 도구를 이용한 정적 분석
         1. 룰 기반 정적분석(PMD, BugFind등)
         2. 의존성 분석
         3. 코드 메트릭 측정  
2. 동적(Dynamic)인 방법(좁은 의미에서의 테스트는 동적 테스트라고도 함)
   1. 소프트웨어를 실행하여 결함을 발견
   2. 발견된 결함은 디버깅 활동으로 확인하여 수정함
   3. 소스코드 만들어진 이후에 수행함!
   4. 대표적인 방법
      1. 테스트
         1. 단위 테스트(Unit Test)
         2. 통합 테스트(Integration Test)
         3. 시스템 테스트(System Test)
         4. 인스 테스트(Acceptance Test)
      2. 테스트
         1. 블랙박스 테스트(명세 기반 테스트)
         2. 화이트박스 테스트(구조 기반 테스트)

# 소프트웨어 테스트 프로세스

- 소프트웨어 테스트를 수행하기 위한 절차/방법, 도구/장비, 인력의 통합

- 테스트 절차 : 테스트 계획 -> 테스트 케이스 설계 -> 테스트 실행 및 측정 -> 테스트 결과 분석 -> 오류 추적 및 추정

- 국제 표준 : ISO/IEC 29119 

- 테스트 활동

• 테스트 계획(Test Planning), 테스트 모니터링 및 제어(Test Monitoring and Control), 테스트 분석(Test Analysis), 테스트 디자인, 테스트 구현, 테스트 실행, 테스트 완료... (다 하지는 않음)

1. 테스트 계획
   1. 테스트 목표를 정의하고 테스트 대상 및 범위를 결정하며, 테스트 계획서를 작성하고 검토
   2. 테스트 계획은 초반에만 하느냐?? 모든 테스트 과정에서 계획이 필요함... 
   3. 소프트웨어 테스트 계획 단계
      1. 입력 : 프로젝트 계획서, 요구분석 명세서
      2. 처리 : 테스트 목표 정의, 테스트 대상 및 범위 결정, 테스트 계획서 작성 및 검토
      3. 결과 : 테스트 요구사항 정의서, 테스트 계획서
2. 테스트 케이스 설계
   1. 테스트 설계 기법을 정의하고, 도출된 테스트 케이스에 입력 값으로 사용 할 원시 데이터를 작성
      1. 소프트웨어 테스트 케이스 설계 단계
         1. 입력 : 테스트 계획서
         2. 처리 : 테스트 설계 기법 정의, 테스트 케이스 도출, 원시 데이터 기반
         3. 결과 : 테스트 케이스 명세서, 테스트 설계서, 테스트 절차서
   2. 테스트 케이스(Test Case)
      
      1. 특정한 요구사항이 제대로 구현되었는지 검증하기 위하여 테스트 조건, 입력 값, 예상 출력 값, 실제 수행한 결과를 기록하는것
   3.  테스트 케이스 작성 시점
      1. 테스트 베이시스(근거 문서)를 작성할때 테스트 케이스 작성
      2. 테스트 케이스 작성을 통해 테스트 베이시스의 품질을 개선

3. 테스트 실행 및 측정

- 테스트 환경을 구축하고 도출된 테스트 케이스를 이용해 테스트를 실시하고 테스트 실행 결과를 문서화

- 실패하는모든 항목에 대해서 결함관리를 수행해야 한다

4.  테스트 결과 분석

- 테스트가 끝나면 계획 대비 결과를 비교 분석하고 테스트 결과에 대한 보고서를 작성

- 입력 : 테스트 계획 단계의 목표 값, 테스트 활동을통해 얻은 결과 값

- 처리 : 테스트 결과 분석, 보고서 작성

- 결과 : 테스트 케이스별 결과 분석서, 소프트웨어 상태 보고서, 테스트 결과 보고서

 5. 오류 추적 및 수정

 - 테스트가 끝나면 계획 대비 결과를 비교 분석하고 테스트 결과에 대한 보고서를 작성

- 입력 : 테스트 결과 보고서, 테스트 케이스별 결과 분석서

- 처리 : 오류 수정 계획, 오류 수정, 수정된 내용 검토

- 결과 : 수정 결과 보고서 

# 테스트 원리

• 테스트는 결함이 존재함을 밝히는 활동
• 완벽한 테스트는 불가능(전수 테스트 불가능)
• 테스트는 개발 초기에 시작
• 결함 집중
• 살충제 패러독스
• 테스트는 정황(Context)에 의존적
• 오류 부재의 궤변  

# 테스트하기 좋은 소스코드 작성 방법

• 메서드는 적정한  크기로 작성
  • LOC 80 라인 이하
• 메서드를 너무 복잡하지 않게 작성
  • 순환 복잡도 10이하 / 인지 복잡도 2-3 권장
  • if(A)는 9개까지. (이 조건문은 CNN1)
• 코드 수정할 때 메서드를 새로 만들 수 있다면, 새로 만들고 Call 해주세요
  • 단위 테스트는 메서드를 대상으로 합니다
• 단일 책임 원칙을 지켜주세요
  • 메서드는 하나의 기능만 수행해야 합니다
• 메서드의 의존을 낮춰주세요
  • 의존이 있는 부분과 없는 부분으로 메서드를 나누는 것이 좋습니다.
• Public, Protected 메서드는 리턴 타입을 명시해주세요
  • 각 접근 지정자의 목적에 맞게 사용해주세요
  • Private도 리턴 타입을 명시하는 것이 좋습니다

# 결함 발생 원인

• Communication : 10명의 사람이 있으면 45개의 Path가 생김
• Short Term memory : 사람이 관리할 수 있는 범위(7digit) / 여러 가지 Interruption이 발생
• Cognitive Dissonance : 자신의 산출물에서 결함을 찾기가 힘듦
• Complexity of work : 설계문서의 복잡성으로 Code 작성이 어려운 경우 발생
• 아무리 능숙한 프로그래머라도 평균적으로 35 Defs/KLoc가 발생함...

# 정적 테스트 단계에서 식별 가능한 결함

• 요구사항 결함 : 불일치, 모호성, 모순, 누락, 부적황성, 중복 등
• 잘못된 인터페이스 명세 : 매개변수의 개수, 유형, 순서 불일치 등
• 설계 결함 : 비효율적인 데이터베이스 구조, 모듈화 불량 등
• 특정유형의 보안 취약성 : 버퍼 오버플로우 등
• 특정 유형의 코딩 결함 : 정의되지 않는 값을 가진 변수 반환 ...등
• 테스트 베이시스 커버리지의 차이 또는 부정확성 : 인수 조건 하나에 대한 테스트 누락 등
• 표준 위반사항 : 코딩 표준 명명규칙을 준수하지 않은 경우 등 

# 정적 분석(Static Analysis)

• 실제 실행 없이 컴퓨터 소프트웨어, 특히 소스코드를 분석하는 것
  • 사용 목적
    • 소스코드의 잠재적인 품질 문제(낮은 품질 발견)
      • 네트워크 지원 누수, 높은 복잡도, 추천하지 않는 패턴등
      • 네트워크 지원 누수  ex) 네트워크 소켓의 open()는 있으나, 명시적인 close()가 없는 경우...
    • 결함의 조기 발견 : 메모리 릭, 버퍼 오버플로우 등
    • 소스코드 표준 준수 확인 : 코딩 컨벤션(명명 규칙), 보안
    • 설계 상의 낮은 품질, 표준 위반 확인 
  • 도구를 이용한 정적 분석
    • 룰 기반 정적분석(PMD, BugFind 등)
    • 의존성 분석
    • 코드 메트릭 측정
    • 시맨틱 분석(실행 오류 분석) 
    • 정형 검증

# 소프트웨어 코딩 표준(표준 코딩 규칙)

- 코딩 규칙(Coding Conventions)은 특정프로그램 언어에 대한 가이드라인 모음(프로그래밍 스타일과 관행을 권고) => Coding Standard

# PMD Rule Set

- 여러 언어를 지원하는 오픈소스 정적코드 분석 도구(룰 셋 개수 총 512개)

- 지원 언어 : Java, JavaScript, Python, C++, HTML, PLSQL, Apex, Swift, Kotlin, Scala, PHP 등..

https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html 

# Eclipse에 pmd 설치

# 제품 품질 메트릭

• 규모 관련
  • 라인 수(LOC : Line of Code)
  • 주석 제외 라인 수(NLOC : Non-Comment Lines of Code)
  • 주석 비율 : 20% 이상
  • 함수/파일/패키지 별 라인수 (미국방부 : 80 / NASA : 60 / 폭스바겐 : 50)
• 복잡도 관련
  • 순환 복잡도(Cyclomatic Complexity) : 함수의 제어 흐름이 얼마나 복잡한지 측정. 분기문 + 1
  • 인지 복잡도(Cognitive Complexity) : 함수가 얼마나 중첩문이 많은지 측정, Nesting Depth라고도 표현

# 동료검토

• 동료에게 원시 코드나 여러 가지 산출물에 대한 검토를 의뢰하여 오류를 찾는 방법
  • 정해진 형식도 없고 별도의 격식을 차린 회의를 수행할 필요가 없어 비공식 검토에 속함
  • 동적 테스트에서 발견하기 어려운 산출물에서 발생할 수 있는 누락과 같은 결함을 조기에 발견할 수 있는 이점
  • CMMI에서는 결함을 발견하기 위해 프로젝트를 하는 과정에서 동료가 검통하는 활동이라고 정의함.. 
• 체크리스트를 통해 검토를 진행해야 함
  • 사전 준비 : 공지, 검토자 지정, 배포, 준비
  • 검토 회의 : 문제점해결, 보고서 작성
  • 후속 조치 : 시정조치, 조치 보고  

#  효율적인 체크리스트를 작성 방법

• 체크리스트는 결함 분석에 기초해서 정기적으로 갱신되어야 합니다
• 체크리스트는 한 페이지보다 길지 않아야 합니다
• 체크리스트 아이템은 명령문으로 재 표현될 수 있는 질문의 형태로 표현합니다 
  • 메소드 리턴 값은 적절하게 명시하였는가?
• 체크리스트 아이템은 너무 일반적이지 않아야 합니다
  • 완전하고 일관성 있고 명백한가? (모호하게 작성하지 않아야 함)

# 소스콬드 동료검토 주의 사항

• Review fewer than 200 ~ 400 lines of code at a time 
  • 한번에 200 ~ 400 라인 이내의 단위로 검토
• Aim for an inspection rate of less than 300 ~ 500 LOC/hour
  • 1시간에 300 ~ 500 라인 보다 적게 본다는 느낌으로 검토 / 너무 빨리 검토하는 것은 안 좋음
• Authors should annotate source code before the review begins
  • 검토를 요청하는 개발자는 다른 사람에게 어떤 내용인지 설명을 해주는 것이 좋음
• Establish quantifiable goals for code review and capture metrics so you can imporve tour processes
  • 목적의식을 갖는 것이 중요합니다. 예를 들어 에러율을 현재보다 50% 줄이겠다는 등의 명확한 수치를 설정하면 이를 위해 노력하게 됩니다.
• Managers must foster a good code review culture in which finding defects is viewed positively
  • 관리자들은 검토활동이 잘 되고 있는지 관찰하고, 이를 장려하는 조직문화를 만들어 줘야 합니다
• 동료 검토를 하지 않는다고 하더라도 남이 본다고 생각하고 작성하기!
• Beware the "Big Brother" effect
  • 동료가 자신의 코드에 오류를 많이 발견한다고 해서 너무 기죽지 마세요. 품질을위한 하나의 과정이 뿐이지 누구를 모욕하거나 비하하는 자리가 아닙니다   

# 인스텍션의 주요 특징

• 전문가검토이며 공식적 평가
  • 시작과 종료 조건을 갖는 체크리스트와 규칙을 기반으로 정식 프로세스가 존재
  • 검토할 산출물의 작성자가 아닌 훈련된 진행자에 의한 진행
  • 소프트웨어 구성 요소 혹은 산출물들의 정확성 평가
• 결함 발견이 주요 목적
  • 소프트웨어가 명세를 만족하는지 검증
  • 소프트웨어가 명시된 품질 속성을 만족하는지 검증
  • 소프트웨어가 어플리케이션 규격, 표준, 가이드라인, 계획 및 프로시저와 일치하는지 검증
  • 표준이나 규격과 상이한 부분 식별

# 회귀 테스트(Regression Test)

• 정상 동작하던 기능이 SW 수정 후 문제가 발생하는 회귀 결함의 유무를 확인하기 위해 이전 테스트 케이스를 다시 실행하며 확인하는 테스트 
  • SW 수정으로 인한 부정적인 영향 유무를 확인하기 위한 테스트
• 회귀 결함을 발생시키는 SW 수정의 종류
  • 새로운 결함의 조치
  • 리팩토링
  • 새로운 기능의 추가/변경
• 웹은 필수는 아니지만 결함의 확인이 중요한 임베디드(차량)의 경우는 필수적임.. 

# SW 동적 테스팅의 4단계

1. 단위(Unit) 테스팅
2. 통합(Integration) 테스팅
3. 시스템(System) 테스팅
4. 인수(Acceptance) 테스팅

# 단위 테스팅(Unit Testiong) / 컴포넌트 테스팅(Component Testing)

• 설계된 모듈이 정확히 구현되었는지 확인하고, 모듈과 같은 하나의 소프트웨어 구성요소나 소프트웨어 구성요소의 집합이 프로그램의 요구사항에 맞는지 확인하는 테스팅
• 목적 : 모듈이 올바로 코딩 되었는지 확인
• 수행주체 : 개발자
• 테스트 대상 : 모듈 수행가능(블랙박스), 코드 내부표현(화이트박스), 경계조건
• 완료시점 : 개발자가 더 이상의 오류가 없다고 판단될 때

# 단위 테스트 결함 원인 한정

- 단위 테스트에서 결함이 발생한다면, 그 원인은 테스트 대상 모듈에 한정해야 함

# 통합 테스팅(Integration Testing)

- 시스템의 설계와 요구사항에 부합하는지 보이기 위해 소프트웨어 구성요소, 하드웨어 구성요소 등이 점차 통합되어 전체 시스템으로 통합될 때까지 이루어지는 절차적인 테스팅

# 소프트웨어 통합 전략과 연계

• SW 통합 전략
  • 빅뱅(Big Bang) 기법
    • 모듈을 한꺼번에 통합하여 테스팅을 하는 방법
    • 오류가 발생하였을 경우 어느 부분에서 오류가 났는지 찾기가 힘듦 
  • 하향식(Top-Down) 기법
    • 가장 상위 모듈부터 하위 모듈로 점진적으로 통합하는 방법
    • 상위 모듈 테스팅 시, 하위 모듈에 대한 스템이 필요
  • 상향식(Bottom-Up) 기법
    • 하위 모듈부터 테스팅하고 상위 모듈로 점진적으로 통합하는 방법
    • 하위 모듈 테스팅
  • 지속적 통합 방법(Continuous Integration)
    • SW 통합 오류를 개발초기부터 예방하는 것 

# 시스템 테스팅(System Testing)

• 모듈이 모두 통합된 후, 사용자의 요구사항이 만족되었는지 검사하는 테스팅
• 고객에게 시스템을 전달하기 전, 시스템을 개발한 조직이 주체가 되는 마지막 테스팅
• 테스팅 대상
  • 요구사항 명세서를 기초로 하여 사용자의 기능 요구사항
  • 보안, 성능, 신뢰성, UX 등의 비 기능 요구사항
  • 기능 안전 요구사항

# 인수 테스팅(Acceptance Testing)

• 시스템이 사용자에게 인수되기 전, 사용자에 의해 실시되는 테스팅
• 실제 사용자가 운영하는 환경에서 실시
• 인수 테스팅을 통과해야만 시스템이 정상적으로 사용자에게 인수되고 프로젝트는 종료됨

# 동적 SW 테스트 설계 기법의 종류 (+ 경험 기반 Test)

• 명세 기반 테스트(Black-Box)
  • 소스 코드 자체의 로직(Logic)은 제외하고, 출력 값에만 초점을 두고 테스팅 하는 방법
  • 요구사항 명세서(SRS)나 설계서로부터 테스트 케이스 추출
    • 블랙박스 테스트
    • 모듈의 외부(입력, 출력)
• 구조 기반 테스트(White-Box)
  • 소스 코드 내의 모든 독립적인 경로를 수행하여 봄으로써 잠재적인 오류를 찾아내는 방법
  • 내부구조(소스 코드, 알고리즘)를 기반으로 테스트 케이스 추출 -> 주로 단위테스트에서 쓰임
    • 화이트 박스 테스트
    • 모듈의 내부(로직)

#  블랙박스(Black Box) 테스팅 개요

- 소스 코드 자체의 로직은 제외하고, 출력 값에만 초점을 두고 테스팅 하는 방법으로 요구사항 명세서나 설계서로부터 테스트 케이스 추출

• 테스팅 종류
  • 구문 테스팅(Syntax Testing) : 입력 값을 적합과 부적합 조건으로 분류한 뒤, 테스트 케이스를 작성하여 예상되는 결과를 테스팅
  • 페어와이즈(Pairwise) : 테스트를 하는데 필요한 각 입력 값들이 다른 입력값과 최소한 한번씩 조합을 이루게 하여 테스트 하는 방법 / 페어 : 입력값의 각 쌍의 개별 조합
  • 동등 분할(Equivalence Partitioning) : 입력 값의 범위가 정해져 있을 경우, 각 범위의 대푯값으로 테스트 케이스를 작성하여 예상되는 결과를 테스팅
  • 경계 값 분석(Boundary Value Analysis) : 입력 값의 주요 오류 대상인 경계 값을 입력 값으로 테스트 케이스를 작성하여 예상되는 결과를 테스팅 
  • 의사결정 테이블(Devision Table) : 입/출력값이 True, False로 결정될 수 있는 경우, 입/출력값의 모든 논리적 경우의 수를 확인해볼 수 있는 방법

# 페어와이즈 도구 실습

https://github.com/microsoft/pict/releases/tag/v3.7.4

- 페어와이즈는 cmd 창에서 실행!!(데이터가 뽑아져 나온다)

- 일단 케이스의 경우를 txt 파일에 적어줌

pict 파일명 > 만들고 싶은 파일명.xls  => 테스트 케이스를 엑셀로 가져가줌!!

# 화이트박스(White Box) 테스팅 개요

•  소스 코드 내 모든 독립적인 경로를 수행하여 봄으로써 결함을 찾아내는 방법으로 프로그램 소스 코드로부터 테스트 케이스를 추출
  
  

# 테스트 커버리지(Coverage)

• 테스트 케이스 수행 시 텟트 대상을 몇 %나 실행했는지 알려주는 지표
• 요구사항커버리지
  • 테스트 케이스가 요구사항을 얼마만큼 실행했는지 측정
    • ex) 전체 30개 요구사항 중, 50% 요구사항을테스트 수행
  • 블랙박스 테스트 기법에 주로 사용
• 소스코드 커버리지
  • 테스트 케이스가 소스코드를 얼마만큼 실행했는지 측정
    • 예1) 문장 커버리지 : 소스코드 전체 문장의 40% 문장을 테스트 수행
    • 예2) 결정 커버리지 : 소스코드 전체 if 문의 60%의 참/거짓(결정)을 테스트 수행
  • 화이트박스 테스트 기법에 주로 사용

#   화이트박스 테스팅 종류

• 경로 커버리지(Basis Path Coverage)
  
  • 프로그램 제어구조를 Flow Graph로 표현하고, 순환 복잡도(Cyclomatic Complexity)를 통해 독립적인 경로의 수를 찾아 테스트 케이스로 선정하여 수행하는 테스팅
  • 경로 커버리지 수행 프로세스
    • 1. Flow Graph 작성
    • 2, 순환 복잡도 계산
    • 3. 독립 경로 정의
    • 4. 테스트 케이스 작성
  • 입력에서 출력에 이르기까지의 프로그램 내부구조를 플로우 그래프로 표현
• 함수 커버리지(Function Coverage)
  • 프로그램을 구성하는 함수들의 테스팅 정도를 나타내며 가장 낮은 수준의 커버리지이므로  단위 테스팅을 통해 100% 달성이 필요함
  • 웹에서는 거의 쓸 일이 없음.. 함수를 불러오는거지 그 안의 알고리즘을 보지는 않기 때문에
  • 임베디드에서 모든 모듈을 다 호출했는지, 통합했는지 확인하기 위해서 사용함 
• 문장 커버리지(Line Coverage)
  • 프로그램을 구성하는 문장들이 최소한 한번은 실행될 수 있는 입력 값을 테스트 케이스로 선정하여 수행하는 테스 
  • 문장 커버리지의 단점
    • 소스코드의 로직(Logic)에 영향을 미치는 조건문을 테스트하지 못함
    • 조건문 자체의 결정(Decision이 True/False 인 경우 -> 결정(Decision) 커버리지 적용
    • 조건문의 각 조건(Condition)이 True/False 인 경우 -> 조건(Condition) 커버리지 적용
• 분기 커버리지(Branch Coverage)
  • 분기문 전체가 참 한 번, 거짓 한 번을 갖도록 테스트 케이스를 선정하여 수행하는 테스팅 방법으로 결정(Decision) 커버리지라고도 함 

# Junit 소개와 기본 테스트 구조

• 에릭 감마와 켄트백이 탄생시켜 현재 전 세계적으로 널리 사용되는 Java 단위 테스트 프레임워크
• 기본 테스트구조 : assertEquals() 사용 예제
  • assertEquals(Expected, Actual) : Expected(Object)와 Actual(Object)의 객체 타입 및 값이 동일한지 확인하여 같으면 테스트가 성공함
    
    

# 단위테스트(메서드 단위) 수행 방법 요약

• 테스트 단위
  • public 메서드, API 메서드 등메서드 단위
  • 인터페이스를 구현한 메서드에서 시작
•   테스트 방법
  • JUnit을 활용한 테스트 메서드를 작성하여 특정 메서드의 기능이 정상 동작함을 확인
• 테스트 절차
  • 기능 구현 -> 테스트 케이스 생성 -< 단위테스트 수정 -> 커버리지 측정 -> 리포트 출력
  • 기능 구현과 테스트를 병행하며 점진적 개발 수행
  • 필요시 커버리지 측정 후 테스트가 미흡한 코드에 대해서는 테스트 보완 가능

# JUnit5 실습

package com.calc;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

class CalculatorTest {
	
	Calculator calculator = new Calculator();

	@Test
	void testAdd() {
//		assertEquals(기대결과, add());
		assertEquals(6, calculator.add(4, 2));
//		System.out.println(assertEquals(6, calculator.add(4, 2)));
	}
	
	@Test
	void testMinus() {
		assertEquals(2, calculator.minus(4, 2));
	}

	@Test
	void testMulti() {
		assertEquals(8, calculator.multi(4, 2));
	}

	@Test
	void testDivide() throws Exception {
		assertEquals(2, calculator.divide(4, 2));
		assertThrows(Exception.class, () -> 
			calculator.divide(4, 0), "Divide Error"
		);
	}
	
	@Test
    void testCalculate() throws Exception {
        assertEquals(6, calculator.calculate("+", 4, 2)); 
        assertEquals(2, calculator.calculate("-", 4, 2));
        assertEquals(8, calculator.calculate("*", 4, 2)); 
        assertEquals(2, calculator.calculate("/", 4, 2)); 
//        assertEquals(0.5, calculator.calculate("/", 2, 4)); 
    }
	
	// 테스트 케이스는 독립적인 기능을 하도록 모듈을 개발해야하는데.. 하나의 목적을 가지는게 좋아서 정상적으로 수행되지 않는 경우를 빼주는 것을 더욱 추천!
    @Test
    void testUnsupportedOperator() {
        assertThrows(Exception.class, () -> 
            calculator.calculate("%", 4, 2), "Unsupported Operator"
        );
    }
	
	/**
	@Test
	void testParseInput() {
		fail("Not yet implemented");
	}

	@Test
	void testMain() {
		fail("Not yet implemented");
	}
	**/
}

# 테스트 실행 걸차

# 결함 관리 기법

• 결함 감소(Reduction) : 주입된 결함을 가능한 많이 발견하고 제거함
• 결합 봉쇄(Containment) : 결함이 발견되지 않고 그 결함으로 인해 문제가 생겨도 그것이 실패로 이어지지 않게 함
• 결함 예방(Prevention) : 결함을 예측하고 그 원인을 파악하여 방지 및 해결함
• 결함 예방 활동이 제대로 이루어 진다면? => 결함 감소와 봉쇄에 들이는 노력과 비용 감소 가능

# 소프트웨어 결함의 특징

• 소프트웨어 개발은 인력 절약적 작업으로 소프트웨어 결함의 대부분은개발자의 휴먼 에러로 인해 발생
  • 구현 단계의 결함도 휴먼 에러로 인해 발생
  • 휴먼 에러 예방을 통해 구현 단계 결함의 잔존을 방지할 필요가 있음
  • 결함 관리 단계에서 충분한 데이터를 수집해야 함!!

# 결함 예방을 위한 데이터 수집

• 결함 유형 
  • 결함 발견자 입장에서 결함의 모습 : 테스트 단계마다 결함 유형이 달라질 수 있음
• 결함 원인 
  • 결함 제거자(개발자) 입장에서 결함 원인 : 테스트 단계 결함 유형이 달라질 수 있음
• 결함 유입 단계 
  • 결함이 포함된 단계
• 결함 발견 단계 
  • 테스트/리뷰 단계
• 기타 
  • OS, 테스트 환경, 테스트 ID

# 결함의 추적

• 개발자는 소프트웨어를 개발 후 테스터에게 전달
• 테스터는 테스트 계획, 분석 및 설계 방법에 따라 테스트 케이스를 생성하고 실행
• 테스트 케이스 실행 중 결함을 검출하고 검출된 결함을 개발자에게 전달 및 수정 요청
• 개발자는 결함을 수정하고 다시 테스터에게 전달

# 결함 처리 유형

• Fixed : 요청된 결함을 수정 완료한 경우
• Duplicated : 기존의 다른 결함과 중복되는 경우
• Won't fix : 수정이 필요할 정도로 중요하거나 긴급한 것이 아니라 수정하지 않는 경우
• Invalid : 테스트 케이스에 문제가 있는 경우

문제 😵‍💫

https://school.programmers.co.kr/learn/courses/30/lessons/12909?language=java

내 풀🦷

import java.util.*;

class Solution {
    boolean solution(String s) {
        Stack<String> str = new Stack<>();
        boolean answer = true;
        
        for(int i = 0; i < s.length(); i++) {
            char c = s.charAt(i);
            
            if(c == '(') {
                str.push(String.valueOf(c));
            } else if(c ==')') {
                if(str.isEmpty()) {
                    answer = false;
                    break;
                }
                str.pop();
            }
        }
        
        if (!str.isEmpty()) {
            answer = false;
        }
        return answer;
    }
}

정말정말 오랜만에 괄호 검사 문제를 풀었다 ㅎㅎㅎ

진짜 괄호 검사 추억이 많은 문제라 너무 기억나는데 파이썬 했던시절이라 잠시 흠칫했다 ㅎㅎㅎㅎ

당연히 스택 써서 풀어야 겠다 했는데 다른 사람 풀이가 스택도 쓰지 않고 정말 간단하게 썼던 풀이가 있어서 한번 가져와 봤다...

// 다른 사람 풀이

class Solution {
    boolean solution(String s) {
        boolean answer = false;
        int count = 0;
        for(int i = 0; i<s.length();i++){
            if(s.charAt(i) == '('){
                count++;
            }
            if(s.charAt(i) == ')'){
                count--;
            }
            if(count < 0){
                break;
            }
        }
        if(count == 0){
            answer = true;
        }

        return answer;
    }
}

참고하면 좋을 개념들 ✍️

스트링으로 변환 : String.valueOf(바꿀 값);

MariaDB 볼 때 사용하는 tool이 너무 느렸는데요...

VS CODE에서 연동해서 보기 좋게 볼 수 있다더라구요!!

엄청 쉽습니다!!!!

- 일단 Database Client를 깔아줍니다!!

- 왼쪽바에서 데이터베이스 모양을 누르고 + 버튼을 눌러서  Server Type을 선택하고 host, username, 비밀번호를 입력하고 마지막 Connect를 누르면 완료!!!

- 실행은 해당 줄 [ Ctrl ] + [ L ]로 선택해서 [ Ctrl ] + [ Enter ] 선택하면 실행되면서 테이블이 생깁니다!!

UI도 보기 편하고 빨라서 완전 추천드려요!