[번역] 테스터를 위한 디버깅

 

 

앨런 페이지가 쓴 “Debugging For Testers”를 번역했습니다.

 

테스팅 업계의 큰 화두인 “테스터가 코드에 대해서 얼마나 알아야 하는가?”라는 명제에 대한 앨런 페이지

 

개인의 답이기도 하면서, 제 개인적으로도 동의하는 의견인지라 흥미있게 읽은 포스트입니다.

 

실제로 크래시가 발생할 경우 콜스택을 활용해 수정 작업을 진행하고 있어서 제게는 더욱 의미가 있었던

 

포스트 같습니다.

 

번역 및 포스트에 대해서는 저자의 허락을 받았습니다.

출처: Tooth of the Weasel - Alan Page's blog

Debugging for Testers

Alan Page

최근 개인적으로 내게 경각심을 불러일으키는 말들을 자주 들을 수 있었다. 내가 들은 이런 말들의 요지는 한 마디로 ‘디버깅은 코더들을 위한 것이고, 테스터들은 단순히 이슈를 찾는 것 뿐’ 이라는 것이다. 이렇게 말하는 이유를 이해할 수 있다(아니면 적어도 최소한 이해한다고 생각한다). 나는 모든 테스터가 코더일 필요는 없다는 말에도 동의한다. 또한 모든 테스터들이 디버깅 마스터가 될 필요도 없다. 하지만 그 어떤 테스터도 디버깅을 두려워해서 이를 멀리해서는 안된다고 생각한다.

 

사실, 오히려 나는 모든 테스터들이 디버깅에 대해 최소한의 지식은 가지고 있어야 한다고 생각한다. 그들이 끝내주는 프로그래머이거나, 혹은 파트타임으로 일하는 IT 애플리케이션 테스터이던간에 상관없이 말이다.

 

자, 이제 시작해보자. 좀 짜증이 나면 더 길어질지도 모르지만…

여기부터다.

 

모든 테스터들이 디버깅에 대해서 알아야만 하는 것들

● 콜스택 – ‘콜스택(Call Stacks)’은 애플리케이션 크래시를 유발하는 일련의 기능들을 일컫는다. 각각의 다른 디버거들이 조금씩 다른 형태로 이를 보여주지만, 일단 대부분의 형태는 다음과 같다.

 

FunctionThatCrahsed

Function_Three

Function_Two

Function_One

 

아래부터 위로 읽으면 된다. Function_one 이 Function_Two 를 호출하고, Function_Two 가 Function_Three 를 호출하고, 마지막으로 Function_Three 가 크래시를 유발한 FunctionThatCrashed 를 호출하는 형식이다.

 

십중팔구 어떤 함수들이 이 목록에 있는지를 살펴보았다면, 그 다음으로 이 함수들의 파라미터에 대해 조사하게 될 것이다. 바로 이 파라미터 값들이 당신에게 문제를 푸는 실마리를 던져줄 것이다. 만약 당신이 개발자와 함께 일하는 환경에서 디버거에서 이런 크래시가 발견되고 콜스택이 남았다면, 이런 콜스택이야말로 당신이 테스트로서 개발자에게 제공할 수 있는 가장 중요한 정황 정보가 될 것이다.

 

● 크래시 vs. 어서트 – 프로그램이 갑자기 디버거를 띄울 때, 즉 프로그램이 실행을 중단하고 디버거가 갑자기 구동될 때, 이는 해당 프로그램에서 유효하지 않은 메모리를 대상으로 읽기/쓰기 행동을 시도하는 것과 같은  크래시가 발생했거나, 혹은 개발자가 심어놓은 브레이크포인트[1](주로 ‘어서트(assert)[2]’라고 불리우는 매크로)가 구동되었을 경우라고 보면 된다. X86/amd64 플랫폼에서는 디버거 상에서 int 3 혹은 int 2C 라고 표시된다. 어서트 형태로 에러가 표시되는 경우, 가장 주목해야 할 점은 바로 프로그램 실행을 중단시킨 이유가 아주 명백하다는 것이다. 최소한 당신이 코드를 볼 수 있다면 이는 더 명백해 질것이다. 실제로, 어서트는 다음과 같이 활용된다.

 

      bool bSuccess = CreateUserAccount();

      //break into the debugger of the call to CUA fails so we can debug

      ASSERT(bSuccess == true);

 

이런 상황에서 프로그램 실행이 중단되었을때, 테스터는 단순히 “로그온 도중에 프로그램에서 크래시가 발생했다”라고 말하는 대신에, “오늘 빌드의 CreateUserAccount 함수에서 오류가 발생해 어서트가 동작했다”라고 말할 수 있을 것이다. 두 문장 모두가 나름대로의 가치를 가지고 있지만, 후자가 좀 더 충실한 정보를 전달하고 있다는 것은 누구나 알 수 있을 것이다. 대부분의 경우 이 정보를 기반으로 당장 문제의 수정에 필요한 행동에 착수할 수 있을 것이다.

 

● 기본적인 단어들 – 크래시의 기본적인 형태 몇 가지에 대해서는 반드시 알고 있어야 한다. 예를 들어, 접근 오류(AV; Access Violation), 스택 오버플로우(Stack Overflow), 버퍼 오버런(Buffer Overrun) 등의 크래시와 이를 유발하는 원인에 대해 잘 알고 있어야 한다. 즉 잘못된 메모리 주소를 읽어들인다든지, 일반적으로 루프가 잘못 되어 발생하는 너무 많은 함수를 호출하는 경우, 혹은 버퍼에 너무 긴 스트링을 넣는 것들이 크래시를 유발한다는 것을 인지하고 있어야 한다.

 

당신이 전문가가 될 필요는 없지만, 여기 적어놓은 몇 가지 지식들이야말로 버그를 분석하고 이를 수정하게 되는 길고 긴 여정의 출발점이 되는 것이다.

 

지금 당장 생각해보면 이 정도면 일단 충분할 것 같다. 하지만 충분히 많은 것을 다룬 것은 아니다. 아직도 배워야 할 것들은 더 많이 남아있고, 지금 이야기한 것들은 프로페셔널 테스터가 되기 위해 알아야 하는 최소한의 것에 지나지 않는다.

 

더 좋은 아이디어들이 있다면 코멘트에 추가해주길 바란다.   

 

---

[1] 역자 주: 프로그램에서 디버깅을 목적으로 프로그램의 실행을 내부적으로 멈추게 하는 지점을 의미한다.

위키피디아 ‘breakpoint’ 참조.

 

[2] 역자 주: Hermet님의 블로그 ‘길고 긴 모험’의 assert문 사용하기 참조.