Вход в виртуальную машину для запуска тестов GUI при запуске теста
Мы настраиваем нашу автоматизацию так, чтобы она работала удаленно, чтобы мы могли начать включать их в сборки (вы знаете, всю вещь CI/CD). Это несколько важных автоматических тестов GUI, которые по понятным причинам нуждаются в активной виртуальной машине для запуска. Это не браузерные тесты, это на самом деле автоматические тесты для Windows-приложений, поэтому любая поддержка, которую Selenium предлагает на рассмотрение, для нас отключена.
Теперь перейдем к задаче - как я могу поддерживать работоспособность виртуальных машин без необходимости входа в них с помощью подключения к удаленному рабочему столу, чтобы они могли правильно выполнять тесты. В настоящее время я должен подключиться к ним со своего локального компьютера, а затем свернуть его, а затем начать сборку. Однако, как только я выхожу, виртуальная машина снова блокируется.
Я хочу, чтобы виртуальные машины работали полностью независимо от моей машины, поэтому я скептически относился к этому подходу, потому что казалось, что он все еще будет привязан только к моей машине. Практически любой в компании может войти в виртуальные машины со своего компьютера, используя свои учетные данные. Что я хотел бы сделать, так это программно подключиться к виртуальной машине во время моего глобального TestStartup, а затем отключиться на TearDown. Возможно ли это сделать? Кто-нибудь имел успех или сталкивался с подобными ситуациями в процессе интеграции? Мы используем инструмент под названием LeanFT и NUnit в качестве нашего тестового бегуна.,
1 ответ
Ваша идея войти в систему как часть теста немного хрупкая и подвержена нестабильности.
Вот настройка, которая работает для каждого инструмента автоматизации пользовательского интерфейса, который я использовал для Windows
- настроить виртуальную машину так, чтобы она не блокировалась / не спала / не находилась в спящем режиме и т. д.
- Избегайте использования RDC (отключите эту функцию даже для администраторов, если можете)
- Используйте только просмотр консоли для вашего сервера VM
- Ограничьте доступ к этим системам, используя разрешения на сервере виртуальных машин, чтобы только вы и ваша команда могли взаимодействовать с ними.
Вот почему это работает. Вы уже обнаружили, что, когда вы отключаете соединение RDP, сеанс блокируется, и ваша автоматизация перестает работать. Использование средства просмотра консоли vm по сути напоминает включение / выключение монитора, подключенного к системе. Поддерживая их все время и не спя, они всегда доступны для выполнения тестов.
Мы используем LeanFT, и для обеспечения стабильности наших тестов у нас есть задачи по настройке, чтобы проверить запущенные процессы, чтобы убить любые случайные отклонения времени выполнения, которые не были закрыты чисто после предыдущего запуска, а также любые случайные приложения, которые не были закрыты правильно после пробного запуска.
Подобные проблемы действительно раздражают автоматизацию пользовательского интерфейса.
В конце концов я нашел решение. Не совсем хорошо, но работает. Все, что я сделал, - это создал контейнер Docker и использовал его для автоматизации пользовательского интерфейса.
Контейнер состоит из SSHD, Xvfb и xfreerdp, которые позволяют подключаться к массивному удаленному RDP, а поскольку он использует xvfb, инструмент виртуального отображения, он требует небольших ресурсов.
Вот изображение, которое я создал для вашей справки.
https://hub.docker.com/repository/docker/ariyuan/ubuntu1604_ssh_rdp
Перед запуском автоматизации пользовательского интерфейса вам просто нужно указать контейнеру открыть удаленное RDP-соединение с машиной, на которой размещена ваша автоматизация пользовательского интерфейса. В этом случае ваш дисплей для автоматизации пользовательского интерфейса будет постоянно сохраняться во время выполнения (вы можете сделать все это с помощью Jenkins с параметрами для подключения к другому удаленному компьютеру)