Meny

Valideringstesting Ultimate Guide

validation testing ultimate guide

Prøv Instrumentet Vårt For Å Eliminere Problemer

Utforsk viktigheten av valideringstesting:

Hva du vil lære:

Hva er valideringstesting?

Valideringstesting er prosessen for å sikre om den testede og utviklede programvaren tilfredsstiller klientens / brukerens behov. Forretningskravets logikk eller scenarier må testes i detalj. Alle kritiske funksjoner i en applikasjon må testes her.

Som tester er det alltid viktig å vite hvordan du kan verifisere forretningslogikken eller scenariene du får. En slik metode som hjelper i detaljevaluering av funksjonalitetene er valideringsprosessen.

Hver gang du blir bedt om å utføre en valideringstest, tar det et stort ansvar ettersom du trenger å teste alle kritiske forretningskrav basert på brukernes behov. Det bør ikke engang være en eneste glipp av kravene som brukeren spør. Derfor er det viktig å ha god kunnskap om valideringstesting.

Valideringstesting

Som tester må du vurdere om resultatene av testutførelsen er i samsvar med det som er nevnt i kravdokumentet. Ethvert avvik skal rapporteres umiddelbart, og det avviket kalles dermed en feil.

Verktøy som HP kvalitetssenter, selen, appium osv. Brukes til å utføre valideringstest, og vi kan lagre testresultatene der. En riktig testplan, testkjøring, manglerapporter, rapporter og beregninger er de viktigste resultatene som skal leveres.

Fra et selskapsperspektiv utføres valideringstesten i enkle trinn:

  • Du samler forretningskravene for valideringstesting fra sluttbrukeren.
  • Utarbeide forretningsplanen og send den til godkjenning til de involverte stedene / interessentene.
  • Når du har godkjent planen, begynner du å skrive de nødvendige testtilfellene og sende dem til godkjenning.
  • Når du er godkjent, begynner du å fullføre testingen med den nødvendige programvaren, miljøet og sende leveransene på forespørsel fra klienten.
  • Etter godkjenning av leveransene utføres UAT-testing av klienten.
  • Etter det går programvaren for produksjon.

trinn for valideringstesting

hvordan åpne .key-fil på Windows 10

La oss nå utforske mer om validering i detalj.

Forskjellen mellom verifisering og validering

La oss forstå disse med et eksempel på en enkel måte.

Eksempel:

Kundekrav:

Den foreslåtte injeksjonen bør ikke veie over 2 cm.

Bekreftelsestest:

  • Sjekk om injeksjonen er injeksjonen som ikke veier over 2 cm ved å bruke sjekkliste, gjennomgang og design.

Valideringstest:

  • Sjekk om injeksjonen ikke veier over 2 cm ved å bruke manuell eller automatiseringstesting.
  • Du må sjekke hvert eneste scenario som gjelder injeksjonsvekten ved å bruke en hvilken som helst egnet testmetode (funksjonelle og ikke-funksjonelle metoder).
  • Se etter mål mindre enn 2 cm og over 2 cm.
BekreftelseValidering
Prosessen sjekker bare design, kode og program.Den skal evaluere hele produktet inkludert koden.
Vurderinger, gjennomganger, inspeksjoner og skrivebordskontroll involvert.Funksjonelle og ikke-funksjonelle testmetoder er involvert. Det gjøres en grundig sjekk av produktet.
Den sjekker programvaren med spesifikasjon.Den sjekker om programvaren oppfyller brukerens behov.

Stadier involvert

  • Designkvalifisering: Dette inkluderer å lage testplanen basert på forretningskravene. Alle spesifikasjonene må nevnes tydelig.
  • Installasjonskvalifikasjon: Dette inkluderer programvareinstallasjon basert på kravene.
  • Operasjonell kvalifikasjon: Dette inkluderer testfase basert på spesifikasjonen for brukerkrav.

Dette kan inkludere Funksjonstesting:

    • Enhetstesting - Svart boks, Hvit boks, Grå boks.
    • Integrasjonstesting - Ovenfra og ned, nedenfra og opp, Big Bang.
    • Systemtesting - Sanity, Smoke, and Regression Testing.
  • Ytelseskvalifisering: UAT (testing av brukeraksept) - Alpha og Beta testing.
  • Produksjon

stadier involvert i valideringstesting

Designkvalifisering

Designkvalifisering betyr ganske enkelt at du må forberede utformingen av programvaren på en slik måte at den oppfyller brukerens spesifikasjoner. Primært må du skaffe deg URS-dokument (User Requirements Specification) fra klienten for å fortsette med designet.

Teststrategi:

Dette dokumentet danner grunnlaget for å utarbeide testplanen. Det utarbeides vanligvis av teamlederen eller prosjektlederen. Den beskriver hvordan vi skal gå frem for å teste og oppnå ønsket mål.

For å innlemme alle prosedyrene, bør en riktig plan utformes og godkjennes av interessentene. Så gi oss beskjed om komponentene i testplanen.

I noen få prosjekter kan testplan og teststrategi innarbeides som et enkelt dokument. Separate strategidokumenter blir også utarbeidet for et komplekst prosjekt (for det meste innen automatiseringsteknikk).

Komponenter i valideringstestplanen:

  • Beskrivelse av prosjektet
  • Forstå kravene
  • Omfanget av testing
  • Testnivåer og testplan
  • Kjør planopprettelse
  • Maskinvare-programvare og bemanningskrav
  • Roller og ansvar
  • Antakelse og avhengighet
  • Risiko og avbøting
  • Rapport og beregninger

Beskrivelse av prosjektet: Her må du belyse all beskrivelsen av applikasjonen du har fått for testing. Den skal inneholde alle funksjonene i appen.

Forstå kravene: Når du får USR, må du nevne de forståte kravene fra din side. Du kan også ta opp avklaringer hvis noen. Dette står som basen eller testkriteriene for testing.

Testens omfang: Omfanget må inkludere modulene i detalj sammen med funksjonene på et høyt nivå. Du må fortelle klienten hva alle kravene du vil dekke i testingen.

Fra et forretningsperspektiv kan valideringstesting bli bedt om å utføre for de kritiske kravene til en applikasjon. Det betyr ganske enkelt at du sier hva som skal dekkes og hva ikke .

Testnivåer og testplan: Du må nevne hvor mange testerunder som må gjennomføres. Den samlede innsatsen for testprosjektet er estimert ved hjelp av standard estimeringsteknikker som TCP-estimering (Test Case Point) etc.

Som navnet tilsier testplan beskriver hvordan testingen skal gjennomføres. Det bør også si hvordan og når godkjenningen og gjennomgangene vil bli gjennomført.

Eksempel:

Prosjektet vurderes å utforme en webside.

Testnivåer inkluderer:

Nivå 1: Røykprøving
Nivå 2: Enhetstesting
Nivå 3: Integrasjonstesting
Nivå 3: Systemtesting
Nivå 3: Akseptprøving

Testplan:

  1. Planinnsending - Dag 1
  2. Design av testsaker - Dag 2
  3. Tørrkjøring og feilretting - Dag 4
  4. Anmeldelse- Dag 5
  5. Formelt løp - Dag 6
  6. Leveranser sendt for godkjenning - Dag 8
  7. Rapporter - Dag 10

Kjør oppretting av plan: Løpsplanen markerer antall løp som kreves for testing. Hver løp du utfører på offsite vil bli notert av teamet på stedet.

For eksempel, når du bruker HP Quick Test Professional-verktøy for kjøring vil antall løp vises i fanen Kjører i testplanen.

Maskinvare-programvare og bemanningskrav:

  • Maskinvare- og programvarekrav som enheter, nettleserversjoner, IOS, testverktøy som kreves for prosjektet.
  • Bemanning betyr å utnevne personene som er nødvendige for testing. Du kan nevne antall lag her.
  • I tilfelle du trenger ekstra testmedlemmer, kan du be om stedet avhengig av testomfanget. Bare når antallet testsaker øker, betyr det at du trenger flere teammedlemmer for å utføre dem.

Roller og ansvar: Dette innebærer å tildele oppgaver til de relaterte rollene som er ansvarlige for å gjennomføre de forskjellige testnivåene.

For eksempel,

En app må testes av et team bestående av 4 medlemmer for å utføre 4 valideringsprotokoller, og du kan delegere ansvaret som følger:

  1. Testledning: Design av testplan
  2. Lagmedlem 1: Design og utførelse av protokoller 1,2.
  3. Teammedlem 2: Design og utførelse av protokoller 3,4.
  4. Teammedlem: Utarbeidelse av rapporter, gjennomgang og beregninger.

Antakelse og avhengighet: Dette betyr at forutsetningene som er gjort under design og avhengigheter som er identifisert for testing, vil bli inkludert her.

Risiko og avbøtende forhold: Risiko knyttet til testplanlegging, for eksempel tilgjengelighet av de ønskede miljøene, bygg osv. Sammen med avbøtende og beredskapsplaner.

Rapport og beregninger: Faktorer som ble brukt til testing og rapporter til interessentene må nevnes her.

Et eksempel på en mobilapp er gitt nedenfor:

beregninger

Installasjonskvalifisering

  • Installasjonskvalifisering inneholder detaljer som hvilke og hvor mange testmiljøer som vil bli brukt, hvilket tilgangsnivå som kreves for testerne i hvert miljø sammen med de nødvendige testdataene. Det kan omfatte nettleserkompatibilitet, verktøy som kreves for utføring, enheter som kreves for testing, etc. Systemet som utvikles bør installeres i samsvar med brukerens krav.
  • Testdata kan være nødvendig for å teste noen applikasjoner, og den må gis av riktig person. Det er en viktig forutsetning.
  • Noen applikasjoner kan kreve en database. Vi må ha alle dataene som kreves for testing klare i en database for å validere spesifikasjonene.

For eksempel, En ny app sier at “abc” må testes i mobil (Android 4.3.1) og nettleser (Chrome 54). I et slikt tilfelle må vi holde rede på følgende:

  • Sjekk om riktig autorisasjon er gitt til å sjekke nettstedet til appen “abc”.
  • Se om enhetene som brukes til å teste appen som mobil (android / ios), nettleser-Chrome, Internet Explorer med nødvendig versjon er tilgjengelige.
  • Sjekk om de er riktig installert med de angitte versjonene (f.eks. Chrome 54, Android versjon 4.3.1).
  • Forsikre deg om at appen er tilgjengelig i både nettleser og mobil.

Operasjonell kvalifikasjon

Operasjonell kvalifisering sikrer at hver modul og undermodul designet for applikasjonen under test fungerer som den forventes i ønsket miljø.

Generelt utføres en valideringstesting i følgende hierarki.

Valideringsprøvehierarki

Funksjonstesting spiller en viktig rolle i valideringstesting. Det betyr ganske enkelt at du må validere funksjonaliteten til applikasjonen etter hvert kritiske krav som er nevnt. Dette baner vei for å kartlegge kravene nevnt i dokumentet Funksjonsspesifikasjon og sikre at produktet oppfyller alle nevnte krav.

Funksjonell testing og dens typer

Som navnet antyder, funksjonstesting er å teste funksjonene, dvs. hva programvaren må gjøre. Funksjonene til programvaren vil bli definert i kravspesifikasjonsdokumentet.

beste gratis brannmur for Windows 10 2018

La oss få et raskt blikk av typene.

# 1) Enhetstesting:

Enhetstesting er å teste de enkelte enhetene / modulene / komponentene / metodene til det gitte systemet. Feltvalidering, layoutkontroll, design osv. Testes med forskjellige innganger etter koding. Hver linje i koden bør valideres til de enkelte testtilfellene.

Enhetstesting gjøres av utviklerne selv. Kostnaden for å fikse feil er mindre her sammenlignet med de andre testnivåene.

Eksempel:

Evaluering av en løkke av koden for en funksjon sier at kjønnsvalg er et eksempel på enhetstesting.

# 2) Black Box Testing:

Å teste oppførselen til en applikasjon for de ønskede funksjonalitetene mot kravene uten å fokusere de interne detaljene i systemet kalles Black box testing. Det utføres vanligvis av et uavhengig testteam eller sluttbrukerne av applikasjonen.

Applikasjonen er testet med relevante innganger og testes for å validere hvis systemet oppfører seg som ønsket. Dette kan brukes til å teste både funksjonelle og ikke-funksjonelle krav.

# 3) Testing av hvit boks:

Testing av hvit boks er ingenting annet enn en detaljert kontroll av programkoden etter kode. Hele bruken av applikasjonen avhenger av koden som er skrevet, og det er derfor nødvendig å teste koden veldig nøye. Du må sjekke hver enhet og dens integrering som en hel modul trinnvis.

En tester med programmeringskunnskap er et must-kriterium her. Dette finner tydelig ut om det er noe avvik i arbeidsflyten til applikasjonen. Det er nyttig for både utviklere og testere.

# 4) Testing av grå boks:

Testing av grå bokser er en kombinasjon av både hvit boks og svart boks testing. Delvis kunnskap om strukturen eller koden til enheten som skal testes er kjent her.

Integrasjonstesting og dens typer

De enkelte komponentene i programvaren som allerede er testet i enhetstesting, integreres og testes sammen for å teste funksjonaliteten som en helhet, for å sikre dataflyt over modulene.

Dette gjøres av utviklerne selv eller av et uavhengig testteam. Dette kan gjøres etter at to eller flere enheter er testet.

Topp-ned-tilnærming:

Top-down tilnærming

I denne tilnærmingen testes de øverste enhetene først, og deretter blir enhetene på lavere nivå testet en etter en trinnvis. Teststubber som kan brukes er påkrevd for å simulere enheter på lavere nivå som kanskje ikke er tilgjengelige i de innledende fasene.

Bottom-up-tilnærming:

Bottom-up-tilnærming

I denne tilnærmingen testes bunnenhetene først, integreres, og deretter blir enhetene på høyere nivå testet. Teststubber som kan brukes, kreves for å simulere enhetene på høyere nivå som kanskje ikke er tilgjengelige i de innledende fasene.

Systemtesting og dens typer

Å teste hele systemet / programvaren kalles systemtesting. Systemet er testet fullstendig mot funksjonskravspesifikasjonene. Systemtesting gjøres mot både funksjonelle og ikke-funksjonelle krav. Black box testing er generelt foretrukket for denne typen testing.

# 1) Røykprøving:

Når byggherrene gir bygget til å teste innledningsvis, må vi teste bygget grundig. Dette kalles røykprøving. Vi må oppgi om bygningen er i stand til å teste videre eller ikke.

For å utføre validering, trenger du en riktig bygging. Derfor blir røykprøving først utført av testteamet. Arbeidsflyten for den testede applikasjonen skal testes enten med testtilfellene eller uten den. Testtilfelle som dekker hele flyten er nyttig for denne testingen.

# 2) Sanity Testing:

Ved fornuftstesting testes hovedfunksjonalitetene til modulene i applikasjonen som testes. Ved testing av et nettsted som har tre faner, dvs. oppretting av profil, utdanning, innlogging, etc., i IRCTC , de viktigste funksjonene til alle disse kategoriene må sjekkes uten å gå veldig dypere.

Menyene, undermenyene, fanene må testes i alle modulene. Det er en delmengde av regresjonstesting da testing bare utføres av hovedstrømmen og ikke i dybden.

# 3) Regresjonstesting:

For hver utgivelse av prosjektet kan utviklingsteamet innføre visse endringer. Validering hvis de nye endringene som er innført ikke har påvirket arbeidsflyten i systemet, kalles regresjonstesting. Bare visse testtilfeller knyttet til de nye kravene må testes her.

krav om fremkallingsteknikker innen programvareteknikk

Ytelseskvalifisering

UAT (testing av brukeraksept):

Dette er den siste fasen av testing som er gjort for å sikre at systemet oppfører seg etter behov tilsvarende de spesifiserte kravene. Dette gjøres av klienten. Når klienten sertifiserer og fjerner systemtesting, kan produktet gå for distribusjon.

Alfa- og betatesting:

Alpha-testing gjøres av utviklerne på applikasjonen før de slippes på programvareutviklingssiden. Det innebærer testing i svart-hvitt-boks. Betatesting gjøres på kundesiden etter at produktet er utviklet og distribuert.

Eksempel på valideringstestsaker eller protokoller

Med min erfaring har jeg skrevet denne protokollen for Gmail-pålogging.

Grundig sjekk av påloggingsfunksjonaliteten som dekkes er hva validering faktisk er. Men jeg vil nevne at stilen til setningskolonner som brukes, kan være helt forskjellig og avhenge av kundens krav.

=> Last ned eksempler på valideringstest: Gmail-påloggingsprøvesak

Konklusjon

Validering handler om å analysere funksjonene til et produkt i detalj. Som valideringstester må du alltid huske å rapportere avvikene der og da for å oppnå optimale resultater i testingen.

Hver prøvesak som er skrevet skal være skarp, kortfattet og forståelig selv for den vanlige mannen. Valideringstester bør sikre at riktig produkt utvikles mot de spesifiserte kravene.

Som en guide for valideringstesting har jeg dekket prosessen knyttet til validering.

Designkvalifisering som involverer valideringsplan, Installasjonskvalifisering som snakker om maskinvare-programvareavdelingen, en Operasjonell kvalifikasjon som involverer hele systemtesten, Ytelseskvalifisering som involverer testing av brukeraksept som gir autorisasjon for produksjon.

Håper denne artikkelen ville ha beriket din kunnskap om konseptet valideringstesting !!

Anbefalt lesing

^