7 principes de test de logiciels avec des exemples

Ce didacticiel présente les sept principes de base des tests logiciels que tout testeur de logiciels et professionnel de l'assurance qualité devrait connaître.

Apprenons les principes de test avec ce qui suit Exemple de vidéo-

Cliquez sur ici. si la vidéo n'est pas accessible

Information de Base:

Il est important que vous obteniez des résultats de test optimaux lorsque vous effectuez des tests logiciels sans vous écarter de l'objectif. Mais comment déterminer que vous suivez la bonne stratégie de test ? Pour cela, vous devez vous en tenir à certains principes de test de base. Voici les sept principes de test courants largement pratiqués dans l’industrie du logiciel.

Pour comprendre cela, envisagez un scénario dans lequel vous déplacez un fichier du dossier A vers le dossier B.

Pensez à toutes les manières possibles de tester cela.

Outre les scénarios habituels, vous pouvez également tester les conditions suivantes

• Essayer de déplacer le fichier lorsqu'il est ouvert
• Vous n'avez pas les droits de sécurité pour coller le fichier dans le dossier B
• Le dossier B se trouve sur un lecteur partagé et la capacité de stockage est pleine.
• Le dossier B contient déjà un fichier du même nom, en fait, la liste est interminable
• Ou supposons que vous ayez 15 champs de saisie à tester, chacun ayant 5 valeurs possibles, le nombre de combinaisons à tester serait de 5^15.

Si vous deviez tester l’ensemble des combinaisons possibles du projet, LE TEMPS D’EXÉCUTION ET LES COÛTS augmenteraient de façon exponentielle. Nous avons besoin de certains principes et stratégies pour optimiser l'effort de test

Voici les 7 principes :

1) Des tests exhaustifs ne sont pas possibles

Oui! Des tests exhaustifs ne sont pas possibles. Au lieu de cela, nous avons besoin d’une quantité optimale de tests basée sur l’évaluation des risques de l’application.

Et la question à un million de dollars est la suivante : comment déterminez-vous ce risque ?

Pour répondre à cela, faisons un exercice

À votre avis, quelle opération est la plus susceptible de provoquer votre Operale système de réglage échoue-t-il ?

Je suis sûr que la plupart d'entre vous l'auraient deviné, ouvrant 10 applications différentes en même temps.

Donc si tu testais ça Operasystème, vous vous rendriez compte que des défauts sont susceptibles d'être trouvés dans une activité multitâche et doivent être testés minutieusement, ce qui nous amène à notre prochain principe Défaut Clusterfaire respecter

2) Défaut Clusterfaire respecter

Défaut Clustering qui indique qu'un petit nombre de modules contiennent la plupart des défauts détectés. Il s'agit de l'application du principe de Pareto aux tests logiciels : environ 80 % des problèmes se retrouvent dans 20 % des modules.

Par expérience, vous pouvez identifier ces modules risqués. Mais cette approche a ses propres problèmes

Si les mêmes tests sont répétés encore et encore, les mêmes cas de test ne trouveront finalement plus de nouveaux bugs.

3) Le paradoxe des pesticides

L'utilisation répétée du même mélange de pesticides pour éradiquer les insectes pendant l'agriculture conduira, au fil du temps, à développer une résistance aux insectes. Les pesticides seront donc inefficaces sur les insectes. Il en va de même pour les tests de logiciels. Si le même ensemble de tests répétitifs est effectué, la méthode sera inutile pour découvrir de nouveaux défauts.

Pour surmonter ce problème, les cas de test doivent être régulièrement examinés et révisés, en ajoutant de nouveaux et différents cas de test pour aider à trouver davantage de défauts.

Les testeurs ne peuvent pas simplement dépendre des techniques de test existantes. Il doit veiller continuellement à améliorer les méthodes existantes pour rendre les tests plus efficaces. Mais même après toute cette sueur et tout ce travail acharné lors des tests, vous ne pouvez jamais prétendre que votre produit est exempt de bogues. Pour bien comprendre ce point, regardons cette vidéo du lancement public de Windows 98

Vous pensez qu'une entreprise comme MICROSOFT n'aurait pas testé son système d'exploitation de manière approfondie et risquerait sa réputation juste pour voir son système d'exploitation planter lors de son lancement public !

4) Les tests montrent la présence de défauts

Par conséquent, le principe de test stipule que – Le test parle de la présence de défauts et ne parle pas de l'absence de défauts. Test de logiciel réduit la probabilité que des défauts non découverts subsistent dans le logiciel, mais même si aucun défaut n'est trouvé, cela ne constitue pas une preuve d'exactitude.

Mais que se passerait-il si vous travailliez très dur, en prenant toutes les précautions et en rendant votre produit logiciel exempt de bogues à 99 %. Et le logiciel ne répond pas aux besoins et exigences des clients.

Cela nous amène à notre prochain principe, qui stipule que : Absence d'erreur

5) Absence d’erreur – erreur

Il est possible qu'un logiciel exempt de bogues à 99 % soit toujours inutilisable. Cela peut être le cas si le système est testé minutieusement pour répondre à une mauvaise exigence. Les tests logiciels ne consistent pas simplement à détecter des défauts, mais également à vérifier que le logiciel répond aux besoins de l'entreprise. L'absence d'erreur est une erreur, c'est-à-dire que la recherche et la correction des défauts n'aident pas si la version du système est inutilisable et ne répond pas aux besoins et exigences de l'utilisateur.

Pour résoudre ce problème, le principe suivant des tests stipule que les tests précoces

6) Tests précoces

Tests précoces – Les tests doivent commencer le plus tôt possible dans le cycle de vie du développement logiciel. Afin que tout défaut dans les exigences ou la phase de conception soit détecté dès les premières étapes. Il est beaucoup moins coûteux de corriger un défaut dès les premiers stades des tests. Mais à quel moment faut-il commencer les tests ? Il est recommandé de commencer à rechercher le bogue dès que les exigences sont définies. Plus d’informations sur ce principe dans un didacticiel de formation ultérieur.

7) Les tests dépendent du contexte

Les tests dépendent du contexte, ce qui signifie essentiellement que la façon dont vous testez un site de commerce électronique sera différente de la façon dont vous testez une application commerciale standard. Tous les logiciels développés ne sont pas identiques. Vous pouvez utiliser une approche, des méthodologies, des techniques et des types de tests différents en fonction du type d'application. Par exemple, les tests de tout système de point de vente dans un magasin de détail seront différents du test d'un distributeur automatique de billets.

Mythe : « Les principes sont juste à titre de référence. Je ne les utiliserai pas dans la pratique.

C’est tellement faux. Les principes de test vous aideront à créer un système efficace Stratégie de test et rédiger des cas de test de détection d'erreurs.

Mais apprendre les principes des tests, c’est comme apprendre à conduire pour la première fois.

Au début, pendant que vous apprenez à conduire, vous faites attention à tout et à tout comme les changements de vitesse, la vitesse, la manipulation de l'embrayage, etc. Mais avec l'expérience, vous vous concentrez uniquement sur la conduite, le reste vient naturellement. De telle sorte que vous puissiez même discuter avec d'autres passagers de la voiture.

Il en va de même pour les principes de test. Les testeurs expérimentés ont intériorisé ces principes à un point tel qu’ils les appliquent même sans réfléchir. Le mythe selon lequel les principes ne sont pas appliqués dans la pratique est donc tout simplement faux.