iOS와 Android 간 UI 자동화 속도 차이 해결하기 (부제 : ActionChains로 iOS 테스트 자동화 속도에 로켓 달아주기)안녕하세요. 29CM QA Engineer 정다정입니다. 29CM QA팀에서는 업무의 효율성을 위해 앱 UI 자동화를 진행하고 있습니다.동일한 시나리오로 작성한 자동화 스크립트를 실행했을 때, iOS가 Android에 비해 최대 2배 정도 느린 실행 속도를 보이고 있습니다. 이는 QA팀이 세운 자동화 원칙을 지키지 못할 수 있다고 판단되어 원인을 파악하고 개선하기 위한 노력을 기울이고 있습니다.문제를 해결을 위해 시도한 방법과 해결한 방법에 대해 소개하고자 합니다.29CM QA팀의 자동화 원칙BVT(Build Verification Test : 빌드 검증 테스트)의 기본 원칙 중에 ‘BVT 수행 시간은 30분을 넘기지 않는다.’가 있습니다.https://testgrid.io/blog/build-verification-testing/QA팀에서는 매뉴얼이 아닌 자동화 테스트로 ‘BVT 수행 시간은 최대 20분을 넘기지 않는다.’라는 기본 원칙보다 더 높은 수준의 원칙을 세웠습니다.QA팀에서는 이 원칙을 지키기 위해 시간 분배에 대해 고민했고 iOS 기기 2대로 병렬 테스트를 진행하고 있었습니다. 하지만, 전체 케이스의 스크립트 완성 후 iOS 자동화는 평균적으로 최대 19분대가 소요되었고, 추가 작업이 진행될 경우 팀에서 세워둔 원칙이 깨질 수 있어 iOS 기기를 3개로 늘리는 방안을 고려해야 하는 상황이었습니다.이를 해결하기 위해 iOS 자동화 실행 시간을 감소시킬 방안이 꼭 필요했고, 원인을 분석하고 최적화를 시도해 보았습니다.iOS의 속도가 더 느린 이유는 무엇일까요?테스트를 진행하며 iOS의 실행 속도를 늦추는 원인으로 파악된 사항은 크게 3가지가 있습니다.element를 click 한 후 다음 화면까지 넘어가는데 걸리는 시간자동 롤링되는 영역이 존재해 element를 찾는데 걸리는 추가 시간webview에서 native로 전환 후, 다음 element를 찾는데까지 걸리는 시간위 3가지의 상황에서 발생하는 추가적인 시간에 의해 불필요한 대기 시간이 소요되고 있었습니다.파악한 원인 중 테스트 시에 가장 많이 사용되는 동작인 ‘click’ 동작의 시간을 최적화한다면, 자동화 실행 시간을 효과적으로 감소시킬 수 있다고 생각하였고, 바로 원인 파악을 시작했습니다.원인 파악click 동작을 확인한 결과, element를 찾는 시간은 약 1초 소요되었지만, 실제 click 후 다음 화면이 나타나는 데 약 20초 정도의 시간이 소요되는 것을 확인했습니다. 더 자세한 분석에서는 element를 찾아 클릭하는데는 약 3초 정도의 시간이 걸리지만, 다음 화면이 표시되기까지 추가적으로 17초가 소요되었습니다.element = wd.find_element(AppiumBy.ACCEBILITY_ID, 'test')element_click = wd.find_element(AppiumBy.ACCEBILITY_ID, 'test'

1. 목표내가 원하는 이미지를 웹사이트 검색을 통해 수집합니다.2. 사용 도구 : Selenium3. Selenium 사용 준비Python crawling package인 Selenium을 사용하기 위해서는 두가지가 필요합니다.Selenium에서 사용할 browser에 대한 드라이버 저는 Selenium 내에서 크롬을 사용할 것이기 때문에 chrome driver를 다운받습니다 그리고 나서 Selenium package가 있는 python 경로로 옮겨줍니다. Geckodriver를 다운받습니다. 저는 Selenium 내에서 크롬을 사용할 것이기 때문에 chrome driver를 다운받습니다4. 원하는 이미지 URL selector 획득저는 구글에서 이미지 검색 했을 때 바로 나오는 이미지가 아닌 원본 이미지를 가져오고 싶기 때문에 검색했을 때 나오는 이미지와 클릭후 나오는 원본 이미지에 대한 css selector 또는 Xpath경로가 필요합니다.이 두가지를 활용하여 해당 Property의 태그 정보를 가져올 수 있기 때문입니다.정보를 가져오기 위해서 저는 크롬 개발자도구에서 element select하는 방법을 활용했습니다. (참고링크)검색하고 나오는 이미지들에 대한 css selector검색 후 나오는 이미지 배열은 공통적으로 class=”rg_i”라는 프로퍼티를 동시에 가집니다.클릭했을 때 나오는 원본 이미지의 XPath클릭 후 이미지의 Xpath는 //*[@id="Sva75c"]/div[2]/div/div[2]/div[2]/div[2]/c-wiz/div[2]/div[1]/div[1]/div[2]/div/a/img 입니다 저는 구글에서 이미지 검색 했을 때 바로 나오는 이미지가 아닌 원본 이미지를 가져오고 싶기 때문에 검색했을 때 나오는 이미지와 클릭후 나오는 원본 이미지에 대한 css selector 또는 Xpath경로가 필요합니다. 이 두가지를 활용하여 해당 Property의 태그 정보를 가져올 수 있기 때문입니다.5. Crawling code 작성위에서 얻은 property 정보를 활용하여 Crawling을 code를 작성합니다.모듈 임포트import requestsfrom selenium import webdriverfrom bs4 import BeautifulSoupfrom selenium.webdriver.common.by import Byimport timeimport json크롬 옵션chrome_options = webdriver.ChromeOptions()chrome_options.binary = '/Users/chemseok/miniforge/envs/epicone/bin/chromedriver'검색할 쿼리query = '루피'구글 드라이버에 루피 검색driver = webdriver.Chrome()driver.get(f'https://www.google.com/imghp')Search my querysearch_bar = driver.find_element(By.NAME,"q")search_bar.send_key

안녕하세요. QA 엔지니어 이승훈입니다. 원티드랩은 채용&커리어 서비스인 원티드 외에도, HR 관리 서비스 원티드스페이스, 프리랜서 전문 매니징 서비스 긱스, 기업정보 제공 서비스인 크레딧잡 등도 운영하고 있습니다. 오늘은 크레딧잡 사이트의 DB를 포함한 백앤드 서비스를 대대적으로 리뉴얼하는 프로젝트를 QA하면서 만들었던 에러 크롤링 스크립트에 대한 글을 적어보려 합니다. 왜 크롤링을 고려하게 됐는가? 크레딧잡은 오랜 기간 눈에 띄는 기능 개선이 없었던 터라, QA 검증 대상 범위 밖에 있었습니다. 그래서 기존 기능에 대한 기능 파악도 안돼있고, 참고할 만한 문서나 테스트 산출물도 없는 상황이었습니다. 이런 상황에서 사이트를 전수 조사하는데 일정 부분 도움을 받을 수 있는 도구가 필요했고, 차후 진행될 사이트 개선에도 이를 지속적으로 활용할 수 있을 것이라 생각했습니다. 목표 사이트의 대표 주소를 입력하면 크롤링 스크립트가 사이트 내 하위 페이지와 연결된 페이지를 돌며 발생하는 스크립트, 네트워크 에러를 자동적으로 검출한다. PYTHON + REQUESTS, SELENIUM python에서는 requests 라이브러리를 이용하여 http 리퀘스트의 응답값을 확인할 수 있습니다. 하지만 이는 서버에서 제공하는 코드만 받아오기 때문에 브라우저에 의해 최종적으로 랜더링된 페이지의 소스 코드와는 상당한 차이가 있을 수 있습니다. (javascript에 의해 랜더링되는 부분이 누락 됨) 반면, selenium 라이브러리를 이용할 경우 실제로 브라우저를 띄우기 때문에 누락없이 모든 응답 소스 코드를 가져올 수 있습니다. (주의, 브라우저에 옵션을 걸어 headless로 구동할 경우에도, 최종 렌더링된 소스 코드가 다를 수 있음) https://medium.com/media/d0f571b20f2235a417d8dd71897c3f49/href 대략적인 전체 스크립트 구조 (초안) SELENIUM 웹드라이버 객체에서 콘솔에러 읽어오기 Selenium 웹드라이버 객체의 get_log(browser) 메소드를 이용하여 콘솔에 찍히는 에러들을 확인할 수 있습니다. 로그 중 SEVERE 수준의 에러가 있을 경우 로그 정보를 캡쳐하고 fail로 간주합니다. 결과는 json 형태로 OK, NOK라는 key에 분리하여 담습니다. https://medium.com/media/be69ac13ada7fc869f18db654ea67212/href 에러가 있는 페이지들을 리스트에 넣고 돌려봤을 때 에러가 잘 기록이 됩니다. 그러나 브라우저에 의해 해석된 메세지다 보니 구체적이지만 직관적이지 않은 경우가 있습니다. 주요 테스트 항목이 API 변경이다 보니, 네트워크 에러 같은 경우 [Response Status Code], [Content Type], [Request URL] 의 정보만 간결하게 직관적으로 결과를 확인하고자 하였습니다. 하지만, Selenium에서는 리퀘스트/응답의 구체적인 정보를 확인할 수 있는 기능이 제공되지 않습니다. SELENIUMWIRE = SELEN