- \u00darovne testovania<\/a><\/li>
- \u010co je integra\u010dn\u00e9 testovanie?<\/a><\/li>
- Pre\u010do by sme mali vykon\u00e1va\u0165 integra\u010dn\u00e9 testovanie?<\/a><\/li>
- V\u00fdhody integra\u010dn\u00e9ho testovania<\/a><\/li>
- Typy integra\u010dn\u00e9ho testovania<\/a><\/li>
- Big-bang integr\u00e1cia<\/a><\/li>
- Integra\u010dn\u00e9 testovanie zhora nadol (top-down integration testing)<\/a><\/li>
- Integra\u010dn\u00e9 testovanie zdola nahor (bottom-up integration testing)<\/a><\/li>
- Hybridn\u00e9 integra\u010dn\u00e9 testovanie<\/a><\/li>
- N\u00e1stroje na testovanie integr\u00e1cie<\/a><\/li><\/ul><\/div>\n
Niveaux de test<\/h2>\n\n
Les types de tests de logiciels peuvent \u00eatre divis\u00e9s en deux grandes cat\u00e9gories : les tests statiques et les tests dynamiques. Dans le cas des tests statiques, nous n’ex\u00e9cutons pas l’application logicielle d\u00e9velopp\u00e9e, mais nous utilisons diverses techniques pour tester l’application, telles que les v\u00e9rifications, les tests interm\u00e9diaires, les examens informels et techniques.<\/p>\n\n
Dans le cas des tests dynamiques, nous testons l’application logicielle en ex\u00e9cutant le code et en examinant son comportement dynamique, ce qui implique l’analyse de divers param\u00e8tres tels que le temps de r\u00e9ponse, l’utilisation de l’unit\u00e9 centrale, l’utilisation de la m\u00e9moire, etc. Actuellement, les tests dynamiques impliquent diff\u00e9rents niveaux de tests qui commencent par des tests unitaires et se poursuivent par des tests d’int\u00e9gration, de syst\u00e8me et enfin d’acceptation.<\/p>\n
\n![\"l'essai](\"https:\/\/ittester.sk\/wp-content\/uploads\/2023\/08\/dynamicke-testovanie-600-500.webp\")
essais dynamiques – niveaux<\/figcaption><\/figure>\n<\/div>\n Tests unitaires<\/strong> – Il s’agit du premier niveau de test o\u00f9 des modules individuels ou de plus petits blocs de construction de l’application sont test\u00e9s de mani\u00e8re isol\u00e9e. L’avantage est que, comme nous ne nous concentrons que sur des modules plus petits, il est plus facile de tester compl\u00e8tement et exhaustivement un module donn\u00e9. En outre, les erreurs d\u00e9tect\u00e9es \u00e0 ce niveau peuvent \u00eatre corrig\u00e9es rapidement et facilement avec moins de ressources.<\/p>\n\n
Tests d’int\u00e9gration<\/strong> – Il s’agit du deuxi\u00e8me niveau de tests que nous allons aborder dans cet article. Il comprend l’essai des modules int\u00e9gr\u00e9s dans leur ensemble et de leur interconnexion.<\/p>\n\n
Test du syst\u00e8me<\/strong> – Le troisi\u00e8me niveau de test consiste \u00e0 tester l’ensemble de l’application de bout en bout. Il permet de v\u00e9rifier les exigences avant le test final par le client.<\/p>\n\n
Test d’acceptation<\/strong> – Il s’agit du quatri\u00e8me et dernier niveau de test, au cours duquel le client ou les parties prenantes v\u00e9rifient si l’application r\u00e9pond ou non \u00e0 leurs exigences professionnelles.<\/p>\n\n
Maintenant que nous connaissons les tests statiques et dynamiques et les diff\u00e9rents niveaux de test, nous pouvons passer \u00e0 l’apprentissage d\u00e9taill\u00e9 des tests d’int\u00e9gration.<\/p>\n\n
Qu’est-ce qu’un test d’int\u00e9gration ?<\/h2>\n\n
Le test d’int\u00e9gration est le deuxi\u00e8me niveau de test effectu\u00e9 apr\u00e8s le test unitaire, dans lequel nous testons l’interconnexion entre les modules en m\u00eame temps que les composants int\u00e9gr\u00e9s. Il peut \u00eatre r\u00e9alis\u00e9 \u00e0 l’aide de techniques de test bo\u00eete blanche et bo\u00eete noire.<\/p>\n\n
Pourquoi effectuer des tests d’int\u00e9gration ?<\/h2>\n\n
- \n
- Un module peut fonctionner parfaitement de mani\u00e8re isol\u00e9e, mais peut rencontrer des probl\u00e8mes d’int\u00e9gration lorsqu’il interagit avec un autre module. <\/li>\n\n\n\n
- Il peut y avoir des probl\u00e8mes de type de donn\u00e9es ou de plage de donn\u00e9es valides entre les modules. <\/li>\n\n\n\n
- Dans les grandes \u00e9quipes o\u00f9 les modules sont cr\u00e9\u00e9s par diff\u00e9rents d\u00e9veloppeurs ou m\u00eame par des \u00e9quipes, cela est tr\u00e8s n\u00e9cessaire car il peut y avoir un d\u00e9calage dans la compr\u00e9hension des diff\u00e9rents d\u00e9veloppeurs.<\/li>\n<\/ul>\n\n
Avantages des tests d’int\u00e9gration<\/h2>\n\n
- \n
- Comme indiqu\u00e9 plus haut, il permet d’identifier les probl\u00e8mes d’int\u00e9gration entre les modules. <\/li>\n\n\n\n
- Il permet de s’assurer que les modules int\u00e9gr\u00e9s fonctionnent correctement avant de passer aux tests de l’application \u00e0 l’\u00e9chelle du syst\u00e8me. <\/li>\n\n\n\n
- Les bogues trouv\u00e9s \u00e0 ce niveau sont plus faciles \u00e0 r\u00e9soudre que les bogues trouv\u00e9s dans les \u00e9tapes ult\u00e9rieures des tests – tests du syst\u00e8me et tests d’acceptation.<\/li>\n\n\n\n
- Il am\u00e9liore la couverture des tests et offre un niveau de fiabilit\u00e9 suppl\u00e9mentaire.<\/li>\n<\/ul>\n\n
Types de tests d’int\u00e9gration<\/h2>\n\n
nous en connaissons 4 types :<\/p>\n\n
L’int\u00e9gration du big-bang<\/h2>\n\n
Dans le cas d’une int\u00e9gration de grande envergure, tous les modules doivent d’abord \u00eatre compl\u00e9t\u00e9s, puis int\u00e9gr\u00e9s. Apr\u00e8s l’int\u00e9gration, l’unit\u00e9 int\u00e9gr\u00e9e dans son ensemble est test\u00e9e. Il diff\u00e8re du test du syst\u00e8me car il se concentre sur l’interconnexion\/communication entre les modules.<\/p>\n\n
Avantage<\/strong> – Elle convient aux projets de moindre envergure, pour lesquels tous les modules peuvent \u00eatre d\u00e9velopp\u00e9s avant le d\u00e9but des tests d’int\u00e9gration.<\/p>\n\n
Inconv\u00e9nient<\/strong> – Il est tr\u00e8s difficile de l’int\u00e9grer car il n’est pas pratique ou commode d’avoir tous les modules pr\u00eats avant de commencer les tests d’int\u00e9gration.<\/p>\n\n
Test d’int\u00e9gration descendant<\/h2>\n\n
L’int\u00e9gration descendante est une approche de test d’int\u00e9gration incr\u00e9mentale dans laquelle le flux de test part des modules de haut niveau (modules les plus \u00e9lev\u00e9s dans la hi\u00e9rarchie) vers les modules de niveau inf\u00e9rieur. Comme il est tr\u00e8s probable que les modules de niveau inf\u00e9rieur ne soient pas d\u00e9velopp\u00e9s avant que les modules de niveau sup\u00e9rieur ne soient lanc\u00e9s, des plugins (stubs) sont utilis\u00e9s dans ce cas.<\/p>\n\n
Les modules proxy sont des modules fictifs qui simulent le fonctionnement d’un module en acceptant les param\u00e8tres re\u00e7us par le module et en fournissant un r\u00e9sultat acceptable. En g\u00e9n\u00e9ral, les stubs ont des entr\u00e9es et des sorties cod\u00e9es en dur qui permettent de tester les autres modules qui y sont int\u00e9gr\u00e9s.<\/p>\n\n
Avantage<\/strong> – Avec l’utilisation des stubs, nous ne devons pas attendre le d\u00e9veloppement de tous les modules. Nous pouvons \u00e9galement donner la priorit\u00e9 aux tests des modules int\u00e9gr\u00e9s critiques.<\/p>\n\n
Inconv\u00e9nient<\/strong> – Cette technique n\u00e9cessite la cr\u00e9ation de nombreux modules enfants pour simuler les modules de niveau inf\u00e9rieur. Il peut \u00e9galement arriver que les modules de niveau inf\u00e9rieur ne soient pas suffisamment test\u00e9s.<\/p>\n\n
Tests d’int\u00e9gration ascendants<\/h2>\n\n
L’int\u00e9gration ascendante est \u00e9galement bas\u00e9e sur une approche incr\u00e9mentale, partant des modules de niveau inf\u00e9rieur pour aller vers les modules de niveau sup\u00e9rieur. L\u00e0 encore, les modules de niveau sup\u00e9rieur peuvent ne pas \u00eatre d\u00e9velopp\u00e9s au moment o\u00f9 les modules de niveau inf\u00e9rieur sont test\u00e9s. Dans ce cas, des pilotes sont utilis\u00e9s. Ces pilotes simulent la fonctionnalit\u00e9 des modules de niveau sup\u00e9rieur pour tester les modules de niveau inf\u00e9rieur.<\/p>\n\n
Avantage<\/strong>: comme pour les tests descendants, il n’est pas n\u00e9cessaire d’attendre que tous les modules soient d\u00e9velopp\u00e9s avant de commencer les tests.<\/p>\n\n
Inconv\u00e9nient<\/strong> – Les modules de haut niveau qui sont test\u00e9s \u00e0 des stades ult\u00e9rieurs peuvent ne pas \u00eatre suffisamment test\u00e9s et contenir des bogues.<\/p>\n\n
Test d’int\u00e9gration hybride<\/h2>\n\n
L’approche d’int\u00e9gration hybride est \u00e9galement appel\u00e9e approche sandwich. Cette approche est une combinaison de tests d’int\u00e9gration descendants et ascendants. Dans cette approche, l’int\u00e9gration commence par la couche interm\u00e9diaire et les tests sont effectu\u00e9s dans les deux sens – vers les modules de niveau sup\u00e9rieur (vers le haut) et vers les modules de niveau inf\u00e9rieur (vers le bas). Cette m\u00e9thode int\u00e8gre les avantages des approches descendante et ascendante et permet de tester plus rapidement les interfaces des modules.<\/p>\n\n
Avantage<\/strong> – Puisque nous pouvons aller de haut en bas, c’est la m\u00e9thode la plus efficace en termes de temps, avec la possibilit\u00e9 de prioriser les modules au niveau sup\u00e9rieur ou inf\u00e9rieur.<\/p>\n\n
Inconv\u00e9nient <\/strong>– cette approche est difficile \u00e0 mettre en \u0153uvre car il faut int\u00e9grer et d\u00e9placer dans les deux sens le module test\u00e9.<\/p>\n\n
D\u00e9fis li\u00e9s aux tests d’int\u00e9gration<\/strong><\/p>\n\n
- \n
- Difficile \u00e0 ex\u00e9cuter<\/strong> – il est tr\u00e8s difficile \u00e0 ex\u00e9cuter par rapport aux tests de syst\u00e8mes, o\u00f9 l’on peut consid\u00e9rer l’application comme une bo\u00eete noire.<\/li>\n\n\n\n
- Consommation de temps<\/strong> – Le test de toutes les interconnexions entre les diff\u00e9rents modules li\u00e9s prend beaucoup de temps et de ressources.<\/li>\n\n\n\n
- Effort suppl\u00e9mentaire<\/strong> – N\u00e9cessite la cr\u00e9ation de sous-groupes et de pilotes qui, s’ils ne sont pas cr\u00e9\u00e9s correctement, peuvent donner lieu \u00e0 des tests inad\u00e9quats.<\/li>\n<\/ul>\n\n
Outils de test d’int\u00e9gration<\/h2>\n\n
Rational Integration Tester<\/strong> – Rational Integration Tester est un outil de test d’int\u00e9gration d’IBM. Il fournit un environnement sans code pour d\u00e9velopper des tests d’int\u00e9gration.<\/p>\n\n
TESSY<\/strong> – Tessy de Razorcat Development GmbH permet d’automatiser le cycle de test unitaire et d’int\u00e9gration des logiciels embarqu\u00e9s en C et C++.<\/p>\n\n
LDRA <\/strong>– La suite d’outils LDRA permet d’effectuer des tests unitaires, d’int\u00e9gration et de syst\u00e8me. Il est principalement utilis\u00e9 pour des applications logicielles critiques telles que l’a\u00e9rospatiale, les appareils m\u00e9dicaux, l’automobile, etc.<\/p>\n\n
Protractor<\/strong> – Protractor est un framework de test open-source pour les applications Angular et AngularJS supportant les scripts Javascript.<\/p>\n\n
Citrus Integration Testing<\/strong> – Citrus est un cadre de test open-source qui aide \u00e0 d\u00e9velopper des tests d’int\u00e9gration automatis\u00e9s pour les protocoles et formats de messages HTTP REST, TCP\/IP, SOAP, FTP, XML, JSON, etc.<\/p>\n\n
Steam <\/strong>– Steam est un cadre d’automatisation des tests open-source qui permet de r\u00e9aliser des tests d’int\u00e9gration sans t\u00eate.<\/p>\n\n
Jasmine <\/strong>– Jasmine est un framework BDD open-source qui peut \u00eatre utilis\u00e9 pour automatiser n’importe quelle application bas\u00e9e sur Javascript.<\/p>\n","protected":false},"excerpt":{"rendered":"
Traditionnellement, les tests de logiciels sont consid\u00e9r\u00e9s comme un moyen de trouver des bogues une […]<\/p>\n","protected":false},"author":8,"featured_media":2876,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[54],"tags":[],"class_list":["post-2874","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\/2874","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=2874"}],"version-history":[{"count":1,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/posts\/2874\/revisions"}],"predecessor-version":[{"id":2879,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/posts\/2874\/revisions\/2879"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/media\/2876"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/media?parent=2874"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/categories?post=2874"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/fr\/wp-json\/wp\/v2\/tags?post=2874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Consommation de temps<\/strong> – Le test de toutes les interconnexions entre les diff\u00e9rents modules li\u00e9s prend beaucoup de temps et de ressources.<\/li>\n\n\n\n
- Difficile \u00e0 ex\u00e9cuter<\/strong> – il est tr\u00e8s difficile \u00e0 ex\u00e9cuter par rapport aux tests de syst\u00e8mes, o\u00f9 l’on peut consid\u00e9rer l’application comme une bo\u00eete noire.<\/li>\n\n\n\n
- \u010co je integra\u010dn\u00e9 testovanie?<\/a><\/li>