black box testing an depth tutorial with examples
En aquest tutorial, utilitzant la meva experiència industrial en proves de programari, familiaritzem-nos amb els tipus i tècniques de Black-box Testing, juntament amb el seu procés, avantatges, desavantatges i algunes eines d’automatització per provar-lo que no sigui la prova manual.
També coneixerem les diferències entre la prova de caixa blanca i la prova de caixa negra.
Llista de tutorials sobre 'Tècniques de prova de la caixa negra':
Tutorial # 1: Què és la prova de Black Box?
Tutorial # 2: Què és la prova de caixes blanques
Tutorial # 3: Prova funcional simplificada
Tutorial # 4: Què és la prova de casos d’ús
Tutorial # 5 : Tècnica de proves de matriu ortogonal
Tècniques
Tutorial # 6: Anàlisi del valor límit i particionament d'equivalència
Tutorial # 7: Prova de la taula de decisions
Tutorial # 8: Proves de transició estatal
Tutorial # 9 : Error en endevinar
Tutorial # 10: Mètodes de prova basats en gràfics
Gairebé tots realitzem proves Black Box cada dia.
Tant si hem après com si no, tots hem fet i realitzat proves de caixes negres moltes vegades en el nostre dia a dia !!
Des del mateix nom, probablement podreu entendre que implica interactuar amb el sistema, que esteu provant com un quadre misteriós. Vol dir que no teniu prou coneixement del funcionament intern del sistema, però sabeu com s’ha de comportar.
Si prenem un exemple per provar el nostre cotxe o bicicleta, sempre el conduïm per assegurar-nos que no es comporta d’una manera inusual. Veieu? Ja hem fet proves de Black Box.
Què aprendreu:
- Què són les proves de Black Box?
- Tipus de proves de caixes negres
- Eines de prova de Black Box
- Tècniques de proves de Black Box
- Com fer-ho pas a pas?
- Avantatges i inconvenients
- Diferència entre la prova de caixa blanca i la prova de caixa negra
- Conclusió
- Lectura recomanada
Què són les proves de Black Box?
Les proves de caixes negres també es coneixen com a proves de comportament, caixa opaca, caixa tancada, basades en especificacions o proves a ull.
És un mètode de prova de programari que analitza la funcionalitat d’un programari / aplicació sense saber molt sobre l’estructura interna / disseny de l’element que s’està provant i compara el valor d’entrada amb el valor de sortida.
convertidor de youtube a mp3 descàrrega gratuïta d'alta qualitat
L’objectiu principal de les proves de Black Box és la funcionalitat del sistema en general. El terme 'Proves de comportament' també s’utilitza per a les proves de Black Box. El disseny de proves de comportament és lleugerament diferent del disseny de proves de caixa negra perquè no es prohibeix estrictament l’ús de coneixement intern, però es recomana.
Cada mètode de prova té els seus propis avantatges i desavantatges. Hi ha alguns errors que no es poden trobar utilitzant l'única tècnica de caixa negra o només de caixa blanca.
La majoria de les aplicacions es posen a prova mitjançant el mètode Black Box. Hem de cobrir la majoria dels casos de prova de manera que a Black-Box mètode.
Aquestes proves es realitzen al llarg del desenvolupament de programari i el cicle de vida de proves, és a dir, en les etapes de proves de la unitat, la integració, el sistema, l'acceptació i la regressió.
Això pot ser funcional o no funcional.
Tipus de proves de caixes negres
Pràcticament, hi ha diversos tipus de proves de caixa negra que són possibles, però si tenim en compte la seva variant principal, a continuació, esmenten els dos fonamentals.
# 1) Prova funcional
Aquest tipus tracta dels requisits o especificacions funcionals d'una aplicació. Aquí es proven diferents accions o funcions del sistema proporcionant l'entrada i comparant la sortida real amb la sortida esperada.
Per exemple ,quan provem una llista desplegable, hi fem clic i verificem que s’expandeixi i que es mostrin tots els valors esperats a la llista.
Alguns dels principals tipus de proves funcionals són:
- Proves de fum
- Proves de seny
- Proves d’integració
- Proves del sistema
- Proves de regressió
- Proves d’acceptació d’usuaris
=> Llegiu-ne més Proves funcionals .
# 2) Proves no funcionals
A part de les funcionalitats dels requisits, també hi ha diversos aspectes no funcionals que cal provar per millorar la qualitat i el rendiment de l'aplicació.
Alguns dels principals tipus de proves no funcionals inclouen:
- Proves d’usabilitat
- Prova de càrrega
- Proves de rendiment
- Proves de compatibilitat
- Proves d’estrès
- Proves d’escalabilitat
=> Llegiu-ne més Proves no funcionals .
Eines de prova de Black Box
Les eines de proves de Black Box són principalment eines de gravació i reproducció. Aquestes eines s'utilitzen per a proves de regressió per comprovar si la nova versió ha creat cap error en la funcionalitat d'aplicacions de treball anterior.
Aquestes eines de gravació i reproducció registren casos de prova en forma d’alguns scripts com TSL, script VB, Javascript, Perl, etc.
Tècniques de proves de Black Box
Per provar sistemàticament un conjunt de funcions, és necessari dissenyar casos de prova. Els verificadors poden crear casos de prova a partir del document d’especificació de requisits mitjançant les següents tècniques de proves de Black Box.
- Particionament d'equivalències
- Anàlisi del valor límit
- Prova de la taula de decisions
- Proves de transició estatal
- Error en endevinar
- Mètodes de prova basats en gràfics
- Proves de comparació
Anem a entendre cada tècnica en detall.
# 1) Particionament d'equivalència
Aquesta tècnica també es coneix com a particionament de classe d’equivalència (ECP). En aquesta tècnica, els valors d’entrada al sistema o aplicació es divideixen en diferents classes o grups en funció de la seva similitud en el resultat.
Per tant, en lloc d’utilitzar tots i cadascun dels valors d’entrada, ara podem utilitzar qualsevol valor del grup / classe per provar el resultat. D’aquesta manera, podem mantenir la cobertura de la prova mentre podem reduir moltes reelaboracions i, sobretot, el temps dedicat.
Per exemple:
Tal com es mostra a la imatge anterior, un camp de text 'EDAT' només accepta els números del 18 al 60. Hi haurà tres conjunts de classes o grups.
Dues classes no vàlides seran:
a) Menor o igual a 17.
b) Superior o igual a 61.
Una classe vàlida serà entre 18 i 60 anys.
Per tant, hem reduït els casos de prova a només 3 casos de prova basats en les classes formades, cobrint així totes les possibilitats. Per tant, provar amb qualsevol valor de cada conjunt de la classe és suficient per provar l’escenari anterior.
=> Lectura recomanada - Què és el particionament d'equivalència?
# 2) Anàlisi del valor límit
Pel propi nom, podem entendre que en aquesta tècnica ens centrem en els valors dels límits, ja que es constata que moltes aplicacions tenen una gran quantitat de problemes sobre els límits.
Límit: els valors propers al límit en què canvia el comportament del sistema. En l'anàlisi del valor límit, s'estan provant tant les entrades vàlides com les entrades no vàlides per verificar els problemes.
converteix youtube a mp4 mac gratis en línia
Per exemple:
Si volem provar un camp on s’acceptin valors d’1 a 100, escollim els valors límit: 1-1, 1, 1 + 1, 100-1, 100 i 100 + 1. En lloc d’utilitzar tots els valors de l’1 al 100, només fem servir 0, 1, 2, 99, 100 i 101.
# 3) Prova de la taula de decisions
Com el seu propi nom indica, allà on hi hagi relacions lògiques com:
Si
{
(Condició = cert)
després acció1;
}
else action2; / * (condició = Fals) * /
A continuació, un provador identificarà dues sortides (action1 i action2) per a dues condicions (True i False). Així, basant-se en els escenaris probables, es talla una taula de decisions per preparar un conjunt de casos de prova.
Per exemple:
Prenguem un exemple de banc XYZ que proporciona un tipus d'interès per a la gent gran masculina del 10% i de la resta de persones del 9%.
En aquest exemple de condició, C1 té dos valors com a vertader i fals, la condició C2 també té dos valors com a veritable i fals. El nombre de combinacions possibles totals seria llavors quatre. D’aquesta manera podem derivar casos de prova mitjançant una taula de decisions.
com injectar codi a un lloc web
# 4) Proves de transició estatal
La prova de transició d'estats és una tècnica que s'utilitza per provar els diferents estats del sistema que es prova. L'estat del sistema canvia en funció de les condicions o esdeveniments. Els esdeveniments activen estats que esdevenen escenaris i un provador ha de provar-los.
Un diagrama de transició d'estats sistemàtic proporciona una visió clara dels canvis d'estat, però és eficaç per a aplicacions més senzilles. Projectes més complexos poden conduir a diagrames de transició més complexos, de manera que resulten menys efectius.
Per exemple:
# 5) Error en endevinar
Aquest és un exemple clàssic de proves basades en l'experiència.
En aquesta tècnica, el provador pot utilitzar la seva experiència sobre el comportament i les funcionalitats de l’aplicació per endevinar les àrees propenses a errors. Es poden trobar molts defectes utilitzant la suposició d’errors on solen cometre errors la majoria dels desenvolupadors.
Pocs errors habituals que els desenvolupadors solen oblidar de manejar:
- Divideix per zero.
- Gestió de valors nuls en camps de text.
- Acceptació del botó Enviar sense cap valor.
- Càrrega de fitxers sense fitxers adjunts.
- Càrrega de fitxers amb una mida límit inferior o superior.
# 6) Mètodes de prova basats en gràfics
Totes les aplicacions són una acumulació d’alguns objectes. Tots aquests objectes s’identifiquen i es prepara el gràfic. A partir d’aquest gràfic d’objectes, s’identifica cada relació d’objectes i s’escriuen casos de prova en conseqüència per descobrir els errors.
# 7) Prova de comparació
S’utilitzen diferents versions independents del mateix programari per comparar-se entre si per provar amb aquest mètode.
Com fer-ho pas a pas?
En general, quan es segueix un procés sistemàtic per provar un projecte / aplicació, la qualitat es manté i és útil a la llarga per a altres rondes de proves.
- El pas més important és entendre l'especificació de requisits d'una aplicació. Hi hauria d’haver un SRS (Software Requirement Specification) documentat.
- Utilitzant les tècniques de prova de Black Box esmentades, com ara Anàlisi de valor límit, particionament d’equivalència, etc., conjunts d’entrades vàlides i no vàlides s’identifiquen amb les seves sortides desitjades i els casos de prova es dissenyen en funció d’això.
- Els casos de prova dissenyats s’executen per comprovar si passen o no, verificant els resultats reals amb els resultats esperats.
- Els casos de prova fallits es plantegen com a defectes / errors i s’adrecen a l’equip de desenvolupament per solucionar-los.
- A més, en funció de la solució dels defectes, el comprovador torna a provar els defectes per verificar si és recurrent o no.
Avantatges i inconvenients
Avantatges
- El comprovador no necessita tenir antecedents tècnics. És important provar estant en la pell de l’usuari i pensar des del punt de vista de l’usuari.
- Les proves es poden iniciar un cop finalitzat el desenvolupament del projecte / aplicació. Tant els provadors com els desenvolupadors treballen independentment sense interferir en l’espai de l’altre.
- És més eficaç per a aplicacions grans i complexes.
- Es poden identificar defectes i inconsistències en la fase inicial de les proves.
Desavantatges
- Sense cap coneixement tècnic ni de programació, hi ha possibilitats d’ignorar les possibles condicions de l’escenari a provar.
- En un temps estipulat, hi ha possibilitats de provar menys i saltar totes les entrades possibles i les proves de sortida.
- No es pot fer una cobertura completa de les proves per a projectes grans i complexos.
Diferència entre la prova de caixa blanca i la prova de caixa negra
A continuació es detallen algunes diferències entre tots dos:
| Proves de caixa negra | Proves de caixa blanca |
|---|---|
| És un mètode de prova sense tenir coneixement del codi real o de l'estructura interna de l'aplicació | És un mètode de prova que té coneixements sobre el codi real i l'estructura interna de l'aplicació |
| Es tracta d’una prova de nivell superior, com ara proves funcionals. | Aquest tipus de proves es realitzen a un nivell inferior de proves, com ara proves unitàries, proves d’integració |
| Es concentra en la funcionalitat del sistema que es prova | Es concentra en el codi real: programa i la seva sintaxi |
| La prova de caixa negra requereix una especificació de requisit per provar-la | Les proves de White Box requereixen documents de disseny amb diagrames de flux de dades, diagrames de flux, etc. |
| Els provadors fan la prova de la caixa negra | Les proves de caixes blanques les fan desenvolupadors o verificadors amb coneixements de programació. |
Conclusió
Aquests són alguns dels punts bàsics sobre les proves de caixa negra i la visió general de les seves tècniques i mètodes.
Com que no és possible provar-ho tot amb implicació humana amb una precisió del 100%, si les tècniques i mètodes esmentats anteriorment s’utilitzen amb eficàcia, definitivament millorarà la qualitat del sistema.
Per concloure, aquest és un mètode molt útil per verificar la funcionalitat del sistema i identificar la majoria dels defectes.
Espero que hagueu adquirit un coneixement profund de la tècnica de proves de caixes negres.
Lectura recomanada
- Diferències clau entre la prova de caixa negra i la prova de caixa blanca
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Proves funcionals contra proves no funcionals
- Prova de parelles o Tutorial de proves de tots els parells amb eines i exemples
- Proves de caixes blanques: una guia completa amb tècniques, exemples i eines
- Tutorial de proves de volum: exemples i eines de prova de volum
- Tutorial de proves de configuració amb exemples
- Prova de descàrrega de llibres electrònics