BDD 2007: Anwendungskompatibilität – Handbuch für das Feature-Team (Kapitel 4)

Entwickeln

Veröffentlicht: 30. Nov 2006

Abbildung 3 zeigt die Hauptaktivitäten während der Entwicklungsphase. Der Großteil dieser Aktivitäten umfasst die Vorbereitung der Server, mit denen die Anwendungen installiert werden, sowie die Migration vorhandener Benutzerdaten. Je nach Bereitstellungsstrategie können sich diese Aufgaben durchaus wiederholen. Bei einigen unternehmensweiten Bereitstellungen muss die nachstehende Sequenz aus Serverinstallation, Stabilisierung und Bereitstellung mehrfach wiederholt werden (entweder nacheinander oder parallel).

Abbildung 3: Aktivitäten während der Entwicklungsphase
Auf dieser Seite

Rollen und Verantwortlichkeiten Rollen und Verantwortlichkeiten
Erstellen der Testumgebung Erstellen der Testumgebung
Ermitteln des richtigen Zeitpunkts für die Virtualisierung Ermitteln des richtigen Zeitpunkts für die Virtualisierung
Testen der Schutzstrategien Testen der Schutzstrategien
Erstellen der Anwendungsschutzpakete Erstellen der Anwendungsschutzpakete
Meilenstein: Anwendungsschutzmaßnahmen erstellt Meilenstein: Anwendungsschutzmaßnahmen erstellt

Rollen und Verantwortlichkeiten

Alle sechs Rollencluster des MSF-Teammodells sind in der Entwicklungsphase der Initiative von Bedeutung. In Tabelle 5 werden die Rollen aufgeführt und die Schwerpunktbereiche für die einzelnen Rollencluster relativ zum Bereitstellungsprozess in der Planungsphase definiert. Weitere Informationen zu MSF-Rollenclustern finden Sie im Artikel zum Microsoft Solutions Framework unter http://www.microsoft.com/technet/itsolutions/msf/default.mspx (auf Englisch).

Tabelle 5: Teamrollen und Verantwortlichkeiten in der Entwicklungsphase

Rolle

Schwerpunkt

Produktmanagement

  • Analyse der Geschäftsanforderungen

  • Kommunikationsplan

Programm-Management

  • Budget

  • Masterprojektplan und Masterprojektzeitplan

Entwicklung

  • Entwicklungsplan und -zeitplan

  • Einrichten der Testumgebung

  • Logischer und physischer Entwurf

  • Auswerten der Technologien

Test

  • Testplan und -zeitplan

  • Definition der Testanforderungen

Benutzerfreundlichkeit

  • Anforderung an Lokalisierung/Eingabehilfen

  • Zeitpläne

  • Schulungspläne

  • Verwendungsszenarios/Anwendungsfälle

  • Benutzerdokumentation

  • Benutzeranforderungen

Releasemanagement

  • Anwendungs- und Hardwarebestand

  • Interaktion mit dem Betriebsbereitschafts- und dem SicherheitsFeature-Team

  • Netzwerkerkennung

  • Ablaufanforderungen

  • Pilot- und Bereitstellungsplan/-zeitplan

Erstellen der Testumgebung

Sobald Sie den Anwendungsbestand zusammengestellt und Anwendungsschutzstrategien ermittelt haben, erstellen Sie die Testumgebung, in der die Schutzstrategien überprüft werden können. In den meisten Fällen lässt sich diese Testumgebung gemeinsam mit dem Feature-Team für Anwendungsverwaltung nutzen.

Die Testumgebung ist eine langfristige Investition im Bereitstellungsprozess insgesamt. Behalten Sie die Testumgebung nach Abschluss der Bereitstellung bei, sodass diese Umgebung auch bei künftigen Bereitstellungsprojekten zur Verfügung steht.

So erstellen Sie die Testumgebung:

  • Legen Sie fest, wie die Produktionsumgebung in der Testumgebung nachgebildet werden soll.

  • Konfigurieren Sie die Testumgebung so, dass automatische Tests der Schutzstrategien unterstützt werden.

Festlegen der Nachbildung der Produktionsumgebung

Das Ziel der Testumgebung ist es, die Produktionsumgebung angemessen nachzubilden. Je genauer das Feature-Team für Anwendungskompatibilität die Produktionsumgebung nachbaut, desto aussagekräftiger sind die Tests in der Testumgebung.

Beachten Sie beim Erstellen einer Testumgebung die nachstehenden Empfehlungen:

  • Verwenden Sie virtuelle oder physische Abbilder der Produktionscomputer, und erstellen Sie auf der Grundlage dieser Abbilder die Gegenstücke in der Testumgebung. Virtuelle oder physische Abbilder sorgen mit dafür, dass die Konfiguration der Testumgebung die Produktionsumgebung so genau wie möglich wiedergibt. Darüber hinaus enthalten die Abbilder Liveinformationen (z. B. Benutzer, Benutzerprofile und Dateiberechtigungen), die bei den Tests herangezogen werden.

  • Trennen Sie die Testumgebung physisch von der Produktionsumgebung. Mit einer physisch getrennten Testumgebung ist das Feature-Team für Anwendungskompatibilität in der Lage, eine identische IP-Konfiguration zu verwenden und damit sicherzustellen, dass sich die Tests in der Testumgebung nicht auf die Produktionsumgebung auswirken. Die Verwendung derselben IP-Adresse, derselben Subnetze und derselben sonstigen Netzwerkkonfigurationsdaten trägt dazu bei, die größtmögliche Genauigkeit der Testumgebung zu gewährleisten. Das Duplizieren der IP-Adressen ist allerdings nicht immer die optimale Lösung, wenn die Anwendungen keine fest programmierte IP-Adresse nutzen. Unter Umständen sollten Sie einen Teil des Netzwerkdatenverkehrs von der Produktionsumgebung über den Router leiten, sodass weniger Netzwerkdienste repliziert werden müssen. Wenn Sie beispielsweise die Ports für DHCP öffnen, ist ein eigener DHCP-Server in der Testumgebung nicht erforderlich.

  • Stellen Sie sicher, dass in der Testumgebung dasselbe Service Pack und dieselbe Updateversion eingesetzt werden wie in der Produktionsumgebung. Falls das Feature-Team für Anwendungskompatibilität die Testumgebung schon vor einiger Zeit erstellt hat, ist die dort aktuelle Version der Service Packs und der Updates möglicherweise veraltet. Bevor Sie Anwendungsschutztests durchführen, sollten Sie die Testumgebung auf den neuesten Stand bringen. Installieren Sie hierzu die verfügbaren Service Packs und Updates, oder aktualisieren Sie die virtuellen oder physischen Abbilder der Computergegenstücke in der Produktionsumgebung. Erwägen Sie unter Umständen, die Testumgebung in den Änderungsverwaltungsprozess einzubinden, um so die Verfolgung der Aktualisierungen zu vereinfachen.

  • Führen Sie die Tests mit Benutzerkonten durch, für die ähnliche Berechtigungen gelten wie für die entsprechenden Konten in der Produktionsumgebung. Wenn die Benutzer im Unternehmen keine Administorrechte besitzen, weisen Sie den Benutzern in der Testumgebung die entsprechenden Rechte zu. Mit diesem Prozess wird sichergestellt, dass die Mitglieder des Feature-Teams für Anwendungskompatibilität alle Kompatibilitätsprobleme, die ggf. auch mit der Sicherheit zusammenhängen, sorgfältig testen.

Ermitteln Sie als Nächstes, welche Produktionscomputer in der Testumgebung nachgebildet werden sollen. Die Modellproduktionscomputer sollten die folgenden Merkmale aufweisen:

  • Teil der Netzwerkinfrastruktur (DHCPS, DNS, WINS, andere Netzwerkinfrastrukturdienste), es sei denn, das Feature-Team für Anwendungskompatibilität plant, diese Dienste aus dem Produktionsnetzwerk in die Testumgebung zu übernehmen

  • Teil der Remotezugriffsinfrastruktur (Routing- und RAS-Dienste, Internetauthentifizierungsdienste)

  • Teil der Active Directory Infrastruktur (Domänencontroller, DNS-Dienste)

  • Teil der Messaging-Infrastruktur (Front-End-Server, Back-End-Server und Bridgeheadserver mit Microsoft Exchange Server)

  • Teil des Extranets des Unternehmens (Webserver, Firewalls)

  • Einbindung in den Anwendungsbestand zu einem früheren Zeitpunkt im Prozess

Konfigurieren der Testumgebung für automatisierte Tests

In den meisten Fällen muss das Feature-Team für Anwendungskompatibilität die Schutzstrategien mehrfach testen. Automatisieren Sie diese Tests so weit wie möglich, damit die Reproduzierbarkeit und die Konsistenz des Testvorgangs gewährleistet sind.

Darüber hinaus sollte das Feature-Team für Anwendungskompatibilität dafür sorgen, dass die Konfiguration der Testumgebung vor Beginn der Tests wiederhergestellt werden kann, damit die Teammitglieder denselben Test in derselben Konfiguration wiederholen können. Wird die Wiederherstellung der Testumgebung in einem früheren Zustand automatisiert, können die Teammitglieder ihre Tests problemlos auf der Grundlage derselben Daten und derselben Konfiguration durchführen.

Die Mitglieder des Feature-Teams für Anwendungskompatibilität können Folgendes automatisieren:

  • Ausführen der Testfälle mithilfe von zugekauften oder selbst entwickelten Testautomatisierungstools Weitere Informationen zum Entwickeln eines Testautomatisierungstools finden Sie im Artikel über die kompakte Automatisierung von Tests einer Benutzerumgebung mit .NET unter http://msdn.microsoft.com/msdnmag/issues/05/01/TestRun (auf Englisch).

  • Die Testumgebung lässt sich mithilfe der folgenden Elemente in einen früheren Zustand zurückversetzen:

    • Software für die Abbilderstellung von Datenträgern für physische Abbilder der Server

    • Softwarevirtualisierungsfeatures, mit denen Änderungen an virtualisierten Festplatten rückgängig gemacht werden können (z. B. die Einstellungen für das Rückgängigmachen von Aktionen auf dem Datenträger in Virtual PC 2004 und Virtual Server 2005)

Ermitteln des richtigen Zeitpunkts für die Virtualisierung

Mit Virtual PC 2004 und Virtual Server 2005 kann das Feature-Team für Anwendungskompatibilität virtualisierte Server auf Computern erstellen und ausführen, auf denen Windows Vista bzw. Windows Server 2003 ausgeführt wird. Eines der Hauptziele dieser Produkte liegt darin, das Anlegen von Testumgebungen zu vereinfachen.

Die Virtualisierung bietet die folgenden Vorteile:

  • Unterstützung zahlreicher Server in begrenztem physischem Rackplatz In vielen Umgebungen bieten die Racks nur wenig Platz zum Einbau physischer Computer. Das Feature-Team für Anwendungskompatibilität kann so viele virtuelle Server ausführen wie die Ressourcen des physischen Computers ermöglichen (z. B. Speicher, mehrere Prozessoren, freier Speicherplatz).

  • Die gemeinsame Verwendung einer Testumgebung durch mehrere Teams ist deutlich einfacher. Sobald eine Testumgebung erstellt wurde, kann das Feature-Team für Anwendungskompatibilität diese Umgebung für andere Teams freigeben. Das TestFeature-Team kann beispielsweise eine virtualisierte Testumgebung anlegen und eine Kopie dieser Testumgebung im Entwicklungsrollencluster bereitstellen, die dann im Entwicklungsprozess verwendet wird.

  • Mehrere Entwickler oder Tester können gleichzeitig Tests durchführen. In herkömmlichen Testumgebungen müssen die Benutzer meist um den Zugriff auf die Testumgebung „kämpfen“. Durch die Virtualisierung der Server erhält jeder Benutzer potenziell eine eigene Testumgebung. Auf diese Weise werden die Test- und Entwicklungsprozesse rationalisiert.

  • Die Konfiguration der virtualisierten Server lässt sich leicht in einen früheren Zustand zurückversetzen. Der Großteil der Virtualisierungssoftware bietet eine Möglichkeit, Änderungen an den virtualisierten Festplatten rückgängig zu machen (z. B. die Einstellungen für das Rückgängigmachen von Aktionen auf dem Datenträger in Virtual PC 2004 und Virtual Server 2005). Mit diesem Feature ist das Feature-Team für Anwendungskompatibilität in der Lage, einen früheren Zustand der Serverkonfiguration wiederherzustellen. Wenn die Teammitglieder dieselben Arbeitsabläufe wiederholt durchführen müssen, können sie mit diesem Feature die Umgebung rasch wiederherstellen.

Nachteile der Virtualisierung:

  • Die virtualisierten Server sind langsamer als ihre physischen Gegenstücke. Virtualisierte Server sind bedeutend langsamer, weil ein Großteil der physischen Ressourcen (z. B. Datenträger) virtualisiert sind. Vor allem Aktivitäten im Zusammenhang mit den Datenträgern laufen in virtualisierten Umgebungen bedeutend langsamer ab.

  • Hardwarespezifische Gerätetreiber und Anwendungen werden bei virtualisierten Servern nicht unterstützt. In einigen Fällen müssen die Mitglieder des Feature-Teams für Anwendungskompatibilität die Kompatibilität der hardwarespezifschen Gerätetreiber und Anwendungen testen. Die virtualisierten Server nutzen virtualisierte Gerätetreiber, mit denen die jeweiligen physischen Gegenstücke emuliert werden. Der Zugriff auf sämtliche Hardwareressourcen erfolgt über diese virtualisierten Gerätetreiber.

Testen der Schutzstrategien

Sobald die Konfiguration der Testumgebung feststeht, ermitteln Sie die zu testenden Schutzstrategien. Das Feature-Team für Anwendungskompatibilität muss sämtliche Strategien testen, die zu Beginn des Prozesses im Anwendungsportfolio benannt wurden.

So testen Sie die Schutzstrategien:

  • Stellen Sie die Testmatrix auf. (Diese Matrix enthält die Liste der zu testenden Anwendungen sowie die Kriterien zum Ermitteln der Kompatibilität.)

  • Stellen Sie die Testumgebung bereit, in der die Schutzstrategien getestet werden sollen.

Erstellen der Testmatrix

In der Testmatrix sind die Tests definiert, die das Feature-Team für Anwendungskompatibilität durchführt. Außerdem ist hier festgelegt, wie der Erfolg (oder das Fehlschlagen) der einzelnen Tests bestimmt wird. Die Testmatrix liefert eine Vorlage für die Durchführung der Tests und fungiert zudem als primäres Mittel zur Weitergabe der Testverfahren zwischen dem Entwicklungsrollencluster und dem Testrollencluster.

So erstellen Sie die Testmatrix:

  • Kategorisieren Sie die Anwendungen, die das Feature-Team für Anwendungskompatibilität testet, sodass die Teammitglieder deren Priorität im Testverfahren ermitteln können.

  • Legen Sie die Kriterien fest, die den Erfolg beim Schutz vor Inkompatibilitäten bei Anwendungen bestimmen.

Weitere Informationen zum Erstellen der Testmatrix und zu den Teststrategien finden Sie im Handbuch für das TestFeature-Team.

Kategorisieren der zu testenden Anwendungen

Das Feature-Team für Anwendungskompatibilität muss die zu testenden Anwendungen kategorisieren, sodass die Teammitglieder diese Anwendungen auf der Grundlage der Priorität und Komplexität der Schutzmaßnahmen testen können.

Kategorisieren Sie die Anwendungen innerhalb der Testmatrix gemäß den folgenden Punkten:

  • Anwendungspriorität

  • Anwendungsschutzstatus, beispielsweise:

    • Anwendungen mit bekannten Kompatibilitätsproblemen und entsprechenden Schutzmaßnahmen

    • Anwendungen mit bekannten Kompatibilitätsproblemen ohne entsprechende Schutzmaßnahmen

    • Anwendungen mit unbekannten Kompatibilitätsproblemen

Erstellen Sie die Testmatrix mit einem Tool (z. B. Microsoft Office Excel 2003), das eine Sortierfunktion bietet und diese Anwendungen in diese Kategorien und Unterkategorien einteilen kann.

Festlegen der Kriterien für die Kompatibilität

Geben Sie in der Testmatrix die Kriterien für den erfolgreichen Schutz vor Kompatibilitätsproblemen an. Legen Sie dabei für jede Anwendung, die vom Feature-Team für Anwendungskompatibilität getestet wird, die folgenden Punkte fest:

  • Arbeitsschritte, die die Mitglieder während der Tests durchführen

  • Richtige Reaktionen auf die einzelnen Schritte

Wenn eine Anwendung diese Kriterien erfüllt, gilt diese Anwendung als kompatibel.

Bereitstellen der simulierten Testumgebung

Zu Beginn des Prozesses hat das Feature-Team für Anwendungskompatibilität die Infrastruktur und die Computer definiert, die für die Tests erforderlich sind. Darüber hinaus hat das Team die Teile der Testumgebung ermittelt, die auf virtualisierten Computern ausgeführt werden können bzw. auf physischen Computern getestet werden müssen.

Stellen Sie die Testumgebung in jedem Fall mithilfe der (virtuellen oder physischen) Abbilder bereit, die in der Produktionsumgebung angelegt wurden, unabhängig vom tatsächlich eingesetzten Verfahren. Das Feature-Team für Anwendungskompatibilität kann Abbilder erstellen, sodass sich die physischen Server mit einer Software zur Erstellung von Datenträgerabbildern wiederherstellen lassen.

Für die virtualisierten Computer in der Testumgebung ist das Feature-Team für Anwendungskompatibilität mithilfe verschiedener Tools in der Lage, virtuelle Abbilder physischer Server in der Produktionsumgebung zu erstellen, z. B. mit dem Virtual Server Migration Toolkit. (Weitere Informationen zum Virtual Server Migration Toolkit finden Sie im Artikel über das Virtual Server 2005 Migration Toolkit unter http://www.microsoft.com/windowsserversystem/virtualserver/evaluation/vsmt.mspx [auf Englisch].)

Erstellen der Anwendungsschutzpakete

Als Endergebnis des Testprozesses entstehen Anwendungsschutzpakete, die im Unternehmen bereitgestellt werden. Diese Pakete lassen sich mithilfe der Anwendungstools auch automatisch erstellen (z. B. die Schutzmaßnahmen aus ACT). Bei anderen Anwendungsschutzmaßnahmen legen Sie die Pakete und die Installationsskripts bzw. die EXE-Dateien an (auch MSI-Dateien).

So erstellen Sie die Anwendungsschutzpakete:

  • Automatisches Erstellen der Pakete

  • Manuelles Erstellen der Pakete

Automatisches Erstellen der Pakete

In vielen Fällen lassen sich mit den verwendeten Anwendungskompatibilitätstools automatisch Anwendungsschutzpakete erstellen. Diese Pakete können dann auf den entsprechenden Zielcomputern bereitgestellt werden.

Verpacken Sie die Lösungen für die Bereitstellung in der Test- und Produktionsumgebung wahlweise mit Solution Builder aus ACT 4.1 oder mit Application Compatibility Manager aus ACT 5. Die Komponente Packagerin Solution Builder kann eine beliebige Anzahl von ADQ-Dateien aus Analyzer oder von SDB-Dateien aus Compatibility Administrator annehmen und daraus ein selbstextrahierendes ausführbares Paket erstellen. Anschließend kann das Feature-Team für Anwendungskompatibilität dieses ausführbare Paket zur Problembehebung bei den Anwendungen bereitstellen.

Die EXE-Pakete aus Packager umfassen Schutzmaßnahmen, die als Reaktion auf Probleme in den folgenden Produkten zusammengestellt wurden:

  • Compatibility Administrator

  • Firewall Compatibility Evaluator

  • DCOM Compatibility Evaluator

Das Feature-Team für Anwendungskompatibilität muss diese Schutzmaßnahmen, die in anderen Tools (z. B. IECE) ermittelt und erstellt werden, manuell verpacken.

Manuelles Erstellen der Pakete

Werden Schutzmaßnahmen nicht mit automatisierten Tools ermittelt und erstellt, stellen Sie die zu installierenden Pakete manuell zusammen. In einigen Fällen umfasst dieser Prozess das Erstellen von Skripts oder MSI-Dateien, um so die Installation zu vereinfachen.

Stellen Sie Folgendes für die Pakete sicher:

  • Die Pakete lassen sich in die Bereitstellungsabbilder eingliedern.

  • Die Pakete werden separat auf den vorhandenen Zielcomputern bereitgestellt.

Das Verfahren für die Installation auf dem Zielcomputer muss beide Bereitstellungsszenarios unterstützen. Ein Anwendungsschutztool (z. B. IECE) kann beispielsweise REG-Dateien erstellen, mit denen die Konfigurationseinstellungen von Internet Explorer geändert werden. Beim Erstellen eines Pakets für die REG-Datei fallen die folgenden Schritte für die Mitglieder des Feature-Teams für Anwendungskompatibilität an:

  1. Skript schreiben bzw. MSI-Datei entwickeln, mit der die folgenden Aufgaben erledigt werden:

    • REG-Datei am richtigen Speicherort ablegen

    • „regedit“ für die REG-Datei ausführen, um so die Konfigurationseinstellungen auf dem Zielcomputer zu ändern

  2. MSI-Datei in das Anwendungspaket im Bereitstellungsabbild aufnehmen oder MSI-Datei mithilfe des ausgewählten Verfahrens zur Softwareverteilung bereitstellen

Meilenstein: Anwendungsschutzmaßnahmen erstellt

Meilensteine sind Synchronisierungspunkte für die Gesamtlösung. Weitere Informationen finden Sie im Planungs-, Entwicklungs-und Bereitstellungshandbuch (auf Englisch).

An diesem Meilenstein hat das Feature-Team für Anwendungskompatibilität die notwendigen Anwendungsschutzpakete entwickelt (vgl. Tabelle 6).

Tabelle 6: Ergebnisse der Entwicklungsphase

Meilenstein in Entwicklungsphase

Beschreibung der Ergebnisse

Besitzer

Testumgebung erstellt

Die Testumgebung wird als Nachbildung der Produktionsumgebung angelegt. In der Testumgebung werden zu einem späteren Zeitpunkt in der Entwicklungsphase verschiedene Schutzstrategien getestet und Anwendungsschutzpakete erstellt.

Entwicklung

Zu testende Schutzstrategien ermittelt

Die Schutzstrategien, die in der Testumgebung getestet werden müssen, sind ermittelt. Darüber hinaus steht der Testplan für die einzelnen Schutzstrategien fest.

Test

Anwendungsschutzpakete erstellt

Die Problembehebungen für die Anwendungskompatibilität sind in einem Paket vereint, das sich in die Betriebssystemabbilder eingliedern oder auch separat bereitstellen lässt.

Entwicklung

Teamkonsens erreicht und Bestätigung des Teams eingeholt

Alle Beteiligten am BDD 2007-Projekt erklären den Konsens für die Begrenzung aller Probleme im Zusammenhang mit der Anwendungskompatibilität sowie für künftige Projektmeilensteine.

Produktmanagement

Anzeigen: