Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Дайте оценку такому подходу к кроссбраузерному тестированию (DDT)

cross-browser
selenium
webdriver
Теги: #<Tag:0x00007f7b6584c668> #<Tag:0x00007f7b6584c398> #<Tag:0x00007f7b6584c258>

(Alexander) #1

Доброго времени суток. Есть вопрос по кроссбраузерному тестированию. Сам я еще не сталкивался по работе с подобной задачей, но для себя, понимая что такая задача рано или поздно встанет, бывало, задумывался. Как только встает вопрос кроссбраузерности, так сразу везде встречаешь упоминания SauceLab или Selenium Grid. К чему пока пришел сам, опишу ниже, а вопрос топика в следующем: насколько описанный мною ниже подход имеет право на жизнь, возможно кто-то может указать на принципиальные недостатки, которые я смогу выявить только в процессе реализации на гипотетическом проекте.

Берется стандартный метод для объявления вебдрайвера, принимающий в себя String как триггер для определения требуемого драйвера:

public static void runDriver(String browser) {
if (browser.equals("chrome")) {
    System.setProperty("webdriver.chrome.driver", "C:\\Selenium\\chromedriver.exe");
    driver = new ChromeDriver();
} else if (browser.equals("firefox")) {
    driver = new FirefoxDriver();
} else if (browser.equals("ie")) {
    System.setProperty("webdriver.ie.driver", "C:\\Selenium\\IEDriverServer.exe");
    driver = new InternetExplorerDriver();
}
}

и стандартный data-driven test:

import Common.TestHelper;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;

import java.util.Arrays;
import java.util.Collection;

@RunWith(Parameterized.class)
public class CrossbrowserDdt {
private String browser;

@Parameterized.Parameters
public static Collection testData() {
    return Arrays.asList(new Object[][]{
            {"chrome"},
            {"firefox"},
            {"ie"}
    });
}

public CrossbrowserDdt(String browser) {
    this.browser = browser;
}

@Test
public void multipleTests() {
    TestHelper.runDriver(browser);
    TestHelper.quit();
}
}

Таким образом каждый тест будет прогоняться три раза, по очереди в каждом из браузеров. Достаточно просто и удобно на первый взгляд, как по-мне. Какие потенциальные проблемы вижу я.

Во-первых, возможны проблемы с версионностью и доступностью драйверов и прочие environmental issues на удаленном сервере, не всегда возможно им управлять и иметь оперативный доступ, обращаться к вебдрайверу в облаке наверное проще. Никакого IE на линуксовом сервере само собой не будет.

Во-вторых отчетность. Подобные тесты будут помечены в репорте как ‘someTestName[0]’, ‘someTestName[1]’, ‘someTestName[2]’. И хоть последовательность всегда будет идентичной - 0 - всегда хром, 1 - всегда мозилла и 2 - всегда эксплорер, все-таки встанет задача эту информацию как-то более приемлемо группировать.

В-третьих, что-то было в голове, но вылетело. В общем буду благодарен за полезные советы.


(Sergey Pirogov) #2

Первое, что я вижу - нельзя задавать браузеры через проперти. Как к примеру отрубить IE или FF. Если скажем я хочу прогнать просто в одном браузере.Тесты у вас перезапускаемые? Если скажем тест упадет в одном из браузеров это как-то может вызвать фейл и в другом, так как состояние системы было изменено. Ну и да, это не совсем дата-дривен.


(Alexander) #3

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

Шаблон взят из Selenium Cookbook, Chapter 4 - Data-driven Testing, Creating a data-driven test using JUnit, я просто несколько переменных поменял на одну - browser. В остальном это классический пример data-driven теста, приспособленного для наших кроссбраузерных нужд.


(Sergey Korol) #4
  • Ваш код не масштабируем. При текущем подходе, максимум, чего вы добьетесь, - последовательный локальный запуск в разных браузерах.
  • Идея параметризации типа браузера - правильная, но реализация… Тесты вообще ничего не должны знать о драйвере или браузерах. К тому же, не будете же вы дублировать одну и ту же конструкцию во всех тестовых классах?
  • Основная идея DDT никак не связана с параметризацией браузера. Механизм так называемых data providers применяют непосредственно к тестовым данным, а не конфигурации запуска.
  • Работая с гридом, пути к бинарникам задаются в конфигурации самого грида (или на уровне system path). Хардкодить абсолютные пути в коде - моветон.
  • Попробуйте testng вместо junit. Работать с конфигурациями в рамках задачи масштабирования будет проще. Не говоря уже о DDT.

(Jane Tymoschuk) #5

А по поводу именования, так в аннотации Parameters есть поле имени, туда можно подставить {0} и будет выводиться имя браузера