Menu

Trin for trin vejledning til implementering af bevis for koncept (POC) i automatiseringstest

step step guide implement proof concept automation testing

Prøv Vores Instrument Til At Fjerne Problemer

Hvordan implementeres bevis for koncept (POC) i automatiseringstest?

Hver organisation har forskellige testprocesser og procedurer. Manuel test er vigtig og uerstattelig - dog er automatisering plukkehastighed.

Introduktion til automatiseringstest til en organisation er en udfordring, og følgende punkter vil afgøre, om det overhovedet er nødvendigt:

Automatiseringstest bevis for koncept poc

# 1 . Projektets varighed: Kortsigtede eller langsigtede - langsigtede projekter er gode kandidater til automatisering

#to. Hvor meget regression sker der i hver testcyklus ? - projekter, der har gentagne og lange regressionstest, da automatisering reducerer den samlede testtid og sikrer fuld dækning.

# 3. Ansøgningens stabilitet: Anvendelse, der ikke er modtagelig for hyppige ændringer, bør overvejes til automatisering. Det produkt, der ikke er stabilt, hvor GUI / funktionalitet fortsætter med at ændre sig, elementer eller dets XPath på side bliver ved med at ændre sig, bør ikke automatiseres, før det er stabilt.

sql forespørgsler til praksis med svar

# 4. Er projektdataene sikre, og kræver testingen nogle komplicerede procedurer? - I dette tilfælde er det bedst at gå til manuel test.

# 5. Gør det organisation har et budget til automatisering? - Automatisering vil tilføje yderligere udgifter til organisationen som omkostninger til automatiseringsværktøj, ressourceomkostninger, en tid, der kræves til rammeudvikling og skrivning / vedligeholdelse af automatiseringstestskripter.

Med automatisering vil manglende tests eller tage nogle testresultater for givet aldrig ske. Det sikrer 100% dækning af det givne modul hver gang det samme testes. Automatisering hjælper også med at udføre den samme test flere gange på flere browsere og platforme.

Følgende figur hjælper med at forstå processen med automatiseringstest

Process for automatiseringstest

Fra det tekniske testperspektiv er QA-teamet skal forstå følgende aspekter om deres automatiseringsværktøj:

  1. Platforms- og OS-testmatrix
  2. Datadrevet kapacitet
  3. Rapporteringskapacitet og rapportportabilitet
  4. Nem fejlretning og logning
  5. Versionskontrol understøttet
  6. Kan udvides og tilpasses (kan integreres med andre værktøjer som Ant, TestNG)
  7. Kontinuerlig integration.
  8. E-mail-meddelelser (Brugerdefineret e-mail-besked modtaget, hvis test er bestået / mislykkedes / eller enhver netværksfejl)
  9. Hvis der kræves test på tværs af browsere og test af flere platforme, understøttes distribueret testmiljø eller ej.

Hvad du lærer:

Valg af korrekt automatiseringsværktøj:

Valg af korrekt automatiseringsværktøj

# 1. En applikation, der testes, er en webapplikation eller en desktopapplikation.
#to. Valg af et open source-værktøj Vs betalt en.
# 3. Værktøjet skal opfylde applikationens testkrav
# 4. Brug af værktøjet - holdets ekspertise og komfortniveau med hensyn til brug og indlæring af værktøjerne
# 5. Understøtter det rapportering - Hvis nej hvilke andre rapporteringsmuligheder er tilgængelige (open source eller betalt). Hvis ja, hvor godt det er med hensyn til at formidle korrekte data fra præsentationer såvel som indholdssynspunkt.

Læs også => A til Z-vejledningen om valg af det bedste automatiseringsværktøj

Derudover inkluderer værktøjsevaluering:

Mens du vælger et automatiseringsværktøj, er det meget vigtigt at overveje, om det understøttes af applikations-GUI-implementeringen.

  1. GUI implementeres ved hjælp af traditionel HTML eller AJAX eller et andet værktøj til webudvikling
  2. Omfatter GUI videoer, billeder eller meget skrevet indhold?
  3. Det er interaktivt eller kun informativt
  4. Browsere skal testes .

Det er vigtigt at vurdere værktøjet på ovenstående punkter for at forstå, om værktøjet virkelig opfylder projektets testkrav.

Udvikling af bevis for koncept om automatisering:

Implementering af en automatiseringstest POC er en vigtig og oftest anvendt metode til at introducere et værktøj til en organisation. Når det er besluttet, at automatisering skal udføres, og et værktøj er valgt, er det tid til at oprette en prototype som en POC og præsentere den for ledelsen for at fremvise realtidsbrug og fordele.

For at gøre det:

1) Afgør testsagerne som vi vil bruge i POC.
to) Det hjælper med at vælge de områder, som kunderne vil være mest interesserede i.
3) Planlæg at vise manuel vs automatisering på en måde, der beviser, at der ikke er nogen forringelse af kvaliteten ved at vælge automatisering.
4) Inkluder en test sag, der mislykkes, og resulterer i at finde en defekt - dette hjælper med at forstærke, at værktøjet virkelig kan finde mangler
5) Brug påstande og valideringspunkter, hvor det er nødvendigt.
6) Vis tydeligt områder, der kan og ikke kan automatiseres. Normalt kan følgende aspekter ikke automatiseres:

  • Video dampes
  • Flash-indhold (ikke-statisk indhold)
  • Ikke-statiske billeder

7) Fremhæv, hvis værktøjet opfylder følgende krav?

  • Kan det automatisere alle nøglefunktionerne i den ønskede applikation
  • Er automatisering mulig i den samme browser, som projektet kræver
  • Vil automatisering kræve ændringer i implementering af applikationer? (som for automatisering er det vigtigt, at elementidentifikatorer er unikke og ikke ændres hver gang siden påkaldes)

Resultatet af POC-det er normalt et af følgende:

  1. Værktøjer opfylder projektkravene - Træn yderligere detaljer. Såsom omkostninger ved implementering - det er nødvendigt at forhandle priser, færdiggøre licensafgifter, uddannelses- og supportomkostninger, konsultation og implementeringsudgifter osv. I tilfælde af open source bestemmer værktøjer værktøjets modenhed, tilgængelige læringsressourcer, læringskurve, tilgængelig support osv. For både licenserede og open source-værktøjer skal vedligeholdelsesomkostninger også overvejes. Det skal huskes, at fordelene kun er betydelige over en lang periode.
  2. Værktøjet opfylder ikke kravene og har begrænsninger - værktøjet tages ikke længere i betragtning.
  3. Værktøjet opfylder delvist kravene - besøg igen og kontroller, om en anden opfylder kravene bedre ELLER hvis automatisering er helt ude af billedet ELLER hvis der er nogen anden løsning med det samme værktøj.

Når vi først har præsenteret vores bevis for koncept for ledelsen, og vi får klarsignal fra dem, er det næste trin at implementere et pilotprojekt ved hjælp af dette værktøj.

fordele og ulemper ved Linux vs Windows

POC-skabelon:

Der er ingen perfekt POC-skabelon. Det inkluderer generelt:

  1. Krav til POC
  2. Kandidater til POC (alle automatiseringsværktøjer)
  3. Projektkrav
  4. Fordele og ulemper ved hvert værktøj baseret på projektkravene
  5. POC-resultat

Her er et par Automation POC-skabeloner til reference:

help desk interview spørgsmål og svar

=> POC-skabelon 1
=> POC-skabelon 2

Implementering af et pilotprojekt:

Vi bør definere vores pilotprojekt ved at:

  • Kvantificering af forretningssager, der afgør, om vi skal bruge dette værktøj eller ej.
  • Definer navngivningskonvention og forskellige retningslinjer for applikationsværktøj.
  • Fordele ved et værktøj som finansielt og andet, hvad der kan gøres, og hvad der ikke kan gøres, og også dets mulige løsninger.

Trin 1. Valg af testsager til pilot

  • Moduler / funktioner vigtige set fra klientperspektiv
  • Funktionalitet let at demonstrere (lykkelig vej ende til ende)
  • Testtilfælde, der er vanskelige at teste manuelt, og når de er automatiseret, bliver det lettere at teste dem
  • Brudt funktionalitet til at demonstrere, hvordan automatisering kan hjælpe med at identificere mislykket testtilfælde

Trin 2. Automatiseringsramme udvikling

En testautomatiseringsramme er sæt af begreber, proces, procedurer, praksis og miljø. Det er intet andet end et integreret system, der består af regler til automatisering af et givet produkt. Dette system inkluderer sæt funktionelle biblioteker, API'er, testdata, objektlager og forskellige andre moduler. Rammen og tilgangen til scripting, der bruges til testautomatisering, har indflydelse på dens omkostninger.

Følgende scriptingteknikker kan bruges:

  • Lineær
  • Hybrid
  • Datadrevet
  • Søgeordsdrevet og
  • Struktureret

Ved hjælp af en af ​​ovenstående teknikker kan der designes en testramme, der hjælper med at opnå et specifikt format til at køre testen, forenkle testudførelse og rapportering.

Bestem skabeloner, navngivningskonventioner til objekter, testtilfælde, testpakker, datalager osv.

Trin # 3. Script udvikling og udførelse

Trin # 4. Rapportering: Har værktøjet indbyggede rapporteringsfunktioner? Er de indbyggede rapporter i stand til at formidle alle de krævede oplysninger præcist? Har vi brug for et andet værktøj til rapporteringsformål som krystalrapporter, reportNG osv.?

Trin # 5 . Vedligeholdelse af automatiseringsskripter

Præsentation for interessenterne:

Så meget som bevis på koncept og implementering af en pilot er vigtigt, så er det at præsentere det på den rigtige måde. Følgende punkter hjælper med at præsentere det på en positiv måde.

  1. Begynd med, hvor meget manuel testindsats der lægges i hver testcyklus, udfordringer, der står over for under manuel test, og hvordan kan vi bruge automatisering til at overvinde dem.
  2. Forklar, hvordan du valgte værktøjet baseret på beviset for konceptet
  3. Fremhæv funktioner i automatiseringsværktøjet, og hvordan det supplerer testkravene
  4. Mens du kører igennem automatiseringen, skal du forklare, hvordan automatiseringsværktøjet ikke kun hjælper med hurtigere testudførelse, men også dets evne til at udføre verifikation og fejlidentifikation.
  5. Demonstrer, hvordan rapporten viser status for eksekvering af testsag
  6. Fremhæv rapporteringsfunktioner som farverige legender til forskellige testsagestatus, snapshots af mislykkede testsager og rapportportabilitet
  7. Og endelig vis, hvor meget testtid der reduceres for hver testcyklus.
  8. Forklar også, hvordan du er i stand til at opnå hele den automatiseringsramme, du har udviklet, og dens fordele med hensyn til brug og vedligeholdelse.

Vær forberedt på at besvare spørgsmål relateret til hvor lang tid det tager at automatisere en enkelt enkel eller kritisk funktionalitet. Også, hvis der sker en mindre ændring på applikationsfronten, hvor mange scriptændringer der kræves, hvor meget tid der skal bruges til at ændre.

Vi håber, at denne guide er nyttig for dig at begynde at skrive et automatiseret test-POC-dokument. Fortæl os, hvis du har spørgsmål.

Anbefalet læsning

^