Una dintre problemele cu care se confruntă adesea furnizorii de software cu mai multe produse este duplicarea competențelor inginerilor - dezvoltatori, testeri și administratori de infrastructură - în aproape fiecare echipă. Acest lucru este valabil și pentru inginerii scumpi - specialiști în domeniul testării sarcinii.
În loc să-și facă responsabilitățile directe și să-și folosească experiența unică pentru a construi un proces de testare a încărcăturii, pentru a alege o metodologie, valori optime de măsură și pentru a scrie autotestări în conformitate cu profilurile de încărcare, inginerii trebuie adesea să implementeze o infrastructură de testare de la zero, să configureze instrumentele de încărcare. , și să le încorporeze ei înșiși în sistemele CI, să configureze monitorizarea și publicarea rapoartelor.
Soluțiile la unele probleme organizaționale în testare pe care le folosim la Positive Technologies pot fi găsite în . Și în acest articol voi vorbi despre posibilitatea integrării testelor de sarcină într-o conductă CI comună folosind conceptul de „testare de încărcare ca serviciu”. Veți afla cum și ce imagini docker ale surselor de încărcare pot fi utilizate într-o conductă CI; cum să conectați sursele de încărcare la proiectul dvs. CI folosind un șablon de asamblare; cum arată conducta demonstrativă pentru rularea testelor de încărcare și publicarea rezultatelor. Articolul poate fi util inginerilor de testare software și inginerilor de automatizare din CI care se gândesc la arhitectura sistemului lor de încărcare.
Esența conceptului
Conceptul de testare a încărcăturii ca serviciu implică capacitatea de a integra instrumentele de testare a încărcăturii Apache JMeter, Yandex.Tank și propriile cadre într-un sistem arbitrar de integrare continuă. Demo-ul va fi pentru GitLab CI, dar principiile subliniate sunt comune tuturor sistemelor CI.
Testarea de sarcină ca serviciu este un serviciu centralizat pentru testarea de încărcare. Testele de încărcare sunt rulate în grupuri de agenți dedicate, iar rezultatele sunt publicate automat în GitLab Pages, Influx DB și Grafana sau în sistemele de raportare a testelor (TestRail, ReportPortal etc.). Automatizarea și scalarea sunt implementate cât mai simplu posibil - prin adăugarea și parametrizarea șablonului obișnuit gitlab-ci.yml în proiectul GitLab CI.
Avantajul abordării este că întreaga infrastructură CI, agenții de încărcare, imaginile docker ale surselor de încărcare, conductele de testare și publicarea rapoartelor sunt susținute de un departament de automatizare centralizat (ingineri DevOps), iar inginerii de testare a încărcăturii își pot concentra eforturile pe dezvoltarea testelor și analizându-le rezultatele fără a se ocupa de problemele de infrastructură.
Pentru simplitatea descrierii, vom presupune că aplicația țintă sau serverul testat a fost deja implementat și configurat în prealabil (pentru aceasta, pot fi folosite scripturi automate în Python, SaltStack, Ansible etc.). Apoi, întregul concept de testare a sarcinii ca serviciu se încadrează în trei etape: pregătirea, testarea, publicarea rapoartelor. Mai multe detalii în diagramă (toate imaginile se pot face clic):
Concepte și definiții de bază în testarea sarcinii
Când efectuăm teste de sarcină, încercăm să respectăm , folosim terminologia adecvată și valorile recomandate. Voi oferi o scurtă listă a principalelor concepte și definiții în testarea sarcinii.
Agent de încărcare — o mașină virtuală pe care va rula aplicația — o sursă de încărcare (Apache JMeter, Yandex.Tank sau un modul de încărcare auto-scris).
Țintă de testare - un server sau o aplicație instalată pe un server care va fi supus încărcării.
Scenariu de testare (caz de testare) — un set de pași parametrizați: acțiuni ale utilizatorului și reacții așteptate la aceste acțiuni, cu solicitări și răspunsuri de rețea înregistrate, în funcție de parametrii specificați.
Profil sau plan de încărcare (profil) - în (clauza 4.2.4, p. 43) profilele de sarcină determină valorile critice pentru un anumit test și opțiunile pentru modificarea parametrilor de sarcină în timpul testului. Puteți vedea exemple de profiluri în figură.
Test — un scenariu cu un set predeterminat de parametri.
Planul de testare — un set de teste și profil de sarcină.
Testrun — o iterație a executării unui test cu un scenariu de încărcare complet executat și un raport primit.
Solicitarea rețelei — O solicitare HTTP trimisă de la agent către țintă.
Răspunsul rețelei — Un răspuns HTTP trimis de la țintă la agent.
Starea răspunsului HTTP - cod de răspuns standard de la serverul de aplicații.
O tranzacție este un ciclu complet cerere-răspuns. O tranzacție este contorizată de la începutul trimiterii unei cereri și până la finalizarea primirii unui răspuns.
starea tranzacțiilor — dacă a fost posibilă finalizarea cu succes a ciclului „cerere-răspuns”. Dacă a existat vreo eroare în acest ciclu, atunci întreaga tranzacție este considerată nereușită.
Timp de răspuns (latență) — timpul de la sfârșitul trimiterii unei cereri și până la începutul primirii unui răspuns.
Încărcați valorile — caracteristicile serviciului încărcat și ale agentului de sarcină determinate în timpul încercării de sarcină.
Măsuri de bază pentru măsurarea parametrilor de sarcină
Unele dintre cele mai frecvent utilizate și recomandate în metodologie (paginile 36, 52) sunt afișate în tabelul de mai jos. Valori similare pentru agent și țintă sunt listate pe aceeași linie.
Încărcați valorile agentului
Măsuri ale sistemului sau aplicației țintă aflate în testare la sarcină
Număr vCPU si memorie RAM,
Disc — caracteristicile „fierului” ale agentului de încărcare
Procesor, Memorie, utilizarea discului — dinamica procesorului, memoriei și încărcării discului
în timpul testării. De obicei, măsurată ca procent de
valorile maxime disponibile
Debitul rețelei (pe agent de încărcare) - debit
interfață de rețea pe server,
unde este instalat agentul de încărcare.
De obicei, măsurată în octeți pe secundă (bps)
Debitul rețelei(la țintă) — lățime de bandă a interfeței de rețea
pe serverul țintă. De obicei, măsurată în octeți pe secundă (bps)
Utilizatori virtuali— numărul de utilizatori virtuali,
implementarea scenariilor de încărcare și
simulând acțiunile reale ale utilizatorului
Starea utilizatorilor virtuali, Trecut/Eșuat/Total - numărul de reușite și
stări nereușite ale utilizatorilor virtuali
pentru scenariile de încărcare, precum și numărul lor total.
În general, este de așteptat ca toți utilizatorii să fi putut finaliza
toate sarcinile dvs. specificate în profilul de încărcare.
Orice eroare va însemna că utilizatorul real nu va putea
rezolvați-vă problema când lucrați cu sistemul
Solicitări pe secundă (minut)— numărul de solicitări de rețea pe secundă (sau minut).
O caracteristică importantă a unui agent de încărcare este câte solicitări poate genera.
De fapt, aceasta este o imitație a accesului la aplicație de către utilizatorii virtuali
Răspunsuri pe secundă (minut)
— numărul de răspunsuri ale rețelei pe secundă (sau minut).
O caracteristică importantă a serviciului țintă: cât de mult a avut succes
generați și trimiteți răspunsuri la solicitări cu
agent de încărcare
Starea răspunsurilor HTTP— numărul de coduri de răspuns diferite
de la serverul de aplicații primit de agentul de încărcare.
De exemplu, 200 OK înseamnă o solicitare reușită,
și 404 - că resursa nu a fost găsită
Latență (timp de răspuns) - timp de la finalizare
trimiterea unei cereri înainte de a primi un răspuns.
De obicei, măsurată în milisecunde (ms)
Timpul de răspuns la tranzacție— timpul unei tranzacții complete,
finalizarea ciclului cerere-răspuns.
Acesta este timpul de la începutul trimiterii cererii (cererii)
până la primirea răspunsului.
Timpul tranzacției poate fi măsurat în secunde (sau minute)
în mai multe moduri: luați în considerare minimul,
maxim, mediu și, de exemplu, percentila 90.
Citirile minime și maxime sunt extreme
starea performanței sistemului.
Percentila nouăzecea este cea mai frecvent utilizată
deoarece arată majoritatea utilizatorilor,
lucru confortabil la pragul performanței sistemului
Tranzacții pe secundă (minut) - numărul de complete
tranzacții pe secundă (minut),
adică cât de mult a putut accepta cererea și
procesează cererile și emite răspunsuri.
De fapt, acesta este debitul sistemului
Starea tranzacțiilor , Trecut / Eșuat / Total - cantitate
de succes, nereușit și numărul total de tranzacții.
Nereușită pentru utilizatorii reali
tranzacția va însemna de fapt
incapacitatea de a lucra cu sistemul sub sarcină
Schema schematică a încercării de sarcină
Conceptul de testare a sarcinii este foarte simplu și constă din trei etape principale, pe care le-am menționat deja: Pregătire - Testare - Raportare, adică pregătirea țintelor de testare și setarea parametrilor pentru sursele de încărcare, apoi efectuarea testelor de sarcină și, în final, generarea și publicarea unui raport de testare.
Note asupra diagramei:
- QA.Tester - expert în testarea sarcinii,
- Target este aplicația țintă pentru care doriți să-i cunoașteți comportamentul la încărcare.
Clasificator de entități, etape și pași din diagramă
Etape și pași
Ce se întâmplă
Ce este la intrare
Care este rezultatul
Pregătire: etapa de pregătire pentru testare
LoadParameters
Setare și inițializare
utilizator
parametrii de încărcare,
selecția de metrici și
pregătirea planului de testare
(incarca profilul)
Opțiuni personalizate pentru
inițializarea agentului de încărcare
Planul de testare
Scopul testării
VM
Implementare în cloud
mașină virtuală cu
caracteristicile cerute
Parametrii VM pentru agentul de încărcare
Scripturi de automatizare pentru
crearea unui VM
VM configurată în
nor
Plic
Configurarea și pregătirea sistemului de operare
mediu pentru
funcționarea agentului de încărcare
Setări de mediu pentru
agent de încărcare
Scripturi de automatizare pentru
setările mediului
Mediu pregătit:
OS, servicii și aplicații,
necesare muncii
agent de încărcare
LoadAgents
Instalare, configurare si parametrizare
agent de încărcare.
Sau descărcați imaginea docker de pe
sursă de încărcare preconfigurată
Încărcați imaginea docker sursă
(YAT, JM sau cadru auto-scris)
Setări
agent de încărcare
Configurați și gata
agentul de încărcare să lucreze
Test: etapa de executare a testelor de sarcină. Sursele sunt agenți de încărcare implementați în pool-uri de agenți dedicate pentru GitLab CI
A incarca
Pornirea agentului de încărcare
cu planul de testare selectat
și parametrii de încărcare
Opțiuni personalizate
pentru inițializare
agent de încărcare
Planul de testare
Scopul testării
Jurnalele de execuție
teste de sarcină
Jurnalele de sistem
Dinamica modificărilor în valorile țintă și agent de încărcare
RunAgents
Executarea de către agent
sarcinile de caz de testare
în conformitate cu
incarca profilul
Interacțiunea agentului de încărcare
în scop de testare
Planul de testare
Scopul testării
Activitate
Colectare de bușteni „bruți”.
în timpul testării de sarcină:
înregistrări ale acțiunilor agentului de încărcare,
starea țintei de testare
și VM-ul pe care rulează agentul
Jurnalele de execuție
teste de sarcină
Jurnalele de sistem
Metrici
Colectarea valorilor „brute” în timpul testării
Dinamica schimbărilor în valorile obiectivelor
și agent de încărcare
Raport: etapa de pregătire a raportului de testare
Generator
Prelucrarea colectate
sistem de încărcare și
sistem de monitorizare pentru „raw”
metrici și jurnalele
Generarea unui raport în
formă lizibilă de om,
posibil cu elemente
analiști
Jurnalele de execuție
teste de sarcină
Jurnalele de sistem
Dinamica schimbărilor în metrici
țintă și agent de încărcare
Bușteni bruti prelucrați
într-un format potrivit pentru
încărcare pe stocare externă
Raport de sarcină statică,
uman-analizabil
Publica
Publicarea raportului
despre sarcină
testare externă
serviciu
Procesat „brut”
jurnalele într-un format adecvat
pentru descărcare în exterior
bolti
Salvat în extern
rapoarte de stocare
sarcina, potrivita
pentru analiza umană
Conectarea surselor de încărcare într-un șablon CI
Să trecem la partea practică. Vreau să arăt cum în unele proiecte din companie am implementat conceptul de testare a sarcinii ca serviciu.
În primul rând, cu ajutorul inginerilor noștri DevOps, am creat un grup dedicat de agenți în GitLab CI pentru a rula teste de încărcare. Pentru a nu le confunda în șabloane cu alte, de exemplu, grupuri de asamblare, am adăugat etichete acestor agenți, : sarcină. Puteți folosi orice alte etichete ușor de înțeles. Ei se întreabă GitLab CI Runners.
Cum să aflați puterea necesară de la hardware? Caracteristicile agenților de încărcare - un număr suficient de vCPU, RAM și disc - pot fi calculate pe baza faptului că agentul trebuie să ruleze Docker, Python (pentru Yandex.Tank), agent GitLab CI, Java (pentru Apache JMeter). Pentru Java sub JMeter se recomandă, de asemenea, utilizarea unui minim de 512 MB RAM și, ca limită superioară, .
Astfel, pe baza experienței noastre, vă recomandăm să folosiți cel puțin: 4 vCPU-uri, 4 GB RAM, 60 GB SSD pentru agenții de încărcare. Debitul plăcii de rețea este determinat în funcție de cerințele profilului de încărcare.
Utilizăm în principal două surse de încărcare - Apache JMeter și imagini docker Yandex.Tank.
este un instrument open source de la Yandex pentru testarea încărcării. Arhitectura sa modulară se bazează pe generatorul de solicitări HTTP Phantom asincron asincron de înaltă performanță. Rezervorul are monitorizare încorporată a resurselor serverului testat prin protocolul SSH, poate opri automat testul în funcție de condițiile specificate, poate scoate rezultate atât în consolă, cât și sub formă de grafice și vă puteți conecta propriile dvs. module pentru a extinde funcționalitatea. Apropo, am folosit Tank când nu era încă mainstream. In articol "» puteți citi povestea despre cum în 2013 am efectuat teste de încărcare cu ajutorul acestuia - unul dintre produsele companiei noastre.
este un instrument open source de testare a încărcării pentru Apache. Poate fi folosit la fel de bine pentru testarea aplicațiilor web statice și dinamice. JMeter acceptă un număr mare de protocoale și metode de interacțiune cu aplicații: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET etc.), Servicii web SOAP/REST, FTP, TCP, LDAP, SMTP(S), POP3( S ) și IMAP(S), baze de date prin JDBC, pot executa comenzi shell și pot lucra cu obiecte Java. JMeter are un IDE pentru crearea, depanarea și executarea planurilor de testare. Există, de asemenea, un CLI pentru a lucra pe linia de comandă a oricărui sistem de operare compatibil Java (Linux, Windows, Mac OS X). Instrumentul poate genera dinamic un raport de testare HTML.
Pentru ușurința de utilizare în cadrul companiei noastre, astfel încât testerii înșiși să poată schimba și adăuga mediul, am construit imagini docker ale surselor de încărcare pe GitLab CI cu publicare în interiorul . Acest lucru face mai rapidă și mai ușoară conectarea lor în conducte pentru testele de sarcină. Cum se efectuează un push docker către registry prin GitLab CI - vezi .
Am luat acest fișier docker de bază pentru Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Și pentru Apache JMeter asta:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Puteți citi cum funcționează sistemul nostru de integrare continuă în articolul „".
Șablon și conductă
Un exemplu de șablon pentru efectuarea testelor de sarcină este disponibil în proiect . În Puteți citi instrucțiunile de utilizare a șablonului. În șablonul în sine (fișier ) există note despre ceea ce este responsabil pentru fiecare pas.
Șablonul este foarte simplu și demonstrează cele trei etape ale testării sarcinii descrise în diagrama de mai sus: pregătirea, testarea și publicarea rapoartelor. Ei sunt responsabili pentru asta : Pregătiți, testați și raportați.
- etapă ar trebui utilizat pentru a pre-seta ținte de testare sau pentru a verifica disponibilitatea acestora. Nu este nevoie să configurați mediul pentru sursele de încărcare, acestea sunt pre-construite ca imagini docker și postate în registrul docker: trebuie doar să specificați versiunea dorită în etapa de testare. Dar le puteți reconstrui și face propriile imagini modificate.
- etapă folosit pentru a specifica sursa de încărcare, pentru a rula teste și pentru a salva artefactele de testare. Puteți alege orice sursă de încărcare: Yandex.Tank, Apache JMeter, propria dvs. sau toate împreună. Pentru a dezactiva sursele inutile, trebuie doar să comentați sau să ștergeți jobul. Puncte de intrare pentru sursele de încărcare:
- Parametrii de lansare Yandex.Tank sunt specificați în .,
- Parametrii de lansare Apache JMeter sunt specificați în fișier .
Notă: șablonul de configurare a ansamblului este utilizat pentru a configura interacțiunea cu sistemul CI și nu implică plasarea logicii de testare în acesta. Pentru teste, este indicat punctul de intrare, unde se află scriptul control bash. Metoda de rulare a testelor, generarea de rapoarte și scripturile de testare în sine trebuie implementate de inginerii QA. În exemplul demonstrativ, pentru ambele surse de încărcare, o solicitare din pagina principală Yandex este folosită ca un test simplu. Scripturile și parametrii de testare sunt în director .
- La scenă trebuie să descrieți modalități de a publica rezultatele testării obținute în etapa de testare în depozite externe, de exemplu, pagini GitLab sau sisteme speciale de raportare. GitLab Pages necesită ca directorul ./public să nu fie gol și să conțină cel puțin un fișier index.html când testele sunt finalizate. Puteți citi despre nuanțele serviciului GitLab Pages .
Exemple de cum să exportați date:
- de la JMeter la ,
- de la Yandex.Tank la .
Instrucțiuni pentru crearea unei publicații:
- Statistici HTML în ,
- către InfluxDB și apoi către .
În exemplul demonstrativ, conducta cu teste de încărcare și două surse de încărcare (puteți să o dezactivați pe cea inutilă) arată astfel:
Apache JMeter poate genera singur un raport HTML, deci este mai profitabil să îl salvați în GitLab Pages folosind instrumente standard. Iată cum arată raportul Apache JMeter:
În exemplul demonstrativ pentru Yandex.Tank veți vedea doar în secțiunea pentru Pagini GitLab. În timpul procesului de testare, Tank poate salva rezultatele în baza de date InfluxDB, iar de acolo pot fi afișate, de exemplu, în Grafana (setarea se face în fișier ). Iată cum arată raportul Tank în Grafana:
Rezumat
În articol am vorbit despre conceptul de „testare de încărcare ca serviciu”. Ideea principală este să folosiți infrastructura pool-urilor preconfigurate de agenți de încărcare, imagini docker ale surselor de încărcare, sisteme de raportare și o conductă care le combină în GitLab CI pe baza unui șablon simplu .gitlab-ci.yml (exemplu ). Toate acestea sunt susținute de o echipă mică de ingineri de automatizare și replicate la cererea echipelor de produs. Sper că acest lucru vă va ajuta în pregătirea și implementarea unei scheme similare în compania dumneavoastră. Vă mulțumesc pentru atenție!
PS Aș dori să le mulțumesc foarte mult colegilor mei, Serghei Kurbanov și Nikolai Yusev, pentru asistența tehnică acordată în implementarea testării sarcinii ca concept de serviciu în compania noastră.
Autor: - deputat Şeful Departamentului Tehnologie şi Procese de Dezvoltare (DevOps) la Positive Technologies
Sursa: www.habr.com
