Pull to refresh

Comments 30

Чем не устраивают winrunner и другие подобные продукты? Они для того и созданы, чтобы гуи тестировать.
Почему они не подошли?
Извините, что вопросом на вопрос, но в нём и содержится ответ:
А вы пробовали решить поставленную задачу с помощью winrunner и других продуктов тестирования GUI?
Нет, не сталкивался с такой задачей. Но мне очень интересно, почему пришлось изобретать свое средство, чего не хватает уже существующим решениям. Как бы в дополнение к вашей статье. :)
Тоже както думали над автоматизацией/упрощением тестирования верстки, как по мне эта идея супер
только можно не маркеры добавлять, а например class=js_test для ключевых элементов и потом на сервер отсылать не только положение но и ширину/высоту элемента
Решение с маркерами более отказоустойчивое: классы могут заменяться JS сценариями. Кроме того, перед выкладкой, как показала практика нашего проекта, удалять комментарии вполне безопасно. Удалять же регуляркой классы я бы не стал, как потенциально багоопасный момент (вырезания лишнего), который мы не контролируем. Да, я понимаю, что можно написать правильную регулярку, но тут в самом методе модержится погрешность.
Что касается необходимости вычисления ширины (маркеры — суть определение высоты, только в неявном виде), теоретически это может быть полезно. На практике, надо проверять.
добавление экстракода это потенциальные баги, лучше его избегать, как и внедрение дополнительного js на страницу.
пара лишних классов большой роли не сыграет

… зато появляется возможность живого тестирования :)
на пару часов в месяц включаем юзерам этот JS, логируем версию браузера, и получаем самую живую статистику )))
А почему бы не вставлять дополнительный код, а написать парсер, который бы брал координаты классов, для примера.
— Как вы собрались определять координаты точек для разных разрешений экрана, для разных браузеров, и это все сапортить в дальнейшем?
— Как вы однозначно определяете по полученным координатам что блок находиться в ошибочном месте

Приведу пример: У вас каскад из трёх вложенных блоков, ошибка сдвига по некой координате по первому (который включает остальные) блоку -1px, такая же ошибка для второго блока +2px, ошибка для третьего блока -1px. Маркер в третьем блоке — его координаты относительно окна верны и безошибочны (-1 +2-1=0). Но на самом деле как мы видим ошибки раскладки во всех трех блоках.
на самом деле макет выглядит так, как и должен, визуальной ошибки нет, клиент увидит то, что и должен, повода для паники — нет
проблема может править себя в дальнейшем, тогда и будет исправлена
не велосипедте. возьмите селениум.

verifyElementPositionLeft
verifyElementPositionТоп
verifyElementHeight
verifyElementWidth
и тд.

и в код ничего вставлять не надо.
Спасибо за совет. Селениум упустили из виду… Сейчас изучаем применимость к решению наших конкретных задач. Пока останавливает негибкость конфига. Мой гипотетический метод абстрагирован от разметки, что нас и привлекает.
Не совсем понимаю что вы имеете ввиду, под негибкостью конфигурации? Уж куда уж гибче то?

И на верстку ему в данном конкретном случае будет наплевать, ему надо только ID изучаемого элемента знать.

>> В ручном режиме разработчик просматривает данные страницы
вот от этого можно будет избавиться.
Конечно на внедрение и на «разобраться» (+ на поддержку естественно) понадобится некоторое время, но на больших проектах оно окупается.
Негибкость конфига заключается в необходимости привязки к конкретным классам (id не используем). Это не тот уровень абстракции, который хотелось бы достичь. В моём понимании, если мы ставим задачу тестировать «картинку», то не должны завязываться на коде. Мне кажется более правильным подход в установке уровней (как направляющие в фотошопе), нежели метрики конкретных элементов (сегодня элемент такой, завтра другой).
Возможно, я что-то недопонимаю или толкую неверно. Но я не хотел бы спорить на сей счёт, пока изучаю возможность применения селениума для данной проблемы, иначе у нас получится разговор слепого с глухим )
ага, понятно. Но если уж вы добавляете в код , то наверно можно вместо него добавить определенные классы или id к определенным элементам.

У селениума довольно гибкая система локаторов, reqexp в xpath, можно выполнять js на клиенте(без изменения кода) и прочие интересные вещи. Например:
Number n = selenium.getXpathCount("//td[@width>50]");

Мы для тестирования верстки в наших проектах используем другой, более «тупой», но, возможно, более эффективный подход. Робот запускает браузер, устанавливает ему заданный размер и начинает прокликивать указанные в тестовом скрипте страницы. В том же скрипте указано какие страницы (и какую область) нужно сфотографировать (сделать скриншот) и какое имя дать скриншоту. Робот фотографирует и смотрит наличие на диске существующего скриншота с таким же именем. Если такой скриншот найден, то он считается эталонным и происходит попиксельное сравнение двух скриншотов. Если скриншоты совпадают, тест считается пройденным. Если скриншот не найден, то он создается на диске. Процедура создания эталонных скриншотов проста, запускаем все скрипты, просматриваем все полученные картинки один раз глазами, чтобы убедиться что все выглядит правильно, далее робот все делает за вас. Если тест упал, открываем невалидную картинку (робот делает diff, и подсвечивает различающиеся области красным) проверяем глазами была ли разметка сломана или это плановое изменение. Если поломано — чиним, если все нормально, удаляем «плохой» эталон и запускаем тест еще раз, чтобы создать новый.
Хм… прекрасная идея! Благодарен.
Если вдруг надумаете реализовать, хочу еще сделать одну ремарку. Рендеринг UI может включать в себя недетерминированные алгоритмы (у нас, например, это хорошо заметно на антиалиасинге шрифтов, которым видимо занимается графическая система), поэтому при сравнении успехом считается совпадение двух картинок с определенной заранее заданной максимальной погрешностью. В прочем, алгоритм расчета этой погрешности может быть индивидуальным.
Согласен, прекрасная идея! А чем попиксельно сравниваете картинки?
Робот написан на C#/.Net, включая модуль который картинки сравнивает.
А если страница сайта в экран целиком не попадает?
К счастью, нам удалось научить робота скроллировать ;)
Спасибо за ссылку, насколько я понял, пробежавшись по сайту, sikuli все-таки заточено под функциональное тестирование, несмотря на то что, технически позволяет искать шаблонную картинку на экране. Плюс, если Вы намеренно изменили внешний вид, то Вам придется менять сами тесты, в нашей системе в 99% случаев тесты остаются неизменными. Но замечу, что наш робот тоже изначально занимался лишь функциональным тестированием, модуль тестирования скриншотов появился позже и достаточно хорошо вписался в существующую архитектуру.
Трудолюбивый у вас робот однако.
Поясни, пожалуйста, чем OperaDriver может помочь в тестировании вёрстки? Насколько я понимаю, это сделает чего-то, что не может Selenium без OperaDriver.
На видео не весь доклад, а только половина. Интересующая часть в запись не вошла, видимо. В любом случае, спасибо за ссылку.
Only those users with full accounts are able to leave comments. Log in, please.