Wondershare EdrawMind
Galerie de cartes mentales Résumé des points de connaissances sur les tests de systèmes logiciels
- 8
Résumé des points de connaissances sur les tests de systèmes logiciels
Résumé des connaissances de base des tests de systèmes logiciels. Le test de logiciels est le processus d'exécution ou de mesure d'un système logiciel à l'aide de moyens manuels ou automatiques. Le but est de vérifier s'il répond aux exigences spécifiées ou de clarifier la différence entre les résultats attendus et les résultats réels. .
Modifié à 2024-01-12 16:00:06
- Cent ans de solitude - Tableau des relations entre les personnages
Cent ans de solitude est le chef-d'œuvre de Gabriel Garcia Marquez. La lecture de ce livre commence par l'analyse des relations entre les personnages, qui se concentre sur la famille Buendía et raconte l'histoire de la prospérité et du déclin de la famille, de ses relations internes et de ses luttes politiques, de son métissage et de sa renaissance au cours d'une centaine d'années.
- Cent ans de solitude - Tableau des relations entre les personnages
Cent ans de solitude est le chef-d'œuvre de Gabriel Garcia Marquez. La lecture de ce livre commence par l'analyse des relations entre les personnages, qui se concentre sur la famille Buendía et raconte l'histoire de la prospérité et du déclin de la famille, de ses relations internes et de ses luttes politiques, de son métissage et de sa renaissance au cours d'une centaine d'années.
- Modèle de processus de gestion de projet
La gestion de projet est le processus qui consiste à appliquer des connaissances, des compétences, des outils et des méthodologies spécialisés aux activités du projet afin que celui-ci puisse atteindre ou dépasser les exigences et les attentes fixées dans le cadre de ressources limitées. Ce diagramme fournit une vue d'ensemble des 8 composantes du processus de gestion de projet et peut être utilisé comme modèle générique.
Résumé des points de connaissances sur les tests de systèmes logiciels
- Cent ans de solitude - Tableau des relations entre les personnages
Cent ans de solitude est le chef-d'œuvre de Gabriel Garcia Marquez. La lecture de ce livre commence par l'analyse des relations entre les personnages, qui se concentre sur la famille Buendía et raconte l'histoire de la prospérité et du déclin de la famille, de ses relations internes et de ses luttes politiques, de son métissage et de sa renaissance au cours d'une centaine d'années.
- Cent ans de solitude - Tableau des relations entre les personnages
Cent ans de solitude est le chef-d'œuvre de Gabriel Garcia Marquez. La lecture de ce livre commence par l'analyse des relations entre les personnages, qui se concentre sur la famille Buendía et raconte l'histoire de la prospérité et du déclin de la famille, de ses relations internes et de ses luttes politiques, de son métissage et de sa renaissance au cours d'une centaine d'années.
- Modèle de processus de gestion de projet
La gestion de projet est le processus qui consiste à appliquer des connaissances, des compétences, des outils et des méthodologies spécialisés aux activités du projet afin que celui-ci puisse atteindre ou dépasser les exigences et les attentes fixées dans le cadre de ressources limitées. Ce diagramme fournit une vue d'ensemble des 8 composantes du processus de gestion de projet et peut être utilisé comme modèle générique.
- Recommandé pour vous
- Contour
![[Notes d'étude] Structure-Arbre de données](https://edrawcloudpublicus.s3.amazonaws.com/work/5594721/2024-5-20/1716168861/thumb.png?x-oss-process=image/resize,w_300,m_lfit)
Test du système
concept
Les tests logiciels sont le processus consistant à utiliser des moyens manuels ou automatisés pour exécuter ou mesurer un système logiciel, dans le but de vérifier s'il répond à des exigences spécifiées ou de clarifier la différence entre les résultats attendus et les résultats réels.
contenu
PCM
Principe du concept minimal
cycle de vie du logiciel
plan
Déterminer l'objectif de développement : développer un petit logiciel
Étude de faisabilité complète du projet : si cela est réalisable et s'il est judicieux de le faire
Estimer et organiser l'avancement du projet : personnes, budget temps
Élaborer un plan de mise en œuvre
analyse de la demande
Analyser et trier les exigences du projet : fonctions à développer, fonctionnalités détaillées
Sur la base des exigences triées, préparez une spécification des exigences (SRS : Software Requirement Spécification)
Réaliser des prototypes de produits
conception
Conception complète des grandes lignes du projet
Conception détaillée complète
codage
Rédaction complète du code conformément à la spécification de conception générale et à la spécification de conception détaillée
test
Test unitaire : la plus petite unité du programme (fonction ou code d'une classe)
Intégration : tester l'interface entre les modules
Système : le processus de test de l'ensemble du système compilé
Acceptation : Tests complets avec le client
Opération et maintenance
déploiement de produits
Opération et maintenance
Mise à niveau des fonctions
Amélioration des performances
Modèles de test courants
modèle de cascade traditionnel
Inconvénients : post-test, une fois le développement terminé, les coûts de modification sont énormes
Modèle V
Caractéristiques : Le processus de test est affiné et divisé en quatre étapes différentes : tests unitaires, tests d'intégration, tests système et tests d'acceptation.
Inconvénients : post-test, ne résout pas le problème du risque
Modèle W
avantage
①Les activités de test et le développement sont effectués simultanément
②L'objet de test n'est pas seulement le programme, mais aussi les exigences et la conception
③Détecter les défauts logiciels le plus tôt possible peut réduire les coûts de développement
défaut
Impossible de prendre en charge l'itération de version flexible
Modèle de développement agile
Caractéristiques
Le modèle de développement et de test agile est principalement un modèle de développement et de test conçu pour s'adapter au rythme de développement « court, plat et rapide » des sociétés Internet modernes.
contenu
①Itération : chaque itération est appelée un sprint. Les exigences sélectionnées pour être mises en œuvre dans chaque sprint seront organisées dans le backlog du sprint. Chaque sprint prend généralement un mois sous forme de cycle.
② Product Owner : équivalent au chef de produit. Trier toutes les exigences pour l'ensemble du projet et organiser les exigences dans le Produce Backlog en fonction de leur priorité
③ Réunion quotidienne : réunion quotidienne, généralement sous la forme d'une réunion debout. Le discours de chacun ne dépasse généralement pas 1 minute et le contenu principal comprend trois points : le travail réalisé hier, le travail à réaliser aujourd'hui et les risques et problèmes rencontrés.
④ Burndown du sprint : graphique d'avancement itératif pour enregistrer la charge de travail restante
⑤ Réunion de revue de sprint : réunion de revue d'itération, principalement pour examiner les problèmes qui existaient dans cette itération et comment l'améliorer, etc.
⑥ scrum master : équivalent au chef d'équipe, qui gérera uniformément les membres de l'équipe
modèle de qualité logiciel
définition
Le modèle de qualité logicielle fournit une base pour considérer les attributs de qualité des produits sous différentes dimensions.
contenu
Fonctionnalité, fiabilité, facilité d'utilisation, efficacité des performances, compatibilité, sécurité, maintenabilité, portabilité
La différence entre portabilité et compatibilité :
La portabilité est une qualité interne du produit, qui se concentre davantage sur la question de savoir si le code peut être installé et configuré correctement sur différentes plates-formes.
La compatibilité est la qualité externe d'un produit et concerne davantage l'utilisation et l'affichage corrects de différents navigateurs, de différentes résolutions et de différents appareils que les utilisateurs finaux peuvent percevoir.
Méthodes d'essai
test en boîte noire
Les tests en boîte noire font référence au processus de test des entrées et des sorties du logiciel du point de vue de l'utilisateur final en fonction des exigences et des spécifications du produit sans connaître la structure du code du logiciel testé.
test en boîte blanche
Fait référence au processus de test du code et de la structure du logiciel testé, basé sur le code et la structure du logiciel testé lui-même, appelé test en boîte blanche.
Tests en boîte grise
Entre la case blanche et la case noire, d'une manière générale, la case grise teste l'interface, par exemple, elle ne connaît que le nom de la fonction, les paramètres et la valeur de retour de la fonction, mais ne connaît pas la structure d'implémentation interne de la fonction.
Tests d'intégration
Une fois les unités testées et les défauts logiciels sous-jacents détectés et réparés, elles sont intégrées ensemble et la combinaison de modules est testée pour l'intégration, ce qui implique principalement des tests d'interface.
Test de validation
Également appelé test de fumée, il confirme si les fonctions de base sont implémentées et n'est généralement pas utilisé comme processus de test formel.
Test du système
Tester toutes les fonctions du système et simuler les opérations de tous les utilisateurs du logiciel
Les tests de régression
Répétez les cas de test précédents lors du test d'une nouvelle version du logiciel
But
①Vérifiez que le défaut précédent a été corrigé
② Confirmez que la réparation des défauts n'entraîne pas de nouveaux défauts
Test d'acceptation : tests réalisés à la fois par les parties de l'offre et de la demande et par des tiers, qui peuvent être divisés en test ɑ (à l'intérieur), test bêta (bêta public) et test γ selon différents thèmes en cours.
Documents liés au projet
Principaux documents pendant la phase de développement
Spécification des exigences
Conception de contour
conception détaillée
Principaux documents pendant la phase de test
Plans et scénarios de tests
cas de test
Rapport de défaut
rapport de test
méthode
Processus de test
analyser
Examen des exigences (liste de contrôle pour l'examen des exigences)
D’où vient la demande, et que se passe-t-il s’il n’y en a pas ?
Comment évaluer l’évaluation des besoins ?
Analyse des exigences de test
Pourquoi devons-nous procéder à une analyse des exigences de test ?
Processus d’analyse des exigences de test
obtenir des points de test
Planification : plan de tests et rédaction du document de solution
Concepts de conception de tests
Rédaction de cas d'utilisation
Numéro de test : TC TestCase
Titre du test : utilisez une phrase pour décrire le point de test que ce cas d'utilisation teste.
Priorité : Haute, Haute, Basse. La fonction est que lorsque le temps du projet est insuffisant ou que le personnel est insuffisant, nous pouvons prioriser le test des cas de test clés.
Condition prédéfinie : un état ou une condition que le système doit atteindre à l'avance lors de l'exécution de ce cas d'utilisation. Facultatif, écrivez-le s'il existe, ne l'écrivez pas s'il n'existe pas
Étapes du test : décrivez en détail les opérations à effectuer lors du test de ce cas d'utilisation.
Résultats attendus : Un résultat qui vient des besoins et que nous devons atteindre.
Résultats réels : résultats obtenus après le système d'exploitation réel.
Résultats des tests : réussite/échec/NA réussite Les résultats attendus sont les mêmes que les résultats réels. fail Le résultat attendu et le résultat réel sont différents. N/A signifie que le cas d'utilisation actuel n'est pas applicable ou inutilisable
Conception : conception de cas de test
Méthode de conception de cas de test
Méthode de classe d'équivalence
Champ de saisie : une zone dans laquelle tous les utilisateurs peuvent saisir du contenu
Étapes de conception des classes d’équivalence
Écrivez un tableau de classes d'équivalence, divisez les classes d'équivalence pour chaque entrée, obtenez un tableau de classes d'équivalence et spécifiez un numéro unique pour chaque classe d'équivalence.
Concevez un scénario de test qui couvre autant de classes d'équivalence valides que possible qui ne sont pas encore couvertes. Répétez cette étape jusqu'à ce que toutes les classes d'équivalence valides soient couvertes par les cas de test
Concevez un scénario de test de manière à ce qu'il ne couvre qu'une seule classe d'équivalence non valide. Répétez cette étape jusqu'à ce que toutes les classes d'équivalence invalides soient couvertes
Principe de division en classes d'équivalence
Si la condition d'entrée spécifie une plage de valeurs ou le nombre de valeurs, une classe d'équivalence valide et deux classes d'équivalence non valides peuvent être déterminées.
Si l'âge d'entrée doit être compris entre 18 et 25 ans, alors 18-25 ans est une classe d'équivalence valide, et ceux de moins de 18 ans et ceux de plus de 25 ans sont deux classes d'équivalence invalides.
Une fonction doit avoir 3 paramètres, alors 3 paramètres sont une classe d'équivalence valide, et plus de 3 paramètres et moins de 3 paramètres sont des classes d'équivalence invalides.
La condition d'entrée spécifie l'ensemble des valeurs d'entrée ou spécifie les conditions qui doivent être remplies. Vous pouvez ensuite déterminer une classe d'équivalence valide et une classe d'équivalence non valide.
Par exemple, si vous devez saisir des valeurs de qualifications académiques et que les qualifications académiques incluent un collège, un baccalauréat, une maîtrise, un doctorat et un postdoctorat, alors ces valeurs dans les qualifications académiques constituent une classe d'équivalence valide, et toute valeur qui le fait n'appartenant pas à cet ensemble de qualifications académiques est une classe d'équivalence invalide.
Dans le cas où la condition d'entrée est une valeur booléenne, une classe d'équivalence valide et une classe d'équivalence invalide peuvent être déterminées.
Par exemple, si le sexe d’entrée est féminin, alors féminin est une classe d’équivalence valide et masculin est une classe d’équivalence non valide.
Si nous savons avec certitude que chaque élément de la classe d'équivalence déjà divisée est traité différemment dans le programme, nous devrions diviser davantage la classe d'équivalence.
Lorsque des règles sont spécifiées auxquelles les données d'entrée doivent se conformer, une classe d'équivalence valide (obéissant aux règles) et plusieurs classes d'équivalence invalides (violant les règles sous différents angles) peuvent être établies.
Les données d'entrée requises doivent être un entier positif, alors l'entier positif est une classe d'équivalence valide et la classe d'équivalence non valide peut être 0, des nombres négatifs et des décimales.
méthode des valeurs limites
définition
1. Une méthode de conception de cas d'utilisation en boîte noire qui teste les limites d'entrée et de sortie d'un programme. Elle est souvent utilisée en conjonction avec la méthode de conception de classe d'équivalence. À l'heure actuelle, ses cas d'utilisation proviennent des limites de la classe d'équivalence.
2. La base théorique de la méthode d'analyse des valeurs limites est de supposer que la plupart des erreurs se produisent aux limites de diverses conditions d'entrée si les valeurs proches des limites ne provoquent pas d'erreurs de programme. La possibilité que d’autres valeurs conduisent à des erreurs de programme est également très faible.
3. Conditions d'utilisation des valeurs limites (accent : mesurable)
La condition d'entrée clarifie la plage d'une valeur ou spécifie le nombre de valeurs.
La condition d'entrée spécifie un ensemble ordonné
Notions associées
Point supérieur : point sur la frontière
Point hors : le point le plus proche de la limite
Point intérieur : n'importe quel point dans la plage de valeurs
Chaque point doit être un numéro différent. Il est impossible qu'un point soit à la fois un point supérieur et un point éloigné.
Point supérieur : les deux points que vous voyez dans la plage doivent être le point supérieur
Étapes du cas d'utilisation
Analyser le type de paramètres d'entrée : analyser les types de paramètres d'entrée à partir des spécifications de test
Division de classes d'équivalence (facultatif) : pour la méthode de division de classes d'équivalence d'entrée, divisez les classes d'équivalence pour déterminer les limites : utilisez la méthode d'analyse de test de domaine pour déterminer les limites de la plage de domaines (point supérieur, point éloigné et point intérieur).
Former un élément de test : sélectionnez ces points supérieurs, hors points et points intérieurs ou une combinaison de ces points pour former un élément de test
Principes d'analyse
Si la condition d'entrée (de sortie) spécifie une plage de valeurs, les valeurs à l'intérieur et à proximité des limites de la plage doivent être utilisées comme cas de test.
Si la condition d'entrée (de sortie) spécifie le nombre de valeurs, utilisez le nombre maximum, le nombre minimum, le nombre 1 inférieur au nombre minimum et le nombre 1 supérieur au nombre maximum comme scénario de test.
Si l'entrée ou la sortie mentionnée dans la spécification du programme est un ensemble ordonné, il convient de veiller à sélectionner le premier et le dernier élément de l'ensemble ordonné comme cas de test.
Si une structure de données interne est utilisée dans le programme, la valeur à la limite de la structure de données interne doit être sélectionnée comme scénario de test.
Scénario d'utilisation : divisez les conditions d'entrée en plusieurs sous-conditions différentes. Les conditions sont relativement indépendantes et n'ont aucune relation restrictive.
méthode de table de décision
Définition (si)
La table de décision est un outil permettant d'analyser et d'exprimer différentes actions effectuées par le système dans plusieurs conditions d'entrée. Elle peut exprimer des relations logiques complexes et des combinaisons de plusieurs conditions de manière spécifique et claire.
état du tas
Répertoriez toutes les entrées du système. L’ordre des entrées répertoriées n’a aucun effet.
article conditionnel
Lister les valeurs de la condition d'entrée dans la colonne de gauche, les valeurs vraies et faussesdans toutes les situations possibles
pile d'action
Répertoriez les actions possibles que le système peut entreprendre, dans n'importe quel ordre
élément d'action
Répertoriez les actions à entreprendre pour différentes valeurs de l'entrée
étapes de conception
Déterminez le nombre de règles. Par exemple, il y a 3 conditions ici, et chaque condition a deux valeurs, il devrait donc y avoir 2*2*2=8 règles.
Répertorier toutes les piles de conditions et les piles d'actions
Remplissez les éléments conditionnels
Remplissez les piles d'actions et les éléments d'action
Simplifiez et fusionnez des règles similaires
Convertissez chaque règle en cas d'utilisation
l'analyse des processus
définition
La méthode d'analyse de processus (également connue sous le nom de méthode de conception de scénarios) considère un certain processus du système logiciel comme un chemin et utilise la méthode d'analyse de chemin pour concevoir des cas de test. Combinez-les en séquence selon l’ordre du processus, afin que toutes les branches du processus puissent être atteintes. Il s'agit d'une méthode d'analyse de test étendue de la méthode d'analyse de couverture de chemin dans les tests en boîte blanche aux tests en boîte noire.
concept
Flux de base : fait référence au processus principal dans lequel toutes les opérations sont correctes
Flux alternatif : fait référence à la branche du processus où certaines opérations sont incorrectes
étapes de conception
Dessiner un diagramme de processus métier
Définir la priorité du chemin de fonction
Déterminer le chemin de test
Sélectionnez les données de test
Construire des cas de tests
Exemple : dans un système embarqué, une fois les données à envoyer conditionnées dans un format de trame conforme au protocole CA, elles peuvent être écrites dans le tampon d'envoi et envoyées automatiquement.
1. Entrez le sous-programme d'envoi
2. Le système détermine s'il existe un tampon d'envoi libre. Dans le cas contraire, il renvoie et affiche le message d'échec d'envoi.
3. S'il y a un tampon libre, écrivez le paquet de données dans le tampon d'envoi libre
4. Le système détermine si l'écriture a réussi. Dans le cas contraire, il renvoie et affiche le message d'échec d'envoi.
5. Si l'écriture réussit, lancez la commande d'envoi
6. Renvoyez un message réussi
mauvaise supposition
définition
La méthode de détection des erreurs consiste à deviner quel peut être le problème en fonction de l'expérience et à concevoir des cas de test en conséquence.
Les méthodes de test d'erreur ne peuvent être utilisées qu'en complément de la conception des tests et ne peuvent pas être utilisées seules pour concevoir des cas de test. Dans le cas contraire, des tests insuffisants pourraient en résulter.
Une mauvaise estimation n'est pas une supposition aveugle, ni une supposition sans fondement ni objectif. Elle doit être basée sur une compréhension des faiblesses du système et des angles morts des développeurs.
exemple
une = [3,5,8,9,2,4]
répéter
[1,1,1,1,1,1,1]
Pas un numéro
[1,2,3,a,7,6,5]
La liste est vide
: [] [67]
Problème de séquence
[1,2,3,4,5,6] [6,5,4,3,2,1]
Connaissance des affaires et richesse de l'expérience en programmation
Résumé de la conception du cas de test
Il existe de nombreuses méthodes pour concevoir des cas de test. Nous devons non seulement savoir comment utiliser chaque méthode, mais également les scénarios dans lesquels chaque méthode est utilisée.
Les classes d'équivalence et les valeurs limites sont les pierres angulaires de toute autre approche de conception de tests, et la conception de cas d'utilisation utilisant des classes d'équivalence et des valeurs limites doit d'abord être prise en compte.
Lorsqu'il existe une relation de contrainte entre le domaine d'entrée et le domaine d'entrée, une table de décision doit être utilisée pour la combinaison.
Après avoir examiné toutes les méthodes de conception de cas de test, il est également nécessaire de les compléter par des méthodes de estimation des erreurs pour éviter de rater quelque chose.
Lorsque vous testez un certain champ, vous devez vous assurer que la valeur des autres champs est une valeur normale.
Implémentation : rédaction de cas de tests, de scripts de tests, etc.
Analyse et extraction des points de test
Questions à réfléchir avant de passer le test
Savez-vous ce que fait le système que vous souhaitez tester ?
Comprenez-vous les caractéristiques du système ?
Savez-vous quelles sont les fonctions du système ?
Savez-vous quel est le processus métier du système ?
Dans cette version du système, qu’est-ce qui doit être testé et qu’est-ce qui ne l’est pas ?
Le système a-t-il des exigences en matière de performances et de sécurité ?
Processus d’analyse des exigences de test
1. Extraire les points de test du système en fonction des exigences du produit
1. Vérifiez d'abord si les éléments de l'interface s'affichent correctement
2. Testez les fonctions de base de la page. Si la page contient à la fois un formulaire et une liste, testez en priorité si la fonction du formulaire est normale.
3. Lorsque vous testez le formulaire, vous devez tester chaque champ du formulaire dans l'ordre. Tous les champs de saisie que les utilisateurs peuvent saisir doivent être considérés en fonction des contraintes du champ à l'aide de classes d'équivalence et de valeurs limites.
4. S'il existe des corrélations et des contraintes entre plusieurs champs, après avoir testé la classe d'équivalence et la valeur limite d'un seul champ, vous devez continuer à utiliser des méthodes de test telles que les tables de décision pour les tests combinés.
5. Après avoir testé le formulaire, testez les fonctions de la liste
6. Une fois le contenu d'une seule page testé, testez le contenu lié au processus à l'aide de la méthode d'analyse de processus (méthode des scénarios).
7. Une fois l'analyse et les tests du processus terminés, utilisez enfin la méthode de estimation des erreurs pour vous assurer qu'aucun point de test n'a été manqué.
8. Exemples
2. Rédigez une matrice de suivi des exigences
La matrice de suivi des exigences fait référence à l'établissement d'une liste de trois mappages basés sur les exigences du produit, les points de test et les cas de test. Ce tableau est appelé matrice de suivi des exigences.
Le rôle de la matrice de suivi des exigences
Établir la relation de cartographie entre les exigences du produit, les exigences de test et les cas de test pour faciliter les statistiques de couverture des exigences des cas d'utilisation
Si les exigences changent, vous pouvez rapidement localiser les cas de test qui doivent être mis à jour en fonction de la matrice de suivi des exigences.
3. Concevoir des cas de test basés sur des points de test en utilisant des méthodes de conception de cas de test appropriées
Exécution : configurer un environnement de test, exécuter des scripts de test et des rapports de défauts
Mettre en place un environnement de test
Configuration de l'environnement serveur
Installation du JDK
L'installation du JDK vise principalement à fournir un environnement d'exécution pour JAVA. (Le serveur TOMCAT est écrit en Java, donc pour exécuter Tomcat, vous devez d'abord configurer l'environnement d'exploitation JAVA)
JAVA_HOME : chemin d'accès où vous avez installé JDK
CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar
Dans la variable d'environnement Path, ajoutez les deux chemins %JAVA_HOME%\jre\bin et %JAVA_HOME%\bin
Installation de TOMCAT
Tomcat sert de serveur Web principal et est responsable du traitement de toutes les demandes envoyées par les clients.
Décompressez le package compressé Tomcat vers un chemin qui ne contient pas de caractères chinois ou spéciaux
CATALINA_HOME : le chemin d'accès à l'endroit où vous avez décompressé le package Tomcat
Dans la variable d'environnement Path, ajoutez le chemin %CATALINA_HOME%\bin
Démarrez Tomcat en double-cliquant sur le fichier startup.bat dans le répertoire bin
Installation de la base de données MYSQL
La base de données MySQL est principalement utilisée pour gérer les données du système
Installez l'application mysql via la boîte à outils wampserver et démarrez les serveurs mysql et apache via wampserver
Paramètres liés au système testé
Placez le package war du système testé dans le chemin spécifié par Tomcat
Importez le fichier sql correspondant à la base de données dans la base de données, et modifiez le mot de passe par défaut des données mysql
Démarrez le serveur et accédez au système testé. L'adresse est : http://localhost:8080/mms/login.html
Variables d'environnement
Les variables d'environnement sont en fait des paramètres système. Grâce à ces paramètres, nous pouvons indiquer à l'ordinateur où se trouve le fichier cible que nous voulons exécuter.
Rapport de défaut
Définition du défaut
Le logiciel n'implémente pas les fonctions décrites dans le manuel du produit.
Le logiciel implémente des fonctions qui ne doivent pas être décrites dans le manuel du produit.
Le logiciel a effectué une opération non mentionnée dans le manuel du produit.
Le logiciel n'implémente pas de fonctions qui ne sont pas mentionnées dans le manuel du produit mais qui doivent être implémentées
Du point de vue d'un testeur de logiciel, le logiciel est difficile à comprendre, difficile à utiliser, lent ou n'est pas considéré comme correct par l'utilisateur final.
Gestion des défauts
Maîtriser le cycle de vie des défauts logiciels
Maîtrisez comment remplir des rapports de défauts de haute qualité
Un rapport de test complet
Numéro de défaut
Conditions préalables
Titre du défaut
Étapes du test
gravité
priorité
Reproductibilité
Statut de défaut
Maîtriser les attributs pertinents des défauts logiciels
Gravité du défaut
gravité
Comme son nom l'indique, il fait référence à la mesure dans laquelle un défaut logiciel affecte la qualité du logiciel, c'est-à-dire à l'impact qu'aura l'existence de ce défaut logiciel sur le fonctionnement et les performances du logiciel.
fatal
Par exemple, le logiciel se ferme de manière inattendue ou même le système d'exploitation tombe en panne, entraînant une perte de données.
sérieux
Par exemple, plusieurs fonctions liées échouent en raison de l'échec d'une seule fonction
en général
Par exemple, si une seule fonction du logiciel échoue
indice
Défauts mineurs dans l'interface du logiciel, par exemple, un certain champ n'est pas aligné, un certain signe de ponctuation manque, etc.
Classification de l'état des défauts
Découvrez les outils courants pour la gestion des défauts logiciels
Comprendre certains problèmes courants dans les conflits de défauts
Comment traiter les défauts non reproductibles ? Assurez-vous de le soumettre à la bibliothèque de gestion des défauts !
1. Assurez-vous de décrire en détail le processus dans lequel le défaut a été rencontré et la configuration de l'environnement concernée. S'il existe des journaux, assurez-vous de joindre les journaux d'opérations pertinents ou les journaux d'opérations du système.
2. Pour les défauts non reproductibles, veillez à décrire le taux de récidive aussi clairement que possible.
3. Pour les défauts non reproductibles, lorsque le développeur définit le défaut comme corrigé, lors de la vérification, le défaut ne peut pas être vérifié sur une seule version. Il doit être vérifié sur au moins 3 versions ou plus sans récurrence, pour clôturer le défaut.
L'ensemble du processus d'exécution des tests
Le but des tests de régression : 1. Vérifier si le défaut a réellement été corrigé. 2. Le programmeur a-t-il introduit de nouveaux défauts lors du processus de correction des défauts ?
Tests de régression et tests d'acceptation
Les tests de régression
définition
Après avoir modifié le code, retestez
But
Vérifiez si le défaut est réellement corrigé
Si les programmeurs introduisent de nouveaux défauts lors de la correction des défauts
processus
1. Au stade de la formulation de la stratégie de test, formulez une stratégie de tests de régression
2. Déterminez la version qui nécessite des tests de régression et la version dans laquelle le bogue est modifié sera renvoyée.
3. Libérez la version du test de régression et effectuez des tests de régression conformément à la stratégie de test de régression
4. Le test de régression est réussi et le rapport de défaut est clôturé.
5. Si le test de régression échoue, le rapport de défaut est renvoyé au développeur, le développeur modifie à nouveau le problème et le soumet à nouveau au testeur pour un test de régression.
Stratégie
retour complet
Réexécutez tous les cas de test créés au début de la phase de test pour confirmer l'exactitude de la modification du problème et l'impact local de la modification.
régression sélective
Autrement dit, réexécutez de manière sélective certains des scénarios de test créés au début de la phase de test pour tester le programme modifié.
méthode
Écraser les modifications
Pour la pièce modifiée, sélectionnez ou reconstruisez les cas de test pour vérifier qu'aucune erreur ne se produit. Utilisez la méthode de sélection des cas.
influence environnante
Il inclut les cas d'utilisation identifiés par la méthode de modification de couverture, et analyse également l'impact de diffusion de la modification pour vérifier si d'autres parties sont affectées.
Objectif atteint
Test d'admission
définition
Après avoir réussi les tests du système interne, les tests d'acceptation peuvent commencer
Les tests d'acceptation sont un test centré sur l'utilisateur et l'équipe d'acceptation doit être composée de membres de l'équipe de projet, de représentants des utilisateurs, etc.
En principe, le test de réception est effectué chez l'utilisateur, mais avec le consentement de l'utilisateur, il peut également être effectué dans l'entreprise pour simuler l'environnement utilisateur.
Tests de réception : tests de réception des produits finis conformément au contrat, aux "Spécifications des exigences" ou au "Plan de tests de réception"
Pour les projets de type produit, les tests d'acceptation sont généralement divisés en tests alpha (tests internes : effectués dans l'environnement de développement) et en tests bêta (tests publics : tests dans l'environnement d'utilisation réel).
Comparaison des méthodes de tests de cycle de vie
Rédiger un rapport de test (chaque entreprise a un modèle)
But
Aperçu
Objet testé
Fonctionnalités de test
Conclusion du test
heure, lieu, personnes
environnement
Schéma du réseau de test
Environnement matériel
Environnement logiciel
Évaluation sommaire
Statistiques associées
test de logiciel
concept
Les tests logiciels sont le processus consistant à utiliser des moyens manuels ou automatisés pour exécuter ou mesurer un système logiciel, dans le but de vérifier s'il répond à des exigences spécifiées ou de clarifier la différence entre les résultats attendus et les résultats réels.
contenu
PCM
Principe du concept minimal
cycle de vie du logiciel
plan
analyse de la demande
conception
codage
test
Opération et maintenance
Modèles de test courants
modèle de cascade traditionnel
Modèle V
Modèle W
Modèle de développement agile
modèle de qualité logiciel
Méthodes d'essai
test en boîte noire
test en boîte blanche
Tests en boîte grise
Tests d'intégration
Test de validation
Test du système
Les tests de régression
Test d'admission
Documents liés au projet
Principaux documents pendant la phase de développement
Spécification des exigences
Conception de contour
conception détaillée
Principaux documents pendant la phase de test
Plans et scénarios de tests
cas de test
Rapport de défaut
rapport de test
méthode
Processus de test
analyser
Planification : plan de tests et rédaction du document de solution
Conception : conception de cas de test
Implémentation : rédaction de cas de tests, de scripts de tests, etc.
Exécution : configurer un environnement de test, exécuter des scripts de test et des rapports de défauts
L'ensemble du processus d'exécution des tests
Le but des tests de régression : 1. Vérifier si le défaut a réellement été corrigé. 2. Le programmeur a-t-il introduit de nouveaux défauts lors du processus de correction des défauts ?
Tests de régression et tests d'acceptation
Les tests de régression
Test d'admission
Comparaison des méthodes de tests de cycle de vie
Rédiger un rapport de test
cycle de vie du logiciel
plan
Déterminer l'objectif de développement : développer un petit logiciel
Étude de faisabilité complète du projet : si cela est réalisable et s'il est judicieux de le faire
Estimer et organiser l'avancement du projet : personnes, budget temps
Élaborer un plan de mise en œuvre
analyse de la demande
Analyser et trier les exigences du projet : fonctions à développer, fonctionnalités détaillées
Sur la base des exigences triées, préparez une spécification des exigences (SRS : Software Requirement Spécification)
Réaliser des prototypes de produits
conception
Conception complète des grandes lignes du projet
Conception détaillée complète
codage
Rédaction complète du code conformément à la spécification de conception générale et à la spécification de conception détaillée
test
Test unitaire : la plus petite unité du programme (fonction ou code d'une classe)
Intégration : tester l'interface entre les modules
Système : le processus de test de l'ensemble du système compilé
Acceptation : Tests complets avec le client
Opération et maintenance
déploiement de produits
Opération et maintenance
Mise à niveau des fonctions
Amélioration des performances
Modèles de test courants
modèle de cascade traditionnel
Inconvénients : post-test, une fois le développement terminé, les coûts de modification sont énormes
Modèle V
Caractéristiques : Le processus de test est affiné et divisé en quatre étapes différentes : tests unitaires, tests d'intégration, tests système et tests d'acceptation.
Inconvénients : post-test, ne résout pas le problème du risque
Modèle W
avantage
①Les activités de test et le développement sont effectués simultanément
②L'objet de test n'est pas seulement le programme, mais aussi les exigences et la conception
③Détecter les défauts logiciels le plus tôt possible peut réduire les coûts de développement
défaut
Impossible de prendre en charge l'itération de version flexible
Modèle de développement agile
Caractéristiques
Le modèle de développement et de test agile est principalement un modèle de développement et de test conçu pour s'adapter au rythme de développement « court, plat et rapide » des sociétés Internet modernes.
contenu
①Itération : chaque itération est appelée un sprint. Les exigences sélectionnées pour être mises en œuvre dans chaque sprint seront organisées dans le backlog du sprint. Chaque sprint prend généralement un mois sous forme de cycle.
② Product Owner : équivalent au chef de produit. Trier toutes les exigences pour l'ensemble du projet et organiser les exigences dans le Produce Backlog en fonction de leur priorité
③ Réunion quotidienne : réunion quotidienne, généralement sous la forme d'une réunion debout. Le discours de chacun ne dépasse généralement pas 1 minute et le contenu principal comprend trois points : le travail réalisé hier, le travail à réaliser aujourd'hui et les risques et problèmes rencontrés.
④ Burndown du sprint : graphique d'avancement itératif pour enregistrer la charge de travail restante
⑤ Réunion de revue de sprint : réunion de revue d'itération, principalement pour examiner les problèmes qui existaient dans cette itération et comment l'améliorer, etc.
⑥ scrum master : équivalent au chef d'équipe, qui gérera uniformément les membres de l'équipe
modèle de qualité logiciel
définition
Le modèle de qualité logicielle fournit une base pour considérer les attributs de qualité des produits sous différentes dimensions.
contenu
Fonctionnalité, fiabilité, facilité d'utilisation, efficacité des performances, compatibilité, sécurité, maintenabilité, portabilité
La différence entre portabilité et compatibilité :
La portabilité est une qualité interne du produit, qui se concentre davantage sur la question de savoir si le code peut être installé et configuré correctement sur différentes plates-formes.
La compatibilité est la qualité externe d'un produit et concerne davantage l'utilisation et l'affichage corrects de différents navigateurs, de différentes résolutions et de différents appareils que les utilisateurs finaux peuvent percevoir.
Méthodes d'essai
test en boîte noire
Les tests en boîte noire font référence au processus de test des entrées et des sorties du logiciel du point de vue de l'utilisateur final en fonction des exigences et des spécifications du produit sans connaître la structure du code du logiciel testé.
test en boîte blanche
Fait référence au processus de test du code et de la structure du logiciel testé, basé sur le code et la structure du logiciel testé lui-même, appelé test en boîte blanche.
Tests en boîte grise
Entre la case blanche et la case noire, d'une manière générale, la case grise teste l'interface, par exemple, elle ne connaît que le nom de la fonction, les paramètres et la valeur de retour de la fonction, mais ne connaît pas la structure d'implémentation interne de la fonction.
Tests d'intégration
Une fois les unités testées et les défauts logiciels sous-jacents détectés et réparés, elles sont intégrées ensemble et la combinaison de modules est testée pour l'intégration, ce qui implique principalement des tests d'interface.
Test de validation
Également appelé test de fumée, il confirme si les fonctions de base sont implémentées et n'est généralement pas utilisé comme processus de test formel.
Test du système
Tester toutes les fonctions du système et simuler les opérations de tous les utilisateurs du logiciel
Les tests de régression
Répétez les cas de test précédents lors du test d'une nouvelle version du logiciel
But
①Vérifiez que le défaut précédent a été corrigé
② Confirmez que la réparation des défauts n'entraîne pas de nouveaux défauts
Test d'admission
Les tests du côté de l'offre et de la demande et des tiers peuvent être divisés en test ɑ (à l'intérieur), test bêta (test public) et test γ selon différents thèmes en cours.
Processus de test
analyser
Examen des exigences (liste de contrôle pour l'examen des exigences)
D’où vient la demande, et que se passe-t-il s’il n’y en a pas ?
Comment évaluer l’évaluation des besoins ?
Analyse des exigences de test
Pourquoi devons-nous procéder à une analyse des exigences de test ?
Processus d’analyse des exigences de test
obtenir des points de test
Planification : plan de tests et rédaction du document de solution
Concepts de conception de tests
Rédaction de cas d'utilisation
Numéro de test : TC TestCase
Titre du test : utilisez une phrase pour décrire le point de test que ce cas d'utilisation teste.
Priorité : Haute, Haute, Basse. La fonction est que lorsque le temps du projet est insuffisant ou que le personnel est insuffisant, nous pouvons prioriser le test des cas de test clés.
Condition prédéfinie : un état ou une condition que le système doit atteindre à l'avance lors de l'exécution de ce cas d'utilisation. Facultatif, écrivez-le s'il existe, ne l'écrivez pas s'il n'existe pas
Étapes du test : décrivez en détail les opérations à effectuer lors du test de ce cas d'utilisation.
Résultats attendus : Un résultat qui vient des besoins et que nous devons atteindre.
Résultats réels : résultats obtenus après le système d'exploitation réel.
Résultats des tests : réussite/échec/NA réussite Les résultats attendus sont les mêmes que les résultats réels. fail Le résultat attendu et le résultat réel sont différents. N/A signifie que le cas d'utilisation actuel n'est pas applicable ou inutilisable
Conception : conception de cas de test
Méthode de conception de cas de test
Implémentation : rédaction de cas de tests, de scripts de tests, etc.
Extraction des points de tests et matrice de suivi des exigences
Exécution : configurer un environnement de test, exécuter des scripts de test et des rapports de défauts
Mettre en place un environnement de test
Rapport de défaut
Méthode de conception de cas de test
Méthode de classe d'équivalence
Champ de saisie : une zone dans laquelle tous les utilisateurs peuvent saisir du contenu
Étapes de conception des classes d’équivalence
Écrivez un tableau de classes d'équivalence, divisez les classes d'équivalence pour chaque entrée, obtenez un tableau de classes d'équivalence et spécifiez un numéro unique pour chaque classe d'équivalence.
Concevez un scénario de test qui couvre autant de classes d'équivalence valides que possible qui ne sont pas encore couvertes. Répétez cette étape jusqu'à ce que toutes les classes d'équivalence valides soient couvertes par les cas de test
Concevez un scénario de test de manière à ce qu'il ne couvre qu'une seule classe d'équivalence non valide. Répétez cette étape jusqu'à ce que toutes les classes d'équivalence invalides soient couvertes
Principe de division en classes d'équivalence
Si la condition d'entrée spécifie une plage de valeurs ou le nombre de valeurs, une classe d'équivalence valide et deux classes d'équivalence non valides peuvent être déterminées.
Si l'âge d'entrée doit être compris entre 18 et 25 ans, alors 18-25 ans est une classe d'équivalence valide, et ceux de moins de 18 ans et ceux de plus de 25 ans sont deux classes d'équivalence invalides.
Une fonction doit avoir 3 paramètres, alors 3 paramètres sont une classe d'équivalence valide, et plus de 3 paramètres et moins de 3 paramètres sont des classes d'équivalence invalides.
La condition d'entrée spécifie l'ensemble des valeurs d'entrée ou spécifie les conditions qui doivent être remplies. Vous pouvez ensuite déterminer une classe d'équivalence valide et une classe d'équivalence non valide.
Par exemple, si vous devez saisir des valeurs de qualifications académiques et que les qualifications académiques incluent un collège, un baccalauréat, une maîtrise, un doctorat et un postdoctorat, alors ces valeurs dans les qualifications académiques constituent une classe d'équivalence valide, et toute valeur qui le fait n'appartenant pas à cet ensemble de qualifications académiques est une classe d'équivalence invalide.
Dans le cas où la condition d'entrée est une valeur booléenne, une classe d'équivalence valide et une classe d'équivalence invalide peuvent être déterminées.
Par exemple, si le sexe d’entrée est féminin, alors féminin est une classe d’équivalence valide et masculin est une classe d’équivalence non valide.
Si nous savons avec certitude que chaque élément de la classe d'équivalence déjà divisée est traité différemment dans le programme, nous devrions diviser davantage la classe d'équivalence.
Lorsque des règles sont spécifiées auxquelles les données d'entrée doivent se conformer, une classe d'équivalence valide (obéissant aux règles) et plusieurs classes d'équivalence invalides (violant les règles sous différents angles) peuvent être établies.
Les données d'entrée requises doivent être un entier positif, alors l'entier positif est une classe d'équivalence valide et la classe d'équivalence non valide peut être 0, des nombres négatifs et des décimales.
méthode des valeurs limites
définition
1. Une méthode de conception de cas d'utilisation en boîte noire qui teste les limites d'entrée et de sortie d'un programme. Elle est souvent utilisée en conjonction avec la méthode de conception de classe d'équivalence. À l'heure actuelle, ses cas d'utilisation proviennent des limites de la classe d'équivalence.
2. La base théorique de la méthode d'analyse des valeurs limites est de supposer que la plupart des erreurs se produisent aux limites de diverses conditions d'entrée si les valeurs proches des limites ne provoquent pas d'erreurs de programme. La possibilité que d’autres valeurs conduisent à des erreurs de programme est également très faible.
3. Conditions d'utilisation des valeurs limites (accent : mesurable)
La condition d'entrée clarifie la plage d'une valeur ou spécifie le nombre de valeurs.
La condition d'entrée spécifie un ensemble ordonné
Notions associées
Point supérieur : point sur la frontière
Point hors : le point le plus proche de la limite
Point intérieur : n'importe quel point dans la plage de valeurs
Chaque point doit être un numéro différent. Il est impossible qu'un point soit à la fois un point supérieur et un point éloigné.
Point supérieur : les deux points que vous voyez dans la plage doivent être le point supérieur
Étapes du cas d'utilisation
Analyser le type de paramètres d'entrée : analyser les types de paramètres d'entrée à partir des spécifications de test
Division de classes d'équivalence (facultatif) : pour la méthode de division de classes d'équivalence d'entrée, divisez les classes d'équivalence pour déterminer les limites : utilisez la méthode d'analyse de test de domaine pour déterminer les limites de la plage de domaines (point supérieur, point éloigné et point intérieur).
Former un élément de test : sélectionnez ces points supérieurs, hors points et points intérieurs ou une combinaison de ces points pour former un élément de test
Principes d'analyse
Si la condition d'entrée (de sortie) spécifie une plage de valeurs, les valeurs à l'intérieur et à proximité des limites de la plage doivent être utilisées comme cas de test.
Si la condition d'entrée (de sortie) spécifie le nombre de valeurs, utilisez le nombre maximum, le nombre minimum, le nombre 1 inférieur au nombre minimum et le nombre 1 supérieur au nombre maximum comme scénario de test.
Si l'entrée ou la sortie mentionnée dans la spécification du programme est un ensemble ordonné, il convient de veiller à sélectionner le premier et le dernier élément de l'ensemble ordonné comme cas de test.
Si une structure de données interne est utilisée dans le programme, la valeur à la limite de la structure de données interne doit être sélectionnée comme scénario de test.
Scénario d'utilisation : divisez les conditions d'entrée en plusieurs sous-conditions différentes. Les conditions sont relativement indépendantes et n'ont aucune relation restrictive.
méthode de table de décision
Définition (si)
La table de décision est un outil permettant d'analyser et d'exprimer différentes actions effectuées par le système dans plusieurs conditions d'entrée. Elle peut exprimer des relations logiques complexes et des combinaisons de plusieurs conditions de manière spécifique et claire.
état du tas
Répertoriez toutes les entrées du système. L’ordre des entrées répertoriées n’a aucun effet.
article conditionnel
Lister les valeurs de la condition d'entrée dans la colonne de gauche, les valeurs vraies et faussesdans toutes les situations possibles
pile d'action
Répertoriez les actions possibles que le système peut entreprendre, dans n'importe quel ordre
élément d'action
Répertoriez les actions à entreprendre pour différentes valeurs de l'entrée
étapes de conception
Déterminez le nombre de règles. Par exemple, il y a 3 conditions ici, et chaque condition a deux valeurs, il devrait donc y avoir 2*2*2=8 règles.
Répertorier toutes les piles de conditions et les piles d'actions
Remplissez les éléments conditionnels
Remplissez les piles d'actions et les éléments d'action
Simplifiez et fusionnez des règles similaires
Convertissez chaque règle en cas d'utilisation
l'analyse des processus
définition
La méthode d'analyse de processus (également connue sous le nom de méthode de conception de scénarios) considère un certain processus du système logiciel comme un chemin et utilise la méthode d'analyse de chemin pour concevoir des cas de test. Combinez-les en séquence selon l’ordre du processus, afin que toutes les branches du processus puissent être atteintes. Il s'agit d'une méthode d'analyse de test étendue de la méthode d'analyse de couverture de chemin dans les tests en boîte blanche aux tests en boîte noire.
concept
Flux de base : fait référence au processus principal dans lequel toutes les opérations sont correctes
Flux alternatif : fait référence à la branche du processus où certaines opérations sont incorrectes
étapes de conception
Dessiner un diagramme de processus métier
Définir la priorité du chemin de fonction
Déterminer le chemin de test
Sélectionnez les données de test
Construire des cas de tests
Exemple : dans un système embarqué, une fois les données à envoyer conditionnées dans un format de trame conforme au protocole CA, elles peuvent être écrites dans le tampon d'envoi et envoyées automatiquement.
1. Entrez le sous-programme d'envoi
2. Le système détermine s'il existe un tampon d'envoi libre. Dans le cas contraire, il renvoie et affiche le message d'échec d'envoi.
3. S'il y a un tampon libre, écrivez le paquet de données dans le tampon d'envoi libre
4. Le système détermine si l'écriture a réussi. Dans le cas contraire, il renvoie et affiche le message d'échec d'envoi.
5. Si l'écriture réussit, lancez la commande d'envoi
6. Renvoyez un message réussi
mauvaise supposition
définition
La méthode de détection des erreurs consiste à deviner quel peut être le problème en fonction de l'expérience et à concevoir des cas de test en conséquence.
Les méthodes de test d'erreur ne peuvent être utilisées qu'en complément de la conception des tests et ne peuvent pas être utilisées seules pour concevoir des cas de test. Dans le cas contraire, des tests insuffisants pourraient en résulter.
Une mauvaise estimation n'est pas une supposition aveugle, ni une supposition sans fondement ni objectif. Elle doit être basée sur une compréhension des faiblesses du système et des angles morts des développeurs.
exemple
une = [3,5,8,9,2,4]
répéter
[1,1,1,1,1,1,1]
Pas un numéro
[1,2,3,a,7,6,5]
La liste est vide
: [] [67]
Problème de séquence
[1,2,3,4,5,6] [6,5,4,3,2,1]
Connaissance des affaires et richesse de l'expérience en programmation
Résumé de la conception du cas de test
Il existe de nombreuses méthodes pour concevoir des cas de test. Nous devons non seulement savoir comment utiliser chaque méthode, mais également les scénarios dans lesquels chaque méthode est utilisée.
Les classes d'équivalence et les valeurs limites sont les pierres angulaires de toute autre approche de conception de tests, et la conception de cas d'utilisation utilisant des classes d'équivalence et des valeurs limites doit d'abord être prise en compte.
Lorsqu'il existe une relation de contrainte entre le domaine d'entrée et le domaine d'entrée, une table de décision doit être utilisée pour la combinaison.
Après avoir examiné toutes les méthodes de conception de cas de test, il est également nécessaire de les compléter par des méthodes de estimation des erreurs pour éviter de rater quelque chose.
Lorsque vous testez un certain champ, vous devez vous assurer que la valeur des autres champs est une valeur normale.
Analyse et extraction des points de test
Questions à réfléchir avant de passer le test
Savez-vous ce que fait le système que vous souhaitez tester ?
Comprenez-vous les caractéristiques du système ?
Savez-vous quelles sont les fonctions du système ?
Savez-vous quel est le processus métier du système ?
Dans cette version du système, qu’est-ce qui doit être testé et qu’est-ce qui ne l’est pas ?
Le système a-t-il des exigences en matière de performances et de sécurité ?
Processus d’analyse des exigences de test
1. Extraire les points de test du système en fonction des exigences du produit
1. Vérifiez d'abord si les éléments de l'interface s'affichent correctement
2. Testez les fonctions de base de la page. Si la page contient à la fois un formulaire et une liste, testez en priorité si la fonction du formulaire est normale.
3. Lorsque vous testez le formulaire, vous devez tester chaque champ du formulaire dans l'ordre. Tous les champs de saisie que les utilisateurs peuvent saisir doivent être considérés en fonction des contraintes du champ à l'aide de classes d'équivalence et de valeurs limites.
4. S'il existe des corrélations et des contraintes entre plusieurs champs, après avoir testé la classe d'équivalence et la valeur limite d'un seul champ, vous devez continuer à utiliser des méthodes de test telles que les tables de décision pour les tests combinés.
5. Après avoir testé le formulaire, testez les fonctions de la liste
6. Une fois le contenu d'une seule page testé, testez le contenu lié au processus à l'aide de la méthode d'analyse de processus (méthode des scénarios).
7. Une fois l'analyse et les tests du processus terminés, utilisez enfin la méthode de estimation des erreurs pour vous assurer qu'aucun point de test n'a été manqué.
8. Exemples
2. Rédigez une matrice de suivi des exigences
La matrice de suivi des exigences fait référence à l'établissement d'une liste de trois mappages basés sur les exigences du produit, les points de test et les cas de test. Ce tableau est appelé matrice de suivi des exigences.
Le rôle de la matrice de suivi des exigences
Établir la relation de cartographie entre les exigences du produit, les exigences de test et les cas de test pour faciliter les statistiques de couverture des exigences des cas d'utilisation
Si les exigences changent, vous pouvez rapidement localiser les cas de test qui doivent être mis à jour en fonction de la matrice de suivi des exigences.
3. Concevoir des cas de test basés sur des points de test en utilisant des méthodes de conception de cas de test appropriées
Mettre en place un environnement de test
Configuration de l'environnement serveur
Installation du JDK
L'installation du JDK vise principalement à fournir un environnement d'exécution pour JAVA. (Le serveur TOMCAT est écrit en Java, donc pour exécuter Tomcat, vous devez d'abord configurer l'environnement d'exploitation JAVA)
JAVA_HOME : chemin d'accès où vous avez installé JDK
CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar
Dans la variable d'environnement Path, ajoutez les deux chemins %JAVA_HOME%\jre\bin et %JAVA_HOME%\bin
Installation de TOMCAT
Tomcat sert de serveur Web principal et est responsable du traitement de toutes les demandes envoyées par les clients.
Décompressez le package compressé Tomcat vers un chemin qui ne contient pas de caractères chinois ou spéciaux
CATALINA_HOME : le chemin d'accès à l'endroit où vous avez décompressé le package Tomcat
Dans la variable d'environnement Path, ajoutez le chemin %CATALINA_HOME%\bin
Démarrez Tomcat en double-cliquant sur le fichier startup.bat dans le répertoire bin
Installation de la base de données MYSQL
La base de données MySQL est principalement utilisée pour gérer les données du système
Installez l'application mysql via la boîte à outils wampserver et démarrez les serveurs mysql et apache via wampserver
Paramètres liés au système testé
Placez le package war du système testé dans le chemin spécifié par Tomcat
Importez le fichier sql correspondant à la base de données dans la base de données, et modifiez le mot de passe par défaut des données mysql
Démarrez le serveur et accédez au système testé. L'adresse est : http://localhost:8080/mms/login.html
Variables d'environnement
Les variables d'environnement sont en fait des paramètres système. Grâce à ces paramètres, nous pouvons indiquer à l'ordinateur où se trouve le fichier cible que nous voulons exécuter.
Rapport de défaut
Définition du défaut
Le logiciel n'implémente pas les fonctions décrites dans le manuel du produit.
Le logiciel implémente des fonctions qui ne doivent pas être décrites dans le manuel du produit.
Le logiciel a effectué une opération non mentionnée dans le manuel du produit.
Le logiciel n'implémente pas de fonctions qui ne sont pas mentionnées dans le manuel du produit mais qui doivent être implémentées
Du point de vue d'un testeur de logiciel, le logiciel est difficile à comprendre, difficile à utiliser, lent ou n'est pas considéré comme correct par l'utilisateur final.
Gestion des défauts
Maîtriser le cycle de vie des défauts logiciels
Maîtrisez comment remplir des rapports de défauts de haute qualité
Un rapport de test complet
Numéro de défaut
Conditions préalables
Titre du défaut
Étapes du test
gravité
priorité
Reproductibilité
Statut de défaut
Maîtriser les attributs pertinents des défauts logiciels
Gravité du défaut
gravité
Comme son nom l'indique, il fait référence à la mesure dans laquelle un défaut logiciel affecte la qualité du logiciel, c'est-à-dire à l'impact qu'aura l'existence de ce défaut logiciel sur le fonctionnement et les performances du logiciel.
fatal
Par exemple, le logiciel se ferme de manière inattendue ou même le système d'exploitation tombe en panne, entraînant une perte de données.
sérieux
Par exemple, plusieurs fonctions liées échouent en raison de l'échec d'une seule fonction
en général
Par exemple, si une seule fonction du logiciel échoue
indice
Défauts mineurs dans l'interface du logiciel, par exemple, un certain champ n'est pas aligné, un certain signe de ponctuation manque, etc.
Classification de l'état des défauts
Découvrez les outils courants pour la gestion des défauts logiciels
Comprendre certains problèmes courants dans les conflits de défauts
Comment traiter les défauts non reproductibles ? Assurez-vous de le soumettre à la bibliothèque de gestion des défauts !
1. Assurez-vous de décrire en détail le processus dans lequel le défaut a été rencontré et la configuration de l'environnement concernée. S'il existe des journaux, assurez-vous de joindre les journaux d'opérations pertinents ou les journaux d'opérations du système.
2. Pour les défauts non reproductibles, veillez à décrire le taux de récidive aussi clairement que possible.
3. Pour les défauts non reproductibles, lorsque le développeur définit le défaut comme corrigé, lors de la vérification, le défaut ne peut pas être vérifié sur une seule version. Il doit être vérifié sur au moins 3 versions ou plus sans récurrence, pour clôturer le défaut.
Tests de régression et tests d'acceptation
Les tests de régression
définition
Après avoir modifié le code, retestez
But
Vérifiez si le défaut est réellement corrigé
Si les programmeurs introduisent de nouveaux défauts lors de la correction des défauts
processus
1. Au stade de la formulation de la stratégie de test, formulez une stratégie de tests de régression
2. Déterminez la version qui nécessite des tests de régression et la version dans laquelle le bogue est modifié sera renvoyée.
3. Libérez la version du test de régression et effectuez des tests de régression conformément à la stratégie de test de régression
4. Le test de régression est réussi et le rapport de défaut est clôturé.
5. Si le test de régression échoue, le rapport de défaut est renvoyé au développeur, le développeur modifie à nouveau le problème et le soumet à nouveau au testeur pour un test de régression.
Stratégie
retour complet
Réexécutez tous les cas de test créés au début de la phase de test pour confirmer l'exactitude de la modification du problème et l'impact local de la modification.
régression sélective
Autrement dit, réexécutez de manière sélective certains des scénarios de test créés au début de la phase de test pour tester le programme modifié.
méthode
Écraser les modifications
Pour la pièce modifiée, sélectionnez ou reconstruisez les cas de test pour vérifier qu'aucune erreur ne se produit. Utilisez la méthode de sélection des cas.
influence environnante
Il inclut les cas d'utilisation identifiés par la méthode de modification de couverture, et analyse également l'impact de diffusion de la modification pour vérifier si d'autres parties sont affectées.
Objectif atteint
Test d'admission
définition
Après avoir réussi les tests du système interne, les tests d'acceptation peuvent commencer
Les tests d'acceptation sont un test centré sur l'utilisateur et l'équipe d'acceptation doit être composée de membres de l'équipe de projet, de représentants des utilisateurs, etc.
En principe, le test de réception est effectué chez l'utilisateur, mais avec le consentement de l'utilisateur, il peut également être effectué dans l'entreprise pour simuler l'environnement utilisateur.
Tests de réception : tests de réception des produits finis conformément au contrat, aux "Spécifications des exigences" ou au "Plan de tests de réception"
Pour les projets de type produit, les tests d'acceptation sont généralement divisés en tests alpha (tests internes : effectués dans l'environnement de développement) et en tests bêta (tests publics : tests dans l'environnement d'utilisation réel).
Comparaison des méthodes de tests de cycle de vie