От автора: многие компании, даже если они знают, что производительность является ключом к успеху их бизнеса, часто не уверены в том, как, когда или где тестирование производительности должно выполняться в рамках цикла разработки. И, что еще усугубляет ситуацию, они также, как правило, не уверены, на кого должна возлагаться ответственность за это.
Короткий ответ, конечно, «все время» и «на каждого», но это взаимное исключение является распространенной причиной, по которой производительность часто упускается из виду. Когда за что-то отвечают все, обычно за это не отвечает никто.
Чтобы решить эту проблему и регулярно проводить регулярные тесты производительности, я стараюсь выделять те типы тестирования, которые мы выполняем в трех различных категориях: «Проактивное», «Реактивное» и «Пассивное». У каждого есть свое время, место, цель и аудитория. Простое понимание различных форм тестирования производительности, которые нам доступны, и их места в процессе разработки продукта, упрощает для бизнеса принятие стратегии анализа и поддержки производительности.
В этой короткой статье я хочу познакомить вас с этими тремя типами тестирования, как и когда они должны выполняться, и каковы их цели и результаты. Каждый вид тестирования перечисляется в хронологическом порядке, то есть вы должны выполнять их по порядку, но все они дополняют друг друга и в конечном итоге взаимодействуют друг с другом.
Проактивное
Много раз я проверял клиентские сайты, и многие проблемы и недостатки, которые я обнаружил, могли быть легко обнаружены командой разработчиков. Проблемы можно было выявить, решить и никогда к этому не возвращаться, если бы они только знали, где искать!
Первым типом тестирования должно быть Проактивное тестирование: оно является целенаправленным и представляет собой попытку определить проблемы с производительностью.
Оно выполняется в форме оценки разработчиками влияния на производительность каждой выполняемой ими задачи. Идея заключается в том, что мы рассматриваем проблему, прежде чем она становится собственно проблемой. В конце концов, профилактика лучше, чем лечение. Определение проблем с производительностью на этом этапе гораздо предпочтительнее того, если вы обнаружите их после того, как они проявятся.
Причина, по которой я называю это Проактивным тестированием, заключается в том, что мы, как правило, нуждаемся в том, чтобы уйти с пути, чтобы выявить проблемы. Все всегда кажется быстрым, когда мы разрабатываем это. Потому что чаще всего мы работаем на высокопроизводительных машинах в выделенных сетях, а также обслуживаем продукты на локальном хосте, что устраняется большую часть проблем с задержкой и пропускной способностью, которые реальный пользователь мог бы ощутить на себе.
К сожалению, на этом этапе большинство проблем не определяются. Это хорошая новость для меня, потому что мне платят за то, чтобы найти и исправить их, но компании сэкономили бы много денег, если бы выявили все проблемы с производительностью в этот момент. Поэтому крайне важно, чтобы инженеры имели четкое представление об основах работы, а также о возможностях своих инструментов.
Этот этап тестирования, как правило, довольно узконаправлен и, как правило, не очень ориентирован на бизнес: прочим отделам организации не нужно знать о каких-либо проблемных местах, потому что они еще не существуют в реальном продукте.
Мое участие в работе с клиентами здесь — это, как правило, семинары и тренинги: обучение разработчиков приемам и инструментам, необходимым для эффективного проведения аудита производительности, а также обеспечение самодостаточности команд.
Кто: инженеры
Когда: во время разработки
Для чего: чтобы определить и устранить проблемы, прежде чем они будут перенесены в релиз
С помощью чего: инструменты для разработчиков, браузеры, локальные инструменты
Реактивное
Конечно, невозможно решить (или даже определить) все проблемы с производительностью на этапе разработки. Поэтому мы вводим немного более оборонительный стиль тестирования: реактивное тестирование.
Реактивное тестирование обычно выполняется в ответ на событие в жизненном цикле разработки, такое как сборка или релиз, и измеряет совокупный эффект всех изменений инженеров. Возможно, каждый человек считает, что его изменения не являются негативными, но все изменения в совокупности приводят к неприемлемой регрессии. Важно, чтобы мы это зафиксировали.
Реактивное тестирование должно быть разумно автоматизировано и должно проводиться в как можно более приближенной к реальной среде. Это может означать задачи Gulp, которые запускают Lighthouse вместо вашей промежуточной среды, автоматизированные WebPageTests, которые выполняются при каждом развертывании, бюджеты производительности, которые анализируются при каждой сборке, и так далее.
Это синтетическое тестирование может позволить нам измерять регрессии до того, как они будут перенесены в производство, а представители бизнеса могут решить, достаточно ли значительны регрессии, чтобы отложить релиз, или же мы запускаем релиз и уделяем приоритетное внимание решению проблему в следующей версии. Соответственно, при реактивном тестировании частично должно осуществляться взаимодействие с широкой организацией — как разработчики, так и товарные команды должны быть осведомлены и реагировать на результаты реактивного тестирования производительности.
Любые обнаруженные проблемы возвращаются к Проактивному тестированию для отладки и исправления локально.
Мое участие в работе с клиентами на этом этапе — это оценка того, где лучше всего внедрить инструменты в жизненном цикле разработки, и работать над определением соответствующих пороговых значений и бюджетов.
Кто: инженеры, владельцы продуктов
Когда: каждая сборка, каждый релиз
Для чего: Определить регрессии перед их переносом в реальный продукт
С помощью чего: бюджеты эффективности, автоматизация, синтетическое тестирование, CI
Пассивное
Несмотря на два предыдущих этапа тестирования производительности, мы все еще не в состоянии захватить все, прежде чем оно будет воплощено. В какой-то момент, возможно, наш сайт будет выглядеть сильно отлично от того, как это было в нашей среде разработки: менеджеры тегов, ваши рекламные объявления, размещенные на сайте, пакет аналитики, захватывающий данные — над ними всеми работали сторонние разработчики. Вы находитесь во всемирной паутине — вы понятия не имеете, кто обращается к сайту, каков их контекст, какое оборудование, программное обеспечение или инфраструктуру они используют или что-то еще.
Теперь мы должны проводить пассивные тесты для сбора данных в течении времени и анализа ситуации: можем ли мы определить общие тенденции? Возникаю ли шаблонные проблемы для некоторых браузеров или географических мест? Могут ли изменения в производительности соответствовать изменениям бизнес-показателей?
Для этого нам нужно обратиться к Real User Monitoring (RUM). RUM отлично подходит для сбора реальных и исторических данных, но к этому моменту уже слишком поздно что-то исправлять… ваши проблемы с производительностью уже существуют!
Однако хорошая новость заключается в том, что вы, по крайней мере, осознаете их. Пассивно собирая данные RUM от фактических посетителей, вы будете намного лучше подготовлены, чтобы определить, какие проблемы имеются на вашем сайте в реальной среде.
Проблемы, возникающие здесь, часто требуют больше времени на исправление, поскольку нам нужно собирать и оценивать данные, а затем анализировать их во временном диапазоне (если только у нас нет чего-то критического), после чего мы возвращаемся на стадию Проактивного тестирования, чтобы иметь возможность проверить локально, что мы движемся в правильном направлении.
Мое взаимодействие с клиентами здесь — это либо оценка существующих данных RUM, чтобы определить проблемы с производительностью, либо помощью бизнесу в определении стратегии их исправления или значимых и релевантных показателей для отслеживания.
Кто: инженеры, владельцы продуктов, маркетинг
Когда: постоянно в реальных средах
Для чего: для определения текущих или исторических проблем производительности в реальном времени
С помощью чего: инструменты, аналитика, мониторинг RUM
Что это значит для разработчиков
Теперь у разработчиков есть четкое представление о том, что от них ожидается. Вещи следует проверять рано и часто, и регрессии следует найти и зафиксировать, прежде чем они покинут виртуальную среду.
У них есть четкие временные метки на протяжении всего проекта, которые помогут выявить и устранить проблемы с производительностью, а также улучшить взаимодействие с бизнесом, чтобы постоянно поддерживать и координировать усилия.
Что это значит для бизнеса
Я чувствую, что, когда дело доходит до мониторинга производительности, многие компании все еще не уверены, стоит ли вообще начинать, и по факту они не делают ничего. Демистифицируя процесс тестирования и разбивая его на три четкие категории, каждая из которых имеет свое собственное время, место и цель, мы сразу отбрасываем большое количество ненужных усилий: вместо того, чтобы беспокоиться о том, какова должна быть их стратегия, теперь им просто нужно спросить себя: «Мы уже делаем это?»
Сформулировав, что должны представлять собой этапы тестирования, и как и когда их выполнять, мы можем существенно упростить мониторинг производительности. Это означает, что мы быстрее определим регрессии и, в конечном счете, заработаем и сэкономим деньги для бизнеса.
Источник: https://csswizardry.com/
Редакция: Команда webformyself.
