안녕하세요 깍돌이 입니다.

 

기존에 준비하였던 내용중 일단 여기까지 하고 배포 릴리즈가 있기 때문에 .. 주말에 작업을 (또르르) 하고 다시 이어서 할 예정입니다.

 

품질은 제품이 잘 나가야 하는게 1순위니까요 이번 LNB Menu 선택 이후에 할 예정된 포스팅은 

  • Selenium-Webdriver 에서 Puppeteer 로 작업중인 이유 (Puppeteer  선택의 이유 )
  • 요즘 새로 핫한 playwright 에 대해 ( 퍼펫티어 팀이 나가서 MS에서 개발 중 ) 
  • MPA, SPA 페이지에 대한 waitForNavigationAPI , isIntersectingViewport API  사용 
  • 현재 진행 중 인 Console 자동화에서 Server 생성 (waitForNavigation API 먼저 포스팅 예정)
  • Server List에서 서버 상태 체크 

등등이 있고 이제까지 업무하면서 개인적으로 공부 했던 부분들을 모두 포스팅으로 남겨 놓도록 하겠습니다.

 

LNB Menu 선택을 위한 함수 제작 입니다.

뭔가 앞에 로그인기능, 콘솔 이동, 파라미터 유효성 등 저렇게까지 해야하나 싶을정도의 예외 처리 등이 들어가게 되는데 이유는  공통적으로 사용되는 기능이라면 모듈화가 필수기 때문입니다. 

 

3개의 Test Case 가 아래처럼 되어있다고 생각해보겠습니다.

 

각각의 로그인을 따로 구현, 콘솔이동도 따로 구현, 메뉴선택도 따로 구현 하였습니다.

이렇게 구현할 경우면 앞선 포스팅처럼 까다롭게 할필요도 없습니다. 단순히 그냥 지금 현상태로 로그인 Element가져와서 바로 입력하고 실행하게 하면 되는 것이지요  그럼 예외처리도 필요없고 파라미터도 필요 없고 하지만 대부분의 케이스들의 UI를 하기 위해선 콘솔로 이동을 하여야 하기 때문에 중복되는 케이스들이 발생합니다. 

 

그래도 사용성에 문제가 없어서 잘 쓰고 있었다면 ?  네 이상이 없으면 상관이없을 수 있습니다. 

하지만 이렇게 진행하다가 Automation Test Case가 100건까지 늘어났습니다. (이때까지 아무 이슈가 없다고 했을 경우)

그러는 와중에 개발팀에서 메뉴 Item의 class를 바꿨습니다.  그럼해야할 작업은

 

"모든 케이스의 직접 .class를 다시 맞춰서 찾아 주는 작업을 해줘야 합니다.  콘솔이동시에 URL체크로 하고있는데 이경우도 마찬가지입니다. 이동하는 URL의 변경 될경우 모두 바꿔 주어야 합니다.  그렇기 때문에 공통되는 작업들에 대해서는 일단 혼자 작업한다고 해도 모듈화를 우선적으로 하는게 건강에 좋기 때문에 위와같이 작성 되고있습니다.

그리고 모듈화에 앞서 UI Automation 에 서 보면 아래와 같은 질문들이 올라오는 경우가 있습니다.

 

"UI Automation 을 하면 개발자들의 자꾸 바꾸는 바람에 테스트가 오류가 납니다."

 

라는 이야기를 많이 듣기도했고 해보다 보니 그런거 같기도 하고 그래서 UI 는 답이없네 라고 할수도 있습니다.

하지만 실제로 경험을 해봤을 경우 웹사이트의 경우 그렇게 크게 바뀌지 않습니다. (대개편이 일어나지않는 이상)

특히 B2B 의 제품을 QA하고 계시다면 더더욱 그럴일은 더 적어지게 됩니다.  

 

"그럼 QA분들이 말하는 게 다 허상이냐" 그건 또 아닙니다. 제가 느꼈던 짤막한 경험으로는 xpath 의 사용 혹은 고정 CSS Selector의 사용이였습니다. ( Element 선택에 대한 기본기가 부족하다고 할수 있습니다. )

 

예를 들면 요소 > 요소 > 요소  에서 최초에 3번째의 요소만 무조건 찾는 형태로 구성되어 있는 상태에서 

개발자들의  hidden Element를 추가하게 될시 ( Tooltip 등을 Custom 으로 제작시등 많이 사용 합니다. - Z-index를 통한 툴팁 박스 ) 

요소 > 요소 > 히든 > 요소 의 구조가 가 되기때문에 기존에 지정해놓은 경로인 세번째 요소로는 찾아지지가 않는 것뿐입니다. xpath 가 나쁘다는 건 아니지만 CSS Selector를 유연하게 작업할수 있다면 그리고 공통적으로 써야하는 모듈을 제작하면서 예외처리를 하나씩 추가하게되면 화면을 통쨰로 갈아 엎지 않는 이상 자주 변경할 일은 발생하지않습니다.

 

그래서 결론적으로는 해당 공통케이스에 대한 모듈화 + CSS Selector를 위한 정확한 Element 선택 을 LNB Menu 에서 사용하고자 합니다.   같이 사용하게된다면 메뉴는 가장많이 사용되는 기능일수 있습니다.

 

 

 

 

 

 

우선 사용 호출 부 입니다.

navigateLNBMenu 호출시 

해당 서버 밑의 서버 메뉴를 선택해야 하기 때문에 Server, Server를 파라미터로 받습니다. 만약에 3depth 까지 있을수 있기에 파라미터는 배열형태로 받게 되었습니다.

 

["Server","Storage"]  라면 Server를 열고 Storage를 선택하게 합니다.

 

지금은 완성이 아니지만 추가작업으로 Server가 ( 1depth ) Open 되어있는상태에서 Server, Snapshot이 들어오게된다면

1depth의 Server가 Expand 상태라면 바로 Snapshot을 선택할 수 있어야합니다.

 

 

 

 

다른 파라미터로는 testplatform 과 environment를 받게 됩니다.  NCP의 콘솔의 경우 Classic 과 VPC를 선택할수 있기 때문이고 environment 는 환경 로깅 용 입니다.

보시면 해당 페이지의 개발자의 경우 모든 첫번째 메뉴들은 a태그와 id값을 사용 하였습니다.

따로 요청 하지않은 경우에 위와같이 id값을 직접 쓰게 되면 매우 좋은 케이스로 자체적으로도 유니크한 값을 쓰고있다고 보시고 #을 이용하여서 가져옵니다.

 

#인 경우는 따로처리할 필요가 없습니다. 다만유의해야 할 점이 있다면 li나 a 태그가 아니라 그 하단에 span 태그를 선택하는점  '#Server > span' 으로 클릭해주면 자연스럽게 열리게 됩니다. 

 

DNS 메뉴를 선택하려고 해도 

 

같은 방식으로 되어있기 때문에 첫번째 메뉴 선택까진 큰 무리가 없습니다.

 

두번째 서브 메뉴를 선택하려고 하면  메뉴상태에 따라서 여러가지 선택이 될수 있는 데 금일은 .active상태인걸 확인하고 (바로 1depth 의 메뉴가 열렸다는 가정) 선택을 할수 있도록 합니다. 

 

지금 작성을 하려고 보니 예외처리나 여러가지 기능들이 잘 안되어있네요.  간단하게 설명드리자면

 

위의 케이스는 active된 케이스 ( Server ) 에 첫번째 Element를 가져와서 선택하게 되어있네요 (이부분은 수정해서 해당 포스팅에 그대로 작성하겠습니다.)

 

상태별 케이스를 추후 추가!

 

 

 

 

 

 

 

 

+ Recent posts