Menu

Valideringstest Ultimate Guide

validation testing ultimate guide

Prøv Vores Instrument Til At Fjerne Problemer

Udforsk vigtigheden af ​​valideringstest:

Hvad du lærer:

Hvad er valideringstest?

Valideringstest er processen med at sikre, om den testede og udviklede software opfylder klientens / brugernes behov. Forretningskravets logik eller scenarier skal testes i detaljer. Alle de kritiske funktioner i en applikation skal testes her.

Som tester er det altid vigtigt at vide, hvordan man verificerer den forretningslogik eller de scenarier, der er givet til dig. En sådan metode, der hjælper med detaljeret evaluering af funktionaliteterne er valideringsprocessen.

Når du bliver bedt om at udføre en valideringstest, tager det et stort ansvar, da du har brug for at teste alle de kritiske forretningskrav baseret på brugernes behov. Der bør ikke engang være en eneste glip af de krav, som brugeren stiller. Derfor er en stor viden om valideringstest meget vigtig.

Valideringstest

Som tester skal du evaluere, om testudførelsesresultaterne er i overensstemmelse med det, der er nævnt i kravdokumentet. Enhver afvigelse skal rapporteres straks, og denne afvigelse kaldes således en fejl.

Værktøjer som HP kvalitetscenter, selen, appium osv. Bruges til at udføre valideringstest, og vi kan gemme testresultaterne der. En ordentlig testplan, testkørsel, fejlrapporter, rapporter og målinger er de vigtige resultater, der skal indsendes.

Fra et virksomhedsperspektiv udføres valideringstesten i enkle trin med følgende trin:

  • Du samler forretningskravene til valideringstest fra slutbrugeren.
  • Forbered forretningsplanen og send den til godkendelse til de involverede onsite / interessenter.
  • Efter godkendelse af planen begynder du at skrive de nødvendige testsager og sende dem til godkendelse.
  • Når du er godkendt, begynder du at afslutte testning med den krævede software, miljø og sende leveringerne efter anmodning fra klienten.
  • Efter godkendelse af leverancerne udføres UAT-test af klienten.
  • Derefter går softwaren til produktion.

trin til valideringstest

konvertere ascii til int c ++

Lad os nu undersøge mere om validering i detaljer.

Forskellen mellem kontrol og validering

Lad os forstå disse med et eksempel på en enkel måde.

Eksempel:

Kundekrav:

Den foreslåede injektion bør ikke veje over 2 cm.

Bekræftelsestest:

  • Kontroller, om injektionen er den injektion, der ikke vejer over 2 cm ved hjælp af tjekliste, gennemgang og design.

Valideringstest:

  • Kontroller, om injektionen ikke vejer over 2 cm ved hjælp af manuel eller automatiseringstest.
  • Du skal kontrollere alle mulige scenarier vedrørende injektionsvægten ved hjælp af en hvilken som helst egnet testmetode (funktionelle og ikke-funktionelle metoder).
  • Kontroller for målinger mindre end 2 cm og over 2 cm.
VerifikationValidering
Processen kontrollerer bare design, kode og program.Det skal evaluere hele produktet inklusive koden.
Anmeldelser, gennemgange, inspektioner og skrivebordskontrol involveret.Funktionelle og ikke-funktionelle testmetoder er involveret. Der foretages en dybtgående kontrol af produktet.
Det kontrollerer softwaren med specifikation.Den kontrollerer, om softwaren opfylder brugernes behov.

Stadier involveret

  • Designkvalifikation: Dette inkluderer oprettelse af testplanen baseret på forretningskravene. Alle specifikationer skal nævnes tydeligt.
  • Installationskvalifikation: Dette inkluderer softwareinstallation baseret på kravene.
  • Operationel kvalifikation: Dette inkluderer testfase baseret på brugerkravsspecifikationen.

Dette kan omfatte Funktionstest:

    • Enhedstest - Sort kasse, Hvid kasse, Grå kasse.
    • Integrationstest - Top-down, Bottom-up, Big bang.
    • Systemtest - Test af sanitet, røg og regression.
  • Præstationskvalifikation: UAT (test af brugeraccept) - Alpha og Beta test.
  • Produktion

faser involveret i valideringstest

Designkvalifikation

Designkvalifikation betyder simpelthen, at du er nødt til at forberede softwarens design på en sådan måde, at den opfylder brugerens specifikationer. Primært skal du få URS-dokument (User Requirements Specification) fra klienten til at fortsætte med designet.

Teststrategi:

Dette dokument danner grundlaget for udarbejdelse af testplanen. Det udarbejdes normalt af teamlederen eller projektlederen. Den beskriver, hvordan vi skal fortsætte med at teste og nå det ønskede mål.

For at indarbejde alle procedurerne skal der udformes en ordentlig plan og godkendes af interessenterne. Så lad os kende komponenterne i testplanen.

I nogle få projekter kan testplan og teststrategi indarbejdes som et enkelt dokument. Der udarbejdes også separate strategidokumenter til et komplekst projekt (hovedsagelig inden for automatiseringsteknik).

Komponenter i valideringstestplanen:

  • Beskrivelse af projektet
  • Forståelse af kravene
  • Testens omfang
  • Testniveauer og testplan
  • Kør oprettelse af plan
  • Hardware-software og personalekrav
  • Roller og ansvar
  • Antagelse og afhængighed
  • Risici og afbødning
  • Rapport og målinger

Beskrivelse af projektet: Her skal du belyse hele beskrivelsen af ​​den applikation, du får til test. Det skal omfatte alle funktionerne i appen.

Forståelse af kravene: Når du får USR, skal du nævne de forståede krav fra din side. Du kan også rejse afklaringer, hvis nogen. Dette står som basis eller testkriterier for test.

Testens omfang: Omfanget skal omfatte modulerne i detaljer sammen med funktionerne på et højt niveau. Du skal fortælle klienten, hvilke krav du vil dække i din test.

Fra et forretningsperspektiv kan valideringstest blive bedt om at udføre de kritiske krav til en applikation. Det betyder simpelthen, at du siger, hvad der vil blive dækket, og hvad ikke .

Testniveauer og testplan: Du skal nævne, hvor mange testrunder der skal gennemføres. Den samlede indsats for testprojektet estimeres ved hjælp af standardestimeringsteknikker som TCP-estimering (Test Case Point) osv.

Som navnet antyder testplan beskriver, hvordan testen udføres. Det skal også sige, hvordan og hvornår godkendelsen og gennemgangene vil blive gennemført.

Eksempel:

Design af en webside er det projekt, der overvejes.

Testniveauer inkluderer:

Niveau 1: Røgtest
Niveau 2: Enhedstest
Niveau 3: Integrationstest
Niveau 3: Systemtest
Niveau 3: Accept test

Testplan:

  1. Planindgivelse - Dag 1
  2. Design af testsager - Dag 2
  3. Tørkørsel og bug fixing - Dag 4
  4. Anmeldelse- Dag 5
  5. Formel løb - Dag 6
  6. Leverancer sendt til godkendelse - Dag 8
  7. Rapporter - Dag 10

Kør oprettelse af plan: Kørplanen markerer det antal kørsler, der kræves til testning. Hver kørsel, du udfører i offsite, vil blive noteret af teamet på stedet.

For eksempel, når du bruger HP Quick Test Professional-værktøj til udførelse vises antallet af kørsler i fanen Kør i testplanen.

Hardware-software og personalekrav:

  • Hardware- og softwarekrav som enheder, browserversioner, IOS, testværktøjer, der kræves til projektet.
  • Bemanding betyder udnævnelse af de personer, der kræves til test. Du kan nævne holdtællingen her.
  • Hvis du har brug for ekstra testmedlemmer, kan du anmode om stedet afhængigt af testomfanget. Simpelthen når antallet af testsager stiger, betyder det, at du har brug for flere teammedlemmer til at udføre dem.

Roller og ansvar: Dette indebærer at tildele opgaver til de relaterede roller, der er ansvarlige for at gennemføre de forskellige testniveauer.

For eksempel,

En app skal testes af et team bestående af 4 medlemmer for at udføre 4 valideringsprotokoller, og du kan delegere ansvarsområderne som følger:

  1. Testledning: Design af testplan
  2. Teammedlem 1: Design og udførelse af protokoller 1,2.
  3. Teammedlem 2: Design og udførelse af protokoller 3,4.
  4. Medarbejder: Udarbejdelse af rapporter, gennemgang og metrics.

Antagelse og afhængigheder: Dette betyder, at de antagelser, der er foretaget under design og afhængigheder, der er identificeret til test, vil blive inkluderet her.

Risici og afbødning: Risici i forbindelse med testplanlægningen såsom tilgængelighed af de ønskede miljøer, build osv. Sammen med afbødnings- og beredskabsplaner.

Rapport og målinger: Faktorer, der blev brugt til test og rapporter til interessenterne, skal nævnes her.

Nedenfor gives et eksempel på en mobilapp:

vægtet graf tilstødelsesliste c ++

målinger

Installationskvalifikation

  • Installationskvalifikation indeholder detaljer som hvilke og hvor mange testmiljøer, der ville blive brugt, hvilket adgangsniveau der kræves for testerne i hvert miljø sammen med de krævede testdata. Det kan omfatte browserkompatibilitet, nødvendige værktøjer til udførelse, enheder, der kræves til test osv. Det system, der udvikles, skal installeres i overensstemmelse med brugernes krav.
  • Testdata kan være nødvendige for at teste nogle applikationer, og det skal gives af den rette person. Det er en vital forudsætning.
  • Nogle applikationer kræver muligvis en database. Vi er nødt til at holde alle nødvendige data til test klar i en database for at validere specifikationerne.

For eksempel, En ny app siger, at 'abc' skal testes i mobil (Android 4.3.1) og browser (Chrome 54). I et sådant tilfælde skal vi holde styr på følgende:

  • Kontroller, om der er givet tilladelse til at kontrollere webstedet for appen “abc”.
  • Se om de enheder, der bruges til at teste appen som mobil (android / ios), browser-Chrome, Internet Explorer med den krævede version, er tilgængelige.
  • Kontroller, om de er installeret korrekt med de angivne versioner (f.eks. Chrome 54, Android version 4.3.1).
  • Sørg for, om appen er tilgængelig i både browser og mobil.

Operationel kvalifikation

Operativ kvalifikation sikrer, at hvert modul og undermodul designet til applikationen under test fungerer korrekt, som det forventes i det ønskede miljø.

En valideringstest udføres generelt i det følgende hierarki.

Valideringstest hierarki

Funktionel test spiller en vigtig rolle i valideringstest. Det betyder simpelthen, at du er nødt til at validere applikationens funktionalitet af hvert eneste nævnte kritiske krav. Dette baner vejen for at kortlægge kravene nævnt i dokumentet Funktionsspecifikation og sikre, at produktet opfylder alle de nævnte krav.

Funktionel testning og dens typer

Som navnet antyder, funktionstestning tester funktionerne, dvs. hvad softwaren skal gøre. Softwarens funktionaliteter vil blive defineret i kravspecifikationsdokumentet.

Lad os få et hurtigt overblik over dens typer.

# 1) Enhedstest:

Enhedstestning tester de enkelte enheder / moduler / komponenter / metoder i det givne system. Feltvalidering, layoutkontrol, design osv. Testes med forskellige input efter kodning. Hver linje i koden skal valideres til de enkelte enhedstesttilfælde.

Enhedstest udføres af udviklerne selv. Omkostningerne ved at rette bugs er mindre her sammenlignet med de andre testniveauer.

Eksempel:

Evaluering af en sløjfe af koden for en funktion siger, at kønsvalg er et eksempel på enhedstest.

# 2) Black Box Testing:

Test af en applikations opførsel for de ønskede funktionaliteter i forhold til kravene uden at fokusere på de interne detaljer i systemet kaldes Black box-test. Det udføres normalt af et uafhængigt testteam eller slutbrugerne af applikationen.

Applikationen testes med relevante input og testes for at validere, hvis systemet opfører sig som ønsket. Dette kan bruges til at teste både de funktionelle såvel som ikke-funktionelle krav.

# 3) White Box Testing:

Test af hvid boks er intet andet end en detaljeret kontrol af programkoden efter kode. Hele anvendelsen af ​​applikationen afhænger af den skrevne kode, hvorfor det er nødvendigt at teste koden meget omhyggeligt. Du skal kontrollere hver enhed og dens integration som et helt modul trin for trin.

En tester med programmeringskendskab er et must-kriterium her. Dette finder tydeligt ud af, om der er nogen afvigelse i programmets workflow. Det er nyttigt for både udviklerne og testere.

# 4) Test af grå boks:

Test af grå boks er en kombination af både hvid boks og sort boks test. Delvis viden om strukturen eller koden for den enhed, der skal testes, er kendt her.

Integrationstest og dets typer

De enkelte komponenter i softwaren, der allerede er testet i enhedstest, integreres og testes sammen for at teste deres funktionalitet som helhed for at sikre dataflyden på tværs af modulerne.

Dette gøres af udviklerne selv eller af et uafhængigt testteam. Dette kan gøres, når to eller flere enheder er testet.

Top-down tilgang:

unix interviewspørgsmål til Java-udviklere

Top-down tilgang

I denne tilgang testes topenhederne først, og derefter testes enhederne på lavere niveau en efter en trinvis. Teststubber, der kan bruges, er nødvendige for at simulere de enheder på lavere niveau, der muligvis ikke er tilgængelige i de indledende faser.

Bottom-up tilgang:

Bottom-up tilgang

I denne tilgang testes bundenhederne først, integreres, og derefter testes enhederne på højere niveau. Teststubber, der kan bruges, er nødvendige for at simulere enheder på højere niveau, der muligvis ikke er tilgængelige i de indledende faser.

Systemtest og dets typer

Test af det komplette system / software kaldes systemtest. Systemet testes fuldstændigt i forhold til specifikationerne for funktionelle krav. Systemtest udføres i forhold til både de funktionelle og ikke-funktionelle krav. Black box-test foretrækkes generelt til denne type test.

# 1) Røgtest:

Når bygherrer giver build til test indledningsvis, er vi nødt til at teste build grundigt. Dette kaldes røgtest. Vi er nødt til at angive, om bygningen er i stand til yderligere test eller ej.

For at udføre validering har du brug for en ordentlig opbygning. Derfor udføres røgtest først af testteamet. Workflowet for den testede applikation skal testes enten med testcases eller uden den. Test sag, der dækker hele flowet, er nyttigt til denne test.

# 2) Sanity Testing:

Ved fornuftstest testes de vigtigste funktioner i modulerne i den applikation, der testes. Ved test af et websted, der har 3 faner, dvs. oprettelse af profil, uddannelse, login osv. I IRCTC , de vigtigste funktioner i alle disse faner skal kontrolleres uden at gå meget dybere ind.

Menuerne, undermenuerne, fanerne skal testes i alle moduler. Det er en delmængde af regressionstest, da test kun udføres af hovedstrømmen og ikke i dybden.

# 3) Regressionstest:

For hver frigivelse af projektet kan udviklingsteamet introducere visse ændringer. Validering, hvis de nye indførte ændringer ikke har påvirket systemets arbejdsgang, kaldes regressionstest. Kun visse testtilfælde, der vedrører de nye krav, skal testes her.

Ydelseskvalifikation

UAT (test af brugeraccept):

Dette er den sidste testfase, der udføres for at sikre, at systemet opfører sig som krævet svarende til de specificerede krav. Dette gøres af klienten. Når klienten certificerer og rydder systemtest, kan produktet gå til implementering.

Alfa- og betatestning:

Alpha-test udføres af udviklerne på applikationen inden frigivelse på webstedet for softwareudvikling. Det involverer test i sort og hvid boks. Betatestning udføres på kundesiden, efter at produktet er udviklet og implementeret.

Prøvevalideringstestsager eller protokol

Med min erfaring har jeg skrevet denne protokol til Gmail-login.

Dybtgående kontrol af den dækkede loginfunktionalitet er, hvad validering faktisk er. Men jeg vil gerne nævne, at den anvendte sætningskolonnes stil kan være helt forskellig og afhænger af klientens krav.

=> Download eksempler på valideringstestsager: Gmail login test sag

Konklusion

Godkendelse handler om at analysere funktionerne i et produkt i detaljer. Som valideringstester skal du altid huske at rapportere afvigelserne der og da for at opnå optimale resultater i testningen.

Enhver testsag, der er skrevet, skal være skarp, kortfattet og forståelig, selv for den almindelige mand. Valideringstesteren skal sikre, at det rigtige produkt udvikles mod de specificerede krav.

Som en guide til valideringstest har jeg dækket processen i forbindelse med validering.

Designkvalifikation, der involverer valideringsplan, installationskvalifikation, der taler om installation af hardware-software, en operationel kvalifikation, der involverer hele systemtesten, Performance-kvalifikation, der involverer test af brugeraccept, som giver godkendelse til produktion.

Håber denne artikel ville have beriget din viden om begrebet valideringstest !!

Anbefalet læsning

^