So automatisieren wir das Testen mit Release Management - Teil 2

Ursprünglicher Autor: Abhishek Agarwal
  • Übersetzung
Im ersten Teil dieses Artikels habe ich das Einrichten der Testautomatisierung mit RM ausführlich beschrieben. Im zweiten (und letzten) Teil des Artikels werde ich einige Entwurfslösungen erläutern, die Probleme, auf die wir beim Einrichten des Systems gestoßen sind, und Möglichkeiten, diese Probleme zu überwinden.

Ein oder mehrere Agentenpools?

Frage : Wie kann die Definition der Freigabe an einen geeigneten Agentencomputer umgeleitet werden, d. H. an einen Computer mit den für diese Release-Definition erforderlichen Ressourcen?
Lösung: Als wir mit der Erstellung der Release-Definitionen begannen, wurde deutlich, dass jede Release-Definition an den entsprechenden Agenten gesendet werden musste, da die Anforderungen aller Testsuiten unterschiedlich waren. Zuerst haben wir für jede Release-Definition einen eigenen Agentenpool erstellt, aber es war schwierig, eine große Anzahl von Agentenpools zu verwalten. Letztendlich folgten wir dem Rat von Chris Patterson von der Baugruppe und entwickelten ein System, das einen einzelnen Agentenpool namens RMAgentPool verwendete. Alle Agenten dieses Pools unterschieden sich in ihren Benutzerfunktionen. Jetzt wird jede Release-Definition und Build-Definition von einem geeigneten Agenten mithilfe der RmCdpCapability-Funktion ausgeführt. Ein Computer, der für RM.CDP.TfsOnPrem vorbereitet ist, verfügt beispielsweise über die Fähigkeit RmCdpCapability = TfsOnPrem:


RM.CDP.TfsOnPrem RD leitet seine Ausführung mithilfe der Anforderung RmCdpCapability = TfsOnPrem an diesen Agenten weiter:


JIT debuggen

Frage : Wie können zeitweise auftretende Fehler behoben werden, wenn Protokolldateien nicht genügend Daten enthalten? Wenn Entwickler das Problem finden, wird beim nächsten Testlauf der „Fehlerstatus“ vom Testcomputer entfernt.
Lösung : Wenn das Verhalten der Testsuite nicht vorhersehbar ist, wird die Aufgabe "Agent bei Testfehler anhalten" in die Release-Definition aufgenommen:


Diese Task pausiert die Freigabe, wenn in einem unvorhersehbaren Test ein Fehler auftritt. In dieser Situation kann der Entwickler eine Remoteverbindung mit dem Agentencomputer herstellen, dessen Status exakt mit dem Status zum Zeitpunkt des Fehlers übereinstimmt. Bitte beachten Sie, dass dies nur möglich ist, wenn der Umgebungs-Timeout-Wert 0 ist (kein Timeout).
Pause Aufgabe nimmt die folgenden Argumente (in der Abbildung oben):
-AlternateCredentialsUserName $ (release.alternateusername) -AlternateCredentialsPassword $ (release.alternatepassword) -ReleaseId $ (Release.ReleaseId) -TaskName $ (TaskToDebugName) -NumberOfSeconds $ (TaskToDebugTimeInSeconds)
Schlüsselargument Hier ist $ (TaskToDebugName): Es ist wichtig"RMCDPOnPrem-Tests ausführen" für RM.CDP.TfsOnPrem, d.h. Der Name der Aufgabe, für die zeitweise Fehler auftreten. Alle RM.CDP. * -Release-Definitionen enthalten dieselbe Task mit denselben Argumenten, aber der Wert von $ (TaskToDebugName) in jeder Release-Definition entspricht der Task, deren zeitweilige Fehler wir debuggen möchten.
Den Quellcode für diese Aufgabe finden Sie hier (anstelle von "YourAccount" ersetzen Sie den Namen des Kontos und verwenden Sie ihn).

Ausführen von Tests im Administratormodus auf einem Agentencomputer

Frage : Auch wenn der Agent als Administrator ausgeführt wird, führt er die Aufgabe in einem anderen Modus als dem Administratormodus aus. Dies macht es unmöglich, eine Aufgabe auszuführen, die im Administratormodus ausgeführt werden muss (z. B. Installieren eines Dienstes auf einem Agentencomputer).
Lösung : Dieses Problem wurde mithilfe der Aufgabe "PowerShell auf Zielcomputern" und des Remotezugriffs auf den aktuellen Agentencomputer als Administrator behoben. Beispielsweise installieren wir den TFS-Dienst in RM.CDP.RmEqTfs wie folgt:


Tests, die die VsTest-Task nicht wiederverwenden können

Frage : Einige Tests wurden vor relativ langer Zeit erstellt (wir werden sie als "veraltet" bezeichnen) und sind nicht mit der VsTest-Aufgabe kompatibel. Wie können Sie in solchen Situationen den vollen Nutzen aus der Erstellung von Berichten ziehen, die Tests liefern, die mit der VsTest-Aufgabe kompatibel sind?
Lösung : Um dieses Problem zu lösen, haben wir folgende Maßnahmen ergriffen:
  1. Wir haben die veralteten Tests mithilfe eines Stapelskripts oder einer Powershell-Task (je nachdem, was bequemer ist) durchgeführt und den Speicherort der Ausgabeprotokolldatei ermittelt.
  2. Wir haben den Task VsTest hinzugefügt, der die im vorherigen Schritt erkannte Ausgabeprotokolldatei analysierte und feststellte, ob der Test erfolgreich war.

Unsere Release-Definition für RM.CDP.DevFabricUpgrade lautet wie folgt: Der Haupttest wird mit dem Powershell-Skript RunAOConfigTest.ps1 durchgeführt.


Anschließend wird die VsTest-Task ausgeführt, die die Protokolldatei analysiert und prüft, ob sie Fehler enthält.
Hinweis: Bis vor kurzem hat der VsTest-kompatible RM.CDP.DevFabricUpgrade-Testcode einfach den Text "Erwartet wahr, aber falsch gefunden" in die Protokolldatei eingefügt, was das Debuggen sehr schwierig machte. Die Entwickler waren gezwungen, die Ausgabeprotokolldatei RunAOConfigTest.ps1 zu öffnen, was an sich einige Zeit in Anspruch nahm, da die Datei sehr groß war, und nach einem echten Fehler zu suchen, wie im folgenden Screenshot gezeigt:


Wir haben diesen Code kürzlich geändert, um die Ausgabeprotokolldatei RunAOConfigTest.ps1 genauer zu analysieren. Wenn der Test fehlschlägt, werden nun detailliertere Fehlerinformationen angezeigt:


Wie können Engpässe bei der Durchführung von Tests beseitigt werden?

Frage : Die Implementierung einiger Release-Definitionen dauert sehr lange, was zum Auftreten der Warteschlange führt und die Verarbeitungszeit erheblich verlängert. Was kann in dieser Situation verbessert werden?
Lösung : Da die meisten unserer Tests darauf ausgelegt sind, sicherzustellen, dass die Dienstbereitstellung und die Tests auf einem Agentencomputer durchgeführt werden, können wir einfach zusätzliche Geräte (mit der richtigen RmCdpCapability) für problematische Release-Definitionen installieren.

Wie führe ich Benutzerschnittstellentests durch?

Frage : Wie führe ich Benutzerschnittstellentests auf einem Agentencomputer durch?
Lösung : Eine schnelle und einfache Möglichkeit, dieses Problem zu beheben, besteht darin, den Agenten im interaktiven Modus (und nicht im Servicemodus) zu starten, da der Agent im Servicemodus nicht mit dem Desktopcomputer interagieren kann. Der Nachteil dieser Methode ist, dass bei der Ausführung des Agenten im interaktiven Modus die automatischen Aktualisierungsfunktionen nicht unterstützt werden. Um den Agenten zu aktualisieren, müssen Sie sich am Agentencomputer anmelden und den Agenten neu starten.
Ein automatisierterer Ansatz besteht darin, den Agenten im Servicemodus zu starten und die Aufgaben Visual Studio Test Agent-Bereitstellung (Visual Studio Test Agent-Bereitstellung) und Visual Studio-Test mit Test-Agent zu verwenden (Visual Studio-Test mit Test ausführen) agent ”). Wir verwenden eine Methode ähnlich der oben beschriebenen Aufgabe "PowerShell auf Zielcomputern", bei der wir uns remote mit Administratorrechten beim aktuellen Agentencomputer anmelden. Diese Aufgaben werden auf dem Agenten von dem Testdienst ausgeführt, der für die Interaktion mit dem Desktop-Computer konfiguriert ist.
Um diese Methode zu verwenden, erstellen wir zunächst eine Gruppe geeigneter Computer im Abschnitt Test:


Dann verwenden wir diese Gruppe von Computern in den beiden oben genannten Aufgaben des VS-Testagenten. Wählen Sie in der Aufgabe "VsTest-Agent-Bereitstellung" die Option "Interaktiver Prozess" aus:


Am Ende führt die Aufgabe "Vs-Test mit Test-Agent" Tests mit unserer Computergruppe durch In diesem Fall werden dieselben Filter wie bei der Standard-VsTest-Aufgabe verwendet:


Es ist zu beachten, dass dieser Prozess in naher Zukunft konsistenter wird. Es ist nicht mehr erforderlich, Computergruppen für die Aufgaben des Testagenten zu erstellen, und es reicht aus, den Computernamen im Parameter $ (Agent.MachineName) anzugeben.

Welche Variablen stehen zur Laufzeit zur Verfügung?

Frage : Welche Variablen sind zur Laufzeit verfügbar?
Lösung : Variablen, die zur Laufzeit verfügbar sind und in der Release-Definition verwendet werden können, werden am Anfang der folgenden Protokolle aufgeführt:


Ist es möglich, RM gemäß den Bedürfnissen unserer Gruppe zu skalieren?

Frage : Wenn wir uns dem Ende des Sprints nähern, steigt die Anzahl der Prüfungen in unserer Gruppe exponentiell an und wir haben Zweifel, dass RMO mit diesen Belastungen fertig wird. Das Durchführen von 15 Überprüfungen pro Tag in der Release-Phase ist gängige Praxis und umfasst 15 * 9 = ~ 135 Bereitstellungen pro Tag (da jede Überprüfung neun Release-Definitionen aktiviert).
Lösung : Zunächst zeigte der RMO-Service eine gewisse Instabilität bei hoher Belastung, aber in der zweiten Jahreshälfte 2015 haben wir dies durch eine Reihe von Stresstests behoben. Jetzt kann RMO die Aufgaben unserer Gruppe problemlos bewältigen. Der Screenshot unten zeigt ungefähr 20 Ausgaben von RM.CDP.DevFabircUpgrade, die in den letzten 24 Stunden abgeschlossen wurden. Dies entspricht 20 * 9 = 180 Ausgaben unserer Gruppe für den gleichen Zeitraum.


Fazit


Ich hoffe, diese Veröffentlichung hilft Ihnen, die meisten Probleme zu lösen, die bei der Automatisierung von Tests mit RM auftreten.

Jetzt auch beliebt: