краткое содержание

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

Такие действия, как создание и отладка подходящей тестовой среды, слишком сложны и зависят от конкретной ситуации, чтобы давать содержательные рекомендации, но для некоторых ключевых задач я могу предоставить рекомендации, если это возможно. Следующие рекомендации даются вам на шкале. ·Запись сценариев тестирования производительности: каждая транзакция занимает полдня. Фактически, некоторые задачи могут занять больше времени, чем другие. Но, судя по моему опыту тестирования производительности, полдня более разумно.

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

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

Сбор данных (и удаление программного обеспечения): занимает один день. Если это внутренний тест, удаление не требуется. Если вы предоставляете услуги по тестированию, вам необходимо удалить программное обеспечение для тестирования. Дайте себе день, чтобы удалить и собрать результаты тестирования и данные мониторинга KPI.

Шаг первый: анализ потребностей

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

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

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

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

Установите крайний срок для тестирования производительности, включая запланированный график.

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

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

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

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

Шаг 2. Настройте тестовую среду

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

Для настройки тестовой среды необходимо выполнить следующие шаги:

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

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

Учитывайте ссылки на внешние системы. Никогда не игнорируйте внешние ссылки,

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

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

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

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

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

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

Шаг 3. Запишите сценарий транзакции.

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

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

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

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

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

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

Шаг 4. Создайте сценарии тестирования производительности.

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

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

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

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

Разверните типы генерации нагрузки «Большой взрыв», «Нарастание», «Нарастание»/«Снижение» для каждого генератора нагрузки. В зависимости от целей тестирования типы нагрузки могут включать тип «Большой взрыв» для представления статической нагрузки и один или несколько типов переменных «нарастание/нарастание» для проверки масштабируемости-понижения. На рис. 3-2 показан план тестирования производительности с использованием этого подхода. Темный прямоугольник внизу представляет статическую нагрузку, созданную в результате развертывания «Большого взрыва», а различные другие нагрузки поверх него представляют собой типы развертывания с «нарастанием».

Может ли тест выполняться в течение заданного периода времени или он будет прерван из-за недостаточности тестовых данных. Может ли транзакция повторяться несколько раз или потребуется вмешательство пользователя? Если ваши тесты основаны на данных, убедитесь, что вы создали достаточно данных для тестов.

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

Шаг 5. Выполните тестирование производительности

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

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

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

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

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

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

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

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

Шаг 6. Анализ результатов тестирования, написание отчетов о тестировании и восстановление среды.

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

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

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

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