Mobile performance testing проверяет, насколько быстро и устойчиво приложение помогает пользователю выполнить задачу при ограниченных ресурсах устройства. Продукт может правильно отвечать на запросы и всё равно раздражать: долго запускаться, зависать при прокрутке, перегревать телефон или закрываться после нескольких переходов.
Для QA важно связать измерение с пользовательским сценарием. Число мегабайт или миллисекунд становится полезным, когда понятно, на каком устройстве оно получено, что делало приложение и какой результат команда считает приемлемым.
Что именно измеряют
Производительность мобильного клиента включает запуск, готовность экрана, отклик на ввод, плавность, CPU, память, сеть, хранилище и энергопотребление. Отдельно оценивают стабильность: crash, зависания и завершения из-за давления на ресурсы.
Это дополняет серверные нагрузочные тесты. Быстрый API не гарантирует быстрый экран, если клиент долго разбирает данные, декодирует изображения или блокирует главный поток. И наоборот, медленный backend может определять большую часть ожидания при исправном клиенте.
Сформулируй критерии до прогона
Вместо «должно работать быстро» опиши сценарий, устройство, условия и измеряемую границу. Например, команда может принять внутреннюю цель времени от запуска до доступной корзины на выбранном телефоне. Это продуктовый критерий, а не универсальный стандарт для всех приложений.
Заранее договорись о числе повторов, способе подготовки данных и сравнении с предыдущей сборкой. Порог без метода измерения даёт спорный результат: два тестировщика могут засекать разные события и оба считать себя правыми.
Запуск: первый кадр и полезная готовность
Разделяй холодный запуск, возврат существующего процесса и восстановление состояния. В Android для запуска различают TTID, время до первого отображения, и TTFD, время до полной готовности. Красивый splash screen не доказывает, что пользователь уже может действовать.
Первый запуск после установки также может выполнять особую подготовку. Его полезно измерять отдельно от обычного запуска, чтобы не смешивать onboarding и миграцию с типичным ежедневным использованием.
Подготовка повторяемой среды
Используй подходящее физическое устройство, зафиксированные ОС и сборку, одинаковые данные и сеть. Учитывай заряд, температуру, энергосбережение, свободное место и фоновые процессы. Сравнивать перегретый телефон с остывшим без пометки некорректно.
Для итоговых сравнений нужна согласованная конфигурация, близкая к пользовательской. Debug-сборка и активный отладчик способны менять производительность. Подробное профилирование помогает объяснить причину, но само тоже создаёт нагрузку.
Практический пример: регрессия каталога
Представь, что после обновления каталога прокрутка стала заметно хуже. План должен отделить изменение клиента от случайного медленного ответа сервера.
- 1.Подготовь одинаковый каталог и устройство. Запиши исходные условия, номер предыдущей и новой сборок.
- 2.На предыдущей сборке выполни фиксированный путь: запуск, открытие категории, загрузка списка и одинаковая последовательность прокрутки.
- 3.Сохрани время готовности, профиль кадров и наблюдаемое поведение. Повтори серию в согласованном объёме.
- 4.На новой сборке повтори опыт с теми же данными, сетью и подготовкой кэша.
- 5.Сравни распределение результатов, а затем запиши профиль проблемного участка. Возможная гипотеза — изображения декодируются во время прокрутки и мешают обработке кадров.
- 6.После исправления повтори тот же сценарий. Ожидается выполнение критерия и отсутствие ухудшения памяти, качества изображений и загрузки.
Если порядок прогонов влияет на нагрев или кэш, учти это в плане. Одного быстрого и одного медленного запуска недостаточно для устойчивого вывода.
Память и длительные сценарии
Измеряй память не только сразу после старта. Повтори открытие тяжёлого экрана, смену разделов, загрузку изображений и возвращение назад. Наблюдай, выходит ли потребление на стабильный уровень после завершения операций.
Рост сам по себе ещё не доказывает утечку: приложение может наполнять полезный кэш. Проверяй удерживаемые объекты, повторяемость и последствия при ограниченных ресурсах. Финальный симптом может проявляться как перезапуск приложения или потеря состояния после фона.
Отклик, кадры и зависания
Средний FPS способен скрыть отдельные заметные задержки. Смотри длительность кадров, проблемные участки и реакцию на ввод. Допустимый бюджет кадра зависит от частоты обновления и поведения устройства; одна цифра не подходит всем экранам.
Различай тяжёлую анимацию, краткий пропуск кадров и длительную неотзывчивость. Для пользователя эти симптомы связаны, но инструменты и причины могут различаться. Android Studio и Instruments позволяют исследовать конкретный участок вместо оценки «на глаз».
Сеть, батарея и хранение
Проверь объём загрузок, повторные запросы, работу кэша и поведение в фоне. Незаметный постоянный опрос сервера способен расходовать батарею и трафик даже при быстром интерфейсе.
Короткий взгляд на процент заряда малоинформативен. Для сравнения используй повторяемый длительный сценарий и доступные инструменты измерения. Учитывай также рост файлов и кэша: приложение не должно бесконтрольно занимать хранилище после обычной работы.
Как оформить результат
Укажи пользовательский эффект, устройство, условия, сборки, точные границы измерения и результаты серии. Сохрани профиль или trace, а видео используй как иллюстрацию наблюдаемого симптома.
Не называй p95 надёжным показателем по нескольким случайным попыткам. Небольшая серия подходит для первичной диагностики, но выводы о распределении и редких задержках требуют достаточного объёма данных. Производственные метрики дополнительно показывают, встречается ли проблема у реальных пользователей.
Что должен вынести QA
Производительность проверяют через воспроизводимые сценарии, согласованные критерии и подходящие устройства. Сначала докажи регрессию, затем объясняй её профилем. Оценивай скорость вместе с памятью, стабильностью и энергопотреблением: ускорение одного экрана не должно ухудшать остальную работу продукта.