top 20 practical software testing tips you should read before testing any application
Desitjo que tots els verificadors llegeixin les pràctiques de proves de programari actualitzades en aquest article . Llegiu cada punt detingudament i intenteu implementar-los en les vostres activitats de proves quotidianes. Això és el que espero dels lectors a través d’aquest article. Si no enteneu cap pràctica de prova, demaneu més aclariments a la secció de comentaris a continuació.
Tot i això, aprendreu totes aquestes pràctiques de proves per experiència. Però, per què no apreneu totes aquestes coses abans d’equivocar-vos?
Vine a fer una ullada ells!
Aquí hi ha algunes de les millors pràctiques de prova que he après per experiència:
què és la prova beta en proves de programari
# 1) Apreneu a analitzar a fons els resultats de les proves. No ignoreu els resultats de les proves. El resultat final de la prova pot ser 'aprovar' o 'fallar', però la resolució de problemes de la causa principal de 'error' us donarà la solució al problema. Els comprovadors seran respectats si no només registren el fitxer Errors però també aportar solucions.
# 2) Apreneu a maximitzar el Cobertura de la prova cada vegada que proveu qualsevol aplicació. És possible que la cobertura del 100% de les proves no sigui possible, però sempre podeu provar d’arribar-hi.
# 3) Per tal de garantir la màxima cobertura de les proves, divideix la teva aplicació sota prova (AUT) en mòduls funcionals més petits. Escriviu casos de prova en aquests mòduls individuals. També si és possible, trenca aquests mòduls en parts més petites.
Per exemple, suposem que heu dividit l’aplicació del lloc web en mòduls i que ‘accepta la informació de l’usuari’ és un dels mòduls. Podeu dividir aquesta pantalla 'Informació de l'usuari' en parts més petites per escriure casos de prova: parts com la prova de la IU, Proves de seguretat , Proves funcionals del formulari 'Informació de l'usuari', etc.
Apliqueu totes les proves de tipus i mida de camp de formulari, proves de negatiu i de validació als camps d’entrada i escriviu tots aquests casos de prova per obtenir una cobertura màxima.
# 4) Mentre Escriptura de casos de proves , escriviu primer casos de prova per a la funcionalitat prevista, és a dir, per a condicions vàlides segons els requisits. A continuació, escriviu casos de prova per a condicions no vàlides. Això cobrirà el comportament esperat i inesperat de l'aplicació sotmesa a prova.
# 5) Penseu en positiu. Comenceu a provar l'aplicació amb la intenció de trobar errors / errors. No penseu prèviament que no hi haurà cap error a l’aplicació. Si proveu l'aplicació amb la intenció de trobar errors, segur que ho aconseguirà Bugs subtils també.
# 6) Escriviu els vostres casos de prova a la pròpia fase d’anàlisi de requisits i disseny. D'aquesta manera, podeu assegurar-vos que es puguin comprovar tots els requisits.
# 7) Feu el vostre proves de casos disponibles per als desenvolupadors abans de codificar. No deixeu els casos de prova a l’espera d’obtenir la versió final de l’aplicació per a la prova, pensant que podeu registrar més errors. Deixeu que els desenvolupadors analitzin els casos de prova a fons per desenvolupar una aplicació de qualitat. Això també permetrà estalviar temps de reelaboració.
# 8) Si és possible identificar i agrupeu els vostres casos de prova Proves de regressió . D’aquesta manera, es garantirà una prova manual de regressió ràpida i eficaç.
# 9) Les aplicacions que requereixen un temps de resposta crític s’han de comprovar a fons el rendiment. Proves de rendiment és una part crítica de moltes aplicacions. En manual Les proves, aquesta és la part més ignorada pels verificadors a causa de la manca de gran volum de dades requerit en les proves de rendiment.
Esbrineu les maneres de provar el rendiment de la vostra aplicació. Si no és possible crear dades de prova manualment, escriviu alguns scripts bàsics per crear dades de prova per a proves de rendiment o demaneu als desenvolupadors que en escriguin un.
# 10) Els programadors no han de provar el seu propi codi. Com es comenta al nostre document publicació anterior , La prova unitària bàsica de les aplicacions desenvolupades hauria de ser suficient perquè els desenvolupadors publiquessin l'aplicació per als provadors. Però (provador) no heu d’obligar els desenvolupadors a llançar el producte per provar-lo.
fusiona el codi de classificació C ++
Que es prenguin el seu propi temps. Tothom, des del responsable fins al gestor, sap quan es publica el mòdul / actualització per a la prova i pot estimar el temps de prova en conseqüència. Aquesta és una situació típica en un Àgil entorn del projecte.
# 11) Aneu més enllà de les proves de requisits. Comproveu l'aplicació del que no se suposa que ha de fer.
# 12) Mentre feia proves de regressió utilitzeu el gràfic d’errors anterior (Gràfic d'errors: nombre d'errors trobats a temps per a diferents mòduls). Aquest gràfic d'errors basat en mòduls pot ser útil per predir la part d'errors més probable de l'aplicació.
# 13) Anoteu els nous termes, conceptes que apreneu mentre proveu. Mantingueu obert un fitxer de text mentre proveu qualsevol aplicació. Anoteu el progrés i les observacions de les proves en ell. Utilitzeu aquestes observacions del bloc de notes mentre prepareu l'informe final de la versió de la prova. Aquest bon hàbit us ajudarà a proporcionar un informe de proves complet i inequívoc i detalls de la versió.
# 14) Moltes vegades els provadors o desenvolupadors fan canvis a la base de codi per a l'aplicació que es prova. Aquest és un pas obligatori en l'entorn de desenvolupament o proves per evitar l'execució del processament de transaccions en directe com en els projectes bancaris.
Anoteu tots aquests canvis de codi realitzats a efectes de proves i en el moment de la versió final, assegureu-vos que heu eliminat tots aquests canvis dels recursos finals del fitxer de desplegament del costat del client.
# 15) Mantingueu els desenvolupadors allunyats de l’entorn de prova. Es requereix un pas per detectar els canvis de configuració que falten al document de llançament o desplegament. De vegades, els desenvolupadors fan alguns canvis en la configuració del sistema o de l’aplicació, però s’obliden d’esmentar-los als passos de desplegament.
Si els desenvolupadors no tenen accés a l’entorn de prova, no faran aquests canvis accidentalment a l’entorn de prova i aquestes coses que falten es poden capturar al lloc adequat.
# 16) És una bona pràctica involucrar provadors des de la pròpia fase de requisits i disseny de programari. D'aquesta manera, els verificadors poden obtenir coneixement de la fiabilitat de l'aplicació, cosa que proporciona una cobertura detallada de les proves. Si no se us demana que formeu part d'aquest cicle de desenvolupament, podeu fer una sol·licitud al vostre responsable o gerent perquè participi el vostre equip de proves en tots els processos de presa de decisions o reunions.
# 17) Els equips de proves ho haurien de fer compartir les millors pràctiques de proves , experiència amb els altres equips de la seva organització.
# 18) Augmenteu la vostra conversa amb els desenvolupadors per saber més sobre el producte. Sempre que sigui possible, feu comunicacions cara a cara per resoldre els conflictes amb rapidesa i evitar malentesos.
Però també quan entengueu el requisit o resoleu qualsevol controvèrsia: assegureu-vos de comunicar les mateixes formes de comunicació sobreescrites com els correus electrònics. No mantingueu res verbal.
# 19) No córrer Sense temps per fer tasques de proves d'alta prioritat. Doneu prioritat al vostre treball de proves d’alta a baixa prioritat i planifiqueu el vostre treball en conseqüència. Analitzeu tots els riscos associats per donar prioritat al vostre treball.
# 20) Escriviu un document clar, descriptiu i inequívoc Informe d'error . No només proporcioneu els símptomes de l'error, sinó que també proporcioneu l'efecte de l'error i totes les solucions possibles.
No oblideu que provar és una tasca creativa i desafiant. Finalment, tot depèn de la vostra habilitat i experiència quant a la manera d’afrontar aquest repte.
A vosaltres:
Compartir la vostra pròpia experiència de proves, consells o proves de secrets als comentaris següents farà que aquest article sigui més interessant i útil.
Feu-nos saber els vostres pensaments / suggeriments sobre aquest article.
Lectura recomanada
- Les millors eines de prova de programari 2021 [Eines d'automatització de proves de control de qualitat]
- Prova de programari Treball d'assistent de control de qualitat
- Les proves de programari són una tasca emocional?
- Curs de proves de programari: a quin institut de proves de programari m'he d'afegir?
- Selecció de proves de programari com a carrera professional
- Prova de programari Treball freelance d'escriptor de contingut tècnic
- Què és la prova de mico en la prova de programari?
- Proves d'aplicacions: els conceptes bàsics de la prova de programari.