Как стать автором
Обновить

Комментарии 26

Отличия в картинках ищутся быстро. Разными глазами сводишь их в одну, ну как с трёхмерными изображениями. Все отличия начинают мерцать
НЛО прилетело и опубликовало эту надпись здесь
отодвигайся, пока не совместятся. У меня получилось на 40см от экрана

Проще не с расстояния смотреть, а себе на нос.

Действительно, так тоже можно :) А ещё нашёл одно отличие, на краю тарелки, недалеко от ломтиков лимона — на одном изображении на одну чёрную точку больше.
с точками не понятно. Там — jpg
Всегда таким образом нахожу все отличия в подобных задачках:)
Обычно в подобных задачах вторую картинку поворачивают на небольшой угол
Отдел тестирования
image
image

Ну не все.
Например, отличия в цвете на ролле справа я таким образом заметить не смог.
:-D вот это лайфхак, но даже так я не заметил разницы в правом нижнем углу. У кусочка ролла форма и очертания идентичные, отличается лишь цвет.
Значит вы неправильно смотрите стереокартинки. При правильном рассмотрении надо смотреть ЗА неё, и тогда изображение не «свести» более, чем на расстояние между глазами. Ну и сами стереокартинки получаются инвертированными (если только специально под такой «альтернативный» способ не сделаны, впрочем, все картинки, между соответствующими точками которых расстояние больше условно среднего расстояния между глазами — такие). А неправильно — это смотреть в точку перед изображением и отодвигать само изображение, как вы и пишете
Фотошоп, копия слоя, смешивание слоев: разница и все как на ладони
Там кстати будет видно еще одно отличие: белая точка на фоне, внизу под темным пятном.

Не слишком ли жирно покупать лицензию фотошопа для таких целей?
Ну и очевидный ответ — а если таких скриншотов десятки тысяч?

Как уже вам ответили, предложенный вами подход разобьется о количество сравниваемых изображений. В среднем обычное наше приложение содержит 150 страниц, и проверяется в 6 разрешениях на 3 браузерах, итого: 2700. А есть и больше.
Суть нашего подхода в том, что человек нужен только для разбора упавших тестов (сравнений).
Белая точка действительно не попала в выделенную зону. Финальная картинка не была получена в результате сравнения нашим инструментом. Но смею заверить, наш инструмент нашел бы ее ;)
Видимо ошибок слишком много, я постоянно косяки всякие нахожу, мелочи конечно
Багов не мало. Практически каждый месяц пишу в техподдержку Тинькофф-Бизнес очередной репорт.
Молодцы: правят довольно быстро.

P.S. Что-то типа багбаунти все же есть, один раз за более-менее серьезный баг в безопасности дали месяц бесплатного обслуживания (порядка 2т.р.). Мелочь, а приятно. Но давно пора сделать её публичной.
Если мне не изменяет память, мы (уже не мы) делали попиксельное (и, вроде, не только) сравнение изображений в регрессионных тестах на проекте Artisteer лет эдак, чтобы не соврать, восемь-десять назад. Да, думаю, много кто делал. Но публичного проекта, заточенного под эти цели, я не видел. Ну, здорово, конечно, что могу сказать :)
Такой тяжкий труд, стоил ли он свечь на фоне простого extension Pixel Perfect
А разве можно Pixel Perfect'ом автоматически 50 страниц проверить в трех разных разрешениях и разных браузерах?
Как уже отвечал выше идея была по-максимуму автоматизировать этот процесс.
Этот процесс встроен в CI? Если да, то как обрабатывается случай, если изменение верстки плановое?
И еще — если на целевой странице есть анимация, то есть присутствуют несколько слайдов с картинками и текстами (кнопками, да с чем угодно), которые листаются каждые n-минут. Как проверять их?
Да, CI есть. Несколько путей решения:
1) в финальном отчете выставляем фильтры в соответствии с изменениями и принимаем эти риски (например обновили стили, поэтому в отчете убираем из фильтрации ошибки css)
2) Если изменения касаются конкретных элементов, то убираем из списка локаторов те, что ссылаются на измененный (что тоже несет некоторые риски)
Для подстраховки используем скриншот-тесты отдельных компонент в Storybook: верстка, как правило меняется не радикально, а лишь отдельные элементы (банеры, кнопки, и т.д.). В storybook компоненты вынесены на отдельные страницы. Так, что проверка изменений не занимает много времени даже при «ручном» тестировании, а проверка остальных компонент на отсутствие изменений уже с помощью Qvisual.
Анимацию и динамический контент (банеры с рандомными рекомендации продуктов, например) перед снятием снапшота удаляем со страницы при помощи js. Потом отдельно проверяем другими тестами (иногда руками).
О! Я могу комментарии писать!

Пытаюсь запустить на Linux Mint бэкенд, но не получается.

```
java
-Xms2g
-Xmx13g
-XX:+AlwaysPreTouch
-XX:+UseG1GC
-XX:+ScavengeBeforeFullGC
-Dspark.host=localhost
-Dspark.port=8081
-Dbackend.domain=http://localhost:8081
-Dfrontend.domain=http://localhost:5000
-Dmongodb.host=localhost
-Dmongodb.port=27017
-Dscreenshooter.dir=/home/ogion/Projects/Java/QVisual/results
-Djava.library.path=/home/ogion/Projects/Java/QVisual/visualreport/src/main/resources/
-jar /home/ogion/Projects/Java/QVisual/visualreport/target/visualreport-1.0.jar
```
```
Exception in thread «main» java.lang.UnsatisfiedLinkError: no opencv_java341 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at ru.tinkoff.VisualReport.(VisualReport.java:34)
```
```
ls -la
total 90212
drwxrwxr-x 2 ogion ogion 4096 Nov 12 17:12.
drwxrwxr-x 4 ogion ogion 4096 Nov 9 18:06…
-rwxrwxr-x 1 ogion ogion 1441664 Nov 9 18:06 libopencv_java341.dylib
-rw-rw-r-- 1 ogion ogion 72600648 Nov 9 18:06 libopencv_java-3.4.1.so
-rw-rw-r-- 1 ogion ogion 594 Nov 9 18:06 logback.xml
-rw-rw-r-- 1 ogion ogion 422463 Nov 9 18:06 opencv-3.4.1_4.jar
-rw-rw-r-- 1 ogion ogion 18053632 Nov 9 18:06 opencv_ffmpeg341_64.dll
lrwxrwxrwx 1 ogion ogion 25 Nov 12 17:12 opencv_java341 -> ./libopencv_java-3.4.1.so
```

```
Укажите в главном pom.xml в параметре <opencv.dir> (строка 380) путь до файла libopencv_java341.so на вашей машине.
Если возникнут трудности — пишите в личку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий