Эта статья написана новичком, человеком, который не занимался нагрузочным тестированием, но очень пытался понять: сходил на тематическую встречу QA Club Minsk и очень много лазил в интернете, пытаясь как-то систематизировать знания. Пост оформлен как FAQ по тем вопросам, ответы на которые, вероятно, могут быть полезными совсем новичкам в этом деле:
·
Что такое тестирование производительности?
·
Что такое автоматизированный нагрузочный тест или тест производительности?
·
Где взять тестовые сценарии для проведения тестирования производительности?
·
Инструменты нагрузочного тестирования.
·
Настройки и возможности тестов.
·
Что нужно знать, чтобы стать специалистом по тестированию производительности?
·
С чего начинать, когда задание по тестированию производительности формулируют как «система должна быть производительной» или «проведите нагрузочное тестирование»?
·
Как организовать тестовую среду.
·
Пример отчёта о проведении нагрузочного тестирования.
Ошибки в изложении возможны – потому комментарии только приветствуются. Не судите строго. =)
Тестирование производительности – это отдельный вид
тестирования, объектом которого является производительность приложения. Т.е. это вид тестирования, направленный не на проверку, например, корректности работы функциональности, как при функциональном тестировании, а на проверку скорости работы, на получение информации о затрачиваемых ресурсах системы или её частей при определённых условиях (например, заданное количество пользователей, их действия, длительность работы системы в целом и т.д,).
В зависимости от того, какая ставится цель у тестирования производительности, или же - на какой бизнес-вопрос должен ответить проводимый тест, можно выделить следующие виды тестов:
· нагрузочные (load): проводятся для того, чтобы оценить поведение приложения при заданной ожидаемой нагрузке:
· стрессовые (stress): проводятся с целью оценки поведения системы при превышении стандартной нагрузки. Если к моменту организации нагрузочного тестирования нет никакой информации о производительности приложения, то - как минимум для сбора показателей максимальной нагрузки, будет проведён стресс тест.
· стабильности (stability, uptime) - то же самое что и load тест, но который длится в течение месяца-двух с целью убедиться в том, что приложение выдерживает ожидаемую нагрузку в течение длительного времени (при проведении uptime тестов наибольшее внимание уделяется использованию ресурсов).
Как типы тестов на встрече назывались rump up тесты и rush hour тесты - это не виды тестирования, но специфические тесты, используемые в рамках проведения того или иного вида тестирования производительности для получения конкретной информации. Более подробно о них - в разделе о настройках тестов.
Что такое автоматизированный нагрузочный тест или тест производительности?
С помощью специального инструмента обычные тестовые сценарии превращаются в некий программный код, который может быть этим же инструментом выполнен. По сути - это эмуляция работы пользователей системы, однако не столько в смысле выполнения конкретных действий в тестируемом приложении (GUI), но скорее в смысле создания нагрузки на сервер, соответствующей работе пользователей в системе. В зависимости от целей тестирования, эти тестовые сценарии выполняются с различными входными данными и настройками: количество пользователей, скорость их подключения, количество повторений тестового случая, длительность теста и т.д. и т.п.
Как в тестовом сценарии есть ожидаемый результат, так и в нагрузочном тесте можно установить некие элементарные контрольный точки, в соответствии с которыми определяется успешно или нет прошёл тест. Например:
· можно установить максимальное время ожидания отклика сервера;
· можно установить проверку на код ответа сервера (200, 300 и т.п);
· можно проверить наличие элемента (кнопка, список, текст и т.д.) на странице;
· и т.д.
Наиболее важными результатам работы теста являются комплексные графики и таблицы, изучая которые, специалисты проводят оценку работы системы и, по возможности, дают рекомендации.
Обычно тестирование производительности основывается на наиболее часто выполняемых сценариях работы с приложением, источником которых могут быть:
· заказчик, который знает, как будет использована его система;
· бизнес-аналитики системы, которые тоже должны понимать, как система будет использована;
· реальные данные по фактическому использованию системы (если таковые уже имеются);
· критичные сценарии для бизнеса (грубо говоря, те, на которых заказчик деньги зарабатывает, а в случае проблем - из-за которых в первую очередь деньги потеряет).
При выборе инструмента важно понимать, что проводя нагрузочное тестирование, мы тестируем не GUI представление нашего приложения, а создаём в первую очередь нагрузку на сервер, который отвечает за необходимую нам функциональность. А средство нагрузочного тестирования просто «внедряется» в их общение. И если оно не понимает язык общения (JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP), то использовать его мы не сможем. Так, например, с JMeter можно протестировать web сервисы и http запросы, но в общение клиента и сервера через tcp/ip протокол внедриться он уже не сможет.
По структуре все инструменты в принципе своём одинаковы и состоят из следующих компонент:
· recorder – записывает действия, выполняемые пользовате в соотетствии с тестовыми сценариями, и превращает их в программный код;
· code IDE – среда разработки;
· generator - та самая штука, которая создаёт виртуальных пользователей, выполняющих описанные тестовые сценарии;
· analyzer – анализатор показателей-результатов теста.
Инструментов тестирования производительности большое множество, однако на встрече клуба были выделены:
· Apache Jmeter. Средство бесплатное, что, пожалуй, является главным его достоинством и причиной популярности. Инструмент, в целом, неплохой и, как заявлено, вполне полнофункциональный, несмотря на не самый удобный интерфейс. Вот так выглядит скрипт:
К сожалению, этот инструмент имеет достаточно много проблем и ограничений: как упоминалось выше, он может не поддерживать необходимые протоколы; в нём отсутствуют удобные средства мониторинга; выдаваемые им результаты требуют дополнительной обработки; и он содержит довольно много багов сам по себе (например, в последней версии на текущий день (16 апреля 2011г.) не работает несколько блоков IF подряд). Однако приятно то, что у данного инструмента есть хорошая поддержка со стороны разработчика: баги не игнорируются и могут исправляться довольно быстро (естественно, определённых severity =)), инструмент вполне активно развивается.
В целом, JMeter - неплохой инструмент для решения не самых больших и не самых сложных задач при скромном бюджете.
· HP LoadRunner. В отличие от предыдущего инструмента, LoadRunner имеет гораздо больше достоинств, однако наибольшим его недостатком является весьма серьёзная стоимость. Однако если бюджет позволяет, то использование продукта HP будет гораздо более предпочтительным по сравнению с JMeter: LoadRunner имеет более удобный интерфейс, имеет больше возможностей, имеет встроенный мониторинг и предоставляет по результатам выполнения тестов более понятные графики. В целом, на собрании клуба был назван коэффициент 1,5 - во столько раз потребуется меньше усилий при решении одной и той же задачи в LoadRunner по сравнению с JMeter.
Были также названы, но столь серьёзно не рассматривались:
· Borland SilkPerformer.
· Visual Studio Test tools
· Oracle Automation Testing Suites (OATS).
Кстати, если стоит задача протестировать "производительность клиентской части" приложения (например, скорости выполнения каких-то операций) - то это уже несколько другая история: если нам не надо создавать нагрузку на сервер, то использоваться будут не стандартные средства для проведения тестирования производительности, а, например, можно использовать обычное средство для автоматизации функционального тестирования с добавлением в необходимых местах таймеров.
В зависимости от используемого средства автоматизации тестирования производительности, при запуске тестов могут быть настроены некоторые опции:
· При старте теста заданное количество пользователей может быть сгенерировано сразу, а может добавляться для нагрузки системы постепенно - «партиями» через определяемые интервалы времени. Такие тесты называются ramp up. Одной из целей таких тестов может быть: с помощью увеличения нагрузки определить пределы возможностей системы. Ramp up тесты могут проводиться как первый этап выполнения тестирования производительности.
· Может быть установлена длительность тестирования (в минутах, например), а может быть задано количество повторений (итераций) выполнения теста.
· Тестовый сценарий может быть один, а может быть и их набор. Каждому тесту может быть выставлено процентное отношение количества его использования в общем количестве выполняемых тестов.
· Может эмулироваться использование различных браузеров и смешанных типов сетевых протоколов - опять же выставляется процентным соотношением.
· Все тесты из заданного набора могут выполняться по очереди, в установленном порядке, а могут и в случайном.
· С помощью соответствующих настроек можно провести тест, который называется rush hour: сначала подаётся стабильная стандартная (нормальная, ожидаемая) нагрузка, затем идёт резкое увеличение нагрузки до максимума и возврат к нормальному состоянию. Анализируя результаты теста, следует обратить внимание на показатели до и после скачка - если в этих показателях есть более ли менее значительная разница, то это говорит о наличии в системе проблемы.
1. Важно знать основы функционального тестирования.
2. Опыт автоматизированного тестирования иметь желательно, но не обязательно.
3. Очень полезно иметь опыт администрирования (знание протоколов, возможность самостоятельной настройки системы, т.д.).
4. Необходимо научиться хорошо понимать архитектуру приложения.
5. Аналитический склад ума и знание математики будут необходимы для анализа результаты тестов, часто представленных в виде сложных графиков и таблиц.
А вот исходный код приложения знать не обязательно - специалисту по тестированию производительности непосредственно с ним взаимодействовать необходимости нет.
Если у вас нет готового специалиста, и вы думаете, кому поручить провести нагрузочный тест – программисту или не имеющему опыта в этом деле хорошему функциональному тестировщику, - то поручите его тому, кто проявляет к этой деятельности наибольший интерес и у кого есть необходимые для этого навыки и склонности, а так же понимание терминологии, или хотя бы горячее желание всему этому [самостоятельно] обучиться.
Кстати, начинать изучение нагрузочного тестирования можно с изучения словаря (hit, transaction per load, response time, и прочего, что можно увидеть на экране в попытках организовать свои первые запуски теста производительности).
Попробуйте пойти по следующему пути:
1. Уточните задачу и её условия:
· что конкретно нужно узнать: время отклика системы при некой нагрузке, длительности выполнения транзакции, либо максимальное количество пользователей, при работе которых будут выполняться определенные условия (время отклика не более чем время N, сервер отвечает Service Unavailable) и т.д.
2. Уточните информацию о тестируемой системе:
· на какое количество пользователей направлено её использование;
· какие браузеры будут использованы, из каких стран ожидается больше всего пользователей, их соотношение и прочая статистическая информация (при проведении тестирования конфигурации будет важным узнать, какие операционные системы и аппаратное обеспечение будет у большинства конечных пользователей);
· наиболее часто используемые бизнес-сценарии и то, какие компоненты системы они используют (например, для интернет-магазина это поиск, просмотр каталога товаров, совершение покупки);
3. Узнайте о том, какое аппаратное обеспечение будет использовано или используется для продакшн серверов. Организуйте такую же тестовую среду.
4. Узнайте, где находятся реальные рабочие сервера и какова доступная ширина канала. Попробуйте организовать такие же условия.
5. Выберите инструмент для проведения тестирования. Не забудьте убедиться в том, что он поддерживает протоколы общения клиента и сервера.
На встрече сообщества не рассматривался полностью вопрос организации тестовой среды, но были выделены следующие отдельные моменты:
1. Лучше всего проводить тестирование на системе, идентичной той, что будет при реальной работе приложения. Масштабировать результат нельзя, как бы ни хотелось и ни мечталось. =)
2. Каждый элемент системы (база данных, сервер приложения, генератор нагрузки, который забирает
очень много ресурсов, и пр.) желательно устанавливать на отдельную машину. Именно таким образом, будет намного проще определить – какой из элементов является «слабым звеном».
3. Доступная при тестировании ширина канала должна быть адекватна генерируемой нагрузке. В противном случае - результаты тестирования будут некорректными только из-за ограничений по ширине канала. Как правило, всей системе тестирования лучше работать в одной и той же сети, чтобы пропускная способность была максимальной. Тестирование через интернет уменьшает ширину канала.
4. Для проведения нагрузочного тестирования не рекомендуется использовать виртуальные машины: когда ваша система будет работать на основе реальной «железной» - результаты её работы могут оказаться отличными от результатов тестирования на виртуальных машинах.
5. При отсутствии или недостатке собственных ресурсов можно использовать внешние специализированные, например, площадки amazon.com (облака). Но помните, что это те же виртуальные машины. Существуют также риски нарушения безопасности, некомпетентности персонала по конкретно вашему приложению или вопросу.
6. При необходимости провести нагрузочное тестирование, с учетом работы пользователей из разных уголков планеты, можно:
a. Использовать инструменты/сервисы, с помощью которых можно проверить, например, сколько времени будет открываться некая страница из разных точек мира. Примером является сервис
http://newrelic.com.
b. Можно поискать дата-центры, имеющие нужное географиеское местоположение, и провести сеансы тестирования, используя их оборудование. Довольно трудоёмкий и дорогостоящий вариант, но результаты его использования наиболее близки к реальным.
c. Обратится к специалистам, проводящим аутсорсинг нагрузочного тестирования.
В процессах поиска информации для этого обзора, в дебрях интернета нашёлся
пример отчёта о проведённом нагрузочном тестировании. Возможно, кому-то будет полезен.
Спасибо экспертам в вопросе Анатолию Лётычу (Epam) и Дмитрию Тищенко (Itransition) за то, что участники очередной встречи QA Club Minsk смогли с нуля получить представление о нагрузочном тестировании. =)
Автор: Савастюк Наталья. Редактор: Елена Первая. Огромное спасибо за подсказки Масловскому Михаилу и Кныш Надежде.
