complete non functional testing guide
Cjelovit vodič za nefunkcionalno testiranje: njegova svrha, vrste, alat, slučajevi ispitivanja s primjerima
Što je nefunkcionalno testiranje?
Nefunkcionalno testiranje vrši se radi provjere nefunkcionalnih zahtjeva aplikacije poput performansi, upotrebljivosti itd.
Provjerava je li ponašanje sustava prema zahtjevu ili ne. Obuhvaća sve aspekte koji nisu obuhvaćeni funkcionalno ispitivanje . U našem svakodnevnom testiranju puno se pozornosti posvećuje funkcionalnom ispitivanju i funkcionalnim zahtjevima.
Klijenti su također zainteresirani za ispunjavanje funkcionalnih zahtjeva koji su izravno povezani s funkcionalnošću aplikacije. Ali u stvarnoj fazi, tj. Kada ste funkcionalno testirani, softver dolazi na tržište i koriste ga stvarni krajnji korisnici, a postoje šanse da se suoči s nekim problemima vezanim uz izvedbu.
Ti se problemi ne odnose na funkcionalnost sustava, ali mogu negativno utjecati na korisničko iskustvo. Stoga je važno da se softver ili aplikacija testira i na nefunkcionalne zahtjeve kako bi se izbjeglo negativno korisničko iskustvo.
Testiranje se široko klasificira u dvije vrste:
- Ispitivanje funkcionalnosti
- Nefunkcionalno ispitivanje
Što ćete naučiti:
- Važnost
- Svrha
- Primjer
- Prednosti
- Kako uhvatiti nefunkcionalne zahtjeve?
- Razlika u funkcionalnim i nefunkcionalnim zahtjevima
- Je li ovo ispitivanje crne ili bijele kutije?
- Kontrolni popis nefunkcionalnih slučajeva
- Pristupni dokument
- Nefunkcionalne vrste ispitivanja
- Nefunkcionalni alati za ispitivanje
- Zaključak
- Preporučena literatura
Važnost
Ovom testiranju nedostajalo je dužne pažnje s obzirom da ne utječe na funkcionalnost sustava.
Nefunkcionalnim zahtjevima također se nije pridavala odgovarajuća pažnja u ranijim ispitnim ciklusima. Međutim, ovo se sada promijenilo. Nefunkcionalni testovi sada su najvažniji jer uzimaju u obzir sve probleme performansi i sigurnosti ovih dana.
Ovo testiranje ima veći utjecaj na aplikacije kada je u pitanju izvedba aplikacije pod velikim korisničkim prometom. Ovo testiranje osigurava da je vaša aplikacija stabilna i sposobna podnijeti opterećenje pod ekstremnim uvjetima.
Kao što i samo ime govori, ovo se ispitivanje koncentrira na nefunkcionalni aspekt aplikacije. Pa koji su nefunkcionalni aspekti? Ili bih trebao reći koje su značajke koje nisu povezane s funkcionalnošću aplikacije?
Pa, evo odgovora na one:
- Kako aplikacija funkcionira u normalnim okolnostima?
- Kako se aplikacija ponaša kad se istovremeno prijavljuje previše korisnika?
- Može li aplikacija podnijeti stres?
- Koliko je sigurna aplikacija?
- Može li se aplikacija oporaviti od bilo koje katastrofe?
- Može li se aplikacija ponašati na isti način u drugom okruženju ili OS-u?
- Koliko je jednostavno prenositi aplikaciju u drugi sustav?
- Jesu li dokumenti / korisnički priručnici priloženi uz aplikaciju lako razumljivi?
Popis se nastavlja. Ali poanta je ovdje u tome - ne pridonose li ove značajke kvaliteti aplikacije? Odgovor je DA. Te su značajke jednako važne.
Zamislite da aplikacija u potpunosti ispunjava sve korisničke zahtjeve, ali neki neovlašteni korisnik lako ide i probija podatke koje je korisnik unio u aplikaciju ili aplikacija umre kad se prenese više od 5BB bilo koje datoteke. Pa biste li rekli da je aplikacija kvalitetna? Očito nije u redu !!
Svrha
Jedina svrha ove vrste testiranja je osigurati da se nefunkcionalni aspekti aplikacije testiraju i da aplikacija dobro funkcionira u kontekstu iste.
Svrha je pokriti ispitivanje svih karakteristika aplikacije koje pomažu u pružanju aplikacije koja ispunjava poslovna očekivanja.
Primjer
Ovo je važan tip ispitivanja.
Funkcionalno testiranje testira funkcionalnost aplikacije i osigurava da radi kako se očekuje, ali nefunkcionalno testiranje osigurava da aplikacija radi dovoljno dobro da udovolji poslovnim očekivanjima.
Da bismo razumjeli njegovu važnost, uzmimo jednostavan primjer:
Razvijena je aplikacija koja je u potpunosti testirana na funkcionalnost, ali se na njoj ne provodi nefunkcionalno testiranje.
U međuvremenu, kada aplikacija krene s radom, to bi moglo rezultirati kritičnim ili velikim problemima, poput povećanja opterećenja aplikacije, postaje presporo i treba joj puno vremena da se otvori.
Vrijeme odziva može se povećati ili kada se opterećenje poveća u određenoj mjeri, aplikacija se može srušiti. To pokazuje koliko je važno testirati nefunkcionalne aspekte aplikacije.
Prednosti
Slijede neke od prednosti nefunkcionalnog testa:
- Obuhvaća ispitivanja koja se ne mogu obuhvatiti funkcionalnim ispitivanjem.
- Osigurava da aplikacija radi učinkovito i dovoljno pouzdano.
- Osigurava sigurnost aplikacije.
Kako uhvatiti nefunkcionalne zahtjeve?
Dok provodimo testiranje, fokus je uglavnom na funkcionalnom testiranju koje testira funkcionalnost proizvoda. No, nefunkcionalno ispitivanje jednako je važno kao i funkcionalno ispitivanje i njegov bi se zahtjev trebao uzeti u obzir već od samog početka proizvoda.
Nefunkcionalni zahtjevi koriste se za provođenje nefunkcionalnog ispitivanja. Ti zahtjevi uključuju učinak izvedbe koji se očekuje od aplikacije ili softvera koji se ispituje. To u osnovi uključuje vrijeme potrebno softveru za rad određenog sustava.
Nefunkcionalni zahtjevi također bilježe ponašanje kada velik broj ljudi istodobno koristi softver. Većinu vremena doživljava se da su poslužitelji zauzeti ili nedostupni zbog velikog opterećenja (tj. Više ljudi ga istovremeno koristi). Rezervacija željezničkih karata putem interneta može biti najbolja primjer takve situacije.
Stoga će pravilno dokumentiranje nefunkcionalnog zahtjeva i pravilno provođenje ispitivanja osigurati visoko zadovoljstvo u pogledu upotrebljivosti potencijalnih kupaca.
Iako ovo testiranje nema izravan poslovni utjecaj na funkcionalnost sustava, ono može u većoj mjeri povećati korisničko iskustvo i jednostavnost za upotrebu, što će zauzvrat imati veći utjecaj na kvalitetu softvera.
Primjer:
Razmotrite isti primjer stranice za prijavu na Facebook. U ovom je slučaju opseg nefunkcionalnog testiranja zabilježiti vrijeme potrebno sustavu za prijavu na Facebook nakon unosa valjanih vjerodajnica.
Također, može se testirati kada se (recimo 100) korisnici istovremeno prijave, koliko vremena treba za prijavu korisnika na Facebook.
To osigurava da sustav može podnijeti opterećenje i promet što zauzvrat ima dobro korisničko iskustvo.
Agilan, nefunkcionalni zahtjev treba uhvatiti pomoću ulaza.
Nefunkcionalni zahtjev treba obuhvatiti kao:
- Korisničke / tehničke priče
- U kriterijima prihvaćanja
- U Artefaktu
9
# 1) Korisničke / tehničke priče
Nefunkcionalni zahtjev može se uhvatiti pomoću korisničke priče ili tehničke priče. Snimanje nefunkcionalnih zahtjeva kao korisničke priče isto je kao i bilježenje bilo kojeg drugog zahtjeva. Jedina razlika u korisničkoj i tehničkoj priči je ta što korisnička priča zahtijeva raspravu i ima vidljivost.
# 2) Kriteriji prihvaćanja
Kriteriji prihvatljivosti je točka koja je definirana za prihvaćanje proizvoda od strane kupca, tj. da bi se proizvod prihvatio do definiranih točaka treba biti u stanju prolaska.
Nefunkcionalni zahtjev trebao bi biti uključen u kriterije prihvaćanja, ali ponekad nije moguće testirati nefunkcionalne zahtjeve sa svakom pričom, tj. Sa svakom iteracijom. Stoga zahtjeve treba dodati ili testirati samo s odgovarajućom iteracijom.
# 3) U Artefaktima
Za nefunkcionalne zahtjeve treba pripremiti zasebni artefakt, što bi zauzvrat pomoglo da se dobije bolja predodžba o tome što treba testirati i kako se to može učiniti u iteracijama.
Razlika u funkcionalnim i nefunkcionalnim zahtjevima
Postoji nekoliko razlika između funkcionalnih i nefunkcionalnih zahtjeva, a nekoliko ih je navedeno u nastavku:
S.Ne. | Funkcionalni zahtjev | Nefunkcionalni zahtjev |
---|---|---|
Izvođenje | Tester izvedbe putem alata koji operaciju tretira kao transakciju koju izvodi određeni broj istovremenih korisnika dok tester analizira svu logistiku | Vrijeme odziva |
jedan | Funkcionalni zahtjev temelji se na kupcu. | Nefunkcionalni zahtjev temelji se na programerima i tehničkom znanju tima. |
dva | Funkcionalni zahtjev određuje koju funkcionalnost treba uzeti u obzir, tj. Što treba testirati. | Nefunkcionalni zahtjevi određuju kako ga treba testirati. |
3 | Ispitivanje funkcionalnosti provodi se prije nego što aplikacija krene uživo. | Nefunkcionalni zahtjevi uključuju ispitivanje održavanja, ispitivanje dokumentacije koje nisu potrebne dok traje izvođenje, ali jedan je program pokrenut. |
4 | Poznat je samo kao funkcionalni zahtjev. | Poznat i kao zahtjevi kvalitete. |
5 | Plan provedbe funkcionalnih zahtjeva definiran je u projektnom dokumentu sustava. | Plan provedbe za nefunkcionalne zahtjeve definiran je u arhitekturi sustava. |
6 | Funkcionalni zahtjev uključuje ispitivanje tehničke funkcionalnosti sustava. | Nefunkcionalni zahtjev uključuje kvalitete poput sigurnosti, upotrebljivosti itd. |
Daljnje čitanje => Razlike između funkcionalnog i nefunkcionalnog ispitivanja
Je li ovo ispitivanje crne ili bijele kutije?
Nefunkcionalni test spada pod ispitivanje crne kutije tehnika.
Ova tehnika nije ograničena samo na testiranje funkcionalnosti, već se također može koristiti za testiranje nefunkcionalnih zahtjeva, kao i performansi, upotrebljivosti itd. Tehnika testiranja crne kutije ne zahtijeva nikakvo znanje o unutarnjem sustavu, tj. Ne zahtijeva znanje koda ispitivaču.
Kontrolni popis nefunkcionalnih slučajeva
Kontrolni popis koristi se kako bi se osiguralo da niti jedan važan aspekt ne ostane bez testiranja.
Kontrolni se popis obično koristi kada nema vremena za dokumentaciju, a proizvod treba testirati ili kada postoji vremensko ograničenje, kontrolni se popis može koristiti kako bi se osiguralo da su obuhvaćeni svi važni aspekti.
Da vidimoprimjerkontrolnog popisa za testiranje performansi, sigurnosti i dokumentacije.
Kontrolni popis za ispitivanje performansi
- Vrijeme odziva aplikacije treba provjeriti, tj. koliko vremena treba za učitavanje aplikacije, bilo koji ulaz dat aplikaciji daje izlaz za koliko vremena, osvježavanje preglednika itd.
- Propusnost treba provjeriti broj transakcija dovršenih tijekom testa učitavanja.
- Okoliš postavljeno treba biti isto kao i živo okruženje, inače rezultati ne bi bili jednaki.
- Vrijeme procesa - Obradite aktivnosti poput uvoza i izvoza excela, bilo koji izračun u aplikaciji treba testirati.
- Interoperabilnost treba provjeriti, tj. softver bi trebao biti u mogućnosti surađivati s drugim softverom ili sustavima.
- ETL treba provjeriti vrijeme, tj. vrijeme potrebno za izdvajanje, pretvaranje i učitavanje podataka iz jedne baze podataka u drugu.
- Povećavanje opterećenja na prijavi treba provjeriti.
Kontrolni popis za sigurnosno testiranje
- Ovjera: Samo autentični korisnik trebao bi se moći prijaviti.
- Ovlašteno: Korisnik bi trebao biti u mogućnosti prijaviti se samo na one module za koje je ovlašten ili za koje je korisniku omogućen pristup.
- Zaporka: Potrebno je potvrditi zahtjev za lozinkom, tj. Lozinka treba odgovarati onome kako zahtjev definira tj. Duljinu, posebne znakove, brojeve itd.
- Pauza: Ako je aplikacija neaktivna, tada bi trebalo isteknuti u određenom vremenu.
- Sigurnosna kopija podataka: Sigurnosne kopije podataka treba poduzeti u određeno vrijeme i kopirati ih na sigurno mjesto.
- Interne poveznice web aplikaciji ne bi trebao biti dostupan ako se nalazi izravno u pregledniku.
- Sva komunikacija treba biti šifrirana.
Kontrolni popis za ispitivanje dokumentacije
- Dokumentacija za korisnike i sustav.
- Dokumenti u svrhu obuke.
Pristupni dokument
Izradite dokument specifičnog pristupa za fazu ispitivanja izvedbe pročišćavanjem cjelokupne strategije ispitivanja. Ovaj pristup testiranju vodi u planiranju i izvršavanju svih zadataka ispitivanja izvedbe.
uloga poslovnog analitičara u okretnom obračunu
- Opseg ispitivanja
- Ispitne metrike
- Alati za ispitivanje
- Ključni datumi i rezultati
Opseg ispitivanja
Provedite testiranje izvedbe iz različitih perspektiva, poput korisničkih performansi, poslovnih procesa, stabilnosti sustava, potrošnje resursa itd. Vrste ispitivanja performansi koje treba izvršiti razmotrene su u gornjem odjeljku članka (poput testa opterećenja, testa naprezanja itd.)
Ispitne metrike
Pristup testiranju pročišćava mjerne podatke za mjerenje i izvještavanje tijekom testiranja, kao što su:
- Vrijeme odziva (na mreži)
- Prozor serije (serija)
- Propusnost ( Na primjer , broj transakcija u jedinici vremena)
- Iskorištenje ( Na primjer , postotak korištenih resursa)
Alati za ispitivanje
Testiranje izvedbe uglavnom zahtijeva upotrebu odgovarajućih alata:
- Alati za generiranje tereta
- Alati za nadzor izvedbe
- Alati za analizu izvedbe
- Alati za profiliranje aplikacija
- Alati za oblaganje podnožja.
Ključni datumi i rezultati
Dokument o pristupu ispitivanju izvedbe trebao bi opisivati sljedeće:
- Datum i vrijeme svakog provođenja testa izvedbe.
- Vrste testova i kombinacija funkcionalnosti koje se uključuju u svako provođenje ispitivanja izvedbe.
- Datumi završetka testa izvedbe.
Nefunkcionalne vrste ispitivanja
Sljedeća slika prikazuje vrste nefunkcionalnih ispitivanja:
Ispitivanje izvedbe:
Procjenjuje ukupne performanse sustava .
Ključni elementi su sljedeći:
- Potvrđuje da sustav zadovoljava očekivano vrijeme odziva.
- Ocjenjuje da značajni elementi aplikacije ispunjavaju željeno vrijeme odziva.
- Može se provesti i kao dio integracijskog testiranja i testiranja sustava.
Ispitivanje opterećenja:
Procjenjuje jesu li performanse sustava očekivane u normalnim i očekivanim uvjetima.
Ključne točke su:
- Potvrđuje da sustav radi prema očekivanjima kada istodobni korisnici pristupe aplikaciji i dobiju očekivano vrijeme odziva.
- Ovaj se test ponavlja s više korisnika kako bi se dobilo vrijeme odziva i propusnost.
- U vrijeme testiranja baza podataka trebala bi biti realna.
- Test bi se trebao provesti na namjenskom poslužitelju koji stimulira stvarno okruženje.
Ispitivanje naprezanja:
Procjenjuje jesu li performanse sustava očekivane kada nema dovoljno resursa.
Ključne točke su:
- Testirajte na malo memorije ili malo prostora na disku na klijentima / poslužiteljima koji otkrivaju nedostatke koji se u normalnim uvjetima ne mogu pronaći.
- Više korisnika izvodi iste transakcije na istim podacima.
- Više je klijenata povezano s poslužiteljima s različitim radnim opterećenjima.
- Smanjite vrijeme razmišljanja na „Nula“ kako biste servere stresirali na njihov maksimalan stres.
Vrijeme razmišljanja: Baš kao i vremenski interval između unosa vašeg korisnika i lozinke.
Ispitivanje volumena:
Procjenjuje ponašanje softvera kada je u pitanju velika količina podataka.
Ključne točke su:
- Kad je softver podložan velikim količinama podataka, provjerava ograničenje u slučaju kada softver zakaže.
- Izrađuje se maksimalna veličina baze podataka i više klijenata postavlja bazu podataka ili izrađuje veće izvješće.
- Primjer - Ako aplikacija obrađuje bazu podataka kako bi stvorila izvješće, ispitivanje volumena bilo bi korištenje velikog skupa rezultata i provjera je li izvješće ispravno ispisano.
Ispitivanje upotrebljivosti:
Procjenjuje sustav za ljudsku upotrebu ili provjerava je li prikladan za upotrebu.
Ključne točke su:
- Je li rezultat točan i smislen i je li isti kao što se očekivalo prema poslu?
- Jesu li pogreške ispravno dijagnosticirane?
- Je li GUI točan i u skladu sa standardom?
- Je li aplikacija jednostavna za upotrebu?
Testiranje korisničkog sučelja:
Procjenjuje GUI.
Ključne točke su:
- GUI bi trebao pružiti pomoć i savjete kako bi ga olakšao za upotrebu.
- Dosljedan svom izgledu?
- Podaci se pravilno prelaze s jedne stranice na drugu?
- GUI ne bi smio živcirati korisnika ili biti teško razumljiv.
Ispitivanje kompatibilnosti:
Procjenjuje da je aplikacija kompatibilna s ostalim hardverom / softverom s minimalnom i maksimalnom konfiguracijom.
Ključne točke su:
- Testirajte svaki hardver s minimalnom i maksimalnom konfiguracijom.
- Testirajte s različitim preglednicima.
Test slučajevi su isti kao oni koji su izvršeni tijekom funkcionalnog ispitivanja. - U slučaju da je broj hardvera i softvera previše, možemo koristiti tehnike OATS-a kako bismo došli do testnih slučajeva kako bismo imali maksimalno pokriće.
Ispitivanje oporavka:
Procjenjuje da se aplikacija elegantno završava u slučaju bilo kakvog kvara i da se podaci odgovarajuće oporavljaju od bilo kakvih kvarova hardvera i softvera.
Ispitivanja nisu ograničena na dolje navedene točke:
- Prekid napajanja klijentu tijekom obavljanja CURD aktivnosti.
- Nevažeći pokazivači baze podataka i ključevi.
- Proces baze podataka se prekida ili prijevremeno prekida.
- Pokazivači, polja i ključevi baze podataka oštećeni su ručno i izravno unutar baze podataka.
- Fizički prekinite komunikaciju, isključite napajanje, isključite usmjerivače i mrežne poslužitelje.
Ispitivanje nestabilnosti:
Procjenjuje i potvrđuje da li se softver ispravno instalira i deinstalira.
implementacija binarnog stabla u izvornom kodu c ++
Ključne točke su:
- Potvrđuje da su komponente sustava ispravno instalirane na naznačeni hardver.
- Potvrđuje da navigacija na novom stroju ažurira postojeću instalaciju i starije verzije.
- Potvrđuje da s nedovoljnim prostorom na disku nema neprihvatljivog ponašanja.
Ispitivanje dokumentacije:
Procjenjuje dokumente i druge korisničke upute.
Ključne točke uključuju:
- Potvrđuje da su navedeni dokumenti dostupni u proizvodu.
- Potvrđuje sve korisničke vodiče, postavlja upute, čita mi datoteke, bilješke o izdanju i internetsku pomoć.
Ispitivanje otkaza:
Testiranje preusmjeravanja vrši se kako bi se potvrdilo da je u slučaju kvara sustava sustav dovoljno sposoban za obradu dodatnih resursa poput poslužitelja.
Kako bi se spriječila takva situacija, testiranje sigurnosne kopije igra veliku ulogu. Stvaranje sigurnosnog sustava je ono što je proces. Ako je sigurnosna kopija dostupna, onda pomaže u povratku sustava.
Ispitivanje sigurnosti:
Ispitivanje sigurnosti se radi kako bi se osiguralo da aplikacija nema rupe koje bi mogle dovesti do gubitka podataka ili prijetnji. To je jedan od važnih aspekata nefunkcionalnog testiranja i ako se ne izvede pravilno, može dovesti do sigurnosnih prijetnji.
Uključuje testiranje provjere autentičnosti, autorizacije, integriteta i dostupnosti.
Ispitivanje skalabilnosti:
Testiranje skalabilnosti provodi se kako bi se provjerilo je li aplikacija dovoljno sposobna nositi se s povećanim prometom, brojem transakcija, količinom podataka itd. Sustav bi trebao raditi prema očekivanjima kada se izvrši obujam podataka ili promjena veličine podataka.
Ispitivanje sukladnosti:
Ispitivanje sukladnosti vrši se kako bi se provjerilo slijede li se definirani standardi ili ne. Revizije se rade kako bi se potvrdilo isto.
Za Primjer , Revizije se rade kako bi se verificirao postupak stvaranja test slučajeva / planova ispitivanja i njihovo postavljanje na zajedničko mjesto sa standardnim nazivom koji se radi ili ne. U QC, dok se imenuju test slučajevi, slijedi se standardni naziv test slučaja ili ne. Dokumentacija je cjelovita i odobrena ili ne.
Ovo je nekoliko uputa koje su obuhvaćene tijekom revizije.
Ispitivanje izdržljivosti:
Ispitivanje izdržljivosti vrši se radi provjere ponašanja sustava kada se opterećenje poveća u određenoj mjeri dulje vrijeme.
Također se naziva i ispitivanje namočenjem i ispitivanje kapaciteta. Pomaže u provjeri postoji li curenje memorije u sustavu. Ispitivanje izdržljivosti podskup je ispitivanja opterećenja.
Ispitivanje lokalizacije:
Ispitivanje lokalizacije vrši se radi provjere aplikacije na različitim jezicima, tj. različitim lokalitetima. Prijava bi trebala biti verificirana za određenu kulturu ili lokalitet. Glavni fokus je testirati sadržaj, GUI aplikacije.
Ispitivanje internacionalizacije:
Ispitivanje internacionalizacije je također poznato kao i18n testiranje.
I18n predstavlja I - osamnaest slova - N. To se radi kako bi se provjerilo radi li aplikacija kako se očekuje u svim postavkama jezika. Provjerava da se bilo koja funkcionalnost ili sama aplikacija ne pokvari, tj. Aplikacija bi trebala biti sposobna za obradu svih međunarodnih postavki.
Također provjerava da li se aplikacija instalira bez ikakvih problema.
Ispitivanje pouzdanosti:
Ispitivanje pouzdanosti vrši se kako bi se provjerilo je li aplikacija pouzdana i testira li se određeno vrijeme u definiranom okruženju. Aplikacija bi svaki put trebala dati isti rezultat kao što se očekivalo, samo se tada može smatrati pouzdanim.
Ispitivanje prenosivosti:
Testiranje prenosivosti vrši se kako bi se provjerilo bi li u slučaju da je softver / aplikacija instaliran na drugom sustavu ili na drugoj platformi trebao moći raditi po očekivanjima, tj. To ne bi trebalo utjecati na funkcionalnost zbog promjene u okruženju.
Tijekom testiranja, također je potrebno testirati promjenu s hardverskom konfiguracijom, poput prostora na tvrdom disku, procesora, kao i s različitim operativnim sustavima kako bi se osiguralo ispravno ponašanje i očekivana funkcionalnost aplikacije.
Početno ispitivanje:
Početno ispitivanje je također poznato kao benchmark ispitivanje jer stvara osnovu za bilo koji novi program koji će se testirati.
Na primjer: U prvoj je iteraciji vrijeme odziva aplikacije bilo 3 sekunde. Sada je ovo postavljeno kao mjerilo za sljedeću iteraciju, a u sljedećoj iteraciji vrijeme odziva mijenja se na 2 sekunde. To je u osnovi dokument o valjanosti koji se koristi kao osnova za buduće reference.
Ispitivanje učinkovitosti:
Ispitivanje učinkovitosti vrši se kako bi se provjerilo radi li aplikacija učinkovito i broj potrebnih resursa, potrebnih alata, složenosti, zahtjeva kupaca, potrebnog okruženja, vremena, vrste projekta itd.
Ovo su neki od uputa koji bi pomogli definirati koliko će učinkovito aplikacija raditi ako svi razmatrani parametri rade kako se očekuje.
Ispitivanje oporavka od katastrofe:
Ovo se ispitivanje vrši kako bi se provjerila stopa uspješnosti oporavka aplikacije ili sustava ako se dogodi bilo kakav kritični kvar i je li sustav u stanju vratiti podatke i aplikaciju ili se sustav mogao lako nositi i vratiti se na način na koji je radio ranije, tj. Od operativni front.
Ispitivanje održavanja:
Jednom kada aplikacija / proizvod krene uživo, tada postoji mogućnost da se problem pojavi u živom okruženju ili će kupac možda htjeti poboljšati aplikaciju koja je već aktivna.
U ovom slučaju tim za testiranje održavanja dostupan je za testiranje gore spomenutih scenarija. Kad aplikacija počne raditi, i dalje joj je potrebno održavanje za koje radi tim za testiranje održavanja.
Nefunkcionalni alati za ispitivanje
Na tržištu je dostupno nekoliko alata za ispitivanje performansi (opterećenja i naprezanja).
Nekoliko ih je navedeno u nastavku:
- JMeter
- Loadster
- Loadrunner
- Loadstorm
- Neoload
- Prognoza
- Učitavanje završeno
- Alat za stres web poslužitelja
- WebLoad Professional
- Loadtracer
- vPerformer
Da li se nefunkcionalno testiranje uvijek provodi bez dokumentacije i test slučajeva? Zašto?
“Uvijek nas uče kako pisati funkcionalne testove. Zašto je to? Provodi li se 'nefunkcionalno ispitivanje' bez dokumentacije (drugim riječima, ad hoc) ili je to zaseban postupak koji je puno teže razumjeti? Kako se pišu slučajevi ispitivanja za različite vrste ispitivanja koja se događaju u aplikaciji? '
Ovo je jedno od najoriginalnijih, najosebujnijih i najneobičnijih pitanja koja su mi postavljena u posljednje vrijeme. Pronađimo odgovor.
Kako to da nikad ne vidimo i vježbamo u pisanju nefunkcionalnih test slučajeva?
Počnimo s onim što znamo i kao i uvijek sa praktičnim scenarijem.
Primjer: Slijede koraci koje treba izvršiti na aplikaciji za mrežno bankarstvo kako bi se izvršio prijenos. Iskoristimo to kao test za referencu.
- Prijavite se na web mjesto.
- Odaberite bankovni račun.
- Odaberite primatelja uplate (ovaj primatelj uplate mogao bi pripadati istoj ili nekoj drugoj banci - to ovisi o vašem izboru podataka za izvršenje ovog koraka. U svakom slučaju odaberite jedan. Također, pretpostavit ćemo da je primatelj uplate već dodan.) .
- Unesite iznos koji želite prenijeti (pozitivna vrijednost, unutar ograničenja, ispravan format itd.).
- Kliknite Prijenos i provjerite je li primljena potvrda, je li stanje računa ažurirano i sve to.
Ovo je funkcionalni test, zar ne?
Na istoj aplikaciji, na istoj stranici prijenosa recimo da nastupamo Ispitivanje performansi, sigurnosti i upotrebljivosti . To su nefunkcionalni tipovi, zar ne?
Kako bismo napisali test slučajeve?
# 1) Ispitni slučajevi upotrebljivosti
Testiranje upotrebljivosti žanr je softverskog testiranja koji se bavi korisničkim iskustvom. Ovo su neka od pitanja na koja pokušavamo odgovoriti.
- Koliko je jednostavno koristiti aplikaciju?
- Koliko je zadovoljavajuće iskustvo korištenja sustava?
- Ako ne odmah to poznato, koliko je jednostavno naučiti?
Više informacija o tome nalazi se ovdje: Vodič za ispitivanje upotrebljivosti
Kako bi korisnik odredio odgovore na gornja pitanja u kontekstu ispitivanja upotrebljivosti?
Korisnik bi izvršio potpuno iste korake kao u funkcionalnom testnom slučaju. Jesam li u pravu?
# 2) Ispitni testovi performansi
Postoji nekoliko varijacija testiranja performansi, ali u osnovi se koristi za dobivanje statistike o sustavu, iskorištenosti resursa, vremenu odziva, potrošnji mreže itd. Na različitim mjestima učitavanja.
Pogledajte naš Vodiči za ispitivanje izvedbe znati više o tome.
Sada, ako bih testirao izvedbu transakcije prijenosa, imao bih 10, 20, 30, 100 ... 1000 ... itd. Korisnici izvršavaju operaciju prijenosa istovremeno ili postupno, ovisno o tome na što želim ciljati i prikupljati podatke.
Koje korake bi svaki korisnik izvršio kako bi koristio prijenos dok je test izvedbe u tijeku?
Isti isti koraci kao i funkcionalni test, zar ne?
# 3) Ispitni slučajevi ispitivanja sigurnosti
Ispitivanje sigurnosti je grana osiguranja kvalitete koja pomaže da softverski sustavi budu zaštićeni od haka. Identificira ranjivosti (potencijalna problematična područja u softverskom sustavu), iskorištava ih penetracijom ili tehnikom testiranja bijelog šešira, a kada se pronađu rupe na njima, obrađuje se.
Kada želim provjeriti jesu li transferi otporni na hakove i jesu li usmjereni ispravno primatelja te da li u cijelom procesu nema crnih mrlja? Izvršio bih prijenos dok se paralelno odvija postupak praćenja curenja sigurnosti.
Stoga, u stvari, provodim potpuno iste korake koje bih inače radio u slučaju funkcionalnog test slučaja.
Pretpostavljam da imamo dovoljno da utvrdimo da su koraci u svim situacijama jednaki. Različita je metoda i namjera procesa.
Pogledajmo usporedni pogled:
Vrsta ispitivanja | Who? | Zašto? Namjera |
---|---|---|
Funkcionalno ispitivanje | QA testeri | Točnost |
Učinkovitost | ||
Poslovna primjenjivost | ||
Upotrebljivost | QA testeri ili korisnici u stvarnom vremenu | Jednostavnost korištenja |
Jednostavnost učenja | ||
Učinkovitost | ||
Korištenje mreže itd. | ||
Sigurnost | Alati za skeniranje i drugi nadzorni sustav od strane specijaliziranih sigurnosnih stručnjaka | Hack sigurno |
Primatelj uplate i zaštita identiteta obveznika itd. |
Ono što je zanimljivo primijetiti jest to bez obzira koji oblik testiranja želimo obaviti, svi su koraci isti .
Prava razlika je u tome što:
- Tko izvodi ove korake?
- Koja je namjera, odnosno drugim riječima što pokušavam postići ovim testom?
- Alati i tehnike koji se koriste.
Vraćajući se na naše pitanje, zašto nikada ne naučimo pisati nefunkcionalne ispitne slučajeve sa svim detaljnim koracima koji su u vezi s tim?
To je zato što ,u svojoj su osnovi koraci ispitivanja za varijaciju tipova ispitivanja na određenoj funkciji svi su isti, funkcionalni ili ne. Namjera je ta koja čini razliku, a možda i metoda.
Zaključak
Prije izvođenja nefunkcionalnog testiranja, bitno je pravilno planirati strategiju ispitivanja kako biste osigurali pravilno ispitivanje. Na tržištu su dostupni različiti alati za izvođenje ove vrste testova poput Load Runner, RPT itd.
Ovo testiranje igra glavnu ulogu u uspjehu aplikacije i izgradnji dobrih odnosa s kupcima i stoga ga ne treba zanemariti. Ovo je jedan od važnih dijelova testiranja softvera i testiranje se bez toga ne može smatrati cjelovitim.
U plan ispitivanja možemo uključiti nefunkcionalne detalje ispitivanja ili možemo stvoriti zasebnu strategiju za njega. U oba slučaja, cilj je imati odgovarajuće pokrivanje nefunkcionalnih aspekata softvera.
Nadamo se da vam je ovaj proces dubokog udubljivanja u ovu temu bio jednako zabavan kao i svima vama. Voljeli bismo čuti vaše povratne informacije i razmišljanja o ovoj temi.
Kako se nosite s nefunkcionalnim testiranjem u svojim timovima? I kao i uvijek, javite nam se slažete li ili ne ili imate li što dodati onome što se ovdje događa.
Preporučena literatura
- Funkcionalno ispitivanje vs nefunkcionalno testiranje
- Alfa testiranje i beta testiranje (cjelovit vodič)
- Vodič za ispitivanje sigurnosti web aplikacija
- Kompletan vodič za funkcionalno ispitivanje sa svojim vrstama i primjerima
- Kompletni vodič za testiranje provjere izrade (BVT testiranje)
- Najbolji alati za testiranje softvera 2021. [Alati za automatizaciju ispitivanja kvalitete]
- Vodič za početnike za ispitivanje prodora web aplikacija
- Kompletni vodič za ispitivanje učitavanja za početnike