Тест кейсы для нагрузочного тестирования

Доброго времени суток.
Поиск по форуму делал, поиск по гуглу вел на этот форум, но конкретного ответа не нашел.

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

Так, вот, ПМ просит создать тест-кейсы для нагрузочного тестирования. В моем понимании, и в понимании некоторых господ-участников данного форума, тест кейсы - это набор действий, которые должен выполнить пользователь для проведения тестирования. При написании тест кейсов я обычно руководствовался тем, что в них должно быть несколько колонок: User Action, Expected Result, Result, Pass/Fail, Comment
А как быть при нагрузочном тестировании?
То, как будет себя вести приложение при загрузке ничего неизвестно, через какое время будут появлять исходящие сообщения и т.п. нет информации.
Как быть?
Заранее благодарен.

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

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

Спасибо Дмитрий за совет, но тут возникает такая проблема.
Ведь Expected Results подразумевают, что эти данные будут верными.
Может же получится так, что при первом прогоне получились ошибочные результаты. А я поставлю на них что тест Failed.

Может быть есть некие шаблоны тест кейсов при нагрузочном тестировании?? Может кто нибудь слышал?
И будет ли это нормально, если из тест кейсов, которые я приводил выше, выкинуть столбец Expected Results оставить только столбец с получеными данными.
Хм, тогда придется выкинуть и столбец Pass/Fail - будет ли это еще тест кейсом?
Еще раз спасибо.

Тест-кейс по большому счёту простой. Запустить стенд, ждать 8 часов (например), остановить стенд. Наверно лучше писать отдельные подробные тест-план и отчёт, мне так кажется...

Спасибо Дмитрий за совет, но тут возникает такая проблема.
Ведь Expected Results подразумевают, что эти данные будут верными.

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

Обычно описывается сценарий(и) - high level и определяются критерии для оценки результатов. Результаты обычно "ошибочны", если тест выполнялся "нечестно" или "упал". Критерии позволяют оценить "неошибочные" результаты на предмет того, удовлетворяют ли они требованиям. Перфоманс - это нефункциональные требования, поэтому и "ошибочность" - вобщем-то неприменимый термин.

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

2 Dmitry_NJ: Дмитрий, как по мне, то такой подход применим если стоит задача, к примеру, отслеживать динамику изменения производительности (компонента, модуля, не суть) от билда к билду или при введении новой технологической части в проект?

2 Dmitry_NJ: Дмитрий, как по мне, то такой подход применим если стоит задача, к примеру, отслеживать динамику изменения производительности (компонента, модуля, не суть) от билда к билду или при введении новой технологической части в проект?

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

Еще раз спасибо всем тем, кто откликнулся на мой вопрос.

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

Еще раз спасибо, очень полезны Ваши советы.
Попробую разобраться с тем, что мне скажут разработчики, заказчики.