Сообщений в теме: 14

[GarryGaGarry]

Добрый день. Поделитесь пожалуйста как у вас встроен процесс тестирования по скриншотам в общий рабочий процесс.
В данный момент у нас есть решение, но оно нам кажется излишне сложным.
1. Появляется пул-реквест в основной проект
2. CircleCI разворачивает приложение запускает ui и unit тесты
3. Скриншоты лежат в отдельном репозитории (А), Ci создает новую ветку для репозитория (А), с названием ветки разработчика с которого был создан пул-реквест.
4. После прохождения всех тестов, если все успешно то происходит мерж
5. Если есть конфликты в скриншотах, то разработчик заходит на специально созданный веб сервис, где видит исходный, актуальный скриншот и картинку с разницей, он может пометить тест как устаревший, тогда его актуальный скриншот становиться исходным, а его ветка репозитория (А) мержится с мастером
6. Проходит мерж основного репозитория проекта

Хотелось бы, увидеть решение проблемы с заменой старых скриншотов на новые, но чтоб все гонялось на CI и было максимально автоматизировано.

[Freiman]

Я пока что не вижу даже проблемы. Что именно вы хотите улучшить?

[GarryGaGarry]

Описанное выше это решение в перспективе, а не готовое. Но продукт менеджера не устраивает временные затраты, на данное решение. Хотел услышать альтернативные версии.

[Vasiliy]

Временные затраты на создание данного механизма или затраты при использовании?

[Spock]

может что-то готовое дешевле выйдет?

https://crossbrowser...ual-comparisons

[GarryGaGarry]

Временные затраты на создание данного механизма или затраты при использовании?

Затраты на создание данного механизма
 

 

может что-то готовое дешевле выйдет?

https://crossbrowser...ual-comparisons

 

Я опишу полностью ситуацию. В компании несколько команд scrum и kanban, каждая пилит фичу и ui/unit тесты по надобности.  В результате, иногда начали всплывать баги из разряда сделали таску, случайно сломали фичу другой команды. Скорее всего, из-за неполного тестового покрытия. Но сложно оценить покрытие, поскольку документации нет, других артефактов подобного плана тоже. Проект не самый маленький и быстро расписать документацию и все возможные тест-кейсы сложно. Я принял решение, сделать тестирование по скриншотам, как самый быстрый способ покрыть большую часть регресса. Тесты написаны на selenide+ashot, но не продумал про все нюансы интеграции в си. Когда стали обсуждать поняли, что приемлемый вариант для разработчиков тот, что я описывал выше. Но поскольку времени на создание тестового фремворка и так ушло больше чем планировалось, новые проблема заставили задуматься продукт-менеджера о ресурсозатратах на данную таску. В итоге, вопрос стоит так найти варианты рабочих workflow, которые быстры в создании, или отказаться от проделанной работы.

[Vasiliy]

У нас проект был поменьше, но расскажу. Механизм все то же, кроме вашего п.5. Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.

[Spock]

 

 

Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно. 

ну где-то ведь тестировщик смотрит эти скриншоты, и где-то "решение" верно или неверно тоже регистрируется, и референсные скриншоты заменяются

[GarryGaGarry]

У нас проект был поменьше, но расскажу. Механизм все то же, кроме вашего п.5. Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.

Да 5 пункт и вызывает больше всего тревоги, но как уже спросили выше, чем именно вы его заменили? находили скрины вручную?

[Vasiliy]

 

 

 

Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно. 

ну где-то ведь тестировщик смотрит эти скриншоты, и где-то "решение" верно или неверно тоже регистрируется, и референсные скриншоты заменяются

 

А зачем вам это решение регистрировать? Посмотрели скриншоты средсвами ОС, приняли решение. Не сможет тестировщик принять решение, спросит у разработки или коллеги. Заменить скриншоты это команда копирования плюс коммит в хранилище. Зачем для этого веб-сервис?:)

[Vasiliy]

 

У нас проект был поменьше, но расскажу. Механизм все то же, кроме вашего п.5. Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.

Да 5 пункт и вызывает больше всего тревоги, но как уже спросили выше, чем именно вы его заменили? находили скрины вручную?

 

Что значит находили вручную?! У вас две папки скриншотов и еще набор результатов автоматического сравнения. Просмотрели сравнение, там где есть подозрительная разница смотрите изначальные результаты.

Сколько у вас скриншотов, что ручная работа вызывает у вас оторопь?

[GarryGaGarry]

 

 

У нас проект был поменьше, но расскажу. Механизм все то же, кроме вашего п.5. Веб-сервиса не было и я не понимаю зачем он вам. Были эталонные снимки и снимки текущего выполнения. Они сравнивались автоматом (Araxis merge) и, при наличии расхождений, тестировщик сам смотрел картинки и решал верно или неверно.

Да 5 пункт и вызывает больше всего тревоги, но как уже спросили выше, чем именно вы его заменили? находили скрины вручную?

 

Что значит находили вручную?! У вас две папки скриншотов и еще набор результатов автоматического сравнения. Просмотрели сравнение, там где есть подозрительная разница смотрите изначальные результаты.

Сколько у вас скриншотов, что ручная работа вызывает у вас оторопь?

 

сейчас 43 тестов, это 129 скриншотов(изначальный, актуальный, разница) Планируется что тестов будет около 80, и потом будут дублироваться для разных размеров экрана. Они раскиданы по папкам, но все равно есть неудобство, даже сейчас. 

[Vasiliy]

1. Вам нужна разница. И только она есть и вызывает подозрения, то смотрите уже другие скрины.
2. Яркий пример, что автоматизауия не панацея))

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

[Spock]

 

 

Они раскиданы по папкам, но все равно есть неудобство, даже сейчас.

может просто у вас как-то неудобно организован процесс обновления скриншотов?

 

например если старые скриншоты хранятся в мастере, а новые в ветке согласно ветке разработки, например 10 тестов зафейлилось, тестер просмотрел эти 10 скриншотов с разницей, из них 1 баг, 9 новая фича, после фикса этого 1го бага сет прогоняется опять и тестер нажимает одну кнопку в веб-интерфейсе СКВ чтобы замёржить ветку в мастер

 

где тут неудобство? 

 

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

[Aleksche]

У меня так сделано

Если падает тест на сравнении то создается папка с номером билда и туда копируются две картинки expected и actual

соответственно генерируется  нотификация в канал, дальше дев смотрит и говорит, ой баг, открывайте тикет

или, нет все ок, меняйте шаблон.

Можно конечно этот сценарий автоматизировать, но в моем случае игра не стоит свеч