Selenium WebDriver: quit или close?

В этой статье речь пойдет о том как правильно останавливать работу драйвера или, другими словами, как закрыть браузер.
Запускается Selenium driver автоматически во время инициализации, для запуска у него нет отдельного метода.

FirefoxDriver driver = new FirefoxDriver();

Если по какой-либо причине запуск браузера не произойдет, то возникнет исключение и вебдрайвер не создастся.
А вот остановка его работы в определенное время ложится на разработчика тестов. WebDriver содержит два метода – quit() и close(), которые можно использовать для остановки работы браузера.

• void close() — закрывает только одно текущее окно, и в случае, если это было последнее открытое окно — закрывает браузер.
• void quit() — закрывает все открытые окна, завершает работу браузера и сервисов, и освобождает все ресурсы.

Поэтому для корректного завершения работы драйвера после выполнения теста используйте метод quit().

driver.quit();

Если же вам нужно закрыть отдельное открытое окно, используйте метод close(). Обратите внимание, что метод close() после закрытия одного из окон не передает управление в предыдущее открытое окно, Вы должны сделать это самостоятельно:

// переключаемся в новое окно driver.switchTo().window(newWindowHandler); // закрываем его driver.close(); // возвращаемся в предыдущее окно driver.switchTo().window(oldWindowHandler);

Если вы хотите просто уйти с текущей страницы, но не закрывать ее или браузер, можете просто использовать:

driver.get("");

Нагрузочное тестирование, используя облачный сервис

Всем доброго дня!
Недавно для одного из заказчиков проводил нагрузочное тестирование веб портала. Результат оказался достаточно неожиданным, веб сайт лег раньше, чем предполагалось:) Посему в данной статье хочу поделится опытом проведения нагрузочных тестов, используя инструмент Visual Studio и облачный сервис Visual Studio Team Services (бывший Visual Studio Online).

Зачем проводить нагрузочные тесты

Но прежде, чем мы начнем погружаться в технические детали, немного теории. Зачем вообще проводить нагрузочные тесты? Вопрос достаточно важный, и в зависимости от того, как вы на него отвечаете, выбирается та или иная стратегия тестирования нагрузки.
Во многих случаях нагрузочные тесты проводят для того, чтоб определить максимальное количество пользователей, которые могут обслуживаться на выбранном сервере. Соответственно, нагрузочные тесты проводят перед запуском продукта на продуктиве. Казалось бы, вроде ничего криминального... Но подобный подход не дает вам ответа на вопрос: а можно ли на данном сервере обслужить большее количество пользователей? Возможно, нужно немного оптимизировать код, и сервер сможет корректно обслуживать большее количество запросов?
Конечно, можно перед запуском проекта покопаться в коде, найти слабые места, попробовать поправить, но все же не самый эффективный способ оптимизации, так как отсутствуют адекватные метрики. Откуда вы знаете, что улучшения, которые вы сделали, достаточны, чтобы сказать: лучше это приложение работать не будет. Что такое «лучше»? Где эталон? Насколько далеко мы от него ушли?
Задавая эти вопросы, мы плавно переходим во второй подход проведения нагрузочных тестов. Нагрузочные тесты нужно проводить регулярно во время работы над проектом (например, в конце спринта). Причем начинать нужно с момента, когда у вас готов каркас. Результат проведения нагрузочного теста на эталонном сервере, куда вы публикуете каркас вашего приложения, — это и есть эталон. Дальнейшие измерения вам покажут изменения относительно эталона. И если изменения драматические, это повод провести дополнительные работы для оптимизации кода. Проще искать проблемы с производительностью на ранних этапах, нежели пытаться перелопатить весь проект в конце.

Оборудование для генерации нагрузки

Есть еще одна проблема проведения нагрузочных тестов. Это оборудование (сервера), которое будут генерить нагрузку. Проблема в том, что для проведения адекватных нагрузочных тестов рядом с эталонным сервером, приближенным по параметрам к боевому, нужно поставить такой же или лучше для генерации нагрузки. Более того, вы рискуете получить неадекватные результаты в том случае, если ваш боевой сервер торчит наружу по порту 80, а тестируете вы его используя локальную сеть организации, где стоит ваш генерирующий нагрузку сервер.
Попробуйте обосновать для службы закупок покупку сервера, который вы собираетесь использовать раз в 2 недели один-два часа. Очень часто в этом случае задействуют сервера, которые не используются (устаревшие), либо на время тушат какие-то приложения внутри организации, дабы задействовать высвободившиеся ресурсы под нагрузочные тесты (такой сценарий большая редкость, но на своем опыте видал и такое). В обеих вариантах есть свои недостатки. Наприем, не использующееся сервера могут либо списать, либо отключить для экономии электропитания, либо снять с поддержки и т.д. А процесс согласования прерывания работы какого-то приложения внутри организации — это ад для всех.
В общем, вы, наверное, поняли, на что я намекаю: надо использовать облачные ресурсы с оплатой по часам. На серверы нужно залить и настроить необходимый софт для генерации нагрузки (иногда это не тривиальная задача).

Тестирование с помощью Visual Studio Team Services

Я предлагаю для генерации нагрузки использовать Visual Studio Team Services (бывший Visual Studio Online). Итак, что нам надо:
— Аккаунт в Visual Studio Team Services. >Бесплатно его можно взять тут.
— Visual Studio Enterprise. Триальная версия тут.
Итак, приступим:
После того, как вы создали бесплатный аккаунт в Visual Studio Team Services, вам необходимо создать новый проект, указав название и систему контроля версий, которую вы будете использовать (для этой демонстрации не принципиально, какую выбирать):