3 장소프트웨어테스트 소프트웨어는프로그래밍언어만알고개발환경만있으면누구나개발할수있다. 기능자체를개발할수있느냐없느냐는문제가아니다. 문제는개발된소프트웨어의기능이얼마나제대로작동을하고있는지성능은만족할만한지, 안정성이나확장성은충분한지를검증해야한다. 이는테스트를통해서검증이가능한데,

3 장소프트웨어테스트 소프트웨어는프로그래밍언어만알고개발환경만있으면누구나개발할수있다. 기능자체를개발할수있느냐없느냐는문제가아니다. 문제는개발된소프트웨어의기능이얼마나제대로작동을하고있는지성능은만족할만한지, 안정성이나확장성은충분한지를검증해야한다. 이는테스트를통해서검증이가능한데, 전통적인소프트웨어개발에서는소프트웨어개발이완료된후출시전에테스팅을하는방식을사용했다. 그러나문제점은초기에발견하는것이수정이쉽고비용이적게들기때문에, 개발단계별로그에맞는테스팅전략을수립함으로써, 개발중에도계속해서소프트웨어품질을다듬어나가는개발모델이주류를이루고있다. V 모델 여기서설명할테스팅모델은 V 모델이라는테스팅모델을기반으로한다. ISTQB 의테스팅방법 론에정의된모델이다. V 모델은 Water-fall 의확장형으로, Water-fall 모델의개발각단계를각각 대칭되는 4 가지단계의테스팅모델로정의하여테스트절차를강화한개발모델이다. V 모델은개발및테스트단계를기준으로개발모델상의구현을수행하는좌측의 Verification 테스트영역과, 개발이된시스템을가지고테스트를하는 Verification 영역으로나뉘어진다. 좌측부분에대한검증을 Verification이라고하는데, Verification의의미는 우리가맞는 (right) 제품을만들고있는가? 를검증하는것이고, 우측부분에대한검증은 Validation으로그의미는 우리가제품을맞게 (right) 만들고있는가? 를검증하는것이다. Verification 작업을하기위해서는제품을개발하기전에요구사항이나디자인이옳은지를점검을하게되는데, 이러한작업은주로문서를기반으로이루어진다. 이렇게실제로작동하는시스

템이아닌문서와같이정적인것을가지고검증을하는것을정적테스트 (Static Test) 라고한다. 이정적인것이란 소스코드, 설계문서, 요구사항정의서 와같은산출물이중심이된다. 우리가가장손쉽게접하는정적테스트의사례는표준준수여부를체크하는것이다. 산출물문서는목록에맞춰서제대로작성이되어있는지, 내용이나문서포맷은표준에맞는지등의표준준수여부확인활동이다. 또는요구사항이나산출물에대해서검수를받는과정도대표적인정적테스트의과정으로볼수있다. 우측영역인동적테스트는작동이가능한실제시스템을기반으로테스트를수행한다. 동적테스트의각테스트단계는좌측영역에맵핑되는각단계의내용을기반으로하여검증을수행한다. 단위테스트단계에서는구현에대한신뢰성검증을, 통합테스트는상세설계에대한유효성검증을, 시스템테스트단계에서는설계에대한검증을그리고인수테스트단계에서는사용자요구사항에대한만족도를중심으로테스트를수행하게된다. 정적테스트 이런산출물검수이외에소스코드를대상으로정적테스트를수행할수있는데, 크게두가지 방법을널리사용한다. Code Review (Human driven) 코드리뷰는앞장의 개발프로세스 에서이미설명하였듯이사람이직접소스코드를보면서코드의품질을체크하는프로세스이다. 방식에따라서 Peer Review,Walk-through,Team Review,Code Inspection등이있으며, 비용대비효과가매우큰방식이다. Static Analysis (Automated) 코드리뷰가사람에의해서수동적으로수행되는정적분석과정이라고하면 Static Analysis ( 정적분석 ) 은자동화된툴에의해서이루어지는정적분석과정이다. 흔히정적분석툴라고불리는툴들이소스코드를분석하여, 잘알려진버그에대해서리포팅을하거나 ( 예 Connection Leak - JDBC Connection Pool에서 Connection을사용한후 Pool에돌려놓지않아서생기는문제 ) 코딩표준에맞지않는코딩내용을찾아내거나 ( 띄어쓰기, 줄바꾸기, 변수명이나클래스명규칙등 ) 실행되지않는 dead code등을검출하거나 코드의복잡도를계산하는작업을수행한다.

이런정적분석을수행하는툴로는 PMD,Find Bugs, Jdepends와같은오픈소스툴가있으며, 상용툴로는 Klockworks 등이있다. 이정적분석의효율성은사실툴를인스톨해서실행만한다고나타나지않는다. 정적분석은미리정의된소스코드의패턴을기반으로해서테스트대상이되는시스템을분석하여결과를내는원리로동작한다. 즉이 미리정의된패턴 이라는것이매우중요한데, 위에언급한툴들에기본으로설정되어있는패턴들은매우폭넓게적용되어있는패턴으로아마처음수행해보면셀수없이많은오류결과들을리포팅해낼것이다. 이것을여과없이개발팀에넘기게되면고치지않아도되는 ( 결함이아닌 ) 부분에대한수정을해야할수도있고, 개발팀입장에서는해당내용이결함이아니라는것을테스트팀에설득하면서시간이소요될수있다. 그래서정적분석툴를적용하려면반드시패턴을검토하고개발하고자하는소프트웨어에맞도록패턴을재정의해서사용해야한다. 제대로된패턴을사용한다면정적분석툴는코딩규칙에벗어난코드나일반화된자주발생하는오류들을검출하는데매우유용하게사용될수있다. 테스팅레벨 V 모델에따르면, 동적테스트는단계별로테스트의범위와주체에따라서따라단위테스트, 통 합테스트, 시스템테스트, 인수테스트 4 가지로분리될수있다.

단위테스트 ( 개발자가개발단계에수행 ) 단위테스트는시스템의소스코드로직등을점검하는단계로, 소스코드의 Class나 method단위의검증을수행한다. 단위테스트는개발단계에서개발자또는개발팀차원에서직접수행을하게된다. 자신이코딩한 method나 class가정상적으로동작하는지를테스트하는데, 주로기능이제대로작동하는지를점검한다. In container Test 자바애플리케이션에서는주로 JUnit과같은 xunit 시리즈의단위테스트프레임웍을사용하는데, Tomcat이나 WebLogic과같은미들웨어위에서작동하는애플리케이션의경우테스트가반드시해당미들웨어위에서동작해야한다. 이런테스트를 In-container 테스트라고하는데, 이런 in-container 테스트를지원하는프레임웍으로는 Cactus등이있다. Mock up 단위테스트는소프트웨어구성요소의각컴포넌트를독립된환경에서테스트하는것이다. 그렇지만일반적으로소프트웨어컴포넌트는혼자서동작할수없고다른컴포넌트에대해서종속성 (Dependency) 를가지고있기때문에종속관계에있는컴포넌트가완성되지않거나그컴포넌트에오류가있으면정상적으로테스트를진행할수없다. 그래서이런경우에는가상의테스트용클래스와메서드를구현하는데, 이를 Mock-up Class라고한다. 이 Mock Up 의경우 Class와 method의정의는있지만, 안에비지니스로직은구현되어있지않고, input에대해서정해진 output 값만을내는형식이된다. 이러한 Mock-up Class는직접구현할수도있지만, EasyMock (http://www.easymock.org에서) 과같은프레임웍을사용하면조금더쉽게구현할수있다. Continuous Integration CI 구현이끝난코드는이단위테스트를통해서검증을하고, 소스관리시스템에저장 (commit) 하게된다. 저장된소스코드는다른사람이작성한소스코드와함께다시컴파일이되서모든단위테스트를다시거치게된다. 이번저장때작성한단위테스트를포함해서이를포함한예전단위테스트까지모두같이테스트하게되는데, 이를 Regression Test ( 회귀테스트 ) 라고한다. 회귀테스트를하는이유는예전코드의변경이없더라도새로운코드가기존로직에영향을줄수있기때문에, 새코드가기존코드에대해서결함을발생시키지않았음을검증하기위해서수행한다. 이러한일련의과정은보통자동화된환경에서이루어지는데이를 Continuous Integration-CI 라고한다. 이 CI에대한개념과전체프로세스는나중에개발환경부분에서다시언급하도록하겠다. 단위테스트는결함을개발중에찾아낼수있는대단히유용한테스트기법이기도하지만개발자가직접단위테스크코드를구현해야하기때문에개발자에대한부담이가중이된다. 특히단위테스트를꼼꼼하게구현할수록, 단위테스트구현시간이늘어나는데, 이런경우에는필요에

따라개발팀에별도의단위테스트를구현할수있는개발자를배치하는경우가있다. 개발자 3~5명당단위테스트를구현및수행하는사람을 1명정도둘수있다. 그러나가장이상적인케이스는코딩시간과단위테스트구현시간을같이고려하여개발스케쥴을짜고, 모듈을개발한개발자가단위테스트까지같이작성하게하는것이효율성이높다. 통합테스트 ( 개발팀에서개발단계에수행 ) 통합테스트는각개발자또는단위개발팀에서개발된모듈들을서로합쳐서상호연동이제대로되는지를검증하는테스트이다. 단일서버형태로배포되는시스템의경우에는개인들이작성한코드들의통합정도수준이지만, 여러개의하드웨어서버에각각다른역할로서비스컴포넌트가배포되는대규모시스템의경우에는각서비스컴포넌트간의상호연계성을확인해야하기때문에매우중요한테스트단계이다. 통합테스트는일반적으로개발팀의주도로이루어져서수행이되며, 시스템의규모가클경우에는테스트팀의주도로이루어진다. 통합테스트에서는시스템연동의기능적인면을주로검토를하고성능등의비기능적인면은검증하지않고시스템테스트단계에서수행한다. 시스템테스트 ( 테스트팀에서테스트단계에수행 ) 시스템테스트는통합이완료된시스템에대해서기능테스트및비기능테스트를수행한다. 시스템테스트는주로부하를주는상황에서수행을하게되고비기능테스트를중점적으로진행한다. 시스템테스트는테스트팀이주도하여릴리즈가끝난버전을가지고테스트를수행한다. 애자일개발방식에서의시스템테스트는 Sprint ( 또는 iteration) 이종료될때마다개발환경과분리된테스트환경에서진행하며, 제품출시전의몇번의시스템테스트는테스트환경이아닌실운영환경에서테스트를진행한다. 실운영환경에서테스트를진행하는것은개발된시스템에대한소프트웨어뿐만아니라운영환경자체에대한검증을진행하기위함이다. 비기능테스트의종류 - 성능테스트 시스템에부하를주면서시스템의성능을측정한다. 성능측정시에체크해야하는성능지표는 TPS와 Response Time이다. TPS는초당몇건의요청을처리하느냐이고, Response Time은요청당응답시간이다. 부하테스트를수행할때는, 가상사용자의수를늘려가면서부하의양을점차적으로늘려가는데이때 TPS와 Response Time의변화추이를측정한다. 이때임계성능을측정해야하는데, ( 시스템이허용하는최대성능 ) 임계성능은여러조

건을통해서결정한다. 부하량을늘려가게되면, 위의좌측그래프와같이 TPS가어느부하량이상이되면더이상 TPS가증가하지않고일정수준을유지하게된다. 이때의부하량즉가상사용자수가이시스템의처리가능용량이되고, 이때의 TPS가이시스템의최대성능이된다. 응답시간이중요한시스템의경우에는 TPS의임계점을기준으로하지않고목표응답시간을기준으로성능의임계점을정해야하는데, 부하량이늘어나면응답시간은 x^2 ( 제곱 ) 형식으로증가하게되는데, 이응답시간이목표한응답시간이상으로올라가는시점을임계성능으로측정하고이때의 TPS를시스템의최대성능으로정한다. 이렇게성능테스트를하는과정에서 CPU나 Memory등의하드웨어리소스가남을경우에는튜닝이나구조변경등을통해서남은 CPU와 Memory 자원을모두사용하도록하여다시성능치를구한다. CPU는일반적으로 70%~80% 를사용하는때를시스템의허용용량으로잡는다. 100% 를기준치로하지않는것은운영상황에서 CPU가 70~80% 가되면보통, 시스템에대한하드웨어증설을하는시기이기때문에목표치를 70~80% 로잡는다. - 장애테스트장애테스트는시스템이장애가났을때이에대한감지와장애복구능력을검증하는테스트이다. 기업의서버시스템의경우여러대의서버로구성되어장애대응이되어있는아키텍쳐의경우전체시스템에서일부시스템이장애가나더라도거래정보가유실이없이제대로작동해야한다. 이에대한테스트가장애테스트이다. 장애테스트는장애가발생할수있는곳에부하를주는중에강제적으로장애를일으켜서거래가문제없이처리되는지를체크하게된다. 장애의유형은여러가지가있지만대표적으로아래와같은장애의유형에따라테스트를진행한다. 1 미들웨어장애테스트 서버소프트웨어를기동하기위한미들웨어, 예를들어 DBMS, 웹서버, Web Application 서버등이장애가났을때에대한장애대응능력을검증한다. 이러

한형태의장애대응은미들웨어자체의클러스터링기능에의해서처리되는경우가많다. 미들웨어장애테스트는부하테스트중에강제적으로가동중인미들웨어인스턴스를종료시킨후에, 시스템으로의요청이실패없이처리되어야한다. 2 하드웨어장애테스트 다음으로하드웨어에대한장애테스트를들수있는데, 하드웨어가장애났을때의대처능력을검증한다. 해당하드웨어의전원을강제적으로내림으로써인위적으로장애를발생시킨다. 3 네트워크장애테스트네트워크장애는각서버간의연결장애에대한대응능력검증으로, 네트워크선을스위치나서버에서강제적으로뽑아서장애를발생시키고테스트를수행한다. 이러한장애에대한대처는하드웨어나소프트웨어에대한클러스터링 (Clustering) 이나이중화 (High Availibility) 구성을통해서이루어지는것이일반적이다. 장애가났을때장애가나지않은나머지시스템으로요청을전달하여처리는것을 Fail- Over라고한다. 위의시나리오는장애에대한 Fail Over에대한테스트이다. 장애가났을때의테스트를했다면반대로장애가복구되었을때는테스트를수행해야하는데이를 Fail Back이라고하고, 이에대한검증테스트를 장애복구테스트 라고한다. 장애복구테스트는장애테스트와역순으로진행하는데, 서버를강제종료시켰다면서버를재기동시키거나, 네트워크선을뽑았다면다시연결해서상황이정상화되었을때장애가났던시스템이다시정상적으로거래를처리하는지를확인해야한다. - 안정성테스트 안정성테스트는시스템이오랫동안운영이되더라도문제가없는지를검증하는테스트로부하를수일동안주면서시스템이문제없이서비스가되는지를체크한다. 3~7일정도지속적으로부하를주면서시스템상황을모니터링하는데, 특히시스템이메모리누수 (Memory Leak) 가있거나인프라자원을효율적으로반납하지못할경우에는장애가발생한다. 실운영환경처럼아주장기적인부하를줄수는없지만짧은기간이라도많은양의부하를주고, 하드웨어자원의사용그래프를분석하면잠재적인문제가있는지를예측할수있다 Memory Leak ( 메모리누수 ) : 코드상에서메모리를요청한후반납하지않아서사용가능한메모리용량이줄어드는현상. 메모리를자동으로관리해주는자바의경우에도 Memory Leak은발생한다. - 확장성테스트

확장성테스트는시스템을증설함에따라용량이선형적으로증가하는지를확인하는테스트이다. 확장성은크게 Vertical Scalability와 Horizontal Scalability가있는데, Vertical Scalability는서버의수는유지한체 CPU나 Memory 용량등을증설하는방법이다. Horizontal Scalability는서버의대수를늘려서용량을증설하는방법이다. 서버의대수를늘려가면서 Horizontal Scalabilty를테스트하고, CPU나 Memory를늘려가면서 Verical Scalability를테스트한다. 용량증가에따라 TPS가선형적으로 ( y=a*x ) 증가하는지를확인한다. Vertical Scalability는요즘가상화환경의발전으로인해서 Virtual Machine에할당되는 CPU Core수와 Memory를늘려서테스트를수행할수있다. Horizontal Scalability는서버의대수가증가한다고해서용량이증가될수있는것이아니라시스템자체가서버증설에대해서확장할수있는아키텍쳐로설계가되어있어야한다. - 단일거래테스트와복합거래테스트 앞에서언급한 4개의시스템테스트는단일거래와복합거래두가지관점에서수행이가능하다. 단일거래란하나의기능에대해서테스트를수행하는것이고, 복합거래테스트는여러개의단일거래를실운영상황에맞춰서가중치를줘서부하를주는테스트이다. 단일거래테스트는단일시나리오에대해서만테스트를진행하기때문에, 비기능적결함에대한발견이용이하다. 복합거래테스트는여러시나리오를동시에테스트하기때문에, 각개별시나리오의상호간섭을검증할수있고, 실운영환경에가까운테스트결과를얻을수있다. 또한복합거래로측정된성능치가운영환경에서의성능과용량이된다. 복합거래테스트에서각단일거래에주는가중치는실업무패턴을중심으로작성되어야하는데, 기존의비슷한업무가있다면기존업무의각단일거래기능에대한비중을기본으로하는것이가장좋다. ( 웹로그분석등 )

시스템테스트는성능테스트를기본으로이루어진다. 부하를넣고있는상태에서장애를테스트하고, 시스템을확장해가면서확장테스트를수행하며, 부하상황을지속시킴으로써안정성을테스트할수있다. 그만큼성능테스트를얼마나잘만드냐가나머지테스트를성공적으로수행할수있게해주는중요한테스트이다. White box 테스트 & Black Box 테스트 이 4가지테스팅은 White-Box(Clear Box) 테스트와 Black Box 테스트두가지로다시분리할수있는데, White Box 테스트시스템의내부구조를이해하고, 내부구조를주요테스트대상으로삼는테스트이다. Black Box 테스트는시스템의내부구조보다는외부로노출되는기능과비기능에대한테스트를중점으로한다. 자동차를테스트한다고했을때차가잘가는지, 속도, 주행능력들을보는것이 Black Box테스트, 차의엔진이제대로작동하는지조향장치와같이내부구조를테스트하는것이 White Box 테스트가된다. 이는테스트의주체와도연결이되는데, White Box 테스트는내부구조를잘안상태에서수행해야하기때문에개발팀주도로이루어지고, Black Box 테스트는시스템의내부구조에대해서상세한이해없이도수행이가능하기때문에, 테스트팀주도로테스트가이루어진다. 이관점에서단위테스트와통합테스트는 Black Box 테스트관점에서접근하고, 시스템테스트와인수테스트는 White Box 테스트관점에서접근한다. 인수테스트 ( 테스트팀또는고객이출시전단계에수행 ) 인수테스트는개발이완료된후시스템을출시하기전에최종적으로수행되는테스트로고객의주도로테스트가이루어진다. B2C 서비스의경우에는알파, 베타서비스를수행하기도하고, SI 의경우에는 SI 발주고객의주도로테스트를수행한다. 인수테스트는다른레벨의테스트와는다르게결함의발견이목적이아니고제품의출시여부를판단하는것을목적으로한다. 인수테스트단계에서는요구사항과디자인스펙에대한준수여부는당연한범위가되고이외에도법적인사항 (Legal) 과사용자경험 (User Experience) 등을검증한다. 법적인사항의경우서비스나제품이해당국가의법률에위배되는것이없는지를검토한다. 예를들어한국같은경우에는위치기반서비스 (LBS) 를하기위해서는이에대한허가를국가로부터취득해야하며, 미국이나유럽의경우에는사용자의개인정보를국외에저장할수없도록되어있다. 또한구현부분에대한특허침해여부는없는지도법적인사항검증범위에해당한다. 오픈소스를사용했을경우에는오픈소스라이센싱정책을제대로지키고있는지도검토한다. 물론이러한사항들은시스템설계단계에서부터고려되어야하는사항이지만출시전에최종적인점검단계로생각하면된다. 다음은사용자경험 (User Experience) 검증부분이있는데, 실사용자를대상으로베타테스트를수행함으로써사용자인터페이스에대한검증을수행하는데, B2C 서비스의경우이러한사용자경험테스트는서비스의성공요인을결정하는매우중요점이된다.

인수테스트는단순히검증만을하는것이아니라시스템의출시여부를결정하는중요한과정이된다. 인수테스트결과에따라서시스템을출시할지아니면보강개발을하여출시시기를조율할지를결정하게된다. 아울러인수테스트단계에는최종적인보안테스트를수행하는데, 보안테스트는제품출시나서비스오픈후에도지속적으로수행하여, 보안결함이발견되었을경우에는보안패치를적용한다. 특히서비스시스템의경우에는별도의보안서비스팀을운영하여정기적인보안검사와이에대한지속적인보완을하는것을권장한다. 테스트레벨별주체와시점테스트레벨을언제적용하는지시점을다시정리해보자 단위테스트는 Sprint 가진행되는중에개별개발자나개발팀에의해서수행된다. Sprint가끝날때는 Short Release형태로, 시스템의완성된기능까지를 Release하는데, Release 전에개발팀의주도로개발된컴포넌트에대한통합을진행하고, 통합테스트를진행한다. Short Release가된버전은테스트환경으로이관되어테스트팀에의해서시스템테스트가진행된다. 이과정들을매 Sprint에걸쳐서반복적으로진행하고, 전체개발이완료되고시스템을출시하기전에고객을중심으로인수테스트를진행한다. 테스트싸이클 V 모델에서언급한각각의테스팅은다음과같은싸이클을반복적으로수행한다. 1 PRE-TEST ( 계통테스트 ) PRE-TEST는계통테스트라고하는데, 본격적인테스트를수행하기앞서서, 테스트환경의점검테스트시나리오를점검하는과정이다. 예를들어성능테스트를위한부하테스트를한다고했을때, 성능테스트를위한서버환경및부하발생기들을점검하고, 실제테스트에들어가기앞서서성능테스트스크립트의추출및스크립트가잘돌아가는

지등의검증작업을수행한다. 이러한계통테스트를별도로두는이유는소프트웨어가제대로개발되었다하더라도테스트에들어가면여러가지예상하지못했던문제들이발생하게된다. 방화벽이막혀있어서부하가안들어간다거나, 설정잘못으로인해서클러스터링들이안된다거나, 네트워크대역폭이충분하지않아서테스트용부하가제대로못들어간다던지상당히여러가지시나리오가발생하는데, 이런문제를푸는데는대부분타부서나타팀의협조가필요하게되고, 이는시간을필요로한다. MAIN-TEST의경우모든이해당사자가모여서테스트를진행하기때문에, MAIN-TEST의원할한진행을위해서는 PRE-TEST를통한계통이원할하게진행되어야한다. 이 PRE- TEST에서는테스트자체가잘수행되는지테스트자체를검증하는단계이지구축된시스템자체를검증하지는않는다. 성능이나오지않거나에러가나오는경우에대한해결은 MAIN-TEST 단계에서해결한다. 이계통테스트과정은짧게는 1~2일에서길게는 2~3주까지소요되기 ( 통상 1~2주가일반적임 ) 때문에테스트일정수립시에충분히반영해야한다. 이계통테스트과정이정상적으로이루어지지않으면, MAIN-TEST 단계에서참여한인력들이노는 (?) 현상이발생하여리소스와비용낭비가발생할수있다. 2 MAIN-TEST ( 테스트 ) MAIN-TEST는본테스트로, 테스트시나리오에입각하여테스트를수행하고, 목표기능에대한테스트통과여부를가리고, 통과하지못한경우문제점을파악및정의하는데까지를그범위로둔다. 일반적으로 MAIN-TEST를수행하는데있어서, 테스트조직은테스트를통과하지못하면테스트를통과하지못했다는것만을리포팅할뿐, 그원인에대한부분은언급하지않는데, 이것은잘못된방법이다. 성능테스트를예를들었을때목표성능에도달하지못했을경우병목구간분석을통해서, 어느부분이병목의원인인지까지분석하여개발팀에넘겨야한다. 이러한본테스트기간이아니라면전체시스템에대해서분석을할수있는이해당사자 ( 테스터, 개발자, 아키텍트, 튜닝엔지니어 ) 들이한자리에모일수없기때문에, 모였을때원인을파악하는것이효율적이다. MAIN TEST 수행시에는모든테스트시나리오와테스트절차와정황및데이타를문서로로깅해야한다. 이는버그나문제가있을때나중에해결을하기위한중요한정황자료로사용이되기때문에, 몇시에테스트시작, 테스트대상의환경정보, 버전정보, 테스트시나리오 O 번을수행, 이때 CPU, 메모리,IO 사용률, 부하발생기툴상황 등을제대로기록해야한다. 3 CONFORMATION TEST ( 확인테스트 / 재테스트 ) 확인테스트라고하는데, 테스트과정에서발견된결함이해결된후에, 결함이제대로해결되었는지검증을하는단계이다. 이전테스트에서발견된결함이해결되었는지검증하는테스트 이다. 4 REGRESSION TEST ( 회귀테스트 )

회귀테스트는앞단계에정상적으로수행된테스트에대해서 ( 통과된테스트 ) 다시테스트를수행하는과정이다. 회귀테스트를수행하는이유는소프트웨어개발이진척되거나또는기타요인의변화에의해서기존에잘작동했던기능이작동하지않는경우가있는데, 이렇게 변화에의한영향을검증 을함으로써기존기능이정상적으로작동하지않게되는경우 를조기에검출하기위해서테스트시에는회귀테스트를다시수행하는것이바람직하다. 회귀테스트의수행시점은일반적으로 PRE-TEST후, MAIN-TEST 전이좋다. PRE-TEST를통해서테스트환경이셋업되었음을확인한후에, MAIN-TEST를들어가기전에이번테스트버전이기존버전에어떤변화를줬는지를확인하기위함이다. 테스트의수행절차는 PRE-TEST로계통이끝난후에, MAIN-TEST를수행하는데, 매일테스트를수행하고, 문제가있는부분을일단위로리포트해서개발팀에전달하고, 단기수정이가능한부분에대해서는 MAIN-TEST 기간내에수정하여반영후 CONFORMATION 테스트를거친다. 만약, 테스트기간중에수정이불가능한결함의경우개발스케쥴에반영하여다음 SPRINT에서수정하여테스트할수있도록한다. 테스트범위조정 단위테스트를제외한모든테스트는테스트의범위가하나의시스템이된다. 단위테스트는독립적으로클래스나메서드만테스트하면되지만, 통합테스트부터는하나의비지니스컴포넌트단위의테스트를수행해야하며, 화이트박스테스트가아니라블랙박스테스트형태로수행이된다. 이테스트과정은테스트할수있는대상이명확해야하는데, 주로기능단위가주요테스트의시나리오가되고, 테스트의범위는이전 SPRINT 에서개발이완료된릴리즈버전을대상으로한다. 그래서테스트의범위는현재진행중인 SPRINT 의이전릴리즈버전을사용하며, 한 SPRINT 씩 느리게테스트를진행하며따라오게된다. SPRINT 가통상 4~6 주인것을감안할때, 테스트기간이

긴것처럼느껴질수있으나, 계통테스트, 주테스트를걸쳐서결함의발견과원인해결및리포 팅까지사용하면, 결코짧은기간이아니라상당히빡빡하게돌아가게된다. 테스트프로세스 그러면이전체테스트사이클에걸쳐테스트를수행하기위해서는어떤프로세스를거쳐야할까? 테스트의전체적인프로세스는다음과같다. 이프로세스는단위테스트과정에서는사용되지않고, 단위테스트이상의통합, 시스템, 인수테스트과정에서만사용된다. 단위테스트는개발자또는개발자와단위테스터가함께개발과정중에병행해서진행하기때문에이렇게복잡한테스트프로세스를필요로하지는않는다. 1) 테스트계획단계테스트의목적과테스트의범위정의테스트의목적을정의한다. 예를들어이번테스트에서는어떤기능을위주로보겠다던지, 성능을위주로보겠다던지안정성검증을목적으로하겠다던지와같이목적을정의한다. 목적이정의되었으면테스트의범위를정의해야하는데, 테스트의범위는크게세가지관점에서정의가가능하다. 첫번째는테스트를수행할시스템의범위, 하나의소프트웨어시스템은단하나의소프트웨어컴포넌트로구성되는경우는드물다. 비지니스로직, 사용자인터페이스, 데이타저장로직등으로나눌수도있고, 인터넷뱅킹, 타행연동, 대출시스템과같이각업무시스템으로나눠서범위를정의할수도있다. 두번째는테스트를수행할시스템의기능범위 테스트를수행할컴포넌트의기능을파악하고, SPRINT 계획에따라구현되어있는기능리스트 들을테스트의범위에포함시킨다.

세번째는테스트를수행할방법이다. 테스트수행방법은단순하게기능테스트만할것인지, 성능테스트, 안정성테스트등을할것인지테스팅타입을정의한다. 다음은테스트의데스크탑가상화를위한테스트계획의 목적과범위 를정의한샘플이다. 테스트대상시스템에대한구조파악 그림 0-1 테스트계획요약샘플 목적과범위가정의되었으면, 테스트계획을세우기위해서테스트대상시스템의구조를파악해야한다. 이과정은대상시스템의복잡도에따라서, 테스트의목적이정의된후, 범위를정하기전에수행하기도한다. 어떤기능을가지고있으며, 어떤컴포넌트들로구성이되어있으며, 상호연계가어떻게되어있는지를파악한다. 시스템의구조를파악하지못하고테스트를진행할경우에는테스트의성공실패여부만을판단할수있고, 실패시의원인파악이어렵기때문에반쪽짜리테스트가될수있으며, 또한구조파악없이는결함의발생가능성이높은곳을찾기가어렵기때문에정교한테스트가어렵다. 테스트대상시스템에대한구조파악이완료되면, 이구조를아키텍쳐문서로서술하는데, 다음과같은내용을포함해야한다.

업무컴포넌트정의시스템을구성하기위해서어떤업무컴포넌트들이구성되었는지를다이어그램으로서술한다. 소프트웨어배포구조각업무시스템이사용하는소프트웨어솔루션의배포구조를서술한다. 예를들어데스크탑가상화를예를들었을때, 가상화소프트웨어는 Hyper-V 를사용하였고, 사용자인증정보는 LDAP에저장하였다던지와같이업무컴포넌트가실제어떤솔루션으로구현되서배포되었는지를서술한다. 여기에는솔루션의배포구조뿐아니라, 정확한버전및디렉토리정보를포함해야하며, 특히로그디렉토리의정보를서술해야나중에다른사람이문제를추적할때손쉽게해당시스템에접근하여정보를수집할수있다. 하드웨어배포구조다음으로는하드웨어에대한배포구조를서술해야하는데, 어떤서버에어떤업무컴포넌트가배포되었는지등을서술한다. 특히서버뿐만아니라, 서버간을연결하는네트워크구성과, 스토리지 ( 디스크어레이등 ) 을어떻게구성하였는지를서술해야한다. 실제로잘조직화된개발팀의경우, 제품의구조에대해서설명을들으려면아키텍트보다는테스트엔지니어를찾으라고할정도로, 테스트엔지니어의테스트대상시스템에대한이해도는높아야한다. 테스트스케쥴정의테스트의범위가정의되었으면, 테스트활동을위한주요스케쥴을정의한다. 여기에는아주상세한테스트케이스별의스케쥴을정의하는것이아니라, 테스트의전체적인절차에필요한일정을정의한다. 테스트시나리오별의일정은향후디자인단계에서다시고려한다. Exit Criteria 정의 그림 0-2 테스트일정샘플

Exit Criteria는테스트의종료조건에대한정의이다. 매우중요한항목중의하나인데, 테스트가다완료되면끝나는거지별도의종료조건을정의해야하나? 하고반문을할수도있지만, 테스트에는자원이소모된다. 테스트를정상적으로모두종료한후에끝내면가장이상적이겠지만, 테스트기간이종료되면테스트를종료해야할수도있고, 테스팅에필요한비용을모두소모한경우도테스트종료조건이될수도있고, 또는테스트를모두수행하였으나, 테스트결과가모두성공이어야테스트를종료할수도있다. 테스트가끝나지않았는데, 테스트가종료된경우에는다음테스트단계에서해당테스트를포함해서하는등의추가적인품질보장전략이수립되어야하며, 시스템의목적과성격에따라서종료조건이정의되어야한다. 은행과같이 Mission Critical한시스템의경우에는테스트전체가종료되고, 테스트결과가모두성공인것을종료목표로해야하겠지만, ( 돈을다루는중요한업무이기때문에결함은바로은행비지니스에타격을줄수있기때문에 ) SNS 서비스를하는벤쳐기업같은경우에는 Time To Market ( 시장출시시간 ) 이중요하기때문에, 기간을종료조건으로잡고, 최대한중결함을테스트기간중에해결하되, 오픈후에경결함을해결하는전략을선택할수도있다. 테스트조직구성및비용산정 전체적인테스트의스케쥴과범위가정해졌으면, 이에투여되는인력의양을산출할수있다. 테스트를기간내에수행할인력들에대한조직을구성하고, 이들에대한인건비와제반비용 테스팅툴임대료, 부하테스트용 PC, 테스트환경구축비용등 을산정하여테스트에소요되는예산을산정한다. 이렇게작성된테스트계획문서는다른문서를참고하지않고도, 테스트하고자하는대상시스템의구조와기능을파악할수있어야하고, 어떤목적으로어떤기간내에누가얼마의비용으로테스트를수행하겠다는계획이일목요연하게정리되어있어야한다. 이는보고를위한것일수도있겠지만, 독립된문서를만들었다는사실자체가테스팅팀이해당테스트에대해서목적과범위그리고환경을이해하였고, 이를위한준비가되었다는확인이기도하다. 2) 테스트분석및디자인단계테스트에대한모든계획이수립되었으면, 이제실제테스트에대한상세디자인작업을수행해야한다. 테스트에대한전체적인계획은테스트리드가작성하였다면, 테스트에대한상세계획은테스트엔지니어에의해서작성되며절차는다음과같다. 테스트목적과기본원칙에대한리뷰먼저테스트수행자는테스트의목적과범위를리뷰하고테스트계획서를숙지한다. 그리고테스트의목적과, 범위, 일정, 인원별역할을기본으로하여상세테스트시나리오를작성한다. 테스트케이스디자인및우선순위설정

다음으로테스트범위에해당하는컴포넌트와각기능들에대해서상세테스트시나리오를정의한다. 이를테스트케이스라고하는데, 상세테스트시나리오는테스트대상시스템의릴리즈버전의기능을기준으로작성하고, 각기능에대해서테스트시나리오를작성한다. 예를들어 파일업로드 라는기능이있을때, 테스트시나리오는 1M,5M,10M,100M 일반파일업로드 10M,100M 동영상파일업로드처럼변수별로다양화될수있고, 5M 일반파일업로드중, 업로드컴포넌트장애 ( 강제종료 ) 5M 일반파일업로드중, 네트워크단선처리 다양한장애테스트시나리오등을만들수있다. 테스트시나리오에대한종류는 시스템테스트 의세부종류를참고하기바란다. 테스트케이스를정의할때필수적으로포함되어야하는내용은상세한테스트절차와, 테스트성공조건이다. 테스트절차는 STEP BY STEP으로테스트를수행하기위한절차를자세하게서술해야한다. 그리고 Exit Criteria는테스트성공조건은기능의경우기능의성공여부, 성능의경우에는구체적인성능수치 ( 응답시간, Throughput per second) 등을명시해서테스팅을수행해야한다. 특히성능수치의경우테스팅환경과운영환경이다른경우가많기때문에 ( 테스팅환경이운영환경보다작다.) 하드웨어사이즈의비율을고려하여테스팅환경에서의목표성능치를환산하는작업이매우중요하다. 그림 0-3 테스트시나리오예제 1

그림 0-4 테스트시나리오예제 2 테스트시나리오작성이완료되면, 각테스트시나리오에우선순위를부여해야한다. 우선순위를부여하는것은이상적인경우에는기간내에모든테스트를종료할수있겠지만, 기간이나비용과같은요인으로인해서전체테스트를종료할수없는경우를고려해야하기때문에, 우선순위를배정해야하며, 또한테스트에투여되는인력을조정하기위해서도우선순위조정이필요하다. 테스트결과가실패하더라도경결함이고서비스에큰지장이없는낮은우선순위의테스트인경우비용을소모해가면서외부기술엔지니어를불러올필요가없다. 우선순위가높은테스트케이스를테스트기간중앞쪽에몰아서배치하고, 테스트팀외부에서투여되는인원도앞쪽에몰아서집중배치하면중결함의발견과함께해결하는데까지효율적으로테스트를진행할수있다. 테스트데이타준비테스트시나리오가완료되었으면다음으로테스트에사용할데이타를준비해야하는데, 테스트데이타는해당도메인에 ( 업무 ) 유사한데이타라야한다. 가장좋은데이타는기존에유사서비스를했던시스템이있을때의자료를기반으로테스트데이타를작성하는게좋다. 기업시스템의경우에는어떤형태로던지유사데이타가존재한다. 은행에서계좌계설시나리오의경우에는이미월별, 일별로평균과최대계좌개설건수에대한데이타가존재하며, 기존유사서비스가없는경우에는시스템요구사항서의용량계획서를참고하도록한다. 전세계 1억명을동시에사용할수있도록하는시스템 과같은용량목표는테스트데이타준비에유용하게사용될수있다. 테스트용데이타는최대한실운영환경과유사하게작성되어야하며필요에따라서는테스트데이타를생성하는툴를개발해서데이타를생성하는것을권장한다.

테스팅환경및툴준비 테스트시나리오와데이타가준비하면서테스트를수행할환경과툴을준비해야한다. 테스팅환경에대해서는 개발환경 부분에서다시언급하겠지만, 테스팅환경은개발환경과별도의분리된환경을구축하는것을권장한다. 부하를넣고서버를강제로다운시키는것과같은터프한테스트를진행하는데개발환경과테스트환경을겸해서사용할경우개발자체가중단될수있고, 이는비용절감이아니라개발일정증가로인한추가비용증대를발생시킬수있다. 이와더불어서테스트툴에대한셋업을병행해야하는데, 부하테스트툴의경우에는컨트롤러장비와함께부하발생용장비를따로요구하기때문에이에대한준비와라이센스설치등을병행해야하며, 특히테스트중에테스트환경이운영환경과같은네트웍대역폭을공유할경우에는테스트부하로인한네트워크부하가운영에영향을줄수있기때문에이를철저하게분리할필요가있다. 테스트환경구축은테스트를위한툴뿐만아니라릴리즈된시스템을테스트환경에배포하는것을포함한다. 테스트때마다이렇게테스트환경을구축하고장비를확보하는것은여러모로비용과시간이많이드는작업중의하나인데, 만약에사내에개발과테스트를위한클라우드환경을가지고있으면테스트환경을테스트기간중에만클라우드를이용하여사용하고, 테스트가끝난후에는보관하였다가다음테스트환경에서다시로딩해서사용할수있기때문에환경구축에대한시간을절약할수있으며, 해당환경을다른시스템에대한테스트로도사용할수있기때문에여러자원활용의효율성을기대할수있다. 3) 테스트케이스구현및수행단계테스트에대한상세디자인이완료되었으면테스트케이스를구현하고테스트를진행하고그결과를수집해야한다. 이단계가테스트구현및수행단계이다. 테스트케이스구현및스크립트작성설계된디자인에따라테스트케이스를구현하고테스트용스크립트를구현한다. 개통테스트 테스트케이스가구현되었으면테스트케이스가제대로작동하는지테스트케이스자체를테스트한다. 이과정에서테스트환경에대한검증이이루어진다. 네트워크의연결상태, 환경설정정보등이검증된다. 테스트준비과정에서가장많은시간이소요되는부분이기도하다. 개통을하기위해서는환경이제대로작동해야하며, 특히외부연동시스템이있을경우에는외부연동시스템과 API 연동규약이제대로준수되어야하며, 연동대상시스템의테스트환경이제대로확보되어있어야한다. ( 방화벽, 부하테스트시발생한데이타를저장할수있는공간등 ).

환경검증부분에대한시간소요와외부연동시문제가있었을때, 외부팀에대해서협조를구 하는시간이가장많이소요되는부분으로사전준비에많은노력을기울일필요가있다. 테스트수행과결과수집 모든테스트케이스구현이완료되었으면테스트를수행한다. 테스트수행은초기데이타를먼저로딩한다음에테스트케이스를실행한후, 테스트결과와자원의사용률을기록한다. ( 기록이중요하다 ). 모든테스트가끝나면테스트에의해생성된데이타를초기화한다. 자세한테스트수행프로세스는앞의 테스트싸이클 을참고한다. 결함리포팅 그리고테스트시발견된결함을기록하고, 결함이발생하였을때는가능하면재현테스트를할수있도록결함의발생순서를함께기록한다. 4) 테스트결과평가및리포팅단계테스트결과정리 모든테스트가종료되었으면, 테스트결과를문서화하여정리한다. 이문서에는테스트계획, 디자인문서에서부터개별테스트시나리오및테스트결과가모두포함되어야하며, 다른문서를참조하지않고이문서만보더라도테스트대상시스템을이해하고테스트의목적과내용결과를이해할수있도록작성되어야한다. 그리고품질의경우여러관계자가관심을가지고있는부분이므로, 보고해야할대상이많기때문에테스트의문서를보고대상에맞게여러본을작성할필요가있다. 상위레벨메니져를위해서 5장내외의테스트결과요약문서를작성한다. 이문서에는테스트계획과함께가장중요한것은소요비용과테스트결과로인해서판단할수있는현재대상시스템에대한품질상태를포함해야한다. 품질상태는테스트커버리지, 테스트성공률, 발생한결함의수와중요도등을포함한다. 결함이나테스트내용자체는상위레벨메니져의경우그내용을이해못하는경우가많기때문에 ( 상위레벨메니져는디테일한기술적인내용에대해서이해하기가어려운경우가대부분이다.) 결함의수나, 커버리지등의정량화된품질지표를이용하여현재품질에대한이해를도와야한다. 개발팀을위한테스트결과서도필요한데, 이문서는결함에대해서중점적으로기록되어야하며결함의내용및결함발생시의상황 (CPU등의자원의사용률과로그정보 ), 그리고결함의재현순서를자세히기록하여개발팀이결함을재현및수정할수있도록한다. 테스트프로세스및결과평가 매번테스트가끝날때마다테스트를수행한프로세스를리뷰하고결과에대한평가를수행해야 한다. 특히애자일방법론을사용할경우테스트는연속해서이루어지기때문에매번테스트가

끝날때마다프로세스를최적화하여다음테스트에더높은효과를얻을수있도록한다. 테스트프로세스를리뷰해보면한두번의테스트는조직이테스트프로세스에적응하는시간이필요하다. 프로세스의최적화는문서리포팅포맷과보고체계, 그리고팀내외부의커뮤니케이션과협업과정에서의최적화가많이필요하다. 테스트의디자인및수행자체는전문화된테스트엔지니어만있다면가능하지만, 위에서언급한작업들은조직의개발체계나, 보고체계와같이조직마다문화가다르기때문에주요최적화대상이된다. 테스트조직구조 테스트를수행하는테스트팀의구조는테스트방법론이나개발조직, 개발팀의개발방법론에따 라모두차이가있다. 여기서는일반적으로적용할수있는테스트조직구조에대해서소개한다. 각각의역할은중첩될수는있으나, 생략될수는없다. 테스트팀테스트팀은테스트를계획하고주도적으로수행하는팀이다. 테스트팀의일반적인구조는다음과같다. Test Lead 전체테스트에대한모든것을관장한다. 테스트팀관리뿐만아니라시스템에대한전체품질관리를포함하여관리한다. - Define strategy, methodology : 시스템의품질보장을위한테스트전략과운영할방법론을찾고, 조직에맞게테스트방법론을설계및수립한다. - Define Process : 시스템개발및테스트단계에서운용할테스트프로세스를수립한다. 테스트프로세스는테스트팀만이사용하는방법론이아니라, 개발및출시전과정에서적용해야한다. 즉테스트팀뿐만아니라개발팀에서도사용해야하며, 출시여부를결정하는마케팅팀에서도이테스트프로세스에영향을받는다. 수립된테스트프로세스는 FIX된체로운용되는것이아니라적용과정을거쳐서시스템과조직의성격에맞도록계속해서성숙시켜나가야하는데, 이역할역시 Test Lead가담당해야한다.

- Manage test project : 테스트팀을운용하고관리한다. 인원을뽑는것에서부터, 일정관리, 예산관리와같이팀관리에해당하는모든업무를수행한다. - Communicate with other team : Test Lead의역할중가장중요한역할중하나가, 다른팀과의의사소통가교역할을하는것이다. 테스트는테스트대상을가지고있으며, 제품출시여부를결정기준이되며, 테스트중발견된결함을개발팀에서수정되어야하며, 테스트운영을위해필요한인원에대한채용, 테스트에필요한툴구입을위해서예산을확보해야한다. 이러한모든작업은테스트팀자체적으로해결할수없고타팀과의협업을통해서만해결할수있기때문에, 타팀과의의사소통은매우중요한역할이다. - Educate team : Test Lead는테스트수립된전략과프로세스, 방법론에따라테스트팀및개발팀이테스트작업을수행할수있도록교육을진행한다. - Define matrix : 시스템에대한품질, 테스트팀의진척률, 개발프로세스에대한품질등을체크할수있는정량화된 ( 수치화된 ) Matrix 표를정의한다. 여기에사용될수있는 Matrix 는다음과같다. 1) Defect / KLOC : 소스코드 1000라인당발견되는 Defect의수 2) Test Coverage : 전체테스트대상에대해서테스트가커버하는범위로, 전체소스코드에대한테스트가커버한소스코드라인 ( 라인커버리지 ), IF와같은분기문에대한커버리지를분석하는브랜치커버리지, 전체기능대비테스트한기능에대한기능커버리지등이있다. 3) Defect / Hour : 개발시간별발생한 Defect 수 4) Days test effot / Requirement : 하나의요구사항에대해서테스트하는데소요된날짜이러한 Matrix는전체적인제품의품질현황이나개선추이를그래프로한눈에알아볼수있기때문에많은도움이되며, 특히 Defect/KLOC, Defect/Hour 등의척도는개발과정에서발생하는결함의수와이를해결하는데필요한리소스를산정할수있는지표이기때문에, 개발과정에서소요되는테스트비용과인력계획의기반자료로사용할수있다. Test Designer 테스트디자이너는 Test Lead에의해정의된전략, 방법론, 프로세스에따라테스트대상시스템을분석하고, 상세테스트전략을수립한후상세테스트케이스를디자인한다. - Analysis & design test requirement : 테스트대상시스템의기능, 요구사항과상세아키텍쳐를파악하고, Defect가발생될수있는부분을탐색한후에, Defect의가능성이있는부분을중심으로, 테스트전략을수립한다. - Design test case : 테스트전략을기반으로, 상세테스트케이스를설계한다.

Test Operator 설계된테스트케이스디자인에따라서상세테스트케이스를구현및수행한다. - Implement test case : 테스트디자이너를기반으로상세테스트케이스를구현한다. - Execute test case : 테스트를검증하고, 테스트과정에서구현된테스트를수행한다. - Result document : 테스트수행과정에서나온데이타를수집하고, 결과를리포팅한다. - Generate defect report : 테스트과정에서결함이발견된다면, 결함의내용과결함의발생절차를기록한다. - Track defect : 향후결함을개발팀과함께 FIX할때, 개발자와함께 Defect에대한수정에대해서의사소통을하고, 결함의해결과정을자세하게리포팅한다. - Test tool set up : 필요에따라서테스트에필요한툴를셋업한다. Test Environment Manager 일반적인테스트조직에서는존재하지않는경우가많은데, 테스트환경을셋업하고유지하는역할을한다. 테스트환경이란, 테스트대상이되는대상시스템을테스트환경에배포한환경과테스트를위해사용되는부하발생툴등의테스트툴, 테스트과정중대상시스템을관측하기위한모니터링시스템그리고테스트에서발견된결함을로깅하기위한결함관리시스템등으로구성된다. 이런테스트환경의구성은개발팀또는테스트엔지니어가겸하는경우가많은데, 테스트환경구축자체가많은시간이들기때문에이를구축하는개발자나테스트엔지니어의리소스가허비되고이로인해서개발일정이나테스트일정에차질을가지고올수있기때문에명시적으로테스트환경을셋업하고유지하는역할을만들필요가있다. 그리고개통테스트단계가많은시간이소요되는경우가많은데, 개통테스트에많은시간이소요되는주요한원인은테스트환경셋업과점검에서발생하는경우가많다. IP가틀리고, 설정정보가잘못되고, 제대로문서화되어있지않은등에사소한문제인경우가대부분인데, 이러한문제를사전에예방하기위해서, 구축도중요하지만해당환경을계속적으로유지해야반복적인회귀테스트가가능하다. - Set up test environment : 테스트대상시스템을테스트환경에배포하고, 테스트에필요한테스팅툴와모니터링툴들을설치관리한다. 그리고이환경에대한설정정보를문서화하여관리한다. - Monitor environment during test : 테스트가진행되는중에모니터링툴를이용하여테스트환경인프라와테스트시스템등에대한모니터링을수행하고, 테스트진행중환경에

대한모니터링정보를저장한다. 외부지원팀테스트는대상시스템에대한검증을수행하는작업이다. 작게보면테스트를수행하는조직이만들지않은외부의것을검증하는작업으로, 테스트의주체는테스트대상을잘알지못한다. 그래서테스트에필요한기술적인지원이필요하다. Development Team 테스트환경에대한설정에서부터 Defect 에대한해결까지개발팀에대한지원은필수적이다. - Support test environment set up : 테스트환경에개발대상시스템을배포한다. 개발대상배포시스템의설치는테스트팀이독립적으로수행할수는없고테스트대상시스템에대한지식이있어야하기때문에개발당사자인개발팀의지원은필수적이다. - Fix defect : 발생된결함에대해서테스트엔지니어로부터현상과관련자료를받아서, 결함을수정하고이에대한확인작업을같이수행한다. - Monitoring test : 테스트과정중에테스트대상시스템에대한모니터링을수행한다. System Engineer 시스템엔지니어는테스트대상시스템이외의테스트툴, 모니터링툴, 하드웨어인프라나 RDBMS 또는미들웨어등에대한모니터링작업을지원하는엔지니어이다. 테스트대상시스템에대한지식은개발자가알고있지만, 미들웨어와같이개발에사용한기반시스템등에대한지식은미약한경우가많기때문에, 제품에대한전문적인지식을가지고있는기술지원엔지니어의지원이있다면조금더효율적인테스트가가능하다. - Monitoring & Tuning : 테스트대상시스템이외의부분 ( 위에언급한부분 ) 에대한제품모니터링과튜닝을지원한다. 테스트케이스의우선순위결정방법 위험도기반의우선순위결정 테스트케이스의우선순위를결정하는방법은여러가지가있지만, 여기서는위험도기반의우선순위결정방법을소개하고자한다. 결함의위험도는발생가능성과, 발생시심각도를기반으로판단할수있다. Risk = Likelyhood ( 발생가능성 ) * Impact ( 발생시심각도 ) 발생가능성은측정방법은소스코드의복잡도, 구현난이도, 테스트대상기능의구현크기 ( 소 스코드라인수 ), 해당모듈을개발한개발자의수준등의기술적인내용을통해서판단할수있고

발생시심각도는이기능에대해서장애가발생하였을때, 비지니스적으로끼치는타격을기준으로작성할수있다. 이렇게테스트케이스별로 Risk Factor를계산하여, 상위 36개정도의테스트케이스를집중관리하면중결함을크게예방할수있다. 이렇게 Risk 항목을도출하여, 표로그려보면위와같은 4개의영역으로분할할수있는데, STA(Server Test Area) 영역 : 발생가능성도높고, 발생시타격이큼 SSTA(Strong Test Area) 영역 : 발생가능성은낮지만, 발생시타격이큼 ITA(Intensive Test Area) 영역 : 발생가능성은높지만, 발생시타격이작음 FTA(Fundamental Test Area) 영역 : 발생가능성도낮고, 발생시타격도낮음테스트의 Level에따라서우선순위를정할수있다. 발생가능성이높은경우는대부분기술적인요인에서발생하기때문에, 단위테스트나통합테스트와같은기술적인 Low Level 테스트단계에서집중적으로커버하는것이좋다. 그래서단위테스트와통합테스트는 STA ITA SSTA FTA 순으로진행하고, 비지니스임팩트가큰결함에대해서는 High Level 테스트단계인시스템테스트와인수테스트단계에서진행하는것이좋으며 STA SSTA ITA FTA 순으로진행하는것이좋다.

복잡도기반의우선순위산출 코드의복잡도가높을수록결함의발생확률도올라가는데, 코드의복잡도를측정하는방법중의 하나가 Cyclomatic Complexity 라는방법이있다. Cyclomatic Complexity 는 ( 분기조건의수 + 1) 로계산된다. 즉 if,while,switch,or 연산등분기문이많으면코드의복잡도가높아진다는이론인데, 사실이그렇다분기문이많으면실수를할확률도높아진다. 그렇다면이복잡도를산출하기위해서일일이코드를다뒤져야하는것인가? 다행이도 Cyclomatic Complexity를계산해주는여러툴들이있다. Cyvis(http://cyvis.sourceforge.net/screenshoots.html) 그래프로자바코드의 Cyclomatic Complexity를계산해줌 PMD(http://pmd.sourceforge.net/) 코드복잡도계산뿐만아니라뒤에설명될정적분석기능도포함하고있음 테스트커버리지 테스트커버리지는 테스트대상의전체범위에서테스트를수행한범위이다. 즉테스트대상을얼마만큼테스트를했냐는것을정의하는것으로, 테스트의정확성의하나의척도가될수있다. 테스트커버리지에서분수의분모수를결정하는것이가장중요한데, 테스트의범위를무엇으로측정할것인가이다. 가장쉬운방법은테스트대상기능을모수로하는방법이가장일반적이고쉬운방법이다. UI 가많은시스템의경우전체화면수를모수로도사용할수있다. 주로 High Level Test 인 System Test 나 Acceptance Test 의경우이와같이기능이나컴포넌트들을모수로하여테스트커버리지를분석한다. 기능기반의경우에는테스트커버리지를 100% 달성하는것을목표로한다. 왜냐하면일단정의된기능은모두테스트하는것이상식이니까라인커버리지 재미있는것은 Low Level Test인 Unit Test나 Integration Test인데, Unit Test의경우기능을중심으로테스트를하는것이아니라 Class나 method를테스트하기때문에기능자체를테스트커버리지의모수로삼을수가없다. 그래서다음과같은모수를사용하는경우가일반적이다. 테스트대상시스템의전체 Class 수 테스트대상시스템의전체 method 수 테스트대상시스템의전체소스코드 Line 수

특히전체소스코드 Line 수대비, 테스트시나리오가거쳐가는소스코드의 Line 수를측정한것을라인커버리지라고하는데, Unit Test 에서는이라인커버리지를척도로삼는경우가많다. 고품질의소프트웨어개발팀의경우에는라인커버리지의목표를 80% 로잡는데, 이건상당히잘조직화된개발및테스팅조직이있을경우에나가능하다. 일반적인국내 SI 개발팀의경우단위테스트의개념자체가약하고, 테스트케이스구현레벨이떨어지기때문에이를습득하는시간이필요하며, 테스트케이스자체를개발하는시간은개발시간 ( 고객이 ) 에포함하지않고예산에산정된경우가많기때문에, 80% 라인커버리지를달성하기위해서는개발자의업무부담이작게는 20% 에서많게는 50% 까지가중될수있다. 그래서국내 SI 환경에서적절한라인커버리지는전체시스템중 40% 를난이도가높거나중요한시스템을기준으로산정하여이시스템에대해서 80% 의라인커버리지를달성하는것을목적으로하고, 나머지 60% 시스템에대해서는 60% 의라인커버리지를유지하는것이좋다. 이커버리지를관리할때는자바의 PACKAGE 단위로나눠서관리하면여러가지로관리가편하다. 중요모듈의 PACAKGE 를정하고, 각 PACKAGE 의라인커버리지는 Class 커버리지는 100% 로하고, 각 Class별평균라인커버리지를 80% 로맞추는정책을사용하면쉽게정량적인측정이가능하다. 브랜치커버리지 브랜치커버리지란 if나 switch 같은분기조건문에대해서각조건에대해서테스트가얼마나커버하고있느냐를나타내는수치이다. 예를들어다음과같은중첩 if 문이있다면 // IF A If(condition){ // IF B If(codition) // do something else // do something }else{ // do something } 두개의 IF 문이중첩되어있기때문에첫번째 IF문에서분기되는경우가 2가지, 두번째 IF 문에서분기되는첫번째분기문에대한조건에대해 2가지경우의수가나타나기때문에총 3개의경우의수가나타난다. 첫번째 IF문 True True False 그래서브랜치커버리지의분모수는 3이된다. 두번째 IF문 True False N/A

라인커버리지이외에정확한테스트를위해서는브랜치커버리지를분석해야하는데, 복잡도가매우높기때문에서버애플리케이션에서는왠만해서는이브랜치커버리지를측정하지않으며임베디드시스템과같이비교적서버에비해서소스코드가작고분기조건이 Critical한경우에주로사용하게된다. 마이크로벤치마크테스트 마이크로벤치마크란소규모의부하테스트를의미한다. 비기능적결함의특징중의하나가많은부하가아니라소규모부하를주더라도성능문제나, 병목, 안정성, 확장성등의문제는쉽게들어난다. 소규모부하에서도들어날문제라는것은반대로이야기하면그정도로시스템의완성도가떨어진다는것으로, 중결함이대부분이다. 비기능테스트는앞서설명한테스트프로세스에서본것과같이많은준비와수행인원과시간과비용이소요된다. 마이크로벤치마크테스트는개발팀이나소규모의테스트팀으로소규모의부하를줘서중결함을 1차적으로필터링하는개념으로, 릴리즈된시스템뿐만아니라개발진행중인시스템또는프로토타입 ( 탐색개발 ) 에대해적용할수있으며초기에중결함을찾아내는데유용하다. 소규모의부하만주면되기때문에가격이높은부하테스트툴를사용하지않아도되며, 단위테스트를멀티쓰레드로돌려서부하를주거나오픈소스부하테스팅툴 (SOAPUI, Apache JMeter,Japex) 등을사용해도충분하다. 마이크로벤치마크테스트는일반적으로 10~30 동시사용자정도면수행이가능하고, 상황에따라서전용테스트프로그램을만들어서도수행할수있다. 마이크로벤치마크의가장큰특징은테스트의주체가대규모테스트팀이아니라개발팀이나소규모테스트팀에서수행한다는것을들수있으며, 투자대비효과가매우좋은테스트기법이다. 필자의경우에는개발시시스템에대한아키텍쳐설계후프로토타입핑후에, 마이크로벤치마크테스트를수행하여아키텍쳐의건정성을검증하거나, 여러오픈소스솔루션에대한선택결정이필요한경우자주사용하였다. 테스트환경 테스트를준비하고진행함에있어서가장간과하기쉬운부분이전용테스트환경을구축하는 것이다. 보통테스트는개발환경에서진행하거나또는오픈전에운영환경에서진행하는것이 일반적이었다. 전통적인 Water-fall 모델이라면이방법도나쁘지는않다. 그러나, Interation 기반의애자일방법론을사용한다면이야기가틀려진다. 테스트를진행하는중에도개발팀은계속해서다음 Iteration(Sprint) 개발하고있기때문에, 개발과테스트가상호간섭을줘서개발과테스트를원할하게이루어지지못하게한다. 이는개발자와테스트엔지니어의리소스낭비로이어지는데, 이를

해결하기위해서는테스트환경을분리해서운영하는것이좋다. 비용적인문제때문에테스트환경을별도로운영하는것을꺼린다면, 가상머신 (Virtual Machine) 기반의서버나클라우드환경을이용하여테스트시에만일시적으로테스트환경을운용하는것도좋은방법이다. 단이경우에는다음테스트에대한영속성을위해서테스트가끝난후에는 Virtual Machine Image를저장해놓고, 다음테스트에다시로딩해서사용해야한다. 개발, 서비스환경은크게아래와같이 3 가지단계로구분할수있다. 개발을위한개발환경, 테스트를위한전용테스트환경과실운영환경이다. 이 3가지환경은가능하면물리적으로분리되는것이좋다. 네트워크대역을나누고, 공유디스크를분리하는등의작업이필요한데, 특히부하테스트시에네트워크의대역폭이급격하게차거나 CPU 사용률이급격하게올라가는경우, 이환경들을공유했다면다른환경에영향을줘서뜻하지않은장애나결과를유발할수있다. 물리적인환경분리가불가능하다면, 네트워크는 VLAN과같이소프트웨어를이용하여논리적으로분할을하고, 공유디스크의경우, IO Segregation 기법을사용하는것도좋다. IO Segregation 이란공유디스크로서버에 Attach 되는볼륨에대해서별도의물리적디스크로분리하여서로간의 IO 성능간섭을줄이는방법중의하나이다. 테스트환경시에신경써야하는점중의하나는독립적으로작동하는시스템이아니라다른시스템과연동을하는시스템의경우에는연동시스템에대한테스트환경이별도로구성되어있어야한다. 마찬가지로연동대상시스템에대해서개발환경이나운영환경을쓰면같은문제점이발생한다. 만약에연동대상시스템도개발중이거나아직배포가불가능한경우에는 Mock up 환경이라는

것을만드는데, Mock Up 환경은연동테스트를위해서사용하는일종의껍데기환경으로특정 Input 에대해서기계적인 Output 만을내도록하는테스트전용환경이다. Mock up 환경을먼저 구축하여테스트를진행한후에, 점차적으로실연동환경으로전환하는방법을사용하도록한다. 결함관리방법 지금까지는결함을발견하는테스트에대해서설명했다. 그러면결함이발견된후에, 결함에대 한처리와관리방법에대해서설명한다. 결함처리프로세스 테스트팀에의해서결함이발견되었으면테스트팀과개발팀이협업하여해결해야한다. 이결 함을처리하는프로세스는다음과같다. 1 Report Defect : 테스트팀에서발견된결함은결함관리시스템 (Defect Management System) 에기록된다. 2 Yank Defect : 개발팀에서는자신팀이맏은모듈에서발생한 Defect를꺼내서가지고온다. 3 Assign Defect : 개발팀리드는 Defect를개발팀의일정과리소스, 그리고담당에따라서개발자에게배치한다. 4 Fix Defect : Defect를할당받은개발자는담당테스트엔지니어와함께재현과추적등을통해서 Defect를수정한다. 5 Conform Fix & Add Test Case : Defect가수정되었으면, Defect를검증할수있는단위 Test Case를보강하여 Fix 된코드와함께, 소스관리시스템에저장한다. 6 Change defect status to Resolved : Defect Management System에해당 Defect를해결됨 (Resolved) 상태로바꾸고, 테스트엔지니어에게다시배당한다. 7 Conform Test : 테스트엔지니어는해결된 Defect를다시테스트하여문제가없는지검증한다.

8 Close the defect : 문제가없을경우에는해당 Defect를 Close한다. 만약문제가해결되지않았으면다시 Defect Management System을통해서해당개발자에게다시 Assign하고 4번단계에서부터다시반복하여해결한다. 결함프로세스를만들때는가장중요한것은단순해야한다. 복잡한프로세스는다수의사람에게적용하기도힘들고, 교육과적응시간도오래걸린다. 여기서소개한결함처리프로세스는일반적인프로세스이다. 제품의성격 ( 엔터프라이즈용인지, B2C용인지 ) 에따라서도차이가나며, 회사의성격이제품을개발해서판매하는행태인지, 제품을구매해서사용하는형태인지, 자체개발해서서비스하는형태인지에따라서도결함처리프로세스가변경되어야한다. 이프로세스의기본흐름에따라서각조직에맞춰서변형을해서프로세스를재수립해야한다. 결함리포팅 테스트중에발견된결함은결함관리시스템 (Defect Mangement System) 에등록해서관리하는데, 다음과같은항목을가지고관리한다. 1 Number ( 번호 ) : 결함의고유번호이다. 2 Title ( 제목 ) : 결함의내용을간단하게한줄로기록한다. 3 Description ( 설명 ) : 결함에대한자세한내용을서술한다. 구체적으로어떤결함인지, 그리고결함을재현하는절차와분석내용들을서술한다. 4 Module ( 모듈 ) : 전체시스템중에서결함이발견된컴포넌트나모듈명을명시한다. 이모듈의분류를잘정의하는것이중요한데, 모듈은개발의세부조직과맵핑될수도있고, 시스템구조또는기능들과맵핑될수도있는데처음에이구조를잘못잡아놓으면향후결함처리에많은혼선을야기한다. 특히결함을다시개발팀에서배분할때, 이배분의기준이모듈이되기때문에이부분을잘정의해야한다. 5 Version & Fixed Version ( 발견버전과수정버전 ) : Version은결함이발견된버전, Fixed Version이해당결함이해결된버전이다. 이항목은매우중요한항목인데, 결함은버전에따라서다르게발생할수있기때문에반드시이항목이정의되어야한다. 결함수정은제품의다음버전에반영하는것이일반적이지만, 다음버전출시일이늦거나필수적인패치가아닐경우에는반영을하지않고패치를사용해서해결하는경우가있기때문에, 나중에운영환경에서이결함으로인한문제가발생하였을때, 이결함이제품에반영되었는지여부와반영이안되었을경우어떻게해결하는것인지 ( 패치적용등 ) 를확인할수있어야한다. 6 Servirity, Priority ( 시급도와우선순위 ) : 시간적으로빨리처리해야하는경우시급도가높은것을의미하고, 결함의우선순위는위중도 ( 위험도 ) 를의미한다. 결함의우선순위가높을수록중결함이되고, 낮을수록경결함이된다. 시급도가높은결함중우선순위가높은결함을우선적으로처리한다. 시급도와우선순위는각각 5단계정도로나눠서정의하는것이바람직하며, 일반적인결

함은중간단계인 3단계정도로하며, 시급도와우선순위가가장높은결함의경우에는최우선적으로처리해야하기때문에긴급하게개발팀과테스트자원을투여해야한다. 그래서개발일정에영향을줄수있다. 이런이유로시급도와우선순위를 1단계까지높이는것은개별테스트엔지니어나개발자가할수있는일이아니고, 해서도안된다. 우선순위를 1순위로올리는것은반드시개발팀이나테스트팀의관리자승인을통해서올려야한다. 우선순위나시급도에따라서결함처리정책을내부적으로정의해놓을필요가있다. 예를들어우선순위 2 등급의결함이발생되었을경우에는 20분내에개발팀에게해당문제가할당되어야한다던지, 1 등급결함의경우에는개발팀이소집되어야한다던지와같은결함해결정책을정의한다. 최상위순위는일종의비상사일렌이라고생각해야한다. 예전에미국의소프트웨어회사에서기술지원을업무로하는부서에서일한적이있는데, Priority가 1로올라가는것을본적이없는데, Priority 1 상황은원자력발전소정지나국가기간시설정지, 병원시스템정지와같이높은수준의장애에서만사용될수있었다고한다. 7 Status ( 결함처리상태 ) : 현재결함이처리되고있는상태를기록한다. 이결함처리상태는결함처리프로세스와도연동이되기때문에, 뒤에자세하게다시설명하도록한다. 8 Fixed code ( 코드수정내용 ) : 결함을수정하였을경우에는수정내용을기록해야한다. 결함내용수정은소스코드수정인경우가많은데, 이때는소스코드수정내용을기록한다. 별도로소스코드내용을기록하는것보다는소스코드관리시스템 (SCM) 에수정코드를반영한버전 (Revision Number) 을기록해놓으면된다. 요즘은소스코드관리시스템들이 Revision Number에서소스코드가수정된내용을 diff등의툴를이용해서보여준다. 아래는 Atlassian 社의 Fish Eye라는툴로, 소스코드의변경사항등을추적해주는툴의 Revision 별소스코드변화를표시해주는화면이다. 이렇게결함해결전후의코드변화를보면, 어떻게결함을해결했는지를알수있고, 유사결함이나또는여러개의버전을가지고있는제품의경우이내용을바탕으로수정내용을다른버전에반영할수있다.

9 Attachment ( 첨부파일 ) : 결함을기록할때는첨부파일을사용하는데, 이첨부파일은결함발생당시의로그나데이타 (CPU 사용률, 네트워크상황 ), 결함을추적하는데사용된코드나샘플, 결함이해결되었을경우패치같은것을첨부한다. Defect Management System에저장되는각결함케이스에는위의정보를포함해서, History 정보가남게되는데, 이 History 정보는테스트엔지니어와개발팀이주고받은이메일과, 전화통화내용그리고결함을해결하는과정에서서로의의사소통내용이모두포함되어야한다. 나중에어떤사람이이결함에대한케이스정보를보더라도, 결함의내용, 원인그리고해결순서와방법이일목연하게서술되어있어야한다. 결함의상태정의 결함의해결과정을추적하기위해서결함을로깅할때는처리단계별로상태를기록하여야한다. 다음은결함의처리과정에따라서상태에대한정의방법이다. 1 New : 테스트과정에서결함이발견되어결함관리시스템에등록된상태이다.

2 Opened : 등록된결함이개발팀에게넘어갔을때의상태를 Opened라고한다. 결함이발생한모듈을개발한개발팀에게결함이전달된상태로, 아직담당자는정해지지않은상태이다. 3 Assigned : 결함을수정할개발자에게결함이할당된상태이다. 4 NMI (Need More Information) : 추가정보가필요함 상태로, 개발팀에서결함의내용을검토했을때, 결함의원인과정확한증상들을확인할수없을때, 추가적인로그나재현절차를테스트팀에다시요구하는상태이다. 개발팀은자료가부족한결함에대해서 NMI 상태로바꾼후에, 결함을보고한테스트엔지니어에게다시배당한다. 5 In Progress : 개발자가결함을확인하고, 수정작업중인단계이다. 6 Postponed : 결함처리과정에서결함의중요도가낮거나다른결함수정일정또는개발일정에따라서우선순위조정이필요할때, 결함의처리를미뤄놓는 ( 지연시키는 ) 상태이다. 7 Resolved : 결함이해결된상태이다. 해결은되었으나, 개발팀차원에서결함이해결된것이고, 아직테스트팀으로부터결함에대한재테스트를통한확인을받지못한상태이다. 결함이 Resolved 상태로바뀌면개발팀은확인테스트를요청하기위해서테스트팀에다시해당결함을 Assign 한다. 8 Closed : 테스트팀에의해결함의수정내용이확인되고제품의소스코드에반영된상태로, 결함처리의최종단계이다. 약 8 가지단계만간략하게소개하였는데, 전이되는상태는적을수록좋다. 또필요하면많아도된다. 중요한것은개발팀과테스트팀이이결함의상태를이해하고효율적으로이해할수있도록협의가되고프로세스에녹아들어야한다. 결함관리툴 결함을관리하는툴를 Defect Management System, Bug Tracking System 또는 Issue Tracking System이라고한다. 대표적인상용툴로는 HP QC (Quality Center), IBM Clear Quest 등이있는데, 이제품들은다양한기능과프로세스를지원하지만무겁고복잡하다. 조금가볍고실용주의적인제품으로는 Atlassian 社의 JIRA라는툴가있다. 아는사람들은모두다아는 Issue Tracking 시스템으로결함관리뿐만아니라개발과정에서의 Task 관리에도많이사용된다. 오픈소스제품으로는 Mozilla의 Bugzilla(http://www.bugzilla.org/) 가있는데, 설치가편하고군더더기없이버그관리용으로사용하기가좋다. 다른제품으로는 Trac (http://trac.edgewall.org/) 이라는제품이있는데, 이제품은버그관리뿐만아니라, 개발 Task 용 Issue 관리, 소스코드형상관리및 Wiki 기반의문서관리까지지원한다.

효율적인툴를사용하는것도중요하지만결함관리에있어서가장중요한것은프로세스를잘 설계하는것이고툴는그프로세스를시스템적으로잘구현하는것이중요하다. 테스팅툴와환경 지금까지테스트의개념, 조직, 프로세스, 환경들에대해서알아보았다. 여기서는이러한테스트를실제로수행하기위한툴들에대해서소개하고자한다. 사실테스트에사용되는툴들은종류도많고쓰임새도제각각이다. 여기서소개하는툴들은일부이기는하지만, 현업무에서많이사용하는테스트툴이고, SI 개발에서사용하는테스트툴범위보다약간많은양을소개하기때문에, 이툴들을이해하고개발하는제품의성격이나팀의성숙도에맞춰서테스트툴들을축소또는확장해서구성하면된다. 단위테스트툴개발단계에서사용하는단위테스트툴는 xunit 시리즈가가장유명하다. 자바진영에서는 JUnit (http://www.junit.org) 이라는툴를사용하는데, 개별의테스트를 TestCase, TestCase 들의집합을 TestSuite 이라고한다. 요즘은개발툴나빌드툴들이이 JUnit과연동이잘되어있어서어렵지않게통합된개발및빌드환경에서단위테스트를수행할수있다. JUnit 은가장기본적인테스트로, Class 나 method 에대한테스트를수행한다. 테스트를수행하다 보면 UI, DBMS 등다양한로직에대해서테스팅이필요한데, 이러한테스트를지원하기위해서 JUnit 을확장한여러가지테스트프레임웍들이제공된다. 1 DBUnit (http://www.dbunit.org) : RDBMS 관련된테스트를위해서최적화된단위테스트프레임웍이다. 주로 DAO나 RDBMS에관련된로직을테스트하는데사용되며, 테스트수행시데이타초기화, 테스트수행후 RDBMS 내용에대한비교, 그리고테스트종료후데이타에대한 Cleansing 작업까지모두지원한다. 2 XML Unit (http://xmlunit.sourceforge.net/) : XML은 Open API의등장과 SOAP 기반의웹서비스에의해서더욱더많이사용되었고, 이와더불어설정정보들이 XML로저장되기때문에자주테스트대상이된다. XML은구조화된문서양식을가지고있다. 그리고, 각 Element에대해서순서가있는것도있고없는것도있기때문에, 단순하게문자열비교만으로는 XML 문서에대한비교가불가능하다. 그렇다고일일이 Parsing을해서비교하는구문을만드는것도만만치않은작업이다. 이런 XML에대한비교와테스트를해주는단위테스트프레임웍이 XML Unit이다. 근래에들어서는 OPEN API가 JSON으로많이구현되기때문에, JSON을지원하는단위테스트프레임웍으로 JSONUnit (https://github.com/lukas-krecan/jsonunit)

3 Japex (http://japex.java.net/docs/manual.html) : Japex는 JUnit의확장으로, 작성된 JUnit 테스트를 N개의클라이언트로동시에돌려서 Micro Benchmark 테스트를수행할수있게해준다. 100~200 유저의대규모테스트는어렵지만, 10~25 유저정도의소규모 Micro Benchmakr 테스트를가능하게해주고, 무엇보다재미있는점중의하나는, 이부하테스트를위해서별도의테스트케이스를새로작성하는것이아니라기존 JUnit 코드를그대로재활용하기때문에, 들어가는노력에비해서높은효과를기대할수있다. Japex는성능테스트결과를아래처럼그래프로출력하여주기때문에결과분석에도유용하다. 유사한프레임웍으로는 JUnitPerf (http://www.clarkware.com/software/junitperf.html ) 4 Selenium (http://seleniumhq.org/) : 단위테스트프레임웍들은 Class와 Method 단위의테스트만수행할수있다. 웹 UI가있는웹애플리케이션의경우 JUnit등과같은일반적인단위테스트프레임웍으로는테스트가불가능하다. Selenium 은가상웹브라우와같은역할을한다. Selenium은초기버전에비해서현재버전은상당히진화된기능을지원하는데, 첫번째가레코딩기능이다. (Selenium IDE의기능 ) 테스트입력으로제공할 INPUT 데이타를웹브라우져를통해서레코딩해서, 그레코딩된웹브라우져의행위를테스트데이타로사용할수있게한다. 두번째기능은다수의클라이언트를이용한테스트를지원할수있다. (Selenium GRID) 유사한툴로는 HTMLUnit (http://htmlunit.sourceforge.net/) 이있다. 웹 UI를테스트할때는매우유용한툴이기때문에, 꼭사용해보기를권장한다.

5 Cactus (http://jakarta.apache.org/cactus/) : Java Enterprise Edition의컴포넌트중에 Servlet,JSP나 EJB와같은컴포넌트들은구동을위해서 Servlet Engine과같은 JEE 컨테이너를필수적으로필요로한다. 이말은테스트를할때도 Servlet Engine이필요하다는이야기인데, 단위테스트케이스를만들었을때, 빌드스크립트나 IDE 툴에서이런 Servlet Engine이필요한 Class나 method를테스트하기가어렵다. ( 리모트로서버에로직이존재하기때문에,) 이러한테스트를 In-Container Test 라고하는데, 이런 In-Cotainer Test 를지원하는프레임웍중의하나다 Cactus라는프레임웍이다. 일반적으로작성하는 JUnit 처럼코드를작성한후에, 빌드스크립트, 테스트스크립트또는 IDE에서테스트케이스를실행하면원격의 Servlet Container에서테스트케이스를수행한후그결과를리턴하는형태로, JUnit과똑같은형태로테스트를진행할수있다. 자바애플리케이션중, Tomcat 이나 WebLogic과같이 Container를사용하는애플리케이션테스트를위해서는거의필수적인단위테스트프레임웍이다. 커버리지분석툴 테스트커버리지에대해서는이미앞서설명하였다. 테스트커버리지는테스트행위자체에대한품질을측정할수있는척도가된다. 보통이런커버리지측정툴의원리는 Java Virtual Machine(JVM) 이클래스를 Load할때, Class와 Method 앞뒤부분에커버리지를측정할수있는코드를삽입 (Injection) 하여, Class나 Method가실행될때마다로그를파일등으로남긴후, 테스트가끝난후에이로그정보를분석하여리포팅을해주는형태이다. JVM 에서커버리지측정용코드를 Injection 하기때문에성능저하를가지고온다. (10~20% 정도 ) 이런이유로, 성능측정등에는사용하지않는것이좋고, 순수커버리지분석시에만사용하고, 다 른테스트에서는제거하고테스트를수행하는것이좋다. 이런커버리지를측정해줄수있는툴가있는데, 대표적인툴들은다음과같다. Cobertura (http://cobertura.sourceforge.net/) 테스트커버리지의개념은앞서설명했고, 테스트커버리지중에서, Line Coverage, Branch Coverage 등을분석해줄수있는툴이다.

그림 0-1 Cobertura로자바코드의코드커버리지를분석한결과다른유사한툴로는 Emma (http://emma.sourceforge.net/) 라는툴가있다. 저렴한상용툴로는유명한 Atlassian 社의 Clover (http://www.atlassian.com/software/clover/overview) 라는툴가있다. 3가지툴모두어느정도안정성이검증되었고, 특히예산상의여유만허락한다면, Clover를사용하기를권장한다. 금액이크게비싼편이아니고, 커버리지분석용코드를 Injection하는과정도잘최적화되어있기때문에, 비교적안정적으로동작하며, 문제가발생할시에는기술지원을받을수있다. OPEN API 테스트툴근래의시스템들은 HTTP/XML이나 HTTP/JSON 기반의 OPEN API를리모트인터페이스로사용하는경우가많다. 엔터프라이즈시스템의경우에는 SOAP/HTTP 기반의웹서비스를표준인터페이스로사용하는경우도많은데, 이러한 API 인터페이스를테스트하기위해서는단위테스트프레임웍을사용할수도있지만별도의 OPEN API 테스트툴을사용할수도있다. 단위테스트프레임웍의경우에는개발팀이개발과정에서검증을목적으로사용하는데, OPEN API의경우에는별도의테스트팀이 API의명세만을가지고도 Black Box테스트가가능하다. 특히 OPEN API는제품을개발한사람보다는다른사람이 API 명세를가지고사용하기때문에, API 명세에대한검증, 기능에대한검증을개발자가아닌다른사람이검증하는것이바람직하다. SOAP UI (http://www.soapui.org) 이러한 OPEN API 테스트를지원하는툴로는 SOAPUI라는툴가있다. HTTP기반의 JSON 또는 XML OPEN API나, SOAP 기반의웹서비스테스트를지원한다. 여러개의테스트케이스를묶어서 Test Suite 개념으로테스트를진행할수있으며, 여기에더해서소규모의부하테스트도가능하다. ( 50~100 클라이언트 )

그림 0-2 SOAPUI 부하테스트툴부하테스트툴는성능테스트와기타비기능테스트에서없어서는안될필수적인툴이다. 여러상용툴와오픈소스제품이있는데, 여기서는대표적인제품만을소개한다. HP Load Runner (http://www8.hp.com/kr/ko/software/software-product.html?compuri=tcm:192-935779) 현업에서가장많이사용하는상용부하테스트툴이다. 자체스크립트언어를이용하여다양한부하테스트시나리오를작성할수있으며, 부하테스트과정중에, 테스트대상시스템에대한정교한모니터링이가능하다. CPU, 메모리사용률에서부터 SNMP ( 네트워크모니터링 ) 를이용한모니터링도가능하다.

그림 0-3 HP Load Runner 화면 여러가지부하테스트툴을써봤지만, 사실 Load Runner가좋기는제일좋다. 사용하기편하고, 모니터링도편리하고 HTTP 뿐만아니라여러가지프로토콜을지원하며, 복잡한스크립트작성을통해서다양한시나리오를가지고테스트를할수있다. 사실비용이비싸기는하지만가능하다면사용을권장하고싶은툴이다. 유사한부하테스트툴로는 Apache JMeter (http://jmeter.apache.org/ ) 와 Multi-Mechanize (http://testutils.org/multi-mechanize/) 등이있다. JMeter의경우현업에도많이사용하기는하지만, 툴을다루고스크립트를작성하는데, 높은숙련도가필요하다. Muti-Mechanize의경우 Python 기반으로작성되었고, 스크립트도 Python으로작성하기때문에비교적스크립트작성이용이하다. 테스트결과는 Apache JMeter와호환되는포맷으로출력되기때문에, JMeter용결과분석툴을호환하여사용할수있는장점이있다. 모니터링툴다음은모니터링툴이다. 위의툴로는테스트에서결함을발견할수는있지만결함발생구간과결함발생의원인을파악하는데는부족하다. 테스트가원할하게진행이되는지, 결함이발생하였을때는어느구간에서발생을하였고원인을무엇인지를살펴보려면별도의모니터링툴이필요하다.

모니터링이필요한구간의위와같이크게 4가지구간으로나뉘어질수있다. 물론다른미들웨어나프로그래밍언어를사용한다면그에맞는모니터링툴을갖춰야한다. RDBMS나다른 DBMS를쓴다면 DBMS에대한모니터링도구도필요하다. Application Monitoring Application에대한모니터링은 APM (Application Performance Monitoring) 이라는툴을사용한다. 이툴은테스트중에, Application의상태를알려준다. 처리된 Request에대해, 초당처리건수, 처리데이타, 처리과정에서어떤 class의어떤 Method를사용했으며, 각 Method에서소요된시간과 CPU Time을계산해준다. 애플리케이션을코드레벨에서병목과수행과정을모니터링해준다. 이정보만가지고있으면병목이발생하였을때, method에소요된시간이나 CPU가높은것을찾아서병목으로지목하고진단을할수있기때문에매우유용한도구이다. 여기에 Application 뿐만아니라 Application이기동되는 Middleware에대한모니터링을포함하는경우가많다. 안타깝게도테스트과정에서사용할만한오픈소스 APM툴은없고, 상용도구로는 CA 社의 Introscope나국산솔루션인 Jennifer 社의 Jennifer (http://www.jennifersoft.com/docs/java-j2eeapm-jennifer-overview.html ) 등이있다. Jennifer의경우에는.NET과 Java 플랫폼만모니터링이가능하고, Introscope의경우 Java,.NET 플랫폼뿐만아니라, IBM CICS,SAP와같은다른플랫폼도모니터링이가능하다.

그림 0-4 Jennifer APM 솔루션의커버리지는 Introscope가높은편이나 Java나.NET에대한성능모니터링관점만본다면, Jennifer가직관적이고사용하기편리하다. Middleware Monitoring Tomcat, WebLogic과같은미들웨어의경우에는미들웨어자체에서모니터링콘솔을제공한다. 애플리케이션의로직이아니라미들웨어에대한운용상태를보여주는데, 여기서는애플리케이션을구동하는데사용되는쓰레드수, 동시접속사용자, DB로의 Connection, 클러스터링구성상태등의애플리케이션의상세구동환경을보여준다. 이러한항목은 Java의모니터링표준인 JMX(Java Management Extension) 를준수하기때문에필요에따라서, JMX 호출코드를작성하여 Customized된모니터링환경구축이가능하다. 오픈소스미들웨어인 Tomcat의경우에는 GUI 기반의모니터링기능이기본탑재되어있지않기때문에확장된관리도구가필요하다. PSI-Probe (http://code.google.com/p/psi-probe/) 등이자주사영되는톰캣모니터링도구이다. 만약에 APM 을사용하고있다면, APM 에서운영과테스트에필요한미들웨어의정보를함께모니 터링해주기때문에, 별도로 Middleware Monitoring 툴을설치할필요는없다. Java Virtual Machine Monitoring

자바애플리케이션의경우에는 JVM 자체의모니터링에서많은정보를얻을수있다. 특히메모리사용현황에대해서는 JVM에서만얻을수있는데, 시스템이동작중에 JVM에대한런타임정보는 JConsole이라는도구를이용해서얻을수있다. JConsole (http://java.sun.com/developer/technicalarticles/j2se/jconsole.html) JConsole에서는 JVM 메모리상황, 사용이끝난메모리를수거할때발생하는 Garbage Collection 의발생과, 소요시간등을모니터링할수있고, 모니터링현재시점에각쓰레드들이어떤작업을하고있는지 Thread에대한실시간모니터링이가능하다. Thread에대한모니터링은테스트중에시스템이느려지거나멈췄을때, 애플리케이션이어떤동작을하고있는지, 어떤코드를수행하고있는지추적이가능하기때문에병목구간추적에매우유용하게사용될수있다. 그림 0-5 JConsole Infrastucture Monitoring 하드웨어인프라에대한모니터링은 OS 에서제공하는기본도구나장비제공업체로부터제공 되는도구를이용한다. 가장기본적인 CPU,Memory,Disk IO 등에대해서는 Top 이나 Glance 와같은

유틸리티를이용한다. 네트워크단에문제가있을경우에는패킷을직접검사할수있는데, tcpdump와같이임베딩되어있는도구를사용할수도있지만, 완전히원본데이타를보여주기때문에, tcpdump는사용하기가어렵고 GUI 환경을갖춘도구를사용하는데, WireShark (http://www.wireshark.org/) 를많이사용한다. 테스트중의모니터링은 CPU,Memory 사용률과, Disk, Network IO 정도만모니터링하더라도충분하다. 병목의발생되었을때구체적인분석은해당장비를다루는전문적인기술엔지니어를통해서기술지원을받아야한다. 좀더고급화된모니터링솔루션으로는 Cacti(http://www.cacti.net/) 나 Nagios(http://www.nagios.org/) 등이있는데, 이러한류의솔루션은운영하고있는전체하드웨어에대한세밀한모니터링및장애감지가가능하기는하지만복잡도가높고상당히숙련된운영노하우가필요하기때문에테스트과정중에적용하기는어렵고, 시스템운영단계에적용하는것이좋다. 테스트를진행해보면, 테스트의성공, 실패여부만을판별하기위해서테스트에매진하는조직들이있다. 인수테스트야출시여부를결정해야하지만, 다른테스트들은품질을향상시키는데목적이있다. 테스트가실패하였을때, 단순히안된다가아니라. 어디어디가어떤문제가있어서안된다. 와같이원인분석을함께하는자세가필요하다. 이런관점에서테스트과정중의모니터링도구의셋업은대단히중요한작업이며, 많은노력을기울이기를권고한다. 테스트팀운용사례 몇몇프로젝트에서테스트팀을셋업하여운영했었는데, 여기서겪었던 Lessoned Learned를몇가지공유한다.. 테스트팀은 Test 전략과방법론, 팀구조 R&R을정의하는 Test Lead를따로두고, 매번 Sprint 때마다테스트대상시스템에대한분석과시나리오정의를하는 Test Designer를세팅하고, 스크립트구현과테스트를 Test Engineer에게전담시켰다. 앞서언급한팀모델과상의한점은 Test Lead가 PM역할을겸임하지않았다. Test Lead는전체프로젝트관리자가겸임하였으며, Test Lead는프로젝트초반에테스트팀구조및방법론, 프로세스에대한상세디자인을수행하여전체틀을셋업하는역할을수행하였다. 일종의초기구조셋업을한역할정도로생각하면된다. 개발팀에는단위테스트를적용하였으며, CI를이용한자동빌드를통해서관리하고 Line Coverage를적용하였다. 전체기능중, 중요한패키지를 40% 정도선정하여, 해당패키지는 Line Coverage 달성률을 80% 목표로잡고테스트를진행하였다. 조직은프로세스셋업을하는조직, Load Runner를이용하여시스템테스트를전담하는조직그리고, SOAP UI를이용하여인터페이스테스트를수행하는조직으로나눠서운영하였다. 이때배운 Lesson Learned를몇가지이야기해보면다음과같다. 1 전체적인테스트프로세스, 방법론정의가약하다.

체계적으로개발과테스트과정에걸친프로세스와방법론을설계할수있는능력이약하다. 부하테스트정도는모두들알고있지만이과정에서비기능 ( 장애, 안정성, 확장성 ) 테스트에대한개념이약하고, 테스트의목표가되는목표성능모델을디자인하는능력이매우약하다. 전문적으로테스트의개념과이론을겸비하고오랜경험을가진사람이이러한큰그림을그릴수있는데, 품질검수는할수있을지모르겠지만, 품질을향상시키는품질관리자체를할수있는사람은많지않은듯싶다. 큰그림이틀어지면좋은결과가나오기가어렵다. 큰그림을그릴수있는능력을배양하고이론적인배경지식을습득하는것이필요하다. 2 전체적인테스트흐름을개발팀에이해시키기가어렵다. 막상테스트에대한큰그림을그리더라도, 이전체그림을모든개발팀원이이해하고공유해야되는데, 개발자들은주어진단위테스트구현에만집중한다. 시간이없어서일수도있겠지만, 개발자가품질과테스트에대한폭넓은이해가없는경우가많다. 이는개발자가구현뿐만아니라품질에대한이해와자신이품질을지키기위한노력이있어야하는데, 상당히아쉬운부분이다. 3 개통테스트에많은시간이소요된다. 시스템테스트등의부하테스트를할때, 개통테스트에소요되는시간이항상길었다. 안정적인 Staging 환경을확보하지못한것도원인이될수있지만, 배포를담당하는엔지니어가전체시스템에대한흐름과구조, 배포절차를이해하지못하고시스템을배포하다보니, Configuration 상에많은실수가있었고, 이를다시찾는데많은시간이소요되었다. 이러한실수들은개발팀이참여해야수정을할수있었다. 배포엔지니어가개발된소프트웨어를독립적으로배포할수있는역량을갖추어야하고, 무엇보다배포자체가자신의업무임을인식해야하는데, 국내 SI 특성때문이었을까? 배포는개발한개발팀의역할로생각했기때문에, 항상개발팀에의존적일수밖에없다. 4 단위테스트가효과적으로적용되지않는다. 5 테스트프레임웍을정교하게만들었음에도불구하고여기저기헛점이발견된다. 6 Log 데이타수집이약하다. 가장큰 Lesson Learned는이런고수준의테스트를적용은단시간에가능한것이아니라, 상당한시간의숙련기간이필요하고, 각자의역할에대해서방어적이기보다는품질목표를위해서조금더포괄적인역할을해야한다. 물론, 배포, 테스트, 개발각각의본연의역할에대해서는명확한정의와인식이필요하다. 아울러개발일정산정에있어서, 테스트에소요되는자원을반드시배정해야한다. 테스트에시간과인력이들어가지않고제대로된테스트가나올수가없다. 그리고개발자와테스트팀의품질관리에대한수준이낮다. 납기일에항상쫓기는국내 SI구조를보면어쩔수없는현실이기는하지만, 품질을초반에안잡아놓으면그만큼이를보강하는데많은비용이들어갈수밖에없다. 우리소프트웨어산업의구조적인문제이기는하지만, 개발팀을가지고있는조직이라면, 이러한테스트에대한큰그림을만들고지속적으로교육시키고사용

하다보면품질높은소프트웨어개발이가능하지않을까한다. 참고자료 ISTQB Test Fundamental Syllabus - http://www.istqb.org/downloads/finish/16/15.html