답변.

모바일 애플리케이션의 수동 테스트는 사용자의 행동을 통해 모바일 프로그램이 요구사항에 맞게 작동하는지 확인하는 프로세스입니다.

문제의 역사:

스마트폰의 등장으로 개발 및 테스트의 초점이 데스크톱 및 웹 제품에서 모바일로 이동했습니다. 모바일 기기는 특별한 아키텍처, 제한된 리소스, 변동하는 네트워크, 그리고 인터페이스의 특수한 행동을 가지고 있어, 에뮬레이터뿐만 아니라 실제 기기에서 테스트 요구가 증가했습니다.

문제:

모바일 애플리케이션은 다양한 운영체제 버전, 기기 모델, 화면 해상도 및 인터넷 속도에서 작동합니다. 오류는 종종 한 플랫폼에서 나타나고 다른 플랫폼에서는 나타나지 않습니다. 일부 버그는 멀티터치, 센서, 재시작 또는 앱 간 전환과 관련이 있습니다.

해결책:

테스트는 다음과 같은 단계로 이루어집니다:

기기 준비 및 에뮬레이터/실제 기기 설정.
인터페이스의 비즈니스 논리 및 네트워크 작업 테스트.
Wi-Fi 꺼짐, 전화 수신, 기기 잠금 시의 행동 테스트.
인터페이스의 적응성과 응답성 테스트.
애플리케이션 설치, 삭제 및 업데이트 검증.

주요 특징:

다양한 운영체제와 해상도를 가진 실제 기기에서 테스트해야 합니다.
연결 상태 변화, 호출 및 알림에 대한 행동을 고려해야 합니다.
리소스 의존적인 케이스(GPS, 카메라, 메모리, 배터리)를 포함한 시나리오가 필요합니다.

함정이 있는 질문.

에뮬레이터에서만 테스트할 때 자주 놓치는 버그는 무엇인가요?

배터리, 속도, 센서 문제, 푸시 알림 및 하드웨어 상호작용의 오류는 실제 기기에서만 나타납니다.

구형 운영체제에서 애플리케이션을 테스트하는 것이 왜 중요한가요?

API 지원 및 시스템 기능(권한, 알림)의 행동이 다르기 때문에, 종종 버그는 구형 Android 또는 iOS 버전에서만 나타납니다.

모바일 테스트에서 검증이 데스크톱과 어떻게 다른가요?

모바일 테스트에서는 비표준 시나리오(전화통화, SMS, 네트워크 손실)에 대한 반응을 반드시 검증해야 하며, 이는 데스크톱에서는 필요하지 않습니다.

일반적인 오류 및 안티 패턴

에뮬레이터에서만 테스트.
불안정한 시나리오(배터리 방전, 네트워크 손실)를 무시함.
기기 및 운영체제의 범위가 부족함.

실제 사례

부정적 케이스

iPhone 14와 최신 Android 에뮬레이터에서만 테스트했습니다. 릴리스 후, Android 7 및 Xiaomi 사용자가 푸시 알림 부재 및 전화 복귀 시 정지 문제를 신고했습니다.

장점:

빠른 테스트, 짧은 베타 기간.

단점:

프로덕션에서 많은 치명적인 버그, 고객 손실, 부정적인 리뷰.

긍정적 케이스

10개의 다양한 브랜드와 운영체제 버전의 기기에서 테스트하고, 전화 수신, 인터넷 손실, 카메라 전환의 시나리오를 시도했습니다. 결과적으로, 릴리스 전에 버그가 발견되었고 요구사항이 충족되었습니다.