come testare i test di automazione dei microservizi

Quando i test automatizzati del microservizio iniziano a "abbandonare la catena"

Immagina questo: la nuova funzionalità che hai appena lanciato ha funzionato senza intoppi, ma pochi giorni dopo l'elaborazione degli ordini ha improvvisamente rallentato di mezzo battito. Dopo un po', l'interfaccia di pagamento ha segnalato inspiegabilmente un errore. Dopo aver controllato più e più volte, abbiamo scoperto che non c'era un problema con il codice stesso, ma che c'era qualcosa di sbagliato nella collaborazione tra i vari microservizi: un servizio era aggiornato e l'altro non riusciva a tenere il passo; un'interfaccia ha cambiato i suoi parametri e il modulo che la chiamava utilizzava ancora le vecchie regole. A questo punto potresti pensare quanto sarebbe meno preoccupante se potessi individuare il problema prima che si presenti.

Questo è lo scopo del test automatizzato dei microservizi. Non si tratta solo di scrivere alcuni script ed eseguirli. È come conoscere la propria cucina, sapere quale ruolo gioca ogni servizio nell'intero sistema e come dialogare tra loro. Ancora più importante, il test deve "muoversi" insieme al servizio: ogni volta che c'è un aggiornamento, il test può controllare automaticamente la reazione a catena, senza aspettare che l'utente lo incontri per poi farsi prendere dal panico.

Allora, qual è la "misurazione in atto"?

Alcune persone pensano che eseguire l'interfaccia alcune volte per verificare il valore restituito sia considerato un test. In realtà, è più come confermare che il servizio è ancora "vivo". I veri test automatizzati devono andare più in profondità: ad esempio, simulando la catena completa di un ordine dalla generazione al completamento per vedere se ciascun servizio perderà informazioni o cambierà formato durante la trasmissione dei dati; oppure aggiungere deliberatamente un piccolo ritardo a un servizio e osservare se altri servizi aspettano pazientemente o vanno direttamente in timeout e si bloccano. Questo tipo di test è come un regolare controllo fisico dell'intero sistema, non si limita a osservare i singoli organi, ma controlla anche come funzionano insieme.

kpowerQuando aiutiamo i clienti a risolvere tali test, spesso troviamo due trappole in cui è facile cadere: in primo luogo, lo script del test è scritto in modo troppo "difficile" e dovrà essere modificato in modo significativo una volta aggiornato il servizio; in secondo luogo, la copertura del test è incompleta e ci sono sempre alcune scene angolari che non vengono prese in considerazione e sono proprio questi i luoghi in cui è più probabile che si verifichino problemi. Successivamente, hanno modificato il loro modo di pensare, suddividendo i casi di test per essere più flessibili, come mettere insieme i Lego, cambiando leggermente il servizio, cambiando semplicemente i moduli corrispondenti; allo stesso tempo, simulare deliberatamente quelle situazioni "strane" che non accadono spesso, come interruzioni di rete o elevata concorrenza istantanea, può scoprire in anticipo vulnerabilità nascoste.

Qual è la differenza tra "può correre" e "correre costantemente"?

Ad esempio, se assembli un braccio robotico con una scatola dello sterzo e un servomotore, non importa quanto accuratamente ruotino i singoli motori, se i tempi non sono regolati correttamente, il movimento complessivo sarà comunque incerto. Lo stesso vale per i microservizi. Se i test automatizzati si concentrano solo su un singolo servizio, è come calibrare un singolo motore e ignorare il coordinamento generale. Un buon framework di test consentirà ai servizi di "controllarsi a vicenda", ad esempio simulando automaticamente il traffico reale che scorre attraverso tutti i servizi su base regolare e registrando dove la risposta è lenta e dove i dati non corrispondono. L'accumulo di questi dati non solo può individuare rapidamente i problemi, ma anche ricordare quali servizi potrebbero essere necessari e quali interfacce sono troppo strettamente dipendenti.

Una volta in chat mi è stato chiesto: "Non abbiamo molti servizi, abbiamo bisogno di test così dettagliati?" In effetti, il numero di servizi non è la chiave, ciò che è importante è quanto siano "appiccicosi". Anche se ci sono solo tre o quattro servizi, se le chiamate reciproche sono complicate e ci sono molti collegamenti di trasferimento dati, sarà difficile che i test manuali li coprano tutti. I test automatizzati sono più come la creazione di una rete di monitoraggio intelligente, che di solito rimane in background. Una volta che si verifica un aggiornamento o un'anomalia del servizio, può immediatamente fornire un feedback e dirti se il cambiamento è salutare o un "piccolo raffreddore".

Lascia che il test "cresca" da solo

La scrittura manuale dei casi di test richiede molto tempo e anche la post-manutenzione è faticosa.kpowerSuccessivamente, ho provato a generare automaticamente alcuni casi di test: in base ai registri delle chiamate dell'interfaccia e ai modelli di traffico effettivi, il sistema consiglierà scenari di test comuni e persino costruirà automaticamente casi d'uso edge. Non si tratta di sostituire completamente la progettazione manuale, ma di liberare gli ingegneri dal lavoro ripetitivo per concentrarsi sulla logica di test che richiede maggiore creatività. Ad esempio, come simulare un aumento degli ordini durante le vacanze e come testare le prestazioni di compatibilità dei nuovi servizi dopo la connessione, questi devono ancora essere progettati in base all'esperienza.

Anche il rapporto di prova è reso il più chiaro possibile. Non è più un mucchio di numeri e log, ma è come raccontare una storia: questa volta è cambiato il servizio all’utente, che ha influenzato anche ordini e pagamenti, come è cambiato il tempo di risposta complessivo dei link e a quali link vale la pena prestare attenzione. Le persone che leggono il rapporto riescono a cogliere rapidamente i punti chiave invece di perdersi nei dettagli.

Non c’è nulla di misterioso nei test automatizzati dei microservizi. È essenzialmente un'abitudine continua. Così come ogni giorno quando torni a casa controlli se le porte e le finestre sono chiuse, così deve esserci anche un regolare meccanismo di "ispezione" del sistema in funzione. Quanto più questo meccanismo è automatico e quanto più è in linea con il reale flusso dei dati, tanto più sicuro sarai quando dormi la notte: dopotutto, chissà dove sarà il prossimo utente e in quale modo inaspettato, innescando una serie di interazioni di servizio a cui non avevi mai pensato?

Per iniziare a farlo, puoi iniziare in piccolo: prima scegli un collegamento di core business, elenca chiaramente i servizi che passano, le interfacce richiamate e i dati attesi, quindi simula varie possibili trame su questo collegamento come un regista che prova uno spettacolo teatrale. Una volta che le cose procedono senza intoppi, espandi lentamente l'ambito. Col tempo, scoprirai che i test automatizzati non servono solo a trovare bug, ma ti aiutano anche a comprendere meglio il tuo sistema: come funziona ogni servizio, come comunica tra loro, quali aree sono solide e quali devono essere rafforzate. Questa comprensione stessa è la migliore garanzia.

Fondata nel 2005,kpowerè dedicata a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare, Kpower integra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate. Kpower ha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.