Такие термины, как тестирование производительности, нагрузочное и стресс-тестирование часто используются как синонимы. Однако замер скорости работы сервиса и измерение возможной нагрузки на него – это не одно и то же, а подтверждение способности сервиса справиться с нормальным уровнем нагрузки не означает, что он так же среагирует на очень высокую. Как же создавать высокоэффективные тесты производительности, не налепив распространенных ошибок?
Вначале определитесь, чего вы ожидаете от сервиса, и что именно вы хотите проверить. Ваше приложение – "заяц", обязанный максимально быстро отвечать на вопросы? А может, это "черепаха", которая выигрывает гонку благодаря постоянно поддерживаемой скорости?
В реальной жизни веб-сервисы имеют как качества зайца, так и качества черепахи, и эти качества должны быть сбалансированы. Они проверяются по-разному в зависимости от природы вашего теста. Без глубокого понимания сервиса, его применения пользователями, пользовательской базы и целей теста вы потратите много времени, гоняясь за несуществующими проблемами, в то время как реальные риски утекут у вас сквозь пальцы.
Все, кто когда-либо сталкивался с тестированием производительности, прекрасно знают, как сложно сделать отчеты понятными, хорошо визуализированными и прозрачными для заказчика. Очень важно выбрать "правильные" метрики и разработать нужные профили нагрузки, но если в результате заказчик увидит скучные и непонятные кривые на белом фоне, он вполне может отказаться от тестирования производительности как такового, поскольку результат будет не вполне прозрачен. Давайте посмотрим, как можно улучшить впечатление от результатов тестирования производительности, на примере интеграции JMeter с мощным инструментом визуализации - Grafana.
Я заметил, что тема тестирования производительности все еще остается не до конца понятной для большинства тест-инженеров. Мы стремимся сфокусировать внимание на функциональном аспекте тестирования, оставляя производительность, масштабирование и настройку на усмотрение разработчиков. Разве не является стабильность существенной составляющей качества программного продукта? Особенно во времена распределенной обработки данных, когда мы масштабируем приложения независимо друг от друга и всецело рассчитываем на внедрение интеграций по HTTP протоколу. Другим существенным фактором является возможность расширения систем. Для того, чтобы справиться с увеличением трафика, мы должны быть осведомлены об ограничениях пропускной способности.
Существует несколько хорошо известных тестировщикам инструментов, таких как JMeter, Gatling, Tsung и т.д. И хотя они довольно просты в использовании, анализ полученных результатов и выводы на их основании представляют для тестировщиков сложность. Во время проведения собеседований на позицию QA инженера я часто встречаю кандидатов, утверждающих, что у них есть опыт в области тестирования производительности, но, по факту, не обладающих знаниями метрик и основных понятий с ним связанным. Поскольку основной задачей тестирования производительности является не знание инструментария, а данные, полученные с его помощью, цель этой статьи - рассмотреть основные аспекты этой сферы тестирования.
Тестирование производительности – обобщенное понятие, которым часто обозначают разные виды проверки ПО. В данной статье команда A1QA с опорой на реальные кейсы расскажет, в какой последовательности проводится тестирование и что измеряется на каждом из этапов.
Первым в череде тестов проводится стресс-тест (StressTest), цель которого – установить предельный уровень производительности продукта. Стресс-тест позволяет проанализировать зависимость ключевых характеристик системы (времени отклика самых важных бизнес-транзакций, количества запросов в секунду, количества транзакций в секунду) от количества одновременно работающих пользователей.
Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, пока не будет достигнут один из критериев его остановки. Например, стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S).
На втором этапе проводится нагрузочный тест(Load Test), с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте. Уровень нагрузки при тестировании банковской системы поддерживался на одном уровне в течение восьми часов и составил 1200 пользователей. Нагрузочный тест показал существенное ухудшение производительности системы с течением времени, а дополнительное профилирование ее компонентов позволило обнаружить дефекты, проявляющиеся только при длительной работе большого количества пользователей (например, утечки памяти).
Сегодня, когда рост вычислительных мощностей снизился, а объемы обрабатываемых данных, количества пользователей и запросов к системам продолжают расти, вопросы производительности и ее тестирования широко обсуждаются в профессиональной среде.
В данной статье команда по тестированию производительности A1QA освещает основные виды тестов и рассказывает, что нужно учесть при их выполнении для получения релевантных результатов.
Перед вами самые распространенные виды тестирования производительности.
1. Стресс-тестирование (Stress Test)
Этот тест проводится первым. Нагрузка постепенно увеличивается до тех пор, пока приложение не перестанет работать корректно. В конце теста фиксируется количество пользователей, которое приложение выдерживало, соответствуя требованиям производительности, и сколько выдержать не смогло. Первое значение и будет пределом производительности вашего приложения. Часто этот вид тестирования проводится, если заказчик предвидит резкое увеличение нагрузки на систему. Например, для e-commerce это могут быть дни распродаж.
Запись доклада Игоря Колосова со встречи QA-talk в Харькове.
- «Семь раз отмерь» — виды требований к производительности ПО. - «За водой или по воду?» — как правильно собирать требования к производительности. - «Пойди туда, не знаю, куда» — хорошие и плохие требования. - «Одинокий рейнджер» — что делать, если вы в проекте играете соло-партию и/или ответственны за сбор требований к производительности.
Однажды наша команда решилась на эксперимент по расстрелу боевой платежной системы реальными деньгами. Это позволило бы понять, сколько сможем выдержать мы вместе с нашими партнерами. Об этом неоднозначном опыте и хочу рассказать.
К исследованию побудили два фактора: появление у нас собственного процессинга карт и предстоящая крупная распродажа одного из популярных в РФ онлайн-ритейлеров.
Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.
Как оказалось, мы не одиноки – ни один из наших банков-партнеров еще полгода назад не знал своего настоящего «потолка» и решал проблемы по мере поступления. По сути, они просто добавляли новые мощности прямо во время распродаж, хотя и не всегда успешно.
Будущие жертвы
Система карточных платежей (Mastercard в нашем случае) соединяет между собой множество внешних организаций, у каждой из которых свой зоопарк систем. Под нагрузку карточных платежей попадают практически все они, поэтому сразу посмотрим на всех участников.
Ниже представлена упрощенная схема взаимодействия нескольких организаций для обеспечения возможности оплатить какой-то товар картой через сервис Яндекс.Денег:
Я заметил, что большинство тестировщиков слабо знакомо с такой областью, как тестирование производительности. В основном мы концентрируем усилия на функциональных аспектах тестирования, оставляя тестирование производительности, масштабируемости и настройки на откуп разработчикам. Но ведь стабильность – важная часть качества продукта, особенно в эпоху распределенных сетей, когда приложения масштабируются независимо и опираются на интеграцию через HTTP-протоколы. Другой аспект качества – способность увеличивать масштаб наших систем. Для того, чтобы справиться с ростом трафика, нужно знать пропускную способность ПО.
Инженеры хорошо знакомы с такими инструментами, как JMeter, Gatling, Tsung. Они относительно просты в использовании, но люди зачастую плохо разбираются в анализе выданных ими результатов, и не умеют делать выводы на их основании. Собеседуя кандидатов на должность тест-инженера, я часто встречаю людей, утверждающих, что они имеют опыт тестирования производительности, но не владеющих знаниями о метриках этого вида тестирования, а также о его элементарных положениях. Основная цель нагрузочного тестирования и тестирования производительности – не умение обращаться с соответствующими инструментами, а знания, полученные в результате их использования. Цель этой статьи – осветить основные аспекты этой области.
Доклад посвящён эволюции методологии используемой для нагрузочного тестирования и основан на практическом опыте нескольких проектов. В начале пути была простая автоматизации нагрузочного тестирования. По-мере усложнения разрабатываемого продукта и изменения требований, возникала потребность в усложнения методологии и в заимствовании подходов хорошо зарекомендовавших себя для функционального тестирования. Кульминацией эволюции, в рамках доклада, будет рассказ об адаптации BDD (Behaviour Driven Develoment) практики для нагрузочного тестирования.
Оригинал статьи: 
Оригинальная статья: 
Тестирование производительности – обобщенное понятие, которым часто обозначают разные виды проверки ПО. В данной статье команда 
Сегодня, когда рост вычислительных мощностей снизился, а объемы обрабатываемых данных, количества пользователей и запросов к системам продолжают расти, вопросы производительности и ее тестирования широко обсуждаются в профессиональной среде.
Запись доклада Игоря Колосова со встречи QA-talk в Харькове.
Оригинал статьи: