Uno dei problemi che spesso devono affrontare i fornitori di software multiprodotto è la duplicazione delle competenze degli ingegneri (sviluppatori, tester e amministratori dell'infrastruttura) in quasi tutti i team. Questo vale anche per ingegneri costosi, specialisti nel campo dei test di carico.
Invece di svolgere i loro compiti diretti e utilizzare la loro esperienza unica per creare un processo di test di carico, scegliere una metodologia, metriche ottimali e scrivere autotest in conformità con i profili di carico, gli ingegneri spesso devono implementare l'infrastruttura di test da zero, configurare gli strumenti di carico e incorporarli stessi nei sistemi CI, istituire il monitoraggio e la pubblicazione di rapporti.
Puoi trovare soluzioni ad alcuni problemi organizzativi nei test che utilizziamo in Positive Technologies in . E in questo parlerò della possibilità di integrare i test di carico in una pipeline CI comune utilizzando il concetto di "test di carico come servizio" (test di carico come servizio). Imparerai come e quali immagini docker delle origini di caricamento possono essere utilizzate nella pipeline CI; come connettere le origini di caricamento al tuo progetto CI utilizzando un modello di compilazione; come appare la pipeline demo per l'esecuzione dei test di carico e la pubblicazione dei risultati. L'articolo può essere utile per gli ingegneri di test del software e gli ingegneri dell'automazione in CI che stanno pensando all'architettura del loro sistema di carico.
L'essenza del concetto
Il concetto di test di carico come servizio implica la capacità di integrare gli strumenti di carico Apache JMeter, Yandex.Tank e i propri framework in un sistema di integrazione continua arbitrario. La demo sarà per GitLab CI, ma i principi sono comuni a tutti i sistemi CI.
Il test di carico come servizio è un servizio centralizzato per il test di carico. I test di carico vengono eseguiti in pool di agenti dedicati, i risultati vengono pubblicati automaticamente in GitLab Pages, Influx DB e Grafana o nei sistemi di reportistica dei test (TestRail, ReportPortal, ecc.). L'automazione e il ridimensionamento sono implementati nel modo più semplice possibile, aggiungendo e parametrizzando il solito modello gitlab-ci.yml nel progetto GitLab CI.
Il vantaggio di questo approccio è che l'intera infrastruttura CI, gli agenti di caricamento, le immagini docker delle origini di caricamento, le pipeline di test e i report di pubblicazione sono gestiti da un reparto di automazione centralizzato (ingegneri DevOps), mentre gli ingegneri del test di carico possono concentrare i propri sforzi sullo sviluppo dei test e analisi dei loro risultati, senza occuparsi di questioni infrastrutturali.
Per semplicità di descrizione, assumeremo che l'applicazione o il server di destinazione sotto test sia già stato distribuito e configurato in anticipo (a questo scopo possono essere utilizzati script automatizzati in Python, SaltStack, Ansible, ecc.). Quindi l'intero concetto di test di carico come servizio si inserisce in tre fasi: preparazione, collaudo, pubblicazione di report. Maggiori dettagli sul diagramma (tutte le immagini sono cliccabili):
Concetti e definizioni di base nei test di carico
Quando eseguiamo i test di carico, cerchiamo di attenerci , utilizzare la terminologia appropriata e le metriche consigliate. Darò un breve elenco dei concetti e delle definizioni principali nei test di carico.
Agente di carico - una macchina virtuale su cui verrà avviata l'applicazione - l'origine di caricamento (Apache JMeter, Yandex.Tank o un modulo di caricamento autoscritto).
Obiettivo del test (target) - server o applicazione installata sul server che sarà soggetta a carico.
Scenario di test (caso di test) - una serie di passaggi parametrizzati: azioni dell'utente e reazioni attese a queste azioni, con richieste e risposte di rete fisse, a seconda dei parametri specificati.
Profilo o piano di carico (profilo) - in (Sezione 4.2.4, p. 43) i profili di carico definiscono le metriche critiche per un particolare test e le opzioni per modificare i parametri di carico durante il test. Puoi vedere esempi di profili nella figura.
Test — uno script con una serie predeterminata di parametri.
Piano di test (piano di test) - una serie di test e un profilo di carico.
Testran (testrun) - un'iterazione dell'esecuzione di un test con uno scenario di carico completamente eseguito e il report ricevuto.
Richiesta di rete (richiesta) — Una richiesta HTTP inviata da un agente a una destinazione.
Risposta della rete (risposta) — Una risposta HTTP inviata dalla destinazione all'agente.
Codice di risposta HTTP (stato delle risposte HTTP): codice di risposta standard dal server delle applicazioni.
Una transazione è un ciclo completo di richiesta-risposta. Una transazione viene conteggiata dall'inizio dell'invio di una richiesta (request) al completamento della ricezione di una risposta (response).
Stato della transazione - se è stato possibile completare con successo il ciclo richiesta-risposta. Se si è verificato un errore in questo ciclo, l'intera transazione è considerata non riuscita.
Tempo di risposta (latenza) - il tempo dalla fine dell'invio di una richiesta (richiesta) all'inizio della ricezione di una risposta (risposta).
Carica metriche — le caratteristiche del servizio caricato e l'agente di carico determinato nel processo di test di carico.
Metriche di base per la misurazione dei parametri di carico
Alcuni dei più comunemente usati e consigliati nella metodologia (p. 36, 52) le metriche sono mostrate nella tabella sottostante. Metriche simili per agente e destinazione sono elencate sulla stessa riga.
Metriche per l'agente di caricamento
Metriche del sistema di destinazione o dell'applicazione testata sotto carico
numero CPU virtuale e memoria RAM,
Disco - caratteristiche "ferriche" dell'agente di carico
CPU, Memoria, utilizzo del disco - dinamica della CPU, della memoria e del caricamento del disco
in fase di test. Solitamente misurato come percentuale di
valori massimi disponibili
Velocità di trasmissione della rete (sull'agente di caricamento) - throughput
interfaccia di rete sul server,
dove è installato l'agente di caricamento.
Solitamente misurato in byte al secondo (bps)
Velocità di trasmissione della rete(sul target) - larghezza di banda dell'interfaccia di rete
sul server di destinazione. Solitamente misurato in byte al secondo (bps)
Utenti virtuali- il numero di utenti virtuali,
implementazione di scenari di carico e
imitando le azioni degli utenti reali
Stato degli utenti virtuali, Superato/Non riuscito/Totale — numero di riusciti e
stati non riusciti degli utenti virtuali
per gli scenari di carico, nonché il loro numero totale.
In genere si prevede che tutti gli utenti siano stati in grado di completare
tutte le attività specificate nel profilo di carico.
Qualsiasi errore significherà che un utente reale non sarà in grado di farlo
risolvere il problema quando si lavora con il sistema
Richieste al secondo (minuto)- il numero di richieste di rete al secondo (o minuto).
Una caratteristica importante di un agente di caricamento è il numero di richieste che può generare.
In realtà, questa è un'imitazione dell'accesso all'applicazione da parte di utenti virtuali
Risposte al secondo (minuto)
- il numero di risposte di rete al secondo (o minuto).
Una caratteristica importante del servizio target: quanto
generare e inviare risposte alle query con
agente di caricamento
Stato della risposta HTTP— numero di diversi codici di risposta
dal server delle applicazioni ricevuto dall'agente di caricamento.
Ad esempio, 200 OK indica una chiamata andata a buon fine,
e 404 - che la risorsa non è stata trovata
Latenza (tempo di risposta) - tempo dalla fine
inviare una richiesta (request) prima di iniziare a ricevere una risposta (response).
Solitamente misurato in millisecondi (ms)
Tempo di risposta della transazione— tempo di una transazione completa,
completamento del ciclo richiesta-risposta.
Questo è il tempo dall'inizio dell'invio della richiesta (richiesta)
fino al completamento della ricezione di una risposta (risposta).
Il tempo di transazione può essere misurato in secondi (o minuti)
in diversi modi: considera il minimo,
massimo, medio e, ad esempio, il 90° percentile.
Le letture minime e massime sono estreme
stato delle prestazioni del sistema.
Il novantesimo percentile è il più comunemente usato,
come mostra la maggior parte degli utenti,
operando comodamente alla soglia delle prestazioni del sistema
Transazioni al secondo (minuto) - il numero di completi
transazioni al secondo (minuto),
cioè quanto l'applicazione è stata in grado di accettare e
elaborare le richieste ed emettere le risposte.
In effetti, questo è il throughput del sistema
Stato della transazione , Superato / Fallito / Totale - numero
riuscite, non riuscite e il numero totale di transazioni.
Per gli utenti reali senza successo
la transazione significherà effettivamente
incapacità di lavorare con il sistema sotto carico
Diagramma schematico del test di carico
Il concetto di test di carico è molto semplice e si compone di tre fasi principali, che ho già citato: Preparare il rapporto di prova, ovvero, preparare gli obiettivi del test e impostare i parametri per le origini di carico, quindi eseguire i test di carico e, infine, generare e pubblicare un rapporto di test.
Note schematiche:
- QA.Tester è un esperto in test di carico,
- Target è l'applicazione di destinazione di cui si desidera conoscere il comportamento sotto carico.
Classificatore di entità, fasi e passaggi nel diagramma
Fasi e passaggi
Cosa succede
Cosa c'è all'ingresso
Qual è l'output
Preparare: fase di preparazione per il test
Carica parametri
Impostazione e inizializzazione
per utente
parametri di caricamento,
scelta delle metriche e
preparazione del piano di prova
(caricamento profilo)
Opzioni personalizzate per
inizializzazione dell'agente di caricamento
Piano di prova
Scopo del test
VM
Distribuzione cloud
macchina virtuale con
caratteristiche richieste
Impostazioni della macchina virtuale per l'agente di caricamento
Script di automazione per
creazione della macchina virtuale
VM configurata in
nuvola
Inviluppo
Installazione e preparazione del sistema operativo
ambiente per
caricare il lavoro dell'agente
Impostazioni dell'ambiente per
agente di carico
Script di automazione per
impostazioni dell'ambiente
Ambiente preparato:
OS, servizi e applicazioni,
necessario per il lavoro
agente di carico
LoadAgent
Installazione, configurazione e parametrizzazione
agente di caricamento.
O scaricando un'immagine docker da
origine di caricamento preconfigurata
Carica l'immagine della finestra mobile di origine
(YAT, JM o framework autoprodotto)
Impostazioni
agente di carico
Montato e pronto
all'agente del carico di lavoro
Test: fase di esecuzione dei test di carico. Le origini sono agenti di caricamento distribuiti in pool di agenti dedicati per GitLab CI
Caricare
Avvio dell'agente di caricamento
con il piano di test selezionato
e caricare i parametri
Opzioni utente
per l'inizializzazione
agente di carico
Piano di prova
Scopo del test
Log di esecuzione
prove di carico
Registri di sistema
Dinamica dei cambiamenti nelle metriche degli obiettivi e nell'agente di carico
Esegui agenti
Esecuzione dell'agente
un sacco di script di test
secondo
caricamento profilo
Carica l'interazione con l'agente
ai fini del test
Piano di prova
Scopo del test
Registri
Raccolta di registri "grezzi".
durante il test di carico:
caricare i record delle attività dell'agente,
stato del bersaglio di prova
e la macchina virtuale che esegue l'agente
Log di esecuzione
prove di carico
Registri di sistema
Metrica
Raccolta di metriche "grezze" durante i test
Dinamica dei cambiamenti nelle metriche degli obiettivi
e agente di carico
Report: fase di preparazione del rapporto di prova
Generatore
Elaborazione raccolti
sistema di caricamento e
sistema di monitoraggio "grezzo"
metriche e log
Formazione di un rapporto in
forma leggibile dall'uomo
possibile con gli elementi
analisti
Log di esecuzione
prove di carico
Registri di sistema
Dinamica dei cambiamenti nelle metriche
destinazione e agente di caricamento
Log "grezzi" elaborati
in un formato adatto a
caricamenti su memoria esterna
Rapporto di carico statico,
leggibile dagli umani
Pubblica
Pubblicazione del rapporto
sul carico
collaudo in esterno
servizio
Elaborato "crudo"
registri in un formato adatto
per lo scarico all'esterno
repository
Salvato in esterno
rapporti di archiviazione su
carico, adatto
per l'analisi umana
Collegamento delle origini di carico nel modello CI
Passiamo alla parte pratica. Voglio mostrare come su alcuni progetti in azienda abbiamo implementato il concetto di test di carico come servizio.
Innanzitutto, con l'aiuto dei nostri ingegneri DevOps, abbiamo creato un pool dedicato di agenti in GitLab CI per eseguire i test di carico. Per non confonderli nei modelli con altri, come i pool di assembly, abbiamo aggiunto tag a questi agenti, : carico. Puoi utilizzare qualsiasi altro tag comprensibile. Loro chiedono GitLab CI Runner.
Come scoprire la potenza richiesta dall'hardware? Le caratteristiche degli agenti di caricamento - un numero sufficiente di vCPU, RAM e disco - possono essere calcolate in base al fatto che Docker, Python (per Yandex.Tank), agente GitLab CI, Java (per Apache JMeter) dovrebbero essere in esecuzione sull'agente . Per Java sotto JMeter, si consiglia inoltre di utilizzare un minimo di 512 MB di RAM e, come limite massimo, .
Pertanto, in base alla nostra esperienza, consigliamo di utilizzare almeno 4 vCPU, 4 GB di RAM, 60 GB di SSD per gli agenti di caricamento. Il throughput della scheda di rete viene determinato in base ai requisiti del profilo di carico.
Utilizziamo principalmente due origini di caricamento: Apache JMeter e immagini docker Yandex.Tank.
è uno strumento open source di Yandex per i test di carico. La sua architettura modulare si basa sul generatore di richieste HTTP asincrono basato su hit ad alte prestazioni di Phantom. Il serbatoio ha un monitoraggio integrato delle risorse del server in prova tramite il protocollo SSH, può interrompere automaticamente il test in condizioni specificate, può visualizzare i risultati sia nella console che sotto forma di grafici, puoi collegare i tuoi moduli ad esso per espandere la funzionalità. A proposito, abbiamo usato il Tank quando non era ancora mainstream. Nell'articolo "» puoi leggere la storia di come abbiamo eseguito i test di carico con esso nel 2013 è uno dei prodotti della nostra azienda.
è uno strumento di test di carico open source di Apache. Può essere utilizzato altrettanto bene per testare applicazioni web sia statiche che dinamiche. JMeter supporta un numero enorme di protocolli e modi per interagire con le applicazioni: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ecc.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) e IMAP(S), database via JDBC, possono eseguire comandi shell e lavorare con oggetti Java. JMeter ha un IDE per la creazione, il debug e l'esecuzione di piani di test. C'è anche una CLI per il funzionamento della riga di comando su qualsiasi sistema operativo compatibile con Java (Linux, Windows, Mac OS X). Lo strumento può generare dinamicamente un rapporto di prova HTML.
Per facilità di utilizzo all'interno della nostra azienda, per la capacità degli stessi tester di modificare e aggiungere l'ambiente, abbiamo realizzato build di immagini docker di sorgenti di caricamento su GitLab CI con pubblicazione all'interno . In questo modo è più facile e veloce collegarli nelle pipeline per i test di carico. Come eseguire il push docker al registro tramite GitLab CI - vedere .
Abbiamo preso questo file docker di base per Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]E per Apache JMeter questo:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Puoi leggere come funziona il nostro sistema di integrazione continua nell'articolo "'.
Modello e pipeline
Nel progetto è disponibile un esempio di modello per l'esecuzione di prove di carico . In Puoi leggere le istruzioni per l'utilizzo del modello. Nel modello stesso (file ) ci sono note su ciò di cui è responsabile ogni passaggio.
Il modello è molto semplice e illustra le tre fasi del test di carico descritte nel diagramma precedente: preparazione, test e pubblicazione dei report. Responsabile di questo : Preparare, testare e segnalare.
- Palcoscenico dovrebbe essere utilizzato per preconfigurare gli obiettivi di test o verificarne la disponibilità. L'ambiente per le origini di caricamento non ha bisogno di essere configurato, sono pre-costruite come immagini docker e pubblicate nel registro docker: basta specificare la versione desiderata nella fase di test. Ma puoi ricostruirli e creare le tue immagini modificate.
- Palcoscenico utilizzato per specificare l'origine di caricamento, eseguire test e archiviare artefatti di test. Puoi scegliere qualsiasi sorgente di caricamento: Yandex.Tank, Apache JMeter, la tua o tutte insieme. Per disabilitare le fonti non necessarie, basta commentare o eliminare il lavoro. Punti di ingresso per le origini di caricamento:
- I parametri di avvio per Yandex.Tank sono specificati nel file .,
- I parametri di avvio di Apache JMeter sono specificati nel file .
Nota: il modello di configurazione dell'assieme viene utilizzato per impostare l'interazione con il sistema CI e non implica il posizionamento della logica di test al suo interno. Per i test, viene specificato il punto di ingresso, dove si trova lo script bash di controllo. Il metodo di esecuzione dei test, la generazione dei report e gli stessi script di test devono essere implementati dai tecnici QA. Nella demo, per entrambe le origini di caricamento, la richiesta della pagina principale di Yandex viene utilizzata come test più semplice. Gli script ei parametri di test si trovano nella directory .
- In scena è necessario descrivere come pubblicare i risultati del test ottenuti nella fase di test su archivi esterni, ad esempio su pagine GitLab o speciali sistemi di reportistica. GitLab Pages richiede che la directory ./public non sia vuota e contenga almeno un file index.html al termine dei test. Puoi leggere le sfumature del servizio GitLab Pages. .
Esempi di come esportare i dati:
- da JMeter a ,
- da Yandex.Tank a .
Istruzioni per la configurazione della pubblicazione:
- Statica HTML in ,
- a InfluxDB e poi a .
Nell'esempio demo, la pipeline con i test di carico e due origini di caricamento (è possibile disabilitare quella non necessaria) si presenta così:
Apache JMeter può generare autonomamente un report HTML, quindi è più redditizio salvarlo in GitLab Pages utilizzando strumenti standard. Ecco come appare il rapporto Apache JMeter:
Nell'esempio demo per Yandex.Tank, vedrai solo nella sezione per le pagine GitLab. Durante il test, Tank può salvare i risultati nel database InfluxDB e da lì possono essere visualizzati, ad esempio, in Grafana (la configurazione viene eseguita nel file ). Ecco come appare il rapporto di Tank a Grafana:
Riassunto
Nell'articolo ho parlato del concetto di "test di carico come servizio" (test di carico come servizio). L'idea principale è utilizzare l'infrastruttura di pool preconfigurati di agenti di caricamento, immagini docker di origini di caricamento, sistemi di reportistica e una pipeline che li combini in GitLab CI sulla base di un semplice modello .gitlab-ci.yml (esempio ). Tutto questo è supportato da un piccolo team di ingegneri dell'automazione e replicato su richiesta dei team di prodotto. Spero che questo ti aiuti a preparare e implementare uno schema simile nella tua azienda. Grazie per l'attenzione!
PS Voglio ringraziare di cuore i miei colleghi, Sergey Kurbanov e Nikolai Yusev, per l'assistenza tecnica con l'implementazione del concetto di test di carico come servizio nella nostra azienda.
autore: - Vice Responsabile dei processi tecnologici e di sviluppo (DevOps) presso Positive Technologies
Fonte: habr.com