Jenkins 와 Selenium 을 사용한 웹 자동화(web Automation Test)

안녕하세요 

자사에 있는 제품중인 UI 제품군 중 TOP라는 웹 프론트앤드 프레임워크 의 QA를 맡고 있습니다.

우선 자동화에 대한 설명에 앞서 TOP 에 대한 설명을 제가 직접 할순 없기에 오피셜로 있는 링크를 올립니다.

해당 TOP 에 대한 공식적인 소개

https://tmaxos.com/index#TOP

(소개 페이지였었지만 지금은 TOP로 개발한 홈페이지가 되었습니다) 

기본적으로 Tool + web framework 형태인데

오늘 포스팅 할 내용은 web framework 에 대한 자동화 이야기 입니다. 

IDE라고 하는 tool 자체에 대한 자동화 이야기는 다음에 작성 할 예정입니다.

비즈니스 프레임워크 중에 는 이례적? 이라고 해야할까요 최신 웹 프레임워크의 트렌드를 가진 프레임워크 입니다.

(SPA,Router,Controller,CSR... 등등)

또한 사용자가 만들어야 할 html 코드를 최소화 하여 Data 형태 만  정하게 되면 화면에 나타날수있게 도와줍니다. 

해당 프레임워크에서는 위의 링크와 같이 화면을 구성하기 위한 수십개의 컴포넌트와 컨테이너 등을 제공하게 되는데

그럼과 동시에 해당 컴포넌트들은 크로스 브라우징 형태로 제공이 되기 때문에 지원하는 브라우저가 많아지는 경우

중복하여 확인하여야 하는 작업 이 너무 많아지게 됩니다.

그렇기 때문에 해당 테스트를 자동화 하기 위한 Selenium WebDriver(Node.js) 와 Jenkins 를 사용하여서 하나의 

Selenium 프로젝트에서 여러 운영체제 및 브라우저(Chrome,FireFox,Internet Explorer, Opera, IOS Safari, Android ) 에 

대한 테스트를 자동화를 하여야 합니다.

이와 관련하여서는 기존에 포스팅 하였던 자료가 있지만 좀더  구조적으로 설명 하며 개요 부터 설명 하도록 하기위해 

다시 작성하였습니다.

// 기존 자동화 링크 

https://ipex.tistory.com/entry/Jenkins-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A7%81%ED%81%AC-%EC%A0%A0%ED%82%A8%EC%8A%A4-%EC%97%B0%EB%8F%99-3-%EB%B2%88%EC%99%B8-Iterative-Test-Build-Steps-%EC%82%AC%EC%9A%A9%EC%97%86%EC%9D%B4-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A7%81%ED%81%AC%EC%97%90-%EC%BC%80%EC%9D%B4%EC%8A%A4-%EC%8B%A4%ED%96%89-TestCase-Execution-into-TestLink-without-Iterative-test-build-steps-on-JENKINS

프론트 프레임워크와 기존 웹 페이지 자동화의 차이점

  기존의 화면 (페이지가 만들어져 있는) 에 대한 자동화와 프론트 프레임워크 에 대한 자동화는 차이가있습니다.

            화면 자동화의 경우 A페이지 (로그인 페이지) 일 때

아이디 창에 대한 E2E 테스트가 진행된다고 하면 개발할때 의 스펙에 맞게만 테스트가 진행되어야 합니다.

ex : 50자 최대 일 경우 (50자이상입력이 되는지 )

ex : id만 입력 후 로그인 시 "비밀번호를 입력해주세요" 메시지가 하단에 출력되는지 .

ex : 아이디 입력 후 "엔터" 키 입력 시  "비밀번호" 창으로 이동이 되는지 

해당 화면은 "로그인페이지" 에만 존재하기 때문에 해당 케이스 또한 로그인 페이지에서만 유효한 케이스라고 볼수 있습니다.

하지만 "아이디 입력창" + "비밀번호 입력창" + "로그인 버튼" 이 한개의 컴포넌트라고 보게 됐을경우

<naverLogin-tag> 와 같은 형태로만들어지는 컴포넌트라면 이야기가 달라집니다. 

get함수를 통해서 현재 id pw 가 {id: "",pw:""} 받을수도 있고 하나의 컴포넌트로서 기능적인 면이 들어가기 때문입니다.

컴포넌트를 테스트하는 것과 웹 페이지를 테스트 하는 것은 다르다 

TOP에서는 이런 형태로 수십개의 컴포넌트를 제공하고 있습니다. 단 하나의 태그와 원하는 데이터 형태 로 

사용자가 작성하는 html 태그가 최소화 되는 형태로 제공됩니다.

그렇기 때문에 QA 입장에서는 위젯, 레이아웃,컨테이너가 있을 경우 각각 의 모든 케이스가 TC(테스트케이스) 가 됩니다.

레이아웃은 위젯을 배치하는 컴포넌트이고 위젯은 레이아웃에 배치되는 컴포넌트 컨테이너는 데이터를 표현하기 

위한 컴포넌트 라고 봤을때

A레이아웃  + B 위젯  + C 컨테이너만 놓고 봐도 세개의 컴포넌트에서만 케이스가 무수하게 나옵니다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

A레이아웃 안에 C컨테이너를 배치시 화면에 렌더링 되는지

A레이아웃 안에 B위젯을 배치시 화면에 렌더링 되는지

A레이아웃 안에 B + C 컴포넌트가 같이 있을시 같이 렌더링이 되는지

.....

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

그런데 문제는 하나하나 다 컴포넌트 형태이기 때문에 

각각이 제공하는 API 가있고 속성이 있습니다. 

A레이아웃 - C 컨테이너로 테스트하는데 

C컨테이너에 자체 속성이 20개 API 가 20개 일 경우 단순 무식하게 TC(테스트케이스) 를 만든다고 하면 이 숫자 또한 만만치 않게 됩니다.

그래서 원칙적으로는 페어와이즈 테스트 기법을 통해서 케이스를 추출 + 사용자들에 의해 발생하는 회귀테스트 를 우선 작성하고 이에대한 자동화를 진행하게 됩니다.

SeleniumWebDriver (Node.js) 를 사용하는 이유

  Selenium Webdriver Node.js 를 사용한 이유는 우선적 으로 말씀드리자면 JavaScript를 좀 더 많이 쓰기 때문이였습니다. 

하지만 단순히 이런 이유로 사용하기에는 자동화를 하기 위해 좀더 찾아 본 결과로는 SeleniumWebDriver 를 최초의 만들었던 제작자 가 기존의 JAVA 등의 버전에서 현재 js진영으로 넘어와서 새로 프로젝트를 하고 있기 때문이다.(링크를 하려 하였으나 아직 못찾아서 찾는대로 링크하겠습니다.)

[셀레니엄hq 공식 홈페이지]

https://www.seleniumhq.org/download/

Node.js 의 진영은 보시다시피 메이저 버전이 업된 4.0.0 alpha버전임을 확인 할수 있으며  npm 다운로드 수 또한 매우 높아 해당 셀레니움으로 사용하게 되었습니다. 결론적으로 사용하게 된 이유는

정리를 하자면 

1. 가장 버전이 높은 (활발하기때문)

2. 사용하던 js언어와 호환성

3. Node 에서 할수 있는 기능 (xml포매팅 , 파일 관리 등) 을 같이 사용 가능 (리눅스,윈도우 세팅의 편리)

4. E2E 에서 여러 브라우저를 직접 실행하여 사용가능 ( 하나의 테스트프로젝트를 통해 여러 브라우저에서 테스트 가능 ) 

이외의 알아본 lib 들은 

phantom.js && capser.js , zombie.js slimer.js , webdrivero.io, Cucumber.js , protactor, 

nightwatch.js htmlUnit,Guitar,Cypress.io,uitest, uirecorder,testCafe(*typeScript) 

정도 나열할수 있지만 이러저러한 이유로 사용하지 않았습니다.

 (기본 베이스가 셀레니움이거나, 크로스브라우징에 적합하지않음 등등)

[NPM 다운로드 수 및 이슈]

위의 사진만 비교해봐도 (2018-11-05) selenium-webdriver를 선택 한 점을 찾을수 있다.

SeleniumWebDriver 와 Jenkins 를 사용시 이점 

정확히는 소스코드를 Git으로 관리하게 되는데 이것을 이용한 사용에 대한 이점도 충분히 있습니다.

테스트 자동화 라는게 단순 자동화 를 해주는 SeleniumWebDriver만 이 아니라 일련의 작업

( 최신의 테스트 코드로 테스트를 진행 하고 결과를 리포팅 하는 작업 까지 )

자동화 프로세스

SeleniumWebDriver 코드 작성 

isDisplayDOM 사용 

Chrome브라우저의 경우 속도가 매우 빠릅니다. 타 브라우저에 비해서 그렇기 때문에 단순히 DOM Select 하고 클릭하고

다른 작업으로 넘어 가도 문제가 없지만 IE의 경우에는 이속도가 보장이 되지않는 경우가 많습니다.

(자동화 작업중 트러블 슈팅은 거의 IE에서 일어납니다. ㅜ) 

그렇기 때문에 자체적으로 테스트할 위젯 (클릭하거나 조작할 DOM Element) 를 가져올때 isDisplayDOM 이라는 함수를 만들어서 사용하게 됩니다. 

let startIdx=0;

let retTarget = await this.isDisplayDOM(id);

let tbody = await retTarget.findElement(By.css('table > tbody'));

let totalRowArray = await tbody.findElements(By.css('tr'));

isDisplayDOM 구현체

구현체는 생각보다 단순합니다. driver.wait 라는 API 를 이용해서

until(Util 관련 모듈 입니다.) 을 이용하여서 elementLocated  대상 element가 브라우저 DOM에 붙을때까지 기다립니다.

뒤에 maxWaitTime 같은 경우는 QA가 최대 대기 시간을 작성해놓습니다. 저는 2초 정도로 하였습니다. 2초안에 DOM 에 붙지 않는 다면 해당 테스트 케이스 및 시나리오는 실패로 간주합니다.

(2018-11-20 ) 해당 함수에는 아직 selector 처리가 없네요 id또는 tag , selector로 가져올수 있기 때문에 이부분에 대한처리도 같이 해줘야

진정한 모듈함수 

topqa.prototype.isDisplayDOM = async function(targetId){

let maxWaitTime = 2000;

try{

// let target = await this.driver.findElement(By.id(targetId));

let target = await this.driver.wait(until.elementLocated(By.id(targetId)),maxWaitTime);

if(targetId === await target.getAttribute('id')){

console.log("checked DOM is : ",targetId);

return await target;

}

else{

return false;

}

}

catch(err){

console.warn("isDisplayDOM Error : ",targetId)

console.error(err);

}

}; // isDisplayDOM

해당 과 같이 작성해서 사용하게 되면  DOM 뜨고 나서 진행되기 때문에 중간에  DOM 을 캐치하지못하여 종료되는 오류는 막을수 있습니다.

해당 최신 코드는 

https://github.com/lgance/selenium_tmax/blob/master/topqaModule/autoManager.js

에서 보실수 있습니다!! ( 2019년 에 퇴사를 하여 최신화를 진행하진 않습니다.)