Menú

Què és la prova de components o la prova de mòduls (apreneu amb exemples)

what is component testing

Proveu El Nostre Instrument Per Eliminar Problemes

El que és la prova de components també anomenada prova de mòduls en proves de programari:

Un component és la unitat més baixa de qualsevol aplicació. Per tant, proves de components; com el seu nom indica, és una tècnica per provar la unitat més baixa o més petita de qualsevol aplicació.

De vegades, les proves de components també s’anomenen proves de programes o mòduls.

Una aplicació es pot pensar en una combinació i integració de molts petits mòduls individuals. Abans de provar tot el sistema, és imperatiu que cada component O la unitat més petita de l'aplicació es provi a fons.

preguntes d’entrevistes de proves d’automatització per a experimentats

En aquest cas, els mòduls o les unitats es comproven independentment. Cada mòdul rep una entrada, fa algun processament i genera la sortida. La sortida es valida després de la característica esperada.

Què és la prova de components

Les aplicacions de programari tenen una naturalesa enorme i és un repte provar tot el sistema. Pot provocar molts buits en la cobertura de les proves. Per tant, abans de passar a proves d’integració o proves funcionals, es recomana començar amb la prova de components.

Llegiu també=> Unitat, integració i diferències de proves funcionals

Què aprendreu:

Proves de components

És una mena de proves de caixes blanques.

Per tant, la prova de components busca errors i verifica el funcionament dels mòduls / programes que es poden provar per separat.

Hi ha una estratègia de prova i un pla de prova per a la prova de components. I, per a cada component, hi ha un escenari de prova que es desglossarà encara més en casos de prova. El diagrama següent representa el mateix:

Proves de components

L'objectiu de la prova de components

L'objectiu principal de les proves de components és verificar el comportament d'entrada / sortida de l'objecte de prova. Assegura que la funcionalitat de l'objecte de prova funciona correctament i completament d'acord amb l'especificació desitjada.

Entrades a les proves de nivell de components

Les quatre aportacions principals per a les proves de nivell de components són:

  • Pla de proves del projecte
  • Requisits del sistema
  • Especificacions dels components
  • Implementacions de components

Qui fa la prova de components?

La prova de components la fan els serveis de control de qualitat o el provador.

Què es prova a Proves de components?

Les proves de components poden tenir en compte la verificació de característiques funcionals o específiques no funcionals dels components del sistema.

Pot ser provar el comportament dels recursos (per exemple, determinar fuites de memòria), provar el rendiment, provar estructuralment, etc.

Quan es fa la prova de components?

La prova de components es realitza després de la prova unitària.

Els components es posen a prova tan bon punt es creen, de manera que hi ha possibilitats que els resultats obtinguts d’un component sotmès a prova depenguin d’altres components que al seu torn no es desenvolupin a partir d’ara.

Depenent del model de cicle de vida del desenvolupament, les proves de components es poden realitzar de manera aïllada amb altres components del sistema. L'aïllament es fa per evitar influències externes.

Per tant, per provar aquest component, fem servir Stubs and Driversper simular la interfície entre components de programari.

Les proves d’integració es realitzen després de les proves de components.

Estratègia de prova de proves de components

Depenent de la profunditat del nivell de prova, la prova de components es divideix en dues parts:

  1. Proves de components en petites (ctis)
  2. Proves de components en grans dimensions (CTIL)

Quan la prova de components es fa de manera aïllada amb altres components, s’anomena prova de components en petits. Això es fa sense considerar la integració amb altres components.

Quan la prova de components es realitza sense aïllar-se amb altres components del programari, s'anomena prova de components en gran. Això passa quan hi ha una dependència del flux de funcionalitat dels components i, per tant, no els podem aïllar.

Si els components dels quals tenim dependència encara no estan desenvolupats, fem servir objectes ficticis en lloc dels components reals. Aquests objectes ficticis són el registre (funció anomenada) i el controlador (funció de trucada).

Butlletes i conductors

Abans de saltar a un resum sobre Stubs i Drivers, hauria de fer un resum sobre el diferència entre proves de components i proves d’integració. El motiu és que també s’utilitzen trossos i controladors a les proves d’integració, de manera que això pot provocar una certa confusió entre aquestes dues tècniques de prova.

La tècnica de proves d’integració és una tècnica que combina dos components seqüencialment i provem el sistema integrat junts. Les dades d'un sistema es traslladen a un altre sistema i es validen la correcció de les dades per al sistema integrat.

A diferència de les proves de mòduls, on el component o mòdul únic es prova a fons abans d’integrar-lo a altres components. Per tant, podem dir que la prova de components es realitza abans de la prova d’integració.

Tant la integració com els usos de components Butlletes i conductors .

'Controladors' són els programes ficticis que s'utilitzen per trucar a les funcions del mòdul inferior en cas que no existeixi la funció de trucada.

'Stubs' es pot anomenar codi un fragment que accepta les entrades / sol·licituds del mòdul superior i retorna els resultats / resposta

Com s'ha explicat anteriorment, els components es proven de forma individual i independent. Per tant, pot haver-hi algunes característiques dels components, dependents de l’altre component que no es desenvolupi actualment. Per tant, per provar els components amb aquestes funcions “no desenvolupades”, hem d’utilitzar alguns agents estimulants que processarien les dades i les retornarien als components de la trucada.

D’aquesta manera ens assegurem que els components individuals es comproven a fons.

els components individuals es comproven a fons

Aquí veiem que:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— són els components
  • C1, C2 i C3 junts formen la subunitat 1
  • C4 i C5 junts formen la subunitat 2
  • C6, C7 i C8 junts formen la subunitat 3
  • C9 només fa la subunitat 4
  • La subunitat 1 i la subunitat 2 es combinen per formar la unitat de negoci 1
  • La subunitat 3 i la subunitat 4 es combinen per formar la unitat de negoci 2
  • La unitat de negoci 1 i la unitat de negoci 2 es combinen per fer la sol·licitud.
  • Per tant, la prova de components, en aquest cas, consistiria a provar els components individuals que són de C1 a C9.
  • El xarxa La fletxa entre la subunitat 1 i la subunitat 2 mostra el punt de prova d'integració.
  • De la mateixa manera, el xarxa La fletxa entre la subunitat 3 i la subunitat 4 mostra el punt de prova d'integració
  • La fletxa verda entre la unitat de negoci 1 i la unitat de negoci 2 mostra el punt de prova d’integració

Per tant, faríem:

  • COMPONENT proves de C1 a C9
  • INTEGRACIÓ proves entre les subunitats i les unitats de negoci
  • SISTEMA proves de l'aplicació en conjunt

Un exemple

Fins ara, hem d’haver establert que les proves de components són una mena de tècnica de proves de caixes blanques . Bé, pot ser correcte. Però això no vol dir que aquesta tècnica no es pugui utilitzar en la tècnica de proves de la caixa negra.

com reproduir fitxers .torrent

Penseu en una gran aplicació web que comença amb una pàgina d'inici de sessió. Com a provador (això també en un món àgil) no podíem esperar fins que es desenvolupés tota l'aplicació i estigués preparada per provar-la. Per augmentar el temps de sortida al mercat, hem de començar a fer proves aviat. Per tant, quan veiem que la pàgina d’inici de sessió està desenvolupada, hem d’insistir que estigui disponible per provar-la.

Tan aviat com tingueu disponible la pàgina d'inici de sessió per provar-la, podeu executar tots els casos de prova (positius i negatius) per assegurar-vos que la funcionalitat de la pàgina d'inici de sessió funciona com s'esperava.

Els avantatges de provar la vostra pàgina d'inici de sessió en aquest moment serien:

quin és el millor programa d'eliminació de programari maliciós
  • La interfície d’usuari es prova per a la seva usabilitat (errors ortogràfics, logotips, alineació, format, etc.)
  • Intenta utilitzar-lo tècniques de proves negatives com d'autenticació i autorització. Hi ha una gran probabilitat de trobar defectes en aquests casos.
  • Ús de tècniques com Injeccions SQL asseguraria provar l’incompliment de la seguretat en una etapa molt primerenca.

Els defectes que registraria en aquesta etapa actuarien com a 'lliçons apreses' per a l'equip de desenvolupament i s'implementarien a la codificació de la pàgina consecutiva. Per tant, fent proves primerenques, heu assegurat una millor qualitat de les pàgines que encara estan per desenvolupar.

Com que les altres pàgines consecutives encara no estan desenvolupades, és possible que necessiteu esbossos per validar la funcionalitat de la pàgina d'inici de sessió. Per exemple ,és possible que vulgueu una pàgina senzilla que digui 'registre correcte', en cas de credencials correctes i finestra emergent de missatges d'error en cas de credencials incorrectes.

Podeu consultar el nostre tutorial anterior a Proves d'integració per obtenir més informació sobre Stubs i Drivers.

Com escriure casos de prova de components?

Els casos de prova per a la prova de components es deriven de productes de treball, per exemple, el disseny de programari o el model de dades. Cada component es prova mitjançant una seqüència de casos de prova en què cada cas de prova cobreix una combinació específica d’entrada / sortida, és a dir, de funcionalitat parcial.

A continuació es mostra un fragment d’un cas de prova de components per al mòdul d’inici de sessió.

Podem escriure altres casos de prova de manera similar.

casos de prova

Proves de components contra proves unitàries

La primera diferència entre la prova de components i la prova unitària és que la primera la realitzen els verificadors, mentre que la segona la realitzen desenvolupadors o professionals de SDET.

Les proves d’unitat es realitzen a nivell granular. D'altra banda, la prova de components es fa a nivell d'aplicació. En les proves unitàries, es verifica si s’executa un programa individual o un fragment de codi segons l’especificat. En les proves de components, cada objecte del programari es prova per separat amb o sense aïllament amb altres components / objecte del sistema.

Per tant, la prova de components s’assembla molt a la prova unitària, però es fa a un nivell d’integració més alt i en el context de l’aplicació (no només en el context d’aquesta unitat / programa com en la prova unitària).

Component Vs Interfície Vs Integració Vs Proves de sistemes

Component , com he explicat, és la unitat més baixa d'una aplicació que es prova independentment.

An interfície és la capa d’unió dels 2 components. La prova de la plataforma o de la interfície amb la qual interactuen els dos components s’anomena prova d’interfície.

Ara, provar la interfície és una mica diferent. Aquestes interfícies són majoritàriament API o serveis web , de manera que la prova d'aquestes interfícies no seria similar a la tècnica de Black Box, sinó que faria algun tipus de prova d'API o de servei web mitjançant SOAP UI o qualsevol altra eina.

Un cop feta la prova de la interfície, arriba el fitxer Proves d'integració .

Durant la prova d’integració, combinem els components provats individualment un per un i els provem incrementalment. Durant la integració, validem que els components individuals, quan es combinen un per un, es comporten com s’esperava i que les dades no s’alteren en passar d’un mòdul a un altre.

Un cop integrats i provats tots els components, realitzem el Proves de sistemes per provar tota l'aplicació / sistema en conjunt. Aquesta prova valida els requisits empresarials enfront del programari implementat.

Conclusió

Jo ho diria Proves d’unitat i les proves de components es fan un al costat de l’altre.

A diferència de les proves d’unitats que realitza l’equip de desenvolupament, les proves de components / mòduls les realitza l’equip de proves. Sempre es recomana fer una prova mitjançant components abans de començar la prova d’integració.

Si les proves de components són sòlides, trobarem menys defectes a les proves d’integració. Hi hauria problemes, però aquests problemes estarien relacionats amb l'entorn d'integració o els reptes de configuració. Podeu assegurar-vos que la funcionalitat dels components integrats funciona bé.

Espero que aquest tutorial sigui útil per entendre el component, la integració i les proves del sistema. Si encara teniu cap consulta, no dubteu a fer-nos comentaris.

Lectura recomanada

^