Какво е деструктивно тестване в софтуера?

по: Томас Хамилтън Томас Хамилтън
Hours Обновено

⚡ Умно обобщение

Деструктивното тестване умишлено налага на софтуерното приложение да се повреди, разкривайки точните точки, където устойчивостта се разпада при неправилна употреба, невалиден вход и непредсказуемо поведение, до които обикновените функционални проверки никога не достигат.

  • 💥 Основна идея: Приложението е направено така, че да се проваля умишлено, така че точките му на неуспех да станат видими и измерими.
  • ???? Не са необходими изисквания: Предварителното познаване на спецификацията е незадължително, въпреки че изостря стратегията за тестване.
  • ️ Противоположната двойка: Неразрушителният контрол върви по щастливия път; разрушителният контрол го атакува от всеки грешен ъгъл.
  • 🧰 подходи: Анализ на точките на отказ, експертна оценка от тестери, бизнес преглед и проучвателни изпълнения с протоколи от изпълнения.
  • 🧪 Повторно използвани методи: Регресията, интерфейсът, разделянето на еквивалентност, цикличното и приемателното тестване – всички те служат на разрушителни цели.
  • 📉 Честни ограничения: Трудно е да се гарантира покритие, усилията са високи и резултатите могат да бъдат трудни за възпроизвеждане.
Прочетете повече

Какво е разрушително тестване в софтуера с методи и техники

Какво е разрушителен тест?

Разрушително изпитване е метод за тестване на софтуер, използван за намиране на точки на отказ в софтуерна програма. При тази техника приложението е умишлено накарано да се провали, за да може да се провери неговата устойчивост и да се идентифицират точките на отказ. За разлика от методите за тестване, които проверяват какво трябва да прави приложението, разрушителното тестване изследва непредсказуемото поведение на потребителя в приложението.

Познаването на оригиналните изисквания не е необходимо за разрушителния контрол. Някои знания обаче помагат при разработванетоping добра стратегия за тестване.

Илюстрацията по-долу улавя идеята – тестерът работи срещу продукта, а не заедно с него.

Концепция за разрушително тестване: приложение, умишлено доведено до точката на отказ

Защо се извършва разрушителен контрол?

  • Помага да се разбере предвидимото поведение на софтуера, когато той се използва неправилно.
  • Помага да се провери устойчивостта на софтуерен продукт.
  • Той разкрива редки дефекти, които обикновените потребители никога не задействат, но се появяват по-късно в производството.

Разрушителен контрол срещу неразрушителен контрол

Двата подхода се допълват, а не си противоречат. Неразрушително изпитване — наричано още положително или „щастлив път“ тестване — взаимодейства правилно със софтуера и оставя компилацията непокътната. Деструктивното тестване прави обратното: то подава невалидни данни и грешни последователности, докато нещо не се повреди.

Аспект Разрушително изпитване Неразрушително изпитване
Намерение Принудително прекратяване на приложението Потвърдете, че приложението работи както е посочено
Използван вход Невалидно, неправилно формирано, извън обхват, извън последователност Валидни данни в очаквания диапазон
Отговор на въпроса Къде и как се чупи? Прави ли това, което трябва?
Познания за изискванията По избор Съществен
Типична цена Висше — изследователско и с отворен край Долна част — написана по сценарий и повтаряема
Резултат Точки на отказ, граници на обхвата, поведение при възстановяване Отговаря или не отговаря на спецификацията

Какво проверявате при разрушителния контрол?

Деструктивното тестване разглежда и двете страни на границата на поведението:

  • Правилно поведение на софтуера
  • Неправилно поведение на софтуера
  • Неправилна употреба
  • Неправилни входни данни
  • Правилни изходни данни

Две условия трябва да са изпълнени през цялото упражнение:

  • Софтуерът никога няма да обработва или приема невалидни входни данни.
  • Независимо от валидността или коректността на входните данни, софтуерът винаги трябва да генерира правилни изходни данни.

СВЪРЗАНИ СТАТИИ

Как се прави разрушителен тест?

Деструктивното тестване включва много дейности, като например проектиране на набор от тестови скриптове, изпълнение на тези скриптове, отчитане на грешки, затваряне на грешки и предоставяне на показатели за преминаване или неуспех на заинтересованите страни в края на итерацията.

Има много начини да го изпълните. Следват някои примери.

  • Метод за анализ на точката на отказ: преглед на системата, който оценява какво може да се обърка в различни моменти. Помощ от бизнес анализатор може да се използва за тази стратегия.
  • Рецензия от тестващи: вземи си тестови случаи анализирани или прегледани от друг тестер, който е по-малко запознат със системата или функцията.
  • Бизнес преглед на тестовите случаи: Крайните потребители или експертите често се сещат за валидни сценарии, които тестерите пропускат, защото фокусът на тестера е върху посочените изисквания.
  • Проведете проучвателно тестване, използвайки работни листове: проучвателно тестване С протоколи от тестове се записва какво е тествано, позволява се тестовете да бъдат повтаряни и се контролира обхватът на тестовете.
  • Използвайте друг източник: помолете някой друг да разбие софтуерния продукт и да анализира сценариите, които открие.

Пример за разрушителен контрол

Помислете за екраните за вход и профил на банково приложение. Деструктивният пропуск би проработил в случаи като тези:

  • Поставете низ от 5,000 знака в поле, ограничено до 50 знака, и потвърдете, че полето го отхвърля, вместо да го отрязва безшумно.
  • Въведете букви, символи и отрицателни стойности в поле за числова сума.
  • Нарушете очакваната последователност — отворете страницата за потвърждение на плащането директно, без да завършите предходната стъпка.
  • Натискайте „Изпрати“ многократно и бързо последователно, за да видите дали са създадени дублиращи се записи.
  • Прекъснете мрежовата връзка по време на транзакцията и проверете дали приложението се възстановява безпроблемно или оставя частичен запис.

Всеки случай има определено очакване: ясно съобщение за валидиране, липса на повреда на данните и липса на необработени изключения. Всичко друго е точка на неуспех, която си струва да се посочи като дефект.

Разрушителни методи за изпитване

Следните методи се използват в софтуерното инженерство за постигане на целите на разрушителното тестване:

Техники за разрушително изпитване

Следните техники могат да се използват с модификации:

Съседни техники, които си струва да се добавят, когато целта е устойчивост, са отрицателен тест, стрес тестове, тестване за възстановяване намлява тестване на размиване.

Предимства и недостатъци на разрушителния контрол

Струва си да се посочи ясно компромисът, преди техниката да бъде планирана за пускане на пазара.

Предимства

  • Revоткрива точки на отказ, до които тестването, основано на спецификации, никога не достига.
  • Определя реални граници на обхвата, така че продуктът може да се използва уверено в тях.
  • Разкрива редки дефекти, които се появяват в производството дълго след пускането му на пазара.
  • Проверява издръжливостта, възстановимостта и обработката на грешки при злоупотреба.

Недостатъци

  • Отворен по природа, така че покритието не може да бъде гарантирано или измерено лесно.
  • Отнема време и зависи от опита и креативността на тестващия.
  • Резултатите могат да бъдат трудни за възпроизвеждане без внимателно регистриране на използваните стъпки.
  • Лошо контролираните изпълнения могат да повредят споделените тестови данни, така че е необходима изолирана среда.

Въпроси и Отговори

Те се припокриват, но се различават по обхват. Отрицателен тест проверява дефинираните невалидни входни данни спрямо очакваната обработка на грешки. Деструктивното тестване е по-широкообхватно и отворено, като търси всяко условие, което води до неуспех на приложението.

Обикновено опитни QA инженери, подкрепяни от колеги, които не са запознати с модула, и от бизнес потребители. Външният поглед е важен, защото хората, които са създали функцията, са склонни да я тестват по начина, по който е била проектирана.

След като функционалният пакет е стабилен, неуспехите сочат към надеждност, а не към недовършени функции. Много екипи го планират по време на системно тестване и го повтарят преди основните издания в жизнен цикъл на тестване.

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

Копилот на GitHub бързо изготвя генератори на входни данни, гранични случаи и процедури за демонтаж. Тестерът все пак решава кои режими на отказ са важни и дали наблюдаваното поведение се счита за приемлив резултат.

Точният използван вход или последователност, наблюдаваният неуспех, лог файловете и екранните снимки, средата и тежестта на въздействието. Метриките за преминаване или неуспех за итерацията се предоставят на заинтересованите страни заедно с записи за дефекти.

Никога не трябва да се докосва до производствена среда. Стартирайте го в изолирана среда с възстановими данни, защото умишлено невалидните входни данни и принудителните сривове могат да доведат до частични записи, чието почистване е скъпо.

Водете си протокол по време на сесията, записвайки всяко действие и въвеждане по ред. Възпроизведете протокола от чисто състояние, след което го намалете до най-кратката последователност, която все още задейства неуспеха.

Обобщете тази публикация с: