- Defin\u00edcia testovania \u010diernej skrinky<\/a><\/li>
- Vlastnosti testovania \u010diernej skrinky<\/a><\/li>
- Techniky testovania \u010diernej skrinky<\/a><\/li>
- Ako testova\u0165 \u010diernu skrinku?<\/a><\/li>
- V\u00fdhody testovania \u010diernej skrinky<\/a><\/li>
- Black-box vs. White-box testing<\/a><\/li><\/ul><\/div>\n
D\u00e9finition des tests en bo\u00eete noire<\/h2>\n\n
Le test de la bo\u00eete noire est un type de test dans lequel une application est test\u00e9e sur la base des sp\u00e9cifications de ses besoins sans qu’il soit n\u00e9cessaire de conna\u00eetre son architecture interne.<\/p>\n\n
Caract\u00e9ristiques des tests en bo\u00eete noire<\/h2>\n\n
- \n
- Il teste les exigences fonctionnelles et non fonctionnelles de l’application.<\/li>\n\n\n\n
- La connaissance du codage, de la conception et de l’architecture interne des logiciels, ainsi que l’acc\u00e8s \u00e0 ceux-ci, ne sont pas n\u00e9cessaires.<\/li>\n\n\n\n
- Les testeurs peuvent travailler ind\u00e9pendamment des d\u00e9veloppeurs, ce qui garantit des tests objectifs et centr\u00e9s sur l’utilisateur final.<\/li>\n<\/ul>\n\n
Techniques de test en bo\u00eete noire<\/h2>\n\n
Vous trouverez ci-dessous quelques-uns des types les plus courants de techniques de test en bo\u00eete noire :<\/p>\n\n
S\u00e9paration des classes d’\u00e9quivalence<\/strong><\/p>\n\n
Le partitionnement en classes d’\u00e9quivalence consiste \u00e0 diviser les donn\u00e9es d’entr\u00e9e en groupes logiques ou en classes d’\u00e9quivalence. Il est suppos\u00e9 que toutes les donn\u00e9es appartenant \u00e0 la classe d’\u00e9quivalence seront trait\u00e9es de la m\u00eame mani\u00e8re par l’application lorsqu’elles lui seront transmises en entr\u00e9e.<\/p>\n\n
Par exemple. pour un logiciel qui trouve le carr\u00e9 d’un nombre, nous pouvons avoir diff\u00e9rentes classes d’\u00e9quivalence comme – tous les nombres positifs, les nombres n\u00e9gatifs, les nombres d\u00e9cimaux, les nombres d\u00e9cimaux n\u00e9gatifs, etc.<\/p>\n\n
Son avantage est que le temps global d’ex\u00e9cution des tests est r\u00e9duit car le nombre de donn\u00e9es de test est consid\u00e9rablement r\u00e9duit.<\/p>\n\n
Analyse des valeurs limites<\/strong><\/p>\n\n
L’analyse des valeurs limites est une technique de test en bo\u00eete noire qui est \u00e9troitement li\u00e9e \u00e0 la distribution des classes d’\u00e9quivalence. Dans cette technique, nous analysons le comportement d’une application \u00e0 l’aide de donn\u00e9es de test situ\u00e9es aux fronti\u00e8res des classes d’\u00e9quivalence.<\/p>\n\n
Par exemple. Pour les classes d’\u00e9quivalence dont les entr\u00e9es sont comprises entre 0 et 100, les donn\u00e9es d’essai utilisant l’analyse de seuil seraient 0 et 100.<\/p>\n\n
Son avantage est qu’il est plus facile et plus rapide de trouver des erreurs car la densit\u00e9 des erreurs aux fronti\u00e8res est plus \u00e9lev\u00e9e.<\/p>\n\n
Tableaux de d\u00e9cision<\/strong><\/p>\n\n
Les tests de table de d\u00e9cision sont utilis\u00e9s pour tester le comportement d’une application en fonction de diff\u00e9rentes combinaisons de valeurs d’entr\u00e9e. La table de d\u00e9cision comporte un ensemble diff\u00e9rent de combinaisons d’entr\u00e9es dans chaque ligne et les r\u00e9sultats escompt\u00e9s correspondants.<\/p>\n\n
Graphique de cause \u00e0 effet<\/strong><\/p>\n\n
Le test du graphique de cause \u00e0 effet est effectu\u00e9 \u00e0 l’aide d’une repr\u00e9sentation graphique de l’entr\u00e9e, \u00e0 savoir j. les causes et les r\u00e9sultats, c’est-\u00e0-dire j. de cons\u00e9quence. Nous pouvons d\u00e9terminer la couverture des graphiques de cause \u00e0 effet en fonction du pourcentage de combinaisons des entr\u00e9es test\u00e9es par rapport au nombre total de combinaisons possibles.<\/p>\n\n
Test de transition d’\u00e9tat<\/strong><\/p>\n\n
Le test des transitions d’\u00e9tat est bas\u00e9 sur un mod\u00e8le de machine d’\u00e9tat. Dans cette technique, nous testons l’application en repr\u00e9sentant graphiquement la transition entre les diff\u00e9rents \u00e9tats de l’application en fonction de diff\u00e9rents \u00e9v\u00e9nements et actions.<\/p>\n\n
Test des cas d’utilisation<\/strong><\/p>\n\n
Le test des cas d’utilisation est un type de test r\u00e9alis\u00e9 \u00e0 l’aide de cas d’utilisation. Dans cette technique, nous testons l’application \u00e0 l’aide de cas d’utilisation qui repr\u00e9sentent l’interaction de l’application avec diff\u00e9rents acteurs.<\/p>\n\n
![\"organigramme](\"https:\/\/ittester.sk\/wp-content\/uploads\/2023\/09\/techniky-testovania-ciernej-skrinky-black-box-testing-1000.webp\")
Tests en bo\u00eete noire <\/figcaption><\/figure>\n\n Comment tester une bo\u00eete noire ?<\/h2>\n\n
Apr\u00e8s vous \u00eatre familiaris\u00e9 avec les techniques de test de la bo\u00eete noire, d\u00e9couvrons les \u00e9tapes d’un test typique de la bo\u00eete noire.<\/p>\n\n
- \n
- La premi\u00e8re \u00e9tape consiste \u00e0 v\u00e9rifier les sp\u00e9cifications des exigences fournies par l’application. Les exigences doivent \u00eatre fournies dans un dossier SRS correctement document\u00e9.<\/li>\n\n\n\n
- Le testeur recueille divers sc\u00e9narios de test positifs et n\u00e9gatifs afin de v\u00e9rifier que le syst\u00e8me test\u00e9 les traite correctement. Cela garantira une bonne couverture des tests. <\/li>\n\n\n\n
- Les cas de test seront ex\u00e9cut\u00e9s et les r\u00e9sultats seront v\u00e9rifi\u00e9s par rapport aux r\u00e9sultats attendus. Ce processus est utilis\u00e9 pour indiquer un r\u00e9sultat de test positif ou n\u00e9gatif.<\/li>\n\n\n\n
- Les cas de test qui ont \u00e9chou\u00e9 sont renvoy\u00e9s \u00e0 l’\u00e9quipe de d\u00e9veloppement pour qu’elle corrige les bogues.<\/li>\n\n\n\n
- Apr\u00e8s la r\u00e9paration, un nouveau test sera effectu\u00e9 pour v\u00e9rifier et s’assurer que tous les cas de test ont \u00e9t\u00e9 ex\u00e9cut\u00e9s avec succ\u00e8s. <\/li>\n<\/ul>\n\n
Avantages des tests en bo\u00eete noire<\/h2>\n\n
- \n
- Les tests sont effectu\u00e9s du point de vue de l’utilisateur. Il y a donc plus de chances que les attentes du client soient satisfaites.<\/li>\n\n\n\n
- Les tests sont objectifs car le testeur et le d\u00e9veloppeur travaillent ind\u00e9pendamment l’un de l’autre.<\/li>\n\n\n\n
- Il convient pour tester de tr\u00e8s grands syst\u00e8mes.<\/li>\n\n\n\n
- Aucune connaissance technique ou linguistique n’est requise.<\/li>\n\n\n\n
- Les cas de test peuvent \u00eatre con\u00e7us d\u00e8s que les exigences sont compl\u00e8tes.<\/li>\n<\/ol>\n\n
Tests \u00ab\u00a0bo\u00eete noire\u00a0\u00bb et tests \u00ab\u00a0bo\u00eete blanche<\/h2>\n\n
La diff\u00e9rence entre les tests bo\u00eete noire et bo\u00eete blanche est l’une des questions les plus fr\u00e9quentes lors des entretiens d’embauche. Les deux sont aussi importants l’un que l’autre et sont mis en \u0153uvre en fonction de la situation. Voici quelques diff\u00e9rences qui clarifient les deux techniques.<\/p>\n\n
Tests en bo\u00eete noire<\/strong><\/th> Tests en bo\u00eete blanche<\/strong><\/th><\/tr><\/thead> La connaissance de la mise en \u0153uvre n’est pas n\u00e9cessaire.<\/td> L’ensemble du fonctionnement interne du SUT (syst\u00e8me sous test) est v\u00e9rifi\u00e9 par un testeur qui a une connaissance compl\u00e8te du syst\u00e8me.<\/td><\/tr> Il se concentre sur la validation des exigences fonctionnelles du logiciel.<\/td> Il se concentre sur l’optimisation du code.<\/td><\/tr> Ces tests sont g\u00e9n\u00e9ralement effectu\u00e9s par des testeurs de logiciels.<\/td> Ces tests sont g\u00e9n\u00e9ralement effectu\u00e9s par les d\u00e9veloppeurs de logiciels, car ils connaissent l’architecture interne et la mise en \u0153uvre de l’application.<\/td><\/tr> Cela prend moins de temps.<\/td> Cela prend relativement plus de temps.<\/td><\/tr> Types – tests fonctionnels, tests non fonctionnels, tests de r\u00e9gression, etc.<\/td> Types de tests en bo\u00eete blanche – tests de cheminement, tests de cycle de boucle, tests de condition, etc.<\/td><\/tr><\/tbody><\/table><\/figure>\n","protected":false},"excerpt":{"rendered":" Les tests bo\u00eete noire sont bas\u00e9s sur la sp\u00e9cification du syst\u00e8me test\u00e9 et ne n\u00e9cessitent pas la connaissance de l’architecture interne et du code de l’application.<\/p>\n","protected":false},"author":8,"featured_media":2900,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[54],"tags":[],"class_list":["post-2898","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\/2898","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=2898"}],"version-history":[{"count":1,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/posts\/2898\/revisions"}],"predecessor-version":[{"id":2901,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/posts\/2898\/revisions\/2901"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/media\/2900"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/media?parent=2898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/categories?post=2898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/tags?post=2898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Vlastnosti testovania \u010diernej skrinky<\/a><\/li>