답변:
좋은 버그 데이터베이스는 다음을 가질 수 있습니다
// 날짜 시간 관련
// +에 의해 할당
// 버그 행동
// 우선 순위
// 링크, 상태 및 기타
편집 : 나는 또한 추천하고 싶다
편집 : 나는 @jgauffin의 의견을 좋아한다
편집 : 좋은 버그 데이터베이스 시스템도 유지
프로젝트 요구에 따라 기록해야 할 여러 사용자 정의 필드 가있을 수 있습니다 . 고려해야 할 다음 목록을 생각해 냈습니다.
DateTime버그 / 결함 문제DateTimeDateTime해결되었습니다-버그가 해결되고 종료 될 때편집 : 추적 할 가치가있는 일반적인 정보의 대부분은 Bugzilla와 같은 소프트웨어에 잘 설명되어 있습니다 . 버그질라는 웹 기반의 범용 bugtracker 및 테스트 도구는 원래 개발 모질라 프로젝트에서 사용하고 모질라 공공 License- 아래에 라이센스입니다 무료 . 나는 그것들을 기본 사례로 삼아 프로젝트 요구에 따라 확장 할 것을 강력히 권합니다 .
유용한 필드의 대부분은 이미 다른 답변으로 덮여있는 것 같지만 유용한 일부는 다음과 같습니다.
버그가 발견 / 수정 된 날짜 / 시간보다 약간 더 구체적입니다.
소프트웨어가 여러 플랫폼 (OS 또는 하드웨어)에서 실행되는 경우 버그가 발생하는 플랫폼을 나열하는 필드가 필요할 수도 있습니다.
그러나 포함해야하는 필드보다 버그 데이터베이스를 유지 관리하는 것이 더 중요합니다. 또한베이스를 어떻게 사용하는지 고려해야합니다.
열려 있거나 해결되지 않은 버그 수를 가능한 한 낮게 유지하십시오. 이것은 분명해 보일 수 있지만 적어도 대규모 프로젝트의 경우 예상보다 어려울 수 있습니다. 나는 종종 재현 할 수 없거나 문제가 원래의 제출자에 의해 제공되지 않은 문제를 종결하기를 두려워하는 사람들을 종종 본다. 또한 영원히 누워 있고 고대 버전의 소프트웨어에서 마지막으로 발견 된 버그는 그대로 두어서는 안됩니다. 이로 인해 실제 문제 일 수도 있고 아닐 수도있는 문제로 인해 데이터베이스가 커지고 개발 속도가 느려집니다.
당신은 종종 버그의 역사를 볼 필요가 있습니다 버그가 다시 열릴 때마다 이 테이블은 버그 테이블과 다 대일 관계에 있으며 다음과 같은 필드가있을 수 있습니다.
특히 대규모 팀에서 일하는 경우 누가 누구에게 언제 버그를 재 할당했는지 추적하기 위해 비슷한 테이블이 필요할 수 있습니다.
또한 기존 시스템을 살펴볼 것을 제안합니다. IMHO Jira는 최고의 이슈 추적 시스템 중 하나입니다. 매우 다양한 기능이 있으며 일부 기능을 자체 시스템의 안내서로 사용할 수 있습니다.