23.06.15
DEVOTEE를 활성화 시키면
지금 작성한 커뮤니티 글에 대해 1개의 댓글을 달아줍니다.
버튼을 누르면 글 수정 시 ChatGPT가 작성한 댓글이 수정됩니다.
| 컨텐츠 유형 | 제목 | 저장일 | 삭제 |
|---|
본인인증 로그인에 실패하였습니다.
회원이 아니시거나 본인인증 등록이
완료되지 않은 사용자입니다.
안녕하세요.
에이닷의 모바일 앱 품질 향상을 위해 UI 테스트 자동화를 도입하는 과정에서, 크로스 플랫폼 테스트 도구인 Appium의 가능성과 효용성을 검토하게 되었습니다.
iOS와 Android 양쪽 모두를 효과적으로 테스트할 수 있는 방법을 찾던 중,
Appium이 어떤 장점을 가지고 있는지, 어떤 범위의 테스트를 수행할 수 있을지 직접 경험하며 이 블로그 글을 작성하게 되었습니다.
이 글에서는 모바일 앱 테스트 자동화의 중요성과 함께, Appium을 이용한 크로스 플랫폼 UI 테스트에 초점을 맞추어 다양한 테스트 기법과 노하우를 소개하고자 합니다.
Appium의 기본 설정부터 시작하여, iOS와 Android 앱에 대한 테스트 스크립트 작성 방법, 그리고 다양한 UI 요소 검증 기법에 대해 살펴보겠습니다.
또한, 네이티브 앱과 하이브리드 앱 테스트의 차이점, 디바이스 다양성 대응 전략,
그리고 CI/CD 파이프라인 통합과 같은 실제 적용 시 고려사항에 대한 팁도 포함하여 보다 포괄적인 테스트 전략을 제시하고자 합니다.
Appium을 이용한 UI 테스트 자동화 과정에서 얻은 경험과 인사이트를 공유하며, 실제 적용 시 마주칠 수 있는 상황들과 그에 대한 대응 방법을 소개하고자 합니다.
또한, 테스트 스크립트 작성에 도움이 될 수 있는 코드 예제를 함께 제공하여 여러분께 실질적인 도움이 되는 정보를 전달하려고 합니다.
이 블로그 글을 통해 Appium을 이용한 UI 테스트 자동화에 대한 기초적인 이해부터 실제 적용 시 고려해야 할 점들까지 폭넓게 다루어,
크로스 플랫폼 모바일 앱 개발 과정에서의 테스트 전략 수립에 참고가 되기를 바랍니다.
이 글과 관련된 기존 글도 함께 공유합니다.
에이닷 개발팀은 현재 UI 테스트 자동화 도입을 위해 다양한 솔루션을 검토하고 있습니다.
이는 서비스 품질 향상과 개발 생산성 증대를 위한 노력의 일환입니다. 주요 목표는 다음과 같습니다:
개발 및 검증 과정에서 효과적으로 활용할 수 있는 UI 테스트 자동화 솔루션 선정
에이닷 서비스의 특성에 맞는 최적의 테스트 자동화 전략 수립
다양한 솔루션의 장단점을 비교 분석하여 최적의 선택 도출
현재 시장에서 주목받고 있는 세 가지 주요 UI 테스트 자동화 솔루션에 대해 프로토타입 테스트를 진행하고 있습니다:
Appium: 크로스 플랫폼 테스트가 가능한 오픈 소스 프레임워크
XCTest: iOS 앱 테스트를 위한 Apple의 공식 프레임워크
Espresso: Android 앱 테스트를 위한 Google의 공식 프레임워크
각 솔루션 평가 시 중점적으로 고려하고 있는 요소들은 다음과 같습니다:
초기 설정 및 학습 용이성
테스트 작성의 편의성
실행 속도 및 안정성
크로스 플랫폼 지원 여부
CI/CD 파이프라인과의 통합 용이성
커뮤니티 지원 및 문서화 수준
에이닷 앱의 특수한 요구사항 충족 여부
궁극적으로, 이러한 검토 과정을 통해 우리는 다음을 목표로 합니다:
에이닷 서비스에 가장 적합한 UI 테스트 자동화 솔루션 선정
효과적인 테스트 전략 수립
더 나은 사용자 경험 제공
이 문서가 UI 테스트 자동화를 고려하고 있는 다른 개발자들에게도 도움이 되기를 바랍니다.
Appium은 모바일 애플리케이션(iOS, Android)과 데스크톱 애플리케이션(Windows, macOS)의 자동화 테스트를 위한 오픈 소스 크로스 플랫폼 테스트 자동화 프레임워크입니다.
2013년에 처음 출시된 이후, 모바일 앱 테스트 자동화 분야에서 널리 사용되고 있습니다.
특히 주목할 점은, Appium이 국내 다양한 모바일 서비스에서 가장 많이 사용되고 있는 테스트 자동화 솔루션이라는 것입니다.
대형 IT 기업부터 스타트업까지, 많은 한국 기업들이 Appium을 채택하여 모바일 앱의 품질을 향상시키고 개발 생산성을 높이고 있습니다.
이는 Appium의 강력한 기능과 유연성, 그리고 다양한 개발 환경에 대한 적응성을 잘 보여주는 사례입니다.
Appium의 핵심 특징은 다음과 같습니다:
크로스 플랫폼 지원: iOS와 Android 앱을 동일한 API로 테스트할 수 있습니다.
이는 개발 팀이 단일 테스트 스위트로 여러 플랫폼을 커버할 수 있게 해주어, 시간과 리소스를 크게 절약할 수 있습니다.
다양한 프로그래밍 언어 지원: Java, Python, JavaScript, Ruby 등 여러 언어로 테스트 스크립트를 작성할 수 있습니다.
이러한 유연성은 팀이 이미 익숙한 언어로 테스트를 구현할 수 있게 해주어, 학습 곡선을 낮추고 생산성을 높입니다.
네이티브, 하이브리드, 웹 앱 테스트: 모든 유형의 모바일 앱을 테스트할 수 있습니다.
이는 Appium이 다양한 앱 개발 방식에 적응할 수 있음을 의미하며, 특히 여러 유형의 앱을 개발하는 기업에게 큰 이점입니다.
실제 디바이스 및 에뮬레이터/시뮬레이터 지원: 다양한 환경에서 테스트가 가능합니다.
이는 개발 초기 단계부터 최종 출시 전까지 모든 단계에서 철저한 테스트를 가능하게 합니다.
Appium의 이러한 특징들과 국내 산업에서의 광범위한 채택은, 이 도구가 모바일 앱 테스트 자동화의 신뢰할 수 있는 표준으로 자리잡았음을 보여줍니다.
에이닷을 비롯한 많은 기업들이 Appium을 통해 테스트 프로세스를 혁신하고, 더 높은 품질의 앱을 더 빠르게 제공할 수 있게 되었습니다.
Appium의 큰 장점 중 하나는 크로스 플랫폼 테스트가 가능하다는 점입니다.
하지만 실제로 하나의 스크립트로 iOS와 Android 모두를 완벽하게 테스트하는 것은 쉽지 않습니다. 여기서는 이를 효과적으로 수행할 수 있는 방법을 소개합니다.
Appium의 기본 함수들은 때때로 iOS와 Android에서 다르게 동작할 수 있습니다.
이를 해결하기 위해, 주요 동작들(클릭, 스크롤, 텍스트 확인 등)에 대한 래퍼 함수를 만들어 사용하는 것이 효과적입니다.
예를 들어, 다음과 같은 래퍼 함수를 만들 수 있습니다:
def click_element(self, locator):
if self.platform == 'ios':
self.driver.find_element_by_ios_predicate(locator).click()
elif self.platform == 'android':
self.driver.find_element_by_android_uiautomator(locator).click()
def scroll_to_element(self, locator):
if self.platform == 'ios':
self.driver.execute_script('mobile: scroll', {'predicateString': locator, 'toVisible': True})
elif self.platform == 'android':
self.driver.find_element_by_android_uiautomator(f'new UiScrollable(new UiSelector().scrollable(true).instance(0)).scrollIntoView(new UiSelector().text("{locator}").instance(0))')
def verify_text(self, expected_text):
if self.platform == 'ios':
actual_text = self.driver.find_element_by_ios_predicate(f'label == "{expected_text}"').text
elif self.platform == 'android':
actual_text = self.driver.find_element_by_android_uiautomator(f'new UiSelector().text("{expected_text}")').text
assert actual_text == expected_text, f"Expected text '{expected_text}' but found '{actual_text}'"이러한 래퍼 함수를 사용하면, 테스트 스크립트 본문에서는 플랫폼 차이를 신경 쓰지 않고 동일한 코드를 사용할 수 있습니다.
효과적인 크로스 플랫폼 테스트를 위한 스크립트 구조와 관리 방법은 다음과 같습니다:
기본 클래스 생성: iOS와 Android에서 공통으로 사용할 수 있는 기본 클래스를 만듭니다.
이 클래스에는 위에서 언급한 래퍼 함수들을 포함시킵니다.
페이지 객체 모델 사용: 각 화면에 대한 페이지 객체를 만들고, 이를 iOS와 Android 버전으로 구분합니다.
공통 인터페이스를 정의하여 테스트 코드에서는 동일한 메서드를 호출할 수 있게 합니다.
설정 파일 분리: iOS와 Android의 고유한 설정(예: 디바이스 이름, 플랫폼 버전 등)은 별도의 설정 파일로 분리합니다.
조건부 로직 최소화: 테스트 코드 내에서 if platform == 'ios' 와 같은 조건문 사용을 최소화합니다.
대신 페이지 객체나 래퍼 함수에서 이러한 로직을 처리합니다.
테스트 데이터 관리: 테스트 데이터도 플랫폼별로 다를 수 있으므로, 이를 효과적으로 관리할 수 있는 구조를 만듭니다.
비동기 작업을 포함한 모바일 앱 테스트를 위한 Appium 코드 예제입니다. 이 코드는 비동기 작업의 결과를 기다리고 확인하는 방법을 보여줍니다.
from appium.webdriver.common.appiumby import AppiumBy
import time
def wait_for_element(driver, locator, timeout=5):
# 지정된 시간 동안 요소가 나타날 때까지 기다립니다.
start_time = time.time()
while time.time() - start_time < timeout:
try:
element = driver.find_element(*locator)
if element.is_displayed():
return element
except:
pass
time.sleep(0.5) # 0.5초 간격으로 폴링하여 CPU 사용 최소화
raise TimeoutError(f"Element not found within {timeout} seconds")
def test_async_scenario(self):
# 비동기 작업 시작 (예: 버튼 클릭)
start_button = self.driver.find_element(AppiumBy.ACCESSIBILITY_ID, "start_async_task_button")
start_button.click()
try:
# 비동기 작업의 결과를 최대 5초간 기다림
result_element = wait_for_element(
self.driver,
(AppiumBy.ACCESSIBILITY_ID, "async_task_result"),
timeout=5
)
# 결과 확인
result_text = result_element.text
self.assertEqual(result_text, "Expected Result")
except TimeoutError:
self.fail("Async task did not complete in time")
# 테스트 실행
test_async_scenario(self)실제로 비동기 시나리오를 적용할 때는 케이스별로 다양한 조건이 필요합니다.
예를 들어, 네트워크 상태, 서버 응답 시간, 디바이스 성능 등에 따라 대기 시간이 달라질 수 있습니다.
일반적인 접근 방식으로, 우리는 클릭 시나리오에 일괄적으로 5초간 대기하는 방법을 적용해보았습니다.
이는 다음과 같은 이점을 제공합니다:
단순성: 모든 비동기 작업에 동일한 대기 시간을 적용하여 코드의 일관성을 유지합니다.
안정성: 대부분의 경우 5초는 작업 완료에 충분한 시간이며, 불필요한 지연을 최소화합니다.
유지보수 용이성: 필요에 따라 전역적으로 대기 시간을 쉽게 조정할 수 있습니다.
그러나 이 접근 방식의 한계점도 인지해야 합니다:
일부 빠른 작업의 경우 불필요한 대기 시간이 발생할 수 있습니다.
복잡하거나 시간이 많이 소요되는 작업의 경우 5초가 충분하지 않을 수 있습니다.
따라서, 실제 프로덕션 환경에서는 다음과 같은 개선을 고려할 수 있습니다:
작업의 성격에 따라 다양한 타임아웃 값을 설정합니다.
동적으로 대기 시간을 조정하는 로직을 구현합니다.
명시적인 완료 신호(예: 특정 UI 요소의 출현)를 기다리는 방식을 사용합니다.
이 코드와 접근 방식은 시작점으로 사용하고, 실제 애플리케이션의 요구사항과 특성에 맞게 조정하는 것이 좋습니다.
Appium으로 모바일 앱 테스트 자동화를 샘플 테스트해 본 결과,
가장 주목할 만한 장점은 iOS와 Android에 대한 깊은 기술적 이해 없이도 효과적인 크로스 플랫폼 테스트가 가능하다는 점입니다.
Appium의 작동 방식과 API에 대한 이해만으로도 양쪽 OS의 앱을 동시에 테스트할 수 있습니다.
이는 네이티브 코드(Swift, Kotlin 등)나 OS별 테스트 프레임워크(XCTest, Espresso 등)에 대한 전문 지식 없이도 QA 팀이 효과적으로 테스트를 수행할 수 있게 해줍니다.
더불어, Python 지원은 이러한 접근성을 한층 더 높여줍니다.
Python의 간결한 문법과 풍부한 라이브러리 생태계는 개발 배경이 없는 QA 전문가나 비개발자도 쉽게 테스트 자동화에 참여할 수 있게 합니다.
Appium의 추상화 계층이 플랫폼 간 차이를 처리해주기 때문에, 하나의 테스트 스크립트로 iOS와 Android 앱을 모두 테스트할 수 있습니다.
이는 테스트 코드의 중복을 줄이고 유지보수를 용이하게 만들며, 개발 및 테스트 과정의 효율성을 크게 높입니다.
결과적으로, Appium은 특정 OS에 대한 깊은 지식 없이도 크로스 플랫폼 모바일 앱 테스트 자동화를 구현하고자 하는 팀에게 이상적인 도구가 됩니다.
이는 테스트 자동화의 진입 장벽을 낮추고, 더 많은 팀 구성원이 품질 보증 과정에 참여할 수 있게 해줍니다.
Appium은 잘 동작하는 테스트 프레임워크이지만, 실제 서비스에 적용할 때 몇 가지 중요한 고려사항이 있었습니다:
복잡한 UI 상호작용: 일부 복잡한 제스처나 애니메이션이 포함된 UI 요소는 Appium으로 정확하게 테스트하기 어려울 수 있습니다.
디바이스 특정 기능: 특정 디바이스의 고유한 기능이나 하드웨어 상호작용을 테스트하는 데 제한이 있을 수 있습니다.
네이티브 앱 최적화: 네이티브 앱에 최적화된 일부 기능을 테스트하는 데 제한이 있을 수 있습니다.
SwiftUI 및 Jetpack Compose 지원: 최신 UI 프레임워크인 SwiftUI(iOS)와 Jetpack Compose(Android)로 개발된 앱에 대한 Appium의 효과적인 지원 여부가 의문이었습니다.
기존 TC의 Appium 최적화 어려움: 현재 작성된 수많은 TC를 Appium에 최적화하기 어려울 것 같다는 생각이 들었습니다.
기존의 네이티브 테스트 프레임워크나 수동 테스트를 기반으로 작성된 TC를 Appium 형식으로 변환하는 것은 시간과 리소스가 많이 소요되는 작업일 수 있습니다.
이러한 고려사항들로 인해, Appium 도입 시 다음과 같은 추가적인 도전 과제가 예상됩니다:
기존 테스트 자산의 재사용성: 기존 TC를 Appium으로 마이그레이션하는 과정에서 일부 테스트 로직이나 시나리오가 손실될 수 있습니다.
팀의 학습 곡선: 개발 팀과 QA 팀 모두 Appium에 적응하고 새로운 테스트 작성 방식을 익혀야 합니다.
테스트 커버리지 감소 위험: 모든 기존 TC를 Appium으로 완벽하게 변환하기 어려울 수 있어, 일시적으로 테스트 커버리지가 감소할 위험이 있습니다.
테스트 실행 시간 증가: Appium을 통한 크로스 플랫폼 테스트는 네이티브 테스트에 비해 실행 시간이 길어질 수 있습니다.
따라서 Appium 도입을 고려할 때는 이러한 요소들을 종합적으로 평가해야 합니다. 기존 TC의 변환 가능성, 그리고 이에 따른 비용과 이점을 철저히 분석해야 합니다.
경우에 따라서는 Appium을 부분적으로 도입하거나, 기존의 테스트 방식과 병행하여 사용하는 하이브리드 접근 방식을 고려할 수 있습니다.
결론적으로, Appium은 강력한 크로스 플랫폼 테스트 도구이지만, 실제 서비스에 적용할 때는 프로젝트의 특성, 기존 테스트 자산, 그리고 팀의 역량을 고려한 신중한 접근이 필요합니다.
장기적인 관점에서 Appium 도입의 이점과 초기 도입에 따른 비용을 균형있게 평가하는 것이 중요합니다.
모바일 앱 품질 향상과 개발 프로세스 효율화를 위해 UI 테스트 자동화 도입을 검토 중입니다.
이 과정에서 Appium, XCTest, Espresso 등 다양한 솔루션을 분석했습니다.
Appium은 크로스 플랫폼 지원, 다양한 언어 호환성, 실제 디바이스 및 에뮬레이터 지원 등의 장점을 보여주었습니다.
반면, 초기 설정의 복잡성과 일부 성능 관련 문제 등 잠재적 도전 과제도 확인했습니다.
현재 우리는 각 도구의 장단점을 평가하고 에이닷 서비스에 가장 적합한 솔루션을 선택하는 단계에 있습니다.
이 과정에서 얻은 인사이트는 향후 테스트 자동화 전략 수립에 중요한 자산이 될 것입니다.
우리의 목표는 단순한 도구 선택을 넘어, 선택된 솔루션을 효과적으로 활용하여 서비스 품질을 향상시키고 개발 효율성을 높이는 것입니다.
앞으로 테스트 커버리지 확대, CI/CD 파이프라인 통합 강화, 팀 내 테스트 자동화 역량 향상에 주력할 계획입니다.
이 글이 UI 테스트 자동화를 고려하는 다른 개발자들에게도 유용한 정보가 되길 바랍니다.
UI 테스트 자동화는 지속적인 학습과 개선의 과정입니다. 우리의 경험이 여러분의 여정에 작은 도움이 되길 희망합니다.
DEVOTEE를 활성화 시키면
지금 작성한 댓글에 AI가 댓글을 달아줍니다.