Résumé du cours de technologie de test de logiciels (2) Connaissances de base des tests de logiciels

Classification des tests de logiciels

insérez la description de l'image ici

Par étape de test

  • Tests unitaires : les tests unitaires sont le travail de test de la plus petite unité de conception de logiciel - module de programme ou même segment de code pour vérifier l'exactitude, généralement effectué par les développeurs.
  • Test d'intégration : le test d'intégration consiste à assembler les modules conformément aux exigences de conception pour les tests, le but principal étant de trouver les problèmes liés à l'interface.
  • Test du système : le test du système est effectué après la réussite du test d'intégration, le but est de faire fonctionner complètement le système, de vérifier si chaque sous-système peut fonctionner normalement et répondre aux exigences de conception.
  • Test d'acceptation : le test d'acceptation prend la "spécification des exigences" dans la phase des exigences comme norme d'acceptation, et le test nécessite la simulation de l'environnement d'exploitation réel de l'utilisateur. Pour les projets réels, il peut être réalisé avec les clients et pour les produits, il s'agit du dernier test du système. Le contenu du test est un test complet des modules fonctionnels, en particulier le test de document.

insérez la description de l'image ici

Selon l'organe exécutif

  • Les tests alpha font référence au personnel interne de la société de développement de logiciels simulant divers utilisateurs pour tester les produits logiciels à venir (appelés version alpha) dans le but de trouver des erreurs et de les corriger. La clé des tests α est de simuler l'environnement d'exploitation réel et le fonctionnement du produit logiciel par l'utilisateur de manière aussi réaliste que possible, et d'essayer de couvrir autant que possible tous les modes de fonctionnement utilisateur possibles. Un produit logiciel ajusté par des tests alpha est appelé une version bêta.
  • Le test bêta est un test effectué par plusieurs utilisateurs du logiciel dans l'environnement d'utilisation réel, et ces utilisateurs renvoient des informations d'erreur pertinentes au développeur. Dans les tests bêta, l'utilisateur enregistre tous les problèmes rencontrés, y compris les problèmes réels et subjectifs, et les signale régulièrement au développeur.Ce n'est que lorsque le test alpha atteint un certain degré de fiabilité que le test bêta peut être lancé. C'est en phase finale de test. Dans le même temps, tous les textes manuels du produit doivent également être entièrement finalisés à ce stade.
  • Les tests tiers sont différents des tests effectués par les développeurs ou les utilisateurs, et leur but est d'assurer l'objectivité du travail de test.

Selon l'état d'exécution

  • La méthode statique consiste à ne pas exécuter le programme testé lui-même, mais uniquement à vérifier l'exactitude du programme en analysant ou en vérifiant la syntaxe, la structure, le processus, l'interface, etc. du programme source. Effectuez une analyse structurelle, une analyse d'organigramme et une exécution symbolique sur les spécifications des exigences, les spécifications de conception logicielle et les programmes sources pour trouver les erreurs.
  • La méthode de test dynamique consiste à vérifier la différence entre les résultats de fonctionnement et les résultats attendus en exécutant le programme testé et à analyser les performances telles que l'efficacité de fonctionnement, l'exactitude et la robustesse.

La différence entre les tests statiques et les tests dynamiques :

insérez la description de l'image ici

Selon la technologie de test

Méthodes d'essai introduire
test de la boîte blanche Les tests en boîte blanche, également appelés tests structurels, sont principalement utilisés pour détecter les erreurs dans le processus de codage du logiciel. L'expérience de programmation des programmeurs, la maîtrise des logiciels de programmation, l'état de fonctionnement et d'autres facteurs affecteront la qualité de la programmation et entraîneront des erreurs de code.
test de la boîte noire Les tests boîte noire, également appelés tests fonctionnels, détectent principalement si chaque fonction du logiciel peut être utilisée normalement. Pendant le processus de test, le programme est considéré comme une boîte noire qui ne peut pas être ouverte et l'interface du programme est testée sans tenir compte de la structure interne et des caractéristiques du programme pour vérifier si la fonction du programme peut être ouverte et utilisée normalement selon la conception. exigences et les spécifications du manuel.
test de la boîte grise Le test de la boîte grise est un test entre le test de la boîte blanche et le test de la boîte noire. Le test de la boîte grise est principalement utilisé dans la phase de test d'intégration, non seulement en se concentrant sur l'exactitude de la sortie et de l'entrée, mais en prêtant également attention à la situation interne du programme. Les tests en boîte grise ne sont pas aussi détaillés et complets que les tests en boîte blanche, mais ils accordent plus d'attention à la logique interne du programme que les tests en boîte noire, et jugent souvent l'état de fonctionnement interne à travers certains phénomènes, événements et signes représentatifs.

modèle de test logiciel

Le modèle de test logiciel est le cadre du travail de test logiciel, qui décrit les principales activités incluses dans le processus de test logiciel et les interrelations entre les activités. Les modèles de test de logiciels incluent : le modèle V, le modèle W, le modèle H, le modèle X, le pré-modèle, etc.

Modèle V

insérez la description de l'image ici

Il existe certaines limites dans le modèle en V, qui ne considère le processus de test que comme une étape après l'analyse des exigences, la conception générale, la conception détaillée et le codage. Il est facile de faire comprendre aux gens que les tests sont la dernière étape du développement logiciel, principalement pour tester les programmes afin de trouver des erreurs, et les problèmes cachés dans la phase d'analyse des exigences ne sont découverts qu'au cours des tests d'acceptation ultérieurs.

Modèle W

insérez la description de l'image ici

Par rapport au modèle V, le modèle W augmente les activités de vérification et de validation (V&V) qui doivent être effectuées simultanément à chaque étape de développement logiciel.
Le modèle W est composé de deux modèles en forme de V, représentant respectivement le processus de test et de développement. Le test s'accompagne de l'ensemble du cycle de développement logiciel. L'objet du test n'est pas seulement le programme, mais aussi les exigences et la conception. disons, les tests et le développement sont synchronisés.

Le modèle W incarne le principe de "tester les logiciels le plus tôt possible et en continu". Le modèle W a également des limites. Dans le modèle W, les activités telles que les exigences, la conception et le codage sont considérées comme des activités en série, et les activités de test et de développement maintiennent une relation linéaire d'avant en arrière. Le travail de l'étape suivante commence après la fin de l'étape précédente. , le modèle W ne peut pas prendre en charge l'itération.

Modèle H

insérez la description de l'image ici

Le modèle V et le modèle W croient que le développement logiciel est une série d'activités en série telles que les exigences, la conception et le codage. En fait, ces activités peuvent se chevaucher la plupart du temps, il n'y a donc pas de relation de séquence stricte entre les tests correspondants. Il y a des itérations répétées entre les tests unitaires, les tests d'intégration et les tests système. En raison des problèmes du modèle V et du modèle W, le modèle H sépare complètement les activités de test, de sorte que les activités de préparation des tests et les activités d'exécution des tests sont clairement reflétées.

Le modèle H révèle que les tests logiciels s'exécutent tout au long du cycle de vie du logiciel en tant que processus indépendant et sont exécutés simultanément avec d'autres processus, et souligne que les tests logiciels doivent être préparés et exécutés le plus tôt possible. Différentes activités de test peuvent être effectuées dans un certain ordre, ou elles peuvent être répétées. Tant qu'un certain test atteint le point de préparation, les activités d'exécution de test peuvent être effectuées.

Caractéristiques du modèle H :

  1. La séparation de la préparation et de l'exécution des tests est bénéfique pour l'allocation des ressources, la réduction des coûts et l'amélioration de l'efficacité.
  2. Refléter pleinement la complexité du processus de test (et non la technologie).

Modèle X

insérez la description de l'image ici

Le côté gauche du modèle X décrit le codage et les tests pour des fragments de programme individuels

En haut à droite du modèle X, le produit fini qui a réussi le test d'intégration est scellé et soumis à l'utilisateur, et il peut également être utilisé dans le cadre d'une intégration à plus grande échelle.

Les tests exploratoires sont situés en bas à droite du modèle X. Il s'agit d'un type spécial de test qui n'est pas planifié à l'avance et qui trouve souvent des bogues logiciels en dehors du plan de test.

modèle avant

insérez la description de l'image ici

Caractéristiques du modèle avant :

  1. Combiner développement et tests
  2. Testez chaque livrable
  3. Planifier et tester les conceptions pendant la phase de conception
  4. Gardez les tests d'acceptation et les tests techniques séparés les uns des autres
  5. Développement et tests alternatifs

Avantages et inconvénients du modèle avant :

avantage:

  1. AQ et CQ stricts pour améliorer la qualité des tests
  2. Le test passe par le développement tout le temps, ce qui améliore efficacement le test
  3. L'accent est mis sur les tests d'acceptation et les tests en mode double sont utilisés pour s'assurer que le système peut être accepté avec succès

défaut:

  1. Gestion de processus complexes
  2. Difficile de faire face lorsque les exigences changent
  3. Exigences élevées en matière de documentation, de gestion de la qualité, de gestion de la configuration et de gestion de projet

cas de test

Test Case (Test Case) est une organisation scientifique et une induction du comportement des tests logiciels, dans le but de transformer le comportement des tests logiciels en un modèle gérable; en même temps, Test Case est également l'une des méthodes pour quantifier les tests Classe de logiciel, les cas de test sont différents. Les méthodes de conception des cas de test incluent principalement la méthode de test de la boîte noire et la méthode de test de la boîte blanche

Le rôle des cas de test

  • Mise en œuvre guidée des tests
  • Planification de la préparation des données de test
  • Métriques pour évaluer les résultats des tests
  • Assurer la maintenabilité et la réutilisabilité du logiciel
  • Critères d'analyse des défauts

Exigences de conception de cas de test

  • efficacité
  • économie
  • multiplicité
  • Complétude
  • Décidabilité
  • reproductibilité

Je suppose que tu aimes

Origine blog.csdn.net/lichukuan/article/details/126690853
conseillé
Classement