자체적으로 수정 된 것으로 보이는 버그를 처리하는 방법은 무엇입니까? [닫은]

내부 시스템의 웹 응용 프로그램 개발자입니다. 사용자가 버그가 있다고보고합니다.

버그는 일부 단어를 표시 할 수 없다는 것입니다. 보고서에는 버그를 명확하게 보여주는 화면 캡처가 포함되어 있습니다. 그러나 보고서는 거의 한 달이 지나서 프로덕션 환경에서 버그를 더 이상 재현 할 수 없습니다.

클라이언트와 사용자에게 어떻게 대답해야합니까?

개발 환경을 버그가 발견 된 버전으로 되돌리고 버그가 있는지 확인하십시오.

버그가 있으면 버그를 조사하여 현재 버전에 버그가 없는지 확인할 수 있습니다. 그런 다음 관련이없는 변경으로 해결되었다는 의견으로 버그 보고서를 닫습니다. 필요한 경우 회귀 테스트를 추가하십시오.

해당 버전에서 버그를 재현 할 수없는 경우 여기에서 다른 많은 질문에 제시된 전략을 사용할 수 있습니다 (토마스에게 초기 목록을 주셔서 감사합니다).

• 재현 가능한 테스트 사례가없는 경우 버그를 제거 하시겠습니까?
• 재현하기 어려운 버그를 어떻게 분리합니까?
• 코드를 가장 효과적으로 디버깅하는 방법은 무엇입니까?
• 설명 할 수없는 버그?
• 재현하지 않는 버그로 무엇을해야합니까?

나는 당신이 버그를 재현하기 위해 할 수는 있지만 할 수없는 모든 것을 진심으로했다고 가정합니다.

이와 같은 경우에는 수행중인 작업을 기록하지 못한 응용 프로그램 영역 주위에 일부 코드를 추가하는 것이 가장 좋습니다. 따라서 다시 발생할 경우 작업 양식에 더 많은 데이터가있을 수 있기를 바랍니다. 현재 사용할 수없는 정보가 무엇인지 생각해보십시오. 예를 들어, 특정 입력 매개 변수 세트가 전송 될 때만 발생하므로 프로세스가 실행될 때마다이를 기록 할 수 있습니다. 그러나 버그의 중요성과 발생 빈도에 따라 상사와상의하여 시간을 낭비하고 싶지 않을 수 있습니다.

그런 다음 버그를보고 한 사람에게 가서 (버그 추적 응용 프로그램에서 버그를 발견 한 경우 직접 할 필요는 없음) 버그를 재현 할 수는 없지만 추가로 추가했다고 말하십시오. 버그가 다시 발생하는 경우 프로세스가 수행하는 작업에 대한 자세한 정보를 얻기 위해 로깅. 그런 다음 버그를 닫으십시오.

추가 로깅을 수행 할 수없는 경우 버그를 재현 할 수 없다고보고하고 버그가 다시 발생하면이를 재현하고 필요한 정보를 알려 주어야합니다. 우리는 종종 오류가 발생했을 때 입력 매개 변수를 정확히 알려주도록 요청합니다. 오류의 스크린 샷만 있으면 도움이되지만 오류가 발생한 시점에 어떤 단계를 수행했는지, 어떤 정보를 사용하려고했는지 아는 것이 도움이됩니다. 따라서 기본적으로 오류가 다시 발생하면 오류를보고 할 때 더 많은 정보를 제공하기 위해 onus를 다시 배치합니다.

버그 추적기에서 시도한 단계를 설명하여 버그가 다시 발생할 경우 버그를 처리 한 사람이 이전에 수행 한 작업에 대한 배경 지식을 갖도록하십시오.

재현 할 수없는 가방이 최악입니다! 그 동안 수정되었거나 여전히있을 수 있지만 산발적이거나 재현 단계가 불충분하게 지정되었습니다. 버그의 위험과 버그 조사 범위를 판단해야합니다. 핵 미사일을위한 온라인 레시피 관리자 또는 조향 제어 소프트웨어를 만들고 있습니까?

영향이 적은 버그이고 실수로 버그가 수정 될 수 있는 변경 사항이 있음을 알고 있는 경우 버그를 재현 할 수없고 수정 된 것으로 간주하여 버그를 닫을 수 있습니다. .

더 우려되는 경우, 처음에 버그를 일으킨 원인에 대한 이론을 만들고 변경 로그와 소스 히스토리를 통해 수정 위치를 확인할 수 있는지 확인할 수 있습니다.

더 심각한 버그의 경우 소스를 마지막 릴리스 시점으로 롤백 한 다음 재생산해야합니다. 성공적으로 재현하면 나중에 커밋에서 수정되었는지 테스트를 작성할 수 있습니다.