Home

На очередной встрече сообщества тестировщиков Санкт-Петербурга, состоявшейся 26 мая 2011 года, с докладом «Нагрузочное тестирование с точки зрения тестирования» выступила Марина Широчкина, специалист по нагрузочному тестированию компании Яндекс. Предлагаем Вам ознакомиться с записью выступления в виде слайдкаста (на сайте сообщества желающие смогут найти также видеозапись).

Перевод: Комендантов Илья, компания "Lohika" (г. Одесса)

Оригинал

В статье описаны типовые решения проблем, с которыми может столкнуться пользователь  Ajax TruClient – протокола для записи Web2.0 сайтов, появившегося в 11-й версии HP LoadRunner. А также приведены примеры и советы по использованию тех или иных возможностей нового протокола.

Автор: Комендантов Илья

В предыдущей статье мы начали теоретическое знакомство с новым членом семейства веб-протоколов HP LoadRunner – TruClient. Закончилось оно хвалебной одой в его адрес: быстрое и лёгкое создание скриптов и богатые возможности настройки знаменуют полную и безоговорочную победу светлого будущего нагрузочного тестирования! Восторженные крики, овации, занавес.

Однако не стоит, конечно, делать выводы, основанные только на теоретическом обзоре. «Теория без практики мертва» – утверждал Александр Васильевич Суворов.Поэтому давайте попробуем посмотреть на конкретном примере, как происходит запись скрипта в TruClient.

В качестве подопытного кролика возьмём сайт http://www.signappnow.com/sheet/create . На странице несколько текстовых полей, календарик jQuery, кнопка и простенькая система защиты от автоматических регистраций на основе арифметического выражения. «Вооружение» – HP LoadRunner 11.0 Patch 2 (на момент написания статьи самая свежая версия).

Что ж, с исходными данными ознакомились, приступим-с.

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

Автор: Комендантов Илья, компания "Lohika" (г. Одесса)

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

Скорость доступа к информации, которую запрашивает браузер пользователя, зависит от характеристик работы множества звеньев: запросов к серверу баз данных, расчётов, производимых сервером приложений, "занятости" веб-сервера при огромной нагрузке (миллионом пользователей уже никого не удивишь), загруженности канала связи и многих других. Звенья в свою очередь состоят из более мелких частей, которые могут оказаться тем самым "узким местом", определяющим скорость всей системы, и пользователь вынужден ждать. Но не все обладают терпением Будды.

Поиск "узкого места" - нетривиальная задача. Отдельно модули системы могут работать без видимых отклонений, а производительность системы при этом оказывается далека от желаемой. Проблему интеграции можно описать словами Задорнова: "...по отдельности вы совершенно нормальные ребята! Но когда вместе – это буквально всероссийское бедствие, причем вечное". Коварство слабых звеньев ещё и в том, что при небольшой нагрузке, проявляются только грубые ошибки интеграции, лежащие на поверхности. В реальной жизни начинают сбоить даже те места системы, которые никак не проявлялись ранее. Часто такое поведение связано с проблемами в архитектуре. Нетрудно представить последствия глобальных изменений на финальных стадиях разработки.

Автор: Алексей Баранцев

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

Начну я с рассказа про "золотую середину" -- инструменты с декларативным стилем описания сценариев, то есть не требующие умения программировать, но всё-таки позволяющие задать достаточно сложный сценарий. Потом постепенно перейдём к инструментам, которые позволяют писать сценарии на некотором языке программирования. Далее я расскажу про онлайновые сервисы, позволяющие генерировать нагрузку "из облака". А потом -- про всё остальное :)

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

А в этой заметке я начну рассказывать про BadBoy, который некоторые тестировщики используют как рекордер, чтобы готовить тесты для JMeter, и как раз этот способ его использования я сегодня опишу.

Панкратов Вячеслав, при активном участии консультанта проекта Дмитрия Шевченко.

Содержание: 

• Схема + определение ролей
• Действующие лица
• Создание виртуальных пользователей (V-Users)
• Создание сценариев

Автор: Дмитрий Демченко

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

Автор: Алексей Мишуловин

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

Автор: Сергей Мартыненко

Термин «нагрузочное тестирование» обычно используют в значении «тестирование производительности». А что же тогда есть собственно нагрузочное тестирование?

RUP:

Load testing is a performance test which subjects the target-of-test to varying workloads to measure and evaluate the performance behaviors and ability of the target-of-test to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).

Вольный перевод.

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