"mandelbug"의 존재를 팀원들에게 확신시키는 방법

우리는 응용 프로그램을 개발하고 있습니다; 여기에는 다른 코더가 개발 한 라이브러리가 포함되며이 라이브러리는 여러 네트워크 연결을 통해 서버와 통신하며 여기에는 여러 스레드가 함께 작동합니다. 서버 측 코드는 매우 복잡하므로 소스 코드에 액세스 할 수 없습니다.

최근에 때때로 응용 프로그램 충돌을 일으키는 만델 버그 를 발견했습니다 . 한 번만 재현하고 스택 추적을 얻을 수 있으므로 버그 보고서를 열었습니다. 버그 자체는 수정하기 쉽습니다 (백그라운드 스레드 중 하나에서 포착되지 않은 웹 예외로 인해 CLR이 프로그램을 종료시킵니다).

문제는 "그가 존재한다고 확신하지 않기"때문에 개발자가 버그 수정을 거부한다는 것입니다. 불행히도 상사는 그와 함께 사이딩하고 있으며 버그의 존재를 증명하기 위해 "단단한 테스트 사례"를 작성하지 않고 단위 테스트를 통해 버그가 사라 졌음을 확인하지 않으면이 버그를 해결할 수 없다고 말합니다. 버그의 본질로 인해 기본적으로 불가능한 것.

어떤 충고?

가능하면 응용 프로그램 코드에서 절전 모드 또는 차단 기능 을 사용 하여이 결함을 재현 할 수 있는지 확인하는 데 시간이 걸릴 수 있습니다 . 그러나 너무 많은 시간을 보내지 마십시오. 이 문제는 멀티 테 두링 (및 관찰 한대로)으로 인해 발생하므로 드물게 발생합니다.

나의 충고는 이것으로 너무 땀을 흘리지 않는 것입니다. 작업을 계속하십시오. 이 충돌 이 발생할 때마다 스택 추적으로 버그 보고서 를 업데이트하여 반복 발생 이라고 말하고 소유자를 라이브러리 개발자로 변경하십시오. 관리 / 리드가 빈도에 따라 수정 여부를 결정하게하십시오.

또한 개발자의 사고 방식을 이해하려고 노력하십시오. "발견되지 않은 웹 예외"라고 말하셨습니다. 이 단계의 개발자는 이것을 잡는 다른 효과가 무엇인지 완전히 확신하지 못할 수 있습니다 . 따라서 코드를 만지는 것을 꺼려 할 수 있습니다.

그래서, 당신의 다소 명확한 설명에서, 나는 이것을 다음과 같이 얻었습니다.

간단한 추가 예외 처리 만 누락 된 것이 확실하며 lib의 어떤 코드 행에 문제가 있으며 lib를 수정하는 방법을 이미 알고 있습니다.

그렇다면 몇 줄의 코드 줄을 직접 lib에 추가하지 말고 팀에 변경 사항을 적용하여 친절하게 lib를 테스트하도록 요청하십시오. lib를 담당하는 개발자가 이해하기 쉬운 저 위험 변경인지 확인하십시오. 발생할 수있는 최악의 상황은 수정으로 인해 예기치 않은 새로운 동작이 발생하는 경우 누군가 VCS의 변경 사항을 되돌려 야한다는 것입니다.

대부분의 사람들은 작업이 이미 완료되었을 때 더 쉽게 확신 할 수 있습니다. 또한 "이 코드가 잘못되었습니다. 어떻게 든 수정하십시오"와 반대로 "여기서는 개선 된 솔루션이 있습니다"에 더 잘 반응합니다.

편집 : 개발자가 여전히 변경 사항 추가를 거부하면 최상의 옵션은 네트워크 오류를 시뮬레이션하는 격리 된 테스트 하네스 내에서 문제가있는 코드를 작동시키려는 것입니다. 레거시 코드로 효과적으로 작업하면 이러한 종류의 문제를 해결하는 방법에 대한 많은 기술이 설명됩니다. 예를 들어 문제가있는 모듈과 함수 만 포함하여 라이브러리의 테스트 버전을 만들고 제어 된 조건에서 "네트워크 예외"를 시뮬레이션 할 수있는 "모의 환경"을 만들 수 있습니다. 언뜻보기에는 너무 많은 노력이 필요한 것 같지만 일단 그러한 환경이 있으면 많은 추가 테스트를 추가 할 수 있습니다 (lib의 작성자가 누락을 추가하지 않기 때문에 그럴 것 같습니다. 한 곳에서 예외 처리

이와 같은 버그의 경우 자동 퍼지 테스트 (임의의 테스트라고도 함) 가이 를 재현하는 데 도움이 될 수 있습니다. 이를 통해 고정 된 매개 변수 세트 (또는 입력)를 테스트 대상에 무작위로 지정하여 버그를 찾는 프로세스를 자동화합니다. 각 테스트 실행, 매개 변수는 타임 스탬프 등을 포함하여 로그 파일에 기록되므로 충돌이 발생하면 동일한 매개 변수를 사용하여 테스트를 재생하여 테스트 할 수 있습니다 (이론적으로).

테스트 프로세스는 자동화되어 있기 때문에 단기간에 많은 테스트를 실행할 수 있습니다. 종종 밤새 실행되도록 남겨두고 아침에 충돌을 재현했는지 로그 파일을 확인할 수 있습니다.

악마의 옹호자는 다른 길을 제안합니다.

다른 개발자는 버그가 없다고 단언했다.

존재하지 않는 것으로 보이는 버그에서 지옥을 강조하고 더 자주 충돌하게하는 방법을 생각해 낼 수 있습니까?

스택 추적은 버그가 존재하거나 적어도 특정 빌드에 존재했다는 명백한 증거입니다. 당신이 가지고 있지 않은 것은 버그가 수정되었다는 증거입니다. 그들은 그것을 무시하는 어리 석다. 고객 시스템에서 매번 트리거되는 여러 시스템에서 수십만 번의 자동 시도 후 "재생 불가능"버그가있었습니다 .

스택 추적의 이점조차없이 매년 몇 가지 버그가 발생합니다. 거의 모든 경우에, 사전에 재현 할 수 없었지만 일단 수정되면 자동 테스트를 쉽게 수행 할 수 있습니다.

예를 들어, 몇 달 전에 사용자가 분당 96 단어보다 빠르게 입력했을 때만 발생하는 버그를 수정했습니다. 문제를 해결하기 전에 버그가 "때때로"발생했다는 것을 알았습니다. 빠른 타이핑을위한 단위 테스트를 작성하는 것은 결코 일어나지 않을 것입니다. 그러나 근본 원인을 알고 난 후 테스트를하는 것은 사소한 일이었습니다.

버그를 수정 한 후에도 재현 할 수없는 드문 경우에도 코드 검사를 통해 버그를 닫을 수 있습니다.