264 lines
6.4 KiB
Markdown
264 lines
6.4 KiB
Markdown
|
||
# 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
|