6. Сетевое тестирование в мобильных приложениях

Мобильные приложения работают в реальных условиях: медленный интернет, потери пакетов, таймауты, 4G вместо Wi-Fi. Если тестить только в идеальных условиях, пользователи словят баги, а ты – тикеты от саппорта.

🚨 Долгая загрузка контента → API не отвечает, приложение висит.
🚨 Потеря соединения → краши при переходе между экранами.
🚨 Ошибки при восстановлении соединения → пользователь думает, что его заказ не прошёл, но списание произошло.

✅ Wi-Fi (хороший интернет)
✅ 4G/5G (мобильные сети)
✅ 3G (медленный интернет, задержки)
✅ Нет связи (офлайн-режим)
✅ Плохое соединение (теряются пакеты, лаги)

📌 Как тестить?

Включать/отключать Wi-Fi и мобильные данные.
Использовать Network Link Conditioner (iOS) и Android Emulator Advanced Network Settings.
Эмулировать плохой интернет через Charles Proxy / Fiddler.

✅ Как ведёт себя приложение при задержке 500+ мс?
✅ Что происходит, если пакеты теряются?
✅ Как приложение восстанавливает соединение?

📌 Как тестить?

Clumsy (Windows) – добавляет задержки, потери пакетов.
Charles Proxy / Fiddler – можно вручную рвать соединение.
tc (Linux/Mac) – эмуляция сетевых проблем в терминале:

sudo tc qdisc add dev en0 root netem delay 500ms loss 10%

Если приложение не может подключиться к серверу, оно должно вести себя адекватно:
✅ Показывать закешированные данные.
✅ Не крашиться при попытке загрузить контент.
✅ Корректно синхронизироваться после восстановления сети.

📌 Как тестить?

Отключать интернет и смотреть, как ведёт себя приложение.
Логиниться, отправлять сообщения в офлайне.
Проверять, что данные не теряются после возврата сети.

✅ Шифруются ли запросы?
✅ Можно ли перехватить данные в публичной сети?
✅ Безопасно ли хранится токен авторизации?

📌 Как тестить?

Charles Proxy / Burp Suite – подмена SSL-сертификатов.
Проверять, передаётся ли пароль в открытом виде (спойлер: не должен).
Анализировать заголовки CORS, HSTS, CSP.

Приложение должно адекватно реагировать на плохие ответы от сервера:
✅ 500 Internal Server Error – сервер упал, но UI не должен сдохнуть.
✅ 403 Forbidden – юзер не должен видеть чужие данные.
✅ 408 Request Timeout – таймаут не должен зависать бесконечно.
✅ 429 Too Many Requests – лимит запросов, приложение не должно спамить API.

📌 Как тестить?

Postman / REST Assured / Requests (Python) – отправлять кривые запросы.
Mock-серверы (WireMock, Postman Mock Server) – подставлять кастомные ответы.
Charles Proxy – эмулировать ошибки API.

Пример теста API на Python:

import requests def test_server_error(): response = requests.get("https://api.example.com/broken-endpoint") assert response.status_code == 500, "Сервер должен вернуть 500"

6. Сетевое тестирование в мобильных приложениях

Чтобы тестировать API в пайплайне, можно использовать pytest + Requests.

📌 .gitlab-ci.yml:

stages: - test api_tests: stage: test image: python:3.9 before_script: - pip install requests pytest script: - pytest tests/api_tests.py

Теперь тесты будут автоматически проверять API на каждом коммите.

🔥 Сетевое тестирование важно, потому что реальный мир ≠ идеальные условия.
🚀 Нужно тестировать плохой интернет, потери пакетов, офлайн-режим.
🛠 Лучшие инструменты: Charles Proxy, Burp Suite, Clumsy, Postman, WireMock.
✅ API должны работать даже при лагучем интернете.

6. Сетевое тестирование в мобильных приложениях

🤔 Почему это важно?

🔍 Что может пойти не так?

📡 Виды сетевого тестирования

1 Проверка работы на разных типах соединений

2 Тестирование задержек и потерь пакетов

3 Тестирование офлайн-режима

4 Тестирование безопасности сетевого соединения

5 Тестирование API и ошибок сети

🛠 Инструменты для сетевого тестирования

📌 Сетевое тестирование в CI/CD (GitLab)

📌 Итоги