how find bug application
En mycket bra och viktig punkt. Rätt? Om du är en programvarutestare eller en QA-ingenjör måste du tänka varje minut för att hitta ett fel i en applikation. Och det borde du vara!
Jag tror att hitta en Blocker Bug som alla andra Systemkrasch är ofta givande! Nej, jag tänker inte så. Du bör försöka ta reda på de buggar som är svårast att hitta och som alltid vilseleder användarna.
Att hitta sådana subtila buggar är det mest utmanande arbetet och det ger dig tillfredsställelsen i ditt arbete. Det bör också belönas av seniorer. Jag kommer att berätta om mina erfarenheter av ett sådant subtilt fel som inte bara var svårt att fånga utan också var svårt att reproducera.
Jag testade en modul från mitt sökmotorprojekt. Jag utför de flesta aktiviteterna i detta projekt manuellt eftersom det är lite komplicerat att automatisera. Den modulen består av trafik- och intäktsstatistik för olika dotterbolag och annonsörer. Att testa sådana rapporter är alltid en svår uppgift.
När jag testade denna rapport visade den att uppgifterna bearbetades korrekt under en tid men när jag försökte testa igen efter en tid visade det vilseledande resultat. Det var konstigt och förvirrande att se resultaten.
Det fanns en Cron (Cron är ett automatiskt skript som körs efter angiven tid eller villkor) för att bearbeta loggfilerna och uppdatera databasen. Sådana flera grödor körs på loggfiler och DB för att synkronisera den totala informationen.
Det var två Crons som körde på ett bord med några tidsintervall.
Det fanns en kolumn i tabellen som blev överskriven av andra Cron som gjorde vissa data inkonsekvent. Det tog oss lång tid att räkna ut problemet på grund av de stora DB-processerna och olika Crons.
Min poäng är att försöka ta reda på de dolda buggarna i systemet som kan uppstå för speciella förhållanden och orsakar en stark inverkan på systemet. Du kan hitta en sådan bugg med några tips och tricks.
skapa ett nytt java-projekt i förmörkelse
Så vad är dessa tips:
# 1) Förstå hela applikationen eller modul på djupet innan testet påbörjas.
#två) Förbereda bra testfall innan du börjar testa. Jag menar ge stress på de funktionella testfall som inkluderar den största risken för applikationen.
# 3) Skapa tillräckliga testdata före tester innehåller denna dataset testförhållandena och även databasposterna om du ska testa DB-relaterad applikation.
# 4) Utför upprepade tester med olika testmiljöer .
# 5) Försök ta reda på resulterande mönster och jämför sedan dina resultat med dessa mönster.
# 6) När du tror att du har slutfört de flesta testförhållandena och när du tror att du är trött något då gör lite apatestning.
# 7) Använd din tidigare Testdatamönster för att analysera den aktuella uppsättningen tester.
# 8) Prova lite Standard testfall för vilka du hittade buggarna i någon annan applikation. Som om du testar inmatad textruta, försök att infoga några HTML-taggar som ingångar och se utdata på visningssidan.
# 9) Det sista och det bästa tricket är att försöka hårt för att hitta felet. Som om du bara testar för att bryta applikationen!
Jag kommer att ta med fler tips i några kommande inlägg. Under tiden kan du kommentera fler tips här.
Rekommenderad läsning
- Hur man skriver en bra felrapport? Tips och tricks
- Topp 20 praktiska testtips för programvara du bör läsa innan du testar någon applikation
- Vad är Monkey Testing i Software Testing?
- Skillnad mellan Desktop, Client Server Testing och Web Testing
- Exempel på felrapport
- Testa sjukvårdsprogram - Tips och viktiga testscenarier (del 2)
- Guide för testning av webbapplikationssäkerhet
- 7 grundläggande tips för testning av flerspråkiga webbplatser