지난학기 SE 수업의 term paper로 web application testing tool에 대한 조사를 했었다. 차근차근 블로그에 하나씩 써 보려 하나 게으름때문에 못하겠다. 결론만 이야기하자면, TestNG는 JUnit을 충분히 대체할 만큼 매력적이고, watir는 이런 류의 testing 툴을 접하지 못한 나에게 환상적이었으며, clover를 eclipse에 통합한 code coverage 측정을 통해 unit testing에 대한 정량적인 guide line을 제시해 줄 수 있을 것이다.
이 중 가장 환상적이었던 watir에 대해 간략히 소개한다. 뒷북이라면 부끄러울 따름이에요.
한마디로 이야기하면 ruby script 를 통해 IE 객체를 조정해서, functional test를 자동적으로 수행할 수 있게 하는 library 이다. 내부의 assertion은 ruby 자체의 assertion을 이용한다. option을 달리 줘서 실제 IE가 동작하는 것을 눈으로 보거나, 알아서 뒷단에서 처리하게 할 수 있다. IE 자체가 동작해버리니 testing tool 내부에서 session을 관리할 필요도 없고 여러모로 아주 멋졌다. 좀 더 뒤져보니 이런 툴 자체가 새로운 것이 아닌데, 난 여지껏 이런것도 모르고 뭘 했나 모르겠어.
다운받아서 실행해 보면 알겠지만, 실제 IE가 뜨더니 textbox에 알아서 글씨를 쓰고, 버튼을 누르고, 오만가지 것을 수행한다. 따라서, 이보다 더 정확한 acceptance test가 없을 것이라 생각한다. 다른 tool의 경우 emulation등등을 통해 수행하지만 이것은 실제 IE를 가지고 동작한다. 나의 경우 ruby 언어 자체를 다뤄 본 적은 없지만 제공하는 예제들이 다양해서, 대충 copy & paste 해서 원하는 작업을 무리 없이 수행할 수 있었다. 물론 와중에 엄청난 삽질의 연속이긴 했지만. report 자체도 괜찮더라. 또한, tool 자체적인 script 가 아닌 범용의 ruby script를 사용하기 때문에 ruby를 알고 있는 사람의 경우 아주 매력적일 것이다. 언어 자체를 모르는 나도 이틀 삽질해서 대여섯 가지의 test를 수행할 수 있었으니 진입장벽도 낮다.
문제는 아직 javascript alert, confirm 창에 대한 처리가 매끄럽지 못하다. 가능하긴 한데, 뭔가 알수없는 process를 마구 수행하더니 처리하는 모양새가 만족스럽지는 않았다. 버젼업으로 극복할 수 있는 문제인지, 피할 수 없는 문제인지는 루비나 IE object 처리에 대해 잘 모르기 때문에 모르겠다. activeX에 대한 처리는 할 수 없다고 하니 이것도 아쉽다. 그러나 이런 단점을 제외하고는 아주 매력적이었다.
test case code는 아래와 같은 방식으로 작성한다. ruby를 모르는 사람이 짠 ruby 코드니 만큼 문법이 엉터리 인 것은 감안하고 봐 주세요.
느낀 점은
@조금 더 뒤져보니 jiffie라는, JNI를 통해 IE를 조정하는 것도 있구나.
@이 목록도 눈여겨 봐 둬야 할 것 같다.
이 중 가장 환상적이었던 watir에 대해 간략히 소개한다. 뒷북이라면 부끄러울 따름이에요.
한마디로 이야기하면 ruby script 를 통해 IE 객체를 조정해서, functional test를 자동적으로 수행할 수 있게 하는 library 이다. 내부의 assertion은 ruby 자체의 assertion을 이용한다. option을 달리 줘서 실제 IE가 동작하는 것을 눈으로 보거나, 알아서 뒷단에서 처리하게 할 수 있다. IE 자체가 동작해버리니 testing tool 내부에서 session을 관리할 필요도 없고 여러모로 아주 멋졌다. 좀 더 뒤져보니 이런 툴 자체가 새로운 것이 아닌데, 난 여지껏 이런것도 모르고 뭘 했나 모르겠어.
다운받아서 실행해 보면 알겠지만, 실제 IE가 뜨더니 textbox에 알아서 글씨를 쓰고, 버튼을 누르고, 오만가지 것을 수행한다. 따라서, 이보다 더 정확한 acceptance test가 없을 것이라 생각한다. 다른 tool의 경우 emulation등등을 통해 수행하지만 이것은 실제 IE를 가지고 동작한다. 나의 경우 ruby 언어 자체를 다뤄 본 적은 없지만 제공하는 예제들이 다양해서, 대충 copy & paste 해서 원하는 작업을 무리 없이 수행할 수 있었다. 물론 와중에 엄청난 삽질의 연속이긴 했지만. report 자체도 괜찮더라. 또한, tool 자체적인 script 가 아닌 범용의 ruby script를 사용하기 때문에 ruby를 알고 있는 사람의 경우 아주 매력적일 것이다. 언어 자체를 모르는 나도 이틀 삽질해서 대여섯 가지의 test를 수행할 수 있었으니 진입장벽도 낮다.
문제는 아직 javascript alert, confirm 창에 대한 처리가 매끄럽지 못하다. 가능하긴 한데, 뭔가 알수없는 process를 마구 수행하더니 처리하는 모양새가 만족스럽지는 않았다. 버젼업으로 극복할 수 있는 문제인지, 피할 수 없는 문제인지는 루비나 IE object 처리에 대해 잘 모르기 때문에 모르겠다. activeX에 대한 처리는 할 수 없다고 하니 이것도 아쉽다. 그러나 이런 단점을 제외하고는 아주 매력적이었다.
test case code는 아래와 같은 방식으로 작성한다. ruby를 모르는 사람이 짠 ruby 코드니 만큼 문법이 엉터리 인 것은 감안하고 봐 주세요.
- 간단한 웹 게시판에 글 쓰기 기능을 테스트 한다.
- 글 작성 화면인 http://localhost:8088/webboard/write.jsp 로 이동한다.
- 제목에 글2, 내용에 내용2 를 입력한 후 submit 한다.
- 제목이 "글 목록 조회" 인 창으로 이동해야 한다.
- articleList 라는 id 를 가진 table 의 3,2 위치의 컬럼 내용이 "글2" 여야 한다.
require 'watir'
require 'test/unit'
$ie = Watir::IE.start("http://localhost:8088/webboard")
class TC_view_test < Test::Unit::TestCase
include Watir
def test_write_article
$ie.text_field( :name, "title" ).value = "글2"
$ie.text_field( :name, "content").value="내용2"
$ie.button( :id,"submit").click
assert_equal($ie.title , "글 목록 조회")
list_table =$ie.table(:id, "articleList")
assert_equal("글2" , list_table[3][2].text.strip)
end
def setup()
$ie.goto("http://localhost:8088/webboard/write.jsp")
end
end느낀 점은
- 굳이 watir가 아니더라도, 이러한 web application의 functional testing tool의 도입은 매우 매력적이다. 도대체 우리는 test 단계에서 얼마나 많은 click을 해 왔던가!
- web standard까지는 아니더라도, 구조적인 html 작성은 testing에 많은 도움을 줄 수 있다. 그러니 중요한 부분에 id 나 name 등의 적절한 attribute를 사용하는 것은 반드시 시행해야 한다.
- ruby언어 좋다.
@조금 더 뒤져보니 jiffie라는, JNI를 통해 IE를 조정하는 것도 있구나.
@이 목록도 눈여겨 봐 둬야 할 것 같다.
tag:programming,testing




덧글
napro 2006/07/05 09:11 # 삭제 답글
전에 windows script를 가지고 비슷한걸 구현한적이 있지요. 굉장한 삽질이 필요했던 것 같긴 하지만. 혹시 참고가 될 듯.http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/d78573b7-fc96-410b-8fd0-3e84bd7d470f.asp
세라딘 2006/07/06 16:22 # 삭제 답글
FIT를 좀 볼까 하는데 이거랑 부류가 좀 다른가용?잘 몰라서 --;
오리대마왕 2006/07/06 21:23 # 답글
napro//흥미롭네요. 큰 것 만들기에는 손이 너무 많이갈 것 같고, 조그마한 자동화 tool 만들기에 유용할 것 같네요!세라딘//FIT의 경우,각각의 fixture에 맞는 back단 code를 만들고, 이것의 input과 output을 html등의 format으로 읽어들이는 형식이더라고요. 결국 브라우저 자체의 control보다는, fixture의 control로 생각을 했습니다.
acceptance test의 경우 user가 직접 test를 작성한다는 의미로 보자면 fit가 좋을 것 같긴 하지만, fixture code를 작성해야 하는 점에서는 그다지 내키지가 않더라고요. 대신 watir 와 같은 접근은 user 개입의 여지가 없다고 봐야 하기 때문에 acceptance test인가? 라는 점에서는 또 의문이 생깁니다.
kikiki 2006/09/08 14:00 # 삭제 답글
오리 이거.. 내가 WATIR을 설치해서 해봤는데.. 아주 재미있더라구.. API설명 보면서 세이클럽 로그인 버튼을 클릭하도록 만드는데 꼬박 반나절이 걸리긴 했지만, 아주 Nice하던데 말야.. WATIR을 좀더 살펴봐야 될것 같아. 필요하면 회사에 공유도 하고싶은데, 오리에 대한 comment는 할건데, 블로그나 pdf를 공개하는건 오리가 싫어할란가? 대답좀.. 메신저 들어왔을때 나 있으면 말 걸어줘, 아님 댓글도 내가 체크할께. ( 다른자료좀 있나하고 구글한국에서 WATIR검색하면 오리블로그가 젤먼저 나오더라 ㅋㅋ )
kikiki 2006/09/08 14:02 # 삭제 답글
참, 나 QA쪽으로 업무 바꾸었거든.. 앞으로도 좋은자료 부탁해~
오리대마왕 2006/09/08 17:36 # 답글
kikiki//아무 상관없습니다. 공유하려고 만든 pdf이고 블로그니까요.영택님이랑 같이 팀 옮기신다는 얘기도 들었어요. :)
송군 2006/09/28 11:14 # 삭제 답글
헉... watir 설치해서 한번 해보려고 검색에서 찾아보니..오리님이 뜨네요.. ^^ 역시... !!
오리대마왕 2006/09/29 16:32 # 답글
저도 왜 이게 제일 먼저 뜨는 지... 잘 -_-;