how find bug application
Un punt molt bo i important. Dret? Si sou un provador de programari o un enginyer de control de qualitat, haureu de pensar cada minut per trobar un error en una aplicació. I ho hauries de ser!
Crec que trobar un Error de bloqueig com qualsevol Bloqueig del sistema sovint és gratificant! No, no crec així. Heu d'intentar esbrinar els errors que són més difícils de trobar i que sempre enganyen els usuaris.
Trobar errors tan subtils és el treball més difícil i us proporciona la satisfacció del vostre treball. A més, hauria de ser recompensat per persones grans. Compartiré la meva experiència d’un error tan subtil que no només va ser difícil d’atrapar, sinó que també va ser difícil de reproduir.
Provava un mòdul del meu projecte de cerca. Faig la majoria de les activitats d’aquest projecte manualment, ja que és una mica complex d’automatitzar. Aquest mòdul consisteix en estadístiques de trànsit i ingressos de diferents afiliats i anunciants. Per tant, provar aquests informes sempre és una tasca difícil.
Quan vaig provar aquest informe, mostrava les dades processades amb precisió durant algun temps, però quan es va intentar tornar a provar al cap de temps mostrava resultats enganyosos. Va ser estrany i confús veure els resultats.
Hi havia un Cron (Cron és un script automatitzat que s’executa després d’un temps o condició especificats) per processar els fitxers de registre i actualitzar la base de dades. Aquests cultius múltiples s’executen als fitxers de registre i a la base de dades per sincronitzar les dades totals.
Hi havia dos Crons corrent sobre una taula amb alguns intervals de temps.
Hi havia una columna a la taula que altres Cron sobreescrivien i feia que algunes dades fossin incoherents. Vam trigar molt a esbrinar el problema a causa dels amplis processos de DB i de diferents Crons.
El meu punt és intentar esbrinar els errors ocults del sistema que es poden produir per condicions especials i causar un fort impacte en el sistema. Podeu trobar aquest error amb alguns consells i trucs.
preguntes d’entrevistes de programació java per a experimentats
Quins són aquests consells:
# 1) Enteneu tota l'aplicació o mòdul en profunditat abans de començar la prova.
# 2) Prepareu-vos bons casos de prova abans de començar a provar. Vull dir posar èmfasi en els casos de proves funcionals que inclouen el major risc de l'aplicació.
# 3) Crear Dades de prova suficients abans de les proves, aquest conjunt de dades inclou les condicions del cas de prova i també els registres de la base de dades si voleu provar l'aplicació relacionada amb la base de dades.
# 4) Realitzeu proves repetides amb el entorn de prova diferent .
# 5) Intenta esbrinar el patró resultant i, a continuació, compareu els resultats amb aquests patrons.
# 6) Quan creieu que heu completat la majoria de les condicions de la prova i quan creieu que esteu cansats una mica fer proves de mico.
# 7) Utilitzeu el vostre anterior Patró de dades de prova per analitzar el conjunt actual de proves.
# 8) Proveu-ne alguns Casos de prova estàndard per al qual heu trobat els errors en alguna aplicació diferent. Igual que si proveu un quadre de text d'entrada, intenteu inserir algunes etiquetes HTML com a entrades i consulteu la sortida a la pàgina de visualització.
# 9) El darrer i el millor truc és intentar molt dur per trobar l’error. Com si provés només per trencar l’aplicació.
Inclouré més consells en algunes properes publicacions. Mentrestant, podeu comentar més consells aquí.
Lectura recomanada
- Com escriure un bon informe d'errors? Consells i trucs
- Els 20 millors consells pràctics sobre proves de programari que heu de llegir abans de provar qualsevol aplicació
- Què és la prova de mico en la prova de programari?
- Diferència entre la prova d'escriptori, el servidor de clients i la prova web
- Exemple d’informe d’errors
- Proves d'aplicacions sanitàries: consells i escenaris importants de proves (part 2)
- Guia de proves de seguretat d'aplicacions web
- 7 consells bàsics per provar llocs web multilingües