- 정의 소프트웨어 테스팅 지표?
- 소프트웨어 테스트 측정이란 무엇입니까?
- 왜 측정항목을 테스트해야 합니까?
- 메트릭 수명 주기
- 수동 테스트 메트릭 유형
- 소프트웨어의 예Testing Metrics
- 결론
- 권장 도서
소프트웨어 프로젝트에서는 프로젝트와 프로세스의 품질, 비용 및 효율성을 측정하는 것이 가장 중요합니다. 이를 측정하지 않으면 프로젝트를 성공적으로 완료할 수 없습니다.
오늘 기사에서는 예제와 그래프 – 소프트웨어 테스트 측정항목 및 측정5에 대해 알아봅니다> 및 소프트웨어 테스팅 프로세스에서 이를 사용하는 방법.
유명한 말이 있습니다. "측정할 수 없는 것은 제어할 수 없습니다."
여기서 프로젝트를 제어한다는 것은 프로젝트 관리자/리드가 완벽한 시간에 대응하기 위해 최대한 빨리 테스트 계획의 편차를 식별할 수 있는 방법을 의미합니다. 프로젝트 요구 사항을 기반으로 테스트 지표를 생성하는 것은 테스트 중인 소프트웨어의 품질을 달성하는 데 매우 중요합니다.
정의 소프트웨어 테스팅 지표?
메트릭은 시스템, 시스템 구성요소 또는 프로세스가 주어진 속성을 소유하는 정도를 정량적으로 측정한 것입니다.
측정항목은 '표준 OF 로 정의할 수 있습니다. 측정 ”.
소프트웨어 지표는 프로젝트의 품질을 측정하는 데 사용됩니다. . 간단히 말해서 메트릭은 속성을 설명하는 데 사용되는 단위입니다. 메트릭은 측정을 위한 척도입니다.
일반적으로 "킬로그램"은 "무게" 속성을 측정하기 위한 메트릭이라고 가정합니다. 유사하게, 소프트웨어에서 “얼마나 많은 문제가천 줄의 코드?”, h 여기 아니요. of issues is one measure & 코드 줄 수는 또 다른 측정입니다. 메트릭은 다음 두 측정에서 정의됩니다 .
테스트 메트릭 예:
- 내 결함 수 모듈?
- 1인당 몇 개의 테스트 사례가 실행됩니까?
- 테스트 범위 %란 무엇입니까?
소프트웨어 테스트 측정이란 무엇입니까?
측정은 제품 또는 프로세스의 일부 속성에 대한 정도, 양, 치수, 용량 또는 크기를 정량적으로 나타내는 것입니다.
테스트 측정 예: 총 결함 수.
측정과 측정의 차이점을 명확하게 이해하려면 아래 다이어그램을 참조하십시오. 측정항목.
왜 측정항목을 테스트해야 합니까?
소프트웨어 테스트 지표 생성은 소프트웨어 테스트 리더/관리자의 가장 중요한 책임입니다.
테스트 지표는
- 예: 비용 및 비용 추정과 같은 활동의 다음 단계에 대한 결정을 내립니다. 향후 프로젝트 일정.
- 프로젝트 성공을 위해 필요한 개선 사항 이해
- 수정할 프로세스 또는 기술 등에 대한 결정
Software Testing Metrics의 중요성:
위에서 설명한 것처럼 Test Metrics는 소프트웨어의 품질을 측정하는 데 가장 중요합니다.
이제 어떻게 측정할 수 있습니까? 의 품질Metrics ?
프로젝트에 메트릭이 없는 경우 테스트 분석가가 수행한 작업의 품질을 어떻게 측정할까요?
예를 들어, 테스트 분석가는
- 5가지 요구 사항에 대한 테스트 사례 설계
- 설계된 테스트 사례 실행
- 결함 기록 및 관련 테스트 사례에 실패해야 합니다.
- 결함이 해결된 후 결함 & 실패한 해당 테스트 사례를 다시 실행합니다.
위의 시나리오에서 메트릭을 따르지 않으면 테스트 분석가가 완료한 작업이 주관적입니다. 즉, 테스트 보고서에 적절한 정보가 없습니다. 그의 작업/프로젝트의 상태를 알 수 있습니다.
메트릭스가 프로젝트에 관련된 경우 적절한 숫자/데이터로 작업의 정확한 상태를 게시할 수 있습니다.
즉 테스트 보고서에서 다음을 게시할 수 있습니다.
- 요구 사항당 얼마나 많은 테스트 사례가 설계되었습니까?
- 아직 설계되지 않은 테스트 사례는 몇 개입니까?
- 얼마나 많은 테스트 사례가 실행됩니까?
- 얼마나 많은 테스트 사례가 통과/실패/차단됩니까?
- 아직 실행되지 않은 테스트 사례는 몇 개입니까?
- 결함은 몇 개입니까? 식별되고 & 이러한 결함의 심각도는 무엇입니까?
- 하나의 특정 결함으로 인해 몇 개의 테스트 사례가 실패합니까? 등.
프로젝트 요구에 따라 위에서 언급한 목록보다 더 많은 메트릭을 가질 수 있습니다.프로젝트의 상태를 자세히 설명합니다.
위의 메트릭을 기반으로 테스트 리더/관리자는 아래에 언급된 핵심 사항을 이해하게 됩니다.
- 완료된 작업의 %ge
- 아직 완료되지 않은 작업의 %ge
- 나머지 작업 완료 시간
- 프로젝트가 일정대로 진행되고 있습니까, 아니면 지연되고 있습니까? 등
지표에 따라 프로젝트가 일정대로 완료되지 않을 경우 관리자는 이유를 제공하여 클라이언트 및 기타 이해 관계자에게 경보를 울립니다. 마지막 순간의 놀라움을 피하기 위해 지연됩니다.
메트릭 수명 주기
수동 테스트 메트릭 유형
테스트 메트릭은 주로 2가지 범주로 나뉩니다.
- 기본 메트릭
- 계산된 메트릭
기본 메트릭: 기본 메트릭은 테스트 케이스 개발 및 실행 중에 테스트 분석가가 수집한 데이터에서 파생된 메트릭입니다.
이 데이터는 테스트 수명 주기 전체에서 추적됩니다. 즉. Total no와 같은 데이터를 수집합니다. 프로젝트(또는) 번호를 위해 개발된 테스트 케이스의 수. 실행해야 하는 테스트 케이스의 수(또는) 없음. 테스트 사례 통과/실패/차단 등.
계산된 지표: 계산된 지표는 기본 지표에서 수집된 데이터에서 파생됩니다. 이러한 지표는 일반적으로 테스트 보고 목적으로 테스트 리더/관리자가 추적합니다.
소프트웨어의 예Testing Metrics
소프트웨어 테스트 보고서에 사용되는 다양한 테스트 메트릭을 계산하는 예를 들어 보겠습니다.
다음은 실제로 테스트에 참여하는 테스트 분석가로부터 검색된 데이터의 테이블 형식입니다. 테스트:
지표 계산을 위한 정의 및 공식:
#1) %ge 실행된 테스트 사례 : 이 메트릭은 %ge로 테스트 케이스의 실행 상태를 얻는 데 사용됩니다.
%ge 실행된 테스트 케이스 = ( 실행된 테스트 케이스 수 / 총계 작성된 테스트 케이스 수) * 100.
따라서 위의 데이터에서
%ge 실행된 테스트 케이스 = (65 / 100) * 100 = 65%
#2) %ge 실행되지 않은 테스트 케이스 : 이 메트릭은 %ge 측면에서 테스트 케이스의 보류 중인 실행 상태를 얻는 데 사용됩니다.
%ge 실행되지 않은 테스트 케이스 = ( 실행되지 않은 테스트 케이스 수 / 작성된 테스트 케이스의 총 수) * 100.
따라서 위의 데이터에서
%ge 차단된 테스트 케이스 = (35 / 100) * 100 = 35%
#3) %ge 통과한 테스트 케이스 : 이 메트릭은 실행된 테스트 사례의 통과 %ge를 얻는 데 사용됩니다.
%ge 테스트 사례 통과 = ( No. 통과한 테스트 사례 수 / 총 수 of Test cases Executed) * 100.
따라서 위의 데이터에서
%ge Test cases Passed = (30 / 65) * 100 = 46%
#4) %ge 테스트 사례 실패 : 이 메트릭은 실행된 테스트 사례의 실패 %ge를 얻기 위해 사용됩니다.
%ge 테스트 사례실패 = ( 실패한 테스트 케이스 수 / 실행한 테스트 케이스의 총 수) * 100.
따라서 위의 데이터에서
%ge 테스트 케이스 Passed = (26 / 65) * 100 = 40%
#5) %ge Test cases Blocked : 이 메트릭은 실행된 테스트 케이스의 차단된 %ge를 얻는 데 사용됩니다. 테스트 케이스를 차단한 실제 이유를 지정하여 자세한 보고서를 제출할 수 있습니다.
%ge 차단된 테스트 케이스 = ( 차단된 테스트 케이스 수 / 실행된 총 테스트 케이스 수 ) * 100.
그래서, 위의 데이터에서
%ge Test cases Blocked = (9 / 65) * 100 = 14%
#6) 결함 밀도 = 아니오. 식별된 결함 수 / 크기
( 여기서 "크기"는 요구 사항으로 간주됩니다. 따라서 여기에서 결함 밀도는 요구 사항당 식별된 결함 수로 계산됩니다. 마찬가지로 결함 밀도를 계산할 수 있습니다. 코드 100줄당 식별된 결함 수 [OR] 모듈당 식별된 결함 수 등 )
따라서 위의 데이터에서
Defect Density = (30 / 5) = 6
#7) Defect Removal Efficiency (DRE) = ( QA 테스트 중 발견된 결함 수 / (QA 동안 발견된 결함 수) 테스트 + 최종 사용자가 발견한 결함 수)) * 100
DRE는 시스템의 테스트 유효성을 식별하는 데 사용됩니다. QA 테스트를 통해 100개의 결함을 식별했습니다.
QA 테스트 후 Alpha & 베타 테스트,최종 사용자/클라이언트는 QA 테스트 단계에서 식별될 수 있는 40개의 결함을 식별했습니다.
이제 DRE는 다음과 같이 계산됩니다.
DRE = [100 / (100 + 40)] * 100 = [100 /140] * 100 = 71%
#8) Defect Leakage : Defect Leakage는 QA 테스트의 효율성을 파악하기 위해 사용되는 Metric입니다. 즉, QA 테스트 중에 누락/실패한 결함 수입니다.
결함 누출 = ( UAT에서 발견된 결함 수 / QA 테스트에서 발견된 결함 수.) * 100
개발 중 & QA 테스트를 통해 100개의 결함을 식별했습니다.
QA 테스트 후 Alpha & 베타 테스트, 최종 사용자/클라이언트는 QA 테스트 단계에서 식별할 수 있는 40개의 결함을 식별했습니다.
결함 누출 = (40 /100) * 100 = 40%
#9) Defects by Priority : 이 메트릭은 No.를 식별하는 데 사용됩니다. 소프트웨어의 품질을 결정하는 데 사용되는 결함의 심각도/우선순위에 따라 식별된 결함 수.
%ge 치명적 결함 = 식별된 치명적 결함 수 / 총 수 식별된 결함 수 * 100
위 표에서 사용할 수 있는 데이터에서
%ge 치명적 결함 = 6/ 30 * 100 = 20%
%ge 높은 결함 = 식별된 High Defect 건수 / 총 건수 식별된 결함 수 * 100
위 표의 데이터에서
%ge 높은 결함 = 10/ 30 * 100 = 33.33%
%ge 중간 결함 = 아니요.식별된 중간 결함의 / 총 수 식별된 결함 수 * 100
위 표의 데이터에서
%ge 중간 결함 = 6/ 30 * 100 = 20%
%ge 낮은 결함 = 낮은 결함 발견 건수 / 총 건수 식별된 결함 수 * 100
위 표의 데이터에서
%ge 낮은 결함 = 8/ 30 * 100 = 27%
결론
이 기사에서 제공하는 메트릭은 주로 테스트 케이스 개발/실행 단계 및 테스트 케이스 개발/실행 단계에서 정확한 데이터로 일일/주간 상태 보고서를 생성하는 데 사용됩니다. 이것은 또한 프로젝트 상태를 추적하는 데 유용합니다. 소프트웨어의 품질.
작성자 정보 : Anuradha K의 게스트 게시물입니다. 그녀는 7년 이상의 소프트웨어 테스트 경험이 있으며 현재 컨설턴트로 일하고 있습니다. MNC. 그녀는 또한 모바일 자동화 테스트에 대해 잘 알고 있습니다.
귀하의 프로젝트에서 사용하는 다른 테스트 지표는 무엇입니까? 여느 때처럼 아래 의견에 귀하의 생각/질문을 알려주십시오.