Exemple de cas de test pour une application Web (liste de contrôle)

⚡ Résumé intelligent

La checklist complète de test d'application web couvre l'ergonomie, les fonctionnalités, la compatibilité, les bases de données, les API, la sécurité, les performances et l'accessibilité. Chaque section ci-dessous propose des scénarios de test prêts à l'emploi que les équipes d'assurance qualité peuvent intégrer directement dans un outil de gestion des tests.

  • ⚙️ Fonctionnel d'abord : Validez les champs obligatoires, les longueurs des limites, les années bissextiles, la division par zéro et le comportement en cas de dépassement de délai avant toute vérification cosmétique.
  • 🧭 Signaux d'utilisabilité : Vérifiez l'alignement, les infobulles, l'accès au clavier, les barres de défilement et la récupération des messages d'erreur afin qu'un nouvel utilisateur ne soit jamais bloqué.
  • 🌐 Matrice de compatibilité : Répétez les flux critiques sur Chrome, FirefoxEdge, Safari et les navigateurs mobiles afin de mettre en évidence les différences de mise en page et de script.
  • 🇧🇷 Intégrité de la base de données : Faites correspondre les valeurs frontales aux enregistrements stockés, vérifiez les clés, les déclencheurs, les procédures stockées et les longueurs de champs sur les deux couches.
  • ???? Couche API : Affirmer les codes d'état, les schémas, l'authentification, les limites de débit et la gestion des erreurs en aval séparément du navigateur.
  • (I.e. Niveau de sécurité de base : Imposer le protocole HTTPS, chiffrer les secrets stockés, verrouiller les comptes après des échecs répétés et détecter les injections SQL et les attaques par force brute.
  • 🚀 Performance et accessibilité : Le script charge les profils de manière automatisée plutôt que manuelle, puis vérifie le contraste WCAG, les étiquettes et le fonctionnement du clavier.

Lors du test des applications Web, il convient de considérer le modèle mentionné ci-dessous. La liste de contrôle mentionnée ci-dessous est presque applicable à tous les types d'applications Web en fonction des exigences de l'entreprise.

Le modèle ci-dessus montre comment une seule feuille peut contenir des scénarios pour chaque domaine de la liste de contrôle. Pour plus d'informations, consultez le tests d'applications Web Vue d'ensemble.

Examinons maintenant chaque liste de contrôle en détail :

Essais fonctionnels

Qu’est-ce que les tests fonctionnels ?

  • Tester les fonctionnalités et le comportement opérationnel d’un produit pour s’assurer qu’ils correspondent à ses spécifications.
  • Tests qui ignorent le mécanisme interne d'un système ou d'un composant et se concentrent uniquement sur les sorties générées en réponse aux entrées et aux conditions d'exécution sélectionnées.

Quel est le but ou le but des tests fonctionnels ?

  • L'objectif de Essais fonctionnels consiste à vérifier si votre produit répond aux spécifications fonctionnelles prévues mentionnées dans votre documentation de développement.

Exemples de scénarios de tests fonctionnels :

  • Testez tous les champs obligatoires doivent être validés.
  • Testez le signe astérisque qui doit s’afficher pour tous les champs obligatoires.
  • Testez, le système ne doit pas afficher le message d'erreur pour les champs facultatifs.
  • Vérifiez que les années bissextiles sont correctement validées et ne provoquent pas d'erreurs/erreurs de calcul.
  • Testez les champs numériques ne doivent pas accepter les alphabets et un message d'erreur approprié doit s'afficher.
  • Testez les nombres négatifs si cela est autorisé pour les champs numériques.
  • La division de test par zéro doit être traitée correctement pour les calculs.
  • Testez la longueur maximale de chaque champ pour vous assurer que les données ne sont pas tronquées.
  • Testez le message contextuel (« Ce champ est limité à 500 caractères ») qui devrait s'afficher si les données atteignent la taille maximale du champ.
  • Testez qu'un message de confirmation doit s'afficher pour les opérations de mise à jour et de suppression.
  • Testez les valeurs des montants qui doivent s’afficher au format monétaire.
  • Testez tous les champs de saisie pour les caractères spéciaux.
  • Testez la fonctionnalité de délai d'attente.
  • Testez la fonctionnalité de tri.
  • Testez la fonctionnalité des boutons disponibles
  • Testez la politique de confidentialité et la FAQ sont clairement définies et devraient être disponibles pour les utilisateurs.
  • Testez si une fonctionnalité échoue, l'utilisateur est redirigé vers la page d'erreur personnalisée.
  • Testez que tous les documents téléchargés sont ouverts correctement.
  • Testez que l'utilisateur devrait pouvoir télécharger les fichiers téléchargés.
  • Testez la fonctionnalité de messagerie du système.
  • Testez le Java le script fonctionne correctement dans différents navigateurs (IE, Firefox, Chrome, Safari et Opera).
  • Testez pour voir ce qui se passe si un utilisateur supprime les cookies lorsqu'il est sur le site.
  • Testez pour voir ce qui se passe si un utilisateur supprime les cookies après avoir visité un site.
  • Testez toutes les données dans la zone de liste déroulante/liste et sont classées par ordre chronologique.

Une fois que les fonctionnalités fonctionnent correctement, la question suivante est de savoir si les utilisateurs réels peuvent les utiliser sans aide.

Tests d'utilisabilité

Qu'est-ce que les tests d'utilisabilité ?

  • Les tests d'utilisabilité ne sont rien d'autre que la vérification de la convivialité.
  • Lors des tests d'utilisabilité, le flux de l'application est testé afin qu'un nouvel utilisateur puisse comprendre facilement l'application.
  • Fondamentalement, la navigation dans le système est vérifiée lors des tests d'utilisabilité.

Quel est le but ou l'objectif des tests d'utilisabilité ?

Un test d'utilisabilité établit la facilité d'utilisation et l'efficacité d'un produit à l'aide de pratiques de test d'utilisabilité standard.

Exemples de cas de tests d'utilisabilité

  • Le contenu de la page Web doit être correct, sans aucune erreur d'orthographe ou de grammaire
  • Toutes les polices doivent être identiques selon les exigences.
  • Tout le texte doit être correctement aligné.
  • Tous les messages d'erreur doivent être corrects, sans aucune erreur d'orthographe ou de grammaire et le message d'erreur doit correspondre à l'étiquette du champ.
  • Le texte de l’info-bulle doit être présent pour chaque champ.
  • Tous les champs doivent être correctement alignés.
  • Un espace suffisant doit être prévu entre les étiquettes de champ, les colonnes, les lignes et les messages d'erreur.
  • Tous les boutons doivent être dans un format et une taille standard.
  • Le lien d’accueil doit être présent sur chaque page.
  • Les champs désactivés doivent être grisés.
  • Recherchez les liens et les images brisés.
  • Un message de confirmation doit être affiché pour tout type d’opération de mise à jour et de suppression.
  • Consultez le site sur différentes résolutions (640 x 480, 600×800 etc.?)
  • Vérifiez que l'utilisateur final peut exécuter le système sans frustration.
  • Vérifiez que l'onglet doit fonctionner correctement.
  • La barre de défilement ne doit apparaître que si nécessaire.
  • S'il y a un message d'erreur lors de la soumission, les informations renseignées par l'utilisateur devraient être là.
  • Le titre doit s'afficher sur chaque page Web
  • Tous les champs (zone de texte, liste déroulante, bouton radio, etc.) et les boutons doivent être accessibles par des raccourcis clavier et l'utilisateur doit pouvoir effectuer toutes les opérations à l'aide du clavier.
  • Vérifiez si les données de la liste déroulante ne sont pas tronquées en raison de la taille du champ. Vérifiez également si les données sont codées en dur ou gérées via l'administrateur.

Une mise en page qui s'affiche correctement dans un navigateur peut ne pas fonctionner dans un autre ; il est donc conseillé de reproduire les mêmes écrans dans tous les environnements pris en charge.

Test de compatibilité

Qu'est-ce que le test de compatibilité ?

  • Les tests de compatibilité sont utilisés pour déterminer si votre logiciel est compatible avec d'autres éléments d'un système avec lequel il doit fonctionner, par exemple les navigateurs, Operasystèmes de ting, ou matériel.

Quel est le but ou l'objectif des tests de compatibilité ?

  • Le but des tests de compatibilité est d'évaluer les performances du logiciel dans un navigateur particulier, Operasystèmes, matériels ou logiciels.

Exemples de scénarios de tests de compatibilité :

  • Testez le site Web dans différents navigateurs (IE, Firefox, Chrome, Safari et Opera) et assurez-vous que le site Web s'affiche correctement.
  • Testez que la version HTML utilisée est compatible avec les versions de navigateur appropriées.
  • Testez l'affichage correct des images dans différents navigateurs.
  • Testez les polices utilisables dans différents navigateurs.
  • Testez le code du script java qui est utilisable dans différents navigateurs.
  • Testez les GIF animés sur différents navigateurs.

Un rendu cohérent ne prouve rien quant aux données cachées derrière l'écran. test sur plusieurs navigateurs La matrice permet de gérer cette zone.

Test de base de données

Qu'est-ce que le test de base de données ?

  • In Test de base de données Les enregistrements backend sont testés et ont été insérés via les applications Web ou de bureau. Les données affichées dans l'application Web doivent correspondre aux données stockées dans la base de données.

Pour effectuer les tests de base de données, le testeur doit être conscient des points mentionnés ci-dessous:

  • Le testeur doit comprendre parfaitement les exigences fonctionnelles, la logique métier, le flux des applications et la conception de la base de données.
  • Le testeur doit comprendre les tables, les déclencheurs, les procédures de stockage, les vues et les curseurs utilisés pour l'application.
  • Le testeur doit comprendre la logique des déclencheurs, des procédures de stockage, des vues et des curseurs créés.
  • Le testeur doit déterminer les tables qui sont affectées lorsque les opérations d'insertion, de mise à jour et de suppression (DML) sont effectuées via les applications Web ou de bureau.

À l'aide des points mentionnés ci-dessus, le testeur peut facilement rédiger les scénarios de test pour les tests de base de données.

Exemples de cas de test pour les tests de bases de données :

  • Vérifiez le nom de la base de données : le nom de la base de données doit correspondre aux spécifications.
  • Vérifiez les tables, les colonnes, les types de colonnes et les valeurs par défaut : tout doit correspondre aux spécifications.
  • Vérifiez si la colonne autorise ou non une valeur nulle.
  • Vérifiez la clé primaire et étrangère de chaque table.
  • Vérifiez la procédure stockée :
  • Testez si la procédure stockée est installée ou non.
  • Vérifiez le nom de la procédure stockée
  • Vérifiez les noms des paramètres, les types et le nombre de paramètres.
  • Testez les paramètres s’ils sont requis ou non.
  • Testez la procédure stockée en supprimant certains paramètres
  • Testez lorsque la sortie est nulle, les enregistrements zéro devraient être affectés.
  • Testez la procédure stockée en écrivant simplement SQL requêtes.
  • Tester si la procédure stockée renvoie les valeurs
  • Testez la procédure stockée avec des exemples de données d’entrée.
  • Vérifiez le comportement de chaque indicateur dans le tableau.
  • Vérifiez que les données sont correctement enregistrées dans la base de données après chaque soumission de page.
  • Vérifiez les données si les opérations DML (Mise à jour, suppression et insertion) sont effectuées.
  • Vérifiez la longueur de chaque champ : la longueur du champ dans le back-end et le front-end doit être la même.
  • Vérifiez les noms des bases de données QA, UAT et production. Les noms doivent être uniques.
  • Vérifiez les données chiffrées dans la base de données.
  • Vérifiez la taille de la base de données. Testez également le temps de réponse de chaque requête exécutée.
  • Vérifiez les données affichées sur le front-end et assurez-vous qu’elles sont les mêmes dans le back-end.
  • Vérifiez la validité des données en insérant les données invalides dans la base de données.
  • Vérifiez les déclencheurs.

Liste de contrôle des tests d'API

La plupart des règles métier résident désormais derrière des points de terminaison REST ou GraphQL ; par conséquent, les vérifications effectuées par le navigateur ne suffisent plus à prouver le bon fonctionnement du système. Tester directement les points de terminaison expose des problèmes de compatibilité.tract et les défauts d'autorisation bien plus tôt que l'interface utilisateur ne le permet.

Avant de valider un point de terminaison, il convient de couvrir les scénarios suivants :

Exemples de scénarios de test pour les tests d'API :

  • Vérifiez les codes d'état documentés pour déterminer la réussite, l'échec de la validation, l'accès non autorisé et l'erreur serveur.
  • Vérifiez que la charge utile de la réponse correspond au schéma publié, y compris les noms de champs et les types de données.
  • Vérifiez que les paramètres manquants ou mal formés renvoient un message lisible plutôt qu'une pile. trace.
  • Vérifiez que les jetons d'authentification expirent, se rafraîchissent correctement et ne peuvent pas être réutilisés après la déconnexion.
  • Vérifiez l'autorisation basée sur les rôles, afin qu'un compte standard ne puisse pas accéder aux points de terminaison d'administrateur en modifiant un identifiant.
  • Vérifiez les valeurs limites de chaque paramètre, y compris les chaînes vides et les longueurs maximales.
  • Vérifiez que la limitation de débit renvoie la réponse de limitation correcte au lieu d'échouer silencieusement.
  • Vérifiez que le point de terminaison se dégrade correctement lorsqu'un service tiers expire.
  • Vérifiez qu'aucun mot de passe, jeton ou chemin interne n'apparaît dans les réponses ou les messages d'erreur.

Exécutez cette liste dans chaque environnement, car les environnements de test et de production présentent souvent des ensembles d'autorisations différents. Voir la Test d'API aperçu et tester manuellement une API REST.

Plusieurs de ces contrôles recoupent des travaux de sécurité.

Test de sécurité

Test de sécurité implique le test pour identifier les failles et les lacunes du point de vue de la sécurité.

Exemples de scénarios de test pour les tests de sécurité :

  • Vérifiez que la page Web contenant des données importantes telles que le mot de passe, les numéros de carte de crédit, les réponses secrètes aux questions de sécurité, etc. doit être soumise via HTTPS (SSL).
  • Vérifiez que les informations importantes telles que le mot de passe, les numéros de carte de crédit, etc. doivent s'afficher au format crypté.
  • Vérifiez que les règles de mot de passe sont mises en œuvre sur toutes les pages d'authentification telles que l'inscription, le mot de passe oublié, le changement de mot de passe.
  • Vérifiez si le mot de passe est modifié, l'utilisateur ne devrait pas pouvoir se connecter avec l'ancien mot de passe.
  • Vérifiez que les messages d’erreur ne doivent afficher aucune information importante.
  • Vérifiez si l'utilisateur est déconnecté du système ou si la session utilisateur a expiré, l'utilisateur ne devrait pas pouvoir naviguer sur le site.
  • Vérifiez pour accéder directement aux pages Web sécurisées et non sécurisées sans connexion.
  • Vérifiez que l'option « Afficher le code source » est désactivée et ne doit pas être visible par l'utilisateur.
  • Vérifiez que le compte utilisateur est verrouillé si l'utilisateur saisit plusieurs fois le mauvais mot de passe.
  • Vérifiez que les cookies ne doivent pas stocker de mots de passe.
  • Vérifiez si une fonctionnalité ne fonctionne pas, le système ne doit afficher aucune information sur l'application, le serveur ou la base de données. Au lieu de cela, il devrait afficher la page d'erreur personnalisée.
  • Vérifiez les attaques par injection SQL.
  • Vérifiez les rôles des utilisateurs et leurs droits. Par exemple, le demandeur ne doit pas pouvoir accéder à la page d'administration.
  • Vérifiez que les opérations importantes sont consignées dans les fichiers journaux et que ces informations devraient être traccapable.
  • Vérifiez que les valeurs de session sont dans un format crypté dans la barre d'adresse.
  • Vérifiez que les informations des cookies sont stockées dans un format crypté.
  • Vérifiez l'application pour les attaques par force brute

Une application durcie qui se déforme sous la charge reste inutilisable, la passe suivante consiste donc à mesurer l'échelle.

Test de performance

Test de performance est menée pour évaluer la conformité d’un système ou d’un composant aux exigences de performance spécifiées.

Scénarios de tests généraux :

  • Déterminer les performances, la stabilité et l’évolutivité d’une application dans différentes conditions de charge.
  • Déterminer si l'architecture actuelle peut prendre en charge l'application aux niveaux d'utilisateurs de pointe.
  • Déterminer quelle taille de configuration offre le meilleur niveau de performances.
  • Identifier les goulots d’étranglement des applications et de l’infrastructure.
  • Déterminer si la nouvelle version du logiciel a eu un impact négatif sur le temps de réponse.
  • Évaluer le produit et/ou le matériel pour déterminer s’il peut gérer les volumes de charge projetés.

Comment faire des tests de performances ? Par tests manuels ou par automatisation

En pratique, il n'est pas possible d'effectuer les tests de performances manuellement en raison de certains inconvénients tels que :

  • Un plus grand nombre de ressources sera nécessaire.
  • Des actions simultanées ne sont pas possibles.
  • Une surveillance adéquate du système n’est pas disponible.
  • Pas évident de réaliser la tâche répétitive.

Par conséquent, pour surmonter les problèmes ci-dessus, nous devons utiliser l’outil de test de performances. Vous trouverez ci-dessous la liste de quelques outils de test populaires.

Il manque encore un public : les utilisateurs qui accèdent à ces écrans grâce à des technologies d’assistance.

Liste de contrôle des tests d'accessibilité

Les tests d'accessibilité confirment que les personnes utilisant des lecteurs d'écran, la navigation au clavier ou des loupes peuvent effectuer les mêmes parcours que tous les autres utilisateurs. Il s'agit également d'une exigence d'achat, car les entreprises...tracts référence couramment niveau AA des WCAG 2.2 Ces défauts sont structurels et il est beaucoup moins coûteux de les corriger rapidement.

Exemples de scénarios de test pour les tests d'accessibilité :

  • Vérifiez que les images pertinentes comportent un texte alternatif descriptif et que les images décoratives sont masquées pour les technologies d'assistance.
  • Vérifiez que chaque contrôle de formulaire possède une étiquette associée par programmation, et non pas seulement un texte d'espace réservé adjacent.
  • Vérifiez que la page fonctionne uniquement avec le clavier, avec un indicateur de focus visible à chaque étape.
  • Vérifiez que le texte et les éléments interactifs respectent le rapport de contraste minimal par rapport à leur arrière-plan.
  • Vérifiez que les titres suivent un ordre logique sans sauts de niveaux, afin que la navigation par lecteur d'écran fonctionne.
  • Vérifier que les messages d'erreur sont bien transmis aux technologies d'assistance et identifier le champ défaillant.
  • Vérifiez que la page reste utilisable à un zoom de 200 % sans défilement horizontal.
  • Vérifiez que les widgets personnalisés tels que les fenêtres modales, les onglets et les accordéons exposent les rôles et les états corrects.

Les scanners automatisés ne détectent qu'une partie de ces problèmes ; il est donc conseillé d'ajouter une vérification manuelle du clavier et du lecteur d'écran. test d'accessibilité Le document de référence couvre l'outillage.

FAQ

Un plan de test est un document formel qui décrit le périmètre, le calendrier, les ressources, les risques et les critères de sortie d'une version. Une checklist est un aide-mémoire concis répertoriant les conditions à vérifier. Le plan encadre le projet ; la checklist encadre chaque session de test.

RevIl convient de la revoir après chaque mise à jour majeure, nouvelle intégration ou incident de production. Chaque défaut non détecté doit être signalé par une ligne afin d'éviter sa récurrence. Une liste de contrôle jamais mise à jour cesse rapidement de refléter le comportement réel de l'application.

La plupart des équipes ancrent leur couverture de sécurité sur le Guide de test de sécurité Web OWASPL’accessibilité est conforme aux WCAG 2.2, et la terminologie générale des processus est conforme à celle de l’ISTQB. Ces références permettent de garantir la traçabilité de la liste de contrôle, plutôt que de la laisser reposer uniquement sur les habitudes de l’équipe.

Oui. L'intégration des exigences, des récits utilisateurs ou des spécifications d'API dans un modèle de langage étendu permet d'obtenir une première ébauche solide de scénarios. Un testeur doit ensuite supprimer les doublons, ajouter les règles métier que le modèle ne peut pas inférer et vérifier que chaque élément est bien vérifiable.

Les localisateurs auto-réparateurs réidentifient les éléments après des modifications de balisage, réduisant ainsi les défaillances aléatoires qui constituent la majeure partie des efforts de maintenance. L'IA regroupe également les défauts dupliqués et détermine l'ordre d'exécution des suites de tests, ce qui permet de raccourcir les cycles de régression malgré l'allongement de la liste de contrôle.

Résumez cet article avec :