Sfoglia categorie
Esplora
Fiverr Pro
Italiano
$
USD
Costruirò test di performance k6 per il tuo backend
Ingegnere di controllo qualità dell'automazione
La maggior parte degli ingegneri QA aggiunge più test. Io correggo l'architettura.
Ingegnere di QA Automation, specialista in Playwright – 6 anni in team SaaS. Un cliente: pipeline CI da 45 min a 15 ...
Informazioni su questo servizio
Il tuo sistema funziona per 10 utenti. Il traffico di produzione raddoppia il mese prossimo. Nessuno sa cosa si romperà prima.
La maggior parte dei team scopre alle 2 di notte. Scatta un allarme. La latenza triplica. I ricavi sono alle stelle. Il post-mortem dice "dovevamo fare un load-test".
La mia soluzione: Costruisco una suite di performance k6 che simula il carico reale di produzione, trova il collo di bottiglia prima del lancio e si esegue in CI ad ogni rilascio.
Non è uno script isolato. È una suite ripetibile con soglie, scenari e dashboard di proprietà del tuo team.
COSA INCLUDE
- progetto k6 strutturato per il tuo repo
- scenari di smoke, load, stress, spike e soak
- regole di soglia che falliscono la build in caso di regressione
- integrazione CI (GitHub Actions o GitLab)
- report CLI più dashboard opzionali di Grafana
- guida all'esecuzione per il tuo team
PERCHÉ SCEGLIERE ME
Sei anni in team SaaS. Da 45 a 15 minuti il CI. Ho integrato gate di performance nelle pipeline di rilascio, così una query lenta non raggiunge mai la produzione silenziosamente. Non eseguo k6 una volta e sparisco. Lascio una rete di regressione.
SCRIVIMI PRIMA
Inviami il tuo stack, gli endpoint target e la stima del traffico. Una sola risposta: sì posso aiutarti, o no e perché. Niente pitch.
Applicazione di testing:
API
Tecnologia di sviluppo:
Go
•
JavaScript
Dispositivo:
Altro
Il mio portfolio
FAQ
Traduzione automatica.
Perché k6 invece di JMeter o Locust?
k6 è JavaScript, friendly per gli sviluppatori, si integra bene con CI e produce metriche che piacciono a Grafana. JMeter è pesante di XML, lento da mantenere, e nessun team con cui ho lavorato l'ha mantenuto vivo oltre il lancio. k6 si adatta al workflow di un team di ingegneria moderno.
A quali livelli di traffico puoi simulare?
Fino a 10.000 utenti virtuali su k6 locale con hardware ragionevole. Oltre, usiamo k6 Cloud o runner distribuiti. Ti consiglierò la configurazione giusta in base al traffico target nel primo messaggio.
Quali metriche otterrò?
Tempo di risposta (p50, p95, p99), tasso di errore, throughput (richieste al secondo), e qualsiasi metrica personalizzata che ti interessa (es. tasso di checkout completato). Le soglie trasformano queste in gate di pass/fail in CI.
Testi solo API REST?
REST è di default. Supporto anche GraphQL, WebSocket e gRPC. La performance browser-based (carico di utenti reali) è un altro gig: guarda il mio gig di automazione Playwright per test end-to-end, non load.
Gli test verranno eseguiti contro produzione?
Smoke e carico leggero: di solito sì, fuori orario di punta. Stress e spike: solo contro staging o un ambiente di performance dedicato. Concordiamo traffico e tempi nel primo messaggio. Non eseguo mai un stress test in live senza approvazione scritta esplicita.
E se trovi un collo di bottiglia?
Ricevi un report scritto con l'endpoint che fallisce, la metrica che fallisce e la causa probabile (DB, rete, codice app, coda). Non riparo il collo di bottiglia in questa gig. Lo trovo. La riparazione è del tuo team di ingegneria o di un engagement separato.
Può il test essere eseguito su ogni PR?
Smoke sì. Carico completo no, troppo costoso per ogni PR. Configurazione raccomandata: smoke ad ogni PR, carico completo di notte, stress mensile. Il workflow CI che consegno supporta tutte e tre le modalità fin dal primo giorno.
E per l'autenticazione?
Token-based, OAuth, cookie di sessione, tutti supportati. Configuro l'autenticazione una volta in uno script di setup. I test riutilizzano il token senza ricollegarsi ogni richiesta, come desideri per numeri di carico precisi.
Il mio team può mantenere la suite dopo la consegna?
Sì, per progettazione. Il README spiega come aggiungere uno scenario, come cambiare le soglie e come debugare un fallimento. La versione premium include una call di handover live, così il team ha una sessione di lavoro prima di prendersene carico.
E se il mio codice non ha test di performance esistenti?
La maggior parte no. Il primo scenario in Basic ti dà un numero di baseline. Standard e Premium si basano su quella baseline. Non serve una cultura di performance prima di questa gig. La costruisci con questa gig.
