Menú

Proves de caixes blanques: una guia completa amb tècniques, exemples i eines

white box testing complete guide with techniques

Proveu El Nostre Instrument Per Eliminar Problemes

Què són les proves White Box?

Si seguim la definició, 'Prova de caixa blanca' (també coneguda com a prova de caixa de vidre transparent o estructural) és una tècnica de prova que avalua el codi i l'estructura interna d'un programa.

La prova de caixes blanques consisteix a mirar l'estructura del codi. Quan es coneix l'estructura interna d'un producte, es poden realitzar proves per assegurar-se que les operacions internes es realitzen segons l'especificació. I tots els components interns s’han exercit adequadament.

Prova de caixa blanca amb exemple

Què aprendreu:

La meva experiència

Ara fa gairebé una dècada que em dedico al camp de les proves de programari i fins ara he notat que els provadors són els més entusiastes de tota la indústria del programari.

La raó principal d’aquest fet és que el provador sempre té alguna cosa a l’abast per aprendre. Ja sigui un domini, un procés o una tecnologia, un provador pot tenir un desenvolupament complet si ho desitja.

Però com es diu 'Sempre hi ha un costat més fosc' .

De fet, els provadors també eviten un tipus de prova que consideren molt complicat i el pastís del desenvolupador. Sí, la 'Prova de caixa blanca'.

Cobertura

Les proves de caixes blanques són la cobertura de les especificacions del codi:

1. Cobertura del codi

2. Cobertura del segment: Assegureu-vos que cada instrucció de codi s’executa una vegada.

3. Cobertura de sucursal o proves de nodes: La cobertura de cada branca de codi era possible.

4. Cobertura de l'estat compost: Per a diverses condicions, proveu cada condició amb diversos camins i combinació dels diferents camins per arribar a aquesta condició.

5. Prova de camí bàsic: Cada ruta independent del codi es pren per a la prova.

6. Prova de flux de dades (DFT): En aquest enfocament, feu un seguiment de les variables específiques a través de cada possible càlcul, definint així el conjunt de camins intermedis a través del codi. DFT tendeix a reflectir dependències, però és principalment mitjançant seqüències de manipulació de dades. En resum, es fa un seguiment de cada variable de dades i es comprova el seu ús. Aquest enfocament tendeix a descobrir errors com variables utilitzades però no inicialitzades, o declarades però no utilitzades, etc.

7. Prova de camí: La prova de camins és on es defineixen i cobreixen tots els camins possibles a través del codi. És una tasca que requereix molt de temps.

8. Proves de bucle: Aquestes estratègies estan relacionades amb la prova de bucles individuals, bucles concatenats i bucles imbricats. Amb aquest enfocament es posen a prova bucles i valors de codi independents i dependents.

Per què realitzem WBT?

Per assegurar:

  • Que tots els camins independents d'un mòdul s'han exercit almenys una vegada.
  • Totes les decisions lògiques es verificen sobre els seus valors veritables i falsos.
  • Tots els bucles executats als seus límits i dins dels seus límits operatius validesa de les estructures de dades internes.

Per descobrir els tipus d'errors següents:

  • Els errors lògics tendeixen a introduir-se en el nostre treball quan dissenyem i implementem funcions, condicions o controls que estan fora del programa
  • Els errors de disseny a causa de la diferència entre el flux lògic del programa i la implementació real
  • Comprovació d'errors tipogràfics i de sintaxi

Aquesta prova requereix habilitats de programació detallades?

Hem d’escriure casos de prova que garanteixin la cobertura completa de la lògica del programa.

Per a això, hem de conèixer bé el programa, és a dir, hem de conèixer l’especificació i el codi a provar. Per a aquest tipus de proves cal tenir coneixements de llenguatges i llenguatges de programació.

Limitacions

No és possible provar tots i cadascun dels camins dels bucles del programa. Això significa que les proves exhaustives són impossibles per a sistemes grans.

Això no vol dir que WBT no sigui efectiu. La selecció de camins lògics importants i una estructura de dades per provar és pràcticament possible i eficaç.

Diferència entre les proves White-Box i Black-Box

Per dir-ho en termes simples:

A les proves Black box, provem el programari des del punt de vista de l'usuari, però a White box, veiem i provem el codi real.

A la prova de caixa negra, realitzem proves sense veure el codi intern del sistema, però a WBT sí que veiem i provem el codi intern.

Tant els desenvolupadors com els provadors utilitzen la tècnica de proves de caixes blanques. Els ajuda a entendre quina línia de codi s’executa realment i quina no. Això pot indicar que falta una lògica o una errada tipogràfica, cosa que finalment pot provocar algunes conseqüències negatives.

Lectura recomanada => Una guia completa sobre les proves de Black Box

Passos per realitzar WBT

Pas 1 - Comprendre la funcionalitat d’una aplicació mitjançant el seu codi font. El que significa que un provador ha de tenir un bon coneixement del llenguatge de programació i de les altres eines i tècniques que s’utilitzen per desenvolupar el programari.

Pas 2 - Crear les proves i executar-les.

Quan discutim el concepte de proves, “ cobertura ”Es considera el factor més important. Aquí explicaré com tenir la màxima cobertura des del context de les proves de caixa blanca.

Llegiu també=> Gràfic de causes i efectes - Tècnica d'escriptura de casos dinàmics de prova per a la màxima cobertura

Tipus i tècniques de proves de caixes blanques

Hi ha diversos tipus i mètodes diferents per a cada tipus de prova de caixa blanca.

Consulteu la imatge següent per obtenir la vostra referència.

Tipus de proves de caixes blanques

Avui ens centrarem principalment en el tipus d’execució de proves de ‘Tècnica de caixa blanca de prova d’unitat’.

3 tècniques principals de proves de caixa blanca:

  1. Cobertura de la declaració
  2. Cobertura de sucursal
  3. Cobertura del camí

Tingueu en compte que la declaració, la sucursal o la cobertura del camí no identifica cap error o defecte que calgui solucionar. Només identifica aquelles línies de codi que no s’executen mai o que no es toquen. Basant-se en això, es poden centrar més proves.

Anem a entendre aquestes tècniques una per una amb un exemple senzill.

# 1) Cobertura de l'extracte:

En un llenguatge de programació, una afirmació no és res més que la línia de codi o instruccions perquè l’ordinador entengui i actuï en conseqüència. Una sentència es converteix en una sentència executable quan es compila i es converteix en codi objecte i realitza l'acció quan el programa està en mode d'execució.

Per tant 'Cobertura de la declaració' , com el propi nom indica, és el mètode per validar si totes i cadascuna de les línies del codi s’executen almenys una vegada.

# 2) Cobertura d'oficina:

'Branch' en un llenguatge de programació és com les 'sentències IF'. Una sentència IF té dues branques: T carrer i Fals .

Per tant, a la cobertura de sucursal (també anomenada cobertura de decisions), validem si cada sucursal s’executa almenys una vegada.

En cas d'una 'declaració IF', hi haurà dues condicions de prova:

  • Un per validar la veritable branca i,
  • Un altre per validar la branca falsa.

Per tant, en teoria, la cobertura de sucursal és un mètode de prova que quan s’executa assegura que s’executen totes i cadascuna de les sucursals de cada punt de decisió.

# 3) Cobertura del camí

La cobertura del camí prova tots els camins del programa. Aquesta és una tècnica completa que garanteix que tots els camins del programa es recorrin almenys una vegada. La cobertura del camí és encara més potent que la cobertura de la sucursal. Aquesta tècnica és útil per provar els programes complexos.

Prenem un exemple senzill per entendre totes aquestes tècniques de proves de caixes blanques.

SQL consulta les preguntes i respostes de les entrevistes per a estudiants de primer any

Comproveu també=> Diferents tipus de proves

Exemple de prova de caixa blanca

Penseu en el pseudocodi simple següent:

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE”

Per a Cobertura de la declaració - només necessitaríem un cas de prova per comprovar totes les línies del codi.

Això significa:

Si ho tinc en compte TestCase_01 serà (A = 40 i B = 70), llavors s'executaran totes les línies de codi.

Ara sorgeix la pregunta:

  1. És suficient?
  2. Què passa si considero que el meu cas de prova és A = 33 i B = 45?

Com que la cobertura de la declaració només cobrirà el costat veritable, per al pseudocodi, només un cas de prova NO seria suficient per provar-lo. Com a provador, també hem de considerar els casos negatius.

Per tant, cal tenir en compte la màxima cobertura ' Cobertura de sucursal ' , que avaluarà les condicions “FALSES”.

Al món real, podeu afegir sentències adequades quan la condició falla.

Ara el pseudocodi es converteix en:

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” ELSE PRINT “ITS PENDING”

Com que la cobertura de la declaració no és suficient per provar tot el pseudo codi, requeriríem la cobertura de la sucursal per garantir la màxima cobertura .

Per tant, per a la cobertura de la sucursal, necessitaríem dos casos de prova per completar la prova d’aquest pseudocodi.

TestCase_01 : A = 33, B = 45

TestCase_02 : A = 25, B = 30

Amb això, podem veure que totes i cadascuna de les línies del codi s’executa almenys una vegada.

A continuació, es detallen les conclusions que s’han derivat fins ara:

  • La cobertura de sucursal garanteix més cobertura que la cobertura de extractes.
  • La cobertura d'oficines és més poderosa que la cobertura de declaracions.
  • La cobertura del 100% de la sucursal significa una cobertura del 100% dels extractes.
  • Però la cobertura del 100% de les declaracions no garanteix la cobertura del 100% de les oficines.

Ara passem a Cobertura del camí:

Com s’ha dit anteriorment, la cobertura del camí s’utilitza per provar els fragments de codi complexos, que bàsicament impliquen sentències de bucle o combinació de bucles i sentències de decisió.

Penseu en aquest pseudocodi:

INPUT A & B C = A + B IF C>100 PRINT “ITS DONE” END IF IF A>50 PRINT “ITS PENDING” END IF

Ara, per garantir la màxima cobertura, necessitaríem 4 casos de prova.

Com? Simplement, hi ha dues declaracions de decisió, de manera que per a cada declaració de decisió necessitaríem dues branques per provar-les. Un per al veritable i l'altre per al fals estat. Per tant, per a dues declaracions de decisió, requeriríem 2 casos de prova per provar el costat veritable i 2 casos de prova per provar el costat fals, cosa que fa un total de 4 casos de prova.

Per simplificar-los, considerem a continuació el diagrama de flux del pseudocodi que tenim:

Cobertura del camí 1

Per tenir la cobertura completa, necessitaríem els següents casos de prova:

TestCase_01: A = 50, B = 60

TestCase_02 : A = 55, B = 40

TestCase_03: A = 40, B = 65

TestCase_04: A = 30, B = 30

Així doncs, el camí recorregut serà:

Cobertura del camí 2

Línia vermella - TestCase_01 = (A = 50, B = 60)

Línia blava = TestCase_02 = (A = 55, B = 40)

Línia taronja = TestCase_03 = (A = 40, B = 65)

Línia verda = TestCase_04 = (A = 30, B = 30)

******************
= >> Contacti amb nosaltres per suggerir el vostre llistat aquí
*****************

Eines de prova de caixa blanca

A continuació es mostra una llista de les millors eines de prova de caixes blanques.

# 1) Veracode

Veracode

Les eines de prova de la caixa blanca de Veracode us ajudaran a identificar i resoldre els defectes del programari de forma ràpida i senzilla a un cost reduït. Admet diversos llenguatges d'aplicacions com .NET, C ++, JAVA, etc. i també us permet provar la seguretat de les aplicacions d'escriptori, web i mòbils. Tot i això, hi ha altres avantatges de l'eina Veracode. Per obtenir informació detallada sobre les eines de prova de la caixa blanca de Veracode, consulteu l’enllaç següent.

Enllaç al lloc web: Veracode

# 2) EclEmma

EclEmma

EclEmma es va dissenyar inicialment per realitzar proves i anàlisis dins del banc de treball Eclipse. Es considera una eina gratuïta de cobertura de codi Java i també té diverses funcions. Per instal·lar o saber més sobre EclEmma, ​​consulteu l'enllaç següent.

Enllaç del lloc web: EclEmma

# 3) RCUNIT

RCUnit

Un framework que s’utilitza per provar programes C es coneix com RCUNIT. RCUNIT es pot utilitzar en conseqüència segons els termes de la llicència MIT. És d’ús gratuït i, per instal·lar-lo o saber-ne més, consulteu l’enllaç següent.

Enllaç del lloc web: RCUNIT

# 4) cfix

cfix és un dels marcs de proves unitàries per a C / C ++ que té com a únic objectiu fer el desenvolupament de les suites de proves el més senzill i fàcil possible. Mentrestant, cfix normalment està especialitzat en el mode NT Kernel i Win32. Per instal·lar i saber més sobre cfix, consulteu l'enllaç següent

Enllaç del lloc web: cfix

# 5) Prova de Google

Prova de Google

Googletest és el marc de proves de C ++ de Google. Descobriment de proves, proves de mort, proves amb paràmetres de valor, fallades mortals i no mortals, generació d'informes de proves XML, etc., són algunes de les funcions de GoogleTest, però també hi ha diverses altres funcions. Linux, Windows, Symbian, Mac OS X són poques plataformes on s’ha utilitzat GoogleTest. Per tal deBaixeu-lo, si us plau, consulteu l'enllaç següent.

Enllaç de descàrrega: Prova de Google

# 6) EMMA

Emma

Emma és una eina gratuïta de cobertura de codi JAVA fàcil d'utilitzar. Inclou diverses funcions i avantatges. Per descarregar i saber més sobre Emma, ​​consulteu l'enllaç següent.

Enllaç de descàrrega: EMMA

# 7) NUnit

NUnit

NUnit és un marc de proves d'unitats de codi obert fàcil d'utilitzar que no requereix cap intervenció manual per jutjar els resultats de les proves. És compatible amb tots els llenguatges .NET. També admet proves basades en dades i proves paral·leles a NUnit. Les versions anteriors de NUnit utilitzaven la llicència NUnit, però NUnit 3 es publica sota la llicència MIT. Però ambdues llicències permeten l’ús gratuït sense restriccions. Per descarregar i saber més sobre NUnit, consulteu l'enllaç següent.

Enllaç de descàrrega: NUnit

# 8) CppUnit

CppUnit

CppUnit és un marc de proves d’unitats escrit en C ++ i es considera el port de JUnit. La sortida de prova per a CppUnit pot ser en format XML o text. Crea proves unitàries amb la seva pròpia classe i executa proves a les sales de proves. Està llicenciat sota LGPL. Per descarregar i saber més sobre CppUnit, consulteu l'enllaç següent.

Enllaç de descàrrega: CppUnit

# 9) JUnit

JUnit

JUnit és un marc de prova d’unitat senzill i tranquil que admet l’automatització de proves en llenguatge de programació Java. Principalment és compatible amb el desenvolupament impulsat per proves i també proporciona l'informe de cobertura de proves. Està llicenciat sota la llicència pública Eclipse. Per a la descàrrega gratuïta i per obtenir més informació sobre JUnit, consulteu l'enllaç següent.

regex_match c ++

Enllaç de descàrrega: JUnit

# 10) JsUnit

JsUnit

Es considera que JsUnit és el port de JUnit a JavaScript. I és un marc de proves d’unitats de codi obert per donar suport a Javascript a la cara del client. Està llicenciat sota GNU Public License 2.0, GNU Lesser Public License 2.1 i Mozilla Public License 1.1. Per descarregar i saber més sobre JsUnit, consulteu l'enllaç següent.

Enllaç de descàrrega: JsUnit

A més, consulteu totes les eines que detallem a continuació Anàlisi de codi estàtic aquí .

No dubteu a suggerir eines més senzilles o avançades que utilitzeu per a la tècnica de la caixa blanca.

Conclusió

Basar-se només en les proves de caixa negra no és suficient per a una cobertura màxima de les proves. Hem de tenir una combinació de tècniques de proves de caixa negra i caixa blanca per cobrir els defectes màxims .

Si es fan correctament, les proves de White Box contribuiran sens dubte a la qualitat del programari. També és bo que els provadors participin en aquesta prova, ja que pot proporcionar l'opinió més 'imparcial' sobre el codi. :)

Feu-nos saber si teniu cap pregunta sobre els mètodes que hem comentat en aquest article.

Lectura recomanada

^