Как тестировать приложение: ручные, автотесты и фермы устройств
Практика3 минРедакция Innovialabs
Коротко
Надёжная схема — много быстрых unit-тестов, меньше UI-тестов компонентов и немного end-to-end сценариев, плюс ручная проверка перед релизом. Эмуляторы подходят для ежедневной разработки, а реальные устройства и облачные фермы — для проверки на том, чем пользуются ваши клиенты.
Короткий ответ: пирамида тестов
Мобильное приложение проверяют на трёх уровнях:
- Unit-тесты — много, быстрые, проверяют логику без интерфейса.
- UI-тесты компонентов (в Flutter — widget-тесты) — меньше, проверяют экраны и элементы.
- End-to-end (E2E) — немного, проверяют ключевые сценарии целиком: вход, оплата, оформление заказа.
Поверх автотестов остаётся ручное тестирование: исследование нового функционала и регрессия перед релизом.
Уровни тестов
| Уровень | Что проверяет | Скорость | Где запускать |
|---|---|---|---|
| Unit | Бизнес-логику, расчёты, преобразование данных | Секунды | На каждом коммите |
| UI-компоненты / widget | Отрисовку экрана, реакцию на нажатия, состояния | Быстро | На каждом pull request |
| E2E | Сценарий от запуска до результата, с сетью и навигацией | Медленно | На pull request или по ночам |
Чем выше уровень, тем дороже тест в поддержке и тем чаще он бывает нестабильным (flaky). Поэтому основную логику проверяйте снизу, а E2E оставляйте для самых важных путей.
Инструменты
| Инструмент | Платформа | Для чего |
|---|---|---|
| XCTest / XCUITest | iOS | Unit- и UI-тесты, встроены в Xcode |
| Espresso | Android | UI-тесты внутри процесса приложения, синхронизация с главным потоком |
| flutter_test, integration_test | Flutter | Unit-, widget- и интеграционные тесты |
| Detox | React Native | E2E по принципу «серого ящика»: ждёт, пока приложение освободится |
| Maestro | iOS, Android, кросс-платформа | E2E-сценарии в YAML, быстрый старт без глубокого знания кода |
| Appium | iOS, Android | Кросс-платформенные E2E через WebDriver |
Пример сценария Maestro:
appId: com.example.app
---
- launchApp
- tapOn: "Войти"
- inputText: "test@example.com"
- tapOn: "Продолжить"
- assertVisible: "Главная"
Ручное тестирование
Автотесты не заменяют человека полностью. Вручную стоит проверять:
- новый функционал — исследовательское тестирование, когда сценарии ещё не устоялись;
- визуальные мелочи: шрифты, отступы, тёмную тему, разные размеры экрана;
- прерывания: входящий звонок, сворачивание приложения, потеря сети, отказ в разрешениях;
- регрессию по чек-листу перед релизом.
Для раздачи сборок тестировщикам используйте TestFlight на iOS и внутреннее тестирование в Google Play Console.
Эмуляторы или реальные устройства
| Эмуляторы и симуляторы | Реальные устройства | |
|---|---|---|
| Стоимость | Бесплатно | Нужно покупать или арендовать |
| Скорость старта | Быстро, удобно в CI | Медленнее настраивать |
| Точность | Не воспроизводят реальную производительность, камеру, датчики | Реальное поведение, оболочки производителей |
| Когда использовать | Ежедневная разработка, unit- и UI-тесты | Проверка перед релизом, производительность, железо |
Особенно важно проверять на реальных Android-устройствах: оболочки производителей по-разному работают с фоновыми задачами, уведомлениями и энергосбережением.
Облачные фермы устройств
Если покупать парк телефонов дорого, используйте фермы: Firebase Test Lab, AWS Device Farm, BrowserStack, Sauce Labs. Они запускают ваши тесты на реальных устройствах в облаке и возвращают логи, видео и скриншоты.
Как выбрать набор устройств:
- Возьмите из аналитики самые популярные модели и версии ОС среди ваших пользователей.
- Добавьте минимальную поддерживаемую версию ОС.
- Включите маленький экран и бюджетное устройство с небольшим объёмом памяти.
Частые ошибки
- Ожидания через фиксированные паузы (
sleep) вместо ожидания состояния — главный источник нестабильных тестов. - Тестировать только «счастливый путь» без ошибок сети и пустых данных.
- Проверять приложение только на одном телефоне разработчика.
- Запускать E2E вручную, а не в CI: про них быстро забывают.