재현 불가능하거나 무작위로 발생하는 버그를 수정하려면 어떻게해야합니까?


11

며칠 전에 버그가 발견 된 다국어 웹 사이트가 있습니다. 다른 언어로 된 다른 언어 데이터를 표시하고 영어와 같은 데이터의 혼합을 선택했지만 페이지에서 다른 언어 데이터도 표시했습니다. 자주 수행하지 않지만 웹 사이트에 있습니다. 항상 발생하는 것은 아니기 때문에 코드를 통과해도 도움이되지 않습니다.

적시에 문제를 찾는 데 어떤 제안이 있습니까? 나는 여기서 전략을 요구하고 있습니다.


4
이 버그가 발생할 수있는 상황에 대한 코드 조사를 시작하십시오 (다른 방식으로 진행하는 대신)
— Imran Omar Bukhsh

답변:


20

첫 번째 단계는 이러한 유형의 문제를 일으킬 수 있는 것을 시도하고 특성화하는 것 입니다. 이는 코드 섹션에 올바른 언어를 선택하는 것과 관련이 있으므로 다음을 고려하여 시작하십시오.

  • 언어는 어떻게 감지됩니까? HTTP 요청의 정보를 기반으로합니까? 세션 정보를 기반으로합니까? 아니면 데이터베이스 필드를 기반으로합니까? 본질적으로 이것은 앱이 각 섹션의 언어를 선택하는 방법과 관련하여 문제가 될 수 있습니까?
  • 언어는 어떻게 표시됩니까? 특성 파일 또는 데이터베이스에서 가져 옵니까? 올바른 언어에 대한 참조가 어떻게 손실 될 수 있습니까? 혼합 언어가 항상 사이트의 기본값입니까?
  • 클라이언트 환경과 상관 관계가 있습니까? 이것은 첫 번째 글 머리 기호와 관련이 있지만 조금 더 진행됩니다. 다운 스트림 캐싱 프록시로 인해 이상한 렌더링 문제가 발생했습니다. 일반적으로 이러한 유형의 문제는 부실하거나 한 사람의 페이지를 다른 사용자에게 제공하는 전체 페이지입니다 (당황 스럽습니다).
  • 스레드 로컬 값을 사용하고 있습니까? 요청이 둘 이상의 스레드를 처리하는 경우 스레드 로컬 값은 당시 작동중인 스레드에 따라 다른 정보를 갖습니다. 웹 서버 환경에서는 처리를 시작한 스레드가 처리를 완료 한 스레드와 동일하다고 가정 할 수 없습니다 (플랫폼 사양의 일부가 아닌 한). 서버 작성자는 작은 스레드 풀과 다중 작업을 다시 사용하면 더 많은 요청을 동시에 처리 할 수 ​​있음을 발견했습니다. 요청 시작부터 끝까지 하나의 스레드가 있더라도 서버는 동시에 다른 스레드에 대한 다른 요청을 다중화 할 수 있습니다. 스레드 로컬 대신 해당 값을 요청 또는 세션 속성에 바인딩하십시오.

당신이 특징으로 한 자, 일단 가능성이 잘못 될 수있는 무엇을, 그것의 시간은 당신이 당신이 시도하고 무엇을 찾을 필요가 데이터를 가지고 있는지 확인하는 한 이동 잘못.

  • 문제 영역 주위에 풍부한 로깅을 사용하십시오. 이곳은 Log4J 또는 Log4Net과 같은 도구가 실제로 빛날 수있는 곳입니다. 해당 로깅 프레임 워크 및 이와 유사한 프레임 워크를 사용하면 구성 파일을 변경하여 모든 범주의 노이즈를 줄이면서 특정 범주에 대한 로깅을 설정할 수 있습니다. 의심스러운 것이 문제가 될 수 있는지 확인하기 위해 새로운 로깅 명령문을 도입하려고합니다. 또한 HTTP 액세스 로그에 각 요청에 대해 원하는 모든 정보 (쿠키, http 헤더 매개 변수 등)가 있는지 확인하십시오.
  • 문제를 시뮬레이션하려고합니다. 이 문제는 산발적으로 발생하기 때문에 서버가 발생할 당시의로드는 얼마입니까? 다양한 언어의 여러 동시 요청에 부딪 히고 있습니까? 그렇다면 테스트 환경에서 이러한 종류의로드를 시뮬레이션하십시오. JMeter와 유사한 도구가 필요할 수 있습니다. 가짜 클라이언트의 IP 주소를 스푸핑 할 수도 있습니다. IP 주소는 주소의 처음 두 세그먼트를 기반으로 IP가 어떤 국가 / 지역인지 파악할 수 있도록 나누어 져 있습니다.
  • 문제는 테스트 환경에서 산발적으로 발생하지만 실제 원인으로 범위를 좁 히면 결과가 왜곡 되어 야생에서 보다 자주 발생 합니다. 또한 로그 파일을보다 쉽게 ​​검토하고 그로부터 배우려고 시도 할 수 있습니다.
  • 반복적 인 과정이므로 인내심을 가지십시오. 버그를 재현하고, 로그를 확인하고, 찾은 내용에 따라 테스트를 구체화 할 것으로 생각 되는로드 유형을 유도 해야합니다. 중요한 것은 문제 를 식별하는 것이므로 실제 문제를 덜 자주 발생시킬 수있는 간단한 수정을하려는 충동에 저항하십시오.

마지막으로, 문제를 재현하는 방법과 그 원인을 알기까지 문제를 좁힌 후에는 코드에서 문제를 강제로 실행할 수있는 가장 작은 자동 테스트를 작성하십시오. 문제를 한 클래스로 좁히거나 한 쌍의 클래스가 올바르게 작동하지 않으면 해당 레벨에서 문제를 재현하십시오. 100 개의 스레드를 생성 할 필요가 없으며 100 %의 시간 동안 문제가 발생할 수있는 가장 작은 테스트 만 수행하십시오.

이제 당신은 그것을 고칠 수 있고 다시 물지 않을 것이라고 확신합니다.


10

버그는 생식 할 수 없습니다. 당신은 아직 그것을 재현하는 방법을 찾지 못했습니다.

Random () 문의 반환 값을 기반으로 예외를 throw하지 않으면 임의의 버그가 발생하지 않습니다.

나는 이것이 의미론처럼 보일 수 있다는 것을 알고 있지만 이것을 당신 자신에게 말하는 것은 정신적으로 안심입니다.

복잡한 경쟁 조건 등으로 인해 발생하는 버그를 재현하는 방법을 찾는 것은 매우 어렵고 실망 스럽습니다.

그것을 찾는 방법에 관해서는 더 많은 정보를 줄 수있는 곳에서 응용 프로그램에 로깅을 켜거나 추가 할 것입니다.

다음으로 버그를보고있는 사람들 (개발자, QA, 최종 사용자)에게 발생한 시간과 함께 버그를보고하자마자 로그를 확인하십시오. 다른 정보를 요청하거나 버그는 여러 다른 시스템의 상호 작용 또는 경쟁 조건 으로 인해 발생할 수 있습니다.

잘하면 당신은 리드를 찾을 수있을 것입니다.


Random () 호출조차도 하드웨어 화이트 노이즈 생성기에서 파생되지 않는 한 실제로 무작위가 아닙니다. 그것들은 의사 난수 (psuedo-random)이며, 이는 숫자가 가능한 임의의 순서로 수학적으로 분포됨을 의미합니다. 그러나 동일한 "종자"값에서 시작하면 매번 같은 대답을 얻게됩니다.
— Berin Loritsch

1
@Berin : 알고 있습니다.
— Gilles

"아직 재생산 방법을 찾지 못했습니다"+1 모든 버그는 근본 원인이 있거나 그렇지 않은 경우 발생합니다.
— Mike S

1
Random ()에서 벗어날 필요는 없습니다. 타이밍에 따라 달라지는 것, 특히 공유 리소스에 대한 부적절한 액세스와 관련된 것은 재생산하기가 매우 어려울 수 있습니다.
— Loren Pechtel

2
@Gilles : 합리적으로 측정 할 수있는 것은 결정적이지 않을 수 있습니다. (말은, 다른 작업은 그것의 타임 슬라이스를 발표 정확히 언제.)
— 로렌 Pechtel

5

코드에서 문제가 발생했음을 인식 할 수있는 위치 (예 : 메소드의 매개 변수가 일치하지 않음)를 찾은 다음 코드에 검사를 추가하고 스택 추적, 오브젝트와 같은 추가 정보를 디버그 로그에 추가 할 수 있습니다. 세션 등에 추가)

운이 좋으면이를 수행하여 발생에 대한 정보를 캡처하고 문제점으로 되돌아 갈 수 있습니다.


2

자동화는 실패한 경우를 재현하는 동일한 단계 인 경우 자동화하여 루프에 배치하는 데 도움이됩니다. 50,000 번 실행하면 발생할 가능성이 큽니다.


이벤트는 무작위가 아니라 무작위로 보입니다. 이렇게하면 나타날 수 있지만 그 이유 에 대한 정보는 거의 없습니다 .
— Josh K

1
@Josh-만약 그것을 재현 할 수 없다면, 이것은 디버그 심볼을 가진 스택 트레이스를 얻는 좋은 방법 일 수 있습니다. 나는 그것이 훌륭한 첫 걸음이라고 생각합니다-직접 보는 것
— Kieren Johnstone

스택이 있고 얻을 수 있다고 가정합니다. 그는 응용 프로그램에 대한 기술적 정보 나 이러한 종류의로드에서 디버깅을위한 접근성에 대한 기술 정보를 제공하지 않았습니다. 이것은 디버깅 전략 이 아니며, 그것이 깨지는 정확한 순간을 잡으려고 망치로 때리고 있습니다.
— Josh K

@Josh-실제 경험에 따르면 버그를 조사 / 수정하는 데있어 가장 중요한 것은 버그를 직접보고 있다는 것입니다. 타이밍이 보이는 것, 스택 추적, 로그에있는 것 또는 다른 것의 여부. 가능하면 루프에서 무작위로 발생하는 문제가 테스트되어 실제로 매우 빨리 도착했습니다. 다른 생각이 있다면, 그리스도를위한 답변으로 게시하십시오. 이것은 유효한 방법이며 올바른 답변입니다.
— Kieren Johnstone

나는 동의하지 않으며 베린의 대답은 이것을 해결하는 올바른 방법 이라고 생각 합니다.
— Josh K

1

이 문제가 발생하는 조건을 찾아내는 패턴을 찾으십시오. 그것은 실패하거나 일관성이없는 코드 부분으로 당신을 가리켜 야합니다.


아니 똥 ...........
— theringostarrs

0

문제 가 발생한 시기를 감지 할 수 있습니까 ? 그렇다면 해당 시점에서 시스템 상태에 대한 정보를 안정적으로 덤프 할 수 있습니까?

이 두 질문 모두에 대한 대답이 예인 경우, 실제로 오류가 발생할 때 최대한 많은 정보를 기록하도록 코드를 계측 한 다음 기다리십시오.

이것은 다른 사람들이 제안한 것을 대체하지는 않습니다 (여전히 코드가 현재 상태에 도달하는 방법을 통해 추론해야 할 것입니다).하지만 원하는대로 버그를 재현 할 수 없다면, 그것이 나타나는 경우를 낭비하지 않는 것이 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.