문서요약 - 버그 분류법 by Bizer

제목: 버그 분류법(THE TAXONOMY OF BUGS)

저자: Boris Bizer

문서유형: 책 일부 발췌

 

 

책 Software Testing Techniques의 2장에 기술된 버그 분류 카테고리와 버그 분류 사례(발생 빈도 통계치)를 요약한 자료

---

 

버그 분류 체계

 

버그를 분류하는데 있어서 단 하나의 보편적으로 올바른 방식이 존재하는 것은 아니며, 버그 분류법은 융통성을 가진다. 어떤 주어진 버그가 그것의 과거 이력이나 프로그래머의 마음 상태에 따라 하나의 카테고리 또는 다른 카테고리로 넣어질 수도 있다. 주요 버그 카테고리로는 요구사항(requirements), 기능(features and functionality), 구조(structure), 데이터, 구현 및 코딩(implementation and coding), 통합(integration), 시스템 및 소프트웨어 아키텍쳐(system and software architecture), 그리고 테스팅을 들 수 있다.

 

A. 요구사항 및 기능 버그

요구사항과 명세(Requirements and Specifications)

• 요구사항과 명세가 불완전하거나(incomplete), 모호하거나(ambiguous), 자기모순적(self-contradictory)일 수 있음. 요구사항과 명세가 잘못 이해되거나 이해 불가능 할 수 있음
• 명세가 언급되지 않은 가정사항/전제조건을 갖고 있을 수 있음(명세 담당자들은 이에 대해 알고 있을지 몰라도 설계자들은 알지 못함)
• 설계가 여전히 진행 중인 동안에 명세가 계속 변경될 수 있음(움직이는 타겟)

 

기능 버그(Feature Bugs)

• 명세 문제(specification problems)는 대개 상응하는 기능 문제(feature problems)를 야기함
• 기능이 잘못되거나(wrong), 누락되거나(missing), 또는 불필요(superfluous) 할 수 있다.
• 필수적이지 않은 기능(extra features)은 한 때 바람직한 것으로 여겨졌지만, 이런 “공짜” 기능이 정말로 공짜는 아님을 인지하게 됨(즉, 신뢰성, 모듈성, 유지보수성, 견고성에 부정적인 영향을 미치지는 않는지 의심해야 함). 불필요한 기능들이 오히려 복잡성을 높여서 향후 버그를 탄생시킬 소지를 만들거나 보안 상의 결함으로 이어지는 구멍이 될 수도 있음. 하지만 역으로 좋은 설계를 낳을 수도 있는 추가 기능들을 융통성 없이 완전 차단하는 것도 바람직하지는 않음 

 

기능 상호작용(Feature Interaction) 버그

• 기능이 대개 관련된 기능들의 한 무리(그룹)로 오게되므로 분명하고, 정확하고, 구현 가능하고, 테스트 가능한 기능 명세를 제공하는 것 만으로 충분하지 않음
• 각 그룹 내의 개별 기능과 이것들의 상호작용은 대개 잘 테스트되지만, 문제는 기능 그룹들 간의 상호작용이 예측 불가능한(또는 명세되지 않은) 경우가 많다는데 있다. 

 

B. 구조적 버그(Structural Bugs)

제어 및 시퀀스 버그(Control and Sequence Bugs)

• 제어 및 시퀀스 버그로 아래와 같은 것들이 있다.
  - 빠트린 경로(paths left out)
  - 도달 불가능한 코드(unreachable code)
  - 루프의 부적절한 내포(improper nesting of loops)
  - 루프 되돌림(loop-back)이나 루프 종료(loop-termination) 기준이 부정확
  - 실종된 프로세스 단계(missing process steps)
  - 중복 프로세싱(duplicated processing)
  - 불필요한 프로세싱(unnecessary processing)
  - 미쳐 날뛰는 GOTO 문
  - 계획이 잘못된 switch 문
  - 스파게티 코드, 파칭코 코드(pachinko code)
• 테스팅 문헌에서 제어 흐름 버그를 집중적으로 다루는데 비해서 현실에서는 이 버그가 그다지 빈번하지 않음(대부분의 제어 흐름 버그가 쉽게 테스트 될 수 있고 단위 테스팅에서 발견됨). 다만 어셈블리 언어나 COBOL 코드 같은 지저분한 구 레가시 코드에서는 제어 흐름 버그가 지배적일 수도 있음
• 제어 및 시퀀스 버그는 언어 선택, 스타일, 메모리 가용량에 따라 부분적으로 예방될 수 있다.

 

로직 버그(Logic Bugs)

• 로직 상의 버그(특히, case 문과 로직 오퍼레이터가 어떻게 동작하는가에 대한 착오와 관련된 버그)로 아래와 같은 것들이 있다.
  - 실재하지 않는 케이스(nonexistent cases)
  - 부적절하게 배치된 케이스(improper layout of cases)
  - 불가능한 케이스로 간주되었지만 실제는 불가능하지 않은 경우
  - 신경 안 써도 되는 케이스로 처리했지만 실제는 문제가 되는 경우
  - boolean 표현식의 부적절한 부정(예, < 오퍼레이터의 부정으로 > 오퍼레이터를 사용)
  - 케이스의 부적절한 간소화나 조합
  - 배타적 케이스의 겹침(overlap of exclusive cases)
  - “exclusive OR”를 “inclusive OR”로 착각
  - 특정 컴파일러에서 boolean 표현식이 평가되는 순서에 대한 시맨틱을 잘못 이해
• 이런 버그가 제어 흐름과 관련 없는 논리적 프로세싱의 일부이면 ‘프로세싱 버그’로 분류되고, 제어 흐름을 결정하는 논리 표현식(즉, 제어 흐름 프레디켓)의 일부이면 ‘제어 흐름 버그’로 분류된다. 

 

프로세싱 버그(Processing Bugs)

• 프로세싱 버그는 산술적 버그(arithmetic bugs), 수학적 함수 평가(mathematical function evaluation), 알고리즘 선택, 일반 프로세싱을 포함한다. 이 영역에 있는 많은 문제들이 한 데이터 표현에서 다른 표현으로의 부정확한 전환(incorrect conversion)과 관련되어 있으며, 특히 어셈블리 언어 프로그래밍에서 이런 일이 많다.
• 기타 문제로는 다음과 같은 것들을 포함한다.
  - 오버플로우 무시
  - +0(positive zero)과 -0(negative zero) 간의 차이를 무시
  - >, >=, <, <= 오퍼레이터를 부적적하게 사용
  - 다른 형식 간의 부적절한 비교(예, ASCII와 바이너리 비교, 정수와 부동소수점 비교)

 

초기화 버그(Initialization Bugs)

• 부적절한 초기화나 불필요한 초기화가 발생할 수 있으며, 후자는 덜 해롭기는 하지만 성능에 영향을 미칠 수 있음
• 통상적인 초기화 버그로는 아래와 같은 것들이 있다.
  - 작업 공간(working space), 레지스터, 데이터 영역을 처음 사용하기 전에 초기화하는 것을 잊어버리거나 또는 어딘가 다른 곳에서 초기화 되었을 것으로 가정함
  - 루프 제어 패러미터(a loop-control parameter)의 첫 값에 버그가 존재
  - 유효성 검사(a validation check) 없이 초기 값을 수락
  - 잘못된 형식, 데이터 표현, 또는 타입으로 초기화 함

 

데이터 흐름 버그와 아노말리(Data-Flow Bugs and Anomalies)

• 대부분의 초기화 버그가 데이터 흐름 아노말리의 특수한 경우에 해당한다.
• 데이터 흐름 아노말리는 데이터를 가지고 뭔가 타당치 않은 일을 하는 경로가 있을 때 발생하며, 예를 들면 아래와 같은 것들이 있다.
  - 초기화 안된 변수를 사용
  - 변수가 존재하기 전에 그것을 사용하려고 시도
  - 데이터를 변경하고서는 그 결과를 저장하지 않거나 또는 사용하지 않음
  - 어떤 변수를 중간에 그것을 사용하는 일 없이 두 번 초기화함
• 일부 데이터 흐름 아노말리는 컴파일 타임 시 알려진 정보에 기반하여 컴파일러에 의해 발견될 수 있지만, 많은 부분이 실행을 통해서야 비로소 발견될 수 있음(즉, 테스팅에서 잡아내야 할 대상임)

 

C. 데이터 버그(Data Bugs)

 

데이터 버그는 데이터 오브젝트의 명세, 형식, 수, 초기값 등으로부터 기인하는 모든 버그를 포함한다. 데이터 버그가 코드 상의 버그 만큼이나 흔하지만 종종 아예 존재하지 않는 것처럼 여겨지기도 한다. 데이터 버그를 위해 사용되는 카테고리는 코드 버그를 위한 카테고리와 다르다.

 

동적 대비 정적(Dynamic Versus Static)

• 동적 데이터는 일시적(transitory)이며 상대적으로 짧은 생명 주기를 가짐(통상적으로 단일 트랜잭션을 프로세싱하는 시간)
• 스토리지 오브젝트가 여러 다른 형식, 속성, 잔여값(residues)을 가진 다양한 타입의 동적 데이터를 담는데 사용될 수 있는데, 이렇게 공유된 오브젝트를 제대로 초기화하는데 실패하면 앞에서 타 트랜잭션이 오브젝트를 사용하고 남긴 잔여 데이터로 인한 데이터 의존 버그(data-dependent bugs)가 생길 수 있음. 특히 버그 증상이 발견되었을 쯤에는 문제를 야기한 트랙잭션이 오래 전에 사라지고 없어서 이런 버그를 잡아내기가 어렵다.
• 정적 데이터는 그 형태와 콘텐츠가 고정되어 있으며, 소스 코드나 데이터베이스에 직접 또는 간접적으로 등장한다.
• 전처리(또는 후처리) 코드, 컴파일 타임이나 어셈블리 타임 시에 실행되는 코드, 로드 타임이나 설치 시에 실행되는 코드 모두가 결함이 있는 정적 데이터를 초래할 수 있음. 컴파일러, 어셈블러, 유틸리티, 로더(loaders), 구성기(configurators)가 당연히 정확할거라 여기고 버그 소스로 의심하지 않는 경향이 있는데, 항상 그렇지만은 않으므로 주의가 요구됨. 오브젝트 코드를 생성하는 소프트웨어도 검증이 되기 전까지는 의심을 해야 한다.
• 정적 데이터가 다른 종류 못지 않게 잘못되었을 수 있으며, 따라서 그만큼 많은 버그를 갖고 있을 수 있다. 

 

정보, 패러미터, 제어(Information, Parameter, and Control)

• 정적 데이터 또는 동적 데이터는 패러미터, 제어, 정보의 세 가지 역할 중 하나를 하게 된다(또는 이 세 가지 역할의 조합을 하게 됨).
• 정보가 대개 동적이고 단일 트랜잭션(또는 태스크)에 한정적인 경향이 있기 때문에 정보 상의 에러는(즉, 데이터가 정보로 여겨질 때) 그다지 심각한 버그가 아닐 수도 있음. 진짜 버그는 보호용의 데이터 검증 코드(data-validation code)가 결여되었거나 또는 범위 밖 데이터와 잘못된 형식의 데이터로부터 루틴의 로직을 보호하는데 실패한 것이다.
• 부적절한 데이터 확인(data validation)은 종종 서로 잘못을 미루는 결과로 이어짐. 호출하는 루틴의 작성자와 호출되는 루틴의 작성자 서로가 상대방 루틴에서 데이터가 유효한지 확인을 할 것이라고 가정하거나 또는 양측 모두가 오퍼레이터의 잘못으로 돌릴 수도 있음. 다른 프로그래머가 일을 제대로 했다면 중복적인 데이터 검증과 방어 코드가 필요하지 않을 것이라고 비난하는 이런 태도가 이해할 만은 하지만 생산적이지 않음

 

콘텐츠, 구조, 속성(Contents, Structure, and Attributes)

• 데이터 명세(data specifications)가 아래의 세 부분으로 구성된다.
  - 콘텐츠(Contents): 실제 비트 패턴, 문자열, 또는 데이터 구조로 넣어지는 숫자. 콘텐츠는 순수한 비트 패턴이며, 하드웨어 및 소프트웨어 프로세서에 의해 해석되어야 비로소 의미가 생긴다. 모든 데이터 버그가 콘텐츠의 훼손(corruption) 또는 오역(misinterpretation)을 낳는다.
  - 구조(Structure): 데이터 오브젝트를 서술하는 크기, 형태, 그리고 수. 즉, 콘텐츠를 저장하는데 사용되는 메모리 위치. 구조는 하위 구조(substructures)나 상위 구조(superstructures)를 가질 수도 있음
  - 속성(Attributes): 의미의 명세. 즉 데이터 오브젝트의 콘텐츠와 연관된 시맨틱(예, 정수, 영숫자열, 서브루틴).
• 구조적 버그는 선언 버그(declaration bugs)의 형태를 띌 수 있지만 이게 구조적 버그의 최악의 종류는 아니며, 데이터가 여러 다른 구조로 사용될 때 심각한 버그가 생길 가능성이 있음
• 데이터의 속성은 데이터와 관련된 의미(meanings)이다. 정수를 부동소수점으로 잘못 해석하는 것도 이런 버그에 해당. 동일한 데이터를 여러 다른 의미로 사용할 수도 있는데(즉, 데이터 타입을 변경), 타입이 다른 오브젝트를 논리적 또는 산술적으로 조합하는게 일반적으로 옳지 않지만 실제 이렇게 하지 않고 효율적인 시스템을 생성하는게 거의 불가능함. 따라서 타입 버그(type bugs)가 발생할 수 있음

 

D. 코딩 버그(Coding Bugs)

• 소스 언어 변환기(어셈블러, 컴파일러, 인터프리터)가 적절한 신택스 체킹을 하는 경우 신택스 에러(syntax errors)는 일반적으로 문제가 안됨. 신택스 에러를 잡아내는데 실패하는 것은 변환기에 있는 에러이며, 좋은 변환기는 미선언 데이터, 미선언 루틴, 매달린 코드(dangling code), 많은 초기화 문제들을 잡아낸다.
• 좋은 신택스 체킹이 이루어졌다고 가정했을 때 가장 흔한 코딩 버그는 오타(typographical)로 인한 에러이며(예, 문자 I 대신에 숫자 1을 사용), 그 다음은 인스트럭션/스테이트먼트의 오퍼레이션을 이해하지 못하거나 또는 그것의 부산물(by-products)로 인하여 생긴 에러이다.
• 가장 흔한 종류의 코딩 버그이자 종종 가장 해롭지 않은 것으로 여겨지는게 문서화 버그(documentation bugs)이다. 많은 문서화 버그가 단순 오타나 좋지 못한 글쓰기의 결과물이기는 하지만 실제 에러(예, 오해의 소지가 있거나 잘못된 주석)도 많이 존재함. 이게 실질적인 코딩 에러나 잘못된 유지보수 액션(따라서 또 다른 버그 삽입을 야기)으로 이어질 수 있음

 

E. 인터페이스, 통합, 시스템 버그(Interface, Integration, and System Bugs)

외부 인터페이스(External Interfaces)

• 외부 인터페이스는 외부 세계(사람, 기계)와 의사소통하는데 사용되는 수단으로 기기, 구동기, 센서, 입력 터미널, 프린터, 통신 라인 등을 포함한다.
• 모든 외부 인터페이스는 프로토콜을 사용. 프로토콜이 복잡하고 이해가 어렵기 때문에 프로토콜 자체가 틀렸거나(특히 신규 프로토콜인 경우) 또는 부정확하게 구현되었을 수 있다.
• 기타 외부 인터페이스 버그로는 외부 신호 관련 유효하지 않은 타이밍이나 시퀀스를 가정, 외부 입력 및 출력 형식을 잘못 이해, 나쁜 입력 데이터에 대한 불충분한 용인(insufficient tolerance to bad input data) 등이 포함된다.

 

내부 인터페이스(Internal Interfaces)

• 내부 인터페이스는 원칙적으로 외부 인터페이스와 다르지 않지만, 내부 환경은 더 통제적일 수 있으므로 실제로는 차이가 존재한다. 즉, 외부 환경은 고정적이라 시스템이 반드시 그것에 맞추어야 하지만, 타 컴포넌트들과의 인터페이스로 구성된 내부 환경은 협상이 가능하다.
• 내부 인터페이스는 외부 인터페이스가 가진 것과 동일한 문제를 가지며, 또한 구현 상세사항과 더 긴밀히 관련된 몇몇 추가적 문제들도 가진다(예, 프로토콜 설계 버그, 입력 및 출력 형식 버그, 훼손 데이터에 대한 부적절한 보호, 잘못된 서브루틴 호출 시퀀스, 콜 패러미터 버그, 잘못 이해된 입력/출력 패러미터 값)

 

하드웨어 아키텍쳐(Hardware Architecture)와 인터페이스 문제

• 하드웨어 아키텍쳐에 관련된 소프트웨어 버그는 대개 하드웨어가 어떻게 작동하는지를 잘못 이해한 것으로부터 기인하며, 아래와 같은 예를 들 수 있다.
  - 페이징 메커니즘이 무시되거나 잘못 이해됨
  - 어드레스 생성 에러(address-generation error)
  - I/O-디바이스 오퍼레이션 또는 인스트럭션 에러
  - I/O-디바이스 어드레스 에러
  - 잘못 이해된 디바이스-상태 코드
  - 부적절한 하드웨어 동시성(simultaneity) 가정
  - 하드웨어 경합 조건(race condition)이 무시됨
  - 디바이스를 위한 데이터 형식이 잘못됨
  - 디바이스 프로토콜 에러
  - 디바이스 인스트럭션-시퀀스 제한이 무시됨
  - 너무 빠른 디바이스 반응 속도를 기대함
  - 응답(response)을 너무 오래 기다림,
  - 채널 처리량(throughput) 제한을 무시함
  - 디바이스가 초기화되었다고 가정함, 디바이스가 초기화되지 않았다고 가정함
  - 부정확한 인터럽트 처리(interrupt handling)
  - 하드웨어 결함이나 에러 조건을 무시함
  - 오퍼레이터에게 악의가 있을 수도 있음을 무시함
• 하드웨어 인터페이스 테스팅에서 실제 하드웨어 대신에 하드웨어 시뮬레이터를 사용하는 경우, 실제 버그와 하드웨어 시뮬레이터 구현 버그 간의 구분을 해야하는 문제에 마주치게 된다.

 

운영 체제(Operating System) 인터페이스 버그

• 운영 체제에 관련된 프로그램 버그는 하드웨어 아키텍쳐와 인터페이스 버그의 조합이며, 대개 운영 체제가 하는 일이 무엇인지를 잘못 이해한데서 야기된다. 물론 운영 체제가 자체적인 버그를 가지고 있을 수도 있다.
• 운영 체제는 모든 하드웨어 인터페이스 이슈가 운영 체제에 의해 처리된다는 잘못된 안도감을 프로그래머에게 심어 줄 수 있다.

 

소프트웨어 아키텍쳐(Software Architecture)

• 루틴이 소프트웨어 아키텍쳐 버그를 드러내지 않은 채 단위 테스팅과 통합 테스팅을 통과할 수 있으며, 이런 버그의 많은 부분이 부하(load)에 의존함. 즉, 시스템이 스트레스를 받을 때에만 그 증상이 나타나므로 이를 발견하고 수정하기가 쉽지 않음
• 아키텍쳐 버그는 대개 부정확한 가정에 기반하며, 아래와 같은 예를 들 수 있다.
  - 인터럽트가 없을 것이라고 가정함
  - 인터럽트를 차단하는데(또는 차단 해제하는데) 실패함
  - 코드가 재진입가능하다고(reentrant) 또는 재진입가능하지 않다고 가정함
  - 데이터 인터록(data interlocks)을 우회함
  - 인터록을 닫는데 또는 여는데 실패함
  - 호출되는 루틴이 주재한다고(resident) 또는 주재하지 않는다고 가정함
  - 호출하는 프로그램이 주재한다고(resident) 또는 주재하지 않는다고 가정함
  - 레지스터/메모리가 초기화되었다고 또는 초기화되지 않았다고 가정함
  - 레지스터/메모리 위치 콘텐츠가 변경되지 않았다고 가정함
  - 글로벌 패러미터의 로컬 세팅, 로컬 패러미터의 글로벌 세팅

 

제어 및 시퀀스 버그(Control and Sequence Bugs)

 

• 시스템 레벨의 제어 및 시퀀스 버그로 아래와 같은 것들이 있다.
  - 타이밍이 무시됨
  - 이벤트가 특정 시퀀스로 발생한다고 가정함
  - 프로세스를 그것의 전제조건이 충족되기 전에 시작함(예, 디스크로부터 모든 데이터가 도착하기 전에 데이터에 작업을 수행함)
  - 전제조건들의 불가능한 조합을 기다림
  - 전제조건이 충족되었는데 이를 인식하지 못함
  - 잘못된 우선순위, 프로그램 상태, 또는 프로세싱 레벨을 명세함
  - 누락된/잘못된/중복된/불필요한 프로세스 단계(process steps)

 

리소스 관리 문제(Resource Management Problems)

• 메모리는 버퍼 블록, 큐 블록, 태스크 컨트롤 블록, 오버레이 버퍼 같은 동적 할당 리소스로 세분되며, 외부 대용량 저장 장치(예, 디스크)도 메모리-리소스 풀로 세분됨
• 리소스 사용 및 관리 버그로 아래와 같은 것들이 있다.
  - 요구되는 리소스가 획득되지 않음
  - 잘못된 리소스가 사용됨(동일한 구조를 가진 여러 리소스가 존재하거나 동일한 풀에 여러 다른 종류의 리소스가 있는 경우 흔히 발생)
  - 리소스가 이미 사용 중임
  - 리소스를 얻는데 있어서 경합 조건
  - 리소스가 올바른 풀로 반환되지 않음
  - 분할된 리소스(fractionated resources)가 제대로 재조합되지 않음
  - 리소스를 반환하는데 실패함
  - 리소스 교착 상태(resource deadlock)
  - 리소스 사용이 호출자에게 금지됨
  - 사용된 리소스가 반환되지 않음
  - 리소스가 잘못된 종류의 큐에 연결됨
  - 리소스를 반환해야 하는 것을 잊어버림
• 리소스 손실(resource loss)은 가장 빈번한 리소스 관련 버그이다. 

 

통합 버그(Integration Bugs)

• 통합 버그는 (이미 테스트되었고 잘 동작하는) 컴포넌트들 간의 인터페이스 또는 그것들의 통합과 관련된 버그이며, 주로 컴포넌트들 간의 불일치(inconsistencies)나 비호환성(incompatibilities)으로부터 기인한다.
• 직접 또는 간접적으로 컴포넌트 간의 데이터 이전을 하는데 사용되는 모든 방법, 그리고  컴포넌트들의 데이터 공유를 가능케 하는 모든 방법이 통합 버그를 가질 수 있다(즉, 통합 테스팅의 적절한 타겟).
• 통신 방법으로는 데이터 구조, 콜 시퀀스, 레지스터, 세마포어, 통신 링크, 프로토콜 등이 포함된다.
• 통합 버그는 빈도가 높은 버그 카테고리는 아니지만, 보통 뒤늦게 발견되고 여러 컴포넌트와 데이터 구조의 변경을 요구하므로 값 비싼 버그이다. 

 

시스템 버그(System Bugs)

• 시스템 버그는 특정 컴포넌트나 그것들의 단순 상호작용 탓으로 돌릴 수 없는, 많은 컴포넌트들(예, 프로그램, 데이터, 하드웨어, 운영체제) 간의 상호작용 전체(totality)로부터 생기는 모든 종류의 버그를 커버하는 포괄적인 용어이다.
• 충분한 컴포넌트 테스팅과 통합 테스팅이 있기 전까지는 의미 있는 시스템 테스팅이 일어날 수 없다.
• 시스템 버그는 발생 빈도가 낮지만, 종종 시스템이 시장에 나간 후에서야 비로소 발견되고 버그 수정이 간단한 경우도 드물기 때문에 매우 중요하다(비싸다).

 

F. 테스트와 테스트 설계 버그(Test and Test Design Bugs)

• 테스터라고 버그에 면역이 있는 것은 아님. 테스트(특히 시스템 테스트)가 복잡한 시나리오와 데이터베이스, 그리고 실행되는 테스트 코드를 요구함에 따라 테스트 자체도 버그를 가질 수 있다.
• 테스트 버그가 소프트웨어 버그는 아니지만 이 둘을 따로 떼어 말하기 어렵다(이를 구별시키는데 많은 노력이 소요될 수 있음).

 

샘플 버그 통계치

• 아래 데이터는 독립 테스팅, 통합 테스팅, 시스템 테스팅에서 잡힌 버그들에 대한 것이며, 컴포넌트 레벨의 셀프 테스팅에서 프로그래머에 의해 발견된 버그의 수는 알 수 없다.
• 아래 표의 중요성은 절대적인 버그 빈도(즉, 코드 1000 라인 당 얼마나 많은 버그가 존재하는지)에 있는 것이 아니라 카테코리별 버그의 상대적 빈도에 있다.

 

샘플 크기: 6,877,000 스테이트먼트(주석 포함)

총 보고된 버그 수: 16,209개(1,000 스테이트먼트 당 2.36개)

버그 유형		버그 수	비중
1 요구사항(REQUIREMENTS)		1,317	8.1%
	11 부정확한 요구사항(Requirements Incorrect)	649	4.0%
	12 요구사항 로직(Requirements Logic)	153	0.9%
	13 요구사항 완전성(Requirements, Completeness)	224	1.4%
	14 표현, 문서화(Presentation, Documentation)	13	0.1%
	15 요구사항 변경(Requirements Changes)	278	1.7%
2 기능(FEATURES AND FUNCTIONALITY)		2,624	16.2%
	21 기능 정확성(Feature/Function Correctness)	456	2.8%
	22 기능 완전성(Feature Completeness)	231	1.4%
	23 기능 케이스 완전성(Functional Case Completeness)	193	1.2%
	24 도메인 버그(Domain Bugs)	778	4.8%
	25 사용자 메시지와 진단(User Messages and Diagnostics)	857	5.3%
	26 예외 조건 잘못 처리(Exception Condition Mishandled)	79	0.5%
	29 기타 기능적 버그(Other Functional Bugs)	30	0.2%
3 구조적 버그(STRUCTURAL BUGS)		4,082	25.2%
	31 제어 흐름과 시퀀싱(Control Flow and Sequencing)	2,078	12.8%
	32 프로세싱(Processing)	2,004	12.4%
4 데이터 버그(DATA)		3,638	22.4%
	41 데이터 정의 및 구조(Data Definition and Structure)	1,805	11.1%
	42 데이터 접근 및 처리(Data Access and Handling)	1,831	11.3%
	49 기타 데이터 문제(Other Data Problems)	2	0.0%
5 구현 및 코딩(IMPLEMENTATION AND CODING)		1,601	9.9%
	51 코딩과 오타(Coding and Typographical)	322	2.0%
	52 스타일 및 표준 위반(Style and Standards Violations)	318	2.0%
	53 문서화(Documentation)	960	5.9%
	59 기타 구현 문제(Other Implementation)	1	0.0%
6 통합(INTEGRATION)		1,455	9.0%
	61 내부 인터페이스(Internal Interfaces)	859	5.3%
	62 외부 인터페이스, 타이밍, 처리량(Throughput)	518	3.2%
	69 기타 통합 문제(Other Integration)	78	0.5%
7 시스템 및 소프트웨어 아키텍쳐(SYSTEM, SOFTWARE ARCHITECTURE)		282	1.7%
	71 운영 체제 호출과 사용(O/S Call and Use)	47	0.3%
	72 소프트웨어 아키텍쳐(Software Architecture)	139	0.9%
	73 복구와 책임추적성(Recovery and Accountability)	4	0.0%
	74 성능(Performance)	64	0.4%
	75 부정확한 진단, 예외(Incorrect Diagnostics, Exceptions)	16	0.1%
	76 파티션, 오버레이(Partitions, Overlays)	3	0.0%
	77 Sysgen(OS를 시스템의 형상에 맞게 제작), 환경(Environment)	9	0.1%
8 테스트 정의와 실행(TEST DEFINITION AND EXECUTION)		447	2.8%
	81 테스트 설계 버그(Test Design Bugs)	11	0.1%
	82 테스트 실행 버그(Test Execution Bugs)	355	2.2%
	83 테스트 문서화(Test Documentation)	11	0.1%
	84 테스트 케이스 완전성(Test Case Completeness)	64	0.4%
	89 기타 테스팅 버그(Other Testing Bugs)	6	0.0%
9 기타, 명세 안됨(OTHER, UNSPECIFIED)		763	4.7%