build verification testing complete guide
Hva er Build Verification Testing (BVT)?
Build Verification Test er et sett med tester som kjøres på hver nye build for å bekrefte at build kan testes før den blir utgitt til testteamet for videre testing.
Disse testtilfellene er kjernefunksjonalitetstestsaker som sikrer at applikasjonen er stabil og kan testes grundig. Vanligvis er BVT-prosessen automatisert. Hvis BVT mislykkes, blir byggingen igjen tildelt en utvikler for reparasjonen.
BVT kalles også Røykprøving eller bygger godkjenningstesting (BAT)
Nybygg sjekkes hovedsakelig for to ting:
- Bygg validering
- Bygg aksept
Noen grunnleggende om BVT:
- Det er en delmengde av tester som verifiserer hovedfunksjonalitetene.
- BVT-ene kjøres vanligvis på daglige builds, og hvis BVT mislykkes, avvises build-en, og en ny build frigjøres etter at løsningene er gjort.
- Fordelen med BVT er at det sparer innsatsen til et testteam for å sette opp og teste et bygg når større funksjonalitet er brutt.
- Design BVTs nøye nok til å dekke grunnleggende funksjonalitet.
- Vanligvis bør BVT ikke løpe mer enn 30 minutter.
- BVT er en type Regresjonstesting , gjort på hver eneste nye bygning.
BVT sjekker først og fremst for prosjektintegriteten og sjekker om alle modulene er integrert riktig eller ikke. Testing av modulintegrasjon er veldig viktig når forskjellige team utvikler prosjektmoduler. Jeg hørte mange tilfeller av programfeil på grunn av feil modulintegrering. Selv i verste tilfeller blir hele prosjektet skrotet på grunn av svikt i modulintegrering.
Hva er hovedoppgaven i Build Release? Åpenbart fil 'innsjekking' dvs. å inkludere alle de nye og modifiserte prosjektfilene som er tilknyttet respektive bygg. BVT ble først og fremst introdusert for å sjekke den opprinnelige helsen til bygningen, dvs. for å sjekke om - alle de nye og modifiserte filene er inkludert i utgivelsen, alle filformatene er korrekte, hver filversjon og språk, flagg knyttet til hver fil.
Disse grunnleggende kontrollene er verdt før utgivelsen til testteamet for testing. Du vil spare tid og penger ved å oppdage byggefeilene helt i begynnelsen ved hjelp av BVT.
Hvilke testtilfeller bør inkluderes i BVT?
Dette er en veldig vanskelig beslutning å ta før du automatiserer BVT-oppgaven. Husk at suksessen til BVT avhenger av hvilke testtilfeller du inkluderer i BVT.
Her er noen enkle tips å ta med Test tilfeller i BVT Automation Suite:
- Inkluder bare kritiske testsaker i BVT.
- Alle testtilfeller som inngår i BVT, bør være stabile.
- Alle testsakene burde ha visst forventet resultatet.
- Forsikre deg om at alle inkluderte tilfeller med kritisk funksjonalitet er tilstrekkelig for å dekke applikasjonstester.
Inkluderer heller ikke moduler i BVT, som ennå ikke er stabile. For noen underutviklingsfunksjoner kan du ikke forutsi forventet oppførsel ettersom disse modulene er ustabile, og du kanskje kjenner til noen kjente feil før du tester for disse ufullstendige modulene. Det nytter ikke å bruke slike moduler eller testtilfeller i BVT.
Du kan gjøre denne kritiske funksjonalitetstestenes inkluderingsoppgave enkel ved å kommunisere med alle de som er involvert i prosjektutvikling og testing av livssyklusen. En slik prosess bør forhandle om BVT-testtilfeller, som til slutt sikrer BVT-suksess. Sett noen BVT-kvalitetsstandarder, og disse standardene kan bare oppfylles ved å analysere viktige prosjektfunksjoner og scenarier.
For eksempel, Test tilfeller som skal inkluderes i BVT for Text editor applikasjon (Bare noen prøvetester):
- Test case for å lage tekstfilen.
- Test saker for å skrive noe inn i tekstredigereren
- Test case for kopiering, klipp, lim inn funksjonaliteten til teksteditoren
- Test case for å åpne, lagre, slette tekstfil.
Dette er noen eksempler på testtilfeller, som kan merkes som ‘kritiske’, og for hver mindre eller større endring i applikasjonen, bør disse grunnleggende kritiske testtilfellene utføres. Denne oppgaven kan enkelt utføres av BVT.
BVT-automatiseringsdrakter må vedlikeholdes og endres fra tid til annen. F.eks. inkluderer testtilfeller i BVT når det er nye stabile prosjektmoduler tilgjengelig.
Hva skjer når BVT Suite kjører?
Si at byggeverifiseringsautomatiseringstestpakken er utført etter nybygg.
#1) Resultatet av BVT-utførelse blir sendt til alle e-post-ID-ene som er tilknyttet prosjektet.
#to) BVT-eieren (person som utfører og vedlikeholder BVT-pakken) inspiserer resultatet av BVT.
# 3) Hvis BVT mislykkes, diagnostiserer BVT-eieren årsaken til feilen.
# 4) Hvis feilårsaken er mangelen i build, blir all relevant informasjon med feillogger sendt til respektive utviklere.
# 5) Utvikler på hans første diagnostiske svar til teamet om årsaken til feilen. Om dette virkelig er en feil? Og hvis det er en feil, hva vil da være hans feilrettingsscenario.
# 6) Ved feilretting utføres igjen BVT-testpakke, og hvis build passerer BVT, sendes build til testteam for ytterligere detaljfunksjonalitet, ytelse og andre tester.
Denne prosessen blir gjentatt for hver nybygg.
Hvorfor mislyktes BVT eller Build?
BVT går i stykker noen ganger. Dette betyr ikke at det alltid er en feil i bygningen. Det er noen andre grunner til å bygge mislykkes, som kodefeil i testtilfeller, feil i automatiseringspakken, infrastrukturfeil, maskinvarefeil etc.
Du må feilsøke årsaken til BVT-bruddet og må ta ordentlige tiltak etter diagnosen.
qa testing intervju spørsmål for erfarne
Tips for BVT-suksess:
#1) Bruk mye tid på å skrive skript for BVT-testtilfeller.
#to) Logg så mye detaljert informasjon som mulig for å diagnostisere BVT-bestått eller mislykket resultat. Dette vil hjelpe utviklergruppen til å feilsøke og raskt vite feilårsaken.
# 3) Velg stabile testtilfeller som skal inkluderes i BVT. For nye funksjoner, hvis nye kritiske testtilfeller overføres konsekvent til forskjellige konfigurasjoner, kan du markedsføre denne testsaken i din BVT-suite. Dette vil redusere sannsynligheten for hyppig byggefeil på grunn av nye ustabile moduler og testtilfeller.
# 4) Automatiser BVT-prosessen så mye som mulig. Helt fra utgivelsesprosessen til BVT-resultatet - automatiser alt.
# 5) Har noen straffer for å bryte bygningen ;-) Noen sjokolader eller teamkaffe fra en utvikler som bryter bygget, vil gjøre.
Konklusjon
BVT er bare et sett med regresjonstesttilfeller som utføres hver gang for nybygget. Dette kalles også en røykprøve. Byggingen er ikke tildelt testteamet med mindre og før BVT har bestått.
BVT kan kjøres av utvikler eller tester, og BVT-resultat blir kommunisert i hele teamet, og øyeblikkelig blir det gjort for å fikse feilen hvis BVT mislykkes. BVT-prosessen automatiseres vanligvis ved å skrive skript for testtilfeller.
Bare kritiske testsaker er inkludert i BVT. Disse testtilfellene skal sikre applikasjonstestdekning. BVT er veldig effektivt for både daglige og langsiktige bygg. Dette sparer betydelig tid, kostnader, ressurser og tross alt ingen frustrasjon for testteamet for den ufullstendige bygningen.
Hvis du har erfaring i BVT-prosessen, kan du dele den med leserne våre i kommentarene nedenfor.
Anbefalt lesing
- Alpha Testing og Beta Testing (En komplett guide)
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Funksjonstesting mot ikke-funksjonell testing
- Typer programvaretesting: Ulike testtyper med detaljer
- ETL Testing Tutorial Data Warehouse Testing Tutorial (En komplett guide)
- Veiledning for testing av webapplikasjoner
- Beste QA Software Testing Services fra SoftwareTestingHelp
- Testing Primer eBook Download