Недавно я столкнулся с некоторыми ошибками в разработанном мной приложении, которые касались только пользователей iPhone.
При обнаружении ошибки первым шагом обычно является попытка воспроизвести проблему, а затем проанализировать ее с помощью инструментов разработчика. iOS, однако, является самой сложной средой для отладки/анализа, если вы не полностью привержены Apple и не являетесь гордым владельцем iPhone и Mac. Если вам не хватает какого-либо из них, у вас не будет инструментов разработчика для отладки. Но вернемся к этому чуть позже.
Среда разработки
Разработка на быстрых машинах с (несколькими) большими экранами и быстрой (проводной) сетью всегда довольно удобна, и это, вероятно, предпочитает большинство разработчиков, предоставляя выбор.
Это позволяет быстро «компилировать» и почти мгновенно развертывать ваш код, а несколько экранов позволяют сравнивать вывод в разных браузерах с инструментами разработчика, открытыми в каждом из них.
Таким образом, это не только удобно, но и может значительно повысить производительность!
Однако такая настройка редко соответствует тому, что люди будут использовать для доступа к вашему веб-сайту (или веб-приложению). Таким образом, как разработчик, мы должны иметь возможность моделировать даже экстремальную среду конечного пользователя, чтобы убедиться, что веб-сайты ведут себя так, как мы ожидаем. К счастью, есть куча инструментов, которые могут помочь нам в этом вопросе…
Сеть
Скорость оказывает большое влияние на взаимодействие с пользователем, и хотя общую скорость веб-сайта можно легко проверить с помощью таких инструментов, как маяк или веб-подсказка, они на самом деле не дают конкретного представления о работе пользователя в медленной сети, такой как GPRS. или еще хуже, нестабильная сеть.
Чтобы проверить поведение вашего веб-сайта в этих средах или даже понять болевые точки определенных пользователей. Нам необходимо иметь возможность использовать ваш собственный веб-сайт с аналогичными сетевыми ограничениями. Вот когда регулирование в DevTools пригодится.
Браузеры на базе Chromium (Chrome, Edge, Opera, …) также имеют возможность имитировать Офлайн в том же меню. Похожая опция есть и в Firefox, но совсем в другом месте (Меню > Еще > Автономная работа).
В настоящее время реализация Firefox имеет одно преимущество перед Chromium: как только активируется «работа в автономном режиме», все соединения, включая WebSocket, разрываются.
В браузерах на основе Chromium, хотя обычные запросы также отклоняются, WebSocket остается открытым. Это означает, что в настоящее время невозможно смоделировать потерю сетевого подключения с помощью этого инструмента. С другой стороны, @MsEdgeDev в настоящее время изучает возможность изменить это.
Экраны
В настоящее время адаптивный дизайн является очень важной темой, что делает тестирование с разным размером экрана/браузера наиболее распространенным методом моделирования среды.
Обычный тест, который все, вероятно, делают несколько раз в день, состоит в простом изменении размера браузера для базовой проверки. Однако инструменты разработчика идут немного дальше и позволяют проверить точное разрешение конкретных устройств простым щелчком мыши.
Глядя на два снимка экрана выше, вы могли заметить, что в обоих браузерах представление симулятора также имеет прямой доступ к тем же настройкам виртуальной сети, которые мы использовали ранее из инструментов разработчика.
Хотя этот инструмент отлично подходит для проверки веб-сайта в точном разрешении конкретных устройств, явное наименование устройств в обоих представлениях симулятора может немного ввести в заблуждение, поскольку они не учитывают движок браузера устройств.
Устройства
Итак, как мы можем проверить разные двигатели?
Ну, проще всего тестировать «настольные» движки портативных браузеров, таких как Chromium и Firefox, которые доступны на многих платформах (Windows, MacOS, Linux).
Тестировать с такими браузерами, как Safari (WebKit), которые доступны только на одной платформе (в данном случае MacOS), становится сложнее.
Мобильные браузеры также несколько сложнее. В то время как несколько мобильных браузеров используют тот же движок, что и их настольные аналоги. Есть еще некоторые отличия, некоторые из которых даже добавлены в браузеры специально для повышения производительности и экономии заряда батареи.
Покупка нескольких устройств только для этого, как правило, не вариант. Это было бы слишком дорого, особенно если вы работаете с удаленной командой, где всем нужен доступ к этим устройствам.
Однако в настоящее время есть решение этой проблемы, когда мы можем получить доступ к огромному списку реальных устройств через то, что я бы назвал облачной абстракцией.
Такие сервисы, как lambdatest и browserstack, позволяют нам запускать наше приложение на множестве устройств и движков с доступом к инструментам разработчика. мы даже можем использовать эти сервисы в CI для автоматизации тестирования, если захотим.
Вывод
Существует множество инструментов, которые помогут нам убедиться, что большинство пользователей получат хороший или, в худшем случае, достойный опыт использования нашего веб-сайта.
Теперь все сводилось к моделированию и тестированию. Перед всем этим всегда полезно настроить список браузеров и объединить его с кучей линтеров и прекомпиляторов, чтобы убедиться, что код, который мы пишем, уже максимально адаптирован к браузерам, которые мы хотим поддерживать в будущем. первое место.
