all one guide defect density its importance
결함 밀도 가이드 :
테스트 지표 까다 롭습니다. 측정하는 유일한 방법이지만 그 다양성은 압도적입니다.
원하는 분석을 제공하지 않는 무언가를 수집 할 수 있습니다. 여기서 가장 안전한 방법은 잘 맞은 길을 걷는 것입니다.
전 세계 거의 모든 팀이 결함 경향을 이해하기 위해 결함 밀도에 의존합니다.
오늘의 기사는 결함 밀도 (DD)에 대한 올인원 가이드입니다.
c 프로그래밍 인터뷰 질문 및 답변 설명 pdf
학습 내용 :
- 결함 밀도 란 무엇입니까?
- 버그 밀도는 어떻게 계산됩니까?
- 버그 밀도가 중요한 이유는 무엇입니까?
- 하지 말아야 할 것
- 변형
- 소프트웨어가 허용 할 수없는 버그 밀도 값은 무엇입니까?
- 마지막 생각들:
- 결론적으로
- 추천 도서
결함 밀도 란 무엇입니까?
밀도가 말 그대로 무엇을 의미하는지 살펴 보겠습니다.
'물질의 압축 정도 (출처 : Google)'입니다.
따라서 Defect Density는 응용 프로그램에서 결함의 간결함입니다. (좋아, 결함 분포의 정제 된 버전 일뿐입니다.)
응용 프로그램은 기능 영역으로 나뉩니다. 블록 (천 줄의 코드). 그러므로, 소프트웨어 애플리케이션의 섹션 또는 KLOC 당 평균 결함 수는 버그 밀도입니다.
버그 밀도는 어떻게 계산됩니까?
간단한 수학입니다.
1 단계: 원료 수집 : 총 번호가 필요합니다. 결함 수 (릴리스 / 빌드 / 사이클).
2 단계: 평균 번호를 계산하십시오. 결함 / 기능 영역 또는 KLOC
계산 예가 포함 된 결함 밀도 공식 :
예 1: 특정 테스트주기의 경우 5 개의 모듈 (또는 구성 요소)에 30 개의 결함이 있습니다. 밀도는 다음과 같습니다.
총 아니. 결함 수 / 총 모듈 수 = 30/5 = 6. 모듈 당 DD는 6입니다.
예제 # 2: 다른 관점은 15KLOC에 30 개의 결함이 있다는 것입니다. 그러면 다음과 같습니다.
총 아니. 결함 수 / KLOC = 30/15 = 0.5 = 밀도는 2 KLOC마다 1 개의 결함입니다.
예제 2는 KLOC를 알고 있고 이에 대한 측정이 필요한 팀을위한 것입니다. 대부분의 팀은 그런 종류의 통계를 사용하지 않습니다. 그러나 필요한 경우 애플리케이션이 얼마나 많은 KLOC인지 알아낼 수 있습니다.
버그 밀도가 중요한 이유는 무엇입니까?
테스트 팀이 수집하는 모든 메트릭은 다음 중 하나를 전달합니다.
- 진행
- 생산력
- 품질
그렇지 않다면 시간을 낭비하는 것입니다.
DD는 품질을 이해하는 가장 효과적인 방법입니다.
예를 들면: KLOC 당 DD 5가 포함 된 애플리케이션은 KLOC 당 15 개가 포함 된 애플리케이션보다 품질이 더 좋습니다.
버그 밀도가 높을수록 품질이 떨어집니다.
두 가지 중요한 목적을 제공합니다.
- 알림 : 정보는 힘 이지요? 애플리케이션의 가장 취약한 부분을 파악하면 '사용에 적합한 지'여부를 결정하는 데 도움이됩니다.
- 행동을 요구하다: DD가 더 높은 모듈은 수선이 필요합니다. DD는이를 식별하는 데 도움이됩니다.
하지 말아야 할 것
#1)중복 / 반품 된 결함을 고려하지 마십시오.
부정확하게 계산 된 결함 밀도는 팀을 오도 할 수 있습니다.
중복 / 반환 된 결함을 포함하지 마십시오 (버그가 아님, 의도 한대로 작동 함, 재현 불가능 , etc.) 총 수의 개수를 증가시킵니다. 즉, DD가 비례 적으로 증가합니다. 결과적으로 결함 메트릭은 불량한 품질을 암시하며 이는 확실한 오경보입니다.
#두)하루의 데이터를 기반으로하지 마십시오.
이 가상 상황을 살펴 보겠습니다.
1 일차에는 DD가 더 높습니다. 이로 인해 팀이 즉시 패닉 모드로 전환 될 수 있습니다.
그래서, 더 나은 원료가 될 때까지 기다리십시오. 즉, 며칠 분량의 데이터입니다.
또한 DD를 계산할 때 누적 결함 수를 원합니다.
위의 표에서 2 일차의 DD는 지금까지의 결함 수를 고려하지 않습니다. 그날의 데이터 만 확인합니다.
'2 일차의 결함 밀도가 감소하고 증가하고 있으며 추세가 없습니다.'라는 인상을 받았습니다. 또한 전날보고 된 결함에 대해 아무 조치도 취하지 않은 경우 결함 밀도를 어떻게 줄일 수 있습니까? 그렇지 않습니까? 생각해보세요.
이를 수행하는 더 좋은 방법은 다음과 같습니다.
다시 한번, 이 작업을 매일 수행하는 경우 누적 결함 수를 고려하십시오.
변형
팀이 필요로하는 개선 수준에 따라이 결함 메트릭을 조정할 수 있습니다.
- DD의 높음 / 중요 심각도 문제 , 공식은 다음과 같습니다.
총 아니. KLOC 또는 모듈 당 High / Critical 결함 수
- 모듈별로 문제를 반환 할 때도 이렇게 할 수 있습니다. 여기에서는 빌드 / 릴리스에서 계속 다시 발생하는 문제의 수만 수집합니다.
소프트웨어가 허용 할 수없는 버그 밀도 값은 무엇입니까?
결함 밀도 산업 표준 :
음, 이것은 모든 산업, 응용 프로그램 및 모든 팀에 따라 다릅니다. 제조에는 특정 임계 값이 있으며 IT에서는 완전히 다릅니다.
액면가의 DD는 품질이 좋지 않습니다. 그러나 제품이 사용에 적합한 지 여부를 결정하는 것은 차례로 개별 결함의 심각성입니다.
높은 DD는 결함을 더 깊이 조사하고 그 결과에 대한 결함을 분석하는 지표입니다.
무결점 밀도를 원하지 않는 사람이 있습니까? 따라서 특정 기준이 없더라도이 값이 낮을수록 좋습니다.
마지막 생각들:
- 예측 카운트가 아닙니다. DD 값은 제품의 향후 품질을 기대하는 데 도움이되지 않습니다. 더 좋거나 나쁠 수 있습니다. 과거 데이터는 향후 예측에 도움이되지 않습니다.
- 중요한 테스트 단계 /주기 (예 : UAT) 동안 DD는 시간을 기준으로 계산됩니다.예를 들면: DD / 첫 1 시간, 1 일 DD 등
- 여러 릴리스 /주기 결함 통계를 수집 할 때 결함 밀도는주기 당 또는 릴리스 당 수 있습니다.
- 표 형식 데이터의 간단한 그래픽 표현은 다음과 같습니다.
결론적으로
결함 밀도는 핵심 품질 지표입니다. 이 결함 측정 항목을 수집하고 제시하는 것은 잘못 될 수 없습니다. 또 뭔데? 계산하기 가장 쉬운 방법 중 하나입니다.
이 기사가 결함 밀도를 사용하여 더 깊은 통찰력을 얻을 수있을만큼 충분히 노출 되었기를 바랍니다.
저자 : STH 팀원 Swati가이 자세한 자습서를 작성했습니다.
팀의 결함 밀도를 계산합니까? 그렇다면주기, 모듈 또는 KLOC별로 수행합니까? 그렇지 않다면 품질을 이해하는 데 도움이되는 다른 측정 항목은 무엇입니까? 아래에 귀하의 의견과 질문을 공유하십시오.
추천 도서
- 결함 기반 테스트 기술이란 무엇입니까?
- 알파 테스트 및 베타 테스트 (전체 가이드)
- SoftwareTestingHelp의 최고의 QA 소프트웨어 테스트 서비스
- 소프트웨어 테스트 유형 : 세부 정보가있는 다양한 테스트 유형
- 소프트웨어 테스팅은 아이디어 (및 아이디어 생성 방법)에 관한 것입니다.
- 완벽한 소프트웨어 테스트 이력서 가이드 (소프트웨어 테스터 이력서 샘플 포함)
- 기능 테스트 대 비 기능 테스트
- 소프트웨어 테스트에서 결함 / 버그 수명주기는 무엇입니까? 결함 수명주기 자습서