개념: 테스트의 주요 척도
이 가이드라인은 테스트 스위트에 대한 적용 범위 및 품질 척도를 소개합니다.
관계
기본 설명

소개

테스트의 주요 척도에는 적용 범위와 품질이 포함됩니다.

테스트 적용 범위는 테스트 완전성 측정으로, 테스트 요구사항 또는 테스트 케이스의 적용 범위나 실행된 코드의 적용 범위에 의해 표시되는 테스트 적용 범위를 기반으로 합니다.

품질은 테스트 대상(테스트 중인 응용프로그램이나 시스템)의 신뢰성, 안정성 및 성능의 척도입니다. 품질은 테스트 결과 평가 및 테스트 중 식별되는 변경 요청(결함) 분석을 기반으로 합니다.

적용 범위 척도

적용 범위 메트릭은 "테스트 완료 방법"에 대한 응답을 제공합니다. 가장 공통적으로 사용하는 적용 범위 척도는 소프트웨어 요구사항과 소스 코드의 적용 범위를 기반으로 하는 것입니다. 기본적으로, 테스트 적용 범위는 유스 케이스(요구사항 기반) 확인 또는 모든 코드 행(코드 기반) 실행과 같은 요구사항(요구사항 기반) 또는 코드의 디자인 및 구현 기준(코드 기반)에 대해 완전성을 측정할 수 있습니다.

조직적인 테스트 타스크는 최소 하나의 테스트 적용 범위 전략을 기반으로 합니다. 적용 범위 전략은 테스트의 일반 목적을 설명하면서 테스트 케이스의 디자인을 안내합니다. 적용 범위 전략 구문은 모든 성능 확인과 같이 단순할 수 있습니다.

요구사항 기반 적용 범위 전략은 요구사항이 완전히 카탈로그화될 경우 테스트 완전성에 적합한 척도를 생성하기에 충분할 수 있습니다. 예를 들어, 모든 성능 테스트 요구사항이 식별된 경우 테스트 결과를 참조하여 척도를 얻을 수 있습니다(예: 성능 테스트 요구사항의 75%가 확인되었음).

코드 기반 적용 범위가 적용될 경우, 테스트 전략은 테스트에서 소스 코드가 실행된 양의 관점에서 공식화됩니다. 이 유형의 테스트 적용 범위 전략은 보안이 중요한 시스템에 아주 중요합니다.

두 가지 척도 모두 수동으로 파생되거나(다음의 두 표제에 제공된 등식 사용) 테스트 자동화 도구를 사용하여 계산할 수 있습니다.

요구사항 기반 테스트 적용 범위

테스트 라이프사이클 중에 몇 번 측정된 요구사항 기반 테스트 적용 범위는 계획, 구현, 실행되어 성공한 테스트 적용 범위와 같은 테스트 라이프사이클의 이정표에서 테스트 적용 범위를 식별합니다.

  • 테스트 적용 범위는 다음 등식을 사용하여 계산됩니다.

테스트 적용 범위 = T(p,i,x,s) / RfT

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

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

  • 계획 테스트 타스크에서, 테스트 적용 범위를 계산하여 다음 방식으로 계획된 테스트 적용 범위를 판별합니다.

테스트 적용 범위(계획) = T(p,i,x,s) / RfT

여기서,
Tp는 계획된 테스트 수로, 테스트 프로시저나 테스트 케이스로 표현됩니다.

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

  • 테스트 구현 타스크에서, 테스트 프로시저가 구현(테스트 스크립트로 구현)되는 대로 다음 등식을 사용하여 테스트 적용 범위가 계산됩니다.

테스트 적용 범위(구현됨) = Ti / RfT

여기서,
Ti는 구현된 테스트 수로, 해당되는 테스트 스크립트가 있는 테스트 프로시저 또는 테스트 케이스 수로 표시됩니다.

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

  • 테스트 실행 타스크에서는 두 가지의 테스트 적용 범위 척도가 사용됩니다. 하나는 테스트 실행으로 얻은 테스트 적용 범위를 식별하고 두 번째는 성공적인 테스트 적용 범위(결함이나 예기치 못한 결과와 같은 실패 없이 실행된 테스트)를 식별합니다.

    이 적용 범위 척도는 다음 등식을 사용하여 계산됩니다.

    테스트 적용 범위(실행됨) = Tx / RfT

    여기서,
    Tx는 실행된 테스트 수로, 테스트 프로시저나 테스트 케이스로 표현됩니다.

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



성공적인 테스트 적용 범위(실행됨) = Ts / RfT

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

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



위의 비율을 백분율로 조정하면 요구사항 기반 테스트 적용 범위에 대해 다음 구문을 고려할 수 있습니다.

테스트 케이스의 x%(위의 등식에서 T(p,i,x,s))가 y% 성공율로 처리되었습니다.

테스트 적용 범위에 대한 이 의미있는 구문은 정의된 성공 기준에 대해 일치될 수 있습니다. 기준이 충족되지 않았으면 구문은 남아 있는 테스트 노력 정도를 예측하기 위한 기초를 제공합니다.

비용 기반 테스트 적용 범위

코드 기반 테스트 적용 범위는 테스트 중 실행된 코드 양을 측정하여 실행하도록 남겨진 코드 양과 비교합니다. 코드 적용 범위는 제어 플로우(구문, 분기 또는 경로) 또는 데이터 플로우를 기반으로 할 수 있습니다.

  • 제어 플로우 적용 범위에서, 목적은 코드 행, 분기 조건, 코드 경로 또는 소프트웨어 제어 플로우의 기타 요소를 테스트하는 것입니다.
  • 데이터 플로우 적용 범위에서, 목적은 데이터 상태가 소프트웨어의 오퍼레이션을 통해 유지되는지(데이터 요소가 사용 이전에 정의되는지) 테스트하는 것입니다.

코드 기반 테스트 적용 범위는 다음 등식으로 계산됩니다.

테스트 적용 범위 = Ie / TIic

여기서,
Ie는 실행된 항목 수이며, 코드 구문, 코드 분기, 코드 경로, 데이터 상태 결정 지점 또는 데이터 요소 이름으로 표시됩니다.

TIic은 코드의 총 항목 수입니다.



이 비율을 백분율로 조정하면 코드 기반 테스트 적용 범위에 대한 다음 구문을 고려할 수 있습니다.

테스트 케이스의 x%(위의 등식에서 I)가 y% 성공율로 처리되었습니다.

테스트 적용 범위에 대한 이 의미있는 구문은 정의된 성공 기준에 대해 일치될 수 있습니다. 기준이 충족되지 않았으면 구문은 남아 있는 테스트 노력 정도를 예측하기 위한 기초를 제공합니다.

인식된 품질 측정

테스트 적용 범위 평가에서 테스트 노력의 완전성 범위 척도가 제공되지만, 테스트 중에 발견되는 결함을 평가하면 소프트웨어 품질의 최상의 지표가 제공됩니다. 이와 같은 품질 인식을 사용하여 소프트웨어 시스템의 일반 품질에 대해 전체적으로 판단할 수 있습니다. 인식된 소프트웨어 품질은 소프트웨어가 부과된 요구사항을 어느 정도 제대로 충족시키는 지에 대한 척도이므로, 이 상황에서 결함은 테스트 대상이 소프트웨어 요구사항을 충족시키는 데 실패한 변경 요청의 유형으로 간주됩니다.

결함 평가는 단순 결함 계수에서 정밀한 통계 모델링에 이르기까지 광범위한 방법을 기반으로 할 수 있습니다.

정밀한 평가는 테스트 프로세스 동안 결함 발견 또는 도달 비율에 대한 가정을 사용합니다. 공통 모델에서 비율은 푸아송 분포를 따른다고 가정합니다. 그런 다음 결함 비율에 대한 실제 데이터를 모델에 맞춥니다. 결과 평가는 현재 소프트웨어 신뢰성을 예상하고, 테스트 및 결함 제거가 계속될 경우 신뢰성이 어느 정도 증가할 것인지 예측합니다. 이 평가는 소프트웨어 신뢰성 성장 모델링으로 설명되며 활발한 연구 영역입니다. 이 유형의 평가에 대한 도구 지원 부족으로 인해, 이 접근 방식을 사용할 경우의 비용과 얻어지는 이익 사이에 주의하여 밸런스를 조절해야 할 것입니다.

결함 분석에는 결함과 연관되는 속성 중 하나 이상의 값에 대한 결함 분포의 분석이 포함됩니다. 결함 분석은 소프트웨어의 신뢰성 표시를 제공합니다.

결함 분석에서, 네 가지의 기본 결함 속성이 공통적으로 분석됩니다.

  • 상태 - 결함의 현재 상태(미해결, 수정됨, 처리됨 등)
  • 우선순위 - 처리하고 해결하는 해당 결함의 상대적 중요도
  • 심각도 - 사용자, 조직, 써드파티 등에 대한 해당 결함의 상대적 영향
  • 소스 - 해당 결함을 초래하는 원래의 결함과 그 위치, 또는 결함을 제거하기 위해 수정할 컴포넌트

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

예를 들어, 결함 발견 비율은 결국 테스트 및 수정이 진행됨에 따라 없어질 것으로 예상됩니다. 결함 또는 불량 품질 임계값은 소프트웨어 품질이 허용 불가능한 지점에서 설정될 수 있습니다. 결함 계수는 또한 구현 모델 내의 기점(origin)을 기반으로 보고할 수 있으므로, 되풀이하여 계속 수정되는 "약한 모듈", "핫 스팟" 및 소프트웨어 부분을 감지할 수 있습니다. 이는 더 근본적인 디자인 결함을 표시합니다.

확정된 결함만 이와 같은 종류의 분석에 포함됩니다. 보고되는 모든 결함이 실제 결함을 표시하는 것은 아닙니다. 일부는 프로젝트 범위 외부의 개선 요청이거나 이미 보고된 결함을 설명할 수 있습니다. 그러나 중복되거나 확정된 결함이 아닌 많은 결함이 보고되는 원인을 찾아서 분석하는 것은 가치있는 일입니다.

결함 보고서

Rational Unified Process에서는 다음과 같이 여러 개의 보고 카테고리를 기반으로 결함을 평가할 것을 권장합니다.

  • 결함 분포(밀도) 보고서에서는 결함 계수가 하나 또는 두 개의 결함 속성에 대한 기능으로 표시될 수 있습니다.
  • 결함 추이 분석 보고서는 특수한 유형의 결함 분포 보고서입니다. 결함 추이 분석 보고서는 결함이 특정 상태(예: 미해결)에서 유지된 기간을 표시합니다. 모든 추이 분석 카테고리에서는 결함이 다른 속성(예: 소유자)을 기준으로 정렬될 수도 있습니다.
  • 결함의 상태동향 보고서는 결함 계수를 상태(신규, 미해결 또는 처리됨)에 따라 시간 함수로 표시됩니다. 상태동향 보고서는 누적되거나 누적되지 않을 수 있습니다.

이러한 다양한 보고서들은 소프트웨어 품질 평가에 있어 유용합니다. 이 보고서는 테스트 중인 응용프로그램에 대한 여러 반복 및 테스트 주기에 걸쳐 이끌어 낸 테스트 결과를 보여주는 진행상태 보고서와 테스트 결과를 함께 분석할 때 가장 유용합니다. 보통의 테스트 기준에는 결함 분포 평가로 쉽게 확인되는 심각도 클래스와 같은 특정 카테고리에서 허용할 수 있는 미해결 결함 수에 대한 구문이 포함됩니다. 테스트 동기 부여 요인으로 분포를 그룹화하거나 정렬하면 관심사항의 중요 영역에 평가 초점을 맞출 수 있습니다.

일반적으로 이와 같은 유형의 보고서를 효율적으로 생성하려면 도구 지원이 필요합니다.

결함 밀도 보고서

결함 상태 대 우선순위

각각의 결함에 우선순위를 부여하십시오. 다음과 같은 네 개의 우선순위 레벨이 실용적이며 이 레벨로도 충분합니다.

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

참고: 성공적인 테스트의 기준은 우선순위 레벨에 대한 결함 분포를 어떻게 보아야 하는지의 관점으로 표현될 수 있습니다. 예를 들어, 성공적 테스트 기준은 "미해결 우선순위 1 결함은 없고 다섯 개 이하의 우선순위 2 결함이 미해결 상태임"이 될 수 있습니다. 다음과 같은 결함 분포 다이어그램을 생성해야 합니다.

결함 분포 다이어그램



명백하게 기준을 충족하지 못했습니다. 이 다이어그램에는 테스트 기준에서 요구하는 대로 미해결 결함만을 표시하기 위한 필터가 포함되어야 합니다.

결함 상태 대 심각도

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

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

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

결함 추이 분석 보고서

결함 추이 분석은 테스트 및 결함 제거 타스크의 효율성에 대한 좋은 피드백을 제공합니다. 예를 들어, 오래되고 해결되지 않은 결함의 대부분이 유효성 검증 보류 상태에 있을 경우, 이는 재테스트 노력에 적용되는 자원이 충분하지 않음을 의미할 수 있습니다.

결함의 상태동향 보고서

결함의 상태동향 보고서는 결함 비율을 식별하고 테스트 상태에 대한 알기 쉬운 보기를 제공합니다. 결함의 상태동향은 테스트 주기에서 확실히 예측 가능한 패턴을 따릅니다. 결함 비율은 주기 초기에 빠르게 상승하고 최고조에 도달한 후에는 시간이 지남에 따라 낮은 비율로 감소합니다.



결함의 상태동향 보고서 다이어그램

문제점을 찾으려면 이 상태동향을 보고 프로젝트 스케줄을 검토할 수 있습니다. 예를 들어, 4주 테스트 주기의 세 번째 주에서 결함 비율이 여전히 상승할 경우, 프로젝트는 명백하게 스케줄대로 진행되지 않는 것입니다.

이와 같은 단순 상태동향 분석에서는 결함이 즉시 수정되며 수정사항이 후속 빌드에서 테스트되는 것으로 가정하므로, 결함 처리 비율은 결함 찾기 비율과 같은 프로파일을 따라야 합니다. 이와 같은 상황이 발생하지 않을 경우, 이는 결함 해결 프로세스에 문제점이 있음을 표시합니다. 수정사항을 다시 테스트하고 유효성을 검증할 자원이나 결함 수정 자원이 부적절할 수 있습니다.

상태동향 분석 보고서 다이어그램

이 보고서에 반영되는 상태동향은 새 결함이 프로젝트 시작 부분에서 신속하게 발견되어 열리고 시간이 지나면서 감소함을 보여줍니다. 미해결 결함에 대한 상태동향은 새 결함의 상태동향과 유사하지만 약간 지연됩니다. 처리되는 결함의 상태동향은 미해결 결함이 수정되고 확인됨에 따라 시간이 지나면서 증가합니다. 이 상태동향은 성공적인 노력을 보여줍니다.

상태동향이 갑자기 변하는 경우, 이는 문제점을 표시하고 개발 또는 테스트의 특정 영역에 추가 자원을 적용해야 하는 시기를 식별할 수 있습니다.

테스트 적용 범위 척도와 결합하여, 결함 분석은 테스트 완료 기준의 기초가 되는 아주 좋은 평가를 제공합니다.

성능 척도

테스트 대상의 성능 동작을 평가하고 응답 시간, 타이밍 프로파일, 실행 플로우, 조작 신뢰성 및 한계와 같은 동작 관련 데이터를 캡처하는 데 초점을 맞추기 위해 몇 가지의 척도가 사용됩니다. 기본적으로, 이 척도는 테스트 평가 타스크에서 평가되지만 테스트 진행상태 및 상태를 평가하기 위해 테스트 실행 타스크 중에 사용되는 성능 척도가 있습니다.

기본적인 성능 척도는 다음과 같습니다.

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

동적 모니터링

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

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

예를 들어, 이전 히스토그램에는 동일한 유스 케이스를 실행하는 80개의 테스트 스크립트가 있습니다. 이 그래프에서, 14개의 테스트 스크립트가 대기 상태에, 12개는 조회 상태, 34개는 SQL 실행 상태, 네 개는 SQL 연결에, 16개는 기타 상태에 있습니다. 테스트가 진행됨에 따라 각 상태의 스크립트 수가 변경되는 것을 볼 수 있습니다. 표시된 산출물은 정상적으로 실행 중이며 실행 중간에 있는 테스트 실행의 표본이 됩니다. 그러나 테스트 스크립트가 하나의 상태로 유지되거나 테스트 실행 중 변경사항을 표시하지 않을 경우, 이는 테스트 실행에 문제점이 있거나 다른 성능 척도를 구현 또는 평가해야 함을 표시할 수 있습니다.

응답 시간 및 처리량 보고서

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

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

실제 성능 동작을 표시하는 것 외에 데이터 값의 중간값과 표준 편차와 같은 통계 정보를 계산하고 표시하는 것이 종종 가치가 있습니다.

백분위수 보고서

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

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

비교 보고서

하나의 성능 테스트 실행 결과를 다른 테스트 실행 결과와 비교하는 것은 중요하므로, 성능 동작에 대한 테스트 실행 사이에 수행되는 변경사항의 영향을 평가할 수 있습니다. 두 개의 데이터 세트(각각 다른 테스트 실행 표시) 사이의 차이나 테스트의 많은 실행 사이의 상태동향을 표시하려면 비교 보고서를 사용하십시오.

추적 및 프로파일 보고서

성능 동작을 허용할 수 없거나 성능 모니터링이 가능한 병목 현상을 나타내는 경우(예: 테스트 스크립트가 장기간 특정 상태로 유지되는 경우), 추적 보고가 가장 중요한 보고서가 될 수 있습니다. 추적 및 프로파일 보고서는 하위 레벨의 정보를 표시합니다. 이 정보에는 액터와 테스트 대상, 실행 플로우, 데이터 액세스, 함수 및 시스템 호출 사이의 메시지가 포함됩니다.