testomat.io управление авто тестамиОчень все подозрительно, надо фреймворк и тесты анализировать, как они написаны. Как выделяется драйвер, как хендлятся исключения, как ожидания реализованы. может у вас там действительно слипы стоят и ждут )))
А может и не стоят.
А может и неправильно, а может и правильно
В общем если есть какая-то конкретика, которую можно проверить или каким-то образом отловить, то почему бы и нет? Что имеется в виду? Слипы не использую без всяких “может” насчёт остального - “шаринг драйвера написан неправильно” - вот это как?
Потом насчёт взаимодействия с несуществующим элементом - не делаю так, это долго.
ну ты держись там =))
А по-моему ничего подозрительного. Во-первых совершенно очевиден тот факт, что запуск в один поток через remotedriver должен идти существенно дольше чем локальный запуск через драйвер. Ну так на самом деле и есть. Выигрыш должен наступить при распараллеливании, но опять же ожидать что он будет пропорционален количеству нодов можно только при идеальных условиях и неограниченных ресурсах. При росте количества нодов требования к ресурсам играют всё большую роль и при ограниченном их количестве происходит ускорение из-за распараллеливания и одновременно замедление из-за повышения нагрузки. Надо что-то усилить. Самое главное понять что именно. Потому что вариант “закинуть все тесты на виртуалки Амазон с 20 гигами оперативки на каждой ноде” в данный момент недостижим.
Дмитрий, покажите как вы инициализируете драйвер, какой он у вас (статик, не статик, может, финал даже), и как вы его используете в тесте.
Да пожалуйста. Статик бы не работал. Не статик.
@Parameters({"browser", "runType", "driverPath", "hub"})
@BeforeMethod
public void initDriver(String browser, @Optional("") String runType, @Optional("") String driverPath, @Optional("") String hub) throws Exception {
DesiredCapabilities capabilities;
browser = browser.toLowerCase();
if (!(driverPath.isEmpty() || driverPath == null)) {
System.setProperty("webdriver.chrome.driver", Paths.get(driverPath).toString());
}
if (browser.equals("chrome")) {
ChromeOptions options = new ChromeOptions();
options.addArguments("--test-type");
options.addArguments("no-sandbox");
options.addArguments("--disable-extensions");
if (!(windowSize.isEmpty() || windowSize == null)) {
options.addArguments("window-size=" + windowSize);
}
capabilities = DesiredCapabilities.chrome();
capabilities.setCapability(ChromeOptions.CAPABILITY, options);
capabilities.setBrowserName("chrome");
} else if (browser.equals("ff")) {
..
} else if (browser.equals("ie")) {
..
} else {
..
}
if (runType.equals("remote")) {
driver = new RemoteWebDriver(new URL(hub), capabilities);
} else {
..
}
if (windowSize.isEmpty() || windowSize == null) {
driver.manage().window().maximize();
}
switch (logLevel) {
case "INFO":
((RemoteWebDriver) driver).setLogLevel(Level.INFO);
break;
case "ALL":
((RemoteWebDriver) driver).setLogLevel(Level.ALL);
break;
case "CONFIG":
((RemoteWebDriver) driver).setLogLevel(Level.CONFIG);
break;
case "FINE":
((RemoteWebDriver) driver).setLogLevel(Level.FINE);
break;
case "FINER":
((RemoteWebDriver) driver).setLogLevel(Level.FINER);
break;
case "FINEST":
((RemoteWebDriver) driver).setLogLevel(Level.FINEST);
break;
case "OFF":
((RemoteWebDriver) driver).setLogLevel(Level.OFF);
break;
case "SEVERE":
((RemoteWebDriver) driver).setLogLevel(Level.SEVERE);
break;
case "WARNING":
((RemoteWebDriver) driver).setLogLevel(Level.WARNING);
break;
default: ((RemoteWebDriver) driver).setLogLevel(Level.FINE);
}
}
Вы же писали что ноды находятся на отдельных физических машинах? или нет?
Да. Но больше нодов - больше запросов к серверу приложения, больше запросов к серверу БД. Сервера тоже являются ресурсами. Сервера в моём случае, естественно не продакшн, а весьма посредственные локальные виртуалки. Мне кажется в этом проблема. На 7 нодах результат по времени выполнения - те же 9 часов. По прохождению - дополнительно 3 фейла по таймаутам.
В таком случае, у вас проблемы с приложением, а не с тестами ))
JMeter’ом пробовали грузить, как деградирует производительность изучали?
Возможные факторы(коротко):
- Сеть
- Производительность машин (дженкинс, грид, годы)
- Особенности приложения
Теперь длинно:
-
Вы сравнивали пинг с локальной машины до тачки с приложением напрямую и через всю цепочку дженкинс-грид-нода-приложение?
Вполне очевидно что он будет больше.
Особенно если всё это находится не в одной локальной сети. Если напрямую 10мс, а через всю цепочку - 100мс. То это может давать отставание следующим образом: страницы отдаются дольше + все ожидания появления элементов (а их очень много) работают чуть дольше. Конечно, не в 10 раз, но надо смотреть какой пинг намеряете. -
Если машина на которой запускаешь локально мощнее нод, то тут будут ещё задержки. Исходя из того, что на одной ноде запуск нескольких браузеров оказывается дольше, то могу предположить, что приложение не из лёгких и соответственно процессор и оперативка могут сильно влиять на скорость прогона. Плюс не надо забывать, что селениум сервер на нодах тоже ресурсы потребляет.
-
Надо ещё поисследовать как приложение работает от нескольких потоков. Пробовал локально в нескольких браузерах прогонять? Вдруг там (к примеру) в БД что-то лочится и не обрабатываются остальные запросы. Могут быть варианты.
Что делать:
-
засунуть дженкинс, сервер с приложением, Бд, ноды в одну локалку или посмотреть в сторону контейнеров и может вообще грид не поднимать.
-
помощнее железо
-
исследовать и думать =)
Всё в одной локальной сети.
Ну собственно пришёл к тем же выводам и тем же и занимаюсь.
Хочу приложение перенести с виртуалки на железную машину и посмотреть что будет. Но это не быстро. Как получится - обязательно поделюсь результатами. Может кому интересно будет.