complete non functional testing guide
Kompletný sprievodca nefunkčným testovaním: jeho účel, typy, nástroj, testovacie prípady s príkladmi
Čo je nefunkčné testovanie?
Nefunkčné testovanie sa vykonáva na overenie nefunkčných požiadaviek aplikácie, ako je výkon, použiteľnosť atď.
Overuje, či správanie systému zodpovedá požiadavkám alebo nie. Zahŕňa všetky aspekty, ktoré nie sú obsiahnuté v tomto dokumente funkčné testovanie . Pri našom každodennom testovaní sa veľká pozornosť venuje funkčnému testovaniu a funkčným požiadavkám.
Klienti majú tiež záujem o splnenie funkčných požiadaviek, ktoré priamo súvisia s funkčnosťou aplikácie. Ale v skutočnej fáze, tj. Keď ste funkčne testovaní, softvér prichádza na trh a používajú ho skutoční koncoví používatelia. Existuje šanca, že bude čeliť niektorým problémom súvisiacim s výkonom.
Tieto problémy nesúvisia s funkčnosťou systému, môžu však negatívne ovplyvniť používateľskú skúsenosť. Preto je dôležité, aby bol softvér alebo aplikácia testovaná aj na nefunkčné požiadavky, aby sa zabránilo negatívnym skúsenostiam zákazníkov.
Testovanie je všeobecne rozdelené do dvoch typov:
- Funkčné testovanie
- Nefunkčné testovanie
Čo sa dozviete:
- Dôležitosť
- Účel
- Príklad
- Výhody
- Ako zachytiť nefunkčné požiadavky?
- Rozdiel vo funkčných a nefunkčných požiadavkách
- Testuje sa táto čierna skrinka alebo biela skrinka?
- Kontrolný zoznam nefunkčných testovacích prípadov
- Prístupový dokument
- Typy nefunkčných testov
- Nefunkčné testovacie nástroje
- Záver
- Odporúčané čítanie
Dôležitosť
Tomuto testovaniu chýbala náležitá pozornosť, pretože to nemá vplyv na funkčnosť systému.
Požiadavkám na nefunkčnosť sa v predchádzajúcich testovacích cykloch tiež nevenovala náležitá pozornosť. To sa však teraz zmenilo. Nefunkčné testy sú teraz najdôležitejšie, pretože zohľadňujú všetky problémy s výkonom a zabezpečením aplikácií v dnešnej dobe.
Toto testovanie má väčší vplyv na aplikácie, pokiaľ ide o výkon aplikácie pri vysokej premávke používateľov. Toto testovanie zaručuje, že vaša aplikácia je stabilná a je schopná zvládnuť zaťaženie v extrémnych podmienkach.
Ako sám názov napovedá, toto testovanie sa sústreďuje na nefunkčný aspekt aplikácie. Aké sú teda nefunkčné aspekty? Alebo by som mal povedať, aké sú vlastnosti, ktoré nesúvisia s funkčnosťou aplikácie?
Tu sú odpovede na tieto otázky:
- Ako funguje aplikácia za normálnych okolností?
- Ako sa chová aplikácia, keď sa súčasne prihlási príliš veľa používateľov?
- Zvládne aplikácia stres?
- Aká bezpečná je aplikácia?
- Môže sa aplikácia zotaviť z nejakej katastrofy?
- Môže sa aplikácia správať rovnako v inom prostredí alebo OS?
- Aké ľahké je preniesť aplikáciu do iného systému?
- Sú dokumenty / užívateľská príručka dodávaná s aplikáciou ľahko zrozumiteľné?
Zoznam stále pokračuje. Tu však ide o to, že neprispievajú tieto vlastnosti ku kvalite aplikácie? Odpoveď je ÁNO. Tieto funkcie sú rovnako dôležité.
Predstavte si, že aplikácia dokonale spĺňa všetky požiadavky používateľov, ale nejaký neoprávnený používateľ ľahko narazí na údaje zadané používateľom v aplikácii alebo praskne, alebo ak aplikácia nahrá viac ako 5 BB ľubovoľného súboru, zomrie. Povedali by ste teda, že žiadosť je kvalitná? Evidentne nie v poriadku !!
Účel
Jediným účelom tohto typu testovania je zabezpečiť, aby sa testovali nefunkčné aspekty aplikácie a aby aplikácia fungovala dobre aj v rovnakom kontexte.
Účelom je pokryť testovanie všetkých charakteristík aplikácie, ktoré pomáhajú zabezpečiť aplikáciu, ktorá spĺňa obchodné očakávania.
Príklad
Toto je dôležitý typ testovania.
Funkčné testovanie testuje funkčnosť aplikácie a zaisťuje jej fungovanie podľa očakávania, ale nefunkčné testovanie zaisťuje, že aplikácia funguje dostatočne dobre, aby splnila obchodné očakávania.
Aby sme pochopili jeho dôležitosť, vezmime si jednoduchý príklad:
Aplikácia je vyvinutá a je úplne testovaná na funkčnosť, ale nefunkčné testovanie sa nevykonáva súčasne.
Medzitým, keď bude aplikácia zverejnená, môže to mať za následok kritické alebo závažné problémy, napríklad keď sa zvýši zaťaženie aplikácie, stane sa príliš pomalá a jej otvorenie trvá veľa času.
Môže sa zvýšiť čas odozvy alebo ak sa zaťaženie do istej miery zvýši, môže dôjsť k zlyhaniu aplikácie. To ukazuje, aké dôležité je testovať nefunkčné aspekty aplikácie.
Výhody
Ďalej sú uvedené niektoré výhody nefunkčného testu:
- Zahŕňa testovanie, ktoré nemožno zahrnúť do funkčného testovania.
- Zaisťuje, že aplikácia beží efektívne a je dostatočne spoľahlivá.
- Zaisťuje bezpečnosť aplikácie.
Ako zachytiť nefunkčné požiadavky?
Pri vykonávaní testov sa zameriavame hlavne na funkčné testovanie, pri ktorom sa testuje funkčnosť produktu. Ale nefunkčné testovanie je rovnako dôležité ako funkčné testovanie a jeho požiadavka by sa mala brať do úvahy hneď od začiatku výroby.
Na vykonávanie nefunkčného testovania sa používajú nefunkčné požiadavky. Tieto požiadavky zahŕňajú výstup výkonu, ktorý sa očakáva od testovanej aplikácie alebo softvéru. To v zásade zahŕňa čas, ktorý softvér potrebuje na prevádzku konkrétneho systému.
Nefunkčné požiadavky tiež zachytávajú správanie, keď softvér súčasne používa veľké množstvo ľudí. Väčšinou sa stáva, že servery sú zaneprázdnené alebo nedostupné z dôvodu veľkého zaťaženia (t. J. Viac ľudí ich používa súčasne). Rezervácia online železničných lístkov môže byť najlepšia príklad takejto situácie.
Preto správne zdokumentovanie požiadavky na nefunkčnosť a správne vykonanie testovania zabezpečí vysokú spokojnosť z hľadiska použiteľnosti pre potenciálnych zákazníkov.
Aj keď toto testovanie nemá priamy obchodný dopad na funkčnosť systému, môže zvýšiť užívateľskú skúsenosť a užívateľskú prívetivosť vo vyššej miere, čo bude mať zase väčší vplyv na kvalitu softvéru.
Príklad:
Zvážte rovnaký príklad prihlasovacej stránky na Facebooku. V takom prípade je predmetom nefunkčného testovania zaznamenať čas, ktorý systém vyžaduje na prihlásenie na Facebook po zadaní platných poverení.
Dá sa tiež vyskúšať, ako keď sa (povedzme 100) používatelia prihlásia súčasne, koľko času trvá prihlásenie používateľa na Facebooku.
To zaisťuje, že systém zvládne zaťaženie a prenos, čo má zase dobrý dojem z používania.
V agile by mala byť nefunkčná požiadavka zachytená pomocou vstupov.
Nefunkčná požiadavka by sa mala zachytiť ako:
- Používateľské / technické príbehy
- V kritériách prijatia
- In Artefakt
9
# 1) Používateľské / technické príbehy
Nefunkčnú požiadavku je možné zachytiť pomocou príbehy používateľov alebo technické príbehy. Zachytenie nefunkčných požiadaviek ako užívateľského príbehu je rovnaké ako zachytenie akýchkoľvek iných požiadaviek. Jediný rozdiel v užívateľskom a technickom príbehu je ten, že užívateľský príbeh vyžaduje diskusiu a je viditeľný.
# 2) Kritériá prijatia
Kritériá prijateľnosti je bod, ktorý je definovaný pre prijatie produktu zákazníkom, to znamená, aby sa produkt prijal do definovaných bodov, by mal byť v stave vyhovenia.
Nefunkčná požiadavka by mala byť zahrnutá do kritérií prijatia, ale niekedy nie je možné otestovať nefunkčné požiadavky s každým príbehom, tj. S každou iteráciou. Preto by sa požiadavky mali pridávať alebo testovať iba pomocou príslušnej iterácie.
# 3) V artefaktoch
Pre nefunkčné požiadavky by mal byť pripravený samostatný artefakt, čo by zase pomohlo získať lepšiu predstavu o tom, čo je potrebné testovať a ako sa to dá robiť v iteráciách.
Rozdiel vo funkčných a nefunkčných požiadavkách
Existuje niekoľko rozdielov medzi funkčnými a nefunkčnými požiadavkami a niekoľko z nich je uvedených nižšie:
S.No. | Funkčná požiadavka | Nefunkčná požiadavka |
---|---|---|
Výkon | Testery výkonu pomocou nástroja, ktorý považuje operáciu za transakciu vykonanú určitým počtom súbežných používateľov, zatiaľ čo tester analyzuje všetku logistiku | Doba odozvy |
1 | Funkčné požiadavky sú založené na zákazníkoch. | Nefunkčná požiadavka je založená na vývojároch a technických znalostiach tímu. |
dva | Funkčná požiadavka určuje, ktorá funkčnosť sa má brať do úvahy, t. J. Čo je potrebné testovať. | Nefunkčné požiadavky určujú, ako je potrebné testovať. |
3 | Funkčné testovanie sa vykonáva pred uvedením aplikácie do prevádzky. | Nefunkčné požiadavky zahŕňajú testovanie údržby, testovanie dokumentácie, ktoré sa nevyžadujú počas prebiehajúceho vykonávania, ale jedna, ktorá bola uvedená do života. |
4 | Je známa iba ako funkčná požiadavka. | Známe tiež ako Kvalitné požiadavky. |
5 | Plán implementácie funkčných požiadaviek je definovaný v dokumente návrhu systému. | Plán implementácie nefunkčných požiadaviek je definovaný v architektúre systému. |
6 | Medzi funkčné požiadavky patrí testovanie technickej funkčnosti systému. | Nefunkčné požiadavky zahŕňajú vlastnosti ako bezpečnosť, použiteľnosť atď. |
Ďalšie čítanie => Rozdiely medzi funkčným a nefunkčným testovaním
Testuje sa táto čierna skrinka alebo biela skrinka?
Nefunkčný test spadá pod a testovanie čiernej skrinky technika.
Táto technika sa neobmedzuje iba na testovanie funkčnosti, ale dá sa použiť aj na testovanie nefunkčných požiadaviek, ako aj výkonnosti, použiteľnosti atď. Technika testovania čiernej skrinky nevyžaduje žiadne znalosti interného systému, tj. Nevyžaduje znalosť kódu pre testera.
Kontrolný zoznam nefunkčných testovacích prípadov
Kontrolný zoznam sa používa na zabezpečenie toho, aby bez testovania nezostal žiadny dôležitý aspekt.
Kontrolný zoznam sa zvyčajne používa, keď nie je čas na dokumentáciu a produkt musí byť testovaný, alebo ak existuje časové obmedzenie, môže sa použiť kontrolný zoznam, ktorý zabezpečí, že boli splnené všetky dôležité aspekty.
Pozrime sapríkladKontrolný zoznam testovania výkonnosti, bezpečnosti a dokumentácie.
Kontrolný zoznam na testovanie výkonu
- Doba odozvy aplikácie by mal byť overený, t. j. ako dlho trvá načítanie aplikácie, akýkoľvek vstup poskytnutý aplikácii poskytne výstup za koľko času, obnovenie prehliadača atď.
- Priepustnosť by sa mal overiť z hľadiska počtu transakcií dokončených počas testu zaťaženia.
- Životné prostredie nastavenie by malo byť rovnaké ako živé prostredie, inak by výsledky neboli rovnaké.
- Čas spracovania - Procesné činnosti, ako je import a export programu Excel, je potrebné otestovať všetky výpočty v aplikácii.
- Interoperabilita softvér by mal byť schopný vzájomnej spolupráce s iným softvérom alebo systémami.
- ETL čas by sa mal overiť, t. j. čas potrebný na extrakciu, transformáciu a načítanie údajov z jednej databázy do druhej.
- Zvyšovanie zaťaženia na žiadosti by mala byť overená.
Kontrolný zoznam na testovanie bezpečnosti
- Overenie: Prihlásiť sa má iba autentický používateľ.
- Autorizovaný: Užívateľ by mal byť schopný prihlásiť sa do tých modulov, ku ktorým má oprávnenie alebo ku ktorým má používateľ prístup.
- Heslo: Požiadavka na heslo by mala byť overená, t. J. Heslo by malo zodpovedať definovaniu požiadavky, t. J. Dĺžka, špeciálne znaky, čísla atď.
- Čas vypršal: Ak je aplikácia neaktívna, mala by v stanovenom čase vypršať časový limit.
- Zálohovanie dát: Zálohovanie údajov by sa malo vykonať v určený čas a malo by sa skopírovať na zabezpečené miesto.
- Interné odkazy k webovej aplikácii by nemali byť prístupné, ak sú umiestnené priamo v prehliadači.
- Celá komunikácia by mala byť šifrovaná.
Kontrolný zoznam na testovanie dokumentácie
- Užívateľská a systémová dokumentácia.
- Dokumenty na školiace účely.
Prístupový dokument
Vyvinutím celkovej stratégie testovania vypracovať dokument špecifického prístupu pre fázu Testovania výkonu. Tento testovací prístup vedie pri plánovaní a vykonávaní všetkých úloh týkajúcich sa testovania výkonu.
ukladanie objektov do poľa java
- Rozsah skúšky
- Testovacie metriky
- Testovacie nástroje
- Kľúčové dátumy a výsledky
Rozsah skúšky
Vykonajte testovanie výkonu z rôznych hľadísk, ako napríklad výkon používateľa, obchodné procesy, stabilita systému, spotreba zdrojov atď. O typoch vykonávania testovania výkonu sa hovorí v predchádzajúcej časti článku (napríklad záťažový test, záťažový test atď.)
Testovacie metriky
Prístup Test spresňuje metriky, ktoré sa majú merať a vykazovať počas testovania, napríklad:
- Čas odozvy (online)
- Dávkové okno (dávka)
- Priepustnosť ( Napríklad , počet transakcií za jednotku času)
- Využitie ( Napríklad , percento použitých zdrojov)
Testovacie nástroje
Testovanie výkonu si väčšinou vyžaduje použitie vhodných nástrojov:
- Nástroje na generovanie záťaže
- Nástroje na monitorovanie výkonu
- Nástroje na analýzu výkonnosti
- Nástroje na profilovanie aplikácií
- Nástroje na podšívku.
Kľúčové dátumy a výsledky
Dokument o prístupe k testu výkonu by mal popisovať nasledovné:
- Dátum a čas vykonania každého testu výkonnosti.
- Typy testov a kombinácie funkcií, ktoré majú byť zahrnuté do každého vykonania testu výkonnosti.
- Termíny ukončenia testu výkonnosti.
Typy nefunkčných testov
Nasledujúci obrázok zobrazuje typy nefunkčných testov:
Testovanie výkonu:
Vyhodnocuje celkovú výkonnosť systému .
Kľúčové prvky sú tieto:
- Overuje, či systém spĺňa očakávaný čas odozvy.
- Vyhodnocuje, či významné prvky aplikácie spĺňajú požadovaný čas odozvy.
- Môže sa tiež vykonávať ako súčasť integračného testovania a testovania systému.
Testovanie záťaže:
Vyhodnocuje, či je výkon systému podľa očakávaní za normálnych a očakávaných podmienok.
Kľúčové body sú:
- Overuje, či systém funguje podľa očakávania, keď súbežní používatelia pristupujú k aplikácii a získajú očakávaný čas odozvy.
- Tento test sa opakuje s viacerými používateľmi, aby sa získal čas a priepustnosť.
- V čase testovania by mala byť databáza realistická.
- Test by sa mal vykonať na dedikovanom serveri, ktorý stimuluje skutočné prostredie.
Stresové testovanie:
Vyhodnocuje, či je výkon systému očakávaný, keď má málo zdrojov.
Kľúčové body sú:
- Testujte na nedostatku pamäte alebo na disku na klientoch / serveroch, ktoré odhalia chyby, ktoré sa za normálnych podmienok nedajú nájsť.
- Viacero používateľov vykonáva rovnaké transakcie s rovnakými údajmi.
- K serverom je pripojených viac klientov s rôznymi pracovnými záťažami.
- Skráťte Think Time na „nulu“, aby ste servery zaťažili na maximum.
Čas na rozmyslenie: Rovnako ako časový interval medzi zadaním používateľa a hesla.
Testovanie hlasitosti:
Vyhodnocuje správanie softvéru, ak ide o veľký objem údajov.
Kľúčové body sú:
- Ak softvér podlieha veľkému množstvu údajov, skontroluje limit, pri ktorom softvér zlyhá.
- Vytvorí sa maximálna veľkosť databázy a viacerí klienti vyhľadajú databázu alebo vytvoria väčšiu správu.
- Príklad - Ak aplikácia spracúva databázu na vytvorenie správy, objemovým testom by bolo použitie veľkej sady výsledkov a kontrola, či je správa vytlačená správne.
Testovanie použiteľnosti:
Hodnotí systém pre humánne použitie alebo kontroluje, či je vhodný na použitie.
Kľúčové body sú:
- Je výstup správny a zmysluplný a je rovnaký, aký sa očakával od firmy?
- Sú chyby diagnostikované správne?
- Je GUI správne a v súlade so štandardom?
- Je aplikácia ľahká na používanie?
Testovanie používateľského rozhrania:
Vyhodnocuje GUI.
Kľúčové body sú:
- GUI by malo poskytovať pomoc a popisy nástrojov, ktoré uľahčujú jeho používanie.
- Konzistentné pre svoj vzhľad?
- Dáta sa správne prenášajú z jednej stránky na druhú?
- GUI by nemalo otravovať používateľa alebo byť ťažko pochopiteľné.
Testovanie kompatibility:
Vyhodnocuje, či je aplikácia kompatibilná s iným hardvérom / softvérom s minimálnou a maximálnou konfiguráciou.
Kľúčové body sú:
- Vyskúšajte každý hardvér s minimálnou a maximálnou konfiguráciou.
- Testujte s rôznymi prehliadačmi.
Testovacie prípady sú rovnaké ako prípady, ktoré sa vykonali počas funkčného testovania. - V prípade, že je hardvér a softvér príliš veľa, potom môžeme pomocou techník OATS dospieť k testovacím prípadom, aby sme dosiahli maximálne pokrytie.
Testovanie obnovy:
Vyhodnocuje, že sa aplikácia elegantne ukončí v prípade akejkoľvek poruchy a že údaje sa primerane obnovia po všetkých zlyhaniach hardvéru a softvéru.
Testy sa neobmedzujú iba na tieto body:
- Prerušenie napájania klientovi pri vykonávaní CURD aktivít.
- Neplatné ukazovatele a kľúče databázy.
- Proces databázy je prerušený alebo predčasne ukončený.
- Ukazovatele, polia a kľúče databázy sú poškodené manuálne a priamo v databáze.
- Fyzicky odpojte komunikáciu, vypnite napájanie, vypnite smerovače a sieťové servery.
Testovanie nestability:
Vyhodnocuje a potvrdzuje, či sa softvér inštaluje a odinštaluje správne.
najlepší bezplatný počítačový čistič pre Windows 10
Kľúčové body sú:
- Overuje, či sú komponenty systému správne nainštalované na určený hardvér.
- Potvrdzuje, že navigácia na novom počítači aktualizuje existujúcu inštaláciu a staršie verzie.
- Potvrdzuje, že s nedostatkom miesta na disku nedochádza k neprijateľnému správaniu.
Testovanie dokumentácie:
Vyhodnocuje dokumenty a ďalšie užívateľské príručky.
Medzi kľúčové body patrí:
- Potvrdzuje, že uvedené dokumenty sú v produkte k dispozícii.
- Validuje všetky užívateľské príručky, nastavuje pokyny, číta ma súbory, poznámky k vydaniu a online pomoc.
Testovanie zlyhania:
Testovanie pri zlyhaní sa vykonáva s cieľom overiť, či je systém v prípade zlyhania systému dostatočne schopný na spracovanie ďalších zdrojov, ako sú napríklad servery.
Aby sa zabránilo takejto situácii, hrá veľkú úlohu testovanie zálohovania. Celý proces spočíva v vytvorení záložného systému. Ak je k dispozícii zálohovanie, pomôže to získať systém späť.
Testovanie bezpečnosti:
Testovanie bezpečnosti robí sa tak, aby sa zabezpečilo, že aplikácia nebude mať medzery, ktoré by mohli viesť k akejkoľvek strate údajov alebo hrozbám. Je to jeden z dôležitých aspektov nefunkčného testovania a ak sa nevykoná správne, môže viesť k bezpečnostným hrozbám.
Zahŕňa testovanie autentifikácie, autorizácie, integrity a dostupnosti.
Testovanie škálovateľnosti:
Vykonáva sa testovanie škálovateľnosti, aby sa overilo, či je aplikácia schopná zvládnuť zvýšený prenos, počet transakcií, objem dát atď. Systém by mal fungovať podľa očakávania, keď sa vykoná objem dát alebo zmena veľkosti údajov.
Testovanie zhody:
Vykonáva sa testovanie zhody na overenie, či sa dodržiavajú definované normy alebo nie. Vykonávajú sa audity na overenie toho istého.
Pre Príklad , Audity sa vykonávajú s cieľom overiť proces vytvárania testovacích prípadov / testovacích plánov a ich umiestňovania na zdieľané miesto so štandardným názvom, ktorý sa práve vykonáva alebo nie. V QC sa pri pomenovávaní testovacích prípadov dodržiava štandardný názov testovacieho prípadu alebo nie. Dokumentácia je úplná a schválená alebo nie.
Toto je niekoľko ukazovateľov, ktoré sú pri audite pokryté.
Testy vytrvalosti:
Testy vytrvalosti sa vykonáva na overenie správania systému pri dlhodobom zvyšovaní záťaže.
Nazýva sa tiež ako testovanie namočenia a testovanie kapacity. Pomáha overiť, či v systéme nedochádza k úniku pamäte. Testovanie odolnosti je podmnožinou testovania záťaže.
Testovanie lokalizácie:
Lokalizačné testovanie sa vykonáva na overenie aplikácie v rôznych jazykoch, t. j. v rôznych miestnych nastaveniach. Aplikácia by mala byť overená pre konkrétnu kultúru alebo miestne nastavenie. Hlavným zameraním je testovanie obsahu, GUI aplikácie.
Testovanie internacionalizácie:
Testovanie internacionalizácie je tiež známy ako testovanie i18n.
I18n predstavuje I - osemnásť písmen - N. Vykonáva sa na overenie, či aplikácia funguje podľa očakávaní vo všetkých jazykových nastaveniach. Overuje, či sa ľubovoľná funkčnosť alebo aplikácia sama nerozbije, t. J. Aplikácia by mala byť schopná zvládnuť všetky medzinárodné nastavenia.
Tiež overuje, či je aplikácia nainštalovaná bez akýchkoľvek problémov.
Testovanie spoľahlivosti:
Testovanie spoľahlivosti sa vykonáva s cieľom overiť, či je aplikácia spoľahlivá a či je testovaná konkrétnu dobu v definovanom prostredí. Aplikácia by mala zakaždým poskytnúť rovnaký výstup, aký sa od nej očakáva, až potom ju možno považovať za spoľahlivú.
Testovanie prenosnosti:
Testovanie prenosnosti sa vykonáva s cieľom overiť, či v prípade, že je softvér / aplikácia nainštalovaná v inom systéme alebo na inej platforme, mala by byť schopná bežať podľa očakávania, t. J. Kvôli zmene prostredia by nemala byť ovplyvnená žiadna funkčnosť.
Počas testovania je tiež potrebné testovať zmenu s hardvérovou konfiguráciou, ako je miesto na pevnom disku, procesor, a tiež s rôznymi operačnými systémami, aby sa zabezpečilo, že správne správanie a očakávaná funkčnosť aplikácie budú neporušené.
Základné testovanie:
Základné testovanie je tiež známe ako referenčné testovanie pretože vytvára základ pre každú novú aplikáciu, ktorá sa má testovať.
Napríklad: V prvej iterácii bol čas odozvy aplikácie 3 sekundy. Teraz to bolo nastavené ako štandard pre ďalšiu iteráciu a v nasledujúcej iterácii sa doba odozvy zmení na 2 sekundy. V zásade ide o overovací dokument, ktorý sa používa ako základ pre budúce referencie.
Testovanie účinnosti:
Testovanie účinnosti sa vykonáva s cieľom overiť, či aplikácia funguje efektívne a počet potrebných zdrojov, požadované nástroje, zložitosť, požiadavka zákazníka, požadované prostredie, čas, o aký projekt sa jedná, atď.
Toto sú niektoré z ukazovateľov, ktoré by pomohli definovať, ako efektívne by aplikácia fungovala, keby všetky uvažované parametre fungovali podľa očakávania.
Testovanie obnovy po katastrofe:
Toto testovanie sa vykonáva s cieľom overiť úspešnosť obnovy aplikácie alebo systému, ak dôjde ku kritickému zlyhaniu, a či je systém schopný obnoviť dáta a aplikáciu, alebo by sa systém dokázal ľahko vyrovnať a vrátiť sa tak, ako to fungovalo skôr, tj z operačný front.
Testovanie udržiavateľnosti:
Keď bude aplikácia / produkt zverejnená, existuje šanca, že sa problém objaví v živom prostredí, alebo môže zákazník chcieť vylepšenie pre aplikáciu, ktorá už je zverejnená.
V takom prípade je k dispozícii tím na testovanie údržby, ktorý otestuje vyššie uvedené scenáre. Po spustení aplikácie bude stále potrebné vykonať údržbu, na ktorej pracuje tím pre testovanie údržby.
Nefunkčné testovacie nástroje
Na trhu existuje niekoľko nástrojov na testovanie výkonu (zaťaženie a stres).
Niekoľko z nich je uvedených nižšie:
- JMeter
- Nakladač
- Loadrunner
- Loadstorm
- Neoload
- Predpoveď
- Načítanie dokončené
- Stresový nástroj webového servera
- WebLoad Professional
- Loadtracer
- vPerformer
Vykonáva sa nefunkčné testovanie vždy bez dokumentácie a testovacích prípadov? Prečo?
„Vždy nás učia, ako písať funkčné testovacie prípady. Prečo? Vykonáva sa „nefunkčné testovanie“ bez dokumentácie (inými slovami ad hoc) alebo ide o samostatný proces, ktorému je oveľa ťažšie porozumieť? Ako sú napísané testovacie prípady pre rôzne druhy testovania, ktoré sa vyskytujú v aplikácii? “
Toto je jedna z najoriginálnejších, najosobitejších a najbežnejších otázok, ktoré mi boli v poslednom čase kladené. Poďme nájsť odpoveď.
Ako to, že nikdy nebudeme vidieť a trénovať písanie nefunkčných testovacích prípadov?
Začnime tým, čo vieme, a ako vždy praktickým scenárom.
Príklad: Nasledujú kroky, ktoré je potrebné vykonať v aplikácii Online bankovníctvo, aby sa uskutočnil prevod. Použime to ako náš referenčný test.
- Prihláste sa na stránku.
- Vyberte bankový účet.
- Vyberte príjemcu platby (tento príjemca môže patriť do tej istej banky alebo do inej banky - záleží to na vašom výbere údajov, ktoré bude potrebné vykonať pri vykonaní tohto kroku. V každom prípade vyberte jedného z nich. Budeme tiež predpokladať, že príjemca platby je už pridaný.) .
- Zadajte sumu, ktorá sa má previesť (kladná hodnota, v rámci limitu, správny formát atď.).
- Kliknite na Prevod a skontrolujte, či je potvrdenie prijaté, zostatok na účte bol aktualizovaný a tak ďalej.
Toto je funkčný testovací prípad, je to tak?
V tej istej aplikácii, na tej istej stránke prevodov, povedzme, že predvádzame výkon Testovanie výkonu, bezpečnosti a použiteľnosti . Toto sú nefunkčné typy, je to tak?
Ako by sme napísali testovacie prípady?
# 1) Testovanie použiteľnosti Testovacie prípady
Testovanie použiteľnosti je žáner testovania softvéru, ktorý sa zaoberá používateľskou skúsenosťou. To sú niektoré z otázok, na ktoré sa snažíme odpovedať.
- Aké ľahké je použitie aplikácie?
- Aká spokojná je skúsenosť s používaním systému?
- Ak nie je to hneď také známe, aké ľahké je naučiť sa to?
Viac informácií nájdete tu: Sprievodca testovaním použiteľnosti
Ako by používateľ určil odpovede na vyššie uvedené otázky v rámci testovania použiteľnosti?
Používateľ by vykonal úplne rovnaké kroky ako v prípade funkčného testu. Mám pravdu?
# 2) Testovanie výkonu Testovacie prípady
Testovanie výkonu obsahuje niekoľko variácií, ale vo svojej podstate sa používa na získanie štatistík o systéme, jeho využití zdrojov, času odozvy, spotreby siete atď. V rôznych bodoch zaťaženia.
Vyskúšajte naše Návody na testovanie výkonu vedieť o tom viac.
Ak by som teraz mal otestovať výkonnosť transakcie, mal by som 10, 20, 30, 100 ... 1 000 ... atď., Aby používatelia vykonali operáciu prevodu súčasne alebo postupne podľa toho, na čo chcem zamerať a zhromaždiť údaje.
Aké kroky by vykonal každý používateľ, aby mohol použiť prenos, keď prebieha test výkonu?
Rovnaké presné kroky ako pri funkčnej skúške, je to tak?
# 3) Testovacie prípady zabezpečenia
Testovanie bezpečnosti je odvetvie kontroly kvality, ktoré pomáha zaistiť odolnosť softvérových systémov pred hackermi. Identifikuje zraniteľné miesta (potenciálne problémové oblasti v softvérovom systéme), zneužije ich pomocou techniky prieniku alebo bieleho klobúka a keď sa nájdu medzery, je sa s nimi ďalej pracovať.
Kedy chcem skontrolovať, či sú prevody odolné voči hackerom a či sú správne nasmerované na zamýšľaných príjemcov a či v celom procese nie sú čierne miesta? Prenos by som vykonal, kým bude paralelne prebiehať proces monitorovania bezpečnostných únikov.
Preto v skutočnosti vykonávam úplne rovnaké kroky, aké by som za normálnych okolností urobil v prípade funkčného testovacieho prípadu.
Myslím, že máme dosť na to, aby sme dokázali, že kroky vo všetkých situáciách sú rovnaké. Odlišná je metóda a zámer, ktorý stojí za procesom.
Pozrime sa na porovnanie:
Typ testovania | SZO? | Prečo? Zámer |
---|---|---|
Funkčné testovanie | QA testery | Presnosť |
Účinnosť | ||
Obchodná použiteľnosť | ||
Použiteľnosť | Testéri QA alebo používatelia v reálnom čase | Jednoduchosť použitia |
Ľahkosť učenia | ||
Účinnosť | ||
Využitie siete atď. | ||
Bezpečnosť | Skenovacie nástroje a ďalší monitorovací systém špecializovanými bezpečnostnými expertmi | Hackujte bezpečne |
Ochrana totožnosti príjemcu platby a platiteľa atď. |
Je zaujímavé poznamenať, že bez ohľadu na to, akú formu testovania chceme vykonať, všetky kroky sú rovnaké .
Skutočný rozdiel je v tom, že:
- Kto vykonáva tieto kroky?
- Aký je zámer alebo inými slovami to, čo sa snažím dosiahnuť prostredníctvom tohto testu?
- Použité nástroje a techniky.
Keď sa vrátime k našej otázke, prečo sa nikdy nenaučíme písať nefunkčné testovacie prípady so všetkými podrobnými krokmi, ktoré sú pri tom?
Je to pretože ,v ich jadre sú testovacie kroky týkajúce sa variácie typov testu na určitej funkcii rovnaké, funkčné alebo nie. Je to zámer, ktorý robí rozdiel, a možno aj metóda.
Záver
Pred vykonaním nefunkčného testovania je nevyhnutné správne naplánovať stratégiu testovania, aby sa zabezpečilo správne testovanie. Na trhu sú k dispozícii rôzne nástroje na vykonávanie tohto typu testov, napríklad Load Runner, RPT atď.
Toto testovanie hrá hlavnú úlohu v úspešnosti aplikácie a pri budovaní dobrého vzťahu so zákazníkom, a preto by nemalo byť zanedbávané. Toto je jedna z dôležitých častí testovania softvéru a testovanie sa bez toho nebude dať považovať za úplné.
Do plánu testovania môžeme zahrnúť podrobnosti nefunkčného testovania alebo preň vytvoriť samostatnú stratégiu. V obidvoch prípadoch je cieľom zabezpečiť správne pokrytie nefunkčných aspektov softvéru.
Dúfame, že tento proces hlbokého ponorenia sa do tejto témy bol pre vás rovnako zábavný, ako bol predstavený vám všetkým. Boli by sme radi, keby ste počuli vašu spätnú väzbu a názory na túto tému.
Ako zvládate nefunkčné testovanie vo svojich tímoch? A ako vždy, dajte nám vedieť, či súhlasíte, či nesúhlasíte, alebo máte čo dodať k tomu, čo sa tu deje.
Odporúčané čítanie
- Funkčné testovanie vs. Nefunkčné testovanie
- Alfa testovanie a beta testovanie (kompletný sprievodca)
- Sprievodca testovaním bezpečnosti webových aplikácií
- Kompletný sprievodca funkčným testovaním s jeho typmi a príkladom
- Kompletný sprievodca zostavením Verification Testing (BVT Testing)
- Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
- Sprievodca pre začiatočníkov k testovaniu penetrácie webových aplikácií
- Load Testing Kompletný sprievodca pre začiatočníkov