깍돌이

안녕하세요 깍돌이입니다.  NaverCloudPlatform 을 기준으로 잡고 Puppeteer 를 통해서 UI 자동화 하는 작업들을 포스팅 하려고합니다.

UI 자동화에 대해서는 할말이 매우 많지만 그거는 개인생각 끄적끄적에서 다뤄보도록 하겠습니다.

Portal -> Console

Portal -> Portal 에 대해서 체크할수 있는 방법 

레코딩

간혹 레코딩 방식에 대해서 말씀하시는 분들이 계신데 경험상으로 느꼈지만 UI 자동화에 대한 토론을 해본적이 없었기에 현재 세상에서 UI를 레코딩으로 하는것만큼 비효율적인 게 있을까 싶긴합니다.

Pass / Fail 유무는 어떻게 판단할 것인가

=> 이미지로 판단한다고 하면 OpenCv Template Matching을 이용하여서 기대 이미지로 체크할것도 아니고 더 복잡한 케이스가 된다고 생각합니다.

예외처리에 대해서 어떻게 처리할 것인가

=> 중간에 예외 처리로 종료 되었을 때 Suspend , Resume에 대한 처리는 어떻게 할것 이며 이부분에 대해서 시스템 오류인지 제품에 대한 오류인지 판단을 어떤식으로 할지 10년 전에야 레코딩 방식이 거의 주를 이루었고 그걸 기준으로 자동화가 이루어졌지만 현재 시대 및 앞으로의 방향성에서는 레코딩 방식은 전혀 좋은 방법이 아니라고 생각 합니다. 이에 대해 다른 견해를 가지신분이 있다면 이야기 하면 너무 좋을거 같네요

결과에 따른 신뢰도 바탕이 될 수 있는 것인가

=> 사람이 눈으로 보지 않는 한 레코딩의 Pass / Fail 판단부터 명확하지 않는데 이부분에 대해서 어떻게 할지 마땅이 떠오르지 않습니다.

신입 때 자동화 발표를 봤었는데 시나리오는 아래와 같았습니다.

페이지 이동 -> 로그인 -> 검색 -> 리스트 

레코딩으로 진행된 발표였으며 Pass / Fail 기준은 리스트까지 이동하고 오류없이 진행됐으면 Pass 였습니다.

그래서 질문을 했습니다. 

질문 : " 리스트에 결과가 안나왔어도 성공인가요?

답변 : "네 맞습니다. "

이유는 기준으로 정해놓은 시나리오는 성공했기 때문이라는 답변을 받았습니다.  문제는 없는 답변이였습니다. 리스트페이지까지 이동하는게 시나리오에 제목이였기 때문에 그래서 다시 물어봤던 기억이 납니다.

질문 :  "리스트에 대한 케이스 자동화는 안되는건가요? "

답변 :  "그런건 직접 보고있습니다."

=> 사실 리스트를 클릭하게 하고 Exception 으로 종료시키는 방법도 있지만 레코딩 방법은 한계가 명확한 방법이라고 생각합니다.

Element DOM Native Code

그렇다고 Element 기반으로 하게 되었을때 그만큼 좋냐라고 물어보게 된다면 그것도 확실한 대답을 드리려면

"잘해야" 좋다고 할수있을거 같습니다. 그리고 또한 잘하냐 못하냐에 문제가 해결된다고 해도 직접 코드로 처리로 작성되는 경우는 숙련되지않는 한 공수가 매우 많이 들어가게 됩니다.

필자는 잘한다고 생각하진 않지만 꽤 숙련된 사람이라고 생각 합니다.   그러면 여기서 "잘하기가 어렵지 않냐" 라고 하시는 분들이 간혹 있었습니다. 

QA는 제가 생각하기에 개발자가 만든 제품에 대한 "테스터"가 아닙니다. "품질관리자" 입니다. 그렇기 때문에 당연히 개발 경험도 있어야 하고 최소한 시니어 개발자가 아닌 주니어 개발자 만큼 혹은 그 이상의 뷰를 가질수 있어야 한다고 생각합니다. 외국계에서는 시니어 개발자가 QA로 넘어 가서 주니어개발자들의 코드 및 품질을 봐주는 케이스 처럼입니다. 

그리고 잘하기 위해서 노력해야 한다고도 생각합니다.  QA로써 Web 자동화를 한다면 최소한의 Browser 가 어떻게 Syntax Tree를 그리고 DOM 에 Element를 붙인후에 CSS를 입혀서 스타일링되고 현재시대에 와서 MPA가 아닌 SPA에서의 웹 자동화 테스트를 위해서 어떤식으로 돌아가는지는 알고 완벽하진 않지만 완벽함을 추구하는 테스트 자동화를 구성해야 한다고 생각 합니다.

앱도 마찬가지입니다. 최소한 IOS / APP 의 View Life Cycle은 알고 있어야 한다고 생각 합니다. 

테스트 자동화 케이스는 만드는거 자체는 어렵지 않습니다. 어떻게 보면 쉽다고도 할수 있습니다. UI Automation 어디에서 검색해도 관련 튜토리얼은 너무나 많고 동작 하나하나에 대한 API 도 매우 간단하고 설명도 잘되어있습니다. 

여기서 어려운거는 신뢰도 있는 케이스를 만들어 내는 것이라고 생각 합니다.  지금 실패가 정말 제품에 대한 오류인가에 대한 것에 대해서 

그래서 개인적으로는 많이 실행해본 사람이 더 잘할 거라고 생각합니다. Exception 처리에 대한 경험이 곧 실력이 될수도 있다고도 생각합니다.

포스팅을 통해서 실행이라도 많이 하여야 현재 필요한 시점에 자유롭게 쓸수 있을거 같아서 작성을 준비합니다.

- 임시 포스팅 입니다. ㅜ

안녕하세요 깍돌이입니다.  테스트 자동화 플랫폼 개발기에서 Detail VIEW와 Image VIEW에 대한 기본 구현이 되었는데요  (아직 포스팅안됨) 해당의 Image VIEW의 경우 이미지를 통해서 하다보니까 프레임이 낮고 그러다보니 아쉬운점이 이만 저만이 아닙니다. 그렇기 때문에 해당 자동화 테스트 화면을 실시간으로 스트리밍을 하는게 궁극적인 목표인데요

그렇기 위해서는 아래의 작업들이 필요합니다. 

OBS ( Open Broadcaster Software ) 

방송과 녹화를 할수있는 오픈소스 프로그램으로 해당을 통해서 화면 캡처를 하게 됩니다.

RTMP Server

OBS으로 캡처된 화면을 RTMP Server로 보내게 되며 해당 화면들을 받아서 처리합니다.

ffmpeg && HLS 인코딩

RTMP Server로 받아온 캡처 내용들을 ffmpeg을 통해서 hls로 인코딩합니다.

저장소 저장

저장된 HLS 파일을 특정 저장소에 저장합니다.( S3, Object Storage ) 

hls url 배포

저장소에 저장된 경우 해당 URL이 있기 때문에 배포가 완료 될 경우 hls url을 배포합니다. 그리고 Client FE에서 배포가 된점을 알수 있게 합니다.

FE Client HLS Player 재생 

FE Client에서는 해당 배포 내용을 받고 스트리밍을 시작합니다.

( 작업 내용 추후 포스팅 ) 

임시 포스팅

Mysql 에서 시간 저장을 위해서 datetime 으로 저장하게 되는데

해당의 경우 DB로부터 데이터를 받아 그대로 렌더링시

이와같이 나타나게 해주기 때문에 이를 위해 여러가지 구글링시

첫번째 dbconfig의 dateStrings를  'date' 로 설정합니다.  

안녕하세요 깍돌이입니당~ 

저희집 가훈 중 하나가 시간은 만드는 것이다 라는게 있는데 그래서 어머니께서는 시간이 없다라는 말을 별로 안좋아하십니다.

그럼에도 불구하고 ㅜㅠ 정말 시간이 없네요  막 엄청 부지런한 성격이 아닌가봐요... 해야될게 많지만 하고싶은것도 많아서

자꾸 뒤로 미뤄지게 되네요 그러다보니 평소에 작업하던 내용들을 포스팅 하는것도 있지만 중간중간 생각들을 정리 하려고 합니다.   자동화관련된 이야기를 많이 하게 될거 같습니다. 또한 관련에서 경험에 기반된 케이스가 많기 때문에 양해 부탁드립니다.   첫회사는 QA만 120명이 넘는 회사였고 현재는 작지만 많아지고 있는 상태 입니다.

첫번째로 하고 싶은 말은 Expected Result에 속지 마라입니다.

아마 QA에서 자동화을 하게 되는 상황이나 지켜보는 상황들이 존재 합니다. 저 연차 QA 일때 코드 조금 짤줄 알았던 ( 우물안 개구리였죠 ) 저는 맡은 제품에 API 들을 자동화하면 대충 5500건이 넘어가는데 (당시에 1인 QA) 코드 단으로 하는건 그냥 코드단에서 자동화 하면 쉽지 않을까? 하고 타자가 빠른 저는 며칠 걸리지않아 해당 API 를 자동화 했습니다.

API의 몸통이 되는 코드가 제품 안에 이름이 있었고 파라미터는 공용되는것들이 많아 공통 파라미터로 받는 Result가 같은 포맷이였기에 

let apiFncName = getGrepAPINameList();
// 공통 파라미터 설정
let commonparam = ''
apiFncName.reduce((prev,curr,index,item))=>{
      // 함수 이름 꺼내서 
      // 실행 ( 공통 파라미터  ) 
      // 결과 이상없을 경우
      
      // test_result.push(curr.name, result, test_result);
},0);

와 같은 형태로 동작이 가능한 구조였기 때문에 적은 코드로 많은 다량의 API 들을 호출할수 있었고 ( JS가 1급 함수여서 가능했던 작업 같습니다. - C였다면 함수 포인터까지 가야되지만 그러면 머리가 많이 아팠을 듯 )

여기서 핵심은 짧은 기간내에 5500개의 API 자동화를 한게 아닙니다.  QA로 일한다면 "테스트" 의 목적을 두면 안됩니다. 필요없는 단순 Test Case 100건 보다 평소에 많은 생각과 구조에 대한 연구가 된 하나의 Test Case 가 제품 릴리즈 시에는 빛을 발하게 된다고 생각합니다. 

위의 5500개의 자동화 케이스를 만들고 돌릴 경우 99% 는 Stdout에서 pass로 발생합니다. 1%의 에러도 내가 생각하지 못하였던 예외처리 였습니다.

그럼 거의 API 들을 많이 커버했을까? 그렇지 않습니다. 단순 API 에 대한 커버는 이루어졌지만 해당 자동화 케이스는 위에 말했던 100개의 단순 케이스일 뿐입니다. 그렇기 때문에 추후 발생하는 API 이슈들을 많이 잡아내지 못했습니다. 개인적으로 UI 포함 7천개의 케이스를 돌리고 있던 나는 다시한번 돌아보는 계기가 되었으며 철 없던 저 연차의 시간이 그렇게 지나갔습니다. 그리고 자동화 테스트의 결과는 Expected Result 가 pass 와 fail의 결과를 만들게 되는데 expected Result 또한 담당하는 QA가 작성하게 됩니다.  이로 인해서 너무나 주관적인 견해가 들어가게 됩니다. 그러면서 많은 부류들도 같이 발생합니다.

1. 처음에 생각 했던 대로 진행 ( 쉬운 케이스 부터 얼른 얼른 전체 틀 구조 ) 

자동화 케이스는 기본적인거부터 하는 경우가 많기 때문에 정말 호출 및 결과만 보는 케이스를 작성하고 회사에 보고시

회사에서는 더많은 케이스를 돌리는걸 보고싶어하여 고도화 할시간은 갖지 못하고 계속 저 위에 케이스를 넣게 됩니다. 이 경우는 언젠간 터질지 모르는 시한 폭탄이라고 생각합니다. 오류는 잡지 못하는 자동화 가 되는 수순을 밟게 됩니다.

 2. 어려운거 부터 하는 케이스

복잡한 케이스를 놓치는 경우가 많아서 복잡한 케이스를 우선적으로 하고 그다음에 전체 구조를 고도화 하자라는 목표로 작성시 어찌 보면 Test Case 1건 1건은 공을 들였기에 오류를 잡아 낼수있는 케이스가 될수 있습니다. 하지만 이 경우도 문제가 되는 케이스가 있습니다. 너무 TC에 공들인 나머지 자동화 의 구조를 생각 하지 못하였던 경우입니다. 위에 보고할때 그래도 좀 있어 보이게 해야되는데  공들인 TC가 남아있는데  이걸 아무리 말해도 다른 분들이 이거를 알아주는 경우는 많이 못 보았던거 같습니다.

1,2번 모두 아주 지극히 많은 케이스 중 몇개일 뿐입니다.  시작하려다가 안하는 케이스도있을 거고 tool 선정 하다보니 안되는 케이스도 있을거고 처음부터 내가 간단하게 개발을 해서 하겠다는 케이스등 여러 케이스가 있지만 공통되는 경우는 테스트의 결과에 대한 pass fail은 작성한 QA 의 expected result 입니다.

createServerAPI 

서버를 생성하는 API 입니다. 해당 API 는 생성할때 필요한 생성 값( 파라미터 ) 를 받아서 서버 생성 요청을 넣고 ( VDI ) 방금 request를 보낸 client에게는 바로 서버의 Info( 정보 ) 를 Response로 던집니다.

API 를 자동화를 하려고 할때 Expected Result를 이렇게 하는 경우도 있습니다. 해당 API 주소로 HTTP Method를 request를 보낸후에 response를 받고 Pass 로 표시할수 있습니다.

이경우는 반쪽짜리 케이스라고 볼수 있습니다. createServerAPI는 FE와 BE간의 요청을 전달하는 역할을 하고 "실제 생성"은 VDI를 통해서 이루어지기 때문입니다. Unit Test 를 하는게 아니기 때문에 QA입장에서는 사용자가 쓸수 있는가 정도 까지 생각을 해봐야 합니다.  API 를 테스트하는 것이 아닌 API 의 품질보는 방향에서는 Expected Result가 확연하게 달라질 필요가 있습니다.

1. API Requeset ( 생성 파라미터 ) 

2. API Response 확인 

3. API Request ( 서버 리스트 혹은 상태를 가져오는 API 확인 ) 

4. 생성이 되지않았을 경우 Polling 하여 확인 

5. 생성이 되었다면 Pass로 종료 생성이 되지않았다면 QA가 지정한 Condition Timeout까지 Polling 해당 시간초과시 내부적으로 해당 오류와 함께 오류 리포트

업무를 하다보면 API 테스트에 대해서 간단하게 생각 하시는 사람들이 있습니다. 직군과 사람들 간의 차이로 인해 발생하는 것으로 "테스트"의 관점을 두고 생각 하냐 "품질"의 관점을 두고 생각 하냐에 따른 차이인거 같습니다.

테스트의 관점을 둔다면 API 자동화 테스트는 소위 말하는 "노다지" 입니다.  작성하기도 쉽고 그걸 보여주기도 쉽고 테스트 시간도 적절하고 하지만 품질 관점에서의 API 자동화 테스트를 추가로 한다면 (본업이 있기에) 기존 Test Case를 가지고 Test Plan 을 짜듯이 사용자 입장에서 정상이라고 느껴지는 지점과 그에 대한 Expected Result에 대해 많이 고민해야 합니다.

내가 아닌 누군가가 자동화를 했다고 할 경우 리뷰를 해야하는 경우가있다면 잘돌아가나만 보는게 아니라 Expected Result를 무엇으로 기준을 했냐가 중요합니다.  현재 상황에 따라서 위와같이 못한다고 해도 중요하다고 하는 부분의 경우 Expected Result를 다시 한번 다듬어 볼 필요는 있는거 같습니다.

이부분에 대해서 기술 포스팅은 추후에 꼭 하도록 하겠습니다.

감사합니다.

허니포레스트
산속 밭들 사이에 있기때문에 밤에 갈 경우 도착직전까지 잘못왔나 착각 할 수 있음
커피 맛은 괜찮

밖에 뷰