Контрольный список подготовки к тестированию нагрузки

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

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

Анкета по сбору требований

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

Ответы на эти вопросы помогут вам создать стратегию / план тестирования качества. Если клиент не может дать ответы на все эти вопросы, не о чем беспокоиться. Мы всегда можем изучить тестируемое приложение и найти ответы. Например, если имеется инструмент APM/log, мы можем получить данные о параллельных пользователях, пропускной способности и времени отклика из производственной системы. Никогда не думайте, что вы получите то, что вам нужно, не спрашивая.

Найдите подходящий инструмент для тестирования производительности

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

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

Все виды тестирования производительности требуют времени и усилий. Выполнение нагрузочного тестирования может спасти организацию от потенциального унижения, но в то же время тесты на бесплатном инструменте с открытым исходным кодом, таком как JMeter, не оправдают инвестиций. Когда дело доходит до истинного понимания производительности веб-сайта или приложения с точки зрения конечного пользователя, тестов на основе протоколов недостаточно. Кроме того, необходимо измерить производительность взаимодействий и шагов на стороне клиента. Ниже приведено сравнение LoadView с другими решениями для тестирования производительности и нагрузочного тестирования, а также объяснение того, почему следует выбрать LoadView в соответствии с требованиями к тестированию производительности.

Когда дело доходит до медленной загрузки сайтов и приложений, клиенты могут быстро стать нетерпеливыми и уйдут и найдут замену, если ваш сайт / приложение не соответствует их ожиданиям. Знание того, сколько ваш сайт / приложение может обработать, очень важно по разным причинам, но есть несколько важных сценариев, в которых платформа LoadView может помочь:

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

План/стратегия тестирования производительности

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

• Цели тестирования производительности. Чего мы добьемся.
• Сфера охвата проекта. Каков масштаб проекта, пример: Количество скриптов, сколько времени нам нужно тестировать и т.д.
• Архитектура приложений. Информация о приложении такого сервера приложений, DB сервера, вы можете включить архитектурную диаграмму, если у вас есть.
• Подробная информация об окружающейсреде . Подробная информация об окружающей среде, которую мы собираемся протестировать. Всегда хорошо иметь изолированную среду для тестирования производительности.
• Настройка инфраструктуры. Первоначальная настройка для тестирования производительности (например, облачная среда, установка инструментов и т.д.).
• Подход к тестированию производительности. Как мы собираемся провести тест. Мы должны начать с базового теста с меньшим числом пользователей, а затем постепенно мы можем увеличить пользователей и выполнять различные типы тестов, как стресс, выносливость и т.д.
• Критерии входа и выезда. Это очень важно. Мы всегда должны начинать тестирование производительности, когда есть нулевые функциональные дефекты. Так же, как мы должны документировать, когда мы можем остановить тестирование производительности.
• Управление дефектами. Мы должны следовать тем же инструментам и практикам, за которыми следует клиент, чтобы регистрировать дефекты, связанные с тестированием производительности.
• Роли и обязанности. Подробная информация о держателях акций, участвующих в различных мероприятиях во время тестирования производительности.
• Предположения и риски. Если есть цели, которые могут быть риском для тестирования производительности, мы должны задокументировать его.
• Стратегия тестирования данных. Подробная информация о стратегии тестовых данных и о том, как мы можем извлечь их.
• Сроки и ключевые результаты тестового плана. Хронология сценариев, тестового выполнения, анализа и результатов для проверки клиентов.

Фактическое тестирование производительности основано на комбинации методов. Для достижения ожидаемых целей нам необходимо подготовить другую стратегию для различных требований к тестированию производительности. Существуют различные метрики, такие как пользовательная нагрузка, одновременные пользователи, модели рабочей нагрузки и т.д., которые необходимо учитывать перед планированием нагрузки. Если вы работали над моделированием рабочей нагрузки раньше, вы бы услышали о законе Литтла. Вы должны узнать его и реализовать его, прежде чем планировать тест, чтобы получить желаемые результаты.

Сценарии/сценарии производительности в режиме реального времени

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

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

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

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

• Каково общее количество пользователей, работающих с приложением, при условии, что среднее число в рабочее время?
• Какие действия выполняют пользователи и как часто?
• Сколько пользователей работает с приложением в часы пиковой нагрузки?

Ответы на вышеперечисленные вопросы можно получить с помощью анкеты для сбора требований или статистических данных, собранных с помощью инструментов веб-аналитики, таких как инструменты APM/Google Analytics. Анализ транзакций позволяет находить важные бизнес-транзакции и разрабатывать сценарии тестирования производительности, которые будут использоваться для выполнения теста производительности.

Моделирование рабочей нагрузки

Мы можем планировать нашу модель рабочей нагрузки по-разному. Инженеры по производительности должны изучить и отпрактиковать концепцию «Закона маленького» перед выбором модели рабочей нагрузки. Ниже приведены некоторые из существующих моделей рабочей нагрузки. Опять же, инженер по производительности должен выбрать модель рабочей нагрузки на основе требований, которые в данных руках.

Рабочая нагрузка Модель 1. Это просто простая модель, где количество пользователей будет постоянно увеличивается по мере продвижения теста. Пример: один пользователь в секунду до завершения теста.

Рабочая нагрузка Модель 2. В этой модели количество пользователей будет увеличено как шаг на весь период тестирования. Например, первые 15 минут будут 100 пользователей и следующие 15 минут будет 200 и т.д. Мы можем спланировать этот тип теста для тестирования на выносливость.

Рабочая нагрузка Модель 3. Это наиболее распространенная модель тестирования производительности. Количество пользователей будет постоянно увеличивается в течение определенного времени (мы называем это период наращивания). После этого пользователи будут иметь стабильное состояние в течение определенного периода времени. Затем пользователи начнут рампы вниз и тест будет закончить. Например, если мы планируем 1,5 часа тестирования, мы можем дать 15 минут для наращивания пользователей и 15 минут для рампы вниз. Устойчивое состояние будет один час. Когда мы проанализируем результаты, мы будем принимать только стабильное состояние для рассмотрения.

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

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

Сбор данных

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

Время отклика: Время отклика – это время, которое сервер занял для ответа на запрос клиента. Есть много факторов, которые будут влиять на время отклика сервера. Тест нагрузки поможет найти и устранить те факторы, которые ухудшают время отклика.

Среднее время отклика: Это будет среднее значение времени отклика в течение всего срока стабильного состояния в тестовом тестировании нагрузки.

90 процентов времени отклика: 90-е время отклика означает, что 90 процентов времени отклика падает ниже этого значения. Например, если у вас было 500 запросов, и каждый из них имеет разное время отклика, то 90-й процентиль – это любое значение, которое 90 процентов всех остальных значений ниже 90 процентиль. Только 10 процентов времени отклика будет выше, чем 90 процентов значения. Это будет полезно, если некоторые из ваших запросов имеет огромное время отклика, и они перекос средний результат времени отклика.

Запросы в секунду: Мы должны найти это значение из инструментов APM или с помощью производственных журналов. На основе одновременных пользователей мы можем планировать запрос в секунду на сервер.

Использование памяти: Это метрики, со стороны инфраструктуры, которые помогают выявить узкие места. Кроме того, вы должны планировать свою рабочую нагрузку в режиме реального времени, насколько это возможно. Убедитесь, что мы не бомбардируем сервер непрерывными запросами.

Использование процессора: Так же, как память и должны иметь глаза на эту метрику во время выполнения тестов производительности.

Уровень ошибок: Мы должны отслеживать соотношение транзакций с пройденным/ошибкой. Уровень ошибок не должен быть более 2 процентов пройденных транзакций. Если уровень ошибок увеличивается по мере увеличения числа одновременных пользователей, может возникнуть потенциальное узкое место.

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

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

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

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

Контрольный список среды тестирования производительности (перед выполнением)

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

Вывод: Контрольный список подготовки к тестированию нагрузки

Успешное тестирование производительности программного обеспечения происходит не случайно. Архитекторы, владельцы продуктов, разработчики и команда тестирования производительности должны работать вместе и решать требования к тестированию производительности, прежде чем оценивать программное обеспечение. Более подробную информацию о платформе LoadView можно найти в нашей статье «Технический обзор», чтобы узнать, как максимально использовать тестирование производительности. Тестирование производительности должно быть непрерывным процессом. Когда ваш веб-сайт или веб-приложение начинает расти, вам нужно будет внести изменения, чтобы разместить большую базу пользователей. Существует всегда шанс улучшения в любом приложении и тестах.

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

Или зарегистрируйтесь на бесплатную пробную версию LoadView, чтобы начать работать с нагрузкой тесты прямо сейчас. Мы предоставим вам бесплатные нагрузочные тесты, чтобы начать работу! Счастливое тестирование нагрузки!