4. Test de compatibilité client
1. Tests de plateforme
Il existe de nombreux types de systèmes d'exploitation différents sur le marché, les plus courants étant Windows, Unix, Macintosh, Linux, etc. Le système d'exploitation utilisé par l'utilisateur final du système d'application Web dépend de la configuration du système utilisateur. De cette manière, des problèmes de compatibilité peuvent survenir et la même application peut s'exécuter normalement sous certains systèmes d'exploitation, mais peut ne pas fonctionner sous d'autres systèmes d'exploitation.
Par conséquent, avant la sortie du système Web, il est nécessaire de tester la compatibilité du système Web sous différents systèmes d'exploitation.
2. Test du navigateur
Le navigateur est le composant principal du client Web et les navigateurs de différents fabricants prennent en charge différemment Java, JavaScript, ActiveX, les plug-ins ou différentes spécifications HTML. Par exemple, ActiveX est un produit de Microsoft et est conçu pour Internet Explorer, JavaScript est un produit de Netscape, Java est un produit de Sun, etc. De plus, les styles de cadre et de hiérarchie s'affichent différemment selon les navigateurs, voire ne s'affichent pas du tout. Différents navigateurs ont des paramètres de sécurité et Java différents.
Une façon de tester la compatibilité du navigateur consiste à créer une matrice de compatibilité. Dans cette matrice, l'adaptabilité de certains composants et paramètres à différents fournisseurs et différentes versions de navigateurs est testée.
5. Test de sécurité
Les domaines de tests de sécurité du système d'application Web comprennent principalement :
(1) Le système d'application Web actuel adopte essentiellement la méthode consistant à s'inscrire d'abord, puis à se connecter. Par conséquent, vous devez tester les noms d'utilisateur et mots de passe valides et invalides, faire attention à savoir s'ils sont sensibles à la casse, limiter le nombre de fois que vous pouvez essayer, si vous pouvez parcourir directement une certaine page sans vous connecter, etc.
(2) Si le système d'application Web a un délai d'expiration, c'est-à-dire si l'utilisateur ne clique sur aucune page dans un certain laps de temps (par exemple 15 minutes) après la connexion, s'il doit se reconnecter pour utilisez-le normalement.
(3) Afin d'assurer la sécurité du système d'application Web, les fichiers journaux sont cruciaux. Il est nécessaire de tester si les informations pertinentes sont écrites dans le fichier journal et si elles peuvent être retracées.
(4) Lorsqu'un socket sécurisé est utilisé, il est également nécessaire de tester si le cryptage est correct et de vérifier l'intégrité des informations.
(5) Les scripts côté serveur constituent souvent des failles de sécurité, et ces failles sont souvent exploitées par les pirates. Par conséquent, il est également nécessaire de tester le problème selon lequel les scripts ne peuvent pas être placés et modifiés côté serveur sans autorisation.
6. Résumé
Les méthodes de test des systèmes basés sur le Web ont été abordées ci-dessus sous les aspects de fonction, de performances, de convivialité, de compatibilité client, de sécurité, etc.
Les tests de systèmes basés sur le Web présentent des similitudes et des différences avec les tests de logiciels traditionnels, ce qui pose de nouveaux défis aux tests de logiciels. Les tests du système Web doivent non seulement vérifier s'il fonctionne conformément aux exigences de conception, mais également évaluer si le système s'affiche correctement sur les navigateurs des différents utilisateurs. Il est important d’effectuer également des tests de sécurité et d’utilisabilité du point de vue de l’utilisateur final.
Notes sur les tests de pages Web :
Les tests Web ne sont souvent pas valorisés par les testeurs et sont considérés comme un travail physique sans contenu technique. Je parlerai de certaines précautions dans les tests Web en fonction de mon expérience professionnelle, qui peuvent être utiles à tout le monde. Le processus de test prend principalement en compte les pages HTML, la communication TCP/IP, les liens Internet, les pare-feu et certains programmes exécutés sur des pages Web (par exemple, les applets, javascript, plug-ins d'application), ainsi que les applications exécutées côté serveur (par exemple). exemple, scripts CGI), interface de base de données, programme de journalisation, générateur de pages dynamiques). De plus, comme il existe de nombreux types de serveurs et de navigateurs, les différences entre les différentes versions sont minimes, mais les résultats en termes de performances sont différents, comme la vitesse de connexion, la technologie de plus en plus rapide et les multiples normes et protocoles. Bien entendu, il peut également être automatisé à l’aide d’outils de tests Web. Les autres éléments à considérer sont :
1. Quelle est la charge attendue sur le serveur (par exemple, le nombre d'accès par unité de temps) et quel type de performances doit-il avoir sous ces charges (par exemple, le temps de réponse du serveur, le temps de requête de la base de données). Quels types d'outils de test sont nécessaires pour les tests de performances (par exemple, outils de test de charge Web, autres outils de test adoptés, outils de téléchargement automatique Web, etc.) ?
2. Qui est l'utilisateur du système ? Quel navigateur utilisent-ils ? Quel type de vitesse de connexion utiliser ? Sont-ils internes ou externes à l’entreprise ?
3. Quel type de performances souhaitez-vous côté client (par exemple, vitesse d'affichage des pages ? Animation, vitesse des applets, etc. ? Comment démarrer et exécuter) ?
4. La maintenance ou la mise à niveau du site Web est-elle autorisée ?
5. Besoin de prendre en compte les aspects de sécurité (pare-feu, cryptage, mot de passe, etc.) et comment le faire ? Comment peut-on le tester ? Quelle est la fiabilité des sites Internet nécessitant une connexion ? Comment les demandes de système de sauvegarde ou de liaison redondante sont-elles traitées et testées ? Quelles étapes doivent être prises en compte lors de la gestion et de la mise à niveau des sites Web ? Quel est le besoin en termes d'exigences, de suivi, de contrôle du contenu des pages, de graphiques, de liens, etc. ?
6. Quelle spécification HTML faut-il prendre en compte ? À quel point est-il strict ? Quelles modifications sont autorisées pour les navigateurs des utilisateurs finaux ?
7. Existe-t-il des normes ou des exigences concernant l'affichage des pages et/ou les images occupant la totalité ou une partie de la page ?
8. Les liens internes et externes peuvent-ils être vérifiés et mis à jour ? À quelle fréquence?
9. Peut-il être testé sur le système du produit ? Ou avez-vous besoin d’un système de test séparé ? Les caches du navigateur, les modifications des paramètres de fonctionnement du navigateur, les connexions par ligne commutée et les « embouteillages » Internet ont-ils été résolus pendant le test, et ont-ils été pris en compte ?
10. Le contenu des journaux et des rapports du serveur peut-il être personnalisé ? Sont-ils considérés comme faisant partie intégrante des tests du système et doivent-ils être testés ?
11. Les programmes CGI, les applets, les javascripts, les composants ActiveX, etc. peuvent-ils être maintenus, suivis, contrôlés et testés ?
18. À quoi faut-il prêter attention lors de l’évaluation du test ? À qui s’adresse-t-il principalement ?
Analyse d'experts : Le concept d'examen est très faible en Chine, mais il est omniprésent. Par exemple, des révisions fréquentes du code, des réunions d'approbation de projet, des discussions sur les exigences, etc. sont en fait un examen simplifié. Certaines entreprises appellent cela un « brainstorming » (il s'agit souvent de rassembler la sagesse de chacun pour percer en cas de difficultés).
1. De nombreux éléments peuvent être révisés, tels que les exigences, les stratégies, les plans, les cas d'utilisation, les codes... en gros, tout ce à quoi vous pouvez penser dans le projet peut être révisé.
2. L'examen organisationnel doit avoir un objectif clair (c'est une partie importante de l'ensemble du processus), c'est très simple, vous devez d'abord savoir, qu'avez-vous besoin de retirer de cet examen ? Peut-être est-ce pour espérer que les éléments examinés seront plus parfaits, peut-être pour augmenter les possibilités de communication pour chacun, ou peut-être même pour faire face aux inspections ci-dessus, etc.
3. Pour différents objectifs d'évaluation, les participants changeront naturellement en conséquence : Par exemple, si vous souhaitez avoir une évaluation plus complète, théoriquement tout le personnel lié au produit, allant des chefs de projet au personnel de vente de première ligne, doit participer . Cependant, plus il y a de réviseurs, plus il est difficile d'organiser le temps, il faut donc le réduire en fonction de la situation réelle. Bien entendu, cela ne signifie pas qu'une révision doit réunir XX personnes. Par exemple, une communication privée entre un BA et un client ou un développeur peut également être considérée comme une révision à condition qu'un enregistrement détaillé soit effectué.
Par conséquent, l'examen basé sur le contenu est en réalité informel. Si un examen interne ou externe est nécessaire pour réglementer, je peux seulement dire que ce n'est qu'une formalité.
4. Concernant les détails de l'évaluation de l'organisation, un point est très important : ne « faites pas office de livre » pendant le processus d'évaluation.
De nombreuses entreprises ne se préparent pas avant l'examen. Pendant l'examen, elles font venir un modérateur et lisent les documents et les PPT pendant un moment. Après une demi-journée, ils demandent à chacun s'ils ont des questions, mais le résultat ne peut être qu'un quelques mots.
Par conséquent, il est préférable de faire un pré-examen avant l'examen, c'est-à-dire avant l'examen, de donner aux évaluateurs un certain temps, peut-être trois ou deux jours, peut-être une semaine, afin que les évaluateurs se familiarisent avec l'examen. objectifs et formuler leurs propres avis. Une procédure unifiée est rassemblée et abordée une par une dans la revue. Cet effet sera bien meilleur.
5. Enfin, parlez du processus d'examen plus standardisé
Déterminer les objectifs de la révision —— déterminer les participants (y compris les modérateurs, les rédacteurs, les réviseurs, etc.) — organiser le temps de révision — pré-révision — organiser les rapports de pré-révision — réviser — organiser les rapports de révision — les auteurs révisent les objectifs de la révision — réviser (la révision peut suivre un processus simple, et les évaluateurs qui font des suggestions vérifient si leurs suggestions ont été raisonnablement modifiées) —— archive
19. Comment définir la granularité des cas de tests ? Lorsque je suis confronté à un test avec des fonctions complexes, comment dois-je rédiger des cas de test ?
Analyse experte : selon demande. Pour les cas plus compliqués, vous pouvez d’abord dessiner l’organigramme, puis rédiger les cas de test.
Source de l'article : Les droits d'auteur du réseau appartiennent à l'auteur original
Le contenu ci-dessus n'est pas à des fins commerciales, s'il implique des problèmes de propriété intellectuelle, veuillez contacter l'éditeur, nous nous en occuperons immédiatement