버그 조사 학습 [폐쇄]

이 어려움을 어떻게 정의해야할지 잘 모르겠습니다. 그것은 직장을 구하기 전에 두 명의 예비 직원이 나에게 한 시험을 상기시킵니다. 그들은 방에서 물건을 고른 다음 그 물건이 무엇인지 결정하는 데 도움이되는 질문을 할 수 있습니다 (20 질문과 거의 비슷). 나는 이것에 엄청나게 능숙했습니다 (아니, 겸손에 대한 높은 점수를 얻지 못했습니다). 그래서 나는 버그 문제 해결에 정말로 능숙하다고 가정했습니다 ...

그러나 최근에 내가 알아 낸 것이 있습니다. 나는 그 상황에 정말 좋습니다. 방에있는 모든 것을 실제로 쉽게 볼 수 있기 때문에 구성 요소 부분에 대한 개념으로 내 문제에 접근 할 수 있습니다. 본질적으로 나는 "내가 모르는 것을 안다". 그러나 프로그래밍을 통해 문제가 완전히 알려지지 않은 많은 상황이 발생합니다. 나는 그것이 깨 졌다는 것을 알고 있지만 그것이 어떻게 부서 질 수 있는지에 대한 개념이 없다. 나는 모든 지침을 따랐으며 기술을 상당히 잘 알고 있습니다 ...

내가 정직하다면, 나는 틀릴 수있는 것을 상상하는 데 어려움을 겪고 있다고 느끼기 때문에 그것을 테스트하고 해결책을 찾을 수 있기를 바랍니다.

그 기술을 개발하려면 어떻게해야합니까? 상상력이 부족한 내 상상력이 내 프로젝트가 깨질 수있는 방법을 생각해 내려면 어떻게해야합니까? 나를 더 잘하게 할 수있는 운동이 있습니까 (퍼즐?)? 아마도 가장 큰 치료법은 단지 경험 일 뿐이라는 것을 알고 있습니다. 그러나 가능하다면 프로세스를 가속화하기를 희망합니다. 한 번에 몇 시간 동안 내 컴퓨터 화면을 공백으로 쳐다 보는 것은 그리 재미 있지 않습니다 ...

소프트웨어의 모든 결함은 궁극적으로 가정과 현실의 불일치로 인한 것입니다. 교활한 버그는 특히 심오한 가정과 현실 사이의 불일치입니다. 버그를 진단하는 능력은 자신의 가정에 의문을 제기 할 수있는 능력에 달려 있으며, 실제로 어떤 것을 알지 못한다 는 인식이 필요 합니다. 방금 버그를 가정하고 지금까지 사용하고있었습니다.

무역 도구, 로그 파일, 디버거 등의 도구는 이러한 가정을 밝혀 내고 실제 모델과 실제 시스템을 다시 정렬하는 데 도움이됩니다. 그러나 "포괄적 인 입력 확인 기능이 있기 때문에 입력이 잘못 될 수 없습니다"와 같은 중요한 가정에 의문이 생길 때까지 전체 시간을 시스템의 잘못된 부분을 확인하거나 다른 곳을 알지 못하는 경우 처음에.

상상력이 부족한 내 상상력이 내 프로젝트가 깨질 수있는 방법을 생각해 내려면 어떻게해야합니까?

대부분의 경우, 나는 아무 말도하지 않을 것입니다. 프로그램을 중단시킬 수있는 것들을 꿈꾸지 마십시오. 당신은 체계적으로 무엇을 결정해야 한다 부러 원인.

다음 정보를 사용하여 디버깅 프로세스를 진행해야합니다.

• 수행 된 단계 및 버그를 생성하기 위해 입력 한 값
• 단계와 입력이 주어질 때 프로그램이 해야 할 일;
• 단계와 입력이 주어지면 프로그램 이 수행하는 작업.

오류 메시지가 있으면 가능한 모든 정보를 얻으십시오. 오류 메시지 자체가 명확하지 않고 실제로 의미가 무엇인지 모르는 경우 (일부 오류 메시지가 항상 유용하지는 않음) Google 또는 StackOverflow 또는 기타 온라인 리소스를 사용하여 관련 정보를 찾으십시오. .

프런트 엔드에 오류 메시지가 표시되지 않으면 버그를 재현 한 기간 동안 응용 프로그램에서 오류 메시지를 기록하는 로그를 확인하십시오. 코드가 완료되기까지 실행되었을 수 있지만 최종 결과를 버리고 로그에 항목을 생성하는 방식으로 처리되는 예외가 발생했습니다. 그것들을 찾아서 위와 동일하게 수행하고 그들이 의미하는 바를 정확히 식별하십시오.

코드에 의해 예외가 제공되고 스택 코드가있는 경우 언급 된 코드 행을 확인하십시오. 라인 자체가 실제로 문제를 일으키는 것은 아닐 수도 있습니다. Java 코드 조각에서 NullPointerException이 발생하면 스택 추적은 예상하지 않았을 때 널이었던 것을 사용하려고 시도한 위치를 알려줍니다. 정확히 문제를 일으키는 줄을 가리 키지는 않지만 일반적으로 예상되는 값이없는 변수를 알려주므로 해당 변수에 대한 참조 / 할당을보고 값을 결정할 수 있습니다 설정되지 않았거나 값이 잘못 설정되었습니다.

그 중 아무것도 도움이되지 않으면 디버거를 시작하십시오. 코드를 문제의 원인으로 알고있는 코드 섹션으로 좁혔지만 정확히 어떤 줄을 모르는 경우에는 해당 단계를 수행하십시오. 그렇지 않은 경우 전체 단계를 수행하십시오. 여기에서는 주어진 입력으로 프로그램이 무엇을해야하는지 정확히 알아야합니다. 각 줄 다음에 각 값을보고 원하는 값에서 벗어난 위치를 정확하게 결정해야하기 때문입니다.

아직도 문제가 무엇인지 전혀 알지 못합니까? 누군가에게 도움을 요청하십시오 . 동료, 친구, 온라인 커뮤니티. 방금 수행 한 모든 작업을 보여주십시오. 오류 메시지, 스택 추적을 보여주고 프로그램이 일반적인 용어로 무엇을하는지 (아직 알지 못하는 경우),이 특정 인스턴스에서 수행해야 할 작업 (예 : 값 4 반환), 실제로 수행중인 작업 (예 : 값을 반환 5). 디버거에서 몇 줄의 코드로 좁힌 경우 "문제가 코드에서이 줄로 인해 발생한다는 것을 알고 있습니다. Y 여야 할 때 값을 X로 설정하지만 볼 수 없습니다. 왜 그런 일이 일어나는지 "

화면을 멍하니 쳐다 보면서 몇 시간을 보내는 것은 확실히 재미가 없지만 그렇게해야 할 이유는 없습니다. 코드에 문제가있는 경우 코드를 읽거나 단계별로 실행해야합니다.

어느 정도는 형사 사건이나 마음을 사로 잡는 퍼즐을 조사하는 것과 같습니다.

첫째, 당신은 피해자를 얻었다. 사건을 잠시 조사한 후, 몇 명의 용의자를 확인하고 피해자가 정확히 어떻게 살해 될 수 있는지에 대한 작업 가설을 개발했습니다. 계속해서 조사하고 더 유용한 정보를 찾고 문제의 실제 원인에 더 가까이 다가 가도록합니다.

때때로 당신은 막 다른 길로 들어갑니다 (말장난 의도). 그것은 당신이 가능한 한 빨리 자신을 회복시킬 수 있다면, 그것의 일부이며, 아무런 문제가 없습니다. 핵심은 항상 다음에 어떤 정보가 필요한지에 대해 생각하고 가설을 제공하거나 추가 정보를 제공하는 것입니다. 그런 다음 그 정보를 효율적으로 얻는 방법을 찾고, 결론을 내리고, 유죄를 선고받을 수있을 때까지 계속하십시오.

때로는 범인을 발견하는 데 필요한 모든 사실과 징후가 이미 30 분 전에 당신 앞에서 기다리고 있었다는 것을 알고 있습니다. 성가신 일이지만, 가장 흥미로운 부분 중 하나 입니다. 행동과 실수를 비판적으로 검토 하면 배우고 더 나아질 수 있기 때문 입니다. 다음과 같은 질문을 해보십시오.

• 이 시간 낭비를 어떻게 피할 수 있었습니까?
• 처음에 무엇을 간과 한 이유는 무엇입니까?
• 내가 어떤 검증되지 않았거나 잘못된 가정에 의존 했습니까?

이것은 당신의 능력을 훈련시킬 것입니다. 그것은 또한 직감을 본능적으로 발전시킬 것이므로 시간이 지남에 따라 너무 쉽게 간과되는 모든 사소한 것들을 자동으로 인식하여 정답을 더 빨리 이끌어내는 법을 배웁니다. 결국, 그것은 의도적 인 연습 에 관한 것 입니다.

마지막으로 셜록 홈즈가 우리에게 가르친 것을 항상 기억하십시오. 불가능한 것을 제거했을 때, 남아있을 수는 있지만 불가능한 것은 진실이어야합니다.

상상력이 부족한 내 상상력이 내 프로젝트가 깨질 수있는 방법을 생각해 내려면 어떻게해야합니까?

역사가 당신의 가이드가되게하십시오. 프로젝트가 잘 관리된다면 버그 발견 방법, 재현 방법, 분석 방법 및 수정 방법에 대한 분석과 함께 제품에서 수정 된 모든 버그에 대한 데이터베이스가 있어야합니다 . 이것은 쓰기 전용 데이터베이스가 아닙니다. 데이터베이스를 읽으면 곧 버그 분류가 발생하기 시작합니다.

그것은 당신에게 당신의 제품에 잘못 된 것들의 종류에 대한 좋은 개요를 제공합니다. 모든 종류의 소프트웨어, 특히 보안에 영향을 미치는 결함에 중점을 둔 문제에 더 일반적으로 관심이 있으시면 CWE 목록을 참조하십시오. http://cwe.mitre.org/data/index.html

따라서 특정 결함을 재현하고 수정하려고 시도하는 대신 제품을 조사하는 데 사용할 수있는 새로운 테스트를 생각해볼 필요가 있다고 생각합니다. 예를 들어 특수 문자를 입력하면 어떻게됩니까? 페이지의 비밀번호를 신청하거나 데이터베이스에 쓰는 동안 프로그램을 강제로 닫으면 어떻게됩니까? 이러한 경우는 실제로 생각하기 어렵다.

지난 10 년 동안 소프트웨어 개발 (Agile / XP / TDD 등)은 명시 적 요구 사항 만 충족 한 다음 기능을 완료 한 것으로 선언하고 무언가를 깰 수있는 모든 가능한 방법을 찾지 못한 채 가치를 얻게되었습니다. NASA에서 일하거나 백모 보안을 수행하지만 사용자 스토리의 수용 기준에서 그러한 것들을 불러야 할 경우가 있습니다).

따라서 기능에 입력, 성능 특성, 사용자 워크 플로 작업 등을 처리하는 방법과 같이 시스템이 수행해야하는 작업을 수용 기준으로 명시 적으로 나열한 경우 테스트를 확인해야하는 전체 목록이 제공됩니다. 요구 사항이 충족되었는지 검증하기 위해 테스트를 수행해야하며이를 수행하는 가장 좋은 방법은 모든 요구 사항을 명시 적으로 나열하는 것입니다. Agile Test Quadrants를 살펴보십시오 .

어떤 사람들은 이러한 테스트가 요구 사항을 명시 적으로 선언하도록 요구합니다. 요구 사항을 코드 앞에 작성해야합니다.

그러나 시작하기 전에 자체 개발 모범 사례를 설정하고 소프트웨어가 작성된 후 '테스트'하라는 요청을받은 후에 시작하는 새로운 프로젝트를 고려하고있는 것처럼 들리지 않습니다. 이것은 실제로 더 도전적이지만 동일한 원칙이 적용되며,해야 할 일을 알고 나면 테스트 할 수 있습니다. 개발 팀이 충족해야 할 포괄적 인 요구 사항 목록이없는 경우 질문을하는 것이 최선의 방법입니다. 팀에 따라 소프트웨어 시스템을 구축하기 전에 요구 사항을 명시 적으로 나열하지 않은 사람들은 자신이 놓친 내용을 상기시키지 않지만이 작업을 잘 수행하는 것이 필수적이므로이 작업은 정교하게 수행해야합니다.

요구 사항을 찾은 후에는 강력하고 안전해야합니다. 그런 다음 더 깊이 파고 들어가서 얼마나 안전해야하는지 또는 얼마나 많은 실패를 수용 할 수 있는지 알아 내십시오. 응용 프로그램의 요구 사항으로 또는 보안 비용을 지불하려는 보안 수준. 어떤 유형의 보안 공격을 방어하거나 사용하기 쉬워야 하는지를 명확하게 파악할수록 더욱 명확 해집니다. 그런 다음 일부 도메인 지식은 보안, 디자인, 성능 등에 유용합니다. 여기서 팀이나 SE 또는 Google / 도서에서 찾을 수있는 전문가에게 더 많은 질문을 할 수 있습니다.