Parcourir les catégories
Explorer
Fiverr Pro
Français
$
USD
Je vais construire des tests de performance k6 pour votre backend
Ingénieur en automatisation assurance qualité
La plupart des ingénieurs QA ajoutent plus de tests. Moi, je corrige l'architecture.
Ingénieur en automatisation QA, spécialiste Playwright – 6 ans dans des équipes SaaS. Un client : pipeline CI de 4...
À propos de ce service
Votre système fonctionne pour 10 utilisateurs. Le trafic en production double le mois prochain. Personne ne sait ce qui va casser en premier.
La plupart des équipes découvrent cela à 2h du matin. Une alerte se déclenche. La latence triple. Le chiffre d'affaires chute. Le post-mortem dit « nous aurions dû faire un load-test ».
Ma solution : Je crée une suite de tests de performance k6 qui simule la charge réelle en production, identifie le goulet d'étranglement avant le lancement, et s'exécute dans le CI à chaque version.
Ce n'est pas un script ponctuel. C'est une suite répétable avec seuils, scénarios et tableaux de bord que votre équipe possède.
CE QUI EST INCLUS
- Projet k6 configuré pour votre dépôt
- Scénarios de smoke, charge, stress, spike et soak
- Règles de seuils qui échouent la build en cas de régression
- Intégration CI (GitHub Actions ou GitLab)
- Rapport CLI ainsi que des tableaux de bord Grafana optionnels
- Guide d'exécution pour votre équipe
POURQUOI ME CHOISIR
Six ans dans des équipes SaaS. Réduction du CI de 45 min à 15 min. J'ai intégré des gates de performance dans les pipelines de release pour qu'une requête lente ne passe jamais en production en silence. Je ne lance pas k6 une seule fois et disparais. Je laisse un filet de régression.
CONTACTEZ-MOI D'ABORD
Envoyez votre stack, vos endpoints cibles et votre estimation de trafic. Une seule réponse : oui je peux aider, ou non et pourquoi. Pas de pitch.
Test d'applications:
API
Technologie de développement:
Go
•
JavaScript
Appareil:
Autres
Mon portfolio
FAQ
Traduction automatique
Pourquoi k6 plutôt que JMeter ou Locust ?
k6 utilise JavaScript, est convivial pour les développeurs, s'intègre proprement avec le CI, et produit des métriques appréciées par Grafana. JMeter est lourd en XML, lent à maintenir, et aucune équipe avec laquelle j'ai travaillé ne l'a conservé après le lancement. k6 correspond au workflow actuel d'une équipe d'ingénierie moderne.
Quels niveaux de trafic pouvez-vous simuler ?
Jusqu'à 10 000 utilisateurs virtuels sur k6 local avec du matériel raisonnable. Au-delà, j'utilise k6 Cloud ou des runners distribués. Je recommanderai la configuration adaptée en fonction de votre trafic cible dans le premier message.
Quelles métriques vais-je obtenir ?
Temps de réponse (p50, p95, p99), taux d'erreur, débit (requêtes par seconde), et toute métrique personnalisée qui vous importe (par exemple, taux de finalisation du checkout). Les seuils transforment ces métriques en portes de réussite ou d'échec dans le CI.
Testez-vous uniquement les API REST ?
REST est la configuration par défaut. Je supporte aussi GraphQL, WebSocket, et gRPC. La performance basée sur le navigateur (charge utilisateur réel) est un autre domaine : voir mon service d'automatisation Playwright pour des tests E2E rapides, pas de load.
Les tests seront-ils exécutés en production ?
Smoke et petite charge : généralement oui, en dehors des heures de pointe. Stress et spike : uniquement contre staging ou un environnement de perf dédié. Nous convenons des cibles de trafic et du timing dans le premier message. Je n'exécute jamais un stress test en direct sans approbation écrite explicite.
Et si vous trouvez un goulet d'étranglement ?
Vous recevrez un rapport écrit avec l'endpoint défaillant, la métrique qui a échoué, et la cause probable (DB, réseau, code de l'application, queue). Je ne corrige pas le goulet d'étranglement dans cette gig. Je le trouve. La correction revient à votre équipe d'ingénierie ou à un engagement séparé.
Les tests peuvent-ils s'exécuter à chaque PR ?
Smoke oui. Charge complète non, c'est trop coûteux pour chaque PR. Configuration recommandée : smoke à chaque PR, charge complète chaque nuit, stress mensuel. Le workflow CI que je fournis supporte ces trois modes dès le départ.
Qu'en est-il de l'authentification ?
Basé sur un token, OAuth, cookies de session, tout est supporté. Je configure l'authentification une fois dans un script d'installation. Les tests réutilisent le token sans se ré-authentifier à chaque requête, ce qui est idéal pour des chiffres de charge précis.
Mon équipe pourra-t-elle maintenir la suite après livraison ?
Oui, par conception. Le README explique comment ajouter un nouveau scénario, modifier les seuils, et déboguer une défaillance. La version premium inclut un appel de transfert en direct pour que l'équipe ait une session de travail avant de la prendre en main.
Et si mon code n'a pas de tests de performance existants ?
La plupart n'en ont pas. Le premier scénario de type audit dans Basic vous donne un chiffre de référence. Standard et Premium s'appuient sur cette base. Vous n'avez pas besoin d'une culture de performance avant cette gig. Vous en construisez une avec cette gig.
