모바일 UI 테스트 자습서 (iOS 및 Android 앱의 GUI 테스트)

mobile ui testing tutorial gui testing ios

모바일 앱 UI 테스트 가이드 : iOS 및 Android UI 테스트 수행 방법 알아보기

모바일 시장이 번창하면서 모바일 애플리케이션 테스트는 날로 흥미 진진 해졌습니다.

레지스트리 오류를 수정하는 가장 좋은 프로그램

모바일 애플리케이션에서 기능 테스트를 실행하는 것만으로는 앱에서 사인 오프 할 수 없습니다. 현장 테스트, 네트워크 테스트, UI 테스트, 배터리 수명 테스트 등과 같이 수행해야하는 다른 테스트 유형은 거의 없습니다.

UI 테스트는 모바일 애플리케이션 테스트에서 중요한 테스트 중 하나이며 가볍게 다루어서는 안됩니다.

그래픽 사용자 인터페이스는 사용자가 귀하의 애플리케이션을 얼마나 흥미롭고 대화식으로 찾는 지에 많은 차이를 만듭니다. 괜찮고 매력적인 GUI의 중요성은 노트북이나 데스크톱 화면에 비해 화면 크기가 훨씬 작은 스마트 장치 환경에서 더 크게 느낄 수 있습니다.

학습 내용 :

• 모바일 앱 UI 테스트 중요성
• 얼마나 많은 UI 테스트가 필요한지 결정하는 방법은 무엇입니까?
• 지침 : 모바일 앱 UI 테스트에서 테스트 할 내용
  • # 1) 화면 해상도
  • # 2) 화면 크기
  • # 3) 다른 UI 요소
  • # 4) 스타일 : 장치의 색상 및 테마 구성
  • # 5) 멀티 터치 또는 싱글 터치
  • # 6) 길게 누르기 또는 짧게 누르기
  • # 7) 위치
• 다양한 OS 버전에서 UI 변형을 테스트하는 방법은 무엇입니까?
• 실제 장치 또는 에뮬레이터 : UI 테스트를 위해 무엇을 선택해야합니까?
  • 장점
  • 단점
• 수동 또는 자동화 UI 테스트?
• 모바일 앱 UI 테스트 도구
• 모바일 앱 UI 테스트를위한 체크리스트
• 자동화 된 모바일 UI 테스트에 대한 5 가지 오해
  • 신화 1 : 속도
  • 통념 2 : 범위
  • 통념 3 : 비용
  • 통념 4 : 일관성
  • 오해 5 : 주저
• 신화와 현실
• 결론
• 추천 도서

모바일 앱 UI 테스트 중요성

사용자로서 사용자 상호 작용이 부족하고 사용 방법을 이해하기 어렵게 만드는 앱을 사용하고 싶습니까?

사용자가 처음으로 모바일 애플리케이션을 사용할 때 시선을 사로 잡는 것은 성능뿐 아니라 매력적인 UI입니다. UI 친화적 인 애플리케이션은 가장 잘 개발되었지만 UI가 좋지 않은 앱과 비교할 때 더 많이 판매됩니다.

응용 프로그램이 한 장치에서 완벽하고 멋진 UI를 가지고 있지만 다른 장치에서는 크기가 다르거 나 OS가 다르기 때문에 완전히 뒤틀린 경우 매우 나쁜 인상을 남깁니다. 응용 프로그램의 상업적 성공은 심각한 영향을받습니다.

버튼이 너무 작아서 전체 기능을 차단할 수없는 앱을 홍보 하시겠습니까?

사용자에게 이러한 불쾌한 경험이 아닙니까? 위에서 언급 한 경우로 인해 애플리케이션의 UI를 테스트하는 것이 매우 중요해졌습니다. 모바일 애플리케이션에 대해 수행해야하는 두 가지 주요 검증은 다양한 모델 및 OS 버전에서 사용자 친화 성과 외관입니다.

다음은 다양한 화면 크기에서 UI가 완벽해야하는 방법의 예입니다.

얼마나 많은 UI 테스트가 필요한지 결정하는 방법은 무엇입니까?

다음 차트는 모바일 앱을 분류 할 수있는 다양한 카테고리를 나타냅니다.

(영상 출처 )

위의 차트에서 게임 앱이 약 24.43 %의 시장 점유율에서 대부분을 차지하고 그 다음이 비즈니스 및 교육 앱임을 알 수 있습니다.

• 게임 앱으로 개발 된 앱은 네이티브 앱이든 하이브리드 앱이든 상관없이 성공을 거두는 데 가장 큰 기여를하는 UI이므로 모든 측면에서 철저한 테스트가 필요합니다.
• 대부분의 경우 대상 고객이 앱을 사용하도록 교육을 받았기 때문에 비즈니스 앱은 성공을 위해 UI에 완전히 의존하지 않을 수 있습니다. 따라서 이러한 앱은 간단한 UI를 가질 수 있습니다.
• 교육용으로 개발 된 앱은 철저한 UI 테스트가 필요합니다.
• 쇼핑, 여행 등과 같은 상업용 앱도 기기 및 다양한 OS 버전에서 완전한 UI 테스트가 필요합니다.

간단히 말해, 앱의 목적에 따라 UI 테스트의 깊이를 결정할 수 있지만 UI 테스트는 항상 최소 3 가지 OS 버전에서 수행해야합니다.

지침 : 모바일 앱 UI 테스트에서 테스트 할 내용

모바일 애플리케이션에서 UI를 테스트하는 동안 다양한 특성을 확인해야합니다.

다음은 모든 앱에 대해 테스트해야하는 몇 가지 특성입니다.

#1) 화면 해상도

다음은 테스트 베드를 만드는 동안 고려되는 몇 가지 일반적인 화면 해상도입니다.

• 640 × 480
• 800 × 600
• 1024 × 768
• 1280 × 800
• 1366 년 × 768
• 1400 년 × 900
• 1680 년 × 1050 년

이러한 모든 해상도는 앱에 다중 열 레이아웃이있는 경우 테스트에 필수입니다.

따라서 가장 작은 해상도부터 가장 큰 해상도까지 검증을 수행해야합니다. 이 외에도 앱에 정보가 포함 된 긴 카드 목록이있는 경우 정보 래핑을 위해 다른 해상도에서 테스트해야합니다.

( 이미지 소스 )

# 2) 화면 크기

화면 크기와 사용 가능한 해상도에 너무 많은 변형이 있습니다. 특히 스마트 장치에서 컨트롤 크기는 정적이 아니며 사용 가능한 화면 크기와 관련이 있습니다.

테스트하는 동안 컨트롤 크기가 미적으로 좋고 스크롤없이 화면에서 컨트롤이 완전히 보이는지 확인합니다. 화면 크기와 해상도가 다른 여러 장치에서 GUI를 테스트합니다.

에뮬레이터는 이러한 목적에 적합하지만 실제 장치와 일치하는 것은 없습니다. 따라서 적어도 2 ~ 3 개의 실제 장치에서 테스트해야합니다. 또한 기기에서 지원하는 경우 가로 및 세로 방향에서 테스트하는 것을 잊지 마십시오.

일반적으로 사용되는 해상도로 응용 프로그램을 테스트하여 유용성을 확인해야합니다.

여기서 이해해야 할 몇 가지 사항은 다음과 같습니다.

화면 크기와 해상도의 차이 : 화면 크기는 대각선으로 측정하거나 화면의 한 모서리에서 다른 모서리까지 측정 한 화면 길이입니다. 화면 해상도는 너비와 높이입니다. 예 640w × 480h는 화면을 가로 지르는 픽셀 수에 여러 픽셀을 곱한 값입니다.

# 3) 다른 UI 요소

버튼, 제목, 아이콘, 이미지, 선택 필드, 텍스트 필드, 확인란 등과 같은 UI 요소는 화면에서 모양과 크기를 확인해야하는 여러 요소 중 일부입니다.

특히 텍스트 필드의 경우 소프트 키보드가 텍스트 필드의 탭에 표시되면 테스트 및 확인해야합니다.

가장 중요한 것은 버튼 크기에 대한 철저한 테스트가 필요합니다 .Galaxy S 휴대 전화에서 테스트하는 동안 앱에서 버튼이 클릭하기에 너무 작아서 전체 앱을 차단하는 차단기를 발견했습니다.

UI 요소의 위치도 요구 사항에 따라 확인되어야합니다 (예 : 모두 중앙 정렬 또는 왼쪽 정렬 등).

# 4) 스타일 : 장치의 색상 및 테마 구성

앱 UI 및 색 구성표는 휴대폰의 다른 색 및 테마 구성표와 일치해야합니다. 삼성 폰의 색상과 테마가 노키아 나 MI 폰과 매우 다릅니다. .

따라서 앱이 이러한 휴대폰에서 일관되게 보이는지 확인해야합니다.

애플리케이션에는 특정 디자인이 있습니다. 컨트롤의 스타일은 해당 디자인과 일치해야합니다. 예를 들어 일부 컨트롤이있는 많은 응용 프로그램을 보셨을 것입니다. 패널에는 둥근 모서리와 기타 컨트롤이 있습니다. 텍스트 상자에는 날카로운 모서리가 있습니다.

이러한 유형의 문제는 앱의 유용성 또는 기능에 영향을주지 않지만 애플리케이션의 일관된 모양은 애플리케이션과 사용자 간의 친근한 관계를 구축하는 데 도움이됩니다.

스타일에서 가장 중요한 것 중 하나는 다른 페이지의 글꼴입니다. 응용 프로그램의 모양과 느낌이 일치하지 않도록 글꼴을 잘 테스트해야합니다.

대부분의 경우 우리는 정상적인 상황에서 볼 수있는 텍스트에 초점을 맞추고 특정 상황에서 나타나는 텍스트는 무시합니다. 성공 및 실패 메시지는 이러한 텍스트 유형의 예입니다.

스타일에서 중요한 또 다른 요소는 글꼴 색상과 텍스트가 표시되는 상황 간의 관계입니다.

예를 들면 빨간색은 오류 메시지, 녹색은 성공, 노란색은 경고, 파란색은 하이퍼 링크에 사용됩니다.

# 5) 멀티 터치 또는 싱글 터치

앱이 핀치 투 줌 또는 핀치 투 축소 등과 같은 멀티 터치 기능을 지원하는 경우이 기능을 철저히 테스트하고 적용 가능한 모든 화면에 대해 많은 테스트 사례를 만들어야합니다.

# 6) 길게 누르기 또는 짧게 누르기

아이콘을 길게 누르면 컨텍스트 메뉴가 표시되고 짧은 터치는 메뉴의 첫 번째 작업을 수행합니다. 이 기능이 앱에 제공되는 경우이 기능과 그와 관련된 모든 기능을 확인해야합니다.

# 7) 위치

위치와 위치는 번갈아 사용되는 두 단어이며 흥미롭게도 아래에 설명 된 두 가지 다른 개념을 전달하는 데 더 많이 사용됩니다.

1) 때로는 컨트롤이 나타나는 화면 영역입니다.

예를 들면 헤더는 상단 페이지의 레이블은 왼쪽 정렬 , 텍스트 상자는 오른쪽 정렬, 여기에서‘상단’,‘왼쪽 맞춤’,‘오른쪽 맞춤’은 컨트롤의 상대적 위치입니다.

두) 때로는 다른 컨트롤 간의 컨트롤 순서입니다.

예를 들면 개인 정보를 얻는 동안 이름은 팔로우 성으로. 또는 미국 주소를 요청하는 컨트롤 형식은 주문 – 우편 번호,시, 주.

이 두 가지 상황에서 우리는 컨트롤의 위치에 대해 이야기하고 있습니다.

컨트롤의 위치와 위치를 테스트하는 동안 모든 것이 논리적으로 화면에 배치되고 미적 감각이 좋은지 확인하십시오.

둘 이상의 화면에 하나 이상의 컨트롤이 나타나는 상황이 있습니다. 이 상황에서는 모든 페이지에서 동일한 위치와 동일한 상대 순서에 표시되는지 확인해야합니다.

다양한 OS 버전에서 UI 변형을 테스트하는 방법은 무엇입니까?

UI는 OS 버전에 따라 다르며 새 버전이 출시되면 UI가 향상됩니다.

현재 사용 가능한 최신 OS 3 개의 UI를 살펴보고 이러한 변형이 모바일 애플리케이션에 미치는 영향을 이해해 보겠습니다.

그들은:

1. 사탕 과자
2. 마시멜로
3. 누가

위의 새로운 UI 또는 기능 기능 목록을 살펴보면 QA로이를 중심으로 테스트 케이스를 설계해야합니다.

1) 롤리팝 :

• 새로운 디자인이 앱에 미치는 영향에 대한 테스트 케이스를 만듭니다.
• 모든 화면에 반드시 필요한 것은 아니지만 앱의 새 바로 가기에 액세스하기위한 테스트 사례를 만듭니다.

2) 마시멜로 :

• 앱에서 이모티콘을 다루는 경우 테스트 케이스를 만들어 새 이모티콘을 확인합니다. 사용자가 리뷰를 작성하거나 채팅을 할 수있는 앱은 이모티콘을 자주 사용하는 앱입니다.
• 앱이 처음으로 게시되고 설치되면 권한을 요청해야 할 수 있으므로 새 권한 화면의 UI 테스트를 수행해야합니다. 그리고 동일한 테스트 케이스를 만듭니다.
• 앱에서 Google Now를 사용하는 경우 업데이트 된 Google Now 기능의 UI를 테스트하기위한 테스트 사례를 만들어야합니다.

3) 누가 :

• Daydream 현실 모드에 대해 앱의 철저한 테스트를 수행해야하므로 그에 따라 테스트 사례를 만들어야합니다.
• 앱의 메뉴 옵션을 확인하는 테스트 케이스를 만듭니다.
• 앱이 이모 지와 GIF를 다루는 경우 테스트 케이스를 만들어 새 이모 지와 GIF 전송 옵션을 확인합니다.

실제 장치 또는 에뮬레이터 : UI 테스트를 위해 무엇을 선택해야합니까?

모바일 애플리케이션을 테스트해야 할 때 테스트 베드가 무엇인지 생각할 수 있습니까?

실제 장치 또는 에뮬레이터 또는 둘 다에서 테스트 할 것인지 여부 선택은 테스트하려는 항목에 따라 다르기 때문에 이에 대한 확실한 대답은 없습니다.

기능, 성능, 네트워크 응답, 현장 테스트 등을 테스트하려면 항상 실제 장치를 선호해야합니다. 그러나 UI와 같은 경우 일부 실제 장치와 함께 에뮬레이터를 선택해야합니다.

장점

UI 테스트에 에뮬레이터를 사용하는 장점은 다음과 같습니다.

1) 모든 해상도의 장치를 수집하는 것은 실질적으로 불가능하며 엄청난 비용이들 것입니다. 그러나 에뮬레이터는 비용이 들지 않습니다.
두) 에뮬레이터를 사용하면 모든 화면 해상도와 OS 조합을 만들 수 있습니다.
삼) 실제 기기 세트가 하나만 있지만 QA 팀이 2 명 이상인 경우 모든 QA가 동일한 테스트 베드를 동시에 테스트 할 수 없습니다. 에뮬레이터를 사용하면 모든 QA가 컴퓨터에서 동일한 조합을 만들고 병렬로 테스트 할 수 있습니다.
4) 에뮬레이터에서 테스트하는 것은 시간이 덜 걸리고 실제 장치와 비교할 때 더 빠릅니다.
5) 정렬 등과 ​​같은 UI와 관련된 일반적인 버그는 에뮬레이터에서 쉽게 잡힐 수 있습니다.

Linux가 Windows보다 빠른 이유

단점

단점은 다음과 같습니다.

1) 제스처는 에뮬레이터에서 테스트 할 수 없습니다. 한 번에 하나의 제스처 만 에뮬레이션 할 수 있습니다.
두) GPS의 물리적 입력, 네트워크 끊김 또는 약한 네트워크 등도 테스트 할 수 없습니다.
삼) Sony, LG, Nexus 등의 휴대폰 용 에뮬레이터를 만들 수있는 방법은 없습니다.
4) 에뮬레이터에서 배터리 부족 또는 메모리 부족 등의 실제 환경을 만드는 것은 불가능합니다.

따라서 앱과 테스트 요구 사항에 따라 결정을 내려야합니다.

수동 또는 자동화 UI 테스트?

데스크톱 앱이든 웹 앱이든 모바일 앱이든 테스트 없이는 제품을 출시 할 수 없습니다. QA로서 모든 결함을 찾아보고하는 데 어려움을 겪고 있지만 여전히 고객이보고합니다.

그 이유를 아십니까?

종종 피하거나 놓치는 긴 테스트 때문에 발견되지 않은 버그가 남습니다. 또한 100 % 커버리지, 수동 테스트로는 심층 실행이 불가능합니다.

UI 테스트는 매우 간단하고 간단하며 눈에 어떻게 보이는지 살펴보기 만하면됩니다. 이제이 작업을 수동으로 수행하면 시간이 많이 걸립니다. 또한 스크롤과 같은 UI 테스트를 위해 방대한 데이터를 생성해야하는 대부분의 경우 카드 행이 특정 개수를 초과하는 경우에만 나타납니다.

빅 데이터를 만드는 데는 시간이 많이 걸립니다. 자동화 된 제품군을 사용하면 두 가지 문제를 모두 해결할 수 있습니다.

반대로 앱의 기능이나 UI가 여전히 변화하는 단계에있는 경우 자동화에 투자하는 것은 의미가 없습니다. 마찬가지로 앱의 기능이 중요하다면 수동으로 테스트하는 것이 좋습니다.

따라서 다음 포인터에 따라 수동으로 테스트할지 자동화할지 결정해야합니다.

• 앱의 특성.
• 앱의 안정성.
• 도구를 연구하고 비교하는 인력과 같은 사용 가능한 리소스.
• 필요한 자동화 도구를 연구하고 강화하는 데 얼마나 많은 시간이 투자됩니까?
• 고객이 램프 업 및 연구에 시간을 투자 할 준비가되어 있습니까?

모바일 앱 UI 테스트 도구

다음은 Android 및 / 또는 iOS 용 모바일 애플리케이션의 UI 테스트에 사용할 수있는 5 가지 도구 목록입니다.

(기능 테스트 도구 y 자동화에 대한 자동화 도구 목록을 참조 할 수 있습니다. Android 애플리케이션 테스트 도구 페이지).

# 1) 셀렌 드로이드

Selendroid는 UI 테스트를위한 모바일 애플리케이션 자동화에 가장 권장되는 최고의 도구 중 하나입니다.

네이티브 및 하이브리드 앱 모두에 사용할 수 있습니다. Android 앱에서만 사용할 수 있으며 클라이언트 API 테스트는 Selendroid 2를 사용하여 작성되었습니다. 또한 둘 이상의 장치에서 사용할 수 있으며 JSON과 완벽하게 호환됩니다.

# 2) 테스트 드로이드

이것은 클라우드 기반 도구이며 다양한 장치, 다양한 화면 해상도 및 Android 및 iOS의 OS 버전에 사용할 수 있습니다. 병렬 장치 테스트는이 도구의 큰 장점이며 UI 테스트를위한 좋은 도구입니다. 개발자가 출시 시간을 단축하는 데 도움이됩니다.

# 3) SeeTest

유료 도구이며 Android, iOS, Windows, Symbian 등에서 사용할 수 있습니다.

크로스 플랫폼 도구이므로 모든 플랫폼에서 동일한 테스트를 실행할 수 있다는 장점이 있습니다. 모든 모바일 애플리케이션에 사용할 수 있으며 테스트는 둘 이상의 장치에서 병렬로 실행할 수 있습니다.

# 4) UI 자동화

이것은 Apple의 공식 UI 테스트 도구이며 iOS 애플리케이션 자동화를위한 최고의 도구입니다. 배우기는 어렵지만 라이브러리, 성능, UI 테스트 등에서 큰 이점을 제공합니다.

# 5) 호리병박

네이티브 또는 하이브리드 앱에 대한 Android 및 iOS 테스트 모두에 사용할 수 있습니다. 크로스 플랫폼 도구이며 제스처, 스크린 샷, 어설 션 등을 자동화하는 데 가장 적합합니다. 실제 터치 스크린 장치에서 사용할 수 있습니다. 그것은 또한 오이를 지원합니다.

개발자가 앱을 단위 테스트 할 때 Android Studio를 사용하여 UI 테스트를 수행 할 수도 있지만 Android 애플리케이션에만 사용할 수 있습니다.

추천 자료 => 사용자 인터페이스 테스트 자동화

모바일 앱 UI 테스트를위한 체크리스트

다음은 GUI가 스마트 장치에서 완벽하게 테스트되었는지 확인하기위한 테스터를위한 체크리스트입니다.

자동화 된 모바일 UI 테스트에 대한 5 가지 오해

자동화 된 모바일 UI 테스트는 애플리케이션 성공에 대한 질문이 발생할 때 매우 중요한 것으로 간주됩니다. 그러나 자동화 된 테스트와 관련된 몇 가지 신화가 있습니다.

그러한 신화는 피상적 일 수 있기 때문에 사실이 아닐 수 있습니다. 자동화 된 테스트 프로세스를 자세히 살펴보면 사라집니다. 더 깊이 파헤쳐 보겠습니다.

신화 1 : 속도

이 신화는 매우 일반적입니다. IT 산업과 관련된 대부분의 사람들은 '수동 테스트'에 비해 '자동화 테스트'를 수행하는 데 더 많은 시간이 걸린다는 신화를 가지고 있습니다. 이 사실은 몇 가지 시나리오에서 어느 정도 사실입니다.

그 이유는 자동 모바일 UI 테스트와 비교할 때 수동 테스트가 빠른 결과를 생성하기 때문입니다. 그러나 이것은 예비 및 초기 단계에서만 해당됩니다.

반복되는 종류의 테스트에서는 더 많은 테스트 기능을 추가하거나 테스트 품질을 떨어 뜨려야합니다. 자동 테스트를 사용하면 항상 비슷한 테스트 수준을 항상 실행하므로 장기적으로 시간을 절약 할 수 있습니다.

통념 2 : 범위

현재 시나리오에서는 새로운 Android 기기가 정기적으로 시장에 출시됩니다. 그리고 그러한 운영 체제 (OS)의 앱 수가 증가하고 있습니다. 그런 다음 매일 사용하도록 만들어진 더 많은 앱이있는 iOS와 같은 운영 체제가 있습니다.

너무 많은 앱에 대한 수동 테스트가 매우 어려워집니다. 그러나 자동화 된 테스트의 경우 클라우드 서버의 유지 관리로 충분합니다. 자동화 된 테스트의 도움으로 앱의 전체 및 전체 테스트 범위가 가능합니다.

통념 3 : 비용

앱의 자동 테스트 비용이 수동 테스트 비용에 비해 더 비싸다는 것은 사실입니다. 그러나 이는 앱의 기본 요소에 대한 테스트가 수행되는 경우에만 해당됩니다. 앱의 환경과 소프트웨어가 복잡 해짐에 따라 수동 테스트는 더 많은 비용이 듭니다.

이는 최적의 테스트 결과를 위해 더 정교한 도구가 필요하기 때문입니다. 이러한 정교한 테스트 도구와 함께 이러한 도구를 관리 할 수있는 고도로 훈련 된 직원이 필요합니다. 이를 위해서는 훈련이 필요합니다.

따라서 수동 테스트는 자동화 된 테스트와 비교할 때 비용이 많이 듭니다.

통념 4 : 일관성

수동 테스트의 경우, 테스터마다 다른 인식을위한 여지가 항상 있습니다. 이는 또한 운영 체제 (OS)와 함께 고려되는 테스트, 환경 및 앱에 따라 다릅니다.

소프트웨어에 수동 테스트를 적용 할 때 몇 가지 버그가 통과 할 수있는 구멍이 있습니다. 따라서 수동 테스트는 기본적인 버그를 감지하는 데만 유용합니다. 자동화 된 테스트는 다양한 인식에 대한 여지없이 스크립트에서 실행되어 오류를 방지합니다.

오해 5 : 주저

자동 테스트가 인간을 대체 한 것은 사실이 아니라 수동 테스터의 개선을위한 것입니다. 자동화 된 테스트는 최대 정확도로 여러 번 반복적으로 자동화 된 결과를 제공합니다. 그래서 질문이 생깁니다. 왜 인간이 필요합니까?

자동화 된 테스트에는 스크립트 작성과 전체 테스트 절차 계획이 필요합니다. 이 작업에는 인간의 노력이 필요합니다. 자동 테스트 절차는 수동 테스트 절차를 개선하기 위해 이러한 리소스를 활용할 수 있도록 시간과 비용을 절약하는 데 도움이됩니다. 더 나은 도구의 개발은 기존의 자동화 된 테스트 절차를 발전시키는 데 도움이 될 것입니다.

위에서 언급 한 내용은 자동화 테스트 업계에서 널리 퍼져있는 가장 널리 알려진 신화 중 일부입니다. 자동화 된 모바일 UI 테스트의 개선을 위해이를 근절해야합니다.

신화와 현실

사실 가장 정교한 개발 회사조차도 모바일에 대해 수동 테스트를 사용하거나 완전한 테스트를 전혀 수행하지 않습니다. Xamarin 2014 설문 조사에 따르면 모바일 개발자의 13.2 %가 자동화 된 UI 테스트를 수행합니다. Forrester Research의 연구에 따르면 개발자의 53 %만이 단일 장치에서 간단한 테스트를 수행합니다.

모바일 팀이 모바일 앱의 품질을 자동화하지 않은 이유에 대한 가장 일반적인 5 가지 요소와 이것이 실제로 의미가없는 5 가지 이유는 다음과 같습니다.

a) 속도는 첫 번째 신화입니다.

사람은 자동화에 시간을 할애 할 수 없습니다. 2014 년에 공급 업체는 7000 개의 새로운 Android 장치 유형을 도입했습니다. 그런 다음 모바일 전용 API가 10,000 개였습니다. 모바일 응용 프로그램은 더 빨리 배송되고 빠르게 수정됩니다. 지속적인 크 런칭 모드에서 품질 보증 (QA)을 사용하면 테스트 스크립트를 생성하여 정기적으로 변경되는 기능과 동기화 상태를 유지할 시간이 없습니다.

첫 번째 신화의 실제 시나리오 :

하나는 현재 소중한 시간을 낭비하고 있습니다. 그것은 매우 사실입니다. 수동 테스트는 자동화 테스트보다 빠릅니다. 그러나 이것은 첫 번째 테스트 실행입니다. 후속 실행에서 수동 테스트로 인한 한계 이점이 무엇이든 침식으로 이어집니다. 이것은 거의 즉시입니다. 모든 반복 테스트 실행 또는 기능 추가와 함께 앱 개발자는 테스트 범위 또는 추가 테스트 리소스를 축소해야합니다.

한정된 예산 책정과 함께 이것은 궁극적으로 감소하는 품질의 악순환으로 이어집니다. 테스트되지 않은 기기 사용자에 대한 데이터 참여와 부정적인 리뷰에 대응하여 팀은 기기의 범위를 확대하기를 원합니다. 이는 이미 역량으로 QA 부서에 대한 스트레스를 더욱 증가시킵니다.

비즈니스가 테스트 실행을 수행하는 동안 장치를 유지 관리, 연구 및 조달하기 위해 고군분투하는 것입니다. 최고의 자금을 지원하는 UI 수동 테스트 프로그램조차도 완성 된 범위로 단축됩니다.

미국에서 모바일 팀은 마케팅 점유율을 100 % 차지하기 위해 188 개의 장치에서 테스트해야합니다. 2014 년 Xamarin 연구에 따르면 대부분의 개발 팀은 25 개 이하의 기기에서 자주 테스트합니다.

이러한 개발자 커뮤니티의 1/4 이상이 5 개 이하의 장치를 대상으로합니다. 실제 테스트 상황에서 자동화는 거의 즉각적이고 즉각적인 성과를 거두었습니다. 첫 번째 테스트 실행에서 소비자가 테스트 일정을 4 배까지 가속화하는 것으로 나타났습니다. 50 대 또는 그 이상의 장치에 대해 실행하는 경우 전체 수동 테스트가 끝났습니다.

하위 시퀀스에있는 실행이 훨씬 빨라졌습니다. 그러나 거의 전체 테스트 주 동안 몇 시간 만 사용하는 것으로 단축됩니다.

b) 보장은 두 번째 신화입니다.

조각화는 기기의 범위를 넓힐 가능성이없는 원인입니다. 19000 개 이상의 고유 한 Android 기기와 iOS 용 운영 체제 및 요소를 형성하기위한 수십 개의 순열과 함께 많은 팀은 제공된 시장에서 대부분의 기기를 다룰 수 없다고 생각합니다.

따라서 이러한 장치 중 소수에 대한 기본 테스트가 충분합니다.

두 번째 신화의 현실 :

하나는 장치의 적용 범위를 완료했을 수 있습니다. 사람들이 사내에서 소수의 장치를 유지하는 경우 많은 일을하고 있습니다. 장치 조달이 어렵습니다.

돈, 비용 및 시간을 차례로 유지하여 테스터가 필요할 때 언제 어디서나 사용할 수있게하면 물류 문제가 발생합니다. Gartner는 모바일 개발자가 플랫폼의 속도와 변화의 확산을 따라 잡기 위해 높은 자동화 속도를 달성 할 수있는 방법을 찾아야한다고 언급했습니다. 이것은 호스팅에있었습니다. 다른 기능은 내부 관리를 사용했습니다.

이러한 자동화의 경로는 타사의 클라우드 서비스를 통해 이루어집니다. 타사 클라우드 서비스는 앱 로딩 프로세스 자동화, 스크립트 실행 테스트, 결과보고 및 공장 표준에 대한 장치 재설정을 안전하게 지원합니다. 앱 테스트의 하위 집합이 병렬로 실행되므로 결과가 빨라집니다.

다양한 실제 장치에서 테스트하는 동안 테스트 클라우드를 사용하면 팀원 모두가 앱이 어떻게 작동하는지 정확하게 알 수 있으므로 모바일 개발의 일반적인 추측을 제거 할 수 있습니다.

예: 제품 관리자는 장치 성능에서 정당화되는 확신과 함께 시스템 요구 사항을 더 적게 설정합니다. 개발자는 최신 빌드를 약속하기 전에 버그 수정에 대한 시각적 객관적인 확인을받습니다. 이것은 그들이 작동하는 장소와시기와 관계가 없습니다.

c) 비용은 세 번째 신화입니다.

개인은 수동 테스트 만 감당할 수 있습니다. 자동화 테스트에는 테스트 스크립트 생성, QA 직원을위한 학습 곡선 및 인프라가 필요합니다. 많은 팀이 이미 마감일을 맞추기 위해 고군분투하고 있습니다. 그들은 이미 예산을 초과했습니다. 따라서 자동화 테스트는 먼 거리에있는 것 같습니다.

세 번째 신화에 대한 실제 시나리오 :

수동 테스트는 사람들이 보장을 희생하는 경우에만 비용을 절약합니다. 수동 테스트는 베어 본 대부분의 환경에서만 비용이 적게 드는 것 같습니다.

테스트의 경우 더 적은 수의 장치의 기본 기능에 대한 빠른 '직감 검사'가 포함 된 경우 수동 테스트는 저렴하게 보입니다. 그러나 포괄적 인 테스트 범위 및 장치와의 유사성은 자동화 테스트보다 수동 테스트를 훨씬 더 비싸게 만듭니다. 이것은 심지어 빠르다.

수동 테스트는 더 많은 사람과 대중의 추가에 의해서만 확장됩니다. 비용에는 진정한 선형성이 없습니다. 수요를 충족하기 위해 직원을 확장하면 조정 및 교육의 형태로 엄청난 오버 헤드가 발생합니다. 따라서 테스트 케이스의 분할은 관점을 제거하여 모든 테스터의 효율성을 감소시킵니다.

또한 사용자 행동을 뛰어 넘어 애플리케이션이 실패 할 수있는 이유를 탐색하고 예상하는 데 충분한 정교함을 갖춘 테스터는 많거나 저렴하지 않을 수 있습니다. 자동화 테스트에는 항상 초기 설정시 약간 더 많은 오버 헤드가 필요합니다.

그러나 위에서 언급했듯이 테스트 속도에서 극적으로 이익과 이익을 얻을 수 있습니다. 또한 이틀 이내에 해당 직원을 줄입니다. 클라우드 기반 테스트 환경은 비용을 더욱 절감했습니다. 이는 활용도가 낮고 값 비싼 온 프레미스 테스트 인프라를 제거하기 때문입니다.

d) 일관성은 네 번째 신화입니다.

수행, 실행 및 운영하기에 충분해야합니다. 다양한 테스트 팀의 경우 준비된 배포는 다양한 수동 테스터의 인식에 기반한 주관적인 결정입니다. 그들은 의미가 버그가 균열을 통해 떨어지는 것과 관련이 있다는 것을 알고 있습니다.

겹치는 테스트 범위는 릴리스 전에 가장 일반적이고 중요한 문제를 파악해야합니다. 나머지 버그는 유지 관리 릴리스를 기다립니다.

네 번째 신화의 실제 시나리오 :

자질은 질적이지 않습니다. 제작 준비는 의견의 요소 나 문제가되어서는 안됩니다. 순수한 수동 테스트 환경에서 인식은 테스트마다 다르고 테스터마다 다릅니다. 이로 인해 테스트 결과가 불규칙하고 문서가 일관되지 않습니다.

제품의 준비 상태를 고려하면 결정이 복잡해집니다. 규정 준수 실패, 대중의 환멸, 수익 손실로 이어집니다. 또한 사람과 직원이 문 밖으로 나갈 때 잃어 버리는 부족의 포착되지 않은 이해의 주머니가 생성됩니다.

그러면 자동화는 정량화 가능한 메트릭을 생성합니다. 이것은 비즈니스 결정의 정당성, 제품의 준비 상태 및 차트 팀의 진행에 관한 결정을 알리는 진실의 객관적인 소스 역할을합니다.

e) 꺼리는 것은 다섯 번째 신화입니다.

수동 테스트는 자동화 테스트로 대체되었습니다. 많은 개발자들이 수동 테스터를 기계로 대체 할 것으로 기대하기 때문에 테스트 자동화에 진입했습니다.

테스트 자동화가 100 % 정확도로 유사한 테스트를 1000 번 반복하는 경우 테스트 목적으로 사람이 필요한 이유에 대한 질문이 발생합니다. 테스트 스크립트의 자동화는 기계에서도 수행 할 수 있습니다.

0과 1 사이의 난수 c ++

다섯 번째 신화의 실시간 그림 :

수동 테스터는 자동화 테스트를 통해 향상됩니다. 기계와 인간은 다양한 사물과 요인에서 좋은 시나리오를 가지고 있습니다. 수동 테스트를 수행하는 테스터는 항상 더 창의적으로 테스트 할 수 있습니다.

자동화 테스트는 이러한 작업에서 해방됩니다. 인간은 앱을 파괴하는 새로운 방법을 기대하지만 자동화는 광범위한 장치에서 규정 준수를 보장합니다. 이것은 단위 테스트에서 전체 회귀 테스트까지입니다. 두 가지 접근 방식을 따로 분리 할 필요는 없습니다.

백엔드 시스템이 자동화 된 테스트의 부하를받지 않는 동안 탐색 적 수동 테스트를 수행합니다. 이는 프로덕션 환경에서 발생하는 오류를 발견하는 훌륭한 방법입니다. 자동화 테스트는 인간 테스터를 대체하지 않습니다. 이를 통해 보람 있고 흥미로운 작업을 수행 할 수 있습니다.

더 나은 일관성, 적용 범위, 비용 및 속도는 개선 된 품질에 추가됩니다. 비용과 시간을 절약하면 더 많은 테스트를 수행 할 수 있습니다. 이것은 중요한 이정표에 도달하는 경우입니다. 이를 통해 테스트는 길을 잃지 않고 애자일 개발 팀과 보조를 맞출 수 있습니다.

따라서 조직은 코드를 훨씬 더 자주 릴리스합니다. 이는 영향을 줄이고 빌드에 제공된 결함의 양을 줄입니다. 이것은 개발자가 깨끗한 코드로 작업한다는 것을 의미합니다. 버그 수정은 훨씬 덜 복잡합니다. 이것은 창의성에 초점을 맞춘 게이트 키퍼 역할을하는 유일한 테스터를 통해 테스터를 해방시킵니다. 따라서 탐색 적 테스트는 제품의 품질을 향상시킵니다.

모바일 UI의 자동화 테스트는 시간과 품질에 관한 이점을 제공합니다. 자동화 된 도구를 사용하면 테스터가 광범위한 모바일 장치를 통해 앱의 사용자 인터페이스를 쉽게 평가할 수 있으며 사용자 경험을 쉽게 향상시킬 수 있도록 수정을 수행 할 수 있습니다.

결론

나쁜 GUI는 사용자에게 불쾌한 경험입니다. GUI 테스트는 화면 크기가 비교적 작고 시장에서 다양한 장치를 사용할 수 있기 때문에 특히 스마트 장치와 관련하여 매우 권장되고 중요합니다.

애플리케이션은 기기마다 다르게 보이고 작동 할 수 있습니다. 따라서 최소한 몇 가지 표준 크기와 다양한 기기에서 앱을 테스트하는 것이 중요합니다.

모든 모바일 애플리케이션에는 UI 테스트가 필요하지만 필요한 테스트의 깊이는 애플리케이션의 범주 또는 목적에 따라 정의됩니다. 테스트 베드를 완성하기 전에 휴대 전화의 모델 또는 OS 버전과 비교하여 애플리케이션의 UI 기능을 완전히 분석해야합니다.

이 분석을 기반으로 테스트 용 테스트 케이스를 작성해야합니다. 가능한 한 자동화를 사용하여 시간을 절약하십시오.

UI는 간단하지만 앱 판매에 큰 영향을 미치므로 테스트하는 동안 눈을 뜨십시오.

다음에 대한 자세한 정보는 다음 튜토리얼을 참조하십시오. 모바일 반응 형 테스트 .

추천 도서

• Android 및 iOS 모바일 앱 테스트를위한 Appium 자습서
• 2021 년 최고의 Android 및 iOS 용 모바일 테스트 도구 TOP 15
• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 모바일 앱 베타 테스트 서비스 (iOS 및 Android 베타 테스트 도구)
• 모바일 테스트가 힘든 이유는 무엇입니까?
• Robotium 시작하기-가장 인기있는 Android 애플리케이션 UI 테스트 도구
• 시험 입문서 eBook 다운로드
• Android 애플리케이션 테스트를위한 11 가지 최고의 자동화 도구 (Android 앱 테스트 도구)