주제

소개 페이지 맨 위

테스트의 핵심 측정사항에는 커버리지와 품질이 포함됩니다.

테스트 커버리지는 완전성 테스트의 측정사항이며 테스트 요구사항 및 테스트 케이스의 커버리지 또는 실행된 코드 커버리지로 표현되는 테스트 커버리지에 근거합니다.

품질은 테스트 대상(시스템 또는 테스트 중인 어플리케이션)의 신뢰성, 안정성 및 성능에 대한 측정입니다. 품질은 테스트 중에 식별된 변경 요청(결함)에 대한 분석 및 테스트 결과 평가에 기초합니다.

커버리지 측정 페이지 맨 위

커버리지 메트릭은 "테스트는 얼마나 완전합니까?"라는 질문에 대한 답을 제공합니다. 가장 일반적으로 사용되는 커버리지 측정은 소프트웨어 요구사항 및 소스 코드의 커버리지를 바탕으로 합니다. 기본적으로 테스트 커버리지는 요구사항(요구사항 기반) 또는 코드 설계 및 구현 기준(코드 기반)과 관련된 완전성의 측정입니다(예: 유스 케이스 확인(요구사항 기반) 또는 코드의 모든 행 실행(코드 기반).

체계적인 테스트 활동은 적어도 하나의 테스트 커버리지 전략을 기초로 합니다. 커버리지 전략은 테스트의 일반 목적을 설명하여 테스트 케이스 설계를 안내합니다. 커버리지 전략에 대한 진술은 모든 성능 확인처럼 간단할 수 있습니다.

요구사항 기반 커버리지 전략은 요구사항이 완전히 카탈로그화된 경우 완전성 테스트의 수량화 가능한 척도를 사용하기에 충분할 수 있습니다. 예를 들어, 모든 성능 테스트 요구사항이 식별된 경우 측정사항을 얻기 위해 테스트 결과를 참조할 수 있습니다(예: 성능 테스트 요구사항의 75% 확인).

코드 기반 커버리지가 적용된 경우 테스트 전략은 테스트에서 얼마나 많은 소스 코드가 실행되었는지의 측면에서 형식화됩니다. 이러한 유형의 테스트 커버리지 전략은 안정성이 필수적인 시스템에서 매우 중요합니다.

측정은 수동으로(다음 두 가지 표제에서 제시한 방정식 사용) 도출하거나 테스트 자동화 툴을 사용하여 계산할 수 있습니다.

요구사항 기반 테스트 커버리지 페이지 맨 위

테스트 라이프사이클 중에 여러 번 측정된 요구사항 기반 테스트 커버리지는 테스트 라이프사이클의 이정표에서 테스트 커버리지를 식별합니다(예: 계획된, 구현된, 실행된 및 성공적인 테스트 커버리지).

  • 테스트 커버리지는 다음 방정식을 사용하여 계산합니다.

테스트 커버리지 = T(p,i,x,s) / RfT

여기서:
T는 테스트 프로시저 또는 테스트 케이스로 표현된 테스트(계획된, 구현된, 실행된 또는 성공적인) 수입니다.

RfT는 총 테스트 요구사항 수입니다.

  • 테스트 계획 활동에서 테스트 커버리지는 다음과 같은 방식으로 계획된 테스트 커버리지를 판별하기 위해 계산됩니다.

테스트 커버리지(계획된) = Tp / RfT

여기서:
Tp는 테스트 프로시저 또는 테스트 케이스로 표현되는 계획된 테스트 수입니다.

RfT는 총 테스트 요구사항 수입니다.

  • 테스트 구현 활동에서 테스트 프로시저가 구현됨에 따라(테스트 스크립트로) 테스트 커버리지는 다음 방정식을 사용하여 계산됩니다.

테스트 커버리지(구현된) = Ti / RfT

여기서:
Ti는 상응하는 테스트 스크립트가 존재하는 테스트 프로시저 또는 테스트 케이스의 수로 표현되는 구현된 테스트 수입니다.

RfT는 총 테스트 요구사항 수입니다.

  • 테스트 실행 활동에는 두 가지 테스트 커버리지 측정이 사용됩니다. 한 가지는 테스트 실행으로 도달된 테스트 커버리지를 식별하고 다른 한 가지는 성공적인 테스트 커버리지(결함 또는 예기치 않은 결과와 같은 실패 없이 실행된 테스트)를 식별합니다.

    이러한 커버리지 측정은 다음 방정식을 사용하여 계산됩니다.

    테스트 커버리지(실행된) = Tx / RfT

    여기서:
    Tx는 테스트 프로시저 또는 테스트 케이스로 표현되는 실행된 테스트 수입니다.

    RfT는 총 테스트 요구사항 수입니다.

  •  

성공적인 테스트 커버리지(실행된) = Ts / RfT

여기서:
Ts는 결함 없이 성공적으로 완료된 테스트 프로시저 또는 테스트 케이스로 표현되는 실행된 테스트 수입니다.

RfT는 총 테스트 요구사항 수입니다.

     

위 비율을 백분율로 변환하면 다음과 같은 요구사항 기반 테스트 커버리지의 진술이 가능합니다.

테스트 케이스(위 방정식의 T(p,i,x,s))의 x%가 y%의 성공 비율을 가집니다.

테스트 커버리지에 대한 이러한 의미 있는 진술은 정의된 성공 기준에 대해 대응시킬 수 있습니다. 기준이 충족되지 않는 경우 얼마나 많은 테스트 노력이 남아있는지 예측하는 것의 기초로 진술을 제공합니다.

코드 기반 테스트 커버리지 페이지 맨 위

코드 기반 테스트 커버리지는 아직 실행되지 않은 코드량과 비교하여 테스트 중에 실행된 코드량을 측정합니다. 코드 커버리지는 제어 플로우(명령문, 분기 또는 경로) 또는 데이터 플로우를 기반으로 할 수 있습니다.

  • 제어 플로우 커버리지에서 목표는 코드행, 분기 조건, 코드 경로 또는 소프트웨어 제어 플로우의 기타 요소를 테스트하는 것입니다.
  • 데이터 플로우에서 목표는 소프트웨어 조작을 통해 데이터 상태가 유효하게 남아있는지 테스트하는 것입니다(예: 데이터 요소를 사용하기 전에 정의했는지 테스트).

코드 기반 테스트 커버리지는 다음 방정식으로 계산됩니다.

테스트 커버리지 = Ie / TIic

여기서:
Ie는 코드 명령문, 코드 분기, 코드 경로, 데이터 상태 의사결정 지점 또는 데이터 요소 이름으로 표현되는 실행된 항목 수입니다.

TIic는 코드에 있는 총 항목 수입니다.

 

이 비율을 백분율로 변환하면 다음과 같은 코드 기반 테스트 커버리지 진술이 가능합니다.

테스트 케이스(위 방정식의 I)의 x%가 y%의 성공 비율을 가집니다.

테스트 커버리지에 대한 이러한 의미 있는 진술은 정의된 성공 기준에 대해 대응시킬 수 있습니다. 기준이 충족되지 않는 경우 얼마나 많은 테스트 노력이 남아있는지 예측하는 것의 기초로 진술을 제공합니다.

감지된 품질 측정 페이지 맨 위

테스트 커버리지 평가가 테스트 노력의 완전성 정도에 대한 측정을 제공하지만 경험에 의하면 테스트 중에 발견된 결함 평가는 소프트웨어 품질을 가장 적절하게 보여줍니다. 이러한 품질 이해를 통해 소프트웨어 시스템의 일반적인 품질에 대해 전체적으로 판단을 내릴 수 있습니다. 감지된 소프트웨어 품질은 부과된 요구사항을 소프트웨어가 얼마나 충족하는지에 대한 측정이므로 이 컨텍스트에서 결함은 테스트 대상이 소프트웨어 요구사항을 충족시키는 데 실패한 변경 요청 유형으로 간주됩니다.

결함 평가는 간단한 결함 계수로부터 정밀한 통계 모델링에 이르는 여러 범위의 방법에 기초할 수 있습니다.

정밀한 평가는 테스트 프로세스 중에 결함의 도달 또는 발견 비율에 대한 가정을 사용합니다. 일반 모델은 비율이 Poisson 분포도를 따른다고 가정합니다. 그러면 결함 비율에 대한 실제 데이터가 모델에 맞습니다. 평가 결과는 현재 소프트웨어 신뢰성을 측정하고 테스트 및 결함 제거가 계속되는 경우 신뢰성이 얼마나 커질 수 있는지 예측합니다. 이 평가는 소프트웨어 신뢰성 증가 모델링으로 설명되며 적극적인 연구 분야입니다. 이러한 유형의 평가에 대한 툴 지원 부족으로 인해 이 방법을 사용할 때의 비용과 얻어지는 장점 간에 유의하여 균형을 맞춰야 합니다.

결함 분석에는 결함과 연관된 하나 이상의 속성값에 걸친 결함 분포 분석이 포함됩니다. 결함 분석은 소프트웨어 신뢰성을 보여줍니다.

결함 분석에서는 4가지 주요 결함 속성이 일반적으로 분석됩니다.

  • 상태 - 결함의 현재 상태(미해결, 수정 중, 종결 등).
  • 우선순위 - 처리 및 해결 중인 이 결함의 상대적 중요성.
  • 심각도 - 일반 사용자, 조직, 제삼자 등에 대한 이 결함의 상대적 영향력.
  • 소스 - 이 결함으로 이어지게 만든 발생 결함의 위치와 내용 또는 이 결함을 제거하기 위해 수정할 컴포넌트.

결함 계수는 결함 경향 다이어그램 또는 보고서를 작성하여 시간의 함수로 보고할 수 있습니다. 또한 결함 밀도 보고서에서 심각도 또는 상태와 같은 하나 이상의 결함 속성의 함수로 보고할 수도 있습니다. 이러한 유형의 분석은 소프트웨어 신뢰성을 보여주는 결함 분포 또는 경향에 대한 관점을 제공합니다.

예를 들어, 결함 발견 비율은 테스트 및 수정이 진행됨에 따라 결국 감소된다고 예상합니다. 소프트웨어 품질을 수용할 수 없는 지점에서 결함 또는 품질이 낮은 임계값을 구축할 수 있습니다. 또한 결함 계수는 "약한 모듈", "핫 스팟" 및 반복적으로 수정되고 있는 소프트웨어의 일부분을 발견할 수 있는 보다 기본적인 설계 결함을 나타내는 구현 모델의 근원에 기초하여 보고될 수도 있습니다.

확인된 결함만이 이러한 유형의 분석에 포함됩니다. 보고된 모든 결함이 실제 오류는 아닙니다. 일부는 프로젝트 범위를 넘어서는 개선 요청이거나 이미 보고된 결함을 설명하는 것일 수 있습니다. 그러나 중복되거나 확인되지 않은 많은 결함이 보고되는 지를 살펴보고 분석하는 것은 가치 있는 일입니다.

결함 보고서 페이지 맨 위

Rational Unified Process는 다음과 같이 여러 보고 범주에 기초하여 결함 평가를 권장합니다.

  • 결함 분포(밀도) 보고서로 결함 계수를 하나 또는 두 개의 결함 속성의 함수로 표시할 수 있습니다.
  • 결함 기간 보고서는 특수한 유형의 결함 분포 보고서입니다. 결함 기간 보고서는 결함이 미해결과 같은 특정 상태로 유지된 기간을 보여줍니다. 임의의 기간 카테고리에서 결함은 소유자와 같은 또 다른 속성에 의해 정렬될 수 있습니다.
  • 결함 경향 보고서는 시간 함수로 상태(신규, 미해결 또는 종결)별로 결함 계수를 보여줍니다. 경향 보고서는 누적 또는 누적이 아닐 수 있습니다.

이러한 보고서 중 대다수는 소프트웨어 품질을 평가할 때 유용합니다. 이러한 보고서들은 테스트 중인 어플리케이션에 대한 많은 반복 및 테스트 사이클 동안 수행된 테스트 결과를 보여주는 테스트 결과 및 진행 보고서와 함께 분석할 때 유용합니다. 일반적인 테스트 기준에는 결함 분포 평가와 함께 쉽게 확인되는 특정 카테고리(심각도 클래스)에서 허용 가능한 미해결 결함 수에 관한 진술이 포함됩니다. 이 분포를 테스트 유발 요인별로 정렬 또는 묶어서 중요한 관심 분야에 평가를 집중할 수 있습니다.

이러한 유형의 보고서를 효과적으로 만드려면 일반적으로 툴 지원이 필요합니다.

결함 밀도 보고서 페이지 맨 위

결함 상태 대 우선순위

각 결함에 우선순위를 지정하십시오. 보통 다음과 같이 4개의 우선순위 레벨 정도가 효과적이며 충분합니다.

  • 긴급 우선순위(즉시 해결)
  • 높은 우선순위
  • 보통 우선순위
  • 낮은 우선순위

: 성공적인 테스트에 대한 기준을 이러한 우선순위 레벨에 걸친 결함 분포의 모양 측면에서 표현할 수 있습니다. 예를 들어, 성공적인 테스트 기준은 "우선순위 1의 결함이 없고 5개 미만의 우선순위 2인 결함이 미해결 상태"일 수 있습니다. 결함 분포 다이어그램을 다음과 같이 생성해야 합니다.

결함 분포 다이어그램

 

기준이 충족되지 않은 것이 분명합니다. 이 다이어그램은 테스트 기준의 필요에 따라 오직 미해결 결함만 표시하는 필터를 가지고 있어야 합니다.

결함 상태 대 심각도

결함 심각도 보고서는 각 심각도 클래스에 존재하는 결함 수를 보여줍니다(예: 심각한 오류, 수행되지 않은 주요 기능, 사소한 문제).

구현 모델에서 결함 상태 대 위치

결함 소스 보고서는 구현 모델의 요소에서 결함 분포를 보여줍니다.

결함 기간 보고서 페이지 맨 위

결함 기간 분석은 테스트 및 결함 제거 활동에 대한 효과에 대한 유용한 피드백을 제공합니다. 예를 들어, 대다수 오래된 미해결 결함이 검증 보류 상태인 경우 이것은 아마도 재테스트 노력에 충분한 자원이 적용되지 않았음을 의미합니다.

결함 경향 보고서 페이지 맨 위

결함 경향 보고서는 결함 비율을 식별하고 특히 테스트 상태에 대한 유용한 시각을 제공합니다. 결함 경향은 테스트 사이클에서 상당히 예층 가능한 패턴을 따릅니다. 사이클 초반에 결함 비율은 빠르게 증가하여 최대에 도달하지만 시간이 경과하면서 느린 속도로 감소합니다.

 

결함 경향 보고서 다이어그램

문제점을 찾기 위해 이러한 경향에 비추어 프로젝트 스케줄을 검토할 수 있습니다. 예를 들어, 4주 테스트 사이클의 세 번째 주에도 여전히 결함 비율이 증가되는 경우 프로젝트는 분명히 스케줄을 맞출 수가 없습니다.

이 간단한 경향 분석은 결함이 신속하게 수정될 것이고 수정사항은 다음 빌드에서 테스트될 것이므로 결함 종결 속도는 결함 발견 속도와 동일한 프로파일을 따라야 한다고 가정합니다. 이러한 가정을 따르지 않는 경우 결함 해결 프로세스에 문제가 있는 것입니다. 수정사항을 재테스트하고 검증하는 자원 또는 결함 수정 자원이 부적절할 수 있습니다.

경향 분석 보고서 다이어그램

이 보고서에 반영된 경향은 새 결함이 프로젝트 초기에 신속하게 발견 및 제기되고 시간 경과를 따라 감소된다는 것을 보여줍니다. 미해결 결함의 경향은 신규 결함의 경향과 유사하지만 조금씩 뒤로 지체됩니다. 결함 종결 경향은 미해결 결함이 수정 및 확인됨에 따라 점점 증가합니다. 이러한 경향은 성공적인 노력을 보여줍니다.

경향이 이러한 사항에서 극적으로 벗어나는 경우 문제점의 징후일 수 있고 개발 또는 테스트의 특정 분야에 추가 자원을 적용해야 하는 시기임을 보여주는 것일 수 있습니다.

결함 분석을 테스트 커버리지 측정과 함께 사용하면 테스트 완료 기준의 바탕이 되는 매우 유용한 평가를 제공할 수 있습니다.

성능 측정 페이지 맨 위

몇 가지 측정이 테스트 대상의 성능 작동을 평가하고 작동과 관련된 데이터(예: 응답 시간, 시기 프로파일, 실행 플로우, 조작 신뢰성 및 한계) 파악에 초점을 맞추는 데 사용됩니다. 기본적으로 이러한 측정은 테스트 평가 활동에서 평가되지만 테스트 실행 활동 중에 테스트 진행 및 상태를 평가하기 위해 사용되는 성능 측정이 있습니다.

기본 성능 측정에는 다음 사항이 포함됩니다.

  • 동적 모니터링 - 테스트 실행 중에 실행되는 각 테스트 스크립트의 상태에 대한 실시간 캡처 및 표시.
  • 응답 시간 및 처리량 보고서 - 지정된 액터 및 유스 케이스에 대한 테스트 대상의 응답 시간 및 처리량 측정.
  • 백분위수 보고서 - 데이터 수집 값에 대한 백분위수 측정 및 계산.
  • 비교 보고서 - 서로 다른 테스트 실행을 나타내는 둘 이상의 데이터 세트 간 차이점 또는 경향.
  • 추적 보고서 - 액터(테스트 스크립트) 및 테스트 대상 간 메시지 및 대화에 대한 세부사항.

동적 모니터링 페이지 맨 위

동적 모니터링은 일반적으로 히스토그램 또는 그래프 형식으로 테스트 실행 중에 실시간 표시 및 보고를 제공합니다. 이 보고서는 테스트 스크립트의 현재 상태, 상황 및 진행을 표시하여 성능 테스트 실행을 모니터하거나 평가합니다.

히스토그램으로 표시된 동적 모니터링

예를 들어, 바로 앞의 히스토그램에 동일한 유스 케이스를 실행하는 80개의 테스트 스크립트가 있습니다. 이 그래프에서 14개 테스트 스크립트는 대기 상태이고 12개는 조회, 34개는 SQL 실행, 4개는 SQL 연결, 16개는 기타 상태입니다. 테스트가 진행되면서 각 상태의 스크립트 수가 변화되리라고 예상됩니다. 표시된 출력은 정상적으로 실행되고 실행 중간에 있는 테스트 실행이 일반적입니다. 그러나 테스트 스크립트가 한 가지 상태로 유지되거나 테스트 실행 동안 변화되지 않는 경우 이것은 테스트 실행의 문제점을 보여주는 것이거나 다른 성능 측정의 구현 또는 평가의 필요성을 보여주는 것일 수 있습니다.

응답 시간 및 처리량 보고서 페이지 맨 위

응답 시간 및 처리량 보고서는 그 이름에서 알 수 있듯이 시간 및 처리량(처리된 트랜잭션 수)과 관련된 성능 작동을 측정하고 계산합니다. 일반적으로 이러한 보고서는 "y"축에는 응답 시간(또는 트랜잭션 수), "x"축에는 이벤트가 있는 그래프로 표시됩니다.

샘플 처리량 및 분석 보고서 다이어그램

실제 성능 작동을 보여주는 것 외에도 데이타 값의 평균 및 표준 편차와 같은 통계 정보를 계산하고 보여주는 것이 종종 유용합니다.

백분위수 보고서 페이지 맨 위

백분위수 보고서는 수집된 데이터 유형의 모집단 백분위수 값을 표시하여 성능의 또 다른 통계적 계산을 제공합니다.

샘플 백분위수 보고서 다이어그램

비교 보고서 페이지 맨 위

테스트 실행 사이에 수행된 변경이 성능 작동에 미치는 영향을 평가할 수 있도록 한 성능 테스트 실행의 결과와 다른 성능 테스트 실행의 결과를 비교하는 것이 중요합니다. 비교 보고서를 사용하여 많은 테스트 실행 간의 경향 또는 두 세트의 데이터(각각이 다른 테스트 실행을 나타내는) 간의 차이점을 표시할 수 있습니다.

추적 및 프로파일 보고서 페이지 맨 위

성능 작동이 수용 가능하거나 성능 모니터링이 병목 현상의 가능성(예: 테스트 스크립트가 상당히 장기간 동안 주어진 상태로 유지되는 경우)을 보여주는 경우 추적 보고서는 가장 가치 있는 보고서일 수 있습니다. 추적 및 프로파일 보고서는 낮은 레벨의 정보를 보여줍니다. 이 정보에는 액터와 테스트 대상 간 메시지, 실행 플로우, 데이터 액세스, 함수 및 시스템 호출이 포함됩니다.



Rational Unified Process   2003.06.15