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

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

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

답변