본문에 오류가 있을 수 있음을 감안하고 봐주시길 바랍니다.
# 문제 풀이 중 오답노트 하면서 나온 내용을 정리한 것
결함(Fault): 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것을 의미한다.
- 결함 관리 절차: 결함 관리 계획 → 결함 기록 → 결함 검토 → 결함 수정 → 결함 재확인 → 결함 상태 추적 및 모니터링 활동 → 최종 결함 분석 및 보고서 작성
- 결함 관리 측정 지표: 결함 분포(모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정), 결함 추세(테스트 진행 시간에 따른 결함 수의 추이 분석), 결함 에이징(특정 결함 상태로 지속되는 시간 측정)
- 결함 추적 순서: 결함 등록(Open)→ 결함 검토(Reviewed) → 결함 할당(Assigned) → 결함 수정(Resolved) → 결함 조치 보류(Deferred) → 결함 종료(Closed) → 결함 해제(Clarified)
- 결함 분류: 시스템 결함, 기능 결함, GUI 결함, 문서 결함
- 결함 심각도: 애플리케이션에 발생한 결함이 전체 시스템에 미치는 치명도를 나타내는 척도이다. High·Medium·Low 또는 치명적·주요·보통·경미·단순 등으로 분류된다.
- 결함 우선순위: 발견된 결함 처리에 신속성을 나타내는 척도이다. 결함의 중요도와 심각도에 따라 결정되고 수정 여부가 결정된다. 결정적·높음·보통·낮음 또는 즉시 해결·주의 요망·대기·개선 권고 등으로 분류된다.
- 결함 관리 도구
- Mantis: 결함 및 이슈 관리 도구로 소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 추적도 가능한 도구
- Trac: 결함 추적은 물론 결함을 통합하여 관리할 수 있는 도구
- Redmine: 프로젝트 관리 및 결함 추적이 가능한 도구
- Bugzilla: 결함 신고·확인·처리 등 결함을 지속적으로 관리할 수 있는 도구, 결함의 심각도와 우선순위를 지정할 수 있다.
애플리케이션 성능: 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도를 나타낸다.
- 애플리케이션 성능 측정 지표(소프트웨어 설계 시 구축된 플랫폼의 성능 특성 분석에 사용되는 측정 항목들)
| 지표 | 설명 |
| 처리량(Throughput) | 일정 시간 내에 애플리케이션이 처리하는 일의 양 |
| 응답 시간(Response Time) | 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간 |
| 경과 시간(Turn Around Time) | 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간 |
| 자원 사용률(Resource Usage) | 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률 |
- 애플리케이션 성능 테스트 도구
| 도구 | 설명 | 지원 환경 |
| JMeter | HTTP, FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구 | Cross-Platform |
| LoadUI | · 서버 모니터링, Drag&Drop 등 사용자의 편리성이 강화된 부하 테스트 도구 · HTTP, JDBC 등 다양한 프로토콜 지원 |
Cross-Platform |
| OpenSTA | HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구 | Windows |
시스템 모니터링(Monitoring) 도구: 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
| 도구 | 설명 | 지원 환경 |
| Scouter | · 단일 뷰 통합/ 실시간 모니터링, 튜닝에 최적화된 인프라 통합 모니터링 도구 · 애플리케이션의 성능을 모니터링/통제하는 도구 |
Cross-Platform |
| Zabbix | 웹 기반 서버, 서비스, 애플리케이션 등의 모니터링 도구 | Cross-Platform |
복잡도: 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말이다. 시스템 또는 소프트웨어를 어느 정도의 수준까지 테스트해야 하는지 또는 개발하는 데 어느 정도의 자원이 소요되는지 예측하는 데 사용된다.
시간 복잡도: 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것을 의미한다. 시간 복잡도가 낮을수록 알고리즘의 실행 시간이 짧고 높을수록 실행시간이 길어진다.
- 빅오 표기법(Big-O Notation): 알고리즘의 실행시간이 최악일 때를 표기하는 방법
- O(1): 입력값(n)에 관계 없이 일정하게 문제 해결에 하나의 단계만을 거침(예: 스택의 삽입, 삭제)
- O(log₂n): 문제 해결에 필요한 단계가 입력값(n) 또는 조건에 의해 감소함(예: 이진 트리, 이진 검색)
- O(n): 문제 해결에 필요한 단계가 입력값(n)과 1:1의 관계를 가짐(예: for문)
- O(nlog₂n): 문제 해결에 피룡한 단계가 n(log₂n)번만큼 수행됨(예: 힙 정렬, 2-way 합병 정렬)
- O(n²): 문제 해결에 피룡한 단계가 입력값(n)의 제곱만큼 수행됨(예: 삽입 정렬, 쉘 정렬, 선택 정렬, 버블 정렬, 퀵 정렬)
- O(2ⁿ): 문제 해결에 필요한 단계가 2의 입력값(n) 제곱만큼 수행됨(예: 피보나치 수열)
- 세타 표기법(Big-Θ Notation): 알고리즘의 실행시간이 평균일 때를 표기하는 방법
- 오메가 표기법(Big-Ω Notation): 알고리즘의 실행시간이 최상일 때를 표기하는 방법
순환 복잡도(Cyclomatic Complexity): 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도이다. 맥케이브 순환도 또는 맥케이브 복잡도 메트릭이라고도 한다. 제어 흐름도 이론에 기초를 둔다.

소스 코드 최적화: 나쁜 코드(Bad Code)를 배제하고 클린 코드(Clean Code)로 작성하는 것이다.
- 클린 코드(Clean Code): 누구나 쉽게 이해하고 수정 및 추가할 수 잇는 단순 명료한 코드, 즉 잘 작성된 코드
- 클린 코드 작성 원칙: 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화
- 나쁜 코드(Bad Code): 프로그램의 로직(Logic)이 복잡하고 이해하기 어려운 코드
- 스파게티 코드: 코드의 로직이 서로 복잡하게 얽혀 있는 코드
- 외계인 코드: 아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
- 소스코드 최적화 유형
- 클래스 분할 배치: 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고 크기를 작게 작성함
- 느슨한 결합(Loosely Coupled): 인터페이스 클래스를 이용하여 추상화된 자료 구조와 메서드를 구현함으로써 클래스 간의 의존성을 최소화함
소스 코드 품질 분석 도구
- 정적 분석 도구: 작성한 소스 코드를 실행하지 않고 코딩 표준, 코딩 스타일, 결함 등을 확인하는 코드 분석 도구
- 동적 분석 도구: 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
| 도구 | 구분 | 설명 | 지원 환경 |
| 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 | |
| valMeter | 프로그램이 돌아가면서 발생하는 메모리 누수(Memory Leak)나 스레드 결함 등을 실시간으로 추적하고 분석 | Cross-Platform |
코드 커버리지 분석 도구: Cobertura, Jacoco, Clover 등
코드 검사(Code Inspection) 주요 오류 항목
- 데이터 오류(DA, Data Error): 데이터 유형 정의, 변수 선언, 매개 변수 전달 등 데이터 자체의 취급에서 나타나는 오류
- 기능 오류(FN, Function Error): 서브루틴이나 블록이 요구사항과 전혀 다른, 잘못된 목적(What)을 수행하는 오류
- 논리 오류(LO, Logic Error): 수행해야 할 목적은 맞지만 서브루틴이나 블록이 처리하는 알고리즘이나 방법(How)이 잘못 구현된 오류
- 성능 오류(PF, Performance Error): 프로그램의 기능과 논리는 정상적으로 동작하지만 시스템이 요구하는 처리 속도나 메모리 기준 등을 만족시키지 못하는 오류
- 문서 오류(DC, Documentation Error): 프로그램의 실제 동작에는 영향을 주지 않지만 선언 부분이나 주석 등이 코드의 실제 로직과 다르거나 불필요하게 작성된 오류
이진 검색(이분 검색, Binary Search): 전체 파일을 두 개의 서브파일로 분리해 가면서 Key 레코드를 검색하는 방식이다. 반드시 순서환된 파일이어야 검색할 수 있다. 중간 레코드 Key 값과 비교하면서 검색한다.

'정보처리기사' 카테고리의 다른 글
| [정보처리기사 요약 9-1] Secure SDLC와 시큐어 코딩 주요 보안 약점 총정리 (0) | 2026.02.28 |
|---|---|
| [정보처리기사 요약 8] 데이터베이스 SQL 완벽 가이드 (JOIN, 트리거 활용법 포함) (0) | 2026.02.28 |
| [정보처리기사 요약 7-2] 애플리케이션 테스트 레벨과 V-모델 정리 (0) | 2026.02.27 |
| [정보처리기사 요약 7-1] 애플리케이션 테스트의 기본 원리와 종류 총정리 (0) | 2026.02.27 |
| [정보처리기사 요약 6] UI 시나리오 문서 요건부터 ISO/IEC 9126 품질 특성 (0) | 2026.02.27 |