전체 화면 모양에는 스크린샷을 사용하고, 보이는 텍스트에는 OCR을 사용하고, 알려진 시각적 대상에 대해서는 이미지 일치를 사용하세요. 가장 강력한 Android 시각적 테스트는 하나의 집중된 주장과 안정적인 타이밍 및 실패 증거를 결합합니다.
짧은 대답: 반드시 진실이어야 하는 것을 테스트하세요
전체 화면, 구성 요소, 간격, 색상 또는 타이포그래피가 시각적으로 일관되게 유지되어야 하는 경우 스크린샷 테스트를 사용하세요. 사람이 볼 수 있는 단어, 특히 현지화되거나 동적으로 렌더링되는 텍스트에 대한 요구사항이 있는 경우 OCR을 사용하십시오. 신뢰할 수 있는 UI 식별자가 없더라도 알려진 아이콘, 버튼, 배지 또는 일러스트레이션이 표시되어야 하는 경우 이미지 일치를 사용합니다.
요구 사항이 의미론적일 때 UI 선택기 또는 접근성 상태로 시작합니다. 즉, 컨트롤이 존재하거나, 활성화되거나, 선택되거나 안정적인 레이블을 노출합니다. 대상이 시각적 클래스에 속하고 하나의 템플릿에 대해 크기나 위치가 너무 많이 변경될 수 있는 경우에만 개체 감지를 추가하세요. 이러한 방법은 경쟁 테스트 프레임워크가 아닌 계층입니다.
- 요구 사항이 통과되었음을 검토자에게 확신시킬 수 있는 증거가 무엇인지 물어보십시오.
- 기본적으로 모든 픽셀을 비교하는 대신 가장 좁고 신뢰할 수 있는 신호를 선택합니다.
- 화면을 관찰하기 전에 안정화한 다음 어설션이 실패하면 아티팩트를 저장합니다.
Android 시각적 테스트 방법 비교
| 방법 | 다음에 가장 적합 | 주요 약점 | 유용한 증거 |
|---|---|---|---|
| UI 또는 접근성 상태 | 컨트롤, 라벨, 활성화된 상태, 선택, 탐색 구조 | 사용자 정의 렌더링되거나 액세스할 수 없는 요소는 UI 트리에 표시되지 않을 수 있습니다. | UI 계층 구조, 선택한 속성, 스크린샷 |
| 스크린샷 또는 골든 이미지 | 레이아웃, 간격, 색상, 타이포그래피, 구성 요소 모양 | 동적 데이터, 애니메이션, 장치 차이 및 렌더링 변경으로 인해 시끄러운 차이가 발생할 수 있습니다. | 현재 이미지, 승인된 기준선, 시각적 차이 |
| OCR | 표시되는 텍스트, 현지화, 영수증, 상태 메시지, 픽셀로 렌더링된 값 | 인식 품질은 자르기, 크기, 대비, 언어 데이터, 회전 및 분할에 따라 달라집니다. | 소스 자르기, 인식된 텍스트, 신뢰도 또는 결과 목록 |
| 템플릿 매칭 | 알려진 아이콘, 버튼, 배지, 썸네일 또는 작은 안정 영역 | 테마, 크기, 압축 및 재설계로 인해 템플릿이 무효화될 수 있습니다. | 템플릿, 검색 지역, 최적 일치, 점수, 스크린샷 |
| 객체 감지 | 위치나 크기가 변하더라도 클래스가 의미를 유지하는 시각적 객체 | 호환 가능한 모델, 레이블이 지정된 클래스, 임계값 및 모델 검증이 필요합니다. | 모델 버전, 클래스, 박스, 점수, 스크린샷 |
Android의 공식 스크린샷 테스트 지침에서는 현재 렌더링을 승인된 참조 이미지와 비교하는 방법을 설명합니다. Appium의 이미지 플러그인은 기능 일치, 템플릿 일치 및 유사성 비교를 제공합니다. OpenCV는 이미지 위로 템플릿을 슬라이드하는 메커니즘을 문서화하고, Tesseract는 OCR 전처리 및 페이지 분할이 중요한 이유를 문서화합니다. 도구는 다르지만 테스트 설계 질문은 동일하게 유지됩니다. 이 요구 사항을 입증하는 관찰은 무엇입니까?
네 가지 질문으로 올바른 주장을 선택하세요.
1. 요구사항이 의미적인가요, 아니면 시각적인가요?
테스트에 "제출 버튼이 활성화되었습니다"라고 표시되면 먼저 UI 상태를 검사하세요. "글꼴 변경 후 제출 버튼이 잘리지 않습니다."라는 메시지가 표시되면 스크린샷을 사용하거나 집중적인 시각적 검사를 사용하세요. 의미론적 쿼리는 일반적으로 유지 관리가 더 쉽지만 모양을 증명할 수는 없습니다.
2. 정확한 텍스트가 중요합니까?
사용자에게 표시되는 문자열이 요구 사항이고 텍스트가 UI 트리를 통해 안정적으로 노출되지 않는 경우 OCR을 사용하세요. 의미 있는 가장 작은 영역으로 인식을 제한하고 올바른 언어를 선택한 후 정규화된 결과를 비교합니다. 올바른 OCR 문자열만으로는 잘림, 겹침 또는 낮은 대비를 표시할 수 없으므로 스크린샷을 보관하세요.
3. 안정적인 시각적 타겟이 하나 있나요?
알려진 아이콘이나 작은 컨트롤에 대해 템플릿 일치를 사용합니다. 템플릿을 촘촘하게 자르고, 관심 영역 내부를 검색하고, 실제 양성 샘플과 음성 샘플에서 임계값을 설정하세요. 테마, 해상도, 압축된 원격 스트림 전반에 걸쳐 하나의 범용 임계값을 방어하는 경우는 거의 없습니다.
4. 전체 구성이 일관성을 유지해야 합니까?
많은 요소 간의 관계가 중요한 경우 스크린샷 비교를 사용하세요. 글꼴, 로캘, 장치 구성, 시스템 표시줄, 시간, 네트워크 데이터, 애니메이션 및 시드된 콘텐츠를 제어합니다. 이러한 입력을 제어할 수 없는 경우 영구적으로 노이즈가 있는 테스트를 수용하는 대신 동적 영역을 마스크하거나 자르십시오.
유용하게 실패하는 시각적 테스트 구축
- 승인된 장치 또는 에뮬레이터에서 앱을 명명된 시작 상태로 전환합니다.
- 고정된 지연이 아닌 안정적인 상태를 기다리세요. UI Automator는 안정성 대기를 제공하며 앱별 준비 신호는 더욱 좋습니다.
- 필요한 증거가 포함된 가장 작은 소스 영역을 캡처합니다.
- 하나의 기본 어설션(UI 상태, OCR, 템플릿, 감지 또는 스크린샷 비교)을 실행합니다.
- 다음 작업을 수행하기 전에 소스 이미지와 구조화된 결과를 저장하세요.
- 실패하면 중지하거나 검토된 복구 경로를 따르십시오. 단순히 테스트를 계속 진행하기 위해 근처에 있는 유사 항목을 탭하지 마십시오.
전환을 승인하면 시각적 확인이 더 안전해집니다. 현재 상태를 관찰하고, 어설션을 하고, 성공 후에만 허용되는 작업을 수행하고, 사후 조건을 확인합니다. 이는이미지 인식 자동 클릭 가이드에 설명된 것과 동일한 설계 원칙입니다. 인식은 워크플로가 완료되었다는 증거가 아닙니다.
실제 장치 작업의 경우 모바일 앱 테스트를 위한Android 화면 미러링는 테스트가 설계되는 동안 검토자에게 실시간 보기를 제공합니다.Android 자동화 QA 연기 테스트 가이드에서는 반복 검사 범위를 좁히고 재현 가능하게 유지하는 방법을 설명합니다.
세 가지 실용적인 Android 시각적 테스트 시나리오
결제 화면의 현지화 QA
UI 상태를 사용하여 결제 화면으로 이동하고, OCR을 사용하여 현지화된 합계 및 작업 라벨을 확인하고, 초점을 맞춘 스크린샷을 사용하여 문자열이 잘리거나 겹치지 않음을 보여줍니다. 제어된 테스트 데이터로 각 로케일을 실행합니다. 전체 화면 픽셀 비교만으로는 변환된 문자열 길이에 너무 민감하지만 OCR만으로는 레이아웃 손상을 놓치게 됩니다.
새롭게 디자인된 도구 모음 아이콘 확인
작은 도구 모음 영역에서 허용되는 아이콘에 대한 템플릿을 사용하십시오. 밝은 테마와 어두운 테마가 모두 지원되는 경우 별도의 템플릿을 유지하세요. 일치가 실패하면 도구 모음 자르기와 최고 후보 점수를 첨부하세요. 아이콘을 의도적으로 다시 디자인한 경우 모양이 통과할 때까지 임계값을 낮추기보다는 템플릿을 검토하고 교체하세요.
배포 후 실제 전화 연기 테스트
알려진 계정 및 앱 상태에서 시작하여 랜딩 화면을 기다리고, ID를 확인하고, 허용된 작업 하나를 수행하고, 다음 명명된 상태를 확인합니다. 모든 실패에 대해 스크린샷을 캡처하세요. 장치 밀도, 권한 대화 상자, 키보드, 알림 및 시스템 업데이트는 실제 전화 환경의 일부이므로 테스트에서는 이를 숨기는 대신 보고해야 합니다.
일반적인 허위 오류 및 이를 방지하는 방법
| 증상 | 가능한 원인 | 더 나은 응답 |
|---|---|---|
| 스크린샷 차이는 실행될 때마다 변경됩니다. | 시계, 애니메이션, 광고, 시드 데이터, 키보드, 시스템 표시줄 또는 네트워크 콘텐츠 | 입력을 고정하고, 안정성을 기다리며, 동적 영역만 자르거나 마스킹합니다. |
| OCR은 그럴듯하지만 잘못된 텍스트를 반환합니다. | 잘못된 언어, 낮은 대비, 작은 자르기, 회전, 노이즈 또는 부적절한 분할 | 작물을 저장하고, 규모와 대비를 개선하고, 언어와 분할을 의도적으로 선택하세요. |
| 템플릿 일치는 하나의 휴대폰에서만 작동합니다. | 다양한 밀도, 테마, 배율, 종횡비 또는 압축 | 지원되는 시각적 변형에 관심 영역과 검증된 템플릿을 사용하세요. |
| 올바른 이미지를 찾았으나 탭이 실패함 | 일치 좌표가 현재 화면이나 오버레이 블록 입력으로 변환되지 않았습니다. | 인식과 동작을 분리하고 다음 상태를 확인합니다. |
| 잘못된 화면에서 테스트가 계속됩니다. | 사후 조건이나 실패 가장자리 없음 | 예상 상태에 이름을 지정하고 현재 화면이 검토된 경로를 벗어나면 중지합니다. |
| 개체 감지기가 잘못된 클래스를 찾습니다. | 모델 또는 라벨이 앱 도메인에 맞지 않아 임계값이 검증되지 않았습니다. | 호환 모델 사용, 버전 및 점수 기록, 음성 샘플 테스트 |
Android 회귀 테스트에 대한 커뮤니티 토론은 종종 동일한 유지 관리 비용(기기 매트릭스, 불안정한 타이밍, 기준 검토 및 콘텐츠가 변경되는 화면)으로 돌아갑니다. 이것이 시각적 테스트를 포기할 이유는 아닙니다. 이는 테스트 환경, 허용된 차이 및 실패 아티팩트를 명시적으로 만드는 이유입니다.
LaiCai Flow가 시각적 테스트에 적합한 방법
LaiCai Flow는 LaiCai Screen Mirroring 내부의 자동화 기능입니다. 흐름은 스크린샷 캡처, UI 확인, OCR, 템플릿 일치, 개체 감지, 조건, 작업 및 명시적인 성공 또는 실패 전환을 결합할 수 있습니다. 이를 통해 테스터는 인식을 고립된 트릭으로 처리하는 대신 화면을 상태로 모델링할 수 있습니다.
LaiCai Flow Inside를 사용하면 배포 후 전화기에서 LaiCai Android Agent를 통해 호환되는 프로필을 실행할 수 있습니다. 호환성은 여전히 해당 프로필에서 사용되는 모든 노드와 자산에 따라 다릅니다. 로컬 OCR은 Tesseract를 사용합니다. 템플릿 일치는 선택한 이미지 자산과 구성 가능한 점수를 사용합니다. 호환되는 로컬 감지는 지원되는 모델을 사용합니다. 네트워크 노드 또는 원격 모델에는 여전히 자체 네트워크 종속성이 필요합니다.
이것이 모든 시각적 테스트를 자동으로 신뢰할 수 있게 만드는 것은 아닙니다. 팀에는 여전히 대표 기준선, 템플릿, OCR 영역, 모델, 임계값, 부정적인 사례 및 사후 조건이 필요합니다. 중요한 점은 이러한 결정과 전환을 하나의 워크플로에서 검토할 수 있다는 것입니다.AI Android 자동화 가이드는 작성 및 실제 장치 실행에 대한 더 넓은 관점을 제공합니다.
실패한 시각적 테스트에 대한 최소 증거 번들
- 테스트 이름, 앱 빌드, 기기 모델, Android 버전, 로케일, 테마 및 방향.
- 어설션에서 사용되는 소스 스크린샷 또는 잘린 영역입니다.
- 예상되는 기준선, 템플릿, 텍스트, 클래스 또는 UI 속성입니다.
- 관찰된 diff, OCR 결과, 경계 상자, 일치 점수 또는 UI 값입니다.
- 이전에 명명된 상태, 시도한 작업, 예상되는 다음 상태 및 중지 이유입니다.
- 검토자가 결정을 재현할 수 있는 자산, 모델 또는 기준 버전입니다.
이 컨텍스트가 없는 통과/실패 레이블은 다음 사람이 전체 실행을 재현하도록 강제합니다. 컴팩트 증거 번들은 실패를 검토 가능한 결정으로 전환합니다. 즉, 제품 수정, 테스트 안정화, 승인된 시각적 자산 업데이트 또는 지원되지 않는 장치 구성 거부 등이 가능합니다.
Android 시각적 테스트 FAQ
모든 Android UI 테스트에 스크린샷이 포함되어야 하나요?
아니요. 외관이 중요하거나 오류 아티팩트가 검토자에게 도움이 될 경우 스크린샷을 사용하세요. 의미론적 어설션은 일반적으로 UI 트리가 안정적으로 표시하는 동작에 더 좋습니다.
OCR이 이미지 매칭보다 나은가요?
OCR은 보이는 텍스트에 대한 질문에 답합니다. 이미지 매칭은 알려진 시각적 패턴에 대한 질문에 답합니다. 요구 사항에 라벨과 모양이 모두 포함되어 있는 경우 OCR과 함께 집중 스크린샷 또는 템플릿 확인을 사용하세요.
실제 Android 휴대폰에서 스크린샷 테스트를 실행할 수 있나요?
예, 하지만 실제 장치는 제어되는 호스트 측 렌더러 또는 에뮬레이터보다 더 많은 변형을 제공합니다. 장치 구성을 기록하고, 시스템 UI와 데이터를 안정화하고, 실제로 지원하는 장치 매트릭스에 대한 기대치를 설정합니다.
언제 객체 감지를 사용해야 합니까?
의미 있는 개체 클래스가 안정적인 템플릿의 허용 범위를 넘어 이동하거나 확장되는 경우, 그리고 호환 모델이 앱의 실제 이미지에서 검증된 경우에만 사용하세요. 단지 더 발전된 것 같다고 해서 탐지기를 추가하지 마세요.
기술을 선택하기 전에 증거를 선택하세요
신뢰할 수 있는 Android 시각적 테스트는 검토자가 무엇을 증명할 수 있어야 하는가라는 한 문장으로 시작됩니다. 의미 체계를 위한 UI 상태, 구성을 위한 스크린샷, 텍스트를 위한 OCR, 알려진 시각적 대상을 위한 템플릿 일치, 가변 지오메트리가 있는 검증된 클래스를 위한 개체 감지를 선택합니다.
그런 다음 관찰을 상태 전환의 일부로 만듭니다. 즉, 안정화, 캡처, 주장, 성공 후에만 실행, 사후 조건 확인, 실패 증거 보존 등을 수행합니다. 이러한 디자인은 연결이 끊긴 비전 통화 모음보다 이해하기 쉽고, 앱이나 장치가 변경될 때 유지 관리가 훨씬 쉽습니다.