2. 소프트웨어 개발 - 애플리케이션 테스트 관리(결함 관리 ~ 애플리케이션 성능 개선)

61. 결함 관리

1) 결함

: 소프트웨어가 개발자가 설계한 것과 또는 사용자가 기대한 것과 다르게 동작하거나 다른 결과를 발생시키는 것

• 업무 내용 불일치 등으로 변경이 필요한 부분 역시 결함에 포함

 

- 결함의 분류

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

 

- 결함의 심각도

: 발생한 결함이 전체 시스템에 미치는 치명도. 우선순위에 따라 High, Medium, Low로 분류

• High : 핵심 기능 미구현, 장기간 응답 지연, 시스템 다운 등 더 이상 프로세스를 진행할 수 잆도록 하는 결함
• Medium : 부정확한 기능, DB 에러 등 시스템 흐름에 영향을 미치는 결함
• Low : 부정확한 GUI나 메시지, 문법 및 철자 오류 등 시스템 흐름에는 영향을 미치지 않는 결함

※ 다른 기준에 따라 치명적(Critical), 주요(Major), 보통(Normal), 경미(Minor), 단순(Simple) 등으로 분류하기도 함

 

- 결함의 우선순위

: 발견된 결함 처리에 대한 시급성, 신속성을 나타내는 척도. 결함의 중요도와 심각도에 따라 결정됨

• 일반적으로 결함의 심각도가 높으면 우선순위도 높음
• 결정적(Critical) / 높음(High) / 보통(Medium) / 낮음(Low)
• 즉시 해결 / 주의 요망 / 대기 / 개선 권고

 

2) 결함 관리 프로세스

: 애플리케이션 테스트에서 발견된 결함으로 처리하고 관리하는 과정

• 테스트에서 발견된 결함을 기록하고, 그 원인을 분석하여 해결한 뒤, 재발생을 방지하는 모든 활동이 포함

결함 관리 프로세스 흐름도

1. 결함 관리 계획 : 결함 관리 일정, 인력, 업무 프로세스 등을 확보하고 계획을 수립
2. 결함 기록 : 테스터가 발견된 결함을 결함 관리 DB에 등록
3. 결함 검토 : 테스터와 담당자들이 등록된 결함을 검토하고 이를 수정할 개발자에게 할당
4. 결함 수정 : 개발자가 결함을 할당 받아 수정
5. 결함 재확인 : 테스터는 개발자가 수정한 내용을 확인하고 테스트를 재수행
6. 결함 상태 추적 및 모니터링 : 결함 관리 DB를 이용해 대시보드, 게시판 등으로 결함 상태 모니터링 서비스를 제공
7. 최종 결함 분석 및 보고서 작성 : 발견된 결함에 대한 보고서를 작성하고 결함 관리 종료

 

※ 결함 상태 추적 : 발견된 결함의 상태 변화를 지속적으로 추적하고 관리하는 활동

• 결함에 대한 결함 관리 측정 지표를 분석하여 향후 결함이 발견될만한 모듈이나 컴포턴트를 추정할 수 있음
  • 결함 분포 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 분포 상황
  • 결함 추세 : 테스트 진행 시간에 따른 결함 수의 추이
  • 결함 에이징 : 특정 결함 상태로 지속되는 시간

 

3) 결함 추적 순서

: 결함이 발견된 때부터 해결될 때까지의 전 과정을 추적하는 것

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

 

4) 결함 관리 도구

: 소프트웨어에서 발생한 결함에 대한 체계적 관리를 지원하는 도구

https://youtu.be/0zJecwIvBAM

결함 관리 도구 중 하나인 Redmine의 프로젝트 관리 기능 소개 영상

• Mantis : 결함 및 이슈 관리 도구. 소프트웨어 설계 시 단위별 작업 내용 기록을 통해 결함 추적이 가능
• Trac : 결함 추적 및 관리 도구
• Redmine : 프로젝트 관리 및 결함 추적 도구
• Bugzilla : 결함을 지속적으로 관리하는 도구. 결함의 심각도와 우선순위 지정 가능

---

62. 애플리케이션 성능

: 애플리케이션이 최소한의 자원을 이용해 사용자가 요구한 최대한 많은 기능을 신속하게 처리하는 정도

 

- 성능 측정 지표

• 처리량 (Throughput) : 애플리케이션이 일정 시간 동안 처리하는 일의 양
• 응답 시간 (Response Time) : 애플리케이션에 요청을 전달하고 응답이 도착하기까지 걸린 시간
• 경과 시간 (Turnaround Time) : 애플리케이션에 작업을 의뢰하고 처리가 완료되기까지 걸린 시간
• 자원 사용률 (Resource Usage) : 애플리케이션이 작업을 처리하는 동안 사용된 자원의 비율

 

- 성능 분석 도구 : 성능을 테스트하는 도구와 시스템을 모니터링하는 도구로 분류

• 성능 테스트 도구 : 애플리케이션 성능 테스트를 위해 부하나 스트레스를 가하면서 성능 측정 지표를 점검하는 도구
  • 부하 테스트 : 애플리케이션에 일정 시간동안 부하를 가하면서 반응을 측정
  • 스트레스 테스트 : 부하 테스트를 확장하여 과부하상태에서 어떻게 작동하는지 테스트
  • ex) JMeter, LoadUI, OpenSTA
• 시스템 모니터링 도구 : 애플리케이션 실행 시 시스템 자원의 사용량을 확인하고 분석하는 도구
  • 성능 저하의 원인 분석, 시스템 부하량 분석, 사용자 분석 등의 기능 제공
  • ex) Scouter, Zabbix

 

※ 애플리케이션 성능 저하의 주요 원인

: DB연결을 위한 Connection 객체의 생성이나 쿼리 실행에서 주로 발생

• DB에 필요 이상의 많은 데이터를 요청함
• DB의 Lock이 해제되기를 기다리며 대기상태나 타임아웃이 됨
• 커넥션 풀의 크기가 너무 작거나 너무 큼
• 미들웨어 사용 후 종료를 하지 않아서 연결 누수가 발생함
• 트랜잭션이 Commit 되지 않고 반환되거나 불필요한 Commit이 자주 발생
• 인터넷 접속 불량으로 서버 소켓에 쓰기는 계속되나 읽기가 수행되지 않음
• 대량의 파일을 업로드/다운로드하여 처리 시간이 길어짐
• 트랜잭션 처리 중 외부 호출이 장시간 수행됨
• 네트워크 관련 장비 간 데이터 전송 실패 또는 전송 지연으로 인한 데이터 손실

---

63. 복잡도

: 시스템 및 시스템 구성 요소의 복잡한 정도

• 시스템을 어느 정도 수준까지 테스트해야하는지, 개발에 얼마의 자원이 소모되는지 예측하는데 사용
• ex) LOC(Line of Code), 순환 복잡도(Cyclomatic Complexity), 시간 복잡도(Time Complexity), 공간 복잡도(Space Complexity), etc.

 

1) 시간 복잡도

: 알고리즘의 실행시간 또는 프로세스 수행에 필요한 연산 횟수를 수치화한 것

• 시간 복잡도가 낮을수록 알고리즘의 실행시간이 짧고, 필요한 연산이 적다

- 점근 표기법

: 알고리즘의 실행시간은 하드웨어 성능이나 사용된 프로그래밍 언어에 따라 달라지므로 대신 명령어의 실행횟수로 시간 복잡도를 나타낸 것

• 빅오 표기법 : 알고리즘의 실행시간이 최대(최악)일 때를 표기
• 세타 표기법 : 알고리즘의 실행시간이 평균치일 때를 표기
• 오메가 표기법 : 알고리즘의 실행시간이 최소(최적)일 때를 표기

※ 명령어의 실행 횟수

오메가 표기법의 수치 ≤ 세타 표기법의 수치 ≤ 빅오 표기법의 수치

 

2) 순환 복잡도

: 시스템의 논리적인 복잡도를 측정하는 척도. 제어 흐름도 이론에 기초를 두어 측정함

(맥케이브 순환도, 맥케이브 복잡도 메트릭)

• 프로그램의 독립적인 경로의 수를 정의하고 모든 경로가 한 번 이상 수행됨을 보장하는 테스트의 횟수 상한선을 제공
• 제어 흐름도 G의 순환 복잡도 V(G)는 다음과 같이 측정

V(G) = E - N + 2 (E는 화살표의 개수, N은 노드의 개수)
또는
V(G) = R (R은 노드와 화살표로 나뉜 영역의 수)
또는
V(G) = P + 1 (P는 분기(if, for, while, try 등)의 수)

---

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

1) 소스 코드 최적화

: 나쁜 코드(Bad code)를 배제하고 클린 코드(Clean code)로 작성해 애플리케이션 성능을 개선하는 것

• 나쁜 코드 : 로직이 복잡하고 이해하기 어려운 코드
  • 외계인 코드 : 아주 오래되거나 참고문서 또는 관련 개발자가 없어 유지보수가 어려운 코드
  • 스파게티 코드 : 로직이 너무 복잡하게 얽혀있는 코드
• 클린 코드 : 누구나 쉽게 이해, 수정, 추가할 수 있는 단순하고 명료한 코드
  • 가독성 : 이해하기 쉬운 용어나 들여쓰기를 사용해 누구나 쉽게 읽을 수 있다
  • 단순성 : 클래스/메소드 등이 최소 단위로 분리되어 한번에 한 가지를 처리하도록 간단하게 작성되어있다
  • 의존성 배제 : 코드가 다른 모듈에 미치는 영향이 거의 없다
  • 중복성 최소화 : 코드의 중복을 최소화하고 공통된 코드를 사용한다
  • 추상화 : 상위 클래스/메소드는 간략하게 특성을 나타내고 하위 클래스/메소드에서 상세 내용을 구현한다

 

 - 소스코드 최적화 유형

• 클래스 분할 배치 : 하나의 클래스는 하나의 역할만 수행하여 응집도가 높고 크기는 작다
• 느슨한 결함 (Loosely Coupled) : 인터페이스 클래스를 이용해 클래스 간 의존성을 최소화한다
• 코딩 형식 준수 : 줄 바꿈, 함수나 변수의 선언 위치 등에서 형식을 준수한다
• 명명 규칙 사용 : 변수나 함수의 이름을 정할 때 이해와 기억이 쉽도록 규칙을 정하고 이를 준수한다
• 적절한 주석 사용 : 해야할 일 기록이나 코드의 설명 및 강조에 주석문을 사용한다

 

2) 소스 코드 품질 분석 도구

: 코드의 스타일과 표준, 코드 복잡도, 코드 상 메모리 누수, 스레드 결함 등을 발견하기 위해 사용하는 도구

정적 분석 도구	- 코드 실행 없이 코드의 표준, 스타일, 결함 등을 확인하는 분석 도구 - 자료나 논리의 흐름을 분석하여 비정상적인 패턴 발견 - 개발 초기에 결함을 찾는데 이용 - 개발 완료 시점에서는 코드의 품질 검증 차원에서 이용 - 동적 분석 도구로는 발견하기 어려운 결함 확인이 가능 - ex) pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura, etc.
동적 분석 도구	- 코드를 실행하여 메모리 누수, 스레드 결함 등을 분석하는 도구 - ex) Avalanche, valgrind, etc.