Menu

Kontinuerlig test i DevOps

continuous testing devops

Prøv Vores Instrument Til At Fjerne Problemer

Hvad er kontinuerlig test og kontinuerlig testrørledning i DevOps?

Håber, at I alle nød den sidste tutorial om Kontinuerlig implementering i DevOps .

Vi ved vigtigheden af ​​at teste i enhver softwarelevering, og DevOps er en kort leverancecyklus, det er umuligt at køre alle de designede testtilfælde hver gang manuelt, når en enkelt linje kode opdateres i versionskontrolværktøjet, og det er her kontinuerligt test og automatiseret kontinuerlig testpipeline kommer ind i billedet i DevOps.

Kontinuerlig test i DevOps

Foreslået læsning => DevOps-træningsvejledning fra Scratch

Fordele ved CT:

    • Kvalitet og hastighed er de store fordele ved CT.
    • Hurtigere og hurtigere feedback på koden.
    • Øger holdets tillid og opfordrer dem til løbende at forbedre.

VIDEO Del 3 Blok 4: Kontinuerlig test- 14 minutter og 39 sekunder

Udskrift:

I denne blok vil vi lære om Kontinuerlig test og pipeline til kontinuerlig test i detaljer.

Kontinuerlig test er en anden vigtig proces i den kontinuerlige leveringsrørledning sammen med kontinuerlig integration, i en rørledning inkluderer den, forskellige testfaser hvor de automatiserede tests køres sammen med de automatiserede kvalitetsporte imellem.

Således er kontinuerlig test udførelse af automatiserede tests kontinuerligt og gentagne gange mod kodebasen og de forskellige implementeringsmiljøer.

Hovedsageligt er enhedstest, statisk kodeanalyse, sikkerhedskodeanalyse, integrationstest, belastning og ydelsestest en del af kontinuerlig test, der køres i en automatiseret kontinuerlig testpipeline.

hvad er det nyeste operativsystem

Da kontinuerlig integration og kontinuerlig implementering kaldes CI, CD, kaldes kontinuerlig test oftere som CT.

Hvis du ser dette diagram, som er en kontinuerlig leveringsrørledning, inkluderer denne rørledning to rørledninger, den ene er en buildrørledning, der er CI-rørledning eller kontinuerlig integrationsrørledning, som består af automatiseret build-trigger, kompilering, bygning og implementering.

Den anden er en testrørledning, som er en kontinuerlig testrørledning

Lad os nu se mere om kontinuerlig test.

Vi ved vigtigheden af ​​at teste, teste hver linje kode ... .. teste hver gang ... og teste på forskellige stadier, og det er næsten umuligt at køre alle de designede tests hver gang manuelt, når en kodelinje opdateres til versionskontrol.

Det er her, den kontinuerlige test kommer ind i billedet.

Så medmindre koden, der kommer ind i den automatiske kontinuerlige integrerede pipeline, bliver testet grundigt og sikrer den krævede kvalitet, er der ingen brug for at frigive softwaren til kunderne. Jeg mener kvalitet kan ikke sikres, medmindre koden testes grundigt.

Så kontinuerlig test, som defineret tidligere, er at udføre forskellige typer tests kontinuerligt på kodebasen og i forskellige miljøer, som den bliver implementeret på, som foruddefineret og designet i den kontinuerlige leveringsrørledning.

Som du ser på billedet, sker enhedstest på selve CI-serveren, som tester hver enhed i systemet isoleret.

Integrationstest sker på integrationsmiljø, som grundlæggende verificerer komponenterne integreret sammen. Systemtest i systemtestemiljøet, hvor BIG-systemet med alle de integrerede komponenter og grænseflader testes gennem systemniveau-scenarier i et systemtestmiljø og så videre.

Og dybden af ​​testningen skrider ofte frem, når simuleringen af ​​miljøet kommer tættere på produktionen.

Kontinuerlig test bliver gradvis hårdere og længere med udviklingen mod produktionsmiljøet, da vi langsomt skal tilføje et antal tests og mere komplicerede tests, når koden modnes, og miljøkompleksiteten skrider frem.

Det er ikke sådan, at de samme testcases vil blive kørt igennem, testcases skal opdateres hver gang i forskellige faser, og automatiserede scripts opdateres, da koden bliver mere modnet, skrider frem til et højere miljøniveau, hvor konfigurationer og infrastruktur også forskud, indtil det kommer i produktion.

Så selv den tid, det tager at køre testene, øges, efterhånden som testen skrider frem mod frigørelsespunktet, ligesom enhedstest kan tage meget kortere tid at køre, mens nogle integrationstest eller nogle systemtest eller belastningstest kan tage nogle lange timer at køre eller måske tage få dage til at løbe.

Her vil den kontinuerlige test primært køre de automatiserede testsager automatisk med en trigger. Men som vi definerede tidligere, involverer kontinuerlig levering også visse manuelle tests og porte, hvor visse tests udføres manuelt, inden de skubbes i produktion.

Disse mellemliggende kvalitetsporte i hvert testfase og øger tilliden til koden.

Således inkluderer pipeline til kontinuerlig test som sådan enhedstest sammen med indledende automatiserede sikkerhedsverifikationer. Derefter kommer ind på et integrationsniveau af test, hvor automatiserede integrationstests køres, derefter videre til et systemniveau, hvor scenarier på systemniveau automatiseres og køres.

software skrevet i c ++

Her udføres også visse præstationsscenarier.

Derefter går til 'Acceptance testing', som grundlæggende inkluderer de automatiske teststeder for accept af websted og derefter til 'User Acceptance Testing', som kan være en manuel udførelse og inkluderer slutbrugerdeltagelse for at udføre testene, og dette vil være en slags afslutning på produktet eller en funktion, hvor manuel gate påkaldes og til sidst distribueres videre til produktionsstedet.

Så grundlæggende, når kontinuerlig test skrider frem, øges kompleksiteten af ​​tests og testmiljøet og kommer til miljøet, der er tættere på produktionen som simulering.

Jeg behøver ikke specifikt at skulle nævne, at alle disse testfaser inkluderer bygningsbekræftelsestest, sundhedstest, røgtest og regressionstest også, igen som sagt, det afhænger af, hvad vi designer i den kontinuerlige test- og leveringspipeline.

Dette er den typiske kontinuerlige testpipeline, det kan godt designes af teamet baseret på produkttypen og de forskellige testniveauer og testtyper, som produktet kræver.

Kontinuerlig test kræver integration af automatiseringsrammer med versionskontrol- og CI-værktøjet og de forskellige automatiserede værktøjer til at udføre den funktionelle og ikke-funktionelle test på tværs af forskellige testfaser, som:

  • Ekkolod til analyse af statisk kode,
  • Fortify til sikker kodeanalyse,
  • Selen til funktionel test,
  • Lastskinne til belastningstest osv.,

Microsoft TFS, Jenkins, kok, marionet er få værktøjer, der er tilgængelige på markedet til at designe CI-CD-rørledningen.

Men sagen er, at disse værktøjer muligvis ikke understøtter den komplette slut-til-slut-automatisering, afhængigt af det anvendte versionskontrolværktøj, så få organisationer foretrækker måske at udvikle deres egne automatiseringsrammer, hvilket muliggør slut-til-slut-automatisering af leveringsrørledningen fra kode forpligte sig til kode levering.

teknisk support analytiker interview spørgsmål og svar

Så kontinuerlig test er en meget vigtig del af testen, der sikrer kvaliteten af ​​produktet eller frigivelsen, og man skal være meget forsigtig med valg af et værktøj, en ramme osv., Der primært bestemmer kvaliteten og leveringshastigheden.

Så opsætningen af ​​den rigtige kontinuerlige testpipeline tager lidt mere tid i den kontinuerlige leveringspipeline. Ikke kun på værktøjs- og rammedelen, men også på testcases. Kontinuerlig test inkluderer også definition af implementeringsrørledning inden for.

Fordi CT kræver automatisk implementering af build-up til forskellige miljøer i forskellige faser, hvilket kræver automatisering af implementeringen og opsætning af miljøer via automatiske scripts.

Disse automatiserede scripts, der inkluderer opsætning af infrastruktur og miljøkonfigurationer som en kode, kontrolleres i versionskontrolværktøjet, og leveringsrørledningen henter det fra versionskontrolværktøjet for at udføre implementeringen. Dette kaldes implementeringsrørledningen.

Lad os nu komme til fordelene ved CT,

At opnå kvalitet og hastighed er den største fordel ved kontinuerlig test.

I modsætning til tidligere, hvor test tidligere kun skete i sidste ende, er test igennem konceptet med kontinuerlig test, og derfor giver kontinuerlig test i en leveringsrørledning teamet mulighed for at introducere kvalitetsporte hvor som helst og et hvilket som helst antal kvalitetsporte, de ønsker for at opnå den grad af kvalitet, som de har brug for.

Så hvis koden overhovedet ikke kan testes på et bestemt punkt eller gate i en rørledning, kan holdet gå tilbage og automatisk fejle hele implementeringen op til det punkt.

Dette giver en klar indikation til både Dev- og Ops-teamet om, at der mangler noget der, og teamet kan arbejde på at ordne det. Så dette er fordelen og fleksibiliteten ved kontinuerlig testpipeline.

Så indførelsen af ​​kvalitetsporte i forskellige testfaser styrer kvaliteten af ​​koden bedre i rørledningen.

Mere antallet af porte, som koden passerer, mere vil holdets tillid til koden, at det kan gøre det til produktionen på et højere kvalitetsniveau.

Så løbende test øger holdets tillid og opmuntrer dem til løbende at forbedre.

Samlet set, hvis holdet ikke virkelig forsømmer nogen af ​​testfejlene i nogen testfaser eller kvalitetsporte i rørledningen, vil definitivt kontinuerlig test være en bonus for at nå mål af høj kvalitet.

Så for at konkludere med kontinuerlig test, lige fra enhedstestene, der køres i den indledende fase gennem accepttesten, præstationsafprøvning og endda visse manuelle test, der skal køres, er MEGET MEGET kritisk for at definere kontinuerlig test i DevOps-pipelinen.

Dette afslutter vores diskussion om Part3-emner med kontinuerlig integration, kontinuerlig levering og kontinuerlig test.

I vores kommende vejledning vil vi diskutere mere om Konfigurationsstyring, frigivelsesstyring og overvågning af applikationsydelse.

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^