Com escriure casos de prova: la guia definitiva amb exemples

how write test cases

En aquest tutorial pràctic detallat sobre com escriure casos de prova, he tractat els detalls del que és un cas de prova, la seva definició estàndard i les tècniques de disseny de casos de prova.

Què és un cas de prova?

Un cas de prova té components que descriuen l'entrada, l'acció i la resposta esperada, per tal de determinar si una característica d'una aplicació funciona correctament.

Un cas de prova és un conjunt d’instruccions sobre “COM” per validar un objectiu / objectiu de prova concret que, quan se segueix, ens indicarà si es compleix o no el comportament esperat del sistema.

Llista de tutorials coberts en aquesta sèrie d'escriptura de casos de prova:

Com escriure:

Tutorial # 1: Què és un cas de prova i com escriure casos de prova (aquest tutorial)
Tutorial # 2: Exemple de plantilla de cas de prova amb exemples [Descarregar] (ha de llegir)
Tutorial # 3: Redacció de casos de prova a partir de documents SRS
Tutorial # 4: Com escriure casos de prova per a un escenari determinat
Tutorial # 5: Com preparar-se per escriure casos de proves
Tutorial # 6: Com escriure casos de prova negatius

Exemples:

Tutorial # 7: Més de 180 casos de prova de mostra per a aplicacions web i d'escriptori
Tutorial # 8: Més de 100 escenaris de prova preparats per executar (llista de comprovació)

Tècniques d'escriptura:

Tutorial # 9: Gràfic de causes i efectes: tècnica d'escriptura de casos dinàmics de proves
Tutorial # 10: Tècnica de proves de transició estatal
Tutorial # 11: Tècnica de proves de matriu ortogonal
Tutorial # 12: Tècnica d’endevinació d’errors
Tutorial # 13: Tècnica de disseny de proves de la taula de validació de camp (FVT)

Cas de prova contra escenaris de prova:

Tutorial # 14: Casos de prova vs. escenaris de prova
Tutorial # 15: Diferència entre pla de prova, estratègia de prova i cas de prova

Automatització:

Tutorial # 16: Com seleccionar casos de prova correctes per a proves d'automatització
Tutorial # 17: Com es tradueixen casos de prova manuals a scripts d'automatització

Eines de gestió de proves:

Tutorial # 18: Les millors eines de gestió de proves
Tutorial # 19: TestLink per a la gestió de casos de prova
Tutorial # 20: Creació i gestió de casos de prova mitjançant HP Quality Center
Tutorial # 21: Execució de casos de prova mitjançant ALM / QC

Casos específics de domini:

Tutorial # 22: Casos de prova per a aplicacions ERP
Tutorial # 23: Casos de proves d'aplicació JAVA
Tutorial # 24: Anàlisi del valor límit i particionament d'equivalència

Continuem amb el primer tutorial d'aquesta sèrie.

Eines recomanades:

Abans de continuar amb el procés d'escriptura de casos de prova, es recomana descarregar aquesta eina de gestió de casos de prova. Això facilitarà el procés d’escriptura de casos de prova esmentat en aquest tutorial:

# 1) TestRail

=> Descarregueu l'eina de gestió de casos de proves TestRail

# 2) TestMonitor

Gestió de proves en línia de primer nivell. Fàcil revolucionari.

TestMonitor és una eina de gestió de proves de punta a punta per a totes les organitzacions. Un enfocament senzill i intuïtiu de les proves. Ja sigui que estigueu implementant programari empresarial, que necessiteu control de qualitat, que creeu una aplicació de qualitat o que només necessiteu un cop de mà en el vostre projecte de prova, TestMonitor us ofereix.

com puc reproduir fitxers swf

=> Visiteu el lloc web TestMonitor

Què aprendreu:

• Què és un cas de prova i com escriure casos de prova?
  • Per què escrivim proves?
  • Com escriure casos de prova?
  • Format bàsic de la declaració de cas de prova
• Consells per escriure proves
  • • # 1) Mantingueu-ho senzill però no massa senzill; fer-ho complex però no massa complex:
    • # 2) Després de documentar els casos de prova, reviseu-los una vegada com a provador:
    • # 3) Enquadernat i facilitat als verificadors:
    • # 4) Col·labora:
    • # 5) Mai oblideu l'usuari final:
• Com aconseguir l’excel·lència en la documentació de casos de prova
  • Consells i trucs útils
    • # 1) El document de prova està en bona forma?
    • # 2) No oblideu cobrir els casos negatius
    • # 3) Teniu passos de prova atòmica
    • # 4) Prioritzeu les proves
    • # 5) La seqüència és important
    • # 6) Afegiu la marca de temps i el nom del provador als comentaris
    • # 7) Inclou els detalls del navegador
    • # 8) Conserveu dos fulls separats: 'Errors' i 'Resum' al document
• Com NO escriure proves
  • 3 Problemes més freqüents en casos de prova
    • # 1) Passos compostos
    • # 2) El comportament de l'aplicació es pren com a comportament esperat
    • # 3) Condicions múltiples en un cas
• Com millorar l’eficiència dels casos de prova
  • Col·lecció de documents per a la redacció de proves
  • Exemple real
  • Document de cas de prova
  • Recollida de dades de prova
• Importància de normalitzar els casos de prova
  • Motius per reutilitzar casos de prova
  • Què és una prova estàndard en proves web?
  • Conclusió
  • Lectura recomanada

Què és un cas de prova i com escriure casos de prova?

Escriure casos efectius és una habilitat. I podeu aprendre-ho amb l’experiència i el coneixement de l’aplicació que es prova.

Per obtenir instruccions bàsiques sobre com escriure proves, consulteu el vídeo següent:

Els recursos anteriors ens han de proporcionar els fonaments del procés d’escriptura de proves.

Nivells del procés d'escriptura de la prova:

• Nivell 1: En aquest nivell, escrivireu el fitxer casos bàsics a partir de l’especificació disponible i documentació de l'usuari.
• Nivell 2: Aquest és el etapa pràctica en què els casos d’escriptura depenen del flux funcional i del sistema real de l’aplicació.
• Nivell 3: Aquesta és l'etapa en què agruparà alguns casos i escriure un procediment de prova . El procediment de prova no és res més que un grup de casos petits, potser un màxim de 10.
• Nivell 4: Automatització del projecte. Això minimitzarà la interacció humana amb el sistema i, per tant, el control de qualitat es pot centrar en les funcionalitats actualitzades actualment per provar en lloc de mantenir-se ocupat amb les proves de regressió.

Per què escrivim proves?

L’objectiu bàsic d’escriure casos és per validar la cobertura de proves d’una sol·licitud.

Si esteu treballant en qualsevol organització CMMi, els estàndards de prova es segueixen més de prop. L’escriptura de casos comporta algun tipus d’estandardització i minimitza l’enfocament ad-hoc en les proves.

Com escriure casos de prova?

Camps:

• Identificador del cas de prova
• Unitat per provar: Què cal verificar?
• Supòsits
• Dades de prova: Variables i els seus valors
• Passos a executar
• Resultat Esperat
• Resultat real
• Aprovació / suspensió
• Comentaris

Format bàsic de la declaració de cas de prova

Verifiqueu
Utilitzant [nom de l'eina, nom de l'etiqueta, diàleg, etc.]
Amb [condicions]
Per a [el que es retorna, es mostra, es demostra]

Verifiqueu: S'utilitza com a primera paraula de l'enunciat de prova.
Utilitzant: Per identificar què s’està provant. Podeu utilitzar 'entrar' o 'seleccionar' aquí en lloc d'utilitzar-lo en funció de la situació.

Per a qualsevol aplicació, heu de cobrir tot tipus de proves com:

• Casos funcionals
• Casos negatius
• Casos de valor límit

Mentre escriviu tot això Els TC haurien de ser senzills i fàcils d’entendre .

************************************************

Consells per escriure proves

Una de les activitats més freqüents i importants d'un provador de programari (persona SQA / SQC) és escriure casos i casos de prova.

Hi ha alguns factors importants i crítics relacionats amb aquesta activitat important. En primer lloc, fem una visió d’ocell d’aquests factors.

Factors importants implicats en el procés d'escriptura:

a) Els TC són propensos a la revisió i actualització periòdica:

Vivim en un món que canvia contínuament i el mateix val per al programari. Els canvis de requisits de programari afecten directament els casos. Sempre que s’alteren els requisits, cal actualitzar els TC.

Tot i això, no només el canvi en el requisit pot provocar la revisió i actualització dels TC. Durant l'execució dels TC, sorgeixen moltes idees a la ment i es poden identificar moltes sub-condicions d'un mateix TC. Tot això provoca una actualització dels TC i, de vegades, fins i tot condueix a l'addició de TC nous.

A més, durant les proves de regressió, diverses correccions i / o ondulacions exigeixen revisió o nous TC.

b) Els TC són propensos a distribuir-se entre els provadors que els executaran:

Per descomptat, amb prou feines hi ha tal situació en què un sol provador executi tots els TC. Normalment, hi ha diversos provadors que proven diferents mòduls d'una sola aplicació. Per tant, els TC es divideixen entre els provadors segons les seves àrees de propietat de l’aplicació sotmesa a prova.

Alguns TC relacionats amb la integració de l'aplicació poden ser executats per diversos provadors, mentre que els altres TC només poden ser executats per un sol provador.

c) Els TC són propensos al clúster i al lot:

És normal i comú que els TC que pertanyen a un únic escenari de prova solen exigir la seva execució en una seqüència específica o en forma de grup. Pot haver-hi certs requisits previs d’un TC que exigeixi l’execució d’altres TC abans d’executar-se ell mateix.

De la mateixa manera, segons la lògica de negoci de l'AUT, un sol TC pot contribuir a diverses condicions de prova i una única condició de prova pot consistir en diversos TC.

d) Els TC tenen una tendència d’interdependència:

Aquest també és un comportament interessant i important dels TC que indiquen que poden ser interdependents els uns dels altres. Des d'aplicacions mitjanes a grans amb una lògica empresarial complexa, aquesta tendència és més visible.

L’àrea més clara de qualsevol aplicació on definitivament es pot observar aquest comportament és la interoperabilitat entre diferents mòduls de la mateixa o fins i tot aplicacions diferents. En termes senzills, allà on els diferents mòduls d'una sola aplicació o múltiples aplicacions siguin interdependents, el mateix comportament es reflecteix també en els TC.

e) Els TC són propensos a distribuir-se entre els desenvolupadors (especialment en entorns de desenvolupament basats en proves):

Un fet important sobre els TC és que aquests no només els han de fer servir els provadors. En el cas normal, quan un desenvolupador no està solucionant un error, utilitzen indirectament el TC per solucionar el problema. De la mateixa manera, si se segueix el desenvolupament basat en proves, els desenvolupadors fan servir directament els TC per tal de construir la seva lògica i cobrir tots els escenaris del seu codi que són abordats pels TC.

Consells per escriure proves efectives:

Tenint en compte els cinc factors anteriors, a continuació us oferim alguns consells per escriure TC eficaços.

Comencem!!!

# 1) Mantingueu-ho senzill però no massa senzill; fer-ho complex però no massa complex:

Aquesta afirmació sembla una paradoxa. Però, prometo que no és així. Mantingueu tots els passos dels TC atòmics i precisos. Esmenta els passos amb la seqüència correcta i el mapatge correcte als resultats esperats. El cas de prova s’ha d’explicar per si mateix i és fàcil d’entendre. Això és el que vull dir perquè sigui més senzill.

Ara, convertir-lo en un complex significa integrar-lo amb el pla de proves i altres TC. Consulteu els altres TC, artefactes rellevants, GUI, etc., on i quan sigui necessari. Però feu-ho de manera equilibrada. No feu que un comprovador es mogui cap amunt i cap amunt per la pila de documents per completar un únic escenari de prova.

D'altra banda, ni tan sols deixeu que el provador documenti aquests TC d'una manera molt compacta. Mentre escriviu els TC, recordeu sempre que vosaltres o algú haurà de revisar-los i actualitzar-los.

# 2) Després de documentar els casos de prova, reviseu-los una vegada com a provador:

No penseu mai que la feina s'hagi acabat un cop hàgiu escrit l'últim TC de l'escenari de prova. Aneu al principi i reviseu tots els TC una vegada, però no amb la mentalitat d’un escriptor de TC o d’un planificador de proves. Reviseu tots els TC amb la ment d'un provador. Penseu racionalment i intenteu fer funcionar en sec els vostres TC.

Avalueu tots els passos i comproveu si els heu mencionat de manera clara i comprensible i els resultats esperats coincideixen amb aquests passos.

Assegureu-vos que el fitxer dades de proves especificat als TCs és factible no només per als verificadors reals, sinó que també s’adapta a l’entorn en temps real. Assegureu-vos que no hi hagi cap conflicte de dependència entre els TC i verifiqueu que totes les referències a altres TC / artefactes / GUIs siguin exactes. En cas contrari, els verificadors poden tenir grans problemes.

# 3) Enquadernat i facilitat als verificadors:

No deixeu les dades de la prova als provadors. Proporcioneu-los una gamma d’entrades, especialment quan s’hagin de fer càlculs o el comportament de l’aplicació depèn de les entrades. Podeu deixar que decideixin els valors dels elements de dades de prova, però mai no els podreu escollir ells mateixos.

Com que, intencionadament o no, poden utilitzar les mateixes dades de prova una i altra vegada i algunes dades de prova importants poden ignorar-se durant l'execució dels TC.

Mantingueu els testers a gust organitzant els TC segons les categories de proves i les àrees relacionades d’una aplicació. Clarament, indiqueu i mencioneu quins TC són interdependents i / o per lots. De la mateixa manera, indiqueu explícitament quins TC són independents i aïllats perquè el verificador pugui gestionar la seva activitat general en conseqüència.

En aquest punt, potser us interessa llegir sobre l’anàlisi del valor límit, que és una estratègia de disseny de casos de prova que s’utilitza a les proves de caixa negra. Feu clic a aquí per saber-ne més.

# 4) Col·labora:

No accepteu mai el document de disseny o FS tal com és. El vostre treball no consisteix només a passar pel FS i identificar els escenaris de prova. Com que és un recurs de control de qualitat, no dubteu mai a contribuir al negoci i doneu suggeriments si creieu que es pot millorar alguna cosa a l'aplicació.

Suggeriu-ho també als desenvolupadors, especialment en entorns de desenvolupament basats en TC. Suggeriu llistes desplegables, controls de calendari, llista de selecció, botons d’opció de grup, missatges més significatius, precaucions, indicacions, millores relacionades amb la usabilitat, etc.

Com que és un control de qualitat, no només proveu, sinó que marqueu la diferència.

# 5) Mai oblideu l'usuari final:

L’interès més important és l’usuari final que finalment farà servir l’aplicació. Per tant, no l’oblideu mai en cap etapa de l’escriptura dels TC. De fet, l’usuari final no s’ha d’ignorar en cap moment del SDLC. Tot i així, el meu èmfasi fins ara només està relacionat amb el meu tema.

Per tant, durant la identificació d’escenaris de prova, no oblideu mai aquells casos que l’usuari utilitzarà majoritàriament ni els casos crítics per al negoci, encara que s’utilitzin amb menys freqüència. Mantingueu-vos a la pell de l’usuari final i, a continuació, passeu per tots els TCs i jutgeu el valor pràctic d’executar tots els TCs documentats.

************************************************

Com aconseguir l’excel·lència en la documentació de casos de prova

Com a provador de programari, segur que estareu d’acord amb mi que oferir un document de prova perfecte és realment una tasca difícil.

Sempre deixem algun marge de millora en el nostre Documentació de casos de prova . De vegades, no podem proporcionar una cobertura del 100% de les proves a través dels TC i, de vegades, la plantilla de prova no està a l’alçada o ens falta proporcionar una bona llegibilitat i claredat a les nostres proves.

Com a provador, sempre que se us demani que escriviu documentació de prova, no comenceu de manera ad hoc. És molt important entendre el propòsit d’escriure casos de proves molt abans de treballar en el procés de documentació.

Les proves sempre han de ser clares i lúcides. S'han d'escriure d'una manera que ofereixi al comprovador facilitat per dur a terme les proves completes seguint els passos definits en cadascuna de les proves.

A més, el document del cas de prova hauria de contenir tants casos com calgui per proporcionar-lo complet cobertura de la prova . Per exemple , proveu de cobrir les proves de tots els possibles escenaris que es poden produir a la vostra aplicació de programari.

Tenint en compte els punts anteriors, deixeu-me ara fer-vos un recorregut sobre Com assolir l’excel·lència en la documentació de proves.

Consells i trucs útils

Aquí us oferiré algunes pautes útils que us poden ajudar a la documentació de la prova per part dels altres.

# 1) El document de prova està en bona forma?

La millor manera i senzilla d'organitzar el document de prova és dividint-lo en moltes seccions útils. Dividiu tota la prova en diversos escenaris de prova. A continuació, dividiu cada escenari en diverses proves. Finalment, dividiu cada cas en diversos passos de prova.

Si utilitzeu Excel, documenteu cada cas de prova en un full independent del llibre on cada cas de prova descriu un flux de prova complet.

# 2) No oblideu cobrir els casos negatius

Com a provador de programari, heu de pensar fora de la caixa i traçar totes les possibilitats que ofereix la vostra aplicació. Nosaltres, com a provadors, hem de verificar que si s’ha d’aturar i informar de qualsevol intent autèntic d’entrar al programari o de dades no vàlides que transmetin per l’aplicació.

Per tant, un cas negatiu és tan important com un cas positiu. Assegureu-vos que per a cada escenari que tingueu dos casos de prova: un positiu i un negatiu . El positiu hauria de cobrir el flux previst o normal i el negatiu hauria de cobrir el flux no desitjat o excepcional.

# 3) Teniu passos de prova atòmica

Cada pas de prova ha de ser atòmic. No hi hauria d’haver cap sub-pas més. Com més senzill i clar sigui un pas de prova, més fàcil seria continuar amb la prova.

# 4) Prioritzeu les proves

Sovint tenim terminis estrictes per acabar de provar una aplicació. En aquest cas, ens pot faltar provar algunes de les funcions i aspectes importants del programari. Per evitar-ho, heu d’etiquetar una prioritat amb cada prova mentre la documenteu.

Podeu utilitzar qualsevol codificació per definir la prioritat d'una prova. En general, és millor utilitzar qualsevol dels 3 nivells, alt, mitjà i baix , o bé 1, 50 i 100. Per tant, quan tingueu una línia de temps estricta, primer heu de realitzar totes les proves d'alta prioritat i després passar a les proves de prioritat mitjana i baixa.

Per exemple - per a un lloc web de compres, verificar la denegació d’accés per un intent no vàlid d’iniciar sessió a l’aplicació pot ser un cas de prioritat elevada, la verificació de la visualització de productes rellevants a la pantalla de l’usuari pot ser un cas de prioritat mitjana i la verificació del color del text que es mostra els botons de pantalla poden ser una prova de baixa prioritat.

# 5) La seqüència és important

Confirmeu si la seqüència de passos de la prova és absolutament correcta. Una seqüència incorrecta de passos pot provocar confusió. Preferiblement, els passos també haurien de definir tota la seqüència des de l'entrada a l'aplicació fins a la sortida de l'aplicació per a un escenari concret que s'està provant.

# 6) Afegiu la marca de temps i el nom del provador als comentaris

Pot haver-hi un cas en què proveu una aplicació, algú hi faci modificacions en paral·lel a la mateixa aplicació o algú pugui actualitzar-la després de fer la prova. Això condueix a una situació en què els resultats de les proves poden variar amb el temps.

Per tant, sempre és millor afegir una marca de temps amb el nom del provador als comentaris de la prova de manera que es pugui atribuir un resultat de prova (aprovat o suspès) a l’estat d’una aplicació en aquell moment concret. Com a alternativa, podeu tenir un ‘ Data d'execució ’S’afegeix per separat a la prova que identificarà explícitament la marca de temps de la prova.

# 7) Inclou els detalls del navegador

Com ja sabeu, si es tracta d’una aplicació web, els resultats de les proves poden variar en funció del navegador en què s’executi la prova. Per a la facilitat d'altres provadors, desenvolupadors o qui estigui revisant el document de prova, haureu d'afegir el nom i la versió del navegador a la funda perquè el defecte es pugui replicar fàcilment.

# 8) Conserveu dos fulls separats: 'Errors' i 'Resum' al document

Si esteu documentant en Excel, els dos primers fulls del llibre haurien de ser Resum i Errors. El full de resum hauria de resumir l’escenari de prova i el full d’errors hauria d’enumerar tots els problemes trobats durant la prova. La importància d’afegir aquests dos fulls és que donarà una comprensió clara de les proves al lector / usuari del document.

Per tant, quan es restringeix el temps, aquests dos fulls poden resultar molt útils per proporcionar una visió general de les proves.

El document de prova ha de proporcionar la millor cobertura possible de la prova, una excel·lent llegibilitat i ha de seguir un format estàndard.

Podem assolir l’excel·lència en la documentació de proves només tenint en compte alguns consells essencials com l’organització del document de casos de prova, prioritzant els TC, tenint tot en la seqüència adequada, inclosos tots els detalls obligatoris per executar un TC i proporcionant passos de prova clars i lúcids, etc., tal com s'ha comentat anteriorment.

************************************************

Com NO escriure proves

Dediquem la major part del nostre temps escrivint, revisant, executant o mantenint. És bastant lamentable que les proves també siguin les més propenses a errors. Les diferències en la comprensió, les pràctiques de proves organitzatives, la manca de temps, etc. són alguns dels motius pels quals sovint veiem proves que deixen molt a desitjar.

Hi ha molts articles al nostre lloc sobre aquest tema, però aquí veuràs Com NO escriure casos de prova: alguns consells que seran fonamentals per crear proves distintives, de qualitat i efectives.

Continuem llegint i tingueu en compte que aquests consells són per a provadors nous i experimentats.

3 Problemes més freqüents en casos de prova

1. Passos compostos
2. El comportament de l’aplicació es pren com el comportament esperat
3. Múltiples condicions en un cas

Aquests tres han de figurar a la llista dels tres problemes més habituals del procés d’escriptura de proves.

L’interessant és que succeeixen tant amb provadors nous com experimentats i seguim els mateixos processos defectuosos sense adonar-nos que algunes mesures senzilles poden solucionar les coses fàcilment.

Anem-hi i en parlem detalladament cadascun:

# 1) Passos compostos

En primer lloc, què és un pas compost?

Per exemple, esteu donant indicacions des del punt A fins al punt B: si dieu que 'Aneu al lloc XYZ i després a l'ABC', això no tindrà molt de sentit, perquè aquí ens trobem pensant: 'Com puc arribeu a XYZ en primer lloc ”, en lloc de començar per“ Gireu a l’esquerra d’aquí i aneu 1 milla i, a continuació, gireu a la dreta per Rd. no hi ha 11 per arribar a XYZ ”podria aconseguir millors resultats.

Les mateixes regles també s’apliquen a les proves i als seus passos.

Per exemple Escric una prova per a Amazon.com: feu una comanda per a qualsevol producte.

Els següents són els meus passos de prova (Nota: només escric els passos i no totes les altres parts de la prova, com el resultat esperat, etc.)

a . Inicieu Amazon.com
b . Cerqueu un producte introduint la paraula clau / nom del producte al camp 'Cerca' a la part superior de la pantalla.
c . Trieu el primer dels resultats de la cerca que es mostren.
d . Feu clic a Afegeix a la cistella a la pàgina de detalls del producte.
és . Comanda i pagament.
f . Consulteu la pàgina de confirmació de la comanda.

Ara, podeu identificar quin d'aquests és un pas compost? Pas dret (e)

Recordeu que les proves sempre es refereixen a 'Com' provar, per tant, és important escriure els passos exactes de 'Com fer un pagament i pagar' a la prova.

Per tant, el cas anterior és més eficaç quan s’escriu a continuació:

a . Inicieu Amazon.com
b . Cerqueu un producte introduint la paraula clau / nom del producte al camp 'Cerca' a la part superior de la pantalla.
c . Trieu el primer dels resultats de la cerca que es mostren.
d . Feu clic a Afegeix a la cistella a la pàgina de detalls del producte.
és . Feu clic a Comanda a la pàgina del carretó de la compra.
f . Introduïu la informació de CC, enviament i informació de facturació.
g . Feu clic a Comanda.
h . Consulteu la pàgina de confirmació de la comanda.

Per tant, un pas compost es pot dividir en diversos passos individuals. La propera vegada que escrivim proves, fixem-nos tots en aquesta part i estic segur que estareu d’acord amb mi que ho fem més sovint del que ens adonem.

# 2) El comportament de l'aplicació es pren com a comportament esperat

Cada vegada hi ha més projectes que han d’afrontar aquesta situació en aquests dies.

La manca de documentació, la programació extrema i els cicles de desenvolupament ràpid són algunes de les raons que ens obliguen a confiar en l’aplicació (una versió més antiga més o menys) per escriure les proves o bé per basar-les. Com sempre, es tracta d’una mala pràctica demostrada, no sempre realment.

És inofensiu sempre que mantingueu la ment oberta i mantingueu l'expectativa que el '' AUT podria ser defectuós '. Només quan no creieu que ho sigui, les coses funcionen malament. Com sempre, deixarem que els exemples parlin.

Si la pàgina següent està escrivint / dissenyant els passos de prova:

Cas 1:

Si els passos del meu cas de prova són els següents:

1. Inicieu el lloc de compres.
2. Feu clic a Enviament i devolució: resultat esperat: la pàgina d'enviament i devolució es mostra amb 'Posa la vostra informació aquí' i el botó 'Continua'.

Llavors, això és incorrecte.

Cas 2:

1. Inicieu el lloc de compres.
2. Feu clic a Enviament i devolució.
3. Al quadre de text 'Introduïu el número de comanda' que apareix en aquesta pantalla, introduïu el número de comanda.
4. Feu clic a Continua: resultat esperat: es mostraran els detalls de la comanda relacionats amb l'enviament i les devolucions.

El cas 2 és un cas de prova millor, ja que, tot i que l’aplicació de referència es comporta incorrectament, només la prenem com a pauta, investigem més i escrivim el comportament esperat segons la funcionalitat correcta prevista.

Linia inferior: L’aplicació com a referència és una drecera ràpida, però inclou els seus propis riscos. Sempre que siguem acurats i crítics, produeix resultats sorprenents.

# 3) Condicions múltiples en un cas

Un cop més, aprenem d’ell Exemple .

Feu un cop d'ull als passos de prova següents: Els següents són els passos de prova d'una prova per a una funció d'inici de sessió.

a. Introduïu dades vàlides i feu clic a Envia.
b. Deixeu el camp Nom d'usuari buit. Feu clic a Envia.
c. Deixeu el camp de la contrasenya buit i feu clic a Envia.
d. Trieu un nom d’usuari / contrasenya que ja hàgiu iniciat la sessió i feu clic a Envia.

El que havia de ser 4 casos diferents es combina en un de sol. És possible que estigueu pensant: Què passa amb això? Està estalviant molta documentació i el que puc fer en 4, ho estic fent en 1: no és fantàstic? Bé, no del tot. Raons?

Segueix llegint:

• Què passa si una de les condicions falla: hem de marcar tota la prova com a 'fallida'. Si marquem tot el cas com a 'fallit', significa que les quatre condicions no funcionen, cosa que no és realment cert.
• Les proves han de tenir un flux. Des de la condició prèvia fins al pas 1 i passant pels passos. Si segueixo aquest cas, al pas (a), si té èxit, iniciaré la sessió a la pàgina, on l’opció “iniciar sessió” ja no està disponible. Llavors, quan arribo al pas (b): on anirà el provador a introduir el nom d’usuari? Ja ho veieu, el flux està trencat.

Per tant, escriure proves modulars . Sembla molta feina, però tot el que necessiteu és separar les coses i utilitzar els nostres millors amics Ctrl + C i Ctrl + V per treballar per a nosaltres. :)

************************************************

Com millorar l’eficiència dels casos de prova

Els provadors de programari haurien d’escriure les proves des de l’etapa anterior del cicle de vida del desenvolupament de programari, millor durant la fase de requisits de programari.

El gestor de proves o un gestor de control de qualitat haurien de recollir i preparar el màxim de documents possibles segons la llista següent.

Col·lecció de documents per a la redacció de proves

# 1) Document de requisits de l'usuari

És un document que recull el procés empresarial, perfils d'usuari, entorn d'usuari, interacció amb altres sistemes, substitució de sistemes existents, requisits funcionals, requisits no funcionals, requisits de llicència i instal·lació, requisits de rendiment, requisits de seguretat, usabilitat i requisits concurrents, etc. .,

# 2) Document de cas d'ús empresarial

En aquest document es detallen els fitxers cas d'ús escenari dels requisits funcionals des de la perspectiva empresarial. Aquest document cobreix els actors (o el sistema) empresarials, els objectius, les condicions prèvies, les postcondicions, el flux bàsic, el flux alternatiu, les opcions, les excepcions de tots i cadascun dels fluxos empresarials del sistema segons els requisits.

# 3) Document de requisits funcionals

Aquest document detalla els requisits funcionals de cada característica per al sistema sota requisits.

Normalment, el document de requisits funcionals serveix com a repositori comú tant per a l’equip de desenvolupament i proves, com per als grups d'interès del projecte, inclosos els clients per als requisits compromesos (de vegades congelats), que haurien de ser tractats com el document més important per a qualsevol desenvolupament de programari.

# 4) Pla del projecte de programari (opcional)

Un document que descriu els detalls del projecte, objectius, prioritats, fites, activitats, estructura organitzativa, estratègia, seguiment del progrés, anàlisi de riscos, suposicions, dependències, restriccions, requisits de formació, responsabilitats del client, calendari del projecte, etc.,

# 5) QA / pla de proves

Aquest document detalla el sistema de gestió de qualitat, els estàndards de documentació, el mecanisme de control de canvis, els mòduls crítics i les funcionalitats, el sistema de gestió de configuracions, els plans de proves, el seguiment de defectes, els criteris d’acceptació, etc.

El pla de proves El document s'utilitza per identificar les funcions a provar, les funcions que no s'han de provar, les assignacions de l'equip i la seva interfície, els requisits de recursos, el calendari de proves, l'escriptura de proves, la cobertura de les proves, els lliuraments de les proves, requisit previ per a l'execució de la prova, la notificació d'errors i el seguiment mecanisme, mètriques de prova, etc.,

Exemple real

Vegem com escriure casos de prova de manera eficient per a una pantalla d’inici de sessió simple i familiar, tal com es mostra a la figura següent. El enfocament de les proves serà gairebé el mateix, fins i tot per a pantalles complexes amb més informació i funcions crítiques.

# 1) El primer enfocament per a qualsevol procés de cas de prova serà obtenir un prototip de pantalla (o marcs de filferro) tal com s’ha indicat anteriorment, si està disponible. És possible que això no estigui disponible per a algunes de les funcionalitats i depèn de la criticitat del disseny d'un prototip en les primeres etapes del desenvolupament.

Però, si un SRS Document (Especificació de requisits de programari) està disponible per al projecte, la majoria dels prototips de pantalla els desenvolupa l’equip del projecte. Aquest tipus de pantalla simplifica la feina del comprovador i augmenta l’eficiència de les proves.

# 2) A continuació, el especificacions de requisits funcionals . Depèn del procés d’organització, estarà disponible en un conjunt de documents múltiples.

Per tant, decidiu el millor document per escriure casos, ja sigui un document de requisits d’usuari o unes especificacions de requisits funcionals (o fins i tot un document SRS si l’equip de proves pot entendre-ho còmodament) que donarà un flux funcional complet de funció a provar.

# 3) Un cop el prototip de pantalla i les especificacions funcionals estiguin al seu lloc, el comprovador hauria de començar a escriure els casos amb el següent enfocament i criteris.

• Proves d’interfície d’usuari :Els controls / camps visibles per l'usuari. Hi ha controls estàtics i controls dinàmics disponibles per a la característica a provar. Per exemple, a la pantalla d'inici de sessió superior, els textos 'Nom d'usuari i contrasenya' són camps estàtics que no requereixen cap interacció de l'usuari, només per mostrar només el text.

• Casos funcionals :D’altra banda, el botó d’inici de sessió i els hiperenllaços (Heu oblidat la contrasenya i el registre) són camps dinàmics que requereixen la interacció de l’usuari fent clic als controls, que faran algunes accions després.

• Casos de base de dades :Un cop l'usuari introdueix el nom d'usuari i la contrasenya, es poden escriure les proves per comprovar la base de dades relacionada, si el nom d'usuari i la contrasenya es comproven a la base de dades i a la taula adequades i també l'usuari té el permís per iniciar sessió a l'aplicació que es prova.
  

• Proves de processos :Això està relacionat amb el procés (no les accions associades als controls visibles disponibles a la pantalla) associats a la funció i a la funcionalitat. Per exemple, si feu clic a l'enllaç Oblidar la contrasenya a la pantalla de mostra anterior, podeu enviar un correu electrònic a l'usuari. Per tant, potser cal provar un correu electrònic per confirmar-ne el procés i el procés.

4) Finalment, mantingueu el ' Mantra BAOE ”, Vol dir i) Flux bàsic ii) Flux alternatiu iii) Opcions i iv) Excepcions per a la cobertura completa del flux funcional i la característica a provar. Tots els conceptes s’han d’aplicar a proves positives i negatives.

Per exemple, vegem el simple enfocament BAOE per a la pantalla d'inici de sessió de mostra anterior.

• Flux bàsic: Introduïu la ruta URL de l'inici de sessió a qualsevol navegador i introduïu la informació necessària i inicieu la sessió a l'aplicació.
• Flux alternatiu: Instal·leu l'aplicació en un dispositiu mòbil i introduïu la informació necessària i inicieu la sessió a l'aplicació.
• Opcions: Quines són les opcions disponibles per accedir a la mateixa pantalla d'inici de sessió? Per exemple, després d’iniciar sessió a l’aplicació, si feu clic a “Tancar sessió” es pot obtenir la mateixa pantalla o, si el temps d’espera o la sessió ha caducat, l’usuari pot accedir a la pantalla d’inici de sessió.
• Excepcions: Quines són les excepcions si les meves proves són negatives? Per exemple, si s'introdueixen credencials incorrectes a la pantalla d'inici de sessió, si l'usuari rebrà un missatge d'error o si no hi ha cap acció associada.

Amb tota aquesta informació a la mà, comencem a escriure els TC per a la pantalla d'inici de sessió, en un format amb la cobertura i la traçabilitat completa i amb informació detallada. La seqüència lògica i la numeració d’identificar el ‘ Identificador de cas de prova ' serà molt útil per a un historial d’execució d’identificació ràpida de casos de prova.

Llegiu també=> Més de 180 exemples de casos preparats per utilitzar per a aplicacions web i d'escriptori.

Document de cas de prova

Nota : Les columnes de prova no es limiten al document de prova de mostra següent, que es pot mantenir en un full Excel per tenir tantes columnes com calgui per a una matriu de traçabilitat completa, és a dir, prioritat, finalitat de la prova, tipus de prova, ubicació de la captura d’error. etc.,

Llegiu també=> Exemple de plantilla de cas de prova amb exemples.

Per facilitar la simplicitat i la llegibilitat d’aquest document, escrivim detalladament els passos per reproduir, el comportament esperat i real de les proves de la pantalla d’inici de sessió.

Nota : Afegiu una columna Comportament real al final d'aquesta plantilla.

Recollida de dades de prova

Quan s’escriu el cas de prova, la tasca més important per a qualsevol provador és recopilar les dades de la prova. Molts verificadors ometen aquesta activitat i passen per alt amb la suposició que els casos de prova es poden executar amb algunes dades de mostra o dades fictícies i es poden alimentar quan les dades siguin realment necessàries. Es tracta d’una idea errònia crítica que alimenta dades de mostra o dades d’entrada de la memòria mental en el moment d’executar casos de prova.

Si les dades no es recopilen i no s’actualitzen al document de prova en el moment d’escriure les proves, el comprovador passaria anormalment més temps a recollir les dades en el moment de l’execució de la prova. Les dades de la prova s’han de recollir tant en casos positius com en negatius des de tota la perspectiva del flux funcional de la característica. El document de casos d’ús empresarial és molt útil en aquesta situació.

Cerqueu un exemple de document de dades de prova per a les proves escrites anteriorment, que al seu torn us serà útil per saber com podem recollir les dades que facilitaran la nostra feina en el moment de l’execució de la prova.

************************************************

Importància de normalitzar els casos de prova

En aquest món ocupat, ningú no pot fer coses repetitives dia a dia amb el mateix nivell d’interès i energia. Especialment, no m’apassiona fer la mateixa tasca una i altra vegada a la feina. M’agrada gestionar les coses i estalviar temps. Qualsevol usuari de TI ho hauria de ser.

Totes les empreses de TI executen diferents tipus de projectes. Aquests projectes poden basar-se en productes o en serveis. D 'aquests projectes, la majoria treballen al voltant de llocs web i proves de llocs web . La bona notícia al respecte és que tots els llocs web tenen moltes similituds. I, si els llocs web tenen el mateix domini, també tenen diverses característiques comunes.

La pregunta que sempre em desconcerta és que: 'Si la majoria d’aplicacions són similars, per exemple: com ara els llocs de venda al detall, que s’han provat mil vegades abans,' Per què hem d’escriure casos de prova per a un altre lloc de venda al detall des de zero? ” No estalviarà un munt de temps traient els scripts de prova existents que s’utilitzaven per provar un lloc comercial anterior?

És clar, és possible que haguem de fer alguns petits ajustaments, però, en general, també és més fàcil, eficient i permet estalviar diners i, per tant, sempre ajuda a mantenir alts els nivells d’interès dels verificadors. A qui li agrada escriure, revisar i mantenir repetidament els mateixos casos de prova, oi? Reutilitzar les proves existents pot resoldre-ho en gran mesura i els vostres clients també ho trobaran intel·ligent i lògic.

Per tant, lògicament, vaig començar a treure els scripts existents de projectes similars basats en web, vaig fer canvis i en vaig fer una ràpida revisió. També he utilitzat la codificació de colors per mostrar els canvis que es van fer, de manera que el revisor només es pot centrar en la part que s’ha canviat.

Motius per reutilitzar casos de prova

# 1) La majoria d’àrees funcionals d’un lloc web són gairebé: inici de sessió, registre, afegir a la cistella, llista de desitjos, pagament, opcions d’enviament, opcions de pagament, contingut de la pàgina del producte, productes vistos recentment, productes rellevants, instal·lacions de codis promocionals, etc.

# 2) La majoria dels projectes són només millores o canvis en la funcionalitat existent.

com escriure scripts de prova uat

# 3) Els sistemes de gestió de contingut que defineixen les ranures per a càrregues d’imatges amb formes estàtiques i dinàmiques també són habituals a tots els llocs web.

# 4) Hi ha llocs web minoristes RSC (Servei d'atenció al client) també.

# 5) Tots els llocs web també utilitzen el sistema de backend i l'aplicació de magatzem que utilitzen JDA.

# 6) El concepte de cookies, el temps d'espera i la seguretat també són habituals.

# 7) Els projectes basats en web solen ser propensos a canvis de requisits.

# 8) El tipus de proves necessàries són habituals com el navegador proves de compatibilitat , proves de rendiment , proves de seguretat

Ja ho veieu, hi ha un munt de coses habituals i similars.

Dit això, la reutilització és el camí a seguir, de vegades les modificacions poden trigar o no més o menys. De vegades es pot pensar que és millor començar de zero que modificar tant.

Això es pot gestionar fàcilment creant un conjunt de casos de prova estàndard per a cadascuna de les funcionalitats habituals.

Què és una prova estàndard en proves web?

• Creeu casos de prova complets: passos, dades, variable, etc. Això garantirà que les dades / variables que no siguin similars es puguin substituir simplement quan es requereixi un cas de prova similar.
• Els criteris d’entrada i sortida s’han de definir correctament.
• Els passos modificables o la declaració dels passos s'han de ressaltar amb un color diferent per trobar i substituir ràpidament.
• El llenguatge utilitzat per a la creació de casos estàndard de prova hauria de ser genèric.
• Totes les funcions de cada lloc web haurien d’estar cobertes en els casos de prova.
• El nom dels casos de prova ha de ser el nom de la funcionalitat o la característica que cobreix el cas de prova. Això farà que la troballa del cas de prova del conjunt sigui molt més fàcil.
• Si hi ha alguna mostra bàsica o estàndard o fitxer GUI o captura de pantalla de la característica, s’hauria d’adjuntar amb els passos corresponents.

Utilitzant els consells anteriors es pot crear un conjunt de scripts estàndard i utilitzar-los amb poques o necessàries modificacions per a diferents llocs web.

Aquests casos de prova estàndard també es poden automatitzar, però una vegada més centrar-se en la reutilització sempre és un avantatge. També, si automatització es basa en una GUI, la reutilització dels scripts en diversos URL o llocs és una cosa que personalment mai he trobat efectiva.

Utilitzar un conjunt estàndard de casos de proves manuals per a diferents llocs web amb modificacions menors és la millor manera de realitzar una prova de lloc web. Tot el que necessitem és crear i mantenir els casos de prova amb els estàndards i l’ús adequats.

Conclusió

Millorar l’eficiència dels casos de proves no és un terme simplement definit, sinó que és un exercici que es pot aconseguir mitjançant un procés madurat i una pràctica regular.

L’equip de proves no s’hauria de cansar d’implicar-se en la millora d’aquestes tasques, ja que és la millor eina per aconseguir majors èxits en el món de la qualitat, cosa que s’ha demostrat en moltes de les organitzacions de proves de tot el món en projectes crítics de missió i aplicacions complexes.

Espero que hagueu obtingut un coneixement immens sobre el concepte de casos de prova. Mireu la nostra sèrie de tutorials per obtenir més informació sobre casos de proves i no dubteu a expressar els vostres pensaments a la secció de comentaris que hi ha a continuació.

Pròxim tutorial

Lectura recomanada

• Proves funcionals contra proves no funcionals
• Guia de proves de portabilitat amb exemples pràctics
• Tipus de proves de programari: diferents tipus de proves amb detalls
• Les millors eines de prova de programari 2021 [Eines d'automatització de proves de control de qualitat]
• Proves alfa i proves beta (guia completa)
• Què és la prova del sistema: una guia per a principiants
• Documents de preguntes de mostra de certificació de proves ISTQB amb respostes
• Com escriure un informe d'estat setmanal de proves de programari