how find bug application
Un punct foarte bun și important. Dreapta? Dacă sunteți un software de testare sau un inginer QA, atunci trebuie să vă gândiți în fiecare minut pentru a găsi o eroare într-o aplicație. Și ar trebui să fii!
Cred că găsirea unui Bug de blocare ca oricare Crash de sistem este adesea plină de satisfacții! Nu, nu cred așa. Ar trebui să încercați să aflați erorile care sunt cel mai dificil de găsit și care întotdeauna induc în eroare utilizatorii.
Găsirea unor astfel de bug-uri subtile este cea mai provocatoare lucrare și îți oferă satisfacția muncii tale. De asemenea, ar trebui să fie recompensat de către seniori. Voi împărtăși experiența mea cu un astfel de bug subtil care nu numai că a fost greu de prins, dar a fost dificil de reprodus și.
Testam un modul din proiectul meu de motor de căutare. Majoritatea activităților acestui proiect le fac manual, deoarece este puțin complex de automatizat. Acest modul constă în statistici privind traficul și veniturile diferiților afiliați și agenți de publicitate. Așadar, testarea unor astfel de rapoarte este întotdeauna o sarcină dificilă.
Când am testat acest raport, acesta arăta datele procesate cu precizie pentru o perioadă de timp, dar când a încercat să testez din nou după un timp, a arătat rezultate înșelătoare. A fost ciudat și confuz să vezi rezultatele.
A existat un Cron (Cron este un script automat care rulează după timpul sau condiția specificată) pentru a procesa fișierele jurnal și a actualiza baza de date. Astfel de culturi multiple rulează pe fișiere jurnal și DB pentru a sincroniza datele totale.
Erau doi Croni care alergau pe o singură masă cu câteva intervale de timp.
În tabel era o coloană care a fost suprascrisă de către alți Cron, ceea ce face ca unele date să fie inconsistente. Ne-a luat mult timp să ne dăm seama de problema datorită vastelor procese DB și a diferitelor Crons.
Ideea mea este să încerc să aflu erorile ascunse din sistem care ar putea apărea pentru condiții speciale și care vor avea un impact puternic asupra sistemului. Puteți găsi un astfel de bug cu câteva sfaturi și trucuri.
întrebări de interviuri de reglare a performanței oracle dba
Deci, care sunt aceste sfaturi:
# 1) Înțelegeți întreaga aplicație sau modul în profunzime înainte de a începe testarea.
#Două) A pregati teste bune înainte de a începe testarea. Adică acordați stres asupra cazurilor de testare funcțională care includ riscul major al aplicației.
# 3) Crea date de test suficiente înainte de teste, acest set de date include condițiile cazului de testare și, de asemenea, înregistrările bazei de date dacă urmează să testați aplicația legată de DB.
# 4) Efectuați teste repetate cu mediu de testare diferit .
# 5) Încercați să aflați model rezultat și apoi comparați-vă rezultatele cu acele tipare.
# 6) Când crezi că ai îndeplinit majoritatea condițiilor de testare și când crezi că ești oarecum obosit atunci faceți câteva teste de maimuță.
# 7) Folosiți-vă anterior Model de date de testare pentru a analiza setul actual de teste.
# 8) Încercați câteva Cazuri de testare standard pentru care ați găsit erorile într-o aplicație diferită. De exemplu, dacă testați caseta text de intrare, încercați să inserați niște etichete HTML ca intrări și să vedeți rezultatul pe pagina de afișare.
# 9) Ultimul și cel mai bun truc este să încercați foarte mult să găsiți eroarea. Ca și cum ai testa doar pentru a sparge aplicația!
Voi include mai multe sfaturi în câteva postări viitoare. Între timp, puteți comenta mai multe sfaturi aici.
Lectură recomandată
- Cum se scrie un raport bun de eroare? Sfaturi și trucuri
- Top 20 de sfaturi practice de testare a software-ului pe care ar trebui să le citiți înainte de a testa orice aplicație
- Ce este testarea maimuțelor în testarea software-ului?
- Diferența dintre Desktop, Client Server Testing și Web Testing
- Exemplu de raport de erori
- Testarea aplicațiilor medicale - sfaturi și scenarii importante de testare (partea 2)
- Ghid de testare a securității aplicațiilor web
- 7 sfaturi de bază pentru testarea site-urilor web multilingve