Comments 36
Ребята, есть штуки вроде Sentry, их можно даже в production использовать (особенно полезно для отлова тяпляпов из-за разработчиков браузерных расширений). Самое главное, там есть вещь, которая называется breadcrumbs — в них вы можете записать цепочку действий, которая приводит к возникновению ошибки.
Есть еще один момент с Sentry — она умеет отлавливать ошибки из разных кодовых баз, например из PHP и JS. Это удобно, когда какая-нибудь PHP-ошибка вызывает ошибку в JS.
Есть еще один момент с Sentry — она умеет отлавливать ошибки из разных кодовых баз, например из PHP и JS. Это удобно, когда какая-нибудь PHP-ошибка вызывает ошибку в JS.
+2
Привет. Когда я готовил статью, я узнавал у наших ребят из фронтэнда, как именно они собирают логи с клиента. Мне рассказали о Sentry в том числе, но сказали, что мы свою систему сборки писали примерно в то же время или чуть раньше. Тогда на рынке ничего подходящего не нашлось.
Насколько я понял, наша система в целом работает аналогично. Мои коллеги из разработки меня поправят, если я не прав.
Насколько я понял, наша система в целом работает аналогично. Мои коллеги из разработки меня поправят, если я не прав.
+3
А вы не могли бы рассказать, как вы добились стабильной работы Selenium? На моей практике половина тестов сваливалась с таймаутами или просто web-driver зависал.
+1
Вы имеете в виду — в целом или конерктно со сборкой JS-ошибкой?
Если в целом, то поэтапно, конечно. UI тесты по определению нестабильны, это нормально и с этим нужно бороться ситуативно.
Если Вы про сбор JS-ошибкок, то там с нестабильностью проблем не было.
Если в целом, то поэтапно, конечно. UI тесты по определению нестабильны, это нормально и с этим нужно бороться ситуативно.
Если Вы про сбор JS-ошибкок, то там с нестабильностью проблем не было.
+1
Вы что-то не так делаете. Мой рекорд — трое суток непрерывной работы тестов (проверка отображения около 100 тыс единиц сложного контента). Не обошлось без подводных камней, например, в Хроме при работе с Selenium почему-то не запускается уборка мусора в Javascript, поэтому когда элементы на страничке обновляются без перезагрузки (ajax) через пару часов браузер сжирал несколько гигабайт оперативной памяти при одной открытой вкладке и падал. Все решилось принудительным перезапуском после проверки N единиц контента ( параметр подбирали по опыту)
+1
тесты последовательные были или параллельные? если параллельные, то сколько потоков?
0
последовательные, но по оршанизационным причинам: наш тестовый сервер использовался и для других тестов, запуск в несколько потоков мог замедлять их тоже. Кроме того, в работе использовался самописный фреймворк-надстройка над селениум(содержащий абстракции для нашего контента), который не был thread safe, а на его обновление времени не было.
0
UFO just landed and posted this here
Да, спасибо, мы знаем про sentry — отличное решение, но у нас для сбора и агрегации клиентских ошибок уже достаточно давно написано свое, и оно по-сути очень похоже на то как работает sentry/raven.js. Тут же речь именно про препродакшн тестирование и про то, что нам важно не только как интерфейс выглядел, но и то что при этом не сыпались какие-нибудь ошибки, и если все же сыпались — то вот как мы их привязываем к результату прогона
+3
UFO just landed and posted this here
Привет.
У нас есть похожее решение, но его автор не я. Я попрошу автора выделить время и рассказать. :)
У нас есть похожее решение, но его автор не я. Я попрошу автора выделить время и рассказать. :)
+2
Интересный функционал. Мы рассматривали BugReplay, но в итоге просто иногда записываем видео (когда надо) и почти всегда пишем HAR. Этого вполне достаточно (пока).
Но как мы знаем, аппетит приходит во время еды и пока функционала нет, то его никто и не просит.
Вы это расширение где-то опубликовали?
+2
При помощи WD можно еще свою психику проверять. Этот функционал работает даже лучше чем основной.
+1
Для проверки верстки можно использовать applitools, особенно если таких проверок много или они критичны для бизнеса. метод с попикселным сравнением не слишком надежный
0
Для сбора ошибок можно брать логи браузера прямо в Selenium.
seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/lib/logging.html
seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/lib/logging.html
+1
Привет.
Насколько я помню, это до сих пор не во всех браузерах работает. Нам же требовалось универсальное решение.
Но я посмотрю повнимательнее, спасибо!
Насколько я помню, это до сих пор не во всех браузерах работает. Нам же требовалось универсальное решение.
Но я посмотрю повнимательнее, спасибо!
0
Да, Safari, IE, EDGE — не отдают лог.
Проблема в том что W3C никак не определится с логированием webdriver.
В IE можно решить через аргументы драйвера (запись в файл с LEVEL = ERROR)
В EDGE пока не хотят делать, но думают об этом )
developer.microsoft.com/en-us/microsoft-edge/platform/issues/12238249
Проблема в том что W3C никак не определится с логированием webdriver.
В IE можно решить через аргументы драйвера (запись в файл с LEVEL = ERROR)
В EDGE пока не хотят делать, но думают об этом )
developer.microsoft.com/en-us/microsoft-edge/platform/issues/12238249
+2
У меня в своё время возникала проблема и с ФФ. В спеке geckodriver'а логирование не описано, что ли, поэтому не поддерживается.
0
Ну сейчас всё в порядке.
firefox-source-docs.mozilla.org/testing/geckodriver/geckodriver/TraceLogs.html
Кстати в FF как и в Chrome можно и полный http лог в файл записать.
about:networking в FF и chrome://net-internals у Chrome
Можно и через аргументы браузера запись в файл включить.
developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
dev.chromium.org/for-testers/providing-network-details
firefox-source-docs.mozilla.org/testing/geckodriver/geckodriver/TraceLogs.html
Кстати в FF как и в Chrome можно и полный http лог в файл записать.
about:networking в FF и chrome://net-internals у Chrome
Можно и через аргументы браузера запись в файл включить.
developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
dev.chromium.org/for-testers/providing-network-details
+2
Попробую ещё, спасибо за наводку! Плюс не позволяет поставить карма, к сожалению.
0
Спасибо за наводку, интересно.
HAR мы вытягиваем с помощью экстеншена для Firefox и средствами performance logs для Chrome. Решение хорошо описано у ребят из https://sitespeed.io
Я вот прямо сейчас глянул на то, что Mozilla предлагает — не уверен, что так можно сделать, например, в Selenoid (может, невнимательно смотрел).
0
В Selenoid для FF можно передать переменные среды в browsers.json
У хрома всё можно сделать через capabilities добавив аргументы:
Да, хром может и показать записанный файл, достаточно загрузить его в
chrome://net-internals/#import
"env" : ["MOZ_LOG=timestamp,rotate:200,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5", "MOZ_LOG_FILE=/tmp/log.txt"]
У хрома всё можно сделать через capabilities добавив аргументы:
--net-log-capture-mode=IncludeCookiesAndCredentials
--net-log-capture-mode=IncludeSocketBytes
--log-net-log=/tmp/network_log.json
--log-net-log-level=0
Да, хром может и показать записанный файл, достаточно загрузить его в
chrome://net-internals/#import
+1
UFO just landed and posted this here
Здравствуйте! Извините за, возможно, глупый вопрос. Касаемо темплейтов: вы просто добавляете темплейт со скриптом внутри в код тестируемой страницы? Как это у вас происходит: вы изменяете код страницы на тестовых серверах, попросив помощи у разработчика, либо самолично имеете доступ к коду? либо как-то исполняете код, который добавит этот темплейт в код страницы на время исполнения автотеста, не меняя её исходного кода? Ещё раз прошу прощения за дилетантский вопрос. Если не затруднит, хотелось бы почитать, как именно это реализовано. Спасибо!
0
Добрый день.
Тут, скорее, вопрос не в том, у кого какие доступы есть. Тут вопрос ответственности. Никто, ни разработчики, ни QA-инженеры ничего не делают сами по себе, только потому, что это взбрело в голову.
Задачи предварительно обсуждаются, а после их выполнения проходят Code Review со стороны разработки и несколько этапов тестирования со стороны QA. Вся работа исключительно командная.
О том, как у нас построено тестирование в целом и о Code Review в частности очень подробно написал руководитель отдела тестирования — Илья Агеев. Почитайте , это интересно.
Тут, скорее, вопрос не в том, у кого какие доступы есть. Тут вопрос ответственности. Никто, ни разработчики, ни QA-инженеры ничего не делают сами по себе, только потому, что это взбрело в голову.
Задачи предварительно обсуждаются, а после их выполнения проходят Code Review со стороны разработки и несколько этапов тестирования со стороны QA. Вся работа исключительно командная.
О том, как у нас построено тестирование в целом и о Code Review в частности очень подробно написал руководитель отдела тестирования — Илья Агеев. Почитайте , это интересно.
+1
Sign up to leave a comment.
Что ещё мы проверяем при помощи Selenium, кроме логики интерфейса