소프트웨어를 테스트 하는 일은 매우 노동 집약적이고 많은 시간을 필요로 하는 작업이다. 프로젝트 진행 중의 마일스톤마다 테스트를 반복해야 하며, 그 각각의 과정은 대충 넘어 갈 수가 절대 없다. 가볍게 생각하고 넘어 갈 경우 거의 언제나 문제를 일으키며, 심각한 경우에는 기업의 존속이 위협 받을 수도 있기 때문이다.
소니의 경우 휴대폰의 소프트웨어 결함으로 인해 큰 타격을 입었고, 결국 에릭슨과의 합작을 진행하게 되었던 전례가 있다. 또한 얼마 전에는 한 고등학생이 국내의 모 대기업을 휴대폰 소프트웨어의 결함과 과장 광고로 고발하여 화제가 되었던 일도 있었고, 작년에는 한 인터넷 서점의 시스템 개편시 다양한 문제가 발생하여, 고객들의 원성을 사기도 했었다. 이 외에도 소프트웨어의 문제로 인해 차량이 출발을 못 했다거나, 열차 사고가 발생 할 뻔 했다던가 하는 다양한 사고 사례가 있다.
물론 위와 같은 경우는 좀 심한 경우이기는 하다. 하지만 소프트웨어의 결함이 최소한 고객의 신뢰를 떨어 뜨리기에는 충분하다는 것은 확실하다. 그렇기에 소프트웨어의 철저한 테스트는 매우 중요하다.
우리는 이전의 연재에서 비주얼 스튜디오 팀 시스템의 다양한 테스트 기능을 살펴 보았다. 그러한 테스트들은 자동화가 가능하며, 회귀 테스트의 반복적 수행을 가능하게 해 주었다.
하지만 자동화하여 테스트 하기가 곤란한 경우가 존재한다. 화면에 출력 되는 문구 및 안내가 정상적인지, 사용성은 충분한지와 같은 부분은 기계가 판단 할 수 없다. 또한 큰 트랜잭션을 수행하는 도중에 전원이 꺼진다거나 하는 경우 역시 자동화하여 테스트하기는 상당히 어려운 부분이다.
이러한 테스트는 결국 사람이 수작업으로 진행해야 하며, 이를 위해 비주얼 스튜디오 팀 시스템은 매뉴얼 테스트 기능을 제공하고 있다. 어떠한 기능을 제공하는지 살펴 보자.
기계로는 테스트 할 수 없을 때.. - 매뉴얼 테스트
필자는 처음 매뉴얼 테스트 기능이 포함 된 것을 보았을 때 상당히 궁금했다. 테스트 자체가 사람에 의해 직접 수행 되는데 도대체 어떤 기능을 제공한다는 것일까? 우선 매뉴얼 테스트의 진행 과정을 살펴 보자.
새로운 테스트를 추가하면 다음과 같은 화면에서 매뉴얼 테스트를 선택 할 수 있다.
빨간 사각형 안에 포함된 항목이 매뉴얼 테스트로, 항목을 선택하면 텍스트, 또는 워드 포맷의 문서 파일이 생성된다.
생성된 문서는 하나의 템플릿으로서 어떻게 작성해야 하는지에 대한 간략한 설명이 제공된다. 그리고 테스트의 제목, 상세 설명, 테스트 대상, 테스트 진행 순서, 버전 정보 등을 기록할 수 있게 되어 있다.
각각의 테스트 케이스에 맞게 내용을 정확히 입력하고, 테스트를 수행하면 다음과 같은 화면을 볼 수 있다.
화면의 하단을 보면 테스트 할 항목에 대한 내용이 나타난다. 테스터는 이 문서의 내용을 보면서 테스트 진행 순서(Test Step, 테스트 시나리오라고도 부른다)에 적혀 있는 대로 테스트를 수행한다. 그 결과를 Pass, Fail로 기록하고, 문제가 있는 경우 해당 내용을 Comments에 기록 한 후 다음 테스트를 진행한다. 이렇게 테스트 한 결과는 저장 되어 추후 언제든 재확인이 가능하다.
즉 비주얼 스튜디오 팀 시스템의 매뉴얼 테스트 기능은 테스터들에게 테스트 할 내용을 보여 주며, 테스트의 수행 결과를 기록/보존 할 수 있는 환경을 제공한다.
겨우 이게 다야?라는 생각을 할 수 있지만, 기존의 테스트 진행 방식을 생각하면 제법 편한 기능이라고 볼 수 있다. 일반적으로 테스터들은 테스트 할 내용을 엑셀 문서에 정리하여 출력한 후, 해당 내용을 테스트하고 그 결과는 별도의 트랙킹 시스템에 입력 하는 경우가 많은데, 이러한 일련의 작업을 한 화면에서 간편히 진행 할 수 있다는 것은 꽤 편리하다. 또한 이렇게 수집된 결과는 누적되며 여러 용도로 재활용 될 수도 있다. 물론 매뉴얼 테스트의 용도만으로 사용하기엔 비주얼 스튜디오 팀 시스템이 좀 무겁다는 것도 사실이지만 말이다.
코드들은 과연 전부 테스트 되었을까? - 코드 커버리지
지금까지 이야기 된 다양한 테스트들을 수행 할 때, 여러 의문이 생길 수 있다. 현재의 테스트 방법으로 과연 모든 코드를 테스트 한 것일까? 혹시 테스트 케이스에 누락 된 부분이 있지는 않을까?
소프트웨어 프로젝트가 복잡해지고 규모가 커짐에 따라, 포함하는 기능의 수는 급격하게 늘어났다. 대형 프로젝트의 경우 수 만에서 수 십만에 이르는 코드를 가지는 경우도 있다. 이 코드 안에는 수 없이 많은 조건 분기가 있을 것이며, 매우 복잡한 단계를 거쳐 서로 호출하고 있을 것이다. 조건 분기의 오류에 의해 절대 수행 되지 않는 코드가 포함되어 있을 수도 있으며, 모든 경우를 다 테스트 했다고 생각했지만 내부적인 조합에 의해 테스트 되지 않고 누락 되는 경우가 생길 수도 있다. 우리가 진행 중인 테스트는 모든 코드를 검증하고 있다는 것을 어떻게 알 수 있을까?
이러한 의문을 해소하기 위한 기능이 코드 커버리지 기능이다. 코드 커버리지란 소스 코드의 얼마나 많은 부분이 테스트 되었는가를 의미하는 용어이다.
코드 커버리지를 사용하기 위해서는 .testrunconfig 파일을 열어 옵션을 수정해야 한다. 솔루션 익스플로러에서 Solution Items로 등록 되어 있는 testrunconfig 파일을 열면 다음과 같은 화면을 볼 수 있다.
이 대화상자를 통해 테스트 수행에 필요한 다양한 설정을 할 수 있다. 좌측의 항목을 살펴 보면 Code Coverage 항목이 있음을 알 수 있다. 이 화면에서 어떠한 DLL 또는 실행 파일이 테스트에 사용 될 것인지를 결정 한다.
비주얼 스튜디오 팀 시스템의 코드 커버리지는 사용 되는 DLL, 실행 파일의 호출 내역을 감시함으로써 진행된다. 그러므로 코드 커버리지 정보는 유닛 테스트, 매뉴얼 테스트, 웹 테스트 등의 모든 테스트에서 추출 될 수 있다. 단 로드 테스트의 경우에는 가능한 실제 시스템과 동일한 상황을 시뮬레이션 하는 것이 목적이므로, 추가적인 부하가 가해지는 코드 커버리지를 적용하지 않는 것이 좋다.
코드 커버리지에 사용 할 파일을 모두 지정 한 다음, 테스트를 수행하면 각 DLL별로 어느 정도의 코드가 테스트 되었는지를 테이블로 표시해 준다. 테스트 된 부분과 테스트 되지 않은 부분을 항목의 개수와 퍼센트로 출력해 주기 때문에, 이 결과를 바탕으로 테스터는 테스트 케이스에 헛점이 있거나 애플리케이션 로직에 문제가 있는지를 파악 할 수 있다.
또한 검사 된 항목을 더블 클릭하거나, 컨텍스트 메뉴에서 Go to source code 를 선택하면, 해당 코드에서 검사된 부분과 검사 되지 않은 부분을 시각적으로 파악 할 수 있다. 이는 매우 훌륭한 기능으로 현재의 테스트를 통해 검사 되지 않는 부분을 쉽게 알 수 있다. 왜 해당 부분이 검사되지 않았는가를 추적하면 테스트 케이스의 누락 된 부분이나 조건 분기의 오류를 쉽게 파악 할 수 있으므로, 이 또한 잠재적 버그를 발견해 낼 수 있는 기능이라 볼 수 있을 것이다.
하지만 모든 코드에 대해 유닛 테스트를 수행하고 100%의 코드 커버리지를 달성했다고 해도, 오류가 발생 할 확률이 완전히 사라진 것은 결코 아니라는 것을 명심해야 한다.
유닛 테스트의 리뷰에서 이야기 했던 것처럼 전체 오류 중 25%만이 단일 모듈에서 발생하는 오류이며, 나머지는 필요한 로직이 누락 되었거나 로직이 결합 될 때 발생하는 오류이다. 그러므로 아무리 코드 커버리지의 결과가 좋게 나왔다고 하여도, 코드에 대한 집중적인 리뷰 및 인스펙션을 생략해서는 안 될 것이다.
통합 테스트 자동화 아쉽다
매뉴얼 테스트는 기계에 의한 자동화로는 테스트 할 수 있는 영역의 테스트를 지원해 주고 있다. 상당히 단순하게 구성 되어 있지만, 편안한 테스트 환경을 제공하며 결과를 취합하여 여러 용도로 재활용 할 수 있다는 점을 강점으로 꼽을 수 있을 것이다. 그리고 특정한 상황에서는 테스터들이 가장 많이 사용하는 기능이 될 수 있다는 점에서 중요하다 할 수 있겠다. (특히 현재까지는 윈폼 기반의 애플리케이션을 자동화 하여 테스트 할 수 없다는 점에서 더욱 그러하다)
또한 코드 커버리지는 매우 잘 구성되어 있고, 테스트가 진행 된 코드의 영역을 쉽게 파악 할 수 있게 해 준다. 그로 인해 테스트는 좀 더 정밀 해 질 수 있으며, 로직상의 죽은 코드(절대 실행되지 않는 코드)나 오류를 쉽게 발견 할 수 있다. 시각적으로 한 눈에 알아 볼 수 있도록 표현 해 주는 기능은 정말로 멋지다.
하지만 비주얼 스튜디오 팀 시스템의 테스트 기능에는 정말로 아쉬운 점이 있다. 그것은 윈폼 기반의 애플리케이션에 대한 통합 테스트를 자동화 하여 수행 할 방법이 없다는 것이다. 현재 제공되는 비주얼 스튜디오 팀 시스템의 테스트로는 유닛 테스트와 매뉴얼 테스트만이 수행 가능하다.
물론 윈폼 기반의 애플리케이션을 자동화하여 테스트 한다는 것은 웹 애플리케이션을 테스트 하는 것 보다는 훨씬 어려운 일이다. 마우스 포인터의 이동을 감지해야 하며, 상당 부분 코드를 직접 작성해야 할 경우도 많이 생긴다.
하지만 아예 해당 기능이 빠져 있는 현재의 상황은 이해하기 힘들다. 경쟁 제품이 될 IBM의 Rational 제품군이나 Mercury의 테스트 소프트웨어들은 사용자 액션의 레코딩 및 스크립트 지원 기능의 제공을 통해 클라이언트/서버 애플리케이션의 테스트도 지원하고 있다. (http://www.sqa-test.com/toolpage.html 를 방문하면, 현재 주로 사용되는 테스트 툴의 목록을 볼 수 있다. 어떠한 제품들이 사용되고, 어떠한 기능들을 제공 하고 있는지 해당 사이트를 방문해 보는 것도 좋을 것이다.)
게다가 비주얼 스튜디오 코어 팀의 테스트 엔지니어인 사라 포드의 채널 9 인터뷰를 보면, MS 내부적으로는 Maddog이라 불리는 시스템을 이용해 자동화 된 테스트를 수행하고 있다는 것을 알 수 있다. (사라 포드의 채널 9 인터뷰) 개발 시간이 부족하였던 것인지, 내부 정책상 공개 할 수 없었던 것인지는 알 수 없지만, 이러한 기능이 비주얼 스튜디오 팀 시스템에서 빠진 것은 매우 아쉬운 일이다.
필자 이병철님은 IT 분야의 개발자로 개발 툴에 대한 남다른 관심이 높다. 실제 프로젝트에 임해서도 툴에 대한 분석력이 높다는 평가를 받고 있다.
