Principes de base des tests logiciels - Questions et réponses

Le test logiciel est une activité de développement logiciel. Il s'agit d'une enquête menée sur un logiciel pour fournir des informations sur la qualité du logiciel aux parties prenantes.



Qu'est-ce que le test logiciel?

Différentes personnes ont proposé diverses définitions pour les tests logiciels, mais en général, le but est:

  • S'assurer que le logiciel répond aux exigences et à la conception convenues
  • L'application fonctionne comme prévu
  • L'application ne contient pas de bogues sérieux
  • Répond à son utilisation prévue selon les attentes de l'utilisateur

Les tests de logiciels sont souvent utilisés en association avec les termes vérification et validation .


Validation : Faisons-nous le bon travail? Vérification : Faisons-nous le bon travail?

La vérification consiste à vérifier ou à tester des éléments, y compris des logiciels, pour vérifier leur conformité et leur cohérence avec une spécification associée.


La validation est le processus de vérification que ce qui a été spécifié correspond à ce que l'utilisateur voulait réellement.

Les tests logiciels ne sont qu'un type de vérification, qui utilise également des techniques telles que les revues, l'analyse, les inspections et la visite virtuelle.



Qu'est-ce que le test exploratoire et quand doit-il être effectué?

La définition des tests exploratoires est «conception et exécution de tests simultanés» par rapport à une application. Cela signifie que le testeur utilise ses connaissances du domaine et son expérience de test pour prédire où et dans quelles conditions le système peut se comporter de manière inattendue. Au fur et à mesure que le testeur commence à explorer le système, de nouvelles idées de conception de test sont pensées à la volée et exécutées par rapport au logiciel testé.

Lors d'une session de test exploratoire, le testeur exécute une chaîne d'actions contre le système, chaque action dépend du résultat de l'action précédente, donc le résultat du résultat des actions pourrait influencer ce que le testeur fait ensuite, donc les sessions de test sont pas identique.


Cela contraste avec les tests scriptés où les tests sont conçus à l'avance en utilisant les exigences ou les documents de conception, généralement avant que le système ne soit prêt et exécutent exactement les mêmes étapes contre le système à un autre moment.

Les tests exploratoires sont généralement effectués au fur et à mesure que le produit évolue (agile) ou en tant que contrôle final avant la sortie du logiciel. C'est une activité complémentaire aux tests de régression automatisés.



Quelles techniques de test existe-t-il et quel est leur objectif?

Les techniques de test sont principalement utilisées à deux fins: a) Pour aider à identifier les défauts, b) Pour réduire le nombre de cas de test.

  • Le partitionnement d'équivalence est principalement utilisé pour réduire le nombre de cas de test en identifiant différents ensembles de données qui ne sont pas les mêmes et en n'exécutant qu'un seul test à partir de chaque ensemble de données
  • L'analyse de la valeur aux limites est utilisée pour vérifier le comportement du système aux limites des données autorisées.
  • Le test de transition d'état est utilisé pour valider les états autorisés et interdits et les transitions d'un état à un autre par diverses données d'entrée
  • Le test par paires ou toutes paires est une technique de test très puissante et est principalement utilisée pour réduire le nombre de cas de test tout en augmentant la couverture des combinaisons de fonctionnalités.


Pourquoi les tests sont-ils nécessaires?

Des tests sont nécessaires pour identifier les défauts présents dans le logiciel qui peuvent causer des dommages. Sans des tests appropriés, nous pourrions potentiellement publier un logiciel qui pourrait mal fonctionner et causer des blessures graves.


Des exemples peuvent être:

  • Logiciel dans une machine de survie pouvant causer de graves dommages à un patient;
  • Un logiciel dans une centrale nucléaire qui surveille l'activité nucléaire peut nuire à l'environnement
  • Une application bancaire ou financière qui calcule les taux de change peut entraîner des pertes financières pour une entreprise


Quelle est la différence entre un bogue, un défaut, une erreur, un échec, un défaut et une erreur?

L'erreur et l'erreur sont les mêmes choses. Le bogue, le défaut et le défaut sont la même chose.

En général, un être humain peut commettre une erreur (erreur) qui produit un défaut (bug, faute) dans une application logicielle qui peut provoquer une panne.

Les défauts surviennent parce que les êtres humains sont enclins à faire des erreurs, une application logicielle peut également être très complexe, de sorte que l'intégration de différents composants peut provoquer des comportements étranges.




Combien de tests suffisent-ils?

Il n'y a pas de réponse définitive à cette question. Les tests ne sont pas absolus et n'ont pas de limites. Cependant, nous pouvons utiliser des mesures de risque (tests basés sur les risques) pour identifier les scénarios probables qui peuvent causer le plus de dommages ou les sections du logiciel les plus utilisées afin de concentrer notre temps et nos efforts sur les sections les plus importantes.

Les tests doivent fournir suffisamment d'informations sur l'état ou la santé d'une application, afin que les parties prenantes puissent prendre une décision éclairée sur l'opportunité de publier le logiciel ou de consacrer plus de temps aux tests.



Quel est le processus de test fondamental

Afin de tirer le meilleur parti des activités de test, un processus défini doit être suivi. Mais avant le début de toute activité de test, une grande partie de l'effort doit être consacrée à la production d'un bon plan de test. Un bon plan de test contribue grandement à garantir que les activités de test sont conformes à ce que les tests tentent de réaliser.

Il est peut-être le plus applicable à un environnement de test assez formel (tel que la mission critique). La plupart des organisations commerciales ont des processus de test moins rigoureux. Cependant, tout effort de test peut utiliser ces étapes sous une forme ou une autre.


Le processus de test fondamental comprend cinq activités:

  • Planification
  • spécification
  • Exécution
  • Enregistrement
  • Vérification de l'achèvement du test

Le processus de test commence toujours par la planification du test et se termine par la vérification de l'achèvement du test.

Toutes les activités peuvent être répétées (ou au moins revisitées) car un certain nombre d'itérations peuvent être nécessaires avant que les critères d'achèvement définis au cours de l'activité de planification des tests ne soient satisfaits.



Sept principes du test logiciel

Voici les sept principes du test logiciel:

1. Les tests montrent la présence de bogues

Le test d'une application ne peut que révéler qu'un ou plusieurs défauts existent dans l'application, cependant, le test à lui seul ne peut pas prouver que l'application est exempte d'erreurs. Par conséquent, il est important de concevoir des cas de test qui détectent autant de défauts que possible.

2. Des tests exhaustifs sont impossibles

À moins que l'application testée (AUT) n'ait une structure logique très simple et des entrées limitées, il n'est pas possible de tester toutes les combinaisons possibles de données et de scénarios. Pour cette raison, les risques et les priorités sont utilisés pour se concentrer sur les aspects les plus importants à tester.

3. Tests précoces

Plus tôt nous commençons les activités de test, mieux nous pouvons utiliser le temps disponible. Dès que les produits initiaux, tels que les exigences ou les documents de conception sont disponibles, nous pouvons commencer les tests. Il est courant que la phase de test soit bloquée à la fin du cycle de vie du développement, c'est-à-dire lorsque le développement est terminé, donc en commençant les tests tôt, nous pouvons préparer les tests pour chaque niveau du cycle de vie du développement.

Un autre point important à propos des tests précoces est que lorsque des défauts sont détectés plus tôt dans le cycle de vie, ils sont beaucoup plus faciles et moins coûteux à corriger. Il est beaucoup moins coûteux de modifier une exigence incorrecte que d'avoir à modifier une fonctionnalité dans un grand système qui ne fonctionne pas comme demandé ou comme prévu!

4. Regroupement des défauts

Lors des tests, on peut observer que la plupart des défauts signalés sont liés à un petit nombre de modules dans un système. c'est-à-dire qu'un petit nombre de modules contient la plupart des défauts du système. C'est l'application du principe de Pareto aux tests logiciels: environ 80% des problèmes se retrouvent dans 20% des modules.

5. Le paradoxe des pesticides

Si vous continuez à exécuter le même ensemble de tests encore et encore, il est probable que ces cas de test ne découvrent plus de nouveaux défauts. Parce qu'au fur et à mesure que le système évolue, de nombreux défauts signalés précédemment auront été corrigés et les anciens cas de test ne s'appliquent plus.

Chaque fois qu'une erreur est corrigée ou qu'une nouvelle fonctionnalité est ajoutée, nous devons effectuer des tests de régression pour nous assurer que le nouveau logiciel modifié n'a cassé aucune autre partie du logiciel. Cependant, ces cas de test de régression doivent également changer pour refléter les modifications apportées au logiciel pour être applicables et, espérons-le, corriger les nouveaux défauts.

6. Les tests dépendent du contexte

Différentes méthodologies, techniques et types de tests sont liés au type et à la nature de l'application. Par exemple, une application logicielle dans un dispositif médical nécessite plus de tests qu'un logiciel de jeu.

Plus important encore, un logiciel de dispositif médical nécessite des tests basés sur les risques, être conforme aux réglementations de l'industrie médicale et éventuellement à des techniques de conception de tests spécifiques.

De même, un site Web très populaire doit passer par des tests de performances rigoureux ainsi que des tests de fonctionnalités pour s'assurer que les performances ne sont pas affectées par la charge sur les serveurs.

7. Absence d'erreurs fallacieuses

Ce n'est pas parce que les tests n'ont détecté aucun défaut dans le logiciel que le logiciel est prêt à être expédié. Les tests exécutés ont-ils vraiment été conçus pour détecter le plus de défauts? ou où ils ont conçu pour voir si le logiciel répondait aux exigences de l'utilisateur? Il existe de nombreux autres facteurs à prendre en compte avant de prendre la décision d'expédier le logiciel.



Qu'est-ce que le test de la boîte blanche

Les tests en boîte blanche concernent la logique interne et la structure du code. Le test de boîte blanche est également appelé test de verre, de structure, de boîte ouverte ou de boîte transparente. Les tests écrits sur la base de la stratégie de test de la boîte blanche intègrent la couverture du code écrit, des branches, des chemins, des instructions et de la logique interne du code, etc.

Afin de mettre en œuvre le test de la boîte blanche, le testeur doit gérer le code et doit donc posséder des connaissances du codage et de la logique, c'est-à-dire du fonctionnement interne du code. Le test de la boîte blanche nécessite également que le testeur examine le code et découvre quelle unité / instruction / bloc du code fonctionne mal.

Test unitaire

Le développeur effectue des tests unitaires afin de vérifier si le module ou l'unité de code particulier fonctionne correctement. Le test unitaire intervient au niveau très basique car il est effectué au fur et à mesure que l'unité du code est développée ou qu'une fonctionnalité particulière est construite.

Analyse statique et dynamique

L'analyse statique consiste à parcourir le code afin de découvrir d'éventuels défauts dans le code. L'analyse dynamique implique l'exécution du code et l'analyse de la sortie.

Couverture de l'état

Dans ce type de test, le code est exécuté de telle manière que chaque instruction de l'application soit exécutée au moins une fois. Cela aide à garantir que toutes les instructions s'exécutent sans aucun effet secondaire.

Couverture de la succursale

Aucune application logicielle ne peut être écrite dans un mode de codage continu, à un moment donné, nous devons bifurquer le code afin d'exécuter une fonctionnalité particulière. Les tests de couverture de branche aident à valider toutes les branches du code et à s'assurer qu'aucune branche ne conduit à un comportement anormal de l'application.

Test de sécurité

Des tests de sécurité sont effectués afin de déterminer dans quelle mesure le système peut se protéger contre les accès non autorisés, le piratage - craquage, tout dommage au code, etc. qui traite du code d'application. Ce type de test nécessite des techniques de test sophistiquées.

Test de mutation

Une sorte de test dans lequel, l'application est testée pour le code qui a été modifié après avoir corrigé un bogue / défaut particulier. Cela aide également à découvrir quel code et quelle stratégie de codage peuvent aider à développer efficacement la fonctionnalité.

Avantages des tests en boîte blanche

La connaissance de la structure de codage interne étant une condition préalable, il devient très facile de savoir quel type d'entrée / de données peut aider à tester efficacement l'application. L'autre avantage du test en boîte blanche est qu'il aide à optimiser le code. Il aide à supprimer les lignes de code supplémentaires, ce qui peut entraîner des défauts cachés.

Inconvénients des tests en boîte blanche

La connaissance du code et de la structure interne étant une condition préalable, un testeur qualifié est nécessaire pour effectuer ce type de test, ce qui augmente le coût. Et il est presque impossible d'examiner chaque bit de code pour trouver des erreurs cachées, qui peuvent créer des problèmes, entraînant un échec de l'application.



Qu'est-ce que le test de la boîte noire

Dans Black Box Testing, le testeur teste une application sans connaître le fonctionnement interne de l'application testée.

Étant donné que les tests de boîte noire ne concernent pas le code sous-jacent, les techniques peuvent être dérivées des documents d'exigences ou des spécifications de conception et, par conséquent, les tests peuvent commencer dès que les exigences sont écrites.

Technique de test d'analyse de la valeur limite

L'analyse de la valeur aux limites, BVA, teste le comportement d'un programme aux limites. Lors de la vérification d'une plage de valeurs, après avoir sélectionné l'ensemble de données qui se trouvent dans les partitions valides, il faut ensuite vérifier le comportement du programme aux valeurs limites des partitions valides. L'analyse de la valeur limite est la plus courante lors de la vérification d'une plage de nombres.

Technique de transition d'état

La technique de test de transition d'état est utilisée lorsque certains aspects du système peuvent être décrits dans ce que l'on appelle une «machine à états finis». Cela signifie simplement que le système peut être dans un nombre (fini) d'états différents, et les transitions d'un état à un autre sont déterminées par les règles de la «machine».

C'est le modèle sur lequel le système et les tests sont basés. Tout système dans lequel vous obtenez une sortie différente pour la même entrée, en fonction de ce qui s'est passé auparavant, est un système à états finis.

Technique de test de partitionnement d'équivalence

L'idée derrière la technique de test de partitionnement d'équivalence est d'éliminer l'ensemble des données d'entrée qui font que le système se comporte de la même manière et donnent le même résultat lors du test d'un programme.

Le processus de la technique de partitionnement d'équivalence consiste à identifier l'ensemble de données en tant que condition d'entrée qui donne le même résultat lors de l'exécution d'un programme et à les classer comme un ensemble de données équivalentes (car elles font que le programme se comporte de la même manière et génère la même sortie ) et en les partitionnant à partir d'un autre ensemble équivalent de données.

Avantages des tests Black Box

  • Le test est impartial car le concepteur et le testeur sont indépendants l'un de l'autre.
  • Le testeur n'a pas besoin de connaître les langages de programmation spécifiques.
  • Le test est fait du point de vue de l'utilisateur et non du concepteur.
  • Les cas de test peuvent être conçus dès que les spécifications sont complètes.

Inconvénients des tests Black Box

  • Le test peut être redondant si le concepteur du logiciel a déjà exécuté un cas de test.
  • Les cas de test sont difficiles à concevoir.
  • Tester tous les flux d'entrée possibles n'est pas réaliste car cela prendrait un temps excessif; par conséquent, de nombreux chemins d'accès aux programmes ne seront pas testés.