Was ist SOA-Test? Tutorial mit Beispiel
Thomas Hamilton
โก Intelligente Zusammenfassung
SOA-Tests validieren eine serviceorientierte ArchiEine Architektur, in der lose gekoppelte Dienste Nachrichten รผber ein Netzwerk austauschen und dabei jeden Dienst einzeln, die Integrationen zwischen ihnen und den gesamten Geschรคftsablauf von Anfang bis Ende รผberprรผfen.
Was ist SOA-Test?
SOA (Serviceorientiert). Architektur) Testen ist das Testen des SOA-Architekturstils, bei dem die Anwendungskomponenten so konzipiert sind, dass sie รผber Kommunikationsprotokolle, typischerweise รผber ein Netzwerk, miteinander kommunizieren.
Was ist SOA?
SOA ist eine Methode zur Integration von Geschรคftsanwendungen und -prozessen, um den Geschรคftsanforderungen gerecht zu werden.
In Software EngineeringSOA bietet Agilitรคt und Flexibilitรคt fรผr Geschรคftsprozesse. รnderungen an einem Prozess oder einer Anwendung kรถnnen gezielt auf eine bestimmte Komponente ausgerichtet werden, ohne das Gesamtsystem zu beeintrรคchtigen.
Softwareentwickler, die im SOA-Bereich arbeiten, entwickeln entweder eigene Programmbausteine โโoder kaufen diese zu. Leistungen.
Was ist Dienst?
Das untenstehende Diagramm zeigt ein Zahlungsgateway, das als Dienst verรถffentlicht wurde und von mehreren E-Commerce-Websites aufgerufen werden kann.
- Ein Dienst kann eine funktionale Einheit einer Anwendung oder eines Geschรคftsprozesses sein, die von jeder anderen Anwendung oder jedem anderen Prozess wiederverwendet oder wiederholt werden kann. (Beispielsweise ist im obigen Bild das Zahlungsgateway ein Dienst, der von jeder E-Commerce-Website wiederverwendet werden kann. Immer wenn eine Zahlung erforderlich ist, ruft die E-Commerce-Website den Zahlungsgateway-Dienst auf. Nachdem die Zahlung รผber das Gateway abgeschlossen wurde, wird eine Antwort an die E-Commerce-Website zurรผckgesendet.)
- Die Dienstleistungen sind einfach zu montieren und die Komponenten lassen sich leicht neu konfigurieren.
- Dienstleistungen lassen sich mit Bausteinen vergleichen. Sie kรถnnen jede benรถtigte Anwendung erstellen, und das Hinzufรผgen oder Entfernen von ihnen aus der Anwendung oder dem Geschรคftsprozess ist einfach.
- Dienstleistungen werden eher durch die von ihnen ausgefรผhrte Geschรคftsfunktion definiert als durch Codeblรถcke.
Web Services
Die meisten SOA-Dienste werden als Webdienste bereitgestellt, daher ist es sinnvoll, die Mechanismen eines Webdienstaufrufs vor den Testschichten festzulegen.
Web-Services Es handelt sich um unabhรคngige Anwendungskomponenten, die รผber das Internet verfรผgbar sind.
Sie kรถnnen im Web verรถffentlicht, gefunden und genutzt werden und kommunizieren รผber das Internet. Die folgende Abfolge zeigt die Interaktion zwischen Anbieter, Register und Nutzer.
- Der Dienstanbieter verรถffentlicht den Dienst im Internet.
- Der Client sucht in der Webdienstregistrierung nach einem bestimmten Webdienst.
- A URL und der wsdl Die benรถtigten Webdienste werden zurรผckgegeben. Verwendung der WSDL und der URLDie Kommunikation zwischen Dienstanbieter und Anfragendem erfolgt รผber SOAP-Nachrichten.
- Wenn ein Verbraucher einen Webdienst aufruft, wird eine HTTP-Verbindung zum Anbieter hergestellt.
- Es wird eine SOAP-Nachricht erstellt, um den Provider anzuweisen, die erforderliche Webdienstlogik aufzurufen.
- Die vom Anbieter empfangene Antwort ist eine SOAP-Nachricht, die in die HTTP-Antwort eingebettet ist. Diese HTTP-Antwort stellt das Datenformat dar, das von der Verbraucheranwendung verstanden werden kann.
Beispiel
Der untenstehende Screenshot zeigt einen Wetterbericht, der von einem externen Dienst bereitgestellt und in die Startseite einer Suchmaschine eingebettet ist.
Die Startseite einer Website und eine Suchmaschine zeigen einen tรคglichen Wetterbericht an. Anstatt den Wetterberichtbereich von Grund auf neu zu programmieren, kann ein Wetterberichtdienst von einem Anbieter erworben und in die Seiten integriert werden.
SOA-Testschichten
SOA besteht aus verschiedenen Technologien, und Anwendungen, die mit SOA entwickelt wurden, verfรผgen รผber verschiedene, lose gekoppelte Dienste. Das folgende Diagramm veranschaulicht die drei Ebenen, die ein Testplan abdecken muss.
Beim SOA-Testing sollten sich die Tests auf drei Systemebenen konzentrieren.
Diensteschicht
Diese Schicht besteht aus den von einem System bereitgestellten Diensten, die sich aus Geschรคftsfunktionen ableiten.
Nehmen wir beispielsweise eine Wellness-Website, die aus Folgendem besteht:
- Gewicht Tracker
- Blutzucker Tracker
- Ausgleich bei Blutdruckschwankungen Tracker
TracDie KERS zeigen die jeweiligen Daten und das Datum ihrer Eingabe an. Die Dienstschicht besteht aus den Diensten, die die jeweiligen Daten aus der Datenbank abrufen:
- Gewicht TracKer-Service
- Blutzucker TracKer-Service
- Ausgleich bei Blutdruckschwankungen TracKer-Service
- Anmeldedienst
Prozessschicht
Die Prozessschicht besteht aus den Prozessen, der Sammlung von Diensten, die Teil einer einzelnen Funktionalitรคt sind.
Die Prozesse kรถnnen Teil einer Benutzeroberflรคche (z. B. einer Suchmaschine) oder Teil eines ETL-Tools sein, das Daten aus der Datenbank abruft.
Der Schwerpunkt dieser Ebene liegt auf Benutzeroberflรคchen und Prozessen. Die Benutzeroberflรคche der Gewichtung tracDer Schwerpunkt liegt auf ker und dessen Integration in die Datenbank.
Folgende Funktionen sind zu berรผcksichtigen:
- Hinzufรผgen neuer Daten
- Bearbeiten vorhandener Daten
- Ein neues erstellen tracker
- Lรถschen von Daten
Verbraucherschicht
Diese Ebene besteht hauptsรคchlich aus Benutzerschnittstellen, wie die folgende Abbildung zeigt.
Auf Grundlage dieser Schichten ist das Testen einer SOA-Anwendung in drei Ebenen unterteilt:
- Service Level
- Schnittstellenebene
- End-to-End-Level
Die beiden Vorgehensweisen unterscheiden sich: Fรผr die Testplanung wird ein Top-Down-Ansatz verwendet, fรผr die Testdurchfรผhrung hingegen ein Bottom-Up-Ansatz.
Strategie fรผr SOA-Tests
Testplanungsansatz
- Die SOA-Tester sollten die gesamte Architektur der Anwendung verstehen.
- Die Anwendung muss in unabhรคngige Dienste aufgeteilt werden (ein Dienst, der รผber eine eigene Anfrage- und Antwortstruktur verfรผgt und nicht von einem anderen Dienst abhรคngig ist, um eine Antwort zu bilden).
- Die Anwendungsstruktur muss in drei Komponenten neu organisiert werden โ Daten, Dienste und Frontend-Anwendungen.
- Alle Komponenten mรผssen sorgfรคltig analysiert und Geschรคftsszenarien ausgearbeitet werden.
- Die Geschรคftsszenarien sollten in allgemeine Szenarien und anwendungsspezifische Szenarien unterteilt werden.
- A Rรผckverfolgbarkeitsmatrix sollte vorbereitet sein, und alle Testfรคlle sollten sein tracauf Geschรคftsszenarien angewendet.
Testausfรผhrungsansatz
- Jede Servicekomponente sollte getestet werden.
- Integrationstests Die รberprรผfung der Servicekomponenten sollte durchgefรผhrt werden, um den Datenfluss durch die Services und die Datenintegritรคt zu validieren.
- Systemtest Das vollstรคndige Modell sollte erstellt werden, um den Datenfluss zwischen der Frontend-Anwendung und der Datenbank zu validieren.
- Performance Testing Dies sollte fรผr eine Feinabstimmung und optimale Leistung erfolgen.
SOA-Testmethoden
1) Geschรคftsszenario-gesteuerte datenbasierte Tests
- Es sollten verschiedene betriebswirtschaftliche Aspekte des Systems analysiert werden.
- Szenarien sollten auf der Grundlage der Integration der verschiedenen Webdienste der Anwendung und der Webdienste mit der Anwendung entwickelt werden.
- Die Dateneinrichtung sollte auf der Grundlage der oben genannten Szenarien erfolgen.
- Die Dateneinrichtung sollte auch End-to-End-Szenarien abdecken.
2) Stubs
- Dummy-Schnittstellen werden erstellt, um Dienste zu testen.
- รber diese Schnittstellen kรถnnen verschiedene Eingaben bereitgestellt und die Ausgaben validiert werden.
- Wenn eine Anwendung eine Schnittstelle zu einem externen Dienst nutzt, der nicht getestet wird (ein Drittanbieterdienst), kann wรคhrend des Integrationstests ein Stub erstellt werden.
3) Regressionstests
- Regressionstests Die Anwendung sollte bei mehreren Releases aktualisiert werden, um die Stabilitรคt und Verfรผgbarkeit der Systeme zu gewรคhrleisten.
- Es wird eine umfassende Regressionstestsuite erstellt, die die Dienste abdeckt, die einen wichtigen Teil der Anwendung bilden.
- Diese Testsuite kann รผber mehrere Releases des Projekts hinweg wiederverwendet werden.
4) Service-Level-Tests
Die Service-Level-Tests umfassen die Prรผfung der Komponente auf Funktionalitรคt, Sicherheit, Leistung und Interoperabilitรคt. Jeder einzelne Service muss zunรคchst unabhรคngig getestet werden.
5) Funktionsprรผfung
Funktionsprรผfung sollte bei jedem Service durchgefรผhrt werden, um:
- Stellen Sie sicher, dass der Dienst auf jede Anfrage die richtige Antwort liefert.
- Stellen Sie sicher, dass die richtigen Fehlermeldungen fรผr Anfragen mit ungรผltigen oder fehlerhaften Daten empfangen werden.
- Prรผfen Sie jede Anfrage und Antwort fรผr jede Operation, die der Dienst zur Laufzeit ausfรผhren muss.
- รberprรผfen Sie die Fehlermeldungen, wenn ein Fehler auf Server-, Client- oder Netzwerkebene auftritt.
- รberprรผfen Sie, ob die empfangenen Antworten das richtige Format haben.
- Prรผfen Sie, ob die in der Antwort empfangenen Daten den angeforderten Daten entsprechen.
6) Sicherheitstests
Die Sicherheitsprรผfung des Webdienstes ist ein wichtiger Aspekt bei der Prรผfung der Serviceebene der SOA-Anwendung, da sie die Sicherheit der Anwendung gewรคhrleistet.
Folgende Faktoren mรผssen beim Testen berรผcksichtigt werden:
- Der von WS-Security definierte Branchenstandard sollte vom Webdienst eingehalten werden.
- Sicherheitsmaรnahmen sollten einwandfrei funktionieren.
- Datenverschlรผsselung und digitale Signaturen auf den Dokumenten.
- Authentifizierung und Autorisierung.
- SQL-Injection, Malware, XSS, CSRF und andere Schwachstellen sollen auf dem System getestet werden. XML.
- Denial-of-Service-Angriffe.
7) Leistungstests
Die Leistungsfรคhigkeit des Dienstes muss getestet werden, da Dienste wiederverwendbar sind und mehrere Anwendungen denselben Dienst nutzen kรถnnten.
Folgende Faktoren werden bei der Prรผfung berรผcksichtigt:
- Leistung und Funktionalitรคt des Dienstes mรผssen unter hoher Belastung getestet werden.
- Die Leistung des Dienstes muss verglichen werden, wenn er einzeln funktioniert und wenn er in die Anwendung integriert ist.
- Lastprรผfung Der Service sollte durchgefรผhrt werden, um die Antwortzeit zu รผberprรผfen, Engpรคsse aufzudecken, die Auslastung von CPU und Speicher zu รผberprรผfen und die Skalierbarkeit vorherzusagen.
8) Prรผfung der Integrationsebene
- Die Service-Level-Testung gewรคhrleistet das ordnungsgemรครe Funktionieren der einzelnen Dienste; sie garantiert jedoch nicht das Funktionieren der gekoppelten Komponenten.
- Bei den Integrationstests liegt der Fokus hauptsรคchlich auf der Schnittstellen.
- Diese Phase deckt alle mรถglichen Geschรคftsszenarien ab.
- In dieser Phase sollten erneut nicht-funktionale Tests der Anwendung durchgefรผhrt werden. Sicherheits-, Compliance- und Leistungstests gewรคhrleisten die Verfรผgbarkeit und Stabilitรคt des Systems in allen Aspekten.
- Die Kommunikations- und Netzwerkprotokolle sollten getestet werden, um die Konsistenz der Datenkommunikation zwischen den Diensten zu validieren.
9) End-to-End-Tests
Diese Phase stellt sicher, dass die Anwendung sowohl funktional als auch nicht-funktional den Geschรคftsanforderungen entspricht.
Die folgenden Artikel werden garantiert getestet wรคhrend End-to-End-Tests:
- Alle Dienste funktionieren nach der Integration wie erwartet
- Ausnahmebehandlung
- Benutzeroberflรคche der Anwendung
- Korrekter Datenfluss durch alle Komponenten
- Geschรคftsprozess
Herausforderungen beim SOA-Testing
Die Anwendung dieser Methoden ist selten unkompliziert, und die folgenden Schwierigkeiten treten bei fast jedem SOA-Programm wieder auf.
- Fehlende Schnittstellen fรผr Dienste.
- Der Testprozess erstreckt sich รผber mehrere Systeme, was einen komplexen Datenbedarf mit sich bringt.
- Die Anwendung besteht aus einer Sammlung verschiedener Komponenten, die sich tendenziell รคndern, weshalb Regressionstests hรคufiger erforderlich sind.
- Aufgrund des mehrschichtigen Aufbaus ist es schwierig, Defekte zu isolieren.
- Da ein Dienst von verschiedenen Schnittstellen genutzt wird, ist die Last schwer vorherzusagen, was die Planung von Leistungstests umstรคndlich macht.
- SOA ist eine Sammlung heterogener Technologien. Das Testen einer SOA-Anwendung erfordert Personen mit unterschiedlichen Kompetenzen, was wiederum die Planungs- und Ausfรผhrungskosten erhรถht.
- Da die Anwendung mehrere Dienste integriert, bringt das Sicherheitstesting einige Schwierigkeiten mit sich. Die Validierung von Authentifizierung und Autorisierung gestaltet sich schwierig.
SOA-Testtools
Auf dem Markt sind zahlreiche SOA-Testtools erhรคltlich, die Anwender beim Testen von SOA-Anwendungen unterstรผtzen. Hier sind einige der gรคngigsten SOA-Testtools.
1) SoapUI
SoapUI ist ein Open-Source-Tool fรผr funktionale Tests von Diensten und API-Tests.
- Desktopanwendung
- Unterstรผtzt mehrere Protokolle โ SOAP, REST, HTTP, JMS, AMF, JDBC
- Webdienste kรถnnen entwickelt, รผberprรผft und aufgerufen werden.
- Kann auch fรผr Lasttests verwendet werden. Automatisierungstestsund Sicherheitstests
- Stubs kรถnnen von MockServices erstellt werden
- Webdienstanfragen und -tests kรถnnen automatisch รผber den Webdienstclient generiert werden.
- Verfรผgt รผber integrierte Berichtswerkzeuge
- Entwickelt von SmartBear, das sowohl das Open-Source SoapUI Vertrieb und das kommerzielle ReadyAPI Ausgabe
2) Broadcom Service Virtualization (ehemals iTKO LISA)
LISA ist eine Produkt-Suite, die eine Lรถsung fรผr Funktionstests verteilter Systeme wie SOA bietet. Das Produkt wurde von iTKO an CA Technologies รผbertragen und wird heute unter dem Namen Broadcom Service Virtualization vertrieben.
- Kann auch fรผr Regressions-, Integrations-, Last- und Leistungstests verwendet werden.
- Kann zum Entwerfen und Ausfรผhren von Tests verwendet werden.
3) UFT One (ehemals HP Service Test)
Service Test ist ein funktionales Testtool, das sowohl UI- als auch Shared-Services-Tests unterstรผtzt. Die API-Testfunktionen wurden in Unified Functional Testing integriert, das jetzt von [Name des Unternehmens/der Organisation] vertrieben wird. OpenText as UFT One.
- Sowohl Funktionstests als auch Leistungstests von Diensten kรถnnen mit einem einzigen Skript durchgefรผhrt werden.
- Integriert in Quality Center, jetzt verkauft als OpenText ALM / Qualitรคtszentrum.
- Es lassen sich enorme Mengen an Diensten und Daten verwalten.
- Unterstรผtzt Interoperabilitรคtstests durch Simulation von JEE-, AXIS- und DotNet-Clientumgebungen.
4) Parasoft SOAtest
Parasoft SOAtest ist eine Suite von Test- und Analysetools, die fรผr das Testen von APIs und API-gesteuerten Anwendungen entwickelt wurde.
- Unterstรผtzt Webdienste, REST, JSON, MQ, JMS, TIBCO, HTTP und XML-Technologien.
- Funktions-, Komponenten-, Integrations-, Regressions-, Sicherheits-, Interoperabilitรคts-, Konformitรคts- und Leistungstests sind mรถglich.
- Stubs kรถnnen erstellt werden mit Parasoft Virtualisieren, die leistungsfรคhiger sind als SoapUI MockServices.
Anwendungsfรคlle fรผr SOA-Tests
Das untenstehende Beispiel wendet die oben genannten Strategien, Methoden und Werkzeuge schrittweise auf eine einzelne E-Commerce-Website an.
Betrachten Sie eine E-Commerce-Website, die die folgenden Funktionen und Unterfunktionen enthรคlt.
Auftragsabwicklung
Das nachstehende Diagramm unterteilt die Auftragsabwicklung in die Teilfunktionen, die zu Dienstleistungen werden.
PHASE 1
In der ersten Phase des SOA-Tests, der Teststrategiephase, wird die Anwendung in Dienste und Geschรคftsfunktionen unterteilt.
Betrachten wir die folgenden Dienste in der Anwendung.
- Bestellung anlegen
- รberprรผfen Sie den Kundenstatus
- Auftragsstatus รคndern
- Bestellstatus รผberprรผfen
- Inventar prรผfen
Die Geschรคftsfunktionen entsprechen den Funktionen der Website.
Hinweis: Das Teststrategiedokument enthรคlt die Liste der Dienste und Funktionen, die getestet werden mรผssen.
PHASE 2
Dies ist die Testplanungsphase. Testfรคlle werden fรผr jedes Level geschrieben.
End-to-End-Ebene. Fรผr jeden Anwendungsfall und jeden Arbeitsablauf werden Testfรคlle erstellt. Nachfolgend finden Sie Beispiele fรผr Testfรคlle.
- Erstellen Sie eine Bestellung mit einem aktiven Benutzer.
- Erstellen Sie eine Bestellung mit einem inaktiven Benutzer.
- Erstellen Sie eine Bestellung mit einem verfรผgbaren Produkt, wobei die Bestellmenge kleiner als die verfรผgbare Menge ist.
- Erstellen Sie eine Bestellung mit einem verfรผgbaren Produkt, wobei die Bestellmenge grรถรer als die verfรผgbare Menge ist.
- Erstellen Sie eine Bestellung mit mehreren Artikeln.
- Eine Bestellung vollstรคndig stornieren.
- Eine Bestellung teilweise stornieren.
Integrationsgrad. Fรผr die Integration von Datenbank und Benutzeroberflรคche werden Testfรคlle erstellt. Nachfolgend finden Sie Beispieltestfรคlle.
- Erstellen Sie eine neue Bestellung mit einem einzelnen Artikel. Stellen Sie sicher, dass die Bestellung in der Datenbank erstellt wird.
- Erstellen Sie eine neue Bestellung mit einem einzelnen Artikel. รberprรผfen Sie, ob der fรผr die Bestellung berechnete Preis korrekt ist.
- Erstellen Sie eine neue Bestellung mit einem einzelnen Artikel. รberprรผfen Sie, ob die verfรผgbare Produktmenge um den Bestellwert reduziert wird.
- รberprรผfen Sie, ob der auf der Benutzeroberflรคche angezeigte Status der Bestellung mit dem in der Datenbank รผbereinstimmt.
- Stornieren Sie die Bestellung und รผberprรผfen Sie, ob der Status der Bestellung in der Datenbank geรคndert wurde.
- Bei der ersten Zahlung sollten Sie รผberprรผfen, ob die in der Benutzeroberflรคche eingegebenen Zahlungsdaten in der Datenbank gespeichert wurden.
- รberprรผfen Sie bei der Rรผckgabe von Zahlungen, ob die Zahlungsdetails in der Datenbank auf der Benutzeroberflรคche angezeigt werden.
Service Level. Jeder Dienst wird auf alle Datenbedingungen getestet. Nachfolgend einige Beispiele.
| Nein. | Bestelldetails | Bestellbedingung |
|---|---|---|
| 1 | Bestellung anlegen. Anzahl der Artikel = 1 | Bestellmenge < Menge in der Datenbank |
| 2 | Bestellung anlegen. Anzahl der Artikel > 1 | Bestellmenge < Menge in der Datenbank |
| 3 | Bestellung anlegen. Anzahl der Artikel = 1 | Bestellmenge > Menge in der Datenbank |
| 4 | Bestellstatus รผberprรผfen | Status der Datenbank = Aktiv |
| 5 | Bestellstatus รผberprรผfen | Status in der Datenbank = Ausgeliefert |
| 6 | Bestellstatus รผberprรผfen | Status in der Datenbank = Abgebrochen |
| 7 | Bestellstatus รผberprรผfen | Bestell-ID = Ungรผltig |
| 8 | รberprรผfen Sie die Produktverfรผgbarkeit | Produktmenge >0 |
| 9 | รberprรผfen Sie die Produktverfรผgbarkeit | Produktmenge =0 |
| 10 | รberprรผfen Sie die Produktverfรผgbarkeit | Produkt-ID = ungรผltig |
PHASE 3 โ Testdurchfรผhrung
Die Testdurchfรผhrung erfolgt nach dem Bottom-up-Ansatz: Zuerst werden Tests auf Serviceebene durchgefรผhrt, dann auf Integrationsebene und zuletzt auf End-to-End-Ebene.
1) Serviceniveau
Nehmen wir an, dass die SoapUI Das Tool dient zum Testen der Anwendung. Die WSDL und URL werden im Testfenster angezeigt SoapUIDie Anfrage fรผr jeden Dienst wird im Anfragefenster angezeigt. Durch die Anpassung der Daten gemรคร den Testfรคllen auf Dienstebene werden fรผr jeden Testfall Anfragen erstellt.
| Testfall | PREISANFRAGE (Request) | Erwartete Antwort |
|---|---|---|
| Bestellung erstellen. Anzahl der Artikel = 1, Bestellmenge < Datenbankmenge | x2 2 | o3251 Erfolgreich |
| Bestellung erstellen. Anzahl der Artikel > 1, Bestellmenge < Datenbankmenge | y1 1 y2 3 | o3251 Erfolgreich |
| Bestellung erstellen. Anzahl Artikel = 1, Bestellmenge > Datenbankmenge | x23 200 | Null Erfolglos |
| Bestellstatus prรผfen. Status in der Datenbank = Aktiv | o9876 | Aktiv Erfolgreich |
| Bestellstatus prรผfen. Status in der Datenbank = Versendet | o9656 | Versand Erfolgreich |
| Bestellstatus prรผfen. Bestellnummer = Ungรผltig | y5686 | null Erfolglos |
| Produktverfรผgbarkeit prรผfen. Produktmenge >0 | d34 | 34 Ja Erfolgreich |
| Produktverfรผgbarkeit prรผfen. Produktmenge = 0 | y34 | 0 NEIN Erfolgreich |
| Produktverfรผgbarkeit prรผfen. Produkt-ID = ungรผltig | sder | Erfolglos |
2) Integrationsebene
Die Integrationstests werden auf der Benutzeroberflรคche und der Datenbank ausgefรผhrt. Erstellen Sie eine Bestellung mit einem einzelnen Artikel:
- Ein Benutzer รถffnet die Website.
- Der Benutzer mรถchte eine Bestellung aufgeben.
- Der Benutzer wรคhlt ein gรผltiges Produkt und die entsprechende Menge aus und speichert die Bestellung.
- Es sollte eine Meldung angezeigt werden, die bestรคtigt, dass die Bestellung erfolgreich aufgegeben wurde.
- Der Benutzer รถffnet die Datenbank und prรผft, ob die Bestelldetails mit den auf der Website eingegebenen Daten รผbereinstimmen.
3) End-to-End-Ebene
Die Geschรคftsprozesse und Anwendungsfรคlle werden รผber die Benutzeroberflรคche ausgefรผhrt. Erstellen Sie eine Bestellung mit mehreren Artikeln:
- Ein Benutzer รถffnet die Website.
- Der Benutzer mรถchte eine Bestellung aufgeben.
- Der Nutzer erkundigt sich nach einem gรผltigen Produkt und der gewรผnschten Menge und fรผgt diese dem Warenkorb hinzu.
- Weitere gรผltige Produkte werden in den entsprechenden Mengen hinzugefรผgt und die Bestellung gespeichert. Die Zahlung erfolgt รผber eine neue Zahlungsmethode und die Bestellung wird aufgegeben.
- Es sollte die Meldung โBestellung erfolgreich aufgegebenโ angezeigt werden.
- Ein Tester sollte รผberprรผfen, ob der gesamte Ablauf ohne Datenverfรคlschung vollstรคndig ablรคuft.
