테스트자동화 성공전략

테스트 기본교육
Chap.2 테스트 자동화 전략과 툴 교육
- 테스트

테스트 툴 & 자동화 교육
2. 테스트 자동화의 이해

테스트 자동화가 무엇이라고 생각하시나요?
2.1 테스트 자동화 전략 수립 II. 테스트 자동화의 이해
테스트 자동화?
기대하는 바 없음(아무 생각 없음)
테스트를 뭔가 삐까뻔쩍하게
사람이 신경쓰지 않아도 휙휙~ 슉슉~~
해 줄 것 같은 그 무언가.
내가 하는 반복적인 일을 대신, 쉽게 해 주는 툴
* 툴 : 망치, 가위, 마우스, 이클립스

테스트 툴의 분류기준
- 툴의 분류는 다양한 테스트의 활동 중 툴이 지원하는 주된 기능에 따라 분류가 됨
- 비용관점에서는 오픈소스툴과 상용툴로 분류됨
분류 상세 분류
테스트 관리
지원 툴
요구사항 관리 툴 / 테스트 관리 툴 / 결함 관리 툴 / 형상 관리 툴
정적 분석
지원 툴
리뷰 지원 툴 / 정적 분석 툴 / 모델링 툴
테스트 설계
지원 툴
테스트 설계 툴 / 테스트 데이터 툴
테스트 실행 및
로깅 지원 툴
테스트 시뮬레이터 / 테스트 실행 툴 / 테스트 커버리지 측정 툴 / 보안 테
스트 툴 / …
성능 및
모니터링 툴
성능 테스트 툴 / 모니터링 툴
테스트 툴의 종류 ( 테스트 지원 활동 기준 )

테스트 실행 툴 적용의 가치
- 반복적인 업무 감소
- 일관성과 반복성 제공 ( 테스트 수행 결과 )
- 객관적인 평가 제공 ( 테스트 커버리지 등 )
- 테스트 또는 테스팅 진행 정보에 대한 쉬운 접근성 제공
- 인적자원으로 수행 불가한 테스트 작업 수행 ( 성능/부하 테스트 )
테스트 실행 툴 적용의 위험요소
- 툴의 성능 및 기능에 비해 비현실적인 기대치
- 툴 도입 초기, 툴 사용(적용), 툴 유지 보수에 상당한 시간, 비용 그리고
노력이 투입되는 것을 과소평가
- 툴에 대한 지나친 의존 ( 상황에 맞게 대입이 아닌, 툴에 상황을 맞춤)

※ (토론) 테스트 자동화를 논하기에 앞서
- 자동화란 기존에 사람이 하던 단순, 반복적이고 정형화된 일을 기계가 하도록 하는 것.
사람도 하지 않던 일을 기계가 하게 하려면 @!#&*)(*&^%
- 과연 자동화한 테스트가 사람이 하는 테스트와 동일한 테스트를 하고 있는지
과연 “좋은 테스트”를 자동화하는가?
정말 “자동화 테스트”는 “사람 테스트”와
똑같이 하는가?
자동으로 돌아가게 하는데만 너무 집중해서
자동화된 테스트가 결함을 찾을 수 있게
작성되지 않는 경우
사람은 자신의 감각과 지식, 경험 등을 종합하여
테스트 대상을 테스트 하지만 이걸 그대로 자동화하는
것은 (현재는)거의 불가능하다.
사람의 테스트와 자동화된 테스트를 단순히 수행 횟수로
비교하는 건 무리가 있다
그렇다면?
사람이 오랫동안 반복적으로 테스트 하면서
그 체크 패턴이 정형화된 경우에 자동화가 성공하기 쉽다

테스트 자동화 툴의 ROI ( Return on Investment )
- ROI가 좋기 위한 조건
회귀테스트의 중요성이 있는 제품
매뉴얼 테스트 시 필요한 비용보다 적어야 함
비교적 안정적인 시스템
- 일반적으로 자동화 테스트 비용대비
효과는 다수의 프로젝트에 적용한 뒤에 얻을 수 있음
• Dev : 10배, Exec : ½배, Maintenance : 3배• Dev : 10배, Exec : ½배, Maintenance : 3배
11회
15회
17회

테스트 자동화 실패 사례
(1) 관리자의 지시로 시작된 테스트 자동화, 구축은 했지만 곧 테스트 스크립트는 망가졌
고 담당자는 부재했다
(2) 오픈소스 툴로 테스트 자동화를 시작했고 기술적 문제에 부딪쳐 좌초했다
(3) 전문인력이 투입되어 구축을 했지만 완료 후에 떠났고 빈약한 산출물만으로는 남은
인력이 어떤 테스트인지 알기 어려웠고, 유지보수 하기도 어려웠다
(4) 돌아가는 테스트 자동화를 구축했지만 돌아가는 데에 급급했지 결함을 찾지는 못했다
(5) 테스트 수행 시간이 너무 오래 걸려서 잘 사용되지 않았다

테스트 자동화의 실패 원인
(1) 테스트 자동화는 많은 노력과 집중이 필요한 일이다. 테스트 자동화를 일하고 남는 시간에 하도록
하는 경우 실패한다
(2) 명확한 목적 부재 : 테스트 자동화의 목적은 여러가지가 있을 수 있다. 하지만 이를 동시에 달성하
기는 어렵다. 테스트 자동화의 목적이 정의되지 않으면 십중팔구 실패하게 된다
(3) 경험 부족 : 초보 프로그래머가 구현한 테스트 자동화는 종종 유지하기 어렵다
(4) 많은 실패 : 테스트 자동화는 경우에 따라 기술적으로 많이 어렵거나 시간이 오래 걸릴 수 있다. 이
런 실패 비용이 클 경우 실패할 수 있다
(5) 자동화에 앞서 테스트의 문제 : 테스트 자체에 문제가 있는(안정화가 안 되어 있는) 경우는 테스트
자동화가 답이 아니다
(6) 테스트 보다는 기술, 관리자 관점 : 많은 사람들이 테스트 자체보다는 자동화하는데 더 흥미있어 한
다. 이런 것들로 인해 테스트 관점을 잃을 수 있다

테스트 자동화 성공사례
(1) 단위 테스트, API 테스트 자동화
(2) 빌드 후 테스트 대상 전체에 대해 간단한 헬스체크 테스트
(3) 특정 기능에 대한 반복 테스트 – 대량 데이터에 대한 데이터 기반 테스트
(4) 매뉴얼 테스트를 돕는 보조적인 역할
– 테스트 설정 작업이 복잡한 경우에 대한 자동화
(5) 멀티 브라우저 테스트
(6) 하나의 자동화로 많은 모바일 장비에서 수행하는 자동화

※ 관련 서적
- 제목 : 테스팅 전문가들의 생생한 사례연구 스토리로 익히는 소프트웨어 테스트 자동화
- 지은이 : 도로시 그레이엄, 마크 퓨스터
- 출판사 : 에이콘
전세계 수십 개 프로젝트에서
테스트 자동화를 성공/실패한 사례들
한글판 있음

※ 옮긴이의 글
테스트 자동화는 QA와 테스트 엔지니어의 로망이다. 테스트 자동화를 꾸며주는 화려한 수식어를 듣고
있으면, 당장이라도 나를 오아시스로 이끌어 줄 것만 같다. 자동화 버튼을 한 번 눌러 두고, 그저 여유롭
게 야자수 아래에서 열매나 따 먹으면 될 것 같은 상상을 하게 된다. 하지만 현실은 다르다.
내 경험에 비추어 보면 국내에서는 5년 전만 해도, 테스트 자동화는 실패가 당연한 것으로 보였다. 자동
화가 돌아간다는 짧은 환희만 맛볼 뿐, 인공 호흡기를 늘 해주어야 연명해나가는 것이 테스트 자동화였
던 것 같다.
다윗과 골리앗의 이야기를 들어본 적 있을 것이다. 다윗은 왕의 갑옷과 칼을 착용하고 시험삼아 몇 걸
음 걸어보지만, 거추장스러워서 도저히 행동할 수 없었다고 한다. 결국 다윗이 골리앗을 상대할 때 사용
한 것은, 늘 손에 있던 물맷돌이었다.

테스트 자동화의 목적
- 테스트는 결함을 찾지만 자동화는 그렇지 않다
- 자동화는 테스트를 하기 위한 수단이다
- 특히나 회귀 테스트 자동화의 목적이 결함을 찾는 것이라면 위험한 목적일 수 있다
- 아래는 각 테스트 방식에 따른 결함 발견율 사례로 자동화된 테스트는 전체 결함의
일부만을 찾을 수 있다

테스트 자동화 적용 단계
- 테스트 자동화의 목적 정의
- Pilot 수행을 통한 문제점 도출 및 개선
•조직의 능력
평가
•테스트
프로세스 개선
준비
•툴 도입
요구사항 식별
및 정의
•도입 가능한 툴
조사
•제약사항 식별
및 검토
•In-house 개발
가능성 검토
•툴 평가 기준
준비
•기능 및 관련
기술 평가 및
검토
•툴 및 공급사
평가 실시
•파일럿
프로젝트 선정
•툴 시범 적용
실기
•요구사항 만족
여부 평가
•시범 적용을
통한 문제점
도출 및
해결방안 검토
•툴 선택 기준
준비
•ROI 및 테스트
프로세스 개선
고려
•툴 선택 기준에
의한 툴 선택
•툴 도입 계획
수립
•전담 조직 할당
및 관련 인프라
구축 계획
•툴 도입에 따른
테스트
프로세스 개선
•툴 배포 계획
수립
•교육 및 훈련
계획 수립
•툴 설치 및 환경
구축
•툴 적용의
내재화 및 성공
사례

※ (참고) 애자일 테스트에서 얘기하는 각 영역별 테스트 자동화의 ROI
( 초기 러닝커브가 있기는 하지만 ) 상위보다는 하위 영역의 테스트 자동화가 더 큰 효과 (투자대비 성과) 가 있다
[ An Overview of Agile Testing by Lisa Crispin ]
[ 애자일 테스트 자동화 피라미드 ]
각 피라미드의 영역은 자동화했을 때 투자대비 효과를
의미하며, 이는 곧 자동화해야 하는 양을 뜻한다
아기돼지 삼형제 이야기 비유
패트릭 윌슨-윌시(Patrick Wilson-Welsh, 2008)는 테스트 자동
화의 개념을 "아기돼지 삼형제"에 비유해서 설명했다.
맨 아래 단계는 벽돌집으로 이 테스트는 견고하여 늑대가 와
서 건드려도 끄떡없다.
중간 단계는 통나무집으로 튼튼한 상태를 유지하기 위해서는
벽돌집보다는 자주 그 구조를 바꾸어줘야 한다.
맨 꼭대기 단계는 초가집으로 튼튼하게 유지하기가 어렵고
늑대가 쉽게 망가뜨릴 수 있다.
초가집보다는 벽돌집이 “고통스런 러닝커브”를
지나고 나면 큰 효과를 낸다
ROI가 가장 큰
단위테스트 자동화

테스트
1. 정적분석 툴 - PMD
ContentsContentsContentsContents
2. 테스트 자동화의 이해
3. GUI 테스트 툴 – Selenium 소개
4. GUI 테스트 툴 – Sikuli 소개
5. REST API 테스트 툴 – SoapUI 소개
6. 정 리 – 실 사례 등

3.1 Selenium 소개

GUI (graphical user interface) 테스트 자동화 툴 비교
3.1 Selenium 소개 III. Selenium
구분 Selenium Sikuli HP – UFT(QTP)
라이선스 오픈소스 오픈소스 유료
인식방식 오브젝트 기반 이미지기반 오브젝트 기반
특징
Web application에 대한 multiple
platforms and browser 지원
-윈도우 환경의 여러 application
지원 가능
- 윈도우 환경의 여러 application
지원 가능
지원
브라우저
Firefox, IE, Chrome, opera, safari 이미지 인식 방식으로 관계없음 IE, Firefox
스크립트
언어
Selenese,
Java, C#, Perl, Python, Ruby,
PHP
Python VB Script
테스트 결과
검증방식
별도 검증함수 제공 스크립트 언어 통해서 검증 별도 검증함수 제공
강점
멀티 브라우저 테스트 가능
Firefox IDE를 이용해 Record 가
능
이미지 인식 방식으로 UI 컴포넌
트 인식율이 높음
상용인 만큼 툴 안정성이 높고 많
은 사례를 갖고 있음
약점
오브젝트 인식이 안 되는 경우가
있음
해상도, 브라우저 등이 변경되면
이미지 인식이 안 됨
상용 툴,
오브젝트 인식이 안 되는 경우가
있음(요청시 기술 지원)

Image 기반 인식
※ (참고) Object 기반 vs Image 기반 인식 방식
< UFT(기존 QTP) >
로그인 버튼 인
식 Script사례
로그인 버튼 인
식 Script사례< Selenium >
< Sikuli >< eggPlant >
Object 기반 인식
로그인 버튼의
내부 속성 값으로 인식
로그인 버튼의
모양으로 인식

Selenium 이란
- Record & Play 방식의 Opensource UI테스트 자동화 툴 ( Selenium IDE )
- 기록된 스크립트를 활용하여, 자동빌드, 데이터 다양화로 자동테스트 용도로 활용
( Selenium RC )
- 웹 어플리케이션을 위한 Portable 소프트웨어 테스트 프레임 워크
- 테스트 스크립트가 HTML, Junit 등으로 작성
- 웹 브라우저에서 JavaScript를 구동시키는 방식으로 동작
- JavaScript를 활용하여 테스트 시나리오대로 browser 화면을 조작하는 방식

Selenese(Selenium 스크립트) 소개
- Selenium의 테스트 스크립트
- 스크립트가 HTML 테이블에 “액션키워드 – 대상 – 값” 형태로 구성
[ 네이버에서 특정 키워드로 검색하는 테스트 스크립트 ]
- 다음 URL을 열어라(open)
- 현재 페이지의 타이틀이 “NAVER”인지 확인하라
- 다음 요소(링크)를 클릭하고 기다려라
- 검색어 필드에 “명량”이라는 검색어를 타이핑하라
…
- 검색결과에 다음 링크가 존재하는지 확인하라
…
…
명령어 대상 값

3.2 Selenium 실습

Selenium-
Core
Selenium 수행 절차
3.2 Selenium 실습 III. Selenium
테스트 대상 UI
+
Selenium
스크립트
1) Record
2) 스크립트 Export
3) 스크립트 보완
4) 테스트 수행
CI 서버
Selenium
RC 서버

Selenium IDE 실행
기본 주소
수행 속도 조
절
Test Case
Test Suite
Test Scripts
Recording
Command
Target
Value
수행 로그 등
스크립트 수행

Recording 실습
(1) New TestSuite -> MovieSearchTestSuite.html 저장
(2) New TestCase -> GoogleSearchTestCase.html 저장
- www.google.co.kr 열기 검색어에 “명량” 입력 검색 버튼 클릭
검색 결과에 “명량” 있는지 검증 다시 첫 페이지로 돌아오기
(3) New TestCase -> NaverSearchTestCase.html 저장
- www.naver.com 열기 영화 버튼 클릭 “명량” 입력 검색 버튼 클릭
영화 상세 정보로 이동 검색 결과에 “명량” 있는지 검증 다시 첫 페이지로 돌아오기

TestSuite 저장, TestCase 저장
- 실습에서의 구성
- 일반적인 구성
MovieSearchTestSuite.html NaverSearchTestCase.html
GoogleSearchTestCase.html
회원관리TestSuite.html 관리자로그인TestCase.html
회원조회TestCase.html
회원등록TestCase.html
회원수정TestCase.html
회원삭제TestCase.html

Selenium 주요 명령어
Command 설명 Target Value
결과
검증
assertText(),
verifyText()
검증 실패 시 test 중지
검증 실패 시 로그 남기고 진행
위치 검증할 값(Text) ~Text 외에 Element, Tiltle
등 다양한 명령어 지원
값 저장/
반환
storeText() 값을 변수로 저장 위치 저장할 변수명 Text 외에 Location, table
등 명령어 지원
키보드
조작
type(text),
Click
sendKey
text 입력
클릭 효과
다양한 키 효과
위치
위치
위치
입력할 값
-
키 종류 값
대기하기
waitForXXX
waitForPageToL
oad
waitForPopUp(
windowID,time
out)
XXX(Text, Element등)을 기다림 위치
Timeout
값
-
영역
selectWindow
selectPopUp()
지정한 창/윈도우 선택 windowID -

Recording 실습

Recording 팁
- 재사용, 유지보수 용이성을 위해 전체 테스트를 알맞은 단위로 구조화, 모듈화가 필요
* 하나의 TestSuite은 여러 개의 TestCase로 구성할 수 있고, 기존 TestCase를 가져올 수
있다
- 시작과 끝이 중요, 예를 들면 각 모듈의 시작은 처음부터 시작하도록, 끝은 처음으로 돌
아가도록 작성한다
- 매 페이지 이동마다 페이지 이동이 정상적으로 수행되었는지 assertTitle(현재 페이지 타
이틀 확인)과 같은 검증코드를 삽입하면 나중에 테스트가 실패할 때 원인을 파악하기
쉬워진다
- 테스트가 빠르게 이동되는 상황을 고려해 서버 응답을 기다리는 부분에 waitForXXX 기
능을 이용한다

※ Selenium 사용 Tip
- 경고메시지 창 컨트롤 시 주의 사항
- Popup창 처리 시 주의 사항
• Alert창을 인식하지 못함.
• assertAlert를 제거.
• assertConfirmation 대신, storeConfirmation을 사용
• Alert창을 인식하지 못함.
• assertAlert를 제거.
• assertConfirmation 대신, storeConfirmation을 사용
• Popup창 인식의 어려움
• Popup창이 있으면, Test case를 분리하여 작성
• Popup창 인식의 어려움
• Popup창이 있으면, Test case를 분리하여 작성

- 오브젝트 (디폴트) 인식 방식(css, id, name 등등) 설정
오브젝트 인식 방식을 설정에서
우선순위 조절 가능
IDE – Locator builders 설정에 따라
Object 우선 인식

- 레코딩/스크립팅 시점에 지정 방법
: 특정 오브젝트에 대해 소스보기를 통해 직접 설정할 수도 있다
Link -> Hyper Link 되어있는 텍스트를 검색
CSS Selector -> ID 값을 가지고 선택
CSS Selector -> "+New" 텍스트가 포함된 Object를 검색
XPath -> ID 값을 포함한 < a > 를 검색하여 직계 하위 < span > 의 두번째 Tag
XPath -> "+New" 텍스트를 포함한 < span > 을 검색
- 결과 검증
: 특정 텍스트가 현재 페이지 / 특정 위치에 표시되는지 검증
Command : verifyTextPresent / assertTextPresent
Target : ex) Welcome ( Text )
: 특정 요소(element)가 현재 페이지 / 특정 위치에 표시되는지 검증
Command : verifyElementPresent / assertElementPresent
Target : ex) id=DrName ( Object 의 Attribute 값 : id / name )

스크립트 Export(Java)
- 각 TestCase를 선택하고 Export 합니다
- 간단한 실습을 위해 Junit 4 / Remote Control 로 Export 합니다

3.3 Selenium 활용 사례

값의 저장 및 활용 , 데이터 기반 테스트 확장 사례
- (사례) 별도로 프로그래밍을 해서 엑셀 데이터 기반의 테스트 코드 작성
3.3 사례 III. Selenium

멀티 브라우저 테스트를 위한 처리 (1/2)
- Junit으로 Export한 Selenium 코드에서 브라우저 부분을 FireFox 이외에
다른 브라우저 - 구글 크롬, IE, 오페라 등- 로 변경하여 테스트 수행 가능
selenium = new DefaultSelenium("localhost",
4444, "*chrome", "https://www.google.co.kr/");
*chrome -> 파이어폭스 브라우저
*googlechrome -> 크롬 브라우저
*iexplore -> 인터넷 익스플로러
*opera -> 오페라 브라우저
*safari
*custom 직접경로지정

멀티 브라우저 테스트를 위한 처리 (2/2)
- 시스템 변수를 이용하여 동적으로 브라우저 테스트를 하기 위한 코드 사례
(사례) 시스템 환경변수 값을 바꿔서
하나의 테스트 스크립트로
여러 브라우저에서 테스트가 수행되도록
테스트 코드 작성

정리
- Record & Playback 툴은 비용이 적게 투입될 것으로 예상하지만, 테스트 스크립트의 변
화에 대응이 어렵기 때문에, 다량의 테스트 케이스가 작성되어 있다면, 실행 및 유지에
큰 비용이 필요함
※ Data-Driven방식은 스크립트와 데이터가 분리되어 있기 때문에, 업무 전문가가 데이터
를 만드는 작업에 참여가능
※ Keyword-Driven방식에선 업무 전문가가 Keyword 나열로 참여하고, 세부적인 스크립
트 작성은 자동화툴 전문가가 수행

4.1 Sikuli 소개

Sikuli (시쿨리?)란
- 오픈 소스 ( http://www.sikuli.org/ )
- 시쿨리는 Jython 기반의 언어
- 간편함과 배우기 쉬운 것이 특징
- 화면을 캡쳐하여 해당 이미지를 대상으로 받아 스크립트 작성
- 스크립트는 Python 언어
4.1 Sikuli 소개 IV. Sikuli
[ 이미지 인식 기반의 GUI 테스트 ]

※ 설치방법
1. http://sikuli.org 홈페이지 접속
2. Download 메뉴로 들어감
3. 현재 최종 버전 Sikuli 1.0.0 다운위해 ’visit Launchpad ...’ 이 곳을 클릭
4. Sikuli-IDE-1.0.0-Win32.zip(md5) 파일 선택, 다운로드
5. Java JRE (Oracles Java 6 and/or Java 7)가 설치되어 있어야 함
6. 압축을 풀고 sikuli-ide.cmd 파일을 열면 툴 창이 뜸
7. 홈페이지 메뉴에서 DOCUMENTATION 메뉴를 클릭하면 사용법이 나와있음

Sikuli IDE 구성
- 별도의 Sikuli IDE를 이용하여 이미지 캡처 및 스크립트 작성
스크립트
실행버튼메뉴
이미지 관련 명령어

Sikuli 명령어
- 마우스 조작, 키보드 조작, 이벤트 감시 명령어
- 이 외에도 Python 언어 기반의 문법 사용

자주 사용되는 명령어
화면 전체 또는 특정 영역에서 가장 일치하는 구성요소 찾기
화면 전체 또는 특정 영역에서 구성요소가 나타나기를 기다림
가장 일치하는 구성요소를 클릭
가장 일치하는 구성요소를 두번 클릭
첫번째 구성요소를 두번째 구성요소에 끌어놓음
Text를 현재 창에 입력
구성요소에서 마우스 오른쪽 버튼을 클릭
※ type(특정키) 타입시
- KEY.ENTER
- KEY.TAB

4.2 Sikuli 실습

실습 절차
- 실습 : www.google.co.kr 열기 검색어에 “명량” 입력 검색 버튼 클릭 검색 결과에 “명량” 있
는지 검증
4.2 Sikuli 실습 IV. Sikuli
1) 페이지 오픈
2) 페이지 정상 오픈 확인
3) 검색어 입력
4) 페이지 정상 오픈 확인
5) 검색결과 확인
6) 최초 페이지로 돌아가기

스크립트 예

작성 Tip (1/2)
1) 스크립트 작성 전 파일 저장 : 이미지 파일이 삭제되는 경우 일부 발생,
저장 경로에 한글이 있을 경우 이미지 인식에 영향 줄 수 있음
2) 한글 입력 처리 – UTF-8 encoding : 아래 내용을 sikuli 파일 최상단에 입력,
한글 입력은 type 명령이 아닌 paste 명령어 이용
# This Python file uses the following encoding: utf-8
paste(”한글”)
3) 특수키 입력 : Key.
type(Key.ENTER)
4) 실행 전 창 모두 내리기
type("d", Key.WIN)
5) Synchronization
sleep(sec), wait( 이미지 )

작성 Tip (2/2)
6) 브라우저 실행 : App.open(브라우저 exe 파일 위치)
App.open("C:Program FilesInternet Exploreriexplore.exe")
7) 이미지 파일 정제를 통한 재사용성 높이기
- 캡처된 이미지 파일명을 가독성 있게 변경,
- 속성에 따라 이밎 폴더를 구분
하여 이미지 재사용, 스크립팅 시간 단축, 스크립트 유지 보수성을 높일 수 있다
8) 주석처리는 #
9) Python 주요 구문

※ (참고) Sikuli Script, Image 불러쓰기
작성해 놓은 ‘login_I.sikuli’
Import 하기
이미지 파일이 다른 폴더에
있을 경우 Path 추가
같은 레벨 폴더에 있을 경우
경로지정 없이 import만 써
줌

※ (참고) 이미지 인식 정확도 설정 등
캡처한 이미지를 클릭하면 ‘패턴 설정’ 화면이 뜸. 상황에 맞게 아래와 같이 설정해 줌
1. 파일 2. 매칭 미리보기 3. 대상위치
해당 이미지의 파일 이름
을 변경할 수 있음
가독성을 위해 파일명 변
경 권장
해당 이미지의 파일 이름
을 변경할 수 있음
가독성을 위해 파일명 변
경 권장
Similarity를 조절하면 현재 화
면에서 해당 이미지로 인식한
부분 표시. 원하는 인식률 설
정 가능
Similarity를 조절하면 현재 화
면에서 해당 이미지로 인식한
부분 표시. 원하는 인식률 설
정 가능
이미지 중에서 포인트 할
부분을 지정해줌
이미지 중에서 포인트 할
부분을 지정해줌

4.3 Sikuli 사례

Python 파일을 Junit에서 실행하기
4.3 Sikuli 사례 IV. Sikuli
package sikuli;
import java.io.File;
public class TestSikuli {
@Before
public void setUp() throws Exception{
}
@Test
public void testTestSikuli() throws IOException{
ImageLocator.addImagePath(“scripts/test/TestSikuli.sikuli”);
PythonInterpreter interp = new PythonInterpreter();
File src = new File(“scripts/test/TestSikuli.sikuli/TestSikuli.py”);
FileInputStream is = new FileInputStream(src);
interp.execfile(is);
is.close();
}
@After
public void tearDown() throws Exception{
Screen s = new Screen();
s.type(Key.F4,Key.ALT)
}
}
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import org.python.util.PythonInterpreter;
import org.sikuli.script.ImageLocator;
import org.sikuli.script.Key;
import org.sikuli.script.Screen;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
테스트 끝난 후
‘ALT+F4’로 창 닫기
‘.py’ 파일의 경로
이미지 경로

Sikuli Java API를 활용하여 실행하기
※참고) s.type(key.BACKSPACE) : 선택된 모든 text 삭제
가능

※ 이클립스에서 실행하기
Arguments
-Dsikuli.Home="C:sikuliSikuli-IDE-1.0.0-Win32"
Environment
PATH = C:sikuliSikuli-IDE-1.0.0-Win32libs
Eclipse > Run > Run Configuration

Selenium + Sikuli 활용 사례
Selenium 강점 + Sikuli 강점
- Sikuli의 경우 이미지 인식 기반의 특성상 해상도, 브라우저 등이 변경되면 인식이
안 되는 경우가 있음
- Selenium의 경우 오브젝트 인식이 안 되는 경우가 있음
=> Junit 상에서 Export 및 보완한 Selenium 테스트 코드를 기본으로 작성하고,
이 중 Selenium 동작이 어려운 부분만 Sikuli의 Java API로 작성
JUnit
Selenium
API
Sikuli
API
테스트 대상
Selenium 기반 테스트 코드 + Sikuli 기반 테스트 코드

5.1 RESTful OpenAPI 란

OpenAPI 열풍
“최근 인터넷 업계는 OpenAPI의 열풍이 불고 있다. 너도나도 OpenAPI를 공개하고 있고
사용자들에게 다양한 방식의 사용을 기대하고 있다. 최근 이 OpenAPI와 함께 거론되는
기술은 당연 REST이다. 구글, 아마존, 네이버 모두가 OpenAPI를 REST 방식으로 지원한
다”
5.1 RESTful OpenAPI 소개 V. SoapUI
신용
정보
회사
우리 시스템
[ 예전의 OpenAPI ] [ 현재의 OpenAPI 활용 사례 ]
버스 도착정보
알림 서비스
개인이
만든 앱
게임
앱
게임 서버
비즈니스
서비스(예:CellWe)
스마트
폰
웹
HTTP
HTTP
HTTP
HTTP
스마트폰 보급과 함께다양한 디바이스에서의서비스 욕구↑

OpenAPI 란
- 데이터 플랫폼을 외부에 공개하여 다양하고 재미있는 서비스 및 어플리케이션을 개발
할 수 있도록 외부 개발자와 사용자들과 공유하는 프로그램 (Daum)
- 다양한 서비스와 컨텐츠, 데이터를 좀더 쉽게 이용할 수 있도록 공개한 개발자를 위한
인터페이스 (Naver)
- 웹사이트가 자신의 기능을 이용할 수 있도록 공개한 프로그래밍 인터페이스로 내부를
모르더라도 공개된 API를 이용하여 해당 사이트의 기능, 데이터들을 쉽게 이용 가능
(Nate)
- a word used to describe sets of technologies that enable websites to interact with
each other by using REST, SOAP, JavaScript and other web technologies (Wikipedia)

RESTful 웹 서비스
- REST (Representational State Transfer)
- SOAP기반, WSDL기반 웹서비스를 대체하는 개념
- 쉬운 사용성으로 Yahoo, Google, Facebook 등 각 서비스들이 SOAP, WSDL을 대체하여
서비스 중
- CRUD를 위해 HTTP 메소드를 사용
- Stateless 함 = 요청을 위해 특정 값, 세션, 쿠키값을 유지 하지 않음
- 디렉토리 구조와 같은 URI 을 통한 리소스 접근
- XML, JSON 데이터 구조를 통한 데이터 전송
웹 상에 공개되는 OpenAPI의 경우 RESTful 웹서비스(*)로 구현되는 경우가 많음

RESTful 웹 서비스 구성
- HTTP URI + HTTP Method
HTTP Method
WADL URL
(End Point)
Resource Path
Query Parameter
(Method
Parameter)
Path Parameter
(Resource
Parameter)
- 개념 : 웹서비스
- 구현방식 : SOAP vs RESTful
- RESTful 웹서비스 구현기술 : 다양한 언어, 다양한 프레임워크에서 쉽게 개발할 수 있도록 제공

REST METHOD
- CRUD 연산에 HTTP Method 를 이용
- POST, PUT의 경우 Request Body 필요

5.2 SoapUI 소개

SoapUI ?
- SOAP, REST 방식을 모두 지원하는 웹서비스 기능 테스트 툴
- 무료, 오픈소스
- GUI 제공 (Java Swing으로 개발)
- 무료버전과 상용버전이 있음(Pro버전)
- 공식 사이트 : www.soapui.org
싸이트의 문서가 굉장히 잘 나와 있음
- 웹 서비스 특유의 http 호출, 응답을 툴을 통해 테스트 지원
- 성능/보안 테스트 기능 확보
5.2 SoapUI 소개 V. SoapUI

SoapUI 설치
- soapUI : license가 필요없으며 무료로 사용가능, 주요 기능 제거
- soapUI Pro : license가 반드시 필요하며 모든 기능 사용 가능
(2주간 사용할 수 있는 trial license 발급하여 사용 가능)
- 설치 : http://www.eviware.com > Downloads > Download soapUI Pro
> Windows 32-bit installer
SoapUI 실행
- soapui-pro.bat 파일을 통해서 실행
(C:Program FilesSmartBearsoapUI-Pro-4.0.1bin)
- 실행시 오류 발생하면 heap memory 크기 조절 필요
[ soapui-pro.bat 파일 ]

SoapUI 메뉴 구성
Toolbar 영역
Main toolbar, Icons toolbar
Navigator 영역
각 구성요소를 생성, 수
정, 삭제하면서 관리하기
위한 영역
Properties 영역
각 구성요소의 속성 및 Parameter
를 설정하기 위한 영역
Main 작업 영역
각 구성요소에 대한 주요 작
업 수행 및 수행결과를 확인
하기 위한 영역

SoapUI 테스트 스크립트 구성
Workspace
└ Project
└ Service
└ Resource
└ Method
└ Request
└ TestSuite
└ TestCase
└ TestStep
(2) API를 테스트하기 위한 요소로 TestSuite, TestCase,
TestStep 의 순서로 계층 구조로 생성됨
(1) API를 정의하는 요소로 Service, Resource,
Method, Request 의 순서로 계층 구조로 정의됨

5.3 SoapUI 실습

실습 예제
- Naver 에서 제공되는 Open API 중 검색API > 영화
- 네이버 개발자 센터 : http://developer.naver.com/
- 실습용 API키 :
- 실습 절차
(1) API 명세 파악
(2) Workspace, Project 생성
(3) Service, Resource, Method, Request 생성
(4) TestSuite, TestCase, TestStep 생성
(5) Assertion 추가, Description 작성, 테스트 실행 및 결과 레포팅
5.3 SoapUI 실습 V. SoapUI

API 스펙 파악– 1/5
- API 개요
- 요청변수
API가 어떤 기능을 하는지 파악합니다
필수여부, 데이터 타입, 코드성 데이터에 따른
테스트 조건을 파악합니다

샘플 URL('벤허'를 검색할 경우)
http://openapi.naver.com/search?key=c1b406b32dbbbbeee5f2a36ddc14067f&query=벤허&display=10&start=1&target=movie
정해진 코드 값 이외의 값인 경우.
숫자, 날짜, 범위 등의 데이터 타입 고려

- 출력결과 필드
입력/출력 값과의 연관관계에 따른
테스트 조건 파악

- 결과 코드 정의
정상(Reserved) 수행 이외에 다양한 에러 상황
에 대한 테스트 조건을 파악합니다

실습 절차
(1) Workspace, Project 생성
(2) Service, Resource, Method, Request 생성
(3) TestSuite, TestCase, TestStep 생성
(4) Assertion 추가,
(5) Description 작성
(6) 테스트 실행 및 결과 레포팅

1) Workspace 생성
- New Workspace 메뉴를 이용하여 원하는 경로에 워크스페이스 파일(xml)을 생성한다
soapui_workspace

2) Project 생성
- Workspace 하위에 Create empty project 유형으로 프로젝트를 생성한다
※ 실습에서는 아무것도 없는 상태로 생성하나 “Create REST project from URI” 유형 등으로
쉽게 생성할 수 있다
샘플 URL
http://openapi.naver.com/search?key=c1b406b32dbbbbeee5f2a36ddc140
67f&query=벤허&display=10&start=1&target=movie
※ 존재하는 URI로부터 쉽게 생성할 수 있음

- 생성한 프로젝트의 Properties에서 프로젝트 이름을 변경한다
※ SoapUI 스크립트는 그때그때, 자주 저장한다
(오류가 발생하여 프로젝트 xml 파일 자체가 깨지는 경우가 있음)

3) Service 생성
- 프로젝트를 생성하고 New REST Service from URI 메뉴와 실제 URI로 서비스를 생성한다
http://openapi.naver.com/search

4) Method 생성
- METHOD 방식이 Get 방식이 아닌 경우 생성된 Method를 생성하고 타입을 변경한다
※ POST, PUT인 경우 보통 XML, JSON 등의
Request Body 값이 추가된다

5) Request 생성
- 생성된 Request 를 선택하면 요청 값을 추가할 수 있는 탭이 표시된다
- 한글 처리를 위해 왼쪽 Request Properties에서 Encoding 을 UTF-8로 변경한다

5) Request 생성
- 입력 파라미터 추가 아이콘(+)을 클릭하여 추가해 준다
- 이 때 입력되는 값 중 고정적으로 사용되는 값은 value까지 입력해 준다
실행 버튼을 클릭해서 호출이 수행되는지
확인해 볼 수 있다
API 스펙에 따라 요청 값을 추가한다

1) TestSuite 생성
- 프로젝트를 선택하고 New TestSuite로 TestSuite을 추가합니다
- Testsuite이 추가되면 Description 탭을 선택하여 간략한 설명을 추가해 줍니다
NaverMovieSearchTestSuite
@설명 : 영화검색을 테스트하는 TestSuite 입니다

2) TestCase 생성
- TestSuite을 선택하고 New TestCase 메뉴로 테스트 케이스를 추가합니다
- 마찬가지로 Description 탭을 선택하여 어떤 내용을 테스트하려는지 간략한 설명을 작성합니다
TC_기본_001
@설명 : 영화검색 기본(정상수행) 테스트 케이스
@입력 : 명량
@기대결과 : 명량 영화에 대한 정보가 반환된다

3) TestStep 생성
- TestCase 하위의 Test Steps(0) 를 선택하고 Add Step > REST Test Request 메뉴로
스텝들을 차례로 추가합니다
- 임의로 테스트 수행을 위한 사전작업 스텝을 “setUp”, 테스트 수행 후 초기화 작업을 “tearDown”,
실제 테스트를 하는 스텝을 “수행”이라고 붙입니다

- 스텝 종류를 “REST Test Request “ 로 고르면 앞에서 작성한 Request를 선택할 수 있습니다

※ 위 API 정의 부분에서 TestStep 생성하기
- TestCase만 정의한 상태에서 상단 API 정의에서 추가할 테스트 케이스를 선택하여 스텝을
추가할 수 있습니다

- 가장 기본적인 테스트를 위해 각 입력값에 일반적인 값을 입력합니다
- 실행 버튼을 클릭하여 실행합니다
[ 기본 테스트의 입력 데이터 예 ]
target : movie
query : 명량
display : 20( 기본값 10, 최대 100(,
start : 1 (기본값 1, 최대 1000(
genre : 20 (액션 장르)
country : KR (한국)
yearfrom : 2014 (제작년도)
yearto : 2015

4) Assertion(결과 검증) 생성
- 수행 결과에서 Add Assertion 메뉴로 결과 값을 검증하는 스크립트를 추가합니다
결과값의 version 값이
항상 2.0 인지 툴이 검증하도록
검증 스크립트를 추가합니다

※ 결과 Outline에서 지원하는 검증 방식
항목의 결과가 기대하는 값
과 일치하는지 여부 점검
항목의 결과 개수 점검
항목의 존재 여부 점검
항목의 결과가 기대하는 값
과 일치하는지 여부 점검
(Regular Expression 방식)
항목의 존재 여부
(Script 방식)

※ Assertion 탭에서 지원하는 검증 방식
- 하단 Assertions 탭을 클릭하면 더 다양한 검증 방식을 제공합니다

5) 다른 테스트 케이스를 추가
- 같은 방식으로 필수 입력 필드를 입력하지 않았을 때 기대한 에러가 발생하는지 확인하는 테스트 케
이스를 추가합니다
Clone TestCase 메뉴로
복사하여 쉽게 추가할 수 있습니다
이름을
TC_예외_001 로 정하였습니다
필수 입력인 query 값에
아무 값도 입력하지 않습니다
Errir_code : 011
메시지 : 잘못된 query 값입니다
가 반환됩니다
항상 011이 반환되는지 확인하는
Assertion 을 추가합니다

※ Tip. 테스트 스텝이 실패하더라도 이후 스텝을 수행하도록 설정
- TestCase의 속성중 Abort on Error를 Check 해제

※ Tip. 수행 가능한 스텝 종류
Groovy Script
Step 사이의 delay time (ms)
TestCase를 TestStep에 활용
REST Test Request
다양한 입력 Parameter 정의
다양한 입력 Parameter 사용
JDBC – SQL 활용
별도 코드를 테스트 중간에 수행할 수 있습니다
다른 테스트 케이스를 통째로 실행할 수 있습니다
DB에 바로 접속하여 특정 값을 조회하고
이 값을 테스트에 사용할 수 있습니다

6) 테스트 결과 보고서
- TestCase, TestSuite, 전체 등으로 테스트를 실행합니다

6) 테스트 결과 보고서
- 테스트 결과 레포트 생성 아이콘을 클릭하여 SoapUI 자체 레포트 또는 Junit 스타일의 레포트를 생성
할 수 있습니다

- SoapUI 자체 레포트 스타일

- Junit 스타일 레포트 (html)

※ Tip. SoapUI 가 제공하는 테스트 커버리지
(1) 각 TestSuite, TestCase, TestStep 기준 실행 커버리지
(2) 각 API 별 호출 커버리지
(3) 각 API 별 응답 코드 커버리지

※ Tip. Properties 에 정의한 변수 값을 참조하기
TestSuite의 Test
Properties
- 변수 역할
- 임시 저장소 역할
마우스 우클릭 > Get
Data
마우스 우클릭 > Get
Data
중요 참고 사항

※ Tip. Groovy Script를 이용하여 이전 응답 값을 Properties 변수에 설정하기
- testRunner.testCase.testSuite.setPropertyValue("var_lng", response)
직접 코딩
중요 참고 사항

※ Tip. SoapUI에서 API 성능 테스트하기 (1/2)
- API 성능테스트를 위한 LoadTest 항목 생성

※ Tip. SoapUI에서 API 성능 테스트하기 (2/2)
- API 성능테스트 구성
* 테스트 통
계
동시 사용자 수 테스트 전략 설정
테스트 종료 기준
setUp, tearDown을 구
성

6. 과정 정리

테스트 전략과 이에 따른 테스트 툴 적용 사례
- 샘플 아키텍처 및 테스트 영역
6.1 사례 VI. 정리
RDMBS
DAO implementations
DAO interfaces
Service implementations
Service interfaces
Other remote
interfaces
Data Access
Layer
Service
Layer
Presentation
Layer
개별 화면에 대한 매뉴얼 테스트
Controller에 대한 테스트
Service에 대한 테스트
DAO 에 대한 테스트
Controller REST API
RESTful API 테스트
Web Clients

테스트 전략과 이에 따른 테스트 툴 적용 사례
- (사례) 테스트 단계, 테스트 대상, 주 수행자, 수행방법 등에 대한 프로젝트 별 계획 수립 예
테스트테스트테스트테스트
단계단계단계단계
테스트테스트테스트테스트
대상대상대상대상
정의정의정의정의
주주주주
수행자수행자수행자수행자
사용도구사용도구사용도구사용도구 입력물입력물입력물입력물 수행시기수행시기수행시기수행시기
단위
테스트
DAO
각 대상에 대한
개발자 단위테스트
개발자
Junit 설계 산출물 개발중 상시
Service Junit 설계 산출물 개발중 상시
REST API SoapUI REST API 스펙 개발중 상시
단위 화면
개발자/
3자 테스터
매뉴얼
테스트
설계 산출물 등 개발중 상시
통합
테스트
내부 통합 흐름
(업무, 시스템간)
프로젝트 내 업무간,
시스템간에 통합 테스트
분석/설계/
개발자
Selenium
(+Sikuli) 내부/외부
통합테스트
시나리오
내부/외부
통합테스트
일정외부 통합 흐름
(외부기관)
외부 기관 등관의
통합 테스트
분석/설계/개발자
매뉴얼
테스트
3자 통합
테스트 내부 통합 흐름 3자에 의한 통합 테스트 3자 테스터
매뉴얼
테스트
테스트시나리오
3자
통합테스트
일정
사용자
인수
테스트
내/외부
통합흐름
사용자 관점의 인수 테스트 고객 TF
매뉴얼
테스트
테스트시나리오
인수테스트
일정

단위 테스트 및 코드 인스펙션 툴 사용은 별도 자료로 작성

테스트 자동화가 필요한 이유
테스트 자동화를 통해 다음의 효과를 얻을 수 있다
- 신속한 릴리즈를 위한 테스팅 속도 향상
- 테스팅을 더 자주 수행할 수 있도록
- 반복되는 수작업 테스트 공수를 줄여 테스팅 비용 절감
- 테스트 커버리지 향상
- 일관성(consistency ) 보장
- 테스팅 신뢰성 향상
- 비기술자도 테스팅을 수행할 수 있도록
- 테스팅을 더 흥미롭게 하기 위해서
- 프로그래밍 스킬 개발을 위해
6.2 정 리 VI. 정리

테스트 자동화 성공을 위한 7가지 단계
1단계) 무조건적인 테스트 자동화에 앞서 테스트 프로세스를 검토하고 최적화하라
- 테스트 자동화는 이 과정의 한 방법이다
2단계) 자동화의 목적을 정의하라
- 테스트 자동화는 만병통치약이 아니다. 실패한 사례의 대부분은 아무런 목적 없이 시작한 경우이다
3단계) 개념 증명을 위한 Pilot 을 반드시 수행하라
- Pilot을 통해서 원하는 목적을 달성할 수 있는지. ROI는 나오는지, 어떤 기술적, 인력적 이슈들이 있는지 파악하고
적용을 시작할 수 있다
4단계) 제품의 Testablility를 획득하라
- 테스트가 용이하도록 개발 아키텍처를 조정하라. 예를 들면, GUI 테스트 자동화는 상대적으로 API 나 CLI 같은
특정 인터페이스 테스트보다 어려우므로 테스트가 가능하도록 설계를 변경하라
http://www.io.com/~wazmo/papers/seven_steps.html

5단계) 오래가는 테스트를 설계하라
- 테스트 자동화는 기능적이어야 하고 계속되는 제품 개발에 따라 유지/ 확장 될 수 있어야 한다
- 이런 관점에서 다음 내용들을 만족해야 한다
. 테스트 수행 속도
. 테스트 결과가 분석하고 디버그 하기 쉽도록,
. 작성된 테스트가 이해하기 쉽고 리뷰하기 쉽도록
. 작성된 테스트 스크립트 자체의 유지보수성 (+테스트도 라이브러리화가 필요하다)
. 테스트 결과가 진실하고 유효하도록. 테스트자동화가 통과했을 때 테스트도 진짜 통과인가?
. 독립적이고 반복 수행 가능하도록
. 데이터 기반의 테스트 : 이 테스트는 도메인 전문가가 있는 잘 짜여진 테스트 팀에 잘 맞는다

6단계) 테스트 자동화 배포 계획
- 자동화를 수행하는 사람이 바뀔 수 있다(사례를 보면 항상 바뀌더라). 또 테스트 대상을 확장하거나 기능을 확장해서
사용할 수도 있다. 이를 위해 셋업 과정을 문서화하고, 테스트 툴을 설치하고 실행하기 더 쉽게 만들어야 한다.
7단계) 안정화되면 그 다음 단계로 도전하라
- 테스트 자동화가 안정화 되면 그 다음 단계로 넘어가라. 예를 들면, 테스트 커버리지를 더 높이기 위한 방안을 찾거나,
자동화의 잘못된 알람(결함이 아닌데 결함으로 보고하는 비율) 줄이기, 고객이 개발 초기부터 같이하는 테스트, 자동화 적
용 가능한 시점 등

과정 회고
다음 항목 등을 생각하며 좋았던 점, 나빴던 점을 공유했으면 합니다
. 교재, 강사, 강의 환경
. 이론 설명
. PMD, Selenium, Sikuli, SoapUI 각 툴의 실습
. 현장에 활용 방안
- 좋았던 점
- 나빴던 점, 개선했으면 하는 점
- 활용 아이디어

학습목표
2일차 과정 목표
- 코드 인스펙션 툴(PMD)을 이해하고 직접 사용해 봅니다
- 테스트 자동화가 무엇인지 인식하고 각 테스트 영역별 테스트 자동화의
ROI(투자대비 성과) 를 고민합니다
- 각 툴에 대한 정확한 이해와 테스트 자동화 성공/실패 사례를 통해
각자의 현장에 맞는 테스트 자동화 전략을 수립할 수 있습니다
- 본 교육과정에서는 여러 테스트 툴의 기본적인 사용법을 익히고 이후 현장에
적용할 때는 전문인력 현장 지원 요청을 할 수 있습니다

테스트자동화 성공전략

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to 테스트자동화 성공전략

Similar to 테스트자동화 성공전략 (20)

More from SangIn Choung

More from SangIn Choung (16)

테스트자동화 성공전략