Ооо, є коментарі!) Красавчікі Хлопці!)
На попередньому тижні також додав трохи тестів для дебагу інтеграції з репортером testomat.io
Частина тестів спеціально не проходять щоб подивитися як фейли в репорті відображаються)
Думаю терминология «эталонный снимок» довольно близка и понятна людям которые занимаются тестированием. «мастер образ» — не используем в рабочем сленге по отношению к скриншотам, в различных кругах, может быть принято по разному называть это)
В чем заключается ошибка в логике сравнения и его полноте? Тут я вас не сильно понял.
Пропустить тяжело, так как у вас тест будет «завален», если отличие будет даже в пиксель (в зависимости от того как вы наконфигурируете проверки).
+ Мелкие изменения в «пиксель» можно выделять отдельной рамкой на скриншоте — если уж сильно хотите.
Директории именовать можно как вам угодно. В данном случае у нас нет потребности смотреть все эталонные снимки месячной давности. Так же — если такая потребность возникает то в дженкинсе можно настроить хранение результатов сборки со всеми скриншотами и логами. А так будет слишком много места занимать большое количество скриншотов. Но никто не запрещает этого делать, если у вас есть такая потребность.
«откатывать» к конкретному числу или изменениям потребности никогда не возникало, ну и что бы переделать все снимки достаточно запустить тест с параметром для переделывания скриншотов, либо удалить директорию с конкретными снимками — конкретного теста.
Каждый пишет код под потребности своего проекта, со своим Блэк-джеком и скриншотами.
1. Сервера, либо облачные решения которые вы упомянули в 4м пункте. Количество связок зависит от требований вашего продукта.
2. Делать упор на снимки элементов, а не страниц. Так же можно просто периодически «переснимать» заново все эталонные снимки. (После запланированных изменений).
3. Кол-во скриншотов зависит от пункта 1.
Про «пауков» не понял, можно поподробнее ?)
Фоновая информация — вырезаться \ игнорируется. Если нужно тестировать ее — можно написать отдельный набор тестов для этих вещей (но не уверен насчет целесообразности данного действа)
4. Вопрос довольно философский) «такая» автоматизация не отличается от «обычной» — все метрики и затраты — будут ровно такими-же как и при написании и поддержании тестов «не для верстки». Сложность поддержки тестов зависит от знаний человека который пишет эти тесты.
По поводу ROI вспомнилось обсуждение — automated-testing.info/t/roi/1608
Да, живут вместе)
Да, переиспользуются + много «другого» кода из проекта используется в этих тестах.
TestNG параллелит на ура)
На толковом проекте и CEO и даже рядовой программист будут тестировать свой сайт.
В стремлении сделать качественный продукт — нет ничего зазорного.
Суть не в лейблах и количестве опыта, а в команде и продукте который она делает.
6 лет для изучения космоса — капля в море.
А вот для освоения профессии вполне нормальный срок.
Все люди разные: Кто-то книгу прочитать может за час, кто-то за 2 недели, а кто-то будет пиво пить вместо этого.
Согласен, слово «очень» в данной фразе лишнее, но вся суть в теме статьи, а не в авторе)
Ну и 6 лет это не такой уж и маленький отрывок времени))
Вы не дочитали до конца)
Мы у себя используем Jenkins, в котором генерим Allure отчет со всеми параметрами теста, скриншотами, сделанными в процессе выполнения, gif изображением с отличием, логами браузера, куками и т.д.
Основная суть автоматизации тестирования именно в автоматизации тестирования)
Так конечно применений много можно придумать, ваш вариант тоже подойдет. Но если мы говорим о тестах, а тем более о автотестах — то хотелось бы максимально этот процесс автоматизировать)
+ Как уже писали ниже — если очень много скриншотов то человеку будет тяжко с таким количеством справится, а так же мелкие ошибки глазом бывает гораздо сложнее заметить.
Не сталкивался с этом инструментом. Но думаю в нем есть пару но:
1. Работает только с веб страницами, в отрыве от них таким инструментом не попользуешься.
( например для мобильных или десктоп приложений, флеша )
2. У нас весь код проекта с тестами написан на джаве и львиную долю написанного кода можно использовать и для тестов верстки, соответственно нет заморочек с логированием, репортингом, элементами на страницах и т.д.
Поправил)
Дякую усім хто прийняв участь та не посоромився викласти свої тести!
Хочу також поділитися — ми провели внутрішній челендж в рамках нашої команди.
Силами 10 наших розробників — було написано понад 1500 юніт, та функціональних тестів які уже знаходяться в нашому пайплайні та допомагають нам кожного дня!