structural testing tutorial what is structural testing
Aquest complet tutorial de proves estructurals explica què són les proves estructurals, els seus tipus, què és la prova de flux de control i el gràfic de flux de control, els nivells de cobertura, etc.:
Una ràpida cerca a Google d’alguns dels errors de programari més cars va deixar la meva ment arriscada: 500.000 milions de dòlars. Sí, és tan costós que pot costar un error. Llegir qualsevol cosa relacionada amb la vida perduda a la indústria del transport i de la salut a causa d’un error de programari també pot ser horrible.
Tot i que els errors de codi no sempre són tan extrems en què impliquen la pèrdua de grans quantitats de diners i vides, l'única cosa clau que volem transmetre aquí és que no es pot passar per alt les proves.
Quan les proves es fan amb freqüència a tot el SDLC, ens permet detectar errors que necessitarien molt més temps per corregir després de l’enviament del producte.
El que és important són els tipus de proves de programari que triem. N’hi ha diversos, incloses les proves funcionals, estructurals i basades en els canvis.
Aquest tutorial també explica els tipus de proves estructurals. Obteniu informació sobre com fer proves de mutació, proves de segmentació, proves de flux de dades amb exemples i explicacions.
Què aprendreu:
- Per què és important la prova de programari
- Què són les proves estructurals
- Tipus de proves estructurals
- Avantatges i desavantatges de les proves estructurals
- Bones pràctiques de proves estructurals
- Conclusió
Per què és important la prova de programari
A més d’estalviar diners i evitar desastres com els casos esmentats anteriorment, hi ha altres motius que justifiquen la importància de les proves.
A continuació es detallen alguns motius:
# 1) Assegurar-se que es compleixen els requisits estipulats abans de començar a construir un projecte. Els grups d'interès (per exemple, desenvolupadors i clients) han d'acordar tots els aspectes de la solució / producte / programari necessaris per construir un projecte.
La prova implica verificar si es compleixen els requisits del programari. El desenvolupador o l’empresa que participa en la creació de la solució també guanyen una bona reputació pel fet de dissenyar una solució d’alta qualitat gestionada pel codi eclat.
# 2) Verifica que la funció de codi funcioni tal com es pretenia. La prova també implica verificar la funcionalitat del programari i, en cas de funcionament erroni, s’hauria de solucionar durant les primeres fases de SDLC (Software Development Life Cycle).
# 3) Comprova el rendiment: per exemple, per identificar el temps total transcorregut mentre s’executa el codi. Si en fem servir diversos Per a bucles al nostre codi, trigarem molt a obtenir la sortida prevista i, fins i tot, de vegades es pot esgotar el temps d’espera.
# 4) Ajuda a aconseguir una millor experiència d'usuari. Els usuaris no gaudiran d’utilitzar programes que no funcionin correctament, siguin fallits o siguin ‘massa lents’. És probable que els usuaris s’impacientin i deixin d’utilitzar el programari. Les proves ens proporcionen una millor idea per garantir que els usuaris puguin utilitzar fàcilment els nostres productes.
# 5) Comprova la seva escalabilitat. Un desenvolupador hauria d’orientar-se a la creació de programari que es pugui escalar.
# 6) Comprova si hi ha vulnerabilitats al codi. Les proves ens permeten tenir en compte les vulnerabilitats de seguretat, Per exemple, codi que pot comprometre’s PII (Informació d’identificació personal), que és una prioritat elevada per al GDPR.
En aquest article, ens centrarem en un tipus de proves, és a dir, Proves estructurals . Com el seu nom indica, té a veure amb l'estructura del codi. Això és diferent del que havíem esmentat anteriorment: les proves ajuden a determinar aspectes com el rendiment, la funcionalitat i la seguretat del codi.
Proves estructurals contra altres tipus de proves
Hi ha molts tipus de proves de programari. Tanmateix, el ATURA (International Software Testing Qualifications Board), defineix quatre tipus principals de proves de programari, a saber
- Funcional
- No funcional
- Estructural
- Basat en canvis
Les diferències es poden explicar a continuació:
Proves funcionals: Això implica verificar la funcionalitat del programari en funció dels requisits estipulats. Les dades de prova s’utilitzen com a entrada. També comprovem que la sortida donada és l’esperada.
Proves no funcionals : Això implica un procés de proves per analitzar el funcionament del programari, per exemple, el nombre d’usuaris que pot gestionar simultàniament.
Proves estructurals: Aquest tipus de proves es basa en l’estructura del codi. Per exemple, si es vol que un codi calculi la mitjana de nombres parells en una matriu, les proves basades en l'estructura estarien interessades en els 'passos que porten a calcular la mitjana', en lloc de si la sortida final és un valor numèric correcte.
Suposem que hem de comprovar si hem definit el codi que diferencia els nombres parells dels nombres senars. Podem tenir aquí una afirmació condicional, com si un element de matriu sigui divisible per dos sense resta, if (arr [i]% 2 === 0) llavors el número es pot dir com un número parell.
Les proves estructurals les duen a terme les mateixes persones que escriuen el codi tal com ho entenen millor.
Proves basades en canvis : Això implica provar els efectes de fer canvis al codi i després assegurar-se que els canvis realitzats s'han implementat. També garanteix que els canvis al codi no es trenquin.
El que no són les proves estructurals
Hem esmentat anteriorment que les proves basades en l'estructura es refereixen a l'estructura del codi. Tingueu en compte que aquí tractem el codi real. No comprovem els requisits ni tan sols comprovem les entrades amb les sortides esperades. En aquest moment no ens preocupa la funcionalitat, l’experiència de l’usuari ni el rendiment.
Què són les proves estructurals
Per tant, les proves basades en l'estructura es poden definir com un tipus de proves de programari que prova l'estructura del codi i els fluxos previstos. Per exemple, verificant el codi real per a aspectes com la implementació correcta d’instruccions condicionals i si totes les sentències del codi s’executen correctament. També es coneix com a prova basada en l'estructura.
Per dur a terme aquest tipus de proves, hem d’entendre a fons el codi. És per això que aquesta prova la fan normalment els desenvolupadors que han escrit el codi tal com ho entenen millor.
Com realitzar proves estructurals
Per provar diferents aspectes del codi, primer hem d’entendre els fluxos de control.
Prova de flux de control
Això deriva proves dels fluxos de control del codi (l’ordre en què s’implementen sentències, funcions i diferents aspectes del codi).
Procés de prova de flux de control:
Gràfic de flux de control
El procés de flux de control comença creant una representació visual de diferents seccions del codi que ens ajuda a definir els camins que es poden seguir durant l'execució.
Aquestes representacions visuals es coneixen com a gràfics de flux de control (CFG) i tenen diversos components com ara nodes, vores, camins, unions i punts de decisió. El gràfic es pot crear manualment o automàticament, on s’utilitza programari per extreure el gràfic del codi font.
Vegem aquests components a continuació:
# 1) Bloc de procés
Aquesta part s'utilitza per representar una secció de codi que s'executa seqüencialment. Això vol dir que s’executa de la mateixa manera cada vegada i que no hi ha decisions o ‘ramificacions’ que calgui fer. Està format per nodes amb un camí d’entrada i sortida.
Exemple de bloc de procés:
[imatge font ]
El bloc de procés no és una part essencial del flux de control i, en conseqüència, només s’ha de provar una vegada.
# 2) Punts de decisió
Aquests són alguns components clau del flux de control del codi. Dins d’aquests nodes, es prenen decisions. Normalment, es fa mitjançant la comparació i el flux de control canvia, segons la decisió. Aquesta part del CFG està formada per un node amb almenys 2 sortides.
La decisió que es pren aquí podria ser enunciats condicionals com ara enunciats if-else (que tenen dos possibles resultats) i enunciats de casos (que poden tenir més de dos resultats).
[imatge font ]
Al diagrama anterior, hi ha un punt de decisió (del condicional 'edat = 18') que va seguit de les opcions 'sí' o 'no'.
# 3) Punts d’unió
A partir del diagrama anterior, podem identificar fàcilment els punts d’unió sobre on s’uneixen els punts de decisió. Els punts d’unió poden tenir molts camins d’entrada, però només poden tenir un camí de sortida.
Pràctiques recomanades per als gràfics de flux de control:
Hi ha algunes coses a tenir en compte a l’hora de construir gràfics de flux de control:
- Proveu el màxim possible perquè el CFG sigui senzill. Ho podem fer combinant parts que es puguin considerar 'menys significatives', per exemple, blocs de processos.
- Assegureu-vos que en els punts de decisió només es pren una decisió. En els CFG més complexos, hi ha 'conseqüències' que es produeixen després de prendre la decisió. En el nostre exemple anterior, també podríem afegir que si una persona té 18 anys o més, és elegible i ha de pagar un bitllet. Si no ho són, l’entrada és gratuïta. La decisió 'else' ha de 'saltar-se' uns quants nodes i tots aquests passos s'han de mostrar al nostre CFG.
Un cop hem definit el nostre CFG, és hora de passar al següent pas del procés de proves de flux de control, és a dir, de definir fins a quin punt provarem el codi.
Definir quant provar:
Quina part del codi font s’ha de provar? Hem de provar cada possible camí? Intentar cobrir tots els camins de les nostres proves és pràcticament impossible. Hem de trobar un punt intermedi per determinar quantes proves podem fer.
Si diem que pretenem provar el 50% del nostre codi, això podria significar que definirem totes les sentències de codi executables i tindrem com a objectiu provar-ne almenys la meitat. Tanmateix, la pregunta que sorgeix aquí és: 'Cal definir tots els camins executables possibles?'
Això pot tornar a ser pràcticament impossible. Un enfocament millor podria tenir com a objectiu provar el 50% dels camins que podem identificar a cada secció del codi.
Hi ha diferents nivells de cobertura, a saber, declaració, sucursal i cobertura del camí. Els examinarem breument més endavant.
Creació de casos de prova:
El següent pas és crear els casos de prova que farem servir. Els casos de prova en proves basades en l'estructura es basen en els següents factors:
- Les sentències executables.
- Les ‘decisions’ que cal prendre.
- Els possibles camins que es poden seguir.
- Les condicions que cal complir (aquestes poden ser múltiples o booleanes).
Els factors anteriors ens donen una idea dels tipus de casos de prova que hem de crear. També podem utilitzar una eina de generació de proves estructurals. Si el nostre codi es troba en llenguatge de programació C, podem utilitzar PathCrawler per generar codi de prova. Una altra eina que podem utilitzar és fMBT.
Execució dels casos de prova:
Aquí, fem les proves. Podem introduir dades o dades per comprovar com l’executa el codi i verificar després si obtenim els resultats esperats. Per exemple, introduïu una matriu en una trucada de funció per observar els resultats que obtenim després de fer-ne un bucle o per comprovar si els punts de decisió estan prenent les decisions correctes.
Analitzant els resultats:
En aquesta part, tot el que fem és comprovar si obtenim els resultats correctes després de l'execució. Per exemple, si introduïm una matriu en què tots els valors superen els 18, hauríem de tenir tots els punts de decisió que resultarien 'elegibles'.
Supòsits de flux de control
És important tenir en compte que per dur a terme proves de flux de control, es fan algunes suposicions. Això inclou:
- Els únics errors presents són aquells que poden afectar el flux de control.
- Totes les variables, funcions i elements estan definits amb precisió.
Nivells de cobertura en els fluxos de control
Com hem esmentat anteriorment, hi ha diferents nivells de cobertura en les proves de flux de control.
Vegem-los breument.
# 1) Cobertura de la declaració
En les proves estructurals, les declaracions de codi executables tenen un paper vital a l’hora de decidir els mètodes de disseny de les proves.
El nostre objectiu és aconseguir una cobertura del 100%, cosa que significa que cada instrucció executable s’ha provat almenys una vegada. Com més gran sigui la cobertura, menys hi haurà la probabilitat de perdre els errors i errors.
Aquí és obligatori utilitzar casos de prova. Les dades que necessitem són per assegurar-nos que cada instrucció executable d’un bloc de codi s’executi almenys una vegada.
# 2) Cobertura de sucursal
Aquest nivell de cobertura consisteix a provar els punts de les oficines de CFG (on es prenen decisions). Els resultats són booleans. Fins i tot si s’utilitza una instrucció switch i hi ha múltiples resultats, en essència, cada bloc de casos és una comparació d’un parell de valors.
Igual que amb la cobertura d’extracte, hauríem d’obtenir una cobertura del 100% d’oficines. Per aconseguir-ho, hem de provar cada resultat en cada nivell de decisió almenys una vegada. Com que estem tractant de resultats booleans, hauríem de tenir com a objectiu realitzar almenys 2 proves per secció de codi.
programari que s’instal·la en un ordinador i s’utilitza per gestionar màquines virtuals
# 3) Cobertura del camí
Aquest nivell de cobertura és més exhaustiu en comparació amb la cobertura de decisions i declaracions. L'objectiu aquí és 'descobrir' tots els camins possibles i provar-los almenys una vegada. Això pot consumir molt de temps. No obstant això, pot ajudar a descobrir errors o errors al nostre codi, o fins i tot aspectes que hem de definir, per exemple, entrada de l'usuari.
Tipus de proves estructurals
[imatge font ]
Proves de mutació
La prova de mutació és una tècnica de prova basada en errors en què es posen a prova diverses variacions d'una aplicació de programari amb el conjunt de dades de prova.
>> Consulteu aquest tutorial per veure'n més a fons Proves de mutació.
Prova basada en talls
Les proves basades en slice (SBT) es poden definir com una tècnica de prova de programari en què es basa llesques - parts executables del programa o grups d’instruccions que afecten alguns valors en punts d’interès particulars del programa, per exemple, parts on es defineixen les variables o la sortida d’un grup d’instruccions.
Com fer llesques
Exemple de tallat a SBT: Codi per imprimir números parells i senars (Python)
num_list = range(1,12) even_nums = [] odd_nums = [] for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Hi ha dues maneres de veure una llesca: Seguint el camí d'una variable d'interès o de la part del codi que afecta la sortida.
En el nostre exemple, si observem la sortida de nombres senars, podem rastrejar la part del codi que ens condueix a aquesta sortida.
En els criteris de segmentació donats per Mark Weiser (que va introduir SBT), es defineix un segment mitjançant aquesta fórmula: S (v, n) , on, v fa referència a la variable en qüestió ( per exemple, on es defineix una variable), i n és la declaració d'interès ( per exemple, on es dóna la sortida), i S significa la llesca.
A l'exemple anterior, per obtenir la porció, comencem a partir de la nostra sortida a la línia 10, que es converteix en la nostra n . La nostra variable és on .
Per tant, el nostre criteri de segmentació és:
S(v,n) = S(var,10)
La nostra preocupació són les afirmacions que ens porten a la producció.
Aquests són:
10,9,8,4,3,1
Per tant, la nostra secció d’aquest codi és:
num_list = range(1,12) odd_nums = [] for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Tipus de proves basades en llesques
Hi ha dos tipus de SBT: estàtic i dinàmic
# 1) Prova dinàmica basada en talls
L'exemple SBT explicat anteriorment on vam veure les afirmacions que afecten la impressió dels nombres senars és el SBT dinàmic. La nostra preocupació és molt específica. Ens centrem només en allò que afecta directament a la producció concreta.
Executem el codi i fem servir les dades de prova per assegurar-nos que funcioni tal com es suposa. Podríem augmentar l'interval fins a l'interval (1,50), per exemple, per veure si encara genera només nombres senars. Dynamic SBT també es coneix com a prova de validació.
# 2) EstàticProva basada en talls
A diferència de Dynamic SBT, les proves estàtiques es centren en una variable concreta. Si pensem en la nostra producció a l'exemple anterior com on , podem traçar la llesca que l’afecta com a 10,9,8,7,6,5,4,3,2,1
Bàsicament és tot el bloc de codi. Aquí comprovem que el codi és correcte en termes de sintaxi i requisits, i no l'executem. El SBT estàtic també es coneix com a prova de verificació.
És important tenir en compte que el SBT dinàmic és 'més petit' en comparació amb el seu homòleg estàtic. També és més específic.
Pràctiques recomanades / Directrius per a proves basades en seccions
Els criteris de segmentació s’han de determinar segons:
- Enunciats on es defineixen valors o s’assigna un valor, així com un valor reassignat.
- Declaracions on es reben valors des de fora del programa, per exemple, mitjançant l'entrada de l'usuari.
- Instruccions que imprimeixen la sortida / retorn de la sortida.
- L’última declaració del programa, per exemple, una trucada de funció que pot definir valors o proporcionar valors als arguments
Els avantatges de les proves basades en llesques inclouen:
- Com que a SBT només treballem amb àrees d’interès específiques, facilita la generació efectiva de suites de proves.
- El camí està definit per dependències del codi, que és millor que utilitzar-les cobertura del camí.
- Amb SBT, és més fàcil trobar errors al codi font.
Els desavantatges de les proves basades en llesques inclouen:
- Si utilitzem proves dinàmiques quan provem una base de codis gran, necessitarem molts recursos computacionals.
- Si fem servir proves estàtiques, és possible que ens perdem errors.
Prova de flux de dades
Les proves de flux de dades es poden definir com una tècnica de prova de programari que es basa en els valors de les dades i el seu ús en un programa. Verifica que s’han utilitzat correctament els valors de les dades i que generen els resultats correctes. Les proves de flux de dades ajuden a rastrejar les dependències entre valors de dades en un camí d’execució concret.
Anomalies del flux de dades
Les anomalies del flux de dades són simplement errors en un programa. Es classifiquen en tipus 1, 2 i 3 respectivament.
Aprofundim en ells a continuació:
Tipus 1: Es defineix una variable i se li assigna un valor dues vegades.
Codi d'exemple: Python
lst_1 = [1,2,3,4] lst_1 = [5,6,7,8] for var in lst_1: print(var)
Lst_1 està definit i se li assignen dos valors diferents. El primer valor simplement s’ignora. Les anomalies de tipus 1 no fan que el programa falli.
Tipus 2: S’utilitza o fa referència al valor d’una variable abans de definir-la.
Codi d'exemple: Python
for var in lst_1: print(var)
El bucle anterior no té valors a repetir. Les anomalies de tipus 2 fan que el programa falli.
Tipus 3: A es genera el valor de les dades, però no s’utilitza mai.
Codi d'exemple: Python
lst_1 = [1,2,3,4] lst_2 = [5,6,7,8] for var in lst_1: print(var)
La variable lst_2 no s'ha fet referència. Les anomalies de tipus 3 poden no provocar un error del programa.
Procés de prova de flux de dades
Per definir les dependències entre valors de dades, hem de definir els diferents camins que es poden seguir en un programa. Per fer-ho efectivament, hem de demanar prestat a un altre tipus de proves estructurals conegut com proves de control de flux .
Pas 1) Dibuixa un gràfic de flux de control
Hem de dibuixar un gràfic de flux de control, que és una representació gràfica dels camins que podríem seguir al nostre programa.
Codi d'exemple: Python
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)
A l'exemple de codi anterior, un membre hauria d'obtenir un descompte si convida un visitant.
Gràfic de flux de control (CFG):
Pas 2) Exploreu la definició i ús de variables i valors de dades.
Es defineix o s’utilitza una variable d’un programa. A CFG, tenim variables a cada node. Cada node s’anomena segons el tipus de variable que allotja. Si es defineix una variable en un node concret, es crea un node que defineix. Si s'utilitza una variable en un node, es crea un node d'ús.
Si considerem el cost variable en CFG, aquests són els nodes de definició i d’ús:
Node | Tipus | Codi |
---|---|---|
1 | Node definidor | cost = 20 |
5 | Node d'ús | factura = cost -1 |
7 | Node d'ús | factura = cost |
Pas 3) Definiu camins d'ús de definició.
Hi ha dos tipus de camins d’ús de definició: camins du i camins de corrent continu. Els camins són camins de definició que comencen amb un node de definició i acaben amb un node d’ús. Aquest és el cas del camí en referència al cost variable anterior.
Un exemple de camí de corrent continu, un camí de decisió clar, és el camí de la variable de factura que es mostra a continuació:
Node | Tipus | Codi |
---|---|---|
5 | Node definidor | factura = cost -1 |
7 | Node definidor | factura = cost |
8 | Node d'ús | imprimir (factura) |
El camí de corrent continu té més d'un node de definició tot i que encara acaba en un node d'ús.
Pas 4) Creeu el conjunt de proves.
Això és afegir entrada. Tingueu en compte que hem de tenir un conjunt de proves diferent per a cada variable. El conjunt de proves ens ajudarà a identificar les anomalies del flux de dades.
Tipus de proves de flux de dades
Hi ha dos tipus: Estàtica i dinàmica .
Estàtic significa que revisem el codi i CFG per identificar anomalies de dades, sense executar-les. Dinàmic significa que realment identifiquem els camins específics i, a continuació, creem suites de proves per provar-les amb l'objectiu de 'captar' anomalies que potser ens hem perdut durant les proves estàtiques.
Avantatges i desavantatges de les proves de flux de dades:
- Les proves de flux de dades són ideals per identificar anomalies de flux de dades, cosa que el converteix en un mètode de prova estructural molt eficaç.
- El seu inconvenient és que cal conèixer bé el llenguatge utilitzat per escriure el codi per utilitzar les proves de flux de dades. També requereix molt de temps.
Avantatges i desavantatges de les proves estructurals
Vegem ara els motius pels quals les proves estructurals són un gran enfocament i explorem també alguns dels seus inconvenients.
Avantatges:
- Permet fer proves exhaustives del codi, cosa que provoca errors mínims. Les proves basades en l'estructura permeten que el programari es pugui provar a fons. Els diferents nivells de cobertura: declaració per declaració, cada punt de decisió i camí tenen com a objectiu assolir una cobertura del 100%, cosa que redueix en gran mesura les possibilitats que els errors es detectin.
- La capacitat d’automatitzar . Hi ha diverses eines que podem utilitzar per automatitzar les proves. Això ens ajudarà a aconseguir la màxima cobertura de codi i en un temps més curt en comparació amb fer les proves manualment.
- Es tradueix en un codi de major qualitat . Els desenvolupadors tenen la possibilitat d’estudiar l’estructura i la implementació del codi i corregir els errors, així com millorar aquests aspectes. Ens permet tenir en compte la gran estructura a mesura que escrivim parts posteriors de codi o implementem funcions restants.
- Es pot fer a través de cada fase del SDLC - Les proves estructurals es poden fer a cada fase del SDLC sense esperar que el desenvolupament es completi al 100%. Això fa que sigui fàcil identificar els errors en la fase inicial i, per tant, estalviar molt de temps en comparació amb les proves un cop finalitzat el desenvolupament.
- Ajuda a desfer-se del codi mort . Això es pot veure com a codi 'extra' o innecessari, per exemple, codi que calcularà un resultat però que mai no l’utilitzarà en cap dels càlculs següents.
- Eficiència - Com que els desenvolupadors que escriuen el codi són els mateixos que el proven, no cal que participeu altres persones com els QA.
Desavantatges:
- Els desenvolupadors que realitzen proves basades en l'estructura han de tenir una comprensió completa del llenguatge . Altres desenvolupadors i QA que no estiguin ben versats en l'idioma no poden ajudar-vos a fer proves.
- Pot arribar a ser força car en termes de temps i diners . Es necessita molt de temps i recursos per fer proves de manera eficient.
- Provoca retards en el lliurament de funcions . Això es deu al fet que els desenvolupadors es retiren de crear programari per fer proves.
- L’escala és un problema, especialment quan hi ha aplicacions grans . Una gran aplicació equival a un nombre excessivament elevat de rutes a cobrir. Assolir el 100% de cobertura és impossible.
- Pot haver-hi casos i rutes perdudes , per exemple, en un cas en què les funcions no estan completament desenvolupades o encara estan per desenvolupar. Això vol dir que s’ha de combinar amb altres tipus de proves, com ara la prova de requisits (on comprovem les funcions especificades que calia construir).
Bones pràctiques de proves estructurals
Alguns dels factors que requereixen atenció durant la realització de proves basades en l'estructura són els següents:
- Etiqueu i poseu un nom clar a les proves . Si algú ha de fer les proves, ha de ser capaç de localitzar-les fàcilment.
- Abans de millorar el codi, és a dir, refactoritzant-lo i optimitzant-lo per utilitzar-lo en diferents entorns, assegureu-vos que la seva estructura i flux siguin ideals.
- Executeu les proves per separat . D’aquesta manera, és fàcil identificar i corregir errors. D'altra banda, és menys probable que perdem errors o camins com a conseqüència de superposicions en seccions de codi, blocs o camins.
- Genereu proves abans de fer canvis . Les proves s’executen com s’esperava. D'aquesta manera, si alguna cosa es trenca, és fàcil rastrejar i solucionar el problema.
- Mantingueu separades les proves de cada secció o bloc de codi . D'aquesta manera, si hi ha canvis a la línia, no hem de canviar moltes proves.
- Corregiu els errors abans de continuar amb la prova . Si identifiquem algun error, és millor corregir-los abans de procedir a provar la següent secció o bloc de codi.
- No ometeu mai les proves estructurals amb el supòsit que un control de qualitat 'encara farà proves igualment'. Fins i tot si els errors poden semblar insignificants al principi, acumulativament, poden donar lloc a un codi de buggy que mai no pot assolir el propòsit previst.
Preguntes més freqüents per a proves basades en l'estructura
Aquí explorarem les preguntes més freqüents quan es tracta de proves basades en l'estructura.
Q # 1) Quina diferència hi ha entre proves funcionals i proves estructurals?
Resposta: Les proves funcionals són un tipus de proves de programari basades en els requisits estipulats a la SRS (Software Requirements Specifications). Normalment es fa en un intent de trobar disparitats entre les especificacions del SRS i el funcionament del codi. Les proves estructurals es basen en l’estructura interna del codi i la seva implementació. Cal una comprensió exhaustiva del codi.
Q # 2) Quins són els tipus de proves estructurals?
Respondre a la Els tipus inclouen:
- Proves de flux de dades
- Proves de mutació
- Control de proves de flux
- Prova basada en llesques
P # 3) Què és un exemple de proves estructurals?
Resposta: Aquí teniu un exemple que mostra la cobertura de les declaracions:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();
La quantitat de cobertura que obtinguem depèn de les dades de prova que proporcionem com a entrada (si compleix la suma> 0 condicions).
Q # 4) Quina diferència hi ha entre les proves de flux de dades i les proves de flux de control?
Resposta: Tant les proves de flux de dades com les proves de flux de control utilitzen gràfics de flux de control. L’única diferència és que en les proves de flux de control, ens centrem en els camins generats a partir del codi, mentre que en les proves de flux de dades, ens centrem en els valors de les dades, la seva definició i l’ús dins dels camins identificats dins d’un programa.
P # 5) Per a què serveixen les proves de flux de dades?
Resposta: Les proves de flux de dades són ideals per identificar anomalies en l’ús de valors de dades dins de camins en un gràfic de flux de control, per exemple, una variable a la qual se li ha assignat un valor dues vegades, una variable que s'ha definit i no s'ha utilitzat, o una variable que s'ha utilitzat o s'ha referenciat i no s'ha definit.
P # 6) Quina diferència hi ha entre tallar i tallar a daus a les proves de programari?
Resposta: Tallar significa centrar-se en declaracions d’interès particulars d’un programa i ignorar la resta. El fet de fer el dit és quan identifiquem una llesca que té una entrada incorrecta i, a continuació, la fem més llesca per rastrejar el comportament correcte.
Q # 7) Quina diferència hi ha entre la prova de mutació i la cobertura de codi?
Resposta: A les proves de mutació, considerem el nombre de mutants morts com a percentatge del total de mutants. La cobertura del codi és simplement la quantitat de codi que s’ha provat en un programa.
Conclusió
En aquest tutorial hem analitzat a fons les proves estructurals: què és, què no, com fer-ho, tipus de cobertura, avantatges i desavantatges, bones pràctiques i fins i tot algunes preguntes més freqüents sobre aquest tipus de proves de programari.
Encara hi ha molt més que podem aprendre sobre les proves basades en l'estructura. En futurs tutorials, explorarem la cobertura del codi (declaració, decisió, branca i camí), els tipus de proves estructurals (mutació, flux de dades i basats en slice) i fins i tot les eines que podem utilitzar per automatitzar aquests processos de prova.
És important tenir en compte que no hi ha cap tipus de prova o enfocament de programari que sigui 100% eficient. Sempre és aconsellable combinar diferents tipus de proves i enfocaments.
Per exemple, les proves estructurals es complementen en gran mesura amb les proves de requisits, ja que pot haver-hi funcions que potser no s'havien desenvolupat en el moment en què es realitzaven proves basades en l'estructura.
Les tècniques de proves estructurals es basen en els errors que cometen els programadors humans en escriure codi. La suposició és que el programador és un expert i sap el que està codificant, però de tant en tant s’equivoca.
Els diferents tipus de proves estructurals que hem analitzat: les proves de mutació, les proves basades en talls i les proves de flux de dades es poden remuntar a errors com fer servir un operador incorrecte (prova de mutació) o fer referència a una variable abans d’utilitzar-la (prova de flux de dades) .
Lectura recomanada
- Tutorial de proves destructives i proves no destructives
- Proves funcionals contra proves no funcionals
- Què és la tècnica de proves basades en defectes?
- Tutorial de proves de remull: què és la prova de remull
- Tutorial de proves SOA: metodologia de proves per a un model d’arquitectura SOA
- Prova de càrrega amb tutorials HP LoadRunner
- Què és la prova de gamma? Fase de proves finals
- Tutorial de proves DevOps: com impactarà DevOps en les proves de control de qualitat?
- Què són les proves de conformitat (proves de conformitat)?