Виды тестирования мобильных приложений: полная таксономия типов проверок

По данным Android Vitals в Google Play Console, приложения с crash rate выше 1,09% и ANR-rate выше 0,47% попадают в категорию плохого качества и рискуют понижением в рейтинге или ограничениями в сторе. Apple App Store Review Guidelines прямо указывают: приложения с частыми сбоями при проверке отклоняются немедленно. При этом, по данным Statista, нестабильная работа и баги — одна из главных причин удаления приложений пользователями. Всё это делает тестирование не приятным дополнением, а обязательным условием жизнеспособности продукта.

Но виды тестирования мобильных приложений — это не одно и то же действие, а система разнородных проверок, каждая из которых отвечает за свой аспект качества. Функциональное тестирование проверяет, работают ли фичи. Нагрузочное — выдержит ли сервер пиковый трафик. Тестирование совместимости убеждается, что приложение одинаково ведёт себя на Samsung Galaxy и Xiaomi Redmi. Знать эту таксономию полезно не только QA-инженеру: руководитель или владелец продукта, понимающий классификацию, осознанно выбирает, что проверять на каждой стадии разработки — и не переплачивает за лишнее, и не экономит там, где экономить опасно.

Содержание

• Почему тестирование мобильных приложений — это не одно, а много разных проверок
• По каким осям классифицируют виды тестирования
• Функциональные виды тестирования
• Нефункциональные виды тестирования
• Виды проверок, специфичные именно для мобильных приложений
• Ручное vs автоматизированное тестирование: что и когда
• На каких устройствах тестировать: реальные, эмуляторы, облачные фермы
• Как собрать набор видов под свой проект
• Частые вопросы (FAQ)

Почему тестирование мобильных приложений — это не одно, а много разных проверок

В классической разработке ПО долго жил миф: «протестировали — значит, проверили всё». На практике «тестирование» — это зонтичный термин, скрывающий десятки методик с принципиально разными целями, инструментами и стоимостью. Неверное представление об этом ведёт к двум крайностям: либо команда проводит только минимальные smoke-проверки и получает вал багов от пользователей, либо тратит бюджет на избыточные проверки, не нужные на текущей стадии.

Мобильная разработка добавляет сложности по сравнению с вебом и десктопом. Три ключевых отличия:

• Фрагментация устройств. Только на Android в мире работают тысячи разных моделей с разными экранами, прошивками, версиями ОС и модификациями производителей. iOS более однородна, но у неё свои нюансы — разные поколения железа и особенности последних версий системы.
• Изменчивая среда. Мобильный телефон — не стационарный компьютер. Приложение должно корректно вести себя при входящем звонке, разряде батареи, переключении с Wi-Fi на мобильный интернет и обратно, включении режима «в самолёте».
• Стоимость бага на разных стадиях. Исследования IBM показывают: устранить дефект на стадии дизайна в 6 раз дешевле, чем на стадии разработки, и в 15 раз дешевле, чем после релиза. Разные виды тестирования «ловят» разные классы дефектов на разных стадиях, что напрямую влияет на бюджет проекта.

Из этих реалий и выросла система классификации: каждый вид тестирования закрывает конкретный риск. Ни один вид не покрывает все риски сразу — отсюда и множество методик.

По каким осям классифицируют виды тестирования

Прежде чем перейти к конкретным видам, удобно разложить их по трём главным осям. Это поможет не запутаться в терминологии и понять, почему разные источники дают разные «списки видов».

По знанию внутренностей системы: чёрный, белый и серый ящик

Чёрный ящик (black-box) — тестировщик видит только интерфейс и поведение приложения снаружи, без доступа к коду. Типичный пример: ручное QA-тестирование пользовательских сценариев. Хорошо находит дефекты с точки зрения пользователя, но не видит внутренних ошибок логики.

Белый ящик (white-box) — тестировщик имеет полный доступ к коду и проверяет его изнутри: покрытие ветвей, условий, путей исполнения. Это область юнит-тестов и code review. Находит скрытые логические ошибки, которые не воспроизводятся в типичных пользовательских сценариях.

Серый ящик (grey-box) — промежуточный вариант: тестировщик знает архитектуру и некоторые детали реализации, но тестирует через интерфейс. Актуален для интеграционных тестов, когда важно знать, как компоненты взаимодействуют внутри.

По уровню: модульное, интеграционное, системное, приёмочное

Это пирамида тестирования, которую предложил Майк Кон:

• Модульное (unit) тестирование — проверка отдельных функций и классов в изоляции. Быстрое, дешёвое, автоматизируемое. Даёт основание пирамиды.
• Интеграционное тестирование — проверка взаимодействия модулей между собой (например, как экран авторизации работает с API). Находит ошибки на стыке компонентов.
• Системное тестирование — проверка полного приложения в условиях, близких к боевым. Здесь проверяют сквозные пользовательские сценарии (end-to-end).
• Приёмочное тестирование (UAT). Финальная проверка: соответствует ли продукт требованиям бизнеса и ожиданиям заказчика или реальных пользователей.

По способу выполнения: ручное и автоматизированное

Ручное тестирование выполняет QA-специалист без автоматических скриптов. Гибкое, незаменимо для юзабилити и исследовательских проверок. Автоматизированное тестирование — скрипты, выполняющиеся без участия человека (например, Appium, Espresso, XCUITest). Быстрое при повторных запусках, но требует инвестиций в написание и поддержку тестов.

Ниже — компактная шпаргалка по осям:

Ось	Варианты	Типичные примеры
Знание системы	Чёрный, белый, серый ящик	Ручной QA / Unit-тесты / Интеграционные тесты
Уровень	Unit, интеграционный, системный, приёмочный	Jest / API-тесты / E2E / UAT
Метод выполнения	Ручное, автоматизированное	QA-специалист / Appium, Espresso, XCUITest
Цель	Функциональное, нефункциональное	Проверка фич / Производительность, безопасность

Функциональные виды тестирования

Функциональные виды отвечают на вопрос «делает ли приложение то, что от него требуется?». Это наиболее очевидная часть тестирования, но внутри неё тоже есть чёткое разделение по задачам.

Функциональное тестирование

Проверяет, что каждая функция (фича) приложения соответствует требованиям: форма регистрации создаёт аккаунт, корзина сохраняет товары, push-уведомление приходит в нужный момент. Основной инструмент — тест-кейсы и чек-листы, составленные по требованиям. Проводится как вручную, так и через UI-автотесты (Espresso для Android, XCUITest для iOS).

Дымовое (smoke) и санитарное (sanity) тестирование

Smoke-тест — беглая проверка, что новая сборка вообще работает: приложение запускается, открываются ключевые экраны, авторизация не падает. Занимает 15–30 минут. Его цель — быстро понять, стоит ли тратить время на полноценное тестирование этой сборки или она «сломана на входе». Проводится после каждой новой сборки.

Sanity-тест чуть глубже: проверяет конкретную область, в которой были внесены изменения, убеждаясь, что исправление работает и не сломало ближайшие соседние функции. Применяется при получении патча или хотфикса.

Регрессионное тестирование

После каждого изменения кода — новой фичи, исправления бага или рефакторинга — нужно убедиться, что старый функционал не сломался. Это и есть регрессионное тестирование. Оно критически важно для приложений с растущей кодовой базой: без регресса команда регулярно «чинит одно, ломая другое». Именно здесь автоматизация даёт максимальный возврат инвестиций: скрипт, написанный однажды, прогоняется при каждом билде без участия человека.

Приёмочное / пользовательское тестирование (UAT)

User Acceptance Testing — финальная проверка перед релизом. Реальные пользователи или представители заказчика работают с приложением и подтверждают, что оно соответствует их ожиданиям и бизнес-требованиям. UAT не ищет технических багов — он проверяет, решает ли продукт задачу, ради которой создавался. Нередко именно UAT выявляет несоответствия между тем, что разработала команда, и тем, что нужно бизнесу.

Нефункциональные виды тестирования

Если функциональные проверки отвечают на «что делает?», то нефункциональные — на «как делает?» и «насколько хорошо?». Они закрывают риски, которые не видны в обычных пользовательских сценариях, но критичны для коммерческого успеха продукта.

Тестирование производительности: нагрузочное, стресс, стабильность

Нагрузочное тестирование (load testing) проверяет поведение системы при ожидаемом уровне одновременных пользователей. Цель — убедиться, что серверная часть (бэкенд и API) справляется без деградации времени отклика. Инструменты: k6, Gatling, Apache JMeter.

Стресс-тестирование (stress testing) нагружает систему сверх ожидаемого предела, чтобы найти точку отказа. Важно знать не только «выдержит ли плановую нагрузку», но и «как система себя поведёт, когда лопнет» — упадёт ли корректно или потеряет пользовательские данные.

Soak-тестирование (тестирование стабильности) — длительный прогон под нормальной нагрузкой (часы или сутки). Выявляет утечки памяти, накапливающиеся со временем, и деградацию производительности при длительной эксплуатации. Особенно актуально для мобильных приложений, где пользователи не перезагружают телефон неделями. Если проект требует нагрузочного тестирования в промышленных масштабах, это отдельная специализация.

Тестирование безопасности

Мобильные приложения хранят и передают чувствительные данные: токены авторизации, платёжные реквизиты, геолокацию, личную переписку. Тестирование безопасности проверяет:

• Хранение токенов и паролей (не в открытом виде, не в незащищённом хранилище).
• Шифрование трафика (TLS, certificate pinning).
• Устойчивость к перехвату и MITM-атакам.
• Корректность управления разрешениями (приложение не запрашивает лишний доступ к камере или контактам).
• Защиту от реверс-инжиниринга APK/IPA.

Методика — ручной pentesting плюс статический анализ кода (SAST) и динамический анализ (DAST). Стандарт отрасли — OWASP Mobile Security Testing Guide.

Юзабилити-тестирование

Проверяет, насколько приложение удобно и понятно реальным пользователям. Форматы: лабораторное тестирование (наблюдение за пользователями в условиях студии), удалённое (запись экрана и поведения через инструменты типа Maze, UserTesting) и партизанское (быстрые интервью в полевых условиях). Юзабилити-тестирование находит проблемы UX, которые не видны в требованиях: пользователь «тупит» на шаге регистрации не потому, что кнопка сломана, а потому что он её не находит.

В контексте мобильных приложений к юзабилити примыкает тестирование доступности (accessibility): корректность работы с TalkBack (Android) и VoiceOver (iOS), размер элементов по гайдлайнам WCAG, достаточный цветовой контраст.

Тестирование совместимости

На Android только в России популярны десятки моделей смартфонов — Samsung, Xiaomi, realme, HONOR, Vivo, Tecno — каждая со своей прошивкой и особенностями. Тестирование совместимости проверяет, что интерфейс корректно отображается и приложение стабильно работает на целевой матрице устройств: разные диагонали и разрешения экрана, версии Android (минимально поддерживаемая — актуальная), версии iOS, соотношения сторон (16:9, 18:9, 20:9 и другие).

Профессиональное тестирование ПО обязательно включает матрицу совместимости, составленную под целевую аудиторию продукта — иначе часть пользователей получит сломанный UI или краши на конкретных устройствах.

Локализационное и интернационализационное тестирование

Если приложение выпускается на нескольких языках, важно проверить не только качество перевода, но и технические аспекты: правильная кодировка символов, корректное отображение дат и чисел в формате локали, отсутствие «вылезающих» элементов при длинных словах (немецкий язык, RTL-арабский). Отдельно проверяют форматы телефонных номеров, адресов и валют. Пропущенный баг локализации — это барьер для выхода на новый рынок.

Виды проверок, специфичные именно для мобильных приложений

Мобильная среда порождает класс проверок, которых просто нет в вебе или десктопе. Именно здесь опытный QA для мобайла отличается от специалиста по вебу: он знает эти сценарии наизусть и включает их в тест-план по умолчанию.

Тестирование прерываний

Приложение работает — и вдруг пользователь получает звонок. Или срабатывает будильник. Или приходит push-уведомление от другого приложения. Или телефон уходит в режим энергосбережения. Тестирование прерываний проверяет, что приложение корректно реагирует на каждый из этих сценариев: ставится ли видео на паузу, сохраняется ли введённый текст, восстанавливается ли сессия после возврата в приложение. Нарушение этих ожиданий — один из главных источников низких оценок в сторах.

Сетевые условия и оффлайн-режим

Пользователь едет в метро: сеть то есть, то нет, то 2G вместо 4G. Тестирование сетевых условий проверяет поведение при переходе между типами сети (Wi-Fi → 4G → 3G → 2G → нет сети), при потере соединения в середине запроса, при слабом сигнале с высокой задержкой (latency). Отдельно — поведение в полном оффлайн-режиме: что показывает экран, сохраняются ли действия пользователя локально и синхронизируются ли они при восстановлении связи.

Расход батареи, памяти и нагрев

Приложение, которое разряжает телефон за три часа или нагревает его до «горячей» зоны, быстро летит в удаление. Тестирование потребления ресурсов фиксирует: процент CPU в активном и фоновом режимах, расход оперативной памяти, утечки памяти (memory leaks), использование геолокации и камеры в фоне. На Android инструменты: Android Profiler, Battery Historian. На iOS — Instruments (Xcode).

Работа с разрешениями, обновлениями ОС и жестами

Начиная с Android 6 и iOS 14, пользователи управляют разрешениями (camera, location, contacts) динамически, в любой момент. Тестирование проверяет, как приложение ведёт себя, если разрешение отозвано после установки — не падает ли оно, показывает ли внятное сообщение. Отдельный кейс — жесты: Edge Swipe (возврат в iOS 13+), жесты-навигации Android 10+. При обновлении ОС нередко ломаются UI-компоненты: нужны регрессионные проверки под новые мажорные версии iOS и Android сразу после их выхода.

Установка, обновление, удаление и разные каналы дистрибуции

Приложение должно корректно проходить полный жизненный цикл: установку «с нуля», обновление с предыдущей версии (при этом пользовательские данные и настройки должны сохраниться), удаление без артефактов в системе. Если приложение распространяется через несколько каналов (Google Play, RuStore, AppGallery для Android или TestFlight для бета-тестирования iOS), каждый канал нужно проверять отдельно — они могут иметь разные подписи APK и требования к манифесту.

Ручное vs автоматизированное тестирование: что и когда

Одна из самых частых ошибок в планировании тестирования — воспринимать автоматизацию как самоцель. Автоматизировать «всё» не только дорого, но и бессмысленно: некоторые виды проверок по природе своей требуют живого человека.

Когда автоматизация выгодна:

• Регрессионное тестирование — один раз написанный скрипт прогоняется при каждом билде.
• Smoke-тесты в CI/CD — быстрая проверка сборки без участия QA-инженера.
• Нагрузочное тестирование — воспроизвести тысячи одновременных сессий руками невозможно.
• Стабильные повторяющиеся сценарии (login, checkout, регистрация) — экономия времени при каждом релизе.

Когда ручное тестирование незаменимо:

• Юзабилити-тестирование — машина не чувствует неудобства.
• Исследовательское (exploratory) тестирование — QA импровизирует, пробуя нестандартные сценарии и обнаруживая неочевидные баги.
• Новые фичи с нестабильными требованиями — писать автотест под функционал, который меняется каждые два дня, расточительно.
• Монки-тестирование — хаотичное «издевательство» над приложением для обнаружения краёвых случаев.

Популярные инструменты автоматизации для мобайла: Appium (кроссплатформенный, работает с Android и iOS, поддерживает множество языков), Espresso (нативный для Android, максимально интегрирован с Android Studio), XCUITest (нативный для iOS от Apple, встроен в Xcode). Для нагрузочного тестирования API — k6 и Gatling.

На каких устройствах тестировать: реальные, эмуляторы, облачные фермы

Выбор между реальными устройствами и эмуляторами — не вопрос «что лучше», а вопрос «что нужно на конкретном этапе».

Эмуляторы и симуляторы (Android Emulator, iOS Simulator) хороши для быстрого итерирования в разработке. Дёшевы: не нужен физический парк устройств. Воспроизводимы: одинаковые условия при каждом запуске. Минусы — не передают реальную физику: нагрев не симулируется, точность акселерометра и GPS условна, поведение конкретной прошивки (Samsung One UI, MIUI) не эмулируется.

Реальные устройства критически необходимы для финального системного тестирования, тестирования производительности (CPU, батарея), проверки специфики конкретных производителей и для тестирования прерываний (реальный звонок не симулировать). Минус — расходы на поддержание актуального парка устройств.

Облачные фермы устройств — компромисс: Firebase Test Lab (Google), BrowserStack App Automate, AWS Device Farm дают доступ к сотням реальных физических устройств по требованию. Платная модель, зато не нужен собственный парк. Оптимально для запуска автотестов на матрице устройств в CI/CD-пайплайне.

Практическое правило: юнит- и интеграционные тесты — на эмуляторах; системное тестирование и UAT — на топ-5–10 реальных устройствах из целевой аудитории; полная матрица совместимости — на облачной ферме.

Как собрать набор видов под свой проект

Универсального набора нет, но есть логика выбора. Два главных параметра — стадия проекта и тип продукта. Ниже — ориентировочная таблица для принятия решений:

Стадия / тип	Обязательно	Желательно	Можно отложить
MVP (первый релиз)	Функциональное, smoke, совместимость (топ-5 устройств), безопасность-минимум	Регрессионное (ручное), UAT	Полная матрица совместимости, автоматизация регресса, soak
Активный рост (v2.0+)	Регрессионное (автоматизировать), нагрузочное, совместимость, прерывания, сеть	Стресс, безопасность полная, юзабилити	Локализация (если один язык)
Зрелый продукт / enterprise	Всё вышеперечисленное + локализация, accessibility, soak	Пентест, монки-тестирование	—
Финтех / медицина / e-commerce	Безопасность и пентест — обязательно с самого начала	Нагрузочное с первого релиза	—

Для самостоятельного выбора ориентируйтесь на риски: какой дефект нанесёт наибольший ущерб пользователям и бизнесу, если проскочит в прод? Именно этот риск закрывайте в первую очередь.

Если нужна помощь с подбором и реализацией полного комплекта проверок для вашего приложения, команда YuSMP Group занимается профессиональным тестированием ПО: составим матрицу рисков, разработаем тест-план и закроем все критичные виды тестирования под вашу стадию и бюджет. А если проект начинается с нуля, посмотрите раздел разработки мобильного приложения — тестирование встраивается в процесс с первого спринта.

Частые вопросы (FAQ)

Сколько существует видов тестирования мобильных приложений?

Единой «официальной» цифры нет: разные школы и стандарты называют от 10 до 40+ видов. Важнее понимать оси классификации: по уровню (unit, интеграционное, системное, приёмочное), по знанию системы (чёрный, белый, серый ящик), по цели (функциональное, нагрузочное, безопасности, юзабилити и другие), по методу выполнения (ручное или автоматизированное). Зная эти оси, вы выбираете нужный набор проверок под конкретный проект и стадию, а не гонитесь за абстрактным числом.

Чем тестирование мобильных приложений отличается от тестирования сайтов?

Мобильное тестирование сложнее из-за фрагментации: тысячи устройств с разными экранами, версиями Android и iOS, модификациями производителей. Добавляются специфические проверки: прерывания (звонок посреди сессии), разный уровень сети (2G/5G/офлайн), расход батареи и памяти, системные жесты, разрешения приложения, поведение при обновлении ОС. Веб-сайт живёт в контролируемом браузерном окружении; мобильное приложение — в постоянно меняющейся среде устройства.

Какие виды тестирования обязательны для MVP, а какие можно отложить?

Для MVP критически важны: функциональное (основные пользовательские сценарии работают), дымовое (приложение стартует и не падает), базовое тестирование совместимости (топ-5 устройств целевой аудитории) и минимальная проверка безопасности (хранение токенов, зашифрованный трафик). Можно отложить: полную матрицу совместимости, нагрузочное тестирование (до появления реальной нагрузки), расширенное юзабилити-исследование и автоматизацию регресса (до стабилизации функционала). С ростом продукта эти виды постепенно добавляются.

Нужно ли тестировать на реальных устройствах или хватит эмуляторов?

Эмуляторы хороши для быстрых итераций в разработке и автотестов — они дёшевы и воспроизводимы. Но они не симулируют реальное «железо»: нагрев, расход батареи, точность сенсоров, поведение камеры, сетевые условия и специфику конкретных производителей (прошивки Samsung, Xiaomi). Оптимальный подход: автотесты на эмуляторах плюс ключевые сценарии на реальных устройствах. Облачные фермы (Firebase Test Lab, BrowserStack) дают доступ к сотням реальных устройств без собственного парка.

Что важнее — ручное или автоматизированное тестирование?

Они дополняют друг друга, а не конкурируют. Автоматизация выигрывает на регрессионных проверках, стабильных сценариях и нагрузочных тестах — экономит время при каждом релизе. Ручное тестирование незаменимо для юзабилити, исследовательского (exploratory) тестирования, проверки новых фич, когда тест-кейсы ещё не стабилизированы. Практическое правило: автоматизируйте то, что повторяется часто и меняется редко; всё остальное проверяйте руками.

Кто должен проводить тестирование: разработчик или отдельный QA?

Лучший результат даёт разделение ответственности. Разработчик пишет юнит-тесты и базовые интеграционные тесты — он знает код. Отдельный QA-инженер (или команда QA) проводит системное, приёмочное, нагрузочное и ручное тестирование — у него незашоренный взгляд и специализированные инструменты. Для небольших MVP один человек может совмещать роли, но с ростом продукта специализация QA окупается: баги, пойманные до релиза, обходятся в 4–10 раз дешевле, чем после него.