모바일 앱 성능 테스트

⚡ 스마트 요약

모바일 앱 성능 테스트는 애플리케이션의 시작 속도, 배터리 및 메모리 사용량, API 응답 속도, 그리고 불안정한 네트워크 환경에서의 원활한 작동 여부를 측정합니다.

  • 🔘 세 가지 범주: 기기 성능, 서버 또는 API 성능, 네트워크 성능을 모두 합치면 모든 모바일 병목 현상을 해결할 수 있습니다.
  • ☑️ 장치 신호: 시작 시간, 배터리 소모량, 메모리 사용량, 하드웨어 차이 및 백그라운드 복원은 핵심적인 장치 점검 사항입니다.
  • 서버 신호: 페이로드 크기, 작업당 API 호출 횟수, 그리고 서버 다운타임에 대비한 문서화된 장애 조치 계획이 필요합니다.
  • 🧪 네트워크 신호: 지터, 패킷 손실 및 속도 변화는 모두 화면이 멈추는 것이 아니라 명확한 메시지를 전달해야 합니다.
  • 🛠️ 압형: RobotiumMonkeyRunner와 Automator가 여기에 나타나지만, 앞의 두 프로그램은 더 이상 유지 관리되지 않습니다.
  • 📊 준비: RAM, 응답 시간, 동시성 및 크래시 저항성을 포함하는 체크리스트를 통해 빌드 배포 여부가 결정됩니다.

기기, 서버 및 네트워크 계층 전반에 걸친 모바일 앱 성능 테스트

모바일 앱에 있어 성능은 매우 중요합니다. 모바일 앱의 성능이 좋지 않으면 사용자는 앱을 삭제하고 성능이 더 나은 다른 앱을 찾을 것입니다.

모바일 애플리케이션을 최종 사용자에게 출시하기 전에 철저히 테스트해야 합니다.

모바일 애플리케이션 테스트 전략

휴대전화나 스마트 기기의 애플리케이션 성능은 일반적으로 다음 세 가지 범주로 측정됩니다.

  • 장치 성능
  • 서버/API 성능
  • 네트워크 성능

아래 다이어그램은 세 가지 계층을 각각의 점검 항목과 연결합니다.

모바일 애플리케이션 테스트 전략 차트: 기기, 서버 및 네트워크 성능 검사 분리

장치 성능

클라이언트가 앱 속도가 느리다고 느끼면 짜증이 납니다.

기기 성능 확인을 위해 다음 사항을 점검하십시오.

  • 앱 스타트업: 앱을 시작하는 데 시간이 얼마나 걸리나요? 이는 사용자가 판단하는 첫 번째 성능 매개변수입니다. 경험상 사용자가 앱 아이콘을 탭한 후 첫 번째 화면은 1~2초 내에 표시되어야 합니다.
  • 앱 사용 중 배터리 사용 시간: 일부 모바일 앱은 지속적으로 사용하면 배터리 소모가 심하고 휴대전화가 과열될 수 있습니다. 이는 일반적으로 앱이 필요 이상으로 많은 리소스를 사용하여 프로세서에 부담을 줄 때 발생합니다.
  • 메모리 소비: 인셀덤 공식 판매점인 지원 앱을 사용하는 경우 해당 앱의 메모리 사용량을 확인해야 합니다. 앱에 특정 기능을 구현하면 메모리 소비도 늘어납니다. 예를 들어, Android 푸시 알림이 구현되면 앱에서 메모리 소비가 증가합니다.

    어떤 경우에는 전체 OS의 메모리 사용량이 14%에 불과한데, 새로운 앱이 11%를 소비하는 것으로 관찰되었습니다. 따라서 앱을 실제 세계에 배포하거나 고객에게 제공하기 전에 이러한 요소를 처리해야 합니다.

  • 하드웨어/소프트웨어 변형: 모바일 앱을 테스트할 때는 다양한 기기의 앱을 확인하는 것이 필수입니다. 앱이 한 기기에서는 원활하게 실행되지만 다른 기기에서는 원활하게 실행되지 않는 경우가 있을 수 있습니다. 다른 공급업체와 마찬가지로 Android 장치에서는 Samsung, HTC 및 Lenovo 휴대폰에서 앱을 확인할 수 있습니다. 마찬가지로 앱은 1GB 또는 2GB와 같은 다양한 RAM 및 프로세서 사양을 사용하여 테스트해야 합니다.
  • 다른 앱과의 연동 사용법: 테스트 중인 앱이 다른 앱과 병렬로 실행될 때 간섭이 없어야 합니다. 이를 확인하는 가장 좋은 방법은 테스트 중인 앱과 다른 앱을 전환하는 것입니다.
  • 앱이 백그라운드에서 실행 중입니다. 백그라운드에서 실행 중인 앱을 다시 불러올 때, 앱은 이전 상태 그대로 유지되어야 합니다. 이 시나리오를 제대로 처리하지 못하면 데이터가 손실될 수 있습니다. 관련 라이프사이클 사례는 다음에서 다룹니다. 인터럽트 테스트.

서버/API 성능

앱이 API를 통해 서버와 상호 작용할 때 응답 시간은 성능에 매우 중요합니다. 서버 성능을 확인하려면 다음 사항을 점검하십시오.

  • 서버와의 데이터 송수신: 앱은 서버에서 전송되는 데이터를 효율적으로 처리해야 합니다. 데이터 로딩 시간이 너무 오래 걸려서는 안 됩니다. 일부 앱에서는 데이터가 특정 형식으로 전송되므로 앱에 표시하기 전에 해당 형식으로 변환해야 합니다. 이 과정에서 앱 속도가 느려지고 응답 시간이 길어지는 경우가 있습니다.
  • 앱에서 생성된 API 호출: 테스트 대상 앱에서 앱에서 생성된 서버로 호출되는 횟수가 적어야 합니다. 어떤 경우에는 동일한 기능에 대해 여러 API 호출이 이루어집니다. 더 나은 성능을 위해서는 더 적은 수의 호출로 처리해야 합니다.
  • 서버 점검 시간: 어떤 이유로든 서버가 다운되거나 접속할 수 없는 경우, 데이터를 기본 데이터베이스에 저장할 수 있습니다. 따라서 서버가 다운되더라도 기본 데이터베이스에 저장된 데이터를 표시할 수 있습니다. 또 다른 해결책으로는 장애 조치 데이터베이스 서버를 사용하는 것입니다. 즉, 서버 중 하나가 다운되거나 유지 보수 단계에 있는 경우 백업 서버가 즉시 작동할 수 있도록 해야 합니다. 장애 조치/백업 서버는 기본 서버와 지속적으로 복제 및 동기화되어야 합니다.

네트워크 성능

다양한 네트워크 및 네트워크 속성에서 앱의 성능을 측정해야 합니다.

네트워크 성능을 위해 다음 사항을 확인하세요.

  • 신경 과민: 네트워크에서 정보 수신이 지연되는 경우를 지터라고 합니다. 비연결형 네트워크나 패킷 교환 네트워크의 문제입니다. 정보가 패킷으로 분산되므로 패킷은 보낸 사람에서 받는 사람까지 서로 다른 경로를 통해 이동할 수 있습니다. 데이터가 의도한 위치에 도착하면 원래 전송된 것보다 뒤섞인 상태가 됩니다. Jitters의 경우 모바일 앱이 이를 처리할 수 있을 만큼 충분히 능력이 있어야 합니다.

    최종 사용자에게 요청을 다시 보내거나 시스템 응답을 기다리도록 안내하는 등 적절한 알림을 표시해야 합니다.

  • 패킷 손실 : 패킷이 완전히 손실된 경우 앱은 정보에 대한 요청을 다시 보내거나 그에 따라 알림을 생성해야 합니다. 데이터가 완전하지 않으면 사용자는 앱에 표시된 정보를 이해할 수 없습니다. 이는 사용자에게 스트레스가 될 수 있습니다. 따라서 적절한 메시지를 표시하거나 사용자에게 다시 시도하도록 촉구하는 것이 좋습니다.
  • 네트워크 속도: 앱은 속도가 다양한 여러 네트워크 환경에서 테스트해야 합니다. 3G, 4G, 5G 네트워크에서 모두 테스트해야 하며, Wi-Fi와 모바일 네트워크도 포함됩니다. 특히 두 네트워크가 모두 사용 가능한 경우와 네트워크 전환 시 앱의 동작을 면밀히 모니터링해야 합니다.

    예를 들어, 사용자가 휴대전화 네트워크를 4G에서 Wi-Fi로 또는 그 반대로 전환할 때 앱에서 문제가 발생할 수 있습니다. 이 경우 앱이 응답하지 않게 되며, 사용하려면 앱을 다시 시작해야 할 수 있습니다.

모바일 애플리케이션 성능 문제 해결

문제/문제를 발견한 후 성능 시험이제는 ~할 때입니다 trac오류를 수정합니다.

문제 1) 모바일 앱의 반응이 느리거나 느려집니다.

이 지연의 원인은 RAM, 캐시 등일 수 있습니다.

불필요한 프로세스를 종료하거나 캐시를 지워야 합니다. 연결 문제를 해결하면 지연을 발생시키는 일부 문제를 해결할 수 있습니다.

문제 2) 앱이 다시 시작되거나, 잠기거나, 정지되거나 응답이 없습니다.

다음 단계 중 일부를 수행하면 해결될 수 있습니다.

  • 애플리케이션 코드 최적화
  • 소프트웨어를 패치하고 업데이트해야 합니다.
  • 자동 복원
  • 외부 카드를 사용하는 동안 RAM 또는 경우에 따라 ROM 관리
  • Wiping 캐시 파티셔닝
  • 앱이 다른 타사 앱 및 API와 제대로 연동되는지 확인합니다.
  • 지도ping 기기에 따른 모바일 애플리케이션

유용한 모바일 앱 테스트 도구

모바일 앱 테스트 도구 기기나 모바일 OS에 따라 다릅니다. 몇 가지 일반적인 모바일 앱 성능 테스트 도구는 다음과 같습니다.

기계적 인조 인간

  • Robotium 마치 Selenium 모바일 앱용. 테스터는 테스트를 수행하는 데 필요한 여러 단계를 기록하고 재생할 수 있습니다.
  • 원숭이 주자 MonkeyRunner는 PC나 에뮬레이터에 연결된 실제 장치에서 테스트를 실행할 수 있습니다. 이 도구에는 외부에서 스마트폰, 태블릿 또는 에뮬레이터를 제어할 수 있는 API가 있습니다. Android 암호.

⚠️ 버전 참고: 모두 Android 항목들은 기존 항목입니다. Robotium 2016년 이후로는 발매된 음반이 없습니다. Google MonkeyRunner는 더 이상 유지보수되지 않으며, UI Automator 및 그 유사 도구를 사용하도록 안내합니다. uiautomator뷰어 대신 검사관.

APPLE

  • 자동화 기 (Mac) Automator는 Apple에서 개발한 애플리케이션입니다. macOS이 도구는 포인트 앤 클릭(또는 드래그 앤 드롭) 방식으로 워크플로우를 생성하여 반복적인 작업을 일괄 처리 방식으로 자동화하고 더 빠르게 수정할 수 있도록 지원합니다. 이를 통해 사람이 각 파일을 수동으로 개별적으로 수정하는 데 드는 시간과 노력을 절약할 수 있습니다.

도전

성능 테스트 중 직면하게 되는 주요 과제는 다음과 같습니다.

  • 다양한 모바일 플랫폼과 해당 운영 체제 구성
  • 3G, 4G, 5G 또는 Wi-Fi 등과 같은 연결성을 시뮬레이션합니다.
  • 배터리 및 리소스 소비와 같은 모바일 장치 제약
  • 휴대폰 사용성
  • 동일한 앱을 실행하기 위한 다양한 크기의 모바일 장치

모바일 앱 성능 테스트 환경 설정

테스트 환경을 구성하려면 다음을 수행해야 합니다.

  • 테스트가 필요한 모바일 앱에 대한 이해
  • 앱을 실행해야 하는 다양한 OS 식별
  • 테스트 설정 구축
  • 에뮬레이터 또는 시뮬레이터 빌드
  • 프로토타입ping 실제 설정의
  • 테스트에 적합한 도구 선택

모바일 앱 성능 테스트 체크리스트

모바일 앱의 성능을 테스트하는 것은 출시 전 중요한 척도입니다. 확인하기 위해 성능 테스트가 수행됩니다.

  • 이 앱을 활용하려면 RAM이 얼마나 필요합니까?
  • 다양한 네트워크 및 상황에서 APP의 속도와 응답 시간을 확인합니다.
  • 다양한 네트워크 조건에서 현실적인 사용자 경험 보장
  • 다중 연결의 경우 필요한 결과가 달성되는지 확인하십시오.
  • 응용 프로그램이 충돌하지 않는지 확인하십시오.
  • 데이터, Wi-Fi 또는 기타 연결을 사용하는 동안 모바일 애플리케이션이 제대로 작동하는지 확인
  • 가동 시간 및 모바일 API 사용 병목 현상 모니터링
  • 동시사용자의 최대 수를 확보하기 위해
  • 마지막으로 모바일 앱의 한계를 확인하려면

자주 묻는 질문

중급 기기에서 2초 미만이 일반적인 목표이며, 이는 위에서 언급한 규칙과 일치합니다. 실제 불만 사항은 느린 기기에서 더 많이 발생하므로 평균값보다는 95번째 백분위수를 측정하는 것이 좋습니다.

ANR은 애플리케이션이 응답하지 않을 때 발생하는 이벤트입니다. Android 메인 스레드가 차단됩니다. 충돌 없는 종료율은 충돌 없이 종료된 세션의 비율입니다. Google Play 스토어는 게시된 임계값을 초과하는 앱의 우선순위를 낮춥니다.

스크롤 및 애니메이션의 기본 프레임 속도는 초당 60프레임이며, 최신 디스플레이는 90프레임 이상을 목표로 합니다. 프레임이 끊기는 현상(일명 렉)은 화면에 아무런 오류가 없더라도 화질이 저하된 것처럼 보이게 합니다.

머신 러닝은 각 기기 모델별로 모든 지표의 기준선을 설정하므로, 회귀 분석 결과는 단일 전체 수치가 아닌 유사한 하드웨어를 기준으로 표시됩니다. 또한 클러스터링 속도가 느립니다. trac즉, 어떤 병목 현상이 가장 많은 세션에 영향을 미치는지 순위를 매기는 것입니다.

Copilot은 로드 스크립트 골격이나 메모리 샘플을 캡처하는 루프와 같은 반복적인 구조를 잘 작성합니다. 임계값 및 장치 선택은 제품의 특성을 반영해야 하므로 생성된 모든 어설션을 검토한 후에 신뢰해야 합니다.

둘 다 사용하세요. 에뮬레이터는 파이프라인 내에서 저렴하고 반복 가능한 네트워크 및 API 실행을 제공합니다. 하지만 배터리 소모, 발열로 인한 성능 저하, 그리고 제조사별 동작과 같은 요소들을 제대로 재현하려면 실제 기기가 필요합니다. 에뮬레이터는 이러한 요소들을 완벽하게 재현할 수 없습니다.

JMeter 이는 애플리케이션이 사용하는 동일한 엔드포인트에서 동시 요청을 제어하는 ​​데 일반적으로 사용되는 오픈 소스 도구입니다. 이 도구는 장치 측 도구에서는 볼 수 없는 서버 용량을 측정합니다.

빌드 과정에서 자동으로 확인하는 시작 시간, 메모리 또는 번들 크기에 대한 제한값입니다. 이 제한값을 초과하면 빌드가 실패하므로, 릴리스 후가 아닌 병합 시점에 회귀 오류를 발견할 수 있습니다.

이 게시물을 요약하면 다음과 같습니다.