1. 애플리케이션 테스트케이스 설계

1.1 소프트웨어 테스트

1.1.1 소프트웨어 테스트의 개념

• 구현된 소프트웨어에서, 사용자가 요구하는 기능의 동작과 성능, 사용성, 안정성 등을 만족하기 위하여 소프트웨어의 결함을 찾아내는 활동
• 노출되지 않은 숨어있는 결함(Fault)을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차
• 오류 발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정
• 개발된 소프트웨어의 결함과 문제를 식별하고 품질을 평가하며 품질을 개선하기 위한 일련의 활동

1.1.2 소프트웨어 테스트의 필요성⭐

• 오류 발견 관점
• 오류 예방 관점
• 품질 향상 관점

1.1.3 소프트웨어 테스트의 기본 원칙 : 결완초집 살정오⭐

• 테스팅은 결함이 존재함을 밝히는 활동이다.
• 완벽한 테스팅은 불가능하다.
• 테스팅은 개발 초기에 시작해야 한다.
• 결함 집중(Defect Clustering)⭐
  • 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다.
  • 파레토 법칙 : 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상⭐
• 살충제 패러독스(Presticide Paradox)⭐
  • 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고개선해야 한다.
• 테스팅은 정황(Context)에 의존한다.
  • 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행하여야 한다.
• 오류-부재의 궤변(Absence of Errors Fallacy)⭐
  • 사용자의 요구사항을 만족하지 못하는 오류를 발견하고 그 오류를 제거하였다 해도, 해당 애플리케이션의품질이 높다고 말할 수 없다

1.1.4 테스트 프로세스

• 테스트 계획
• 테스트 분석 및 디자인
• 테스트 케이스 및 시나리오작성
• 테스트 수행
• 테스트 결과 평가 및 리포팅

1.1.5 테스트 산출물⭐

• 테스트 계획서
  • 테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행 절차, 테스트 일정, 조직의 역할 및 책임 정의, 종료 조건 정의 등 테스트 수행을 계획한 문서
• 테스트 케이스
  • 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력 값, 테스트 조건, 기대 결과로 구성된 테스트 항목의 명세서
  • 케이스를 작은 단위로 나누어 각 단위의 입력 값, 테스트 조건, 기대 결과를 기술한다.⭐
• 테스트 시나리오
  • 테스트를 위한 절차를 명세한 문서
  • 테스트 수행을 위한 여러 개의 테스트 케이스의 집합으로 테스트 케이스의 동작 순서를 기술한 문서
• 테스트 결과서
  • 테스트 결과를 정리한 문서
  • 테스트 프로세스를 리뷰하고, 테스트 결과를 평가하고 리포팅하는 문서

1.2 테스트 오라클

1.2.1 테스트 오라클의 개념⭐

• 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법 및 활동

1.2.2 테스트 오라클의 유형 : 참샘휴일⭐

• 참 오라클 (True)
  • 모든 입력 값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클
  • 항공기, 임베디드, 발전소 소프트웨어 등 크리티컬한 업무
• 샘플링 오라클 (Sampling)
  • 특정한 몇 개의 입력 값에 대해서만 기대하는 결과를 제공해 주는 오라클
  • 일반, 업무용, 게임, 오락등의 일반적인 업무
• 휴리스틱 오라클 (Heuristic)
  • 샘플링 오라클을 개선한 오라클로, 특정 입력 값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클
• 일관성 검사 오라클 (Consistent) : 애플리케이션 변경이 있을 때, 수행 전과 후의 결과 값이 동일한지 확인하는 오라클

1.3 테스트 레벨 : 단통시인⭐

1.3.1 단위 테스트

• 소프트웨어 개발에서 테스트 프로세스의 첫 단계
• 에러를 줄이기 위한 의도로 작성된 코드에 대한 분석을 진행
• 코드가 효율적으로 작성되었는지, 프로젝트 내에 합의된 코딩 표준을 준수하고 있는지도 검증
• 모듈 설계 단계에서 준비된 테스트 케이스를 이용하며, 코드를 개발한 개발자가 직접 수행

1.3.2 통합 테스트

• 각각의 모듈들을 통합하여, 통합된 컴포넌트 간의 인터페이스와 상호작용 과정의 오류를 발견하는 작업을수행
• 코드를 직접 확인하는 형태가 아닌 프로그램을 실행하며 테스트를 진행
• 설계 단계에서 준비된 테스트 케이스를 사용하여 테스트가 진행되며, 일반적으로 개발자가 진행

1.3.3 시스템 테스트

• 실제 구현된 시스템과 계획된 사양(specifications)을 서로 비교하는 작업
• 단위, 통합 테스트 후 전체 시스템이 정상적으로 작동하는지 확인
• 시스템 테스트 유형⭐

1.3.4 인수 테스트

• 시스템을 배포하거나 실제 사용할만한 준비가 되었는지에 대해 평가
• 사용자가 요구분석 명세서에 명시된 사항을 모두 충족하는지 판정하고, 시스템이 예상대로 동작하고 있는지를판정하는 방안을 파악
• 인수 테스트 유형⭐

1.4 소프트웨어 테스트 기법

1.4.1 프로그램 실행 여부

• 정적 테스트
  • 소프트웨어의 실행 없이 소스 코드의 구조를 분석하여 논리적으로 검증하는 테스트
  • 경로 분석, 제어 흐름 분석, 데이터 흐름 분석 등을 수행
• 동적 테스트
  • 소프트웨어를 실행 하여 실제 발생하는 오류를 발견하여 문제를 해결하는 분석 기법
  • 다양한 운영 환경에서 소프트웨어를 분석

1.4.2 테스트 기법

(1) 화이트박스 테스트 : 문선경조⭐

문선이 경조사

• 소프트웨어의 내부 구조와 동작을 검사하는 테스트 방식
• 소프트웨어 내부 소스코드를 테스트 하는 기법
• 개발자가 내부 소스코드 동작을 추적하여, 동작의 유효성과 코드를 꼼꼼하게 테스트 할 수 있다.
• 개발자 관점의 단위 테스트 방법
• 화이트박스 테스트 기법 : 문선경조 (문선황후 경조사)

(1-1) 기초 경로 검사 (Basic Path Test) : 브에노이⭐

• McCabe가 제안한 것으로 대표적인 화이트박스 테스트 기법

• 계산식 : V(G)=E-N+2 (e.g. 6 - 4 + 2 = 4)

  • E(엣지) - 선, N(노드) - 동그라미

• 또는 비어있는 공간(사이클) + 1로 외우기 (e.g. 3+1)

(2) 블랙박스 테스트 : 경비동원 오류 ⭐

• 프로그램의 외부 사용자 요구사항 명세를 보면서 테스트, 주로 구현된 기능을 테스트
• 사용자가 소프트웨어에 요구하는 사항과 결과물이 일치하는지 확인
• 사용자 관점의 테스트 방법
• 블랙박스 테스트 기법 : 경비동원 오류 ⭐
  • 경비병을 동원하는 오류

1.4.3 테스트에 대한 시각⭐

• 검증(Verification, 벌리피케이션)
  • 소프트웨어의 개발 과정을 테스트
  • 올바른 소프트웨어가 만들어지고 있는지 검증
• 확인(Validation, 밸리데이션)
  • 완성된 소프트웨어의 결과를 테스트
  • 완성된 소프트웨어가 정상적으로 동작하는지 확인 Ÿ 완성된 소프트웨어가 사용자의 요구사항을 만족하는지 확인

1.4.4 테스트 목적 : 회안성 구회병⭐

• 회귀(Regression) 테스트 회귀(한바퀴 돌아 제자리로 오다)
  • 변경 또는 수정된 코드에 대하여 새로운 결함 발견 여부를 평가하는 테스트
• 안전(Security) 테스트
  • 불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스코드 내의 보안적인 결함을 미리 점검하는 테스트
• 성능(Performance) 테스트
  • 사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는속도 등을 테스트
• 구조(Structure) 테스트
  • 시스템의 내부 논리 경로, 소스코드의 복잡도를 평가하는 테스트
• 회복(Recovery) 테스트
  • 시스템에 고의로 실패를 유도하고 시스템이 정상적으로 복귀하는지 테스트
• 병행(Parallel) 테스트
  • 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트
• 강도(Stress) 테스트
  • 시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정상적으로 작동되는지를 검증하는 테스트

1.4.5 테스트 종류 : 명구경⭐

명나라 구경

• 명세 기반 테스트
  • 주어진 명세를 빠짐없이 테스트 케이스로 구현하고 있는지 확인하는 테스트
  • 동등 분할, 경계 값 분석, 유한상태 기계기반, 결정 테이블, 정형명세 기반, 유스케이스, 페어와이즈, 직교배열테스트 등
• 구조 기반 테스트
  • 소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
  • 구문 기반, 결정 기반, 조건 기반, 조건결정 기반, 변경조건 결정 기반, 멀티조건 기반 커버리지 테스트 등
• 경험 기반 테스트
  • 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한, 직관과 기술 능력을 기반으로 수행하는 테스트

1.5 테스트 커버리지

1.5.1 테스트 커버리지의 개념⭐

• 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준
• 테스트의 정확성과 신뢰성을 향상시키는 역할
• 테스트를 얼마나 수행했는지 측정하는 기준

1.5.2 테스트 커버리지 유형

(1) 기능 기반 커버리지

• 테스트 대상 애플리케이션의 전체 기능을 모수로 설정하고, 실제 테스트가 수행된 기능의 수를 측정하는 방법
• 기능 기반 테스트 커버리지는 100% 달성을 목표로 하며, 일반적으로 UI가 많은 시스템의 경우 화면 수를 모수로 사용할 수도 있다.

(2) 라인 커버리지(Line Coverage)

• 애플리케이션 전체 소스 코드의 Line 수를 모수로 테스트 시나리오가 수행한 소스 코드의 Line 수를 측정하는 방법
• 단위 테스트에서는 이 라인 커버리지를 척도로 삼기도 한다.

(3) 코드 커버리지(Code Coverage) : 구결조조 변다⭐

• 소프트웨어 테스트 충분성 지표 중 하나로 소스 코드의 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트되었는지를 측정하는 방법
• 구문 커버리지(Statement) : 코드 구조 내의 모든 구문에 대해 한 번 이상 수행하는 테스트 커버리지를 말한다.⭐

1
void func(int x) {
2
    printf("start"); // 1번
3
    if (x > 0) { // 2번
4
        printf("process"); // 3번
5
    }
6
    printf("end"); // 4번
7
}
8
// x의 값이 -1일 때, 3번은 수행되지 않는다. // 따라서 ( 3 / 4 ) * 100 = 75%

• 조건 커버리지(Condition) : 결정 포인트 내의 모든 개별 조건식에 대해 수행하는 테스트 커버리지를 말한다.⭐
  • 개별 조건식이 각각, True와 False 만 만족하면 된다.
  • 개별 조건식의 T/F 는 커버되지만 전체 결정포인트의 T/F는 보장 받지 못한다.
  • 조건 커버리지를 만족하기 위해서는 ( x=10, y=10 ), ( x=-1, y=-1 )을 넣으면 만족한다.

• 결정 커버리지(Decision) : 결정 포인트 내의 모든 분기문에 대해 수행하는 테스트 커버리지를 말한다.⭐
  • 결정포인트가 각각, True와 False 만 만족하면 된다.
  • 개별 조건식에서 오류가 있는 경우 찾지 못할 수 있다

• 조건/결정 커버리지(Condition/Decision) : 결정포인트 T/F, 개별조건식 T/F를 가져야 한다

• 변경 조건/결정 커버리지(Modified Condition, Decision)
  • 모든 결정 포인트 내의 개별 조건식은 적어도 한번 T, F를 가져야 한다.
  • 이론적으로 가장 안전한 조합이며 케이스도 줄일 수 있다.

• 다중 조건 커버리지(Multiple Condition) : 결정 포인트 내 모든 개별 조건식의 가능한 조합을 100% 보장해야 한다.

2. 애플리케이션 통합 테스트

2.1 결함관리 도구

2.1.1 결함관리 도구의 개념

• 각 단계별 테스트 수행 후 발생한 결함의 재발 방지를 위해, 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리할 수 있게 해주는 도구

2.1.2 결함관리 프로세스

• 에러 발견 → 에러 등록 → 에러 분석 → 결함 확정 → 결함 할당 → 결함 조치 → 결함 조치 검토 및 승인

2.1.3 결함 추이 분석

• 결함 추이 분석
  • 테스트 완료 후 발견된 결함의 결함 관리 측정 지표의 속성 값들을 분석하고, 향후 애플리케이션의 어떤 모듈 또는 컴포넌트에서 결함이 발생할지를 추정하는 작업
• 결함 관리 측정 지표 : 분추에이 (분노 추적 에이)⭐
  • 결함 분포 : 각 애플리케이션 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수를 측정하여 결함의 분포를 분석할 수 있다.
  • 결함 추세 : 테스트 진행 시간의 흐름에 따른 결함의 수를 측정하여 결함 추세를 분석할 수 있다.
  • 결함 에이징 : 등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정하여 분석할 수 있다.

2.1.4 결함의 식별

• 단계별 결함 유입 분류
  • 기획시 유입되는 결함
  • 설계 시 유입되는 결함
  • 코딩 시 유입되는 결함
  • 테스트 부족으로 유입되는 결함
• 결함 심각도별 분류
  • 치명적 결함(Critical)
  • 주요 결함(Major)
  • 보통 결함(Normal)
  • 낮은 결함(Low, Minor)
• 결함 우선 순위
  • 결정적(Critical) : 24시간 안에 즉시 수정, 전체 기능이 동작하지 않고, 더 이상 테스트도 진행할 수 없다.
  • 높음(High) : 일반적인 결함으로 인해 하나의 기능을 사용할 수 없다.
  • 보통(Medium) : 어떤 기능이 기대치에 못 미칠 경우
  • 낮음(Low) : 종료 기준에 따라 수정하지 않아도 되는 경우

2.1.5 결함 관리 항목

• 결함 내용, 결함 ID, 결함 유형, 발견일, 심각도, 우선순위, 시정 조치 예정일, 수정 담당자, 재테스트 결과, 종료일

2.1.6 결함 관리 도구 종류

• S/W 테스트 관리 : TestLink, GanttProject, OpenProj, Redmine
• 결함 추적 관리 : Mantis, Bugzilla, Trac

2.2 테스트 자동화 도구

2.2.1 테스트 자동화 도구의 개념

• 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현 함으로써,
• 테스트 시간 단축과 인력투입 비용을 최소화하는 한편, 쉽고 효율적인 테스트를 수행할 수 있는 방법

2.2.2 테스트 자동화 도구의 장/단점

• 장점
  • 반복되는 테스트 데이터 재입력 작업의 자동화
  • 사용자 요구 기능의 일관성 검증에 유리
  • 테스트 결과 값에 대한 객관적인 평가 기준 제공
  • 테스트 결과의 통계 작업과 그래프 등 다양한 표시 형태 제공
  • UI가 없는 서비스의 경우에도 정밀한 테스트 가능
• 단점
  • 도구 도입 후 도구 사용 방법에 대한 교육 및 학습이 필요
  • 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력이 필요
  • 상용 도구의 경우 고가, 유지 관리 비용이 높아 추가 투자가 필요

2.2.3 테스트 자동화 도구 유형

• 정적 분석 도구(Static Analysis Tools)
  • 정적 분석 도구는 만들어진 애플리케이션을 실행하지 않고 분석하는 방법
  • 대부분의 경우 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함을 발견하기 위하여 사용
  • 테스트를 수행하는 사람이 작성된 소스 코드에 대한 이해를 바탕으로 도구를 이용해서 분석하는 것
  • 종류 : pmd, SonarQube, cppcheck, checkstyle 등⭐
• 테스트 실행 도구(Test Execution Tools)
  • 테스트를 위해 작성된 스크립트를 실행
  • 작성된 스크립트는 각 스크립트마다 특정 데이터와 테스트 수행 방법을 포함
  • 테스트 실행 도구 방식 (데이터 주도 접근 방식, 키워드 주도 접근 방식)
• 성능 테스트 도구(Performance Test Tools)
  • 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를 수행함으로써 성능 목표를 달성하였는지를 확인하는 도구
• 테스트 통제 도구(Test Control Tools)
  • 테스트 관리 도구 : 테스트 계획 및 관리
  • 형상 관리 도구 : 테스트 수행에 필요한 데이터와 도구를 관리
  • 결함 추적/관리 도구 : 테스트에서 발생한 결함에 대해 관리하거나 협업을 지원
• 테스트 장치(Test Harness)
  • 테스트 장치의 개념
    • 애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분
    • 테스트를 지원하기 위한 코드와 데이터
    • 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성
  • 테스트 장치 구성요소

2.3 통합 테스트

2.3.1 통합 테스트의 개념

• 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
• 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하는 것
• 단위 테스트가 끝난 모듈들을 통합하면서 기능에 맞는지 안맞는지 확인하는 테스트 방법
• 수행 방법으로는 비점증적 방식(빅뱅), 점증적 방식(상향식, 하향식)이 있다.

2.3.2 통합 테스트 수행 방법의 분류 : 하스상드⭐

(1) 하향식 통합 테스트(Top Down)

• 메인 제어 모듈로부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하면서 테스트 진행
• ‘깊이-우선’ 또는 ‘너비-우선’ 방식으로 통합
• 아직 개발되지 않은 하위 모듈은 더미 모듈인 스텁(Stub)을 개발하여 테스트 진행
• 장점
  • 장애 위치 파악이 쉬움
  • 중요 모듈은 먼저 테스트 수행
• 단점
  • 많은 스텁이 필요함
  • 하위 모듈의 불충분한 테스트

(2) 상향식 통합 테스트(Bottom Up)

• 최하위 레벨의 모듈 부터 위쪽 방향으로 제어의 경로를 따라 통합하면서 테스트 진행
• 하위 모듈을 클러스터(Cluster)로 결합하면서 위쪽 방향으로 진행
• 아직 개발되지 않은 하위 모듈은 더미 모듈인 드라이버(Driver)를 개발하여 테스트 진행
• 장점
  • 장애 위치 파악 쉬움
  • 모든 모듈 개발을 위한 시간 낭비가 불필요
• 단점
  • 중요 모듈들이 마지막에 테스트될 가능성이 높음

(3) 빅뱅 테스트

• 모든 구성 요소들을 한꺼번에 통합하여 테스트
• 소규모 시스템에 편리한 테스트 방식
• 장점 : 단시간에 테스트를 할 수 있다.
• 단점
  • 장애가 일어난 위치를 파악하기 어렵다.
  • 모든 모듈들이 설계된 후에 시작 할 수 있기 때문에, 테스트 시간이 적어진다

(4) 백본 테스트

• 샌드위치 테스트
• 상향식과 하향식의 장점을 이용하는 방식
• 드라이버/스텁을 필요에 따라 만들어 사용
• 대규모 프로젝트에 사용하는 방식
• 비용이 많이 들어간다.

2.3.3 통합 테스트 수행 순서

1. 통합 테스트 계획서를 검토
2. 통합 테스트를 수행할 테스트 환경을 준비
3. 통합 테스트 케이스 및 시나리오를 검토
4. 통합 모듈 및 인터페이스가 요구사항을 충족하는지 테스트를 수행
5. 통합 테스트 결과를 기록

3. 애플리케이션 성능 개선

3.1 애플리케이션 성능 저하 원인

3.1.1 데이터베이스 관련 성능 저하

• 데이터베이스 락(DB Lock) : 대량의 데이터 조회, 과도한 업데이트시 발생하며, Lock 해제시까지 대기하거나 타임아웃 된다.
• 불필요한 패치(DB Fetch) : 결과 세트에서 커서를 옮기는 작업이 빈번할 때 발생한다.
• 연결 누수(Connection Leak)
  • DB Connection 사용 후 반환하지 않을 경우 발생한다.
  • Connection 의 Pool 크기가 너무 작거나 크게 설정된

3.1.2 내부 로직으로 인한 성능 저하 원인

• 파일 관련 오류 : 대량의 파일을 업로드 하거나 다운로드 할 때 발생한다.
• 코드 오류 : 코드 오류로 무한 반복등이 수행될 때 발생한다

3.1.3 외부 호출로 인한 성능 저하

• 외부서버와 인터페이스 시 장시간 수행되거나, 타임아웃이 일어나 성능 저하가 발생한다.

3.2 애플리케이션 성능 분석

3.2.1 애플리케이션 성능 분석 지표 : 처응경자⭐

영어도 같이 외우기

• 처리량(Throughput) : 일정 시간 내에 애플리케이션이 처리하는 일의 양
• 응답 시간(Response Time) : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
• 반환/경과 시간(Turn Around Time) : 애플리케이션에 요청을 전달한 시간부터 처리가 완료될 때까지 걸린 시간
• 자원 사용률(Resource Usage): 애플리케이션이 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률

3.2.2 성능 분석 도구

• JMeter : HTTP, FTP등 다양한 프로토콜을 지원하는 부하 테스트 도구
• LoadUI
  • 서버 모니터링, Drag&Drop 등 사용자 편리성이 강화된 도구
  • HTTP, JDBC 등 다양한 프로토콜 지원
• OpenSTA : HTTP, HPPTS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구

3.2.3 모니터링 도구

• Scouter : 단일 뷰 통합/실시간 모니터링
• NMon : 리눅스 서버 자원에 대한 모니터링 도구
• Zabbix : 웹기반 서버, 서비스, 애플리케이션 모니터링 도구
• Jeniffer : 애플리케이션에서 서버로 유입되는 트랜잭션 수량, 처리시간, 응답시간, 자원 활용율 등을 모니터링

3.3 정형 기술 검토회의(FTR, Formal Technical Review)

3.3.1 FTR의 개념⭐

• 소프트웨어 엔지니어가 수행하는 소프트웨어 품질보증 활동
• 개발단계에서 제작되는 문서나 프로그램의 문제점을 찾고, 문제해결을 촉구하는 일반적인 용어
• S/W 개발 산출물을 대상으로 오류를 발견하기 위한 공식적인 활동

3.3.2 FTR의 목적

• 산출물 요구사항 일치여부
• 소프트웨어가 미리 정한 기준에 따라 표현 되었는가를 확인
• 소프트웨어의 표현에 대한 기능, 논리적 오류
• 프로젝트를 보다 관리하기 쉽게 만든다.

3.3.3 검토지침

• 제작자가 아닌 제품의 검토에만 집중한다.
• 문제 영역을 명확히 표현한다.
• 제기된 모든 문제를 바로 해결하고자 하지 말 것
• 검토자들은 사전에 작성한 메모들을 공유한다.
• 논쟁이나 반박을 제한한다.
• 의제를 정하고 그 범위를 유지한다.
• 참가자의 수를 제한하고, 사전 준비를 철저히 하도록 강요한다.
• 자원과 시간 일정을 할당한다.
• 모든 검토자에게 의미있는 교육을 행한다.
• 검토의 과정과 결과를 재검토한다.

3.4 소스코드 품질 분석 : 동워인⭐

3.4.1 동료 검토(Peer Review)

• 2~3명이 진행하는 리뷰의 형태
• 작성자가 코드를 설명하고 이해 관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행하는 기법

3.4.2 워크스루(Walkthrough, 예행연습)

• 계획된 개발자 검토 회의
• 검토 자료를 회의 전에 배포해서 사전검토 한 후 짧은 시간 동안 회의를 진행하는 형태
• 리뷰를 통해 오류를 검출하고 문서화 하는 기법

3.4.3 인스펙션(Inspection, 점검)

• 공식적 검사 회의
• 작업자 외 다른 전문가가 검사하는 가장 공식적인 리뷰 기법
• 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 기법

3.5 소스코드 품질 분석 도구

3.5.1 소스코드 품질 분석 도구의 개념

• 코딩을 하면서 발생하는 문제를 해결하기 위해 사용하는 도구
• 소스코드의 코딩 스타일, 코딩 표준, 코드의 복잡도, 메모리 누수 현상, 스레드 결함과 같은 소스코드로 인해 발생하는 문제를 찾기 위해 사용

3.5.2 소스코드 품질 분석 도구 분류

• 정적 분석 도구
  • 프로그램을 실행하지 않고 소프트웨어를 분석하는 방법
  • 소스 코드의 결함 및 취약성을 찾기 위한 도구
  • 소프트웨어 코드내에 잠재된 오류, 버그, 보안취약점 등의 각종 결함들을 소스코드 분석을 통하여 탐지
• 동적 분석 도구 : 프로그램을 실행하여 코드에 존재하는 메모리 누수나, 스레드의 결함 등을 발견

3.5.3 소스코드 품질 분석 도구 종류⭐

3.6 애플리케이션 성능 개선하기

3.6.1 코드 최적화의 개념

• 주어진 코드에 대해 같은 작업을 수행 하면서, 실행 시간을 줄이거나 메모리를 줄이는 것
• 기존의 방법보다 계산 횟수를 줄이거나 실행 시간을 더 짧고, 기억용량을 더 적게 코드를 작성
• 알고리즘을 개선하거나, 병목 현상을 제거
• 소스코드를 가지고 협업하거나, 유지운영을 위해 소스코드를 다른 사람들이 읽기 쉽게 작성
• 소스코드 리팩토링을 통해서 코드 스멜(Code Smell)을 제거하고 품질 좋은 코드를 작성

3.6.2 코드 스멜(Code Smell)

• 같은 코드가 여러 곳에 존재하는 중복된 코드로 코드 스멜(Code Smell)이 발생
• 클래스, 메소드, 함수, 프로시저의 길이가 매우 길어져서 발생
• 다른 클래스의 메소드들을 너무 많이 사용하는 기능 의존으로 발생
• 다른 클래스의 구현에 세밀하게 의존하는 클래스로서 부적절한 관계를 형성
• 상속을 거부하는 현상으로 부모 클래스의 규약을 지키지 않은 채, 메소드 오버라이드(Method Override)를하는 경우에 발생

3.6.3 리팩토링⭐

• 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법
• 코드가 작성된 후에 디자인을 개선하는 작업
• 모든 것을 미리 생각하기보다는 개발을 하면서 지속적으로 좋은 디자인을 찾는다.
• 이미 작성한 소스코드에서 구현된 일련의 기능을 변경없이, 코드의 가독성과 유지보수성을 높이기 위해내부구조를 변경하는 것
• 주요 리팩토링 기법으로는 메서드 정리, 객체 간 기능 이동, 이름 변경, 추측성 일반화가 있다.

3.6.4 클린코드

(1) 클린코드의 개념

• 의존성을 최소로 하고 사람이 이해할 수 있는 가독성, 목적성이 뛰어난 명확한 코드
• 의존성 최소화, 단일 책임의 원칙, 버그유입 최소화, 가독성 향상, 중복코드 최소화, 변경용이, 작은 코드등의특징

(2) 클린코드 구현 방법

• 클래스명, 메서드명, 변수명은 명사를 사용하여 의미가 있는 이름을 짓는다.
• 불필요한 주석을 제거하고 의도를 명확히 기술한 주석을 작성
• 리팩토링을 통해 점진적인 개선을 통해 코드의 복잡도를 낮게 한다.
• 코드는 가급적 기능별로 간단하게 작성
• 코드의 중복을 최소화
• 누구든지 코드를 쉽게 읽을 수 있도록 작성
• 다른 모듈에 미치는 영향을 최소화하여 작성

(3) 클린코드 작성 원칙 : 가단의 중추⭐

• 가독성
  • 누구든지 코드를 쉽게 읽을 수 있도록 작성한다.
  • 코드 작성 시 이해하기 쉬운 용어를 사용하고, 들여쓰기 등을 이용한다.
• 단순성
  • 코드를 간단하게 작성한다.
  • 한 번에 한 가지를 처리하도록 코드를 작성하고 클래스/메소드/함수 등을 최소 단위로분리한다.
• 의존성 배제
  • 코드가 다른 모듈에 미치는 영향을 최소화한다.
  • 코드 변경 시 다른 부분에 영향이 없도록 작성한다.
• 중복성 최소화
  • 코드의 중복을 최소화한다.
  • 중복된 코드는 삭제하고 공통된 코드를 사용한다.
• 추상화
  • 상위 객체는 간략하게 기능적 특성을 나타내고, 상세 내용은 하위 객체에서 구현한다.