Die Bedeutung von Tests
Dieses Thema bietet eine Übersicht über die Denkweise, die zu unzureichenden Tests führt, beschreibt die Risiken, die mit dem Nichttest von BizTalk-Lösungen verbunden sind, und stellt die Fallstricke manueller Tests mit den Vorteilen automatisierter Tests gegenüber.
Testen als "Mehraufwand"
Leider wird die Testphase eines Projekts häufig als einer der ersten Aspekte eines Projektplans betrachtet, der zurückskaliert werden kann.
Ein Argument gegen das Testen von BizTalk-Lösungen ist folgendes: "Wir müssen unsere Lösung nicht testen, da Microsoft BizTalk Server bereits gründlich testet." Es stimmt zwar, dass Microsoft BizTalk Server gründlich testet, aber verschiedene Verwendungsszenarien erfordern eine von fast unzähligen Permutationen von Geschäftsanforderungen in Bezug auf Durchsatz, Hochverfügbarkeit, Adapternutzung, Latenz, Nachverfolgungsanforderungen, Orchestrierungsnutzung und benutzerdefinierten Code. Da BizTalk Server äußerst flexibel ist und so viele verschiedene Nutzungsszenarien aufnehmen kann, ist es einfach nicht möglich, alle zu antizipieren und zu testen. Darüber hinaus sollten die Standardeinstellungen, die in einer BizTalk Server-Umgebung angewendet werden, für jedes Nutzungsszenario optimiert werden. Die einzige Möglichkeit, die optimalen Einstellungen für ein bestimmtes Nutzungsszenario zu bestimmen, besteht darin, die Lösung zu testen, verschiedene Parameter zu messen, die Umgebung zu optimieren und erneut zu testen. Sehen Sie sich das folgende Diagramm an, das eine Beispielarchitektur für eine BizTalk Server-Lösung darstellt.
Beispiel für physische BizTalk-Architektur
Sie können im obigen Diagramm sehen, dass die BizTalk Server-Lösung viele bewegliche Teile enthält, darunter mehrere Computer, auf denen BizTalk Server ausgeführt werden, Computer, auf denen SQL Server ausgeführt werden, Serverclusterknoten und Active Directory-Domänen. Nachdem das System ausgeführt wird, werden viele Konfigurationsoptimierungen angewendet, um die Anwendung gemäß den Geschäftsanforderungen zu optimieren, um den Gesamt-ROI der Lösung zu maximieren. Dieses einzelne Szenario zeigt, dass viele Variablen im Spiel sind. Sehen Sie sich zusätzlich zur physischen Architektur der Umgebung das folgende Diagramm an, das den Fluss einer Nachricht über BizTalk Server darstellt.
sample Logical BizTalk Message Flow
Wenn wir uns das logische Diagramm einer Nachricht ansehen, die durch BizTalk Server fließt, sehen wir andere Variablen, die pro Projekt tests erfordern, einschließlich benutzerdefinierter Sende- und Empfangspipelinekomponenten und benutzerdefinierter Klassen, die von BizTalk-Orchestrierungen aufgerufen werden können. Da die Typkomplexität und Die Verwendung von benutzerdefinierten Komponenten und BizTalk-Komponenten von Projekt zu Projekt unterschiedlich ist, wird deutlicher, warum es wichtig ist, Tests für jedes bestimmte Verwendungsszenario durchzuführen.
Testmethodik und Zeitachsen
Um sicherzustellen, dass die Tests effektiv und effizient durchgeführt werden, sollte der Testgeschirr vollständig automatisiert werden, damit er leicht reproduzierbar ist und die Wahrscheinlichkeit von menschlichen Fehlern minimiert wird. Darüber hinaus sollte bei der Planung des Projekts ausreichend Zeit für tests zur Verfügung stehen. Ein minimalistischer Testansatz würde manuelle Schritte ähnlich den folgenden umfassen:
Laden Sie eine oder mehrere Nachrichten manuell in einen Empfangsendpunkt, z. B. eine Dateiablage oder mithilfe eines SOAP-Clients zum Aufrufen eines Webdiensts.
Überprüfen Sie manuell den richtigen Inhalt und die richtige Struktur einer Nachricht. Da in einem Projekt häufig mehrere Schemas vorhanden sind, können die Nachrichten eine Mischung aus Flatfile und XML sein und auch feldübergreifende Abhängigkeiten enthalten.
Hinweis
Ein Beispiel hierfür wäre jedes Projekt mit SWIFT-Nachrichten. Hierbei handelt es sich um Flatfilenachrichten mit feldübergreifenden Abhängigkeiten. Das heißt, der Wert eines Felds hängt von einem anderen ab – eine einfache XSD-Validierung funktioniert hier nicht; Daher verwendet der SWIFT Accelerator die BizTalk-Regel-Engine für die Überprüfung der Nachrichten. Weitere Informationen zum SWIFT Accelerator.
Überprüfen Sie die Ereignisprotokolle auf den BizTalk Server Computern manuell auf Fehler.
Überprüfen Sie manuell die BAM-Datenbanken (falls verwendet), um sicherzustellen, dass Aktivitätsinformationen ordnungsgemäß aufgezeichnet werden.
Die Verwendung eines manuellen Prozesses, wie oben beschrieben, für Tests ist subjektiv und fehleranfällig. Erwägen Sie, eine hundertzeilige SWIFT-Nachricht mit feldübergreifenden Abhängigkeiten für 10 verschiedene Testfälle zu untersuchen. Die meisten Projektentwickler wären nicht in der Lage, oder auch wenn sie es könnten, nicht geneigt, eine solche Aufgabe zuverlässig und genau zu bewältigen. Die Implementierung eines subjektiven, manuellen, fehleranfälligen Testprozesses erhöht das Risiko eines Projekts und erhöht die Fehlerwahrscheinlichkeit.
Das Ausfallrisiko wird häufig durch Projektplanungszeitpläne verstärkt, die nicht genügend Zeit für Tests enthalten. Allzu oft hängt eine Projektteststrategie von einem einzelnen manuellen Testdurchlauf ab, der eine Woche oder so vor dem Live-Starttermin geplant ist. Solche begrenzten Tests gefährden das Projekt. Bei einer solchen begrenzten Zeitleiste für Tests kann das Projekt verzögert werden, wenn Probleme erkannt werden, da keine Zeit für die Behebung von Problemen vorgesehen wurde. Wenn ein Problem erkannt und behoben wird, bleibt möglicherweise nicht genügend Zeit, um nachfolgende Testdurchläufe durchzuführen, bevor das System live geschaltet wird.
Die Realität von Tests "Einzelner finaler Build, einzelner Testdurchlauf, live nehmen das Projekt" ist, dass es oft dazu führt, dass das Projekt verzögert wird, das Projekt das Budget überschreitet oder noch schlimmer, das Projekt vollständig fehlschlägt! Für unternehmenskritische Systeme ist diese Art von Testmethodik eine Katastrophe, die darauf wartet.
Effektives und effizientes Testen
Da entsprechende Tests oft als teurer Luxus und nicht als integrale Anforderung angesehen werden, wird sie allzu oft am Ende eines Projekts angeheftet. Angesichts der Komplexität des Software- und Hardwarestapels, der in heterogenen Unternehmensumgebungen verwendet wird, ist dieser Ansatz unrealistisch. Die Implementierung eines automatisierten Testansatzes, der bei Bedarf erneut ausgeführt werden kann, ist die beste Methode, um effektiv und effizient zu testen und ist ein integraler Bestandteil erfolgreicher Projekte, die letztendlich einen hervorragenden ROI für das Unternehmen liefern. Indem Sie zu Beginn des Projekts in vollständige End-to-End-Funktionstests für jeden Codepfad durch das System investieren, generieren Sie Testressourcen. Diese Vermögenswerte erfordern Investitionen (d. h. Entwicklungszeit), um später die Vorteile einer erhöhten Testeffektivität und -effizienz zu nutzen. Um die investitionen zu minimieren, die für das Projekt erforderlich sind, um ein solches Framework abzuleiten, wird empfohlen, das Visual Studio 2010-Auslastungstestframework zu verwenden. Visual Studio 2010 enthält den Großteil der allgemeinen Testschritte, die für erfolgreiche Tests erforderlich sind, und ist das Framework, das in den weiter unten in diesem Leitfaden vorgestellten Testszenarien verwendet wird.