Нагрузочное, стресс тестирование. И краш тестирование?

Недавно был на собеседовании. Попросили объяснить разницу между нагрузочным и стресс тестированием. И тут мы не сошлись в понятиях, так как у меня в голове еще присутствует такой вид, как краш тестирование.
Может я не прав?

Изложу свои мысли в обобщенном виде:
— Нагрузочное — тестирование, когда мы проверяем, что продукт адекватно себя ведет при придельной нагрузке, обусловленной в документации. К примеру, максимальное количество пользователей в один момент времени.
— Стрессовое — тестирование, когда мы проверяем, что продукт ведет себя адекватно за гранью предельной нагрузки И при предельной нагрузке в условиях сбоя определенных частей. К примеру, (количество пользователей больше максимума выглядит довольно тривиально для примера) устойчивость сессии в условиях нестабильной работы портов, систематическая потеря частей данных при передаче и все это в условиях максимального количества пользователей в один момент времени.
— Краш — тестирование, целью которого является вызвать краш системы. То есть мы будем увеличивать нагрузку бесконечно до тех пор, пока система не ляжет.

Да, при каждом виде, описанном выше, система может крашнуться. Но сделать это специально является задачей именно краш тестирования.

Интересны альтернативные мнения

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
— Краш — тестирование, целью которого является вызвать краш системы.
Цель — проверить, может ли система восстановить работу после сбоя.

Вас поймали на типичную уловку собеседующих. Вы не прошли собеседование, у них вообще этот тип тестирования практикуется, в частности на ту позицию на которую собеседовались. Вот слайдик из Soft Serve IT Academy, надеюсь ничего секретного не выдал screencast.com/t/2HirzLZrhjV

Скинь пож-та презенташку svlugovoy@gmail.com — интересно полистать, спасибо!)

да, собственно, собеседование прошел)

Скинь плиз мне презентацию хочу почитать. evgen_man@inbox.ru

Есть еще эта презентация? можете скинуть пожалуйста, интересно тоже почитать))) shubina.daria@gmail.com

Стрессовое — тестирование, когда мы проверяем, что продукт ведет себя адекватно за гранью предельной нагрузки
а чому він має себе вести адекватно ?
Краш — тестирование, целью которого является вызвать краш системы
креш можна викликати не тільки навантаженням.і взагалі, чого воно має крешити ?

Якось воно не логічно

Ні в ISTQB, ні в інших джералах я такого терміна не чув.
Де ви отримали таку інфу ?

Я не претендую на експертність в данному питанні. Але в той же час не прихильник інцеклопедійних знань. Оскільки в джерелах записані знання, які вже колись були застосовані, але це не виключає наявність інших знань.

Визначення, які я давав дуже спрощенні і приблизні. Продукт має вести себе адекватно при стресовому тестуванні тому, що я очікую, що робота продукта буде стабільною і/або він зможе самовідновитися. Якщо мої очікування не виправдалися, значить я виявив баг.
Проте, при крешовому тестуванні, я очікую, що продукт крешнеться, щоб виявити слабкі місця.

ISTQB — це не енцеклопедія. Це організація, яка пропонує свій підхід до класифікації і структуризації знань. Так, як вона відома і операється на інші джерела, тому ми на неї посилаємось і вважаємо її одним з найавторитетніших баз знань

Тестування це не лише перевірка, а оцінка і аналіз. При стресовому тестуванні ми оцінюємо поведінку системи в умовах які не відповідають вимогам. Ви оцінюєте і аналізуєте його поведінку. І найбільш очікувана поведінка — система впаде, хоча це не обов’язково. Якщо система впаде це не обов’язково баг.

Те, що ви називаєте креш тестування не існує, в контексті тестування продуктивності, це стрес тому, що найбільш очікувана поведінка системи — вона впаде.

Можливо, ви під креш тестуванням ви плутаєте негативне тестування ?

Дякую, змістовна відповідь.
Так, якщо я намагаюсь досягнути креша, то

найбільш очікувана поведінка — система впаде
Але, коли я проводжу стресове тестування, то я очікую, що система витримає. Падіння системи в такому випадку, для мене небажана поведінка.

Згоден, креш тестування — це негативне тестування. Але негативне — це не тільки креш.

Я теж проймаюся глибокою повагою до ISTQB, але дух бунтарства з мене ще не вивітрився)
Ще не дуже зрозуміло, кого ви маєте на увазі пишучи «ми»

ми на неї посилаємось і вважаємо її одним з найавторитетніших баз знань
я проводжу стресове тестування, то я очікую, що система витримає
Не так важливо що ви особисто очікуєте від продукту, як власне рекваєрменти і специфікація, система може падати і на конкретному проекті — це буде очікуваний результат, який ніхто не буде фіксити.
Падіння системи в такому випадку, для мене небажана поведінка.
Знову ж таки, не слід сприймати це особисто :) Якби продукт овнер говорив що для нього це небажана поведінка — тоді зовсім інша справа :)
Тому я тут погодився б з вашими співбесідниками, без образ.
очікую, що система витримає
а чому вона має витримати ?
якраз нічого не очікуєте, бо ця поведінка не є описаною в будь якій документації.
дух бунтарства з мене ще не вивітрився
є стандартна термінологія, якої дотримуються всі. Це ж точна наука
ми
Я говорю про людей які працюють в сфері QA
Я говорю про людей які працюють в сфері QA
здається ви пишете ЗА людей, які працюють в сфері QA

давайте до конструктивного діалогу без давління авторитетом. без образ))

особисто мені подобається вислів: «документація придумана для тих, хто неспроможний самостійно приймати рішення»
Звісно це жарт, але в ньому доля глузду, інакше б QA не займалися тестуванням технічної документації і не вводили туди поправки

Знову спробую донести свою думку, що задокументований прецендент не виключає наявність незадокументованого прецендента.

Що тоді креш тестування ? Поясність, будь ласка

Проведення певних маніпуляцій над тестуємим продуктом з метою викликати його збій.

Це моє особисте бачення цього питання. І я не претендую в данному випадку на авторитетність

от із визначення Soft Serve IT Academy, яке в коментарі вище, моє бачення підпадає під стресове тестування. А в визначеннях stress testing SWEBOK, stress testing IEEE 610, з коментаря нижче, взагалі не вказано про падіння продукту

negative testing: Tests aimed at showing that a component or system does not work. Negative testing is related to the testers’ attitude rather than a specific test approach or test design technique, e.g. testing with invalid input values or exceptions. [After Beizer]. ISTQB glossary

Чим тоді ваш креш тест відрізняється від негативного тестування ?

Так, це негативне тестування. Але чи негативне тестування — це креш тестування?
Хоча, стосовно визначення вами преведеного, ви маєте рацію.
Дякую)

Когда-то задавался похожим вопросом. В первоисточниках термина креш-тестирование в контексте тестирования производительности не встречал, поэтому ваша интерпретация мне кажется правильной. В качестве первоисточников использовал:
— IEEE 610 Standard Glossary of Software Engineering Terminology
— SWEBOK

stress testing SWEBOK
Stress testing exercises software at the maximum design load, as well as beyond it.

stress testing IEEE 610
stress testing. Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements.

В ISTQB в контексте тестирования производительности вводятся также понятия:
— Объемное тестирование volume testing
— Нагрузочное тестирование load testing
— Тестирование мощности capacity testing

Еще встречал soak testing и spike testing, правда не знаю кто ввел эти термины. Но креша не встречал, значит вы скорее всего правы

Подписаться на комментарии