Automatisieren des Buildprozesses
Ein automatisierter Buildprozess kompiliert, bereitstellt und führt dann build verification tests (BVTs) für den neuesten Quellcode für ein Projekt in regelmäßigen, vorgegebenen Intervallen aus. Anschließend wird ein "Buildbericht", der den Erfolg oder Misserfolg des Buildprozesses detailliert beschreibt, an die Projektbeteiligten verteilt. Der Buildbericht wird analysiert, um zu bestimmen, welche Bereiche des Projekts Aufmerksamkeit benötigen und ob das Projekt auf eine frühere Version bzw. einen früheren Build zurückgesetzt werden soll.
Die Leistung eines automatisierten Buildprozesses besteht darin, dass er für die Ausführung außerhalb der Geschäftszeiten geplant werden kann. Auf diese Weise kann es dazu beitragen, die Stabilität des Projekts zu gewährleisten, ohne Zyklen direkt von der Entwicklungszeit wegzunehmen. Dieses Thema bietet eine Übersicht über den Buildprozess, beschreibt, wie Buildüberprüfungstests in den Buildprozess passen, beschreibt Aspekte von Funktionstests, die während der Buildüberprüfung verwendet werden, und enthält Informationen über die Bedeutung der Automatisierung des Buildprozesses.
Übersicht über den Buildprozess
Bevor Sie sich mit den Besonderheiten von Tests befassen, ist es wichtig, den Kontext zu berücksichtigen, in dem das Testen in den gesamten Buildprozess passt. Alle Produktgruppen von Microsoft arbeiten nach der Philosophie, dass der Buildprozess der Takt jedes Softwareprojekts ist. Dieser Ansatz wird auch von vielen der weltweit führenden Beratungsunternehmen verwendet, die unternehmenskritische Lösungen auf dem Microsoft-Softwarestapel erstellen. Ohne einen stabilen Takt und eine regelmäßige Überprüfung ist es unmöglich, die Integrität des Projekts zu kennen. Um sicherzustellen, dass die Produktgruppen über einen kontinuierlichen Einblick in die allgemeine Integrität des Projekts verfügen, wird der Buildprozess täglich ausgeführt, in der Regel um Mitternacht. In den folgenden Schritten wird ein typischer automatisierter Buildprozess zusammengefasst:
Rufen Sie den neuesten Build des Quellcodes aus dem Quellcoderepository ab.
Kompilieren Sie den Quellcode.
Packen Sie Binärdateien für die Bereitstellung – in der Regel mithilfe von Skripts oder Microsoft Windows Installer-Dateien.
Stellen Sie das Projekt auf einem Testserver bereit.
Führen Sie automatisch einen vollständigen Satz von Buildüberprüfungstests (BVTs) aus.
Veröffentlichen Sie einen detaillierten Buildbericht für Mitglieder des Projektteams.
Hinweis
BVTs sind Funktionstests, die die Standard Features der Lösung ausführen, um deren Qualität zu testen. Sie müssen sicherstellen, dass Ihre BVTs umfassend genug sind, um die Buildqualität zu messen, aber klein genug, um innerhalb der zugewiesenen täglichen Buildzeit auszuführen!
Hinweis
Sie sollten auch alle Bereitstellungs-, Bereitstellungs-, Konfigurations- und Installationsskripts oder -prozesse zu Testzwecken als Teil des Softwareprojekts behandeln. Sowohl die Vorgänge des Projekts als auch die Bereitstellung und Konfiguration des Projekts sollten getestet werden.
Dieser Prozess wird in der Regel am frühen Morgen um 6 Uhr morgens abgeschlossen, sodass die ersten Mitglieder des Teams mit der Arbeit am Build des neuen Tages beginnen können. Wenn ein oder mehrere der BVTs aus der vorherigen Nacht fehlgeschlagen sind, liegt es in der Verantwortung des Teams, dies so schnell wie möglich zu beheben.
Das Folgen eines täglichen Buildprozesses hat viele Vorteile für das Projekt. Erstens bietet es einen regelmäßigen Takt (bestehend aus dem täglichen Build und den automatisierten BVTs). Zweitens erzwingt die Verwendung von BVTs die Integration in Systeme, was eine schwierige Aufgabe ist, und dies frühzeitig zu tun, reduziert Projektrisiken. Aufgrund der erforderlichen Zeit werden Stress- und Leistungstests in der Regel außerhalb des täglichen Buildprozesses durchgeführt. Belastungs- und Leistungstests werden in der Regel für einen Meilensteinbuild im Projekt geplant.
Der tägliche Buildprozess kann und wurde sehr effektiv für BizTalk-Lösungen verwendet. Sie müssen jedoch sicherstellen, dass Aufgaben, die in Projekten in der Regel bis zum Ende liegen, von Anfang an iterativ ausgeführt werden. Beispielsweise ist die Bereitstellung in BizTalk Server sicherlich nicht trivial. Es ist wichtig, dass automatisierte Bereitstellungsskripts im Voraus entwickelt werden. Wenn Sie dies nicht tun, werden Sie die Lösung während des gesamten Projekts mehrmals manuell bereitstellen und aufheben, was Am Ende mehr Zeit kostet. Es stehen Tools zur Verfügung, um den täglichen Buildprozess zu steuern. Visual Studio Team System und Team Foundation Server sind für viele Personen die primäre Wahl. MSBuild-Skripts können verwendet werden, um die Schritte im Buildprozess zu steuern.
Hinweis
Die Verwendung dieses Tools wird von Microsoft nicht unterstützt, und Microsoft gibt keine Garantien für die Eignung dieser Programme ab. Die Verwendung dieses Programms erfolgt ausschließlich auf eigenes Risiko.
Weitere Informationen zum Automatisieren von Tests mit Microsoft Test Manager findest du unter Ausführen automatisierter Tests.
Buildüberprüfungstest
Buildüberprüfungstests umfassen in der Regel die folgenden Elemente:
Komponententests : Da Komponententests in der Regel die ersten zu entwickelnden Tests sind, sollten sie idealerweise erstellt werden, bevor der Code tatsächlich geschrieben wurde, wenn Sie wirklich einen testgesteuerten Entwicklungsansatz verwenden. Indem Sie sie in den frühen Phasen eines Projekts zu BVTs hinzufügen, stellen Sie mindestens eine gewisse Code Coverage sofort bereit. Wenn die Anzahl der Funktionstests und damit die Testabdeckung zunimmt, können Sie Komponententests aus den BVTs entfernen.
Rauchtests : End-to-End-Funktionstests, die die grundlegende Funktionalität Ihrer Lösung testen. Wenn diese fehlschlagen, stimmt etwas ernsthaft nicht. Diese können in der Regel relativ schnell ausgeführt werden.
Funktionstests : Diese Tests zielen auch auf End-to-End-Szenarien ab, aber in diesem Fall testen sie alle Szenarien im Projekt. Bei großen Projekten kann es sinnvoll sein, Ihre Funktionstests weiter zu kategorisieren (für instance, damit eine bestimmte Komponente schnell, zuverlässig und isoliert getestet werden kann). Diese Funktionstests sollten gesperrt werden, nachdem Sie ihre Lösung als funktionell korrekt abgemeldet haben.
Regressionsüberprüfungstests : Jedes Mal, wenn ein Lösungsfehler gefunden und behoben wird, sollten Testfälle für die Regressionsüberprüfung hinzugefügt werden, um zu überprüfen, ob der Fehler behoben und später im Projektlebenszyklus nicht wieder eingeführt wird. Bei diesen Tests handelt es sich in der Regel um Fälle, die in den Funktionstestfällen nicht behandelt wurden. Sie sollten davon ausgehen, dass die Anzahl Der Regressionsüberprüfungstests auch nach der Liveschaltung der Lösung zunehmen wird, wenn neue Fehler erkannt und behoben werden.
Bei sehr großen Projekten müssen Sie Ihre BVTs möglicherweise zu einer Teilmenge der vollständigen funktionalen Testsammlung machen (aufgrund der Dauer, die für die Ausführung benötigt wird). Bei kleineren Projekten bilden BVTs den gesamten Satz. Wenn Sie die BVTs als Teil Ihres täglichen Builds integrieren möchten, muss der gesamte Prozess natürlich automatisiert werden. Im weiteren Verlauf dieses Themas konzentrieren wir uns darauf, wie Sie BizUnit und andere Tools verwenden können, um dies zu erreichen.
Funktionstests
Testen Sie im Kontext von Funktionstests für BizTalk-Anwendungen ein bestimmtes End-to-End-Szenario. Bei dieser Art von Tests ist es nützlich, sich BizTalk Server als Blackbox vorzustellen, die Sie funktionell aus einer externen Perspektive testen. Ein Test kann z. B. das Einspeisen einer Eingabenachricht (mit bekannten Werten) an einen Endpunkt des Empfangsstandorts umfassen (z. B. URL, FTP-Speicherort, unabhängig davon, ob Sie transporte). Der Test würde dann die richtige Anzahl von Nachrichten mit der richtigen Ausgabe überwachen, die auf der Sendeseite erzeugt wird. Dies mag relativ einfach klingen. Wenn Sie jedoch berücksichtigen, dass einige Szenarien Eingaben in einer bestimmten Reihenfolge und zu einem bestimmten Zeitpunkt erfordern, und Sie dies mit anderen Lösungsanforderungen zusammensetzen (z. B. beim Aufzeichnen von Nachverfolgungsdaten in BAM), wird klar, dass ein Tool und ein Framework verwendet werden können, um dies zu orchestrieren.
Es ist wichtig, dass Funktionstests darauf ausgelegt sind, alle möglichen Pfade durch Ihre Lösung abzudecken. Dies sollte nicht nur die Szenarien umfassen, die Sie in der Produktion erwarten, sondern auch die Fehlerpfade und Ausnahmebehandlungspfade, die Sie implementiert haben, aber hoffentlich niemals verwenden. Ein Häufig verwendeter Ausdruck, um dies zu beschreiben, ist das Testen für das "Szenario mit einem schlechten Tag". Sie sollten sicherstellen, dass alle Orchestrierungen, alle zulässigen Nachrichtentypen und alle Codebranches von Ihrer Funktionstestsammlung ausgeführt werden. In den folgenden Abschnitten wird die Entwicklung positiver und negativer funktionsbezogener Testfälle beschrieben, um alle Codepfade abzudecken.
Weitere Informationen zu Funktionstests und den anderen Testkategorien, die implementiert werden sollten, bevor eine BizTalk Server Lösung in die Produktion aufgenommen wird, finden Sie unter Checkliste: Testen der Betriebsbereitschaft.
Positive Tests
Bei positiven Tests ist es wichtig, sicherzustellen, dass alle Kombinationen von Nachrichten, Pipelines, Orchestrierungen und Endpunkten über die Lösung übergeben werden, damit alle Nachrichtenflüsse ausgeführt werden. Um sicherzustellen, dass Sie alle Codepfade testen, müssen Sie wahrscheinlich verschiedene Nachrichten mit unterschiedlichen Inhalten verarbeiten.
Verwenden Sie beim Testen den Transporttyp, der in der Produktion verwendet wird. Leider werden funktionsbezogene Tests allzu oft nur mithilfe des Dateiadapters durchgeführt, wenn ein anderer Transport in der Produktion verwendet wird. Wenn Sie diesen Ansatz anwenden, können Sie und das Gesamtprojekt später ausfallen.
Überprüfen Sie die Nutzlast aller Nachrichten, die vom System gesendet werden. Wenn es sich bei den Nachrichten um XML handelt, sollten Sie ihr Schema und ihre Schlüsselfelder in der Nachricht mithilfe von XPath-Ausdrücken überprüfen.
Überprüfen aller in BAM gespeicherten Nachverfolgungsdaten (sofern verwendet); alle anderen Daten, die in externen Datenrepositorys verbleiben, sollten berücksichtigt werden.
Testen Sie die Ausführung aller Richtlinien und Regeln der Geschäftsregel-Engine (Business Rule Engine, BRE), wenn Ihre Lösung BRE verwendet.
Negative Tests
Stellen Sie sicher, dass Sie die Behandlung ungültiger Nachrichten über Ihr System testen. Sie sollten überprüfen, ob die von Ihnen gewählte Strategie (ablehnen, bevor sie in BizTalk Server kommen, oder sie auszusetzen) ordnungsgemäß funktioniert hat.
Stellen Sie beim Testen der Behandlung ungültiger Nachrichten sicher, dass alle empfangsseitigen Fehlerbehandlungs-Orchestrierungen implementiert wurden, um angehaltene Nachrichten zu verarbeiten.
Stellen Sie sicher, dass Ihre Fehlerszenarien alle Ausnahmeblöcke in Ihren Orchestrierungen abdecken. Wenn Dies nicht ausreichend getestet wird, ist ein häufiges Problem.
Wenn Sie transaktionen mit langer Ausführungsdauer mit Kompensationsverhalten verwenden, testen Sie diese Szenarien sehr sorgfältig. Dies ist ein weiterer Bereich, in dem unzureichende Tests schwerwiegende Folgen in einer Produktionsumgebung haben werden.
Stellen Sie sicher, dass Fehler in den entsprechenden Fehlerprotokollen ordnungsgemäß protokolliert werden.
Automatisierung ist der Schlüssel
Um all dies effizient und effektiv zu tun, investieren Sie die Zeit im Voraus, um Tests zu automatisieren. Manuelle Tests sind zeitaufwändig, fehleranfällig und teuer (in Bezug auf Zeit und Kosten). Jedes Mal, wenn Sie einen manuellen Testdurchlauf durchführen, fügen Sie einen weiteren Batch von Aufgaben hinzu, die von Projektressourcen (Personen im Team) verarbeitet werden müssen. Wenn Sie dies im Voraus automatisieren, können Sie eine Rendite für die anfängliche Investition erzielen, die für die Entwicklung der Tests bei jeder Ausführung erforderlich ist. Gute Funktionstests sollten schnell und effizient ausgeführt und wiederholbar sein; Jeder Test sollte auch autonom sein (er sollte unabhängig von jedem anderen sein; wenn Sie diesen Ansatz anwenden, können Sie mehrere Tests sequenziell als Testsammlung ausführen.) Die Funktionstests sollten immer zu demselben Ergebnis führen. Schlecht geschriebene Funktionstests oder schlecht geschriebener Code führen zu unterschiedlichen Testergebnissen zwischen Testläufen, was zu Verwirrung und Zeitverschwendung bei der Untersuchung der Grundursache des Fehlers führt.
Es ist wichtig, den Entwicklungsaufwand zu minimieren, der zum Schreiben der einzelnen Funktionstests erforderlich ist. In der Regel ist es umso teurer, etwas (in Bezug auf die Entwicklungszeit) zu produzieren, desto weniger Testfälle werden Sie wahrscheinlich am Ende haben. Dies bedeutet, dass Sie über eine geringere Testabdeckung für Ihren Code verfügen. Mithilfe eines Testframeworks können Sie Testfälle schneller und einfacher entwickeln und somit die vollständige Code Coverage vereinfachen. Die meisten guten Testframeworks verwenden einen deklarativen Ansatz zum Definieren von Tests. (Das heißt, die Konfiguration für einen Test wird in einer Konfigurationsdatei gespeichert, die in der Regel eine XML-Datei ist.) Mit einem guten Testframework können Sie eine voll funktionsfähige Testsammlung auf agile und zuverlässige Weise entwickeln und vermeiden, dass Sie das Rad sozusagen immer wieder neu erfinden müssen.
MSBUILD-Unterstützung für BizTalk Server-Projekte
BizTalk Server bietet Unterstützung für die Microsoft-Build-Engine(MSBUILD)-Plattform, die das Erstellen von verwalteten Projekten in Buildlabumgebungen ermöglicht, in denen Visual Studio nicht installiert ist. MSBUILD unterstützt das Erstellen von Projekten über eine Befehlszeile und erweiterte Funktionen, einschließlich MSBUILD-Protokollierung und Batchverarbeitung. Weitere Informationen zu MSBUILD finden Sie unter MSBuild Overview.