Menu

Build Verification Testing (BVT Testing) Komplet guide

build verification testing complete guide

Prøv Vores Instrument Til At Fjerne Problemer

Hvad er Build Verification Testing (BVT)?

Build Verification Test er et sæt tests, der køres på hver nye build for at kontrollere, at build kan testes, før den frigives til testteamet til yderligere test.

Disse testsager er kernefunktionalitetstestsager, der sikrer, at applikationen er stabil og kan testes grundigt. BVT-processen er typisk automatiseret. Hvis BVT mislykkes, tildeles build igen til en udvikler til rettelsen.

Build Verification Testing (BVT Testing)

BVT kaldes også Røgtest eller Builds Acceptance Testing (BAT)

Nybygning kontrolleres hovedsageligt for to ting:

  • Byg validering
  • Byg accept

Nogle grundlæggende om BVT:

  • Det er en delmængde af tests, der verificerer hovedfunktionaliteter.
  • BVT'erne køres typisk på daglige builds, og hvis BVT mislykkes, afvises build'en, og en ny build frigives, når rettelserne er udført.
  • Fordelen ved BVT er, at det sparer et testteams indsats for at oprette og teste et build, når større funktionalitet er brudt.
  • Design BVT'er omhyggeligt nok til at dække grundlæggende funktionalitet.
  • Typisk bør BVT ikke køre mere end 30 minutter.
  • BVT er en type Regressionstest , gjort på hver eneste nye build.

BVT kontrollerer primært projektintegriteten og kontrollerer, om alle modulerne er integreret korrekt eller ej. Test af modulintegration er meget vigtig, når forskellige hold udvikler projektmoduler. Jeg har hørt mange tilfælde af applikationsfejl på grund af forkert modulintegration. Selv i værste tilfælde bliver det komplette projekt skrottet på grund af fejl i modulintegration.

Hvad er hovedopgaven i Build Release? Åbenbart fil 'check-in', dvs. at inkludere alle de nye og ændrede projektfiler, der er knyttet til respektive builds. BVT blev primært introduceret for at kontrollere den oprindelige byggesundhed, dvs. for at kontrollere, om - alle de nye og ændrede filer er inkluderet i udgivelsen, alle filformater er korrekte, hver filversion og sprog, flag tilknyttet hver fil.

Disse grundlæggende kontrol er værd, før build-frigivelse til testteam til test. Du sparer tid og penge ved at opdage byggefejlene i begyndelsen ved hjælp af BVT.

Hvilke testtilfælde skal inkluderes i BVT?

Dette er en meget vanskelig beslutning at tage inden automatisering af BVT-opgaven. Husk, at succesen med BVT afhænger af, hvilke testsager du inkluderer i BVT.

Her er nogle enkle tip til at medtage Test tilfælde i din BVT Automation Suite:

  • Inkluder kun kritiske testsager i BVT.
  • Alle testsager, der er inkluderet i BVT, skal være stabile.
  • Alle testsagerne burde have kendt forventet resultatet.
  • Sørg for, at alle inkluderede kritiske funktionalitetstestsager er tilstrækkelige til at dække applikationstest.

Omfatter heller ikke moduler i BVT, som endnu ikke er stabile. For nogle underudviklingsfunktioner kan du ikke forudsige forventet adfærd, da disse moduler er ustabile, og du måske kender nogle kendte fejl, før du tester for disse ufuldstændige moduler. Der er ingen mening med at bruge sådanne moduler eller testsager i BVT.

Du kan gøre denne kritiske funktionalitet til at inkludere en enkel opgave ved at kommunikere med alle dem, der er involveret i projektudvikling og test af livscyklus. En sådan proces skal forhandle BVT-testsager, som i sidste ende sikrer BVT-succes. Sæt nogle BVT-kvalitetsstandarder, og disse standarder kan kun overholdes ved at analysere store projektfunktioner og scenarier.

For eksempel, Testcases skal inkluderes i BVT for Teksteditor-applikation (Kun nogle prøvetest):

hvilket er bedre java eller c ++
  • Test sag til oprettelse af tekstfilen.
  • Test sager for at skrive noget i teksteditoren
  • Test sag til kopiering, klipning, indsættelse af funktionaliteten i teksteditoren
  • Test sag til at åbne, gemme, slette tekstfil.

Dette er nogle eksempler på testtilfælde, som kan markeres som 'kritiske', og for hver mindre eller større ændring i applikationen skal disse grundlæggende kritiske testsager udføres. Denne opgave kan let udføres af BVT.

BVT-automatiseringsdragter skal vedligeholdes og ændres fra tid til anden. For eksempel. inkluderer testcases i BVT, når der er nye stabile projektmoduler tilgængelige.

Hvad sker der, når BVT Suite kører?

Sig, at byggeprøveautomatiseringstestsuite udføres efter enhver ny build.
# 1) Resultatet af BVT-udførelse sendes til alle e-mail-id'erne, der er knyttet til projektet.
#to) BVT-ejeren (person, der udfører og vedligeholder BVT-pakken) inspicerer resultatet af BVT.
# 3) Hvis BVT mislykkes, diagnosticerer BVT-ejeren årsagen til svigt.
# 4) Hvis fejlårsagen er manglen i build, sendes alle relevante oplysninger med fejllogfiler til respektive udviklere.
# 5) Udvikler på hans indledende diagnostiske svar til teamet om fejlårsagen. Om dette virkelig er en fejl? Og hvis det er en fejl, hvad vil så være hans fejlrettelsesscenarie.
# 6) Ved fejlrettelse udføres endnu en gang BVT-testpakke, og hvis build passerer BVT, overføres build til testteam for yderligere detaljeringsfunktionalitet, ydeevne og andre tests.

Denne proces gentages for hver ny build.

Hvorfor mislykkedes BVT eller Build?

BVT bryder nogle gange. Dette betyder ikke, at der altid er en fejl i buildet. Der er nogle andre grunde til at oprette mislykkedes som testkodekodningsfejl, automatiseringspakkefejl, infrastrukturfejl, hardwarefejl osv.
Du er nødt til at foretage fejlfinding på årsagen til BVT-pausen og er nødt til at tage ordentlig handling efter diagnosen.

Tips til BVT-succes:

# 1) Brug lang tid på at skrive BVT-testcases-scripts.
#to) Log så meget detaljeret info som muligt for at diagnosticere BVT-pass eller fail-resultatet. Dette hjælper udviklerteamet med at debugge og hurtigt kende fejlårsagen.
# 3) Vælg stabile testsager, der skal medtages i BVT. For nye funktioner, hvis en ny kritisk test sag overføres konsekvent til forskellige konfigurationer, skal du promovere denne test sag i din BVT suite. Dette reducerer sandsynligheden for hyppig byggefejl på grund af nye ustabile moduler og testtilfælde.
# 4) Automatiser BVT-processen så meget som muligt. Lige fra build release-processen til BVT-resultatet - automatiser alt.
# 5) Har nogle sanktioner for at bryde buildet ;-) Nogle chokolader eller teamkaffe-fest fra en udvikler, der bryder buildet, vil gøre.

Konklusion

BVT er intet andet end et sæt regressionstestsager, der udføres hver gang til den nye build. Dette kaldes også en røgtest. Bygningen tildeles ikke testteamet, medmindre og indtil BVT passerer.

BVT kan køres af udvikler eller tester, og BVT-resultatet kommunikeres i hele teamet, og der træffes øjeblikkelig handling for at rette fejlen, hvis BVT mislykkes. BVT-processen automatiseres typisk ved at skrive scripts til testsager.

Kun kritiske testsager er inkluderet i BVT. Disse testsager skal sikre dækning af applikationstest. BVT er meget effektiv til daglige såvel som langsigtede opbygninger. Dette sparer betydelig tid, omkostninger, ressourcer og trods alt ingen frustration for testteamet for den ufuldstændige build.

Hvis du har nogle erfaringer med BVT-processen, så del den med vores læsere i kommentarerne nedenfor.

Anbefalet læsning

^