Pull to refresh

Comments 36

Ребята, есть штуки вроде Sentry, их можно даже в production использовать (особенно полезно для отлова тяпляпов из-за разработчиков браузерных расширений). Самое главное, там есть вещь, которая называется breadcrumbs — в них вы можете записать цепочку действий, которая приводит к возникновению ошибки.
Есть еще один момент с Sentry — она умеет отлавливать ошибки из разных кодовых баз, например из PHP и JS. Это удобно, когда какая-нибудь PHP-ошибка вызывает ошибку в JS.
Привет. Когда я готовил статью, я узнавал у наших ребят из фронтэнда, как именно они собирают логи с клиента. Мне рассказали о Sentry в том числе, но сказали, что мы свою систему сборки писали примерно в то же время или чуть раньше. Тогда на рынке ничего подходящего не нашлось.

Насколько я понял, наша система в целом работает аналогично. Мои коллеги из разработки меня поправят, если я не прав.
А вы не могли бы рассказать, как вы добились стабильной работы Selenium? На моей практике половина тестов сваливалась с таймаутами или просто web-driver зависал.
Вы имеете в виду — в целом или конерктно со сборкой JS-ошибкой?

Если в целом, то поэтапно, конечно. UI тесты по определению нестабильны, это нормально и с этим нужно бороться ситуативно.

Если Вы про сбор JS-ошибкок, то там с нестабильностью проблем не было.
Вы что-то не так делаете. Мой рекорд — трое суток непрерывной работы тестов (проверка отображения около 100 тыс единиц сложного контента). Не обошлось без подводных камней, например, в Хроме при работе с Selenium почему-то не запускается уборка мусора в Javascript, поэтому когда элементы на страничке обновляются без перезагрузки (ajax) через пару часов браузер сжирал несколько гигабайт оперативной памяти при одной открытой вкладке и падал. Все решилось принудительным перезапуском после проверки N единиц контента ( параметр подбирали по опыту)
тесты последовательные были или параллельные? если параллельные, то сколько потоков?
последовательные, но по оршанизационным причинам: наш тестовый сервер использовался и для других тестов, запуск в несколько потоков мог замедлять их тоже. Кроме того, в работе использовался самописный фреймворк-надстройка над селениум(содержащий абстракции для нашего контента), который не был thread safe, а на его обновление времени не было.
UFO just landed and posted this here
Да, спасибо, мы знаем про sentry — отличное решение, но у нас для сбора и агрегации клиентских ошибок уже достаточно давно написано свое, и оно по-сути очень похоже на то как работает sentry/raven.js. Тут же речь именно про препродакшн тестирование и про то, что нам важно не только как интерфейс выглядел, но и то что при этом не сыпались какие-нибудь ошибки, и если все же сыпались — то вот как мы их привязываем к результату прогона
UFO just landed and posted this here
Привет.
У нас есть похожее решение, но его автор не я. Я попрошу автора выделить время и рассказать. :)

Интересный функционал. Мы рассматривали BugReplay, но в итоге просто иногда записываем видео (когда надо) и почти всегда пишем HAR. Этого вполне достаточно (пока).
Но как мы знаем, аппетит приходит во время еды и пока функционала нет, то его никто и не просит.
Вы это расширение где-то опубликовали?

UFO just landed and posted this here
Подскажите пожалуйста про вот эти штуки:

/** lang JavaScript */

Это IDE? Если да — та какие IDE это поддерживают? Или это для каких-то других целей?
Как минимум PhpStorm, но есть подозрение, что и другие Idea-based IDE
Привет.
Да, это для IDE. Для PHPStrom. В этом случае он подсвечивает код внутри строки так, как JS-код.

При помощи WD можно еще свою психику проверять. Этот функционал работает даже лучше чем основной.

Нет, что Вы… Настоящая проверка психики — угадать, как поведет себя тот или иной код на JavaScript. Например, вот:

null > 0
  false

null < 0
  false

null == 0
  false

null >= 0
  true
Для проверки верстки можно использовать applitools, особенно если таких проверок много или они критичны для бизнеса. метод с попикселным сравнением не слишком надежный

Applitools стали популярны примерно полтора года назад. VRT (Visual regression testing) мы начали делать года четыре назад :)

Привет.
Насколько я помню, это до сих пор не во всех браузерах работает. Нам же требовалось универсальное решение.

Но я посмотрю повнимательнее, спасибо!
Да, Safari, IE, EDGE — не отдают лог.
Проблема в том что W3C никак не определится с логированием webdriver.
В IE можно решить через аргументы драйвера (запись в файл с LEVEL = ERROR)
В EDGE пока не хотят делать, но думают об этом )
developer.microsoft.com/en-us/microsoft-edge/platform/issues/12238249
У меня в своё время возникала проблема и с ФФ. В спеке geckodriver'а логирование не описано, что ли, поэтому не поддерживается.
Ну сейчас всё в порядке.
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
Попробую ещё, спасибо за наводку! Плюс не позволяет поставить карма, к сожалению.

Спасибо за наводку, интересно.
HAR мы вытягиваем с помощью экстеншена для Firefox и средствами performance logs для Chrome. Решение хорошо описано у ребят из https://sitespeed.io
Я вот прямо сейчас глянул на то, что Mozilla предлагает — не уверен, что так можно сделать, например, в Selenoid (может, невнимательно смотрел).

В Selenoid для FF можно передать переменные среды в browsers.json
"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

интересно. попробуем, спасибо.

UFO just landed and posted this here
Добрый день.
Вроде обсудили веткой выше. Вы же об этом?
Здравствуйте! Извините за, возможно, глупый вопрос. Касаемо темплейтов: вы просто добавляете темплейт со скриптом внутри в код тестируемой страницы? Как это у вас происходит: вы изменяете код страницы на тестовых серверах, попросив помощи у разработчика, либо самолично имеете доступ к коду? либо как-то исполняете код, который добавит этот темплейт в код страницы на время исполнения автотеста, не меняя её исходного кода? Ещё раз прошу прощения за дилетантский вопрос. Если не затруднит, хотелось бы почитать, как именно это реализовано. Спасибо!
Добрый день.
Тут, скорее, вопрос не в том, у кого какие доступы есть. Тут вопрос ответственности. Никто, ни разработчики, ни QA-инженеры ничего не делают сами по себе, только потому, что это взбрело в голову.
Задачи предварительно обсуждаются, а после их выполнения проходят Code Review со стороны разработки и несколько этапов тестирования со стороны QA. Вся работа исключительно командная.
О том, как у нас построено тестирование в целом и о Code Review в частности очень подробно написал руководитель отдела тестирования — Илья Агеев. Почитайте , это интересно.
Спасибо за ответ, обязательно прочту. И спасибо за статью! Мысль про отлов JS-ошибок очень актуальна в рамках нашего проекта, поэтому возьму на вооружение и попробую запустить у себя нечто подобное.
Sign up to leave a comment.