무엇이 버그를 구성합니까?


10

실제로 버그는 무엇입니까? 사전 정의 된 규칙이 있습니까?


문맥 좀 주 시겠어요? 순전히 기술적 인 관점이나 추적 사이트에서보고 될 버그에 대해 이야기하고 있습니까?
제레미

5
모든 버그는 숨겨진 기능입니다. :)
Marco Ceppi

2
숨겨진 것이 아니라 "언급되지 않은 기능"이라고 말하는 경향이 있습니다 :-)
Little Jawa

답변:


14

버그는 다음과 같습니다.

소프트웨어 버그는 컴퓨터 프로그램 또는 시스템의 오류, 결함, 실수, 실패 또는 결함을 설명하는 데 사용되는 일반적인 용어로, 잘못되거나 예기치 않은 결과가 발생하거나 의도하지 않은 방식으로 동작합니다. ( 위키 백과에서 )

다음 은 버그를 구성하는 것에 대한 또 다른 좋은 정의입니다. 어느 한 쪽:

  1. 이 프로그램은 프로그래머의 의도에 따라 작동하지 않았습니다. 또는
  2. 프로그래머의 의도는 일반적이고 합리적인 사용자 기대를 충족시키지 못했습니다.

우분투 커뮤니티는이 위키 에서 버그에 대한 훌륭한 정의를 가지고 있습니다. 특히 버그누락 된 기능 의 차이점을 강조합니다 .

소프트웨어 버그는 컴퓨터 프로그램의 오류 또는 오류로, 예상대로 작동하지 않습니다. 이것은 전혀 작동하지 않는 것처럼 간단 할 수도 있고, 미묘하게 잘못된 결과만큼 복잡 할 수도 있습니다. [...] 어떤 것은 버그는 아니지만 합리적으로 포함되어야하는 기능이 없습니다. 누락 된 기능은 버그로보고되어서는 안되며 대신 FeatureSpecifications를 작성해야합니다.

두 가지 정의를 구분하는 선을 그리는 것이 어렵지만 버그 또는 기능이 없다는 질문에 대답하십시오 . 다음과 같은 지침을 제공 할 수 있습니다.

  • 해결해야 할 세부 정보가 많은 문제라면 기능 일 가능성이 높습니다. 예를 들어, 최신 Windows 파티션에 파일을 안전하게 쓸 수 없다는 것은 누락 된 기능입니다.
  • ReiserFS 파티션에 파일을 안전하게 쓸 수없는 것은 버그입니다.

두 가지 주장의 차이점은 첫 번째가 더 널리 퍼져 있고 (현대 Windows FS 지원) ​​누락 된 기능으로 볼 수있는 반면 다른 하나는 고유 한 문제 (ReiserFS에 쓸 수 없음)-특정 버그를 강조하는 것입니다.

관심이 있으시면 BugSquad 팀 위키를 살펴 보는 것이 좋습니다 . 버그 퇴치는 훌륭한 학습 기회 일뿐 아니라 소프트웨어 개발주기와 관련된 가장 흥미로운 활동 중 하나입니다.

감사!


좋은 점은 직접 관련이 없지만 커밋하려는 모든 버그를 재현 할 수 있어야한다는 점을 언급 할 가치가 있습니다.
danizmax

아니요, 경쟁 조건으로 인해 버그가 있습니다. 왜 그렇게 커밋하고 싶지 않습니까? 프로그래머가 버그를 재현 할 수 없다면 어려울 것입니다. 그러나 그렇게하려는 의도에는 영향을 미치지 않습니까?
사용자가 알 수 없음

버그에 관한 Ubuntu BugSquad 안내서를 참조하십시오 : wiki.ubuntu.com/Bugs
Thomas Ward

2

나는 스윙을 할 것이다. 주로 디자이너 / 프로그래머가 의도하지 않은 동작 (잘못된 디자인 제외). 사람들에게 어떤 버그를보고해야하는지에 관해서는, 프로그램을 사용하고 위의 설명에 맞도록 만드는 모든 것. 여기에는 최악에서 가장 심각한 시스템 충돌, X 충돌, 프로그램 충돌 및 내부 프로그램 버그가 포함됩니다.

터미널에서 응용 프로그램을 실행하면 충돌이나 창 닫힘을 일으키는 버그로 인해 일반적으로 stderror가 발생합니다.이 기능은 유용 할 수 있습니다. 오류 보고서는 시스템 로그를 참조하십시오.


1

버그는 컴퓨터 프로그램 또는 시스템의 오류이므로 프로그램이 제대로 작동하지 않거나 전혀 작동하지 않습니다. 따라서 버그는 잘못된 프로그래밍 코드 또는 충분히 강력하지 않고 특정 예외를 처리 할 수없는 프로그래밍 코드 (예 : 0으로 나누기)의 결과 일 수 있습니다.


1

모든 실제적인 목적을 위해 "버그"라는 용어는 너무 희미한 용어로 사용하지 않아야합니다.

귀하의 질문에 대한 가장 좋은 답변 은 Andreas Zeller의 "프로그램이 실패한 이유" 전체를 채우는 것 입니다. 모든 프로그래머의 책장에 있어야하는 책. 저자는 또한 "버그"(읽기)라고 부르지 않기 위해 노력하고 있습니다. crncosta의 대답은 이미 "버그"를 건의하지 않기 때문에 단지 프로그래밍 오류입니다. 그렇기 때문에 어떤 사람들은 대신 "문제"라는 용어를 선호합니다 ( "버그 추적기"대신 "문제 추적기"로 이어짐).

최종 사용자가 버그로 인식 한 것은 전혀 버그 일 필요가 없기 때문입니다. 비록 이것이 디자인에 의해 절름발이 변명으로 자주 사용 되기는하지만 그것은 가능합니다. 그러나 한 번 관찰 된 일부 실패는 기능 부족으로 인해 "버그"로 분류됩니다.

앞서 언급 한 책의 저자는 실패결함 과 같은 용어의 정의 와 "버그"가 적절한 용어가 아닌 이유를 설명하는 데 여러 페이지를 사용합니다 (퍼지).

그의 용어 요약 :

  1. 프로그래머는 결함을 만듭니다
  2. 결함으로 인해 감염이 발생 함 ( "결함 프로그램 상태")
  3. 감염 전파
  4. 감염으로 인해 실패 ( "악의적 / 의도하지 않은 행동")
  5. 관찰자 (일반적으로 최종 사용자)가 실패를 본다

보시다시피 저자는 원인과 결과를 구분합니다. "버그"의 경우 거의 항상 혼합되어 있습니다. 대부분의 시간 기간 "버그"가 적용되는 결함감염 실패 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.