지난 10년간 모바일 자동화는 Appium과 같은 프레임워크 덕분에 크게 발전했습니다. 이러한 프레임워크를 통해 개발팀은 익숙한 언어와 도구를 사용하여 앱을 자동화할 수 있게 되었습니다. 동시에 React Native, Flutter, Jetpack Compose와 같은 최신 UI 프레임워크는 네이티브 UI 레이어의 많은 부분을 추상화하여 모바일 애플리케이션 개발 방식을 혁신적으로 변화시켰습니다.
이러한 프레임워크는 개발 속도를 높여주지만, 특히 UI 요소가 동적으로 생성되거나 안정적인 식별자가 없는 경우 테스트 자동화에 예상치 못한 문제를 야기할 수도 있습니다.
최신 프레임워크가 자동화 도구에 UI 요소를 노출하는 방식을 이해하면 팀은 개발자 친화적이면서도 자동화에 친화적인 애플리케이션을 설계하는 데 도움이 될 수 있습니다.
모바일 자동화 도구가 UI 요소를 식별하는 방법
자동화 프레임워크(예: ...) 아 피움 운영체제에서 제공하는 기본 자동화 프레임워크를 통해 모바일 애플리케이션과 상호 작용합니다.
예 :
- AndroidUIAutomator2 :
- iOS: XCUITest
이러한 네이티브 프레임워크는 애플리케이션의 UI 계층 구조를 자동화 도구에 노출합니다. 테스트 스크립트는 다음과 같은 로케이터를 사용하여 이 계층 구조의 요소와 상호 작용합니다.
- 접근성 ID
- 리소스 ID
- XPath 표현식
- 수업 명
이 중에서 접근성 식별자는 빌드 및 UI 변경 전반에 걸쳐 안정적으로 유지되는 경향이 있으므로 널리 권장됩니다.
Appium을 처음 접하는 독자분들은 개요를 살펴보실 수 있습니다. Appium 아키텍처는 다음과 같습니다..
최신 UI 프레임워크 및 로케이터 안정성
React Native, Flutter, Jetpack Compose와 같은 프레임워크는 개발자가 UI 코드를 보다 효율적으로 작성할 수 있도록 추상화 계층을 제공합니다. 하지만 이러한 프레임워크는 종종 런타임에 네이티브 UI 구성 요소를 동적으로 생성합니다.
그 결과 :
- UI 계층 구조는 빌드마다 변경될 수 있습니다.
- 일부 요소는 안정적인 식별자를 노출하지 않을 수 있습니다.
- 자동으로 생성된 뷰 구조는 위치 탐지기의 신뢰성에 영향을 미칠 수 있습니다.
이는 이러한 프레임워크를 자동화하기 어렵다는 의미가 아닙니다. 오히려 자동화의 중요성을 강조하는 것입니다. UI 요소에 대한 안정적인 식별자를 명시적으로 정의합니다. 자동화 테스트가 의존하는 요소입니다.
이는 AI 기반 자가 복구와 같은 새로운 기능에도 영향을 미칩니다. 이러한 시스템은 로케이터가 실제로 변경되었는지 인식하기 위해 애플리케이션 구조의 안정성에 어느 정도 의존합니다. 식별자와 UI 계층 구조가 빌드 간에 크게 변경되면 실행할 때마다 "복구"가 필요할 수 있으며, 이는 자동 복구 메커니즘의 효율성을 떨어뜨립니다.
빌드 간 식별자 불안정성
자동화 불안정의 일반적인 원인 중 하나는 UI 요소가 빌드 간에 변경되는 식별자에 의존하는 경우입니다.
예는 다음과 같습니다 :
- 접근성 식별자가 정의되지 않은 요소
- 동적으로 생성된 뷰 구조
- 내부 구성 요소 계층 구조에서 파생된 식별자
이러한 경우 자동화 테스트는 기본 UI 구조가 변경되었기 때문에 한 빌드에서는 통과하지만 다른 빌드에서는 실패할 수 있습니다.
이는 특히 최신 UI 프레임워크에서 흔히 볼 수 있는데, 레이아웃 업데이트나 프레임워크 최적화에 따라 렌더링되는 네이티브 구성 요소가 달라질 수 있기 때문입니다.
예시: React Native의 안정적인 식별자
React Native와 같은 프레임워크는 개발자가 자동화를 위해 안정적인 식별자를 노출할 수 있도록 하는 속성을 제공합니다.
예 :
<Button
testID="login_button"
title="Login"
/>
이 식별자는 자동화 프레임워크에서 사용할 수 있게 되어 테스트에서 해당 요소를 안정적으로 찾을 수 있도록 합니다.
이처럼 명시적인 식별자를 사용하면 UI 레이아웃이 시간이 지남에 따라 변경되더라도 테스트가 안정적으로 유지됩니다.
접근성과 테스트 용이성은 종종 밀접한 관련이 있습니다.
접근성 식별자를 사용하는 것은 자동화에 도움이 될 뿐만 아니라, 화면 낭독기와 같은 보조 기술에 의존하는 사용자의 사용성도 향상시킵니다.
모두 Apple 구글 의미 있는 접근성 레이블과 식별자를 노출하는 것을 권장합니다. 접근성 향상을 위한 모바일 애플리케이션.
실제로 이는 접근성을 염두에 두고 UI 요소를 디자인하면 종종 개선 효과가 나타난다는 것을 의미합니다. 자동화 신뢰성을 동시에.
실용적인 디버깅 팁: UI 계층 구조를 검사하세요
로케이터가 빌드 간에 일관되지 않게 동작하는 경우, UI 계층 구조를 검사하면 요소가 자동화 도구에 어떻게 노출되는지 파악할 수 있습니다.
이를 위한 도구는 다음과 같습니다.
- Appium 검사관
- Xcode 접근성 검사기
- 안드로이드 UIAutomator 뷰어
- 안드로이드 스튜디오 레이아웃 검사기
이러한 도구를 사용하면 테스터는 UI 트리를 검사하고 다음을 확인할 수 있습니다.
- 요소들이 안정적인 접근성 식별자를 노출하는지 여부
- 식별자가 빌드 간에 변경되는지 여부
- UI 계층 구조에 동적으로 생성된 구성 요소가 포함되어 있는지 여부
종종 UI 계층 구조를 살펴보는 것만으로도 로케이터 불안정의 근본 원인을 훨씬 쉽게 파악할 수 있습니다.
QA 엔지니어를 위한 모범 사례
QA 엔지니어는 몇 가지 핵심 사항을 준수함으로써 자동화의 신뢰성을 향상시킬 수 있습니다.
- 취하다 접근성 식별자 XPath 로케이터에 대하여
- 여러 빌드에서 로케이터의 안정성을 검증합니다.
- 개발자와 협력하여 안정적인 식별자를 정의하십시오.
- UI 검사 도구를 사용하여 로케이터 전략을 검증하세요.
자동화 프레임워크는 강력하지만, 애플리케이션이 UI 요소를 어떻게 노출하는지에 크게 의존합니다.
모바일 개발자를 위한 모범 사례
개발자는 UI 개발 과정에서 자동화를 고려함으로써 테스트 용이성을 크게 향상시킬 수 있습니다.
도움이 되는 방법은 다음과 같습니다.
- 중요 UI 요소에 대한 명확한 접근성 식별자 정의
- 동적으로 생성되는 식별자를 피합니다.
- 빌드 간 식별자 일관성 유지
- 자동화 테스트에서 사용되는 식별자 문서화
개발자들이 테스트 용이성을 UI 디자인 프로세스의 일부로 고려할 때, 자동화는 훨씬 더 안정적이고 유지 관리하기 쉬워집니다.
자동화는 그 일부입니다. Continuous Testing
최신 개발 파이프라인에서 모바일 자동화는 종종 개발 수명 주기 전반에 걸쳐 자동화된 테스트가 실행되는 보다 광범위한 지속적 테스트 전략의 일부입니다.
대규모 디바이스 환경에서 자동화를 확장하려는 팀은 종종 Appium과 같은 프레임워크를 대규모 모바일 자동화 실행을 지원하는 디바이스 팜 플랫폼과 함께 사용합니다. 이를 통해 여러 디바이스와 OS 버전에 걸쳐 테스트를 수행할 수 있습니다.
전단지에 포함된 링크에 대해 더 알아보기 Digital.ai 테스트 플랫폼은 여기입니다: https://docs.digital.ai/continuous-testing/
맺음말
React Native, Flutter, Jetpack Compose와 같은 최신 모바일 프레임워크는 개발자 생산성을 크게 향상시켰습니다. 그러나 이러한 프레임워크의 추상화 계층은 개발 단계에서 테스트 용이성을 고려하지 않으면 자동화에 어려움을 초래할 수 있습니다.
안정적인 자동화를 위해서는 QA 엔지니어와 개발자 모두 다음과 같은 사항을 고려하는 것이 도움이 됩니다. UI 디자인의 핵심 요소로서 테스트 식별자, 덧붙여 생각한 것이 아니라.
안정적인 접근성 식별자는 Appium과 같은 도구를 사용한 자동화의 신뢰성을 향상시키는 동시에 실제 사용자를 위한 더 나은 접근성을 지원합니다.
팀들이 초기에 테스트 용이성을 위해 협력하면(안정적인 식별자를 노출하고, 동적 로케이터를 피하고, UI 계층 구조를 검증하는 등) 모바일 자동화가 빌드 전반에 걸쳐 훨씬 더 예측 가능하고 유지 관리하기 쉬워집니다.
많은 경우, 취약한 자동화와 신뢰할 수 있는 자동화의 차이는 테스트 도구 자체에 있는 것이 아니라 애플리케이션 UI가 얼마나 테스트하기 쉽게 설계되었는지에 달려 있습니다.