소프트웨어 테스팅 지표: 정의, 유형 및 예
토마스 해밀턴
⚡ 스마트 요약
소프트웨어 테스팅 메트릭은 테스팅 프로세스의 진행 상황, 품질 및 생산성을 정량적으로 측정하는 지표입니다. 이 가이드에서는 세 가지 메트릭 유형, 기본 메트릭과 계산 메트릭의 차이점, 메트릭 수명 주기, 그리고 바로 적용할 수 있는 공식 용어집을 다룹니다.
소프트웨어 테스트 메트릭이란 무엇인가요?
소프트웨어 테스팅 지표 소프트웨어 테스팅 프로세스의 진행 상황, 품질, 생산성 및 상태를 추정하는 데 사용되는 정량적 측정값입니다. 소프트웨어 테스트 측정항목의 목표는 소프트웨어 테스트 프로세스의 효율성과 효과를 향상시키고 테스트 프로세스에 대한 신뢰할 수 있는 데이터를 제공하여 추가 테스트 프로세스에 대한 더 나은 결정을 내리는 데 도움을 주는 것입니다.
측정 지표는 시스템, 구성 요소 또는 프로세스가 특정 속성을 어느 정도 가지고 있는지를 정량적으로 나타냅니다. 간단한 비유를 들자면, 자동차의 실제 주간 연료 소비량과 제조업체가 제시한 수치를 비교하는 것과 같습니다.
소프트웨어 테스트 지표 – 소프트웨어 테스트 프로세스의 효율성과 효과를 향상시킵니다.
소프트웨어 테스팅 지표 또는 소프트웨어 테스트 측정은 프로세스 또는 제품의 일부 속성의 범위, 용량, 차원, 양 또는 크기를 정량적으로 표시합니다.
소프트웨어 테스트 측정의 예: 총 결점 수
테스트 지표가 중요한 이유는 무엇일까요?
"측정할 수 없는 것은 개선할 수 없습니다." 테스트 지표는 테스트 과정을 측정 가능하게 만들기 위해 존재합니다.
- 다음 단계 활동이 무엇이어야 할지 결정하세요
- 품질에 관한 주장이나 예측에 대한 증거를 제시하십시오.
- 어떤 종류의 개선이 필요한지 파악하십시오.
- 프로세스 또는 기술 변경을 정당화하십시오
그것에 대해 더 읽어보세요 테스트 지표의 중요성
테스트 지표 유형
- 프로세스 지표: SDLC의 공정 효율성을 향상시키는 데 사용할 수 있습니다(소프트웨어 개발 수명주기)
- 제품 지표: 소프트웨어 제품의 품질을 다룬다.
-
프로젝트 지표: 프로젝트 팀의 효율성을 측정하는 데 사용할 수 있습니다. 테스트 도구 팀원들이 사용하고 있는
많은 지표를 수집하는 것보다 적절한 지표를 선택하는 것이 더 중요합니다. 지표 세트를 확정하기 전에 다음 사항을 고려하십시오.
- 측정항목 준비를 위한 대상 고객을 수정하세요.
- 측정항목 목표 정의
- 프로젝트 요구 사항을 기반으로 모든 관련 지표를 도입합니다.
- 각 지표의 비용과 이점을 비교 분석하고, 프로젝트 수명주기 단계에서 가장 큰 가치를 제공하는 시점을 파악하십시오.
수동 테스트 지표
In 소프트웨어 공학, 수동 테스트 측정항목은 두 가지 클래스로 분류됩니다.
- 기본 메트릭
- 계산된 지표
기본 메트릭은 테스트 사례 개발 및 실행 중에 Test Analyst가 수집한 원시 데이터입니다(실행된 테스트 케이스 수, 테스트 케이스 수). 계산된 지표는 기본 지표에서 수집된 데이터에서 파생됩니다. 계산된 측정항목은 일반적으로 테스트 보고 목적으로 테스트 관리자가 따릅니다(완료율, 테스트 적용 범위 %).
프로젝트 또는 비즈니스 모델에 따라 가장 중요한 지표는 일반적으로 다음과 같습니다.
- 테스트 케이스 실행 생산성 지표
- 테스트 케이스 준비 생산성 지표
- 결함 지표
- 우선순위별 결함
- 심각도별 결함
- 결함 미끄러짐 비율
수동 테스트와 자동화 테스트의 측정 지표 비교
위에서 설명한 지표는 수동으로 실행한 테스트 스위트를 기준으로 합니다. 자동화된 테스트 스위트는 실행 노력이 더 이상 제약 조건이 아니므로 측정 방식이 다릅니다.
| 기준 | 수동 테스트 지표 | 자동화 테스트 지표 |
|---|---|---|
| 주요 초점 | 노력 및 실행 진행 상황 | 커버리지, 안정성 및 실행 시간 |
| 일반적인 측정 | 하루 동안 실행된 테스트 케이스 수 | 자동화 적용률 |
| 품질 신호 | 테스트 시간당 발견된 결함 수 | 불안정한 테스트 비율, 즉 불안정한 테스트의 비율 |
| 비용 측정 | 테스터 시간 | 릴리스별 스크립트 유지 관리 시간 |
| 속도 측정 | 주기 기간(일) | 스위트 실행 시간(분) |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
불안정한 테스트 성공률은 특히 주의해야 합니다. 이 비율이 대략 5%를 넘어서면 팀들은 레드 빌드를 무시하기 시작하고, 그 시점부터는 테스트 범위가 아무리 높더라도 해당 테스트 스위트가 더 이상 정보를 제공하지 않게 됩니다.
소프트웨어 엔지니어링의 테스트 지표 수명주기
| 측정항목 수명주기의 다양한 단계 | 각 단계의 단계 |
|---|---|
| 분석 |
|
| 소통 |
|
| 평가 |
|
| Report |
|
테스트 지표 계산 방법
| Sr # | 측정항목을 테스트하는 단계 | 예시 |
|---|---|---|
| 1 | 키를 식별하세요 소프트웨어 테스팅 측정할 프로세스 | 테스트 진행 상황 trac왕 과정 |
| 2 | 이 단계에서 테스터는 데이터를 기준으로 사용하여 측정항목을 정의합니다. | 하루에 실행될 예정인 테스트 케이스 수 |
| 3 | 추적할 정보의 결정, 빈도 trac왕과 책임자 | 일일 실제 테스트 실행은 하루가 끝날 때 테스트 관리자가 캡처합니다. |
| 4 | 정의된 지표의 효과적인 계산, 관리 및 해석 | 하루에 실행되는 실제 테스트 사례 |
| 5 | 정의된 지표의 해석에 따라 개선 영역 식별 | If 테스트 사례 목표 달성률이 합의된 목표에 미치지 못할 경우, 원인을 조사하고 시정 조치를 제안해야 합니다. |
테스트 지표 계산 예시
테스트 케이스 실행률을 예시로 들어 보겠습니다. 실행 상태를 백분율로 나타내려면 다음 공식을 사용합니다.
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
250개의 테스트 케이스가 작성되었고 175개가 실행되었다면 결과는 (175 / 250) x 100 = 입니다. 70 비율.
실행되지 않은 테스트 케이스, 통과한 테스트 케이스, 실패한 테스트 케이스, 차단된 테스트 케이스 등 다른 모든 실행 매개변수에도 동일한 패턴이 적용됩니다. 각각은 동일한 분모에 대한 서로 다른 분자일 뿐입니다.
가장 중요한 테스트 지표 Track
이 튜토리얼 끝부분의 용어집에는 일반적으로 사용되는 모든 수식이 나열되어 있습니다. 실제로 보고서 패키지에는 8개 이상의 수식이 필요한 경우는 드뭅니다. 이 8개 수식은 의사 결정에 있어 핵심적인 역할을 합니다.
| 메트릭 | 그것이 답하는 것 | 조심해 |
|---|---|---|
| 테스트 케이스 실행률 | 계획된 일정 중 지금 어디까지 진행했나요? | 품질에 대해서는 아무것도 말해주지 않고, 단지 발전에 대해서만 말해준다. |
| 결함 밀도 | 단위 크기당 결함 수를 고려했을 때, 어떤 모듈이 가장 약한가요? | 일관된 크기 측정 방식에 따라 달라집니다. |
| 결함 제거 효율 | 출시 전에 얼마나 많은 결함을 발견했습니까? | 생산 데이터가 도착한 후에야 최종 확정될 수 있습니다. |
| 결함 누출 | 고객에게 전달된 불량품은 몇 개입니까? | 가장 중요한 품질 신호 |
| 테스트 커버리지 | 요구사항 세트 중 얼마나 많은 부분이 충족되었습니까? | 근거가 약한 주장으로 높은 커버리지를 얻는 것은 아무것도 증명하지 못한다 |
| 결함 심각도 지수 | 개방된 결손 부위는 심각한 문제인가요, 아니면 미용상의 문제인가요? | 가중치를 고려하지 않고 결함 수를 세는 것은 오해를 불러일으킵니다. |
| 수리 평균 시간 | 팀이 문제를 해결하는 데 걸리는 시간은 얼마나 되나요? | 몇 가지 오랜 결함으로 인해 왜곡됨 |
| 테스트 실행 생산성 | 테스터는 하루에 몇 건의 테스트를 완료합니까? | 목표로 사용할 경우 얕은 테스트를 권장합니다. |
경영진이 요구하는 공식 두 가지를 용어집에 추가할 가치가 있습니다.
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
측정의 함정. 목표로 사용되는 모든 지표는 더 이상 좋은 측정 기준이 될 수 없습니다. 예를 들어, 하루 30개의 테스트 케이스 작성이라는 생산성 목표를 설정하면 테스터들은 30개의 사소한 테스트 케이스만 작성할 것입니다. 지표는 개별적으로가 아니라 전체적으로 보고해야 하며, 모든 생산성 지표와 품질 지표를 함께 제시해야 합니다.
소프트웨어 테스트 측정 지표 공식 용어집
- 재작업 노력 비율 = (해당 단계에 소요된 실제 재작업 노력량/해당 단계에 소요된 총 실제 노력량) X 100
- 요구사항 크리프 = (추가된 총 요구사항 수/초기 요구사항 수)×100
- 일정 차이 = (실제 배송일 – 배송 예정일)
- 테스트에서 결함을 찾는 비용 = (테스트에 소요된 총 노력/테스트 중 발견된 결함)
- 일정 지연 = (실제 종료일 – 예상 종료일) / (예정 종료일 – 예정 시작일) X 100
- 통과된 테스트 사례 비율 = (통과된 테스트 수/실행된 총 테스트 수) X 100
- 실패한 테스트 사례 비율 = (실패한 테스트 수/실행된 총 테스트 수) X 100
- 차단된 테스트 사례 비율 = (차단된 테스트 수/실행된 총 테스트 수) X 100
- 수정된 결함 비율 = (수정된 결함/보고된 결함) X 100
- 허용된 결함 비율 = (개발팀에서 유효한 것으로 승인한 결함 /보고된 총 결함) X 100
- 결함 지연 백분율 = (향후 릴리스를 위해 연기된 결함 /보고된 총 결함) X 100
- 심각한 결함 비율 = (심각한 결함 / 보고된 총 결함) X 100
- 개발팀이 결함을 복구하는 데 걸리는 평균 시간 = (버그 수정에 걸린 총 시간/버그 수)
- 기간당 실행되는 테스트 수 = 테스트 실행 횟수/총 시간
- 테스트 설계 효율성 = 설계된 테스트 수/총 시간
- 테스트 검토 효율성 = 검토된 테스트 수/총 시간
- 버그 발견율또는 시험 시간당 결함 수 = 총 결함 수 / 총 시험 시간
