결함과 버그의 차이점은 무엇입니까?

• 버그는 코딩 오류의 결과입니다

• 결함은 요구 사항과의 편차입니다.

즉, 결함이 반드시 코드에 버그가 있음을 의미 하는 것은 아니며, 구현되지 않았지만 소프트웨어 요구 사항에 정의 된 기능 일 수 있습니다.

소프트웨어 테스트 의 Wikipedia 페이지에서 :

모든 소프트웨어 결함이 코딩 오류로 인한 것은 아닙니다. 값 비싼 결함의 일반적인 원인 중 하나는 요구 사항 격차, 예를 들어 인식 할 수없는 요구 사항으로 인해 프로그램 디자이너가 누락 오류를 발생시키는 것입니다. [14] 요구 사항 격차의 일반적인 원인은 테스트 가능성, 확장 성, 유지 관리 가능성, 유용성, 성능 및 보안과 같은 비 기능적 요구 사항입니다.

"소프트웨어 엔지니어링을위한 IEEE 표준 컬렉션"(1994) 및 "소프트웨어 엔지니어링 용어의 IEEE 표준 용어"(표준 610.12, 1990)에 정의 된 실용 소프트웨어 테스팅 (권장) 책에서 Ilene Burnstein 인용 :

오류

오류는 소프트웨어 개발자의 실수, 오해 또는 오해입니다.

개발자 범주에는 소프트웨어 엔지니어, 프로그래머, 분석가 및 테스터가 포함됩니다. 예를 들어, 개발자가 디자인 표기법을 오해하거나 프로그래머가 변수 이름을 잘못 입력 할 수 있습니다.

결함 (결함)

오류의 결과로 결함 (결함)이 소프트웨어에 도입됩니다. 소프트웨어의 사양에 따라가 아니라 잘못 동작 할 수있는 소프트웨어의 이상입니다.

결함 또는 결함을 "버그"라고도합니다. 후자의 용어를 사용하면 결함이 소프트웨어 품질에 미치는 영향을 사소한 것으로 간주합니다. "결함"이라는 용어는 요구 사항 및 디자인 문서와 같은 소프트웨어 아티팩트와도 관련이 있습니다. 이러한 아티팩트에서 발생하는 결함은 오류로 인해 발생하며 일반적으로 검토 프로세스에서 감지됩니다.

실패

실패는 소프트웨어 시스템 또는 구성 요소가 지정된 성능 요구 사항 내에서 필수 기능을 수행 할 수 없다는 것입니다.

소프트웨어 구성 요소 또는 시스템을 실행하는 동안 테스터, 개발자 또는 사용자는 소프트웨어 구성 요소 또는 시스템이 예상 결과를 생성하지 않는 것을 관찰합니다. 경우에 따라 특정 유형의 오작동은 특정 유형의 결함이 있음을 나타냅니다. 우리는 잘못된 행동의 유형이 결함의 증상이라고 말할 수 있습니다. 숙련 된 개발자 / 테스터는 메모리에 저장된 결함 / 증상 / 실패 사례 (3 장에 설명 된 결함 모델)에 대한 지식 기반을 갖게됩니다. 잘못된 동작에는 출력 변수에 대한 잘못된 값 생성, 장치 부분의 잘못된 응답 또는 화면의 잘못된 이미지가 포함될 수 있습니다. 개발 중에는 일반적으로 테스터가 실패를 발견하고 개발자가 결함을 찾아서 복구합니다.

여기 에서 Google 도서의 전체 장을 읽을 수 있습니다 .

소프트웨어 버그와 관련된 몇 가지 용어가 있습니다. 내가 취한 과정에서 발췌 :

• 오류 : 결함을 초래하는 인적 조치 또는 누락.

• 결함 : 결함은 실패를 일으키는 소프트웨어 결함 (잘못된 단계, 프로세스 또는 데이터 정의)입니다.

• 버그 : 결함과 동일합니다.

• 실패 : 소프트웨어가 지정된 성능 요구 사항 내에서 필요한 기능을 수행 할 수 없습니다.

이에 따르면 결함과 버그 사이에는 차이가 없습니다. 그러나 어떤 사람들은 버그가 소프트웨어를 출시하기 전에 발견되는 오류이고, 결함은 고객이 발견 한 오류라고 주장합니다.

유명한 "첫 번째 실제 버그 발견"을 게시하는 것을 거부 할 수 없었습니다.

이런.

옛날에는 컴퓨터의 결함있는 작동이 배선을 씹는 쥐와 실제 벌레 (작은 동물)가 작업에 들어가는 등 모든 종류의 일로 인해 발생했습니다.

BUG라는 용어는 예상대로 작동하지 않는 것을 의미하는 용어로 붙어 있습니다.

버그는 결함을 의미하는 전문 용어로 생각해야합니다.

결함은 기술적으로 올바른 용어로 사물이 의도하지 않은 것을 의미합니다.

가능하면 BUG 대신 DEFECT를 사용하면 실제로는 사소한 소리 "버그"로 차용하는 대신 실패 (사용자의 결함, 사용자 요구 사항에 대한 이해 부족 또는 구현에서 간과 한 것)를 인정한다는 의미가 담겨 있습니다. ".

DEFECT를 사용하십시오.

BUG라는 용어를 사용하지 마십시오. 어리 석고, 관련이없고, 역사적이며, 사소한 것입니다.

소프트웨어 테스팅 및 소프트웨어 품질에 대한 지식 KA의 소프트웨어 엔지니어링 바디에 인용 된 소프트웨어 엔지니어링 용어의 IEEE 표준 용어 :

곤충. 참조 : error; 결점.

오류. (1) 계산, 관찰 또는 측정 된 값 또는 조건과 실제, 지정된 또는 이론적으로 정확한 값 또는 조건의 차이. 예를 들어, 계산 결과와 올바른 결과 사이의 30 미터 차이. (2) 잘못된 단계, 프로세스 또는 데이터 정의. 예를 들어, 컴퓨터 프로그램에 잘못된 명령이 있습니다. (3) 잘못된 결과. 예를 들어, 올바른 결과가 10 일 때 계산 결과는 12입니다. (4) 잘못된 결과를 생성하는 휴먼 조치. 예를 들어, 프로그래머 나 운영자의 잘못된 행동. 참고 : 네 가지 정의가 모두 일반적으로 사용되지만 한 가지 구별은 정의 1을 "오류", 정의 2를 "고장", 정의 3을 "실패", 정의 4를 "실수"라고 지정합니다. a2so : 동적 오류를 참조하십시오. 치명적 오류; 원주민 오류; 시맨틱 에러; 구문 오류; 정적 오류; 일시적인 오류.

실패. 시스템 또는 구성 요소가 지정된 성능 요구 사항 내에서 필수 기능을 수행 할 수 없습니다. 참고 : 내결함성 규율은 휴먼 조치 (실수), 표시 (하드웨어 또는 소프트웨어 결함), 결함 결과 (실패) 및 결과의 부정확 한 정도 (오류)를 구분합니다. 참조 : crash; 의존적 실패; 예외; 고장 모드; 실패율; 어려운 실패; 초기 장애; 독립 실패; 무작위 실패; 소프트 고장; 고착 실패.

결점. (1) 하드웨어 장치 또는 구성 요소의 결함; 예를 들어 단락 또는 단선. (2) 컴퓨터 프로그램에서 잘못된 단계, 프로세스 또는 데이터 정의. 참고 :이 정의는 주로 내결함성 원칙에 의해 사용됩니다. 일반적으로 "오류"및 "버그"라는 용어는이 의미를 나타내는 데 사용됩니다. 참조 : 데이터에 민감한 결함; 프로그램 민감한 결함; 동등한 결함; 결함 마스킹; 간헐적 결함.

실패의 정의가 가장 관련성이 있다고 생각합니다. 요구 사항, 디자인, 구현 또는 테스트 사례 / 절차에 관계없이 모든 것이 실수로 시작됩니다. 이 실수가 소프트웨어에 나타나면 오류가됩니다. 소프트웨어에 하나 이상의 결함이 있기 때문에 실패가 발생합니다.

그래도 공식적인 오류 정의에 관심이 없습니다. dukeofgaming이 그의 답변에서 제공 한 정의를 매우 선호 하지만이 답변의 하나는 IEEE 표준 오류 정의입니다.

댄 맥그래스 (Dan McGrath)의 대답 은 그것을 올바르게 이해했다.

• 버그는 코딩 오류의 결과입니다
• 결함은 요구 사항과의 편차입니다.

어쩌면 예가 더 명확해질 것입니다.

예 : 클라이언트는 웹 양식이 창을 저장하고 닫을 수 있기를 원했습니다.

시나리오 # 1 : 웹 양식에는 저장 버튼과 다른 닫기 버튼이 있습니다. 결과 : 클라이언트가 1 버튼을 저장하고 창을 닫으려고했기 때문에 결함이 있습니다. 개발자가 잘못 이해하고 별도로 만들었습니다. 두 버튼 모두 요구 사항을 수행했기 때문에 버그가 아니라 클라이언트 요구 사항을 충족하지 못하기 때문에 결함이 아닙니다.

시나리오 # 2 : 웹 양식에는 저장 및 닫기 단추가 있지만 저장 만하고 닫지는 않습니다. 결과 : 버그. 버튼이 필요 / 예상대로 작동하지 않기 때문입니다. 개발자는 그 결과를 만들어 내야하지만 궁극적으로는 그렇지 않다는 것을 알고 있습니다. (아마 코딩 오류)

이것이 더 분명한지 확실하지 않습니다.

p / s : 개발자 관점에서 (나는 한 번이었다), 결함과 버그 모두 중요합니다. 우리는 여전히 그것을 고칠 것입니다.

우리는 이상한 예외가 발생하여 버그로 분류했으며 원인과 해결 방법을 지속적으로 파악하려고 노력합니다. 버그를 종료한다고해서 결함에 비해 사소한 것은 아닙니다.

차이점은 "버그"라는 용어가 마법처럼 들린다는 것입니다. 마치 프로그래밍을 마치면 프로그램에 무작위로 버그가 생길 수 있습니다. 임의의 버그가있는 경우 사양을 준수하지 않아 프로그램에 오류가있는 것입니다.

결함은 프로그램이 사양을 준수하지 않는 오류를 의미합니다. 이것은 더 심각하며 기본적으로 모든 오류는 프로그램에 큰 문제이며 프로그램이 릴리스하기에 적합하지 않다는 것을 의미합니다.

차이점은 용어를 사용하는 프로그래머의 태도에 있습니다. 버그로 릴리스 된 수백만 개의 프로그램이 있으며 사람들은 어떤 이유로 버그가 마법적이고 무작위 적이며 모든 프로그램에 하나 이상의 버그가 포함되어 있기 때문에 괜찮습니다. 그러나 "결함"이라는 용어를 사용하는 프로그래머는 용어의 심각도가 더 높기 때문에 결함이있는 프로그램을 릴리스하는 데 불편할 수 있습니다.

한 용어를 다른 용어보다 선호한다는 것은 매일 우리에게 영향을 미칩니다.

신뢰성 에 따르면 : 기본 개념 및 용어 :

전달 된 서비스가 시스템 기능을 수행 할 수없는 경우 시스템 장애가 발생합니다. 후자는 시스템의 용도입니다. 오류는 후속하는 오류가 발생할 우려가 시스템 상태의 일부이다 : 서비스에 영향을주는 에러가 발생하거나 장애가 발생했다는 표시이다. 판단되거나 가정 된 오류의 원인은 결함 입니다.

나는 결함 을 다른 결함의 이름으로 이해 합니다.

버그 는 혼란스럽고 상황에 따라 오류 또는 실패를 나타낼 수 있습니다.

사양에 대한 언급은 없습니다. 사양조차도 결함이있을 수 있습니다.

다음은 ISTQB 어휘를 기반으로 한 고용주 Q-LEAP에 대해 이전에 한 일이며 IEEE 어휘도 확인했습니다. 즐겨.

버그와 결함? 이것에 대해 끝없는 토론을 할 수는 있지만 마찬가지입니다. 우리는 정말로 걱정해야 할 다른 것들이 있습니다. 인생은 이미 충분히 복잡합니다.

"Google의 소프트웨어 테스트 방법" 에서이 용어가 어떻게 사용되는지에 대한 예 p. 113. "IEEE Software"기사를 열고 같은 방식으로 사용합니다. 실제로, 실생활에서 "결함"이라는 단어는 거의 만나지 않습니다.

버그의 삶

버그 및 버그 보고서는 모든 테스터가 이해하는 유물입니다. 버그 찾기, 버그 분류, 버그 수정 및 회귀 버그는 소프트웨어 품질의 핵심 요소입니다. 이것은 Google에서 가장 일반적인 테스트의 일부이지만 여전히 표준에서 몇 가지 흥미로운 편차가 있습니다. 이 섹션에서는 작업 항목을 추적하고이 용어를 사용하여 실제 손상된 코드를 식별하기 위해 제출 된 버그를 무시합니다. 따라서 버그는 종종 엔지니어링 팀의 시간별 및 일상적인 워크 플로를 나타냅니다.

버그가 생겼습니다. 버그는 Google의 모든 사람이 찾아서 제출합니다. 제품 관리자는 초기 빌드에서 사양 / 생각과 다른 문제를 발견 할 때 버그를 제기합니다. 개발자는 실수로 문제를 체크인했거나 코드베이스의 다른 곳에서 또는 Google 제품을 개밥하는 동안 문제를 발견 한 경우 버그를 신고합니다. 또한 버그는 크라우드 소싱 테스터, 외부 공급 업체 테스트에서 제공되며 커뮤니티 관리자가 제품 별 Google 그룹스를 모니터링하여 제출합니다. 많은 내부 버전의 앱에는 Google지도와 같이 한 번의 클릭으로 버그를 신고하는 방법도 있습니다. 때로는 소프트웨어 프로그램이 API를 통해 버그를 생성하기도합니다.

특정 버그 / 태스크 / 티켓 / 결함 / 문제 / 추적 시스템 인스턴스 이외의이 단어는 정확한 의미를 갖지 않으므로 이들 단어의 차이점에 대해 논의하는 것은 의미가 없습니다. 워크 플로우를 정할 때 용어를 정하고 설명을 제공해야합니다.

내 현재 환경에서 "결함"은 Jira의 모든 항목입니다. Jira 자체가 "문제"라는 용어를 사용하는 것 같습니다. 우리는 이전 시스템에서 상속했을 수도 있습니다. "버그"는 문서에 설명 된대로 예상대로 작동하지 않는 문제의 한 유형입니다. 예상대로 작동하지만 개선이 필요한 경우 "기능 요청"(명확하고 중요 할 수 있지만 현재 동작이 설명 된 경우 여전히 기능 요청)입니다. 더 많은 유형이 있지만 그 2는 개발 팀 외부의 사람들이 무언가를 요구하는 데 사용됩니다.

이슈 유형에 대한 이름을 선택하는 경우 "bug"및 "defect"가 나와 비슷합니다. 그들 사이의 차이점은 문체입니다. 영어는 모국어가 아니기 때문에 실제로 많은 것을 볼 수 없으며 내가 보는 것이 올바른지 확실하지 않습니다.