1. À propos du Black Box Testing
Le Black Box Testing, ou test en boîte noire, consiste à évaluer un système à partir de ses entrées et de ses résultats observables, sans s'appuyer sur la connaissance de son implémentation. Le testeur peut utiliser une interface graphique, une API ou une commande et observer une réponse, un message d'erreur ou un changement visible dans l'application.
Pour décider si le comportement est correct, le testeur s'appuie sur une référence externe, par exemple un cahier des charges, la documentation de l'API ou une règle métier. Si un formulaire exige un âge minimal de 18 ans, le testeur peut vérifier les réponses pour 17 et 18 ans sans consulter le code qui effectue la comparaison.
| Approche | Informations utilisées pour concevoir les tests | Exemple |
|---|---|---|
| Boîte noire | Interface, spécifications et résultats observables. | Tester les valeurs 17 et 18 à partir de la règle d'inscription. |
| Boîte grise | Informations partielles sur le fonctionnement interne. | Préparer des tests de session en connaissant l'architecture générale de l'authentification. |
| Boîte blanche | Code ou structure interne du composant testé. | Choisir des entrées pour exercer les deux branches d'une condition dans le code. |
2. Préparer et exécuter un test en boîte noire
- Définir le périmètre. Identifier l'interface à tester, la version de l'application et l'environnement utilisé.
- Relever les règles attendues. Par exemple, un service doit accepter les quantités entières comprises entre 1 et 10 inclus.
- Écrire les cas de test. Pour chaque cas, préciser l'état initial, l'entrée, l'action et le résultat attendu.
- Exécuter les tests. Soumettre les entrées par l'interface et relever les réponses et les effets observables.
- Comparer et documenter. Si le résultat observé diffère du résultat attendu, consigner les étapes de reproduction et les preuves utiles.
L'oracle de test est la référence utilisée pour juger le résultat. Dans l'exemple des quantités, c'est la règle métier qui permet de prévoir que 10 doit être accepté. La réponse de l'application constitue le résultat observé.
3. Choisir les cas de test
Classes d'équivalence
Le partitionnement en classes d'équivalence regroupe les entrées censées être traitées de la même manière. Pour une quantité entière de 1 à 10, on distingue les valeurs trop petites, les valeurs autorisées et les valeurs trop grandes. On peut commencer avec un représentant par groupe, par exemple 0, 5 et 11. Si l'interface accepte aussi du texte brut, une valeur comme abc permet de tester une entrée non numérique.
Analyse des valeurs limites
L'analyse des valeurs limites cible les points où le comportement change. Pour l'intervalle de 1 à 10 inclus, les triplets 0, 1, 2 et 9, 10, 11 couvrent les valeurs situées juste en dessous, sur et juste au-dessus de chaque borne. Ces cas peuvent révéler une borne oubliée ou une comparaison trop stricte.
Tables de décision
Une table de décision aide lorsque le résultat dépend de plusieurs conditions. Si une opération exige un compte actif et un rôle autorisé, on teste les quatre combinaisons. Seule la combinaison « compte actif et rôle autorisé » doit permettre l'opération.
4. Détecter une erreur de limite avec Python
Ce programme autonome simule un service qui doit accepter les quantités entières de 1 à 10 inclus. La fonction valider_quantite() joue le rôle de l'interface publique du service. Elle contient volontairement une erreur sur la borne haute. Les cas de test sont construits à partir de la règle métier et comparent chaque réponse de l'interface au résultat attendu.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | def valider_quantite(quantite): # Implémentation du service simulé avec une erreur volontaire. if 1 <= quantite < 10: return "acceptée" return "refusée" # Cas de test établis à partir de la règle : de 1 à 10 inclus. cas_de_test = [ (0, "refusée"), (1, "acceptée"), (2, "acceptée"), (9, "acceptée"), (10, "acceptée"), (11, "refusée"), ] for quantite, attendu in cas_de_test: observe = valider_quantite(quantite) if observe == attendu: verdict = "OK" else: verdict = "ÉCHEC" print(f"{quantite} : attendu = {attendu}, observé = {observe} [{verdict}]") |
Sortie du programme
1 2 3 4 5 6 | 0 : attendu = refusée, observé = refusée [OK] 1 : attendu = acceptée, observé = acceptée [OK] 2 : attendu = acceptée, observé = acceptée [OK] 9 : attendu = acceptée, observé = acceptée [OK] 10 : attendu = acceptée, observé = refusée [ÉCHEC] 11 : attendu = refusée, observé = refusée [OK] |
Le cas 10 révèle une anomalie observable. Le service refuse une valeur que la spécification autorise. La boucle détecte cet écart en appelant l'interface et en comparant les réponses. Le code du service figure dans le même script pour permettre une exécution autonome. Sa lecture permet ensuite de localiser la cause : la comparaison exclut la borne haute.
5. Appliquer la boîte noire à la cybersécurité
Dans un test d'intrusion en boîte noire, le testeur évalue le système depuis les interfaces accessibles dans le périmètre convenu, par exemple une application Web ou une API. L'autorisation de test précise les cibles, les comptes utilisables et les actions permises. Un laboratoire local peut servir à rejouer ces scénarios avec des données fictives.
| Contrôle testé | Scénario de test | Comportement attendu |
|---|---|---|
| Authentification | Ouvrir une ressource réservée aux utilisateurs connectés depuis une session anonyme. | Le serveur refuse l'accès ou redirige vers la connexion sans exposer la ressource. |
| Contrôle d'accès | Avec le compte de test A, demander directement une ressource privée appartenant au compte de test B. | Le serveur ne renvoie ni le contenu privé ni les données réservées au compte B. |
| Gestion de session | Se déconnecter puis rejouer une requête protégée avec l'ancien identifiant de session. | L'ancien identifiant ne donne plus accès à la ressource protégée. |
| Gestion des erreurs | Envoyer une entrée mal formée à l'API de test. | L'API renvoie une erreur contrôlée sans divulguer de trace d'exécution ni de secret. |
Pour un défaut de contrôle d'accès, le rapport doit préciser le rôle du compte utilisé, la ressource demandée, le résultat attendu et les données effectivement exposées. Vérifiez le contenu de la réponse et ses effets, car un code HTTP à lui seul peut masquer un résultat inattendu.
6. À retenir
Le test en boîte noire part d'une règle attendue, soumet une entrée par l'interface et compare le résultat observé à cette règle. Les classes d'équivalence aident à choisir des entrées représentatives, tandis que les valeurs limites ciblent les changements de comportement. En cybersécurité, les tests réussis établissent que les contrôles ont fonctionné dans les scénarios exercés. Leur portée dépend des interfaces, des comptes et des conditions couverts.
Auteur : Younes Derfoufi
Lieu de travail : CRMEF OUJDA
Site Web : www.tresfacile.net
Chaîne YouTube : https://www.youtube.com/user/InformatiquesFacile
Me contacter : https://www.tresfacile.net/me-contacter/
