Привет! Я – Андрей, QA-лид из компании «Совкомбанк Технологии».
Хочу поделиться опытом тестировании мобильных приложений в Xcode — среде, которую многие используют только для разработки. По внутренним данным нашей компании, примерно 65% критических багов в iOS-приложениях можно выловить ещё на этапе разработки, если грамотно использовать встроенные инструменты Xcode.
В сети много материалов о сторонних решениях для отладки и контроля качества iOS-приложений, но часто из виду упускается то, что сам Xcode предлагает всё необходимое «из коробки», при этом многие инструменты остаются невостребованными.
В этой статье я подробно разберу 4 инструмента, которые используются в моей команде для отлова тех самых 65% ошибок. Каждый раздел статьи содержит пошаговый разбор работы инструмента и то, как он применяется в тестировании.
Что обсудим?
Кому рекомендую прочесть эту статью:
Разработчикам приложений, которые хотят глубже разобраться в инструментах тестирования в Xcode
Тестировщикам, работающим с мобильными iOS-приложениями
Начинающим специалистам, чтобы получить базовое понимание ключевых инструментов
1. Симулятор устройств и управление конфигурациями
Начнем с базы. В отличие от IDE Android Studio, где используются эмуляторы, в среде разработки Xcode создаются симуляторы. Если коротко, отличия заключаются в следующем: эмуляторы имитируют как программную, так и аппаратную часть устройства, запуская полноценную ОС на другой архитектуре, а симуляторы — только программную, моделируя ОС на той же архитектуре. Например, на симуляторе невозможно протестировать то, как приложение обращается к камере, GPS-модулю или FaceID, а на эмуляторе – запросто. При этом плюсом симуляторов является скорость работы и экономия ресурсов.
Важно понимать, что симулятор не заменяет тестирование на реальных устройствах, тут рекомендую использовать оба подхода.
1.1 Запуск симулятора
1.1.1 Подготовка
Чтобы полноценно приступить к тестированию, необходимо добавить проект вашего приложения в Xcode, чтобы он получал все необходимые обновления. Чаще всего с этим может помочь команда разработки. В моей практике проект получает изменения кода сборки через клиента системы контроля версий Sourcetree, с ним все правки сразу видны в интерфейсе. В зависимости от особенностей проекта, команды разработки используют разных клиентов.
1.1.2 Начало использования
Заходим в менеджер устройств для управления симуляторами и подключенными устройствами. Открываем в хедере меню быстрого доступа и выбираем Manage Run Destinations.
Данный менеджер помогает упростить выбор цели запуска, особенно когда симуляторов или тестовых устройств много. В�� вкладке Devices отображаются подключенные/добавленные реальные девайсы, в Simulators – симуляторы. Через "+" в нижнем левом углу можно создать подключение с реальным устройством или создать новый симулятор исходя из наших требований.
Примечание: еще один способ открыть Manage Run Destinations: Product → Destinations → Manage Run Destinations
1.1.3 Создание симулятора
Переходим на вкладку симуляторов и создаем необходимый. Нажимаем "+", задаем имя, выбираем модель и версию iOS. Кстати, через выпадающее меню можно предварительно загрузить нужную версию iOS с помощью команды Download more simulator runtimes.
Нажимаем Create. Готово, созданный симулятор отображается в меню слева. Таким образом можем добавить разные модели симуляторов и обзавестись парком устройств с нужными экранами и версиями iOS. Удобно в узких кейсах, например, баг воспроизводится только на устаревшей iOS 16 и на малых диагоналях экранов как на iPhone 6/7/8 - тем самым мы легко можем локализовать ошибку.
1.1.4 Подготовка сборки приложения на созданном ранее симуляторе
Возвращаемся в меню быстрого доступа и выбираем симулятор, другими словами, указываем где будет установлено приложение. Стоит обратить внимание, что все подключенные ранее реальные устройства и симуляторы тоже здесь отображаются. То есть, есть история запусков и подключений, симуляторы - имеют серую иконку, реальные устройства - цветную. После выбора симулятора видим следующую схему: проект (приложение) > выбранный симулятор.
1.1.5 Сборка приложения на выбранном симуляторе
Нажимаем кнопку Start the active scheme или стартуем сборку кнопками быстрого доступа cmd + R и наблюдаем процесс сборки в хэдере слева, а в нижней части отслеживаем лог сборки, если это необходимо.
1.2 Возможности симулятора
В окне симулятора есть быстрый доступ к смене ориентации экрана, например, проверить корректность верстки в обоих режимах и убедиться, что UI правильно адаптируется при повороте. Можно быстро сделать скриншот экрана и есть имитация нажатия кнопки «Домой».
Меню выбора функционала расположено в левом верхнем углу, обратите внимание на скриншоты.
Напротив каждой функциональности есть свои горячие клавиши для быстрого управления:
1.3 Работа с реальным устройством
Подключим реальный девайс по проводу и посмотрим, какие возможности нефункционального тестирования можно произвести. Другими словами, поработаем с аппаратной частью на подключенном устройстве.
1.3.1. Подготовка
Возвращаемся в Manage Run Destinations, переходим на вкладку Devices – видим подключенный девайс и полную информацию о нем. В разделе Installed Apps отображаются установленные приложения через среду разработки, то есть если сделать сборку через Xcode на подключенное устройство.
1.3.2. Работа с возможностями имитации состояний устройства
В разделе Device Conditions настраиваем следующий функционал:
Condition: GPU Performance State и значение Profile: Minimum/Medium/Maximum – можем сымитировать текущий режим производительности графического процессора GPU на подключенном устройстве и испытать приложение при разных нагрузках графического процессора. Так можно проанализировать как приложение работает в разных состояниях, чтобы соблюсти баланс между производительностью и энергопотреблением.
Condition: Network Link, в значении Profile – задаем симуляцию различных сетевых условий на физическом устройстве iOS во время отладки и тестирования. Xcode отправляет специальные команды на устройство, чтобы оно эмулировало определенные сетевые условия. Замечу, что это влияет только на то, как приложение видит сеть, а не на реальное сетевое соединение девайса. Данный функционал обеспечивает тестирование поведения приложения в различных условиях сети.
Condition: Thermal State и значения Profile: Fair/Serious/Critical помогает симулировать различные уровни нагрева устройства. Устройства iOS могут снижать производительность, чтобы предотвратить перегрев. Эта настройка позволяет искусственно заставить устройство «думать», что оно перегрелось, а тестировщику проверить, как приложение ведет себя в таких условиях.
После выбора необходимой настройки не забываем Кнопкой Start запустить вышеописанный режим.
В итоге нам доступен инструмент для тестирования различных сценариев: от размеров экранов до версий iOS и нефункциональных аспектов.
2. Работа с логами и анализ крашей
Снова начнем с вводных. В системе унифицированного логирования Apple (Unified Logging System) есть пять уровней:
Default - стандартный уровень для обычных сообщений. Виден в режиме "All Messages" и выше.
Info - информационные сообщения. Для полезной, но не критичной информации, например, статуса операции. Виден при фильтрации "Info" и выше.
Debug - отладочные сообщения. Для деталей, нужных только при разработке, например, значения переменных. Виден только когда включен режим "Debug".
Error - ошибки. То есть проблемы, которые требуют внимания, но не останавливают работу приложения, например, неудачный сетевой запрос. Виден в режиме "Errors" и выше.
Fault - критические сбои, которые требуют особого внимания. Для серьёзных ошибок, ведущих к неработоспособности, например, ошибка в критическом потоке. Виден всегда, даже в продакшене.
2.1 Работа в Console
Для анализа и просмотра логов в реальном времени используется встроенное приложение Console. Вышеописанные уровни логов можно выставлять в соответствии с потребностями. Подключим реальное устройство или запустим симулятор и пройдемся по функциональности Console.
2.1.1 Подготовка
Переходим в Manage Run Destinations, в верхней части у подключенного девайса есть кнопка Open Console. На скриншоте выше отображено, где расположена данная кнопка.
Примечание: еще один способ открыть Console при подключенном девайсе: Xcode → Window → Devices and Simulators → Выберите устройство → Open Console.
2.1.2 Отчеты диагностики
В левой части раздела Devices выбираем подключенное устройство или симулятор. Ниже отображаются все отчеты диагностики, автоматически собираемые системой, в том числе за прошлые даты.
Отчеты о сбоях. Анализ стектрейса падения — это последовательность вызовов методов и функций в коде приложения, зафиксированная в момент его аварийного завершения или краша. Он показывает, как программа дошла до места сбоя, и помогает точно определить причину падения.
Отчеты Spindump. Отражают «зависания», неадекватно долгое выполнение процессов (>250 мс) или принудительное завершение приложений. Spindump помогает понять, почему программа перестала отвечать или была «убита» системой.
Отчеты журналирования. Системные и пользовательские логи, записанные через Unified Logging System. Они содержат детализированные записи о работе macOS, приложений и фоновых процессов, помогают в отладке и анализе проблем.
Диагностические отчеты. Общая папка, где хранятся все типы отчётов о сбоях, включая вышеописанные.
Данные аналитики. Обезличенная диагностическая информация, которую система автоматически собирает и может отправлять в Apple для улучшения стабильности, производительности и пользовательского опыта. Другими словами, это системные и прикладные события, которые macOS и установленные приложения записывают локально и отправляют в Apple при наличии разрешения. В Console отображается копия данных, сохранённая на Mac.
System.log. Основной системный журнал macOS, в который записываются события ядра (kernel), служб системы, драйверов и критически важных процессов, то есть системные конфликты. Он является частью Unified Logging System, начиная с macOS 10.12, но также сохраняется в устаревшем формате для совместимости.
2.1.3 Запуск логирования и рабочая область
В правой части находится рабочая область. Здесь можно отслеживать/фильтровать/настраивать логи. Кнопка Start streaming запускает поток логов в режиме реального времени. После запуска видим вывод сообщений логов в разрезе типа, времени, процесса и самого сообщения. Можно выставить фильтр вывода всех сообщений или только уровня ошибок, выше отображается общее количество сообщений.
2.1.4 Фильтр и настройки логов
В правом верхнем углу есть поиск, он же фильтр, для собственных настроек. Например, здесь можно задать название своего приложения или произвести поиск по заданному ключевому слову.
2.1.5 Кнопки управления Console
Слева от поиска есть кнопки управления:
Start/Pause. Останавливает/возобновляет поток логов в реальном времени, позволяя зафиксировать текущие сообщения для анализа. В паузе можно скопировать конкретные ошибки без прокрутки. Также опция подойдет для детального изучения моментального снимка логов.
Now. Здесь всегда отображаются текущие логи. С ее помощью можно вернуть отображение логов к актуальным записям в режиме реального времени. Опцию можно использовать с целью прокрутки вверх, чтобы быстро вернуться к текущим событиям или если логи «застряли» на старых данных.
Activities. Показывает логи, сгруппированные по системным или пользовательским «активностям», например, запуск приложения или обновление системы. Стоит использовать для анализа действий в хронологическом контексте, например, чтобы посмотреть, что происходило во время зависания программы.
Clear. Данная опция полностью очищает текущую рабочую область от логов, чтобы убрать старые сообщения и начать анализ «с чистого листа». Примечание: Clear не удаляет сами файлы логов на диске.
Reload. С помощью данной кнопки можно обновить рабочую область, повторно загружая логи из системных файлов. Если не отображаются свежие записи, например, после очистки кэша или при ручном изменении логов через терминал.
Info. Вспомогательное меню в нижней части рабочей области, при выборе любого сообщения в этом меню можно увидеть вспомогательную информацию.
Отображает: точное время события, процесс (PID), подсистему (subsystem), категорию (category), дополнительные метаданные, например, путь к файлу. Можно использовать для глубокого анализа конкретной ошибки или чтобы скопировать технические детали для отладки.Share. Предоставляет возможность делиться текущими логами. Чтобы поделиться отдельным логом, нужно выделить определенное событие через cmd+С/cmd+V и вставить нужный лог в свой документ.
Таким образом, это отличный инструмент для анализа поведения приложения в случае крашей и других подобных событий. При помощи анализа логов можно решить проблемы с неочевидными падениями приложений, конфликтами системных процессов, утечкой памяти и ресурсов.
3. Инспектирование и анализ верстки
Когда пользователь открывает приложение, у приложения есть буквально несколько секунд, чтобы произвести хорошее впечатление. А если верстка «поехала», кнопки не кликаются и текст перекрывает иконки, впечатление остается не лучшим.
По данным наших внутренних исследований,47% пользователей удаляют приложение из-за проблем с интерфейсом, а 90% готовы отказаться от сервиса, если он некорректно работает на устройстве. При этом многие баги верстки можно поймать на ранних этапах — с помощью встроенных инструментов Xcode, о которых часто забывают.
Разберем, как View Debugging и Accessibility Inspector помогают находить:
Некликабельные области из-за неправильных констрейнтов
Проблемы адаптивности для разных экранов
Ошибки в контрастности и читаем��сти текста
Подробный анализ каждого элемента на экранах приложения
3.1. Работа с View Debugging
3.1.1. Подготовка
Создаем сборку на устройстве или симуляторе, как описывал выше. Если нужно проверить как выглядит приложение на малой/средней/большой диагонали, можно воспользоваться симулятором. В случае, если необходимо проверить работу на реальном девайсе, его нужно подключить с помощью кабеля. Далее необходимо выбрать целевое устройство как основное (проект> выбранный симулятор/устройство). Запускаем сборку и открываем необходимый для инспектирования верстки экран.
3.1.2. Рабочая область
В верхней части Xcode выбираем Debug → View Debugging → Capture View Hierarchy – таким образом будет сделан снимок/слепок экрана, который станет нашей рабочей областью:
В верхнем правом углу нужно раскрыть меню подробной информации об элементах (кнопка Hide or show the Inspectors). На снимке экрана курсором выбираем интересующий элемент, нажимаем на кнопку Show the Object inspector. Это позволит отобразить основную информацию (имя, описание, цвет, шрифт и прочее) по выбранному объекту. Если в меню выбрать кнопку Show the Size inspector, отобразятся подробности о размере и расположении элемента. По середине отображается путь к выбранному объекту.
Дополнительно нужные элементы можно искать и выбирать через дерево в левой части. Оно включается с помощью кнопки Show the Debug Navigator в навигаторе отладки, где отображается информация о производительности приложения во время отладки. Панель показывает данные в реальном времени. Затем выбираем View UI Hierarchy. Это отличный инструмент для понимания структуры и расположения элементов, особенно когда что-то не так с отображением или взаимодействием. Здесь в 3D-режиме можно исследовать иерархию визуальных элементов (views) в реальном времени, когда приложение приостановлено в режиме отладки.
Ползунок в левой части внизу используется для отображения 3D модели экрана приложения. Чтобы понять, какие элементы перекрывают друг друга, их можно разобрать по слоям.
Ползунок в правой части помогает поочередно убрать слои/элементы экрана для понимания структуры.
Между ползунками расположены вспомогательные кнопки рабочей области, которые позволяют более детально работать со слоями 3D модели экрана.
С помощью данного инструмента можно инспектировать всю верстку и проводить подробный анализ каждого объекта экрана.
3.2 Работа с Accessibility Inspector
Данный инструмент помогает локализовать некликабельные области, ошибки в контрастности и читаемости текста, поддержку адаптации приложения для людей с ограниченными возможностями.
Это крайне важный аспект в опыте использования мобильного приложения. Если в приложении качественно реализована доступность элементов интерфейса, то людям с ограниченными возможностями, будет гораздо легче использовать приложение.
Приступим к практике.
3.2.1 Подготовка
Выбираем в верхней части Xcode → Open Developer Tool → Accessibility Inspector, откроется рабочая область функционала. Для начала в верхнем левом углу выбираем девайс/симулятор с которым планируем раб��тать и инспектировать.
3.2.2 Рабочая область
В правом верхнем углу нажимаем на кнопку Inspection, здесь три варианта навигации выбора необходимого элемента и ряд кнопок:
Кнопка «Прицел» или Target an element. Остается нажатой и меняет цвет. Когда мы водим по элементам экрана мышью - они выделяются, на реальном девайсе выбираем нужный объект тапом.
Кнопка Play (Start autonavigation while speaking element description. Emulates VoiceOver). Запускает автонавигацию, которая последовательно переключает фокус между компонентами экрана, при этом включается кнопка VoiceOver и каждый элемент озвучивается.
Кнопки ручной навигации «влево-вправо». Можем вручную, последовательно переключать фокус между объектами на экране.
Кнопка Speak the elements description to mimic VoiceOver. Когда она нажата, каждая составляющая экрана будет озвучена через VoiceOver. Это системная программа, озвучивающая элементы, действия и процессы на экране.
Кнопка Settings. Кнопка «Настройки» поможет тестировать общие параметры элементов, если включить соответствующий чекбокс. С её помощью можно изменить размер текста, инвертировать/дифференцировать цвета, увеличить контрастность, уменьшить движение, поставить везде жирный шрифт, выделить формы кнопок и оттенки серого.
3.2.3 Выбор элемента на экране устройства или симулятора
При выборе определенного объекта экрана он выделяется зеленой рамкой, которая подсвечивает, какой элемент сейчас инспектируется. Ниже можно увидеть подробную информацию по выбранной области.
Basic - базовая информация об элементе
Actions – информация о том, какие действия заложены в выбранный элемент
Element - дополнительная информация
Hierarchy - где в иерархии расположен элемент
3.2.4 Базовая информация об элементе
В Basic можно посмотреть все ключевые атрибуты доступности, которые разработчики должны добавить самостоятельно.
Обязательные атрибуты:
Label - текст, который озвучивает VoiceOver. Это обязательный и главный атрибут доступности элемента. Если лейбл отсутствует, пользователь услышит либо тип элемента, либо вообще ничего – это будет значить, что элемент не подписан. В таком случае слабовидящие пользователи просто не смогут понять, на какой элемент они нажали и что он делает.
Traits – тип элемента, например: Button, Header, Image, Textfield, Link и так далее.
Необязательные атрибуты:
Value – необязательный атрибут, текущее состояние элемента, например: Enabled, Disabled и так далее.
Identifier – используется при написании автотестов. Если при определении элемента для тапа в автотестах используется accessibility identifier - это как правило хорошая практика.
Hint – подсказка по действиям элемента. Например: двойной тап для открытия.
User Input Labels – дополнительная информация для озвучивания, которая исходит из текущего контекста использования.
Итак, данный инструмент будет полезен в проверке доступности интерфейса приложений. Accessibility Inspector также помогает в live-просмотре элементов и навигации, проверке логического порядка элементов, выявлении проблемных цветовых сочетаний, анализе соответствия стандартам WCAG, валидации работы с VoiceOver и улучшении UX для всех категорий пользователей.
4. Мокирование сетевых запросов
Традиционно для подмены и анализа сетевого траффика используют снифферы, например, Charles Proxy или Proxyman, но есть и исключения. Что делать если необходимо подменить запрос на специфическом устройстве, например, iPhone SE iOS 17, которого нет под рукой? Или если вдруг потребовалось работать без доступа к реальному API, тестировать в оффлайне или с чувствительными данными?
Для таких сценариев в проекте приложения предусмотрены мок-сервисы. Их расположение зависит от архитектуры приложения, но обычно они находятся в папке с говорящим названием Network/Mock в Xcode.
Важно отметить, что перед изменениями нужно синхронизировать код через клиента контроля версий, на нашем проекте используется Sourcetree.
Переходим к практике:
4.1. Подготовка
Нажимаем иконку папки (кнопка Show the Project navigator) слева, в верхней области. Далее в дереве идем по такому пути: Проект (название приложения) → App → Network → Mock. В Mock структурированно располагаются папки с кодом JSON/Swift всех сетевых запросов и в каждом из них есть запрос-ответ, метод, HTTP-статус, body, которые можем поменять по своему усмотрению.
4.2. Смена запроса
Например, мы поменяли JSON определенного запроса исходя из наших требований, благодаря чему справа автоматически ставится символ "M", обозначающий изменения в текущем запросе.
4.3. Сборка приложения на выбранном симуляторе или подключенном устройстве
Выполняем сборку, как делали это ранее. Нажимаем кнопку Start the active scheme или стартуем сборку кнопками быстрого доступа cmd + R.
4.4. Результат настроек мока
На симуляторе или подключенном девайсе переходим в debug-меню в самом приложении и выбираем стенд MOCK. При наличии мок-сервисов в проекте должен быть такой стенд в debug-приложении. Далее в приложении находим нужный экран или выполняем необходимое действие в запросе которого делали ранее подмену и исследуем полученный результат. Таким образом можем менять запросы по нашему усмотрению, тем самым изменяя состояния экранов приложения или логику. Полезно в тестировании состояния верстки и логики функционала. Отменить данную подмену запроса можно с помощью клиента Sourcetree.
Вывод
В этой статье я разобрал четыре ключевых инструмента:
Симулятор и Device Conditions — полигон для стресс-тестов, c помощью которого можно инспектировать верстку для экранов разных размеров и на разных версиях iOS. Проверять то, как приложение ведёт себя при слабом сигнале, перегреве или нехватке памяти ещё до того, как пользователь столкнётся с этим в реальности.
Console и логи — детективное расследование падений. С помощью данного инструмента можно найти корни проблемы по стектрейсу, проанализировать производительность и читать системные сообщения «между строк».
Accessibility Inspector и View Debugging — не просто отладка интерфейса, а взгляд с позиции пользователя: всё видно? Кликабельно? Адаптивно? Как это звучит для тех, кто не видит экран?
Мокирование запросов — полная свобода для тестирования: проверяются любые сценарии — от успешных операций до ошибок сервера — без зависимостей от бэкенда и риска затронуть продакшен.
В заключение скажу, что данные инструменты вместе — это целая система качества. Каждый силен сам по себе, но реальная мощь раскрывается тогда, когда они работают в связке и используются системно. Вы не просто тестируете отдельные части — вы формируете культуру стабильности, где баги перехватываются на этапе кода, а не пользовательского использования. Чтобы полноценно понять, как это работает, рекомендую пробовать.
Тестирование в Xcode — это не просто набор инструментов. Это смена подхода к разработке. Когда QA и разработчики используют одни и те же встроенные средства, появляется общий язык. Ошибки перестают быть "проблемой тестировщиков" — они становятся частью процесса улучшения продукта.
Внедрение этих практик в нашей команде сократило количество инцидентов после релиза на 40% за полгода. Начинали мы с одного симулятора и моков. Сейчас это часть ежедневной работы. Начните с малого и внедряйте эти инструменты поэтапно. Можно также начать с моков — они сэкономят часы на согласовании со стендами, добавьте проверку accessibility — и ваше приложение станет доступнее миллионам и уже на следующем релизе вы увидите разницу. Со временем это станет стандартом — не потому что «надо», а потому что «работает».
Делюсь полезными ссылками для углубленного изучения:
А вы используете инструменты Xcode в работе? Поделитесь в комментариях, какие ошибки вам удалось найти с их помощью, и удалось ли вообще.