how find bug application
Zelo dobra in pomembna točka. Prav? Če ste preizkuševalec programske opreme ali inženir QA, morate vsako minuto razmišljati, da bi našli napako v aplikaciji. In bi morali biti!
Mislim, da je iskanje a Napaka blokatorja kot katera koli System Crash je pogosto koristno! Ne, ne mislim tako. Poskusite najti napake, ki jih je najtežje najti in ki vedno zavajajo uporabnike.
Iskanje takšnih prefinjenih napak je najbolj zahtevno delo in vam prinaša zadovoljstvo pri delu. Prav tako bi ga morali nagrajevati starejši. Delil bom svoje izkušnje z eno tako prefinjeno napako, ki je ni bilo le težko ujeti, ampak jo je bilo tudi težko razmnožiti.
Testiral sem en modul iz mojega projekta iskalnika. Večino dejavnosti tega projekta opravljam ročno, saj je avtomatizacija nekoliko zapletena. Ta modul vsebuje statistiko prometa in prihodkov različnih podružnic in oglaševalcev. Torej je preizkušanje takih poročil vedno težka naloga.
Ko sem preizkusil to poročilo, je nekaj časa prikazoval podatke, ki so bili natančno obdelani, ko pa sem čez nekaj časa poskusil znova preizkusiti, so pokazali zavajajoče rezultate. Bilo je nenavadno in zmedeno videti rezultate.
Za obdelavo dnevniških datotek in posodobitev baze podatkov je obstajal Cron (Cron je samodejni skript, ki se zažene po določenem času ali stanju). Takšni večkratni pridelki se izvajajo v dnevniških datotekah in DB za sinhronizacijo skupnih podatkov.
Na eni mizi sta tekla dva krona z nekaj časovnimi presledki.
V tabeli je bil stolpec, ki ga je drugi Cron prepisoval, zaradi česar so bili podatki neskladni. Dolgo časa smo raziskovali težavo zaradi obsežnih procesov DB in različnih kronov.
Moja poizkus poskuša ugotoviti skrite napake v sistemu, ki se lahko pojavijo v posebnih pogojih in povzročijo močan vpliv na sistem. Takšno napako najdete z nekaj nasveti in triki.
b-drevo vs b + drevo
Torej, kakšni so ti nasveti:
# 1) Razumevanje celotne aplikacije ali modul poglobljeno pred začetkom testiranja.
#two) Pripravite se dobri testni primeri pred začetkom testiranja. Poudarim funkcionalne testne primere, ki vključujejo največje tveganje za uporabo.
# 3) Ustvari zadostnih testnih podatkov pred preskusi ta nabor podatkov vključuje pogoje testnega primera in tudi zapise baze podatkov, če boste testirali aplikacijo, povezano z DB.
# 4) Ponovite teste z različno testno okolje .
# 5) Poskusite ugotoviti nastali vzorec in nato rezultate primerjajte s temi vzorci.
# 6) Ko mislite, da ste opravili večino testnih pogojev in ko mislite, da ste takrat nekoliko utrujeni opravi nekaj opic.
# 7) Uporabite prejšnjo Vzorec testnih podatkov za analizo trenutnega sklopa testov.
# 8) Poskusite nekaj Standardni testni primeri za katere ste napake našli v neki drugačni aplikaciji. Tako kot če testirate vnosno polje z besedilom, poskusite vstaviti nekaj oznak HTML kot vhode in si oglejte izhodne podatke na prikazni strani.
# 9) Zadnji in najboljši trik je, da se zelo potrudite najti napako. Kot da testirate samo zato, da razbijete aplikacijo!
V nekaj prihodnjih objavah bom vključil več nasvetov. Medtem lahko tukaj napišete več nasvetov.
Priporočeno branje
- Kako napisati dobro poročilo o napaki? Namigi in triki
- 20 najboljših praktičnih nasvetov za preizkušanje programske opreme, ki jih morate prebrati, preden preizkusite katero koli aplikacijo
- Kaj je testiranje opic pri testiranju programske opreme?
- Razlika med testiranjem namizja, odjemalskega strežnika in spletnim preskušanjem
- Vzorčno poročilo o napaki
- Testiranje zdravstvenih aplikacij - nasveti in pomembni testni scenariji (2. del)
- Vodič za preizkušanje varnosti spletnih aplikacij
- 7 osnovnih nasvetov za preizkušanje večjezičnih spletnih strani