Files

2025-12-20 03:47:10 +01:00

6.4 KiB

Executable File

Raw Permalink Blame History

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 :

Backend API
- Validation des endpoints
- Validation de la persistance en base
- Validation de la sécurité (token)
Script client bench.sh
- Fonctionnement sur différentes machines Debian/Ubuntu
- Gestion des erreurs (outils manquants, serveur indisponible)
- Qualité du JSON envoyé
Frontend WebUI
- Rendu des pages (Dashboard, Devices, Device Detail, Settings)
- Consommation correcte de l’API
- UX minimale (lisibilité, tri, navigation)
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 :

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 :

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

Déployer l’application.
Vérifier Dashboard vide, message “Aucun device”.
Exécuter bench.sh sur une machine.
Rafraîchir Dashboard :
- Device apparaît avec score.

Scénario 2 : consultation d’un device

Cliquer sur un device dans le Dashboard.
Page détail :
- Hardware résumé cohérent.
- Dernier benchmark affiché.
Onglet Benchmarks :
- Historique listé.

Scénario 3 : Documents

Aller dans onglet Documents d’un device.
Uploader un PDF.
Vérifier sa présence dans la liste.
Télécharger pour confirmer.

Scénario 4 : Liens constructeur

Onglet Links d’un device.
Ajouter un lien avec label + URL.
Vérifier qu’il est cliquable.
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

Lancer backend + frontend via docker compose up.
Déployer bench.sh sur un client Debian.
Exécuter :

curl -s https://.../bench.sh | bash -s -- \
  --server http://IP_BACKEND:8007/api/benchmark \
  --token XXX \
  --iperf-server 10.0.0.10

Vérifier côté backend (logs) qu’un benchmark a été créé.
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 :

pytest sur le backend
Lancement d’un backend en mode test
Envoi d’un payload JSON factice
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

6.4 KiB Executable File Raw Permalink Blame History Unescape Escape