4장 - 애플리케이션 테스트 관리 | 섹션24. 결함 관리, 섹션25. 복잡도, 섹션26. 애플리케이션 성능개선

2024년도 시나공 필기 책 내용 정리 

---

섹션24. 결함 관리

 

1. 결함(Fault)의 정의

 

• 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생 되는 것을 의미
• 사용자가 예상한 결과와 실행 결과 간의 차이나 업무 내용과의 불일치 등으로 인해 변경이 필요한 부분도 모두 결함에 해당함

---

2. 결함 관리 프로세스

 

1. 결함 관리 계획 : 전체 프로세스에 대한 결함 관리 일정, 인력, 업무 프로세스등을 확보하여 계획을 수립하는 단계
2. 결함 기록 : 테스터는 발견된 결함을 결함 관리 DB에 등록
3. 결함 검토 : 테스터, 프로그램 리더, 품질 관리(QA) 담당자 등은 등록된 결함을 검토하고 결함을 수정할 개발자에게 전달
4. 결함 수정 : 개발자는 전달받은 결함을 수정
5. 결함 재확인 : 테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행
6. 결함 상태 추적 및 모니터링 활동 : 결함 관리 DB를 이용하여 프로젝트별 결함 유형, 발생률 등을 한눈에 볼 수 있는 대시보드 또는 게시판 형태의 서비스를 제공
7. 최종 결함 분석 및 보고서 작성 : 발견된 결함에 대한 정보와 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리를 종료

https://lipcoder.tistory.com/311 출처

---

3. 결함 상태 추적

 

• 테스트에서 발견된 결함은 지속적으로 상태 변화를 추적하고 관리해야 함
• 발견된 결함에 대해 결함 관리 측정 지표의 속석 값들을 분석하여 향후 결함이 발견될 모듈 또는 컴포넌트를 추정할 수 있음
• 결함 관리 측정 지표

결함 분포	모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
결함 추세	테스트 진행 시간에 따른 결함 수의 추이 분석
결함 에이징	특정 결함 상태로 지속되는 시간 측정

 

---

4. 결함 추적 순서

 

1. 결함 등록(Open) : 테스터와 품질 관리 담당자에 의해 발견된 결함이 등록된 상태
2. 결함 검토(Reviewed) : 등록된 결함을 테스터, 품질 관리 담당자, 프로그램 리더, 담당 모듈 개발자에 의해 검토된 상태
3. 결함 할당(Assigned) : 결함을 수정하기 위해 개발자와 문제 해결 담당자에게 결함이 할당된 상태
4. 결함 수정(Resolved) : 개발자가 결함 수정을 완료한 상태
5. 결함 조치 보류(Deferred) : 결함의 수정이 불가능해 연기된 상태로 우선순위, 일정 등에 따라 재오픈을 준비중인 상태
6. 결함 종료(Closed) : 결함이 해결되어 테스터와 품질 관리 담당자가 종료를 승인한 상태
7. 결함 해제(Clarified) : 테스터, 프로그램 리더, 품질 관리 담당자가 종료 승인한 결함을 검토하여 결함이 아니라고 판명한 상태

---

5. 결함 분류

시스템 결함	시스템 다운, 애플리케이션의 작동 정지, 종료, 응답 시간 지연, 데이터베이스 에러 등 주로 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함
기능 결함	사용자의 요구사항 미반영/불일치, 부정확한 비즈니스 프로세스, 스크립트 오류, 타 시스템 연동 시 오류 등 애플리케이션의 기획, 설계 업무 시나리오 등의 단계에서 유입된 결함
GUI 결함	UI 비일관성, 데이터 타입의 표시 오류, 부정확한 커서/메세지 오류 등 사용자 화면 설계에서 발생된 결함
문서 결함	사용자의 요구사항과 기능 요구사항의 불일치로 인한 불완전한 상태의 문서, 사용자의 온라인/오프라인 매뉴얼의 등 기획자, 개발자 간의 의사소통 및 기록이 원할하지 않아 발생된 결함

 

테스트 단계별 유입 결함

 

• 기획 시 유입되는 결함 : 사용자 요구사항의 표준 미준수로 인한 테스트 불가능, 요구사항 불명확/불완전/불일치 결함 등
• 설계 시 유입되는 결함 : 설계 표준 미준수로 인한 테스트 불가능, 기능 설계 불명확/불완전 불일치 결함 등
• 코딩 시 유입되는 결함 : 코딩 표준 미준수로 인한 기능의 불일치/불완전, 데이터 결함, 인터페이스 결함 등
• 테스트 부족으로 유입되는 결함 : 테스트 수행 시 테스트 완료 기준의 미준수, 테스트팀과 개발팀의 의사소통 부족, 개발자의 코딩 실수로 인한 결함 

---

6. 결함 심각도(시스템에 미치는 치명도)

High	핵심 요구사항 미구현, 장시간 시스템 응답 지연, 시스템 다운 등과 같이 더이상 프로세스를 진행할 수 없도록 마드는 결함
Medium	부정확한 기능이나 데이터베이스 에러 등과 같이 시스템 흐름에 영향을 미치는 결함
Low	부정확한 GUI 및 메세지, 에러 시 메세지 미출력, 화면상의 문법/철자 오류 등과 같이 시스템 흐름에는 영향을 미치지 않는 결함

---

7. 결함 우선순위

 

• 발견된 결함 처리에 대한 신속성을 나타내는 척도로 결함의 중요도와 심각도에 따라 설정되고 수정 여부가 결정 됨
• 결함의 심각도가 높으면 우선순위도 높지만 애플리케이션의 특성에 따라 우선순위가 결정될 수도 있기 때문에 심각도가 높다고 반드시 우선순위가 높은 것은 아님
• 결정적(Critical), 높음(High), 보통(Medium), 낮음(Low) 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류

---

8. 결함 관리 도구

Mantis	결함 및 이슈 관리도구, 소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 추적도 가능
Trac	결함 추적은 물론 결함을 통합하여 관리할 수 있는 도구
Redmine	프로젝트 관리 및 결함 추적이 가능한 도구
Bugzilla	결함 신고, 확인, 처리 등 결함을 지속적으로 관리할 수 있는 도구, 결함의 심각도와 우선 순위를 지정할 수 있음

---

섹션25. 복잡도

 

1. 복잡도의 개요

 

• 복잡도(Complexity)는 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말로 시스템 또는 소프트웨어를 어느 정도의 수준까지 테스트해야 하는지 또는 개발하는데 어느 정도의 자원이 소요되는지 예측하는데 사용됨
• LOC(Lind Of Code), 순환 복잡도(Cyclomatic Complexity)등의 측정 방법이 있음

---

2. 시간 복잡도

 

• 알고리즘의 실행시간, 즉 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화 한 것을 의미
• 시간 복잡도가 낮을수록 알고리즘의 실행시간이 짧고, 높을수록 실행시간이 길어짐
• 알고리즘의 실행시간이 하드웨어적 성능이나 프로그래밍 언어의 종류에 따라 달라지기 때문에 시간이 아닌 명령어의 실행 횟수를 표기하는데 이러한 표기법을 점근 표기법이라고 함
• 점근 표기법의 종류

빅오 표기법 (Big-O Notation)	알고리즘의 실행시간이 최악일 때 표기하는 방법 입력값에 대해 알고리즘을 수행했을 때 명령어의 실행 횟수는 어떠한 경우에도 표기 수치보다 많을 수 없음
세타 표기법 (Big- θ Notation)	알고리즘의 실행시간이 평균일 때를 표기하는 방법 입력값에 대해 알고리즘을 수행했을 때 명령어 실행 횟수의 평균적인 수치를 표기
오메가 표기법 (Big-Ω Notation)	알고리즘의 실행시간이 최상일 때를 표기하는 방법 입력값에 대해 알고리즘을 수행했을 때 명령어의 실행 횟수는 어떠한 경우에도 표기 수치보다 적을 수 없음

---

3. 빅오 표기법(Big-O Notation)

 

• 알고리즘의 실행시간이 최악일 때를 표기하는 방법
• 신뢰성이 떨어지는 오메가 표기법이나 평가하기 까다로운 세타 표기법에 비해 성능을 예측하기 용이하여 주로 사용함
• 일반적인 알고리즘에 대한 최악의 시간복잡도를 빅오 표기법으로 표현

O(1)	입력값 (n)에 관계 없이 일정하게 문제 해결에 하나의 단계만을 거침 ex) 스택의 삽입(Push), 삭제(Pop)
O(log₂n)	문제 해결에 필요한 단계가 입력값(n) 또는 조건에 의해 감소 ex) 이진 트리(Binary Tree), 이진 검색(Binary Search)
O(n)	문제 해결에 필요한 단계가 입력값(n)과 1:1의 관계를 가짐 ex) for문
O(nlog₂n)	문제 해결에 필요한 단계가 n(log₂n)번 만큼 수행 됨 ex) 힙 정렬(Heap Sort), 2-Way 합병 정렬(Merge Sort)
O(n²)	문제 해결에 필요한 단계가 입력값(n)의 제곱만큼 수행됨 ex) 삽입 정렬(Insertion Sort), 쉘 정렬(Shell Sort), 선택 정렬(Selection Sort), 버블 정렬(Bubble Sort), 퀵 정렬(Quick Sort)
O(2ⁿ)	문제 해결에 필요한 단계가 2의 입력값(n) 제곱 만큼 수행됨 ex) 피보나치 수열(Fibonacci Sequence)

---

4. 순환 복잡도(Cyclomatic Complexity)

 

• 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도로 맥케이브 순환도(McCabe's Cyclomatic) 또는 맥케이브 복잡도 메트릭(McCabe's Complexity Metrics)라고도 하며, 제어 흐름도 이론에 기초를 둠
• 순환 복잡도를 이용하여 계산된 값은 프로그램의 독립적인 경로의 수를 정의하고 모든 경로가 한 번 이상 수행되었음을 보장하기 위해 행해지는 테스트 횟수의 상한선을 제공
• 제어 흐름도 G에서 순환 복잡도 V(G)는 다음과 같은 방법으로 계산할 수 있음
  
  
  1. 순환 복잡도는 제어 흐름도의 영역 수와 일치 하므로 영역의 수를 계산
  2. V(G) = E - N + 2 : E는 화살표 수, N은 노드의 수

영역의 수 = 4 / 화살표개수 11개 - 노드수 9 + 2 = 4

---

섹션26. 애플리케이션 성능개선

 

1. 소스 코드 최적화

 

• 나쁜 코드를 배제하고 클린 코드로 작성하는 것
• 클린 코드(Clean Code) : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 별로한 코드 (잘 작성된 코드)
• 나쁜 코드(Bad Code)
  
  • 프로그램의 로직(Logic)이 복잡하고 이해하기 어려운 코드, 스파게티 코드와 외계인 코드가 해당됨
  • 스파게티 코드(Spaghetti Code) : 코드의 로직이 서로 복잡하게 얽혀 있는 코드
  • 외계인 코드(Alien Code) : 아주 오래되거나 참고문서 또는 개발자가 없어 유지 보수 작업이 어려운 코드
• 나쁜 코드로 작성된 애플리케이션의 코드를 클린 코드로 수정하면 애플리케이션의 성능이 개선됨

클린 코드 작성 원칙

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

*추상화(Abstraction) : 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화(모델화)하는 것

---

2. 소스 코드 최적화 유형

 

• 클래스 분할 배치 : 하나의 클래스는 하나의 역할만 수행 하도록 응집도를 높이고 크기를 작게 작성
• 느슨한 결합(Loosely Coupled) : 인터페이스 클래스를 이용하여 추상화된 자료구조와 메소드를 구현함으로써 클래스 간의 의존성을 최소화
• 코딩 형식 준수 : 줄 바꿈 사용, 개념적 유사성이 높은 종속 함수 사용, 호출하는 함수는 선배치, 호출되는 함수는 후배치, 지역 변수는 각 함수의 맨 처음에 선언
• 좋은 이름 사용 : 변수나 함수 등의 이름은 기억하기 좋은 이름, 발음이 쉬운 용어, 접두어 사용 등 기본적인 이름 명명 규칙(Naming Rule)을 정의하고 규칙에 밎는 이름을 사용함
• 적절한 주석문 사용 : 소스 코드 작성 시 앞으로 해야 할 일을 기록하거나 중요한 코드를 강조할 때 주석문을 사용

---

3. 소스 코드 품질 분석 도구

 

• 소스 코드의 코딩 스타일, 코드에 설정된 코딩 표준, 코드의 복잡도, 코드에 존재하는 메모리 누수 현상, 스레드 결함 등을 발견하기 위해 사용하는 분석 도구로 크게 정적 분석도구와 동적 분석도구로 나뉨
• 정적 분석 도구
  
  • 작성한 소스 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인하는 코드 분석 도구
  • 비교적 애플리케이션 개발 초기의 결함을 찾는데 사용되고, 개발 완료 시점에서는 개발된 소스 코드의 품질을 검증하는 차원에서 사용됨
  • 자료 흐름이나 논리 흐름을 분석하여 비정상적인 패턴을 찾을 수 있음
  • 동적 분석 도구로는 발견하기 어려운 결함을 찾아내고 소스 코드에서 코딩의 복잡도, 모델 의존성, 불일치성 등을 분석할 수 있음
  • 종류 : pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등
• 동적 분석 도구
  
  
  • 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
  • 종류 : Avalanche, Valgrind 등

---

4.  소스 코드 품질 분석 도구의 종류

도구	설명	지원환경
pmd	미사용 변수, 최적화 되지 않은 코드 등 결함을 유발 할 수 있는 코드를 검사	Linux, Windows
cppcheck	C/C++ 코드에 대한 메모리 누수, 오버플로우 등 분석	Windows
SonarQube	중복 코드, 복잡도, 코딩 설계 등을 분석하는 소스 분석 통합 플랫폼	Cross-Platform
checkstyle	자바 코드에 대해 소스 코드 표준을 따르고 있는지 검사 다양한 개발 도구에 통합하여 사용 가능	Cross-Platform
ccm	다양한 언어의 코드 복잡도를 분석	Cross-Platform
cobertura	자바 언어의 소스 코드 복잡도 분석 및 테스트 커버리지를 측정	Cross-Platform
Avalanche	Valgrind 프레임워크 및 STP 기반으로 구현됨 프로그램에 대한 결함 및 취약점 등을 분석	Lunux, Android
Valgrind	프로그램 내에 존재하는 메모리 및 쓰레드 결함 등을 분석