L’architecture client-serveur est un modèle où une partie du système demande des données ou une action et une autre les fournit. Le client lance une requête ; le serveur la traite et renvoie un résultat.
Cela paraît simple, mais c’est un modèle fondamental pour les testeurs QA. En regardant le produit ainsi, de nombreux bugs cessent d’être des « comportements étranges de l’UI » et deviennent des points de défaillance identifiables : client, réseau, serveur, base, intégration externe, cache, file ou autorisation.
Fonctionnement
Dans un produit web ou mobile typique, le client est un navigateur, une application mobile ou un autre service. L’utilisateur clique ; le client collecte les données et envoie une requête. Le serveur la reçoit, vérifie les permissions, valide l’entrée, exécute la logique métier et consulte au besoin une base ou des systèmes externes.
- →Le client peut être un navigateur, une application mobile, un autre service ou un partenaire externe.
- →Le serveur n’est pas forcément un seul processus ni un monolithe.
- →Passerelles, répartiteurs de charge, caches, files, bases et intégrations externes se trouvent souvent sur le trajet entre client et serveur.
Un seul clic peut donc déclencher une chaîne d’actions plutôt qu’une seule opération.
Exemple simple
L’utilisateur clique sur « Payer la commande ». Le client envoie l’ID de commande, le montant et les informations utilisateur. Le serveur vérifie l’existence de la commande, les droits de paiement de l’utilisateur et la compatibilité de son statut. Il appelle ensuite le prestataire de paiement, enregistre le résultat et répond au client.
L’utilisateur ne voit que le bouton et le message final. Le testeur doit voir toute la chaîne, sinon il risque d’attribuer le défaut à une mauvaise cause.
Ce que les testeurs QA doivent vérifier
- →Une requête a-t-elle réellement été envoyée ?
- →Quelle requête exacte a été envoyée ?
- →Qu’a renvoyé le serveur ?
- →Comment le client a-t-il interprété la réponse ?
- →Les données ont-elles changé partout où elles le devaient ?
- →Un service externe ou un environnement instable intervient-il ?
Si l’UI affiche un mauvais montant, plusieurs causes sont possibles : mauvaise valeur serveur, données incorrectes en base, réponse externe inattendue ou mauvais rendu client d’une réponse correcte. Le symptôme visible est identique, mais les points de défaillance diffèrent.
Les couches les plus souvent testées
- →Couche client : envoi de la requête, construction correcte des paramètres et affichage du résultat.
- →Couche serveur : validation, contrôle d’accès et logique métier corrects.
- →Couche de données : création, modification ou suppression conforme aux attentes.
- →Couche d’intégration : gestion des échecs, délais expirés et réponses externes inattendues.
Utilité pratique
D’abord, l’analyse des défauts. Un testeur limité à l’écran écrit « cela ne marche pas ». Un testeur qui comprend l’architecture précise : paramètre incorrect dans la requête ; réponse 403 alors que le rôle devrait être autorisé ; base non mise à jour. Le rapport est beaucoup plus utile.
Ensuite, la conception des tests. Comprendre les couches impliquées permet de concevoir de meilleures vérifications : parcours nominal UI, erreurs réseau, requêtes répétées, échecs partiels, données incohérentes et problèmes d’intégration.
Enfin, la communication. Ce modèle aide à préciser si le problème se situe côté client, serveur, données ou prestataire externe. Cela fait gagner du temps et facilite le tri des défauts.
Points essentiels pour les testeurs QA
- →Une action utilisateur implique souvent plusieurs étapes techniques.
- →Un même bug visible dans l’UI peut provenir de couches différentes.
- →Pour isoler un problème, examinez la requête, la réponse, les données et les dépendances, en plus de l’écran.
- →Comprendre l’architecture client-serveur rend les rapports plus précis et accélère les analyses.
Lectures complémentaires
- →Dans cette base de connaissances : Qu’est-ce qu’une API ? — une introduction à l’interface de communication.
- →Dans cette base de connaissances : HTTP et HTTPS — pour mieux comprendre le transport des requêtes et des réponses.
- →Dans cette base de connaissances : Méthodes, codes de statut et en-têtes — pour interpréter plus sûrement les signaux techniques des API.
Suivre une action du navigateur jusqu’au stockage
Scénario fictif : un apprenant enregistre le nom affiché de son profil. Une lecture ultérieure doit montrer le nouveau nom pour le même compte autorisé. Un message de succès prouve seulement que le client l’a affiché, pas l’état enregistré.
Couche Observation Ce qu’elle permet d’établir
Navigateur Action, saisie, corps de requête et chronologie Ce que le client a réellement envoyé
Réseau/API Méthode, URL, statut, corps, ID de corrélation La réponse API observée
Journaux du service Même ID de corrélation et résultat de validation Le chemin serveur ayant traité la requête, si les journaux sont disponibles
Stockage Lecture de test autorisée de l’enregistrement cible La valeur persistée au moment de l’observation
Lecture API ultérieure Réponse GET pour le même compte Si le chemin de lecture expose la valeur enregistréeUtilisez une lecture de test autorisée ou un dispositif de test plutôt que de supposer un accès à la base. Dans les systèmes asynchrones, la cohérence immédiate n’est pas forcément garantie : convenez d’abord du signal de fin et du délai. Si le navigateur expire après une écriture, inspectez le résultat avant de réessayer ; le serveur l’a peut-être déjà validée.
Pour isoler un échec, comparez les observations voisines. De mauvaises données de requête orientent vers la préparation client ; une requête correcte avec une erreur de validation documentée vers l’interprétation du contrat ou de l’entrée ; un succès sans données vers le chemin d’écriture ou le traitement asynchrone. Ce sont des pistes, pas des causes prouvées. Conservez horodatages et ID de corrélation, et retirez les secrets des preuves.