validation testing ultimate guide
Exploreu la importància de les proves de validació:
Què aprendreu:
- Què és la prova de validació?
- Diferència entre verificació i validació
- Etapes implicades
- Exemples de casos de prova de validació o protocol
- Conclusió
- Lectura recomanada
Què és la prova de validació?
Les proves de validació són el procés per assegurar si el programari provat i desenvolupat satisfà les necessitats del client / usuari. La lògica o els escenaris de requisits empresarials s’han de comprovar amb detall. Aquí s'han de provar totes les funcionalitats crítiques d'una aplicació.
Com a provador, sempre és important saber com verificar la lògica o els escenaris comercials que se us ofereixen. Un d'aquests mètodes que ajuda a l'avaluació detallada de les funcionalitats és el procés de validació.
Sempre que se us demana que realitzeu una prova de validació, assumeix una gran responsabilitat, ja que heu de provar tots els requisits empresarials crítics en funció de les necessitats de l'usuari. No hauria d’haver-hi ni un sol error sobre els requisits sol·licitats per l’usuari. Per tant, un coneixement profund sobre les proves de validació és molt important.
Com a provador, heu d'avaluar si els resultats de l'execució de la prova compleixen els que s'esmenten al document de requisits. Cal informar immediatament qualsevol desviació i, per tant, aquesta desviació s’anomena error.
Eines com HP Quality Center, Selenium, Appium, etc. s’utilitzen per realitzar proves de validació i hi podem emmagatzemar els resultats de la prova. Un important pla de proves, execucions d’execució de proves, informes de defectes, informes i mètriques són els lliuraments importants que cal enviar.
Des de la perspectiva de l’empresa, la prova de validació en simple es realitza mitjançant els passos següents:
- Reuniu els requisits empresarials per a les proves de validació de l'usuari final.
- Prepareu el pla de negoci i envieu-lo per a la seva aprovació al lloc o als grups d'interès implicats.
- En aprovar el pla, comenceu a escriure els casos de prova necessaris i els envieu a aprovació.
- Un cop aprovat, comenceu a completar les proves amb el programari, l’entorn i els enviaments lliurats segons el requeriment del client.
- Després de l’aprovació dels lliuraments, el client realitza les proves UAT.
- Després, el programari surt a la producció.
preguntes d’entrevistes dirigides per equips basades en escenaris
Explorem ara més detalls sobre la validació.
Diferència entre verificació i validació
Entenguem-los amb un exemple d’una manera senzilla.
Exemple:
Requisits del client:
La injecció proposada no ha de pesar més de 2 cms.
Prova de verificació:
- Comproveu si la injecció és la injecció que no pesa més de 2 cm mitjançant la llista de comprovació, la revisió i el disseny.
Prova de validació:
- Comproveu si la injecció no pesa més de 2 cms mitjançant proves manuals o d’automatització.
- Cal comprovar tots i cadascun dels escenaris possibles relatius al pes de la injecció mitjançant qualsevol mètode de prova adequat (mètodes funcionals i no funcionals).
- Comproveu si hi ha mesures inferiors a 2 cm i superiors a 2 cm.
| Verificació | Validació |
|---|---|
| El procés només comprova el disseny, el codi i el programa. | Ha d’avaluar tot el producte, inclòs el codi. |
| Revisions, recorreguts, inspeccions i revisió de taulells implicats. | Hi intervenen mètodes de prova funcionals i no funcionals. Es realitza una comprovació en profunditat del producte. |
| Comprova el programari amb les especificacions. | Comprova si el programari compleix les necessitats de l'usuari. |
Etapes implicades
- Qualificació del disseny: Això inclou la creació del pla de prova en funció dels requisits empresarials. Cal esmentar clarament totes les especificacions.
- Qualificació de la instal·lació: Això inclou la instal·lació de programari en funció dels requisits.
- Qualificació operativa: Això inclou la fase de proves basada en l'especificació de requisits de l'usuari.
Això pot incloure Proves de funcionalitat:
-
- Proves unitàries - Caixa negra, caixa blanca, caixa gris.
- Proves d'integració - De dalt a baix, De baix a dalt, Big Bang.
- Proves del sistema: Proves de seny, fum i regressió.
- Qualificació del rendiment: UAT (proves d'acceptació d'usuaris) - Proves alfa i beta.
- Producció
Qualificació de disseny
La qualificació del disseny significa simplement que heu de preparar el disseny del programari de manera que compleixi les especificacions de l'usuari. Primerament, necessiteu obtenir el Document d’especificació de requisits d’usuari (URS) del client per continuar amb el disseny.
Estratègia de prova:
Aquest document constitueix la base per preparar el pla de proves. Normalment el prepara el cap de l’equip o el gerent del projecte. Descriu com procedirem a provar i aconseguir l'objectiu desitjat.
Per incorporar tots els procediments, s’hauria de dissenyar un pla adequat i que les parts interessades l’aprovessin. Feu-nos saber els components del pla de prova.
En alguns projectes, el pla de prova i l'estratègia de prova es poden incorporar com a document únic. També es preparen documents d’estratègia separats per a un projecte complex (sobretot en tècnica d’automatització).
Components del pla de prova de validació:
- Descripció del projecte
- Comprensió dels requisits
- Abast de les proves
- Nivells i calendari de proves
- Executeu la creació del pla
- Requisits de maquinari, programari i personal
- Rols i responsabilitats
- Assumpció i dependències
- Riscos i mitigació
- Informe i mètriques
Descripció del projecte: Aquí heu d’explicar tota la descripció de l’aplicació que se us ha concedit per fer proves. Ha d'incloure totes les funcionalitats de l'aplicació.
Comprensió dels requisits: En obtenir l’URS, heu d’esmentar els vostres requisits entesos. Si hi ha, també podeu plantejar aclariments. Aquest és el criteri base o de prova per a les proves.
Abast de les proves: L'abast ha d'incloure els mòduls en detall juntament amb les funcions d'alt nivell. Heu d’indicar al client quins són els requisits que cobriríeu a les proves.
Des d'una perspectiva empresarial, es pot demanar que es realitzin proves de validació per als requisits crítics d'una aplicació. Simplement vol dir que dieu què es tractarà i què no .
Nivells de prova i calendari de proves: Cal esmentar quantes rondes de proves s’han de dur a terme. L’esforç global per al projecte de proves s’estima mitjançant tècniques d’estimació estàndard com l’estimació de Test Case Point (TCP), etc.
Com el seu nom indica calendari de proves descriu com es duran a terme les proves. També s'ha de dir com i quan es duran a terme l'aprovació i les revisions.
Exemple:
El disseny d’una pàgina web és el projecte considerat.
Els nivells de proves inclouen:
Nivell 1: Proves de fum
Nivell 2: Proves unitàries
Nivell 3: Proves d'integració
Nivell 3: Proves del sistema
Nivell 3: Proves d'acceptació
Horari de proves:
- Enviament del pla - Dia 1
- Disseny de casos de prova - Dia 2
- Funcionament en sec i correcció d'errors - Dia 4
- Revisió- Dia 5
- Cursa formal - Dia 6
- Entregables enviats a aprovació - Dia 8
- Informes - Dia 10
Executeu la creació del pla: El pla d'execució marca el nombre d'execucions necessàries per a la prova. Totes les curses que realitzeu a fora del lloc seran assenyalades per l’equip del lloc.
Per exemple, quan utilitzeu el fitxer Eina HP Professional Quick Test Professional per a l'execució, el nombre d'execucions es mostrarà a la pestanya Execucions del pla de prova.
com copiar DVD gratis
Requisits de maquinari, programari i personal:
- Requisits de maquinari i programari, com ara dispositius, versions del navegador, IOS, eines de prova necessàries per al projecte.
- La dotació de personal significa nomenar les persones necessàries per a les proves. Podeu mencionar el recompte d’equips aquí.
- En cas que necessiteu membres de proves addicionals, podeu sol·licitar-los al lloc en funció de l'abast de la prova. Simplement, quan augmenta el nombre de casos de prova, implica que necessiteu més membres de l'equip per executar-los.
Rols i responsabilitats: Això implica assignar tasques als rols relacionats responsables de realitzar els diferents nivells de proves.
Per exemple,
Un equip format per 4 membres ha de provar una aplicació per executar 4 protocols de validació i podeu delegar les responsabilitats de la següent manera:
- Cap de prova: Disseny del pla de proves
- Membre de l'equip 1: Disseny i execució de protocols 1,2.
- Membre de l'equip 2: Disseny i execució de protocols 3.4.
- Membre de l'equip: Preparació d'informes, revisió i mètriques.
Assumpció i dependències: Això significa que s'inclouran aquí les suposicions fetes durant el disseny i les dependències identificades per a la prova.
Riscos i mitigació: Riscos relacionats amb la planificació de proves, com ara la disponibilitat dels entorns desitjats, la construcció, etc. juntament amb els plans de mitigació i contingència.
Informe i mètriques: Aquí s’han d’esmentar els factors que es van utilitzar per fer proves i informes als grups d'interès.
A continuació es proporciona un exemple d'aplicació per a mòbils:
Qualificació de la instal·lació
- La qualificació d’instal·lació conté detalls com quin i quants entorns de prova s’utilitzaran, quin nivell d’accés és necessari per als verificadors de cada entorn juntament amb les dades de prova necessàries. Pot incloure compatibilitat del navegador, eines necessàries per a l'execució, dispositius necessaris per fer proves, etc. El sistema que s'està desenvolupant s'ha d'instal·lar d'acord amb els requisits de l'usuari.
- És possible que siguin necessàries dades de prova per provar algunes aplicacions i que les ha de proporcionar la persona adequada. És un requisit previ vital.
- Algunes aplicacions poden requerir una base de dades. Hem de mantenir preparades totes les dades necessàries per a les proves en una base de dades per validar les especificacions.
Per exemple, Una nova aplicació diu que 'abc' s'ha de provar al mòbil (Android 4.3.1) i al navegador (Chrome 54); en aquest cas, hem de fer un seguiment del següent:
- Comproveu si es dóna l'autorització adequada per comprovar el lloc de l'aplicació 'abc'.
- Consulteu si hi ha disponibles els dispositius que s’utilitzen per provar l’aplicació, com ara mòbils (android / ios), navegador Chrome, Internet Explorer i la versió necessària.
- Comproveu si s’instal·len correctament amb les versions especificades (per exemple: Chrome 54, versió d’Android 4.3.1).
- Assegureu-vos que l’aplicació sigui accessible tant al navegador com al mòbil.
Qualificació operativa
La qualificació operativa garanteix que tots els mòduls i submòduls dissenyats per a l'aplicació sotmesa a prova funcionin correctament tal com s'espera a l'entorn desitjat.
En general, es realitza una prova de validació a la següent jerarquia.
Les proves funcionals tenen un paper important en les proves de validació. Simplement vol dir que heu de validar la funcionalitat de l'aplicació segons tots els requisits crítics esmentats. Això obre la manera de mapar els requisits esmentats al document d’especificacions funcionals i garanteix que el producte compleixi tots els requisits esmentats.
Proves funcionals i els seus tipus
Com el seu nom indica, la prova funcional és provar les funcions, és a dir, el que ha de fer el programari. Les funcionalitats del programari es definiran al document d’especificacions de requisits.
Fem una ullada ràpida als seus tipus.
# 1) Prova unitària:
La prova d’unitat consisteix a provar les unitats / mòduls / components / mètodes individuals del sistema donat. La validació del camp, el control de disseny, el disseny, etc., es proven amb diferents entrades després de la codificació. Cal validar cada línia del codi per a cada cas de prova unitària.
La prova d’unitat la fan els mateixos desenvolupadors. El cost de corregir els errors és menor aquí si es compara amb els altres nivells de proves.
Exemple:
L’avaluació d’un bucle del codi per a una funció diu que l’elecció de gènere és un exemple de proves unitàries.
# 2) Prova de caixa negra:
Provar el comportament d’una aplicació per obtenir les funcionalitats desitjades en funció dels requisits sense enfocar els detalls interns del sistema s’anomena prova de caixa negra. Normalment el realitza un equip de proves independent o els usuaris finals de l'aplicació.
L'aplicació es prova amb les entrades rellevants i es prova per validar si el sistema es comporta com es desitja. Es pot utilitzar per provar tant els requisits funcionals com els no funcionals.
# 3) Prova de caixa blanca:
Proves de caixa blanca no és res més que una comprovació detallada del codi per codi del programa. Tot el funcionament de l'aplicació depèn del codi escrit, per tant, és necessari provar el codi amb molta cura. Heu de comprovar cada unitat i la seva integració com a mòdul sencer, pas a pas.
Un tester amb coneixements de programació és un criteri imprescindible aquí. Això esbrina clarament si hi ha alguna desviació en el flux de treball de l'aplicació. És útil tant per als desenvolupadors com per als provadors.
# 4) Proves de caixes grises:
Les proves de caixes grises són una combinació de proves de caixa blanca i caixa negra. Aquí es coneixen coneixements parcials sobre l’estructura o el codi de la unitat a provar.
Prova d’integració i els seus tipus
Els components individuals del programari que ja s’han provat en proves unitàries s’integren i comproven junts per provar les seves funcionalitats en conjunt, per tal de garantir el flux de dades a través dels mòduls.
Ho fan els propis desenvolupadors o un equip de proves independent. Això es pot fer després de provar dues o més unitats.
Enfocament descendent:
En aquest enfocament, es proven primer les unitats superiors i, després, es posen a prova les unitats de nivell inferior una per una. Els talons de prova que es poden utilitzar són necessaris per simular les unitats de nivell inferior que poden no estar disponibles durant les fases inicials.
Enfocament ascendent:
En aquest enfocament, primer es posen a prova les unitats inferiors, s’integren i després es posen a prova les unitats de nivell superior. Els talons de prova que es poden utilitzar són necessaris per simular les unitats de nivell superior que poden no estar disponibles durant les fases inicials.
Proves de sistemes i els seus tipus
La prova del sistema / programari complet s’anomena prova del sistema. El sistema es prova completament en funció de les especificacions de requisits funcionals. Les proves del sistema es fan en funció dels requisits funcionals i no funcionals. En general, es prefereix fer proves de caixa negra per a aquest tipus de proves.
# 1) Prova de fum:
Quan els constructors donen la versió per provar inicialment, hem de provar la construcció a fons. Això s’anomena proves de fum. Hem d’indicar si la compilació és capaç de fer proves posteriors o no.
Per realitzar la validació, necessiteu una compilació adequada. Per tant, primerament l’equip de proves fa les proves de fum. El flux de treball de l'aplicació provada s'ha de provar amb els casos de prova o sense. El cas de prova que cobreix tot el flux és útil per a aquesta prova.
# 2) Proves de seny:
En les proves de seny, es proven les principals funcionalitats dels mòduls de l'aplicació que es prova. En provar un lloc web que té 3 pestanyes, és a dir, creació de perfils, formació, accés, etc., a IRCTC , s'han de comprovar les principals funcionalitats de totes aquestes pestanyes sense aprofundir.
Els menús, submenús, pestanyes han de ser provats en tots els mòduls. És un subconjunt de proves de regressió, ja que les proves es fan només del flux principal i no en profunditat.
# 3) Proves de regressió:
Per a cada versió del projecte, l'equip de desenvolupament pot introduir certs canvis. La validació si els nous canvis introduïts no han afectat el flux de treball del sistema s’anomena prova de regressió. Aquí només cal provar alguns casos de prova relacionats amb els nous requisits.
Qualificació del rendiment
UAT (proves d’acceptació d’usuaris):
Aquesta és l'última fase de proves que es fa per assegurar-se que el sistema es comporta com es requereix corresponent als requisits especificats. Ho fa el client. Un cop el client certifiqui i esborri les proves del sistema, el producte es pot implementar.
com configurar junit a eclipsi
Proves alfa i beta:
Els desenvolupadors de l'aplicació realitzen les proves alfa abans de llançar-les al lloc de desenvolupament de programari. Implica proves de caixes en blanc i negre. Les proves beta es fan al costat del client després de desenvolupar i desplegar el producte.
Exemples de casos de prova de validació o protocol
Amb la meva experiència, he escrit aquest protocol per iniciar la sessió a Gmail.
La comprovació en profunditat de la funcionalitat d’inici de sessió coberta és el que realment és la validació. Però voldria mencionar que l'estil de les columnes de frases utilitzades pot variar completament i dependre dels requisits del client.
=> Baixeu casos de prova de validació de mostra: Cas de prova d’inici de sessió de Gmail
Conclusió
Bé, la validació es tracta d’analitzar detalladament les funcionalitats d’un producte. Com a provador de validació, sempre heu de recordar que heu d'informar de les desviacions d'aquí i d'allà per obtenir resultats òptims en les proves.
Tots els casos de prova que s’escriuen han de ser nítids, concisos i entenedors fins i tot per a l’home comú. El verificador de validació ha de garantir que el producte adequat s'està desenvolupant en funció dels requisits especificats.
Com a guia per a les proves de validació, he tractat el procés associat a la validació.
Qualificació de disseny que implica el pla de validació, Qualificació d’instal·lació que parla de la instal·lació de maquinari-programari, Qualificació operativa que implica la prova completa del sistema, Qualificació de rendiment que implica la prova d’acceptació de l’usuari que proporciona l’autorització per a la producció.
Espero que aquest article us hagi enriquit el coneixement sobre el concepte de proves de validació.
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Proves alfa i proves beta (guia completa)
- Diferències clau entre la prova de caixa negra i la prova de caixa blanca
- Proves funcionals contra proves no funcionals
- Prova de descàrrega de llibres electrònics
- Guia completa de proves de verificació de compilació (proves BVT)
- Què és la prova del sistema: una guia per a principiants
- Guia de proves de seguretat d'aplicacions web