Сайт тестирования с белым списком IP-адресов с использованием автоматизации BrowserStack + облачный CI

У меня есть тестовая система (различные веб-страницы / веб-приложения), которая размещена в среде, доступной только через машины с IP-адресами, которые указаны в белом списке. Я контролирую белый список.

Наша CI-система размещена в облаке (Gitlab), поэтому виртуальные машины динамически вращаются по мере необходимости для запуска автоматических интеграционных тестов как части конвейера сборки.

Рассматриваемые тесты используют автоматизацию BrowserStack для запуска тестов на основе Selenium, что означает, что исходные IP-адреса запросов, управляемых автоматизацией BrowserStack, которые попадают в среду тестирования, являются динамическими, поскольку BS размещается в облаке. Кроме того, IP-адреса наших тестовых машин, которые вызывают / вызывают автоматизацию BrowserStack, также являются динамическими.

Вся система работала нормально до появления белого списка IP-адресов в тестовой среде. Поскольку белый список был включен, тесты BrowserStack больше не могут обращаться к URL-адресам среды (из-за невозможности занести в белый список динамические IP-адреса).

Я пытался заставить CI-управляемые тесты снова работать, используя функцию BS "Local Testing", описанную здесь https://www.browserstack.com/local-testing.

Я настроил выделенную виртуальную машину Linux со статическим IP-адресом (в облаке). Я установил и запускаю двоичный файл BrowserStackLocal.exe, используя наш ключ BS. Он запускается нормально и говорит, что подключился к BrowserStack через веб-сокет. Насколько я понимаю, это должно привести к тому, что все запросы http(s) и т. Д., Которые поступают из моих автоматических тестов CI / BrowserStack, будут маршрутизироваться через этот автономный компьютер (через облако BS), в результате чего статический IP-адрес будет источником запросов видел в тестовой среде. Этот IP-адрес находится в белом списке.

Эта команда выполняется на выделенном / статическом IP-компьютере:

BrowserStackLocal.exe --{access key} --verbose 3

Я также попробовал ниже, но это не имело никакого видимого различия:

BrowserStackLocal.exe --{access key} --force-local --verbose 3

Тем не менее, это не похоже на работу? Либо через "живое" тестирование, если я попытаюсь получить доступ к тестовой среде напрямую через BrowserStack, либо через автоматизацию BS. В обоих случаях http(s) запрашивает все время и не может получить доступ к URL-адресам нашей тестовой среды. Также даже при включенном уровне ведения журнала --verbose 3 в процессе BrowserStackLocal.exe я никогда не вижу ни одного запроса, регистрируемого на автономном / статическом IP-компьютере, когда я пытаюсь запустить тесты различными способами.

Поэтому мне интересно, если это правильный способ решить эту проблему? Я неправильно понимаю, как это сделать? Нужно ли запускать BrowserStackLocal.exe, возможно, на том же компьютере с CI, который запускает автоматизацию BS? Это было бы проблематично, поскольку они также имеют динамические IP-адреса (в настоящее время).

Заранее благодарю за любую помощь!

РЕДАКТИРОВАТЬ / ОБНОВИТЬ: мне удалось заставить это работать!! (Вроде) - это немного медленно. Если я запускаю следующую команду на моем существующем выделенном / статическом IP-сервере:

BrowserStackLocal.exe --key {mykey} --force-local --verbose 3

Затем на другой машине (например, на моем ноутбуке разработчика), если я нажму на сервер веб-драйверов BS http://hub-cloud.browserstack.com/wd/hub и зайду на сайт http://www.whatsmyip.org/ чтобы увидеть какой IP-адрес возвращается, и он (в конце концов) вернулся с моим статическим IP-адресом машины! Проблема, однако, в том, что он был довольно медленным - 20-30 секунд для этого одного сайта, поэтому все еще ищем альтернативные решения. Обратите внимание, что для того, чтобы это работало, ваш тестовый код должен установить "локальный" флаг возможности браузера в "true" - например, для Node.js:

  // Input capabilities
  var capabilities = {
    'browserstack.local' : 'true'
  }

ОБНОВЛЕНИЕ 2: Уменьшение уровня ведения журнала --verbose в локальном двоичном файле (или полное отключение этого флага), казалось, улучшило ситуацию - теперь я получаю время ответа 5-10 секунд для каждого запроса. Это, возможно, придется сделать. Но это работает, как описано.

Источник

1 ответ

Решение

РЕШЕНИЕ: мне удалось заставить это работать - это только немного медленно. Если я запускаю следующую команду на моем существующем выделенном / статическом IP-сервере (обратите внимание, что добавление подробного ведения журнала, кажется, еще больше замедляет работу, поэтому флаг --verbose сейчас не используется):

BrowserStackLocal.exe --key {mykey} --force-local

Затем на другой машине (например, на моем ноутбуке разработчика), если я нажму на сервер веб-драйверов BS http://hub-cloud.browserstack.com/wd/hub и зайду на сайт http://www.whatsmyip.org/ чтобы увидеть какой IP-адрес возвращается, и он возвращается с моим статическим IP-адресом машин. Обратите внимание, что для того, чтобы это работало, ваш тестовый код должен установить "локальный" флаг возможности браузера в "true" - например, для Node.js:

  // Input capabilities
  var capabilities = {
    'browserstack.local' : 'true'
  }

Так что, пока немного медленно, это, возможно, придется сделать. Но это работает, как описано.

Источник
Другие вопросы по тегам