소프트웨어 버그

Software bug
위키백과에서 MediaWiki 오류를 보고하려면 위키백과를 참조하십시오.버그 리포트.
다음에 대한 시리즈 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
연습
도구들
지식의 표준 및 본문
용어집
윤곽선
다음에 대한 시리즈 일부
정보 보안
vectorial version
관련 보안 카테고리
위협
방어

소프트웨어 버그는 컴퓨터 소프트웨어의 오류, 결함 또는 결함으로 인해 부정확하거나 예상치 못한 결과가 발생하거나 의도하지 않은 방식으로 동작하게 된다.버그를 찾아 교정하는 과정을 '디버깅'이라고 하며, 종종 공식적인 기술이나 도구를 사용하여 버그를 정확히 찾아낸다.1950년대 이후 일부 컴퓨터 시스템은 작동 중 다양한 컴퓨터 버그를 방지, 감지 또는 자동 수정하도록 설계되었다.

대부분의 버그는 프로그램의 설계나 소스 코드 또는 그러한 프로그램에 의해 사용되는 구성 요소와 운영 체제에서 발생한 오류와 실수에서 발생한다.버그가 많거나 심각한 프로그램이 버그라고 한다.버그는 파급 효과가 있을 수 있는 오류를 유발할 수 있다.버그는 미묘한 영향을 미칠 수도 있고, 프로그램을 중단시키거나 컴퓨터를 정지시킬 수도 있다.예를 들어, 다른 버그는 보안 버그로 적합하며, 악의적인 사용자가 무단 권한을 얻기 위해 액세스 제어를 우회할 수 있게 할 수 있다.[1]

몇몇 소프트웨어 버그는 재난과 연관되어 있다.1980년대 환자 사망의 직접적인 원인은 테라크-25 방사선 치료기를 조종했던 암호의 벌레가 있었다.1996년 유럽우주국(ESA)의 10억 달러짜리 시제품 아리안 5호 로켓이 온보드 유도 컴퓨터 프로그램의 버그로 발사 1분도 안 돼 파괴됐다.[2]1994년에 RAF 치누크 헬리콥터가 추락하여 29명이 사망했는데, 처음에는 조종사의 실수로 비난을 받았지만, 나중에 엔진 제어 컴퓨터의 소프트웨어 버그에 의해 발생한 것으로 생각되었다.[3]버기 소프트웨어는 21세기 초 영국 우체국 스캔들을 일으켰는데, 이는 영국 법률 역사상 가장 광범위한 오심이다.[4]

2002년 미국 상무부 국립표준기술원이 의뢰한 한 연구에서는 "소프트웨어 버그, 즉 오류가 너무 만연하고 해로워서 미국 경제에 연간 약 590억 달러(국내 총생산의 약 0.6%)의 손실이 발생한다"고 결론지었다.[5]

역사

주요 기사:버그(엔지니어링)

중세 영어 단어 bugge는 괴물에 사용되는 용어로 bugbear와 bugaboo의 기본이다.[6]

결함을 기술하는 "버그"라는 용어는[7] 1870년대부터 공학 용어의 일부였고 전자제품과 컴퓨터보다 앞서 있다; 그것은 원래 기계적 오작동을 기술하기 위해 하드웨어 공학에서 사용되었을 수 있다.예를 들어, 토마스 에디슨은 1878년에 한 동료에게 보낸 편지에 다음과 같이 썼다.[8]

... 곤란이 발생한다—이것은 포기한다. 그리고 [그것은] 그렇게 작은 결함과 어려움들이 불리기 때문에—자신을[9] 보여주는 것이다.

최초의 기계식 핀볼 게임인 배플 볼은 1931년에 "벌레가 없다"고 광고되었다.[10]제2차 세계 대전 중 군사 장비에 관한 문제를 벌레(또는 결함)라고 불렀다.[11]루이스 디킨슨 리치는 1942년에 출판된 책에서 동력식 얼음절단기에 대해 "얼음 톱질은 창조자가 그의 달링에서 벌레들을 꺼내기 위해 데려올 수 있을 때까지 중단되었다"고 말했다.[12]

아이작 아시모프는 1944년 출간된 단편 '캐치 댓 래빗'에서 로봇과의 문제를 언급하기 위해 '버그'라는 용어를 사용했다.

하버드 Mark II 전자기계 컴퓨터 로그의 페이지, 장치에서 제거된 죽은 나방이 있다.

컴퓨터 선구자인 그레이스 호퍼가 초기 전기기계 컴퓨터의 오작동 원인을 밝힌 계정에서 '버그'라는 용어를 사용했다.[13]그 이야기의 전형적인 버전은 다음과 같다.

1946년 호퍼가 현역에서 풀려나자 그녀는 계산연구소의 하버드 교수진에 입사하여 마크 2세와 마크 3세에 대한 연구를 계속했다.운영자들은 Mark II의 오류를 추적하여 계전기 안에 갇힌 나방과 버그라는 용어를 연결했다.이 벌레는 조심스럽게 제거되어 통나무에 테이프로 붙여 놓았다.첫 번째 버그에서 기인하여 오늘날 우리는 프로그램의 오류나 결함을 버그라고 부른다.[14]

호퍼는 벌레가 발견되었을 때 참석하지 않았지만 그녀가 가장 좋아하는 이야기 중 하나가 되었다.[15]로그북에 있는 날짜는 1947년 9월 9일이었다.[16][17][18]그것을 발견한 운영자들, 윌리엄 '빌' 버크 등, 나중에 버지니아주 달그렌 해군 무기 연구소의 공학적 용어에 익숙했고,[19] "첫 번째 실제 버그가 발견된 경우"라는 표기법으로 즐겁게 곤충을 유지했다.첨부된 나방과 함께 완성된 이 통나무책은 스미스소니언 국립 미국사박물관 소장품의 일부다.[17]

관련 용어 "디버그"는 또한 컴퓨팅에서 그것의 사용을 앞지르는 것으로 보인다: 옥스포드 영어 사전의 단어 어원은 항공기 엔진의 맥락에서 1945년 이후의 증명서를 포함하고 있다.[20]

소프트웨어에 오류가 있을 수 있다는 개념은 분석 엔진에 대한 에이다 러브레이스의 1843년 노트에서 찰스 배비지의 분석 엔진에 대한 프로그램 "카드"의 오류 가능성을 언급했던 것으로 거슬러 올라간다.

... 분석 엔진에 필요한 작동 데이터를 제공하기 위해 분석 프로세스가 동등하게 수행되어야 하며, 여기에 오류의 가능한 원인이 있을 수도 있다.실제 메커니즘이 그 과정에서 모호하지 않다는 것을 인정한다면, 카드는 잘못된 명령을 내릴 수도 있다.

"시스템 내 버그" 보고서

그룹 뉴아메리카가 운영하는 오픈 테크놀로지 인스티튜트는 2016년 8월 미국 정책 입안자들이 소프트웨어 버그를 식별하고 해결할 수 있도록 개혁해야 한다는 내용의 보고서 '버그 인 더 시스템(Bugs in the System)'을 발표했다.[21]보고서는 "소프트웨어 취약점 발견 및 공개 분야의 개혁의 필요성을 강조한다"[22]고 밝혔다.이 보고서의 저자들 중 한 명은 의회가 더 큰 사이버 보안 문제를 해결하기 위한 많은 법안들을 통과시켰음에도 불구하고, 의회가 사이버 소프트웨어 취약점을 다루기 위한 충분한 조치를 취하지 않았다고 말했다.[22]

정부 연구자, 기업, 사이버 보안 전문가들은 전형적으로 소프트웨어 결함을 발견하는 사람들이다.이 보고서는 컴퓨터 범죄와 저작권법을 개혁할 것을 요구하고 있다.[22]

컴퓨터 사기 및 남용법, 디지털 밀레니엄 저작권법, 전자통신 프라이버시법은 보안 연구원이 합법적인 보안 연구를 수행하면서 일상적으로 행하는 행위에 대해 형사처벌하고 민사처벌법을 만든다고 보고서는 밝혔다.[22]

용어.

소프트웨어 오류를 기술하기 위해 '버그'라는 용어를 사용하는 것이 일반적이지만, 많은 사람들이 이를 버려야 한다고 제안했다.한 가지 주장은 '버그'라는 말이 인간이 문제를 일으켰다는 의미에서 이혼한 것이고, 그 대신 결함이 스스로 발생했다는 것을 내포하고 있어 '불량'[23]과 같은 용어에 유리한 '버그'라는 용어를 제한된 성공으로 버리게 된다는 것이다.1970년대 이후 게리 킬달은 다소 유머러스하게 "blunder"[24][25]라는 용어를 사용하자고 제안했다.

소프트웨어 공학에서, 실수 변성(그리스 메타 = "변화", 형태 = "형태")은 소프트웨어 배치의 최종 단계에서 결함의 진화를 말한다.소프트웨어 개발 라이프사이클의 초기 단계에서 애널리스트에 의해 저질러지는 「실수」의 변형은, 사이클의 최종 단계에서 「실수 변성」이라고 한다.[26]

전체 사이클에서 "실수"의 다른 단계는 "실수", "아노멀리", "실수", "실수", "실수", "오류", "오류", "오류", "파손", "고장", "불량", "사건" 또는 "부작용"[26]으로 설명될 수 있다.

예방

프랑스 La Croix de Berny 스테이션의 두 화면에 표시되는 소프트웨어 버그로 인한 오류.

소프트웨어 업계는 버그 수를 줄이는데 많은 노력을 기울였다.[27][28]여기에는 다음이 포함된다.

인쇄상의 오류

보통 프로그래머가 논리 오류를 범할 때 버그가 나타난다.프로그래밍 스타일과 방어 프로그래밍의 다양한 혁신은 이러한 버그를 덜 발생시키거나 발견하기 쉽도록 설계된다.특히 기호나 논리/수학적 연산자의 일부 오자는 프로그램이 잘못 작동하도록 허용하는 반면, 누락된 기호나 철자가 틀린 이름과 같은 오자는 프로그램 작동을 방해할 수 있다.컴파일된 언어는 소스 코드를 컴파일할 때 일부 오타를 나타낼 수 있다.

개발방법론

몇 가지 계획은 버그가 더 적게 생성되도록 프로그래머 활동을 관리하는 데 도움이 된다.소프트웨어 엔지니어링(소프트웨어 설계 문제도 해결)은 결함을 방지하기 위해 많은 기법을 적용한다.예를 들어, 공식적인 프로그램 사양에는 설계 버그가 제거될 수 있도록 프로그램의 정확한 동작이 명시되어 있다.불행히도, 공식 규격은 조합 폭발과 불변성의 문제 때문에 최단 프로그램 이외의 어떤 것에도 비현실적이다.

단위 시험에는 프로그램이 수행하는 모든 기능(단위)에 대한 시험을 작성하는 것이 포함된다.

시험 구동 개발 단위 시험은 코드 전에 작성되며 모든 시험이 성공적으로 완료될 때까지 코드는 완료된 것으로 간주되지 않는다.

신속한 변화를 위한 소프트웨어 개발은 비교적 작은 변경사항으로 빈번한 소프트웨어 릴리즈를 포함한다.결함은 사용자 피드백에 의해 드러난다.

오픈 소스 개발은 누구나 소스 코드를 검사할 수 있게 한다.에릭 S에 의해 대중화된 사상의 학교. 레이몬드의 법칙에 따르면, 인기 있는 오픈소스 소프트웨어는 다른 소프트웨어보다 버그가 거의 없거나 없을 가능성이 더 높다고 한다. 왜냐하면 "충분한 안구를 주어 모든 버그는 얕기 때문이다."[29]그러나 컴퓨터 보안 전문가 엘리아스 레비는 "복잡하고, 거의 이해되지 않으며, 문서화되지 않은 소스 코드의 취약성을 감추기 쉽다"고 썼다. "사람들이 코드를 검토하고 있다고 해서, 그들이 그렇게 할 자격이 있다는 것을 의미하지는 않는다.[30]오픈소스 소프트웨어 버그의 한 예로 드비안의 2008년 OpenSSL 취약성이 있다.

프로그래밍 언어 지원

프로그래밍 언어에는 정적 유형 시스템, 제한된 네임스페이스 및 모듈 프로그래밍과 같은 버그를 방지하는 데 도움이 되는 기능이 포함되어 있다.예를 들어, 프로그래머가 글을 쓸 때(pseudocode)LET REAL_VALUE PI = "THREE AND A BIT", 비록 이것이 구문론적으로 정확할 수 있지만, 코드는 형식 검사에 실패한다.컴파일된 언어는 프로그램을 실행할 필요 없이 이것을 포착한다.해석된 언어는 런타임에 이러한 오류를 포착한다.일부 언어에서는 성능 저하를 감수하고 버그를 발생시키기 쉬운 특징을 의도적으로 배제한다. 일반적으로, 특히 유지관리 비용이 상당하다는 점을 고려할 때, 약간 더 빠르게 실행되는 불가해한 코드보다 더 간단하고 느린 코드를 쓰는 것이 거의 항상 더 낫다.예를 들어, Java 프로그래밍 언어는 포인터 산술을 지원하지 않는다; Pascal과 스크립팅 언어와 같은 일부 언어의 구현은 적어도 디버깅 빌드에서 어레이의 런타임 경계 검사를 하는 경우가 많다.

코드분석

코드 분석을 위한 도구는 컴파일러의 능력 밖의 프로그램 텍스트를 검사하여 잠재적인 문제를 찾아냄으로써 개발자들에게 도움을 준다.일반적으로 규격에 주어진 모든 프로그래밍 오류를 찾아내는 문제는 해결할 수 없지만(정지 문제 참조), 이러한 도구는 인간 프로그래머들이 소프트웨어를 작성할 때 종종 특정한 종류의 단순한 실수를 저지르는 경향이 있다는 사실을 이용한다.

계측

병목 현상과 같은 문제를 찾거나 정확한 작업에 대한 보장을 위해 실행 중인 소프트웨어의 성능을 모니터링하는 도구가 코드에 명시적으로 포함되어 있을 수 있다(아마도 설명처럼 간단하다).PRINT "I AM HERE"() 또는 도구로 제공된다.대부분의 시간을 코드 조각에 의해 빼앗긴 곳을 찾는 것은 종종 놀라운 일이며, 이러한 가정들의 제거는 코드를 다시 쓰는 원인이 될 수 있다.

테스트

소프트웨어 테스터는 버그를 찾거나 테스트를 지원하는 코드를 쓰는 것이 주된 임무인 사람이다.일부 프로젝트에서는 프로그램 개발보다 테스트에 더 많은 리소스가 사용될 수 있다.

테스트 중 측정은 남아 있을 가능성이 있는 버그 수의 추정치를 제공할 수 있다. 이는 제품이 테스트 및 개발되는 시간이 길수록 신뢰성이 높아진다.[citation needed]

디버깅

일반적인 버그 기록(GNU Classpath 프로젝트 데이터).사용자가 제출한 새로운 버그는 확인되지 않았다.일단 개발업자에 의해 재생산되면 확인된 버그다.확인된 버그는 나중에 고쳐진다.다른 범주에 속하는 버그(재생산되지 않음, 고정되지 않음 등)는 대개 소수에 속한다.
주요 기사:디버깅

버그를 찾아 고치는 것, 즉 디버깅은 컴퓨터 프로그래밍의 주요 부분이다.초기 컴퓨터 분야의 선구자인 Maurice Wilkes는 1940년대 후반에 그가 깨달은 것을 설명했는데, 그의 여생 중 많은 부분이 자신의 프로그램에서 실수를 찾는데 쓰일 것이라고 했다.[31]

보통 디버깅에서 가장 어려운 부분은 버그를 찾는 것이다.일단 발견되면, 보통 그것을 고치는 것은 비교적 쉽다.디버거라고 알려진 프로그램은 프로그래머들이 프로그램 동작을 관찰하기 위해 라인별로 코드를 실행하고, 변수 값을 관찰하며, 다른 기능들을 관찰함으로써 버그를 찾는 것을 돕는다.디버거가 없으면 메시지나 값을 콘솔이나 창이나 로그 파일에 기록하여 프로그램 실행을 추적하거나 값을 표시하도록 코드를 추가할 수 있다.

하지만 디버거의 도움을 받아도 버그를 찾는 것은 일종의 예술이다.프로그램의 한 섹션에 있는 버그가 완전히 다른 섹션의 장애를 [citation needed]유발하여 시스템의 명백하게 관련이 없는 부분에서 특히 추적하기 어려운 경우(예: 그래픽 렌더링 루틴의 오류로 인해 파일 I/O 루틴이 실패함)는 드문 일이 아니다.

때때로 버그는 고립된 결함이 아니라 프로그래머의 입장에서 생각하거나 계획하는 오류를 나타낸다.이러한 논리 오류는 프로그램의 한 부분을 재검토하거나 다시 작성해야 한다.코드 검토의 일부로서, 코드를 밟고 실행 과정을 상상하거나 변환하는 것은 버그를 그렇게 재현하지 않고 종종 오류를 발견할 수 있다.

더 전형적으로 버그를 찾는 첫 번째 단계는 버그를 안정적으로 재생산하는 것이다.일단 버그가 재현되면 프로그래머는 프로그램이 빗나간 지점을 찾기 위해 오류를 재현하는 동안 디버거나 다른 도구를 사용할 수 있다.

일부 버그는 프로그래머가 재창조하기 어려울 수 있는 입력에 의해 드러난다.테라크-25 방사선 기계 사망의 한 원인은 기계 운영자가 치료 계획에 매우 빠르게 진입했을 때에만 발생한 버그(특히 경주 조건)로, 이것을 할 수 있는 데 며칠의 연습이 필요했기 때문에 버그는 시험이나 제조자가 복제를 시도했을 때 나타나지 않았다.디버거로 프로그램을 실행하는 것과 같이 버그를 찾는 것을 돕기 위해 설정이 강화될 때마다 다른 버그가 발생하는 것을 멈출 수 있다. 이러한 버그는 하이젠버그(Heisenberg 불확실성 원리의 이름을 따서 짓는다)라고 불린다.

1990년대 이후, 특히 아리안 5편 501편 참사에 이어, 추상적 해석에 의한 정적 코드 분석과 같은 디버깅에 대한 자동 보조장치에 대한 관심이 높아졌다.[32]

어떤 종류의 벌레들은 코드와 아무 관련이 없다.잘못된 문서나 하드웨어는 코드가 문서와 일치하더라도 시스템 사용에 문제를 일으킬 수 있다.경우에 따라 코드를 변경하면 코드가 문서와 더 이상 일치하지 않더라도 문제가 제거된다.임베디드 시스템은 하드웨어 버그를 중심으로 자주 작동하는데, 이는 새로운 버전의 ROM을 만드는 것이 하드웨어를 재제조하는 것보다 훨씬 저렴하기 때문이며, 특히 그것들이 상품 품목인 경우 더욱 그러하다.

버그 벤치마크

시험과 디버깅에 대한 재현 가능한 연구를 촉진하기 위해 연구자들은 다음과 같은 버그에 대한 큐레이션된 벤치마크를 사용한다.

  • 지멘스 벤치마크
  • 많은벅스는[33] 9개의 오픈소스 프로그램에서 185개의 C 버그를 벤치마킹한 것이다.
  • 결함4J는[34] 5개의 오픈소스 프로젝트 중 341개의 자바 버그를 벤치마킹한 것이다.여기에는 다양한 패치 유형을 포괄하는 해당 패치가 포함되어 있다.[35]
  • BEARS는[36] 테스트 실패에 초점을 맞춘 지속적인 통합 빌드 실패의 벤치마크다.트라비스 CI의 오픈소스 프로젝트에서 빌드를 모니터링하여 만들어졌다.

버그 관리

버그 관리는 수정된 코드를 문서화, 분류, 할당, 복제, 수정 및 해제하는 과정을 포함한다.소프트웨어에 대한 제안된 변경사항(버그뿐만 아니라 개선 요청 및 전체 릴리스)은 일반적으로 버그 추적 시스템 또는 문제 추적 시스템을 사용하여 추적 및 관리된다.[37]추가된 항목은 결함, 티켓, 이슈 또는 민첩한 개발 패러다임, 스토리, 에픽을 따르는 것으로 불릴 수 있다.범주는 버전 번호, 소프트웨어의 영역, 심각도 및 우선순위, 기능 요청 또는 버그와 같은 문제 유형과 같은 객관적, 주관적 또는 조합일 수 있다.

버그 트라이지는 버그를 검토하고 버그를 고칠지, 언제 고칠지를 결정한다.이 결정은 버그 우선순위와 프로젝트 일정 등의 요인에 따라 결정된다.삼계탕은 벌레의 원인을 조사하기 위한 것이 아니라 고치는 데 드는 비용이다.3종목은 정기적으로 진행되며, 이전 회의 때부터 벌레를 열거나 다시 열게 된다.전형적으로 3종 과정의 참석자는 프로젝트 매니저, 개발 매니저, 테스트 매니저, 빌드 매니저, 기술 전문가들이다.[38][39]

심각도

심각도는 버그가 시스템 작동에 미치는 영향의 강도다.[40]이러한 영향은 데이터 손실, 재무, 영업권 손실 및 낭비된 노력일 수 있다.심각도 수준은 표준화되지 않는다.영향은 산업마다 다르다.비디오 게임에서의 충돌은 웹 브라우저에서의 충돌, 즉 실시간 모니터링 시스템에서의 충돌과는 전혀 다른 영향을 미친다.예를 들어 버그 심각도 수준은 "충돌 또는 정지"(고객이 주어진 작업을 수행할 수 있는 방법이 없다는 의미), "해결 방법이 있다"(사용자가 여전히 작업을 수행할 수 있다는 의미), "시각적 결함"(예: 누락된 이미지 또는 이동된 버튼 또는 양식 요소) 또는 "문서화 오류"일 수 있다.일부 소프트웨어 게시자는 "중요", "높음", "낮음", "차단" 또는 "다양함"[41]과 같은 보다 검증된 심각도를 사용한다.버그의 심각도는 수정 우선순위와 별개의 범주가 될 수 있으며, 두 범주는 별도로 정량화하여 관리할 수 있다.

우선 순위

버그가 계획된 변경 목록에 포함되는 위치를 우선 순위 제어.우선 순위는 소프트웨어 생산자별로 정한다.우선순위는 1부터 5까지 또는 "심각", "높음", "낮음" 또는 "적절함"과 같은 숫자 또는 이름일 수 있다.이러한 등급 척도는 심각도 등급과 비슷하거나 동일할 수 있지만, 버그의 심각도를 추정된 수정 노력과 조합한 것으로 평가된다. 심각도는 낮지만 수정이 쉬운 버그는 과도한 수정이 필요한 보통 심각도를 가진 버그보다 높은 우선순위를 가질 수 있다.우선순위 등급은 다음 소프트웨어 출시 전에 수정해야 하는 모든 버그를 나타내는 "중요" 우선순위와 같은 제품 출시와 일치할 수 있다.

소프트웨어 릴리스

우선순위가 낮은 알려진 버그가 있는 소프트웨어를 출시하는 것이 일반적이다.우선 순위가 충분히 높은 버그는 그러한 수정 사항이 있는 모듈만 포함하는 코드의 일부를 특별 릴리스할 수 있다.이것들은 패치라고 알려져 있다.대부분의 릴리스에는 행동 변화와 여러 가지 버그 수정이 혼합되어 있다.버그 수정을 강조하는 릴리즈는 기능 추가나 변경을 강조하는 주요 릴리즈와 차별화하기 위해 유지보수 릴리즈로 알려져 있다.

소프트웨어 게시자가 특정 버그를 패치하거나 수정하지 않는 이유는 다음과 같다.

  • 마감일을 맞추어야 하고 마감일까지 모든 버그를 고치기에 자원이 부족하다.[42]
  • 버그는 이미 개봉 예정으로 고정되어 있으며, 우선순위가 높지 않다.
  • 버그를 고치는 데 필요한 변경은 비용이 너무 많이 들거나 다른 구성 요소에 너무 많은 영향을 미치기 때문에 중대한 시험 활동을 요구한다.
  • 일부 사용자가 기존의 버기 동작에 의존하고 있는 것으로 의심되거나 알려져 있을 수 있다. 제안된 수정사항은 변경사항을 도입할 수 있다.
  • 문제는 곧 출시될 예정으로 구식이 될 지역에 있다; 그것을 고치는 것은 불필요하다.
  • "이건 벌레가 아니라 특징이야."[43]예상된 행동과 인지된 행동 또는 문서화되지 않은 특징 사이에 오해가 생겼다.

종류들

소프트웨어 개발 프로젝트에서는 어느 단계에서나 "실수" 또는 "실수"가 도입될 수 있다.버그는 사양, 설계, 코딩, 데이터 입력 또는 문서화 중에 소프트웨어 팀에 의한 감독이나 오해로부터 발생한다.예를 들어, 단어 목록을 알파벳순으로 표시하는 비교적 간단한 프로그램인 이 설계는 단어가 하이픈을 포함할 때 어떤 일이 일어나야 하는지를 고려하지 못할 수 있다.또는 추상적 설계를 코드로 변환할 때 코더는 실수로 "<="가 의도된 "<"가 될 수 있는 개별 오류를 생성하여 목록의 마지막 단어를 정렬하지 못할 수 있다.

버그의 또 다른 범주는 프로그램이 동시에 여러 구성 요소를 실행할 때 발생할 수 있는 경기 조건이라고 불린다.구성 요소가 개발자가 의도한 것과 다른 순서로 상호작용하는 경우, 서로 간섭하고 프로그램이 작업을 완료하지 못하게 할 수 있다.이러한 버그는 프로그램의 모든 실행 중에 발생하지 않을 수 있기 때문에 탐지하거나 예측하기가 어려울 수 있다.

개념적 오류는 소프트웨어가 해야 할 일에 대한 개발자의 오해다.결과적인 소프트웨어는 개발자의 이해에 따라 수행될 수 있지만, 실제로 필요한 것은 아니다.기타 유형:

산술

논리학

구문

  • 동일성 검정 대신 할당을 수행하는 등 잘못된 연산자 사용예를 들어, 일부 언어에서 x=5는 x의 값을 5로 설정하고, x===5는 x가 현재 5인지 또는 일부 다른 숫자인지 여부를 점검한다.해석된 언어들은 그러한 코드들을 실패하게 한다.컴파일된 언어는 테스트를 시작하기 전에 그러한 오류를 잡을 수 있다.

자원

멀티스레딩

  • 과제 B가 완료될 때까지 작업 A를 계속할 수 없지만 동시에 작업 A가 완료될 때까지 작업 B를 계속할 수 없는 교착 상태.
  • 컴퓨터가 프로그래머가 의도한 순서대로 작업을 수행하지 않는 경기 조건.
  • 중요 섹션의 동시성 오류, 상호 배제 및 기타 동시 처리 기능.TOCTOU(Time-of-Time-to-use)는 보호되지 않은 중요 섹션의 한 형태다.

인터페이싱

  • 잘못된 API 사용.[44]
  • 잘못된 프로토콜 구현.
  • 잘못된 하드웨어 취급.
  • 특정 플랫폼에 대한 잘못된 가정.
  • 호환되지 않는 시스템.새로운 API나 통신 프로토콜은 두 시스템이 다른 버전을 사용할 때 작동하는 것처럼 보일 수 있지만, 한 버전에서 구현된 기능이나 기능이 다른 버전에서 변경되거나 누락될 때 오류가 발생할 수 있다.지속적으로 실행되어야 하는 생산 시스템에서는 통신 산업이나[45] 인터넷과 같이 주요 업데이트를 위해 전체 시스템을 종료하는 것이 불가능할 수 있다.[46][47][48]이 경우 대형 시스템의 소규모 세그먼트를 개별적으로 업그레이드하여 대형 네트워크에 대한 중단을 최소화한다.그러나 일부 섹션은 간과되고 업그레이드되지 않을 수 있으며, 찾기 및 수리가 어려울 수 있는 호환성 오류를 야기할 수 있다.
  • 잘못된 코드 주석[49]

팀워크

  • 압축되지 않은 업데이트: 예를 들어 프로그래머가 "myAdd"를 변경하지만 동일한 알고리즘을 사용하는 "mySubtract"를 변경하지 않는 경우.이러한 오류들은 반복하지 마라는 철학에 의해 완화된다.
  • 오래된 코멘트 또는 부정확한 코멘트: 많은 프로그래머들은 코멘트가 코드를 정확하게 기술한다고 가정한다.
  • 문서와 제품의 차이점.

시사점

소프트웨어 버그가 야기할 수 있는 손상의 양과 유형은 자연스럽게 소프트웨어 품질에 관한 의사 결정, 프로세스 및 정책에 영향을 미친다.인간 우주 비행, 항공, 원자력, 의료, 대중 교통 또는 자동차 안전과 같은 애플리케이션에서, 소프트웨어 결함은 인간의 부상이나 심지어 죽음을 초래할 가능성이 있기 때문에, 그러한 소프트웨어는 예를 들어 온라인 쇼핑 웹사이트보다 훨씬 더 많은 정밀 조사와 품질 관리를 할 것이다.소프트웨어 결함으로 인해 은행이나 그 고객들에게 심각한 재정적 피해를 줄 가능성이 있는 은행과 같은 애플리케이션에서는, 예를 들어, 사진 편집 애플리케이션보다 품질 관리가 더 중요하다.NASA의 소프트웨어 보증 기술 센터는 1000줄의 코드(SLOC)[citation needed]당 0.1개 미만으로 오류 수를 줄일 수 있었지만, 이는 비즈니스 세계의 프로젝트에서는 실현 가능하지 않은 것으로 여겨졌다.

'비행 소프트웨어 복잡성'에 대한 NASA 연구에 따르면, "유별나게 우수한 소프트웨어 개발 과정으로 코드 1만 라인당 결함을 1개까지 낮출 수 있다"[50]고 한다.

버그로 인한 피해 외에도 일부 비용은 버그를 고치는 데 쏟은 노력 덕분이다.1978년, Lientz 외 연구진은 프로젝트의 중간값이 개발 노력의 17%를 곤충 고정에 투자한다는 것을 보여주었다.[51]GitHub 저장소에 대한 2020년 조사에서 중위수가 20%[52]인 것으로 나타났다.

잘 알려진 벌레

주요 기사:소프트웨어 버그 목록

많은 소프트웨어 버그는 보통 심각성 때문에 잘 알려져 있다. 예를 들어 다양한 우주 공간과 군용 항공기 추락이 포함된다.아마도 가장 유명한 버그는 2000년 문제 또는 Y2K 버그일 것이다. 이 버그는 19xx에서 20xx 날짜로 전환되기 훨씬 전에 쓰여진 많은 프로그램들을 야기시켰는데, 예를 들어, "25 dec 04"와 같은 날짜를 1904년에 있는 것으로 처리하고, "2000"이 아닌 "19100"을 표시하는 등등이 그것이다.20세기 말 엄청난 노력이 가장 심각한 문제를 해결했고, 큰 결과는 없었다.

2012년 주식 거래 중단은 이전 API와 새로운 API 간의 그러한 비호환성을 포함했다.

대중문화에서

  • 1968년 소설 'A Space Odyssey 2001'과 이에 상응하는 영화 'A Space Odyssey'에서 모두 우주선의 탑재 컴퓨터인 HAL 9000은 승무원 전원을 죽이려고 시도한다.1982년 후속 소설, 2010년: Odyssey Two와 동봉된 1984년 영화인 2010년, 이 액션은 컴퓨터에 두 가지 상반된 목적을 프로그래밍했기 때문에 발생했다는 것이 밝혀졌다: 모든 정보를 완전히 공개하는 것과 승무원들로부터 비행의 진정한 목적을 비밀로 하는 것이다; 이 갈등은 HAL을 편집증적으로 만들었고 결국 살인자로 만들었다.
  • '소프트웨어 속의 벌레'의 결과인 네나 1983년 노래 99루프트볼론(99 레드풍선)의 영문 버전에서는 99개의 붉은 풍선 그룹이 적 핵미사일 발사로 잘못 알려져 이에 상응하는 발사 대응이 요구돼 대재앙이 일어난다.
  • 1999년 아메리칸 코미디 오피스 스페이스에서는 세 명의 직원이 살라미 슬라이싱으로 묘사된 오래된 기술인 1페니의 반올림된 분량을 은행 계좌로 보내는 컴퓨터 바이러스를 이용하여 Y2K 컴퓨터 버그에 대한 회사의 선점을 이용하려고 시도(실패)하고 있다.
  • 엘렌 울먼이 쓴 2004년 소설 '버그'는 한 프로그래머가 데이터베이스 애플리케이션에서 이해하기 어려운 버그를 찾으려는 시도를 다룬 작품이다.[53]
  • 2008년 캐나다 영화 Control Alt Delete는 1999년 말 한 컴퓨터 프로그래머가 2000년 문제와 관련된 자신의 회사의 버그를 고치기 위해 고군분투하는 내용이다.

참고 항목

참조

  1. ^ Mittal, Varun; Aditya, Shivam (January 1, 2015). "Recent Developments in the Field of Bug Fixing". Procedia Computer Science. International Conference on Computer, Communication and Convergence (ICCC 2015). 48: 288–297. doi:10.1016/j.procs.2015.04.184. ISSN 1877-0509.
  2. ^ "Ariane 501 - Presentation of Inquiry Board report". www.esa.int. Retrieved January 29, 2022.
  3. ^ Prof. Simon Rogerson. "The Chinook Helicopter Disaster". Ccsr.cse.dmu.ac.uk. Archived from the original on July 17, 2012. Retrieved September 24, 2012.
  4. ^ "Post Office scandal ruined lives, inquiry hears". BBC News. February 14, 2022.
  5. ^ "Software bugs cost US economy dear". June 10, 2009. Archived from the original on June 10, 2009. Retrieved September 24, 2012.{{cite web}}: CS1 maint : 부적합한 URL(링크)
  6. ^ Computerworld staff (September 3, 2011). "Moth in the machine: Debugging the origins of 'bug'". Computerworld. Archived from the original on August 25, 2015.
  7. ^ "bug". Oxford English Dictionary (Online ed.). Oxford University Press. (가입 또는 참여기관 회원가입 필요) 5a
  8. ^ "Did You Know? Edison Coined the Term "Bug"". August 1, 2013. Retrieved July 19, 2019.
  9. ^ 1878년 11월 13일, 에디슨 투 푸스카스, 미국 국립공원관리국, 웨스트오렌지, N.J.의 에디슨 국립연구소 논문 인용
  10. ^ "Baffle Ball". Internet Pinball Database. (See image of advertisement in reference entry)
  11. ^ "Modern Aircraft Carriers are Result of 20 Years of Smart Experimentation". Life. June 29, 1942. p. 25. Archived from the original on June 4, 2013. Retrieved November 17, 2011.
  12. ^ Dickinson Rich, Louise (1942), We Took to the Woods, JB Lippincott Co, p. 93, LCCN 42024308, OCLC 405243, archived from the original on March 16, 2017.
  13. ^ FCAT NRT Test, Harcourt, March 18, 2008
  14. ^ "Danis, Sharron Ann: "Rear Admiral Grace Murray Hopper"". ei.cs.vt.edu. February 16, 1997. Retrieved January 31, 2010.
  15. ^ James S. Huggins. "First Computer Bug". Jamesshuggins.com. Archived from the original on August 16, 2000. Retrieved September 24, 2012.
  16. ^ "Bug Archived 2017년 3월 23일 웨이백 머신에서 보관", The Jargon File, ver. 4.4.7. 2010년 6월 3일 회수
  17. ^ a b 스미스소니언 국립미국사박물관, "2017년 3월 23일 웨이백머신에 컴퓨터 버그가 있는 로그북"
  18. ^ "제1의 컴퓨터 버그, 해군 역사 센터"그러나 하버드 마크 II 컴퓨터는 1947년 여름까지 완성되지 않았다는 점에 주목하라.
  19. ^ IEEE 연산사 연보, 제22권 제1호, 2000년
  20. ^ 영국항공학회지. 49, 183/2 1945년 "형식시험과 비행시험, '디버깅'의 단계를 거쳐 ...의 범위를 정했다."
  21. ^ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Herr, Trey. "Bugs in the System" (PDF). Open Policy Institute. Archived (PDF) from the original on September 21, 2016. Retrieved August 22, 2016.
  22. ^ a b c d Rozens, Tracy (August 12, 2016). "Cyber reforms needed to strengthen software bug discovery and disclosure: New America report – Homeland Preparedness News". Retrieved August 23, 2016.
  23. ^ "News at SEI 1999 Archive". cmu.edu. Archived from the original on May 26, 2013.
  24. ^ Shustek, Len (August 2, 2016). "In His Own Words: Gary Kildall". Remarkable People. Computer History Museum. Archived from the original on December 17, 2016.
  25. ^ Kildall, Gary Arlen (August 2, 2016) [1993]. Kildall, Scott; Kildall, Kristin (eds.). "Computer Connections: People, Places, and Events in the Evolution of the Personal Computer Industry" (Manuscript, part 1). Kildall Family: 14–15. Archived from the original on November 17, 2016. Retrieved November 17, 2016. {{cite journal}}:Cite 저널은 필요로 한다. journal=(도움말)
  26. ^ a b "Testing experience : te : the magazine for professional testers". Testing Experience. Germany: testingexperience: 42. March 2012. ISSN 1866-5705. (필요한 경우)
  27. ^ Huizinga, Dorota; Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 426. ISBN 978-0-470-04212-0. Archived from the original on April 25, 2012.
  28. ^ McDonald, Marc; Musson, Robert; Smith, Ross (2007). The Practical Guide to Defect Prevention. Microsoft Press. p. 480. ISBN 978-0-7356-2253-1.
  29. ^ "2011년 5월 14일 웨이백 머신에 보관된 "조기 출시, 자주 출시" 레이먼드, 성당과 바자
  30. ^ "Wide Open Source" 2007년 9월 29일 보안, Elias Levy, Wayback Machine에 보관2000년 4월 17일 포커스
  31. ^ 모리스 윌크스 인용
  32. ^ "PolySpace Technologies history". christele.faure.pagesperso-orange.fr. Retrieved August 1, 2019.
  33. ^ Le Goues, Claire; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). "The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs". IEEE Transactions on Software Engineering. 41 (12): 1236–1256. doi:10.1109/TSE.2015.2454513. ISSN 0098-5589.
  34. ^ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). "Defects4J: a database of existing faults to enable controlled testing studies for Java programs". Proceedings of the 2014 International Symposium on Software Testing and Analysis - ISSTA 2014. pp. 437–440. CiteSeerX 10.1.1.646.3086. doi:10.1145/2610384.2628055. ISBN 9781450326452. S2CID 12796895.
  35. ^ Sobreira, Victor; Durieux, Thomas; Madeiral, Fernanda; Monperrus, Martin; de Almeida Maia, Marcelo (2018). "Dissection of a bug dataset: Anatomy of 395 patches from Defects4J". 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER). pp. 130–140. arXiv:1801.06393. doi:10.1109/SANER.2018.8330203. ISBN 978-1-5386-4969-5. S2CID 4607810.
  36. ^ Madeiral, Fernanda; Urli, Simon; Maia, Marcelo; Monperrus, Martin; Maia, Marcelo A. (2019). "BEARS: An Extensible Java Bug Benchmark for Automatic Program Repair Studies". 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER). pp. 468–478. arXiv:1901.06024. doi:10.1109/SANER.2019.8667991. ISBN 978-1-7281-0591-8. S2CID 58028949.
  37. ^ Allen, Mitch (May–June 2002). "Bug Tracking Basics: A beginner's guide to reporting and tracking defects". Software Testing & Quality Engineering Magazine. Vol. 4, no. 3. pp. 20–24. Retrieved December 19, 2017.
  38. ^ Rex Black (2002). Managing The Testing Process (2Nd Ed.). Wiley India Pvt. Limited. p. 139. ISBN 9788126503131. Retrieved June 19, 2021.
  39. ^ Chris Vander Mey (August 24, 2012). Shipping Greatness - Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon. O'Reilly Media. p. 79-81. ISBN 9781449336608.
  40. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (October 1, 2020). "Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems". Information and Software Technology. 126: 106344. doi:10.1016/j.infsof.2020.106344. S2CID 219733047.
  41. ^ "5.3. Anatomy of a Bug". bugzilla.org. Archived from the original on May 23, 2013.
  42. ^ "The Next Generation 1996 Lexicon A to Z: Slipstream Release". Next Generation. No. 15. Imagine Media. March 1996. p. 41.
  43. ^ Carr, Nicholas (2018). "'It's Not a Bug, It's a Feature.' Trite—or Just Right?". wired.com.
  44. ^ Monperrus, Martin; Bruch, Marcel; Mezini, Mira (2010). "Detecting Missing Method Calls in Object-Oriented Software". ECOOP 2010 – Object-Oriented Programming (PDF). Lecture Notes in Computer Science. Vol. 6183. pp. 2–25. doi:10.1007/978-3-642-14107-2_2. ISBN 978-3-642-14106-5. S2CID 16724498.
  45. ^ Kimbler, K. (1998). Feature Interactions in Telecommunications and Software Systems V. IOS Press. p. 8. ISBN 978-90-5199-431-5.
  46. ^ Syed, Mahbubur Rahman (July 1, 2001). Multimedia Networking: Technology, Management and Applications: Technology, Management and Applications. Idea Group Inc (IGI). p. 398. ISBN 978-1-59140-005-9.
  47. ^ Wu, Chwan-Hwa (John); Irwin, J. David (April 19, 2016). Introduction to Computer Networks and Cybersecurity. CRC Press. p. 500. ISBN 978-1-4665-7214-0.
  48. ^ RFC 1263: "유해하다고 간주되는 TCP Extensions" 인용문: "새로운 버전의 프로토콜을 모든 호스트에 배포하는 시간은 상당히 길 수 있다(사실상). ...이전 버전과 새 버전 사이에 조금이라도 양립할 수 없다면 혼란이 올 수 있다."
  49. ^ Yu, Zhongxing; Bai, Chenggang; Seinturier, Lionel; Monperrus, Martin (2019). "Characterizing the Usage, Evolution and Impact of Java Annotations in Practice". IEEE Transactions on Software Engineering. 47 (5): 1. arXiv:1805.01965. doi:10.1109/TSE.2019.2910516. S2CID 102351817.
  50. ^ Dvorak, Daniel L. 1 NASA Study on Flight Software Complexity. CiteSeerX 10.1.1.711.2976.
  51. ^ Lientz, B. P.; Swanson, E. B.; Tompkins, G. E. (1978). "Characteristics of Application Software Maintenance". Communications of the ACM. 21 (6): 466–471. doi:10.1145/359511.359522. S2CID 14950091.
  52. ^ Amit, Idan; Feitelson, Dror G. (2020). "The Corrective Commit Probability Code Quality Metric". arXiv:2007.10912 [cs.SE].
  53. ^ Ullman, Ellen (2004). The Bug. Picador. ISBN 978-1-250-00249-5.

외부 링크