자바 6주차(소프트웨어 공학 주간)

# 아키텍처(Architecture)

 

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

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

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

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

 

 

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

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

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

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

ISO/IEC 25010의 품질 속성 예시

 

 

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

• 가용성(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 모델

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

인수 테스팅 : Validation / 시스템, 통합, 단위 : Verification

 

 

# 소프트웨어 테스트

 

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

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

 

 

# 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 

javadoc

 

 

# Eclipse에 pmd 설치

[help] -> [marketplace]에서 pmd로고 있는걸로 설치하기!

 

pmd 검사

 

pmd 검사 확인기록 남기기

 

 

pmd 수정 코드 추천(추천 코드를 굳이 쓸 필요 x

 

 

# 제품 품질 메트릭

• 규모 관련
  • 라인 수(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

Release Version 3.7.4 · microsoft/pict

 

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

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

 

? 나오는거는 인코딩 UTF-8 -> ANSI로 바꾸면 해결된다!!

 

 

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 실습

 

JUnit이 없다면 추가먼저 해주기

 

알아서 만들어줌!

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 : 테스트 케이스에 문제가 있는 경우