앱 MVP Android UI Automator: 앱 밖 화면까지 검수 범위를 나누는 5가지 기준
앱 MVP Android UI Automator: 앱 밖 화면까지 검수 범위를 나누는 5가지 기준
앱에서 핵심 버튼을 눌렀는데 시스템 권한 창, 브라우저, 다른 앱 선택 화면이 이어지면 앱 내부 UI 테스트만으로는 사용자의 실제 경로를 끝까지 확인하기 어렵습니다. 그렇다고 모든 화면을 거대한 자동화 시나리오 하나에 넣으면, 어떤 조건에서 실패했는지와 제품 문제가 무엇인지 분리하기도 어려워집니다.
먼저 답하면, Android MVP의 UI Automator 검수는 검수할 외부 경계, 기기·앱 빌드, 선택 기준, 완료 조건, 실패 기록을 각각 따로 정할 때 가장 실용적입니다. UI Automator는 앱 프로세스 바깥에서 UI를 다룰 수 있어, 릴리스 빌드와 시스템 UI를 포함한 경로의 검수에 쓸 수 있습니다. 다만 자동화 통과가 모든 기기·계정·네트워크 조건에서의 기능 보증은 아닙니다.
이 글은 실제 앱의 자동화 성공률이나 출시 승인 결과를 말하지 않습니다. 테스트를 새로 만들기 전에 무엇을 제품 범위로 선택하고, 어떤 관찰을 남길지 정하는 기록에 초점을 둡니다. 앱 안의 코드 경고를 정리하는 일은 Android Lint baseline 점검에서, 배포 전 자동 탐색 보고서는 Google Play 사전 출시 보고서에서 이어서 확인할 수 있습니다.
1. 먼저 ‘앱 밖까지 확인할 이유’를 한 문장으로 씁니다
UI Automator는 앱 프로세스 밖에서 앱을 테스트할 수 있습니다. Android Developers는 이 특성으로 minification이 적용된 release 버전도 테스트할 수 있다고 설명합니다. 따라서 시스템 권한 창, 외부 앱으로 이동하는 작업, 앱과 시스템 UI가 번갈아 나오는 경로처럼 앱 내부 테스트만으로 경계를 보기 어려운 경우에 후보가 됩니다.
하지만 “자동화 도구를 쓴다”는 이유만으로 모든 사용자 여정을 넣을 필요는 없습니다. MVP에서는 한 시나리오가 답해야 할 질문을 하나로 좁히는 편이 좋습니다. 예를 들어 사진 선택에서 앱 화면과 시스템 선택 화면을 오가는 경로라면, 사진 자체의 품질이 아니라 ‘사용자 취소 뒤 앱이 어떤 상태로 돌아오는가’를 검수 질문으로 정할 수 있습니다.
기록 칸 | 먼저 정할 질문 | 예시 |
|---|---|---|
검수 경계 | 앱 화면만인가, 시스템 또는 다른 앱까지인가? | 권한 창 확인 뒤 앱 복귀 |
사용자 목적 | 사용자가 끝내려는 한 가지 행동은 무엇인가? | 문서 한 개 선택 후 첨부 |
제외 범위 | 이번 시나리오에서 검증하지 않는 것은 무엇인가? | 서버 처리 완료·실사용자 수 |
완료 신호 | 화면 변화, 저장값, 다음 행동 중 무엇을 확인하는가? | 선택 결과가 입력 칸에 표시됨 |
실패 기록 | 재시도 전에 남길 조건은 무엇인가? | 빌드·기기·OS·계정·화면 상태 |
이 표는 Android의 필수 양식이 아닙니다. 자동화 로그의 성공 표시를 곧바로 고객 업무 완료나 제품 품질 전체로 읽지 않기 위한 팀용 기록입니다.
2. 로컬 테스트와 기기 테스트의 질문을 섞지 않습니다
Android Developers는 instrumented test가 실제 기기 또는 에뮬레이터에서 실행되고, local test는 개발용 컴퓨터에서 실행된다고 구분합니다. 또 모든 단위 테스트가 local인 것도, 모든 end-to-end 테스트가 기기에서 실행되는 것도 아니라고 안내합니다. 이 구분은 도구 선택보다 먼저 ‘무엇을 관찰할 것인가’를 정하는 데 도움이 됩니다.
앱의 순수 계산 규칙과 데이터 변환은 짧고 빠른 테스트에 남길 수 있습니다. 반대로 화면 전환, 시스템 UI, 실제 설치된 앱과의 상호작용처럼 Android 환경이 필요한 질문은 기기 실행 기록이 필요할 수 있습니다. 두 종류의 결과를 하나의 “테스트 완료” 수치로 합치면, 실패한 층이 코드인지 환경인지 사용자 경로인지 알기 어려워집니다.
작은 MVP 팀은 각 시나리오에 다음을 덧붙여 보세요.
실행한 앱의 package와 versionCode 또는 식별 가능한 빌드 정보를 남깁니다.
실기기인지 에뮬레이터인지, Android 버전과 화면 언어·방향을 구분합니다.
테스트 데이터와 계정 상태를 재현 가능한 수준에서만 적고 민감정보를 복사하지 않습니다.
실패가 코드 결함인지, 시스템 설정·권한·네트워크 조건인지 아직 모르는 경우를 그대로 남깁니다.
같은 경로를 다른 기기에서 다시 보더라도, 이전 관찰을 모든 기기 결과로 일반화하지 않습니다.
3. 선택 기준은 문구보다 역할·상태를 우선 검토합니다
현대 UI Automator API는 Kotlin 친화적인 DSL과 predicate 기반 요소 찾기를 제공합니다. 화면의 표시 문구만 찾는 방식은 번역, 공백, 실험 문구 변경에 영향을 받을 수 있습니다. 반대로 내부 구현 이름에 과도하게 묶인 선택도 화면의 실제 사용 경험과 멀어질 수 있습니다.
그래서 선택 기준을 정할 때는 “이 요소가 이 문구를 가졌는가”만 쓰기보다, 사용자가 할 수 있는 역할과 테스트에서 필요한 상태를 함께 적는 것이 좋습니다. 예를 들어 저장 버튼을 찾았다면, 버튼을 눌렀다는 사실과 저장을 기다리는 표시가 사라졌다는 사실, 다음 화면에 이동했다는 사실은 서로 다른 관찰입니다.
관찰 대상 | 불충분할 수 있는 기록 | 분리해 둘 기록 |
|---|---|---|
조작 대상 | 버튼을 찾음 | 어떤 조건에서 활성 상태였는가 |
화면 변화 | 탭 실행 | 다음 화면 또는 상태가 나타났는가 |
대기 | 일정 시간 대기 | 어떤 조건을 기다렸는가 |
시스템 창 | 표시됨 | 허용·거부·닫기 중 어떤 행동을 했는가 |
복귀 | 앱이 다시 보임 | 원래 작업을 계속할 수 있는가 |
이 기준은 특정 selector가 항상 옳다는 처방이 아닙니다. 실제 앱의 접근성 의미, 언어 지원, 화면 구조를 보고 팀이 안정적인 관찰 단서를 정해야 합니다. 텍스트 크기나 보조기술 흐름의 제품 검수는 앱 MVP 스크린 리더 흐름도 함께 확인하세요.
4. 대기는 시간 약속이 아니라 상태 관찰로 기록합니다
Android Developers는 큰 기기 테스트가 더 느리고 불안정해질 수 있다고 설명합니다. 그래서 임의의 긴 대기 시간을 늘리는 것만으로는 실패 원인이 줄었다고 보기 어렵습니다. 대기가 필요한 화면이라면, ‘몇 초 기다렸다’와 ‘사용자가 다음 행동을 할 수 있는 상태가 됐다’를 구분해 남기세요.
가령 외부 선택 화면에서 앱으로 돌아온 뒤에는 앱이 포그라운드가 됐는지, 선택 결과가 들어왔는지, 오류 안내가 나왔는지, 다시 시도할 수 있는지 중 무엇을 관찰할지 정합니다. 이 네 가지는 같은 순간에 일어날 수도 있지만, 하나가 참이라고 나머지가 자동으로 참이 되는 것은 아닙니다.
실패가 반복되면 먼저 테스트의 조건을 기록합니다. 실행 시각, 앱 빌드, 기기·OS, 네트워크 상태, 선택 전 화면, 사용한 계정·권한 상태, 마지막으로 확인한 UI 상태가 최소 단서가 됩니다. 이를 남기면 단순 재실행과 제품 코드 수정, 테스트 선택 기준 수정 중 무엇이 필요한지 분리해 논의할 수 있습니다.
5. 통과 결과와 출시 판단을 별도 칸에 둡니다
UI Automator는 Macrobenchmark와 함께 UI 상호작용을 구동하고 성능 측정에 쓰일 수도 있습니다. 그러나 하나의 자동화 시나리오 통과, 성능 측정값, 스토어 배포 승인, 실제 사용자 경험은 각각 다른 증거입니다. 테스트가 통과했더라도 지원 기기, 서버 상태, 계정 조건, 접근성 흐름, 배포 후 관찰을 대신하지 않습니다.
출시 전에는 아래 다섯 문장으로 결과를 닫아 보세요.
이번 시나리오가 확인한 사용자 경로와 제외한 경로는 무엇인가?
어떤 빌드·기기·OS·설정에서 실행했는가?
마지막으로 확인한 화면 상태와 완료 신호는 무엇인가?
실패 또는 미확인 조건은 무엇이며, 누가 다음 판단을 하는가?
이 결과가 출시 판단에서 보조하는 증거는 무엇이고, 아직 대체하지 못하는 증거는 무엇인가?
유인어스는 민간 사업 지원 서비스입니다. 실제 앱 테스트와 출시 결정은 현재 Android 공식 문서, 사용 중인 도구 버전, 앱의 개인정보 처리와 실제 기기·서비스 조건을 함께 검토해 내리세요.
자주 묻는 질문
UI Automator는 앱 내부 UI 테스트를 모두 대체하나요?
아닙니다. UI Automator는 앱 프로세스 밖에서 UI를 다룰 수 있어 시스템 UI나 외부 경계를 포함한 시나리오에 유용할 수 있습니다. 로컬 테스트, 앱 내부 UI 테스트, 기기 기반 검수는 서로 다른 질문을 다룰 수 있으므로 목적에 맞춰 조합해야 합니다.
자동화가 한 번 통과하면 출시해도 되나요?
한 번의 통과는 그 빌드와 그 실행 조건에서 관찰한 결과입니다. 지원 기기, 계정·권한 상태, 네트워크, 배포 설정, 실제 사용자 환경까지 모두 보장하지 않습니다. 통과 조건과 미확인 조건을 함께 기록하세요.
테스트가 가끔 실패하면 기다리는 시간만 늘리면 되나요?
그렇게 단정하기 어렵습니다. Android Developers는 큰 기기 테스트가 더 느리고 불안정할 수 있다고 설명합니다. 먼저 대기해야 하는 상태, 마지막 UI 상태, 기기·OS·빌드·권한 조건을 기록한 뒤 선택 기준·환경·제품 동작 중 무엇을 확인할지 나누세요.
UI Automator 결과를 성능 지표로 써도 되나요?
UI Automator는 Macrobenchmark의 UI 상호작용 구동에 사용될 수 있습니다. 다만 자동화 통과 여부와 측정값, 사용자 경험, 비즈니스 성과는 다른 지표입니다. 측정 방법과 조건을 함께 남기고 결과 범위를 과장하지 마세요.
확인한 공식 출처
Android Developers · Write automated tests with UI Automator — 앱 프로세스 밖 UI 검수, release 버전 검수, predicate 기반 요소 찾기, Macrobenchmark와의 관계를 2026-09-22 KST에 확인했습니다.
Android Developers · Fundamentals of testing Android apps — local·instrumented test 구분, 기기 기반 테스트의 범위와 큰 테스트의 속도·불안정성 주의점을 2026-09-22 KST에 확인했습니다.