Три типа тестирования производительности

Три типа тестирования производительности

От автора: многие компании, даже если они знают, что производительность является ключом к успеху их бизнеса, часто не уверены в том, как, когда или где тестирование производительности должно выполняться в рамках цикла разработки. И, что еще усугубляет ситуацию, они также, как правило, не уверены, на кого должна возлагаться ответственность за это.

Короткий ответ, конечно, «все время» и «на каждого», но это взаимное исключение является распространенной причиной, по которой производительность часто упускается из виду. Когда за что-то отвечают все, обычно за это не отвечает никто.

Чтобы решить эту проблему и регулярно проводить регулярные тесты производительности, я стараюсь выделять те типы тестирования, которые мы выполняем в трех различных категориях: «Проактивное», «Реактивное» и «Пассивное». У каждого есть свое время, место, цель и аудитория. Простое понимание различных форм тестирования производительности, которые нам доступны, и их места в процессе разработки продукта, упрощает для бизнеса принятие стратегии анализа и поддержки производительности.

В этой короткой статье я хочу познакомить вас с этими тремя типами тестирования, как и когда они должны выполняться, и каковы их цели и результаты. Каждый вид тестирования перечисляется в хронологическом порядке, то есть вы должны выполнять их по порядку, но все они дополняют друг друга и в конечном итоге взаимодействуют друг с другом.

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

Проактивное

Много раз я проверял клиентские сайты, и многие проблемы и недостатки, которые я обнаружил, могли быть легко обнаружены командой разработчиков. Проблемы можно было выявить, решить и никогда к этому не возвращаться, если бы они только знали, где искать!

Первым типом тестирования должно быть Проактивное тестирование: оно является целенаправленным и представляет собой попытку определить проблемы с производительностью.

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

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

К сожалению, на этом этапе большинство проблем не определяются. Это хорошая новость для меня, потому что мне платят за то, чтобы найти и исправить их, но компании сэкономили бы много денег, если бы выявили все проблемы с производительностью в этот момент. Поэтому крайне важно, чтобы инженеры имели четкое представление об основах работы, а также о возможностях своих инструментов.

Этот этап тестирования, как правило, довольно узконаправлен и, как правило, не очень ориентирован на бизнес: прочим отделам организации не нужно знать о каких-либо проблемных местах, потому что они еще не существуют в реальном продукте.

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

Кто: инженеры

Когда: во время разработки

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

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

Реактивное

Конечно, невозможно решить (или даже определить) все проблемы с производительностью на этапе разработки. Поэтому мы вводим немного более оборонительный стиль тестирования: реактивное тестирование.

Реактивное тестирование обычно выполняется в ответ на событие в жизненном цикле разработки, такое как сборка или релиз, и измеряет совокупный эффект всех изменений инженеров. Возможно, каждый человек считает, что его изменения не являются негативными, но все изменения в совокупности приводят к неприемлемой регрессии. Важно, чтобы мы это зафиксировали.

Реактивное тестирование должно быть разумно автоматизировано и должно проводиться в как можно более приближенной к реальной среде. Это может означать задачи Gulp, которые запускают Lighthouse вместо вашей промежуточной среды, автоматизированные WebPageTests, которые выполняются при каждом развертывании, бюджеты производительности, которые анализируются при каждой сборке, и так далее.

Это синтетическое тестирование может позволить нам измерять регрессии до того, как они будут перенесены в производство, а представители бизнеса могут решить, достаточно ли значительны регрессии, чтобы отложить релиз, или же мы запускаем релиз и уделяем приоритетное внимание решению проблему в следующей версии. Соответственно, при реактивном тестировании частично должно осуществляться взаимодействие с широкой организацией — как разработчики, так и товарные команды должны быть осведомлены и реагировать на результаты реактивного тестирования производительности.

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

Любые обнаруженные проблемы возвращаются к Проактивному тестированию для отладки и исправления локально.
Мое участие в работе с клиентами на этом этапе — это оценка того, где лучше всего внедрить инструменты в жизненном цикле разработки, и работать над определением соответствующих пороговых значений и бюджетов.

Кто: инженеры, владельцы продуктов

Когда: каждая сборка, каждый релиз

Для чего: Определить регрессии перед их переносом в реальный продукт

С помощью чего: бюджеты эффективности, автоматизация, синтетическое тестирование, CI

Пассивное

Несмотря на два предыдущих этапа тестирования производительности, мы все еще не в состоянии захватить все, прежде чем оно будет воплощено. В какой-то момент, возможно, наш сайт будет выглядеть сильно отлично от того, как это было в нашей среде разработки: менеджеры тегов, ваши рекламные объявления, размещенные на сайте, пакет аналитики, захватывающий данные — над ними всеми работали сторонние разработчики. Вы находитесь во всемирной паутине — вы понятия не имеете, кто обращается к сайту, каков их контекст, какое оборудование, программное обеспечение или инфраструктуру они используют или что-то еще.

Теперь мы должны проводить пассивные тесты для сбора данных в течении времени и анализа ситуации: можем ли мы определить общие тенденции? Возникаю ли шаблонные проблемы для некоторых браузеров или географических мест? Могут ли изменения в производительности соответствовать изменениям бизнес-показателей?

Для этого нам нужно обратиться к Real User Monitoring (RUM). RUM отлично подходит для сбора реальных и исторических данных, но к этому моменту уже слишком поздно что-то исправлять… ваши проблемы с производительностью уже существуют!

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

Проблемы, возникающие здесь, часто требуют больше времени на исправление, поскольку нам нужно собирать и оценивать данные, а затем анализировать их во временном диапазоне (если только у нас нет чего-то критического), после чего мы возвращаемся на стадию Проактивного тестирования, чтобы иметь возможность проверить локально, что мы движемся в правильном направлении.

Мое взаимодействие с клиентами здесь — это либо оценка существующих данных RUM, чтобы определить проблемы с производительностью, либо помощью бизнесу в определении стратегии их исправления или значимых и релевантных показателей для отслеживания.

Кто: инженеры, владельцы продуктов, маркетинг

Когда: постоянно в реальных средах

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

С помощью чего: инструменты, аналитика, мониторинг RUM

Что это значит для разработчиков

Теперь у разработчиков есть четкое представление о том, что от них ожидается. Вещи следует проверять рано и часто, и регрессии следует найти и зафиксировать, прежде чем они покинут виртуальную среду.

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

Что это значит для бизнеса

Я чувствую, что, когда дело доходит до мониторинга производительности, многие компании все еще не уверены, стоит ли вообще начинать, и по факту они не делают ничего. Демистифицируя процесс тестирования и разбивая его на три четкие категории, каждая из которых имеет свое собственное время, место и цель, мы сразу отбрасываем большое количество ненужных усилий: вместо того, чтобы беспокоиться о том, какова должна быть их стратегия, теперь им просто нужно спросить себя: «Мы уже делаем это?»

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

Источник: https://csswizardry.com/

Редакция: Команда webformyself.

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении

Узнать подробнее

Практика монетизации блога: от раскрутки до реальных денег

Пошаговая система по созданию, раскрутки и монетизации блога.

Научиться

Метки:

Похожие статьи:

Комментарии Вконтакте:

Комментарии Facebook:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Я не робот.

Spam Protection by WP-SpamFree