Primjer testnih slučajeva za web aplikaciju (kontrolni popis)

By: Thomas Hamilton Thomas Hamilton
Hours Ažurirano

⚡ Pametni sažetak

Potpuna kontrolna lista za testiranje web aplikacija obuhvaća provjere upotrebljivosti, funkcionalnosti, kompatibilnosti, baze podataka, API-ja, sigurnosti, performansi i pristupačnosti. Svaki odjeljak u nastavku nudi gotove scenarije testiranja koje timovi za osiguranje kvalitete mogu izravno kopirati u alat za upravljanje testiranjem.

  • ️ Funkcionalno prvo: Prije početka bilo kakvog kozmetičkog pregleda provjerite obavezna polja, duljine granica, prijestupne godine, dijeljenje s nulom i ponašanje isteka vremena.
  • 🧭 Signali upotrebljivosti: Provjerite poravnanje, opise alata, pristup tipkovnicom, trake za pomicanje i oporavak poruka o pogreškama kako se korisnik koji prvi put koristi ne bi susreo s problemima.
  • 🌐 Matrica kompatibilnosti: Ponovite kritične tokove u Chromeu, Firefox, Edge, Safari i mobilne preglednike kako bi se otkrile razlike u izgledu i skriptama.
  • 🗄️ Integritet baze podataka: Usporedite vrijednosti front-enda s pohranjenim zapisima, provjerite ključeve, okidače, pohranjene procedure i duljine polja na oba sloja.
  • 🔌 API sloj: Potvrdite statusne kodove, sheme, autentifikaciju, ograničenja brzine i rukovanje greškama nizvodno odvojeno od preglednika.
  • 🔐 Osnovna sigurnosna linija: Prisilno korištenje HTTPS-a, šifriranje pohranjenih tajni, zaključavanje računa nakon ponovljenih kvarova i ispitivanje SQL injekcija i brute forcea.
  • 🚀 Performanse i pristup: Skriptirajte profile učitavanja s automatizacijom umjesto ručnog napora, a zatim potvrdite WCAG kontrast, oznake i rad s tipkovnicom.
Pročitaj više

Tijekom testiranja web aplikacija treba uzeti u obzir dolje navedeni predložak. Dolje navedeni kontrolni popis je gotovo primjenjiv za sve vrste web aplikacija ovisno o poslovnim zahtjevima.

Gornji predložak pokazuje kako jedan list može sadržavati scenarije za svako područje kontrolne liste. Za pozadinu pogledajte testiranje web aplikacija pregled.

Sada pogledajmo svaki kontrolni popis u detalje:

Funkcionalno ispitivanje

Što je funkcionalno testiranje?

  • Ispitivanje značajki i radnog ponašanja proizvoda kako bi se osiguralo da odgovaraju njegovim specifikacijama.
  • Testiranje koje zanemaruje unutarnji mehanizam sustava ili komponente i fokusira se isključivo na izlaze generirane kao odgovor na odabrane ulaze i uvjete izvršenja.

Koja je svrha ili cilj funkcionalnog testiranja?

  • Cilj Funkcionalno ispitivanje je provjeriti zadovoljava li vaš proizvod predviđene funkcionalne specifikacije navedene u vašoj razvojnoj dokumentaciji.

Primjeri scenarija funkcionalnog ispitivanja:

  • Testiraj sva obvezna polja trebaju biti potvrđena.
  • Testirajte znak zvjezdice koji bi se trebao prikazati za sva obavezna polja.
  • Testiranje sustava ne bi trebalo prikazati poruku o pogrešci za neobavezna polja.
  • Provjerite jesu li prijestupne godine ispravno potvrđene i ne uzrokuju li pogreške/pogrešne proračune.
  • Testirajte da numerička polja ne bi trebala prihvaćati slova i trebala bi se prikazati ispravna poruka o pogrešci.
  • Testirajte negativne brojeve ako je dopušteno za numerička polja.
  • Probno dijeljenje s nulom treba ispravno koristiti za izračune.
  • Testirajte maksimalnu duljinu svakog polja kako biste bili sigurni da podaci nisu skraćeni.
  • Testirajte skočnu poruku ("Ovo je polje ograničeno na 500 znakova") koja bi se trebala prikazati ako podaci dosegnu maksimalnu veličinu polja.
  • Provjerite treba li se prikazati poruka potvrde za operacije ažuriranja i brisanja.
  • Testirajte vrijednosti iznosa koje bi trebale biti prikazane u formatu valute.
  • Testirajte sva polja za unos posebnih znakova.
  • Testirajte funkciju vremenskog ograničenja.
  • Testirajte funkciju sortiranja.
  • Testirajte funkcionalnost dostupnih gumba
  • Testirajte Politika privatnosti i FAQ jasno su definirani i trebali bi biti dostupni korisnicima.
  • Testirajte ako neka funkcija zakaže, korisnik će biti preusmjeren na prilagođenu stranicu s pogreškom.
  • Provjerite jesu li svi učitani dokumenti pravilno otvoreni.
  • Testirajte bi li korisnik trebao moći preuzeti učitane datoteke.
  • Testirajte funkcionalnost e-pošte sustava.
  • Testirajte Java skripta ispravno radi u različitim preglednicima (IE, Firefox, Chrome, safari i Opera).
  • Testirajte da vidite što se događa ako korisnik izbriše kolačiće dok je na stranici.
  • Testirajte da vidite što se događa ako korisnik izbriše kolačiće nakon posjete web-mjestu.
  • Testirajte da su svi podaci unutar kombiniranog/popisnog okvira raspoređeni kronološkim redom.

Nakon što se značajke ispravno ponašaju, sljedeće pitanje je mogu li ih stvarni korisnici koristiti bez pomoći.

Ispitivanje upotrebljivosti

Što je testiranje upotrebljivosti?

  • Testiranje upotrebljivosti nije ništa drugo nego provjera prilagođenosti korisniku.
  • U testiranju upotrebljivosti testira se tijek aplikacije kako bi novi korisnik mogao lako razumjeti aplikaciju.
  • U osnovi, navigacija sustavom provjerava se u testiranju upotrebljivosti.

Koja je svrha ili cilj testiranja upotrebljivosti?

Test upotrebljivosti utvrđuje jednostavnost korištenja i učinkovitost proizvoda korištenjem standardnih praksi testiranja upotrebljivosti.

Primjeri testnih slučajeva upotrebljivosti

  • Sadržaj web stranice mora biti točan bez ikakvih pravopisnih ili gramatičkih pogrešaka
  • Svi fontovi trebaju biti isti prema zahtjevima.
  • Sav tekst mora biti pravilno poravnat.
  • Sve poruke o pogrešci trebaju biti točne, bez ikakvih pravopisnih ili gramatičkih pogrešaka, a poruka o pogrešci mora odgovarati naljepnici polja.
  • Tekst savjeta alata trebao bi biti prisutan za svako polje.
  • Sva polja moraju biti ispravno poravnata.
  • Između oznaka polja, stupaca, redaka i poruka o pogrešci treba ostaviti dovoljno prostora.
  • Svi gumbi trebaju biti standardnog formata i veličine.
  • Poveznica na početnu stranicu trebala bi biti prisutna na svakoj stranici.
  • Onemogućena polja trebaju biti zasivljena.
  • Provjerite neispravne veze i slike.
  • Poruka potvrde trebala bi se prikazati za bilo koju vrstu operacije ažuriranja i brisanja.
  • Provjerite web mjesto na različitim rezolucijama (640 x 480, 600×800 itd.?)
  • Provjerite može li krajnji korisnik pokrenuti sustav bez frustracija.
  • Provjerite radi li kartica ispravno.
  • Traka za pomicanje trebala bi se pojaviti samo ako je potrebna.
  • Ako postoji poruka o pogrešci pri slanju, informacije koje je korisnik ispunio trebaju biti tamo.
  • Naslov bi trebao biti prikazan na svakoj web stranici
  • Sva polja (tekstualni okvir, padajući izbornik, radio gumb, itd.) i gumbi trebali bi biti dostupni tipkovničkim prečacima i korisnik bi trebao moći izvoditi sve operacije pomoću tipkovnice.
  • Provjerite nisu li padajući podaci skraćeni zbog veličine polja. Također provjerite jesu li podaci kodirani ili njima upravlja administrator.

Izgled koji se dobro čita u jednom pregledniku može se pokvariti u drugom, stoga ponovno reproducirajte iste zaslone u svakom podržanom okruženju.

POVEZANI ČLANCI

Ispitivanje kompatibilnosti

Što je testiranje kompatibilnosti?

  • Testiranje kompatibilnosti koristi se kako bi se utvrdilo je li vaš softver kompatibilan s drugim elementima sustava s kojima bi trebao raditi, npr. preglednicima, Operasustave ili hardver.

Koja je svrha ili cilj testiranja kompatibilnosti?

  • Svrha testiranja kompatibilnosti je procijeniti koliko dobro softver radi u određenom pregledniku, Operasustavi, hardver ili softver.

Primjeri scenarija testiranja kompatibilnosti:

  • Testirajte web stranicu u različitim preglednicima (IE, Firefox, Chrome, Safari i Opera) i osigurajte da se web stranica prikazuje ispravno.
  • Provjerite je li HTML verzija koja se koristi kompatibilna s odgovarajućim verzijama preglednika.
  • Testirajte ispravan prikaz slika u različitim preglednicima.
  • Testirajte jesu li fontovi upotrebljivi u različitim preglednicima.
  • Testirajte da li se kod java skripte može koristiti u različitim preglednicima.
  • Testirajte animirane GIF-ove u različitim preglednicima.

Dosljedno renderiranje ne dokazuje ništa o zapisima iza ekrana. unakrsno ispitivanje preglednika matrica održava ovo područje upravljivim.

Testiranje baze podataka

Što je testiranje baze podataka?

  • In Testiranje baze podataka testiraju se pozadinski zapisi koji su umetnuti putem web ili desktop aplikacija. Podaci koji se prikazuju u web aplikaciji trebaju odgovarati podacima pohranjenim u bazi podataka.

Za izvođenje testiranja baze podataka, ispitivač bi trebao biti svjestan niže navedenih točaka:

  • Ispitivač bi trebao temeljito razumjeti funkcionalne zahtjeve, poslovnu logiku, tijek aplikacije i dizajn baze podataka.
  • Ispitivač bi trebao shvatiti tablice, okidače, procedure pohranjivanja, prikaze i pokazivače koji se koriste za aplikaciju.
  • Ispitivač bi trebao razumjeti logiku stvorenih okidača, procedura pohrane, prikaza i kursora.
  • Ispitivač bi trebao otkriti tablice na koje utječe kada se operacije umetanja ažuriranja i brisanja (DML) izvode putem web ili desktop aplikacija.

Uz pomoć gore navedenih točaka, ispitivač može lako napisati testne scenarije za testiranje baze podataka.

Primjeri testnih slučajeva za testiranje baze podataka:

  • Provjerite naziv baze podataka: Naziv baze podataka trebao bi odgovarati specifikacijama.
  • Provjerite tablice, stupce, vrste stupaca i zadane postavke: Sve stvari trebaju odgovarati specifikacijama.
  • Provjerite dopušta li stupac nulu ili ne.
  • Provjerite primarni i strani ključ svake tablice.
  • Provjerite pohranjenu proceduru:
  • Provjerite je li pohranjena procedura instalirana ili ne.
  • Provjerite naziv pohranjene procedure
  • Provjerite nazive parametara, vrste i broj parametara.
  • Testirajte parametre jesu li potrebni ili ne.
  • Testirajte pohranjenu proceduru brisanjem nekih parametara
  • Testirajte kada je izlaz nula, to bi trebalo utjecati na nulte zapise.
  • Testirajte pohranjenu proceduru pisanjem jednostavnog SQL upita.
  • Provjerite vraća li pohranjena procedura vrijednosti
  • Testirajte pohranjenu proceduru s uzorkom ulaznih podataka.
  • Provjerite ponašanje svake zastavice u tablici.
  • Provjerite jesu li podaci pravilno spremljeni u bazu podataka nakon svakog slanja stranice.
  • Provjerite podatke ako se provode operacije DML (ažuriranje, brisanje i umetanje).
  • Provjerite duljinu svakog polja: Duljina polja na stražnjem i prednjem kraju mora biti ista.
  • Provjerite nazive baze podataka QA, UAT i proizvodnje. Imena bi trebala biti jedinstvena.
  • Provjerite šifrirane podatke u bazi podataka.
  • Provjerite veličinu baze podataka. Također testirajte vrijeme odgovora svakog izvršenog upita.
  • Provjerite podatke prikazane na prednjem dijelu i uvjerite se da su isti i na stražnjem dijelu.
  • Provjerite valjanost podataka umetanjem nevažećih podataka u bazu podataka.
  • Provjerite okidače.

Kontrolna lista za testiranje API-ja

Većina poslovnih pravila sada se nalazi iza REST ili GraphQL krajnjih točaka, tako da same provjere preglednika ne mogu dokazati da sustav radi. Testiranje krajnjih točaka izravno otkriva probleme.tracnedostatke t i autorizacije mnogo ranije nego što to može korisničko sučelje.

Prije potpisivanja krajnje točke, obuhvatite sljedeće scenarije:

Primjeri testnih scenarija za testiranje API-ja:

  • Provjerite dokumentirane statusne kodove za uspjeh, neuspjeh validacije, neovlašteni pristup i pogrešku poslužitelja.
  • Provjerite odgovara li sadržaj odgovora objavljenoj shemi, uključujući nazive polja i tipove podataka.
  • Provjerite vraćaju li nedostajući ili neispravni parametri čitljivu poruku umjesto stoga trace.
  • Provjerite isteku li tokeni za autentifikaciju, ispravno se osvježavaju i ne mogu li se ponovno reproducirati nakon odjave.
  • Provjerite autorizaciju na temelju uloge kako standardni račun ne bi mogao dosegnuti administratorske krajnje točke promjenom identifikatora.
  • Provjerite granične vrijednosti za svaki parametar, uključujući prazne nizove i maksimalne duljine.
  • Provjerite vraća li ograničavanje brzine ispravan odgovor na usporavanje umjesto da tiho zakaže.
  • Provjerite da li se krajnja točka elegantno degradira kada istekne vrijeme trajanja usluge treće strane.
  • Provjerite da se u odgovorima ili porukama o pogrešci ne pojavljuju lozinke, tokeni ili interni putovi.

Pokrenite ovaj popis u svakom okruženju, budući da priprava i produkcija često otkrivaju različite skupove dozvola. Pogledajte API testiranje pregled i ručno testiranje REST API-ja.

Nekoliko tih provjera preklapa se sa sigurnosnim radom.

Ispitivanje sigurnosti

Ispitivanje sigurnosti uključuje test za prepoznavanje bilo kakvih nedostataka i nedostataka sa sigurnosne točke gledišta.

Primjeri testnih scenarija za sigurnosno testiranje:

  • Provjerite web stranicu koja sadrži važne podatke kao što su lozinka, brojevi kreditnih kartica, tajne odgovore na sigurnosna pitanja itd. treba poslati putem HTTPS (SSL).
  • Provjerite važne informacije poput lozinke, brojeva kreditnih kartica itd. trebaju biti prikazane u šifriranom formatu.
  • Provjerite jesu li pravila za lozinku implementirana na svim stranicama za provjeru autentičnosti kao što su Registracija, Zaboravljena lozinka, Promjena lozinke.
  • Provjerite ako je lozinka promijenjena da se korisnik ne bi trebao moći prijaviti sa starom lozinkom.
  • Provjerite da poruke o pogrešci ne smiju prikazivati ​​nikakve važne informacije.
  • Provjerite je li korisnik odjavljen sa sustava ili je korisnička sesija istekla, korisnik ne bi trebao moći navigirati web mjestom.
  • Potvrdite za izravan pristup zaštićenim i nezaštićenim web stranicama bez prijave.
  • Provjerite je li opcija "Prikaz izvornog koda" onemogućena i ne bi trebala biti vidljiva korisniku.
  • Provjerite je li korisnički račun zaključan ako korisnik nekoliko puta unese pogrešnu lozinku.
  • Provjerite da kolačići ne bi trebali pohranjivati ​​lozinke.
  • Provjerite ako neka funkcija ne radi, sustav ne bi trebao prikazati informacije o aplikaciji, poslužitelju ili bazi podataka. Umjesto toga, trebao bi prikazati prilagođenu stranicu pogreške.
  • Provjerite napade SQL injekcijom.
  • Provjerite korisničke uloge i njihova prava. Na primjer, podnositelj zahtjeva ne bi trebao moći pristupiti stranici administratora.
  • Provjerite jesu li važne operacije zapisane u datotekama zapisnika i te informacije trebaju biti tracmoguće.
  • Provjerite jesu li vrijednosti sesije u kriptiranom formatu u adresnoj traci.
  • Provjerite jesu li informacije o kolačićima pohranjene u šifriranom formatu.
  • Provjerite aplikaciju za Brute Force Attacks

Očvrsnuta aplikacija koja se savija pod opterećenjem i dalje je neupotrebljiva, pa se u sljedećem prolazu mjeri skala.

Ispitivanje performansi

Ispitivanje performansi provodi se kako bi se ocijenila usklađenost sustava ili komponente sa specificiranim zahtjevima performansi.

Opći testni scenariji:

  • Za određivanje performansi, stabilnosti i skalabilnosti aplikacije pod različitim uvjetima opterećenja.
  • Kako bi se utvrdilo može li trenutna arhitektura podržati aplikaciju na vršnim korisničkim razinama.
  • Da biste odredili koja veličina konfiguracije pruža najbolju razinu izvedbe.
  • Identificirati uska grla aplikacije i infrastrukture.
  • Kako bi se utvrdilo je li nova verzija softvera negativno utjecala na vrijeme odziva.
  • Za procjenu proizvoda i/ili hardvera kako bi se utvrdilo može li podnijeti predviđene količine opterećenja.

Kako napraviti testiranje performansi? Ručnim testiranjem ili automatizacijom

Praktično nije moguće izvršiti testiranje performansi ručno zbog nekih nedostataka kao što su:

  • Bit će potrebno više resursa.
  • Simultane radnje nisu moguće.
  • Ispravno praćenje sustava nije dostupno.
  • Nije lako izvršiti zadatak koji se ponavlja.

Stoga da bismo prevladali gore navedene probleme, trebali bismo koristiti alat za testiranje performansi. Dolje je popis nekih popularnih alata za testiranje.

Jedna publika još uvijek nedostaje: korisnici koji do ovih ekrana dolaze putem asistivne tehnologije.

Kontrolni popis za testiranje pristupačnosti

Testiranje pristupačnosti potvrđuje da ljudi koji koriste čitače zaslona, ​​navigaciju samo tipkovnicom ili uvećavanje mogu dovršiti iste putove kao i svi ostali. To je također zahtjev nabave, budući da poduzeća...tracts se obično referira WCAG 2.2 Razina AAOvi nedostaci su strukturni i njihovo rano rješavanje košta puno manje.

Primjeri testnih scenarija za testiranje pristupačnosti:

  • Provjerite imaju li smislene slike opisni alternativni tekst i jesu li ukrasne slike skrivene od pomoćne tehnologije.
  • Provjerite ima li svaka kontrola obrasca programski povezanu oznaku, a ne samo susjedni tekst rezerviranog mjesta.
  • Provjerite radi li stranica samo s tipkovnicom, s vidljivim indikatorom fokusa na svakom zaustavljanju.
  • Provjerite zadovoljavaju li tekst i interaktivni elementi minimalni omjer kontrasta u odnosu na pozadinu.
  • Provjerite da naslovi slijede logičan redoslijed bez preskakanja razina kako bi navigacija čitača zaslona funkcionirala.
  • Provjerite jesu li poruke o pogreškama objavljene pomoćnoj tehnologiji i identificirajte polje s greškom.
  • Provjerite je li stranica i dalje upotrebljiva pri zumiranju od 200 posto bez horizontalnog pomicanja.
  • Provjerite prikazuju li prilagođeni widgeti poput modalnih prozora, kartica i harmonika ispravne uloge i stanja.

Automatizirani skeneri otkrivaju samo dio ovih problema, stoga dodajte ručnu propusnicu za tipkovnicu i čitač zaslona. testiranje pristupačnosti referenca pokriva alate.

Pitanja i odgovori

Plan testiranja je formalni dokument koji pokriva opseg, raspored, resurse, rizik i kriterije izlaska za izdanje. Kontrolna lista je jednostavni podsjetnik na pokrivenost koji navodi uvjete koje treba provjeriti. Plan upravlja projektom; kontrolna lista upravlja pojedinačnom sesijom testiranja.

RevPregledajte ga nakon svakog većeg izdanja, nove integracije ili incidenta u produkciji. Svaki izbjegnuti nedostatak trebao bi dodati jedan redak kako se isti kvar ne bi mogao ponoviti. Kontrolna lista koja se nikada ne revidira brzo prestaje odražavati kako se aplikacija zapravo ponaša.

Većina timova veže sigurnosnu pokrivenost za OWASP Vodič za testiranje web sigurnosti, pristup WCAG-u 2.2 i cjelokupna terminologija procesa prema ISTQB-u. Ove reference omogućuju reviziju kontrolne liste, umjesto da se temelji isključivo na timskim navikama.

Da. Unošenjem zahtjeva, korisničkih priča ili API specifikacija u veliki jezični model dobiva se solidan prvi nacrt scenarija. Tester i dalje mora ukloniti duplikate, dodati poslovna pravila koja model ne može zaključiti i potvrditi da je svaka stavka zaista provjerljiva.

Samoobnavljajući lokatori ponovno identificiraju elemente nakon promjena oznaka, smanjujući nestalne kvarove koji dominiraju naporima održavanja. Umjetna inteligencija također grupira duplicirane nedostatke i rangira koje pakete treba prvo pokrenuti, tako da regresijski ciklusi ostaju kratki kako kontrolna lista raste.

Sažmite ovu objavu uz: