talas-group/10_QUALITE_TESTS/QA_Fonctionnels/SCENARIOS_TESTS.md

# Scénarios de tests fonctionnels — Veza

> Tests par module : critères d'acceptation, cas limites, flows à valider.
> Chaque scénario = un test qui doit passer avant mise en production.
> Dernière mise à jour : avril 2026.

---

## Organisation

### Priorité des tests

| Priorité | Signification | Quand exécuter |
|:--------:|--------------|----------------|
| **P0** | Bloquant production — si échec, pas de deploy | Chaque PR |
| **P1** | Critique — à corriger dans les 24h si regression | Chaque release |
| **P2** | Important — à corriger avant la prochaine release | Hebdomadaire |
| **P3** | Nice-to-have — à corriger quand possible | Mensuel |

### Format d'un scénario

```
[ID] Titre
Priorité: PX | Type: unit/integ/e2e
Préconditions: ...
Étapes:
  1. ...
  2. ...
Résultat attendu: ...
Cas limites: ...
```

---

## Module 1 — Authentification

### AUTH-001 — Inscription email + password
**P0 | e2e**
- Préconditions : aucun compte existant
- Étapes :
  1. POST /auth/register { email, password, username }
  2. Vérifier email reçu (lien de vérification)
  3. Cliquer le lien
  4. Vérifier que le compte est actif
- Résultat : compte créé, JWT retourné, email vérifié
- Cas limites :
  - Email déjà pris → erreur 409
  - Username déjà pris → erreur 409
  - Password < 12 car → erreur 400
  - Password pwned (HIBP) → warning (V1.5)
  - Email invalide → erreur 400
  - Lien de vérification expiré (> 24h) → erreur + lien "renvoyer"

### AUTH-002 — Login + JWT
**P0 | integ**
- Étapes :
  1. POST /auth/login { email, password }
  2. Vérifier cookies HTTP-only (access + refresh)
  3. GET /auth/me avec cookie
- Résultat : user info retournée
- Cas limites :
  - Mauvais password → 401 (pas de distinction "email inconnu")
  - Compte verrouillé (5 échecs) → 429 + message "réessaie dans 15 min"
  - Compte non vérifié → 403 "vérifie ton email"

### AUTH-003 — Refresh token
**P0 | integ**
- Étapes :
  1. Login → obtenir access + refresh
  2. Attendre expiration access (ou simuler)
  3. POST /auth/refresh avec refresh cookie
- Résultat : nouveau access token, refresh token tourné
- Cas limites :
  - Refresh expiré → 401
  - Refresh révoqué (post-logout) → 401
  - Double utilisation du même refresh → 401 + révoquer TOUTES les sessions (detection replay)

### AUTH-004 — 2FA TOTP
**P1 | integ**
- Étapes :
  1. POST /auth/2fa/setup → QR code
  2. POST /auth/2fa/verify { code } → activation
  3. Logout + login → reçoit { requires_2fa: true }
  4. POST /auth/login/2fa { temp_token, code }
- Résultat : login complet
- Cas limites :
  - Code TOTP incorrect → 401
  - Code TOTP expiré (> 30s window) → 401
  - Backup code utilisé → OK, code invalidé
  - Tous backup codes utilisés → message "configure un nouveau 2FA"

### AUTH-005 — OAuth Discord
**P1 | e2e**
- Étapes :
  1. GET /auth/oauth/discord → redirect Discord
  2. User autorise → callback avec code
  3. Backend échange code → crée/lie le compte
- Résultat : JWT retourné, compte actif
- Cas limites :
  - State mismatch → 400
  - Discord down → erreur propre "service temporairement indisponible"
  - Email Discord déjà lié à un compte local → propose de lier

### AUTH-006 — Rate limiting auth
**P0 | integ**
- Étapes :
  1. Envoyer 6 POST /auth/login (mauvais password)
- Résultat : 429 au 6e avec Retry-After header
- Vérifier : IP différente ne bloque pas

---

## Module 2 — Tracks (morceaux)

### TRACK-001 — Upload + processing
**P0 | integ**
- Étapes :
  1. POST /tracks (metadata)
  2. PUT upload URL (binaire WAV)
  3. POST /tracks/:id/publish
  4. Attendre event "transcoding.completed"
  5. GET /tracks/:id
- Résultat : track publié, HLS manifest disponible, waveform générée
- Cas limites :
  - Fichier > 500 MB → 413
  - Format non supporté (.exe, .pdf) → 415
  - ClamAV détecte virus → status "removed" + notif admin
  - Upload interrompu → status "draft" conservé, reprise possible

### TRACK-002 — Lecture streaming
**P0 | e2e**
- Étapes :
  1. GET /tracks/:id → HLS manifest URL
  2. Charger dans player HLS.js
  3. Vérifier lecture audio
- Résultat : audio jouable, adaptatif (qualité s'adapte au réseau)
- Cas limites :
  - Track privé sans auth → 401
  - Track supprimé → 404
  - Connexion lente → fallback bitrate bas

### TRACK-003 — Permissions
**P1 | integ**
- Vérifier :
  - User A ne peut pas DELETE /tracks/:id de user B → 403
  - User A ne peut pas PUT /tracks/:id de user B → 403
  - Track privé de user A non visible par user B → 404
  - Track avec lien secret accessible avec le bon token

---

## Module 3 — Samples & Presets

### SAMPLE-001 — Upload pack complet
**P0 | integ**
- Même flow que TRACK-001 mais avec .zip
- Vérifications supplémentaires :
  - Extraction liste fichiers post-upload
  - Preview MP3 généré automatiquement
  - Tags indexés pour recherche

### SAMPLE-002 — Téléchargement
**P1 | integ**
- Étapes :
  1. GET /samples/packs/:id/download
  2. Vérifier URL signée MinIO
  3. Vérifier incrément downloads_count
- Cas limites :
  - Pack supprimé → 404
  - Rate limit (50 downloads/h) → 429

### SAMPLE-003 — Remix (arbre)
**P1 | integ**
- Étapes :
  1. Créer pack parent
  2. POST /samples/packs/:id/remix (nouveau pack)
  3. GET /samples/packs/:parent_id/remixes
- Résultat : arbre parent → enfant visible
- Cas limites :
  - Parent avec remix_allowed=false → 403
  - Licence incompatible → erreur

### SAMPLE-004 — Recherche et filtres
**P1 | integ**
- Tester chaque combinaison de filtres :
  - type + genre + bpm_min/max + key + tags + licence
  - sort=recent|popular|downloads
  - Pagination (page + limit)
- Résultat : résultats cohérents, pas de crash

---

## Module 4 — Troc

### TROC-001 — Flow complet création → closing
**P0 | e2e**
- Étapes :
  1. User A : POST /trades/listings (créer annonce)
  2. User B : POST /trades/listings/:id/interest
  3. Vérifier : DM créé entre A et B
  4. User A : POST /trades/listings/:id/conclude { concluded_with: B }
  5. User B : POST /trades/listings/:id/recognition { badges: ['reliable'] }
- Résultat : annonce "conclue", badges sur profil B
- Cas limites :
  - Auto-intérêt (creator == interested) → 403
  - Conclude avec user non-intéressé → 400
  - Double reconnaissance → 409

### TROC-002 — Détection anti-argent
**P1 | unit**
- POST /trades/listings avec "je cherche 100€" → 400
- POST avec "échange contre euros" → 400
- POST avec "je propose un mix" → OK

### TROC-003 — Limites
**P1 | integ**
- 6e annonce active → 400 "max 5 annonces actives"
- 3e annonce dans la journée → 400 "max 2/jour"

---

## Module 5 — Shop

### SHOP-001 — Parcours achat complet
**P0 | e2e**
- Étapes :
  1. GET /shop/products/talas-one → fiche produit
  2. POST /shop/cart/items { variant_id, qty: 1 }
  3. POST /shop/checkout/validate { addresses }
  4. POST /shop/orders → commande créée
  5. POST /payments/create → redirect Mollie
  6. Webhook Mollie payment.paid
  7. Vérifier : order status = "paid", email confirmé, facture générée
- Cas limites :
  - Stock = 0 → erreur au checkout
  - Réservation expirée (15 min) → stock libéré
  - Webhook Mollie en double → idempotent (pas de double charge)
  - Paiement échoué → order annulé, stock libéré

### SHOP-002 — Réservation stock concurrente
**P0 | integ**
- Étapes :
  1. Stock = 1 unité
  2. User A et user B tentent checkout simultanément
- Résultat : un seul réussit, l'autre reçoit "rupture de stock"
- Vérifier : pas de survente (stock négatif impossible)

### SHOP-003 — Calcul prix
**P0 | unit**
- Vérifier :
  - Prix base + options = total correct
  - TVA = 0% (franchise en base) avec mention légale
  - Frais de port ajoutés au total
  - Fees Mollie pas facturés au client (absorbés)

### SHOP-004 — Remboursement
**P1 | integ**
- Étapes :
  1. Commande payée
  2. Admin : POST /admin/payments/:id/refund
  3. Webhook Mollie refund.paid
  4. Vérifier : order status "refunded", facture d'avoir, stock ré-incrémenté

---

## Module 6 — Cloud Perso

### CLOUD-001 — CRUD fichiers
**P1 | integ**
- Upload, download, rename, delete, restore
- Vérifier quotas mis à jour après chaque action

### CLOUD-002 — Isolation
**P0 | integ**
- User A ne peut pas :
  - Lister les fichiers de user B
  - Télécharger un fichier de user B
  - Supprimer un fichier de user B
- Même via manipulation d'URL / brute-force UUID

### CLOUD-003 — Partage
**P1 | integ**
- Créer lien partagé → accessible sans auth
- Lien avec password → exige le bon password
- Lien expiré → 410 Gone
- Max downloads atteint → 403

---

## Module 7 — Formation

### LEARN-001 — Inscription et progression
**P1 | integ**
- Enroll → start lesson → complete lesson → progress updated
- Vérifier progress_percent recalculé correctement

### LEARN-002 — Video streaming
**P1 | e2e**
- Leçon vidéo → HLS manifest → lecture dans player
- Position sauvegardée → reprise au bon endroit

### LEARN-003 — Permissions contenu
**P1 | integ**
- Leçon non-preview sans enrollment → 403
- Leçon preview → accessible sans enrollment
- Seul le content_creator peut modifier son cours

---

## Module 8 — Chat et notifications

### CHAT-001 — DM entre users
**P1 | integ**
- Créer conversation, envoyer message, recevoir (WebSocket)

### CHAT-002 — Groupes
**P1 | integ**
- Poster dans un groupe, voir les messages des autres
- Permissions : modérateur peut supprimer

### NOTIF-001 — Notifications
**P2 | integ**
- Vérifier que chaque action génère la bonne notif :
  - Like sur track → notif au créateur
  - Intérêt troc → notif à l'annonceur
  - Commande payée → email client
  - SAV message → notif user

---

## Module 9 — Performance

### PERF-001 — Temps de réponse API
**P1 | load test**
- GET /tracks (feed) : p95 < 200ms sous 100 req/s
- GET /tracks/:id : p95 < 100ms
- POST /auth/login : p95 < 500ms

### PERF-002 — Streaming concurrence
**P1 | load test**
- 100 connexions WebSocket simultanées → pas de drop

### PERF-003 — Upload concurrence
**P2 | load test**
- 20 uploads simultanés → pas de timeout, pas de corruption

---

## Outils de test

| Couche | Outil | Langage |
|--------|-------|---------|
| Unit backend | `go test` | Go |
| Unit Rust | `cargo test` | Rust |
| Unit frontend | Vitest | TypeScript |
| Integration API | `go test` + httptest | Go |
| E2E | Playwright | TypeScript |
| Load | k6 | JavaScript |
| Sécurité | OWASP ZAP, Nuclei | - |
| Visual | Storybook + Chromatic | TypeScript |

---

## Exécution en CI

```yaml
# Chaque PR
- go test ./...
- cargo test
- npm run test
- govulncheck ./...
- cargo audit
- npm audit --audit-level=high
- gitleaks detect

# Nightly
- playwright test (e2e)
- k6 run perf-tests.js (load)
- trivy image scan

# Pre-release
- OWASP checklist manuelle
- Pentest ciblé si code critique modifié
```

---

## Voir aussi

- [[Tableaux_Validation/CHECKLIST_VALIDATION_V0]] — checklist pré-vente (86 items)
- [[Audit_Sécurité/PLAN_AUDIT_SECURITE]] — tests sécurité spécifiques
- [[Tests_Hardware/PROTOCOLES_TESTS_HARDWARE]] — tests matériel
- [[ARCHITECTURE_VEZA]] — composants à tester
- [[05_EXPERIENCE_UTILISATEUR/Flux_Utilisateurs/PARCOURS_UTILISATEURS_VEZA]] — flows à valider en e2e