Добрый день. Поделитесь пожалуйста как у вас встроен процесс тестирования по скриншотам в общий рабочий процесс.
В данный момент у нас есть решение, но оно нам кажется излишне сложным.
1. Появляется пул-реквест в основной проект
2. CircleCI разворачивает приложение запускает ui и unit тесты
3. Скриншоты лежат в отдельном репозитории (А), Ci создает новую ветку для репозитория (А), с названием ветки разработчика с которого был создан пул-реквест.
4. После прохождения всех тестов, если все успешно то происходит мерж
5. Если есть конфликты в скриншотах, то разработчик заходит на специально созданный веб сервис, где видит исходный, актуальный скриншот и картинку с разницей, он может пометить тест как устаревший, тогда его актуальный скриншот становиться исходным, а его ветка репозитория (А) мержится с мастером
6. Проходит мерж основного репозитория проекта
Хотелось бы, увидеть решение проблемы с заменой старых скриншотов на новые, но чтоб все гонялось на CI и было максимально автоматизировано.
#1
Отправлено 07 ноября 2018 - 10:23
#2
Отправлено 08 ноября 2018 - 13:13
Я пока что не вижу даже проблемы. Что именно вы хотите улучшить?
#3
Отправлено 08 ноября 2018 - 15:59
Описанное выше это решение в перспективе, а не готовое. Но продукт менеджера не устраивает временные затраты, на данное решение. Хотел услышать альтернативные версии.
#4
Отправлено 08 ноября 2018 - 16:17
#5
Отправлено 08 ноября 2018 - 16:30
может что-то готовое дешевле выйдет?
https://crossbrowser...ual-comparisons
#6
Отправлено 09 ноября 2018 - 09:30
Временные затраты на создание данного механизма или затраты при использовании?
Затраты на создание данного механизма
может что-то готовое дешевле выйдет?
https://crossbrowser...ual-comparisons
Я опишу полностью ситуацию. В компании несколько команд scrum и kanban, каждая пилит фичу и ui/unit тесты по надобности. В результате, иногда начали всплывать баги из разряда сделали таску, случайно сломали фичу другой команды. Скорее всего, из-за неполного тестового покрытия. Но сложно оценить покрытие, поскольку документации нет, других артефактов подобного плана тоже. Проект не самый маленький и быстро расписать документацию и все возможные тест-кейсы сложно. Я принял решение, сделать тестирование по скриншотам, как самый быстрый способ покрыть большую часть регресса. Тесты написаны на selenide+ashot, но не продумал про все нюансы интеграции в си. Когда стали обсуждать поняли, что приемлемый вариант для разработчиков тот, что я описывал выше. Но поскольку времени на создание тестового фремворка и так ушло больше чем планировалось, новые проблема заставили задуматься продукт-менеджера о ресурсозатратах на данную таску. В итоге, вопрос стоит так найти варианты рабочих workflow, которые быстры в создании, или отказаться от проделанной работы.
#7
Отправлено 09 ноября 2018 - 10:07
#8
Отправлено 09 ноября 2018 - 10:25
Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.
ну где-то ведь тестировщик смотрит эти скриншоты, и где-то "решение" верно или неверно тоже регистрируется, и референсные скриншоты заменяются
#9
Отправлено 09 ноября 2018 - 13:04
У нас проект был поменьше, но расскажу. Механизм все то же, кроме вашего п.5. Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.
Да 5 пункт и вызывает больше всего тревоги, но как уже спросили выше, чем именно вы его заменили? находили скрины вручную?
#10
Отправлено 10 ноября 2018 - 16:53
Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.
ну где-то ведь тестировщик смотрит эти скриншоты, и где-то "решение" верно или неверно тоже регистрируется, и референсные скриншоты заменяются
А зачем вам это решение регистрировать? Посмотрели скриншоты средсвами ОС, приняли решение. Не сможет тестировщик принять решение, спросит у разработки или коллеги. Заменить скриншоты это команда копирования плюс коммит в хранилище. Зачем для этого веб-сервис?:)
#11
Отправлено 10 ноября 2018 - 16:56
У нас проект был поменьше, но расскажу. Механизм все то же, кроме вашего п.5. Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.
Да 5 пункт и вызывает больше всего тревоги, но как уже спросили выше, чем именно вы его заменили? находили скрины вручную?
Что значит находили вручную?! У вас две папки скриншотов и еще набор результатов автоматического сравнения. Просмотрели сравнение, там где есть подозрительная разница смотрите изначальные результаты.
Сколько у вас скриншотов, что ручная работа вызывает у вас оторопь?
#12
Отправлено 13 ноября 2018 - 14:12
У нас проект был поменьше, но расскажу. Механизм все то же, кроме вашего п.5. Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.
Да 5 пункт и вызывает больше всего тревоги, но как уже спросили выше, чем именно вы его заменили? находили скрины вручную?
Что значит находили вручную?! У вас две папки скриншотов и еще набор результатов автоматического сравнения. Просмотрели сравнение, там где есть подозрительная разница смотрите изначальные результаты.
Сколько у вас скриншотов, что ручная работа вызывает у вас оторопь?
сейчас 43 тестов, это 129 скриншотов(изначальный, актуальный, разница) Планируется что тестов будет около 80, и потом будут дублироваться для разных размеров экрана. Они раскиданы по папкам, но все равно есть неудобство, даже сейчас.
#13
Отправлено 13 ноября 2018 - 14:42
2. Яркий пример, что автоматизауия не панацея))
Честно, я не знаю как решить вашу боль. Пока ничего в голову не приходит.
#14
Отправлено 13 ноября 2018 - 14:53
Они раскиданы по папкам, но все равно есть неудобство, даже сейчас.
может просто у вас как-то неудобно организован процесс обновления скриншотов?
например если старые скриншоты хранятся в мастере, а новые в ветке согласно ветке разработки, например 10 тестов зафейлилось, тестер просмотрел эти 10 скриншотов с разницей, из них 1 баг, 9 новая фича, после фикса этого 1го бага сет прогоняется опять и тестер нажимает одну кнопку в веб-интерфейсе СКВ чтобы замёржить ветку в мастер
где тут неудобство?
п.с. папки не нужны если нейминг нормальный, удобно просматривать разницу просто "некст, некст". Хотя может и нужны если например все фейленые диф-скриншоты в одной папке
#15
Отправлено 16 ноября 2018 - 03:59
У меня так сделано
Если падает тест на сравнении то создается папка с номером билда и туда копируются две картинки expected и actual
соответственно генерируется нотификация в канал, дальше дев смотрит и говорит, ой баг, открывайте тикет
или, нет все ок, меняйте шаблон.
Можно конечно этот сценарий автоматизировать, но в моем случае игра не стоит свеч
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных