Тестування продуктивності мобільного додатка

⚡ Розумний підсумок

Тестування продуктивності мобільних додатків вимірює, як швидко запускається додаток, скільки заряду батареї та пам'яті він споживає, як швидко реагують його API та наскільки коректно він поводиться в ненадійних мережах.

  • 🔘 Три категорії: Продуктивність пристрою, продуктивність сервера або API та продуктивність мережі разом покривають усі вузькі місця мобільних пристроїв.
  • ☑️ Сигнали пристрою: Час запуску, розряд батареї, споживання пам'яті, варіації обладнання та відновлення у фоновому режимі – це основні перевірки пристрою.
  • Сигнали сервера: Розмір корисного навантаження, кількість викликів API на дію та документований план відновлення на випадок простою сервера.
  • 🧪 Мережеві сигнали: Джиттер, втрата пакетів та зміни швидкості повинні створювати чітке повідомлення, а не завислий екран.
  • 🛠️ інструменти: RobotiumТут з'являються , MonkeyRunner та Automator, хоча перші два більше не підтримуються.
  • 📊 Готовність: Контрольний список, що охоплює оперативну пам'ять, час відгуку, паралельність та стійкість до збоїв, визначає, чи буде збірка відправлена.

Тестування продуктивності мобільних додатків на рівнях пристрою, сервера та мережі

Для будь-якого мобільного додатку продуктивність є дуже важливою. Якщо ваш мобільний додаток працює погано, кінцевий користувач видалить його та знайде інший додаток, який працює краще.

Вашу програму для мобільних пристроїв потрібно ретельно протестувати, перш ніж випускати її для кінцевого користувача.

Стратегія тестування мобільних додатків

Продуктивність програми на мобільному телефоні чи будь-якому смарт-пристрої зазвичай вимірюється за такими трьома категоріями.

  • Продуктивність пристрою
  • Продуктивність сервера/API
  • Продуктивність мережі

На діаграмі нижче ці три шари зіставлені з їхніми перевірками.

Діаграма стратегії тестування мобільних додатків, що розділяє перевірки продуктивності пристроїв, серверів та мережі

Продуктивність пристрою

Коли клієнт відчуває повільну роботу програми, він дратується.

Щодо продуктивності пристрою, вам слід перевірити наступне:

  • Запуск програми: Скільки часу потрібно для запуску програми? Це перший параметр продуктивності, який оцінює користувач. Як правило, після того, як користувач торкнеться значка програми, перший екран має відобразитися через 1-2 секунди.
  • Час роботи акумулятора під час використання програми: За постійного використання деякі мобільні програми споживають багато часу від акумулятора та нагрівають телефон. Зазвичай це трапляється, коли ваша програма використовує більше ресурсів, ніж потрібно, що створює навантаження на процесор.
  • Споживання пам'яті: Коли Тестування програмою, необхідно перевірити споживання пам’яті програмою. Реалізація певних функцій у додатку також збільшує споживання пам’яті. Наприклад, в Android програми, коли реалізовано push-сповіщення, споживання пам’яті збільшується.

    У деяких випадках спостерігалося, що використання пам’яті всією ОС становить лише 14%, але нова програма споживає 11%. Таким чином, ці фактори повинні бути розглянуті перед розгортанням програми в реальному світі або наданням клієнту.

  • Варіація апаратного/програмного забезпечення: Під час тестування мобільного додатку обов’язково перевіряйте додатки на різних пристроях. Можливо, програма працює безперебійно на одному пристрої, але не працює на іншому. Як для різних постачальників Android пристроїв, ми можемо перевірити додаток на телефонах Samsung, HTC і Lenovo. Подібним чином програму потрібно протестувати з різними специфікаціями оперативної пам’яті та процесора, наприклад 1 ГБ або 2 ГБ.
  • Використання з іншими програмами: Коли програма, що тестується, працює паралельно з іншими програмами, перешкод бути не повинно. Найкращий спосіб перевірити це, помінявши програму, що тестується, на інші програми.
  • Додаток у фоновому режимі: Коли програма, що працює у фоновому режимі, отримується, вона повинна залишатися в тому ж стані, що й раніше. Якщо цей сценарій не обробити належним чином, дані будуть втрачені. Пов’язані випадки життєвого циклу розглянуті в тестування переривань.

Продуктивність сервера/API

Коли програма взаємодіє із сервером через API, час відгуку стає критично важливим для продуктивності. Щодо продуктивності сервера, вам слід перевірити:

  • Дані на сервер і з сервера: Додаток повинен ефективно обробляти дані, що надсилаються із сервера. Завантаження даних не повинно займати забагато часу. У деяких додатках дані надсилаються у певному форматі, тому перед відображенням у додатку їх слід конвертувати у відповідний формат. У цьому процесі додатки іноді працюють повільніше, а час відгуку збільшується.
  • Виклики API, згенеровані з програми: Кількість викликів від тестованого додатка до сервера, згенерованого додатком, має бути меншою. У деяких випадках для однієї функції виконується кілька викликів API. Для кращої продуктивності це слід обробляти меншою кількістю викликів.
  • Час простою сервера: З будь-якої причини, якщо сервер не працює або недоступний, ми можемо зберігати дані у власній базі даних. Отже, щоразу, коли сервер не працює, ми можемо відображати дані, що зберігаються у власній базі даних. Іншим рішенням можуть бути резервні сервери баз даних, тобто якщо один із серверів не працює або перебуває на етапі технічного обслуговування, резервний сервер повинен бути доступним для перемикання. Резервний сервер/сервер повинен постійно реплікуватися та синхронізуватися з основним сервером.

Продуктивність мережі

Потрібно виміряти продуктивність програми в різних мережах і властивості мережі.

Щоб перевірити продуктивність мережі, перевірте наступне.

  • Тремтіння: Коли є затримка в отриманні інформації в мережі, це називається тремтінням. Це проблема з мережами без підключення або мережами з комутацією пакетів. Оскільки інформація розподіляється в пакети, пакети можуть подорожувати різними шляхами від відправника до одержувача. Коли дані надходять у зазначене місце, вони стають зашифрованими, ніж були надіслані спочатку. У випадку тремтіння мобільний додаток має бути достатньо спроможним, щоб впоратися з ним.

    Вам потрібно показати кінцевому користувачеві відповідні сповіщення, щоб він або повторно надіслав запит, або зачекав, поки система знову відповість.

  • Втрата пакетів: У разі повної втрати пакета програма повинна мати можливість повторно надіслати запит на інформацію або створити відповідні сповіщення. Якщо дані неповні, користувач не зможе зрозуміти інформацію, яка відображається в додатку. Це може бути стресом для користувача. Тому краще відобразити відповідне повідомлення або запропонувати користувачеві повторити спробу.
  • Швидкість мережі: Додаток потрібно перевірити в різних мережах зі змінною швидкістю. Додаток слід протестувати в мережах 3G, 4G та 5G. Це стосується як Wi-Fi, так і мобільних мереж. Також слід контролювати поведінку програми, особливо коли обидві мережі доступні, і відбувається перемикання з однієї мережі на іншу.

    Наприклад, у застосунку може виникнути проблема у користувачів під час перемикання телефонної мережі з 4G на Wi-Fi і навпаки. У цьому випадку застосунок перестає реагувати, і для використання може знадобитися його перезавантажити.

Усунення несправностей продуктивності мобільних додатків

Після виявлення питань/проблем у той час Тестування продуктивностіНастав час tracе та виправити недоліки.

Проблема 1) Затримка або повільна відповідь мобільного додатка.

Причиною цієї затримки може бути оперативна пам'ять, кеш-пам'ять тощо.

Потрібно вбити непотрібні процеси або очистити кеш. Усунення проблеми з підключенням може вирішити деякі проблеми, які створюють затримки

Проблема 2) Додаток перезавантажується, блокується, зависає або не відповідає.

Це можна виправити, виконавши деякі з наступних кроків

  • Оптимізація програмних кодів
  • Програмне забезпечення має бути виправлено та оновлено.
  • Автоматичне відновлення
  • Керування оперативною пам’яттю або, в деяких випадках, ПЗП під час використання зовнішніх карт
  • Wiping розділення кешу
  • Перевірка роботи програми з іншими сторонніми програмами та API
  • картаping мобільний додаток відповідно до пристрою

Корисні інструменти тестування мобільних додатків

Інструменти тестування мобільних додатків відрізняються залежно від пристроїв або мобільних ОС. Деякі поширені інструменти тестування продуктивності мобільних додатків

ANDROID

  • Robotium Це просто як Selenium для мобільних додатків. Тестер може записати та відтворити кілька кроків, необхідних для проведення тестування.
  • Мавпа бігун MonkeyRunner може запускати тести на реальних пристроях, підключених до ПК або емуляторів. Інструмент має API, що дозволяє керувати смартфоном, планшетом або емулятором ззовні Android Код.

⚠️ Примітка до версії: обидві Android записи є застарілими. Robotium не випускався з 2016 року, і Google позначає MonkeyRunner як непідтримуваний, вказуючи на команди щодо UI Automator та його uiautomatorviewer інспектор замість цього.

APPLE

  • Автоматизатор (Mac) Automator — це програма, розроблена компанією Apple для macOSВін реалізує створення робочих процесів методом «вкажи та клацни» (або перетягуванням) для автоматизації повторюваних завдань у пакети для швидшого внесення змін. Це економить час і зусилля порівняно з втручанням людини для ручної зміни кожного файлу окремо.

Виклики

Основні проблеми, з якими стикаються під час тестування продуктивності, включають

  • Організація різних мобільних платформ і їх операційних систем
  • Моделювання підключень, таких як 3G, 4G, 5G або Wi-Fi тощо.
  • Обмеження для мобільних пристроїв, як-от акумулятор і споживання ресурсів
  • Зручність використання мобільного телефону
  • Мобільні пристрої різних розмірів для запуску однієї програми

Налаштуйте середовище тестування продуктивності мобільного додатка

Щоб налаштувати тестове середовище, вам потрібно:

  • Розуміння мобільного додатку, який необхідно протестувати
  • Ідентифікація різних ОС, на яких програма має працювати
  • Побудова тестової установки
  • Створюйте емулятори або симулятори
  • Прототіping фактичного налаштування
  • Вибір відповідного інструменту для тестування

Контрольний список тестування продуктивності мобільних додатків

Тестування продуктивності мобільних додатків є важливим заходом перед випуском. Тестування продуктивності проводиться для перевірки

  • Скільки оперативної пам’яті потрібно для використання цієї програми?
  • Щоб перевірити швидкість і час відгуку APP за різних мереж і обставин.
  • Забезпечте реалістичну взаємодію з користувачем за кількох умов мережі
  • Переконайтеся, що необхідні результати досягнуті у випадку кількох підключень
  • Переконайтеся, що програма не виходить з ладу.
  • Переконайтеся, що мобільні програми працюють добре під час використання даних, Wi-Fi або іншого підключення
  • Відстеження часу безвідмовної роботи та вузьких місць у використанні мобільного API
  • Для забезпечення максимальної кількості одночасних користувачів
  • Нарешті, щоб перевірити мобільний додаток на його межі

Поширені запитання

Менше двох секунд на пристрої середнього класу – це звичайна ціль, що відповідає правилу, зазначеному вище. Вимірюйте 95-й процентиль, а не середнє значення, оскільки повільні пристрої переважають серед реальних скарг.

ANR – це подія «Застосунок не відповідає», яка виникає, коли Android блоки головного потоку. Коефіцієнт без збоїв – це частка сеансів, що завершилися без збоїв. Google Play знижує пріоритетність програм, які перевищують опубліковані пороги для будь-якого з них.

Шістдесят кадрів на секунду – це базова кількість для прокручування та анімації, а новіші дисплеї орієнтовані на дев'яносто або вище. Пропущені кадри, які називаються «брудними», зчитуються як низька якість, навіть якщо нічого не відбувається збоїв.

Машинне навчання визначає базові показники для кожної моделі пристрою, тому регресія позначається відносно подібного обладнання, а не одного глобального числа. Вона також кластеризує повільні traces, ранжуючи, яке вузьке місце впливає на найбільше сесій.

Copilot добре розробляє повторювані каркаси, такі як скелет сценарію завантаження або цикл, який фіксує зразки пам'яті. Пороги та вибір пристрою відображають ваш продукт, тому перегляньте кожне згенероване твердження, перш ніж довіряти йому.

Використовуйте обидва. Емулятори забезпечують дешеві, повторювані мережеві та API-запуски всередині конвеєра. Потрібні реальні пристрої для розрядки батареї, теплового дроселювання та поведінки, специфічної для постачальника, яку емулятори не можуть точно відтворити.

JMeter є поширеним вибором з відкритим кодом для обробки одночасних запитів на тих самих кінцевих точках, які використовує програма. Він вимірює пропускну здатність сервера, яку інструменти на стороні пристрою ніколи не бачать.

Зафіксоване обмеження часу запуску, пам'яті або розміру пакета, яке збірка перевіряє автоматично. Перевищення цього обмеження призводить до невдалого завершення збірки, тому регресії фіксуються під час злиття, а не після випуску.

Підсумуйте цей пост за допомогою: