Перейти к содержимому

Фотография

Обсудим создание сценариев тестирования!


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 6

#1 Сэм

Сэм

    Постоянный участник

  • Members
  • PipPipPip
  • 212 сообщений
  • ФИО:Сергей Минаев
  • Город:Москва


Отправлено 25 октября 2005 - 10:48

Приветствую всех!
Покопался на Форуме, но не нашел подобного обсуждения. Тем не менее для меня (и я думаю, такое у многих бывает) встал вопрос: надо стандартизовать автоматизированное (нагрузочное и стресс) тестирование для всех проектов. Все для того, что бы при каждом новом релизе прогонять их при тех же условиях и сравнивать результаты.
Наверняка у многих вставали подобные задачи. Предлагаю обсудить то, как решить их. Какие, как и где собирать исходные данные для выявления параметров тестирования (нагрузочного и стрессового), да и какие параметры-то важно получить?
Я предложу свой взгляд на эту проблему и буду всем очень благодарен за критику и/или встречные точки зрения.

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

Какие параметры нужно получить для сценария тестирования? Я полагаю, что:
1. число юзеров
2. время работы сценария
3. время задержки (think times)
4. время запуска (день, ночь...)
(предполагается, что сам скрипт для теста уже есть)

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

Какие источники можно использовать для получения исходных данных: заказчик, тест план, разработчики, сисадмин.
И наконец, как из исходных данных получить параметры тестирования?

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

Теперь надо из полученных данных определить параметры для теста. Число юзеров, как я понимаю, должно быть связано с think times, ибо невозможно иногда смоделировать работу 200 пользователей напрямую (ограничено число виртуальных юзеров). Как связать эти параметры? При отсутствии дефицита виртуальных юзеров, например, ставим think time 15-20 сек. Если же у нас ожидается 200 пользователей в системе, а смоделировать можем всего лишь 25, то нам надо think time в 200/25=8 раз сокращать? То есть, ставить 2-3 сек задержки? И это все при условии, что суммарный трафик, который создадут такие юзеры, не превысит пропускной способности канала. Иначе, надо сокращать трафик. Но до какого уровня? Процентов на 30 сократить?
Время работы сценария. Наверное, надо ставить по возможности большое (8-12 часов), чтоб смоделировать хотя бы 1 рабочий день под нагрузкой.
Время запуска теста лучше выбирать, когда нет помех в сети, то есть ночью. Таким образом, например, с 22.00 до 8.00, 10 часов.

Для стресс теста, я полагаю, надо изменить число юзеров и think time. То есть максимально увеличить первое и убрать вообще второе. Но не превысить ширину канала! Время можно сократить до 2-4 часов, стресс вроде больше не должен длиться. Время запуска так же ночью...

Вот примерные соображения на описанную тему. Буду очень рад новым взглядам, мнениям и опыту!
Заранее спасибо всем принявшим участие! :smile:
  • 0

#2 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 25 октября 2005 - 19:34

Какие параметры нужно получить для сценария тестирования? Я полагаю, что:
1. число юзеров
2. время работы сценария
3. время задержки (think times)
4. время запуска (день, ночь...)
(предполагается, что сам скрипт для теста уже есть)

A почему из всех RTS отдельно выделен think time? Все RTS нужно знать если уж речь идет о стандартизации. Я бы еще добавил к параметрам тестирования распределение VUs по скриптам и по load generators + стратегия управления ramp up/ramp down для VUs (автоматически или вручную). Ну и обязательно к стандарту надо добавить мониторинговую составляющую сценария (что именно мониторим и какие параметры выбираем).

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

Если сеть не может пропустить весь траффик от предполагаемого количества VUs, то что собственно мы собираемся тестировать?

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

В общем случае может понадобиться информация еще и от DBA, web admin, network admin, security admin.

При отсутствии дефицита виртуальных юзеров, например, ставим think time 15-20 сек. Если же у нас ожидается 200 пользователей в системе, а смоделировать можем всего лишь 25, то нам надо think time в 200/25=8 раз сокращать? То есть, ставить 2-3 сек задержки?

Это называется голь на выдумку хитра :smile: Мне еще не доводилось видеть ни одного американского клиента, который озаботился бы подобной проблемой :rtfm: Если ваша система предполагает поддерживать одновременную работу 200 пользователей, то и лицензию нужно получить на 200 пользователей. Финты ушами с think time позволят создать вам повышенную нагрузку, но это не будет чистым экспериментом. Например, число одновременно работающих сессий на сервере БД так и останется 25, а не 200. Могут быть и еще какие-нибудь gaps во влиянии на систему между 200 "чистыми" пользователями и 25 "грязными". Никакой заранее известной общей зависимости в виде формул между think time и генерируемым уровнем нагрузки на сервер нет. Все это вы сможете определить только эмпирическим путем для конкретной системы в конкретной конфигурации.

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

Не надо ставить по возможности большое или маленькое. Все зависит от ваших objectives. Если ваша цель смоделировать работу системы в течение дня, то тогда 8-12 часов будут уместны. Если нужно посмотреть как система справляется с повышенной нагрузкой, которая длится в течение, например, 2-3 часов, то гонять такой сценарий 8 часов бессмысленно.

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

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

Для стресс теста, я полагаю, надо изменить число юзеров и think time. То есть максимально увеличить первое и убрать вообще второе. Но не превысить ширину канала! Время можно сократить до 2-4 часов, стресс вроде больше не должен длиться. Время запуска так же ночью...

Все вышесказанное относится и к тестированию под стрессовыми нагрузками. Пляшем от ваших objectives. Вместо того, чтобы изгаляться с think time надо получить нормальную лицензию. Ну и rendezvous points использовать полезно раз уж речь идет о стрессе.
  • 0
Дмитрий Шевченко

HP Software

#3 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 26 октября 2005 - 04:38

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

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

http://software-test...really-need.htm
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#4 Сэм

Сэм

    Постоянный участник

  • Members
  • PipPipPip
  • 212 сообщений
  • ФИО:Сергей Минаев
  • Город:Москва


Отправлено 26 октября 2005 - 07:27

Алексей, спасибо за ссылку на ценную статью, на нее я не наткнулся, а зря. Теперь немного по-другому бы рассуждал...
  • 0

#5 Сэм

Сэм

    Постоянный участник

  • Members
  • PipPipPip
  • 212 сообщений
  • ФИО:Сергей Минаев
  • Город:Москва


Отправлено 26 октября 2005 - 08:58

Дмитрий, я согласен по поводу того, что надо добавить в параметры мониторинговую составляющую, а то непонятно, что нужно для сравнения результатов.
Хотелось бы уточнить, какие именно Вы добавили бы RTS? Я бы добавил только распределение по скриптам (если их больше одного) и ramp up/ramp down. Например, я ставлю всегда ramp up по 1 VU каждые 10 сек, а ramp down - сразу всех.
Теперь что касается сети. Предположим, у меня есть 200 VUs, запускаемых с одной машины. Они начинают отрабатывать протаскивая через сеть файлы по 2-8Мб... Тогда канал, который расчитан на 1 пользователя, будет перегружен и не измерения будут показывать лишь его пропускную способность, а не производительность приложения. Я вижу это так.
Теперь про время работы скрипта. По свежим размышлениям и советам, я решил, что для стандарта сравнительных тестов "достаточно и необходимо" 4 часа. Немного с потолка, но как есть. Каких-либо objectives нет тут, приложение уже работающее, нужно просто проверить, что стало не хуже в новой версии...
Со временем запуска тоже согласен. Отчасти. Ночью - никому не мешаем, ни пользователям, ни разработчикам (смотря где пускаем тест). Зато днем, конечно, более реальные условия.
  • 0

#6 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 26 октября 2005 - 18:23

Хотелось бы уточнить, какие именно Вы добавили бы RTS?

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

Предположим, у меня есть 200 VUs, запускаемых с одной машины. Они начинают отрабатывать протаскивая через сеть файлы по 2-8Мб... Тогда канал, который расчитан на 1 пользователя, будет перегружен и не измерения будут показывать лишь его пропускную способность, а не производительность приложения. Я вижу это так.

Правильно видите. Только непонятно зачем же через канал, рассчитанный на 1 пользователя, гнать траффик от 200. Вам нужен канал, который сможет обслуживать всех пользователей. Либо запускать столько пользователей, сколько может выдержать канал.
  • 0
Дмитрий Шевченко

HP Software

#7 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 27 октября 2005 - 14:43

2 Сэм: наверное плохо искали на форуме, потому что подобные проблемы (я имею в виду первоначальную постановку вопроса) уже неоднократно обсуждались в рамках нашего форума.

Я точно уже где - то приводил (или даже сам нашел) вот эту ссылку:
http://www.qaforums....ic;f=2;t=000901

Думаю, здесь вы найдете ответы на все (или уж точно на большую часть) ваши вопросы.

Удачи!
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных