Share via

  • Artikel

Testen von vom Benutzer initiierten Vorgängen unter Verwendung von Project Professional (Project Server 2010)

 

Gilt für: Project Professional 2010, Project Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

In diesem Artikel geht es um Vorgänge mit Microsoft Project Professional als Haupt-Benutzerschnittstelle. Die am häufigsten ausgeführten Vorgänge, die zu dieser Kategorie gehören, sind folgende:

  • Ein Projekt öffnen

  • Ein Projekt speichern

  • Ein Projekt veröffentlichen

Dieser Artikel wurde neu veröffentlicht. Wenn Sie uns Ihr Feedback senden, können wir Ihnen die bestmögliche technische Dokumentation bieten. Bitte senden Sie Kommentare, Fragen oder Anregungen zu der Dokumentation an epmdocfeedback@microsoft.com.

Microsoft Project Server 2010 unterstützt nicht die Ausführung mehrerer Instanzen in der gleichen Benutzersitzung. Daher benötigen Sie zum Testen vieler gleichzeitiger Benutzer Terminaldienste, es sei denn, Sie haben Dutzende von Servern. Andererseits kann der Visual Studio 2008 Test Agent nicht in mehreren Sitzungen in der gleichen Benutzersitzung instanziiert werden. Dies würde die Integration von Project Professional-Tests in Visual Studio Team System 2008 Test Edition erschweren. Wir haben jedoch ein communitybasiertes Tool entwickelt, mit dem Project Professional-Tests innerhalb von mehreren Terminaldienste-Sitzungen automatisiert werden können. Dieses Tool steht unter Microsoft Project 2010: Belastungstests mit Project Server (https://go.microsoft.com/fwlink/?linkid=190625\&clcid=0x407) in der MSDN Code Gallery zur Verfügung. Mit dem Tool Thick Client Test Framework wird eine Architektur mit Controllern und Agents implementiert, die konzeptionell gesehen der Architektur von Visual Studio 2008 Test Edition ähnelt. In beiden übermittelt der Controller per Push Informationen in eine SQL Server-Datenbank, während Agents per Pull Auftragsinformationen und Aktualisierungsstatusinformationen in Bezug auf ihre Aufträge aus der gleichen Datenbank abrufen. Jeder Auftrag setzt sich aus mehreren Vorgängen zusammen, die mithilfe von benutzerdefinierten .NET-Komponenten unter Nutzung des Project Professional-Clientobjektmodells implementiert sind.

Die drei in den folgenden Absätzen beschriebenen Project Professional-Tests werden mit dem Test Framework-Tool implementiert. Die Datenerfassung erfolgt weiterhin mit Visual Studio Team System 2008 Test Edition, das gleichzeitig ausgeführt wird.

Zugreifen auf die Project Web App-Homepage

Sie können mit dem Tool Webtestaufzeichnung, das in Visual Studio 2008 verfügbar ist, alle HTTP-Anforderungen aufzeichnen, die generiert werden, wenn ein Benutzer auf die PWA-Homepage zugreift. Sobald Sie den Webtest aufgezeichnet haben, richten Sie die Anmeldeinformationen ein, um verschiedene Benutzer im Lastszenario zu simulieren. Anschließend lassen Sie Visual Studio für jeden Testlauf nach dem Zufallsprinzip einen Benutzer aus einer Liste auswählen. Sie können Benutzeranmeldeinformationen an eine Datenquelle binden, die Daten aus einer Datenbank, einer XML- oder einer CSV-Datei oder einer beliebigen anderen geeigneten Datenquelle lesen kann. Beispielsweise können Sie die oben beschriebene Datei Resources.xml als Datenquelle für Benutzeranmeldeinformationen verwenden. Nach dem gleichen Schema können Sie auch für alle anderen Tests vorgehen.

Öffnen von Projekten

Der Beispielcode im Thick Client Test Framework in der Lösung "Belastungstests mit Project Server 2010" zeigt, wie das Öffnen eines Projekts in Microsoft Project Professional automatisiert werden kann. Der Code wird vom Test Framework-Agent dynamisch geladen und ausgeführt. Die Open-Funktion erhält zwei Parameter als Eingabe. Der erste Parameter ist der Dateiname des zu öffnenden Projekts. (Wird "*" als Dateiname verwendet, wählt die Funktion automatisch der Reihe nach ein Project aus der serverseitigen Liste aus.) Der zweite Parameter ist ein boolescher Wert, der angibt, ob das Projekt schreibgeschützt oder mit Lese-/Schreibzugriff geöffnet werden soll. Die Funktion gibt die Zahl der Millisekunden zurück, die der Vorgang beansprucht hat, bzw. null im Falle eines Fehlers. Die zwei Parameter lassen sich über die Benutzeroberfläche des Controllers festlegen.

Speichern von Projekten

Der Ressourcencenter-Test ist dem Projektcenter-Test sehr ähnlich, da er ebenfalls das JavaScript-Steuerelement Grid enthält.

Zugreifen auf die Seite "Eigene Vorgänge"

Microsoft Project Professional sendet beim Speichern nur die tatsächlichen Änderungen an den Server. Wollen Sie einen aussagekräftigen Speicherungstest durchführen, müssen Sie daher einige Änderungen an einem geöffneten Projekt vornehmen, bevor Sie dieses wieder speichern. Dabei sind Ihrer Fantasie keine Grenzen gesetzt. Ändern Sie z. B. den Anfangstermin des Projekts. Das wirkt sich typischerweise auf sämtliche Vorgänge im Projekt aus und verursacht somit eine umfangreiche Änderung, die gespeichert werden kann.

Der Beispielcode in der Test Framework-CodePlex-Lösung zeigt mehrere Beispielfunktionen. Diese können Sie durch Definieren eines Workflows in der Controlleranwendung so konfigurieren, dass sie nacheinander ausgeführt werden. Im Folgenden zwei Beispiele:

  1. Eine ChangeStartDate-Funktion, die ein zufälliges Datum im Bereich [heute ± 30 Tage] auswählt und den Projektanfangstermin auf das zufällig ausgewählte Datum festlegt

  2. Eine Save-Funktion, die das aktive Projekt sichert; die Funktion erhält einen booleschen Parameter als Eingabe, mit dessen Hilfe der Speichervorgang übersprungen werden kann, wenn das aktive Projekt schreibgeschützt geöffnet wird.

Beide Funktionen geben die Zahl der Millisekunden zurück, die der Vorgang beansprucht hat, bzw. null im Falle eines Fehlers.

Veröffentlichen von Projekten

Der Beispielcode im Thick Client Test Framework in der Lösung "Belastungstests mit Project Server 2010" zeigt, wie das Veröffentlichen eines Projekts automatisiert werden kann. Die Publish-Funktion erhält drei Parameter als Eingabe. Der erste Parameter ist ein boolescher Wert, der angibt, ob das gesamte Projekt (true) oder nur die Änderungen (false) veröffentlicht werden. Der zweite Parameter gibt die URL für die optionale URL für den bereitzustellenden Projektarbeitsbereich an. Der dritte Parameter ist ein boolescher Wert, der angibt, ob der Publish-Vorgang übersprungen werden muss, falls das geöffnete Projekt schreibgeschützt ist. Die Funktion gibt die Anzahl der Millisekunden zurück, die der Vorgang beansprucht hat, bzw. null im Falle eines Fehlers.