[정처기 필기] 「2」 | 애플리케이션 테스트 관리 - (4.5) 복잡도, 애플리케이션 성능 개선

[정처기 필기] 「2」 | 애플리케이션 테스트 관리 - (4.5) 복잡도, 애플리케이션 성능 개선

「1」 소프트웨어 설계

> 「2」 소프트웨어 개발

- 데이터 입 / 출력 구현, 통합 구현, 제품 소프트웨어 패키징, > 애플리케이션 테스트 관리, 인터페이스 구현

「3」 데이터베이스 구축

「4」  프로그래밍 언어 활용

「5」  정보시스템 구축 관리

 

1 애플리케이션 테스트

2 애플리케이션 테스트의 분류

3 테스트 기법에 따른 애플리케이션 테스트

4 개발 단계에 따른 애플리케이션 테스트

5 통합 테스트

6 테스트 케이스 / 테스트 시나리오 / 테스트 오라클

7 테스트 자동화 도구

8 결함관리

> 9 복잡도

> 10 애플리케이션 성능 개선

9. 복잡도

복잡도(Complexity)의 개요

 

시스템 / 시스템 구성 요소 / 소프트웨어의 복잡한 정도이고 테스트 수준, 개발 자원 예측하는 데 사용

 

- 복잡도가 높으면 장애 발생 가능성, 정밀한 테스트를 통해 미리 오류 제거

- 복잡도 측정 방법에는 LOC(Line Of Code), 순환 복잡도(Cyclomatic Complexity)

 

시간 복잡도

 

알고리즘의 실행 시간, 프로세스가 수행하는 연산 횟수를 수치화 한 것

 

- 시간 복잡도가 낮을수록 알고리즘의 실행시간 짧고, 높을수록 실행시간 길어짐

- 알고리즘의 실행시간이 하드웨어 성능이나 프로그래밍 언어의 종류에 따라 달라지므로, 명령어의 실행 횟수 표기하는 점근 표기법 사용

 

- 점근 표기법의 종류

빅오 표기법(Big-O Notation)

: 알고리즘 실행시간이 최악일 때 표기

: 입력값에 대해 알고리즘 수행 시 명령어의 실행 횟수는 표기 수치보다 많을 수 없음

세타 표기법(Big-θ Notation)

: 알고리즘 실행 시간이 평균일 때 표기

: 입력 값에 대해 알고리즘 수행 시 명령어의 실행 횟수는 평균적인 수치를 표기

오메가 표기법(Big-Ω Notation)

: 알고리즘 실행 시간이 최상일 때 표기

: 입력 값에 대해 알고리즘 수행 시 명령어의 실행 횟수는 표기 수치보다 적을 수 없음

 

빅오 표기법(Big-O Notation)

 

알고리즘의 실행 시간이 최악일 때 표기, 신뢰성이 떨어지는 오메가 표기법이나 평가하기 까다로운 세타 표기법에 비해 성능 예측 용이

 

O(1)

: 입력값에 관계 없이 일정하게 문제 해결에 하나의 단계만 거침

: ex) 스택의 삽입(Push), 삭제(Pop)

O(log₂n)

: 문제 해결에 필요한 단계가 입력값(n) 또는 조건에 의해 감소

: ex) 이진트리(Binary Tree), 이진 검색(Binary Search)

O(n)

: 문제 해결에 필요한 단계가 입력값(n)과 1:1 관계

: ex) for문

O(nlog₂n)

: 문제 해결에 필요한 단계가 nlog₂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)

 

순환 복잡도

 

한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도이며 제어 흐름도 이론에 기초, == 맥케이브 순환도(McCabe's Cyclomatic)

 

- 프로그램의 독립적인 경로의 수를 정의, 모든 경로가 한번 이상 수행되었음을 보장하기 위해 테스트 횟수의 상한선 제공

- 제어 흐름도 G, 순환 복잡도 V(G), 화살표 수 E, 노드 수 E, 제어 흐름도의 영역 수 or V(G) = E - N + 2

 

↓ ←	← ← ←	← ← ←	← ← ←	← 1 ←	← ← ←	← ← ←	← ← ←	← ↑
↓				↓				↑
↓			↓ ←	← 2, 3 →	→ → →	→ ↓		↑
↓			↓			↓	영역 3	↑
↓		↓ ←	← 6 →	→ ↓		4, 5		↑
↓		7	영역 1	8	영역 2	↓		↑
↓		↓ →	→ 9 ←	← ↓		↓		↑
↓			↓			↓		↑
↓			↓ →	→ → →	→ → →	→ 10 →	→ → →	↑
↓		영역 4
↓ →	→ → →	→ → →	→ → →	→  11

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

소스 코드 최적화

 

나쁜 코드(Bad Code)를 배제, 클린 코드(Clean Code)로 작성

 

클린 코드(Clean Code)

: 누구나 쉽게 이해, 수정 / 추가할 수 있는 단순, 명료한 코드이며, 잘 작성된 코드

나쁜 코드(Bad Code)

: 프로그램 로직(Logic)이 복잡, 이해하기 어려운 코드로 스파게티 코드, 외계인 코드

: 스파게티 코드(Spaghetti Code) - 코드의 로직이 서로 복잡하게 얽혀 있는 코드

: 외계인 코드(Alien  Code) - 아주 오래되거나 참고문서 / 개발자가 없어 유지 보수 작업이 어려운 코드

 

- 클린 코드 작성 원칙

가독성

: 누구든지 코드를 쉽게 읽을 수 있도록 작성

: 이해하기 쉬운 용어 사용, 들여 쓰기 기능 사용

단순성

: 코드를 간단하게 작성

: 한 번에 한 가지 처리하도록 코드 작성, 클래스 / 메서드 / 함수 등 최소 단위로 분리

의존성 배제

: 코드가 다른 모듈에 미치는 영향 최소화

: 코드 변경 시 다른 부분에 영향가지 않도록 작성

중복성 최소화

: 코드의 중복을 최소화

: 중복된 코드 삭제, 공통된 코드 사용

추상화

: 상위 클래스에서 간략하게 애플리케이션 특징, 하위 클래스에서 상세 내용

 

소스 코드 최적화 유형

 

클래스 분할 배치

: 하나의 클래스는 하나의 역할만 수행, 응집도 높이고 크기를 작게 작성

느슨한 결합(Loosely Coupled)

: 인터페이스 클래스를 이용하여 추상화된 자료 구조, 메소드 구현하여 클래스 간 의존성 최소화

코딩 형식 준수

: 줄 바꿈 사용

: 개념적 유사성이 높은 종속 함수 사용

: 지역 변수는 각 함수의 맨 처음에 선언

좋은 이름 선언

: 변수나 함수 등 이름은 기억하기 좋은 이름, 발음이 쉬운 용어, 접두어 사용 등 명명 규칙(Naming Rule) 정의

적절한 주석문 사용

: 소스 코드 작성 시 해야 할 일 기록 / 중요한 코드 강조할 때 주석문 사용

 

소스 코드 품질 분석 도구

 

소스 코드의 코딩 스타일, 코드에 설정된 코딩 표준, 코드의 복잡도, 코드에 존재하는 메모리 누수 현상, 스레드 결함 등 발견하기 위해 사용하는 분석 도구

 

정적 분석 도구

: 소스 코드를 실행하지 않고, 코딩 표준, 코딩 스타일, 결함 등 확인

: 개발 초기 시점에 결함 찾을 때 사용, 개발 완료 시점에 개발된 소스 코드 품질 검증

: 자료 흐름, 논리 흐름 분석하여 비정상적인 패턴 찾음

: 동적 분석 도구로 발견하기 어려운 결함 찾고, 소스 코드에서 코딩의 복잡도, 모델 의존성, 불일치성 등 분석

: 소프트웨어적 방법 - pmd, cppcheck / 하드웨어적 방법 - SonarQube, checkstyle, ccm, cobertura

동적 분석 도구

: 소스 코드를 실행하여, 메모리 누수, 스레드 결함 등 분석

: Avalanche, Valgrind

 

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

 

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

 

 

 

 

 

 

 

 

출처 | <시나공> 정보처리기사 필기 2024 기본서 (길벗알앤디)