Plan de Tests de Performance

1.1 Contexte

Les tests de performance sont essentiels pour garantir que REWAPP peut supporter la charge utilisateur prévue tout en maintenant une expérience utilisateur optimale. Ce document définit la stratégie, les métriques, les scénarios et les outils pour valider les performances de la plateforme.

1.2 Objectifs des Tests de Performance

• Valider la capacité de charge : Vérifier que le système supporte le nombre d'utilisateurs simultanés prévu
• Identifier les goulots d'étranglement : Détecter les points de contention avant la mise en production
• Garantir les temps de réponse : Valider que les SLA de performance sont respectés (< 200ms)
• Tester la scalabilité : Vérifier que l'auto-scaling fonctionne correctement sous charge
• Assurer la stabilité : Confirmer que le système reste stable sous charge prolongée
• Valider les mécanismes de protection : Tester le rate limiting et les circuit breakers

1.3 Périmètre des Tests

1.4 Projections de Charge

2.1 Métriques Principales (KPIs)

2.2 Métriques Système

2.3 Métriques par Endpoint Critique

3.1 Profil Normal (Baseline)

Ce profil représente une charge typique en période normale.

3.2 Profil Charge Standard

Ce profil représente la charge attendue en Année 1.

3.3 Profil Pic de Charge

Ce profil simule un pic d'activité (promotions, événements).

3.4 Profil Année 3 (Cible)

Ce profil valide la capacité pour 300 000 utilisateurs.

4.1 SC-PERF-001 : Parcours Utilisateur Complet

Pré-conditions

• Utilisateurs de test créés en base
• Partenaires de test configurés
• Points crédités sur les comptes de test

Étapes

1. 1

   Connexion

   POST /auth/login

2. 2

   Récupération du profil

   GET /users/me

3. 3

   Consultation du solde

   GET /points/balance

4. 4

   Consultation de l'historique

   GET /transactions?limit=20

5. 5

   Recherche de partenaires

   GET /partners/nearby

6. 6

   Génération QR code

   POST /qr-codes/generate

7. 7

   Vérification statut QR

   GET /qr-codes/{id}/status

Résultats attendus

• Temps total du parcours < 2 secondes
• Aucune erreur HTTP 5xx
• Taux d'erreur < 0.1%

4.2 SC-PERF-002 : Génération QR Code sous Charge

Pré-conditions

• 1000 utilisateurs avec solde de points > 100

Étapes

1. 1

   Génération simultanée

   500 utilisateurs génèrent un QR code simultanément

2. 2

   Vérification blocage

   Vérification du blocage des points (Redis)

3. 3

   Attente expiration

   60 secondes

4. 4

   Vérification déblocage

   Vérification du déblocage automatique

Résultats attendus

• Temps de génération < 150ms (P95)
• Points correctement bloqués
• Déblocage automatique fonctionnel
• Aucune corruption de données

4.3 SC-PERF-003 : Scan QR Code Partenaire

Résultats attendus

• Temps de validation < 200ms (P95)
• Aucun double débit
• QR codes invalidés après scan

4.4 SC-PERF-004 : Webhooks Bancaires

Résultats attendus

• Temps de traitement webhook < 1000ms
• 100% des transactions traitées
• Points crédités correctement
• Notifications envoyées

4.5 SC-PERF-005 : Authentification sous Charge

Résultats attendus

• Temps de login < 300ms (P95)
• Tokens JWT valides générés
• Rate limiting fonctionnel

4.6 SC-PERF-006 : Demandes de Virement

Résultats attendus

• Temps de création demande < 500ms
• Points bloqués correctement
• Aucune demande dupliquée

5.1 Tests API Gateway (Kong)

5.2 Tests Service Authentification

5.3 Tests Service Points

5.4 Tests Service QR Code

5.5 Tests Base de Données PostgreSQL

5.6 Tests Cache Redis

6.1 Objectif

Valider que le système fonctionne correctement sous la charge attendue en conditions normales d'exploitation.

6.2 Configuration

6.3 Distribution des Requêtes

6.4 Critères de Succès Load Test

• Temps de réponse P95 < 200ms
• Taux d'erreur < 0.1%
• CPU < 70%
• Mémoire < 80%
• Aucun timeout
• Toutes les fonctionnalités opérationnelles

7.1 Objectif

Identifier les limites du système et valider son comportement en cas de surcharge.

7.2 Configuration

7.3 Comportement Attendu par Niveau de Charge

7.4 Critères de Validation

• Auto-scaling déclenché correctement
• Circuit breakers activés si nécessaire
• Rate limiting protège le système
• Aucune corruption de données
• Récupération complète après stress

8.1 Objectif

Valider la stabilité du système sur une période prolongée pour détecter les fuites mémoire et la dégradation progressive.

8.2 Configuration

8.3 Points de Surveillance

• Memory leaks : Augmentation progressive de la mémoire utilisée
• Connection leaks : Accumulation de connexions non fermées
• File descriptors : Épuisement des descripteurs
• Disk space : Accumulation de logs/fichiers temporaires
• Performance degradation : Dégradation progressive des temps de réponse

8.4 Critères de Succès

• Mémoire stable (variation < 10% sur 8h)
• Connexions DB stables
• Temps de réponse constants
• Aucun restart nécessaire
• Logs sans erreur critique

9.1 Objectif

Valider que l'auto-scaling horizontal fonctionne correctement et que le système scale linéairement.

9.2 Tests Auto-Scaling ECS

9.3 Test de Scaling Linéaire

Objectif : Vérifier que doubler les ressources double la capacité.

9.4 Test de Scaling Database

10.1 Outils de Tests de Performance

10.2 Outil Principal : K6

• Script en JavaScript : Facile à maintenir par l'équipe
• Performances élevées : Écrit en Go, très efficace
• Intégration CI/CD : S'intègre facilement avec GitHub Actions
• Métriques riches : Export vers InfluxDB/Prometheus/Grafana
• Cloud option : K6 Cloud pour tests distribués

10.3 Infrastructure de Monitoring

10.4 Configuration Environnement de Test

11.1 Script de Test de Charge Basique

// k6-load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate, Trend } from 'k6/metrics';

// Métriques personnalisées
const errorRate = new Rate('errors');
const loginDuration = new Trend('login_duration');

// Configuration du test
export const options = {
  stages: [
    { duration: '5m', target: 100 },  // Ramp-up
    { duration: '30m', target: 500 }, // Steady state
    { duration: '5m', target: 0 },    // Ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<200'],
    errors: ['rate<0.01'],
  },
};

const BASE_URL = 'https://staging.api.rewapp.fr/api/v1';

export default function () {
  // Login
  const loginRes = http.post(BASE_URL + '/auth/login', 
    JSON.stringify({
      email: 'user' + __VU + '@test.rewapp.fr',
      password: 'TestPassword123!'
    }),
    { headers: { 'Content-Type': 'application/json' } }
  );
  
  loginDuration.add(loginRes.timings.duration);
  
  check(loginRes, {
    'login successful': (r) => r.status === 200,
    'has access token': (r) => r.json('data.accessToken') !== undefined,
  }) || errorRate.add(1);

  const token = loginRes.json('data.accessToken');
  
  // Get balance
  const balanceRes = http.get(BASE_URL + '/points/balance', {
    headers: { 
      'Authorization': 'Bearer ' + token,
      'Content-Type': 'application/json'
    }
  });
  
  check(balanceRes, {
    'balance retrieved': (r) => r.status === 200,
  }) || errorRate.add(1);

  sleep(1);
}

11.2 Script de Test QR Code

// k6-qrcode-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 100,
  duration: '10m',
  thresholds: {
    http_req_duration: ['p(95)<150'],
    'checks': ['rate>0.99'],
  },
};

export default function () {
  const token = login();
  
  // Génération QR code
  const qrRes = http.post(BASE_URL + '/qr-codes/generate',
    JSON.stringify({ pointsAmount: 50 }),
    { headers: authHeaders(token) }
  );
  
  check(qrRes, {
    'QR generated': (r) => r.status === 201,
    'has QR data': (r) => r.json('data.qrCodeData') !== undefined,
    'has expiration': (r) => r.json('data.expiresAt') !== undefined,
    'duration < 150ms': (r) => r.timings.duration < 150,
  });

  sleep(0.5);
}

11.3 Script de Test de Stress

// k6-stress-test.js
export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 500 },
    { duration: '5m', target: 1000 },
    { duration: '5m', target: 2000 },
    { duration: '5m', target: 3000 },
    { duration: '5m', target: 4000 },
    { duration: '5m', target: 5000 },
    { duration: '5m', target: 0 },
  ],
  thresholds: {
    http_req_failed: ['rate<0.05'],
    http_req_duration: ['p(99)<1000'],
  },
};

12.1 Environnement Staging

12.2 Environnement Performance Dédié

Pour les tests de charge importants, un environnement dédié est recommandé :

12.3 Données de Test

• 10 000 utilisateurs de test avec profils variés
• 500 partenaires de test
• 100 000 transactions historiques
• Points distribués sur les comptes (0 à 10 000)
• Paliers fidélité variés (Bronze à Diamant)

13.1 Critères Globaux de Succès

13.2 Validation par Type de Test

13.3 Critères de Blocage Release

14.1 Contenu du Rapport de Tests

Chaque session de tests génère un rapport comprenant :

• Résumé exécutif : Pass/Fail, métriques clés
• Configuration du test : Profil, durée, VUs
• Métriques détaillées : Latence par endpoint, throughput, erreurs
• Graphiques : Évolution temporelle des métriques
• Points de rupture : Si stress test
• Recommandations : Optimisations identifiées
• Anomalies : Comportements inattendus

14.2 Template de Rapport

RAPPORT DE TESTS DE PERFORMANCE - [DATE]

1. RÉSUMÉ
   - Type de test : [Load/Stress/Soak/Scalabilité]
   - Résultat global : [PASS/FAIL]
   - Durée : [X heures]
   - VUs maximum : [X]

2. MÉTRIQUES CLÉS
   - P50 : [X ms]
   - P95 : [X ms]
   - P99 : [X ms]
   - Throughput : [X req/s]
   - Taux erreur : [X%]

3. ANALYSE DÉTAILLÉE
   [Graphiques et observations]

4. RECOMMANDATIONS
   [Actions correctives si nécessaire]

14.3 Fréquence des Rapports

15.1 Intégration CI/CD

15.2 Planning Tests Manuels

15.3 Calendrier Année 1

16.1 Checklist Pré-Test

Avant chaque session de tests de performance :

• Environnement staging opérationnel
• Données de test chargées
• Monitoring actif (Grafana, CloudWatch)
• Équipe informée du créneau de test
• Backup de la base de données effectué
• Logs vidés pour analyse propre
• Rate limiting ajusté si nécessaire
• Générateurs K6 configurés

16.2 Checklist Post-Test

Après chaque session de tests :

• Collecter les métriques K6
• Exporter les dashboards Grafana
• Analyser les logs d'erreur
• Vérifier l'intégrité des données
• Restaurer la configuration normale
• Rédiger le rapport de test
• Partager les résultats à l'équipe
• Créer les tickets d'optimisation si nécessaire

16.3 Contacts et Escalade

16.4 Références

• Document 4.1 - Architecture Technique Globale
• Document 4.3 - Architecture Backend API
• Document 7.1 - Documentation API (OpenAPI)
• Document 8.1 - Plan de Tests Global
• Document 10.3 - Procédures de Monitoring et Alerting