Сообщений в теме: 53

[Pet[EG]]

2 Pet[EG]

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

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

1) Фикс багов и выпуск релизов входит в тестирование? ;)
2) Дело отдела тестирования - предложить дэвам отчет с анализом, а уже вопросы фиксить-нефиксить и им подобные решаются и выполняются не тестировщиками ;)

PS: Jackie, ну я-то ладно, я вашей характеристике отвечаю полностью, а Алексея вы так за что? :D

[barancev]

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

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

Упс! Виноват, дяденька, больше не буду! B)

[aleksey_kh]

,Mar 17 2005, 03:56 PM]

2 Pet[EG]

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

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

1) Фикс багов и выпуск релизов входит в тестирование? ;)
2) Дело отдела тестирования - предложить дэвам отчет с анализом, а уже вопросы фиксить-нефиксить и им подобные решаются и выполняются не тестировщиками ;)

PS: Jackie, ну я-то ладно, я вашей характеристике отвечаю полностью, а Алексея вы так за что? :D

2 Pet[EG]

ну большая корректировка:

Ну наверно тогда уж не дэвам а PM проекта ;) пусть он и решает можно систему выпускать или не льзя с такими-то..... ошибками

[Pet[EG]]

ну большая корректировка:

Ну наверно тогда уж не дэвам а PM  проекта ;) пусть он и решает можно систему выпускать или не льзя с такими-то..... ошибками

Абсолютно согласен :)


PS: Алексей, вы что, я же на работе , мне же нельзя смеятся в полный голос :D , начальство непойметс :D

[Jackie]

Упс! Виноват, дяденька, больше не буду! B)

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

[Jackie]

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

Виноват, исправлюсь:)
Хотел написать клиент-сервер, а вышло веб:)

[PeterL]

,Mar 17 2005, 03:56 PM]2) Дело отдела тестирования - предложить дэвам отчет с анализом, а уже вопросы фиксить-нефиксить и им подобные решаются и выполняются не тестировщиками ;)

Согласен что не тестировщиками, но мы-то говорим о самом процессе тестирования :) А сам процесс, по моему наискромнейшему мнению, ещё как влияет, другое дело: какие люди принимают решения.

[Dmitry_NJ]

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

Сколько лет занимаюсь нагрузочным тестированием, но так и не видел ни одного клиента, которому не надо было в отчете видеть response time. А как же вы собираетесь интерпретировать "самый важный показатель"? Само по себе количество пользователей, которые могут работать с системой, абсолютно неинформативный показатель. По той простой причине, что надо формализовать понятие "работать". И вот это понятие как раз и формализуется, как правило, через response time. Определяют сколько пользователей может выполнять определенные бизнес-процессы в системе за приемлемое время. Кому нужна система, если она таки может позволить работать с ней требуемому количеству пользователей, но время выполнения определенных операций при таком количестве пользователей будет вместо 10 секунд, скажем, 5 минут?

Поэтому и response time и количество пользователей одинаково важны. Одно без другого теряет смысл.

[aleksey_kh]

другое дело: какие люди принимают решения.

Кто занимается процессом тоже не мало важно;) А то есть процес а толку нет :D, т.к. нерюх тестированием занимается ;)


2 PeterL
Петр вы не возражаете если тему закроем дабы избежать дальнейшего флуда ?

[Green]

Да, ребята, далеко вы удалились от сути вопроса.
;)

Я бы вопрос разделил на две части: бизнес составляющую и техническую.

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

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

Бизнес.
Что бы определить РЕАЛЬНУЮ реакцию системы в РЕАЛЬНЫХ условиях необходимо их воссоздать. Для этого создается профиль пользователя. Кто, когда и как работает с системой. Какова расчетная нагрузка на систему во временном срезе (сколько человек и в какое время работает)?

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

Выявляются наиболее вероятные и наиболее "тяжелые" варианты запросов к системе. Определяются критерии "прошел - не прошел".

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

Load: Вычисляется типичное время отклика. В течение небольшого промежутка времени (до 1 часа) запускается 1/2 (можно 2/3) планируемой нагрузки. Если полученный результат не удовлетворяет критерию - ищем узкое место.

Stress: Вычисляется максимальное количество пользователей, способных работать одновременно без заметной деградации системы (увеличение времени отклика). Запускаем до 2-х планируемых нагрузок. Смотрим время отклика на уровне планируемой нагрузки. Количество пользователей, при котором НАЧИНАЕТСЯ значительная деградация системы, характеризует "запас прочности". Если он мал, то необходимо подумать об улучшении системы за счет апгрейда харда или использования более быстрого ПО третьей стороны. В крайнем случае - реинженеринг своей программы с выпуском следующей версии продукта.

Reliability: Вычисляется время появления первых ошибок приложения. Тест запускается в режиме 1/3 планируемой нагрузки на длительный промежуток времени (на сутки, на неделю, на месяц). Длительность теста зависит от режима использования ПО. Деградация времени отклика и/или появление ошибок характеризует наличие проблем в программе.

Scalability: Сравнивается производительность равноценных систем с целью выбора наиболее подходящей. Например, какой веб сервер выбрать для приложения? Тестовое приложение устанавливается на все испытуемые сервера. Создается одинаковая нагрузка на приложение. Время отклика, загрузка ресурсов системы являются критериями выбора наиболее подходящего софта третьей стороны.

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

В качестве главного критерия "прошел - не прошел" используется время отклика. Так же используются показатели загрузки системы. Например, не рекомендуется проводить тестирование и принимать результаты к рассмотрению, если загрузка CPU была больше 80%.

[PeterL]

Так же используются показатели загрузки системы. Например, не рекомендуется проводить тестирование и принимать результаты к рассмотрению, если загрузка CPU была больше 80%.

Большое спасибо :) , только по последнему пункту, насчёт загрузки CPU вы не могли бы прояснить немного. Мне казалось что если загрузка CPU была выше нормы (например 80%), то это и есть как раз повод для investigation'а, типа процессор не справляется с нагрузкой>> очередь растёт>>response time увеличивается.

[Green]

Так же используются показатели загрузки системы. Например, не рекомендуется проводить тестирование и принимать результаты к рассмотрению, если загрузка CPU была больше 80%.

Большое спасибо :) , только по последнему пункту, насчёт загрузки CPU вы не могли бы прояснить немного. Мне казалось что если загрузка CPU была выше нормы (например 80%), то это и есть как раз повод для investigation'а, типа процессор не справляется с нагрузкой>> очередь растёт>>response time увеличивается.

Ограничение по этому показателю устанавливают все производители средств тестирования нагрузкой.
Но мне приходилось тестировать и при 100% загрузке процессора. Нужно было сравнить быстродействие идентичных COM и дотНЕТ компонент. При работе обе загружали процессор полностью.

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

[PeterL]

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

Так в том то и дело, я хочу реал тайм смотреть reponse time, CPU load и Processor Queue Lenght, и как раз будет видны количественные показатели влияния CPU на response time.
В одной полезной книженции советуют для выявленя узких мест связанных с использованием процессора (а вернее влияния дисковой подсистемы на CPU) мерить (кроме выше перечисленного):
Average Disk Queue Length
Average Disk Read Queue Length
Average Disk Write Queue Length
Average Disk sec/Read
Disk Reads/sec
Disk Wirites/sec
и это только для выявления узких мест дисковой подсистемы :huh:, мой вопрос, собстно, с самого начала был: что используется для реального нагрузочного тестирования, понятно что придумать можно много всего, но ведь наверняка есть эталоны метрик (я например пока остановиля на Reponse time, CPU load и Processor Queue Lenght, Memory Usage и Сomparison metrics for current version of the product and for etalon/last version ), которые измерятся всегда, потому что всё мерять что описанно и тем паче анализировать это задача дюже большая... :)

[Jackie]

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

Так в том то и дело, я хочу реал тайм смотреть reponse time, CPU load и Processor Queue Lenght, и как раз будет видны количественные показатели влияния CPU на response time.
В одной полезной книженции советуют для выявленя узких мест связанных с использованием процессора (а вернее влияния дисковой подсистемы на CPU) мерить (кроме выше перечисленного):
Average Disk Queue Length
Average Disk Read Queue Length
Average Disk Write Queue Length
Average Disk sec/Read
Disk Reads/sec
Disk Wirites/sec
и это только для выявления узких мест дисковой подсистемы :huh:, мой вопрос, собстно, с самого начала был: что используется для реального нагрузочного тестирования, понятно что придумать можно много всего, но ведь наверняка есть эталоны метрик (я например пока остановиля на Reponse time, CPU load и Processor Queue Lenght, Memory Usage и Сomparison metrics for current version of the product and for etalon/last version ), которые измерятся всегда, потому что всё мерять что описанно и тем паче анализировать это задача дюже большая... :)

Можно использовать след. вариант:

response time
Running Vusers
CPU utilization
Memory usage
Network delay

В случае возникновения проблем в каком либо параметре надо будет рассматривать данный параметр более углубленно (ставить дополнительные счетчики)