- \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
Stufen der Pr\u00fcfung<\/h2>\n\n
Die Arten von Softwaretests lassen sich grob in statische Tests und dynamische Tests unterteilen. Beim statischen Testen f\u00fchren wir die entwickelte Softwareanwendung nicht aus, sondern verwenden verschiedene Techniken, um die Anwendung zu testen, wie z. B. – Checks, Zwischentests, informelle und technische \u00dcberpr\u00fcfungen.<\/p>\n\n
Beim dynamischen Testen wird die Softwareanwendung getestet, indem der Code ausgef\u00fchrt und sein dynamisches Verhalten untersucht wird. Dabei werden verschiedene Parameter wie Antwortzeit, CPU-Auslastung, Speichernutzung usw. analysiert. Derzeit umfasst das dynamische Testen verschiedene Testebenen, die mit Unit-Tests beginnen und mit Integrations-, System- und schlie\u00dflich Akzeptanztests fortgesetzt werden.<\/p>\n
\n![\"Prüfung](\"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/wp-content\/uploads\/2023\/08\/dynamicke-testovanie-600-500.webp\")
dynamische Pr\u00fcfung – Stufen<\/figcaption><\/figure>\n<\/div>\n Unit-Testing<\/strong> – Dies ist die erste Ebene des Testens, bei der einzelne Module oder kleinere Bausteine der Anwendung isoliert getestet werden. Dies hat den Vorteil, dass es einfacher ist, ein bestimmtes Modul vollst\u00e4ndig und ersch\u00f6pfend zu testen, da wir uns nur auf kleinere Module konzentrieren. Au\u00dferdem k\u00f6nnen Fehler, die auf dieser Ebene entdeckt werden, schnell und einfach mit weniger Ressourcen korrigiert werden.<\/p>\n\n
Integrationstests<\/strong> – Dies ist die zweite Ebene der Tests, die wir in diesem Artikel behandeln. Sie umfasst die Pr\u00fcfung der integrierten Module als Ganzes sowie deren Zusammenschaltung.<\/p>\n\n
Systemtests<\/strong> – Die dritte Teststufe, bei der die gesamte Anwendung von Anfang bis Ende getestet wird. Es hilft bei der \u00dcberpr\u00fcfung der Anforderungen vor der endg\u00fcltigen Pr\u00fcfung durch den Kunden.<\/p>\n\n
Abnahmetests<\/strong> – Dies ist die vierte und letzte Teststufe, bei der der Kunde oder die Interessenvertreter pr\u00fcfen, ob die Anwendung ihren gesch\u00e4ftlichen Anforderungen entspricht oder nicht.<\/p>\n\n
Da wir nun \u00fcber statische und dynamische Tests und die verschiedenen Teststufen Bescheid wissen, k\u00f6nnen wir uns nun mit den Integrationstests im Detail besch\u00e4ftigen.<\/p>\n\n
Was sind Integrationstests?<\/h2>\n\n
Integrationstests sind die zweite Testebene nach den Unit-Tests, bei denen wir neben den integrierten Komponenten auch die Verbindung zwischen den Modulen testen. Sie kann sowohl mit White-Box- als auch mit Black-Box-Testverfahren durchgef\u00fchrt werden.<\/p>\n\n
Warum sollten wir Integrationstests durchf\u00fchren?<\/h2>\n\n
- \n
- Ein Modul kann isoliert gut funktionieren, aber bei der Interaktion mit einem anderen Modul k\u00f6nnen Integrationsprobleme auftreten. <\/li>\n\n\n\n
- Es kann Probleme mit dem Datentyp oder dem g\u00fcltigen Datenbereich zwischen Modulen geben. <\/li>\n\n\n\n
- In gro\u00dfen Teams, in denen Module von verschiedenen Entwicklern oder sogar Teams erstellt werden, ist dies sehr wichtig, da das Verst\u00e4ndnis der verschiedenen Entwickler nicht \u00fcbereinstimmen kann.<\/li>\n<\/ul>\n\n
Vorteile von Integrationstests<\/h2>\n\n
- \n
- Wie bereits erw\u00e4hnt, hilft es bei der Identifizierung von Integrationsproblemen zwischen Modulen. <\/li>\n\n\n\n
- So kann sichergestellt werden, dass die integrierten Module ordnungsgem\u00e4\u00df funktionieren, bevor man zum systemweiten Testen der Anwendung \u00fcbergeht. <\/li>\n\n\n\n
- Fehler, die auf dieser Ebene gefunden werden, sind leichter zu beheben als Fehler, die in sp\u00e4teren Testphasen – System- und Akzeptanztests – gefunden werden.<\/li>\n\n\n\n
- Sie verbessert die Testabdeckung und bietet ein zus\u00e4tzliches Ma\u00df an Zuverl\u00e4ssigkeit.<\/li>\n<\/ul>\n\n
Arten von Integrationstests<\/h2>\n\n
Wir kennen 4 Arten:<\/p>\n\n
Urknall-Integration<\/h2>\n\n
Bei einer gro\u00dfen Integration m\u00fcssen zun\u00e4chst alle Module fertiggestellt und dann integriert werden. Nach der Integration erfolgt die Pr\u00fcfung der integrierten Einheit als Ganzes. Sie unterscheidet sich von der Systempr\u00fcfung, da sich die Pr\u00fcfung hier auf die Verbindung\/Kommunikation zwischen den Modulen konzentriert.<\/p>\n\n
Vorteil<\/strong> – Es eignet sich f\u00fcr kleinere Projekte, bei denen alle Module vor Beginn der Integrationstests entwickelt werden k\u00f6nnen.<\/p>\n\n
Nachteil<\/strong> – Die Integration ist sehr schwierig, da es weder praktisch noch bequem ist, alle Module vor Beginn der Integrationstests fertig zu haben.<\/p>\n\n
Top-down-Integrationstests<\/h2>\n\n
Die Top-Down-Integration ist ein inkrementeller Ansatz f\u00fcr Integrationstests, bei dem der Testfluss von den Top-Level-Modulen (Module, die in der Hierarchie h\u00f6her stehen) zu den Modulen der unteren Ebene f\u00fchrt. Da es sehr wahrscheinlich ist, dass die Module der unteren Ebene nicht entwickelt werden, bevor die Module der oberen Ebene gestartet werden, werden in solchen F\u00e4llen Plugins (Stubs) verwendet.<\/p>\n\n
Proxy-Module sind Dummy-Module, die den Betrieb eines Moduls simulieren, indem sie die vom Modul empfangenen Parameter akzeptieren und ein akzeptables Ergebnis liefern. Im Allgemeinen haben Stubs fest kodierte Ein- und Ausgaben, die beim Testen anderer Module, die mit ihnen integriert sind, helfen.<\/p>\n\n
Vorteil<\/strong> – Durch die Verwendung von Stubs m\u00fcssen wir nicht auf die Entwicklung aller Module warten. Wir k\u00f6nnen auch dem Testen kritischer integrierter Module Vorrang einr\u00e4umen.<\/p>\n\n
Nachteil<\/strong> – Diese Technik erfordert die Erstellung vieler untergeordneter Module, um Module auf niedrigerer Ebene zu simulieren. Es kann auch vorkommen, dass Module der unteren Ebene nicht ausreichend getestet werden.<\/p>\n\n
Bottom-up-Integrationstests<\/h2>\n\n
Die Bottom-up-Integration basiert ebenfalls auf einem inkrementellen Ansatz, der von Modulen der unteren Ebene ausgeht und sich zu Modulen der oberen Ebene hocharbeitet. Auch hier ist es m\u00f6glich, dass die Module der h\u00f6heren Ebene nicht zu dem Zeitpunkt entwickelt werden, zu dem die Module der unteren Ebene getestet werden. In diesen F\u00e4llen werden Treiber eingesetzt. Diese Treiber simulieren die Funktionalit\u00e4t von Modulen h\u00f6herer Ebenen, um Module niedrigerer Ebenen zu testen.<\/p>\n\n
Vorteil<\/strong> – \u00e4hnlich wie beim Top-down-Testing m\u00fcssen wir nicht warten, bis alle Module entwickelt sind, bevor wir mit dem Testen beginnen.<\/p>\n\n
Nachteil<\/strong> – Top-Level-Module, die in sp\u00e4teren Phasen getestet werden, sind m\u00f6glicherweise nicht ausreichend getestet und k\u00f6nnen Fehler enthalten.<\/p>\n\n
Hybride Integrationstests<\/h2>\n\n
Der hybride Integrationsansatz wird auch als Sandwich-Ansatz bezeichnet. Dieser Ansatz ist eine Kombination aus Top-down- und Bottom-up-Integrationstests. Bei diesem Ansatz beginnt die Integration in der mittleren Schicht, und die Tests werden in beide Richtungen durchgef\u00fchrt – zu den Modulen der h\u00f6heren Ebene (aufw\u00e4rts) und zu den Modulen der unteren Ebene (abw\u00e4rts). Diese Methode vereint die Vorteile von Top-down- und Bottom-up-Ans\u00e4tzen und erm\u00f6glicht eine schnellere Pr\u00fcfung von Modulschnittstellen.<\/p>\n\n
Vorteil<\/strong> – Da wir uns nach oben und unten bewegen k\u00f6nnen, ist dies die zeitsparendste Methode mit der M\u00f6glichkeit, Module auf der obersten oder untersten Ebene zu priorisieren.<\/p>\n\n
Nachteil <\/strong>– dieser Ansatz ist schwierig zu implementieren, da wir das zu pr\u00fcfende Modul integrieren und in beide Richtungen bewegen m\u00fcssen.<\/p>\n\n
Herausforderungen bei Integrationstests<\/strong><\/p>\n\n
- \n
- Schwierig auszuf\u00fchren<\/strong> – im Vergleich zu Systemtests, bei denen wir die Anwendung als Blackbox betrachten k\u00f6nnen, ist es sehr schwierig, sie durchzuf\u00fchren.<\/li>\n\n\n\n
- Zeitaufwendig<\/strong> – Das Testen aller Verbindungen zwischen den verschiedenen verkn\u00fcpften Modulen ist sehr zeit- und ressourcenaufwendig.<\/li>\n\n\n\n
- Zus\u00e4tzlicher Aufwand<\/strong> – Erfordert die Erstellung von Untergruppen und Treibern, die, wenn sie nicht korrekt erstellt werden, zu unzureichenden Tests f\u00fchren k\u00f6nnen.<\/li>\n<\/ul>\n\n
Werkzeuge f\u00fcr Integrationstests<\/h2>\n\n
Rational Integration Tester<\/strong> – Rational Integration Tester ist ein Integrationstestwerkzeug von IBM. Es bietet eine codierungsfreie Umgebung f\u00fcr die Entwicklung von Integrationstests.<\/p>\n\n
TESSY<\/strong> – Tessy von Razorcat Development GmbH hilft bei der Automatisierung des Unit- und Integrationstestzyklus f\u00fcr eingebettete Software in C und C++.<\/p>\n\n
LDRA <\/strong>– Das LDRA-Toolpaket bietet Funktionen f\u00fcr Unit-, Integrations- und Systemtests. Es wird meist f\u00fcr kritische Softwareanwendungen wie Luft- und Raumfahrt, medizinische Ger\u00e4te, Automobilbau usw. verwendet.<\/p>\n\n
Protractor<\/strong> – Protractor ist ein Open-Source-Testframework f\u00fcr Angular- und AngularJS-Anwendungen, das Javascript-Skripting unterst\u00fctzt.<\/p>\n\n
Citrus Integration Testing<\/strong> – Citrus ist ein Open-Source-Testframework, das bei der Entwicklung automatisierter Integrationstests f\u00fcr HTTP REST, TCP\/IP, SOAP, FTP, XML, JSON usw. Protokolle und Nachrichtenformate hilft.<\/p>\n\n
Steam <\/strong>– Steam ist ein Open-Source-Framework zur Testautomatisierung, das Integrationstests ohne Kopfh\u00f6rer erm\u00f6glicht.<\/p>\n\n
Jasmine <\/strong>– Jasmine ist ein Open-Source-BDD-Framework, das zur Automatisierung jeder Javascript-basierten Anwendung verwendet werden kann.<\/p>\n","protected":false},"excerpt":{"rendered":"
Traditionell wurde das Testen von Software als eine M\u00f6glichkeit angesehen, Fehler zu finden, sobald ein […]<\/p>\n","protected":false},"author":8,"featured_media":1396,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[18],"tags":[],"class_list":["post-377","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-manuelles-testen"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/posts\/377","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/comments?post=377"}],"version-history":[{"count":7,"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/posts\/377\/revisions"}],"predecessor-version":[{"id":1398,"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/posts\/377\/revisions\/1398"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/media\/1396"}],"wp:attachment":[{"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/media?parent=377"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/categories?post=377"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/staging-msg-ittester-sk.rucolabs.sk\/de\/wp-json\/wp\/v2\/tags?post=377"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Zeitaufwendig<\/strong> – Das Testen aller Verbindungen zwischen den verschiedenen verkn\u00fcpften Modulen ist sehr zeit- und ressourcenaufwendig.<\/li>\n\n\n\n
- Schwierig auszuf\u00fchren<\/strong> – im Vergleich zu Systemtests, bei denen wir die Anwendung als Blackbox betrachten k\u00f6nnen, ist es sehr schwierig, sie durchzuf\u00fchren.<\/li>\n\n\n\n
- \u010co je integra\u010dn\u00e9 testovanie?<\/a><\/li>