test coverage software testing
Guia completa de la cobertura de la prova de proves de programari: Com provar més, estalviar temps i obtenir millors resultats de proves:
Les proves de programari són una activitat essencial en els cicles de vida de desenvolupament i manteniment de programari. És una pràctica que s’utilitza sovint per decidir i millorar la qualitat del programari.
Actualment, el desenvolupament és més sistemàtic i les organitzacions busquen mesures de completitud i eficàcia de les proves per mostrar els criteris de finalització de les proves. De tots, la cobertura es considera especialment valuosa.
Què aprendreu:
- Què és la cobertura de les proves?
- Cobertura de proves i cobertura del codi
- La meva experiència
- Significat de la cobertura de la prova
- Com adoptar un mètode de cobertura de prova adequat?
- Com assegurar-se que tot estigui provat?
- Àrees i mètodes crítics per fer proves efectives
- Avantatges de provar el coneixement de la cobertura d'un provador:
- Conclusió
- Lectura recomanada
Què és la cobertura de les proves?
En poques paraules, la cobertura és 'Què estem provant i quant estem provant?'
com obrir fitxers XML en word
La cobertura de les proves ajuda a controlar la qualitat de les proves i ajuda els verificadors a crear proves que cobreixin zones que falten o no estan validades.
La majoria dels equips basen els seus càlculs de cobertura només en requisits funcionals. També és just perquè en primer lloc una aplicació ha de fer el que se suposa que ha de fer. En cas contrari, la seva rapidesa o seguretat o facilitat d’ús: res no importa.
No obstant això, si es dedica i és independent proves no funcionals els equips estan treballant en el rendiment, la seguretat, les proves d’usabilitat, etc., i hauran de fer un seguiment dels seus requisits fins a l’execució mitjançant les analítiques de cobertura de proves.
Cobertura de proves i cobertura del codi
La cobertura de les proves sovint es confon amb la cobertura del codi. Tot i que els principis subjacents són els mateixos, són dues coses diferents.
Cobertura del codi realment parla de pràctiques de proves unitàries que han d’orientar-se a totes les àrees del codi almenys una vegada i que fan els desenvolupadors.
La cobertura de les proves, en canvi, és provant tots els requisits almenys una vegada i és evidentment una activitat de l’equip de control de qualitat.
El que realment es qualifiqui per ser un requisit cobert depèn de la interpretació de cada equip.
Per exemple Alguns equips anomenen un requisit cobert si hi ha almenys un cas de prova en contra. De vegades, es cobreix si s’hi assigna com a mínim un membre de l’equip. O bé, si s’executen tots els casos de prova associats.
- Si es creen 10 requisits i 100 proves (quan aquestes 100 proves s’adrecen a tots els 10 requisits i no en deixen cap), anomenem una cobertura de proves adequada a nivell de disseny.
- Quan només s'executen 80 de les proves creades i s'orienten només a 6 dels requisits. Diem que no es cobreixen 4 requisits tot i que es fa el 80% de les proves. Es tracta d’estadístiques de cobertura a nivell d’execució.
- Quan només 90 proves relacionades amb vuit requisits han assignat verificadors i la resta no ho són, diem que la cobertura de l'assignació de proves és del 80% (8 de cada 10 requisits).
També és important quant al moment de calcular la cobertura.
Si ho feu massa d'hora en el procés, veureu molts buits perquè les coses encara estan incompletes. Per tant, generalment es recomana espereu fins a la darrera versió és a dir, la compilació de regressió final. Això donarà una cobertura correcta de les proves realitzades per als requisits indicats.
Llegiu també => Procés de gestió de llançaments i desplegaments
La meva experiència
Escena de fa 8 anys: Quan tenia 2 anys d’experiència en la indústria de les proves de programari, pensava que estava bé si no conec alguns fonaments sobre les proves de programari, cosa que algú pot aprendre amb experiència i jo també ho faré.
Jo tenia raó, i també m’equivocava.
És correcte perquè amb l’experiència aprens a veure un panorama més ampli, entens el significat real de “Situació crítica” i entens més l’usuari final.
Malament perquè cap de les coses esmentades no requereix experiència, sinó aprenentatge primerenc, que vaig entendre molt tard. Aquest és el factor encoratjador per escriure aquest post.
Aquí teniu la meva experiència d’una de les entrevistes en aquell moment:
Com assegureu-vos que la cobertura de la prova sigui completa o màxima? Em van preguntar.
Ummmm ...... m'asseguro de provar totes les funcionalitats , Jo vaig dir.
S o dieu que, un cop provades totes les funcionalitats, creieu que heu cobert un màxim d'aplicació / producte en termes de proves , l’entrevistador va fer un cop enrere.
Ummm ... bé ...ummm ..., sí, perquè quan proveu totes les funcionalitats, teniu confiança en el comportament de l’aplicació / producte, Vaig donar suport a la meva resposta .
Estic d'acord, però la meva pregunta és: us donarà confiança que la cobertura de les proves sigui màxima o completa? l’entrevistador no tenia cap humor per deixar-me anar.
Ara m’estava impacientant, desconegut pel fet d’aprendre un dels temes més importants sobre les proves de programari: ' Cobertura de la prova ” .
En lloc de reproduir els fragments de l’entrevista, aquí resumeixo allò que vaig aprendre sobre la cobertura de proves aquell dia. Abans d’això, quedem clars en un punt: provar la cobertura no vol dir mai saber si feu proves suficients o no, ni vol dir que feu proves perfectes o no.
Significat de la cobertura de la prova
La cobertura de les proves pot tenir un significat diferent en un context diferent. Descobrim aquests contextos un per un:
Cobertura del producte: quins aspectes del producte heu vist?
Sí, quan es mesura la cobertura de les proves en termes de producte, l’àrea principal a centrar-se és: quines àrees de producte heu provat i quines encara no s’han provat?
Exemple 1:
Si 'ganivet' és un producte, esteu provant; simplement no us concentreu a comprovar si talla les verdures / fruites correctament. Hi ha altres aspectes que cal cercar, com ara: l'usuari hauria de ser capaç de manejar-lo còmodament.
Exemple 2:
Si el 'bloc de notes' és una aplicació, esteu provant, és imprescindible comprovar les funcions rellevants.
Però altres aspectes a tenir en compte són: l'aplicació respon correctament mentre s'utilitzen altres aplicacions simultàniament, l'aplicació no es bloqueja quan l'usuari intenta fer alguna cosa inusual , a l'usuari se li proporcionen missatges d'advertència / error adequats, l'usuari pot entendre i utilitzar l'aplicació fàcilment; el contingut d'ajuda està disponible quan es requereixi.
Si no analitzeu els escenaris esmentats, no podeu afirmar que la cobertura de les proves de l’aplicació estigui completa.
Cobertura de riscos: per a quins riscos heu provat?
La cobertura de riscos és un altre aspecte per tenir una cobertura completa de proves. No podeu etiquetar el producte o l'aplicació com a 'provat' fins que no proveu també els riscos associats. La cobertura dels riscos associats és un factor important en la cobertura global de les proves.
Exemple 1:
Mentre provava un avió, si un provador us indica que ha provat completament el sistema intern de l’avió i funciona bé, però només es cobria la capacitat de vol de l’avió durant les proves: quina seria la vostra reacció?
Bé, això és el que significa la cobertura de riscos. Sempre és una bona pràctica identificar el risc segons l’aplicació / producte i provar-lo a fons.
Exemple 2:
Mentre provava un lloc de comerç electrònic, el verificador va considerar tots els factors efectius, però no va tenir en compte el risc que el nombre d’usuaris accedissin al lloc web simultàniament i el dia de la SUPER OFERTA, el risc no considerat va resultar ser un gran error.
Lectura recomanada =>
Cobertura dels requisits: per a quins requisits heu provat?
Si un producte o aplicació es desenvolupa molt bé, però si no coincideix amb els requisits del client, no serveix de res. La cobertura del requisit durant les proves és tan important com la cobertura del producte.
Exemple 1:
Emocionat per la funció familiar, vau demanar al sastre que us cosís el vestit i que poséssiu els botons d’espectacle de color blau paó a l’escot.
Mentre cosia el vestit, el sastre va pensar que posar aquests botons a l'escot no quedaria bé, de manera que va cosir una sanefa de color daurat. El dia de la prova, definitivament, el client descontent va cridar al sastre perquè no s’adherís als requisits.
Exemple 2:
Mentre provava una aplicació de xat, el provador es va ocupar de tots els punts importants, com ara diversos usuaris que xerren en un grup, dos usuaris que xerren independentment, tots els tipus d’emoticones disponibles, actualitzacions enviades immediatament a l’usuari, etc. es va esmentar que quan dos usuaris xerren independentment, s'hauria d'activar l'opció de videotrucada.
El client va comercialitzar l'aplicació de xat afirmant que permetria trucar, mentre que dos usuaris xataven de forma independent. Us podeu imaginar què hauria passat amb l’aplicació de xat.
També llegir => Com es crea una matriu de traçabilitat dels requisits
Com adoptar un mètode de cobertura de prova adequat?
La consciència ho és tot:
Primer de tot, l’equip de control de qualitat ha de saber quant treballa i on es troben les tasques de disseny. D’aquesta manera, sabran si s’afegiran més proves. Per fer-ho, podeu utilitzar un RTM com és la pràctica habitual.
=> Consulteu aquest article per obtenir-ne més informació i com utilitzar-lo: Com es crea una matriu de traçabilitat dels requisits: procés exacte amb una plantilla de mostra
En segon lloc, comproveu l 'assignació de recursos i procés d'execució de la prova per veure si tot es prova de manera més eficaç.
Una taula com la següent pot ser útil:
| Tipus de prova | Casos totals | Casos executats | Estat | Comentaris |
|---|---|---|---|---|
| Funcional | 100 | 80 | 50 passades, 30 fallades | |
| Compatibilitat | 100 | 50 | 45 passades, 5 fallades | |
| Usabilitat | 100 | 100 | 98 passada, 2 fallades | |
| Regressió final | 100 | 100 | 99 passades, 1 fallades |
Com assegurar-se que tot estigui provat?
- Tots els provadors han de ser conscients dels requisits i dels mètodes de prova
- Prioritzeu els vostres requisits i concentreu la vostra energia allà on més necessiteu
- Informeu-vos de com una versió determinada és diferent de l’anterior per poder identificar els requisits crítics amb més precisió i centrar-vos en la màxima cobertura positiva
- Adaptació de l'automatització de proves
- Utilitzeu eines de gestió de proves per estar sempre al dia
- Assignació de treball intel·ligent: canalitzeu els vostres millors recursos cap a tasques crítiques i deixeu que els nous provadors exploren més per obtenir una perspectiva nova
- Mantenir un llista de comprovació de totes les tasques i activitats diverses
- Interactueu més amb els vostres equips de Dev / Scrum / BA per obtenir informació sobre el comportament de l’aplicació
- Feu un seguiment de tots els vostres cicles de construcció i correccions
- Identifiqueu els problemes més impactants de les construccions inicials (quan sigui possible) perquè els posteriors puguin treballar per obtenir una millor estabilitat i arribar a les zones bloquejades per problemes previs
Àrees i mètodes crítics per fer proves efectives
# 1)Entreteniment de recursos: Intercanvieu tasques entre els membres del vostre equip. Això ajuda a millorar la implicació i a prevenir la concentració de coneixement.
# 2)Cobertura de compatibilitat: Assegureu-vos que esteu al corrent i incloeu el fitxer diferents navegadors i plataformes per provar la vostra sol·licitud.
# 3)Propietat: Feu que els provadors siguin responsables i doneu-los un control lliure (amb control i suport, per descomptat) del mòdul / tasca en què treballen. Això ajuda a crear responsabilitats i els permet provar formes creatives en lloc de seguir els batuts pel camí.
# 4)Terminis: Conèixer els terminis de llançament abans de començar la fase de proves ajuda a una planificació eficaç
# 5)Comunicació : Mantingueu-vos en contacte amb el desenvolupador i altres equips entre cicles de llançament per saber què està passant.
# 6)Mantenir un RTM: Actua com un bon derivat del Interessats o clients , basant-se en què es pot confirmar la programació de llançament
Avantatges de provar el coneixement de la cobertura d'un provador:
- Ajuda principalment a la priorització de tasques de prova
- Ajuda a aconseguir un 100% de cobertura de requisits o, en altres paraules, evita les fuites de requisits
- Anàlisi d’impactes es fa més fàcil
- Útil per determinar el Criteris de SORTIDA
- Activa un punt de prova per preparar un clar informe de tancament de la prova
Conclusió
La cobertura de les proves no acaba amb els contextos esmentats. Hi ha molts altres punts que s’han de tenir en compte a l’hora de provar la cobertura.
No sempre és cert que quan en proveu més, els resultats són millors. De fet, quan proveu més proves sense cap estratègia aparent, probablement acabareu invertint molt de temps.
Amb un enfocament més estructurat, un objectiu de cobertura del 100% de requisits i mètodes de prova eficaços, no comprometreu la qualitat.
Esperem que les tècniques descrites en aquest article us donin algunes indicacions.
Afegiu els vostres comentaris i opinions sobre la publicació. Com és habitual, ens agrada escoltar-vos.
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
- 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
- Les proves de programari són una tasca emocional?
- Algunes preguntes d’entrevistes de proves de programari interessants
- Opinions i ressenyes sobre cursos de proves de programari