Как стимулировать плохой трафик на реальном устройстве

Что проверяют

Умеете ли вы воспроизвести медленную и нестабильную сеть управляемо и повторяемо, а не «сходить в подвал», и знаете ли, что проверять в таких условиях. Следом спрашивают, как тестировать обрыв связи посреди запроса.

Как отвечать

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

• iOS: Network Link Conditioner прямо на устройстве в настройках для разработчиков или Device Conditions в окне устройств Xcode. Есть готовые профили вроде 3G, Edge, Very Bad Network, можно собрать свой с потерями;
• прокси: Charles Proxy или Proxyman, телефон ходит через них по Wi-Fi. Throttle Settings задают скорость и задержку, а Breakpoints и Map Local подменяют ответ, отдают 500 или подвешивают запрос. Ограничение касается только трафика, идущего через прокси;
• сеть на уровне ОС: точка доступа с ноутбука на Linux и tc с netem (задержка, джиттер, процент потерь) ухудшают весь трафик, включая WebSocket и UDP;
• веб на Android: удалённая отладка через chrome://inspect и троттлинг во вкладке Network в DevTools;
• физические условия: авиарежим посреди запроса, переключение с Wi-Fi на мобильную сеть, лифт или экранирующий чехол.

Что проверять: таймауты и понятные сообщения об ошибках, бесконечные лоадеры, повторные запросы без дублей (двойная оплата, повторная отправка формы), возобновление загрузки файлов, работу из кэша и офлайн-режим, поведение после восстановления сети.

Где спотыкаются

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

Проверяют только «медленно, но стабильно». Основные баги ловятся на потерях пакетов и обрыве посреди запроса, а не на ровном 3G.

Забывают, что прокси ограничивает только свой трафик, и делают выводы о пушах, видео или сокетах, которые шли мимо него.