ingen programmer kan nogensinde være helt perfekt. Men er det en licens til at skabe affald? Den manglende ingrediens er vores modvilje mod at kvantificere kvaliteten. For at øge kvaliteten, er det meget vigtigt at sikre en effektiv udførelse af programmet. Programmel test er nødvendig for at sikre, at programmet kører uden fejl. I denne test tutorial vil jeg fortælle dig alt hvad du behøver at vide om test aspekter. I forlængelse af den tidligere blog om, hvad der er programmel test, her vil jeg dykke dybere og dække nedenstående emner.
- Introduktion til test af programmel
- grundlæggende test af programmel
- livscyklus for udvikling af programmel
- verifikations-og Valideringsmodel
- test af programmel
- test af Programmelniveauer
- test af programmel dokumentation artefakter
- Bug livscyklus
- udfordringer ved manuel test
- Automatiseringstest vs manuel test
du kan også gennemgå optagelsen af tutorial til test af programmer, hvor vores eksperter i træning af Programmelprøvning har forklaret begreberne dybdegående.
programmel Test Tutorial for begyndere / Manual & Automation Testing
denne video taler om forskellige typer test, dvs. manuel test og automatiseringstestmetoder.
Introduktion til test af programmer
dagens verden af teknologi er fuldstændig domineret af maskiner, og deres adfærd styres af programmet, der driver det. Programmel test giver en omkostningseffektiv løsning på alle vores bekymringer. Hvad er test af programmer? Test er en proces til at evaluere funktionaliteten af et program til at finde eventuelle fejl. Det kontrollerer, om det udviklede program opfylder de specificerede krav og identificerer eventuelle fejl i programmet for at opnå et kvalitetsprodukt. Det er dybest set at udføre et system til at identificere eventuelle huller, fejl eller manglende krav i strid med de faktiske krav.
det er også angivet som processen med at verificere og validere et programmel produkt. Det kontrollerer, om programmet produkt:
- opfylder de forretningsmæssige og tekniske krav, der styrede dets design og udvikling
- fungerer i henhold til kravet
- kan implementeres med de samme egenskaber
lad os nu gå videre i tutorial-artiklen om test af programmer og få nogle indsigter om det grundlæggende i test af programmer.
grundlæggende test af programmer
først vil jeg fortælle dig, hvad er programudviklingens livscyklus?
programmeludvikling livscyklus
(SDLC) forkortet som programmeludvikling livscyklus er en proces, der anvendes af programmelindustrien til at designe, udvikle og teste programmer af høj kvalitet. Det sigter mod at producere programmer af høj kvalitet, der opfylder eller overstiger kundernes forventninger, når færdiggørelse inden for tid og omkostningsestimater. Nedenstående diagram viser forskellige faser involveret i SDLC.
Fig: Programudvikling livscyklus-program Test Tutorial
krav fase
krav indsamling og analyse er den vigtigste fase i programudvikling livscyklus. Forretningsanalytiker indsamler kravet fra kunden/klienten i henhold til kundens forretningsbehov og dokumenterer kravene i forretningskravspecifikationen (dokumentnavn varierer afhængigt af organisationen).
analysefase
når kravene er samlet og analyseret, er næste trin at definere og dokumentere produktkravene og få dem godkendt af kunden. Dette er registreret gennem SRS (programkrav specifikation) dokument. Den består af alle produktkrav, der skal designes og udvikles under projektets livscyklus
designfase
denne fase har to trin:
- HLD – design på højt niveau-det giver arkitekturen af det programprodukt, der skal udvikles, og udføres af arkitekter og seniorudviklere
- LLD – design på lavt niveau – det udføres af seniorudviklere. Her giver det dig indsigt i, hvordan hver eneste funktion i produktet skal fungere, og hvordan hver komponent skal fungere.
resultatet af denne fase er dokumentet på højt niveau og dokumentet på lavt niveau, der fungerer som input til næste fase.
udviklingsfase
udviklere på alle niveauer (seniorer, juniorer, freshers) er involveret i denne fase. Dette er den fase, hvor du begynder at opbygge koden til programmet.
testfase
når programmet er klar, sendes det til testafdelingen, hvor de tester det grundigt for forskellige fejl. Test af et program udføres enten manuelt eller ved hjælp af automatiserede testværktøjer og sikrer, at hver eneste komponent i programmet fungerer fint. Når programmet er fejlfrit, går det til næste trin, som er implementering.
implementering& vedligeholdelsesfase
når produktet er fejlfrit, leveres/implementeres det til kunden til deres brug. Implementering udføres af implementerings – /Implementeringsingeniørerne. Da kunderne begynder at bruge det udviklede system, kommer de faktiske problemer op og skal løses fra tid til anden. Detektion og løsning af disse problemer, som kunden finder, kommer i vedligeholdelsesfasen.
det hele handlede om Programmeludviklingens livscyklus. Hvis du ønsker at vide om forskellige stadier, der er involveret i testprocessen, kan du læse denne blog om livscyklus for test af programmer. Efter at have forstået dette, lad os gå videre med dette program Test tutorial og se, hvad er v & V model.
V-modellen er nu en af de mest anvendte programmeludviklingsprocesser. Introduktion af V-modellen har faktisk bevist implementeringen af test lige fra kravfasen. Det kaldes også som verifikations-og Valideringsmodel
Hvad er verifikation og validering i test af programmer?
verifikation: verifikation er en statisk analyseteknik. Her udføres test uden at udføre koden. Eksempler inkluderer-anmeldelser, inspektion, og gå igennem.
Validering: Validering er en proces med dynamisk analyse, hvor vi udfører test ved at udføre koden. Eksempler inkluderer funktionelle og ikke-funktionelle testteknikker.
i V-modellen udføres udviklings-og KVALITETSSIKRINGSAKTIVITETERNE samtidigt. Her starter testen lige fra kravfasen. Verifikations-og valideringsaktiviteterne finder sted samtidigt. Lad os se på figuren nedenfor for at forstå V model
i en typisk udviklingsproces viser venstre side udviklingsaktiviteterne, og højre side viser testaktiviteterne. Det bør ikke være forkert, hvis jeg siger, at i udviklingsfasen udføres både verifikation og validering sammen med de faktiske udviklingsaktiviteter.
LHS
som tidligere nævnt er aktiviteter på venstre side udviklingsaktiviteter. Normalt føler vi, hvilken test kan vi gøre i udviklingsfasen? Men dette er essensen af denne model, der illustrerer, at test også kan udføres i alle faser af udviklingsaktiviteter.
RHS
testaktiviteterne eller valideringsfasen udføres i højre side af modellen.
som du har fået nogle indsigt i dette, lad os gå videre med denne program Test tutorial og se, hvad er de forskellige metoder, som programmet kan testes.
programmel testmetoder
Der er tre metoder til test af programmel, og de er som følger:
- test af sort boks
- test af hvid boks
- test af grå boks
test af sort boks: det er en metode til test af programmer, hvor den interne struktur/ design/ implementering af det emne, der testes, ikke er kendt af testeren.
test af hvid boks: det er en metode til test af programmer, hvor den interne struktur/ design/ implementering af det emne, der testes, er kendt af testeren.
test af grå boks: det er en testteknik udført med begrænset information om systemets interne funktionalitet.
Jeg håber du forstod nøglepegere på forskellige metoder til test af programmer. Nu, lad os gå videre i denne test Tutorial artikel og forstå test niveauer.
Programtestniveauer
et niveau i programtestning er en proces, hvor hver enhed eller komponent i et program/system testes. Der er forskellige testniveauer, der hjælper med at kontrollere adfærd og ydeevne til test af programmer. Disse testniveauer er designet til at genkende manglende områder og forsoning mellem udviklingen af livscyklustilstande. I livscyklusmodellen er der karakteriseret faser som kravindsamling, analyse, design, kodning eller udførelse, test og implementering.
alle disse faser gennemgår processen med testniveauer. Der er hovedsageligt fire testniveauer, og de er:
- enhedstest
- integrationstest
- systemtest
- accepttest
grundlæggende starter det med Enhedstestfasen og slutter med accepttest.
i det næste afsnit af denne testvejledning vil jeg dykke dybere ned i det næste emne og forklare, hvad der er de forskellige dokumentationsartefakter i test af programmer.
artefakter
dokumentation af testcases vil gøre det lettere for dig at estimere den testindsats, du har brug for sammen med testdækning og krav til sporing og sporing. Nogle almindeligt anvendte dokumentationsartefakter forbundet med test af programmer er:
- testplan
- Testscenarie
- testcase
- Sporbarhedsmatrice
lad os diskutere hver af dem i korte træk.
- testplan: det giver dig skitsestrategien, som vil blive implementeret til test af applikationen.
- Testscenarie: Testscenarie kan betragtes som en enkelt linjeerklæring, der giver besked om det område, hvor din ansøgning vil blive eksperimenteret. Denne artefakt er nødvendig for at sikre den samlede procedure testet fra starten til slutningen.
- testcase: testcase er intet andet end et sæt betingelser eller variabler, hvorunder en tester vil afgøre, om et system under test opfylder kravene eller fungerer korrekt. Nedenstående testsager kontrolleres under test.
- funktionelle test cases
- negative fejl test cases
- logiske test cases
- fysiske test cases
- UI test cases
- Sporbarhedsmatrice: det er også kendt som en Kravsporbarhedsmatrice (RTM). Den indeholder en tabel, der skitserer kravene, når dit produkts SDLC-model oprettes. Disse dokumenterende artefakter kan anvendes til fremadgående sporing, som skal gå fra design til kodning eller kan implementeres til bagudsporing, hvilket også er bagsiden af den fremadgående sporing.
dette bringer os til slutningen af Dokumentationsartefakter. Nu, lad os gå videre i denne test tutorial artikel og lære hvad er Defect Management?
Hvad er Fejlhåndteringsprocessen?
fejlhåndtering er en proces til at opdage fejl og rette dem. Da fejl er en del af programmelindustrien, forekommer de konstant i processen med programmeludvikling. Teammedlemmerne skal skrive store stykker kode hver dag, og de har normalt ikke tid til at tænke over, hvordan man undgår fejl. Derfor kræver ethvert programudviklingsprojekt en proces, der hjælper med at opdage fejlene og rette dem.
Fejlhåndteringsproces udføres på produktteststadiet. Uden at indse dette, ville det være svært at forstå karakteren af fejlhåndtering.. Normalt tester udviklerne deres produkt selv. Der er også en type test, der er baseret på brugerinddragelse. De endelige brugere får ofte mulighed for at rapportere om de fejl, de har identificeret. Ikke desto mindre er dette ikke den bedste måde at teste på, fordi brugerne måske ikke er i stand til at finde alle fejlene.
fejlhåndteringsprocessen omfatter normalt fire trin.
- det første trin er fasen af defektdetekteringen
- det andet trin er dedikeret til formuleringen af fejlrapporter
- det tredje trin er at rette fejlen.
- i det sidste trin oprettes buglisten
lad os nu gå videre i artiklen om test af tutorial og forstå fejldetekteringsprocessen ved hjælp af bugens livscyklus.
Bug livscyklus
en defekt livscyklus er en proces, hvor en defekt gennemgår forskellige faser i hele dens levetid. Det starter, når en defekt er fundet og slutter, når en defekt er lukket, efter at sikre det ikke er gengivet. En defekt livscyklus er relateret til fejlen fundet under test.
fejl eller defekt livscyklus inkluderer trinene som illustreret i nedenstående figur:
- nye: I dette trin, hvis en defekt logges og bogføres for første gang, angives dens tilstand som ny.
- tildelt:når testeren har sendt fejlen, godkender testerens ledelse, at fejlen er ægte, og han tildeler fejlen til en tilsvarende udvikler og udviklerteamet. Det er staten givet som tildelt.
- åben: idenne tilstand er udvikleren begyndt at analysere og arbejde på fejlrettelsen.
- fast: da udvikleren foretager de nødvendige kodeændringer og verificerer ændringerne, kan han/hun lave fejlstatus som ‘FAST’, og fejlen overføres til testteamet.
- Test:på dette tidspunkt tester testeren den ændrede kode, som udvikleren har givet tilbage til ham for at kontrollere, om fejlen er rettet eller ej.
- verificeret: her tester testeren fejlen igen, efter at den blev rettet af udvikleren. Hvis der ikke er nogen fejl i programmet, godkender han, at fejlen er rettet og ændrer status til “verificeret”.
- Genåbn: hvis fejlen stadig eksisterer, selv efter at fejlen er rettet af udvikleren, ændrer testeren status til “genåbnet”. I denne tilstand går fejlen igen gennem livscyklusen.
- lukket: så snart fejlen er rettet, testes den af testeren. Hvis testeren føler, at fejlen ikke længere findes i programmet, ændrer han status for fejlen til “lukket”. Det indebærer, at fejlen er rettet, testet og godkendt.
- Duplicate:i bugens livscyklus, hvis fejlen gentages to gange, eller de to fejl nævner det samme koncept for fejlen, ændres en fejlstatus til “duplicate”.
- afvist:hvis udvikleren føler, at fejlen ikke er ægte, afviser han fejlen. Derefter ændres bugens tilstand til”afvist”.
- udskudt:hvis fejlen ændres til udskudt tilstand, forventes fejlen at blive rettet i næste udgivelser.
dette handlede om bugens livscyklus og Fejlhåndteringsprocessen. Lad os nu se, hvad der er udfordringerne med manuel test.
udfordringer med manuel test
test af en applikation manuelt af KVALITETSTESTERE kaldes manuel test. Her skal alle testene udføres manuelt i hvert miljø ved hjælp af et andet datasæt, og succes/ fejlfrekvens for hver transaktion skal registreres.
i ovenstående figur kan du se en mand, der manuelt verificerer de registrerede transaktioner. Du kan nemt underrette de udfordringer, han står overfor, kan forårsage træthed, kedsomhed, forsinkelse i arbejdet, fejl og fejl på grund af manuel indsats. Dette førte til fremkomsten af Automatiseringstest.
lad os nu dykke ned i det sidste emne i tutorial-artiklen om programmelprøvning og se, hvordan Automatiseringstest slår manuel test.
Automatiseringstest vs manuel test
Automatiseringstest overvinder manuel test hver gang. Hvorfor? Fordi det er superhurtigt, kræver meget mindre investering i menneskelige ressourcer, ikke tilbøjelige til fejl, hyppig udførelse af test er mulig, understøtter regressionstest og også funktionel test.
lad os tage et eksempel og forstå dette. Sig, at du har en login-side, og du skal kontrollere, om alle login-forsøg er vellykkede, så vil det være virkelig nemt at skrive et stykke kode, som vil validere, om alle transaktions – / login-forsøg er en succes eller ej (automatiseret test case-udførelse).
alle disse tests kan konfigureres på en sådan måde, at de testes i forskellige miljøer. Ikke bare det, du kan også automatisere genereringen af resultatfilen ved at planlægge den til et bestemt tidspunkt i løbet af dagen. Derefter kan du også automatisere genereringen af rapporter baseret på disse resultater og hvad ikke.
vigtigt punkt her er, at automatisering test gør en tester job, en hel del enklere. Se ovenstående billede, der viser et mere afslappet miljø, hvor den samme tester arbejder. Hvis du ønsker at vide mere om Automatiseringstest og det udbredte Automatiseringstestværktøj selen, kan du henvise til denne Selenstudie.
det handlede om, hvordan automatiseringstestning glitrer sin vej inden for programtestning. Det bringer os til slutningen af artiklen om programmel Test Tutorial. Jeg håber, du fandt det informativt, og det har hjulpet med at tilføje værdi til din viden.
hvis du fandt denne “test Tutorial” relevant, tjek Den Live-Online selen Certificering uddannelse af Edureka, en betroet online læringsvirksomhed med et netværk af mere end 250.000 tilfredse elever spredt over hele kloden.