Stress Testing (K6)

À quoi sert cet écran

Stress Testing exécute des tests de charge K6 sur vos services et en conserve les résultats, pour que « c’est devenu lent » devienne un chiffre comparable à celui du mois dernier.

Avant de commencer

Ouvrir l’écran

Tools › Stress Testing.

URL directe : /k6-stress-testing

📸 Capture d’ecran : La page de tests de charge K6 avec une exécution terminée. Repères : (1) la liste des exécutions, (2) le statut d’une exécution, (3) la vue des résultats, (4) l’action de lancement.

Qu’est-ce que Stress Testing ?

Stress Testing est un outil intégré à Fenwave basé sur K6 qui vous permet de tester les performances et la résistance de vos applications sous charge.

Accéder à Stress Testing

1. Cliquez sur Tools dans le menu latéral
2. Sélectionnez Stress Testing

Fonctionnalités principales

Types de tests

Métriques collectées

• Temps de réponse : p50, p90, p95, p99
• Throughput : Requêtes par seconde
• Taux d’erreur : % de requêtes échouées
• Concurrence : Utilisateurs virtuels actifs

Utilisation

Créer un test

1. Cliquez sur Create Test
2. Configurez les paramètres :

// Configuration K6
export const options = {
  stages: [
    { duration: '1m', target: 10 }, // Montée à 10 VUs
    { duration: '3m', target: 10 }, // Maintien
    { duration: '1m', target: 50 }, // Montée à 50 VUs
    { duration: '3m', target: 50 }, // Maintien
    { duration: '1m', target: 0 }, // Descente
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% < 500ms
    http_req_failed: ['rate<0.01'], // < 1% erreurs
  },
};

Définir les scénarios

Créez des scénarios réalistes :

import http from 'k6/http';
import { check, sleep } from 'k6';

export default function () {
  // Page d'accueil
  let res = http.get('https://api.example.com/');
  check(res, {
    'status is 200': r => r.status === 200,
    'response time < 500ms': r => r.timings.duration < 500,
  });

  sleep(1);

  // API endpoint
  res = http.get('https://api.example.com/users');
  check(res, {
    'users loaded': r => r.json().length > 0,
  });
}

Exécuter le test

1. Sélectionnez l’environnement cible (Dev/Staging uniquement)
2. Cliquez sur Run Test
3. Surveillez les métriques en temps réel

Interpréter les résultats

Dashboard temps réel

Pendant l’exécution, visualisez :

• Graphique des temps de réponse
• Nombre de VUs actifs
• Taux d’erreur
• Throughput

Rapport final

Après le test, consultez :

• Résumé : Vue d’ensemble des performances
• Détails : Métriques par endpoint
• Erreurs : Liste des erreurs rencontrées
• Recommandations : Suggestions d’amélioration

Seuils de performance

Bonnes pratiques

Préparation

1. Testez en staging : Jamais en production
2. Isolez l’environnement : Évitez les interférences
3. Données réalistes : Utilisez des données de test représentatives
4. Baseline : Établissez une référence avant modifications

Pendant le test

1. Surveillez les ressources : CPU, mémoire, I/O
2. Logs : Consultez les logs applicatifs
3. Ne pas interrompre : Laissez le test se terminer

Après le test

1. Analysez les résultats : Identifiez les goulots d’étranglement
2. Documentez : Conservez les rapports
3. Comparez : Avec les tests précédents
4. Planifiez : Les optimisations nécessaires

Intégration CI/CD

Ajoutez les tests de performance à votre pipeline :

# GitHub Actions
performance-test:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Run K6 test
      uses: grafana/k6-action@v0.3.0
      with:
        filename: tests/performance/load-test.js

Liens utiles

• Security Scanner
• Developer Tools
• Environnement Staging

Scénario

Trouver où un service cède, avant que vos utilisateurs ne le trouvent.

1. Vérifiez d’abord que le service est correct. Tester la charge de quelque chose de bogué mesure le bogue.
2. Testez sur staging, pas en production — et prévenez ceux qui partagent le staging, car vous allez le ralentir pour eux.
3. Démarrez bien en dessous de la charge attendue. Un premier tir au pic ne vous apprend que la casse, pas l’endroit.
4. Augmentez jusqu’à ce que quelque chose se dégrade, et notez ce qui se dégrade en premier — latence, taux d’erreur, ou un plafond de ressources. C’est là le constat ; le chiffre auquel cela s’est produit est secondaire.
5. Recoupez avec Détail d’un environnement › Metrics. Un échec sur une limite mémoire est un problème de dimensionnement, pas de code, et le correctif relève d’Optimisation des ressources.
6. Enregistrez l’exécution. Un test de charge sans point de comparaison est un point isolé, et les points isolés ne montrent pas de tendance.

En cas de problème

Pour aller plus loin

• Test Runner — la justesse plutôt que la charge
• Cost › Optimisation des ressources — quand la limite est en cause