Скорость загрузки страницы для клиента. С момента перехода на страницу и момента завершения рендеринга страницы.

Под какой технологический стек вам надо то?

Скорость загрузки страницы для клиента. С момента перехода на страницу и момента завершения рендеринга страницы.

+ для замера конечников очень желательно делать срез с привязкой по географии, можно сильно удивиться. что в каком-то регионе сайт почти не грузится

в общем то в хроме в консоли в нетворке пишет время загрузки

Удваиваю.

https://ping-admin.ru/free_test/

Под какой технологический стек вам надо то?

React.js и всё вытекающие из этого. Бекенд мы уже меряем. Поэтому интересует именно рендеринг.

А еще хотелось бы автоматизировать этот процесс. Чтоб после каждого нового релиза иметь картинку по тому, ухудшилось, или не ухудшилась скорость загрузки страницы. Причем тут опять же вопрос, для получения норм оценки мерять придется на моках. Но ведь также есть вероятность, что в реальных условиях он будет отрабатывать не так.

У рендеринга есть много нюансов: 1. Поточность загрузки (например, CSS по умолчанию загружается параллельно, а JS последовательно, блокируя выкачку ресурсов). 2. Наличие SSR (React-разработчики знают, что это такое). 3. Reflow 4. Построение DOM-дерева и тд

А еще хотелось бы автоматизировать этот процесс. Чтоб после каждого нового релиза иметь картинку по тому, ухудшилось, или не ухудшилась скорость загрузки страницы. Причем тут опять же вопрос, для получения норм оценки мерять придется на моках. Но ведь также есть вероятность, что в реальных условиях он будет отрабатывать не так.

запускайте тот же фф из докера и результаты его плагина стягивайте в статистику

Дим, это как можно сделать?

Дим, это как можно сделать?

сделать что именно? )

Запустить FF в Docker и забрать результаты из плагина)

запускайте тот же фф из докера и результаты его плагина стягивайте в статистику

Но ведь синтетические результаты получаются. Разве нет? Операционная система отличается от Оси целевой аудитории. И ФФ не настолько популярный как хром. Хотя имеет смысл посмотреть в сторону api хрома, и с его помощью мерить. Эти плагины все умеют отслеживать тот самый момент, когда страница полностью отрисовалась?

Но ведь синтетические результаты получаются. Разве нет? Операционная система отличается от Оси целевой аудитории. И ФФ не настолько популярный как хром. Хотя имеет смысл посмотреть в сторону api хрома, и с его помощью мерить. Эти плагины все умеют отслеживать тот самый момент, когда страница полностью отрисовалась?

консоль хрома вам не показывает то что нужно?

+vpn если нужно с разных стран смотреть

но тут впн отжирает

Запустить FF в Docker и забрать результаты из плагина)

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

Это все какие-то поверхностные инструменты, нужен глубокий профайлинг видимо

Но ведь синтетические результаты получаются. Разве нет? Операционная система отличается от Оси целевой аудитории. И ФФ не настолько популярный как хром. Хотя имеет смысл посмотреть в сторону api хрома, и с его помощью мерить. Эти плагины все умеют отслеживать тот самый момент, когда страница полностью отрисовалась?

практика показала, что если скорость обработки просаживается в одном браузере, то высоковероятно это происходит и в других

На уровне интерпретатора JS

Чтобы с графами вызова функций и прочим адом )

Возможно это стоит делать какому-то JS аналитику)

Чтобы с графами вызова функций и прочим адом )

Не, пока наши фронтендеры попросили нас научится мерить именно время на рендеринг страницы. Как я поняла, проблема именно в том, что сейчас они не знают, сколько времени занимает отрисовка страницы. Особенно в условиях асинхронна.

А что разрабы сами не могут разработать себе тул?

На клиенте мерять JS время рендера и загрузки и по-тихому сливать на свои сервера

Агрегировать статистику и анализировать

Ну это значит написать свою тулзятинку. Вот чтоб агрегировало и графики рисовало. А я думала, что есть уже готовые решения.

А, ну в общем этой лучше сходить к ДЖсерам, скорее всего они знают готовые тулзы

Но вообще я не уверен что часть агрегации и анализа где-то есть реализованная.

Для больших распределенных систем все пишут сами, хранят в elastisearch там или где еще. Эти тулз метрических дофига.

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

в условиях распределенных систем и распределенной разработки, надеяться на то, что разработчик включит отладочную панель и будет мерять производительность... ну как-то слабо в это верится)

Мне кажется наваять самим тулзу для измерения это вопрос недели максимум. Если у вас хорошая архитектура и язык хорошо изучен.

Зато потом годами можно ею пользоваться, по чуть чуть апгрейдя.

Зато потом годами можно ею пользоваться, по чуть чуть апгрейдя.

+1 к собственной тулзе

Даа) ладно, спасибо за совет ребят. Зайду еще к jsникам, и надо думать.

Даа) ладно, спасибо за совет ребят. Зайду еще к jsникам, и надо думать.

Про xhr вам тут говорили? Мне лень все сканить

еще не говорили) стоит почитать про тулзу?

что-то не похоже на тулзу

Этож вроде какой-то метод или объект в жс..

еще не говорили) стоит почитать про тулзу?

Сори, перепутал, har конечно же http://www.swtestacademy.com/webdriver-browsermob-proxy/ Почитайте, это то, что вам нужно И с автоматизацией, но автоматизирован будет только сбор, для анализа и сравнения искать надо либо писать

Тут конечно вопрос, если вы собираете данные при тестировании без инъекций мониторов в веб клиент, как писал Павел, то вам надо запустить десятки или сотни раз тесты, чтобы получить статистику, а не единичные результаты производительности Другой подход добавить код в клиента, который будет собирать данные при использовании вашего приложения юзерами и слать вам Тогда вам надо будет их анализировать Конечно грубо протестировав перед реализом что у вас не уходит приложение в умат Во втором случае у вас статистика качественнее Она будет от реальных юзеров и её будет больше, она будет разнообразнее ( все эти браузера, локации, сети, прочее барахло) Но вы оба варианты не замутите без чела, который понимает что делать

Ну конечно, второй подход намного качественнее, там и покрытие браузеров больше, и инфа гораздо адекватнее

еще не говорили) стоит почитать про тулзу?

Угу?

Ну конечно, второй подход намного качественнее, там и покрытие браузеров больше, и инфа гораздо адекватнее

Там тоже грабли есть)

Воу) стало понятнее. Надо с нашими фронтендерами общаться. Готовы ли они инъекции делать.

а инъекции ваши клиента на лопатки на положат?

Как напишут, так и положит

Воу) стало понятнее. Надо с нашими фронтендерами общаться. Готовы ли они инъекции делать.

посмотрите newRelic там, если память не изменяет, были инструменты постоянного мониторинга и сбора статистики по стабильности и скорости работы конечного пользователя.

Есть еще такая штука: sitespeed.io

А кто-нибудь уже попробовал laravel dusk?

Всем привет, может кто резюме оценить ? Junior Qa)

Всем привет, может кто резюме оценить ? Junior Qa)

500 рублей

Всем привет, может кто резюме оценить ? Junior Qa)

Кидай)

кидай

я хоть пойму чё там пишут для жуниор куа

кидай и мне

а что значит оценить?

а что значит оценить?

высказать своё субъективное "фе" )

500 рублей

сделай гугл док расшарь по ссылке и разреши комментировать. мы тебе напишем там всё ?

сделай гугл док расшарь по ссылке и разреши комментировать. мы тебе напишем там всё ?

хитро???

А чо такого-то?

Всем привет, может кто резюме оценить ? Junior Qa)

И так возьмут

кто в курсе какие тулы помогают автоматически генерировать тесты, тест дизайн? mbt, pairwise, ещё?

ERROR: S client not available

А кто уже юзал pairwiser? можете про него чего интересного рассказать?

http://qcthoughtsaloud.blogspot.ru/2010/06/pairwise-testing.html?m=1

Есть же старый-добрый Allpairs

http://siliconangle.com/blog/2017/01/23/tricentis-hauls-165m-automate-software-testing-devops-devotees/

А кто уже юзал pairwiser? можете про него чего интересного рассказать?

Я недавно начал, любопытно Сделал тест на end to end Скармливаю селениуму комбинации параметров которые надо проставить на странице и проверяю Для генерации использую pict

Начал пользоваться после этого доклада https://www.youtube.com/watch?v=Bqmuw3ZJ75g

много найденных багов это хорошая работа тестировщика, или плохая работа разработчика?

найденных где?

при тестировании

не на проде

тогда смотря каких.

разраб сказал все готово собирай ветку, собрал ветку а там баги

Имхо, вообще ни то, ни другое. Баги в разработке есть всегда, а то что тестировщик много багов нашел (и их починили) - не значит что продукт будет качественный в итоге.

хорошо а такой вопрос можно ли тестировщика считать как бы лакмусовой бумажкой отдела разработки?

ну как бы разделять их, уже плохая идея

отдали норм продукт, все молодцы

отдали хреновый, всем по шее

так нет я не говорюо разделении

отдали хреновый, всем по шее

+

ну ты собрался по тестировщику определять крутость отдела разработки, низятак

не совсем

разраб сказал все готово собирай ветку, собрал ветку а там баги

это поиск крайнего, плохая практика

например два отдела разработки в одном тестировщик заводит много багов в другом гораздо меньше

ну тут вообще абстрактная хрень

может быть меньше потому что девелоперы лучше пишут

или потому что у тестировщика скилла не хватает

тоесть разраб написал код и в нем оставил кучу мелочи которая сразу вываливается когда просто запускаешь приложение например а в другом разраб сделал отже самое наткнулся на эту мелочь и тут же пофиксил

например два отдела разработки в одном тестировщик заводит много багов в другом гораздо меньше

в другом могут о багах сообщать не через багтрекер а в чатик например

допустим в обоих сообщают в баг трекер

а еще разрабы иногда свое решение тестируют: один получше смотрит, повнимательнее: а другой даже не запускает

короче, не бери "сейчас", бери "потом"