software development
Què són les metodologies de desenvolupament i prova de programari?
Les proves són una part essencial del procés de desenvolupament de programari. Es pot lliurar un producte de programari robust i estable amb l’ús de metodologies de prova estàndard que ajudaran a predir la cronologia del sistema de programari.
Una aplicació de programari pot ser encara més complexa amb un gran nombre de plataformes i dispositius. El que és més important, s’ha de garantir si compleixen els requisits especificats i es poden instal·lar i operar de manera eficient a la màquina de l’usuari o no.
Amb els mitjans de seguretat , compatibilitat i usabilitat, un producte de programari s'ha de provar utilitzant la metodologia de prova adequada.
En aquest article , discutirem què s’entén per metodologies de prova, en què es diferencia de les estratègies de prova i els tipus de mètodes de prova de programari en detall.
Què aprendreu:
- Significat de metodologies de prova
- Tècniques de proves
- Models en SDLC
- Diferència entre metodologies de prova i estratègies de prova
- Conclusió:
- Lectura recomanada
Significat de metodologies de prova
Les metodologies es poden considerar com el conjunt de mecanismes de prova utilitzats en el cicle de vida del desenvolupament de programari, des de la prova unitària fins a la prova del sistema. La selecció d’una metodologia de prova adequada es considera el nucli del procés de prova.
Tècniques de proves
Bàsicament, hi ha 3 metodologies de prova que s’utilitzen per provar-les. Són proves de caixes blanques, proves de caixes negres i Proves de caixes grises . Aquests també es diuen com Tècniques de proves . Cadascuna de les tècniques de prova es mostra a continuació per a una millor comprensió.
# 1) Prova de caixa blanca:
Tècnica de proves de caixa blanca s’utilitza per examinar l’estructura del programa i la lògica empresarial, valida el codi o programa d’una aplicació. També es diu com Proves de caixes clares, proves de caixes de vidre o proves de caixes obertes .
Les tècniques de proves de caixa blanca inclouen:
- Cobertura de la declaració: Examina totes les afirmacions de programació.
- Cobertura de sucursal: Sèrie de proves en curs per assegurar si totes les branques estan provades.
- Cobertura del camí: Prova tots els camins possibles per cobrir cada declaració i branca.
# 2) Prova de caixa negra:
Mètode de prova de Black Box s’utilitza per provar la funcionalitat d’una aplicació en funció de l’especificació de requisits. A diferència de White Box Testing, no se centra en l'estructura / codi intern de l'aplicació.
Les tècniques de Black Box inclouen:
- Anàlisi del valor límit
- Particionament d'equivalència (particionament de classe d'equivalència)
- Taules de decisions
- Proves de domini
- Models d'estat
- Proves exploratòries (requereix menys preparació i també ajuda a trobar els defectes ràpidament).
# 3) Proves de caixes grises:
Aquest mètode de prova es realitza amb menys informació sobre l'estructura interna d'una aplicació. Generalment, es realitza només com a proves de caixa negra, però per a algunes àrees d’aplicació crítiques s’utilitza la prova de caixa blanca.
Models en SDLC
La selecció de metodologies de prova adequades també s’incorpora amb l’elecció d’un model adequat en SDLC.
Els models inclouen:
- Model de cascada
- En el model
- Model àgil
- Model en espiral
- RAD
Vegem de prop les metodologies de desenvolupament de programari amb una breu explicació.
# 1) Model de cascada
Model de cascada és el model bàsic del cicle de vida que va ser desenvolupat per Winston Royce el 1970. Aquest model representa múltiples etapes o processos de manera seqüencial que flueix progressivament cap avall.
Aquest enfocament és útil quan es coneixen els requisits, es comprèn la tecnologia i es disposa dels recursos amb l'experiència necessària.
El model de cascada es defineix per les següents etapes:
- Recopilació i anàlisi de requisits: Captureu i analitzeu tots els requisits i assegureu-vos si es poden provar o no.
- Disseny del sistema: Crear i dissenyar documents basats en l'anàlisi de requisits. Definiu els requisits de maquinari i programari.
- Implementació: Creeu un codi robust per als components segons el disseny i integreu-los.
- Proves del sistema: Els components integrats formen tot un sistema, aquesta fase es realitza per assegurar si el sistema funciona segons els requisits, fent un seguiment i informant del progrés de les proves.
- Desplegament del sistema: Assegureu-vos que si el sistema és estable amb zero errors, tots els criteris de prova havien estat
complert, assegureu-vos de la configuració de l'entorn, etc. - Manteniment del sistema: Assegureu-vos que l'aplicació funciona de manera eficient segons el requisit amb l'entorn adequat. En cas que es trobi un defecte, s'hauria de corregir i desplegar (actualitzar) a l'entorn.
Avantatges del model de cascada:
- Senzill i fàcil d'entendre.
- Fàcil de gestionar, ja que cada fase té els seus propis lliuraments específics.
- S'evita la superposició d'etapes.
- Bo per a petits projectes.
Desavantatges del model de cascada:
- Augment de la quantitat de risc i incertesa.
- Un cop entrats a la fase de proves, no es pot canviar res en les etapes anteriors per exemple Disseny i codificació, etc.
- No és bo per a projectes complexos i grans.
- No és adequat quan els requisits continuen canviant.
# 2) A Model
Model V és un ampliació del model de cascada on l'execució del procés té lloc en un estil seqüencial en forma de V i també es coneix com a model de verificació i validació. En aquest enfocament, existeix una fase de proves associada directament a cada fase del cicle de desenvolupament.
S'ha demostrat beneficiós i rendible que el model de cascada, ja que les proves es realitzen en cada fase de desenvolupament en lloc de finalitzar el cicle de desenvolupament.
El model V es classifica en 3 fases.
- Fase de verificació
- Fase de codificació
- Fase de validació
a) Fase de verificació :
- Anàlisi de requisits empresarials: Comunicar-se amb el client per entendre les seves expectatives i requisits.
- Disseny del sistema: Dissenycompletsistema i els seus components juntament amb els requisits de maquinari i programari.
- Diseny arquitectònic: En aquesta fase es capturen les especificacions arquitectòniques. Això també es coneix com a disseny d’alt nivell.
- Disseny de mòduls: Això també es coneix com Disseny de nivell baix, Disseny intern detallat per a tots els mòduls del sistema especificats.
b) Fase de codificació:
Aquesta fase conté la fase de codificació real del cicle de vida del desenvolupament. Els llenguatges de programació s’han d’escollir en funció del disseny arquitectònic i del sistema especificat a la plataforma tecnològica de la fase anterior. La codificació es realitza d’acord amb els estàndards i pautes predefinides.
c) Fase de validació :
- Proves unitàries: Realitzat en un mòdul individual per eliminar els errors en la fase inicial.
- Proves d'integració: Realitzat per provar la comunicació entre diferents mòduls del sistema.
- Proves del sistema: Proves del sistema es realitza en un sistema en conjunt.
- Proves d'acceptació: Això s’associa als requisits empresarials. Es realitza en un entorn d’usuari des del punt de vista de l’usuari.
Avantatges del model V.
- Senzill, fàcil d'utilitzar i d'entendre.
- S'evita la superposició a mesura que s'executen fases d'una en una.
- Fàcil de gestionar i adequat per a petits projectes.
Els desavantatges del model V són més o menys similars als desavantatges del model de cascada.
# 3) Model àgil
Model Àgil mostra un enfocament iteratiu i incremental. Aquest enfocament divideix el producte en petites unitats incrementals per proporcionar iteracions. A continuació, cada iteració inclou passos com ara Planificació, Anàlisi de requisits, Disseny, Codificació, Prova unitària, Prova d’acceptació, etc.
Aquest enfocament també permet una interacció contínua amb el client per obtenir la seva retroalimentació i correcció dels requisits a intervals regulars.
El següent diagrama us ajudarà a entendre l'enfocament del model Agile amb més precisió:
La imatge següent mostrarà el cicle d'iteració al model àgil:
Avantatges del model Agile:
- Un enfocament realista del desenvolupament de programari.
- Promou el treball en equip.
- Elimina el desajust entre requisits i casos de prova.
- Ràpid i requereix una quantitat mínima de recursos.
- Apte per a projectes a llarg i llarg termini.
- Ideal per canviar els requisits.
- Fàcil de gestionar.
Inconvenients del model Agile:
- No apte per a projectes complexos.
- Requereix una gran interacció amb el client que pot provocar retards.
- El desencert dels requisits pot provocar un desenvolupament incorrecte del producte de programari.
- Augment del risc de manteniment.
- El lliurament a un altre equip pot ser molt difícil.
# 4) Model en espiral
El model en espiral incorpora un enfocament de desenvolupament iteratiu juntament amb l'enfocament sistemàtic del model de cascada. És similar al model incremental i l’èmfasi en l’anàlisi de riscos.
El model en espiral té quatre etapes:
- Fase de Planificació
- Anàlisi de riscos
- Fase d'Enginyeria
- Fase d’avaluació
1) Fase de planificació: En aquesta fase, es reuneixen els requisits i es revisen per finalitzar el cas de prova.
2) Anàlisi de riscos: Aquesta etapa inclou la identificació, seguiment i estimació de riscos de gestió. S’analitzen els requisits per identificar els riscos mitjançant tècniques com la pluja d’idees, la tutoria, etc.
3) Fase d'enginyeria: En aquesta fase, el programari es desenvolupa i prova al final.
4) Fase d'avaluació: Aquesta és l'última etapa en què un client avalua la producció d'un projecte i dóna els seus comentaris per a la propera espiral o aprovació.
Representació pictòrica del model espiral:
Quan s’ha d’utilitzar el model en espiral:
- Per a projectes d’alt risc.
- Quan els requisits són complexos.
- Si un projecte és gran.
- Teniu el temps suficient per obtenir els comentaris de l'usuari per a la següent espiral.
- Requereix canvis significatius a causa de la investigació i l’exploració.
- Els usuaris no estan segurs de les seves necessitats.
Avantatges del model en espiral:
- Evitació del risc, ja que implica una gran quantitat d'anàlisi de riscos.
- Desenvolupament ràpid.
- Els canvis en els requisits s’adapten fàcilment.
- Els requisits es poden adquirir amb més precisió.
Inconvenients del model en espiral:
- Gestió complexa.
- No apte per a petits projectes.
- Pot implicar no. d’espirals (indefinit).
- Costós.
- Requereix una gran quantitat d’anàlisi de riscos i experiència per a l’èxit del seu projecte.
# 5) Model RAD
El desenvolupament ràpid d’aplicacions (RAD) és un tipus de model incremental. En aquest enfocament, els components es desenvolupen en paral·lel.
Es tracta d’un enfocament ràpid i que pot proporcionar un producte ràpid al client per proporcionar-li comentaris.
Les fases de RAD són les següents:
- Modelització empresarial: Identifica la informació vital i el seu flux entre diversos canals de negoci.
- Modelització de dades: La informació recollida a l'etapa anterior s'utilitza per definir objectes de dades necessaris per a l'empresa.
- Modelització de processos: Els objectes de dades es converteixen per obtenir un objectiu comercial i un flux d'informació.
- Generació d'aplicacions: En aquesta fase, s’utilitzen eines d’automatització per convertir el model de procés en codi real.
- Proves i facturació: Comprova tots els components d'un sistema, de manera que es redueix el temps global de proves.
Avantatges del model RAD:
- El progrés es pot mesurar.
- Redueix el temps de desenvolupament.
- Augment de la reutilització.
- Ressenyes inicials ràpides.
- Millora els comentaris dels clients.
Desavantatges del model RAD:
- Requereix recursos altament qualificats.
- Estimació d’alt cost.
- No aplicable per a projectes més econòmics.
- Alta dependència de les habilitats de modelatge.
- Només es pot construir un sistema modularitzat mitjançant RAD.
Diferència entre metodologies de prova i estratègies de prova
La resposta a això no és massa complexa, ja que hi ha una diferència senzilla entre tots dos.
Metodologies de proves són els mètodes o enfocaments de les proves que inclouen des de la prova d’unitat fins a la prova del sistema.
Estratègies de proves és una visió general dels problemes clau que es produeixen en el procés de proves i que ha de tenir en compte el cap de projecte, un equip de desenvolupadors i verificadors.
S’utilitzen els mètodes de prova de programari esmentats anteriorment per implementar-los n nombre d'estratègies de prova.
Alguns d’ells es detallen a continuació:
1) Proves d'unitats:
- Se centra en unitats funcionals molt petites.
- La forma més senzilla de comprovar l'aïllament de les unitats més petites.
- Generalment els desenvolupen.
2) Proves d'integració:
Ripper de DVD gratuït per a Windows 7
- Aquest és el següent pas que cal dur a terme des del desenvolupador.
- Proporcionar mecanismes per provar la interacció, interoperació i comunicació entre els diferents mòduls de programari
3) Proves funcionals:
S'utilitza per comprovar les funcionalitats d'un sistema de programari, és a dir, la sortida a l'entrada donada.
4) Proves de regressió:
Comprova si la correcció d'errors s'ha produït en un lloc, de manera que les funcionalitats complexes no haurien de provocar cap canvi en una altra àrea principal.
5) Prova del sistema:
- Provant tots els mòduls integrats com a sistema col·lectiu.
- Combina diverses funcions en escenaris d'extrem a extrem.
6) Proves de rendiment:
Prova el rendiment de l'aplicació en situacions crítiques com ara la transferència de fitxers de grans dimensions, l'accés d'usuaris simultanis al sistema, la fallada de configuració, etc.
7) Proves d’acceptació :
- Generalment Nivell final de proves on els provadors examinen el producte de programari segons la perspectiva dels usuaris
- El resultat d’aquest pas és subjectiu i triga una mica a trobar el problema exacte
Conclusió:
L'elecció d'una metodologia de prova adequada és l'acció o el conjunt d'accions que es troba al nucli del procés de prova. Fins i tot pot ser una activitat versàtil que canvia segons els requisits empresarials i la cronologia del producte de programari.
Tanmateix, es pot triar metodologies de desenvolupament i proves de programari individuals o fins i tot múltiples per tenir un producte final més flexible i eficient que satisfaci les necessitats i expectatives del client en el límit de temps desitjat o inferior.
Feu-nos saber els vostres suggeriments o suggeriments a la secció de comentaris que hi ha a continuació.
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Prova de programari Treball d'assistent de control de qualitat
- Curs de proves de programari: a quin institut de proves de programari m'he d'afegir?
- Selecció de proves de programari com a carrera professional
- Prova de programari Treball freelance d'escriptor de contingut tècnic
- Algunes preguntes d’entrevistes de proves de programari interessants
- Opinions i ressenyes sobre cursos de proves de programari
- Ajuda de proves de programari Programa d'afiliació.