maj
This commit is contained in:
263
docs/09_tests_qualite.md
Normal file
263
docs/09_tests_qualite.md
Normal file
@@ -0,0 +1,263 @@
|
||||
|
||||
# 09 – Stratégie de tests, validation et qualité pour Linux BenchTools
|
||||
|
||||
Objectif : définir comment tester et valider chaque brique de l’application
|
||||
(backend, script bench, frontend), afin d’assurer fiabilité, reproductibilité des mesures
|
||||
et facilité de maintenance.
|
||||
|
||||
Ce document sert de guide pour écrire les tests et scénarios de validation manuelle.
|
||||
|
||||
---
|
||||
|
||||
# 1. Périmètre des tests
|
||||
|
||||
Les tests couvrent :
|
||||
|
||||
1. **Backend API**
|
||||
- Validation des endpoints
|
||||
- Validation de la persistance en base
|
||||
- Validation de la sécurité (token)
|
||||
2. **Script client `bench.sh`**
|
||||
- Fonctionnement sur différentes machines Debian/Ubuntu
|
||||
- Gestion des erreurs (outils manquants, serveur indisponible)
|
||||
- Qualité du JSON envoyé
|
||||
3. **Frontend WebUI**
|
||||
- Rendu des pages (Dashboard, Devices, Device Detail, Settings)
|
||||
- Consommation correcte de l’API
|
||||
- UX minimale (lisibilité, tri, navigation)
|
||||
4. **Tests de bout en bout (E2E)**
|
||||
- Exécution complète d’un bench depuis un client → apparition dans le Dashboard.
|
||||
|
||||
---
|
||||
|
||||
# 2. Tests Backend
|
||||
|
||||
## 2.1. Types de tests
|
||||
|
||||
- **Tests unitaires** : fonctions isolées (scoring, mapping JSON → modèles).
|
||||
- **Tests d’intégration** : endpoints FastAPI avec base SQLite de test.
|
||||
- **Tests E2E API** : envoi d’un payload complet depuis un script de test.
|
||||
|
||||
Framework recommandé :
|
||||
- `pytest`
|
||||
- `httpx` ou client de test FastAPI
|
||||
|
||||
## 2.2. Cas de test principaux
|
||||
|
||||
### a) POST /api/benchmark
|
||||
|
||||
- [OK] Payload complet, token valide :
|
||||
- Retourne 200
|
||||
- Crée un `device` si inexistant
|
||||
- Crée un `hardware_snapshot`
|
||||
- Crée un `benchmark`
|
||||
- [OK] Device existant :
|
||||
- Réutilise le `device`
|
||||
- [ERR] Token manquant :
|
||||
- 401
|
||||
- [ERR] Token incorrect :
|
||||
- 401
|
||||
- [ERR] JSON invalide :
|
||||
- 400
|
||||
|
||||
### b) GET /api/devices
|
||||
|
||||
- [OK] Base vide → items = [].
|
||||
- [OK] Avec plusieurs devices et benchmarks :
|
||||
- Retourne un `last_benchmark` cohérent.
|
||||
- [OK] Paramètres `page`, `page_size` :
|
||||
- Pagination effective.
|
||||
|
||||
### c) GET /api/devices/{id}
|
||||
|
||||
- [OK] Device existant :
|
||||
- Retourne résumé, snapshot, dernier benchmark.
|
||||
- [ERR] Device inexistant :
|
||||
- 404.
|
||||
|
||||
### d) Liens constructeur
|
||||
|
||||
- [OK] CRUD complet sur `/api/devices/{id}/links`.
|
||||
- [ERR] URL invalide (peut être toléré ou validé selon règle).
|
||||
|
||||
### e) Documents
|
||||
|
||||
- [OK] Upload PDF :
|
||||
- Fichier stocké physiquement
|
||||
- Entrée BDD créée
|
||||
- [OK] Download :
|
||||
- Renvoie bon `Content-Type`
|
||||
- [ERR] doc_id invalide :
|
||||
- 404.
|
||||
|
||||
---
|
||||
|
||||
# 3. Tests Script client (bench.sh)
|
||||
|
||||
## 3.1. Contexte
|
||||
|
||||
Les tests sur `bench.sh` sont principalement :
|
||||
- des tests manuels guidés
|
||||
- des tests automatisables partiellement (CI dans un container Docker).
|
||||
|
||||
## 3.2. Cas de test
|
||||
|
||||
### a) Aide & usage
|
||||
|
||||
- `bench.sh --help` → affiche usage.
|
||||
- Sans arguments → erreur claire.
|
||||
|
||||
### b) Prérequis
|
||||
|
||||
- Si `curl`, `jq`, `sysbench`, `fio` manquants :
|
||||
- message explicite
|
||||
- tentative d’installation si possible (apt-get)
|
||||
- en cas d’échec, test concerné désactivé mais script continue.
|
||||
|
||||
### c) Exécution minimale
|
||||
|
||||
- `bench.sh --server http://backend:8007/api/benchmark --token XXX` :
|
||||
- Détecte le hostname
|
||||
- Exécute les tests par défaut
|
||||
- Envoie un JSON valide (vérifiable via logs backend).
|
||||
|
||||
### d) Modes d’options
|
||||
|
||||
- `--short` :
|
||||
- Durées de tests CPU/mémoire/disk raccourcies
|
||||
- `--skip-network` :
|
||||
- Aucun test iperf3, bloc `results.network` absent ou null
|
||||
- `--iperf-server` avec serveur iperf opérationnel :
|
||||
- Champs réseau correctement renseignés.
|
||||
|
||||
### e) Gestion des erreurs réseau
|
||||
|
||||
- Backend down :
|
||||
- Message d’erreur clair
|
||||
- Code HTTP ≠ 200 connu
|
||||
- Iperf3 indisponible :
|
||||
- Bloc network absent/null
|
||||
|
||||
---
|
||||
|
||||
# 4. Tests Frontend
|
||||
|
||||
## 4.1. Smoke tests (manuels)
|
||||
|
||||
- Accès à :
|
||||
- `/` → Dashboard
|
||||
- `/devices`
|
||||
- `/devices/{id}`
|
||||
- `/settings`
|
||||
- Vérification du rendu :
|
||||
- Aucune erreur JS console
|
||||
- Chargement des datas via API
|
||||
- Tri de base dans les tableaux
|
||||
|
||||
## 4.2. Tests fonctionnels (scénarios)
|
||||
|
||||
### Scénario 1 : Premier lancement
|
||||
|
||||
1. Déployer l’application.
|
||||
2. Vérifier Dashboard vide, message “Aucun device”.
|
||||
3. Exécuter `bench.sh` sur une machine.
|
||||
4. Rafraîchir Dashboard :
|
||||
- Device apparaît avec score.
|
||||
|
||||
### Scénario 2 : consultation d’un device
|
||||
|
||||
1. Cliquer sur un device dans le Dashboard.
|
||||
2. Page détail :
|
||||
- Hardware résumé cohérent.
|
||||
- Dernier benchmark affiché.
|
||||
3. Onglet Benchmarks :
|
||||
- Historique listé.
|
||||
|
||||
### Scénario 3 : Documents
|
||||
|
||||
1. Aller dans onglet Documents d’un device.
|
||||
2. Uploader un PDF.
|
||||
3. Vérifier sa présence dans la liste.
|
||||
4. Télécharger pour confirmer.
|
||||
|
||||
### Scénario 4 : Liens constructeur
|
||||
|
||||
1. Onglet Links d’un device.
|
||||
2. Ajouter un lien avec label + URL.
|
||||
3. Vérifier qu’il est cliquable.
|
||||
4. Tester suppression.
|
||||
|
||||
---
|
||||
|
||||
# 5. Tests E2E (de bout en bout)
|
||||
|
||||
Objectif : couvrir la chaîne complète depuis la machine cliente jusqu’au Dashboard.
|
||||
|
||||
### Scénario E2E type
|
||||
|
||||
1. Lancer backend + frontend via `docker compose up`.
|
||||
2. Déployer `bench.sh` sur un client Debian.
|
||||
3. Exécuter :
|
||||
|
||||
```bash
|
||||
curl -s https://.../bench.sh | bash -s -- \
|
||||
--server http://IP_BACKEND:8007/api/benchmark \
|
||||
--token XXX \
|
||||
--iperf-server 10.0.0.10
|
||||
```
|
||||
|
||||
4. Vérifier côté backend (logs) qu’un benchmark a été créé.
|
||||
5. Ouvrir le Dashboard :
|
||||
- Device présent, scores visibles.
|
||||
|
||||
---
|
||||
|
||||
# 6. Données de test
|
||||
|
||||
Créer un répertoire `tests/data/` contenant :
|
||||
|
||||
- Exemples de payload JSON de bench :
|
||||
- `bench_full.json` (tous tests)
|
||||
- `bench_no_gpu.json`
|
||||
- `bench_short.json`
|
||||
- Scripts auxiliaires :
|
||||
- `send_bench_payload.py` (envoi direct d’un payload pour tests).
|
||||
|
||||
---
|
||||
|
||||
# 7. Automatisation CI (optionnel)
|
||||
|
||||
Intégration avec :
|
||||
|
||||
- GitHub Actions
|
||||
- Gitea Actions / Drone / Woodpecker
|
||||
|
||||
Tâches CI typiques :
|
||||
|
||||
1. `pytest` sur le backend
|
||||
2. Lancement d’un backend en mode test
|
||||
3. Envoi d’un payload JSON factice
|
||||
4. Vérification de la réponse HTTP
|
||||
|
||||
---
|
||||
|
||||
# 8. Critères de qualité
|
||||
|
||||
L’application sera considérée comme “OK” pour usage perso si :
|
||||
|
||||
- Au moins 1 test unitaire par endpoint critique
|
||||
- Un scénario E2E réussi
|
||||
- `bench.sh` fonctionne sur :
|
||||
- 1 machine physique
|
||||
- 1 VM
|
||||
- Les erreurs d’auth/token sont gérées proprement
|
||||
- Le Dashboard reste utilisable avec plusieurs dizaines de devices et benchmarks
|
||||
|
||||
---
|
||||
|
||||
# 9. Améliorations possibles
|
||||
|
||||
- Ajout de tests de charge (Gatling / k6) sur le backend
|
||||
- Ajout de tests de non-régression des scores (baseline)
|
||||
- Ajout de tests visuels (Playwright, Cypress)
|
||||
- Intégration d’un badge “build/test status” dans le README principal
|
||||
Reference in New Issue
Block a user