Пълно ръководство за нефункционално тестване за начинаещи

complete non functional testing guide

Пълно ръководство за нефункционално тестване: неговата цел, типове, инструмент, тестови случаи с примери

Какво е нефункционално тестване?

Нефункционалното тестване се извършва, за да се провери нефункционалното изискване на приложението като производителност, използваемост и др.

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

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

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

Тестването се класифицира най-общо в два вида:

• Функционално тестване
• Нефункционално тестване

Какво ще научите:

• Значение
• Предназначение
• Пример
• Предимства
• Как да уловим нефункционални изисквания?
  • # 1) Потребителски / технически истории
  • # 2) Критерии за приемане
  • # 3) В Артефакти
• Разлика във функционалните и нефункционалните изисквания
• Това тестване на черна кутия или бяла кутия ли е?
• Контролен списък за нефункционални тестови случаи
  • Контролен списък за тестване на производителността
  • Контролен списък за тестване на сигурността
  • Контролен списък за тестване на документация
• Документ за подход
  • Обхват на теста
  • Тестови показатели
  • Инструменти за тестване
  • Основни дати и резултати
• Нефункционални видове изпитване
• Нефункционални инструменти за тестване
  • # 1) Тестови случаи за тестване на използваемост
  • # 2) Тестови случаи за тестване на производителността
  • # 3) Тестови случаи за тестване на сигурността
• Заключение
• Препоръчително четене

Значение

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

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

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

Както самото име показва, това тестване се концентрира върху нефункционалния аспект на приложението. И така, какви са нефункционалните аспекти? Или трябва да кажа какви са функциите, които не са свързани с функционалността на приложението?

Е, тук са отговорите на тези:

• Как работи приложението при нормални обстоятелства?
• Как се държи приложението, когато твърде много потребители влизат едновременно?
• Може ли приложението да се справи със стреса?
• Колко сигурно е приложението?
• Може ли приложението да се възстанови от някакво бедствие?
• Може ли приложението да се държи по същия начин в различна среда или операционна система?
• Колко лесно е да пренесете приложението в различна система?
• Лесно ли се разбират документите / ръководството за потребителя, предоставени с приложението?

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

Представете си, че дадено приложение отговаря на всички потребителски изисквания перфектно, но някои неоторизирани потребители лесно преминават и пробиват данните, въведени от потребителя в приложението, или приложението умира, когато са качени повече от 5BB от който и да е файл. Така че бихте ли казали, че приложението е с добро качество? Очевидно не е наред !!

Предназначение

Единствената цел на този тип тестване е да гарантира, че нефункционалните аспекти на приложението се тестват и приложението работи добре в контекста на същото.

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

Пример

Това е важен тип тестване.

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

За да разберем важността му, нека вземем един прост пример:

Приложението е разработено и е напълно тествано за функционалност, но нефункционалното тестване не се извършва на същото.

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

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

Предимства

Дадени по-долу някои от предимствата на нефункционален тест:

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

Как да уловим нефункционални изисквания?

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

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

Нефункционалните изисквания също улавят поведението, когато голям брой хора използват софтуера едновременно. През повечето време се изпитва, че сървърите са заети или недостъпни поради голямо натоварване (т.е. повече хора го използват едновременно). Резервирането на онлайн железопътни билети може да бъде най-доброто пример на такава ситуация.

Следователно документирането на нефункционалното изискване правилно и извършването на тестването правилно ще осигури високо удовлетворение от гледна точка на използваемостта от потенциалните клиенти.

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

Пример:

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

Също така, може да бъде тествано, когато (да кажем 100) потребителите влизат едновременно, колко време отнема за влизане на потребителя във Facebook.

Това гарантира, че системата може да се справи с натоварването и трафика, което от своя страна има добро потребителско изживяване.

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

Нефункционално изискване трябва да бъде отразено като:

• Потребителски / Технически истории
• В критерии за приемане
• В Артефакт

9

# 1) Потребителски / технически истории

Нефункционално изискване може да бъде уловено с помощта потребителски истории или технически истории. Заснемането на нефункционални изисквания като потребителска история е същото като при улавяне на всяко друго изискване. Единствената разлика в потребителя и техническата история е, че историята на потребителя изисква дискусия и има видимост.

# 2) Критерии за приемане

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

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

# 3) В Артефакти

За нефункционалните изисквания трябва да се подготви отделен артефакт, което от своя страна би спомогнало за по-добра представа за това какво трябва да се тества и как може да се направи в итерации.

Разлика във функционалните и нефункционалните изисквания

Има няколко разлики между функционалните и нефункционалните изисквания и малко от тях са посочени по-долу:

Допълнително четене => Разлики между функционално и нефункционално тестване

Това тестване на черна кутия или бяла кутия ли е?

Нефункционалният тест е под a тестване на черна кутия техника.

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

Контролен списък за нефункционални тестови случаи

Използва се контролен списък, за да се гарантира, че нито един важен аспект не остава без тестване.

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

Нека да видимпримерна контролния списък за тестване на производителност, сигурност и документация.

Контролен списък за тестване на производителността

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

Контролен списък за тестване на сигурността

• Удостоверяване: Само автентичен потребител трябва да може да влезе.
• Упълномощен: Потребителят трябва да може да влиза в онези модули, само за които е упълномощен или за които на потребителя е предоставен достъп.
• Парола: Изискването за парола трябва да бъде проверено, т.е.паролата трябва да бъде според начина, по който изискването определя, т.е. дължина, специални знаци, цифри и т.н.
• Време за изчакване: Ако приложението е неактивно, тогава трябва да изтече изчакване за определено време.
• Архивиране на данни: Архивирането на данни трябва да се извършва в определено време и да се копира на защитено място.
• Вътрешни връзки до уеб приложението не трябва да е достъпно, ако е поставено директно в браузъра.
• Цялата комуникация трябва да бъде шифрована.

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

• Потребителска и системна документация.
• Документи с цел обучение.

Документ за подход

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

най-добрият безплатен видео изтегляне Windows 10

• Обхват на теста
• Тестови показатели
• Инструменти за тестване
• Основни дати и резултати

Обхват на теста

Провеждайте тестване на производителността от различни гледни точки, като производителност на потребителя, бизнес процеси, стабилност на системата, консумация на ресурси и т.н. Видовете тестове за ефективност, които трябва да се изпълнят, са обсъдени в горния раздел на статията (като тест за натоварване, стрес тест и т.н.)

Тестови показатели

Тестовият подход усъвършенства показателите за измерване и докладване по време на тестване, като например:

• Време за реакция (онлайн)
• Партиден прозорец (партида)
• Пропускателна способност ( Например , броят на транзакциите за единица време)
• Използване ( Например , процентът на използваните ресурси)

Инструменти за тестване

Предимно тестване на производителността изисква използването на подходящи инструменти:

• Инструменти за генериране на натоварване
• Инструменти за мониторинг на ефективността
• Инструменти за анализ на ефективността
• Инструменти за профилиране на приложения
• Инструменти за облицоване на основи.

Основни дати и резултати

Документът за подхода за изпитване за изпълнение трябва да описва следното:

• Дата и час на всяко провеждане на теста за изпълнение.
• Видове тестове и функционални комбинации, които трябва да бъдат включени във всяко провеждане на теста за ефективност.
• Дати за изпълнение на теста за изпълнение.

Нефункционални видове изпитване

Следващото изображение изобразява видовете нефункционално тестване:

Тестване на производителността:

Оценява цялостната производителност на системата .

Основните елементи са както следва:

• Проверява дали системата отговаря на очакваното време за реакция.
• Оценява, че значимите елементи на приложението отговарят на желаното време за реакция.
• Може да се проведе и като част от интеграционно тестване и тестване на системата.

Тестване на натоварване:

Оценява дали производителността на системата е очакваната при нормални и очаквани условия.

Основни моменти са:

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

Стрес тестване:

Оценява дали производителността на системата е очакваната, когато има малко ресурси.

Основни моменти са:

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

Време за мислене: Точно като интервала от време между въвеждането на вашия потребител и парола.

Тестване на обема:

Оценява поведението на софтуера, когато е включен голям обем данни.

Основни моменти са:

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

Тестване на използваемостта:

Оценява системата за човешка употреба или проверява дали е годна за употреба.

Основни моменти са:

• Изходът правилен и смислен ли е и същият ли е като този, който се очаква според бизнеса?
• Правилно ли са диагностицирани грешките?
• Правилен ли е GUI и съответства ли на стандарта?
• Лесно ли е приложението?

Тестване на потребителския интерфейс:

Оценява GUI.

Основни моменти са:

• GUI трябва да предоставя помощ и подсказки, за да го направи лесен за използване.
• Съобразен с външния си вид?
• Данните се прехвърлят правилно от една страница на друга?
• GUI не трябва да дразни потребителя или да става трудно за разбиране.

Тестване на съвместимост:

Оценява, че приложението е съвместимо с друг хардуер / софтуер с минимална и максимална конфигурация.

Основни моменти са:

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

Тестване за възстановяване:

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

Тестовете не са ограничени до следните точки:

• Прекъсване на захранването на клиента при извършване на CURD дейности.
• Невалидни указатели и ключове за база данни.
• Процесът на базата данни е прекратен или преждевременно прекратен.
• Указателите, полетата и ключовете на базата данни са повредени ръчно и директно в базата данни.
• Прекъснете физически комуникацията, изключете захранването, изключете рутерите и мрежовите сървъри.

Тестване на нестабилност:

Оценява и потвърждава дали софтуерът се инсталира и деинсталира правилно.

как да използвам регулярния израз в c ++

Основни моменти са:

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

Тестване на документация:

Оценява документите и други ръководства за потребителя.

Основните моменти включват:

• Потвърждава, че посочените документи са налични в продукта.
• Утвърждава всички ръководства за потребителя, настройва инструкции, чете ми файлове, бележки за изданието и онлайн помощ.

Тестване при отказоустойчивост:

Извършва се тестване на отказоустойчивост, за да се провери дали в случай на отказ на системата системата е достатъчно способна да обработва допълнителни ресурси като сървъри.

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

Тестване на сигурността:

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

Той включва тестване на удостоверяване, упълномощаване, целостта и наличността.

Тестване на скалируемост:

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

Тестване за съответствие:

Изпитването за съответствие се прави, за да се провери дали се спазват определените стандарти. Правят се одити, за да се провери същото.

За Пример , Одитите се извършват, за да се провери процесът на създаване на тестови случаи / планове за тестване и поставянето им на споделеното място със стандартното име, което се прави или не. В QC, докато се именуват тестовите случаи, стандартното име на тестовия случай се следва или не. Документацията е пълна и одобрена или не.

Това са малкото насоки, които са обхванати по време на одита.

Тестване на издръжливост:

Тестване на издръжливост се прави, за да се провери поведението на системата, когато натоварването се увеличи до известна степен за дълго време.

Нарича се още Soak testing & Capacity testing. Помага да се провери дали има изтичане на памет в системата. Изпитването за издръжливост е подгрупа на тестовете за натоварване.

Тестване на локализация:

Тестване на локализация се прави, за да се провери приложението на различни езици, т.е.различни локали. Заявлението трябва да бъде проверено за определена култура или локал. Основният фокус е да тествате съдържанието, GUI на приложението.

Тестване за интернационализация:

Тестване за интернационализация е известно още като i18n тестване.

I18n представлява I - осемнадесет букви - N. Направено е, за да се провери дали приложението работи, както се очаква, във всички езикови настройки. Той проверява дали някоя функционалност или самото приложение не се нарушава, т.е.приложението трябва да бъде достатъчно способно да се справи с всички международни настройки.

Той също така проверява дали приложението се инсталира без никакви проблеми.

Тестване на надеждността:

Извършва се тестване за надеждност, за да се провери дали приложението е надеждно и се тества за определен период от време в определената среда. Приложението трябва да дава същия резултат, както се очаква всеки път, само тогава може да се счита за надежден.

Тестване на преносимост:

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

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

Изходно тестване:

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

Например: При първата итерация времето за реакция на приложението беше 3 секунди. Сега това е зададено като еталон за следващата итерация и при следващата итерация времето за реакция се променя на 2 секунди. По същество това е документ за валидиране, който се използва като основа за бъдещи препратки.

Тестване на ефективността:

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

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

Тестване за възстановяване при бедствия:

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

Тестване на поддръжката:

След като приложението / Продуктът стартира, тогава има шанс да възникне проблем в живата среда или клиентът може да поиска подобрение за приложението, което вече е на живо.

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

Нефункционални инструменти за тестване

На пазара има няколко инструмента за тестване на производителността (Load & Stress).

Малко от тях са изброени по-долу:

• JMeter
• Лоудстър
• Loadrunner
• Товарна буря
• Neoload
• Прогноза
• Зареждането завършено
• Инструмент за стрес на уеб сървър
• WebLoad Professional
• Loadtracer
• vPerformer

Винаги ли се провежда нефункционално тестване без документи и тестови случаи? Защо?

„Винаги ни учат как да пишем функционални тестови случаи. Защо така? Извършва ли се „нефункционално тестване“ без документация (с други думи, ad hoc) или това е отделен процес, който е много по-труден за разбиране? Как се пишат тестови случаи за различни видове тестове, които се случват в дадено приложение? '

Това е един от най-оригиналните, отличителни и нестандартни въпроси, които са ми задавани в последно време. Нека намерим отговора.

Как така никога да не виждаме и практикуваме писането на нефункционални тестови случаи?

Нека започнем с това, което знаем и както винаги с практичен сценарий.

Пример: Следват стъпките, които трябва да се извършат в приложение за онлайн банкиране, за да се извърши превод. Нека използваме това като наш тест за справка.

1. Влезте в сайта.
2. Изберете банковата сметка.
3. Изберете получателя (този получател може да принадлежи към същата банка или към друга - това зависи от избора ви на данни за изпълнение на тази стъпка. Във всеки случай изберете такава. Също така ще приемем, че получателят вече е добавен.) .
4. Въведете сумата за превод (положителна стойност, в рамките на лимита, правилен формат и т.н.).
5. Щракнете върху Прехвърляне и проверете дали е получено потвърждение, салдото по сметката е актуализирано и всичко това.

Това е функционалният тестов случай, нали?

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

Как бихме написали тестовите случаи?

# 1) Тестови случаи за тестване на използваемост

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

• Колко лесно е приложението да се използва?
• Колко удовлетворяващ е опитът от използването на системата?
• Ако не толкова познато веднага, колко лесно е да се научиш?

Повече информация за него е тук: Ръководство за тестване на използваемостта

Как потребителят ще определи отговорите на горните въпроси в контекста на тестването на използваемост?

Потребителят ще извърши точно същите стъпки, както във функционалния тестов случай. Прав ли съм?

# 2) Тестови случаи за тестване на производителността

Има няколко варианта на тестване на производителността, но в основата си той се използва за получаване на статистически данни за системата, използването на ресурсите, времето за реакция, консумацията на мрежата и т.н. при различни точки на натоварване.

Вижте нашите Уроци за тестване на производителността за да научите повече за него.

Сега, ако трябваше да тествам ефективността на транзакцията на трансферите, щях да имам 10, 20, 30, 100 ... 1000 ... и т.н., потребителите да извършват операцията за прехвърляне едновременно или постепенно, в зависимост от това към какво искам да насочвам и да събирам данни.

Какви стъпки би извършил всеки потребител, за да използва трансфера, докато е в ход тестът за ефективност?

Същите точни стъпки като функционалния тест, нали?

# 3) Тестови случаи за тестване на сигурността

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

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

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

Предполагам, имаме достатъчно, за да установим, че стъпките във всички ситуации са еднакви. Методът и намерението зад процеса са различните.

Нека да разгледаме сравнително:

Интересното е да се отбележи, че без значение каква форма на тестване искаме да направим, всички стъпки са еднакви .

Истинската разлика е, че:

1. Кой изпълнява тези стъпки?
2. Какво е намерението или с други думи какво се опитвам да постигна чрез този тест?
3. Използваните инструменти и техники.

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

Това е защото ,в основата си тестовите стъпки за вариация на типовете тестове за определена функция са еднакви, функционални или не. Намерението е това, което прави разликата и може би методът.

Заключение

Преди извършване на нефункционално тестване е от съществено значение да планирате правилно стратегията за тестване, за да осигурите правилното тестване. На пазара се предлагат различни инструменти за извършване на този тип тестове като Load Runner, RPT и т.н.

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

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

Надяваме се, че този процес на задълбочаване в тази тема е бил толкова забавен за вас, колкото е бил представен на всички вас. Ще се радваме да чуем вашите отзиви и мисли по този въпрос.

Как се справяте с нефункционалното тестване във вашите екипи? И както винаги, уведомете ни, ако сте съгласни или не, или имате нещо да добавите към това, което се случва тук.

Препоръчително четене

• Функционално тестване срещу нефункционално тестване
• Алфа тестване и бета тестване (Пълно ръководство)
• Ръководство за тестване на сигурността на уеб приложения
• Пълно ръководство за функционално тестване с неговите типове и пример
• Пълно ръководство за тестване за проверка на компилация (BVT тестване)
• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Ръководство за начинаещи за тестване на проникване в уеб приложения
• Пълно ръководство за тестване на зареждане за начинаещи