[정보처리기사 실기] 07. 애플리케이션 테스트 관리

애플리케이션 테스트 

• 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
• 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인하고, 소프트웨어가 기능을 정확히 수행하는지 검증
• 기본 원리
  • 완벽한 테스트 불가능 : 소프트웨어의 잠재적인 결함은 줄일 수 있지만, 소프트웨어에 결함이 없다고 증명할 수 없다.
  • 파레토 법칙(Pareto Principle) : 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙
  • 살충제 페러독스(Pesticide Paradox) : 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상
  • 테스팅은 정황(Context) 의존 :  소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 한다.
  • 오류-부재의 궤변(Absence of Errors Fallacy) : 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 질이 높다고 말할 수 없다는 것
  • 테스트와 위험은 반비례 : 테스트를 많이 하면 할수록 미래에 발생할 위험을 줄일 수 있다.
  • 테스트의 점진적 확대 : 테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야 한다.
  • 테스트의 별도 팀 수행 : 테스트는 개발자와 관계없이 별도의 팀에서 수행해야 한다.
• 분류
  • 프로그램 실행 여부에 따른 테스트
    • 정적 테스트 
      • 프로그램일 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트
      • 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위해 사용
      • 종류 : 워크스루, 인스펙션, 코드 검사 등
    • 동적 테스트
      • 프로그램을 실행하여 오류를 찾는 테스트
      • 소프트웨어 개발의 모든 단계에서 테스트를 수행
      • 종류 : 블랙박스 테스트, 화이트박스 테스트
  • 테스트 기반(Test Base)에 따른 테스트
    • 명세 기반 테스트
      • 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트
      • 종류 : 동등 분할, 경계값 분석 등
    • 구조 기반 테스트
      • 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
      • 종류 : 구문 기반, 결정 기반, 조건 기반 등
    • 경험 기반 테스트
      • 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트
      • 사용자의 요구사항에 대한 명세가 불충분하거나 테스트 시간에 제약이 있는 경우 수행하면 효과적
      • 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅
  • 시각에 따른 테스트
    • 검증(Verification) 테스트
      • 개발자의 시각에서 제품의 생산 과정을 테스트
      • 제품이 명세서대로 완성되었는지 테스트
    • 확인(Validation) 테스트 
      • 사용자의 시각에서 생산된 제품의 결과를 테스트
      • 사용자가 요구한대로 제품이 완성되었는지, 제품이 정상적으로 동작하는지 테스트
  • 목적에 따른 테스트
    • 회복(Recovery) : 시스템에 여러 가지 결함을 주어 실패하도록 한 후, 올바르게 복구되는지 확인하는 테스트
    • 안전(Security) : 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인하는 테스트
    • 강도(Stress) : 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지 확인하는 테스트
    • 성능(Performance) : 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트로, 소프트웨어의 응답 시간, 처리량 등을 테스트
    • 구조(Structure) : 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트
    • 회귀(Regression) : 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트
    • 병행(Parallel) : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트

 

 

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

 

화이트박스 테스트(White Box Test)

• 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
• 종류
  • 기초 경로 검사(Base Path Testing)
    • 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
    • 대표적인 화이트박스 테스트 기법
  • 제어 구조 검사(Control Structure Testing)
    
    • 조건 검사(Condition Testing) : 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스크 케이스 설계 기법
    • 루프 검사(Loop Testing) : 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
    • 데이터 흐름 검사(Data Flow Testing) : 프로그램에서 변수의 정의화 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
• 검증 종류
  • 구문/문장 커버리지(Statement Coverage)
    • 프로그램 내의 모든 명령문을 적어도 한 번 수행
  • 결정/선택 커버리지(Decision Coverage) 또는 분기 커버리지(Branch Coverage)
    • 프로그램 내 전체 결정문이 적어도 한 번은 참과 거짓의 결과를 수행
  • 조건 커버리지(Condition Coverage) 
    
    • 결정 명령문 내 각 조건이 적어도 한 번은 참과 거짓의 결과가 출력되도록 수행
  • 조건-결정 커버리지(Condition/Decision Coverage)
    
    • 전체 조건식 뿐 아니라 개별 조건식도 참, 거짓이 한 번씩 결과를 수행
  • 변경 조건/결정 커버리지(Modified Condition/Decision Coverage)
    
    • 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 독립적 영향을 주도록 수행
  • 다중 커버리지(Multiple Condition Corverage)
    • 결정 조건 내 모든 개별 조건식의 모든 조합을 고려

 

블랙박스 테스트(Black Box Test)

• 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트
• 사용자의 요구사항 명세를 보면서 테스트
• 주로 구현된 기능을 테스트, 기능 테스트라고도 한다.
• 종류
  • 동치 분할 검사(Equivalence Partitioning Testing)
    • 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 기법
    • 동등 분할 기법이라고도 한다.
  • 경계값 분석(Boundary Value Analysis)
    • 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조근의 경계값을 테스트 케이스로 선정하여 검사하는 기법
  • 원인-효과 그래프 검사(Cause-Effect Graphing Testing)
    • 입력 데이터 간의 관계의 출력에 영향을 미치는 상황을 체계적으로 분석한 다음, 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
  • 오류 예측 검사(Error Guessing)
    • 과거의 경험이나 확인자의 감각으로 테스트하는 기법
  • 비교 검사(Comparison Testing)
    • 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법

 

 

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

• 소프트웨어 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류
• 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것을 V-모델 이라고 한다.
• 종류
  • 단위 테스트(Unit Test)
    • 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞추어 테스트
    • 인터페이스, 외부적 I/O, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등 검사
    • 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 수행
    • 구조 기반 테스트와 명세 기반 테스트로 나뉜다.
  • 통합 테스트(Integration Test)
    • 단위 테스트가 완료된 모듈을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
    • 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류 검사
  • 시스템 테스트(System Test)
    • 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
    • 기능적 요구사항과 비기능적 요구사항으로 구분하여 각각을 만족하는지 테스트
  • 인수 테스트(Acceptance Test)
    • 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법
    • 사용자가 직접 테스트
    • 종류
      • 사용자 인수 테스트 : 사용자가 시스템 사용의 적절성 여부를 확인
      • 운영상의 인수 테스트 : 시스템 관리자가 시스템 인수 시 수행하는 테스트 기법
      • 계약 인수 테스트 : 계약상의 인수/검수 조건을 준수하는지 여부 확인
      • 규정 인수 테스트 : 소프트웨어가 정부 지침, 법규, 규정 등 규정에 맞게 개발되었는지 확인
      • 알파 테스트 
        • 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법
        • 테스트는 통제된 환경에서 진행되며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하며 기록
      • 베타 테스트
        • 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법
        • 실업무를 가지고 사용자가 직접 테스트

 

 

통합 테스트(Integration Test)

• 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
• 종류 
  • 비점진적 통합 방식
    • 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법
    • 종류 : 빅뱅 통합 테스트 방식
  • 점진적 통합 방식
    • 모듈 단위로 단계적으로 통합하면서 테스트하는 방법
    • 종류 : 하향식 통합 테스트, 상향식 통합 테스트, 혼합식 통합 테스트

 

하향식 통합 테스트(Top Down Integration Test)

• 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
• 깊이 우선 통합법 또는 넓이 우선 통합법 사용
  • 깊이 우선 통합법 : 주요 제어 모듈을 중심으로 해당 모듈에 종속된 모든 모듈을 통합하는 것
  • 넓이 우선 통합법 : 구조의 수평을 중심으로 해당하는 모듈을 통합하는 것
• 절차 
  1. 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁(Stub)으로 대체
     • 스텁(Stub) : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
  2. 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체
  3. 모듈이 통합될 때마다 테스트 실시
  4. 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트 실시

 

상향식 통합 테스트(Bottom Up Integration Test)

• 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법
• 절차
  1. 하위 모듈들을 클러스터(Cluster)로 결합
  2. 상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버(Driver)를 작성
     • 드라이버(Driver) : 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고 모듈 테스트 수행 후 결과를 도출하는 도구
  3. 통합된 클러스터 단위로 테스트
  4. 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고, 드라이버는 실제 모듈로 대체

 

혼합식 통합 테스트

• 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식
• 샌드위치(Sandwich)식 통합 테스트 방법이라고도 한다.

 

회귀 테스트(Regression Testing)

• 통합 테스트로 인해 변경될 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트
• 이미 테스트된 프로그램의 테스팅을 반복
• 수정한 모듈이나 컴포넌트가 다른 부분에 영향을 미치는지, 오류가 생기지 않았는지 테스트하여 새로운 오류가 발생하지 않음을 보증하기 위해 반복 테스트

 

 

애플리케이션 테스트 프로세스

• 개발된 소프트웨어가 사용자의 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차
• 순서
  1. 테스트 계획 : 프로젝트 계획서, 요구 명세서 등을 기반으로 테스트 목표를 정의하고 테스트 대상 및 범위를 결정
  2. 테스트 분석 및 디자인 : 테스트 목적과 원칙을 검토하고 사용자의 요구 사항 분석
  3. 테스트 케이스 및 시나리오 작성 : 테스트 케이스를 작성하고, 검토하고 확인한 다음 테스트 시나이로 작성
  4. 테스트 수행 : 테스트 환경을 구축한 후, 테스트 수행
  5. 테스트 결과 평가 및 리포팅 : 테스트 결과를 비교 분석하여 테스트 결과를 작성
  6. 결함 추적 및 관리 : 테스트한 후, 결함 발생 위치나 종류 등 결함을 추적 및 관리

 

결함 관리 프로세스

1. 에러 발견 : 에러가 발견되면 테스트 전문가와 프로젝트 팀이 논의
2. 에러 등록 : 발견된 에러를 결함 관리 대장 등록
3. 에러 분석 : 등록된 에러가 실제 결함인지 아닌지 분석
4. 결함 확정 : 등록된 에러가 실제 결함이면 결함 확정 상태로 설정
5. 결함 할당 : 결함을 해결할 담당자에게 결함을 할당하고, 결함 할당 상태로 설정
6. 결함 조치 : 결함을 수정하고, 수정이 완료되면 결함 조치 상태로 설정
7. 결함 조치 검토 및 승인 : 수정이 완료된 결함에 대해 확인 테스트를 수행하고, 이상이 없으면 결함 조치 완료 상태로 설정

 

테스트 케이스(Test Case)

• 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수 했는지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서
• 테스트 케이스를 미리 설계하면 테스트 오류 방지, 테스트 수행에 필요한 인력, 시간 등의 자원 낭비를 줄일 수 있다.

 

테스트 시나리오(Test Scenario)

• 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스를 묶은 집합
• 테스트 케이스를 적용하는 구체적인 절차를 명세
• 테스트 순서에 대한 구체적인 절차, 사전 조건, 입력 데이터 등이 설정

 

테스트 오라클(Test Oracle)

• 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참값을 대입하여 비교하는 기법 및 활동
• 결과를 판단하기 위해 테스트 케이스에 대한 예상 결과를 계산하거나 확인
• 특징
  • 제한된 검증 : 테스트 오라클을 모든 테스트 케이스에 적용할 수 있다.
  • 수학적 기법 : 테스트 오라클의 값을 수학적 기법을 이용하여 구할 수 있다.
  • 자동화 기능 : 테스트 대상 프로그램의 실행, 결과 비교, 커버리지 측정 등을 자동화 할 수 있다.
• 종류
  • 참(True) 오라클
    • 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클
    • 발생된 모든 오류를 검출할 수 있음
  • 샘플링(Sampling) 오라클
    • 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클로, 전수 테스트가 불가능한 경우 사용
  • 추정(Heuristic) 오라클
    • 특정 테스트 케이스 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클
  • 일관성 검사(Consistent) 오라클
    • 애플리케이션에 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클

 

 

테스트 자동화 도구

• 테스트 자동화 : 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함으로써 쉽고 효율적으로 테스트를 수행할 수 있도록 한 것
• 종류
  • 정적 분석 도구(Static Analysis Tools)
    • 프로그램을 실행하지 않고 분석하는 도구
    • 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함
  • 테스트 실행 도구(Test Excution Tools)
    • 스크립트 언어를 사용하여 테스트를 실행하는 도구
    • 테스트 데이터와 테스트 수행 방법 등이 포함된 스크립트를 작성한 후 실행
    • 방식
      • 데이터 주도 접근 방식 : 스프레드시트에 테스트 데이터를 저장하고, 이를 읽어 실행하는 방식
      • 키워드 주도 접근 방식 : 스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 저장하여 실행하는 방식
  • 성능 테스트 도구(Performance Test Tools)
    • 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인하는 도구
  • 테스트 통제 도구(Test Control Tools)
    
    • 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 구행하는 도구
    • 종류 : 형상 관리 도구, 결함 추적/관리 도구 등
  • 테스트 하네스 도구(Test Harness Tools)
    
    • 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구
    • 테스트 하네스(Test Harness)
      • 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분
      • 테스트를 지원하기 위해 생성된 코드와 데이터를 의미
      • 종류
        • 테스트 드라이버(Test Driver) : 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
        • 테스트 스텁(Test Stub) : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트 모듈
        • 테스트 슈트(Test Suites) : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
        • 테스트 케이스(Test Case) : 사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서
        • 테스트 스크립트(Test Script) : 자동화된 테스트 실행 절차에 대한 명세서
        • 목 오브젝트(Mock Object) : 사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체

 

 

결함(Fault)

• 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것
• 사용자가 예상한 결과와 실행 결과 간의 차이나 업무 내용과의 불일치 등으로 인해 변경이 필요한 부분도 모두 결함에 해당
• 결함 관리 프로세스
  1. 결함 관리 계획 : 전체 프로세스에 대한 결함 관리 일정, 인력, 업무 프로세스 등을 확보하여 계획 수립
  2. 결함 기록 : 테스터는 발견된 결함을 결함 관리 DB에 등록
  3. 결함 검토 : 테스트, 프로그램 리더, 품질 관리(QA) 담당자 등은 등록된 결함 검토 및 결함을 수정할 개발자에게 전달
  4. 결함 수정 : 개발자는 전달받은 결함 수정
  5. 결함 재확인 : 테스터는 개발자가 수정한 내용을 확인하고 다시 테스트를 수행
  6. 결함 상태 추적 및 모니터링 활동 : 결함 관리 DB를 이용하여 프로젝트별 결함 유형, 발생률 등을 한눈에 볼 수 있는 대시보드 또는 게시판 형태의 서비스 제공
  7. 최종 결함 분석 및 보고서 작성 : 발견된 결함에 대한 정보와 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리를 종료

 

결함 상태 추적

• 테스트에서 발견한 결함은 지속적으로 상태 변화를 추적하고 관리해야 한다.
• 발견된 결함에 대해 결함 관리 측정 지표의 속성 값들을 분석하여 향후 결함이 발견될 모듈 또는 컴포넌트를 추정할 수 있다.
• 결함 관리 측정 지표
  • 결함 분호 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
  • 결함 추세 : 테스트 진행 시간에 따른 결함 수의 추이 분석
  • 결함 에이징 : 특정 결함 상태로 지속되는 시간 측정
• 순서
  1. 결함 등록(Open) : 테스터와 품질 관리(QA) 담당자에 의해 발견된 결함이 등록된 상태
  2. 결함 검토(Reviewed) : 등록된 결함이 테스터, 품질 관리(QA) 담당자, 프로그램 리더, 담당 모듈 개발자에 의해 검토된 상태
  3. 결함 할당(Assigned) : 결함을 수정하기 위해 개발자와 문제 해결 담당자에게 결함이 할당된 상태
  4. 결함 수정(Resolved) : 개발자가 결함 수정을 완료한 상태
  5. 결함 조치 보류(Deferred) : 결함의 수정이 불가능해 연기된 상태로, 우선순위, 일정 등에 따라 재오픈을 준비중인 상태
  6. 결함 종료(Closed) : 결함이 해결되어 테스터와 품질 관리(QA) 담당자가 종료를 승인한 상태
  7. 결함 해제(Clarified) : 테스터, 프로그램 리더, 품질 관리(QA) 담당자가 종료 승인한 결함을 검토하여 결함이 아니라고 판명한 상태

 

결함 심각도

• 애플리케이션에 발생한 결함이 전체 시스템에 미치는 치명도를 나타내는 적도
• 치명적(Critical), 주요(Major), 보통(Normal), 경미(Minor), 단순(Simple) 또는 High, Medium, Low 등으로 분류

 

결함 우선수위

• 발견된 결함 처리에 신속성을 나타내는 척도
• 결함의 중요도와 심각도에 따라 설정되고, 수정 여부가 결정
• 결정적(Critical), 높은(High), 보통(Medium), 낮음(Low) 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류

 

결함 관리 도구

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

 

 

애플리케이션 성능 분석

• 애플리케이션 성능 : 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도
• 성능 측정 지표
  • 처리량(Throughput) : 일정 시간 내에 애플리케이션이 처리하는 일의 양
  • 응답 시간(Response Time) : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
  • 결과 시간(Turn Around Time) : 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간
  • 자원 사용률(Resource Usage) : 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률

 

성능 테스트 도구

• 애플리케이션의 성능을 테스트하기 위해 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검하는 도구
• 부하(Load) 테스트 : 애플리케이션에 일정 시간 동안 부하를 가하면서 반응을 측정하는 테스트
• 스트레스(Stress) 테스트 : 부하 테스트를 확장한 테스트로, 애플리케이션이 과부화 상태에서 어떻게 작동하는지 테스트
• 종류
  • JMeter : HTTP, FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구
  • LoadUI : 서버 모니터링, Drag & Drop 등 사용자의 편리성이 강화된 부하 테스트 도구
  • OpenSTA : HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구

 

시스템 모니터링(Monitoring) 도구

• 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
• 종류
  • Scouter : 애플리케이션의 성능을 모니터링/통제하는 도구
  • Zabbix : 웹기반 서버, 서비스, 애플리케이션 등의 모니터링 도구

 

 

 

복잡도(Complexity)

• 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말
• 시스템 또는 소프트웨어를 어느 정도의 수준까지 테스트해야 하는지 또는 개발하는 데 어느 정도의 자원이 소요되는지 예측하는 데 사용된다.

 

시간 복잡도

• 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것
• 시간 복잡도가 낮을수록 알고리즘의 실행 시간이 짧고, 높을수록 실행 시간이 길어진다.
• 접근 표기법의 종류
  • 빅오 표기법(Big-O Notation)
    • 알고리즘의 실행 시간이 최악일 때를 표기하는 방법
    • 입력 값에 대해 알고리즘을 수행했을 때, 명령어의 실행 횟수는 어떠한 경우에도 표기 수치보다 많을 수 없다.
  • 세타 표기법(Big-Θ Notation)
    • 알고리즘의 실행 시간이 평균일 때를 표기하는 방법
    • 입력 값에 대해 알고리즘을 수행했을 때, 명령어의 실행 횟수는 평균적인 수치를 표기한다.
  • 오메가 표기법(Big-Ω Notation) 
    • 알고리즘의 실행 시간이 최상일 때를 표기하는 방법
    • 입력 값에 대해 알고리즘을 수행했을 때, 명령어의 실행 횟수는 어떠한 경우에도 표기 수치보다 적을 수 없다.

 

순환 복잡도(Cyclomatic Complexity)

• 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도
• 맥케이브 순환도(McCabe's Cyclomatic) 또는 멕케이브 복잡도 메트릭(McCabe's Complexity Metrics)라고도 한다.
• 제어 흐름도 이론에 기초를 둔다.
• 제어 흐름도 G에서 순환 복잡도 V(G) 계산 방법
  1. 순환 복잡도는 제어 흐름도의 영역 수와 일치하므로 영역 수 계산
  2. V(G) = E - N + 2 (E: 화살표 수, N: 노드 수)

 

 

애플리케이션 성능 개선

• 나쁜 코드(Bad Code)를 배제하고, 클린 코드(Clean Code)로 작성
  • 클린 코드(Clean Code) : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드
  • 나쁜 코드(Bad Code) : 프로그램의 로직이 복잡하고 이해하기 어려운 코드
    • 스파게티 코드 : 코드의 로직이 서로 복잡하게 얽혀 있는 코드
    • 외계인 코드 : 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드

 

클린 코드 작성 원칙

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

 

소스 코드 품질 분석 도구

• 코딩 스타일, 코드에 설정된 코딩 표준, 코드의 복잡도, 코드에 존재하는 메모리 누수 현상, 스레드 결함 등을 발견하기 위해 사용하는 분석 도구
• 종류
  • 정적 분석 도구 
    • 작성한 소스 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인하는 코드 분석 도구
    • 종류 : pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등
  • 동적 분석 도구
    • 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
    • 종류 : Avalanche, Valgrind 등