Een van de problemen waarmee leveranciers van software voor meerdere producten vaak worden geconfronteerd, is de duplicatie van de competenties van ingenieurs - ontwikkelaars, testers en infrastructuurbeheerders - in bijna elk team. Dat geldt ook voor dure engineers - specialisten op het gebied van load testing.
In plaats van hun directe taken uit te voeren en hun unieke ervaring te gebruiken om een belastingtestproces op te bouwen, een methodologie te kiezen, optimale statistieken te kiezen en autotests te schrijven in overeenstemming met belastingsprofielen, moeten ingenieurs vaak een testinfrastructuur vanaf nul implementeren, belastingtools configureren en insluiten. zichzelf in CI-systemen, monitoring opzetten en rapportages publiceren.
U kunt oplossingen vinden voor enkele organisatorische problemen in testen die we bij Positive Technologies gebruiken in . En in deze zal ik het hebben over de mogelijkheid om belastingstests te integreren in een gemeenschappelijke CI-pijplijn met behulp van het concept van "belastingstests als een service" (belastingstests als een service). Je leert hoe en welke docker-images van laadbronnen kunnen worden gebruikt in de CI-pijplijn; hoe u laadbronnen koppelt aan uw CI-project met behulp van een build-sjabloon; hoe de demo-pijplijn eruit ziet voor het uitvoeren van belastingstests en het publiceren van de resultaten. Het artikel kan nuttig zijn voor softwaretestingenieurs en automatiseringsingenieurs in CI die nadenken over de architectuur van hun laadsysteem.
De essentie van het concept
Het concept van load testing as a service impliceert de mogelijkheid om load tools Apache JMeter, Yandex.Tank en uw eigen frameworks te integreren in een willekeurig continu integratiesysteem. De demo is voor GitLab CI, maar de principes gelden voor alle CI-systemen.
Load testing as a service is een gecentraliseerde service voor load testing. Load tests worden uitgevoerd in speciale agent pools, de resultaten worden automatisch gepubliceerd in GitLab Pages, Influx DB en Grafana of in testrapportagesystemen (TestRail, ReportPortal, enz.). Automatisering en schaling worden zo eenvoudig mogelijk geïmplementeerd - door de gebruikelijke gitlab-ci.yml-template toe te voegen en te parametriseren in het GitLab CI-project.
Het voordeel van deze aanpak is dat de volledige CI-infrastructuur, laadagenten, docker-images van laadbronnen, testpijplijnen en publicatierapporten worden onderhouden door een gecentraliseerde automatiseringsafdeling (DevOps-engineers), terwijl load-testing-engineers hun inspanningen kunnen richten op testontwikkeling en analyse van hun resultaten, zonder zich bezig te houden met infrastructuurproblemen.
Om de beschrijving te vereenvoudigen, gaan we ervan uit dat de doeltoepassing of -server die wordt getest, al van tevoren is geïmplementeerd en geconfigureerd (hiervoor kunnen geautomatiseerde scripts in Python, SaltStack, Ansible, etc. worden gebruikt). Dan past het hele concept van load testing as a service in drie fasen: voorbereiding, testen, publicatie van rapporten. Meer details over het diagram (alle afbeeldingen zijn aanklikbaar):
Basisconcepten en definities in belastingtesten
Bij het uitvoeren van belastingtesten proberen we ons hieraan te houden , gebruik de juiste terminologie en aanbevolen statistieken. Ik zal een korte lijst geven van de belangrijkste concepten en definities in belastingtesten.
Laad agent - een virtuele machine waarop de applicatie wordt gestart - de laadbron (Apache JMeter, Yandex.Tank of een zelfgeschreven laadmodule).
Testdoel (doel) - server of applicatie geïnstalleerd op de server die zal worden belast.
Testscenario (testgeval) - een reeks geparametriseerde stappen: gebruikersacties en verwachte reacties op deze acties, met vaste netwerkverzoeken en -antwoorden, afhankelijk van de gespecificeerde parameters.
Profiel of laadplan (profiel) - in (Sectie 4.2.4, p. 43) belastingsprofielen definiëren metrieken die cruciaal zijn voor een bepaalde test en opties voor het wijzigen van belastingsparameters tijdens de test. In de afbeelding ziet u voorbeelden van profielen.
Test — een script met een vooraf bepaalde set parameters.
Testplan (testplan) - een reeks tests en een belastingsprofiel.
Testrun (testrun) - één iteratie van het uitvoeren van één test met een volledig uitgevoerd belastingsscenario en het ontvangen rapport.
Netwerkverzoek (verzoek) — Een HTTP-verzoek verzonden van een agent naar een doel.
Netwerkreactie (reactie) — Een HTTP-antwoord verzonden van het doel naar de agent.
HTTP-antwoordcode (HTTP-antwoordstatus) - standaard antwoordcode van de toepassingsserver.
Een transactie is een volledige verzoek-antwoordcyclus. Een transactie wordt geteld vanaf het begin van het verzenden van een verzoek (verzoek) tot het voltooien van het ontvangen van een antwoord (antwoord).
Transactiestatus - of het mogelijk was om de vraag-antwoordcyclus succesvol af te ronden. Als er een fout is opgetreden in deze cyclus, wordt de gehele transactie als mislukt beschouwd.
Responstijd (latentie) - de tijd vanaf het einde van het verzenden van een verzoek (verzoek) tot het begin van het ontvangen van een antwoord (antwoord).
Laad statistieken — de kenmerken van de geladen service en de load agent bepaald tijdens het load testing proces.
Basisstatistieken voor het meten van belastingsparameters
Enkele van de meest gebruikte en aanbevolen in de methodologie (p. 36, 52) de statistieken worden weergegeven in de onderstaande tabel. Vergelijkbare statistieken voor agent en doel worden op dezelfde regel weergegeven.
Statistieken voor de laadagent
Statistieken van het doelsysteem of de toepassing die wordt getest onder belasting
Aantal vCPU en geheugen RAM,
Schijf - "ijzeren" eigenschappen van het laadmiddel
CPU, Geheugen, schijfgebruik - dynamiek van CPU, geheugen en schijfladen
tijdens het testen. Meestal gemeten als een percentage van
maximaal beschikbare waarden
Netwerkdoorvoer (op laadagent) - doorvoer
netwerkinterface op de server,
waar de laadagent is geïnstalleerd.
Gewoonlijk gemeten in bytes per seconde (bps)
Netwerkdoorvoer(op doel) - bandbreedte van de netwerkinterface
op de doelserver. Gewoonlijk gemeten in bytes per seconde (bps)
Virtuele gebruikers- het aantal virtuele gebruikers,
het implementeren van belastingsscenario's en
het imiteren van echte gebruikersacties
Status virtuele gebruikers, Geslaagd/Gezakt/Totaal — aantal geslaagde en
mislukte statussen van virtuele gebruikers
voor belastingsscenario's, evenals hun totale aantal.
Over het algemeen wordt verwacht dat alle gebruikers het hebben kunnen voltooien
al uw taken gespecificeerd in het belastingsprofiel.
Elke fout betekent dat een echte gebruiker dit niet kan
los uw probleem op wanneer u met het systeem werkt
Verzoeken per seconde (minuut)- het aantal netwerkverzoeken per seconde (of minuut).
Een belangrijk kenmerk van een load agent is hoeveel verzoeken hij kan genereren.
In feite is dit een imitatie van toegang tot de applicatie door virtuele gebruikers
Reacties per seconde (minuut)
- het aantal netwerkreacties per seconde (of minuut).
Een belangrijk kenmerk van de doeldienst: hoeveel
antwoorden op vragen genereren en verzenden met
laadmiddel
HTTP-antwoordstatus— aantal verschillende responscodes
van de applicatieserver ontvangen door de load agent.
200 OK betekent bijvoorbeeld een succesvol gesprek,
en 404 - dat de bron niet is gevonden
Wachttijd (responstijd) - tijd vanaf het einde
het verzenden van een verzoek (verzoek) voordat u begint met het ontvangen van een antwoord (antwoord).
Gewoonlijk gemeten in milliseconden (ms)
Reactietijd transactie— tijd van één volledige transactie,
voltooiing van de vraag-antwoordcyclus.
Dit is de tijd vanaf het begin van het verzenden van het verzoek (verzoek)
tot voltooiing van het ontvangen van een reactie (antwoord).
Transactietijd kan worden gemeten in seconden (of minuten)
op verschillende manieren: denk aan het minimum,
maximum, gemiddelde en bijvoorbeeld het 90e percentiel.
De minimale en maximale waarden zijn extreem
prestatiestatus van het systeem.
Het negentigste percentiel is het meest gebruikte,
zoals het de meeste gebruikers laat zien,
comfortabel werkend op de drempel van systeemprestaties
Transacties per seconde (minuut) - het aantal compleet
transacties per seconde (minuut),
dat wil zeggen, hoeveel de applicatie kon accepteren en
verzoeken verwerken en antwoorden geven.
In feite is dit de doorvoer van het systeem
Transactiestatus , Geslaagd / Gezakt / Totaal - aantal
succesvol, niet succesvol en het totale aantal transacties.
Voor echte gebruikers mislukt
de transactie daadwerkelijk zal betekenen
onvermogen om te werken met het systeem onder belasting
Belasting testen schematisch diagram
Het concept van belastingtesten is heel eenvoudig en bestaat uit drie hoofdfasen, die ik al heb genoemd: Opstellen-Test-Rapport, dat wil zeggen het opstellen van testdoelen en het instellen van parameters voor belastingsbronnen, vervolgens het uitvoeren van belastingstests en, aan het eind, het genereren en publiceren van een testrapport.
Schematische notities:
- QA.Tester is een expert in loadtesten,
- Target is de doeltoepassing waarvan u het gedrag onder belasting wilt weten.
Classificatie van entiteiten, stadia en stappen in het diagram
Stadia en stappen
Wat is er gaande
Wat staat er bij de ingang
Wat is de opbrengst
Voorbereiden: voorbereidingsfase voor testen
Laadparameters
Instelling en initialisatie
gebruiker
belastingsparameters,
keuze van metrische gegevens en
voorbereiding van het testplan
(laad profiel)
Aangepaste opties voor
load agent initialisatie
Testplan
Doel van testen
VM
Cloud-implementatie
virtuele machine met
vereiste eigenschappen
VM-instellingen voor laadagent
Automatiseringsscripts voor
VM-creatie
VM geconfigureerd in
wolk
env
Installatie en voorbereiding van het besturingssysteem
omgeving voor
laadagent werk
Omgevingsinstellingen voor
laadmiddel
Automatiseringsscripts voor
omgeving instellingen
Voorbereide omgeving:
OS, diensten en toepassingen,
nodig voor werk
laadmiddel
Agenten laden
Installatie, configuratie en parametrering
laadmiddel.
Of een docker-image downloaden van
vooraf geconfigureerde laadbron
Laad bron docker-afbeelding
(YAT, JM of zelfgeschreven framework)
Instellingen
laadmiddel
Opgezet en klaar
om ladingsagent te werken
Test: stadium van uitvoering van belastingstests. Bronnen zijn laadagenten die worden ingezet in speciale agentpools voor GitLab CI
Laden
De Load Agent starten
met geselecteerd testplan
en laadparameters
Gebruikers opties
voor initialisatie
laadmiddel
Testplan
Doel van testen
Uitvoeringslogboeken
belasting testen
Systeemlogboeken
Dynamiek van veranderingen in doelstatistieken en belastingagent
Voer agenten uit
Agent-uitvoering
heel veel testscripts
volgens
laad profiel
Agentinteractie laden
met het oog op testen
Testplan
Doel van testen
Logs
Verzameling van "ruwe" logboeken
tijdens het testen van de belasting:
activiteitsrecords van agent laden,
toestand van het testdoel
en de VM die de agent uitvoert
Uitvoeringslogboeken
belasting testen
Systeemlogboeken
Metriek
Het verzamelen van "ruwe" statistieken tijdens het testen
Dynamiek van veranderingen in doelstatistieken
en laadagent
Rapport: voorbereidingsfase testrapport
Generator
Verwerking verzameld
laadsysteem en
monitoringsysteem "rauw"
statistieken en logboeken
Opstellen van een rapport in
voor mensen leesbare vorm
mogelijk met elementen
analisten
Uitvoeringslogboeken
belasting testen
Systeemlogboeken
Dynamiek van veranderingen in metrieken
doelwit en laadmiddel
Verwerkte "ruwe" logboeken
in een formaat geschikt voor
uploadt naar externe opslag
Statisch belastingsrapport,
leesbare
Publiceer
Publicatie van het rapport
over lading
testen in extern
dienst
Verwerkt "rauw"
logt in een geschikt formaat
voor lossen naar buiten
repositories
Opgeslagen in extern
opslagrapporten op
laden, geschikt
voor menselijke analyse
Laadbronnen verbinden in CI-sjabloon
Laten we verder gaan met het praktische gedeelte. Ik wil laten zien hoe op sommige projecten in het bedrijf we hebben het concept van load testing as a service geïmplementeerd.
Ten eerste hebben we met de hulp van onze DevOps-engineers een speciale pool van agenten in GitLab CI gemaakt om belastingstests uit te voeren. Om ze in sjablonen niet te verwarren met andere, zoals montagepools, hebben we tags aan deze agents toegevoegd, : laden. U kunt alle andere begrijpelijke tags gebruiken. Zij vragen GitLab CI Runners.
Hoe het benodigde vermogen door hardware te achterhalen? De kenmerken van laadagenten - een voldoende aantal vCPU, RAM en schijf - kunnen worden berekend op basis van het feit dat Docker, Python (voor Yandex.Tank), GitLab CI-agent, Java (voor Apache JMeter) op de agent zouden moeten draaien . Voor Java onder JMeter wordt ook aanbevolen om minimaal 512 MB RAM te gebruiken en als bovengrens .
Op basis van onze ervaring raden we daarom aan om ten minste 4 vCPU's, 4 GB RAM, 60 GB SSD te gebruiken voor laadagenten. De doorvoer van de netwerkkaart wordt bepaald op basis van de vereisten van het belastingsprofiel.
We gebruiken voornamelijk twee laadbronnen: Apache JMeter en Yandex.Tank docker-afbeeldingen.
is een open source tool van Yandex voor load testing. De modulaire architectuur is gebaseerd op Phantom's krachtige asynchrone hit-gebaseerde HTTP-aanvraaggenerator. De tank heeft een ingebouwde monitoring van de bronnen van de geteste server via het SSH-protocol, kan de test automatisch stoppen onder gespecificeerde omstandigheden, kan de resultaten zowel in de console als in de vorm van grafieken weergeven, u kunt uw modules aansluiten om de functionaliteit uit te breiden. Overigens gebruikten we de Tank toen die nog niet mainstream was. In het artikel "» lees je het verhaal van hoe we er in 2013 belastingtesten mee hebben uitgevoerd is een van de producten van ons bedrijf.
is een open source load-testtool van Apache. Het kan even goed worden gebruikt voor het testen van zowel statische als dynamische webapplicaties. JMeter ondersteunt een groot aantal protocollen en manieren om met applicaties te communiceren: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) en IMAP(S), databases via JDBC, kunnen shell-commando's uitvoeren en werken met Java-objecten. JMeter heeft een IDE voor het maken, debuggen en uitvoeren van testplannen. Er is ook een CLI voor opdrachtregelbediening op elk Java-compatibel besturingssysteem (Linux, Windows, Mac OS X). De tool kan dynamisch een HTML-testrapport genereren.
Voor het gebruiksgemak binnen ons bedrijf, voor de mogelijkheid van de testers zelf om de omgeving te wijzigen en toe te voegen, hebben we builds gemaakt van docker-images van laadbronnen op GitLab CI met publicatie naar de interne . Dit maakt het sneller en gemakkelijker om ze in pijpleidingen aan te sluiten voor belastingstests. Hoe docker push naar register te doen via GitLab CI - zie .
We hebben dit standaard docker-bestand voor Yandex.Tank genomen:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]En voor Apache JMeter deze:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Hoe ons continuous integration systeem werkt lees je in het artikel ".
Sjabloon en pijplijn
Een voorbeeld van een sjabloon voor het uitvoeren van belastingtesten is beschikbaar in het project . In U kunt de instructies lezen voor het gebruik van de sjabloon. In de sjabloon zelf (file ) zijn er opmerkingen over waar elke stap verantwoordelijk voor is.
De sjabloon is heel eenvoudig en demonstreert de drie fasen van belastingtesten die in het bovenstaande diagram worden beschreven: rapporten voorbereiden, testen en publiceren. Hiervoor verantwoordelijk : Voorbereiden, testen en rapporteren.
- Stadium moet worden gebruikt om testdoelen vooraf te configureren of hun beschikbaarheid te controleren. De omgeving voor laadbronnen hoeft niet te worden geconfigureerd, ze zijn vooraf gebouwd als docker-images en gepost in het docker-register: geef gewoon de gewenste versie op in de testfase. Maar u kunt ze opnieuw opbouwen en uw eigen aangepaste afbeeldingen maken.
- Stadium gebruikt om de laadbron te specificeren, tests uit te voeren en testartefacten op te slaan. U kunt elke laadbron kiezen: Yandex.Tank, Apache JMeter, uw eigen of allemaal samen. Om onnodige bronnen uit te schakelen, hoeft u alleen maar een opmerking te plaatsen of de taak te verwijderen. Ingangspunten voor laadbronnen:
- Startparameters voor Yandex.Tank worden gespecificeerd in het .,
- Apache JMeter-opstartparameters zijn gespecificeerd in het bestand .
Opmerking: De montageconfiguratiesjabloon wordt gebruikt om interactie met het CI-systeem in te stellen en impliceert niet dat er testlogica in wordt geplaatst. Voor tests wordt het ingangspunt opgegeven, waar het control bash-script zich bevindt. De methode voor het uitvoeren van tests, het genereren van rapporten en de testscripts zelf moeten worden geïmplementeerd door QA-engineers. In de demo wordt voor beide laadbronnen het Yandex-hoofdpaginaverzoek gebruikt als de eenvoudigste test. Scripts en testparameters staan in de directory .
- Op het podium u moet beschrijven hoe u de testresultaten die in de testfase zijn verkregen, kunt publiceren naar externe opslag, bijvoorbeeld naar GitLab Pages of speciale rapportagesystemen. GitLab Pages vereist dat de ./public-directory niet leeg is en ten minste een index.html-bestand bevat nadat de tests zijn voltooid. U kunt lezen over de nuances van de GitLab Pages-service. .
Voorbeelden van het exporteren van gegevens:
- van JMeter naar ,
- van Yandex.Tank naar .
Installatie-instructies plaatsen:
- HTML-statistieken in ,
- naar InfluxDB en vervolgens naar .
In het demovoorbeeld ziet de pijplijn met belastingstests en twee belastingsbronnen (u kunt de onnodige uitschakelen) er als volgt uit:
Apache JMeter kan zelf een HTML-rapport genereren, dus het is voordeliger om het op te slaan in GitLab Pages met behulp van standaardtools. Zo ziet het Apache JMeter-rapport eruit:
In het demo-voorbeeld voor Yandex.Tank ziet u alleen in de sectie voor GitLab-pagina's. Tijdens het testen kan de Tank de resultaten opslaan in de InfluxDB-database en van daaruit kunnen ze worden weergegeven in bijvoorbeeld Grafana (configuratie gebeurt in het bestand ). Zo ziet het rapport van Tank eruit in Grafana:
Beknopt
In het artikel had ik het over het concept van "load testing as a service" (load testing as a service). Het belangrijkste idee is om de infrastructuur van vooraf geconfigureerde pools van laadagenten, docker-afbeeldingen van laadbronnen, rapportagesystemen en een pijplijn die ze combineert in GitLab CI te gebruiken op basis van een eenvoudig .gitlab-ci.yml-sjabloon (voorbeeld ). Dit alles wordt ondersteund door een klein team van automatiseringsingenieurs en gerepliceerd op verzoek van productteams. Ik hoop u hiermee van dienst te kunnen zijn bij het opstellen en uitvoeren van een soortgelijke regeling in uw bedrijf. Bedankt voor de aandacht!
PS Ik wil mijn collega's, Sergey Kurbanov en Nikolai Yusev, hartelijk bedanken voor hun technische assistentie bij de implementatie van het concept van load testing as a service in ons bedrijf.
Auteur: - Plaatsvervangend Hoofd Technologie en Ontwikkelingsprocessen (DevOps) bij Positive Technologies
Bron: www.habr.com