Как тестировать Safari 26.6 в Windows: руководство по приёмке научных сайтов в 2026 году

Safari 26.6 — это не набор пользовательских строк, который можно достоверно воспроизвести сменой User-Agent. Приёмка должна проверять реальное выполнение страницы в Safari и WebKit. На Windows можно отсеять часть ошибок CSS, проверить базовую доступность URL и сравнить серверные ответы, но нельзя объявлять сайт совместимым только на основании такой проверки.

Сначала зафиксируйте границу проекта:

• какие страницы входят в научный рабочий процесс;
• какие роли должны войти в систему — исследователь, руководитель, оператор или администратор;
• какие типы данных используются — таблицы, изображения, архивы, CSV или другие контрольные файлы;
• какие действия обязательны для результата — поиск, фильтрация, запуск расчёта, просмотр графика, загрузка и экспорт;
• какие функции относятся только к iPhone или iPad.

Подмена User-Agent не меняет движок браузера. Режим устройства в Chromium помогает проверить ширину экрана и отдельные точки адаптивной вёрстки, но не поведение Safari. Responsive Design Mode полезен для просмотра разных размеров окна, однако не равен испытанию iPhone или iPad. Официальное описание режима указывает на его назначение как инструмента проверки адаптивного представления, а не как полной замены мобильного устройства — документация Apple по Responsive Design Mode.

На дату 2 сентября 2026 года стабильный Safari 26.6 уже опубликован: в официальных примечаниях указана дата выпуска 27 июля 2026 года — Safari 26.6 Release Notes. Safari 27 в этой инструкции не рассматривается как стабильная основа приёмки. Последняя проверка актуальности выполнена 2 сентября 2026 года по официальным материалам Safari Release Notes и Safari Developer Documentation.

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

Сформируйте короткую матрицу. Она должна связывать функцию, роль, данные, ожидаемый результат и способ доказательства. Например, для страницы анализа это может выглядеть так:

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

До начала проверки определите критерии:

1. Блокирующий дефект — невозможно войти, выполнить обязательный расчёт или получить результат.
2. Дефект с обходом — сценарий выполняется другим документированным способом, но требует исправления.
3. Незначительный дефект — визуальная или второстепенная проблема, не меняющая научный результат.

Такой уровень детализации защищает команду от спора «страница открывается, значит всё работает». Для приёмки важен весь путь от входа до проверяемого файла или вывода.

Перед ручным тестированием запишите среду без секретов. В журнале должны быть:

• версия macOS;
• версия Safari;
• дата последнего обновления;
• адрес тестового стенда;
• тип подключения к удалённому Mac;
• идентификатор сборки сайта;
• версия тестовых данных;
• часовой пояс и локаль, если сайт форматирует даты или числа.

Версию Safari проверяйте непосредственно в меню браузера на удалённом Mac, а не по сообщению браузера Windows. Версия macOS также должна быть получена с самого Mac. Сохраните текстовую запись и снимок экрана без логинов, токенов и содержимого закрытых проектов.

Включение инструментов разработчика выполняйте только в тестовом профиле. Официальная инструкция Apple описывает включение меню Develop и связанных возможностей — настройка функций разработчика Safari. После этого откройте Web Inspector и убедитесь, что доступны консоль, сетевые запросы, хранилище и средства анализа страницы. Состав возможностей и расположение пунктов могут меняться, поэтому перед повторной кампанией сверяйтесь с официальным разделом Safari Developer Tools.

Проверка готовности занимает несколько последовательных действий:

1. Откройте точный адрес тестового стенда.
2. Проверьте сертификат и отсутствие предупреждения о небезопасном соединении.
3. Убедитесь, что открывается именно тестовый, а не производственный проект.
4. Войдите отдельной учётной записью с минимальными правами.
5. Загрузите небольшой обезличенный файл.
6. Скачайте тестовый результат и убедитесь, что файл не повреждён.
7. Очистите историю, загрузки и данные сайта после проверки канала.
8. Запишите исходное состояние браузера до изменения настроек.

Если уже на этом этапе не открывается адрес, не называйте проблему несовместимостью Safari. Причиной может быть DNS, сертификат, межсетевой экран, разрешение аккаунта или ограничение удалённого рабочего места. Сначала классифицируйте доступность, затем переходите к браузерному поведению.

Ручная проверка нужна до автоматизации. Скрипт может подтвердить, что кнопка была нажата, но не объяснит, почему пользователь не видит ошибку, почему график обрезан или почему скачался пустой файл.

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

Порядок проверки:

1. Откройте стартовую страницу в Safari 26.6 и обновите её без использования старого кэша, если это предусмотрено процедурой стенда.
2. Проверьте заголовки, шрифты, переносы, таблицы и горизонтальную прокрутку.
3. Войдите под каждой обязательной ролью.
4. Выполните поиск и примените фильтр к контрольному набору.
5. Заполните форму сначала корректным, затем заведомо ошибочным значением.
6. Откройте график, переключите диапазон и проверьте подписи.
7. Загрузите небольшой файл и дождитесь явного подтверждения операции.
8. Скачайте результат и откройте его вне браузера.
9. Повторите ключевые действия с клавиатуры, без мыши.
10. Зафиксируйте консольные ошибки, сетевые ответы и состояние хранилища.

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

Проверяйте не только положительный путь. Научный интерфейс должен корректно сообщать о просроченной сессии, пустом результате, недопустимом формате, слишком большом файле и отказе в доступе. Если сервер возвращает ошибку, отделите её от ошибки отображения: одна проблема находится в API или правах, другая — в обработке ответа Safari.

После ручного прохода выберите действия, которые повторяются при каждом выпуске:

• вход и переход в рабочий проект;
• поиск записи;
• применение фильтра;
• заполнение формы;
• экспорт результата;
• выход и очистка тестового состояния.

Не пытайтесь сразу автоматизировать субъективную оценку графика или все пиксельные отличия. Автоматизация должна быстро показывать, что критический путь перестал работать. Визуальную проверку оставьте ручному этапу или отдельному инструменту сравнения, если его правила заранее согласованы командой.

Safari использует встроенный safaridriver. Процедуру включения удалённой автоматизации и запуска тестов описывает официальное руководство Apple по WebDriver в Safari. Команды запуска и параметры зависят от версии macOS и выбранной библиотеки, поэтому не копируйте старый пример без проверки на целевом Mac.

Минимальная последовательность подготовки выглядит так:

1. Откройте Safari на тестовом Mac.
2. Включите функции разработчика.
3. Разрешите удалённую автоматизацию в настройках Safari.
4. Проверьте доступность safaridriver локальным тестовым запуском.
5. Запустите один сценарий открытия страницы и завершения сессии.
6. Добавьте вход, поиск и экспорт только после успешного минимального запуска.
7. Сохраните журнал драйвера и снимок экрана при сбое.
8. После прогона удалите созданные записи и завершите сессию.

Команды должны выполняться на доверенном Mac или через закрытый канал. Не выставляйте порт автоматизации непосредственно в Интернет. Доступ к машине ограничьте учётными записями команды, а секреты передавайте через защищённое хранилище, а не через файл сценария.

W3C WebDriver определяет общий протокол управления браузером, но конкретная реализация и ограничения Safari остаются важными для тестовой среды — стандарт W3C WebDriver. Поэтому в отчёте указывайте не только название библиотеки, но и Safari, macOS, драйвер, сборку теста и способ подключения.

Удалённый Mac удобен для воспроизведения, но он добавляет собственные переменные. Задержка указателя, задержка передачи изображения и временная потеря соединения могут создать впечатление, что сайт медленный. Это нельзя записывать как измерение производительности Safari.

Разделяйте наблюдения на три группы:

• Safari-специфичное — ошибка появляется в Safari 26.6 при тех же данных и исчезает в другом браузере;
• дефект сайта — одинаково воспроизводится в нескольких браузерах или на серверном уровне;
• артефакт удалённого доступа — меняется при задержке соединения, но не подтверждается локальным журналом браузера или сетевым запросом.

Для каждого предполагаемого дефекта повторите сценарий после обновления страницы, в чистом тестовом профиле и с тем же обезличенным набором. Если ошибка исчезла после очистки данных сайта, это ещё не доказательство несовместимости: возможно, проблема в миграции кэша, устаревшем Service Worker или неправильной инвалидизации сессии.

Автоматический тест тоже требует контроля состояния. Перед запуском очищайте созданные записи, восстанавливайте исходный проект и проверяйте наличие контрольного объекта. Иначе сценарий может «пройти» только потому, что предыдущий запуск уже создал нужные данные.

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

Сверьте:

• успешный вход и правильную роль;
• полноту найденных записей;
• состояние формы после отправки;
• значения и подписи визуализации;
• содержимое экспортированного файла;
• сообщения при ошибке;
• повторяемость результата после нового входа;
• поведение в другом поддерживаемом браузере.

Решение оформляйте условием, а не общим впечатлением:

• есть блокирующий дефект — выпуск Safari-версии останавливается;
• есть обходной путь — выпуск возможен с зафиксированной инструкцией и сроком исправления;
• есть только визуальное отличие без влияния на результат — выпускайте с записью в список улучшений;
• нет воспроизводимого доказательства — тест повторяется на том же наборе данных, а не закрывается фразой «не удалось повторить».

В пакет передачи включите версию браузера и macOS, дату проверки, матрицу сценариев, тестовые аккаунты без секретов, контрольные файлы, логи, скриншоты и список известных ограничений. Для лаборатории это превращает разовую проверку в процедуру, которую сможет повторить другая смена или следующая исследовательская группа.

Safari Technology Preview подходит для раннего обнаружения будущих изменений, но не заменяет приёмку стабильного Safari 26.6. Его назначение и текущие заметки следует отслеживать отдельно в официальных материалах Safari Technology Preview. Результат предварительной версии помечайте как подготовительный, а не как основание для выпуска.

Можно ли установить Safari 26.6 непосредственно на Windows?
Нет. Для итоговой проверки нужен реальный macOS Safari. Установка неподдерживаемой копии, User-Agent и профиль мобильного устройства могут дать ложное чувство совместимости. На Windows оставляйте предварительный скрининг, а ручное воспроизведение переносите на удалённый Mac.

Как поступить, если в лаборатории нет Mac?
Соберите матрицу сценариев на Windows, затем арендуйте удалённый Mac на период тестирования. Подключитесь через разрешённый канал, создайте отдельный профиль и выполните тот же путь от входа до экспорта. Такой вариант подходит короткому проекту, когда покупка физического устройства не оправдана.

Можно ли считать Responsive Design Mode тестом iPhone?
Нет. Режим проверяет адаптивное представление окна на Mac. Он не воспроизводит полностью сенсорный ввод, мобильное хранение, клавиатуру и особенности iOS или iPadOS. Страницы с мобильными разрешениями, жестами или камерой проверяйте на соответствующем устройстве.

Что нужно для WebDriver на удалённом Mac?
Нужны доступ к целевому Mac, включённые функции разработчика, разрешённая удалённая автоматизация, safaridriver, тестовый аккаунт и стабильный набор данных. Начинайте с одного сценария. После этого добавляйте очистку состояния, журналы и снимки сбоя. Канал управления нельзя публиковать в открытой сети.

Какие функции научного сайта нельзя пропускать?
Минимальный набор — роли и вход, поиск, фильтры, формы, таблицы, графики, загрузка, скачивание, экспорт и клавиатурная навигация. Если сайт запускает расчёт, проверяйте не только кнопку, но и итоговые значения на контрольном наборе. Ошибка интерфейса и ошибка результата должны иметь разные записи.

• [ ] Зафиксированы macOS, Safari 26.6, сборка сайта и дата проверки.
• [ ] Проверен точный адрес тестового стенда и сертификат.
• [ ] Используются отдельные аккаунты без производственных прав.
• [ ] Реальные сведения участников исследования исключены.
• [ ] Составлена матрица ролей, страниц, данных и обязательных действий.
• [ ] Выполнен ручной путь от входа до экспорта.
• [ ] Проверены консоль, сеть, хранилище и ошибки загрузки.
• [ ] Отдельно проверены клавиатурные действия и сообщения об ошибках.
• [ ] Responsive Design Mode не выдан за тест iPhone или iPad.
• [ ] Автоматизированы только стабильные и повторяющиеся сценарии.
• [ ] Для WebDriver сохранены логи, снимки сбоев и сведения о среде.
• [ ] Служба автоматизации не выставлена в Интернет.
• [ ] После теста удалены временные записи и очищены секреты.
• [ ] Один представительский научный сценарий повторён с контрольными данными.
• [ ] Каждый дефект отнесён к блокирующему, обходному или несущественному.
• [ ] Отчёт позволяет другой команде повторить проверку.

Если сравнивать этот процесс с ожиданием локального Mac в лаборатории, Windows-подход без удалённого оборудования имеет три постоянных недостатка: нет настоящего движка Safari, нельзя достоверно проверить macOS-инструменты разработчика и сложнее повторить тот же профиль среды для всей команды. Для короткого исследовательского проекта разумнее взять у MESHLAUNCH полностью управляемый удалённый Mac, провести ручную приёмку Safari 26.6 и затем решить, нужен ли доступ на следующий цикл. Подходящие варианты доступа и оформления собраны на странице MESHLAUNCH для удалённого Mac, а после подтверждения требований можно перейти к оформлению аренды Mac. Для длительной стабильной нагрузки или задач, которым необходимы физические порты и локальные периферийные устройства, собственный Mac всё ещё может быть практичнее.