Menu

Automatiseret regressionstest: udfordringer, proces og trin

automated regression testing

Prøv Vores Instrument Til At Fjerne Problemer

Denne vejledning forklarer udfordringerne ved automatiseret regressionstest. Vi vil også lære om processen og trinene til automatisering af regressionstest:

Vi lærer, hvordan man automatiserer regressionstestsager startende fra at identificere dem, vælge et værktøj til automatisering, udføre analyse af omkostninger, tid og kræfter, skrive scripts og endelig levere det til det manuelle testteam, så de kan udføre testsagerne hvor som helst når som helst.

Hvis du undrer dig over, hvorfor kun regressionstestpakken er, fordi regressionstestpakken er den primære kandidat til automatisering, da det er et sæt testsager, der er gentagne og tidskrævende. Således ville automatisering af dem faktisk spare dig for mange ressourcer, og det ville også være mindre tidskrævende.

Du vil få hurtige rapporter om tilfælde af regressionstest, og du kan også bruge disse trin til at automatisere andre testpakker.

=> Klik her for den komplette serie af regressionstest.

Automatiseret regressionstest

Hvad du vil lære:

Automatiseret regressionstest

For nylig, da jeg ønskede at starte mit nye automatiserede testprojekt med fire ressourcer, tænkte jeg på at anvende en af ​​de agile metoder. Men jeg var ikke i stand til at fortsætte, fordi en række spørgsmål blev rejst i mit sind.

Spørgsmålene var som:

  • Er det muligt at bruge agile metoder i automatiseret test?
  • Kan jeg bruge traditionelle værktøjer?
  • Skal jeg gå efter open source-værktøjer?
  • Hvilke udfordringer skal jeg stå over for, hvis jeg implementerer automatisering i det agile miljø?

Lad os i denne artikel analysere nogle af de udfordringer, vi står over for, mens vi implementerer Automation med Agile-metoder. Automatiseret regressionstest i det agile miljø udgør en risiko for at blive kaotisk, ustruktureret og ukontrolleret.

Agile Projects præsenterer deres egne udfordringer for Automation-teamet. Agile-metoden lægger vægt på teamsamarbejde og hyppig levering af et produkt. Faktorer som uklart projektomfang, flere iterationer, minimal dokumentation, tidlige og hyppige automatiseringsbehov og aktiv involvering af interessenter osv. Kræver mange udfordringer fra Automation Team.

Automatiseret test: udfordringer i agile omgivelser

Der er flere Agile udfordringer for Automation-teamet. Imidlertid er en få af dem er beskrevet nedenfor.

Udfordring 1:Kravsfase

Test Automation-udvikler fanger kravene i form af “brugerhistorier”, som er korte beskrivelser af den kunderelevante funktionalitet.

Hvert krav skal prioriteres som følger:

Høj: Dette er missionskritiske krav, der absolut skal gøres i den første udgivelse
Medium: Dette er de krav, der er vigtige, men som kan bearbejdes, indtil de implementeres.
Lav: Dette er de krav, der er gode at have, men ikke kritiske for softwarens drift.

Når førsteprøver er etableret, planlægges frigivelses 'iterationer'. Normalt tager hver Agile release iteration mellem 1 og 3 måneder at levere. Kunder / software-folk tager friheden til at foretage for mange ændringer i kravene. Nogle gange er disse ændringer så ustabile, at gentagelserne stødes af. Disse ændringer er større udfordringer i implementeringen af ​​Agile Automation-testprocessen.

hvad er alle e-mail-siderne?

Udfordring 2:Valg af de rigtige værktøjer

Traditionelle test-sidste værktøjer med optagelses- og afspilningsfunktioner tvinger hold til at vente, indtil softwaren er færdig. Desuden fungerer traditionelle testautomationsværktøjer ikke i en Agile-kontekst, fordi de løser traditionelle problemer, der adskiller sig fra de udfordringer, Agile Automation-teams står over for.

Automatisering i de tidlige stadier af et smidigt projekt er normalt meget hårdt, men når systemet vokser og udvikler sig, afviger nogle aspekter, og det bliver passende at implementere automatisering. Så valget af testværktøjer bliver afgørende for at høste effektiviteten og kvalitetsfordelene ved agil.

Udfordring 3:Scriptudviklingsfase

Automatiseringstestere, udviklere, forretningsanalytikere og projektinteressenter bidrager samlet til kick-off-møder, hvor 'User-Stories' vælges til næste sprint. Når “User-Stories” er valgt til sprinten, bruges de som basis for et sæt tests.

Da funktionaliteten vokser med hver iteration, skal der udføres regressionstest for at sikre, at eksisterende funktionalitet ikke er blevet påvirket af introduktionen af ​​ny funktionalitet i hver iterationscyklus. Det omfanget af regressionstesten vokser med hver sprint og sikrer, at dette forbliver en håndterbar opgave, og testteamet bruger testautomatisering til regressionspakken.

Udfordring 4:Ressourcestyring

Agile-tilgangen kræver en blanding af testfærdigheder, dvs. testressourcer vil være nødvendige for at definere uklare scenarier og testcases, udføre Manuel test ved siden af ​​udviklere, skriv automatiske regressionstest og udfør de automatiserede regressionspakker.

Efterhånden som projektet skrider frem, vil der også være behov for specialkompetencer til at dække yderligere testområder, der kan omfatte integration og Performance Testing.

Der bør være en passende blanding af domænespecialister, der planlægger og samler kravene. Den udfordrende del i ressourcestyring er at finde ud af testressourcer med flere færdigheder og tildele dem.

Udfordring 5:Meddelelse

God kommunikation skal eksistere blandt Automatiseringstest team, udviklere, forretningsanalytikere og interessenter. Der skal være et stærkt samarbejde mellem klienten og leveringsteamene. Mere klientinddragelse indebærer flere forslag eller ændringer fra klienten. Og det indebærer mere båndbredde til kommunikation.

Hovedudfordringen er, at processen skal være i stand til at indfange og effektivt implementere alle ændringer, og dataintegriteten skal bevares. I traditionel test er udviklere og testere som olie og vand, men i et smidigt miljø er den udfordrende opgave, at de begge skal arbejde sammen for at nå målet.

Udfordring 6:Dagligt Scrum-møde

Daily Scrum Meeting er en af ​​nøgleaktiviteterne i Agile Processen. Hold mødes i 15 minutters stand-up-sessioner. Hvad er effektiviteten af ​​disse møder? Hvor langt disse møder hjælper automatisering med at udvikle udviklere? osv. drøftes på dette møde.

Udfordring 7:Slip fase

Formålet med Agile-projektet er at levere et grundlæggende arbejdsprodukt så hurtigt som muligt og derefter gennemgå en proces med kontinuerlig forbedring. Dette betyder, at der ikke er en enkelt frigivelsesfase for et produkt. Den udfordrende del ligger i integrationstest og acceptstest af produktet.

Trin til automatisering af regressionstest

Processen, der skal følges for at automatisere regression, kan opdeles nøjagtigt i følgende trin:

7 trin til automatisering af regressionstest

Disse 7 trin forklares detaljeret nedenfor i enkle termer for at gøre det let for dig.

1. Identifikation

Identifikation

# 1) Identificer test tilfælde som skal være en del af regressionstestpakken.

  • For at starte automatisering af regressionstestsager er den allerførste ting, du skal gøre, at få regressionstestsagerne identificeret og korrekt defineret med alle trin, data og forudsætninger.
  • For at sikre dig har du en effektiv regressionstestpakke, glem ikke at medtage:
    • Test tilfælde med tilbagevendende mangler.
    • Test sager, der dækker slut-til-slut-scenarier.
    • Test sager, der er mere synlige for slutbrugerne.
    • Test tilfælde på grænseværdier.
    • God blanding af positive og negative testsager.
    • Komplekse testsager.

#to) Identificer automatiseringsværktøjer der passer bedst til dine krav og applikationsadfærd. Når Regression-testsagerne er identificeret og klar til automatisering, skal du identificere de værktøjer, der passer bedst til dine testsager.

Den bedste måde at identificere værktøjerne på er at lave en matrix med værktøjerne og dine krav og derefter holde styr på, hvilket værktøj der opfylder hvilke krav.

Foreslået læsning => Liste over de bedste automatiseringsprøvningsværktøjer

# 3) Identificer Programmeringssprog som du vil bruge. Med så mange værktøjer, der er tilgængelige på markedet, understøttes flere sprog af disse værktøjer. Derfor er det vigtigt at identificere det programmeringssprog, som du vil skrive dine automatiseringstestsager i.

Eksempel :Lad os antage, at vi har et projekt, hvor vi vil automatisere en regressionstestsuite til en browserbaseret applikation.

Som forklaret ovenfor identificerer vi testsagerne.

  • Lad os antage, at vores testsag er 'Bekræft, at en bruger kan logge ind med et gyldigt brugernavn og en gyldig adgangskode'.

Dernæst identificerer vi automatiseringsværktøjerne.

  • En browserbaseret testsag kan automatiseres med “ Selen ',' Ranorex ”,“ TestComplete ”. Lad os beslutte Selen-værktøjet, da det bedst passer til kravene.

Lad os nu identificere et programmeringssprog.

  • Vi vil bruge ' Java ”Som programmeringssprog som et meget understøttet sprog.

2. Analyse

Analysis1

# 1) Gør Koste analyse. Det er meget vigtigt at arbejde inden for budgetgrænserne. Efter identifikationsfasen får du således en idé om, hvor mange testsager der skal automatiseres, og hvilke der er de mulige værktøjer, der kan bruges.

Alle fund fra identifikationsfasen hjælper dig med at komme med et omtrentligt budget, og du kan dermed få godkendelse osv., Hvis det kræves.

#to) Gør ressource og indsats analyse for at se, om du har ressourcerne til at arbejde på dette. Sammen med omkostningsanalysen er det meget vigtigt at foretage en ressource- og indsatsanalyse for bedre fordeling af ressourcer og bruge deres tid på projektet effektivt.

Mens du estimerer ressourcerne og indsatsen, skal du sørge for at tage højde for risici som, hvis nogen bliver syge, eller hvis nogle testsager har brug for flere ressourcer til udførelse osv.

# 3) Gør Tid Analyse. Tidsanalyse er påkrævet for at sikre, at du kan afslutte automatiseringsprojektet inden for budgettet og tidslinjerne. Mens du arbejder med tidsanalyse, vil det være nyttigt at udarbejde et tidslinjediagram til overvågning af fremskridtene under udviklingen.

For en bedre tidslinjeanalyse af projektet:

  • Identificer opgaver og underopgaver i dine projekter.
  • Prioriter opgaverne og delopgaverne.
  • Tegn et Gantt-diagram eller netværksdiagram for bedre afbildning af tidslinjen.

Eksempel :Fremadrettet med vores eksempel i betragtning fra identifikationsfasen gives forklaringen til denne fase nedenfor:

Omkostningsanalyse:

Lad os antage, at de omtrentlige omkostninger for dette projekt er $ X-beløb.

Ressource og indsats:

Til dette skal en testsag automatiseres fra ende til slut, og vi har brug for en ressource på fuld tid i ca. 24 timer, og vi har også brug for en ressource mere til at gennemgå arbejdet. Således har vi brug for 2 ressourcer, og anslaget til indsats er omkring 40 timer.

Tidsanalyse:

Lad os tegne et lille Gantt-diagram for at se tidslinjen.

gantt-diagram - Automatiseret regressionstest

3. Uddannelse / Ansættelse

# 1) Hvis nogle ressourcer kræver det uddannelse , planlæg derefter deres træning. Nogle gange har du muligvis nogle manuelle testressourcer, der er interesseret i at skrive automatiseringstestsager, eller nogle har arbejdet med automatisering, men forskellige værktøjer og er villige til at lære det værktøj, du har valgt til din automatisering.

I dette tilfælde skal du identificere disse ressourcer og planlægge deres træning, så de kan begynde at arbejde på automatisering af tilfælde af regressionstest.

#to) Hvis vi har brug for flere ressourcer, så arbejd på ansættelse plan. Når du har foretaget ressourceanalysen for indsatsen, og hvis du ikke er i stand til at tilfredsstille behovene med de allerede tilgængelige ressourcer, så planlæg at ansætte nogle nye ressourcer med de rette færdigheder, der kræves til projektet inden for budgettet.

Eksempel:

Lad os sige, at vi allerede har en ressource, der er fortrolig med Java-koncepter og ønsker at lære Selen. Så arrangerer vi selenstræning for den person.

Hvis vi ikke har nogen ressourcer til rådighed til automatisering. Derefter ansætter vi en person, der har en vis baggrund i automatisering af sådanne testsager ved hjælp af selen og java.

4. Ramme og retningslinjer

# 1) Når værktøjet og ressourcerne er klar, skal du arbejde på at komme med en ramme eller beslutte, hvilken der skal bruges fra de eksisterende rammer. Flere allerede byggede rammer kan bruges, eller du kan bygge din ramme fra bunden.

Mens du vælger eller bygger en ramme, skal du sørge for at involvere komponenterne om, testcases, logfiler, rapporter, input, databaseforbindelse osv.

#to) Beslut den anden understøttende værktøjer som du vil bruge. Da udvikling af automatiseringsscript er en udviklingsopgave, der involverer skrivning af kode, ville det være meget bedre at finde ud af de andre udviklingsværktøjer, der ville være nødvendige for at understøtte skrivning af dine scripts.

For eksempel , Nogle værktøjer, der kan være til hjælp, inkluderer git, GitHub, Jenkins osv.

# 3) Skitsere retningslinier til skrivning af automatiseringsskripter. Det er nødvendigt at skitsere retningslinjerne, så alle ressourcer, der arbejder på projektet, er synkroniseret og bruger de samme navngivningskonventioner, de samme procedurer til kodeind- / udcheckning og det samme programmeringssprog.

tegn til heltal c ++

Eksempel:

Ramme: Lad os beslutte BDD (adfærdsdrevet udvikling) ramme til automatiseringstest.

Støttende værktøjer: De værktøjer, som vi har brug for til fuldt ud at understøtte automatiseringen, vil være, GitHub, Jenkins, Log4J, Agurk og JUnit.

5. Automationsskripter

Begynd at skrive automatiseringsskripter. Når vi først har alt, dvs. værktøjet, programmeringssprog, nødvendige færdigheder og testsager, der skal automatiseres, kan vi begynde at skrive automatiseringsskripts.

Mens vi skriver manuskripter, skal vi sørge for, at:

  • Retningslinjerne følges.
  • Vi bruger værktøjerne.
  • Testcases er modulopbygget.
  • Vi skulle være i stand til at genbruge komponenterne, hvis de kræves i flere testtilfælde.

Vi skal også sørge for, at koden vedligeholdes korrekt i versionskontrolværktøjet, og at alle teammedlemmer kan samarbejde let.

Eksempel:

Lad os skrive faktiske scripts for at få denne test sag til at køre. Prøve fra scripts kan vises som nedenfor.

For det første ville agurkscenariet for denne test sag se ud som nedenfor:

Funktion: Bekræft login-funktionalitet
Som bruger vil jeg logge ind på applikationen
Scenariooversigt: Log ind på applikationen
Da jeg åbner ansøgning
Når jeg indtaster brugernavn “”
Og jeg indtaster adgangskoden “”
Og jeg klikker på knappen Login
Så går jeg til startsiden

Eksempler:
| brugernavn | adgangskode |
| testbruger1 | adgangskode1 |
| testbruger2 | adgangskode2 |

Efter funktionsfilen implementerer vi trindefinitionen for de trin, der er nævnt i funktionsfilen.

public class Login { LoginImpl loginImpl = new LoginImpl(); @Given('^I open application$') public void i_open_application() { loginImpl.openURL('URL'); } @When('^I Enter username '((^')*)'$') public void i_Enter_username(String arg1) { loginImpl.enterUserName(arg1); } @When('^I Enter password '((^')*)'$') public void i_Enter_password(String arg1) { loginImpl.enterPassword(arg1); } @When('^I click on Login button$') public void i_click_on_Login_button() { loginImpl.clickLoginButton(); } @Then('^I go to Home page$') public void i_go_to_Home_page() { loginImpl.verifyHomePage(); } }

I sidste ende vil den faktiske implementering af login-funktionsklassen se ud som nedenfor:

public class LoginImpl { WebDriver driver; public LoginImpl(){ System.setProperty('webdriver.chrome.driver', 'webdriver/chromedriver.exe'); driver = new ChromeDriver(); } public void openURL(String string) { driver.get(string); } public void enterUserName(String arg1) { driver.findElement(By.id('UserName')).sendKeys(arg1); } public void enterPassword(String arg1) { driver.findElement(By.id('Password')).sendKeys(arg1); } public void clickLoginButton() { driver.findElement(By.id('LoginButton')).click(); } public void verifyHomePage() { String currUrl = driver.getCurrentUrl(); if(currUrl.equals('homePageURL')) { System.out.println('Home page verified'); } } }

6. Gennemgang

Anmeldelse

(billede kilde )

# 1) Kodeanmeldelse: Når en automatiseringsudvikler er færdig med at skrive automatiseringsskripter, er det meget vigtigt at gennemgå de forskellige niveauer af kodegennemgang.

Kodevurderinger hjælper med

  1. Identificering af forkerte verifikationer.
  2. Find kodeoptimeringspunkter.
  3. Finde bedre måder til at implementere funktionaliteten til effektiv ressourceudnyttelse.

Kodevurderinger udsætter også en udviklers arbejde for de andre udviklere og giver det også et andet perspektiv og plads til forbedringer.

# 2) Gennemgang af testsager: Sammen med kodevurderingen er test case review også meget vigtig. Vi er nødt til at sikre os, at automatiseringstestscriptene, når de udføres, udfører det samme sæt handlinger og verifikationer, som vi forventer af de manuelle testsager.

Gennemgang af automatiseringstestsagerne med forretningsanalytikere eller testeksperter hjælper således med at øge tilliden til automatiseringstest af disse testsager.

Eksempel:

Lad os sige til vores eksempel i betragtning til kodegennemgang, at vi fik kommentarer som 'søgeelement efter id og ikke navn'. Her tager vi højde for dette og ændrer vores script i overensstemmelse hermed.

Der kan også foretages en testanmeldelse for at tilføje trin til testning, hvis du er på hjemmesiden efter et vellykket login. Derefter vil vi også tilføje dette til vores scripts.

7. Lever

Lever testsagerne, så enhver kan køre dem når som helst. Når automatiseringsskripterne er klar til brug, er det meget vigtigt at komme med en leveringsplan for automatiseringsskripterne.

Denne plan er påkrævet, da vi ønsker at sikre, at automatisering af testsagerne ikke begrænser dens udførelse til et specifikt sæt mennesker eller færdigheder. Alle i teamet eller projektet skal have lov til at udføre testsagerne.

En af de mulige leveringsplaner er at give et Jenkins-job, der kan udløses til at udføre de automatiserede testsager.

Eksempel:

Lad os i vores tilfælde antage, at vi har leveret testsagen ved hjælp af et Jenkins-job. Dette Jenkins-job tager koden fra GitHub, bygger den og kører testcases på en anden maskine.

Når jobbet er vellykket, viser det dig den genererede testrapport. Enhver, der har adgang til Jenkins, kan køre dette job. Dette job kan også planlægges kørt på et bestemt tidspunkt.

Konklusion

Hvis vi kan imødegå disse udfordringer på en veloptimeret måde, er automatiseret regressionstest i det agile miljø en fremragende mulighed for kvalitetsstyrelsen at tage ledelsen af ​​de agile processer. Det er bedre placeret til at bygge bro mellem brugerne og udviklerne, forstå, hvad der kræves, hvordan det kan opnås, og hvordan det kan sikres inden implementering.

Automatiseringspraksis skal have en interesse i begge, resultatet, såvel som fortsat at sikre, at hele det udviklende system opfylder forretningsmål og er egnet til formålet.

Automatisering af en regressionstestsag er altid nyttigt, da det er den bedste kandidat til start automatiseringstest . Du kan følge ovenstående trin for at automatisere enhver testpakke og ikke kun regression.

Automatiseringstest er også meget nyttigt og omkostningseffektivt, og den tid, investering i automatiseringstestning kun er i at skrive scripts og vedligeholde dem. Således skal automatiseringstest planlægges ordentligt og planlægges til et vellykket projekt.

Om forfatteren: J.B. Rajkumar har mere end 15 års erfaring inden for både akademiske og softwaretest. Han har arbejdet som Corporate Trainer, Test Lead, QA Manager og QC Manager.

Fortæl os dine kommentarer / forslag til denne artikel.

=> Besøg her for den komplette regressionstestserie.

Anbefalet læsning

^