Résumé du cours de technologie de test de logiciels (5) Processus de test de logiciels

Processus de test logiciel

Le processus de test du logiciel est le suivant :

1. Plan de test
2. conception des tests
3. exécution des tests
   • Test de l'unité
   • Tests d'intégration
   • essai de validation
   • Test du système
   • Test d'admission
   • Les tests de régression
4. Vérifier l'activité

Plan de test

Le plan de test est rédigé par le responsable du test pour déterminer les objectifs et les stratégies de chaque phase de test. Ce processus produira le plan de test, clarifiera les activités de test à réaliser, estimera le temps et les ressources nécessaires pour terminer les activités, et procédera à l'organisation des activités et à l'allocation des ressources.
La base de test est principalement formulée sur la base du plan de développement du projet et des résultats de l'analyse des exigences de test.

conception des tests

Concevoir le schéma de test selon le plan de test. Le résultat du processus de conception de test est les cas de test utilisés dans chaque phase de test, déterminer l'ensemble de cas de test pour chaque exigence de test et déterminer le processus de test pour exécuter les cas de test.

Selon le plan de test logiciel, les exigences logicielles, la conception de l'architecture logicielle, la conception détaillée du logiciel et d'autres documents, concevez les cas de test comme suit :

1. Pour chaque exigence de test, déterminez les cas de test dont elle a besoin.
2. Pour chaque cas de test, déterminez ses entrées et les résultats attendus.
3. Déterminez la configuration de l'environnement de test et les pilotes requis pour le scénario de test.
4. Rédiger la documentation des cas de test
5. Examen par les pairs des cas de test

exécution des tests

Comme indiqué, le processus d'exécution des tests est divisé en phases de test suivantes : tests unitaires, tests d'intégration, tests de validation, tests système, tests d'acceptation, etc.

Test de l'unité

Le test unitaire est le niveau le plus bas des activités de test dans le processus de développement logiciel, l'objet du test est la plus petite unité de conception logicielle, le test unitaire est également appelé test de module

Beaucoup de gens comprennent mal le concept d'unité comme une fonction concrète ou une méthode d'une classe, ce qui n'est pas exact. En tant qu'unité minimale, il doit avoir une définition de fonction, une définition de performance et une définition d'interface claires, et peut être clairement distingué des autres unités. Un menu, une interface d'affichage ou une fonction spécifique pouvant être complétée indépendamment peut constituer une unité. En un sens, le concept d'unité a été étendu à un composant.

Environnement pour les tests unitaires :

Étant donné que chaque module n'est pas isolé dans l'ensemble du logiciel, lors
du test unitaire de chaque module, il doit tenir compte de son
interrelation avec les modules environnants.
Afin de simuler cette connexion, plusieurs modules de test auxiliaires doivent être mis en place lors des tests unitaires . Ces modules auxiliaires sont divisés en deux types :

• Module pilote (driver) : Il sert à simuler le module supérieur du module sous test, qui est équivalent au programme principal du module sous test.
• Module stub (stub) : Il permet de simuler le module de niveau inférieur du module sous test, qui est équivalent au sous-module appelé par le module sous test.

Comment se déroulent les tests unitaires

Les tests unitaires peuvent être effectués de deux manières :

Inconvénients des tests unitaires :

• De nouveaux problèmes sont introduits lorsque les modules s'appellent ;
• La combinaison de plusieurs sous-fonctions ne peut réaliser la fonction principale ;
• Les erreurs s'accumulent à des niveaux inacceptables ;
• Erreurs dans les structures de données globales, etc.

Tests d'intégration

Bon essai

Une fois le test d'intégration terminé, les modules développés séparément sont connectés pour former un programme complet. Parmi eux, divers problèmes existant dans les interfaces entre les modules ont été éliminés. Il est donc entré dans la phase de test de confirmation.

Le test de confirmation est le processus d'évaluation d'un produit logiciel par rapport à la spécification des exigences logicielles afin de déterminer s'il répond à la spécification des exigences. Il détermine si le produit logiciel final est correct ou non.

Déterminez la stratégie de test :

• Tests basés sur les exigences : à l'aide d'une stratégie de test de boîte noire, les exigences des utilisateurs sont testées sans connaître les spécifications de conception détaillées ou le code. Les tests basés sur les exigences conçoivent des cas de test basés sur des spécifications de conception fonctionnelles.
• Tests basés sur les fonctions : adoptez la stratégie de la boîte noire, concevez des cas de test conformément aux spécifications de conception fonctionnelle et utilisez des méthodes telles que la division de classe d'équivalence, l'analyse des valeurs limites et la supposition des défauts.
• Tests internes : Seules les stratégies de test en boîte blanche peuvent être utilisées, mais les spécifications de conception fonctionnelle peuvent être utilisées pour développer des plans de test. Une fois les tests en boîte blanche adoptés, une série de techniques peuvent être utilisées pour s'assurer que les parties internes du système sont entièrement testées et atteignent une couverture logique suffisante.

Test du système

Le test du système est en fait une inspection complète de chaque composant du système, ce qui est très proche de nos pratiques de test quotidiennes.
L'objectif des tests système n'est pas de trouver des défauts logiciels, mais de démontrer les performances du système.

注意：系统开发人员和组织不能负责系统测试，系统测试最好由独立的测试机构完成。 

Test d'admission

Le test d'acceptation est le processus de comparaison du produit final avec les besoins actuels de l'utilisateur final. Il s'agit de la dernière activité d'inspection de la qualité une fois le développement du logiciel terminé et avant que le produit logiciel ne soit livré à l'utilisateur. Il détermine si le produit logiciel développé répond aux exigences attendues, acceptation par l'utilisateur, etc.

Les tests d'acceptation vérifient non seulement la qualité d'un certain aspect du logiciel, mais effectuent également une inspection de qualité complète et déterminent si le logiciel est qualifié. Par conséquent, les tests d'acceptation sont une activité de test strictement formelle et doivent être effectués dans un environnement de production plutôt que dans un environnement de développement.

Les tests de régression

Le test de régression est le test d'un programme pour déterminer si de nouveaux bogues ont été introduits à la suite de corrections de bogues.
Le test de régression n'est pas une nouvelle activité de test, c'est le processus de réexécution de certains ou de tous les cas de test pour vérifier si la réparation d'un défaut introduit un nouveau défaut.

Vérifier l'activité

Des activités de vérification existent à chaque étape du cycle de vie du test, y compris la vérification des exigences, la vérification de la conception fonctionnelle, la vérification de la conception détaillée et la vérification du code. Dans chaque activité de vérification, le but des tests est de trouver autant de défauts que possible, et les testeurs doivent participer activement à l'examen du logiciel et au travail de revue, et effectuer le travail de vérification.