Опрос: сколько в среднем UI тестов в вашем(их) проекте(ах)?

(Alex Okrushko) #9

Не совсем понятно что имеется в виду под “UI тестами”. Любые тесты, которые работают с UI интерфейсом? Потому что на самом деле я разделяю такие тесты на:

  1. Интеграция Клиента и Фронтэнда. Тесты, где бэкэнды являются Mockам. Соответственно валидация идет с обеех сторон: со стороны бэкэнда, когда Клиент что-то посылает через Фронтэнд и со стороны Клиента, когда имитирую ответы с бэкенда.
  2. Фунциональные тесты Клиента. Тесты, которые не затрагивают бэкэнд вообще (только Клиента или Клиент <-> Фронтэнд), но они больше чем обычные юнит-тесты Клиента.
  3. Энд-то-энд. Тесты, где Фронтэнд связан с бэкэндами, т.е. весь environment полностью связан.

Мне кажется, что нельзя их все месте в кучу связывать, потому что подходы к их реализации очень разные. (Хотя 1 и 2 можно связать вместе).

(Дмитрий Жарий) #10

На мой взгляд, имееться в виду именно e2e тесты, т.е. автоматизация тестирования через UI

(Mykhailo Poliarush) #11

@alex_okrushko как правильно заметил @dzhariy подразумевалось end2end тесты

(Alex Okrushko) #12

Я очень сильно надеюсь, что люди не делают упор на e2e тесты. Очень надеюсь…

(Mykhailo Poliarush) #13

Ну вот хочется увидеть цифры

(asolntsev) #14

Точно! Таких end-2-end должно быть настолько мало, насколько это возможно. И автоматизировать такие тесты практически не имеет смысла, т.к. все эти системы наверняка невозможно контролировать из тестов (запускать/останавливать/менять данные).

(Alexey Bulat) #15

У нас ~600 end-2-end историй (каждая новая фича вносит еще 3-10), продолжительность запуска каждой примерно 1-3 минуты, т.к. это не просто проверка состояния контрола, а проверка пользовательского сценария. Оптимизация времени запуска имеет у нас в данный момент первый приоритет. Задачу решаем распараллеливанием тестов. Но все начинает усложняться тем что с этого года начинаем саппортить еще 3 браузера и их разные версии :slight_smile: таким образом получим все что имели умноженное на X.

(Alex Okrushko) #16

Цифры не важны. Важны пропорции.

(Serhii Tanchenko) #17

ага :slight_smile:

(Serhii Tanchenko) #18

у нас цифры следующие:
e2e tests: 21
integration tests: 56
unit tests: 90

(Dmitry Bogatko) #19

подскажите, за счет чего удается достичь такой маленькой продолжительности запуска 424 тестов. Можете привести пример обезличенного среднестатистического теста у вас на проекте?

(Dmitry Bogatko) #20

А как планируется учесть процент уникальных темтов или наоьорот дэйтадривен? По факту нужно понять что хотим узнать опросом? Величину среднего проекта или размер среднего запуска? Например на проекте ожет быть 300 уникальных тестов, но на запуске все они парметризуются и в конечном счете запускается 2500.

(asolntsev) #21

Привет!
За счёт мы достигает такой скорости тестов, я рассказывал подробно на SelenimCamp и SQA Days.
Если вкратце - эмуляция медленных внешних систем, in-memory база данных, встраивание хаков в систему, чтобы тесты могли попадать сразу нужным пользователем на нужную страницу без многократного прокликивания всей цепочки.

Вот пример теста для интернет-банка БСПБ:

  @Test
  public void invalidLoginShowsDirectLinkToResettingPassword() {
    loginFirstStep("blahblah");
    $(".alert-error").shouldBe(visible).shouldHave(text(label("Secure.invalidLogin")));
    $(".alert-error > a").click();
    $("#reset-password-dialog").shouldBe(visible);
  }
(Mykhailo Poliarush) #22

Эта тема отлеплена. Она больше не будет отображаться наверху списка тем раздела.

(Mykhailo Poliarush) #23

Стоит подытожить результаты голосования состоянием на момент когда у нас 100 проголосовавших

Имя файла изображения747x592 43.9 KB

Серия at.info опросов по автоматизации тестирования ПО
(Ant1dot) #24

У нас
Кол-во уникальных тестов 7459
Которые тестируют интеграцию полную.
Проекту, лет 5 вроде бы.
Есть еще отдельные тесты верстки, базовых компонент и тд.

(Konstantin) #25

50 - 100

(Goshko Nazar) #26

Извините, но это bad-way подход, так как задача тестов - эмулировать поведение пользователя… а транзакционные запросы вы что, из базы берете?

(asolntsev) #27

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

Каждый тест должен тестировать только что-то своё. Во всех книжках ведь пишут, что тесты долнжы быть независимые и т.д.

  1. То есть, тест для логина должен эмулировать действия пользователя при логине. Да. Заполнять логин, пароль, вот это всё.
  2. А тест для покупки телевизора должен эмулировать действия пользователя на странице покупки телевизора. А заполнять логин и пароль сто тысяч раз не должен, потому что эта функциональность уже протестирована в пункте 1.
(Goshko Nazar) #28

Ну, в целом я Вас понял, тут просто нужно разделять глубину выхода из тест-шагов.
Если касаемо логина, то вход выполняется единожды на сессию. Если навигация по сайту, то для каждого теста своя, И - главное, если она не касается самого теста (проверить товар в корзине, но ведь до корзины нужно дойти) - выносится или в фикстуру, как подготовочные шаги, или как фаст преддикат функция, которая говорит о возможности проведения теста (если я дошла до корзины - выполнить тест)

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