결함 밀도란 무엇입니까? 예제로 계산하는 공식

결함 밀도란 무엇입니까?

결함 밀도 결함률(Default Rate, DPF)은 특정 운영 또는 개발 기간 동안 소프트웨어 또는 모듈에서 확인된 결함 수를 해당 소프트웨어 또는 모듈의 크기로 나눈 값입니다. 이를 통해 팀은 소프트웨어 출시 준비 여부를 결정할 수 있습니다.

결함 밀도는 코드 1,000줄당(KLOC)으로 계산됩니다. 모듈 크기에 따라 정규화되기 때문에 결함이 많은 대형 모듈과 결함이 적은 소형 모듈을 동일한 기준으로 비교할 수 있습니다. 이는 단순히 버그만 집계하는 방식으로는 불가능한 장점입니다.

해당 지표는 일반적으로 테스트 주기 종료 시점에 보고됩니다. tracked는 여러 차례 릴리스되었으므로 나머지와 함께 배치됩니다. 결함 관리 프로세스 인간을 소프트웨어 테스팅 수명주기.

결함 밀도 계산 방법

결함 밀도를 측정하는 공식:

Defect Density = Defect count/size of the release

릴리스 크기는 코드 라인 수(LOC)로 측정할 수 있습니다.

결과 숫자가 의미를 갖는지 여부는 세 가지 세부 사항에 달려 있습니다.

• 크기 단위. LOC와 KLOC는 가장 일반적인 단위입니다. 기능 포인트는 프로그래밍 언어에 따라 변하지 않는 크기 측정 기준을 원하는 팀에서 사용하며, 일부 팀은 모듈 또는 구성 요소별로 정규화하기도 합니다.
• 결함으로 간주되는 것은 무엇입니까? 분자에는 확인된 결함만 포함되어야 합니다. 중복, 거부된 보고서 및 개선 요청은 제외해야 합니다. 그렇지 않으면 코드 품질 변화 없이 수치가 부풀려집니다.
• 측정 범위. 시스템 테스트 중에 발견된 결함 회귀 테스트그리고 출시 후에는 다른 내용을 설명하므로 기간을 숫자로 명시해야 합니다.

결함 밀도 예

소프트웨어 제품에 3개의 모듈이 통합되어 있다고 가정해 보겠습니다. 각 모듈에서 발견된 버그의 수는 다음과 같습니다.

• 모듈 1 = 버그 10개
• 모듈 2 = 버그 20개
• 모듈 3 = 버그 10개

총 벌레 수 = 10+20+10 = 40

각 모듈의 전체 코드 줄 수는 다음과 같습니다.

• 모듈 1 = 1000 LOC
• 모듈 2 = 1500 LOC
• 모듈 3 = 500 LOC

총 라인 Code = 1000+1500+500 = 3000

결함 밀도는 다음과 같이 계산됩니다.

Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc

아래 차트에서 볼 수 있듯이, 모듈별로 동일한 계산을 적용하는 것이 합산 수치보다 더 유용합니다. 모듈 2는 1500줄의 코드에 20개의 결함이 있고, 모듈 3은 500줄의 코드에 10개의 결함이 있으므로, 보고된 버그 수는 더 적지만 모듈 3이 두 모듈 중 결함 밀도가 더 높고 위험도가 더 큽니다.

결함 밀도에 대한 표준

결함 밀도에 대한 고정된 기준은 없습니다. 연구에 따르면 하나는 결함 코드 1,000줄당 높은 수치는 일반적으로 프로젝트 품질의 지표로 여겨지며, 이는 업계에서 가장 널리 인용되는 경험 법칙입니다.

기대치는 해당 분야에 따라 달라집니다. 항공전자 장비나 의료기기와 같은 안전 필수 및 규제 대상 소프트웨어는 KLOC당 결함 1개 미만이라는 목표를 훨씬 충족해야 하는 반면, 일반 비즈니스 애플리케이션은 일반적으로 이 목표를 초과합니다. 조직마다 계산 규칙, 크기 단위, 테스트 깊이가 다르기 때문에 발표된 연구에서 가져온 벤치마크는 동일한 방식으로 측정된 프로젝트에서만 비교할 수 있습니다. 따라서 이 지표의 실제 활용은 내부적인 용도로만 사용됩니다. 즉, 동일한 제품의 이전 릴리스와 동일한 방식으로 측정된 릴리스를 비교하는 데 사용됩니다.

결함 밀도에 영향을 미치는 요인

동일한 코드베이스라도 다음과 같은 요인에 따라 결함 밀도 수치가 매우 다르게 나타날 수 있습니다.

• Code 복잡성. 깊이 중첩된 논리와 높은 순환 복잡도 단순한 코드보다 한 줄당 더 많은 결함을 생성합니다.
• 고려된 결함 유형. 기능적 결함만 계산하는가, 아니면 사용성, 문서화 등을 포함하는가? 기능하지 않는 연구 결과는 분자를 상당히 변화시킵니다.
• 고려된 시간 기간. 2주간의 테스트 주기 동안 측정된 수치는 6개월간의 실제 사용 기간 동안 측정된 수치와 비교할 수 없습니다.
• 개발자 및 테스터 역량. 숙련된 개발자는 결함을 덜 주입하고, 숙련된 테스터는 존재하는 결함을 더 많이 찾아내므로 이 두 가지 효과가 지표를 반대 방향으로 끌어당깁니다.
• 테스트 범위. 애초에 찾지 않았던 결함은 집계되지 않으므로, 테스트 범위 측정된 밀도가 도달할 수 있는 최대치를 조용히 제한합니다.

결함 밀도와 기타 결함 지표 비교

결함 밀도는 알려진 결함이 얼마나 집중되어 있는지라는 한 가지 질문에 답합니다. 세 가지 보조 지표는 결함 밀도가 답할 수 없는 질문에 답하며, 대부분의 팀은 이 세 가지 지표를 함께 보고합니다.

이 네 가지를 함께 읽어보면 더 완전한 그림을 얻을 수 있습니다. 결함 밀도가 낮고 결함 누출이 높다는 것은 깔끔한 코드보다는 얕은 테스트를 의미하며, 이는 다음 섹션에서 경고하는 바로 그 오해입니다.

결함 밀도의 장점

결함 밀도의 장점은 다음과 같습니다.

• 이는 테스트의 효과성을 측정하는 데 도움이 됩니다.
• 이는 구성 요소와 소프트웨어 모듈 간의 결함 집중도를 구분하는 데 도움이 됩니다.
• 이는 수정이나 개선이 필요한 부분을 파악하는 데 유용합니다.
• 이는 위험도가 높은 구성 요소를 지적하는 데 유용하며, 이는 직접적으로 다음 단계로 이어집니다. 위험 기반 테스트.
• 이는 다양한 인력의 교육 요구 사항을 파악하는 데 도움이 됩니다.
• 결함으로 인해 발생하는 테스트 및 재작업 노력량을 추정하는 데 도움이 될 수 있습니다.
• 소프트웨어에 남아있는 결함을 추정할 수 있습니다.
• 출시 전에 지금까지 진행된 테스트가 충분한지 판단하는 데 도움이 됩니다.
• 이는 향후 출시될 제품들을 평가할 수 있는 기준선을 구축하는 데 도움이 됩니다.

결함 밀도의 한계

이 지표는 계산하기 쉽지만 잘못 해석하기 쉽습니다. 다음 제한 사항들이 릴리스 결정에서 이 지표의 중요도를 결정합니다.

• 발견되지 않은 결함은 보이지 않습니다. 분자에는 실제로 테스트를 통해 발견된 결함만 포함되므로, 테스트가 부실한 모듈은 실제보다 좋은 수치를 보여줍니다.
• 심각성은 무시됩니다. 결제를 손상시키는 결함 하나와 외관상의 정렬 문제 하나는 동일하게 취급되므로, 심각도에 따라 가중치를 부여하는 방식이 함께 필요합니다.
• 결함 정의는 다양합니다. 서로 다른 방식으로 계산하는 두 팀의 결과는 같은 조직 내에서도 비교할 수 없습니다.
• 코드 줄 수는 크기를 나타내는 약한 지표입니다. 장황한 코드는 아무런 이점도 없이 밀도를 낮추고, 단위는 프로그래밍 언어마다 비교할 수 없습니다.
• 해당 지표는 조작될 수 있다. 애매한 보고서를 거부하거나 항목 수를 부풀리는 것은 제품의 품질을 향상시키지 않고 수치만 개선하는 행위입니다.

이 모든 것이 결함 밀도 지표를 무용지물로 만드는 것은 아닙니다. 다만, 결함 밀도는 팀 간 비교 지표라기보다는 특정 제품을 지속적으로 측정했을 때의 추세 지표일 뿐입니다.

결함 밀도를 줄이는 방법

결함 밀도를 서류상으로만 낮추는 것이 아니라 실제로 낮추려면 결함을 더 일찍 예방하고 출시 전에 나머지 결함을 찾아내야 합니다. 아래 나열된 방법들은 공개된 지침 전반에서 반복적으로 언급되는 사항들입니다.

• 테스트 시기를 앞당기세요. 요구사항 및 설계 단계에서 테스터를 참여시키면 코드가 작성되기 전에 모호한 부분을 잡아낼 수 있으며, 결함 제거 비용이 가장 저렴한 단계가 바로 이 시점입니다.
• Rev병합하기 전에 코드를 확인하세요. 동료 검토는 논리적 오류, 요구사항에 대한 오해, 설계 결함 등을 잡아냅니다. 단위 테스트 찾아보려고 쓴 글입니다.
• 회귀 테스트 스위트를 자동화하세요. 모든 커밋에 대해 검사를 실행합니다. 지속적인 통합 새로운 코드를 작성하는 동안 기존의 결함이 다시 발생하는 것을 방지합니다.
• 테스트 코드를 먼저 작성하세요. 테스트 주도 개발 각 동작이 구현되기 전에 명시되어야 함을 강제합니다. 돌연변이 테스트 그러면 결과 테스트가 실제로 어떤 것을 주장하는지 확인할 수 있습니다.
• 정적 분석을 사용하세요. 자동화된 코드 스캔은 단일 테스트가 실행되기 전에 널 역참조, 리소스 누수 및 복잡성 병목 현상을 표시합니다.
• 밀집된 모듈들을 리팩토링하세요. 결함 밀도 분석에서 가장 문제가 심각한 구성 요소를 파악한 후에는 해당 구성 요소를 분할하고 단순화하면 일반적으로 복잡성과 결함 수를 모두 줄일 수 있습니다.
• 결함을 다시 공정에 투입하십시오. 회고 시 근본 원인 분석을 통해 개별적인 결함을 일회성 임시방편이 아닌 프로세스 개선으로 전환할 수 있습니다.

Tracked 릴리스는 함께 릴리스되었습니다. 소프트웨어 테스트 기법 커버리지 데이터와 함께, 결함 밀도는 성적표라기보다는 조기 경보 시스템이 됩니다.

자주 묻는 질문