t.me/atinfo_chat Telegram группа по автоматизации тестирования

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

общие вопросы
#9

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

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

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

#10

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

#11

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

#12

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

1 Симпатия
#13

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

#14

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

1 Симпатия
#15

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

1 Симпатия
#16

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

#17

ага :slight_smile:

#18

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

1 Симпатия
#19

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

#20

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

#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);
  }
1 Симпатия
#22

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

#23

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

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

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

1 Симпатия
#25

50 - 100

#26

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

#27

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

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

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

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

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