Les tests sont essentiels dans le d\u00e9veloppement de logiciels afin de garantir la livraison de produits logiciels de haute qualit\u00e9 et exempts d’erreurs. Les testeurs utilisent diverses techniques de test de logiciels pour identifier les probl\u00e8mes, les bogues et les erreurs dans les produits logiciels. L’un d’entre eux est le test de la bo\u00eete blanche. Il s’agit de l’\u00e9valuation de la structure interne du logiciel et des d\u00e9tails de sa mise en \u0153uvre. <\/p>\n\n
Dans cet article, nous aborderons les aspects fondamentaux des tests en bo\u00eete blanche.<\/p>\n
Le test de la bo\u00eete blanche est une technique de test des logiciels qui permet de tester la conception interne du syst\u00e8me, la structure du code source, les structures de donn\u00e9es utilis\u00e9es et les d\u00e9tails de fonctionnement. Son objectif principal est d’am\u00e9liorer la conception des logiciels, le flux des entr\u00e9es\/sorties, la facilit\u00e9 d’utilisation et la s\u00e9curit\u00e9. Il est \u00e9galement appel\u00e9 essai transparent, essai structurel et essai en bo\u00eete de verre. <\/p>\n\n
La mise en \u0153uvre de cette technique de test exige que les testeurs soient familiaris\u00e9s avec le code du syst\u00e8me, son architecture et les d\u00e9tails de sa mise en \u0153uvre. Sur la base de ces connaissances, ils cr\u00e9ent des cas de test et les ex\u00e9cutent pour v\u00e9rifier l’exactitude du syst\u00e8me au niveau du code. C’est pourquoi ces tests sont \u00e9galement appel\u00e9s tests bas\u00e9s sur le code. <\/p>\n\n
En g\u00e9n\u00e9ral, les d\u00e9veloppeurs effectuent des tests en bo\u00eete blanche. Comprendre parfaitement le code source et le fonctionnement interne du logiciel. Dans certains cas, cependant, elle peut \u00e9galement \u00eatre r\u00e9alis\u00e9e par des experts en assurance qualit\u00e9 (AQ) et des testeurs qui comprennent un code complexe. <\/p>\n\n
Cette technique de test est appel\u00e9e \u00ab\u00a0bo\u00eete blanche\u00a0\u00bb parce que les d\u00e9veloppeurs ou les testeurs examinent le fonctionnement interne du syst\u00e8me depuis l’ext\u00e9rieur de la bo\u00eete. <\/p>\n\n
Il est appliqu\u00e9 aux deux premiers niveaux des tests de logiciels : les tests unitaires et les tests d’int\u00e9gration. Les tests unitaires v\u00e9rifient chaque module logiciel s\u00e9par\u00e9ment. Les tests d’int\u00e9gration relient alors logiquement les modules test\u00e9s et testent leur interaction ou leur communication.<\/p>\n\n
Le test de la bo\u00eete blanche dans les tests de logiciels \u00e9value le code source du logiciel pour v\u00e9rifier les param\u00e8tres suivants : <\/p>\n\n
En bref, cette technique de test permet de v\u00e9rifier le flux de travail du logiciel. Il s’agit de fournir un ensemble d’intrants et de comparer les r\u00e9sultats attendus et r\u00e9els. Si la sortie r\u00e9elle ne correspond pas \u00e0 la sortie attendue, il en r\u00e9sulte une erreur ou un bogue.<\/p>\n\n
En g\u00e9n\u00e9ral, les d\u00e9veloppeurs ou les testeurs v\u00e9rifient les applications \u00e0 l’aide de cette technique de test des logiciels en deux \u00e9tapes : <\/p>\n\n
Cela les aidera \u00e0 cr\u00e9er des cas de test efficaces pour d\u00e9couvrir les vuln\u00e9rabilit\u00e9s potentielles en mati\u00e8re de s\u00e9curit\u00e9 et garantir un pourcentage maximal de couverture des tests.<\/p>\n\n
Nous savons maintenant que l’objectif des tests en bo\u00eete blanche est de v\u00e9rifier la structure du code, comme les instructions de boucle, les instructions conditionnelles, les branches de d\u00e9cision, etc. Nous allons le comprendre \u00e0 l’aide d’un exemple simple :<\/p>\n\n
Test (a, b)\n{\nint n ;\nsi (n % 2 ==0)\n{\nprint(\"Nombre impair\")\n}\nautre\n{\nprint(\"Nombre impair\")\n}\n}<\/pre>\n\nPour v\u00e9rifier ce code, nous disposons des deux cas de test suivants : <\/p>\n\n
Pour le premier cas de test, n = 25, la condition \u00ab\u00a0si\u00a0\u00bb ne s’applique pas. Le programme passe donc au bloc \u00ab\u00a0else\u00a0\u00bb et imprime l’instruction qu’il contient. Dans le deuxi\u00e8me cas de test, n = 50, la condition \u00ab\u00a0if\u00a0\u00bb est vraie et l’instruction qu’elle contient est ex\u00e9cut\u00e9e. <\/p>\n\n
De cette mani\u00e8re, les tests en bo\u00eete blanche ont parcouru chaque ligne du code source de l’application et ont permis de d\u00e9couvrir des bogues potentiels au niveau du code. <\/p>\n\n
Les diff\u00e9rents types de techniques de test de la bo\u00eete blanche sont les suivants : <\/p>\n\n
1. Couverture de la d\u00e9claration<\/strong><\/p>\n\n Cette technique exige que vous examiniez et testiez chaque d\u00e9claration du code source au moins une fois. Ainsi, l’ensemble du code source est exerc\u00e9. <\/p>\n\n La couverture des instructions d\u00e9termine le pourcentage du code source qu’un ensemble particulier de cas de test exercera. La formule pour couvrir les d\u00e9clarations est la suivante : <\/p>\n\n Couverture des d\u00e9clarations = (nombre de d\u00e9clarations faites \/ nombre total de d\u00e9clarations) * 100<\/strong><\/p>\n\n 2. Couverture de la d\u00e9cision\/couverture de la branche<\/strong><\/p>\n\n Le meilleur exemple de branche (point de d\u00e9cision) en programmation est l’instruction \u00ab\u00a0if\u00a0\u00bb. Il comporte deux branches : True (vrai) et False (faux). La technique de couverture des branches garantit que chaque branche de la source est ex\u00e9cut\u00e9e au moins une fois.<\/p>\n\n La couverture des branches est le pourcentage de branches ou de points de d\u00e9cision ex\u00e9cut\u00e9s pendant les tests.<\/p>\n\n Couverture des succursales = (nombre de succursales mises en \u0153uvre \/ nombre total de succursales) * 100 %.<\/strong><\/p>\n\n 3. Couverture des conditions<\/strong><\/p>\n\n Le test des conditions consiste \u00e0 tester chaque condition pour obtenir des r\u00e9sultats VRAIS et FAUX. Pour obtenir une couverture nationale de 100 %, il faut donc appliquer chaque condition pour les r\u00e9sultats VRAI et FAUX. Pour n conditions, nous aurons 2n scripts de test.<\/p>\n\n L’objectif principal de la couverture des conditions est de d\u00e9terminer la sortie de chaque condition dans le code source. Cependant, il ne teste que les conditions avec des op\u00e9randes logiques dont le r\u00e9sultat est soit vrai, soit faux.<\/p>\n\n 4. Essais multi-conditionnels<\/strong><\/p>\n\n Son objectif est de tester toutes les combinaisons possibles de chaque \u00e9tat de la branche. Comprenons-le \u00e0 l’aide d’un exemple.<\/p>\n\n Les cas de test pour le code ci-dessus seront les suivants :<\/p>\n\n A=VRAI, B=VRAI<\/p>\n\n A=VRAI, B=FAUX<\/p>\n\n A=FAUX, B=VRAI<\/p>\n\n A=FAUX, B=FAUX<\/p>\n\n Notre exemple comporte 2 conditions – A et B – et 4 cas de test. S’il y avait 3 expressions, le nombre de cas de test serait de 8.<\/p>\n\n Par cons\u00e9quent, pour une couverture de 100 %, nous aurons 2n scripts de test. C’est tr\u00e8s \u00e9puisant et il est tr\u00e8s difficile d’obtenir une couverture \u00e0 100 %.<\/p>\n\n 5. Test de cheminement<\/strong><\/p>\n\n Le test de chemin garantit que tous les chemins possibles dans le code source sont ex\u00e9cut\u00e9s au moins une fois. Il s’agit de cr\u00e9er un diagramme de flux de contr\u00f4le \u00e0 l’aide du code source ou d’un organigramme. Ensuite, il d\u00e9termine la complexit\u00e9 cyclomatique, qui concerne les chemins ind\u00e9pendants. Les testeurs cr\u00e9ent donc des cas de test minimaux pour ces chemins ind\u00e9pendants. <\/p>\n\n Couverture des voyages = (nombre de voyages effectu\u00e9s \/ nombre total de voyages dans le programme) x 100 %.<\/strong><\/p>\n\n 6. Test des cycles de boucle<\/strong><\/p>\n\n Les cycles sont des constructions courantes et sont utilis\u00e9s dans la plupart des grands programmes. Les tests cycliques sont essentiels car il existe une forte probabilit\u00e9 d’erreurs au d\u00e9but ou \u00e0 la fin d’un cycle. Par cons\u00e9quent, les tests effectu\u00e9s r\u00e9v\u00e8lent les erreurs ou les bogues dans un cycle particulier. La principale erreur qui se produit dans les cycles est la pr\u00e9sence d’indices incorrects.<\/p>\n\n Voici les diff\u00e9rents types de tests en bo\u00eete blanche : <\/p>\n\n Tests unitaires :<\/strong> il s’agit du premier niveau de test des logiciels. Il teste chaque module d’application, appel\u00e9 unit\u00e9, individuellement pour s’assurer qu’il est correct. Veille \u00e0 ce que chaque composant fonctionne comme pr\u00e9vu.<\/p>\n\n Tests d’int\u00e9gration :<\/strong> ils interviennent apr\u00e8s les tests unitaires. Il combine les diff\u00e9rents \u00e9l\u00e9ments test\u00e9s de mani\u00e8re logique et confirme l’interaction entre eux. Son objectif est de d\u00e9tecter toute erreur dans l’interaction des composants. <\/p>\n\n Tests de p\u00e9n\u00e9tration en bo\u00eete blanche : <\/strong>les testeurs ont un acc\u00e8s total au code source de l’application et aux donn\u00e9es du r\u00e9seau, de l’IP et du serveur, y compris les mots de passe et les cartes. L’objectif principal des tests de p\u00e9n\u00e9tration est de d\u00e9tecter les zones du code source pr\u00e9sentant des faiblesses en mati\u00e8re de s\u00e9curit\u00e9. <\/p>\n\n Tests de mutation en bo\u00eete blanche :<\/strong> comme son nom l’indique, les tests de mutation d\u00e9pendent des changements. Les testeurs apportent des modifications mineures au code source pour v\u00e9rifier que l’ex\u00e9cution des cas de test ne r\u00e9v\u00e8le pas de bogues. Si les cas de test r\u00e9ussissent, cela indique une erreur dans le code source. Toutefois, si les cas de test \u00e9chouent, le code source est exempt d’erreurs.<\/p>\n\n Pr\u00e9cisons maintenant les avantages et les inconv\u00e9nients du test de la bo\u00eete blanche. <\/p>\n\n Voici une liste d’outils de test en bo\u00eete blanche couramment utilis\u00e9s : <\/p>\n\n Le tableau suivant met en \u00e9vidence les principales diff\u00e9rences entre les tests en cabinet noir et les tests en cabinet blanc :<\/p>\n\n Le test de la bo\u00eete blanche est une technique de test des logiciels qui exige des testeurs une compr\u00e9hension compl\u00e8te du fonctionnement interne et de la structure du code d’une application. Elle r\u00e9v\u00e8le donc des lacunes structurelles et s\u00e9curitaires. L’objectif principal est de v\u00e9rifier la fonctionnalit\u00e9 et l’exactitude de l’application au niveau du code. <\/p>\n\n Bien que cette technique de test prenne du temps et demande beaucoup d’efforts, c’est le seul moyen de s’assurer que vous testez chaque ligne de votre code source. S’il est effectu\u00e9 correctement, le test de la bo\u00eete blanche am\u00e9liorera consid\u00e9rablement la qualit\u00e9 du logiciel.<\/p>\n","protected":false},"excerpt":{"rendered":" Les tests en bo\u00eete blanche testent la conception interne du syst\u00e8me, la structure du code source, les structures de donn\u00e9es utilis\u00e9es et les d\u00e9tails de fonctionnement. <\/p>\n","protected":false},"author":8,"featured_media":2860,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[54],"tags":[],"class_list":["post-2859","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tests-manuels"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/posts\/2859","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/comments?post=2859"}],"version-history":[{"count":1,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/posts\/2859\/revisions"}],"predecessor-version":[{"id":2861,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/posts\/2859\/revisions\/2861"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/media\/2860"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/media?parent=2859"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/categories?post=2859"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/tags?post=2859"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}si (A||B) \nimprimer C<\/pre>\n\n
Types de tests en bo\u00eete blanche<\/h2>\n\n
Avantages et inconv\u00e9nients des tests en bo\u00eete blanche <\/h2>\n\n
Avantages <\/h2>\n\n
\n
Inconv\u00e9nients <\/h2>\n\n
\n
Outils de test en bo\u00eete blanche <\/h2>\n\n
\n
La diff\u00e9rence entre les tests de la bo\u00eete blanche et de la bo\u00eete noire<\/h2>\n\n
Tests en bo\u00eete blanche<\/strong><\/td> Tests en bo\u00eete noire<\/strong><\/td><\/tr> N\u00e9cessite une connaissance de la structure interne et du fonctionnement de l’application.<\/td> Aucune connaissance interne de l’application n’est requise.<\/td><\/tr> Nous pouvons tester de nombreux aspects d\u00e9taill\u00e9s de l’application.<\/td> Nous testons la fonctionnalit\u00e9 de bout en bout de l’application.<\/td><\/tr> Ces tests sont effectu\u00e9s par des d\u00e9veloppeurs ou des professionnels de l’assurance qualit\u00e9 ayant une bonne connaissance de la programmation et de l’architecture des applications.<\/td> Les tests \u00ab\u00a0bo\u00eete noire\u00a0\u00bb sont effectu\u00e9s par une \u00e9quipe ind\u00e9pendante de contr\u00f4le de la qualit\u00e9.<\/td><\/tr> S’applique aux niveaux inf\u00e9rieurs de test – tests unitaires et tests d’int\u00e9gration.<\/td> Il s’applique \u00e0 des niveaux de test plus \u00e9lev\u00e9s – tests de syst\u00e8me et tests d’acceptation, o\u00f9 nous devons tester l’application dans son ensemble.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n Conclusion<\/h2>\n\n