블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

개발환경 자동화 환경에 대한 추천 조합

ALM | 2008.03.13 11:04 | Posted by 조대협

몇가지 개발환경 자동화에 대한 테스트 조합을 해본결과에 대해서 추천을 드리겠습니다.

1. 이슈 관리 시스템
Mantis,Trac,Bugzilla,JIRA를 운용해봤습니다
결과는 JIRA가 가장 좋다는 것이 결론이고 구입 비용은 대충 120만원이면 일반 기업에서 무리 없이 사용이 가능합니다.
나머지는 오픈 소스 인데, Trac의 경우 기능은 막강하지만 인스톨과 운용이 어렵기 때문에 작은 단위나 기술력이 부족한경우에는 그다지 추천하고 싶지 않습니다.
Bugzilla의 경우 제 경우 매우 편리하게 사용을 했습니다만, 인스톨이 제법 까다롭습니다.
Matins의 경우 Instant Mantis라는 것으로 매우 쉽게 설치 및 운용이 가능합니다. 한글 지원도 잘되구요. 그러나.. 프로세스에 대한 흐름이나 UI가 좀 딸리는 느낌이 듭니다.

2. 소스 관리 도구
SVN이 널리 사용되기 때문에 다른 언급은 하지 않겠습니다.
단 SVN의 내용을 (소스나 변화 내용, 브렌치 추적) 웹에서 보여주는 도구로는 Fisheye가 제일 좋더군요. (유료입니다.) JIRA하고 연동도 쉽구요.
 무료로는 sventon이 비교적 사용도 쉽고 연동도 쉽습니다. 둘중 하나를 사용해보시는것이 좋겠습니다.

3. 빌드 스크립트
대표적으로 ANT와 MAVEN이 있습니다만, MAVEN의 경우 의존성 관리등이나 여러 기능적인 장점은 가지고 있습니다.
그러나.. 저의 경우 대부분의 작업이 엔터프라이즈 솔루션을 기반으로 하고 있는데, 이런 엔터프라이즈 개발 도구들은 MAVEN을 아직까지 지원하지 않는 경우가 많기 때문에 ANT를 사용합니다.

4. CI도구
Cruise Control, Team City, Anthill Pro, Hudson등이 있습니다.
Cruise Control은 오래된 솔루션 같구요.. 자바진영에서는 이미 좋은 솔루션들이 많아서 다른 솔루션을 사용하시는것이 좋겠습니다. Anthill pro가 많이 언급되는데 유료이고 아직 사용해본 경험은 없습니다만 널리 사용되는 만큼 추천할만 합니다.

무료로 사용될 수 있는 솔루션이 Team City Pro, Hudson이 있는데,
Hudson이 직관적이고 사용법도 매우매우 쉽습니다.
그러나 아직 개발 중인 관계로 버그가 종종 있고 자료가 적어서 다소 삽질이 많이 필요합니다. Team City는 완성도가 높지만 직관도는 Hudson에 비해서 떨어지는 것 같습니다.

5. 테스팅 도구
단위 테스트는 말할것 없이 JUnit이 추천할만합니다.
단!! JUnit은 3.X와 4.X가 코딩 스타일이 다르고 (물론 기능은 4.X가 더 좋습니다.) 특히 JUnit과 조합되는 프레임웍에서 4.X를 지원하지 않는 경우가 많기 때문에 3.X를 추천합니다.

In Container Test로는 JUnitEE와 Cactus가 있는데, 개인적으로는 Cactus를 추천합니다.
Cactus의 경우 Test Wrapper를 JUnit을 상속 받아 만들 수 있기 때문에, JUnit을 지원하는 모든 도구들과 잘 어울립니다. 특히 단위 부하 테스트를 해야하는 경우 Japex와 잘 조합이 되기 때문에 JUnitEE보다 약간 불편하긴 하지만 Cactus를 사용하는 것이 좋겠습니다.

다음으로 엔터프라이즈 시스템의 경우 DB에 대한 테스트 전후에 데이타 초기화와 개발자간의 테스트 데이타 동기, 그리고 테스트 결과 비교에 매우 유용합니다.

다음은 단위 성능 테스트인데,
JPerfUnit은 성능지표를 측정만 하는 것이기 (테스트가 어느 성능에 도달했는지 못햇는지) 때문에 단독으로는 큰효과를 얻을지는 미지수 입니다.
Japex의 경우 Junit과 조합되어 기존 JUnit에 대한 부하 테스트가 가능하고 Hudson과 통합이 매우 잘됩니다. (사용법도 간단하구요..) 이건 꼭 추천합니다. 그래프 기능도 좋구요..

6. 테스트 커버러지
다음으로는 테스트 결과에 대한 분석을 위한 커버러지 도구인데, 크게 Cobertura와 EMMA가 있습니다. EMMA는 이클립스 연동은 잘되지만 EAR이나 WAR에 대한 Instrument를 지원하지 않기 때문에, EJB등의 패키징이 많은 (JAR,WAR,EAR) JEE 시스템에는 그리 적절하지 않습니다. Cobertura의 경우 기존 패키징된 아카이브에 instrument를 할 수 있기 때문에 편리하게 사용할 수 있습니다. EMMA의 경우 runtime instrumentation을 지원하기 때문에 대안은 될 수 있겠지요. 이건 사용자의 몫에 맏깁니다.

7. Code Inspection
코딩에서 에러 발생 가능성이 있는 부분이나 코딩 스타일의 문제를 지적하는 것인데, FindBug나 PMD같은 도구들이 있고 상용으로는 Klockworks등이 있습니다만 이건 팀의 기술과 프로세스 운용 수준이 높지 않은 이상 도입에 무리가 있다고 봅니다.

그래서 제가 추천하는 조합은

SVN+JIRA+FISHEYE+HUDSON+JUnit 3.8x+DBUnit+Cactus+Cobertura+Japex

입니다. 여기에 확장으로 Confluence Wiki를 통한 팀내의 지식 공유 기반을 마련하는 것이 좋을것으로 생각됩니다.

요즘 Goverance 이야기 많이 하는데.. 뜬 구름 잡는 Governance보다는 이런 환경들이 진정한 Goverance로 가는 지름길이 아닌가 싶네요.

참고하세요

테스트 코드 커버러지와 단위 부하 테스트

(Test Code Coverage & Unit performance test)

 

자바스터디 조대협 (http://bcho.tistory.com)

현재 BEA Systems Korea에서 Senior 컨설턴트로 엔터프라이즈 애플리케이션 개발과 미들웨어 SOA에 대해 컨설팅을 진행하고 있다.

온라인 자바 사이트 http://www.javastudy.co.kr 의 초기 시샵이며, 한국 자바 개발자 협의회 JCO의 초대 부회장을 맏았다.

 

이번 글에서는 테스트가 애플리케이션을 어느정도 테스트했는지를 측정하는 코드 커버러지와, Japex 테스트 프레임웍을 이용한 부하 테스트 방법에 대해서 알아보도록 한다.

1.코드 커버러지 (Code Coverage)

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

위에서 예를 든것과 같이 기능에 대한 테스트 완료여부를 커버러지의 척도로 삼을 수 도 있다.
좀더 작은 범위의 테스트인 단위 테스트의 경우는 개개의 클래스나 논리적인 단위의 컴포넌트 각각을 테스트하기 때문에, 테스트에 대한 커버 범위를 각각의 클래스 또는 소스 코드의 각 라인을 척도로 삼을 수 있는데, 테스트가 전체 소스코드중에서 얼마나를 커버했는지를 나타내는것이 "코드 커버러지(Code Coverage)" 이다.

* 코드 커버러지 툴의 원리
코드 커버러지 툴의 주요 기능은 실행중에 해당 코드라인이 수행이 되었는가? 아닌가를 검증하는것이다. 이를 위해서 커버러지 툴은 클래스의 각 실행 라인에 커버러지 툴로 로깅을 하는 로직을 추가 하는 것이 기본 원리이다.

예를 들어 아래와 같이 간단한 HelloWorld라는 소스가 있을 때, 소스 커버러지 툴을 거치게 되면 <그림 2> 와 같은 형태의 소스 코드를 생성해내게 된다.

public class HelloWorld(){
  public void HelloBcho(){

  System.out.println(Hello Bcho);

}

public void HelloHyunju(){

System.out.println(Hello Hyunju);

}

}

< 그림 1. 원본 소스 코드 >

 

public class HelloWorld(){
  public void HelloBcho(){

    CoverageTools.log(클래스 및 라인 관련 정보1);

  System.out.println(Hello Bcho);

CoverageTools.log(클래스 및 라인 관련 정보2);

}

public void HelloHyunju(){

CoverageTools.log(클래스 및 라인 관련 정보3);

System.out.println(Hello Hyunju);

CoverageTools.log(클래스 및 라인 관련 정보4);

}

}

< 그림 2. 코드 커버러지 로그 수집이 추가된 코드>

 

그림 2와 같이 변형된 코드가 수행되게 되면 코드 수행에 따른 로그가 생성되게 되고, 이를 분석하여 코드중에 어느 부분이 수행되였는지를 보여주는 것이 코드 커버러지 툴의 기능이다.

이렇게 기존의 클래스에 커버러지 분석을 위한 분석 코드를 추가 하는 작업을 instrument 라고 하고 크게 정적 기법과 동적 기법 두가지를 지원한다.

정적 기법은 애플리케이션이 수행되기 이전에 소스코드나 컴파일이 완료되어 있는 클래스 파일을 instrument하여 instrumented class들을 만든후 그것을 수행하는 방식이고, 원본 class를 가지고 애플리케이션을 수행하여 런타임시에 클래스가 로딩되는 순간에 클래스에 Instrumentation을 하는 것이 동적 방식이다.

 동적 방식은 AOP (Aspect Oriented Programming)이나, APM (Application Performance Monitoring)에서 많이 사용하는 방법이다. 그러나 이 방식의 경우 런타임에서 code instrumentation을 하는 부하가 발생하기 때문에, instrumentation양이 AOP APM에 비해서 압도적으로 많은 Code Coverage툴의 경우에는 정적인 instrumentation 방식이 좀더 유리 하다. 단 정적 방식의 경우 컴파일후에도 instrumentation을 한번 거쳐야 하고, coverage를 분석하기 위한 애플리케이션 묶음(JAR,WAR)과 운영을 위한 애플리케이션 묶음이 다르기 때문에 용도에 따라서 매번 다시 배포(DEPLOY)해야 하는 번거로움이 있다.

 툴에 따라서 instrumentation 방식이 다르기 때문에 애플리케이션의 성격과 규모에 따라서 적절한 instrumentation을 사용하는 툴을 사용하기 바란다.

 

* Cobertura를 이용한 커버러지 분석

많이 사용하는 코드 커버러지 분석 도구로는 상용으로 www.atlassian.com Clover, http://www.instantiations.com/ Code Pro Analytix 등이 있다.

대표적인 오픈소스로는 EMMA Cobertura가 있다. EMMA의 경우 동적,정적 Instrumentation을 모두 지원하며, Eclipse 플러그인도 지원한다.

Cobertura의 경우 정적 Instrumentation만 지원하지만 사용 방법이 매우 쉽기 때문에, 여기서는 Cobertura를 이용한 Code Coverage분석 방법을 설명한다.

Cobertura를 이용하기 위해서는 http://cobertura.sourceforge.net 에서 다운 받아서 설치한다.

<!-- 1)클래스 패스 정의 -->

<path id="cobertura.class.path">

  <pathelement location="${cobertura.home}/cobertura.jar"/>

  <fileset dir="${cobertura.home}/lib" includes="*.jar" />

</path>

 

<!-- 2) 태스크 정의 -->

<taskdef resource="tasks.properties" classpathref="cobertura.class.path" />

 

<!-- 3) 빌드 -->

<target name="build">

<!-- 컴파일후에, EAR 파일로 패키징을 한다. -->

<javac debug=true >

</target>

 

<!-- 4) Code Instrumentation -->

<target name="instrument_cobertura" dependes="build">

 <cobertura-instrument todir="${workspace.dir}"

  datafile="${workspace.dir}/cobertura.ser" >

   <includeClasses regex="bcho.*" />

   <instrumentationClasspath>

      <pathelement location="${ear.file}/>

   </instrumentationClasspath>

  </cobertura-instrument>

</target>

 

<!-- 5)Code Coverage Report generation -->

<target name="report_cobertura" >

   <cobertura-report format="html" desdir="리포트 HTML이 저장될 디렉토리"

      datafile="${workspace.dir}/cobertura.ser">

      <fileset dir="원본 소스 코드가 있는 디렉토리 >

           <include name="**/*.java" />

   </cobertura-report>

</target>

< 그림 3 . Cobertura 사용을 위한 ANT TASK >

 

1) Cobertura를 인스톨한 디렉리를 ${cobertura.home} Property로 정의하고, 클래스 패스를 지정한다.

2) Cobertura에 대한 ANT TASK를 이용하기 위해서 <taskdef>를 이용하여 cobertura classpath에 정의된 TASK를 정의한다.

3) 다음으로 애플리케이션을 빌드하고, JAR WAR,EAR등으로 패키징한다. (Instrument code를 넣기 위해서 패키징은 필수 사항은 아니다. ) 이때 커버러지 분석에서 결과가 제대로 표시되게 하기 위해서 <javac> 컴파일 옵션에 debug=true를 추가한다.

4) 컴파일과 패키징이 완료된 자바 애플리케이션에 대한 Instrumentation을 수행하기 위해서 <cobertura-instrument> 테스크를 사용한다.

 todirInstrument된 애플리케이션 (EAR Instrument할 경우, Instrument EAR파일이 이 경로에 저장된다.) 저장될 디렉토리이며, datafile은 커버러지를 분석한 결과 데이터를 저장할 파일명이다.

 다음으로 커버러지를 분석할 클래스명을 지정하는데, <includeClasses> 라는 엘리먼트를 이용하여, regular expression을 사용하여 클래스의 범위를 지정한다. 예제에서는 bcho.*로 시작하는 패키지의 클래스만 Instrument를 하도록 지정하였다.

 그리고 마지막에 Instrument를 할 class 파일들의 위치를 지정하는데, <instrumentationClasssPath> class들이 저장된 경로를 지정하거나 또는 EAR등으로 패키징된 파일 경로를 지정한다.

 예제에서는 EAR파일을 Instrument하는것으로 지정하였다.

여기까지 진행한후 ant instrument_cobertura를 수행하면, ${workspace.dir} instrumented ear 파일이 생성된다.

 

Instrumented 된 애플리케이션을 서버에 배포하거나 단독 수행 애플리케이션일 경우 실행을 한다. 이때 JUnit을 이용한 테스트를 수행해도 되고, 손으로 직접 기능을 수행해봐도 된다. Instrumented 된 애플리케이션은 모든 수행 결과에 대한 로그를 저장하기 때문에 특정 테스팅 프레임웍을 사용하지 않아도 된다.

이때 수행되는 애플리케이션에 Cobertura에 대한 Coverage 로그를 저장할 디렉토리를 지정해야 하는데, JAVA에서 -D옵션을 이용하여

 -Dnet.sourceforge.cobertura.datafile=위의 ANT 스크립트에서 지정한 *.ser 파일의 절대 경로

를 지정해야 *.ser파일에 제대로 커버러지 분석 결과가 저장된다.

 

필자의 경우에는 JUnit + Cactus를 이용하여 EJB 2.1 WebLogic에서 수행하였다.

애플리케이션의 실행 또는 테스트가 끝난후 애플리케이션을 종료하면 (WAS의 경우 WAS를 종료해야 한다.) 종료시에 커버러지 데이터를 *.ser 파일에 기록하게 된다. (런타임시에는 *.ser파일에 결과가 기록되지 않는다.)

 

*.ser파일에 기록된 커버러지 분석 값은 바이너리 형태로 사용자가 볼 수 없기 때문에 이를 리포트로 생성한다.

<그림 3>에서 "report_cobertura 라는 타겟을 정의하였는데,

<cobertura-report> 엘리먼트에서 HTML 리포트가 저장될 디렉토리를 destdir로 지정하고, *.ser의 위치를 datafile attribute로 지정한다.

 그리고, 원본 소스 코드가 있는 디렉토리를 <fileset>으로 지정해주면 destdir HTML형식으로 커버러지 분석 리포트가 생성된다.

사용자 삽입 이미지

<그림 4. 테스트 커버러지 클래스 레벨 리포트 >

그림 4에서 보는것과 같이 전체 코드에 대해서 테스트가 전체 코드중 몇 %를 수행했는지를 나타내 준다. 결과에서 주의할점은 HelloEJBBean의 경우 86%의 커버러지가 나오지만 나머지 클래스들은 N/A 또는 0%가 나온다.

 이는 EJB 2.1로 코딩한 EJB의 경우 사용자는 HelloEJBBean만 코딩을 하지만 나머지 클래스들은 빌드과정에서 WAS가 자동으로 생성해주는데, 자동으로 생성된 클래스(Home, Interface,Stub )에 대한 위치 정보가 없기 때문에, N/A또는 0으로 그 결과가 표시되는 것이다. 이런 경우에는 <cobertura-instrument> 엘리먼트에서 <includeClasses>와 같은 엘리먼트로 <excludedClasses>라는 엘리먼트를 이용하여 특정 클래스들을 Instrumentation에서 제거할 수 있다.

 이런 경우에는 <excludedClasses regex=*Home /> 등을 정의해서 자동 생성되는 클래스들을 제거하거나 또는 반대로, <included Classes=bcho.*\.*Bean/> 으로 해서 bcho.* 패키지에서 Bean으로 지정되는 부분에 대해서만 Instrumentation을 수행할 수 있다.

 

사용자 삽입 이미지

<그림 5. 테스트 커버러리 코드 레벨 리포트 >

 

연두색으로 표시되는 부분, (27,35,41,42,43,47 라인)은 수행된 라인이고 그 옆에 숫자는 수행된 횟수를 나타낸다.

분석 결과를 보면 sayHello 메서드에서 isMale이 항상 true 14번 수행이 되었고 false인 경우에 대한 코드는 수행 되지 않았음을 확인할 수 있다.

 

여기 까지 간단하게 Cobertura를 이용한 코드 커버러지 분석 방법에 대해서 알아보았다.

 

* 코드 커버러지의 척도

코드 커버러지 분석에서 가장 어렵고 논란의 여지가 많은 부분은 목표 커버러지율이다. 혹자들은 테스트가 80% 이상의 코드 커버러지를 가져야 한다고 주장하는데, 일반적인 Value Object 그 많은 Util 클래스등등을 감안할 때, 80%는 상당히 높은 수준이다. 필자의 경우에는 60%도 쉽지 않는 수준이라도 보는데, 이 척도에 대한 기술적인 지표가 필요할 경우 CMM(Capability Maturity Model)등을 참고하기 바란다.

 개인적인 생각으로는 Coverage rate를 올리는 것 보다 중요도가 높은 모듈의 Coverage rate만을 관리하는 것이 효율적이라고 생각한다.

 전체 클래스가 1000개가 있을 때, 이 클래스들을 논리적인 컴포넌트로 묶은 후 (UML Conceptual Mode, Logical Model, Implementation Model Logical Model 단위로) 이 소프트웨어 컴포넌트에 대한 위험도와 복잡도를 지정하여 이를 Ranking하여 상위 순서에서 기준에 따라서 중요 컴포넌트만 Test Coverage를 관리하도록 하는 것을 권장한다.

 커버러지 분석에 대한 수치는 고객이나 메니져 입장에서 전체 시스템중 80%가 테스트 되었습니다.와 같은 의미로 받아 들여지기 때문에, 30%,60% 와 같은 기준은 받아들여지기가 어렵다. 몇 달은 테스트를 했는데, 60% rate로 매우 중요한 시스템을 오픈한다면 당신이라면 accept하겠는가?

 그렇지만 실제 애플리케이션의 전체 코드를 테스트 하는 것은 어렵고 대부분 중요 문제는 상위 10~30%의 모듈에서 발생한다. 만약 100%의 테스트 커버러지가 가능하다면 IBM이나 MS와 같은 첨단 거대 기업에서 만든 소프트웨어들에서 버그가 존재하고, 우주로 쏘아 올리는 로켓에서 문제가 생기겠는가?

 그래서 테스트 코드 커버러지를 도입하기 전에 무엇보다 중요한 것은 어떤 툴이나 커버러지 분석을 자동화하는 것이 아니라, 코드 커버러지를 적용할 소프트웨어 컴포넌트의 범위와 목표 커버러지율을 정의하고 이에 대해서 이해 당사자 (Stakeholder-고객,메니져 등)로부터 동의를 얻어내는 것이 선행되어야 한다.

 그후에 테스트 코드 커버러지 검사를 통해서 특히 단위 테스트의 정확도를 높이는 방향으로 애플리케이션의 완성도를 높이는 방향으로 개발을 진행하도록 한다.

 

2.부하 테스트 (Stress Test)

마지막으로 살펴볼 부분은 단위테스트에 대한 부하테스트에 대해서 살펴보고자 한다.

 

* 부하 테스트

부하테스트는 대상 애플리케이션에 동시에 대용량의 요청을 넣어서, 애플리케이션의 가용 용량, 속도와 같은 성능적인 척도를 측정하고, 대용량 요청시에도 애플리케이션이 문제가 없이 작동하는지를 확인하는 과정이다. (1회의 테스트 과정에서 설명하였다.)

보통 Load Runner Apache JMeter,MS WebStress등을 이용하여 애플리케이션의 기능에 대해서 부하 테스트를 수행하지만, 여기서 설명하고자 하는 부하테스트는 소프트웨어 컴포넌트에 대한 부하 테스트 이다.  필자의 경우 이를 국지적 부하테스트 라고 정의 하는데, 단위 테스트에 대해서 부하를 넣어서 테스트를 진행하는 방법이다.

 부하 상태에서 소프트웨어 컴포넌트에서 발생할 수 있는 문제는 크게 응답 시간 저하와, synchronized 또는 IO에 의한 lock 경합 현상,deadlock 그리고 메모리 사용량에 대한 이슈가 가장 크다. 이런 문제는 대규모의 전체 애플리케이션 부하테스트가 아니더라도 국지적인 단위 테스트에 대해서 부하를 줄 경우에도 어느정도 검출이 가능하다.

 

이런 단위테스트에 대한 부하 테스트로는 성능 테스트 프레임웍으로 JUnitPerf등이 있지만 여기서는 Japex라는 테스팅 프레임웍을 설명하도록 한다. (http://japex.dev.java.net )

Japex의 경우 별도의 코딩을 할 필요가 없이 기존의 JUnit에 설정을 추가하는 것만으로 JUnit에 대해서 부하 테스트가 가능하다.

 

* Japex를 이용한 부하 테스트

Japex를 사용하기 위해서는 http://japex.dev.java.net에서 Japex 라이브러리를 다운 받은후

java com.sun.japex.Japex config파일

로 수행하면 된다.

또는 같은 방식으로 ANT task에서 정의할 수 있다.

<pathelement id="class.path">

  <pathelement location="컴파일된 애플리케이션 클래스패스"/>

  <fileset dir="${JAPEX_HOME}/lib" includes="*.jar"/>

  <fileset dir="${JAPEX_HOME}/jsdl" includes="*.jar"/>

  <fileset dir="컴파일된 애플리케이션 클래스패스"/>

</pathelement>

 

<target name="run_japex">

 <java dir=." fork="true" classname="com.sun.japex.Japex" >

   <classpath refid="class.path" />

   <arg line="${Japex config 파일}" />

 </java>

</target>

< 그림 6. Japex ANT 스크립트 >

 

다음으로 japex config 파일을 지정해야 하는데 다음과 같이 지정한다.

<?xml version="1.0" encoding="UTF-8"?>

<testSuite name="ParsingPerf" xmlns="http://www.sun.com/japex/testSuite" >

 <param name="japex.classPath" value="애플리케이션이 빌드된 디렉토리 (클래스 경로)" />

 <param name="japex.classPath" value="Japex home/jsdl/*.jar" />

 <param name="japex.resultUnit" value="ms" />

 <param name="japex.wrampupTime" value="0" />

 <param name="japex.runtime" value="00:03" />

 <param name="japex.numberOfThreads" value="20" />

 

 <driver name="JUnitDriver">

   <param name="japex.driverClass" value="com.sun.japex.jdsl.junit.JUnitDriver"/>

 </driver>

 

 <testCase name="testHello">

  <param name="testName" value="bcho.test.junit.HelloWorldTestCaseWrapper" />

 </testCase>

</testSuite>

 

<그림 7. Japex config 파일 ${Japex config 파일} >

 

중요한 parameter로는

l        japex.resultUnit 은 성능 결과치에 대한 단위 (, 밀리세컨드 등)

l        japex.wrampumTime은 성능 테스트시 본 테스트전에 시스템을 워밍업 하는 시간 (캐쉬 초기화등등).

l        japex.runtime은 실제 테스트를 수행하는 시간

l        japex.numberOfThreads는 동시에 부하를 주는 클라이언트 수이다.

그리고 JUnit Japex로 호출하기 위해서 driver JUnit 드라이버를 지정하여 로딩하고 <testCase> 엘리먼트에 testName으로 JUnit 테스트 슈트를 지정하여 해당 슈트가 Japex의 설정에 따라 부하테스트가 되도록 한다.

테스트가 끝나면 테스트 결과를 다음과 같이 여러 형태의 그래프로 표현할 수 있다.

사용자 삽입 이미지사용자 삽입 이미지

< 그림 8. Japex로 생성한 성능 테스트 그래프 >

 

매우 간단하게 Japex를 이용한 단위 부하테스트를 소개했지만, Japex JUnit 뿐만 아니라 driver를 추가함으로써 여러 형태의 부하테스트를 지원할 수 있고, 상당히 여러 종류의 그래프를 출력할 수 있으며 개발자에게 별도의 개발이 없이 기존의 JUnit을 재활용하여 부하테스트를 가능하게 해주기 때문에, 상당히 유용한 테스팅 프레임웍이다.

 

3. 맺음말

지금까지 3회에 걸쳐서 자바 단위 테스트의 기본이 되는 JUnit, J2EE에서 유용한 DBUnit Cactus와 같은 확장된 프레임웍, 테스트 검증을 위한 커버러지 분석툴 그리고 단위 부하테스트까지 간단하게 살펴보았다.

사실 테스트에 대한 범위는 매우 넓고 광범위 하다. 우리가 살펴본 내용은 이제 막 걸음마를 뗀 수준에 불과 하지만, 단위 테스트가 무엇이고 어떻게 진행해야 할것인가에 대한 방향성을 제시하기 위한 내용이다.

 반드시 기억해야 하는 내용은

 테스트는 도입해야 한다.

 어떤 테스트 툴을 도입 하는가 보다는 어떻게 테스트를 할것인가?

가 가장 중요하다.

 

Code Coverage Tools

ALM/Build Automation (빌드 자동화) | 2008.02.01 18:03 | Posted by 조대협

상용 도구

Code Pro Anlytix Pro
: 기능이 풍부한것 같고, 정적 코드 분석을 통해서 Complexity 분석도 되고 기능은 풍부한편으로 보인다.
http://www.instantiations.com/codepro/analytix/server/index.html

Clover
: 다들 잘 아는 툴 이미들 많이 사용하고 있고, 널리 알려진 만큼 다른 시스템 (CI툴이나 Issue Tracking Tool, 소스 관리툴)들과의 통합도 쉽다.

오픈소스

Cobertura - 요즘 가장 유행하는 툴이 아닐까도 싶고.. 사용이 쉽고 직관적이다. 추천할만한 툴
EMMA-꽤 오래된듯한 툴 같은데... 여기저기 사례도 충분한거 같고 이클립스 플러그인도 지원한다. 마음에 드는것중 하나가 컴파일이 이미 다된 jar 파일을 emma 위에서 실행 시키면 바로 Coverage 분석도 가능하다는 말씀.. 리포트가 직관적이지 않긴 하지만 이클립스 지원하니까는 커버되지 않을까?
http://emma.sourceforge.net/intro.html

NUinit - 나온지 얼마 안된거 같기도 하고... 오픈 소스 툴 중에서는 가장 허접한듯..

Cobertura는 실컷 써봤고... EMMA를 한번 써볼까나?

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

Hudson에서 SMTP PORT 지정하기 (Assign SMTP server port in Hudson)  (0) 2008.02.11
통합 빌드 환경 설정 완료  (0) 2008.02.05
Code Coverage Tools  (0) 2008.02.01
이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
Atlassian Bamboo  (0) 2007.11.08

테스트 성공!!

사는 이야기 | 2008.01.17 19:09 | Posted by 조대협
빌드 배포 자동화 과정중에 테스트의 자동화는 말할 필요 없이 중요한 내용...
테스트 자동화를 시간 날때마다 계속 했는데.
오늘에야 대충 전체 시나리오를 만들었다...

POJO 기반의 테스트는 JUnit
J2EE 컴포넌트의 인컨테이너 테스트는 Cactus
DB 테스트는 DBUnit
하면은 HttpUnit과 JWebUnit

정말 관건은 J2EE 애플리케이션에서 필요한 InContainer 테스트에 대한 내용이었다.

단순히 InContainer Test만으로는 기능 이외의 다른 요건을 충족하기 힘들어서
J2EE 애플리케이션의 커버러지와, 성능 단위테스트가 필요하였다.
그래서 조합한것이

Cactus + Cobertura = J2EE 애플리케이션의 커버러지 분석
Cactus + Japex = J2EE 애플리케이션의 단위 성능 테스트

이정도면 왠만한 J2EE 애플리케이션의 단위 테스트는 문제가 없으리라.
단 성능과 외부적인 요인 메모리 이슈를 해결하는게 문제인데..
이건 해가면서 해야겠다.

'사는 이야기' 카테고리의 다른 글

우리 단비 얼굴 보다..  (0) 2008.01.27
JCO 컨퍼런스 2008  (0) 2008.01.23
테스트 성공!!  (0) 2008.01.17
요즘...  (1) 2008.01.14
톰을 만들다..  (0) 2008.01.14
아.. 좌절...  (1) 2008.01.11
Cobertrua의 분석 리포트를 보면 Line Coverage율과, BranchCoverage율이 나오는데.
이 값이 정학하게 나오지 않고 N/A로 나오거나, 100%로 나오는 경우가 있는데
이건 클래스를 컴파일할때 디버깅 모드로 컴파일하지 않아서 발생하는 문제이다.
이를 해결하기 위해서
ANT TASK에서 <javac debug="true"...> 옵션을 추가해주면 된다.
서버쪽에서 Cobertura를 이용한 커버러지 분석을 할때
주의할점은

Cobertura는 기본적으로 ASM을 이용하여, 테스트를 진행할 코드에 커버러지 분석 코드를 삽입하는 방식이다. (AOP와는 다르게 STATIC한 방식을 사용)
그렇기 때문에, Instrumented 된 코드가 반드시 실행되도록 클래스패스에 삽입 하거나 또는 패키징 할때 Instrumented 되지 않은 코드를 WEB-APP에 먼저 복사한후 그 다음에 Instrumented된 코드를 복사하여 Overwrite가 되게 해야 한다.

그리고, Cobertura는 커버러지 분석한 정보를 메모리에 담아 놨다가 서버가 shutdown될 당시에 한꺼번에 파일에 쓰기 때문에 메모리 요구량이 높을 수 있다.
그래서 각 단위 테스트마다 리스타트를 해서 메모리가 오버 되지 않게 유지 해야 한다.

기동 스크립트에서는
JAVA에 -D 옵션으로 -Dnet.sourceforge.cobertura.datafile=파일명.ser 로 지정하고
Cobertura에서 사용하는 파일들 corbertura.jar, asm, asm-tree, jakarta-oro.. jar들을 클래스 패스에 삽입해야 한다.

이렇게 하고 Instrumented된 코드를 수행하면, (비단 JUnit이 아니더라도) 수행한 내역을 *.ser 파일에 저장하게된다.

Test Coverage 분석툴

ALM/Test Automation | 2007.11.08 16:36 | Posted by 조대협
http://cobertura.sourceforge.net/
http://emma.sourceforge.net/

요즘 빌드 자동화와 테스트 커버러지에 관심이 많은데.
거기에 해당하는 툴.
위에 툴 둘다 재미있는게, 실제 소스코드에서 테스트가 된곳과 안된곳을 하이라이트 처리해준다는것이 매우 흥미롭네.
EJB도 그만큼 잘 지원해줄려나?

물론 돈만 있다면
http://www.cenqua.com/clover/
클로버를 쓰고 싶은데.. ^^;

==
형준이 말로는 JCoverage가 좋다네.

'ALM > Test Automation' 카테고리의 다른 글

JUnitPerf  (0) 2008.01.16
단위 테스트 1회 (JUnit)  (1) 2007.11.23
Test Coverage 분석툴  (0) 2007.11.08
Cactus 실행용 ANT 스크립트  (0) 2007.09.13
Cactus 빌드 스크립트 샘플  (0) 2007.09.12
Unit Testing WebLogic Workshop 8.1 Applications & JWebUnit  (0) 2007.08.27