Menú

7 Principis de proves de programari: agrupació de defectes i principi de Pareto

  • Principal
  • Altres
  • 7 Principis de proves de programari: agrupació de defectes i principi de Pareto

7 principles software testing

Proveu El Nostre Instrument Per Eliminar Problemes

Set principis de proves de programari: incloent més detalls sobre l'agrupació de defectes, el principi de Pareto i la paradoxa dels plaguicides.

Estic segur que tothom és conscient del ' Set principis de proves de programari '.

Aquests principis fonamentals de proves ajuden els equips de proves a utilitzar el seu temps i esforç per fer que el procés de prova sigui eficaç. En aquest article, aprendrem en detall sobre dos principis, és a dir, Agrupació de defectes, principi de Pareto i paradoxa dels pesticides .

7 principis de proves de programari

Què aprendreu:

Set principis de proves de programari

Abans d’examinar en profunditat aquests dos principis, comprenguem breument els set principis de les proves de programari.

Explorem !!

# 1) Les proves mostren la presència de defectes

Totes les aplicacions o productes es publiquen a la producció després d'una quantitat suficient de proves per part de diferents equips o passa per diferents fases, com ara proves d'integració de sistemes, proves d'acceptació d'usuaris i proves beta, etc.

Tan alguna vegada heu vist o escoltat d'algun equip de proves que ha provat completament el programari i que no hi ha cap defecte en el programari ? En lloc d'això, tots els equips de proves confirmen que el programari compleix tots els requisits empresarials i que funciona segons les necessitats de l'usuari final.

A la indústria de les proves de programari, ningú dirà que n’hi ha cap defecte al programari, la qual cosa és cert, ja que les proves no poden demostrar que el programari estigui lliure d’errors o defectes.

No obstant això, l'objectiu de les proves és trobar cada cop més defectes ocults mitjançant diferents tècniques i mètodes. Les proves poden revelar defectes no descoberts i, si no es detecten defectes, no vol dir que el programari estigui lliure de defectes.

Exemple 1 :

Penseu en una aplicació bancària, aquesta aplicació està provada a fons i experimenta diferents fases de proves com SIT, UAT, etc. i actualment no s’identifiquen defectes al sistema.

Tanmateix, podria existir la possibilitat que a l’entorn de producció, el client real provi una funcionalitat que poques vegades s’utilitza al sistema bancari i els verificadors han passat per alt aquesta funcionalitat, de manera que no s’ha trobat cap defecte fins a la data o el codi mai no ha estat tocat pels desenvolupadors. .

Exemple 2:

Hem vist diversos anuncis de sabons, pasta de dents, rentats de mans o aerosols desinfectants, etc. a la televisió.

Penseu en un anunci de rentat de mans que digui a la televisió que es pot eliminar el 99% de gèrmens si s’utilitza aquest rentat de mans específic. Això demostra clarament que el producte no està 100% lliure de gèrmens. Per tant, en el nostre concepte de proves, podem dir que cap programari és lliure de defectes.

# 2) Proves primerenques

Els verificadors han d’implicar-se en una etapa inicial del cicle de vida del desenvolupament de programari (SDLC). Així, es poden identificar els defectes durant la fase d'anàlisi de requisits o qualsevol defecte de documentació. El cost que suposa solucionar aquests defectes és molt inferior si es compara amb els que es troben durant les últimes etapes de la prova.

Penseu en la imatge següent que mostra com augmenta el cost de la reparació de defectes a mesura que les proves avancen cap a la producció en directe.

proves inicials: cost de reparació de defectes

(imatge font )

La imatge anterior mostra que el cost necessari per solucionar un defecte trobat durant l’anàlisi de requisits és menor i continua augmentant a mesura que avancem cap a la fase de proves o manteniment.

Ara la pregunta és quant d'hora ha de començar la prova ?

Un cop finalitzats els requisits, els provadors han de participar en la prova. Les proves s’han de realitzar en documents de requisits, especificacions o qualsevol altre tipus de document, de manera que, si els requisits no es defineixen correctament, es poden solucionar immediatament en lloc de solucionar-los en la fase de desenvolupament.

# 3) No es poden fer proves exhaustives

No és possible provar totes les funcionalitats amb totes les combinacions vàlides i no vàlides de dades d'entrada durant les proves reals. En lloc d'aquest enfocament, es considera la prova d'algunes combinacions basada en la prioritat mitjançant diferents tècniques.

Les proves exhaustives requeriran esforços il·limitats i la majoria d'aquests esforços són ineficaços. A més, els terminis del projecte no permetran provar tantes combinacions. Per tant, es recomana provar les dades d'entrada mitjançant diferents mètodes com el particionat d'equivalència i l'anàlisi del valor límit.

Per exemple ,Si suposem que tenim un camp d'entrada que accepta alfabets, caràcters especials i números només del 0 al 1000. Imagineu quantes combinacions apareixerien per provar, no és possible provar totes les combinacions per a cada tipus d’entrada.

Els esforços de prova necessaris per provar seran enormes i també afectaran la cronologia i el cost del projecte. Per tant, sempre es diu que pràcticament no és possible fer proves exhaustives.

# 4) Les proves depenen del context

Hi ha diversos dominis disponibles al mercat, com ara banca, assegurances, serveis mèdics, viatges, publicitat, etc., i cada domini té diverses aplicacions. També per a cada domini, les seves aplicacions tenen diferents requisits, funcions, diferents finalitats de prova, risc, tècniques, etc.

Els diferents dominis es proven de manera diferent, de manera que la prova es basa únicament en el context del domini o de l'aplicació.

Per exemple ,provar una aplicació bancària és diferent de provar qualsevol aplicació de comerç electrònic o publicitat. El risc associat a cada tipus d'aplicació és diferent, de manera que no és eficaç utilitzar el mateix mètode, tècnica i tipus de prova per provar tots els tipus d'aplicació.

# 5) Agrupació de defectes

Durant les proves, pot passar que la majoria dels defectes trobats estiguin relacionats amb un nombre reduït de mòduls. Pot haver-hi múltiples raons, com ara que els mòduls poden ser complexos, la codificació relacionada amb aquests mòduls pot ser complicada, etc.

Aquest és el principi de Pareto de les proves de programari on el 80% dels problemes es troben en el 20% dels mòduls. Més endavant, en aquest article, obtindrem més informació sobre l’agrupació de defectes i el principi de Pareto.

# 6) Paradoxa dels pesticides

El principi de la paradoxa de pesticides diu que si el mateix conjunt de casos de prova s’executen una i altra vegada durant el període de temps, llavors aquest conjunt de proves no són prou capaços d’identificar nous defectes del sistema.

Per superar aquesta 'paradoxa dels pesticides', cal revisar i revisar regularment el conjunt de casos de prova. Si cal, es pot afegir un nou conjunt de casos de prova i es poden suprimir els casos de prova existents si no poden trobar més defectes del sistema.

# 7) Absència d'error

Si el programari es prova completament i si no es detecten defectes abans del llançament, podem dir que el programari està lliure de defectes al 99%. Però, què passa si aquest programari es prova amb requisits incorrectes? En aquests casos, fins i tot trobar defectes i solucionar-los a temps no ajudaria, ja que es realitzen proves amb requisits equivocats que no són segons les necessitats de l'usuari final.

Per exemple, suposem que l'aplicació està relacionada amb un lloc de comerç electrònic i amb els requisits contra la funcionalitat 'Cistella de la compra o Cistella de la compra' que s'interpreta i prova incorrectament. Aquí, fins i tot trobar més defectes no ajuda a traslladar l'aplicació a la següent fase ni a l'entorn de producció.

Aquests són els set principis de la prova de programari.

Ara explorem Agrupació de defectes, principi de Pareto i paradoxa dels pesticides a detall .

Agrupació de defectes

Mentre proven qualsevol programari, els provadors es troben principalment amb una situació en què la majoria dels defectes trobats estan relacionats amb algunes funcionalitats específiques i la resta de funcionalitats tindran un nombre inferior de defectes.

L’agrupació de defectes significa un petit nombre de mòduls que contenen la majoria dels defectes. Bàsicament, els defectes no es distribueixen de manera uniforme a tota l'aplicació, sinó que es concentren o centralitzen entre dos o tres funcionalitats.

De vegades, és possible a causa de la complexitat de l'aplicació, la codificació pot ser complexa o complicada, un desenvolupador pot cometre un error que pot afectar només una funcionalitat o mòdul específics.

L’agrupació de defectes es basa en “ Principi de Pareto ”Que també es coneix com Regla 80-20 . Vol dir que el 80% dels defectes trobats es deuen al 20% dels mòduls de l'aplicació. El concepte de principi de Pareto va ser definit inicialment per un economista italià - Vilfrodo Pareto .

Si els provadors observen 100 defectes, no quedarà clar si hi ha cap significat subjacent contra aquests 100 defectes. Però si aquests 100 defectes es classifiquen segons alguns criteris específics, és possible que els comprovadors entenguin que un gran nombre de defectes pertanyen a molt pocs mòduls específics.

Per exemple ,Considerem la imatge següent que es prova per a una de les aplicacions bancàries i mostra que la majoria dels defectes estan relacionats amb la funcionalitat 'Overdraft'. La resta de funcions, com ara Resum del compte, Transferència de fons, Instruccions permanents, etc., tenen un nombre limitat de defectes.

Agrupació de defectes

(imatge font )

La imatge anterior indica que hi ha 18 defectes al voltant de la funcionalitat de Descobriment dels 32 defectes totals, cosa que significa que el 60% dels defectes es troben al mòdul 'Descobriment'.

Per tant, els provadors es concentren principalment en aquesta àrea durant l’execució per trobar cada cop més defectes. Es recomana que els provadors tinguin un enfocament similar també en els altres mòduls durant la prova.

Quan es prova un mateix codi o mòdul, una i altra vegada, utilitzant un conjunt de casos de prova que durant les iteracions inicials, el nombre de defectes és elevat, però, després d’una certa iteració, el recompte de defectes es reduirà significativament. L’agrupació de defectes indica que l’àrea propensa a defectes s’ha de provar a fons durant les proves de regressió.

Paradoxa dels pesticides

Quan es troba que un dels mòduls té més defectes, els provadors fan alguns esforços addicionals per provar aquest mòdul.

Després d’unes poques iteracions de proves, la qualitat del codi millora i el recompte de defectes comença a disminuir, ja que la majoria dels defectes són solucionats per l’equip de desenvolupament, ja que els desenvolupadors també són cautelosos mentre codifiquen un mòdul concret on els provadors van trobar més defectes.

Per tant, en un moment donat, la majoria dels defectes són descoberts i corregits de manera que no es trobin defectes nous en aquest mòdul.

Tanmateix, de vegades pot passar que, tot i ser molt cautelós durant la codificació d’un mòdul concret (aquí en el nostre cas Descobert 'Mòdul'), el desenvolupador pot descuidar els altres mòduls per codificar-lo correctament o els canvis realitzats en aquest mòdul en particular poden tenir un impacte negatiu en les altres funcionalitats com ara Resum del compte, Transferència de fons i Instruccions permanents.

Quan els provadors utilitzen el mateix conjunt de casos de prova per executar el mòdul on es troben la majoria dels defectes (mòdul de descobert), després de solucionar aquests defectes pels desenvolupadors, aquests casos de prova no són molt efectius per trobar nous defectes. Com a flux d'extrem a extrem del descobert, el mòdul es prova a fons i els desenvolupadors també han escrit el codi d'aquest mòdul amb precaució.

Cal revisar i actualitzar aquests casos de prova. També és una bona idea afegir casos de prova nous perquè es puguin trobar nous i més defectes en diferents àrees de programari o aplicació.

Mètodes preventius de la paradoxa dels pesticides

Hi ha dues opcions mitjançant les quals podem prevenir la paradoxa dels plaguicides, tal com es mostra a continuació:

a) Escriviu un nou conjunt de casos de prova que se centraran en diferents àrees o mòduls (que no siguin els mòduls propis de defectes anteriors - Exemple: 'Descobert') del programari.

b) Prepareu casos de prova nous i afegiu-los als casos de prova existents.

Al ' mètode A ”, Els provadors poden trobar més defectes en els altres mòduls en els quals no estaven enfocats durant les proves anteriors o els desenvolupadors no eren extremadament prudents durant la codificació.

En el nostre exemple anterior, els verificadors poden trobar més defectes als mòduls Resum del compte, Transferència de fons o Instruccions permanents mitjançant el nou conjunt de casos de prova.

Però pot passar que els provadors descuidin el mòdul anterior ( Exemple: 'Overdraft') on es van trobar la majoria dels defectes en la iteració anterior i això podria suposar un risc, ja que aquest mòdul (Overdraft) podria haver estat injectat amb els nous defectes després de codificar els altres mòduls.

Al ' mètode B ”, Es preparen nous casos de prova perquè es puguin trobar nous defectes potencials a la resta de mòduls.

Aquí, en el nostre exemple, els casos de prova de nova creació podran ajudar a identificar defectes en mòduls com Resum del compte, Transferència de fons i Instruccions permanents. Tanmateix, els provadors no poden ignorar els mòduls propensos a defectes anteriors ( Exemple: 'Descobert') ja que aquests nous casos de prova es combinen amb els casos de prova existents.

Els casos de prova existents es van centrar més en el mòdul “Overdraft” i els nous casos de prova es van centrar en els altres mòduls. Per tant, tot el conjunt de casos de prova s’executen almenys una vegada que fins i tot es produeix un canvi de codi en qualsevol mòdul. Això assegurarà que s’executi la regressió adequada i que es pugui identificar el defecte a causa d’aquest canvi de codi.

Mitjançant el segon enfocament, el recompte total de casos de prova augmenta significativament i resulta en més esforços i temps necessaris per a l'execució. Això, òbviament, repercutirà en els terminis del projecte i, sobretot, en el pressupost del projecte.

Per tant, per superar aquest problema, es poden revisar i eliminar els casos de prova redundants. Hi ha molts casos de prova que es tornen inútils després d'afegir nous casos de prova i modificar els casos de prova existents.

Cal comprovar quins casos de prova han fallat per identificar els defectes de les darreres 5 iteracions (suposem 5 iteracions) i quins casos de prova no són molt importants. També es pot donar el cas que el flux únic cobert en alguns casos de prova es pugui cobrir en un altre cas de prova de cap a extrem i que es puguin eliminar aquells casos de prova que tinguin un flux únic.

Al seu torn, això reduirà el recompte total de casos de prova.

Per exemple ,tenim 50 casos de prova per cobrir un mòdul concret i hem vist que d’aquests 50 casos de prova 20 casos de prova no han pogut detectar un defecte nou en les darreres iteracions de prova (suposem 5 iteracions). Per tant, aquests 20 casos de prova s’han de revisar a fons i hem de comprovar la importància que tenen aquests casos de prova i, en conseqüència, es pot decidir si es conserven els 20 casos de prova o s’eliminen.

Abans d’eliminar qualsevol cas de prova, comproveu que el flux de funcionalitat cobert en aquests casos de prova estigui cobert en un altre cas de prova. Cal seguir aquest procés en tots els mòduls per tal de reduir significativament el recompte total de casos de prova. D’aquesta manera, es garantirà que es redueixi el recompte total dels casos de prova, però encara hi ha una cobertura de requisits del 100%.

Vol dir que tots els casos de prova restants cobreixen tots els requisits empresarials, de manera que no hi ha cap compromís sobre la qualitat.

Conclusió

La prova de programari és un pas essencial en SDLC, ja que verifica si el programari funciona tal com ho necessita o no l'usuari final.

Les proves identifiquen el màxim de defectes possible. Per tant, per tal de realitzar proves de manera eficaç i eficaç, tothom hauria de ser conscient i, de fet, entendre els set principis de les proves de programari i que se’ls coneix com els pilars de les proves.

La majoria dels provadors han implementat i experimentat aquests principis durant les proves reals.

retornant una matriu de cadena a Java

Generalment, el terme principi significa les regles o lleis que cal seguir. Per tant, tothom a la indústria de les proves de programari ha de seguir aquests set principis i, si algú ignora algun d’aquests principis, pot costar molt el projecte.

Bona lectura !!

Lectura recomanada

^