<div id="readability-page-1" class="page"><div><div><a rel="noopener follow" href="/@dajjeong?source=post_page-----0ee1ff90208a--------------------------------"><div aria-hidden="false"><p><img alt="정다정" src="https://miro.medium.com/v2/resize:fill:88:88/1*18FWDThmVpY7CQUq_I9nBA.jpeg" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a><a href="https://medium.com/29cm?source=post_page-----0ee1ff90208a--------------------------------" rel="noopener follow"><div aria-hidden="false"><p><img alt="29CM TEAM" src="https://miro.medium.com/v2/resize:fill:48:48/1*TP1aY6ZJaPSPs3fKA6sYKA.png" width="24" height="24" loading="lazy" data-testid="publicationPhoto"></p></div></a></div><p id="b757">안녕하세요. 29CM QA Engineer <a href="https://www.linkedin.com/in/%EB%8B%A4%EC%A0%95-%EC%A0%95-b32560225/" rel="noopener ugc nofollow" target="_blank">정다정</a>입니다. <br>29CM QA팀에서는 업무의 효율성을 위해 앱 UI 자동화를 진행하고 있습니다.</p><p id="09ab">동일한 시나리오로 작성한 자동화 스크립트를 실행했을 때, iOS가 Android에 비해 최대 2배 정도 느린 실행 속도를 보이고 있습니다. 이는 QA팀이 세운 자동화 원칙을 지키지 못할 수 있다고 판단되어 원인을 파악하고 개선하기 위한 노력을 기울이고 있습니다.</p><p id="1713">문제를 해결을 위해 시도한 방법과 해결한 방법에 대해 소개하고자 합니다.</p><h2 id="a8ab">29CM QA팀의 자동화 원칙</h2><p id="bfe1">BVT(Build Verification Test : 빌드 검증 테스트)의 기본 원칙 중에 ‘BVT 수행 시간은 30분을 넘기지 않는다.’가 있습니다.</p><figure><figcaption><a href="https://testgrid.io/blog/build-verification-testing/" rel="noopener ugc nofollow" target="_blank">https://testgrid.io/blog/build-verification-testing/</a></figcaption></figure><p id="11d6">QA팀에서는 매뉴얼이 아닌 자동화 테스트로 ‘BVT 수행 시간은 최대 20분을 넘기지 않는다.’라는 기본 원칙보다 더 높은 수준의 원칙을 세웠습니다.</p><p id="70e1">QA팀에서는 이 원칙을 지키기 위해 시간 분배에 대해 고민했고 iOS 기기 2대로 병렬 테스트를 진행하고 있었습니다. 하지만, 전체 케이스의 스크립트 완성 후 iOS 자동화는 평균적으로 최대 19분대가 소요되었고, 추가 작업이 진행될 경우 팀에서 세워둔 원칙이 깨질 수 있어 iOS 기기를 3개로 늘리는 방안을 고려해야 하는 상황이었습니다.</p><p id="9b6f">이를 해결하기 위해 iOS 자동화 실행 시간을 감소시킬 방안이 꼭 필요했고, 원인을 분석하고 최적화를 시도해 보았습니다.</p><h2 id="9d1b">iOS의 속도가 더 느린 이유는 무엇일까요?</h2><p id="0a77">테스트를 진행하며 iOS의 실행 속도를 늦추는 원인으로 파악된 사항은 크게 3가지가 있습니다.</p><ol><li id="57b0">element를 click 한 후 다음 화면까지 넘어가는데 걸리는 시간</li><li id="7903">자동 롤링되는 영역이 존재해 element를 찾는데 걸리는 추가 시간</li><li id="c82a">webview에서 native로 전환 후, 다음 element를 찾는데까지 걸리는 시간</li></ol><p id="9753">위 3가지의 상황에서 발생하는 추가적인 시간에 의해 불필요한 대기 시간이 소요되고 있었습니다.</p><p id="f758">파악한 원인 중 테스트 시에 가장 많이 사용되는 동작인 ‘click’ 동작의 시간을 최적화한다면, 자동화 실행 시간을 효과적으로 감소시킬 수 있다고 생각하였고, 바로 원인 파악을 시작했습니다.</p><h2 id="8d49">원인 파악</h2><p id="f8c0">click 동작을 확인한 결과, element를 찾는 시간은 약 1초 소요되었지만, 실제 click 후 다음 화면이 나타나는 데 약 20초 정도의 시간이 소요되는 것을 확인했습니다. 더 자세한 분석에서는 element를 찾아 클릭하는데는 약 3초 정도의 시간이 걸리지만, 다음 화면이 표시되기까지 추가적으로 17초가 소요되었습니다.</p><pre><span id="1ea1">element = wd.find_element(AppiumBy.ACCEBILITY_ID, 'test')<br>element_click = wd.find_element(AppiumBy.ACCEBILITY_ID, 'test').click()</span></pre><figure></figure><p id="f11a">이러한 현상을 고려하여, WebElement의 click 메소드에 딜레이가 있는 것으로 판단하였고, 다른 기능을 활용하여 최적화하는 실험을 진행하였습니다.</p><h2 id="dde9">최적화 실험</h2><p id="d0e5">ActionChains 사용하여 최적화를 시도해보았습니다. (TouchAction을 사용할 수 있지만, 최신 버전에서는 권장하지 않는 기능으로 ActionChains를 선택했습니다.)</p><p id="842a">ActionChains가 WebElement에서 제공하는 메소드보다 element를 선택하고 동작하는 데 있어 좀 더 세밀하게 제어가 가능하기에 불필요한 동작이 없어 속도 향상에 적합할 것이라는 기대가 있었습니다.</p><p id="fac1">WebElement의 click 메소드를 ActionChain의 click 메소드로 변경하여 테스트 시, element를 클릭하는 속도가 향상된 것을 확인했습니다.</p><pre><span id="93fd">action = ActionChains(wd)<br>action.move_to_element(element).click().pause(0.1).perform()</span></pre><figure></figure><p id="0c83">하지만, 위 코드를 사용했을 때의 문제점이 있었습니다. 바로 Webview 화면에서는 해당 코드가 동작하지 않는다는 것이었습니다.</p><p id="eece">새로운 기능을 찾아 추가 테스트를 진행해야 하나 고민을 했었으나, Webview 화면에서는 기존의 WebElement를 사용하여 click 하더라도 속도가 저하되지 않았습니다. 그래서, 현재 위치한 화면의 context를 확인해서 Native 화면에서는 최적화한 코드를 Webview 화면에서는 기존의 코드를 사용하도록 수정하여 테스트를 진행했습니다.</p><pre><span id="2b5a">if 'NATIVE' in wd.current_context:<br>    ActionChains(wd).move_to_element(element).click().pause(0.1).perform()<br>else:<br>    element.click()</span></pre><figure><figcaption>webview에서는 기존 코드도 매우 빠름</figcaption></figure><p id="3305">각 화면에서 element click 속도가 향상된 것을 확인하고 QA팀에서 진행하는 자동화 테스트의 모든 스크립트에 적용을 해보았습니다.</p><p id="e0a1">그 결과, 아래 스크린샷에서 보이는 것처럼 자동화 수행 시간이 최대 절반으로 감소된 것을 확인할 수 있었습니다.</p><figure></figure><h2 id="1e27">왜 ActionChains가 더 빠를까?</h2><p id="f346">WebElement와 ActionChains의 click 메소드를 확인해보니 두 기능 간의 차이와 속도 향상의 원인을 추측해 볼 수 있었습니다.</p><figure><figcaption>WebElement vs ActionChains</figcaption></figure><p id="7e6f">WebElement는 Selenium 3의 JSON Wire Protocol을 사용하여 통신하고, ActionChains에서는 Selenium 4의 W3C Webdriver Protocol을 사용하고 있습니다.</p><p id="2a50">각각 다른 Selenium 버전을 사용하여 동작을 하고 있는데, 두 버전 간의 차이점을 확인해보았습니다.</p><figure><figcaption>Selenium Architecture 3 vs 4</figcaption></figure><figure><figcaption><a href="https://www.selenium.dev/documentation/legacy/json_wire_protocol/" rel="noopener ugc nofollow" target="_blank">https://www.selenium.dev/documentation/legacy/json_wire_protocol/</a></figcaption></figure><p id="7573">Selenium 3에서 Selenium 4로 업데이트되며 가장 큰 변경사항은 JSON Wire Protocol을 W3C Webdriver Protocol로 대체하게 되었다는 것입니다.</p><p id="1858">Selenium 3에서는 클라이언트(Python)과 서버(Browser Driver) 간의 직접적인 통신이 없고, JSON Wire Protocol을 사용하여 클라이언트와 서버 간의 데이터를 전송하고 있었습니다. 이로 인해 (1) 통신의 단계 추가로 비효율적 (2) 표준화 불충분으로 브라우저 간의 일관성과 호환성이 부족하여 자동화 수행 속도에 부정적인 영향을 끼쳤습니다.</p><p id="15d2">Selenium 4에서는 JSON Wire Protocol을 제거하며 클라이언트와 서버 간의 직접 통신이 가능해졌습니다. W3C WebDriver Protocol을 사용하며 (1) 통신의 단계 1단계 축소 (2) W3C에서 표준으로 제정한 프로토콜을 사용하며 표준화된 형식으로 브라우저 간의 일관성과 호환성 향상되었습니다.</p><p id="a5eb">이로 인해 Selenium 3 코드 대신 Selnium 4의 코드를 사용함으로써 자동화 실행 속도가 빨라졌다는 결과에 이르렀습니다.</p><h2 id="7855">마치며</h2><p id="830f">최적화 실험을 통해 실행 속도를 거의 2배 가까이 향상시킬 수 있을 것이라는 생각을 하지 못한 것은 아쉬운 부분이었습니다. 기존에 사용하던 WebElement 메소드들이 잘 작동하고 있었고, iOS가 Android보다 속도가 느리다는 편견으로 속도 차이를 해석했던 것이 원인으로 보입니다.</p><p id="10ec">속도 향상의 필요성을 깨닫고 시도하기까지의 시간이 길게 소요된 점은 아쉽습니다. 하지만, 앞으로는 “원래 그런 거야”라는 생각을 최대한 배제하고, 지금의 경험을 바탕으로 효율적인 테스트 및 자동화 방법에 대해 지속적으로 고민하는 QA가 되기로 다짐하며 글을 마치겠습니다. 감사합니다.</p></div></div>

29CM 기술블로그 - Medium

iOS와 Android 간 UI 자동화 속도 차이 해결하기 (부제 : ActionChains로 iOS 테스트 자동화 속도에 로켓 달아주기)
안녕하세요. 29CM QA Engineer 정다정입니다. 
29CM QA팀에서는 업무의 효율성을 위해 앱 UI 자동화를 진행하고 있습니다.
동일한 시나리오로 작성한 자동화 스크립트를 실행했을 때, iOS가 Android에 비해 최대 2배 정도 느린 실행 속도를 보이고 있습니다. 이는 QA팀이 세운 자동화 원칙을 지키지 못할 수 있다고 판단되어 원인을 파악하고 개선하기 위한 노력을 기울이고 있습니다.
문제를 해결을 위해 시도한 방법과 해결한 방법에 대해 소개하고자 합니다.
29CM QA팀의 자동화 원칙
BVT(Build Verification Test : 빌드 검증 테스트)의 기본 원칙 중에 ‘BVT 수행 시간은 30분을 넘기지 않는다.’가 있습니다.
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').click()
이러한 현상을 고려하여, WebElement의 click 메소드에 딜레이가 있는 것으로 판단하였고, 다른 기능을 활용하여 최적화하는 실험을 진행하였습니다.
최적화 실험
ActionChains 사용하여 최적화를 시도해보았습니다. (TouchAction을 사용할 수 있지만, 최신 버전에서는 권장하지 않는 기능으로 ActionChains를 선택했습니다.)
ActionChains가 WebElement에서 제공하는 메소드보다 element를 선택하고 동작하는 데 있어 좀 더 세밀하게 제어가 가능하기에 불필요한 동작이 없어 속도 향상에 적합할 것이라는 기대가 있었습니다.
WebElement의 click 메소드를 ActionChain의 click 메소드로 변경하여 테스트 시, element를 클릭하는 속도가 향상된 것을 확인했습니다.
action = ActionChains(wd)
action.move_to_element(element).click().pause(0.1).perform()
하지만, 위 코드를 사용했을 때의 문제점이 있었습니다. 바로 Webview 화면에서는 해당 코드가 동작하지 않는다는 것이었습니다.
새로운 기능을 찾아 추가 테스트를 진행해야 하나 고민을 했었으나, Webview 화면에서는 기존의 WebElement를 사용하여 click 하더라도 속도가 저하되지 않았습니다. 그래서, 현재 위치한 화면의 context를 확인해서 Native 화면에서는 최적화한 코드를 Webview 화면에서는 기존의 코드를 사용하도록 수정하여 테스트를 진행했습니다.
if 'NATIVE' in wd.current_context:
    ActionChains(wd).move_to_element(element).click().pause(0.1).perform()
else:
    element.click()
각 화면에서 element click 속도가 향상된 것을 확인하고 QA팀에서 진행하는 자동화 테스트의 모든 스크립트에 적용을 해보았습니다.
그 결과, 아래 스크린샷에서 보이는 것처럼 자동화 수행 시간이 최대 절반으로 감소된 것을 확인할 수 있었습니다.
왜 ActionChains가 더 빠를까?
WebElement와 ActionChains의 click 메소드를 확인해보니 두 기능 간의 차이와 속도 향상의 원인을 추측해 볼 수 있었습니다.
WebElement는 Selenium 3의 JSON Wire Protocol을 사용하여 통신하고, ActionChains에서는 Selenium 4의 W3C Webdriver Protocol을 사용하고 있습니다.
각각 다른 Selenium 버전을 사용하여 동작을 하고 있는데, 두 버전 간의 차이점을 확인해보았습니다.
Selenium 3에서 Selenium 4로 업데이트되며 가장 큰 변경사항은 JSON Wire Protocol을 W3C Webdriver Protocol로 대체하게 되었다는 것입니다.
Selenium 3에서는 클라이언트(Python)과 서버(Browser Driver) 간의 직접적인 통신이 없고, JSON Wire Protocol을 사용하여 클라이언트와 서버 간의 데이터를 전송하고 있었습니다. 이로 인해 (1) 통신의 단계 추가로 비효율적 (2) 표준화 불충분으로 브라우저 간의 일관성과 호환성이 부족하여 자동화 수행 속도에 부정적인 영향을 끼쳤습니다.
Selenium 4에서는 JSON Wire Protocol을 제거하며 클라이언트와 서버 간의 직접 통신이 가능해졌습니다. W3C WebDriver Protocol을 사용하며 (1) 통신의 단계 1단계 축소 (2) W3C에서 표준으로 제정한 프로토콜을 사용하며 표준화된 형식으로 브라우저 간의 일관성과 호환성 향상되었습니다.
이로 인해 Selenium 3 코드 대신 Selnium 4의 코드를 사용함으로써 자동화 실행 속도가 빨라졌다는 결과에 이르렀습니다.
마치며
최적화 실험을 통해 실행 속도를 거의 2배 가까이 향상시킬 수 있을 것이라는 생각을 하지 못한 것은 아쉬운 부분이었습니다. 기존에 사용하던 WebElement 메소드들이 잘 작동하고 있었고, iOS가 Android보다 속도가 느리다는 편견으로 속도 차이를 해석했던 것이 원인으로 보입니다.
속도 향상의 필요성을 깨닫고 시도하기까지의 시간이 길게 소요된 점은 아쉽습니다. 하지만, 앞으로는 “원래 그런 거야”라는 생각을 최대한 배제하고, 지금의 경험을 바탕으로 효율적인 테스트 및 자동화 방법에 대해 지속적으로 고민하는 QA가 되기로 다짐하며 글을 마치겠습니다. 감사합니다.
이렇게 QA활동과 지식공유 활동이 활발하게 이루어지고 있는
‘29CM 엔지니어링 조직에 합류하세요!’
🚀 29CM 채용 페이지 : https://www.29cmcareers.co.kr
iOS와 Android 간 UI 자동화 실행 속도 차이 해결하기 (부제 : ActionChains로 iOS 테스트 자동화 속도에 로켓 달아주기) was originally published in 29CM TEAM on Medium, where people are continuing the conversation by highlighting and responding to this story.

iOS와 Android 간 UI 자동화 실행 속도 차이 해결하기 (부제 : ActionChains로 iOS 테스트 자동화 속도에 로켓 달아주기)

댓글