how find bug application
Et veldig bra og viktig poeng. Ikke sant? Hvis du er en programvaretester eller en kvalitetsingeniør, må du tenke hvert minutt å finne en feil i et program. Og det burde du være!
Jeg tror å finne en Blocker Bug som alle andre Systemkrasj er ofte givende! Nei, jeg tenker ikke slik. Du bør prøve å finne ut hvilke feil som er vanskeligst å finne, og som alltid villeder brukere.
Å finne slike subtile bugs er det mest utfordrende arbeidet, og det gir deg tilfredsheten med arbeidet ditt. Også, det skal belønnes av eldre. Jeg vil dele min erfaring med en slik subtil feil som ikke bare var vanskelig å fange, men som også var vanskelig å reprodusere.
Jeg testet en modul fra søkemotorprosjektet mitt. Jeg gjør de fleste aktivitetene i dette prosjektet manuelt, da det er litt komplisert å automatisere. Den modulen består av trafikk- og inntektsstatistikk for forskjellige tilknyttede selskaper og annonsører. Så å teste slike rapporter er alltid en vanskelig oppgave.
Da jeg testet denne rapporten, viste den dataene som ble behandlet nøyaktig i noen tid, men da jeg prøvde å teste igjen etter en tid, viste det misvisende resultater. Det var rart og forvirrende å se resultatene.
Det var en Cron (Cron er et automatisert skript som kjører etter angitt tid eller tilstand) for å behandle loggfilene og oppdatere databasen. Slike flere avlinger kjører på loggfiler og DB for å synkronisere totaldataene.
Det var to Crons som kjørte på ett bord med noen tidsintervaller.
Det var en kolonne i tabellen som ble overskrevet av andre Cron som gjorde noe data inkonsekvent. Det tok oss lang tid å finne ut av problemet på grunn av de store DB-prosessene og forskjellige Crons.
Poenget mitt prøver å finne ut de skjulte feilene i systemet som kan oppstå under spesielle forhold og forårsaker en sterk innvirkning på systemet. Du kan finne en slik feil med noen tips og triks.
hva gjør en betatester
Så hva er disse tipsene:
#1) Forstå hele søknaden eller modulen i dybden før du starter testingen.
#to) Forberede gode testtilfeller før du begynner å teste. Jeg mener gi stress på de funksjonelle testtilfellene som inkluderer den største risikoen ved applikasjonen.
# 3) Skape tilstrekkelig testdata før tester inkluderer dette datasettet testtilstandsbetingelsene og også databaseregistreringene hvis du skal teste DB-relatert applikasjon.
# 4) Utfør gjentatte tester med forskjellige testmiljøer .
# 5) Prøv å finne ut resulterende mønster og sammenlign deretter resultatene dine med disse mønstrene.
# 6) Når du tenker at du har fullført de fleste testforholdene og når du tror du er sliten noe da gjøre noen Monkey Testing.
# 7) Bruk din forrige Test Data mønster for å analysere gjeldende sett med tester.
# 8) Prøv litt Standard testtilfeller som du fant feilene i et annet program. Som om du tester inntastingsboksen, prøv å sette inn noen HTML-koder som inngangene og se utdataene på skjermsiden.
# 9) Det siste og beste trikset er å prøve veldig hardt for å finne feilen. Som om du bare tester for å bryte søknaden!
Jeg vil ta med flere tips i noen kommende innlegg. I mellomtiden kan du kommentere flere tips her.
Anbefalt lesing
- Hvordan skriver jeg en god feilrapport? Tips og triks
- Topp 20 praktiske tips om programvaretesting du bør lese før du tester applikasjoner
- Hva er Monkey Testing i Software Testing?
- Forskjellen mellom stasjonær, klientservertesting og nettesting
- Eksempel på feilrapport
- Testing av helseprogrammer - tips og viktige testscenarier (del 2)
- Veiledning for testing av webapplikasjoner
- 7 grunnleggende tips for testing av flerspråklige nettsteder