Menu

Top 20 praktiske softwaretesttip, du bør læse, før du tester en applikation


top 20 practical software testing tips you should read before testing any application

Prøv Vores Instrument Til At Fjerne Problemer

Jeg ønsker alle testere at læse softwaretestpraksis, der er opdateret i denne artikel . Læs hvert punkt omhyggeligt, og prøv at implementere dem i dine daglige testaktiviteter. Dette er, hvad jeg forventer af læserne gennem denne artikel. Hvis du ikke forstår nogen testpraksis, bede om mere afklaring i kommentarfeltet nedenfor.


Du vil dog lære alle disse testmetoder efter erfaring. Men hvorfor lærer du ikke alle disse ting, før du begår nogen fejl?

Kom lad os se på dem!


Praktiske tip til test af software

Her er nogle af de bedste testpraksis, som jeg har lært af erfaring:


open source resten api testværktøjer

# 1) Lær at analysere dine testresultater grundigt. Ignorer ikke testresultater. Det endelige testresultat kan være 'bestået' eller 'mislykkes', men fejlfinding af grundårsagen til 'fail' giver dig løsningen på problemet. Testere vil blive respekteret, hvis de ikke kun logger Bugs men også give løsninger.

#to) Lær at maksimere Test dækning hver gang du tester en applikation. 100% testdækning er muligvis ikke mulig, men alligevel kan du altid prøve at nå i nærheden af ​​den.

# 3) For at sikre maksimal testdækning, opdel din applikation under test (AUT) i mindre funktionelle moduler. Skriv testcases på sådanne individuelle enhedsmoduler. Opdel også disse moduler i mindre dele, hvis det er muligt.
For eksempel, lad os antage, at du har opdelt din webstedsapplikation i moduler, og 'accept af brugeroplysninger' er et af modulerne. Du kan opdele denne 'Brugeroplysninger'-skærm i mindre dele til skrivning af testsager: Dele som UI-test, Sikkerhedstest , Funktionel testning i formularen 'Brugeroplysninger' osv.


Anvend alle formularfelttype- og størrelsestest, negative og valideringstest på inputfelterne, og skriv alle sådanne testcases for maksimal dækning.

# 4) Mens Skrivning af sager , skriv først testcases for tilsigtet funktionalitet, dvs. for gyldige betingelser i henhold til kravene. Skriv derefter testsager for ugyldige forhold. Dette dækker både forventet og uventet opførsel af den testede applikation.

# 5) Tænk positivt. Begynd at teste applikationen med det formål at finde fejl / fejl. Tænk ikke på forhånd, at der ikke vil være nogen fejl i applikationen. Hvis du tester applikationen med det formål at finde fejl, vil du helt sikkert lykkes at finde dem Subtile Bugs også.


# 6) Skriv dine testsager i selve kravsanalysen og designfasen. På denne måde kan du sikre, at alle kravene kan testes.

# 7) Lav din testcases tilgængelige for udviklerne inden kodning. Hold ikke dine testsager med dig og venter på at få den endelige ansøgningsudgivelse til test, og tænk at du kan logge flere fejl. Lad udviklerne analysere dine testsager grundigt for at udvikle en kvalitetsapplikation. Dette sparer også genarbejdstiden.

# 8) Hvis det er muligt identificere og gruppere dine testsager til Regressionstest . Dette vil sikre hurtig og effektiv manuel regressionstest.

# 9) Applikationer, der kræver kritisk responstid, skal testes grundigt for ydeevne. Test af ydeevne er en kritisk del af mange applikationer. I Håndbog Testning, dette er den mest ignorerede del af testere på grund af mangel på krævet stort datavolumen i ydeevne test.

Find ud af måderne til at teste din ansøgning om ydeevne. Hvis det ikke er muligt at oprette testdata manuelt, skal du skrive nogle grundlæggende scripts for at oprette testdata til præstationstest eller bede udviklerne om at skrive en til dig.

# 10) Programmører bør ikke teste deres egen kode. Som diskuteret i vores forrige indlæg , Enhedstestning af udviklede applikationer skal være tilstrækkelig til, at udviklere frigiver applikationen til testere. Men du (tester) bør ikke tvinge udviklerne til at frigive produktet til test.

Lad dem tage deres egen tid. Alle fra bly til manager ved, hvornår modulet / opdateringen frigives til test, og de kan estimere testtiden i overensstemmelse hermed. Dette er en typisk situation i en Adræt projektmiljø.

# 11) Gå ud over kravtest. Test applikationen for, hvad den ikke skal gøre.

# 12) Mens du foretager regressionstest brug den forrige fejlgraf (Fejlgraf - antal fejl fundet mod tid for forskellige moduler). Denne modulvise buggraf kan være nyttig til at forudsige den mest sandsynlige bugdel af applikationen.

# 13) Noter de nye termer, begreber, du lærer under testning. Hold en tekstfil åben, mens du tester ethvert program. Noter testforløbet og observationer i det. Brug disse notepad-observationer, mens du udarbejder den endelige rapport om testudgivelse. Denne gode vane vil hjælpe dig med at levere en komplet utvetydig testrapport og frigive detaljer.

# 14) Mange gange foretager testere eller udviklere ændringer i kodebasen til applikation, der testes. Dette er et påkrævet trin i udviklings- eller testmiljøet for at undgå udførelse af behandlingen af ​​live transaktioner som i bankprojekter.

Noter alle sådanne kodeændringer, der er udført til testformål og på tidspunktet for den endelige frigivelse skal du sikre dig, at du har fjernet alle disse ændringer fra de endelige filressourcer til implementering af klientsiden.

# 15) Hold udviklere væk fra testmiljøet. Dette kræves et trin for at opdage eventuelle konfigurationsændringer, der mangler i frigivelses- eller implementeringsdokumentet. Nogle gange foretager udviklere nogle system- eller applikationskonfigurationsændringer, men glemmer at nævne dem i implementeringstrinnene.

Hvis udviklerne ikke har adgang til testmiljøet, foretager de ikke sådanne ændringer ved et uheld i testmiljøet, og disse manglende ting kan fanges på det rigtige sted.

# 16) Det er en god praksis at involvere testere lige fra selve softwarekrav og designfasen. På denne måde kan testere få kendskab til applikationspålidelighed, hvilket resulterer i detaljeret testdækning. Hvis du ikke bliver bedt om at være en del af denne udviklingscyklus, kan du bede din leder eller leder om at involvere dit testteam i alle beslutningsprocesser eller møder.

# 17) Testhold skal dele bedste testpraksis , erfaring med de andre hold i deres organisation.

# 18) Forøg din samtale med udviklerne at vide mere om produktet. Lav så vidt muligt ansigt til ansigt kommunikation for hurtigt at løse tvister og for at undgå misforståelser.

Men også når du forstår kravet eller løser enhver tvist - sørg for at kommunikere de samme overskrevne kommunikationsmåder som e-mails. Hold ikke noget verbalt.

# 19) Kør ikke For sent at udføre testopgaver med høj prioritet. Prioriter dit testarbejde fra høj til lav prioritet, og planlæg dit arbejde i overensstemmelse hermed. Analyser alle tilknyttede risici for at prioritere dit arbejde.

# 20) Skriv en klar, beskrivende, utvetydig Fejlrapport . Giv ikke kun fejlsymptomerne, men også effekten af ​​bugten og alle de mulige løsninger.

Glem ikke, at test er en kreativ og udfordrende opgave. Endelig afhænger det hele af din dygtighed og erfaring med, hvordan du håndterer denne udfordring.

Over til dig:

er der et vr headset til xbox 360

Deling af din egen testoplevelse, tip eller test af hemmeligheder i kommentarerne nedenfor vil helt sikkert gøre denne artikel mere interessant og hjælpsom !!

Fortæl os dine tanker / forslag om denne artikel.

Anbefalet læsning


^