Мобільні Flutter-додатки очима QA: типові баги, їх пошук та корисні інструменти

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Я Катерина, Senior QA, останні три роки займаюся тестуванням мобільних Flutter-додатків.

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

Чим і збираюся поділитися у цій статті.

Типові баги Flutter-додатків та їх пошук

Flutter дозволяє створювати додатки для iOS та Android з однієї кодової бази, що скорочує час на розробку. Водночас архітектурні особливості Flutter впливають не лише на процес розробки, а й на характер дефектів, які зустрічаються в застосунках. Частково це пов’язано з особливостями Flutter: власною системою віджетів, підходом до рендерингу інтерфейсу та взаємодією з нативними компонентами систем.

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

Розбіжність інтерфейсу з вимогами платформи

Цей тип багів виникає тоді, коли додаток на одній платформі виглядає або поводиться так, ніби він створений для іншої. Наприклад, на iPhone користувач бачить елементи інтерфейсу в стилі Android замість характерних для iOS компонентів.

Де шукати баг

1.Навігація та переходи між екранами

Перевірте коректність роботи кнопки «Назад» на Android та загальну поведінку навігації відповідно до рекомендацій платформи.

2.Заголовки

Зверніть увагу на розташування заголовків. Наприклад, для iOS характерне центрування заголовка, тоді як на Android частіше використовується вирівнювання ліворуч.

3. Діалоги та системні повідомлення

Перевірте зовнішній вигляд кнопок, шрифтів і структуру діалогових вікон. Вони повинні відповідати гайдлайнам платформи.

4. Селектори

Зверніть увагу на вибір дати та часу. Наприклад, для iOS характерний picker у вигляді «барабана», тоді як на Android зазвичай використовується календарна сітка.

5. Елементи керування

Перевірте перемикачі, чекбокси, текстові поля та інші інтерактивні елементи. Вони мають виглядати та поводитися відповідно до рекомендацій платформи.

6. Індикатори завантаження

На iOS і Android використовуються різні стилі індикаторів завантаження. Переконайтеся, що застосунок використовує відповідний варіант.

Ривки та підгальмовування анімації

Для користувача ця проблема зазвичай виглядає як «смикана» анімація, затримки під час переходів між екранами або помітні ривки під час прокручування контенту.

Як шукати баг

1.Перевірка під час запуску

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

2.Скрол «важких» списків

Швидко прокручуйте стрічки з великою кількістю зображень або складних UI-елементів. Звертайте увагу на ривки, підгальмовування та затримки під час завантаження контенту.

Втрата стану

Цей баг проявляється так: користувач заповнює форму, перемикається на іншу вкладку або згортає додаток, а після повернення бачить, що введені дані зникли або були скинуті до значень за замовчуванням.

Як шукати баг

1. Перемикання між вкладками

Заповніть форму частково → перейдіть на іншу вкладку → поверніться назад і перевірте, чи збереглися введені дані.

2. Робота у фоновому режимі

Введіть дані → згорніть додаток → відкрийте інший застосунок → поверніться назад. Переконайтеся, що стан екрана не було втрачено.

Безкінечний скрол

Це можуть бути візуальні «стрибки» списку, дублювання елементів, повторне завантаження тих самих даних або нескінченний індикатор завантаження, який так і не зникає.

Як виявити баг

1.Стресове прокручування списку

Швидко прокручуйте список до моменту появи індикатора завантаження нових даних. У цей момент спробуйте різко прокрутити список у протилежному напрямку.

2.Перевірка на різних об’ємах даних

Тестуйте список як із мінімальною кількістю елементів (1–2 записи), так і з великими наборами даних (1000+ записів). Перевіряйте, чи не дублюються елементи під час підвантаження нових сторінок.

Platform Channel Exception

Ця помилка виникає, коли Flutter не може коректно взаємодіяти з нативною функціональністю платформи (наприклад, камерою, GPS або Bluetooth). У результаті користувач може побачити технічну помилку або додаток може перестати реагувати на дії.

Як виявити баг

1. Перевірка системних дозволів

Забороніть доступ до камери, GPS або інших системних сервісів у налаштуваннях ОС та спробуйте скористатися відповідною функцією в додатку. Замість зависання або крашу користувач має отримати зрозуміле повідомлення.

2. Вимкнення системних функцій

Вимкніть інтернет, Bluetooth або GPS під час активного використання відповідної функції та перевірте, як поводиться додаток.

3. Тестування на реальних пристроях

Такі проблеми часто не проявляються на емуляторах. Тому всі сценарії, пов’язані з нативною функціональністю пристрою, бажано тестувати на реальних девайсах.

Помилка контексту

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

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

Як шукати баг

1.Тестування на повільному інтернеті

Використовуйте емуляцію повільного з’єднання (3G або Edge). Це допоможе знайти ситуації, коли дані ще не отримані від сервера, а UI вже намагається їх відобразити.

2. Monkey Testing

Швидко та хаотично натискайте кнопки й перемикайте екрани. Це дозволяє знайти помилки, коли користувач уже перейшов на інший екран, а асинхронна операція все ще намагається оновити попередній.

Перекриття контенту клавіатурою

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

keyboard overlap bug

Як шукати баг

1.Фокус на нижніх полях

Обов’язково тестуйте введення тексту в полях, що розташовані в нижній частині екрана.

2.Зміна мови клавіатури

Деякі клавіатури (наприклад, із додатковими символами) вищі за стандартні. Перевірте, чи не перекривають вони кнопку відправки форми.

3. Тестування у Landscape Mode

Переверніть телефон горизонтально та відкрийте клавіатуру.

Вихід контенту за межі контейнера

Так звана «зебра» — жовто-чорні смуги та повідомлення про помилку безпосередньо на екрані, які з’являються, коли елемент виходить за межі батьківського контейнера.

overflow error

Як шукати баг

1.Перевірка на малому екрані

Використовуйте найменший доступний пристрій, наприклад, iPhone SE або старі моделі Android.

2. Регулювання розміру шрифту

Установіть максимальний розмір шрифту в налаштуваннях телефону. Flutter-верстка може «розповзатися», якщо текст не поміщається в статичні контейнери.

3. Flutter Inspector та Debug Paint

Використайте Flutter Inspector у DevTools, щоб знайти проблемний елемент у Widget Tree, переглянути його властивості та зрозуміти, який віджет відповідає за переповнення. Додатково можна увімкнути Debug Paint — він візуально підсвічує межі віджетів і допомагає побачити, де саме елемент виходить за межі контейнера.

Оновлення Flutter та бібліотек

Окрему увагу варто приділити оновленню версії Flutter та сторонніх бібліотек.

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

Під час оновлення бібліотек варто уточнити у розробників, який функціонал може бути зачеплений змінами, та провести додаткове тестування саме цих ділянок системи на різних платформах і версіях ОС.

Не забувайте і про специфічні інтеграції. Наприклад, мапа може використовувати різні сервіси на Android та iOS. В ідеалі такі особливості мають бути задокументовані, але на практиці це відбувається не завжди. Тому важливо проговорювати подібні нюанси з розробниками ще на початку роботи над проєктом.

І ще один важливий момент: тестувати варто не лише на iOS та Android загалом, а й на різних версіях операційних систем. Особливо це актуально для Android, де один і той самий функціонал може працювати по-різному залежно від версії ОС або виробника пристрою.

Корисні інструменти для тестування та пошуку багів у Flutter

Знайти баг — це лише половина справи. Не менш важливо швидко зрозуміти причину проблеми та надати розробникам достатньо інформації для її виправлення.

Flutter має власний набір DevTools, який допомагає аналізувати роботу додатка, досліджувати UI, відстежувати мережеві запити та знаходити проблеми з продуктивністю.

Серед інструментів, які можуть стати у нагоді тестувальникам:

Flutter Inspector

Flutter Inspector дозволяє побачити, як Flutter будує дерево віджетів, і швидко зрозуміти, з яких елементів складається екран. За допомогою режиму Select Widget Mode можна натиснути на елемент безпосередньо в додатку та знайти його в Widget Tree і коді. Це корисно під час пошуку UI-проблем: наприклад, коли елемент виходить за межі контейнера, текст обрізається, кнопка має неправильний розмір, відступи між елементами виглядають некоректно або екран ламається на різних розмірах пристроїв.
Також Inspector може стати в нагоді під час роботи з автотестами. Він допомагає швидше знайти потрібний віджет та зрозуміти, як краще звертатися до цього елемента в тестах.

inspector

Network

Network дозволяє відстежувати мережеві запити безпосередньо у Flutter DevTools. У деяких випадках під час роботи з Flutter цього достатньо, щоб не використовувати Fiddler, Charles Proxy чи подібні інструменти: наприклад, коли потрібно швидко перевірити URL, статус відповіді, headers, body запиту та відповіді або час виконання запиту. Водночас Network View не є повноцінною заміною проксі-інструментів, оскільки він більше підходить для перегляду й аналізу трафіку, а не для його зміни. Наприклад, для підміни response усе ще можуть знадобитися Fiddler, Charles Proxy чи аналогічні інструменти.

network view

Logging

Logging можна розглядати як аналог консолі.

Інструментом можна користуватися, щоб переглядати системні логи, повідомлення від print(), помилки фреймворку та події Garbage Collector.

loging tab

Performance View

Використовується для аналізу плавності роботи інтерфейсу.

Інструмент показує час рендерингу та допомагає знаходити так званий jank (ривки та підгальмовування анімацій, про які йшлося вище).

performance tab

CPU Profiler View

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

cpu tab


Flutter і автотести

Окрім інструментів для аналізу та пошуку дефектів, Flutter має власну екосистему для автоматизованого тестування.

Серед основних інструментів — Unit Tests, Widget Tests та Integration Tests.

Використання Flutter Tests для автоматизації Flutter-додатків має низку переваг. Насамперед вони працюють безпосередньо з Flutter Framework, а не лише з тим, що доступне на рівні системного UI або Accessibility Layer. Завдяки цьому можна знаходити потрібні віджети через Flutter finder-и, працювати з Widget Tree, перевіряти стан елементів і точніше тестувати кастомний UI.

Це особливо важливо для Flutter-додатків, де UI складається з кастомних віджетів, анімацій і динамічного оновлення стану.

Мобільні додатки, як правило, взаємодіють не лише з Flutter UI, а й з нативними елементами операційної системи.
Такі кейси можна покрити за допомогою Patrol — фреймворку, побудованого поверх Flutter Integration Tests.

Patrol дозволяє тестувати не лише Flutter UI, а й нативні взаємодії, зокрема системні дозволи, системні діалоги, push-нотифікації, інші сценарії взаємодії з операційною системою.

Але важливий нюанс: можливості можуть відрізнятися між Android та iOS. Наприклад, Android часто дає більше контролю над системними діями, а iOS має більше обмежень через саму ОС.

Висновки

Flutter значно спрощує кросплатформну розробку, але водночас має свої особливості, які важливо враховувати під час тестування.

Чим краще тестувальник розуміє специфіку Flutter-додатків, тим швидше може помічати типові проблеми, локалізувати їх причини та обирати правильні інструменти для перевірки.

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

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Додам про Patrol, маю купу позитивного досвіду з ним. (у порівнянні з Аппіумом)
— Тести фактично раняться на девайсі, назовні сервер лиш слухає за результами проходження. Зовнішній сервер якщо ляже то тести можуть на девайсі продовжити ранитись. Аппіум то навпаки тест виконується ззовні, апіум то HTTP сервак який штрикає апку.
— Patrol огортає всю апку, і можна перед запуском теста всередені задати потрібний стан, або перевіряти стан не через UI а просто подивившись що засетапилось. Через аппіум сетап стану то треба писати файли в ситему і на запуску вони підтянуться. Уявіть що трапиться коли деви почнуть шифрувати дані? Розробники так і зробили, а мої тести навіть того не помітили. На аппіумі то щоб зробити треба шифрування самому робити і ключами ділитися. І коли щось десь оновиться дуже важко те підтримувати.
— Вихід контенту за межу контейнера навіть на 1 піксель = патруль падає з людською помилкою. Аппіумом треба окремо читати десь логи дивитися хто і де падає.
— Скріншоти можливі, хоча і не з коробки тільки треба інтегрувати навколо апки, потім викидати їх з девайса на якому раняться тести.
— Селектори можна через тексти перекладів робити, або додавати власні семантики. По селекторам треба б детальніше розповісти. Вони працюють через Dart машину, а не через UI, тому працюють супер стабільно. Буває треба UI зовнішній посмикати, то можливі ті самі проблеми що і у Appium. Дерево відбудовується але без нод.
— Тести супер швидкі, розігнав до абсурду. Проходять швидше і стабільніше за playwright Web тести.
— Можливі проблеми з тим щоб на ферми кудись віддавати тести. Проте треба зауважити що тестів відро і трошки але менше 10 хвилин працюють. На CI один iOS і один Andoid емулятор і того досить.
— Тести ближче до розробників, їм легше зрозуміти що падає. Можна запустити дебаг E2E теста, а зупинити в коді самого застосунку.
— Зробив тести на Android, а потім з пів тика вони завелись на iOS. Але це ще і заслуга Flutter.

Були з Patrol і проблеми, але не суттєві. Але то окрема розмова.

дуже дякую за коментар! цінна інформація!

Дякую за чудовий матеріал!
Описані кейси дійсно часто зустрічаються при розробці на Flutter!

Підписатись на коментарі