버그 추적 시스템

Bug tracking system

버그 추적 시스템 또는 결함 추적 시스템은 소프트웨어 개발 프로젝트에서 보고된 소프트웨어 버그를 추적하는 소프트웨어 응용 프로그램이다.이슈 추적 시스템의 일종으로 볼 수 있다.

대부분의 오픈소스 소프트웨어 프로젝트에서 사용되는 것과 같은 많은 버그 추적 시스템은 최종 사용자가 버그 보고서를 직접 입력하도록 허용한다.[1]다른 시스템들은 소프트웨어 개발을 하는 회사나 조직 내에서만 사용된다.일반적으로 버그 추적 시스템은 다른 프로젝트 관리 소프트웨어와 통합된다.

버그 추적 시스템은 일반적으로 전문 소프트웨어 개발 인프라에서 필요한 구성 요소로서 버그나 이슈 추적 시스템의 일관성 있는 사용은 "좋은 소프트웨어 팀의 특징" 중 하나로 간주된다.[2]

만들기

버그 추적 시스템의 주요 구성요소는 알려진 버그에 대한 사실을 기록하는 데이터베이스다.사실에는 버그가 보고된 시간, 심각성, 잘못된 프로그램 행동, 버그를 재생산하는 방법에 대한 세부사항뿐만 아니라 버그를 보고한 사람과 버그를 고치는 작업을 하고 있는 프로그래머의 신원을 포함할 수 있다.[3]

대표적인 버그 추적 시스템은 버그에 할당된 상태를 통해 추적되는 버그 수명 주기의 개념을 지원한다.버그 추적 시스템은 관리자가 상태를 기준으로 권한을 구성하거나, 버그를 다른 상태로 이동하거나, 버그를 삭제할 수 있도록 허용해야 한다.또한 시스템은 관리자가 버그 상태와 특정 상태의 버그를 어느 정도까지 이동할 수 있는지 구성할 수 있도록 허용해야 한다.일부 시스템은 새로운 기록이 추가되거나 상태가 변경될 때 제출자, 할당된 프로그래머와 같은 이해관계자에게 전자우편을 보낼 것이다.

버그리포트의 내용에 따라 자동진단이 가능하다.예를 들어, 버그 복제나[4] 자동 버그 수정의 자동 탐지를 할 수 있다.[5]

사용법

버그 추적 시스템의 주요 이점은 개발 요청(버그와 개선사항 모두 포함, 경계가 모호한 경우가 많음)과 그 상태에 대한 명확한 중앙집중식 개요를 제공하는 것이다.보류 중인 항목의 우선순위 목록(백로그라고도 함)은 제품 로드맵을 정의할 때 또는 "다음 릴리스"를 정의할 때 귀중한 입력을 제공한다.

기업 환경에서는 버그 추적 시스템을 사용하여 버그 수정 시 프로그래머의 생산성에 관한 보고서를 작성할 수 있다.그러나 버그마다 심각도와 복잡성의 수준이 다를 수 있기 때문에 부정확한 결과가 나올 수 있다.버그의 심각도는 버그를 고치는 복잡성과 직접 관련이 없을 수 있다.관리자와 건축가 사이에 이견이 있을 수 있다.

로컬 버그 트래커(LBT)는 일반적으로 응용 프로그램 지원 전문가 팀(종종 헬프 데스크)이 소프트웨어 개발자에게 전달되는 문제를 추적하기 위해 사용하는 컴퓨터 프로그램이다.LBT를 사용하면 지원 전문가가 "개발자의 언어"가 아닌 "자체 언어"로 버그를 추적할 수 있다.또한, LBT는 지원 전문가 팀이 불만을 제기하기 위해 전화를 건 사용자에 대한 특정 정보를 추적할 수 있도록 허용한다. 이 정보는 실제 개발 대기열에서 항상 필요한 것은 아니다.따라서, LBT가 제자리에 있을 때 두 개의 추적 시스템이 있다.

통합 프로젝트 관리 시스템의 일부

버그 및 문제 추적 시스템은 통합 프로젝트 관리 시스템의 일부로 구현되는 경우가 많다.이 접근방식은 일반 제품 개발 프로세스에서 버그 추적 및 수정, 여러 제품 버전에서 버그 수정, 제품 지식 기반 자동 생성 및 릴리스 노트를 포함할 수 있다.

분산 버그 추적

일부 버그 추적기는 분산된 개정 제어 소프트웨어와 함께 사용하도록 설계되었다.이러한 분산형 버그 추적기를 통해 개발자가 오프라인일 때 버그 보고서를 편리하게 읽거나 데이터베이스에 추가하거나 업데이트할 수 있다.[6]화석과 Veracity는 둘 다 분산된 벌레 추적기를 포함한다.

최근에는 상업용 버그 추적 시스템도 분산 버전 제어와 통합되기 시작했다.예를 들어, FogBugz는 소스 제어 도구인 Killa를 통해 이러한 기능을 가능하게 한다.[7]

위키와 버그 트래킹 시스템은 일반적으로 구별되는 유형의 소프트웨어로 간주되지만, 아이키위키는 분산형 버그 트래커로도 사용될 수 있다.통합 분산 방식으로 문서와 코드도 관리할 수 있다.그러나 그것의 쿼리 기능은 Bugzilla와 같은 다른 비분산 버그 추적기처럼 고급스럽거나 사용자 친화적이지 않다.[8]비록 그것이 그렇게 위키 소프트웨어는 아니지만, 조직 모드에 대해 유사한 진술을 할 수 있다.

버그 추적 및 테스트 관리

HP Quality Center와 IBM Rational Quality Manager와 같은 기존의 테스트 관리 툴은 자체 버그 추적 시스템과 함께 제공되지만, 다른 툴은 인기 있는 버그 추적 시스템과 통합된다.[citation needed]

참고 항목

참조

  1. ^ Bogomil Shopov (September 8, 2014). "Implement Client-side Bug Reporting". Archived from the original on 13 November 2014. Retrieved 17 November 2014.
  2. ^ Joel Spolsky (November 8, 2000). "Painless Bug Tracking". Retrieved 29 October 2010.
  3. ^ Kaner, Cem (July 2000). "Bug Advocacy" (PDF). kaner.com. pp. 81, 98. Retrieved 2021-05-19.
  4. ^ Jalbert, Nicholas; Weimer, Westley (2008). Automated duplicate detection for bug tracking systems. pp. 52–61. doi:10.1109/dsn.2008.4630070. ISBN 978-1-4244-2397-2. S2CID 11545475.
  5. ^ Koyuncu, Anil; Liu, Kui; Bissyandé, Tegawendé F.; Kim, Dongsun; Monperrus, Martin; Klein, Jacques; Le Traon, Yves (2019). "iFixR: bug report driven program repair". Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering: 314–325. arXiv:1907.05620. Bibcode:2019arXiv190705620K. doi:10.1145/3338906.3338935. ISBN 9781450355728. S2CID 196471046.
  6. ^ Jonathan Corbet (May 14, 2008). "Distributed bug tracking". LWN.net. Retrieved 7 January 2009.
  7. ^ "FogBugz Features". Fogbugz.com. Retrieved 2010-10-29.
  8. ^ Joey Hess (6 April 2007). "Integrated issue tracking with Ikiwiki". NetworkWorld.com. IDG. Retrieved 10 November 2014.

외부 링크