Meni

Pisanje testnih slučajeva iz SRS dokumenta (PREUZMITE Uzorke testnih primjera projekata uživo)

writing test cases from srs document

Isprobajte Naš Instrument Za Uklanjanje Problema

Pisanje testnih slučajeva iz SRS dokumenta (preuzmite primjere testnih slučajeva uživo) - Testiranje softverskog testiranja QA, 4. dan

Samo da ponovimo ono što smo do sada radili - probijamo se kroz Obuka za testiranje softvera mini-tečaj na live projektu OrangeHRM.

U ovoj besplatnoj internetskoj seriji QA treninga do sada smo završili sa:

  1. Pregled SRS-a,
  2. Test scenarij / identifikacija opsega ispitivanja i
  3. Dokumentirao plan ispitivanja .

Pisanje ispitnih slučajeva iz SRS dokumenta

Sad smo došli do dijela koji je stvarna stvar,test slučajevi.

Kao što je navedeno u članku prije ovoga: Test slučajeve dokumentira QA tim dok traje SDC-ova faza koda. Drugim riječima, dok Dev tim gradi softverski sustav, tim za testiranje sprema se s testnim slučajevima koji bi nam pomogli da testiramo sustav kada je spreman, tj. Na kraju faze koda.

Dakle, u današnjem ćemo članku raditi na razumijevanju što su test slučajevi, kako ih stvoriti i napisati nekoliko uzoraka testnih slučajeva za naš projekt uživo.

Krenimo odmah do toga.

Što ćete naučiti:

Osnove pisanja ispitnih slučajeva

# 1) Ako su se u scenarijima ispitivanja radilo na temu „Što ćemo testirati“ na AUT - testni slučajevi su u pitanju 'Kako ćemo testirati zahtjev'.

Na primjer , ako je testni scenarij „Provjera funkcionalnosti administratorske prijave“ - To bi rezultiralo u 3 testna slučaja (ili uvjeta) - Prijava (uspješna), Neuspješna prijava kada se unese pogrešno korisničko ime, Neuspješna prijava kada se unese netočna lozinka . Svaki bi testni slučaj, zauzvrat, imao korake za rješavanje načina na koji možemo provjeriti je li određeni testni uvjet zadovoljen ili ne.

#dva) Ulaz za stvaranje dokumenta testnog slučaja je FRD, scenariji ispitivanja stvoreni u prethodnom koraku i svi drugi referentni dokumenti ako postoje.

# 3) Dokumentacija o testnom slučaju važan je rezultat QA tima i dijeli se s BA, PM-om i ostalim timovima kada se to radi radi njihovih povratnih informacija.

# 4) Posao je podijeljen između članova tima i svaki će član biti odgovoran za stvaranje test slučajeva za određeni modul ili dio određenog modula.

# 5) Baš kao i kod testnih scenarija, prije nego što započnemo s dokumentacijom testnog slučaja, mora se dogovoriti zajednički predložak. Za stvaranje testnih slučajeva može se koristiti praktički sve. 2 najčešće korištena izbora su MS Excel i MS word.

# 6) The Predložak MS riječi izgleda otprilike ovako:

Test slučajevi MS word predložak

# 7) The Excel predložak može izgledati ovako:

qa uzorci za ispitne treninge xls

# 8) Iz gornja dva predloška može se primijetiti da su polja (ili komponente) koja čine testni slučaj jednaka, jedina razlika je način na koji su organizirana.

Dakle, dok postoji polje za svaku od vrsta informacija koje se uključuju u test, format predloška nije važan. Međutim, moj osobni favorit je excel list, jer ga je lako proširiti, sažeti, razvrstati itd. Ali opet, odaberite bilo koji format koji vam najviše odgovara.

Polja u test slučajevima

Uzmimo trenutak, da promatramo polja koja su dio test slučaja.

Id testnog slučaja i opis testnog slučaja su generički.

Ostala polja mogu se objasniti na sljedeći način:

  • Preduvjet: Stanje AUT (stanje u kojem AUT mora biti da bismo mogli započeti).
  • Ulazni: Koraci za unos podataka. Za ove korake važno je napomenuti kakve su ulazne informacije potrebne - test podaci.
  • Točka provjere / okidač / radnja : Što uzrokuje validaciju? (Klik na gumb ili prebacivanje ili pristup poveznici. Provjerite postoji li barem jedna točka provjere valjanosti testnog slučaja - u suprotnom će sve biti unos podataka bez ičega što treba tražiti. Također kako bismo osigurali dovoljno modularnosti, pokušajte ne kombinirati previše točaka validacije u jedan testni slučaj. Optimalno je 1 po testnom slučaju.)
  • Izlaz: Očekivani rezultat.
  • Postuslov: Ovo su dodatne informacije koje se pružaju u korist testera samo kako bi test slučaj bio pronicljiviji i informativniji. To uključuje objašnjenje što se događa ili što se može očekivati ​​od AUT-a nakon što se izvrše svi koraci na testnom slučaju.

Također pogledajte => Uzorak predloška testnog slučaja

Primjeri testnih slučajeva uživo (preuzimanje)

Sad kad imamo dovoljno osnovnih podataka da započnemo s postupkom izrade testnih slučajeva, krenimo i stvorimo nekoliko testnih slučajeva za naš Live Project.

Na temelju gore spomenutog postupka stvorili smo nekoliko primjera testnih slučajeva za modul OrangeHRM računa. Oni bi vam trebali dati točan format test primjera i ideju o tome kako pristupiti pisanju test slučajeva.

=> Preuzmite ovdje uzorak dokumenta o test slučajevima za naš projekt uživo .

Bilješka: Postoji nekoliko slika upućenih na uzorke XLS dokumenata za test slučajeve. Ako ovo gledate na starijoj verziji MS Officea, mogli biste se suočiti s problemima kompatibilnosti.

U nastavku smo naveli te slike prema njihovim imenima u XLS datotekama:

Pogledajte sliku 1
Pogledajte sliku 2
Pogledajte sliku 3

Eto, sve gotovo i sve dobro.

Metode pisanja / optimizacije test slučajeva

Zamislite sada situaciju u kojoj određena stranica ima nekoliko deset polja ili na sebi ima složenu poslovnu logiku. Kako bismo bili sigurni da optimiziramo postupak stvaranja testnih slučajeva u takvim situacijama, mi testeri imamo određene metode optimizacije testnih slučajeva.

Dolje su navedene veze za više informacija o ovim metodama.

kako mogu ažurirati svoj bios windows 10

Koristeći gornje tehnike i prateći opći postupak stvaranja testnih slučajeva, kreiramo skup testnih slučajeva koji bi učinkovito testirali postojeću aplikaciju.

Nekoliko važnih bodova koje treba zabilježiti

  • Test slučajevi koje kreiramo nisu referentna točka samo za QA fazu već i za UAT.
  • Slučajevi internih testova su Recenziran unutar tima .
  • Kada se određena situacija ne riješi test slučajem - pravilo je da se neće testirati. Dakle, ovo je dobro mjesto za provjeru postiže li testni paket koji smo stvorili cilj 100% pokrivenosti testom ili ne. Da bi se to učinilo, može se stvoriti matrica sljedivosti. Pogledajte sve što možete znati o Ovdje je matrica sljedivosti .
  • Alati - Alati za upravljanje testovima poput QC , qTest pomozite nam u aktivnosti stvaranja test slučajeva. Primjer kako se mogu riješiti test slučajevi pomoću Centra za kvalitetu, pogledajte ovo Vodič za Centar za kvalitetu .
  • Alati za automatizaciju mogu se koristiti za stvaranje testnih slučajeva - u tom slučaju se nazivaju Test skripte.
Pro savjet :Izvršite provjeru pravopisa i gramatike na svakom dokumentu koji izradimo. Mi smo predstavnici kvalitete za IT projekte - i to se ne odražava pozitivno na nas ako su sami naši proizvodi lošije kvalitete.

To nas dovodi do cilja još jednog zanimljivog segmenta.

Zaključak

Kraj postupka izrade testa / faze dizajna testa (STLC) i kraj faze koda (SDLC) općenito će označiti kraj faze pripreme za test i početak faze izvođenja testa.

Sljedeći vodič u ovom tečaju za testiranje softvera - U sljedećem članku govorit ćemo o tome što je izvršenje testa, što uključuje i kakva su očekivanja od QA tima tijekom ove faze.

=> QA trening dan 5: Izvršenje testa

Nadamo se da svi radite zajedno s ovom serijom. Radi jednostavnosti stvoreno je samo nekoliko testnih slučajeva. Međutim, najbolji rezultati mogu se vidjeti kada intenzivno radite na testiranju, što znači pisanje sve više i više slučajeva. Dakle, molim vas, nemojte ograničavati svoj rad i radite koliko god možete.

Javite nam svoja pitanja i komentare u nastavku. Sretno testiranje!

PREV Vodič | SLJEDEĆA Vodič

Preporučena literatura

^