실제 소프트웨어 테스트 (권장)”IEEE 표준 정의 Collection for Software Engineering “(1994) 및”IEEE Standard Glossary of Software Engineering Terminology “(표준 610.12, 1990) :

오류

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

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

결함 (결함)

오류의 결과로 소프트웨어에 결함 (결함)이 도입되었습니다. 소프트웨어의 이상으로 인해 사양에 따라 잘못 작동 할 수 있습니다.

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

실패

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

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

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

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

• 오류 : 사람의 행동 또는 누락 오류가 발생합니다.

• 오류 : 오류는 소프트웨어입니다. 결함 (잘못된 단계, 프로세스 또는 데이터 정의)로 인해 실패합니다.

• 버그 : 오류와 동일합니다.

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

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

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

댓글

• 마지막으로 읽음 : testingstandards.co.uk/bs_7925-1_online.htm
• 그 ‘ 내가 얻은 곳은 아니지만 공통 소스를 가지고있을 수 있습니다 (또는이 소스가 소스 일 수 있습니다).
• 예, 수년 전에 버그를 수정하는 데 시간을 보냈습니다. 화면의 한 셀에 성가신 깜박임이 있었는데 말이되지 않았습니다. 드디어 날아갔습니다. (검은 화면에 흰색 텍스트가있는 시대 였지만 문제의 지점은 항상 검은 색이 될만큼 오른쪽으로 멀었습니다. 편집 중이 어서 프로그램이 약간의 흰색을 표시했을 때만 알아 차 렸습니다.)

이런.

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

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

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

결함은 기술적으로 올바른 용어 의미입니다. 가능한 한 BUG 대신 DEFECT를 사용하는 것은 실제로 우리의 실패 (결함, 사용자 요구 사항에 대한 이해 부족 또는 우리는 구현에서 간과) 더 사소한 소리의 “버그”로 꾸미는 대신.

DEFECT를 사용하십시오.

BUG라는 용어를 사용하지 마십시오. 우스꽝스럽고 무관하며 역사적이며 상식적입니다.

댓글

• 잘 이해 된 전문 용어를 사용하지 않으려는 이유는 무엇입니까? 저는 ‘ 미안합니다 … 예, BUG는 역사적입니다.하지만 프로그래머가 버그 (일반적으로 특정이 아닌)를 사소한 것으로 간주한다고 생각한다면 ‘ 버그 또는 그 기원 때문에 관련없는 용어라고 불리며 ‘ 내가 심술 궂은 중년으로 변하는 것이 전적으로 정당화 될까 두렵습니다. 오, @Dan이 지적했듯이 버그는 결함이지만 결함이 반드시 버그는 아닙니다. ‘이 용어가 가치가 있음을 의미합니다.
• @Murph, a ” 버그 “는 프로그래밍 오류에 대한 완곡 어법입니다. 무의식적으로 이것은 개발자가 제어 할 수없는 일종의 그렘린을 유혹합니다. 이것은 정확하지 않습니다. 오류이며 이것이 더 전문적인 행동을 향한 단계임을 인정하는 것입니다. (물론 Imho :-))
• 음, 분명히 동의하지 않습니다. (-: 코드에있는 버그 (코딩 및 논리 오류)의 원인을 정확히 알고 있습니다. (I ‘ 또한 다른 사람들의 코드에서 오류를 식별 할 수 있습니다 ‘.) 제가 아는 모든 프로그래머는이 용어가 의미하는 바에 대해 분명히 알고 있습니다. 일부 프로그래머) 그렘린이 실수를 한 것은 아닙니다.
• 고객을 다룰 때 이러한 것을 버그 또는 결함이라고 부를 수 있습니다. 버그는 전문 용어입니다. 결함은 전문 용어를 벗어난 인정입니다. ” 결함 “은 프로그램 형제회 외부에서도 명확한 의사 소통을 장려하는 용어입니다. 내부로.(나는 또한 버그와 결함 사이에 차이가 있다는 것에 동의하지 않습니다.)
• 결함은 적절한 용어입니다. 버그가있는 프로그램이 몇 개나 출시 되었는가? 그러나 결함이있는 프로그램이 얼마나 많이 출시됩니까? 우리는 ‘이 용어가 더 큰 심각도를 의미하고 그것이 ‘ 오류에 대한 우리의 잘못이라는 것을 알고 있기 때문에 받아들이지 않을 것입니다. 날씨 나 시간을 비난 할 수있는 버그보다.

IEEE 표준에서 소프트웨어 테스트 및 소프트웨어 품질에 대한 지식 KA의 소프트웨어 엔지니어링 기관에 인용 된 소프트웨어 엔지니어링 용어의 용어집 :

버그. 참조 : 오류; 오류.

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

실패. 시스템 또는 구성 요소가 지정된 성능 요구 사항 내에서 필요한 기능을 수행 할 수 없음. 참고 : 내결함성 규율은 사람의 행동 (실수), 그 징후 (하드웨어 또는 소프트웨어 결함), 결함의 결과 (실패) 및 결과가 잘못된 정도 (오류)를 구별합니다. 참조 : crash; 의존적 실패; 예외; 실패 모드; 실패율; 심한 실패; 초기 실패; 독립적 인 실패; 무작위 실패; 부드러운 실패; 멈춤 실패.

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

실패의 정의가 가장 적절하다고 생각합니다. 요구 사항, 설계, 구현 또는 테스트 케이스 / 절차 등 모든 것이 실수로 시작됩니다. 이러한 실수가 소프트웨어에 나타나면 오류가됩니다. 실패는 오류가 발생합니다. 소프트웨어에 더 많은 결함이 있습니다.

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

Dan McGrath의 답변 이 정답입니다.

• 버그는 코딩 오류의 결과입니다.
• 결함은 요구 사항에서 벗어난 것입니다.

예를 들어 더 명확하게 할 수 있습니다.

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

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

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

이것이 더 명확하게 만드는지 확실하지 않습니다.

p / s : 개발자로부터 (저는 한때) 결함과 버그가 모두 중요합니다. 우리는 여전히 그것을 고칠 것입니다.

우리는 심지어 이상한 이상 현상을 발견했습니다. 우리는 버그로 분류하고 지속적으로 무엇을 알아 내려고 노력합니다. 원인과 해결 방법입니다. 버그를 종료하는 것은 “결함과 비교할 때 사소한 것이 아닙니다.

댓글

• 불완전한 요구 사항을 무엇이라고합니까?
• @ gnasher729 잘못된 요구 사항으로 인해 프로그래머가 요구 사항을 오해했음을 의미했다면 ‘ 결함이라고 생각합니다. 그러나 사용자가 잘못된 요구 사항을 제공하여 최종 작업이 초기 문제를 해결하지 못하여 잘못된 요구 사항을 의미했다면 이는 개발이 아닌 요구 사항 수집 세션의 문제이므로 버그와 결함을 넘어서는 것입니다.

다음은 ISTQB 어휘를 기반으로 고용주 Q-LEAP을 위해 이전에 수행 한 작업입니다. IEEE 어휘. 즐겨.

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

용어가 야생에서 사용되는 방법, “Google이 소프트웨어를 테스트하는 방법” p. 113. “IEEE Software”기사를 열면 같은 방식으로 사용됩니다. 실제로 “결함”이라는 단어는 실생활에서 거의 접하지 않습니다.

버그의 수명

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

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

다른 점은 “버그”라는 용어가 마법처럼 들린다는 것입니다. 마치 프로그램이 “프로그래밍을 마친 후 임의의 버그를 가질 수있는 것처럼. 임의의 버그가 있으면”사양을 준수하지 않았으며 프로그램에 오류가 있음을 의미합니다.

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

차이점은 용어를 사용하는 프로그래머의 태도에 있습니다. 버그와 함께 릴리스되는 프로그램은 수백만 개가 있으며, 사람들은 어떤 이유로 든 받아 들일 수 있습니다. 버그는 마술적이고 무작위 적이며 모든 프로그램에 적어도 하나의 버그가 포함되어 있습니다. 그러나 “결함”이라는 용어를 사용하는 프로그래머는이 용어가 더 큰 심각도를 의미하기 때문에 결함이있는 프로그램을 출시하는 데 불편할 수 있습니다.

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

특정 버그 / 작업 / 티켓 / 결함 / 문제 / 어떤 추적 시스템 인스턴스를 제외하고이 단어는 정확한 의미가 없으므로 그 차이를 논의하는 것은 무의미합니다. 워크 플로를 정할 때 용어를 정하고 설명을 제공해야합니다.

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

문제 유형의 이름을 고르는 경우 “버그”와 “결함”이 저와 비슷하게 들립니다. 그들 사이의 차이점은 문체입니다. 영어가 제 모국어가 아니기 때문에 많은 부분을 볼 수없고 제가 보는 내용이 정확한지 확신 할 수 없습니다.