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

complete non functional testing guide

Комплетан водич за нефункционално тестирање: његова сврха, типови, алат, примери случајева

Шта је нефункционално тестирање?

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

Проверава да ли је понашање система према захтеву или не. Обухвата све аспекте који нису обухваћени функционално испитивање . У нашем свакодневном тестирању, велика пажња се посвећује функционалном тестирању и функционалним захтевима.

Клијенти су такође заинтересовани за испуњавање функционалних захтева који су директно повезани са функционалношћу апликације. Али у стварној фази, тј. Када сте функционално тестирани, софтвер долази на тржиште и користе га стварни крајњи корисници, а постоје шансе да се суочи са неким проблемима у вези са перформансама.

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

Тестирање је широко класификовано у две врсте:

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

Шта ћете научити:

• Значај
• Сврха
• Пример
• Предности
• Како ухватити нефункционалне захтеве?
  • # 1) Корисничке / техничке приче
  • # 2) Критеријуми за прихватање
  • # 3) У Артефактима
• Разлика у функционалним и нефункционалним захтевима
• Да ли је ово тестирање црне кутије или беле кутије?
• Контролна листа нефункционалних случајева
  • Контролна листа за испитивање перформанси
  • Контролна листа за безбедносно тестирање
  • Контролна листа за тестирање документације
• Приступни документ
  • Опсег испитивања
  • Тест Метрицс
  • Алати за тестирање
  • Кључни датуми и резултати
• Нефункционални типови испитивања
• Нефункционални алати за тестирање
  • # 1) Тест случајеви тестирања употребљивости
  • # 2) Тест случајеви тестирања перформанси
  • # 3) Тест случајеви тестирања сигурности
• Закључак
• Препоручено читање

Значај

Овом тестирању је недостајало дужне пажње с обзиром да то не утиче на функционалност система.

Нефункционалним захтевима такође није посвећена одговарајућа пажња у ранијим циклусима испитивања. Међутим, ово се сада променило. Нефункционални тестови су сада најважнији јер узимају у обзир све проблеме перформанси и безбедности ових дана.

Ово тестирање има већи утицај на апликације када су у питању перформансе апликације под великим корисничким прометом. Ово тестирање осигурава да је ваша апликација стабилна и способна да поднесе оптерећење под екстремним условима.

Као што само име говори, ово тестирање се концентрише на нефункционални аспект апликације. Па, који су нефункционални аспекти? Или да кажем које су функције које нису повезане са функционалношћу апликације?

Па, ево одговора на њих:

• Како апликација ради у нормалним околностима?
• Како се апликација понаша када се истовремено пријављује превише корисника?
• Да ли апликација може да се носи са стресом?
• Колико је сигурна апликација?
• Да ли се апликација може опоравити од било које катастрофе?
• Да ли се апликација може понашати на исти начин у другом окружењу или ОС-у?
• Колико је лако пренети апликацију у други систем?
• Да ли су документи / корисничка упутства која се испоручују уз апликацију лако разумљиви?

Листа се наставља. Али поента је овде у томе - нису ли ове карактеристике допринеле квалитету апликације? Одговор је ДА. Ове особине су подједнако важне.

Замислите да апликација савршено испуњава све корисничке захтеве, али неки неовлашћени корисник лако крене и провали податке које је корисник унео у апликацију или апликација умре када се учита више од 5ББ било које датотеке. Па да ли бисте рекли да је апликација квалитетна? Очигледно није у реду !!

Сврха

Једина сврха ове врсте тестирања је осигурати да се нефункционални аспекти апликације тестирају и да апликација добро функционише у контексту исте.

Сврха је да обухвати тестирање свих карактеристика апликације које помажу у пружању апликације која испуњава пословна очекивања.

Пример

Ово је важан тип испитивања.

Функционално тестирање тестира функционалност апликације и осигурава да ради како се очекује, али нефункционално тестирање осигурава да апликација ради довољно добро да испуни пословна очекивања.

Да бисмо разумели његову важност, узмимо једноставан Пример:

Апликација је развијена и у потпуности је тестирана на функционалност, али се на њој не врши нефункционално тестирање.

У међувремену, када апликација почне да ради, то може резултирати критичним или великим проблемима, на пример, када се оптерећење апликације повећа, постаје преспоро и треба јој пуно времена да се отвори.

Време одзива може се повећати или када се оптерећење повећа у одређеној мери, апликација се може срушити. Ово показује колико је важно тестирати нефункционалне аспекте апликације.

Предности

У наставку су дате неке од предности нефункционалног теста:

• Обухвата испитивање које не може бити обухваћено функционалним испитивањем.
• Осигурава да апликација ради ефикасно и да је довољно поуздана.
• Обезбеђује сигурност апликације.

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

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

Нефункционални захтеви се користе за обављање нефункционалних испитивања. Ови захтеви укључују излазне перформансе које се очекују од апликације или софтвера који се тестира. То у основи укључује време потребно софтверу за рад са одређеним системом.

Нефункционални захтеви такође бележе понашање када велики број људи истовремено користи софтвер. Већину времена се доживљава да су сервери заузети или недоступни због великог оптерећења (тј. Више људи га истовремено користи). Резервација железничких карата на мрежи може бити најбоља пример такве ситуације.

Стога ће правилно документовање нефункционалног захтева и правилно извршавање тестирања обезбедити велико задовољство у погледу употребљивости потенцијалних купаца.

Иако ово тестирање нема директан пословни утицај на функционалност система, оно може у већој мери повећати корисничко искуство и једноставност за употребу, што ће заузврат имати већи утицај на квалитет софтвера.

Пример:

Размотрите исти пример Фацебоок странице за пријаву. У овом случају, опсег нефункционалног тестирања је да забележи време потребно систему да се пријави на Фацебоок након уноса важећих акредитива.

Такође, може се тестирати када се (рецимо 100) корисници истовремено пријаве, колико времена је потребно да се корисник пријави на Фацебоок.

Ово осигурава да систем може да се носи са оптерећењем и саобраћајем, што заузврат има добро корисничко искуство.

Агилан, нефункционални захтев треба ухватити помоћу улаза.

Нефункционални захтев треба обухватити као:

• Корисничке / техничке приче
• У критеријумима за прихватање
• У Артефакту

9

# 1) Корисничке / техничке приче

Нефункционални захтев се може ухватити помоћу корисничке приче или техничке приче. Снимање нефункционалних захтева као корисничке приче је исто као и хватање било ког другог захтева. Једина разлика у корисничкој и техничкој причи је та што корисничка прича захтева дискусију и има видљивост.

# 2) Критеријуми за прихватање

Кретеријум је тачка која је дефинисана за прихватање производа од стране купца, тј. да би се производ прихватио до дефинисаних тачака треба да буде у пролазном стању.

Нефункционални захтев треба да буде укључен у критеријуме прихватања, али понекад није могуће тестирати нефункционалне захтеве са сваком причом, тј. Са сваком итерацијом. Дакле, захтеве треба додати или тестирати само са одговарајућом итерацијом.

# 3) У Артефактима

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

Разлика у функционалним и нефункционалним захтевима

Постоји неколико разлика између функционалних и нефункционалних захтева, а неколико од њих је наведено у наставку:

Даље читање => Разлике између функционалног и нефункционалног тестирања

Да ли је ово тестирање црне кутије или беле кутије?

Нефункционални тест спада под тестирање црне кутије техника.

Ова техника није ограничена само на тестирање функционалности, већ се такође може користити за тестирање нефункционалних захтева, као и перформанси, употребљивости итд. Техника тестирања црне кутије не захтева никакво знање о унутрашњем систему, тј. Не захтева знање кода тестера.

Контролна листа нефункционалних случајева

Контролна листа се користи како би се осигурало да ниједан важан аспект не остане без тестирања.

Контролна листа се обично користи када нема времена за документацију и производ мора да се тестира или када постоји временско ограничење, контролна листа се може користити да би се осигурало да су покривени сви важни аспекти.

Да видимопримерконтролне листе за тестирање перформанси, безбедности и документације.

Контролна листа за испитивање перформанси

• Време одзива апликације треба верификовати, тј. колико је потребно учитавање апликације, било који унос дат апликацији даје излаз за колико времена, освежавање прегледача итд.
• Пропусност треба верификовати број трансакција извршених током теста учитавања.
• Животна средина постављено треба да буде исто као и живо окружење, иначе резултати не би били исти.
• Процесно време - Процесне активности попут увоза и извоза екцела, било који прорачун у апликацији треба тестирати.
• Компатибилност треба верификовати, тј. софтвер треба да буде у могућности да комуницира са другим софтвером или системима.
• ЕТЛ време треба верификовати, тј. време потребно за издвајање, трансформисање и учитавање података из једне базе података у другу.
• Повећавање оптерећења на пријави треба верификовати.

Контролна листа за безбедносно тестирање

• Аутентикација: Само аутентични корисник треба да буде у могућности да се пријави.
• Овлашћени: Корисник би требао бити у могућности да се пријави само на оне модуле за које је овлаштен или за које је кориснику омогућен приступ.
• Лозинка: Потребно је верификовати захтев за лозинком, тј. Лозинка треба да буде у складу са начином на који захтев дефинише тј. Дужину, посебне знакове, бројеве итд.
• Пауза у утакмици: Ако је апликација неактивна, требало би да истекне за одређено време.
• Повратак података: Сигурносне копије података треба узети у одређено време и копирати их на сигурно место.
• Интерне везе веб апликацији не би требало да буде доступна ако се налази директно у прегледачу.
• Сва комуникација треба да буде шифрована.

Контролна листа за тестирање документације

• Корисничка и системска документација.
• Документи у сврху обуке.

Приступни документ

Развијте документ специфичног приступа за фазу испитивања перформанси дорађивањем целокупне стратегије тестирања. Овај тест приступ води кроз планирање и извршавање свих задатака тестова перформанси.

ц ++ сачекајте секунде

• Опсег испитивања
• Тест Метрицс
• Алати за тестирање
• Кључни датуми и резултати

Опсег испитивања

Извршите тестирање перформанси из различитих перспектива, као што су перформансе корисника, пословни процеси, стабилност система, потрошња ресурса итд. Врсте испитивања перформанси које треба извршити размотрене су у горњем одељку чланка (попут теста оптерећења, теста напрезања итд.)

Тест Метрицс

Приступ тестирању прецизира метрике за мерење и извештавање током тестирања, као што су:

• Време одзива (на мрежи)
• Прозор серије (серија)
• Пропусност ( На пример , број трансакција у јединици времена)
• Коришћење ( На пример , проценат коришћених ресурса)

Алати за тестирање

Тестирање перформанси углавном захтева употребу одговарајућих алата:

• Алати за генерисање терета
• Алати за праћење учинка
• Алати за анализу учинка
• Алати за профилисање апликација
• Алати за облагање подножја.

Кључни датуми и резултати

Документ о приступу испитивању перформанси треба да описује следеће:

• Датум и време сваког извођења теста перформанси.
• Врсте тестова и комбинација функционалности које треба укључити у свако спровођење теста перформанси.
• Датуми завршетка теста перформанси.

Нефункционални типови испитивања

Следећа слика приказује типове нефункционалног тестирања:

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

Процењује укупне перформансе система .

Кључни елементи су следећи:

• Потврђује да систем испуњава очекивано време одзива.
• Процењује да значајни елементи апликације испуњавају жељено време одзива.
• Такође се може спровести као део интеграционог тестирања и тестирања система.

Испитивање оптерећења:

Процењује да ли су перформансе система очекиване у нормалним и очекиваним условима.

Кључне тачке су:

• Потврђује да систем ради онако како се очекивало када истовремени корисници приступе апликацији и добију очекивано време одзива.
• Овај тест се понавља са више корисника да би се добило време одзива и пропусност.
• У време тестирања база података требало би да буде реална.
• Тест треба спровести на наменском серверу који стимулише стварно окружење.

Испитивање напрезања:

Процењује да ли су перформансе система очекиване када нема довољно ресурса.

Кључне тачке су:

• Тестирајте на мало меморије или на меморијском простору на клијентима / серверима који откривају недостатке који се у нормалним условима не могу наћи.
• Више корисника врши исте трансакције на истим подацима.
• Више клијената је повезано са серверима са различитим радним оптерећењима.
• Смањите време размишљања на „Нула“ да бисте сервере стресирали на њихов максималан стрес.

Тхинк Тиме: Баш као и временски интервал између уноса вашег корисника и лозинке.

Тестирање запремине:

Процењује понашање софтвера када је у питању велика количина података.

Кључне тачке су:

• Када је софтвер подложан великим количинама података, проверава ограничење у случају када софтвер откаже.
• Израђује се максимална величина базе података и више клијената тражи базу података или креира већи извештај.
• Пример - Ако апликација обрађује базу података да би креирала извештај, тест обима био би употреба великог скупа резултата и провера да ли је извештај правилно одштампан.

Испитивање употребљивости:

Процењује систем за људску употребу или проверава да ли је погодан за употребу.

Кључне тачке су:

• Да ли је резултат тачан и смислен и да ли је исти као што се очекивало према послу?
• Да ли су грешке правилно дијагностиковане?
• Да ли је ГУИ тачан и у складу са стандардом?
• Да ли је апликација једноставна за употребу?

Тестирање корисничког интерфејса:

Процењује ГУИ.

Кључне тачке су:

• ГУИ треба да пружи помоћ и савете алата како би га олакшао за употребу.
• Доследан по свом изгледу?
• Подаци се правилно пребацују са једне странице на другу?
• Графички кориснички интерфејс не сме да нервира корисника или да постане тешко за разумевање.

Испитивање компатибилности:

Процењује да је апликација компатибилна са осталим хардвером / софтвером са минималном и максималном конфигурацијом.

Кључне тачке су:

• Тестирајте сваки хардвер са минималном и максималном конфигурацијом.
• Тестирајте са различитим прегледачима.
  Тест случајеви су исти као они који су извршени током функционалног тестирања.
• У случају да је број хардвера и софтвера превише, онда можемо да користимо технике ОАТС да бисмо дошли до тест случајева како бисмо имали максимално покриће.

Испитивање опоравка:

Процењује да се апликација елегантно завршава у случају било каквог квара и да се подаци одговарајуће опорављају од било каквих кварова хардвера и софтвера.

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

• Прекид напајања клијенту током обављања ЦУРД активности.
• Неважећи показивачи базе података и кључеви.
• Процес базе података је прекинут или превремено завршен.
• Показивачи, поља и кључеви базе података оштећени су ручно и директно у бази података.
• Физички искључите комуникацију, искључите напајање, искључите рутере и мрежне сервере.

Испитивање нестабилности:

Процењује и потврђује да ли се софтвер правилно инсталира и деинсталира.

ворлд оф варцрафт ванилин приватни сервер

Кључне тачке су:

• Потврђује да су системске компоненте исправно инсталиране на назначени хардвер.
• Потврђује да навигација на новом уређају ажурира постојећу инсталацију и старије верзије.
• Потврђује да са недовољним простором на диску нема неприхватљивог понашања.

Испитивање документације:

Процењује документе и друге корисничке приручнике.

Кључне тачке укључују:

• Потврђује да су наведени документи доступни у производу.
• Потврђује све корисничке водиче, поставља упутства, чита ми датотеке, белешке о издању и помоћ на мрежи.

Испитивање отказа:

Испитивање отказа се врши како би се верификовало да је у случају квара система систем довољно способан да рукује додатним ресурсима попут сервера.

Да би се спречила таква ситуација, тестирање резервних копија игра велику улогу. Стварање резервног система је оно што је процес. Ако је резервна копија доступна, онда помаже у повратку система.

Испитивање сигурности:

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

Укључује тестирање аутентичности, ауторизације, интегритета и доступности.

Испитивање скалабилности:

Тестирање скалабилности се врши да би се верификовало да ли је апликација довољно способна да се носи са повећаним прометом, бројем трансакција, обимом података итд. Систем треба да ради како се очекује када се изврши обим података или промена величине података.

Испитивање усаглашености:

Испитивање усаглашености врши се како би се верификовало да ли се поштују дефинисани стандарди. Ревизије се раде да би се потврдило исто.

За Пример , Ревизије се врше да би се верификовао поступак стварања тест случајева / планова испитивања и њихово смештање на заједничку локацију са стандардним именом које се ради или не. У КЦ-у, док се именују тест случајеви, прати се стандардно име тест случаја или не. Документација је комплетна и одобрена или не.

Ово је неколико упута које су обухваћене током ревизије.

Испитивање издржљивости:

Испитивање издржљивости се врши ради верификације понашања система када се оптерећење повећа у одређеној мери дуго.

Такође се назива и Соак тестирање и тестирање капацитета. Помаже у провери да ли у систему цури меморија. Испитивање издржљивости је подскуп испитивања оптерећења.

Испитивање локализације:

Испитивање локализације се врши ради верификације апликације на различитим језицима, тј. различитим локалитетима. Пријава треба да буде верификована за одређену културу или локалитет. Главни фокус је тестирање садржаја, ГУИ апликације.

Испитивање интернационализације:

Испитивање интернационализације је такође познато као и18н тестирање.

И18н представља И - осамнаест слова - Н. То се ради да би се верификовало да ли апликација ради како се очекује у свим поставкама језика. Проверава да се било која функционалност или сама апликација не поквари, тј. Апликација треба да буде довољно способна да обрађује сва међународна подешавања.

Такође проверава да ли се апликација инсталира без икаквих проблема.

Испитивање поузданости:

Тестирање поузданости се врши како би се утврдило да ли је апликација поуздана и тестира ли се одређено време у дефинисаном окружењу. Апликација треба сваки пут давати исти резултат као што се очекивало, само се тада може сматрати поузданим.

Испитивање преносивости:

Тестирање преносивости врши се да би се верификовало да ли у случају да је софтвер / апликација инсталиран на другом систему или на другој платформи, да ли треба да може да се покреће како се очекује, тј. Ниједна функционалност не сме да утиче због промене у окружењу.

Током тестирања, такође је потребно тестирати промену помоћу хардверске конфигурације, као што је простор на чврстом диску, процесор, као и помоћу различитих оперативних система како би се осигурало исправно понашање и очекивана функционалност апликације.

Основно тестирање:

Почетно тестирање је такође познато као бенчмарк тестирање јер ствара основу за било коју нову апликацију која се тестира.

На пример: У првој итерацији, време одзива апликације је било 3 секунде. Сада је ово постављено као репер за следећу итерацију, а у следећој итерацији време одзива се мења на 2 секунде. То је у основи документ о валидацији који се користи као основа за будуће референце.

Испитивање ефикасности:

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

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

Испитивање опоравка од катастрофе:

Ово тестирање се врши како би се верификовало степен успешности опоравка апликације или система ако се деси било какав критични квар и да ли је систем у стању да обнови податке и апликацију или се систем лако снашао да би вратио начин на који је раније радио, тј. оперативни фронт.

Испитивање одржавања:

Једном када апликација / производ крене уживо, постоји могућност да се проблем појави у живом окружењу или ће купац можда желети побољшање за апликацију која је већ активна.

У овом случају, тим за тестирање одржавања доступан је за тестирање горе поменутих сценарија. Када апликација почне да ради, и даље јој је потребно одржавање за које ради тим за тестирање одржавања.

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

На тржишту је доступно неколико алата за испитивање перформанси (оптерећења и напрезања).

Неколико њих је наведено у наставку:

• ЈМетер
• Лоадстер
• Лоадруннер
• Лоадсторм
• Неолоад
• Прогноза
• Учитавање завршено
• Алат за стрес веб сервера
• ВебЛоад Профессионал
• Лоадтрацер
• вПерформер

Да ли се нефункционално тестирање увек спроводи без документације и тест случајева? Зашто?

„Увек нас уче како да пишемо функционалне тестове. Зашто је то? Да ли се „нефункционално тестирање“ врши без документације (другим речима, ад хоц) или је то засебан процес који је много теже разумети? Како се пишу примери за различите врсте испитивања која се дешавају у апликацији? “

Ово је једно од најоригиналнијих, најосебујнијих и најнеобичнијих питања која су ми постављена у последње време. Пронађимо одговор.

Како то да никад не видимо и вежбамо у писању нефункционалних тест случајева?

Почнимо са оним што знамо и као и увек са практичним сценаријем.

Пример: Следе кораци које треба извршити у апликацији за мрежно банкарство да би се извршио пренос. Искористимо то као тест за референцу.

1. Пријавите се на сајт.
2. Изаберите банковни рачун.
3. Изаберите примаоца уплате (овај прималац уплате могао би припадати истој банци или некој другој - ово зависи од вашег избора података за извршење овог корака. У сваком случају, одаберите један. Такође, претпоставићемо да је прималац уплате већ додат.) .
4. Унесите износ за пренос (позитивна вредност, унутар ограничења, тачан формат итд.).
5. Кликните на Трансфер и проверите да ли је примљена потврда, да ли је стање на рачуну ажурирано и све то.

Ово је функционални тест, тачно?

На истој апликацији, на истој страници трансфера, рецимо да наступамо Испитивање перформанси, сигурности и употребљивости . То су нефункционални типови, зар не?

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

# 1) Тест случајеви тестирања употребљивости

Тестирање употребљивости је жанр софтверског тестирања који се бави корисничким искуством. Ово су нека од питања на која покушавамо да одговоримо.

• Колико је једноставно користити апликацију?
• Колико је задовољавајуће искуство коришћења система?
• Ако не одмах то познато, колико је лако научити?

Више информација о томе је овде: Водич за испитивање употребљивости

Како би корисник одредио одговоре на горња питања у контексту тестирања употребљивости?

Корисник би извршио потпуно исте кораке као у случају функционалног теста. Да ли сам у праву?

# 2) Тест случајеви тестирања перформанси

Постоји неколико варијација тестирања перформанси, али у основи се користи за добијање статистике о систему, коришћењу ресурса, времену одзива, потрошњи мреже итд. На различитим тачкама учитавања.

Погледајте наш Водичи за тестирање перформанси да бисте сазнали више о томе.

Сада, ако бих тестирао перформансе трансакције трансфера, имао бих 10, 20, 30, 100 ... 1000 ... итд. Корисници извршавају операцију преноса истовремено или постепено, у зависности од тога на шта желим циљати и прикупљати податке.

Које кораке би сваки корисник извршио да би користио пренос док је тест перформанси у току?

Исти тачни кораци као и функционални тест, тачно?

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

Испитивање сигурности је грана осигурања квалитета која помаже да софтверски системи буду заштићени од хаковања. Идентификује рањивости (потенцијална проблематична подручја у софтверском систему), користи их пенетрацијом или техником тестирања белог шешира и када се пронађу рупе на њима, ради се на њима.

Када желим да проверим да ли су трансфери против хаковања и да ли су исправно усмерени примаоцима и да ли у целом процесу нема црних тачака? Пренос бих обављао док се паралелно одвија поступак праћења цурења безбедности.

Стога, у ствари, спроводим потпуно исте кораке које бих иначе радио у случају функционалног тест случаја.

Претпостављам да имамо довољно да утврдимо да су кораци у свим ситуацијама исти. Метода и намера која стоји иза процеса су оно што је различито.

Погледајмо упоредни приказ:

Оно што је занимљиво напоменути је то без обзира који облик тестирања желимо да урадимо, сви кораци су исти .

Права разлика је у томе што:

1. Ко изводи ове кораке?
2. Каква је намера, или другим речима шта покушавам да постигнем овим тестом?
3. Коришћени алати и технике.

Враћајући се на наше питање, зашто никада не научимо да пишемо нефункционалне тест случајеве са свим детаљним корацима који су у вези са тим?

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

Закључак

Пре него што извршите нефункционално тестирање, неопходно је правилно планирати стратегију тестирања како бисте осигурали правилно тестирање. На тржишту су доступни различити алати за извођење ове врсте тестова попут Лоад Руннер, РПТ итд.

Ово тестирање игра главну улогу у успеху апликације и у изградњи добрих односа са купцима и стога га не треба занемарити. Ово је један од важних делова тестирања софтвера и тестирање се без тога не може сматрати комплетним.

У план испитивања можемо да уврстимо детаље нефункционалног тестирања или можемо да створимо засебну стратегију за њега. У оба случаја, циљ је правилно покривање нефункционалних аспеката софтвера.

Надамо се да вам је овај процес удубљивања у ову тему био једнако забаван као и свима вама. Волели бисмо да чујемо ваше повратне информације и размишљања о овој теми.

Како се носите са нефункционалним тестирањем у својим тимовима? И као и увек, обавестите нас ако се слажете или не или ако желите да додате нешто што овде радимо.

Препоручено читање

• Функционално тестирање вс нефункционално тестирање
• Алфа тестирање и бета тестирање (потпун водич)
• Водич за тестирање безбедности веб апликација
• Комплетан водич за функционално тестирање са својим врстама и примерима
• Комплетни водич за тестирање верификације израде (БВТ тестирање)
• Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
• Водич за почетнике за тестирање продирања у веб апликације
• Комплетан водич за тестирање оптерећења за почетнике