Menú

Guia completa de proves de verificació de compilació (proves BVT)

build verification testing complete guide

Proveu El Nostre Instrument Per Eliminar Problemes

Què són les proves de verificació de compilació (BVT)?

La prova de verificació de la compilació és un conjunt de proves que s’executen en cada nova versió per verificar que la versió es pugui provar abans de llançar-la a l’equip de proves per a proves posteriors.

Aquests casos de prova són casos bàsics de prova de funcionalitat que garanteixen que l’aplicació sigui estable i que es pugui provar a fons. Normalment, el procés BVT està automatitzat. Si falla BVT, la compilació torna a assignar-se a un desenvolupador per a la solució.

Proves de verificació de compilació (proves BVT)

També s’anomena BVT Proves de fum o construeix proves d'acceptació (BAT)

Nova versió es comprova principalment per dues coses:

  • Validació de compilació
  • Accepta l’objectiu

Alguns conceptes bàsics de BVT:

  • És un subconjunt de proves que verificen les principals funcionalitats.
  • Normalment, els BVT s’executen en versions diàries i, si el BVT falla, es rebutja la versió i s’allibera una nova versió després d’acabar les correccions.
  • L’avantatge de BVT és que estalvia els esforços d’un equip de proves per configurar i provar una compilació quan es trenca la funcionalitat principal.
  • Dissenyeu els BVT amb prou cura per cobrir la funcionalitat bàsica.
  • Normalment, la BVT no ha de durar més de 30 minuts.
  • BVT és un tipus de Proves de regressió , fet a cada nova construcció.

BVT comprova principalment la integritat del projecte i comprova si tots els mòduls estan integrats correctament o no. Les proves d’integració de mòduls són molt importants quan diferents equips desenvolupen mòduls de projecte. Vaig escoltar molts casos de fallada de l’aplicació a causa d’una integració incorrecta del mòdul. Fins i tot en els pitjors casos, el projecte complet s’elimina a causa d’un error en la integració del mòdul.

qa dirigeix ​​preguntes i respostes de l'entrevista

Quina és la tasca principal a Build Release? Viouslybviament, el fitxer 'check-in', és a dir, per incloure tots els fitxers de projecte nous i modificats associats a les versions respectives. BVT es va introduir principalment per comprovar l'estat inicial de la compilació, és a dir, per comprovar si tots els fitxers nous i modificats s'inclouen a la versió, tots els formats de fitxer són correctes, totes les versions i idiomes de cada fitxer, els senyals associats a cada fitxer.

Aquestes comprovacions bàsiques valen abans de la versió de compilació per provar-les a l'equip de proves. Estalvieu temps i diners en descobrir els defectes de construcció al principi amb BVT.

Quins casos de prova s'han d'incloure a BVT?

Aquesta és una decisió molt difícil de prendre abans d’automatitzar la tasca BVT. Tingueu en compte que l'èxit de BVT depèn de quins casos de prova incloeu a BVT.

Aquests són alguns consells senzills que cal incloure Casos de prova al vostre BVT Automation Suite:

  • Incloeu només casos de prova crítics a BVT.
  • Tots els casos de prova inclosos en BVT haurien de ser estables.
  • Tots els casos de prova haurien d'haver conegut el resultat esperat.
  • Assegureu-vos que tots els casos de prova de funcionalitat crítica inclosos siguin suficients per a la cobertura de la prova de l’aplicació.

A més, no inclou mòduls en BVT, que encara no són estables. Per a algunes funcions de subdesenvolupament, no podeu predir el comportament esperat, ja que aquests mòduls són inestables i és possible que conegueu alguns errors coneguts abans de provar aquests mòduls incomplets. No té cap sentit utilitzar aquests mòduls o casos de prova a BVT.

Podeu simplificar aquesta tasca d’inclusió de casos de prova de funcionalitat crítica comunicant-vos amb tots aquells que participen en el desenvolupament del projecte i en la prova del cicle de vida. Aquest procés hauria de negociar casos de proves BVT, que en última instància assegurin l’èxit de BVT. Estableix alguns estàndards de qualitat BVT i aquests estàndards només es poden complir analitzant les principals característiques i escenaris del projecte.

Per exemple, Casos de prova que s'inclouran a l'aplicació BVT per a l'editor de text (Només algunes proves de mostra):

  • Cas de prova per crear el fitxer de text.
  • Comproveu casos per escriure alguna cosa a l'editor de text
  • Cas de prova per a la funcionalitat de copiar, retallar, enganxar de l'editor de text
  • Cas de prova per obrir, desar i suprimir fitxers de text.

Aquests són alguns casos de prova de mostra, que es poden marcar com a 'crítics' i, per a cada canvi menor o important en l'aplicació, s'han d'executar aquests casos de prova bàsics crítics. Aquesta tasca la pot fer fàcilment BVT.

Els vestits d’automatització BVT s’han de mantenir i modificar puntualment. Per exemple. inclou casos de prova a BVT quan hi hagi nous mòduls de projecte estables disponibles.

Què passa quan s’executa la BVT Suite?

Digueu que el paquet de proves d'automatització de verificació de compilació s'executa després de qualsevol versió nova.
# 1) El resultat de l’execució de BVT s’envia a tots els identificadors de correu electrònic associats amb aquest projecte.
# 2) El propietari de BVT (persona que executa i manté la suite BVT) inspecciona el resultat de BVT.
# 3) Si la FVB falla, el propietari de la FVB diagnostica la causa de la falla.
# 4) Si la causa de l’error és el defecte de la compilació, s’envia tota la informació rellevant amb els registres d’errors als respectius desenvolupadors.
# 5) El desenvolupador en les seves respostes inicials de diagnòstic a l’equip sobre la causa del fracàs. Si realment es tracta d’un error? I si es tracta d’un error, quin serà el seu escenari de correcció d’errors.
# 6) Quan es corregeix l'error, es torna a executar el conjunt de proves BVT i, si la compilació passa per BVT, la versió es passa a l'equip de proves per obtenir més detalls sobre la funcionalitat, el rendiment i altres proves.

Aquest procés es repeteix per a cada nova versió.

Per què va fallar BVT o Build?

com utilitzar arrays.sort a Java

La BVT es trenca de vegades. Això no vol dir que sempre hi hagi cap error a la compilació. Hi ha algunes altres raons per construir fallades, com ara error de codificació de casos de prova, error de paquet d’automatització, error d’infraestructura, fallades de maquinari, etc.
Heu de resoldre la causa del trencament de la BVT i haureu d’actuar correctament després del diagnòstic.

Consells per a l'èxit de la BVT:

# 1) Dediqueu un temps considerable a escriure scripts de casos de proves BVT.
# 2) Registreu tanta informació detallada com sigui possible per diagnosticar el resultat aprovat o fallit de la BVT. Això ajudarà l'equip de desenvolupadors a depurar i conèixer ràpidament la causa de l'error.
# 3) Seleccioneu casos de prova estables que voleu incloure a BVT. Per a les noves funcions, si el nou cas crític de prova passa constantment en diferents configuracions, promou aquest cas de prova a la vostra suite BVT. D’aquesta manera es reduirà la probabilitat de fallades freqüents en la construcció a causa de nous mòduls inestables i casos de prova.
# 4) Automatitzeu el procés BVT tant com sigui possible. Des del procés de llançament de la versió fins al resultat BVT: automatitzeu-ho tot.
# 5) Tingueu algunes sancions per trencar la compilació ;-) Faran alguns bombons o un cafè en equip d'un desenvolupador que trenca la construcció.

Conclusió

BVT no és res més que un conjunt de casos de proves de regressió que s’executen cada vegada per a la nova versió. Això també s’anomena prova de fum. La compilació no s’assigna a l’equip de prova, tret que passi la BVT.

El desenvolupador o el verificador pot executar BVT i el resultat de BVT es comunica a tot l'equip i es prenen mesures immediates per solucionar l'error si falla BVT. Normalment, el procés BVT s’automatitza escrivint scripts per a casos de prova.

Només s’inclouen els casos crítics de proves a la BVT. Aquests casos de prova haurien de garantir la cobertura de les proves de l’aplicació. BVT és molt eficaç tant per a versions diàries com a llarg termini. Això estalvia temps, costos, recursos i, al cap i a la fi, cap frustració de l’equip de prova per la construcció incompleta.

Si teniu una mica d’experiència en el procés BVT, compartiu-la amb els nostres lectors en els comentaris següents.

Lectura recomanada

^