7장 애플리케이션 테스트 관리

제7장 애플리케이션 테스트 관리

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

• 개발하고자 하는 응용소프트웨어의 특성을 반영한 테스트 방식, 대상과 범위를 결정하여 테스트케이스를 작성 할 수 있다.
• 개발하고자 하는 응용소프트웨어의 특성을 반영한 테스트 방식, 대상과 범위가 적용된 시나리오를 정의할 수 있다.
• 애플리케이션 테스트 수행에 필요한 테스트 데이터, 테스트 시작 및 종료 조건 등을 준비 할 수 있다.

1.애플리케이션 테스트

(1)개요

• 소프트웨어 시험이란 결함(fault)을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차를 말한다.
• 시험은 시험사례(Test Case)들을 만들어 진행한다.
• 디버깅(Debugging)은 소프트웨어가 시험사례 통과시 발견된 결함을 제거시키는 작업을 말한다.

(2)특징

• 시험은 오류의 유입을 최소화할 수 있으며, 테스트를 개발 초기 단계부터 계획하여 꾸준히 시행하는 것으로 본다면 단순히 오류를 발견하는 작업만은 아니라 할 수 있다.
• 완벽한 시험은 불가능하며, 시험에서 발견된 문제가 없다고 하여 프로그램에 오류가 없다고 할 수는 없다.
• 시험과정을 통해서 모든 오류가 발견, 수정될 수는 없지만 효율적인 시험이 될 수 있도록 시험계획을 수립하여야 한다.

(3)시험의 경제성

• 소프트웨어 개발 노력 분포도는 40(분석-설계) - 20구현 -40(시험) 을 따른다.

(4)애플리케이션 테스트 기본 원리

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

2.테스트 케이스

(1)테스트 케이스의 정의

• 소프트웨어가 목표하는 보장성을 만족할 수 있도록 최적의 테스트 케이스로 가능한 많은 결함을 발견 할 수 있어야 한다.

(2)테스트 케이스 작성 절차

1. 참조 문서 수집: 시험 계획서에 명시된 테스트 케이스 작성지침과 수준을 고려하여 테스트 설계에 필요한 분석/설계 문서를 수집한다.
2. 테스트 케이스 작성: 테스트 설계기법을 이용하여 테스트 케이스를 작성한다.
3. 내부 검토: 아키텍쳐, 관리자, 기획자, 개발자, 테스터 등이 작성된 테스트 케이스의 적정성을 검토한다.
4. 요구사항 대비 커버리지 분석: 테스트 케이스가 어느 정도 요구사항을 반영하는가에 대한 분석으로 테스트 가능한 요구사항이 모두 테스트 케이스에 반영되었는지 확인한다.
5. 승인:작성된 테스트 케이스를 고객, 기획자, 관리자 등의 승인을 획득한다.

3.테스트의 종류

1)테스트 단계에 의한 분류

1. 모듈 시험: 독립적인 환경에서 하나의 모듈만을 테스트
2. 통합 시험:시스템 모듈간의 상호 인터페이스에 관한 테스트. 즉, 모듈간의 데이터 이동이 원하는대로 이루어지고 있는가를 확인하는 작업 /하향식, 상향식
3. 확인 시험: 사용자의 요구사항을 만족하는지를 확인하는 테스트 (알파)
4. 시스템 시험: 시스템이 초기의 목적에 부합하는지에 대한 테스트

2)테스트 목적에 의한 분류

1. 기능 시험: 주어진 입력에 대한 기대되는 출력제공 여부 시험
2. 성능 시험: 응답시간, 처리량, 메모리 활용도, 처리속도 등
3. 스트레스 시험: 정보의 과부하시, 최저조건 미달-최고조건 초과시, 물리적 충격과 변화시 반응 정도
4. 복잡도 시험:소프트웨어에 내재되어 있는 논리경로의 복잡도를 평가하는 구조시험

3)시각에 의한 분류

①검증(Verification)

• 개발자의 시각에서 시스템이 명세서대로 만들어졌는지를 점검하는 것이다.
• 각 단계에서 입력으로 제공된 제품들과 표준에 기준하여 정확성과 일치성을 보장하기 위한 것이다.

②확인(Validation)

사용자의 시각에서 고객의 요구사항이 올바르게 구현되었는지를 점검하는 것이다.

4)테스트 방법에 의한 분류

• 블랙박스 시험(Black Box Testing) : 소프트웨어 외부명세서를 기준으로 그 기능, 성능을 시험
• 화이트박스 시험(Whtie Box Testing):소프트웨어 내부의 논리적 구조를 시험

�코드 커버리지

• 구문 커버리지:프로그램 내의 모든 명령문을 적어도 한번 수행하는 테스트케이스
• 결정 커버리지:프로그램 내의 전체 결정문이 적어도 한번은 참과 거짓의 결과를 수행하는 테스트케이스
• 조건커버리지:결정 명령문 내의 각 조건이 적어도 한번은 참과 거짓이 결과가 되도록 수행하는 테스트케이스
• 조건-결정커버리지: 전체 조건식 뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행하는 테스트케이스
• 변경 조건-결정 커버리지: 각 개별 조건식이 다른 개별 조건식에 영향받지 않고 전체 조건식에 독립적으로 영향을 주도록 하는 테스트케이스
• 다중 조건 커버리지:결정 포인트내에 있는 모든 개별식 조건의 모든 조합을 고려한 커버리지

5)프로그램 실행 여부에 따른 분류

정적 테스트: 프로그램을 실행하지 않고 명세서나 소스코드를 대상으로 분석하는 테스트(인스펙션, 워크수루, 코드검사)

동적 테스트:프로그램을 실행하여 결함을 발견하는 테스트이다.(화이트박스 테스트, 블랙박스 테스트)

4.테스트 레벨

(1) 모듈 시험(단위 시험, Unit Test)

• 단위 테스트에는 정형화되지 않은 기술이 많이 사용된다.
• 코딩이 끝난 후 설계의 최소 단위인 모듈에 초점을 두고 검사하는 단계
• 화이트박스 검사 기법 적용

1. 검사내용

• 모듈 인터페이스 시험
• 자료구조 시험
• 실행 경로 시험
• 오류 처리 시험
• 경계 처리 시험

(2) 통합시험(Integration Test)

• 단위검사가 끝난 모듈들을 하나로 결합하여 시스템으로 완성하는 과정에서의 검사이다.
• 모듈간의 인터페이스와 연관된 오류를 밝히기 위한 검사와 함께 프로그램 구조를 구축하는 체계적인 기법이다.
• 시스템을 구성하는 모듈사이의 인터페이스와 결합을 테스트하며, 시스템 전체의 기능과 성능을 테스트한다.
• 통합시험은 시스템을 구성하는 여러 모듈을 어떤 순서로 결합하여 테스트할 것이냐에 따라 동시식(Big-Bang), 하향식(Top-down), 상향식(Bottom-up) , 연쇄식(Threads) 등이 있다.

(3) 시스템 시험(System Test)

모든 모듈들은 하나의 시스템으로 작동하게 된다. 사용자의 모든 요구를 하나의 시스템으로서 완벽하게 수행하기 위해서는 아래와 같은 다양한 시험들이 필요하다.

1. 외부 기능 테스트(function test):소프트웨어에 대한 외부로부터의 시각에서 요구분석 단계에서 정의된 외부명세(external specification)의 충족성을 테스트한다.
2. 내부 기능 테스트(facility test):사용자의 상세기능 요구를 요구명세서의 문장 하나 하나 짚어가며 테스트한다.
3. 부피 테스트(volume test):소프트웨어로 하여금 상당량의 데이터를 처리해 보도록 여건을 조성하는 것이다.
4. 스트레스 테스트(stress test):소프트웨어에게 다양한 스트레스를 가해 보는 것으로 민감성 테스트(sensitivity test)라고 불리기도 한다.
5. 성능 테스트(performance test):소프트웨어의 효율성을 진단하는 것으로서 응답속도, 처리량, 처리속도 등을 테스트한다.
6. 호환성 테스트(compatibility test):많은 소프트웨어들은 이미 사용중인 소프트웨어의 대체용일 가능성이 높기 때문에 기존 소프트웨어와 호환성을 따져본다.
7. 신뢰성 테스트(reliability test):소프트웨어가 오류를 발생시키고 고장(failure)을 내는 정도를 테스트한다.
8. 복구 테스트(recovery test):소프트웨어가 자체결함이나 하드웨어 고장이나 데이터의 오류로부터 어떻게 회복하느냐를 평가하는 것이다.
9. 보수 용이성 테스트(serviceability test):고장 진단, 보수절차 및 유지보수 단계에서의 작용을 얼마나 용이하도록 하고 있는가를 테스트한다.

(4) 인수 시험(Validation Testing, 확인 시험)

1)개요

• 사용자측 관점에서 소프트웨어가 요구를 충족시키는가를 평가
• 하나의 소프트웨어 단위로 통합된 후 요구사항 명세서를 토대로 진행한다. 명세서에는 유효성 기준(Validation Criteria)절을 포함하고 있다.
• 개발 집단이 사용자 집단을 대신하여 검토회(Review, Inspection, Walkthrough) 등 일정한 방법을 사용하면서 품질보증에 임하는 것

2)알파 테스트와 베타 테스트

• 알파 테스트

  특정 사용자들에 의해 개발자 위치에서 테스트를 실행한다. 즉, 관리된 환경에서 수행된다.

  본래의 환경에서 개발자가 사용자의 "어깨 너머"로 보고 에러와 문제들을 기록하는 것을 다룬다.

  통제된 환경에서 일정기간 사용해 보면서 개발자와 함께 문제점들을 확인하며 기록한다.

• 베타 테스트

  최종 사용자가 사용자 환경에서 검사를 수행한다. 개발자는 일반적으로 참석하지 않는다.

  발견된 오류와 사용상의 문제점을 기록하여 추후에 반영될 수 있도록 개발조직에게 보고해 주는 형식을 취한다.

5.테스트 시나리오

(1)테스트 시나리오의 개요

테스트 시나리오는 테스트 할 수 있는 모든 기능을 말하는 것으로 테스트 조건 또는 테스트 기능성이라고 한다.

여러 개의 테스트 케이스들의 집합을 수행하기 위한 동작 순서를 기술한 문서를 말하는 것으로 테스트 절차 명세라고 할 수 있다.

(2)테스트 시나리오 작성 목적

다양한 이해 관계자가 승인하여 테스트 중인 소프트웨어가 철저하게 테스트되었는지 확인할 수 있다.

소프트웨어의 종단 간 기능을 연구하기 위해 테스트 시나리오가 중요한 역할을 한다.

최대한의 테스트 커버리지를 보장할 수 있다.

(3)테스트 시나리오 작성 절차

1. 요구사항 문서 리딩
2. 각 요구사항에 대해 가능한 사용자 행동 및 목표 파악
3. 적절한 분석 후에 소프트웨어의 각 기능을 검증하는 다양한 테스트 시나리오 나열
4. 추적성 매트리스 생성: 가능한 모든 테스트 시나리오를 나열하면 각 요구사항에 대한 테스트 시나리오가 있는지 확인 위해 필요
5. 생성된 사니라오 검토

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

• 개발자 통합 테스트 계획에 따라 통합 모듈 및 인터페이스가 요구사항을 충족하는지에 대한 테스트를 수행할 수 있다.
• 개발자 통합테스트 수행 결과 발견된 결함에 대한 추이 분석을 통하여 잔존 결함을 추정할 수 있다.
• 개발자 통합테스트 결과에 대한 분석을 통해 테스트의 충분성 여부를 검증하고, 발견된 결함에 대한 개선 조치사항을 작성할 수 있다.

1.테스트 시나리오

• 테스트 수행 후 발생한 결함들이 다시 발생되는 것을 방지하기 위하여 결함을 추적하고 관리하는 활동을 결함 관리라고한다.

1. 결함 관리 시스템(Defect Management System)
2. 버그 추적 시스템(Bug Tracking System)
3. 이슈 관리 시스템(Issue Tracking System)

(1)결함관리 상용도구

• HP QC(Quality Center)
• IBM Clear Quest
• JIRA

(2)결함관리 오픈소스 도구

• Bugzilla:설치가 다소 어렵지만, 다양한 플러그인 기능을 제공(프로젝트 관리도구, 이클립스 등)
• Trac:버그 관리, 개발 Task용 이슈 관리, 소스 코드 형상 관리 및 위키 기반의 문서 관리
• Mantis: 버그 관리에 최적화, 설치와 사용법이 매우 용이, 일반적으로 결함만 관리한다면 Mantis 많이 권장

2.테스트 자동화 도구

• 테스트 자동화 도구는 테스트에 포함되는 여러 과정들을 자동적으로 지원하여 생산성 및 일관성을 향상시킬 수 있다.

(1)자동화된 테스팅의 필요성

• 수동 테스팅의 모든 작업 흐름, 모든 분야, 모든 부정적인 시나리오들이 시간과 비용을 소비한다.
• 수동적으로 다양한 언어로 된 사이트들을 테스트하는 것은 어렵다.
• 자동화는 사람의 개입 요구 X, 본인이 현장에 있지 않아도 밤새도록 자동화된 테스트를 실행할 수 있다.
• 자동화는 테스트 실행 속도를 향상시킨다.
• 자동화는 테스트 범위를 넓히는 데에 도움을 준다.
• 수동 테스팅은 다소 지루해 질 수 있기 때문에 실수를 범하기 쉽다.

(2)테스트 자동화 도구

• QTP

  • HP의 기능적 테스팅 툴
  • Quality Center와 함께 사용될 수 있다.

• Rational Robot

  IBM의 툴, ERP 애플리케이션과 마찬가지로 클라이언트/서버, 전자 상거래를 위환 회귀, 기능적, 환결 설정 테스트를 자동화 하기 위해 사용된다.

• Selenium

  오픈소스 웹 자동화 툴이며, 모든 종류의 웹 브라우저들을 지원한다.

3.통합 테스트

(1)통합 테스트의 개요

모듈들을 하나로 결합하여 시스템으로 완성하는 과정에서의 검사

모듈간의 인터페이스와 연관된 오류를 밝히기 위한 검사와 함께 프로그램 구조를 구축하는 체계적인 기법이다.

모듈을 어떤 순서로 결합하여 테스트할 것이냐에 따라 동시식(Big-bang), 하향식(Top-down), 상향식(Bottom-up), 연쇄식(Threads) 등이 있다.

(2)동시식 방안(Big-Bang Approach, 비점진적 통합, 차분 통합 검사)

모든 모듈이 한꺼번에 결합되어 하나로 시험한다.

혼란스럽고, 결함의 원인 발견이 어려우며 통합기간이 훨씬 많이 소요되므로 바람직하지 않다.

(3)하향식 통합(Top to Bottom)

• 특징

1. 주프로그램으로부터 그 모듈이 호출하는 다음 레벨의 모듈을 테스트하고, 점차적으로 하위 모듈로 이동하는 방법
2. 드라이버는 필요하지 않고 통합이 시도되지 않은 곳에 스텁(가짜모델)이 필요, 통합이 진행되면서 스텁은 실제 모듈로 교체
3. 검사제어 소프트웨어:Stub -모듈의 부수적인 인터페이스를 사용하는 가짜 모듈(입출력 흉내만 매는 무기능 모듈)
4. 깊이 우선 통합, 너비 우선 통합

• 순서

1. 주 모듈을 드라이버로 사용하고, 주 모듈의 하위모듈들을 스텁으로 대신한다.
2. 깊이 우선 or 너비 우선 등의 통합방식에 따라 하위 스텁들을 실제모듈과 대체한다.
3. 각 모듈이 통합될 때마다 시험을 실시한다.
4. 시험이 통과할 때마다 또 다른 스텁이 실제 모듈로 대체된다.
5. 새로운 오류가 발생하지 않음을 보장하기 위해 회귀 시험을 실시한다.

• 장-단점

1. 장점: 하위모듈 시험이 끝난 상위모듈을 이용하므로 시험환경이 실제 가동 환경과 유사, 주요 기능을 조기에 시험, 처음부터 독립된 소프트웨어 구조를 갖춤
2. 단점:병행작업이 어렵다 스텁이 필요하다.

(4)상향식 통합 (Bottom to Top)

• 특징

1. 하위 레벨의 모듈로부터 점진적으로 상위 모듈로 통합하면서 테스트하는 기법
2. 스텁은 필요하지 않고 드라이버가 필요
3. 검사제어 소프트웨어:Driver - 시험사례를 입력받고, 시험을 위해 받은자료를 모듈로 넘기고, 관련된 결과를 출력하는 메인 프로그램

• 순서

1. 하위 모듈은 소프트웨어의 부수적 기능을 수행하는 클러스터로 조합된다.
2. 각 클러스터의 시험을 위한 시험 사례 입출력을 조정하도록 드라이버를 개발한다.
3. 각 클러스터를 시험한다.
4. 드라이버를 제거하고 클러스터는 위로 이동하며 소프트웨어 구조를 상향식으로 만들어간다.
5. 최종 드라이버 대신 주프로그램을 대체시키고 전체적인 소프트웨어 구조를 완성한다.

• 장*단점

1. 장점: 초기단계부터 병행작업이 가능, 불필요한 개발(스터브)을 피함, 철저한 모듈단위의 시험이 가능
2. 단점:인터페이스의 시험이 가정에 의해 이루어지며, 마지막 단계까지 독립된 소프트웨어 형태를 갖지 못함.

(5)연쇄식(Threads) 통합

• 특수하고 중요한 기능을 수행하는 최소 모듈 집합을 먼저 구현하고 보조적인 기능의 모듈은 나중에 구현하여 테스트한 후 계속 추가한다.
• 제일 먼저 구현되고 통합될 모듈은 중심을 이루는 기능을 처리하는 모듈의 최소집합이다. 이렇게 점차적으로 구축된 스레드에 다른 모듈을 추가시켜 나간다.

1)샌드위치형 통합

• 하위 수준에서는 상향식 통합을, 상위 수준에서는 하향식 통합을 진행하며 최적의 시험 환경을 지원하는 방식
• 샌드위치 시험은 우선적으로 통합을 시도할 중요 모듈을 선정하여 중요 모듈로부터 쌍방향으로 통합을 진행한다. 중요 모듈은 다음의 특성을 지닌 모듈이다.
  1. 사용자의 요구 기능을 많이 발휘하는 모듈
  2. 계층구조의 상위에 위치하여 제어기능을 갖춘 모듈
  3. 구조가 복잡하거나 오류 발생률이 높은 모듈
  4. 분명한 성능 요구를 축종시켜야 하는 모듈

2)회귀 시험(Regression Testing) 유지보수형테스트

• 변경된 소프트웨어 컴포넌트에 초점을 맞춘 테스트

1. 새로운 결함발생의 가능성에 대비하여 이미 실시했던 시험 사례들의 전부 혹은 일부를 재실시하여 시험하는 것이다.
2. 변화들이 의도하지 않은 부작용을 전파하지 않는 것을 확인하기 위해 실시한다.
3. 모든 시험 사례를 재실행하거나 자동화한 Capture/Playback Tools를 사용하여 수동적으로 수행될 수 있다.

제3절 애플리케이션 성능 개선

애플리케이션 테스트를 통하여 애플리케이션의 성능을 분석하고, 성능 저하 요인을 발견할 수 있다.

코드 최적화 기법, 아키텍쳐 조정 및 호출 문서 조정 등을 적용하여 애플리케이션 성능을 개선할 수 있다.

프로그래밍 언어의 특성에 대한 이해를 기반으로 소스코드 품질 분석 도구를 활용하여 애플리케이션 성능을 개선할 수 있다.

1.애플리케이션 성능 분석

애플리케이션 성능은 최소한의 자원을 사용하여 사용자가 요구한 많은 기능을 신속하게 처리할 수 있는 정도를 나타낸다.

(1)애플리케이션의 성능을 측정하기 위한 지표

1. 처리량: 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수
2. 응답시간:애플리케이션에 요청을 전달한 시간부터 응답이 도착할때까지 걸린 시간
3. 반환시간:사용자가 요구를 입력한 시점부터 트랜잭션 처리 후 출력이 완료할 때까지 걸리는 시간
4. 자원 사용률:애플리케이션이 트랜잭션을 처리하는 동안에 사용하는 자원 사용률(CPU 사용량, 메모리 사용량, 네트워크 사용량)

(2)애플리케이션 성능 분석 절차

1. 성능 점검을 위하여 성능 테스트 도구와 시스템 모니터링 도구를 파악
2. 점검 계획서 작성
3. 성능 측정을 위한 시험사례 작성
4. 성능 테스트 수행
5. 테스트 결과 분석 및 성능 저하 요인 분석

• 성능 테스트 도구:JMeter, OpenSTA, LoadUI 등

• 성능 테스트

  Load 테스트:부하(Load)를 순차적으로 증가시키면서 응답시간이 급격히 증가하거나 처리량이 더 이상 증가하지 않는 등 비정상 상태가 발생하는 임계점을 찾아낸다.

  Stress 테스트:임계값 이상의 요청이나 비정상적인 요청을 보내 비정상적인 상황의 처리 상태를 확인하고 시스템의 최고 성능 한계를 측정하기 위한 테스트이다. (부피테스트)

  Spike 테스트:갑자기 부하(Workload)가 증가하였을 때 요청이 정상적으로 처리되는지 그 업무 부하가 줄어들 떄 정상적으로 반응해지는지를 확인하기 위한 테스트

  Stability 테스트: 긴 시간 동안 테스트를 진행해서 테스트 시간에 따르느 시스템의 메모리 증가, 성능 정보의 변화 등을 확인하는 테스트이다.

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

(1)코드 최적화

• 코드 최적화의 개요

  • 코드 최적화는 동등한 의미를 가지면서 실행시간이나 메모리를 줄이는 것이라 할 수 있다.
  • 크기가 작고 보다 빠르며 기억장소 요구량이 작은 코드로 개선하는 것이다.
  • 최적화는 나쁜 코드(bad code)를 읽기 쉽고 변경 및 추가가 쉬운 클린 코드(clean code)로 작성하는 것이다.
  • 나쁜코드(bad code):로직을 이해하기 어렵게 작성된 코드이며, 동일한 처리 로직이 중복되게 작성된 코드라든지 코드의 로직이 서로 얽혀 있는 스파게티 코드가 여기에 속한다.
  • 클린코드(clean code):잘 작성되어 가독성이 높고 단순하고 의존성을 줄이고 중복을 최소화하여 잘 정리된 코드이다.

• 코드 최적화 규칙

  프로그램을 이루는 각각의 모듈 중 어느 부분이 느리게 작동하거나, 큰 메모리를 소비하는지 찾아야한다.

  컴파일러의 버전과 종류, 만들고자 하는 애플리케이션의 특징을 고려해야 한다.

  느슨한 결합을 지향하여, 부품간의 상호의존성을 반드시 최소화한다.

  표준적인 코딩 형식을 사용하며, 주석문은 반드시 작성한다.

(2)코드 리팩토링(Refactorying)

1)리팩토링의 정의

• SW를 보다 쉽게 이해할 수 있고 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것 → 프로그램의 가치 상승
• Code smell을 고치고 다듬는 과정

2)리팩토링의 목적

• SW의 디자인을 개선시킴
• SW를 이해하기 쉽게 만듦
• 버그를 찾는 데 도움을 줌
• 프로그램을 빨리 작성할 수 있게 도와 줌

3)리팩토링 시기

• 기능을 추가할 때
• 버그를 수정할 때
• 코드를 검토할 때

4)코드스멜과 리팩토링 대상

• 코드 스멜
  • 읽기 어려운 프로그램
  • 중복된 로직을 가진 프로그램
  • 실행중인 코드를 변경해야 하는 특별 동작을 요구하는 프로그램
  • 복잡한 조건이 포함된 프로그램
• 리팩토링 대상
  • 중복코드
  • 긴 메소드명
  • 큰 클래스
  • 긴 파라미터 리스트
  • switch parameter
  • 병렬 상속 구조
  • Lazy Class
  • Data Class
  • 불충분한 Library Class

5)리팩토링 프로세스

1. 소규모의 변경: 단일 리팩토링
2. 코드가 전부 잘 작동되는지 테스트
3. 전체가 잘 작동하면 다음 리팩토링 단계로 전진
4. 작동하지 않으면 문제를 해결하고 리팩토링한 것을 Undo하여 시스템이 작동되도록 유지

6)리팩토링 메소드 기법

1. Extract Method: 그룹으로 함께 묶을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다.
2. Move Method: 메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면, 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만든다.
3. Rename Method: 메소드의 이름이 그 목적을 드러내지 못하고 있다면 메소드의 이름을 바꾼다.
4. Pull up Method:동일한 일을 하는 메소드를 여러 서브클래스를 갖고 있다면, 이 메소드를 수퍼클래스로 옮긴다.

(3)소스코드 품질분석 도구

①소스코드 품질분석 도구의 개요

• 소프트웨어 산업으로의 다양성 확대, 기능 확장, 복잡도 증가 등의 이유로, 소프트웨어 검증, 테스팅 등의 품질 관련한 부분이 중요해지고 있으며, 이에 품질분석 도구는 더 중요한 요소가 되고 있다.
• 소스코드 품질분석 도구는 정적/동적 분석 도구로 나눌 수 있다.

②정적 분석 도구

• 소스코드의 실행없이 코드 자체만으로도 코드를 분석하는 도구이다.
• 코딩 스타일 적정 여부, 잔재 결함 여부, 코딩 표준 준수 여부 등 확인
• cppcheck, pmd, checkstyle 등

https://docs.google.com/spreadsheets/d/e/2PACX-1vSd8bh6vhGKNv5U6ZBFxw9NnlBoWhJqPO5UUYlYkdAtuJZQfNL4L0EGwZWxnHPSrgfgZIqZXKK8Bac5/pubhtml

③동적 분석 도구

• 프로그램을 실행하여 코드를 분석하는 도구
• Valgrind, Avalanche 등

https://docs.google.com/spreadsheets/d/e/2PACX-1vRhqnepoN4hbOW_myRlF3S-ogdbVHE2K_vBm0phUz_Kkh9zlKvKFdZGAVU7ev2OI3IranRYYuQr7ZBb/pubhtml