재현하지 않는 버그로 무엇을해야합니까?

테스트하는 동안 오류가 발생하지만 (지금까지는) 오류가 발생하는 테스터가 있지만 즉시보고합니다. 그런 다음 우리 (개발자)는 테스터가 문제를 재현하려고 시도하지 않았으며 (요청시) 다시 일어날 수있는 방법을 찾을 수 없다는 것을 알게되었습니다.

이제 이것들은 여전히 ​​버그이며 무시하고 싶지 않습니다. 그러나 재현 단계가 없으면 나는 붙어 있습니다. 때때로 스택 트레이스가 있습니다 (단순한 프레임 워크이고 행 번호가 없기 때문에 유용하지는 않습니다). 그러나 스택 추적을 사용하여 코드를 열어서 추측하기 시작할 수는 있지만 테스트 가능한 "수정"으로 이어지지는 않습니다.

이와 같은 시나리오에서 무엇을합니까?

문맥이없는 버그는 버그가 아니라 우연입니다. 문제는 코드, 타사 라이브러리, 하드웨어 또는 단일 비트로 인해 자체 비트가 발생하는 태양 복사 일 수 있습니다. 최소한 일정한 규칙으로 그것을 재현 할 수 없다면 ( "10 ~ 20 회에 한 번만 X를한다"고해도) 테스터가 "어딘가에 문제가 생겼다-고쳐라"고 말하는 것이 나쁘지 않다. .

테스터에게 그의 일이 문제가 생길 때까지 입력을 생성하는 것이 아니라고 설명해야 할 수도 있습니다. 그렇다면 난수 생성기로 대체 할 수 있습니다. 그의 임무 중 하나는 버그를 식별하는 것이며 버그를 생성하는 방법을 식별하는 것입니다.

궁극적으로 개발자 나 테스터 중 어느 누구도 버그를 재현 할 수 없다면 닫혀 야하지만 그렇게 표시되어야합니다.

그러나 그 시점까지 걸리는 시간은 논쟁의 여지가 있습니다.

어떤 사람들은 그것이 즉시 재현 할 수 없다면 닫혀 져야한다고 주장 할 것입니다.

나는 보통 문제의 발신자로부터 더 많은 정보를 얻으려고 노력합니다. 원본 보고서에 잊어 버린 내용이있을 수 있습니다. 필요한 단계에 대해 대화하면 누락 된 정보가 드러날 수 있습니다.

하나의 마지막 생각- "reprore"로 폐쇄되었다고 해서 고정 된 것은 아닙니다 . 실제 문제가있는 경우 조만간 공개되며 문제를 최종적으로 재현 할 때 도움이 될 수있는 모든 정보가 있습니다.

몇 가지 제안 :

1. 제품 코드에 로깅 (키로거 :}이 아닌)을 추가하십시오. "반복 없음"버그는 우연 일 수 있지만, 예상치 못한 방식 (예 : 고객 컴퓨터)으로 사용되는 더티 시스템에서만 발생하는 메모리 또는 상태 손상일 수 있습니다. 로그인 또는 정보를 추적하면 알아낼 도움이 될 수 있습니다 테스터는 우연을 발견했을 때하고 잘못이있다.

2. 데이터베이스의 나머지 "repro"버그를 스캔하십시오 (또는 버그 추적에 사용하는 모든 것). 종종, 플럭은 제품의 한 영역에서 서로 뭉칩니다. 하나의 구성 요소에 결함이있는 것 같으면 코드에서 구성 요소에 결함이 있는지 검토하고 해당 구성 요소에 로깅을 추가하십시오 (또는 둘 다).

3. 30 분 정도 걸리고 테스터 테스트를보십시오. 그들의 접근 방식은 무엇이 잘못되었는지에 대한 아이디어를 줄 수 있습니다 (예 : "흥미로운-나는 당신이 그런 방식으로 대화에 접근 할 수 있다는 것을 몰랐습니다"). 또한 대화 상자 나 구성 단계를 실수로 건너 뛴다는 것을 알 수 있습니다. 그들의 머리에 조금 투자하는 것은 시간 투자의 가치가 있습니다.

큰 상용 코드로 QA를 수행하는데,이 자극적 인 시나리오는 너무 자주 발생합니다. 일반적으로 우리가 지원하는 모든 플랫폼에서 바이너리를 빌드하기위한 철통 절차가 없음을 나타냅니다. 따라서 개발자가 자신의 코드 (디버그 및 수정해야 함)를 작성하고 동일한 빌드 절차를 따르지 않으면 시스템 종속 버그가 마술처럼 사라지는 것처럼 보일 수 있습니다. . 물론 이런 것들은 대개 버그 데이터베이스에서 "works for me"로 닫히고 다음에 문제가 실행될 때 실패하면 버그를 다시 열 수 있습니다. 버그가 시스템에 의존적이라고 생각 될 때마다 다양한 플랫폼에서 버그를 테스트하고 어떤 조건에서 발생하는지보고하려고합니다. 종종 손상된 데이터가 크래시를 일으킬 정도로 큰 경우 메모리 손상 문제가 나타납니다. 일부 플랫폼 (HW 및 OS 조합)은 실제 손상의 원인에 가깝게 충돌 할 수 있으며이를 디버깅해야하는 가난한 사람에게 매우 유용 할 수 있습니다.

테스터는 자신의 시스템에 장애가 있음을보고하는 것 외에도 부가 가치를 추가해야합니다. 나는 오 탐지를 찾아내는 데 많은 시간을 할애합니다. 문제의 플랫폼이 과부하되었거나 네트워크에 결함이있을 수 있습니다. 그리고 때로는 임의의 타이밍 이벤트에 의해 실제로 영향을받는 것을 얻을 수 있습니다. 하드웨어 버그는 종종 예와 같습니다. 두 개의 데이터 요청이 정확히 동일한 클럭 주기로 되돌아오고 잠재적 충돌을 처리하기위한 하드웨어 논리에 결함이있는 경우, 버그는 간헐적으로 만 나타납니다. 병렬 처리와 마찬가지로 신중한 디자인으로 솔루션을 더 빠른 프로세서와 독립적으로 제한하지 않는 한, 블루 문에서 한 번만 발생하는 버그를 얻을 수 있으며 통계 불일치로 인해 악몽을 디버깅합니다.

또한 우리 코드는 일반적으로 매일 여러 번 업데이트되며 남쪽으로 갈 때 정확한 소스 코드 개정 번호를 추적하면 디버깅에 매우 유용한 정보가 될 수 있습니다. 테스터는 디버거 및 개발자와 적대 관계를 맺어서는 안되며 제품의 품질을 향상시키기 위해 팀의 일원으로 있습니다.

재현 할 수없는 두 종류의 버그가 있습니다.

1) 테스터 (또는 사용자)가 한 번 본 적이 있지만 재생산 할 수 없거나 재현하지 못한 것.

이러한 상황에서는 다음을 수행해야합니다.

• 결함을 보여주는 기본 조치 과정을 아주 간단히 점검하여 결함을 재현 할 수 없도록합니다.

• 테스터 / 사용자에게 말하면 도움이 될만한 다른 정보가 있는지 확인하십시오.

• 여러 인스턴스를 기반으로 결함을 조사하기에 충분한 정보가 있는지 확인하기 위해 관련된 다른 결함과 상호 참조하십시오. 이 한 가지 문제만으로도 충분한 정보를 얻지 못하지만 다른 여러 가지 문제와 함께 조사 할 때 가치가없는 것을 제안 할 수도 있습니다.

• 그래도 계속 진행할 수 없다면 정보가 충분하지 않다는 것을 사용자 / 테스터에게 설명해야합니다. 충분한 정보가 어떻게 보이는지, 왜 필요한지 정중하게 설명하십시오.

2) 안정적으로 재현 할 수 없지만 결함이 있음을 암시 할 수있는 충분한 증거 (반복 발생에 대한 증거)가있는 경우 개발자 문제이며 개발자가 테스터가 지원한다는 것을 알 수 있습니다 / 사용자-조사해야합니다.

이것은 느리고 고통 스러울 수 있습니다. 코드를 걷고, 더 많은 로깅을 추가하고, 데이터를보고, 테스터 / 사용자에게 깊이 이야기해야하지만 가능성이 있음을 암시할만한 충분한 증거가있는 경우 는 소유권을 가져 와서 해결하기 위해 수행해야하는 모든 문제입니다.

이것은 상대적으로 자주 발생하는 것처럼 들립니다. 대부분의 버그가 실제로 재현하기가 어렵거나 그가 시도하지 않은 다른 이유 때문입니까? 그가 왜 문제를 재현하려고하지 않는지 아십니까 ? 그가 당신에게 그것이 얼마나 중요한지 몰랐기 때문입니까? 아니면 다른 압력이있을 수 있습니다. 예를 들어, 테스트 관리자가 할당 된 테스트를 빠르게 통과하고 버그를 벽에 던지기를 원하는 테스트 관리자입니까? 아니면 어쩌면 그는 그것에 대해 어떻게 해야할지 잘 모르겠습니까?

더 나은 로깅 작업이 우선이라는 다른 사람들의 의견에 동의합니다. 그동안 테스터 기술 / 자신감 부족이 문제가 될 수 있다고 생각되면 대니 패트 (Danny Faught)의 버그 격리에 대한 기사를 정말 좋아합니다 .

문제가 경영 압력으로 인한 것으로 판명되면-특히 테스터와 프로그래머가 다른 관리자에게보고하고 관리자가 다른 팀을 "도우려는"경향이없는 경우 내 동정심이 있습니다.

일반적으로 재현 할 수는 없지만 테스트 또는 반복 배치가 완료 될 때까지 열어 두십시오.

해당 지점에서 재생산되지 않은 경우 닫히지 만 다시 발견되면 다시 열 수 있습니다.

이 테스터 워크 스테이션에 키로거를 설치하십시오!

첫 번째 과제는 재현 가능한 테스트 시스템을 갖추는 것입니다. 테스터 는 잘 정의 된 프로세스를 갖추어야합니다. 가능하면 자동으로 수행하십시오.

이 세 가지 조건이 있습니다.

• 동일한 바이너리
• 같은 단계
• 같은 기계

위의 3 가지 조건에서 버그가 산발적으로 나타나면, 더 이상 격리를 시작하십시오. 시스템 스택의 각 레벨과 구성을 고려하십시오.

메모리 관리 오류를 감지하는 한 가지 방법은 여러 컴파일러가있는 여러 OS에서 프로그램을 실행하는 것입니다. Valgrind도 도움이 될 수 있습니다.

그러나 일반적으로 병렬 시스템은 재현 할 수없는 버그를 유발할 수 있습니다. 버퍼 크기 및 처리 속도, 비동기식, 데이터베이스 잠금, 가변 메모리 쓰기 인터리빙과 같은 것들; 모든 문제가 발생할 수 있습니다. 등등.

우선, 엄격한 테스트 절차를 거쳐야합니다 (그러나 회사에서는 귀하가 설명한 내용이 자주 발생 함을 이해합니다).

버그의 심각성에 따라 재현 단계가 제공 될 때까지 시간을 투자하거나 무시할 수 있습니다.