Перейти к содержимому

GarryGaGarry

Регистрация: 07 окт 2016
Offline Активность: 03 дек 2018 11:30
-----

Мои сообщения

В теме: Workflow тестирование по скриншотам

13 ноября 2018 - 14:12

 

 

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

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

 

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

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

 

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


В теме: Workflow тестирование по скриншотам

09 ноября 2018 - 13:04

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

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


В теме: Workflow тестирование по скриншотам

09 ноября 2018 - 09:30

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

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

 

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

https://crossbrowser...ual-comparisons

 

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


В теме: Workflow тестирование по скриншотам

08 ноября 2018 - 15:59

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