태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
BLOG main image
Not so Simple World (251)
이생각 저생각 (92)
이클립스 RCP (10)
Books (15)
잊기전에 회고 (7)
Better SW Development (83)
node.js (OctoberSkyJs) (32)
[뭘, 이런걸 다?] (12)
bảng giá máy tính xách tay
bảng giá máy tính xách tay
Beer Brewing Tutorials
Beer Brewing Tutorials
harga alat kesehatan spirometri
harga alat kesehatan spirometri
air max pas cher
air max pas cher
veste parajumpers
veste parajumpers
«   2017/06   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
797,038 Visitors up to today!
Today 76 hit, Yesterday 203 hit
rss
tistory 티스토리 가입하기!
Recent Entries
2011.09.30 23:00

테스트 자동화는 QA들이 이루고자 하는 궁극의 단계중 하나입니다. 버튼 하나만 누르면 수십 수백개의 테스트가 알아서 돌고 결과를 알려준다는 건 제가 생각해도 짜릿합니다.

예전에 옆 팀에서 win runner라는 자동화 툴을 사서 썼었는데 저한테 가끔씩 이런 말을 하곤 했었습니다.

"이게 한 copy에 얼마짜린줄 알아?"

정확히 기억은 안나지만 하여튼 그당시 제 기준으론 상상을 초월하는 가격이었습니다. (제 기억에 1000만원이하는 아니었습니다.) 단일 소프트웨어를 그정도 받을 수도 있구나 라고 처음 생각했었습니다. 그 뒤에 로드런너(load runner)라는 부하툴을 사용했었는데요, win runner만든 회사(머큐리얼)에서 부하 테스트 전용으로 win runner의 기능 일부를 차용해서 만든 소프트웨어 였습니다. 뭐 것도 만만치 않게 비쌌습니다만, 몇 대의 PC로 몇 십명의 동시 테스트, 부하테스트 인원을 대체할 수 있었기때문에 가격값은 했던것 같습니다. 그런데 문제는 말이죠, win runner나 로드런너나 단순 레코딩은 간단했지만, 변수값을 변경하면서 실행하도록 스크립트를 짜는 것은 쉽지가 않았습니다. 전문 인력을 키워서 그것만 전담하게 만들어야 했을 정도라 다른 일반 개발자들은 사용할 엄두를 쉽게 못냈습니다.

시간은 흘러흘러 웹이 대두되면서, 그리고 오픈소스가 확산되면서 오픈소스 웹 테스트 툴도 많이 나왔습니다. 최근 가장 유명한 건, 역시 셀네늄(selenium)인 것 같습니다. 그 외에도 몇 가지 있었습니다. (이클립스 TPTP라던가 MS Stress라던가)
목적이 조금씩 다르고 UI도 다르고 주 사용목적도 다르긴 합니다만, 어쨌든 웹 애플리케이션용 자동화 테스트 도구로 나름 열심히 써봤습니다. (전 대체 뭘 하는 사람인걸까요? -_-) 이번 IBM 기사에는 Sahi라는 자동화 도구를 소개하고 있네요.

Sahi로 웹 애플리케이션 테스트 자동화
http://www.ibm.com/developerworks/kr/library/wa-sahi/
Sahi Pro라는 상용제품도 있는데, 글쎄요.. 흠..

자. 여기부터는 전적으로 저 개인의 경험과 생각입니다. 절대적인건 아니니까 걸러서 들어주세요. (무슨 말을 하려고!!!)

- 웹 UI테스트는 쉽지 않았습니다. 쉽지 않다는 건 여차하면 수동 테스트에 비해 ROI가 크게 높지 않을 수 있다는 걸 뜻합니다.
- 사용자 동작을 그대로 녹화만 하는 UI 레코딩 툴들도 Robust 정도가 높지 않았습니다. 환경이 조금만 변해도 제대로 안 돌아가는 경우가 많았습니다.
- 사용자의 동작을 스크립트로 짜서 실행하는 툴들도 있었습니다. (대표적 셀레늄) 마찬가지로 스크립트 작성이 쉽지 않았고, 유지보수의 문제가 있었습니다. 브라우저별로 조금씩 스크립트가 달라져야 하는 경우도 있었습니다.
- 즉 UI 자동화 테스트는 기술적으로 테스트가 가능하냐 안하냐, 할 수 있냐 없냐의 문제보다 지속가능하냐, 유지가능하냐의 문제를 더 고려해야 했습니다.
- 그리고 학습이 상당히 필요해서 스크립트 만들어서 옆 동료 던져줘 봐야 소용없는 경우가 많습니다. 그래서 스크립트 방식은 웬만한 팀이나 인력이 아니라면 권장하고 싶지 않습니다.
- UI 변경이나 리팩터링시에 스크립트나 레코딩을 다시 작성해야 하는 경우에는 일이 더 복잡해지도 했습니다.

그래서 제 개인적으로 내린 결론은 'UI 테스트 자동화는 완성품에 대한 사용자 액션 레코딩이 그나마 제일 유용하다'입니다.
UI를 단위테스트처럼 작성하는건 개발 도중엔 매우 비추합니다. 출시 후에도 변경에 대한 비용은 단단히 각오해야 합니다.

그리고 마지막으로,,

어설픈 무료제품은 쓰지 마세요. 감당이 안됩니다.

저작자 표시 비영리 동일 조건 변경 허락
신고