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


(Mykhailo Poliarush) #1

Следом за предыдущим опросом, где выяснилось что в общем большинство создают свои собственные фреймворки нежели переиспользуют уже существующие, мы продолжаем серию опросов по поводу автоматизации тестирования для того чтобы понять общую картину.

  • 0
  • 1 - 10
  • 10 - 20
  • 20 - 50
  • 50 - 100
  • 100 - 200
  • 200 - 500
  • 500 - 1000
  • 1k - 5k
  • 5k - 10k
  • >10k

0 участников

И не забываем ставить лайки, чтобы и дальше было желание вести опросы :smile:


Серия at.info опросов по автоматизации тестирования ПО
Опрос: Кто на вашем проекте(ах) занимается автоматизацией тестирования?
(Mykhailo Poliarush) #2

Эта тема теперь прилеплена глобально и будет появляться вверху списка тем соответствующего раздела и всех списков тем, пока персонал не отлепит ее глобально или пользователь не отлепит лично для себя.


(asolntsev) #3

Трудно будет делать какие-то выводы. Количества тестов мало - ведь они могут быть большими или маленькими, долгими или быстрыми…

Может, ещё можно опросить пропорцию юнит-тестов и UI-тестов в проекте. Я вот сейчас прикинул, у меня в текущем проекте 424 UI-теста (бегут 13 минут) и 2315 юнит-тестов (бегут < 1 минуты).


(Mykhailo Poliarush) #4

Верно, но тогда надо больше делать многоуровневый опрос с матрицами ответов. Добавил твой комментарий в общую тему, обдумаем при следующем опросе.


(Dmytro Makhno) #5

проголосовал и лайкнул…

Но как-то сферический опрос получается.
У нас 150+, юнит UI тестов, где-то в 2-3 минуты укладываются. Селениум есть, но бэкенд фальшивый. (И им же кроссбраузерность проверяем). Стэк: javascript/coffeescript/nodejs.
И где-то 20-50 (интервал т.к.: тестов мало, ассертов - много), минут на 6, где уже все система поднята, и нужен именно реальный бекенд. Стэк: sbt/scala+python :panda_face:

Что хотет узнать автор? :smile:


(Mykhailo Poliarush) #6

Хочу понять общую картину, сколько в среднем создают (количественно) автоматических UI тестов на проектах. Конечно без дополнительной информации (за сколько тесты проходят, какой процент UI тестов, а какой unit тестов, сложность тестов и т.д.) тяжело будет судить о результатах, но это серия опросов и с появлением результатов, пазлы будут складываться в общую картинку.


(Serhii Tanchenko) #7

у кого 5-10к тестов? :frowning: признавайтесь :slight_smile:
интересно:

  • сколько лет проекту?
  • за сколько пробегают тесты?

(Руслан) #8

лет? :slight_smile:


(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.