Web Application 자동화 test 도구 분석 및및및및 적용pds1.egloos.com/pds/1/200608/05/15/analysis and... · Web Application 자동화 test 도구 분석 및 적용 - 1 -

Web Application 자동화자동화자동화자동화 test 도구도구도구도구

분석분석분석분석 및및및및 적용적용적용적용

안세원([email protected])

Web Application 자동화 test 도구 분석 및 적용

- 1 -

Web Application 자동화자동화자동화자동화 test 도구도구도구도구 분석분석분석분석 및및및및 적용적용적용적용

안세원

1. Abstract

web application은 application 일 뿐 아니라 service이므로 계속적인 유지보수 cost가 발생하

게 된다. 또한, 발전하는 internet 환경에 의해 web application의 범위와 복잡도는 점점 증가

해가고 있다. 이런 점에서 Web application의 test는 일반 Application 보다 더 철저히 수행되

어야 한다. 개발 및 유지보수 cost를 줄이고, service 안정성을 추구하기 위해서는 지속적인

regression test가 중요하고, 이를 위해서는 unit test, acceptance test level에서의 자동화 test

가 필수적이다.

현재 어떤 자동화 test tool들이 개발되었고 그 특징이 무엇인지 살펴본다. 또, 이를 이용해

간단한 web application을 개발하고, 이를 토대로 실제 개발 process에 어떻게 적용할 지 논

의해 본다.

2. Introduction

현재의 통신기술의 발달, 사회 각 분야의 전산화를 통해 web application은 그 사용빈도 및

영역이 계속 확장될 것이다. 또한 기존 application-user 간 interaction에서 SOA 및 web ser-

vice 개념의 등장으로 인해 application-application 의 interaction이 가능케 되어, 범위가 더욱

넓어지고 있다.

현재 수많은 web application들이 유/무상으로 제공되고 있다. 적용범위는 초창기의 개인 홈

페이지에서 B2B, B2C, B2G, G2C로 점차 확장되어 왔다. 통신 기술의 발달로 기존의 유선

internet 기반에서 무선 internet, WiBro등의 다양한 접근방식이 개발됨에 따라 사람들이 web

에 접근할 수 있는 방식도 다양화되었고, 좀 더 쉽게 어디에서나 원하는 web application에

접근할 수 있는 환경이 갖춰지게 되었다. 여기에 전자기술의 발달로 PC 기반의 web brows-

ing에서 핸드폰, 가전기기로 접속 client 환경 또한 다양해지고 있다. 이렇게, 어떤 환경에서

어떤 단말기로도 internet에 연결되어 서비스를 받을 수 있는 Ubiquitous Computing 환경에

서 web application은 점차 그 활용빈도가 높아지고 있다.

Web application은 internet, 혹은 intranet의 통신망으로 연결된 환경에서 웹 브라우저를 통

해 접근하는 application이다. 그러나 web service 개념이 도입됨에 따라 사용자가 직접 입력

한 web form에 대한 서버 측 작업수행결과를 HTML로 보여주는 것에서 벗어나, web applica-

tion 자체가 다른 application의 일부 service를 제공하는 형태로 진화하고 있다. 이를 뒷받침


- 2 -

하기 위해 기존에 사용되는 HTML과 함께 XML, SOAP, XML-RPC, REST 등의 다양한 interface

가 사용되고 있고, 계속 그 spec이 도입/발전하고 있다. 이를 통해 하나의 application을 개

발하면 이것을 독립적인 web application 뿐만 아니라 service 형태로도 제공할 수 있으므로

유연성 및 재사용성의 증가를 기대할 수 있다.

이처럼 web application은 점차 그 기능 및 범위, interface가 다양화 됨에 따라 이를 기획/개

발/유지보수 하는 전반적인 프로세스의 정교화 및 체계화가 요구된다.

3. web application에서의 test

3.1. web application의의의의 자동화자동화자동화자동화 test 의의의의 필요성필요성필요성필요성

web application 은 하나의 완성된 product의 개념보다는 유연하게 진화해 가는 service의

형태로 생각해야 한다. 따라서 계속적인 기능 추가, 오류 수정, 유지보수가 요구된다. 또한

web의 특성 상 대상 사용자의 환경도 PC에서 냉장고에 이르기까지 폭넓기 때문에 다양한

접속환경에 대한 고려가 필요하다. 또한, 일반 software product와 다르게, web application은

end user에 대한 추가적인 migration이나 배포가 필요하지 않다. 이는 web application의 빠

른 update 적용의 장점으로 작용할 수 있으나, 반대로 service에 공개된 오류는 바로 전체

service에 영향을 줄 수 있기 때문에, 철저한 검증이 필요하다. 아울러 service 자체의 기술

적 복합도도 점차 증가하고 있다. 이러한 자체적인 business logic의 복잡도 증가뿐만 아니라,

DB를 포함한 타 web service와의 통신 등의 분산환경 기술 및 performance, load balancing,

보안문제 등 non-functional requirement등의 추가적인 고려요소들이 경쟁력 측면에서 필수불

가결한 요소로 대두됨에 따라, 사전에 다각도의 검증이 필요하다.

점차 복잡해 지고, 다양해지는 환경에서 민첩하게 요구사항을 충족하기 위해서는 체계적

인 개발 및 검증 프로세스가 필요하다. 이러한 개발 프로세스 중 test는 실제 개발된 appli-

cation 이나 module 단위가 특정 상황에 대해 올바로 동작하는 지를 검증하는 기능을 수행

한다. 그러나 web application의 test는 다양한 접속환경, 분산환경에 따른 테스트 환경 구현

의 복잡함으로 인해 시간적 cost와 인적 cost 가 매우 많이 들어가게 된다. 빠른 서비스 기

능 개선을 위해서는 이러한 test cost를 줄이는 것이 불가피하다.

기존의 web application의 test는 직접 tester가 브라우저에서 개별 test case의 시나리오에

따라서 링크를 따라가거나 web form에 수치를 입력하고 그 결과를 직접 확인하는 형태였다.

그러나 web application이 복잡해지고 규모가 커짐에 따라, 매번 서비스 update가 일어날 때

전체 서비스에 대한 test을 tester에 의존하여 수동으로 실행하는 것이 시간과 인건비 측면

에서 거의 불가능한 수준에 이르렀다. 이러한 이유로 tester의 직접적인 test외에 자동화

test이 대두되게 되었다. Tester는 UI와 display등의 시각적인 면, 혹은 새로 추가된 기능에

대한 최종 확인에 집중하고, 내부의 functionality 는 자동화된 test scenario에 따라 수행하면


- 3 -

test의 cost를 낮추고, coverage를 높일 수 있다. 또한 지속적인 regression test를 시행하기

위해서도 test을 자동화하는 것은 반드시 필요하다.

3.2. web application 개발에개발에개발에개발에 관련된관련된관련된관련된 test 의의의의 종류종류종류종류 및및및및 절차절차절차절차

3.2.1. Unit test

정의정의정의정의 특정 code unit (function, serial of function) 의 정합성을 검증하는 white box test

이다.

대상대상대상대상 code unit

수행자수행자수행자수행자 개발자

의의의의의의의의

1. 개발과정에서 다른 code unit과 통합 되기 전에, 개발자가 스스로 test를 수

행하고, 발견된 오류를 수정할 수 있다.

2. Regression test의 일부로서, 기능 변화에 따른 특정 code unit에의 영향을

확인하기 위해서 사용할 수도 있다.

3. code unit 단위의 test 이므로, 특정 bug 발생 시 scope를 줄여가는데 도움

이 된다.

4. 비교적 자동화하기 쉽다.

한계한계한계한계

1. test에 사용할 input set 을 작성하는데 한계가 있다.

2. code unit 단위들의 test 이므로, unit 과 unit의 integration으로 인한 에러

검증을 할 수 없다.

3. 특정 function의 정상동작 여부를 확인하기 때문에, 오류의 존재를 파악할

수 있지만, 오류가 존재하지 않는다는 보장을 할 수 없다.

절차절차절차절차

1. test case 를 위한 code를 작성한다.

2. test case를 수행하기 위해 1번에서 작성한 code 를 실행한다.

3. 실행결과를 확인 한 후 성공하지 못한 경우 직접 source 코드를 수정하거

나 보고한다.

3.2.2. Acceptance test

Acceptance test 는 다음과 같이 세분화된다.

3.2.2.1. Release acceptance test (RAT) (build acceptance test, smoke test)

- 각 개발 release 시에 결과물이 이후의 test을 시작할 수 있을 만큼 안정적인지 판단

한다.

- 가장 일반적인 data 를 가지고 주로 작동되는 function에 대해 test case를 작성한다.

- 개발자들이 각 build를 submit하기 전 수행한다.

3.2.2.2. Functional acceptance simple test (FAST):

- 각 개발 release 시에 프로그램의 중요기능이 적절히 수행되는지 확인한다.


- 4 -

- 각각의 기능에 대해 피상적인 간단한 test만을 수행한다.

3.2.2.3. Deployment acceptance test

- Web application 이 deploy 될 대상 환경에 build를 deploy 한 후 FAST 가 적절히 동작

하는지 확인한다.

- Deploy 환경과 동일한 test 환경을 구축한다.

정의정의정의정의 개발된 system이 고객의 요구사항을 충족시키는 지 확인하는 black box test이다.

대상대상대상대상 완성된 기능단위

수행자수행자수행자수행자 개발자, 고객


1. 고객은 각 iteration에서 최종적으로 자신의 요구사항이 올바로 반영되었는

지 확인할 수 있다.

2. 개발팀은 요구사항의 모든 기능을 구현했고, 해당 구현사항이 올바로 동작

하는 지 확인할 수 있다.


1. 실제 application 동작을 관찰해야 하므로 unit test에 비해 자동화하기 힘들

다. 이를 위해 html page를 parsing 하여 검증하는 framework들이 개발되

었지만, 단순한 html page상의 코드 변경에도 테스트가 실패할 수 있다.


1. 요구사항 문서를 기준으로 테스트 항목을 설정한다.

2. 시스템이 해당 요구사항을 만족시켰는지 확인하기 위한 input 과 output

을 통해 test case를 작성한다. test case는 고객이 직접 작성할 수도 있다.

3. 수동 혹은 자동화 툴을 이용하여 test case의 성공여부를 기록한다.

4. 실패된 test에 대해 issue-tracking process 를 통해 처리하도록 한다.

3.2.3. Stress test, Load test, Performance test

정의정의정의정의

Stress test는 memory, disk space, network bandwidth 등의 제약사항을 서버에 적

용하여 system이 가혹상황에서 정상적으로 동작하고 error 상황을 올바르게 처리

하는 지 확인 하는 black box test이다.

Load test는 user scenario에 기초하여 다음과 같은 상황을 발생시켜 서버 부하를

측정하는 black box test이다.

1. 동시에 많은 request를 발생시킨다.

2. process의 입력data의 크기를 늘린다.

3. 장시간에 걸친 지속적인 task를 발생시킨다.

Performance test는 적절한 system performance를 유지하기 위한 효과적인 전략

을 수립하기 위한 black box test이다.

대상대상대상대상 application

수행자수행자수행자수행자 QA팀


- 5 -


1. 실제 서비스 상황에서 안정적인 서비스를 보장할 수 있는 upper limit를 측

정할 수 있다.

2. 한계상황에서 발생할 수 있는 오류들에 대한 검출 및 대비방법을 마련할

수 있다.

3. 자동화 test로만 수행할 수 있다.

4. 현재 web application은 전통적인 3 tier 방식에서 2 tier 방식이 확산되는 추

세이다. 2 tier 방식에서는 저가/비교적 저성능의 server들로 service를 운용

하게 된다. 이 경우 performance 측정이 정량적으로 이루어지지 않을 경

우, 운용할 server의 수요예측이 과거의 3 tier 방식에 비해 힘들기 때문에

performance 측정의 중요성은 더욱 커지고 있다.


1. 실제 web application의 사용환경에서는 여러 기능들에 대한 서로 다른

load들이 발생한다. 그러나 현재의 stress test tool들로 이런 실제 상황에

대한 근사적인 modeling에는 많은 어려움이 따른다.

2. load test는 server측의 load를 중심으로 진행되기 때문에 사용자의 환경에

따른 실제 가동모습과 차이가 있을 수 있다. 따라서 실제 서비스를 운용할

경우 load test 결과보다 많은 buffer 요소가 필요하다.


1. 실제 서비스 가동 시 사용자의 이용 pattern을 통계자료를 이용하거나 예

측하여 modeling 한다.

2. 1번의 modeling 결과에 따른 stress 매개 변수 혹은 사용자 시나리오를

stress test tool에 입력한다.

3. stress test를 적정횟수 실행하여 수치를 측정한다.

4. 여러 시나리오에 대해 2-3번을 반복하여 수행한다.

5. 측정 결과를 통해 program의 bottle neck을 처리하거나 서비스 용량을 추

정하여 서비스 운영에 반영한다.

4. test tool 조사

4.2 에서 살펴보았던 각 단계별 test를 수행하기 위해 대표적인 test tool의 특징을 살펴본다.

Web application에 대표적으로 사용되는 언어인 java, c#, php와 ruby, python의 script 언어를

위주로 정리한다.

4.1. Unit test

4.1.1. Summary

- 대부분의 unit test tool은 JUnit을 근간으로 이를 각 언어로 porting한 nUnit의 형태에

서 크게 벗어나지 않는다.

- 각각의 test case에 해당하는 Test method 들과 이를 포함하는 test class, 그리고 이들

을 관리하는 test suite의 형태를 지닌다.


- 6 -

- 언어에 따라 해당 언어의 특성을 활용해 test 포함여부, 의존성을 설정한다.

ex) .Net 의 attribute, java 5.0의 annotation

- language level에서 unit test가 기본 포함되는 추세이다.

ex) ruby, python의 기본 배포판에 library로 추가, j2se 1.4의 assert keyword

- nUnit의 단점인 test class를 extend 하는 문제, testXXX 형태의 method naming에 대한

대안을 마련하는 형태로 발전 중이다.

ex) TestNG, JUnit 4.0의 annotation 활용, NUnit의 .NET attribute 활용

- report 기능을 통해 html, xml 형태로 결과를 확인하거나, IDE의 plug-in 이나 stand-

alone GUI application을 통해 관찰할 수 있다.

- Code coverage tool, mock object tool과 연동하여 사용할 수 있다.

4.1.2. JUnit (http://junit.org/): Java 용 framework

- Java에서 가장 널리 쓰이는 unit test framework이다. Smalltalk용 SUnit의 java version

이고, 이후 다른 언어들로 porting 되었다. 다른 언어 버전과 통칭하여 nUnit으로 부른

다.

- Open source

- 개별 test method와 이를 묶는 개별 class 단위의 test case, 이를 묶는 test suite로 구

성되어 있다.

- setUp(), tearDown() method를 통해 test 전후 상태를 지정할 수 있다.

- GUI/text기반 test runner를 제공한다.

- 다양한 extension을 제공한다.

4.1.3. Cactus (http://jakarta.apache.org/cactus/): java web application의 server-side

code(Servlet, EJB, TagLib 등)의 unit test

- JUnit을 기반으로 이를 확장하여 만들었다.

- Open Source

- 다양한 integration module을 제공한다. Ant(http://ant.apache.org/)와의 integration으로

build와 동시에 test를 수행할 수 있다.

- 실제 web application을 통해 실행하여, 결과를 xml으로 반환한다. XSLT를 이용하여

html format으로 변환을 제공한다.

- 테스트 대상에 따른 TestCase class를 제공하고, 이를 extend하여 test case를 java

code로 작성한다. (ServletTestCase, JspTestCase, FilterTestCase)

- testXXX 형식의 test 대상 method를 정의하고, 이에 대해 beginXXX 형식의 method를

정의하여 각 test가 시작되기 전에 수행될 server side 작업을 실행할 수 있다. endXXX

method를 통해 test가 종료된 후 수행될 server side 작업을 실행할 수 있다.


- 7 -

4.1.4. TestNG (http://testng.org/): JUnit을 보완한 java용 framework

- JUnit의 부족한 기능을 보완했다. (method, test case 별 실행 여부를 수정할 경우 재

compile 필요, test case간 연관관계 설정, method별 setup/teardown)

- Open source

- java 5.0의 annotation을 이용하여 test method 설정

- XML을 이용하여 test case 를 구성할 수 있다. ( suite > tests > classes > methods )

- thread safety, timeout, expected exception 의 기능과 실패한 test만 다시 실행하는 기

능을 제공한다.


4.1.5. PHPUnit2 (http://pear.php.net/package/PHPUnit2): PHP5용 framework

- JUnit 3.8.1 의 PHP 5 porting이다. PHP5에서 추가된 class개념을 도입하였다.

- Open Source

- Code coverage analysis, mock object가 포함되어 있다.

- command line의 test 실행을 위한 command(phpunit)를 제공한다.

4.1.6. PyUnit (http://pyunit.sourceforge.net/): Python용 framework

- JUnit에 기반을 하였고, Python 2.1 standard library로 포함되었다.

- Open Source


4.1.7. NUnit (http://www.nunit.org/): .NET language용 framework

- JUnit에 기반을 두었다.

- .Net 의 모든 language에 대해 사용할 수 있다.

- Open Source

- [TestFixture],[Test]와 같은 attribute를 통해 test class, test method를 설정한다.

- ASP.NET 테스트를 위한 extension으로

NUnitAsp (http://nunitasp.sourceforge.net/index.html)이 있다. 각 WEBControl,

HTMLConrol에 해당하는 Tester 클래스를 통해 aspx 페이지에 대한 테스트를 수행한다.

4.1.8. TEST::UNIT (http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/index.html): Ruby용

framework

- Ruby에 기본 내장된 library로 제공된다.

- Open Source


- test class와 이를 묶는 test suite로 구성된다.


- 8 -

4.1.9. DbUnit (http://www.dbunit.org/): DB 관련 가상 data set 생성을 위한 JUnit extension

- DB 관련 Unit test을 할 때 DB상의 기존 data에 의해 test가 영향을 받는다. 따라서 일

종의 가상 DB를 구현하고, 여기에서 기존 정의한 외부 dataset을 가져와서 test를 수

행한다.

- Flat xml dataset 을 직접 만들거나 기존 DB에서 data를 export해서 test용 dataset을

만들 수 있다.

4.2. Acceptance test

4.2.1. Summary

- User가 일반 문서 형태의 test case를 작성하고, 이를 실행하기 위한 code를 개발자가

개발하는 형태(Fit, FiTNesse)와, script언어로 직접 test 코드를 개발하는 형태(WATIR,

Marathon(http://marathonman.sourceforge.net/)) 의 형태, XML로 기술하는 형태

(Canoo)가 있다. 그러나 acceptance test의 중요한 의의 중 user가 참여하여 직접 결

과를 확인한다는 점에서 일반 문서로 기술하는 형태가 좀 더 바람직한 형태로 생각한

다.

- Http request와 response 를 통해 validation을 하는 방식과, application의 특정 method

를 호출하는 형태(Fit, FiTNesse) 가 존재한다. 그러나 web application에서의 accep-

tance test의 경우, 내부 function의 직접적인 호출 방식보다는 Http request를 통한 방

식을 택해야 한다. 그렇지 않을 경우, servlet level의 method 호출은 성공했다고 하더

라도 중간 controller level에서의 오류로 인해 실제 동작이 실패할 수 있기 때문이다.

- Script 형태의 test case를 사용하는 tool들은 proxy server를 통해 user action을 저장하

여 이를 test case로 변형하는 tool을 함께 제공하기도 한다.

- 직접적인 IE embedded 객체 호출을 통한 접근을 하는 WATIR의 방식이 가장 직관적

이고 정확한 테스트 방법이라 생각한다.

4.2.2. Fit (http://fit.c2.com/wiki.cgi?FitDocumentation): HTML을 입력소스로 받는 test appli-

cation

- 사용자가 작성한 HTML 파일의 table을 입력소스로 받는다.

- 개발자가 만든 “fixture”로 입력된 table을 해석한다.

- 실제 application을 구동한 후 테스트 결과에 대한 output 문서를 만든다. Output 문서

는 원본HTML 파일의 table에 실행결과를 색깔과 결과값으로 표시한다.

- Fixture는 action의 종류에 따라 각각의 super class를 extend하여 작성한다.

- 다양한 언어 버전(http://fit.c2.com/wiki.cgi?DownloadNow)으로 개발되었다.

- Extension을 통해 기능확장이 가능하다.

- 모든 test를 위해서 fixture class를 coding해야 한다.


- 9 -

4.2.3. Canoo (http://webtest.canoo.com/webtest/manual/WebTestHome.html): XML 기반

test application

- Ant의 task 형식으로 test를 정의한다. Ant의 build file 내부에 test 내용을 기술한 후,

이를 수행한다.

- HtmlUnit (http://htmlunit.sourceforge.net/)을 통해 내부 page validation을 수행한다.

- test step과 이를 묶는 steps로 구성되어 있다.

- Step은 크게3가지 항목으로 구분되어 있다.

� Action: 실제 http request를 수행한 후 결과값을 저장

� Verification: 수행된 결과값을 비교하여 테스트 결과 판단

� Manipulation: 결과값을 이용하여 테스트에 필요한 조건을 구성한다.

- Groovy(http://groovy.codehaus.org/) script를 embed하여 복잡한 조건 구현이 가능하다.

Script 내부에서 verification을 수행할 수 있다.

- 실행결과를 PDF, Excel, Email로 저장할 수 있다.

- XML로 테스트 절차를 기술해야 하므로 하나의 test case 작성에 손이 많이 가고, cli-

ent가 작성하기 힘들다.

4.2.4. FiTNesse (http://fitnesse.org/): wiki를 test case로 사용하는 FIT를 기반으로 한 test

application

- Fit 초기 버전을 기반으로 작성되었으며, Fit가 개별 html 파일을 test case로 사용하는

것에 반해, 자체적인 wiki 시스템을 test case로 사용한다. 또한 자체적인 web server를

갖춘 독립적인 application 이다.

- Open Source

- Windows / UNIX, Linux에서 구동 가능하다.

- FiTNesse 서버에 작성된 wiki 페이지를 Fit의 html table로 변환한 후 Fit를 통해 test를

수행한다. Fit의 결과를 다시 FiTNesse의 wiki 페이지로 변환하여 게시한다.

- FiTNesse wiki의 test버튼을 클릭하면 test가 수행된 후 해당 페이지에 결과를 표시한

다.

- Java, C#으로 fixture를 작성한 후 wiki page를 통해 해당 fixture를 test한다.

- SubWiki를 통한 test wiki page의 관리가 가능하다.

- 기존 wiki 문법이 아닌 FiTNesse 자체의 wiki 문법을 익혀야 한다.

4.2.5. Solex (http://solex.sourceforge.net/): Eclipse plug-in으로 동작하는 개발자 중심 test

application

- Eclipse plug-in으로 동작하므로 개발 process와 융합하기 쉽다. 그러나 Eclipse 환경이

므로 개발자에게 적합하다.


- 10 -

- Open Source

- Proxy http server를 통해 사용자 action 에 대한 header, parameter 등의 action 정보를

저장한 후, 해당 action에 대한 내장 web browser의 playback을 통해 validation을 수

행한다.

- Regular expression, XPATH를 통해 validation에서의 유연성을 제공한다.

- Extraction rule을 통해 사용자 action상의 dynamic parameter를 추출 한 후, 이를 변경

하여 test case들을 만들어 낼 수 있다.

- Eclipse를 통해 실행해야 하므로, command line에서의 반복적인 batch 실행을 할 수

없다.

4.2.6. TextTest (http://texttest.carmen.se): domain language로 test case를 기술하여 plain

text 결과물 비교를 행하는 test application

- Fit와 다른 tool들이 java, python같은 programming language를 사용하는 것과 달리,

domain language를 정의한 후 이를 통해 test를 기술한다.

- Open Source

- 사용자가 기술한 test API를 호출하여 분석을 하는 다른 tool과 달리 plain text를 비교

하여 assertion을 수행한다.

- Java와 Python GUI를 외부 library를 통해 (JUseCase/PyUseCase) 제공한다.

- Python 기반으로 만들어졌다.

- Web Application 보다는 일반 GUI Application 위주이므로, Web Application 자체에 대한

지원이 부족하다.

- Domain language 자체에 대한 이해가 필요하다.

4.2.7. WATIR (http://wtr.rubyforge.org/): ruby 기반의 scripting 을 통한 web test application

- Ruby script를 통해 test case를 작성하여 이를 실행한다.

- Open Source

- 실제 IE를 통해 테스트 진행을 확인할 수 있다.

- 실제 브라우저의 실행을 통해 테스트를 수행하므로, File upload와 같은 browser spe-

cific한 테스트가 가능하다. 이를 통해 tester에 의해서 수동으로만 수행 가능한 file

upload나 active-X feature의 test도 가능하다.

- Ruby 언어에 대한 지식이 필요하고, program coding이 필요하므로 client가 직접 test

를 작성하기 어렵다.

- Internet Explorer 기반 테스트이므로, 타 browser 지원이 필요하다.

4.2.8. WebKing (http://parasoft.com/jsp/products/home.jsp?product=WebKing): 상용 func-

tionality & load test tool


- 11 -

- web application에 대한 static analysis, functionality test, load test 기능을 수행한다.

- 상용 application이다.

- Windows, Linux platform을 지원한다.

- Web application 에 대한 다양한 정적 분석 기능을 지원한다. (link, spell, html valida-

tion, spell check)

- IE를 이용한 사용자 action을 저장하여 action을 토대로 functionality, load test를 수행

한다.

- 각 web page의 form에 대한 인식 및 submit 을 통한 test를 지원한다.

4.3. Performance test

4.3.1. Summary

- 단순 request 발생 후 server load 측정 방식/ user scenario 재현 후 server load 측정

방식으로 나뉜다. user scenario 재현 방식의 경우 http request의 순차적인 발생과

script를 통한 programming 방식으로 나뉜다. 후자의 경우에 실제 사용자 pattern에

가까우므로 좀 더 정교한 측정이 가능하다.

- 부하를 발생시키는 것이 측정 server에 부담을 주게 되므로, 분산 test를 지원하기도

한다.

4.3.2. OpenSTA (http://www.opensta.org/): Windows용 stress test & monitoring application

- 정교한 사용자 action 재현에 의한 test가 가능하다.

- Open Source

- SNMP, windows performance monitor, HTTP(HTTPS) result 등의 실질적인 서버 부하 측

정 및 통계기능을 제공하므로, 단순 HTTP response time 측정에 의한 결과보다 신뢰

성이 높다.

- stress test 이외의 performance monitoring 기능을 제공한다.

- Windows용의 정교한 GUI를 제공한다.

- 정교한 test plan을 짤 수 있으나, 학습에 시간이 걸린다.

4.3.3. JMeter (http://jakarta.apache.org/jmeter/): java 기반의 test application

- Java 기반이므로 platform에 상관없이 실행 가능하다.

- Open Source

- Swing 기반 GUI/ command line interface를 제공한다.

- HTTP(HTTPS), FTP, SOAP, JDBC, XML-RPC 등의 다양한 sampler를 제공한다.

- Assertion을 통해 개별 request의 성공여부를 판단 가능하다.

- Graph, table, log등의 report 방식을 지원한다.

- 분산 test을 지원한다.


- 12 -

- 개별 request 단위의 sampling만이 가능하므로, OpenSTA와 같은 복잡한 scenario에 대

한 test는 수행하기 어렵다.

4.3.4. Grinder (http://grinder.sourceforge.net/): java 기반, jython scripting test application

- Java 기반, jython library를 이용해 내부의 python script로 test case를 기술한다.

- Open Source

- Jython을 이용, java로 작성된 내장 library를 python 형식의 test case로 작성하여 test

를 수행한다.

- test script는 직접 작성하거나, 같이 제공되는 proxy server를 통해 사용자 action을 re-

cord한 후 이를 통해 자동으로 작성할 수 있다.

- Script 작성을 통한 test 를 수행하므로, 복잡한 test scenario가 가능하지만 python

script에 대한 지식이 필요하다.

- 실행결과를 Graph와 text data format으로 저장할 수 있다.

4.4. 기타기타기타기타

4.4.1. clover (http://www.cenqua.com/clover/): java/ .NET code의 test coverage 를 측정하

는 application

- ant의 task, IDE의 plug-in으로 제공되며, unit test의 code coverage를 측정한다.

- 상용 소프트웨어

- HTML, PDF, XML, GUI의 reporting 방식을 지원한다.

- 각 package/ class/ method/ state별 coverage를 report한다.

- Filtering을 통해 측정하지 않을 요소들을 선택할 수 있다.

5. 실제 test tool 적용

이 절에서는 위에서 조사한 tool들을 간단한 web application에 실제 적용해 보고, test sce-

nario를 실제 적용하는 과정 및 결과에 대해서 알아본다.

5.1. Test 환경환경환경환경 기술기술기술기술

5.1.1. Requirement

- 간단한 웹 게시판을 만든다.

- 글 읽기/삭제/작성/목록보기의 기능을 갖는다.

- 각각의 글은 제목/내용/번호/작성일을 가진다.

� 번호는 정수형이다.

� 작성일은 “년-월-일 시:분:초”의 형태이다.

� 제목, 내용은 반드시 입력되어야 한다.

- 글 목록 화면의 상단에 [글 쓰기] 링크가 위치한다. 글 목록 화면의 각각의 글 항목은


- 13 -

“번호 제목 작성일 [삭제] [보기]”의 형태로 구성된다.

� [삭제] 링크 클릭 시 “정말 삭제하겠습니까?” 라는 alert 박스를 보여준다.

‘네’ (yes) 를 선택할 경우 해당 글을 삭제한 후 목록으로 돌아간다.

‘아니오’(no) 를 선택할 경우 삭제를 취소한다.

� [글 쓰기] 링크 클릭 시 글 작성 화면으로 이동한다.

� [보기] 링크 클릭 시 글 조회 화면으로 이동한다.

- 글 작성 화면은 [제목], [내용] 입력란과 [저장] 버튼이 위치한다.

� 제목이나 내용을 입력하지 않고 저장 버튼을 클릭할 경우 “제목과 내용을 입력

하세요” 라는 alert 박스를 보여주고, 저장이 실패한다.

� 저장이 성공했을 경우 글 목록 화면으로 이동한다.

- 글 조회 화면에는 제목/내용/번호/작성일이 표시되고, 하단에 [목록으로] 링크가 위치

한다.

� [목록으로] 링크 클릭 시 글 목록 화면으로 돌아간다.

- 모든 작업 실패 시 실패화면으로 이동한다. 실패화면 하단에는 [목록으로] 링크가 위

치한다.

5.1.2. Class Diagram


- 14 -

5.2. Test Cases

5.2.1. Unit Test

Class Method 조건조건조건조건 예상결과예상결과예상결과예상결과

DB server와 연결에 실패했다. throw Exception DBManager getConnection

DB server가 연결된 상태이다. connection != null

DB server가 연결된 상태이다.

등록된 글이 없다

empty list getArticleList


글이 4개 등록되어있다.

list, size =4


id =4

id=4의 row가 있다.

article, id =4 getArticle


id =4

id=4의 row가 없다.

null


id =5

id = 5의 row가 없다.

글이 4개 등록되어있다.

getArticleList test가 성공했다.

false

getArticleList() 의 결과 list size

=4

deleteArticle


id =4

id =4 의 row가 존재한다.


true


=3


글이 등록되어 있지 않다.

1 getNextId


글 번호 4까지 등록되어 있다.

5

ArticleManager

saveArticle DB server가 연결된 상태이다.


getNextId가 성공했다.

getArticle이 성공했다.

글이 4개 등록되어 있다.

true


= 5

새로 저장한 글에 대해 DB에

서 getArticle로 가져온 후 제

목, 내용, id, 글 쓴 시각 string

이 모두 같다.


- 15 -

Article getWriteDat-

eString

date = 1999년 12월 31일 23시

59분 59초의 date 객체

“1999-12-31 23:59:59”



request의 “type” parameter=”list”

response의 result attribute 는

List type이고, size =4 이다.


request의 “type” parameter=”get”

request의 “id” parameter=”4”

DB에 id=4인 row가 존재한다.


Article type이고, id =4 이다.

doGet


request의 “type” parame-

ter=”delete”

request의 “id” parameter=”4”

DB에 id=4인 row가 존재한다.




ArticleMan-

agerServlet

doPost DB server가 연결된 상태이다.




5.2.2. Acceptance Test

화면화면화면화면 action 조건조건조건조건 결과결과결과결과

화면을 조회한다 글이 4개 등록되어 있다. 글 목록이 4개 표시된다.

[등록] 버튼을 클릭한다 글 등록화면으로 이동한다.

가장 상위 글의 [조회] 링크를

클릭한다

글이 1개 이상 등록되어 있다. 글 조회화면으로 이동한다.

가장 상위 글의 [삭제] 링크를

클릭한다.

alert 발생 시 [취소]를 선택한

다.

글이 1개 이상 등록되어 있다. “삭제하겠습니까” alter가 발생

한다.

아무 action도 발생하지 않는다.

목록화면

가장 상위 글의 [삭제] 링크를

클릭한다.

alert 발생 시 [확인]을 선택한

다.

글이 1개 이상 등록되어 있다. “삭제하겠습니까” alter가 발생

한다.

글 목록화면으로 이동한다.

글 개수가 1개 감소되어 있다.

조회화면 화면을 조회한다.

[목록으로] 링크를 클릭한다.

글 번호 =1

글 번호 1에 해당하는 글이 등록

되어 있다.

글의 작성일은 1999-12-31

글 번호, 작성일, 제목, 내용이

올바르게 표시된다.

[목록으로] 링크가 존재한다.

클릭 후 목록화면으로 이동한


- 16 -

23:59:59 이다.

글의 제목은 “Article1” 이다.

글의 내용은 “Content1” 이다.

다.

등록화면 화면을 조회한다.

글 제목과 내용을 입력하고 [입

력]버튼을 클릭한다.

글 제목은 “글2” 이다. 목록화면으로 이동한다.

목록화면에 “글2” 라는 제목을

가진 글이 목록 가장 상단에

위치한다.

5.3. 개발환경개발환경개발환경개발환경

5.3.1. Java 1.5.0_06

5.3.2. Eclipse

5.3.3. Unit Test: TestNG 4.7 / Cactus 1.7.2

5.3.4. Acceptance Test: WATIR 1.4.1

5.3.5. Performance Test: OpenSTA

5.3.6. Service DB: ORACLE XE

5.3.7. 개발 DB: HSQL DB, memory mode

5.3.8. WAS: Tomcat 5.5.17

5.4. 개발개발개발개발 process

5.4.1. Class diagram 의 코드를 작성한다.

5.4.2. 6.2.1의 Unit test중 servlet 동작과 관계 없는 DBManager, ArticleManager, Article

class 관련 test를 TestNG를 이용해 작성한다.

test시, 환경설정을 위해 HSQL DB를 이용해 DB data를 작성한다. 매번 test 실행 시

마다 이전의 모든 data를 소거한 후 필요한 data를 test에 맞게 작성하여, unit test의

완전성을 보장한다.

Clover를 이용해 unit test를 통한 code coverage를 측정하고, 만약 unit test에 의해

cover되지 않는 부분이 발견될 경우 unit test를 추가하여 기준 coverage를 충족하도

록 한다.

5.4.3. 6.2.1의 Unit test중 servlet 동작과 관련된 ArticleManagerServlet을 Cactus를 이용해

작성한다. Cactus 실행을 위해 tomcat 서버를 설치하고 실제 web application을 설치

한다. 이때 실행DB를 oracle로 설정한다.

5.4.4. Unit test를 실행하여 모두 성공할 때까지 오류를 수정한다.

5.4.5. 화면을 구성할 JSP를 만든다. 작성한 JSP는 write.jsp, get.jsp, list.jsp의 3개이다.

5.4.6. 실제 application이 동작하는 지 확인한다.

5.4.7. 6.2.2의 acceptance test의 실행코드를 ruby를 이용해 작성한 후 WAITR로 실행한

다.


- 17 -

5.4.8. acceptance test가 성공할 때까지 오류를 수정한다.

5.4.9. performance test를 위해 OpenSTA를 이용해 test scenario를 작성한다. 본 test의

경우 목록화면 조회- 글 조회 – 목록화면 조회 – 글 작성 – 목록화면 조회 – 글 삭

제를 하나의 scenario로 설정하였다.

5.4.10. OpenSTA를 이용해 stress test를 수행한다.

5.5. 결과결과결과결과

5.5.1. TestNG를 이용한 unit test

총 12개의 test method, 모두 성공

5.5.2. TestNG test에 대한 Clover coverage 측정

test package와 servlet code를 제외한 모든 class에 대한 unit code coverage 측정결과

이다.

DBManager class의 객체생성을 막기 위한 private 생성자를 제외한 모든 method가

unit test에 의해 실행되었고, 모든 statement가 실행되었다.

5.5.3. Cactus에 의한 Servlet 동작 수행 test

총 2개의 test case, 모두 성공


- 18 -

5.5.4. WATIR에 의한 acceptance test

총 3개의 test class, 9개의 test case, 15개의 assertion 모두 성공

5.5.5. OpenSTA를 이용한 performance test

- 목록 조회 – 글 조회 – 목록 조회 – 글 작성 – 목록 조회 – 글 삭제 – 목록 조회 의

scenario를 기반으로 수행한다.

- 50명의 동시접속자, 9번의 iteration, 0~1초 사이의 random delay 설정으로 수행한다.

그림그림그림그림 5.5-1 Http Error vs. Concurrent Request

- 약 57명의 concurrent request 이후로 급격하게 error가 발생하므로 57명이 maximum

사용자로 판단된다. 따라서 실제 service시 50명 내외의 동시접속자 thread를 유지할

수 있어야 한다.

6. 개선 방향

6.1. Unit test


- 19 -

6.1.1. unit test는 모든 test 중 가장 하위 level의 테스트이다. 따라서 다른 테스트보다 소

스코드 자체의 검증을 보장해야 하며, 이 경우 code coverage tool을 적용하여 적정수

준 이상의 coverage 비율을 보장하도록 하는 것이 바람직하다.

6.1.2. XP와 함께 널리 퍼진 TDD의 접근방식과 같이, 이미 개발된 로직에 test를 작성하

는 것이 아닌, test를 통과하기 위한 개발방식도 unit test의 발전방향으로 생각된다.

이를 통해 test하기 용이한 application을 작성하는 것이 이후의 test 자체의 개발 cost

를 크게 낮춰주고, 개발 process와 test를 좀 더 밀접하게 연결해 줄 수 있다.

6.1.3. 대부분의 web application은 DB와 연동하여 동작한다. 이 경우 DB의 data에 따른

다른 동작이 요구되는 상황에 대해 unit test가 필요하다. 이를 위해서는 HSQL

DB(http://www.hsqldb.org/)와 같은 경량의 memory/file DB, 혹은 mock object를 이용한

가상 DB를 적용할 수 있다. 이를 위해서는 실제 code에서 DB connection을 담당하는

logic을 business logic과 분리해야 한다.

어느 정도 규모 이상의 project들은 DB pool을 사용해서 connection을 관리하게 되는

데, 대부분 JNDI를 통한 DB pool instance을 호출한 후 connection을 가져오게 된다.

따라서 test시에 test용 DB pool을 등록한 다음, 이를 활용하여 호출할 경우 보다 편

리하게 test 환경과 서비스 환경의 DB 설정 변경이 가능하다.

6.1.4. web application의 개발흐름은 MVC model의 도입(Struts, JavaServerFaces,

RubyOnRails, Spring), CBD(J2EE), SOA개념의 도입(Spring) 등으로 presentation과

logic이 구분되고 있다. 따라서 기존의 acceptance test 단계에서 발견하고 수정 가능

한 많은 부분들을 unit test 단계에서 미리 발견할 수 있다. 따라서 위와 같은 logic-

presentation 분리가 가능한 framework의 도입이 적극 권장된다.

6.2. Acceptance test

6.2.1. acceptance test의 경우, 사용자가 web browser를 통해 web application을 사용하는

과정에 가까울수록 test가 효과적이다. Fit와 WATIR의 두 tool을 비교한 결과, 전자는

실제 사용환경과 거리가 있지만 사용자가 직접 use case를 생성할 수 있는 장점이

있고, 후자는 ruby scripting을 통해 직접 program을 작성해야 하지만, 실제 IE 객체를

통해 test가 진행되므로 그 효과는 크다고 볼 수 있다. Proxy를 통한 사용자 action 저

장 후 직접 script를 생성하는 tool들도 존재하고 있으므로, 앞으로 acceptance test

tool은 직접 browser를 호출하여, 자동적으로 script를 작성할 수 있는 기능을 제공하

는 tool로 발전해야 할 것으로 생각한다.

6.2.2. acceptance test를 효과적으로 진행하기 위해서는 browser의 기본 object를 보다 정

교하게 활용해야 한다. Test tool에서 각 항목을 정확하게 찾아가기 위해서는 각각의

항목에 대해 id property나 표준 object를 사용해야 한다. 따라서 효과적인 acceptance

test를 위해서는 web standard에 맞는 HTML coding이 요구된다.

6.2.3. 기존의 vendor 별로 제공하는 script언어에서 최근 개발된 tool들은 일반적인 script


- 20 -

언어로 test case를 기술 할 수 있다. 이와 같은 python, ruby, groovy 와 같은 일반

script language로 test case를 작성할 경우, command line에서 batch로 테스트를 실행

후 report를 뽑아내거나, 추후 다른 tool을 적용하게 될 경우에도 기존 test case를 재

사용할 수 있는 장점이 있으므로 이와 같은 방식이 추천된다.

6.3. Performance Test

6.3.1. load test나 performance test의 경우 현재 개발된 application의 현 상태를 측정하고,

시스템간의 병목 구간을 알아낼 수 있다. 이와는 별도로 Application 내부의 logic상의

performance를 알아내기 위해서는 profiling을 통한 source code level에서의 분석이 필

요하다. 따라서 지속적인 performance test와 profiling이 병행되어야 실질적인 개선효

과를 기대할 수 있다.

6.3.2. 실제 application 실행 시점의 대부분의 cost는 DBMS와의 처리부분에서 발생하고

있다. 이러한 문제를 처리하여 해결하기 위해서는 지속적인 DBMS에 대한 query

monitoring, query profiling이 함께 병행되어야 한다.

6.4. 개발개발개발개발 및및및및 유지보수유지보수유지보수유지보수 Process에의에의에의에의 Integration

6.4.1. 자동화 test의 가장 큰 장점은 개발과정의 build, distribute 와 시스템 설정변경 등

의 다양한 유지보수의 process에 융합하기 쉽다는 것이다. 현재 대부분의 unit test

tool은 IDE 및 ANT와 같은 build process에 대한 task를 제공하고 있다. 또한 accep-

tance test tool은 test 실패 결과를 Trac(http://www.edgewall.com/trac/), Bug-

zilla(http://www.bugzilla.org/)와 같은 bug tracking system에 자동적으로 등록하여 bug

처리 process가 수행되도록 한다.

6.5. 차세대차세대차세대차세대 framework

6.5.1. 현재의 web application의 presentation layer는 전적으로 하드코딩 된 html이 담당하

였다. 그러나 XML + XSLT 를 이용한 XML형식의 presentation 이나, JSF와 ASP.NET,

Java Portlet 등의 framework들을 통한 자동 HTML 생성 방안이 모색되고 있다.

Laszlo(http://www.laszlosystems.com/), Flex(http://www.adobe.com/products/flex/)와 같

은 HTML이 아닌 flash를 통한 presentation도 활발히 개발되고 있다. 이들 framework

들은 presentation 자체를 framework 내부에 포함하고 있기 때문에, 적절한 tool에 의

해 손쉽게 test가 가능할 것으로 생각된다.

7. References

1. Web Application, http://en.wikipedia.org/wiki/Web_application

2. WiBro, http://en.wikipedia.org/wiki/WiBro


- 21 -

3. Web Service, http://en.wikipedia.org/wiki/Web_service

4. Internet Usage Statistics http://www.internetworldstats.com/stats.htm

5. Ubiquitous Computing, http://www.ubiq.com/hypertext/weiser/UbiHome.html

6. JUnit http://junit.org/index.htm

7. Testing Private Methods with JUnit and SuiteRunner

http://www.artima.com/suiterunner/private.html

8. XProgramming.com – an agile software development resource

http://www.xprogramming.com

9. Web Site Test Tools and Site Management Tools

http://www.softwareqatest.com/qatweb1.html

10. Unit testing with mock objects

http://www-128.ibm.com/developerworks/library/j-mocktest.html

11. jMock – A Lightweight Mock Object Library for Java http://www.jmock.org/

12. Open Testware Reivews – Unit Test Tool Survey

http://tejasconsulting.com/open-testware/feature/unit-test-tool-survey.html

13. List of unit testing frameworks

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

14. Acceptance test http://xper.org/wiki/xp/AcceptanceTest

15. Acceptance tests http://www.extremeprogramming.org/rules/functionaltests.html

16. Comparing tools for acceptance testing of web apps

http://texttest.carmen.se/AcceptanceTesting/webcomparison.html

17. Diane Stotllemyer,Automated Web Testing Toolkit, 2001

18. Hung Q. Nguyen, Testing Applications on the Web, 2000

19. Frank Cohen, Java Testing and Design, 2004

20. Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli, Fundamentals of Software Engineering, 2003

21. Hani Suleiman, Beyond JUnit:Introducing TestNG The Next Generation in Testing,2006

8. Appendix

8.1. TestNG test code 예시예시예시예시

@Test(dependsOnMethods = {"testGetFourArticleList"},

groups = {"articleManager"}) // 글 목록 읽어오기가 성공한 경우에만 실행

public void testDeleteArticleSuccess() throws Exception //글 삭제 성공을 test함

{

Connection conn = null;

try {

DBManagerTest.insertFourArtilces(); // 테스트 조건을 위해 글 4개를 저장


- 22 -

conn = DBManager.getConnection();

assertTrue(ArticleManager.deleteArticle(conn, 4)); //4번 글의 삭제를 성공해야 한다.

List articleList = ArticleManager.getArticleList(conn);

assertEquals(3, articleList.size()); //글 하나를 삭제했으므로 글이 3개만 남아있어야 함

} catch (Exception e) {

throw e;

} finally {

DbUtils.closeQuietly(conn);

}

}

8.2. Cactus test code 예시예시예시예시

public void testGetList() //글 목록 읽어오기를 테스트한다

{

try {

ArticleManageServlet servlet = new ArticleManageServlet(); //servlet 생성

servlet.doGet(request, response); //doGet 실행

List resultList = (List) request.getAttribute("result"); //request의 result attribute 를 가져온다.

assertNotNull(resultList); //결과가 있어야 한다.

assertEquals(4, resultList.size()); //결과의 개수가 4개여야 한다.

} catch (Exception e) {

e.printStackTrace();

}

}

public void beginGetList(WebRequest requestObj) //testGetList 를 위한 환경설정

{

// request의 parameter를 type=LIST로 설정한다.

requestObj.addParameter("type", ArticleManageServlet.ACTION.LIST.name());

}

8.3. WATIR test code 예시예시예시예시

def test_goto_register //글 작성 화면으로 이동하는지 테스트한다.

assert(exists?{$ie.link(:text, "작성")}) // “작성” link가 존재해야 한다.

$ie.link(:text, "작성").click //”작성” link를 클릭한다.

assert_equal($ie.title , "글 작성") //이동된 페이지의 title이 “글 작성”이어야 한다.


- 23 -

end

def test_delete_confirm_ok

old_row_count = $ie.table(:id, "articleList").row_count #기존 글 개수를 저장한다.

assert(exists?{$ie.link(:text, "삭제")}) #”삭제 link가 존재해야 한다.

#”삭제” 버튼을 클릭한 후 뜨는 확인상자에서 “확인”을 클릭한다.

startClicker("확인",1)

$ie.link(:text, "삭제").click

assert_equal($ie.title , "글 목록 조회") #”글 목록 조회” 화면으로 되돌아온다.

#글 하나를 삭제했으므로 전체 글 개수가 1개 줄어들어야 한다.

assert( old_row_count-1 ,$ie.table(:id, "articleList").row_count )

end

Documents

Web Application 자동화 test 도구 분석 및및및및 적용pds1.egloos.com/pds/1/200608/05/15/analysis and... · Web Application 자동화 test 도구 분석 및 적용 - 1 -