Menu

Continu testen in DevOps

continuous testing devops

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is continu testen en pijplijn voor continu testen in DevOps?

Ik hoop dat jullie allemaal genoten hebben van de laatste tutorial over Continue implementatie in DevOps ​

java 8 nieuwe functies interviewvragen

We kennen het belang van testen in elke softwarelevering en DevOps is een korte leveringscyclus, het is onmogelijk om alle ontworpen testcases elke keer handmatig uit te voeren, wanneer een enkele regel code wordt bijgewerkt in de versiebeheertool en dat is waar continu testen en geautomatiseerde continue testpijplijn komen in beeld in DevOps.

Continu testen in DevOps

Voorgestelde lezing => DevOps Training Tutorial van Scratch

Voordelen van CT:

    • Kwaliteit en snelheid zijn de grote voordelen van CT.
    • Snellere en snellere feedback over de code.
    • Verhoogt het vertrouwen van het team en moedigt hen aan om continu te verbeteren.

VIDEO Deel 3 Blok 4: Continu testen- 14 minuten 39 seconden

Vertaling:

In dit blok zullen we leren over Continu testen en continu testen pijplijn in detail.

Continu testen is een ander belangrijk proces van de continue leveringspijplijn, samen met continue integratie, in een pijplijn omvat het: verschillende testfasen waarbij de geautomatiseerde tests worden uitgevoerd samen met de geautomatiseerde kwaliteitspoorten ertussen.

Continu testen is dus, het uitvoeren van geautomatiseerde tests, continu en herhaaldelijk tegen de codebasis en de verschillende implementatieomgevingen.

Voornamelijk unit-tests, statische code-analyse, beveiligingscode-analyse, integratietests, belasting- en prestatietests maken deel uit van continue tests die worden uitgevoerd in een geautomatiseerde continue testpijplijn.

Omdat continue integratie en continue implementatie CI, CD worden genoemd, wordt continu testen vaker CT genoemd.

Als u dit diagram ziet, dat een continue leveringspijplijn is, omvat deze pijplijn twee pijplijnen, een is een buildpijplijn die een CI-pijplijn is of een continue integratiepijplijn, die bestaat uit een geautomatiseerde build-trigger, compileren, bouwen en implementeren.

De andere is een testpijplijn, een continue testpijplijn

Laten we nu eens kijken naar continu testen.

We kennen het belang van testen, het testen van elke regel code… .. elke keer testen… en testen in verschillende stadia en het is bijna onmogelijk om alle ontworpen tests elke keer handmatig uit te voeren wanneer een regel code wordt bijgewerkt naar versiebeheer.

Dat is waar het continue testen in beeld komt.

Dus tenzij de code die in de geautomatiseerde continue geïntegreerde pijplijn terechtkomt, grondig wordt getest en de vereiste kwaliteit garandeert, heeft het geen zin om de software aan de klanten vrij te geven. Ik bedoel, kwaliteit kan niet worden gegarandeerd, tenzij de code grondig wordt getest.

Continu testen, zoals eerder gedefinieerd, is dus het uitvoeren van verschillende soorten tests, continu op de codebasis en op verschillende omgevingen waarin het wordt geïmplementeerd, zoals vooraf gedefinieerd en ontworpen in de continue leveringspijplijn.

Zoals u op de afbeelding ziet, vinden unit-tests plaats op de CI-server zelf, die elke unit van het systeem afzonderlijk test.

Integratietests vinden plaats in een integratieomgeving die in feite de componenten verifieert die samen zijn geïntegreerd. Systeemtests in de systeemtestomgeving waar het BIG-systeem met alle geïntegreerde componenten en interfaces wordt getest door middel van scenario's op systeemniveau in een systeemtestomgeving, enzovoort.

En de diepte van het testen vordert vaak naarmate de simulatie van de omgeving dichter bij de productie komt.

Continu testen wordt steeds moeilijker en langer met de voortgang naar de productieomgeving, aangezien we langzaamaan een aantal tests en meer gecompliceerde tests moeten toevoegen naarmate de code ouder wordt en de complexiteit van de omgeving toeneemt.

Het is niet zo dat overal dezelfde testcases worden uitgevoerd, de testcases moeten elke keer in verschillende fasen worden bijgewerkt en geautomatiseerde scripts worden bijgewerkt, naarmate de code volwassener wordt, doorgaat naar een hoger niveau van omgeving waar configuraties en infrastructuur ook vooruit, totdat het in productie gaat.

Dus zelfs de tijd die nodig is om de tests uit te voeren, neemt toe naarmate het testen vordert naar het release-punt, zoals het testen van eenheden kan veel minder tijd kosten om uit te voeren, terwijl sommige integratietests of sommige systeemtests of laadtests enkele lange uren kunnen duren of kunnen duren een paar dagen om te rennen.

Hier zou het continue testen voornamelijk bestaan ​​uit het automatisch uitvoeren van de geautomatiseerde testgevallen met een trigger. Maar zoals we eerder hebben gedefinieerd, omvat continue levering ook bepaalde handmatige tests en poorten, waarbij bepaalde tests handmatig worden uitgevoerd voordat ze in productie gaan.

Deze poorten van gemiddelde kwaliteit in elke testfase en vergroten het vertrouwen in de code.

De pijplijn voor continu testen omvat dus het testen van eenheden samen met voorlopige geautomatiseerde beveiligingsverificaties. Vervolgens komt het op een integratieniveau van testen, waar geautomatiseerde integratietests worden uitgevoerd, en vervolgens op een systeemniveau waar scenario's op systeemniveau worden geautomatiseerd en uitgevoerd.

Hier worden zelfs bepaalde prestatietestscenario's uitgevoerd.

Gaat vervolgens naar de 'Acceptatietest' die in feite de geautomatiseerde testcases voor site-acceptatie omvat en tenslotte naar de 'Gebruikersacceptatietest' die een handmatige uitvoering kan zijn en deelname van de eindgebruiker omvat om de tests uit te voeren en dit zal worden een soort definitieve afmelding op het product of een functie, waarbij handmatige poort wordt aangeroepen en uiteindelijk op de productielocatie wordt ingezet.

Dus naarmate het continu testen vordert, neemt de complexiteit van tests en de testomgeving toe en komt deze dichter bij de productie, zoals simulatie.

Ik hoef niet specifiek te vermelden dat al deze testfasen ook buildverificatietests, gezondheidstests, rooktests en regressietests omvatten, nogmaals, zoals ik al zei, het hangt af van wat we ontwerpen in de continue test- en leveringspijplijn.

Dit is de typische continue testpijplijn, en deze kan door het team worden ontworpen op basis van het type product en de verschillende testniveaus en soorten tests die het product vereist.

Voor continu testen is integratie van een automatiseringsraamwerk vereist met de versiebeheer- en CI-tool en de verschillende geautomatiseerde tools om de functionele en niet-functionele tests uit te voeren in verschillende testfasen, zoals:

  • Sonar voor analyse van statische code,
  • Versterken voor veilige code-analyse,
  • Selenium voor functioneel testen,
  • Load runner voor load testing etc.,

Microsoft TFS, Jenkins, chef, puppet zijn enkele tools die op de markt beschikbaar zijn om de CI-CD-pijplijn te ontwerpen.

Maar het punt is dat deze tools mogelijk niet de volledige end-to-end-automatisering ondersteunen, afhankelijk van de gebruikte versiebeheertool, dus weinig organisaties geven er de voorkeur aan om hun eigen automatiseringsraamwerken te ontwikkelen, die de end-to-end automatisering van de leveringspijplijn vanuit code mogelijk maken. committeren aan codelevering.

Continu testen is dus een zeer cruciaal onderdeel van testen om de kwaliteit van het product of de release te waarborgen en men moet heel voorzichtig zijn bij de selectie van een tool, framework, enz., Die primair de kwaliteit en snelheid van levering bepaalt.

Dus het opzetten van de juiste continue testpijplijn kost wat meer tijd in de continue leveringspijplijn. Niet alleen op het tool- en raamwerkgedeelte, maar ook op het gedeelte met testcases. Continu testen omvat ook het definiëren van de implementatiepijplijn binnen.

Omdat CT de geautomatiseerde implementatie van de build op verschillende omgevingen in verschillende fasen vereist, wat vraagt ​​om automatisering van de implementatie en het opzetten van de omgevingen via geautomatiseerde scripts.

Deze geautomatiseerde scripts, waaronder het instellen van infrastructuur- en omgevingsconfiguraties als een code, worden ingecheckt in het versiebeheerprogramma en de bezorgingspijplijn haalt het op van het versiebeheerprogramma om de implementatie uit te voeren. Dit wordt de implementatiepijplijn genoemd.

Laten we nu eens kijken naar de voordelen van CT,

Het bereiken van kwaliteit en snelheid is het grootste voordeel van continu testen.

In tegenstelling tot vroeger, waar testen alleen aan het eind gebeurde, is testen het concept van continu testen en dus het continu testen in een leveringspijplijn, stelt het team in staat om overal kwaliteitspoorten en een willekeurig aantal kwaliteitspoorten te introduceren die ze willen. om de kwaliteit te bereiken die ze nodig hebben.

Dus als de code niet kan worden getest op een bepaald punt of poort in een pijplijn, kan het team teruggaan en automatisch de hele implementatie tot dat punt mislukken.

Dit geeft zowel het Dev- als het Ops-team een ​​duidelijke indicatie dat daar iets ontbreekt en het team kan eraan werken om het op te lossen. Dit is dus het voordeel en de flexibiliteit van een continue testpijplijn.

De introductie van kwaliteitspoortjes in verschillende testfasen regelt de kwaliteit van de code dus beter in de pijplijn.

Hoe meer poorten de code passeert, hoe groter het vertrouwen van het team in de code dat het de productie kan halen met een hoger kwaliteitsniveau.

Continu testen vergroot dus het vertrouwen van het team en moedigt hen aan om continu te verbeteren.

Over het algemeen, als het team niet echt een van de testfouten in testfasen of kwaliteitspoorten in de pijplijn negeert, zal continu testen zeker een bonus zijn voor het behalen van hoogwaardige doelen.

Dus om te concluderen over continu testen, vanaf de unit-tests die worden uitgevoerd tijdens de voorbereidende fase tot en met de acceptatietests, prestatietests en zelfs bepaalde handmatige tests die zullen worden uitgevoerd, zijn HEEL ERG kritiek voor het definiëren van continue tests in de DevOps-pijplijn.

Hiermee is onze discussie over Part3-onderwerpen van continue integratie, continue levering en continu testen voltooid.

In onze aanstaande tutorial zullen we er meer over bespreken Configuratiebeheer, releasebeheer en monitoring van applicatieprestaties.

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^