Een van de problemen waarmee multi-product softwareleveranciers vaak te maken hebben, is de dubbele competenties van engineers - ontwikkelaars, testers en infrastructuurbeheerders - in bijna elk team. Dit geldt ook voor dure engineers - specialists in belastingstestingen.
In plaats van zich bezig te houden met hun directe verantwoordelijkheden en hun unieke ervaring te gebruiken om het proces van belastingtesten op te bouwen, methodologieën te kiezen, optimale metrische waarden vast te stellen en geautomatiseerde tests in overeenstemming met de belastingprofielen te schrijven, moeten engineers vaak vanaf nul de testinfrastructuur opzetten, belastingtools configureren, deze zelf in CI-systemen integreren, monitoring instellen en rapporten publiceren.
Oplossingen voor sommige organisatieproblemen in testen die we toepassen bij Positive Technologies, vindt u in . En in dit artikel bespreek ik de mogelijkheid om belastingstests te integreren in de algemene CI-pijplijn door middel van het concept 'belastingtesten als een dienst' (load testing as a service). U leert welke en hoe Docker-images voor belastingbronnen kunnen worden gebruikt in de CI-pijplijn; hoe u belastingbronnen aan uw CI-project kunt koppelen met behulp van een bouwsjabloon; hoe een demo-pijplijn eruitziet voor het uitvoeren van belastingstests en het publiceren van resultaten. Dit artikel kan nuttig zijn voor softwaretestingenieurs en CI-automatiseringsingenieurs die nadenken over de architectuur van hun belastingtestsysteem.
De kern van het concept
Het concept van load testing as a service houdt in dat het mogelijk is om belastingstools zoals Apache JMeter, Yandex.Tank en onze eigen frameworks in elk willekeurig continuous integration-systeem te integreren. Het demo-voorbeeld is voor GitLab CI, maar de principes zijn algemeen voor alle CI-systemen.
Load testing as a service is een gecentraliseerde service voor het uitvoeren van belastingstests. De belastingstests worden uitgevoerd in speciale pools van agents, en de publicatie van resultaten gebeurt automatisch in GitLab Pages, Influx DB en Grafana of in testrapportagesystemen (TestRail, ReportPortal, enz.). Automatisering en schaling worden zo eenvoudig mogelijk gerealiseerd - door een gebruikelijk sjabloon gitlab-ci.yml toe te voegen en te parametriseren in het GitLab CI-project.
Het voordeel van deze aanpak is dat de gehele CI-infrastructuur, belastingagenten, Docker-images van belastingbronnen, testpijplijnen en rapportpublicatie worden ondersteund door een gecentraliseerde automatiseringsafdeling (DevOps-engineers), waardoor belastingtestingenieurs zich kunnen richten op het ontwikkelen van tests en het analyseren van de resultaten, zonder zich bezig te houden met infrastructuurkwesties.
Voor de eenvoudigen beschrijving nemen we aan dat de doeltoepassing of server al van tevoren is uitgerold en geconfigureerd (automatiseringsscripts op Python, SaltStack, Ansible, etc. kunnen hiervoor worden gebruikt). De gehele concept van belastingtesting als service bestaat dan uit drie fasen: voorbereiding, testen, rapportpublicatie. Zie de diagram voor meer details (alle afbeeldingen zijn aanklikbaar):
Basisconcepten en definities in belastingtesting
Bij het uitvoeren van belastingtests proberen we ons te houden aan , gebruiken we de juiste terminologie en aanbevolen metrics. Hier is een korte lijst van de belangrijkste concepten en definities in belastingtesting.
Belastingagent (load agent) — een virtuele machine waarop de belastingbronnenapplicatie zal draaien (Apache JMeter, Yandex.Tank of een zelfgeschreven belastingmodule).
Testdoel (target) — de server of applicatie die op de server is geïnstalleerd en die aan belasting onderhevig zal zijn.
Testscenario (test case) — een verzameling geparametriseerde stappen: acties van gebruikers en de verwachte reacties op die acties, met vastgelegde netwerkverzoeken en antwoorden, afhankelijk van de gegeven parameters.
Profiel of belastingplan (profile) — tot (sectie 4.2.4, blz. 43) belastingprofielen bepalen de cruciale metrics voor een specifieke test en de variaties in belastingparameters die tijdens de test kunnen worden gewijzigd. Voorbeelden van profielen zijn te zien in de afbeelding.
Test (test) — een scenario met een vooraf gedefinieerde set parameters.
Testplan (test-plan) — een set tests en een belastingprofiel.
Testrun (testrun) — één iteratie van het uitvoeren van één test met een volledig uitgevoerd belastingscenario en een verkregen rapport.
Netwerkverzoek (request) — een HTTP-verzoek dat van de agent naar de doelserver wordt verzonden.
Netwerkantwoord (response) — HTTP-respons die van de doelserver naar de agent wordt verzonden.
HTTP-statuscode (HTTP response status) — een standaardresponscode van de applicatieserver.
Transactie (transaction) — de volledige cyclus van 'verzoek — antwoord'. Een transactie wordt beschouwd vanaf het moment van verzenden van het verzoek (request) tot het ontvangen van de respons (response).
Status van de transactie (transactions status) — of de cyclus 'verzoek – antwoord' succesvol is voltooid. Als er tijdens deze cyclus een fout is opgetreden, wordt de hele transactie als onsuccesvol beschouwd.
Reactietijd (latency) — de tijd van het beëindigen van het verzenden van het verzoek (request) tot het begin van het ontvangen van de respons (response).
Laadmetriek (metrics) — kenmerken van de belaste service en de belastingagent, die worden vastgesteld tijdens het load testing.
Belangrijkste metriek voor het meten van laaddeparameters
Enkele van de meest algemene en aanbevolen metrics in de methodologie (blz. 36, 52) zijn in de onderstaande tabel weergegeven. Vergelijkbare metrics voor de agent en het doel zijn in dezelfde regel aangegeven.
Metriek voor de belastingagent
Metriek van het doelsysteem of de applicatie die onder belasting wordt getest
Aantal vCPU en geheugen RAM,
Schijf — 'hardware' kenmerken van de belastingagent
CPU, Geheugen, Schijfgebruik — dynamiek van CPU-, geheugen- en schijfbelasting
tijdens de test. Gewoonlijk gemeten in procenten van
de maximaal beschikbare waarden
Netwerkdoorvoer (op de belastingagent) — de doorvoersnelheid
van de netwerkinterface op de server,
waar de belastingagent is geïnstalleerd.
Gewoonlijk gemeten in bytes per seconde (bps)
Netwerkdoorvoer(op het doel) — de doorvoersnelheid van de netwerkinterface
op de doelsserver. Gewoonlijk gemeten in bytes per seconde (bps)
Virtuele gebruikers— het aantal virtuele gebruikers,
die belastingscenario's uitvoeren en
echte acties van gebruikers imiteren
Status van virtuele gebruikers, Geslaagd / Mislukt / Totaal — het aantal succesvolle en
mislukte status van operationele virtuele gebruikers
voor belastingscenario's en hun totale aantal.
Gewoonlijk wordt verwacht dat alle gebruikers hun
taken, zoals aangegeven in het belastingprofiel, kunnen uitvoeren.
Elke fout betekent dat ook een echte gebruiker niet in staat zal zijn
zijn taak op te lossen bij het werken met het systeem.
Verzoeken per seconde (of minuut)— het aantal netwerkverzoeken per seconde (of minuut).
Een belangrijke eigenschap van de belastingagent: hoeveel verzoeken hij kan genereren.
In feite is dit een simulatie van aanvragen aan de applicatie door virtuele gebruikers
Antwoorden per seconde (per minuut)
— het aantal netwerkniveau-antwoorden per seconde (of per minuut).
Een belangrijke eigenschap van de doelservice: hoeveel er is
gegenereerd en verzonden responses op aanvragen van
de belastingagent
HTTP-responsstatus— het aantal verschillende antwoordcodes
van de applicatieserver, ontvangen door de belastingagent.
Bijvoorbeeld, 200 OK betekent een succesvolle aanvraag,
terwijl 404 betekent dat de bron niet is gevonden
Latency (reactietijd) — de tijd van het einde
van de verzending van de aanvraag (request) tot het begin van de ontvangst van de reactie (response).
Wordt meestal gemeten in milliseconden (ms)
Transactie-responstijd— de tijd voor één volledige transactie,
het voltooien van de cyclus ‘aanvraag — antwoord’.
Dit is de tijd van het begin van de verzending van de aanvraag (request)
tot het einde van de ontvangst van de respons (response).
De transactietijd kan op verschillende manieren in seconden (of minuten) worden gemeten.
Er worden minimaal, maximaal, gemiddeld en bijvoorbeeld de 90ste percentiel berekend.
Minimale en maximale metingen zijn de uiteinden
van de systeemprestaties.
De negentigste percentiel wordt het vaakst gebruikt,
omdat deze de meeste gebruikers weergeeft,
die comfortabel werken op de prestatiegrens van het systeem.
Transacties per seconde (per minuut)
— het aantal volledige transacties per seconde (of per minuut),
dat wil zeggen hoeveel aanvragen de applicatie heeft kunnen ontvangen en
deze heeft verwerkt en antwoorden heeft gegeven.
In feite is dit de doorvoersnelheid van het systeem.
Transactiestatus
, Geslaagd / Mislukt / Totaal — het aantal succesvolle, mislukte en het totale aantal transacties.
Voor echte gebruikers betekent een mislukte
transactie feitelijk dat
het onmogelijk is om met het systeem te werken onder belasting.
Het principe schema van belastingstest
Het basisprincipe van belastingtesten is heel eenvoudig en bestaat uit drie belangrijke fasen, waar ik al eerder over heb gesproken:
Voorbereiden — Testen — Rapporteren , dat wil zeggen voorbereiding van testdoelen en instellingen voor belastingbronnen, daarna het uitvoeren van belastingtests en ten slotte het opstellen en publiceren van een testverslag.Opmerkingen bij het schema:
QA.Tester — expert in belastingtesten,
- Doel — de doeltoepassing waarvan het gedrag onder belasting moet worden onderzocht.
- Classificator van entiteiten, fasen en stappen in het schema
Fasen en stappen
Wat er gebeurt
Wat gebeurt er
Wat er binnenkomt
Wat er eruitkomt
Voorbereiden: de voorbereidingsfase voor testen
Laadparameters
Taak en initialisatie
de gebruiker
van de belastingparameters,
de keuze van de metrics en
de voorbereiding van het testplan
(belastingprofiel)
Gebruikersonderlen voor
initialisatie van de belastingagent
Testplan
Doel van het testen
VM
Implementatie in de cloud
van een virtuele machine met
de vereiste specificaties
VM-parameters voor de belastingagent
Automatiseringsscripts voor
het creëren van VM
Geconfigureerde VM in
de cloud
Env
Configuratie van het besturingssysteem en voorbereiding
van de omgeving voor
de werking van de belastingagent
Omgevingsparameters voor
de belastingagent
Automatiseringsscripts voor
omgevingsinstellingen
Voorbereide omgeving:
OS, diensten en applicaties,
nodig voor de werking
de belastingagent
LoadAgents
Installatie, configuratie en parameterisatie
van de belastingagent.
Of het downloaden van een Docker-image met
een vooraf geconfigureerde belastingbron
Docker-image van de belastingbron
(JMeter, JM of een zelfgeschreven framework)
Configuratieparameters
de belastingagent
Geconfigureerde en geready
voor gebruik belastingagent
Test: fase van het uitvoeren van belastingstests. De bronnen zijn belastingagenten, geïmplementeerd in speciale pools van agenten voor GitLab CI
Load
Start van de belastingagent
met het geselecteerde testplan
en belastingparameters
Gebruikersonderlen
voor initialisatie
de belastingagent
Testplan
Doel van het testen
Uitvoeringslogboeken
van belastingstests
Systeemlogboeken
Dynamiek van veranderingen in doelmetrics en de belastingagent
RunAgents
Uitvoering door de
belastingagent van testscenario's
in overeenstemming met
belastingprofiel
Interactie van de belastingagent
met het testdoel
Testplan
Doel van het testen
Logs
Verzamelen van "ruwe" logs
tijdens belastingtesten:
registraties van de acties van de belastingagent,
de status van het testdoel
en de VM waarop de agent draait
Uitvoeringslogboeken
van belastingstests
Systeemlogboeken
Metrics
Verzamelen van "ruwe" metrics tijdens testen
Dynamiek van veranderingen in doelen
en belastingmetrics
Rapport: fase van de voorbereiding van de testrapportage
Generator
Verwerking van verzamelde
door het belasting systeem en
monitoringsysteem van "ruwe"
metrics en logs
Opstellen van een rapport in
menselijk leesbare vorm,
mogelijk met elementen
van analyse
Uitvoeringslogboeken
van belastingstests
Systeemlogboeken
Dynamiek van veranderingen in metrics
doelen en de belastingagent
Verwerkte "ruwe" logs
in een formaat dat geschikt is voor
export naar externe opslagplaatsen
Statisch rapport over belasting,
geschikt voor menselijke analyse
Publish
Publicatie van het rapport
over de belasting
testen in een externe
dienst
Verwerkte "ruwe"
logs in een bruikbaar formaat
voor export naar externe
opslag
Bewaarde rapporten in externe
opslag over
belasting, geschikt
voor menselijke analyse
Aansluiting van belastingbronnen in CI-sjabloon
Laten we overgaan naar het praktische gedeelte. Ik wil laten zien hoe we in sommige projecten bij het concept van load testing als een service hebben geïmplementeerd.
Eerst hebben onze DevOps-engineers in GitLab CI een speciale pool van agents gemaakt voor het uitvoeren van load tests. Om verwarring met andere pools, zoals bouwpools, te voorkomen, hebben we tags aan deze agents toegevoegd, : load. Elke andere begrijpelijke tag kan gebruikt worden. Ze worden ingesteld van GitLab CI Runners.
Hoe bepaal je de benodigde hardwarecapaciteit? De specificaties van de load agents — het aantal vCPU, RAM en Disk — kunnen worden berekend op basis van het feit dat op de agent Docker, Python (voor Yandex.Tank), de GitLab CI-agent en Java (voor Apache JMeter) moeten draaien. Voor Java onder JMeter wordt ook aangeraden minimaal 512 MB RAM te gebruiken en, als bovengrens, .
Op basis van onze ervaring raden we aan om voor load agents minimaal te gebruiken: 4 vCPU, 4 GB RAM, 60 GB SSD. De bandbreedte van de netwerkadapter wordt bepaald op basis van de eisen van het belastingprofiel.
We gebruiken voornamelijk twee bronnen van belasting — Docker-images van Apache JMeter en Yandex.Tank.
is een open-source tool van Yandex voor load testing. De kern van de modulaire architectuur is een hoogwaardige asynchrone hit-gebaseerde generator van HTTP-verzoeken, Phantom. Tank heeft ingebouwde monitoring van de bronnen van de te testen server via SSH, kan automatische stops van de test op basis van gedefinieerde voorwaarden uitvoeren, kan resultaten zowel in de console als in grafieken weergeven, en kan worden uitgebreid met eigen modules. Overigens hebben we Tank gebruikt voordat het mainstream werd. In het artikel "" kun je het verhaal lezen hoe we in 2013 load testing uitvoerden — een van de producten van ons bedrijf.
JMeter is een open-source tool voor belastingstest van het bedrijf Apache. Het kan even goed worden gebruikt voor het testen van zowel statische als dynamische webapplicaties. JMeter ondersteunt een enorme verscheidenheid aan protocollen en manieren van interactie met applicaties: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, enz.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3(S) en IMAP(S), databases via JDBC, kan shell-commando's uitvoeren en werken met Java-objecten. JMeter beschikt over een IDE voor het creëren, debuggen en uitvoeren van testplannen. Ook is er een CLI voor gebruik in de opdrachtregel van elk Java-compatibel besturingsysteem (Linux, Windows, Mac OS X). De tool kan dynamisch een HTML-rapport over de tests genereren.
Voor gebruiksgemak binnen ons bedrijf, zodat de testers zelf de omgeving kunnen wijzigen en toevoegen, hebben we Docker-image builds voor belastingbronnen gemaakt op GitLab CI met publicatie naar de interne . Hierdoor wordt het sneller en eenvoudiger om ze te koppelen in pipelines voor belastingstests. Hoe je docker push naar de registry via GitLab CI doet, kun je bekijken in de .
De basis Dockerfile voor Yandex.Tank is deze:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]En voor Apache JMeter is deze:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Hoe ons continuous integration-systeem is opgezet, kun je lezen in het artikel "».
Sjabloon en pipeline
Een voorbeeldsjabloon voor het uitvoeren van belastingstests is beschikbaar in het project wordt een tabel met wijzigingen en instructies voor de overgang naar de nieuwe configuratie gegeven. Voor meer informatie, zie kun je de instructies voor het gebruik van het sjabloon lezen. In het sjabloon (bestand ) zijn er opmerkingen over welke stap waarvoor verantwoordelijk is.
Het sjabloon is heel eenvoudig en demonstreert drie fasen van belastingstest, zoals hierboven beschreven in het schema: voorbereiding, testen en rapporteren. Dit wordt uitgevoerd door de : Prepare, Test en Report.
- Fase moet worden gebruikt voor de voorbereiding van de testdoelen of het controleren van hun beschikbaarheid. De omgeving voor belastingbronnen hoeft niet te worden ingesteld, deze zijn van tevoren opgebouwd als Docker-images en zijn gepubliceerd in de Docker registry: je hoeft alleen de gewenste versie op de fase Test aan te geven. Maar het is mogelijk om ze opnieuw te bouwen en je eigen gemodificeerde images te maken.
- Fase wordt gebruikt om de belastingbron aan te geven, tests uit te voeren en testartefacten op te slaan. Elke belastingbron kan worden gekozen: Yandex.Tank, Apache JMeter, een eigen bron of allemaal samen. Om ongewenste bronnen uit te schakelen, volstaat het om de job te commentariëren of te verwijderen. Toegangspunten voor belastingbronnen:
- de opstartparameters van Yandex.Tank worden gespecificeerd in het bestand.,
- de opstartparameters van Apache JMeter worden gespecificeerd in het bestand .
Opmerking: het sjabloon voor de bouwconfiguratie wordt gebruikt om de interactie met het CI-systeem in te stellen en is niet bedoeld om de testlogica daarin te plaatsen. Voor tests wordt een toegangspunt opgegeven waar het beheerscript in bash is. De manier van het uitvoeren van tests, het genereren van rapporten en de testscenario's zelf moeten worden gerealiseerd door QA-engineers. In het demovoorbeeld wordt voor beide belastingbronnen als eenvoudigste test een aanvraag voor de belangrijkste pagina van Yandex gebruikt. Scenario's en testparameters bevinden zich in de map .
- In de fase moet de publicatiemethoden van de testresultaten die in de fase Test zijn verkregen, worden beschreven, naar externe opslagplaatsen, bijvoorbeeld naar GitLab Pages of speciale rapportagesystemen. Voor GitLab Pages is het vereist dat de map .\/public na het beëindigen van de tests niet leeg is en minimaal het bestand index.html bevat. Over de nuances van de werking van de GitLab Pages-service kunt u lezen .
Voorbeelden van hoe gegevens te exporteren:
- van JMeter naar ,
- van Yandex.Tank naar .
Instructies voor het instellen van publicatie:
- HTML-statistieken naar ,
- in InfluxDB en vervolgens naar .
In het demovoorbeeld ziet de pipeline met belastingstests en twee belastingbronnen (waarvan de ongewenste kan worden uitgeschakeld) er als volgt uit:
Apache JMeter kan zelf HTML-rapporten genereren, daarom is het voordeliger om die met de standaard middelen op GitLab Pages op te slaan. Dit is hoe het rapport van Apache JMeter eruit ziet:
In het demovoorbeeld voor Yandex.Tank ziet u alleen in de sectie voor GitLab Pages. Tijdens het testen kan Tank resultaten opslaan in de InfluxDB-database, en daarvandaan kunnen ze bijvoorbeeld in Grafana worden weergegeven (de instelling wordt uitgevoerd in het bestand ). Dit is hoe het rapport van Tank eruit ziet in Grafana:
Samenvatting
In dit artikel heb ik het concept 'load testing as a service' behandeld. Het belangrijkste idee is het gebruik van infrastructuur met vooraf ingestelde pools van belastingagenten, Docker-images van belastingbronnen, rapportagesystemen en een samenvoegende pipeline in GitLab CI op basis van een eenvoudig sjabloon .gitlab-ci.yml (voorbeeld ). Dit wordt ondersteund door een klein team van automatiseringsingenieurs en wordt gerepliceerd op verzoek van productteams. Ik hoop dat dit u helpt bij het voorbereiden en implementeren van een vergelijkbare opzet in uw bedrijf. Bedankt voor uw aandacht!
P.S. Ik wil mijn collega’s, Sergey Kurbanov en Nikolai Yusev, hartelijk bedanken voor hun technische hulp bij de implementatie van het concept load testing as a service in ons bedrijf.
Auteur: — plaatsvervangend hoofd van de afdeling technologie en ontwikkelingsprocessen (DevOps) bij Positive Technologies
Bron: habr.com
