Meny

Automatisert regresjonstesting: utfordringer, prosesser og trinn

automated regression testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne veiledningen forklarer utfordringene ved automatisert regresjonstesting. Vi vil også lære om prosessen og trinnene for å automatisere regresjonstesting:

Vi vil lære å automatisere regresjonstesttilfellene fra å identifisere dem, velge et verktøy for å gjøre automatiseringen, gjøre kostnad-, tid- og innsatsanalyse, skrive manus og til slutt levere det til det manuelle testteamet slik at de kan utføre testsakene. hvor som helst når som helst.

Hvis du lurer på hvorfor bare regresjonstestpakken, er det fordi regresjonstestpakken er den viktigste kandidaten for automatisering, da det er settet med testsaker som er repeterende og tar tid. Dermed ville automatisering av dem faktisk spare deg for mange ressurser, og det ville også være mindre tidkrevende.

Du vil få raske rapporter om regresjonstesttilfellene, og du kan bruke disse trinnene til å automatisere andre testpakker også.

=> Klikk her for den komplette serien for regresjonstesting.

Automatisert regresjonstesting

Hva du vil lære:

Automatisert regresjonstesting

Nylig, da jeg ønsket å starte mitt nye automatiserte testprosjekt med fire ressurser, tenkte jeg å bruke en av de smidige metodene. Men jeg klarte ikke å fortsette fordi en serie spørsmål ble reist i tankene mine.

Spørsmålene var som:

  • Er det mulig å bruke smidige metoder i automatisert testing?
  • Kan jeg bruke tradisjonelle verktøy?
  • Skal jeg måtte gå etter verktøy med åpen kildekode?
  • Hva er utfordringene jeg må møte hvis jeg implementerer automatisering i det smidige miljøet?

La oss i denne artikkelen analysere noen av utfordringene vi møter når vi implementerer Automation med Agile-metoder. Automatisert regresjonstesting i det smidige miljøet står som en risiko for å bli kaotisk, ustrukturert og ukontrollert.

Agile Projects presenterer sine egne utfordringer for Automation-teamet. Agile-metoden legger vekt på teamsamarbeid og hyppig levering av et produkt. Faktorer som uklart prosjektomfang, flere iterasjoner, minimal dokumentasjon, tidlige og hyppige automatiseringsbehov og aktiv involvering av interessenter, etc., krever mange utfordringer fra automatiseringsteamet.

Automatisert testing: utfordringer i smidig miljø

Det er flere smidige utfordringer for Automation-teamet. Imidlertid a noen av dem er orientert nedenfor.

Utfordring 1:Kravsfase

Test Automation-utvikler fanger opp kravene i form av “brukerhistorier”, som er korte beskrivelser av den kunderelevante funksjonaliteten.

Hvert krav må prioriteres som følger:

Høy: Dette er oppdragskritiske krav som absolutt må gjøres i den første utgivelsen
Medium: Dette er kravene som er viktige, men som kan bearbeides til de er implementert.
Lav: Dette er kravene som er fine å ha, men ikke kritiske for driften av programvaren.

Når priorier er etablert, planlegges utgivelsen 'iterasjoner'. Normalt tar hver Agile release iteration mellom 1 til 3 måneder å levere. Kunde / programvare folk tar friheten til å gjøre for mange endringer i kravene. Noen ganger er disse endringene så ustabile at gjentakelsene blir støtet av. Disse endringene er større utfordringer i implementeringen av Agile Automation-testprosessen.

hva er et beslutningstreet i data mining

Utfordring 2:Velge riktig verktøy

Tradisjonelle, test-siste verktøy med innspillings- og avspillingsfunksjoner tvinger teamene til å vente til etter at programvaren er ferdig. Dessuten fungerer tradisjonelle testautomatiseringsverktøy ikke for en smidig kontekst fordi de løser tradisjonelle problemer som er forskjellige fra utfordringene Agile Automation-team står overfor.

Automatisering i de tidlige stadiene av et smidig prosjekt er vanligvis veldig tøft, men når systemet vokser og utvikler seg, blir noen aspekter avgjort, og det blir hensiktsmessig å distribuere automatisering. Så valget av testverktøy blir viktig for å høste effektiviteten og kvalitetsfordelene med smidig.

Utfordring 3:Skriptutviklingsfase

Automasjonstestere, utviklere, forretningsanalytikere og prosjektinteressenter bidrar helt til startmøter der 'User-Stories' velges ut til neste sprint. Når “User-Stories” er valgt for sprinten, blir de brukt som grunnlag for et sett med tester.

Ettersom funksjonaliteten vokser med hver iterasjon, må regresjonstesting utføres for å sikre at eksisterende funksjonalitet ikke har blitt påvirket av innføringen av ny funksjonalitet i hver iterasjonssyklus. De omfanget av regresjonstestingen vokser med hver sprint og sørger for at dette forblir en håndterbar oppgave, og testteamet bruker testautomatiseringen til regresjonspakken.

Utfordring 4:Ressursforvaltning

Den smidige tilnærmingen krever en blanding av testferdigheter, det vil si at testressurser vil være nødvendig for å definere uklare scenarier og tester, gjennomføre Manuell testing sammen med utviklere, skriv automatiserte regresjonstester og utfør automatiserte regresjonspakker.

Etter hvert som prosjektet utvikler seg, vil det også være behov for spesialistiske ferdigheter for å dekke ytterligere testområder som kan omfatte integrering og ytelsestesting.

Det bør være en passende blanding av domenespesialister som planlegger og samler kravene. Den utfordrende delen i ressursadministrasjon er å finne ut testressurser med flere ferdigheter og tildele dem.

Utfordring 5:Kommunikasjon

God kommunikasjon må eksistere blant Automatiseringstesting team, utviklere, forretningsanalytikere og interessenter. Det må være et svært samarbeidende samspill mellom klienten og leveringsteamene. Mer klientengasjement innebærer flere forslag eller endringer fra klienten. Og det innebærer mer båndbredde for kommunikasjon.

Hovedutfordringen er at prosessen skal kunne fange opp og effektivt implementere alle endringene og dataintegriteten må beholdes. I tradisjonell testing er utviklere og testere som olje og vann, men i et smidig miljø er den utfordrende oppgaven at de begge må samarbeide for å nå målet.

Utfordring 6:Daglig Scrum Meeting

Daily Scrum Meeting er en av nøkkelaktivitetene i den smidige prosessen. Lag møtes i 15 minutter på stand-up-økter. Hva er effektiviteten til disse møtene? Hvor langt disse møtene hjelper automatisering med å utvikle utviklere? osv., blir diskutert på dette møtet.

Utfordring 7:Utgivelsesfase

Målet med Agile-prosjektet er å levere et grunnleggende arbeidsprodukt så raskt som mulig, og deretter gjennomgå en prosess med kontinuerlig forbedring. Dette betyr at det ikke er en enkelt frigjøringsfase for et produkt. Den utfordrende delen ligger i integrasjonstesting og godkjenningstesting av produktet.

Fremgangsmåte for å automatisere regresjonstesting

Prosessen som skal følges for å automatisere regresjon kan deles nøyaktig i følgende trinn:

7 trinn for å automatisere regresjonstesting

Disse 7 trinnene er forklart i detalj i enkle termer for enkel forståelse.

1. Identifikasjon

Identifikasjon

#1) Identifiser test tilfeller som skal være en del av regresjonstestpakken.

  • For å begynne å automatisere tilfeller med regresjonstest, er det aller første du trenger å gjøre å få regresjonstesttilfellene identifisert og riktig definert med alle trinn, data og forutsetninger.
  • For å være sikker på at du har en effektiv regresjonstestpakke, ikke glem å ta med:
    • Test tilfeller med gjentatte feil.
    • Test tilfeller som dekker slutt-til-slutt-scenarier.
    • Test tilfeller som er mer synlige for sluttbrukerne.
    • Test tilfeller på grenseverdier.
    • God blanding av positive og negative testsaker.
    • Komplekse testsaker.

#to) Identifiser automatiseringsverktøy som er best for dine krav og applikasjonsatferd. Når regresjonstesttilfellene er identifisert og klar for automatisering, kan du identifisere verktøyene som passer best til testtilfellene dine.

Den beste måten å identifisere verktøyene på er å lage en matrise med verktøyene og kravene dine, og deretter holde oversikt over hvilket verktøy som tilfredsstiller hvilke krav.

Foreslått lesing => Liste over de beste testverktøyene for automatisering

# 3) Identifiser Programmeringsspråk som du vil bruke. Med så mange verktøy som er tilgjengelige i markedet, støttes flere språk av disse verktøyene. Derfor er det viktig å identifisere programmeringsspråket du vil skrive automatiseringsprøvesakene dine på.

Eksempel :La oss anta at vi har et prosjekt der vi vil automatisere en regresjonstestpakke for en nettleserbasert applikasjon.

Som forklart ovenfor, vil vi identifisere testtilfellene.

  • La oss anta at testsaken vår er 'Bekreft at en bruker kan logge på med et gyldig brukernavn og passord'.

Deretter vil vi identifisere automatiseringsverktøyene.

  • En nettleserbasert testsak kan automatiseres med “ Selen ',' Ranorex ”,“ TestComplete ”. La oss bestemme Selen-verktøyet slik det passer best til kravene.

La oss nå identifisere et programmeringsspråk.

  • Vi ønsker å bruke “ Java ”Som programmeringsspråk som et høyt støttet språk.

2. Analyse

Analyse1

#1) Gjøre Koste analyse. Det er veldig viktig å jobbe innenfor budsjettgrensene. Dermed vil du etter identifikasjonsfasen få en ide om hvor mange testsaker som må automatiseres og hvilke mulige verktøy som kan brukes.

Alle funnene fra identifikasjonsfasen vil hjelpe deg med å komme med et omtrentlig budsjett, og dermed kan du få godkjenning osv. Hvis nødvendig.

#to) Gjøre ressurs og innsats analyse for å se om du har ressurser til å jobbe med dette. I tillegg til kostnadsanalysen er det veldig viktig å gjøre en ressurs- og innsatsanalyse for bedre ressursallokering og bruke tiden sin på prosjektet effektivt.

Når du estimerer ressursene og innsatsen, må du sørge for å redegjøre for risikoer, som om noen blir syke, eller hvis noen testtilfeller trenger flere ressurser for utførelse, etc.

# 3) Gjøre Tid Analyse. Tidsanalyse er nødvendig for å sikre at du kan fullføre automatiseringsprosjektet innenfor budsjett og tidslinjer. Mens du arbeider med tidsanalyse, vil det være nyttig å utarbeide et tidslinjediagram for å overvåke fremdriften under utviklingen.

For en bedre tidslinjeanalyse av prosjektet:

  • Identifiser oppgavene og deloppgavene i prosjektene dine.
  • Prioriter oppgavene og deloppgavene.
  • Tegn et Gantt-diagram eller nettverksdiagram for bedre bilder av tidslinjen.

Eksempel :Fremover med vårt eksempel i betraktning fra identifikasjonsfasen, er forklaringen på denne fasen gitt nedenfor:

Kostnadsanalyse:

La oss anta at den omtrentlige kostnaden for dette prosjektet er $ X beløp.

Ressurs og innsats:

For dette må en prøvesak automatiseres fra ende til annen, og vi trenger en ressurs på heltid i ca. 24 timer, og vi trenger også en ressurs til for å gjennomgå arbeidet. Dermed trenger vi to ressurser og anslagsestimatet er rundt 40 timer.

Tidsanalyse:

For dette la oss tegne et lite Gantt-diagram for å se tidslinjen.

gantt-diagram - Automatisert regresjonstesting

3. Trening / Ansettelse

#1) Hvis noen ressurser krever opplæring , planlegg deretter treningen. Noen ganger kan du ha noen manuelle testressurser som er interessert i å skrive automatiseringstestsaker, eller noen har jobbet med automatisering, men forskjellige verktøy, og er villige til å lære verktøyet du har valgt for automatiseringen.

I dette tilfellet, identifiser disse ressursene og planlegg for opplæringen slik at de kan begynne å jobbe med automatisering av tilfeller med regresjonstest.

#to) Hvis vi trenger flere ressurser, så arbeid på ansettelse plan. Når du har gjort ressursanalysen for innsatsen, og hvis du ikke er i stand til å tilfredsstille behovene med de allerede tilgjengelige ressursene, planlegger du å ansette noen nye ressurser med riktig kompetanse som kreves for prosjektet innenfor budsjettet.

Eksempel:

La oss si at vi allerede har en ressurs som er kjent med Java-konsepter og ønsker å lære Selen. Så ordner vi selenstrening for vedkommende.

Hvis vi ikke har noen ressurser tilgjengelig for automatisering. Deretter ansetter vi en person som har litt bakgrunn i å automatisere slike testsaker ved bruk av selen og java.

4. Rammeverk og retningslinjer

#1) Når verktøyet og ressursene er klare, kan du arbeide med å komme med en rammeverk eller bestemme hvilken som skal brukes fra eksisterende rammer. Flere allerede bygde rammer kan brukes, eller du kan bygge rammeverket ditt fra bunnen av.

Mens du velger eller bygger et rammeverk, må du sørge for at du involverer komponentene om, testtilfeller, logger, rapporter, input, databasetilkobling, etc.

#to) Bestem deg for den andre støtteverktøy som du vil bruke. Ettersom å utvikle automatiseringsskript er en utviklingsoppgave som innebærer å skrive kode, ville det være mye bedre å finne ut de andre utviklingsverktøyene som vil være nødvendige for å støtte å skrive manusene dine.

For eksempel , Noen verktøy som kan være til hjelp inkluderer git, GitHub, Jenkins, etc.

# 3) Skissere retningslinjer for å skrive automatiseringsskript. Det er nødvendig å skissere retningslinjene slik at alle ressursene som arbeider med prosjektet er synkronisert og bruker de samme navnekonvensjonene, de samme prosedyrene for kodeinnsjekking / utsjekking og samme programmeringsspråk.

beste gratis programvare for å øke hastigheten på pc

Eksempel:

Rammeverk: La oss bestemme oss for BDD (atferdsdrevet utvikling) rammeverk for automatiseringstesting.

Støtteverktøy: Verktøyene vi trenger for å støtte automatiseringen fullt ut vil være, GitHub, Jenkins, Log4J, Cucumber og JUnit.

5. Automatiseringsskript

Begynn å skrive automatiseringsskript. Når vi har alt, dvs. verktøyet, programmeringsspråk, nødvendige ferdigheter og testtilfeller som må automatiseres, kan vi begynne å skrive automatiseringsskript.

Mens vi skriver manus, må vi sørge for at:

  • Retningslinjene følges.
  • Vi bruker verktøyene.
  • Testtilfellene er modulert.
  • Vi skal kunne bruke komponentene hvis de er nødvendige i flere testtilfeller.

Vi må også sørge for at koden blir riktig vedlikeholdt i versjonskontrollverktøyet, og at alle teammedlemmene enkelt kan samarbeide.

Eksempel:

La oss skrive faktiske skript for å få denne testsaken til å kjøre. Eksempel fra manusene kan vises som nedenfor.

For det første vil agurkscenariet for denne testsaken se ut som nedenfor:

Funksjon: Bekreft påloggingsfunksjonalitet
Som bruker vil jeg logge på applikasjonen
Scenariooversikt: Logg inn på applikasjonen
Gitt at jeg åpner søknaden
Når jeg skriver inn brukernavn “”
Og jeg skriver inn passord “”
Og jeg klikker på Logg inn-knappen
Så går jeg til hjemmesiden

Eksempler:
| brukernavn | passord |
| testbruker1 | passord1 |
| testbruker2 | passord2 |

Etter funksjonsfilen vil vi implementere trinndefinisjonen for trinnene som er nevnt i funksjonsfilen.

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(); } }

Til slutt vil den faktiske implementeringen av påloggingsfunksjonalitetsklassen se ut 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. Gjennomgang

Anmeldelse

(bilde kilde )

# 1) Kodevurdering: Når en automatiseringsutvikler er ferdig med å skrive automatiseringsskript, er det veldig viktig å gå gjennom de forskjellige nivåene av kodegjennomgang.

Kodevurderinger hjelper i

  1. Identifisere feil bekreftelser.
  2. Finne kodeoptimaliseringspunkter.
  3. Finne bedre måter å implementere funksjonaliteten for effektiv ressursbruk.

Kodevurderinger utsetter også utviklerens arbeid for de andre utviklerne og gir det et annet perspektiv og forbedringsrom.

2) Gjennomgang av testsaker: Sammen med kodegjennomgangen er også test case case review veldig viktig. Vi må sørge for at automatiseringstestskriptene når de kjøres, utfører samme sett med handlinger og verifikasjoner som vi forventer fra manuelle testtilfeller.

Dermed kan gjennomgang av automatiseringstestsaker med forretningsanalytikere eller testeksperter bidra til å øke tilliten til automatiseringstesting av disse testsakene.

Eksempel:

For vårt eksempel i betraktning, la oss si at for kodegjennomgang fikk vi kommentarer som 'søkeelement etter ID og ikke navn'. Her tar vi hensyn til dette og endrer skriptet vårt deretter.

Det kan også gjøres en testanmeldelse for å legge til trinn for testing hvis du er på hjemmesiden etter en vellykket pålogging. Deretter vil vi også legge til dette i skriptene våre.

7. Lever

Lever testtilfellene, slik at hvem som helst kan kjøre dem når som helst. Når automatiseringsskriptene er klare til bruk, er det veldig viktig å komme med en leveringsplan for automatiseringsskriptene.

Denne planen er påkrevd ettersom vi ønsker å sørge for at automatisering av testsakene ikke begrenser utførelsen til et bestemt sett med mennesker eller ferdigheter. Alle i teamet eller prosjektet skal ha lov til å utføre testsakene.

En av de mulige leveringsplanene er å gi en Jenkins-jobb som kan utløses for å utføre de automatiserte testsakene.

Eksempel:

La oss i vårt tilfelle anta at vi har levert testsaken ved hjelp av en Jenkins-jobb. Denne Jenkins-jobben tar koden fra GitHub, bygger den og kjører testsakene på en annen maskin.

Når jobben er vellykket, viser den deg den genererte testrapporten. Alle som har tilgang til Jenkins kan kjøre denne jobben. Også denne jobben kan planlegges å kjøre på et bestemt tidspunkt.

Konklusjon

Hvis vi kan møte disse utfordringene på en godt optimalisert måte, er automatisert regresjonstesting i det smidige miljøet en utmerket mulighet for QA til å ta ledelse av de smidige prosessene. Det er bedre plassert for å bygge bro over gapet mellom brukerne og utviklerne, forstå hva som kreves, hvordan det kan oppnås og hvordan det kan sikres før distribusjon.

Automatiseringspraksis bør ha en egeninteresse i begge deler, resultatet, samt å fortsette å forsikre at hele systemet som utvikler seg, oppfyller forretningsmålene og er egnet for formålet.

Å automatisere en regresjonstest er alltid nyttig, da den er den beste kandidaten for å starte automatiseringstesting . Du kan følge trinnene nevnt ovenfor for å automatisere en hvilken som helst testpakke og ikke bare regresjonen.

Automatiseringstesting er også veldig nyttig og kostnadseffektivt, og tidsinvesteringene i automatiseringstesting er bare å skrive manus og vedlikeholde dem. Dermed må automatiseringstesting planlegges riktig og planlegges for et vellykket prosjekt.

Om forfatteren: J.B. Rajkumar har mer enn 15 års erfaring innen både akademikk og programvaretesting. Han har jobbet som Corporate Trainer, Test Lead, QA Manager og QC Manager.

Gi oss beskjed om dine kommentarer / forslag til denne artikkelen.

=> Besøk her for den komplette serien for regresjonstesting.

Anbefalt lesing

^