소프트웨어 개발과 테스트 -단위 테스트 도구/테스트케이스 관리도구

소프트웨어 개발과 테스트 국내도서 저자 : 조대협 출판 : 프리렉 2015.01.15 상세보기

◎ 단위 테스트 : 단위 테스트는 테스트 대상이 되는 코드 기능의 아주 작은 특정 영역을 실행해 보는, 개발자가 작성한 코드 조각이다. 대개 단위테스트는 특정 상황에서 특정 메서드를 시험해본다. 예를 들어 어떤 정렬된 리스트에 큰 값을 넣고 이 값이 리스트 끝에 들어가 있는지 확인해 볼 수 있다. 

◎ Junit : Junit는 자바 애플리케이션의 단위 테스트 자동화를 위한 프레임워크다. 상당히 사용하기 쉽고, 이클립스와 같은 IDE나 ANT/Maven과 같은 빌드 스크립트에서 쉽게 통합이 되기 때문에 가장 널리 사용되고 있다. 

◎ 코드 커버리지 : 좀 더 작은 범위의 테스트인 단위 테스트의 경우는 개개의 클래스나 논리적인 단위의 컴포넌트 각각을 테스트하기 때문에, 테스트에 대한 커버 범위를 각각의 클래스 또는 소스 코드의 각 라인을 척도로 삼을 수 있는데, 테스트가 전체 소스 코드 중에서 얼마나 커버 했는지를 나타내는 것이 코드 커버리지이다. 

◎ Selenium Grid : Selenium의 재미있는 기능 중의 하나다 Grid라는 기능이다. 하나의 PC에서 브라우저로 테스트하는 것이 아니라, 테스트 케이스를 동시에 여러 개의 PC에서 테스트를 실행할 수 있다. 이 말은 테스트를 빠르게 진행할 수 있다는 말도 되지만, 궁극적인 장점은 호환성 테스트에 유리하다. 

◎ 테스트 프로젝트 : 테스트 프로젝트는 테스트를 수행하는 프로젝트 자체를 이야기한다. 하나의 서비스에 대해서도 특성에 따라서 여러 가지 프로젝트로 분할해서 테스트를 진행할 수 있다. 분할의 기준은 자유롭지만, 테스트 팀 단위로 분할하는 것이 관리에 용이하다.

◎ 단위 테스트는 테스트 대상이 되는 코드 기능의 아주 작은 특징 영역을 실행해 보는, 개발자가 작성한 코드 조각이다. 대개 단위 테스트는 특정 상황에서 특정 메서드를 시험해본다. 예를 들어 어떤 정렬된 리스트에 큰 값을 넣고 이 값이 리스트 끝에 들어가 있는지 확인해 볼 수 있다. 

◎ 단위 테스트는 소프트웨어 구성 요소의 각 컴포넌트를 독립된 환경에서 테스트 하는 것이다. 그렇지만, 일반적으로 소프트웨어 컴포넌트는 혼자서 동작할 수 없고 다른 컴포넌트에 대해서 종속성을 가지고 있기 때문에 종속 관계에 있는 컴포넌트가 완성되지 않거나 그 컴포넌트에 오류가 있으면 정상적으로 테스트를 진행할 수 없다. 이런 문제를 해결하기 위해서 사용하는 것이 Mock Object이다. Mock Object는 가상 오브젝트로, 테스트를 위한 Operation만을 구현하여 테스트에 사용할 수 있다. 

◎ 우리가 단위 테스트나 통합 테스트와 같은 일련의 테스트 작업을 수행하였을 때 이 테스트가 전체 테스트를 해야 하는 부분 중에서 얼마만큼을 테스트했는지를 판단해야 한다. 예를 들어, 20가지의 기능을 가진 애플리케이션이 있을 때 몇 가지 기능에 대해서 테스트를 했는가와 같이, 수행한 테스트가 테스트의 대상을 얼마나 커버했는지를 나타내는 것이 테스트 커버리지다. 이 커버리지 비율을 기준으로 애플리케이션이 릴리즈가 가능한 수준으로 검증되었는가를 판단하게 된다. 

◎ 테스트 프로젝트는 테스트를 수행하는 프로젝트 자체를 이야기한다. 블로그 서비스를 만들었을 때 '블로그 서비스 프로젝트'와 같은 단일 테스트 프로젝트로도 만들 수 있고 혹은 '블로그 서비스 모바일 클라이언트 테스트', '블로그 서비스 웹 서비스 테스트'와 같이 하나의 서비스에 대해서도 특성에 따라서 여러 가지 프로젝트로 분할해서 테스트를 진행할 수 있다. 분할의 기준은 자유롭지만, 테스트 팀 단위로 분할하는 것이 관리에 용이하다. 

◎ 애플리케이션에 대한 모니터링은 APM 이라는 도구를 사용한다. 이 도구는 테스트 중에 애플리케이션의 상태를 알려준다. 처리된 요청에 대해 초당 처리 건수, 처리 데이터베이스, 처리 과정에서 어떤 클래스의 어떤 매서드를 사용했으며 각 메서드에서 소요된 시간과 CPU 처리 시간을 계산해준다. 애플리케이션을 코드 레벨에서 병목과 수행 과정을 모니터링 해준다. 이 정보만 가지고 있으면 병목이 발생하였을 때 메서드에 소요된 시간이나 CPU가 높은 것을 찾아서 병목으로 지목하고 진단을 할 수 있기 때문에 매우 유용한 도구이다. 여기에 애플리케이션 뿐만 아니라 애플리케이션이 기동되는 미들웨어에 대한 모니터링을 포함하는 경우가 많다. 

◎ 톰캣, 웹로직과 같은 미들웨어의 경우에는 미들웨어 자체에서 모니터링 콘솔을 제공한다. 애플리케이션의 로직이 아니라 미들웨어에 대한 운용 상태를 보여주는데, 여기서는 애플리케이션을 구동하는 데 사용되는 스레드 수, 동시 접속 사용자, DB로의 연결, 클러스터링 구성 상태 등의 애플리케이션의 상세 구동 환경을 보여준다. 이러한 항목은 자바의 모니터링 표준인 JMX를 준수하기 때문에 필요에 따라서 JMX 호출 코드를 작성하며 커스터마이징된 모니터링 환경 구축이 가능하다. 

◎ 하드웨어 인프라에 대한 모니터링은 OS에서 제공하는 기본 도구나 장비 제공 업체로부터 제공되는 도구를 이용한다.  가장 기본적인 CPU,메모리, 디스크 IO 등에 대해서는 Top이나 Glance와 같은 유틸리티를 이용한다. 네트워크 단에 문제가 있을 경우에는 패킷을 직접 검사할 수 있는데, tcpdump와 같이 임베딩되어 있는 도구를 사용할 수도 있지만, 완전히 원본 데이터베이스를 보여주기 때문에 tcpdump는 사용하기가 어렵고 GUI 환경을 갖춘 도구를 사용하는데, 와이어샤크를 많이 사용한다. 

◎ 소프트웨어 테스트는 아주 넓은 분야이다. 그만큼 그에 활용되는 도구들도 많다. 실제 개발하고자 하는 소프트웨어에 맞는 테스트 도구를 찾아서 알맞게 테스트 프로세스에 녹이는 것이 중요하다. 그리고, 도구는 사람이나 프로세스를 넘어설 수 없다. 도구는 자동화를 통한 효율성을 추구함이 목적이지 도구 자체가 목적이 되어서는 안 된다. 그에 앞서서 적절한 테스트 프로세스와 방법론 그리고 그에 맞는 조직 구도를 구축하는 것이 선행되어야 한다.