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

Автоматизация функционального тестирования
онлайн, начало 3 июля
Автоматизатор мобильных приложений
онлайн, начало 8 июля
Тестирование безопасности
онлайн, начало 8 июля
Автоматизация тестов для REST API при помощи Postman
онлайн, начало 9 июля
Фотография

С чего начинается Performance Testing


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

#21 bolshik

bolshik

    Новый участник

  • Members
  • Pip
  • 44 сообщений
  • Город:Санкт-Петербург

Отправлено 15 марта 2005 - 16:25

Хорошо, тогда, как кажется, задачу можно разделить: ваша система в роли инициатора и в роли аксептора. Также каждый из этих типов делится на, собственно, вашу систему и точку входа\выхода.
Ассептор:
Кроме 'response time и объема пользователей при котором один из 10-15 серваков сдохнет' хорошо бы протестировать систему распределения нагрузки, т.е. не только объемно (найти время, когда 'один из серваков сдохнет'), но и функционально (например, все ноды сразу не будут пытаться обрабатывать входящие fix-messages). Произвести объемное тестирование именно входной точки вашей системы, сравнить потом результаты с результатами объемного тестирования системы т.е. может оказаться, что ваша система, представляющая собой мощный кластер, в состоянии поддерживать одновременную работу, к примеру, ста тысяч пользователей, а fix-сообщения могут обрабатываться, к примеру, только от десяти тысяч.

Initiator:
Сделать то же самое, только в противоположном направлении.

Для тестирования вас как инициатора можно использовать стандартный ui или сразу фасады вашей системы, потому как они уже умеют передаваться в fix-формат.
Для тестирования системы как аксептора, для имитации неправильного поведения\сбоев инициатора, я пишу свой код. Для проверки стандартных операций использую quickfix (http://www.quickfixengine.org/)
  • 0

#22 PeterL

PeterL

    Активный участник

  • Members
  • PipPip
  • 76 сообщений
  • ФИО:Лёвин Пётр Александрович
  • Город:Москва

Отправлено 15 марта 2005 - 16:59

2 bolshik
Спасибо, но не могли бы вы прояснить для меня ещё пару вопросов :) ?

Кроме 'response time и объема пользователей при котором один из 10-15 серваков сдохнет' хорошо бы протестировать систему распределения нагрузки, т.е. не только объемно (найти время, когда 'один из серваков сдохнет'), но и функционально (например, все ноды сразу не будут пытаться обрабатывать входящие fix-messages).

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

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


Initiator:
Сделать то же самое, только в противоположном направлении.

имеется ввиду поток данных к "клиенту" ?
  • 0
Best Regards,
Peter Levin

#23 bolshik

bolshik

    Новый участник

  • Members
  • Pip
  • 44 сообщений
  • Город:Санкт-Петербург

Отправлено 16 марта 2005 - 06:32

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

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

имеется ввиду поток данных к "клиенту" ?

Да, допустим, вы заявляете, что ваша система интегрирована с другой по fix'у, причем поддерживается одновременная работа тридцати тысяч пользователей. Вы знаете, что сама ваша система справляется с такой нагрузкой, но не факт, что initiator пропустит через себя такой объем. Т.е. найти максимум для инициатора, сравнить с максимумом самой систему и заявленным максимумом.
  • 0

#24 Jackie

Jackie

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

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 16 марта 2005 - 07:03

А чем Вам не нравится responce time?
responce time - это один из немногих показателей, с которым сталкиваются пользователи при работе с веб-приложением.
Собственно, цель нагрузочного тестирования (для веб приложения) в том и состоит, чтобы уменьшить время отклика.
  • 0

#25 bolshik

bolshik

    Новый участник

  • Members
  • Pip
  • 44 сообщений
  • Город:Санкт-Петербург

Отправлено 16 марта 2005 - 12:21

[QUOTE]Собственно, цель нагрузочного тестирования (для веб приложения) в том и состоит, чтобы уменьшить время отклика.[code=auto:0]
А как, если не нагрузочным тестированием, можно проверить что, например, при ста пользователях запросы вообще перестают обрабатываться? Здесь речь уже идет не о response time..
  • 0

#26 Dmitry_NJ

Dmitry_NJ

    Консультант

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

Отправлено 16 марта 2005 - 15:54

responce time - это один из немногих показателей, с которым сталкиваются пользователи при работе с веб-приложением.

Response time важен для любых клиент/серверных систем, не только web. Хотя из данного топика у меня не сложилось впечатление, что речь идет о web приложении.
  • 0
Дмитрий Шевченко

HP Software

#27 Dmitry_NJ

Dmitry_NJ

    Консультант

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

Отправлено 16 марта 2005 - 15:58

А как, если не нагрузочным тестированием, можно проверить что, например, при ста пользователях запросы вообще перестают обрабатываться? Здесь речь уже идет не о response time..

Если запросы перестают обрабатываться, то клиент, как правило, не получает ответов от сервера. Соответственно response time увеличивается вплоть до time out.
  • 0
Дмитрий Шевченко

HP Software

#28 PeterL

PeterL

    Активный участник

  • Members
  • PipPip
  • 76 сообщений
  • ФИО:Лёвин Пётр Александрович
  • Город:Москва

Отправлено 16 марта 2005 - 16:33

Response time важен для любых клиент/серверных систем, не только web. 

Если запросы перестают обрабатываться, то клиент, как правило, не получает ответов от сервера. Соответственно response time увеличивается вплоть до time out.

Полностью с вами согласен. Но, как я счиатаю, задача Performance Testing'а, не только выявить наличие проблемы, но и выяснить на каком она уровне происходит, то ли это дефект кода, то ли hardware, то ли ещё чего :), а по одному response time это сделать достаточно проблематично.
  • 0
Best Regards,
Peter Levin

#29 PeterL

PeterL

    Активный участник

  • Members
  • PipPip
  • 76 сообщений
  • ФИО:Лёвин Пётр Александрович
  • Город:Москва

Отправлено 16 марта 2005 - 17:33

[quote name='Dmitry_NJ' date='Mar 14 2005, 07:06 PM'][QUOTE (PeterL @ Mar 14 2005, 11:30 AM)
...работает с арендованными линиями, кадровой трансляцией (frame relay), Интернетом, и т. д. Не определяет конкретный тип протокола безопасности. 

Так это протокол транспортного уровня что ли? Я имел в виду application level protocol. Как вы собираетесь инструмент подбирать?[/quote]
Sorry for delayed reply :)
Тул у нас есть свой (в смысле наши девелоперы написали), заточенный конкретно под клиентскую систему, задача состоит в том чтоб дописать его так чтоб он Performance Testing осуществлять мог, а нашему отделу как раз поручили, кроме остальных performance related issues :) , сформулировать список requirment'ов к этому тулу, как раз в связи с этим и возникает проблема замеряемых метрик, все которые есть в LR сетапить нет смысла, вот и мучаюсь сейчас думая что может пригодиться что нет.
  • 0
Best Regards,
Peter Levin

#30 Dmitry_NJ

Dmitry_NJ

    Консультант

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

Отправлено 17 марта 2005 - 03:08

Но, как я счиатаю, задача Performance Testing'а, не только выявить наличие проблемы, но и выяснить на каком она уровне происходит, то ли это дефект кода, то ли hardware, то ли ещё чего :), а по одному response time это сделать достаточно проблематично.

По response time, естественно, причину проблемы определить невозможно. Response time - это всего лишь температура больного. Чтобы понять причину высокой температуры нужны приборы разной степени сложности. Tот же LoadRunner, например, такие "приборы" обеспечивает.
  • 0
Дмитрий Шевченко

HP Software

#31 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 274 сообщений
  • Город:Москва


Отправлено 17 марта 2005 - 08:40

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

Неверно по нескольким пунктам.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой". Как правило, в десятки - сотни (редко в тысячи) раз больше показателя "Сколько пользователей в секунду обслуживает сервер"
3) Пользователь, как правило, наблюдает не время отклика сервера, а время отклика системы в целом.
Пример.
Вася, работающий на P-166 по диалапу, запросил из библиотеки Машкова документ, объемом 30к.
Сервер отдал все за 0.1 сек; качалось по сети - 8 сек; форматировалось на клиенте - 7 сек
Итог: responce time сервера - 0.1 сек, пользователь имеет дело с задержкой в 15 сек.

Что вы имеете в виду под временем отклика, время до получения первого байта или до получения последнего? Второй показатель более важен.
  • 0

-- 

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

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#32 Jackie

Jackie

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

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 17 марта 2005 - 11:44

Не подскажете ли что можно  придумать для нагрузочного тестирования этой системы,  кроме:
1.Response time
2.Объема пользователей прикотором один из 10-15 серваков сдохнет
И что использовать для тестирования выше перечисленного ?

Определение критериев загрузки по Microsoft:

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

А насчет инструментария - это зависит от тестируемого приложения, Ваших предпочтений, и количества денег, которые Вы готовы выложить за инструмент:)
Я предпочитаю Load Runner. Можно использовать также Silk Performer, Application Center Test от Microsoft, Rational и. т. д.
  • 0

#33 Jackie

Jackie

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

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 17 марта 2005 - 12:15

Неверно по нескольким пунктам.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой"

1) Если тестирование ничего не меняет, то зачем же оно вообще Вам нужно?
Насколько я знаю, тестирование меняет многое - иногда даже саму архитектуру проекта - если выясняется, что добиться
требуемых параметров другими способами нельзя. Именно поэтому рекомендуется начинать тестирование как можно раньше.

2) Сколько пользователей может работать в системе - этот показатель вообще-то должен указываться в документации, а не рассчитываться исходя из результатов тестирования. И если Ваш продукт рассчитан на конечного пользователя - то ему, пользователю, до лампочки, сколько одновременных коннектов выдерживает система. Он имеет дело именно с временем отклика приложения.
  • 0

#34 Jackie

Jackie

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

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 17 марта 2005 - 12:23

Вася, работающий на P-166 по диалапу, запросил из библиотеки Машкова документ, объемом 30к.
Сервер отдал все за 0.1 сек; качалось по сети - 8 сек; форматировалось на клиенте - 7 сек
Итог: responce time сервера - 0.1 сек, пользователь имеет дело с задержкой в 15 сек.

Что вы имеете в виду под временем отклика, время до получения первого байта или до получения последнего? Второй показатель более важен.

Я говорил о времени отклика приложения, а не сервера.
Время отклика приложения (речь идет о веб приложении) включает в себя:
- Задержки на веб-уровне.
- Задержки в базе данных
- Сетевые задержки.
  • 0

#35 Pet[EG]

Pet[EG]

    Активный участник

  • Members
  • PipPip
  • 86 сообщений
  • ФИО:Петраш А.Ю.
  • Город:Харьков, Укр

Отправлено 17 марта 2005 - 12:43

Неверно по нескольким пунктам.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой"

1) Если тестирование ничего не меняет, то зачем же оно вообще Вам нужно?
Насколько я знаю, тестирование меняет многое - иногда даже саму архитектуру проекта - если выясняется, что добиться
требуемых параметров другими способами нельзя. Именно поэтому рекомендуется начинать тестирование как можно раньше.

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

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

2) В максимальное количество пользователей вписываете в документацию как душа возжелает? ;)
  • 0

#36 Jackie

Jackie

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

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 17 марта 2005 - 12:59

,Mar 17 2005, 02:43 PM] 1) Оригинальные у вас суждения о тестировании :) Как уже написал SALar, тестирование ничего не меняет, оно нужно для анализа полученной в ходе разработки системы.

2) В максимальное количество пользователей вписываете в документацию как душа возжелает? ;)


Ох, если бы это были мои суждения - я бы уже был богаче Билла Гейтса.
Уменьшение responce time является главной целью нагрузочного тестирования - это утверждает Microsoft, и в этом случае я с ними совершенно согласен.
Но я никому не навязываю это мнение, упаси Боже! Нравится "анализировать полученную в ходе разработки систему" - пожалуйста! Успехов в Вашем многотрудном начинании:)

2) Максимальное количество пользователей расчитывается на стадии проектирования проекта, - по крайней мере, у нас.
Ну знаете, есть бизнес правила, маркетинговые исследования, прогнозы аналитиков. Цифра эта, конечно, не константа, и может меняться за время жизни приложения.

А как Вы расчитываете ? По типу " я его слепила из того, что было, а потом что было, то и полюбила"?
  • 0

#37 PeterL

PeterL

    Активный участник

  • Members
  • PipPip
  • 76 сообщений
  • ФИО:Лёвин Пётр Александрович
  • Город:Москва

Отправлено 17 марта 2005 - 13:04

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

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

2 Pet[EG]

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

Да, но с учётом этого анализа будут фиксится баги, выпускаться новые релизы, итп. Следовательно - меняет.
  • 0
Best Regards,
Peter Levin

#38 barancev

barancev

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

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


Отправлено 17 марта 2005 - 13:09

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

Слушайте, а ведь Меркури наверное и не догадывается, что ЛоадРаннер -- это инструмент для изменения архитектуры системы :)
  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#39 Jackie

Jackie

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

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 17 марта 2005 - 13:12

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

Как уже говорил Дмитрий - если система упала - значит responce time плавно перешел в time out:)
как может остаться время отклика прежним, если система упала? :)
Но вообще то я говорил о главной цели нагрузочного тестирования. Конечно, есть еще и другие:)
  • 0

#40 Jackie

Jackie

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

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 17 марта 2005 - 13:17

Слушайте, а ведь Меркури наверное и не догадывается, что ЛоадРаннер -- это инструмент для изменения архитектуры системы :)

Блин, ну почему на этом форуме масса людей, любящих повыпендриваться?
Предполагаю, что от малых знаний и больших амбиций.
Что тут сказать... как говорил герой классической комедии: "А Вы не знаете, так молчите"
:)
  • 0


Программирование на С# для тестировщиков
онлайн
Автоматизатор мобильных приложений
онлайн
Selenium WebDriver: полное руководство
онлайн
Программирование на Python для тестировщиков
онлайн



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

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

Яндекс.Метрика
Реклама на портале