MSDN Magazin > Home > Ausgaben > 2007 > October >  Testlauf: Testautomatisierung mit Windows ...
Testlauf
Testautomatisierung mit Windows XP Embedded
Dr. James McCaffrey and Mike Hall

Codedownload verfügbar unter: TestRun2007_10.exe (1402 KB)
Browse the Code Online
Haben Sie jemals mit dem Betriebssystem Windows® XP Embedded gearbeitet? Es ist im Wesentlichen eine für Entwickler angepasste, abgespeckte Version des Betriebssystems Windows XP, das auf PC-ähnlichen Geräten ausgeführt werden soll: Spielekonsolen, Informationskiosks, Netzwerkgeräte und so weiter. Aufgrund des raschen Zuwachses bei der Verwendung mobiler und eingebetteter Geräte wird diese Plattform zunehmend wichtiger.
Ich habe entdeckt, dass es zwischen Softwaretestingenieuren und Softwareentwicklern, die mit den auf Windows XP Embedded basierenden Softwaresystemen arbeiten, so etwas wie eine Wissenslücke gibt. In diesem Artikel werde ich von Mike Hall unterstützt, um diese Lücke zu überbrücken. Mike ist Senior Product Manager in der Arbeitsgruppe Mobile and Embedded Devices von Microsoft® und Fachmann in Bezug auf Windows XP Embedded. Gemeinsam erläutern wir die Erstellung von einfachen und dennoch leistungsfähigen automatischen Benutzeroberflächentests für Softwaresysteme, die unter Windows XP Embedded ausgeführt werden.
Mithilfe eines Screenshots lässt sich am besten zeigen, wie wir vorgehen werden. Abbildung 1 zeigt einen einfachen automatischen Test einer Benutzeroberfläche in Aktion. Aus dem Screenshot geht jedoch nicht sofort hervor, dass die Automatisierung auf einem Gerät ausgeführt wird, auf dem Windows XP Embedded ausgeführt wird.
Abbildung 1 Automatische Tests einer Benutzeroberfläche unter Windows XP Embedded (Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie sich Abbildung 1 genau ansehen, erkennen Sie, dass der automatische Test einer Benutzeroberfläche eine simple aber repräsentative, formularbasierte Windows-Anwendung verwendet, die mit einer Anwendung auf Kioskgeräten vergleichbar ist, auf dem Windows XP Embedded ausgeführt wird. Die Testautomatisierung ist eine Konsolenanwendung, die:
  • die zu testende formularbasierte Anwendung startet und sie manipuliert
  • eine Produktsuche mit dem Text „idg“ im Produktnamen simuliert
  • den resultierenden Anwendungszustand auf „111“ untersucht
  • ein Testszenarioergebnis ermittelt
Die Testautomatisierung manipuliert die zu testende Anwendung im Hintergrund mithilfe des P/Invoke-Mechanismus von Microsoft .NET Framework, um Win32® API-Funktionen wie FindWindow, SendMessage und GetMenu aufzurufen.
In dem Artikel diesen Monats wird die zu testende Anwendung kurz erläutert. Danach wird die Testautomatisierung betrachtet, die die Ergebnisse in Abbildung 1 erbracht hat. Danach wird ausführlich beschrieben, wie die Tools von Windows Embedded Studio verwendet werden können, um ein Windows XP Embedded-System zu erstellen, das die Anwendung und die Testautomatisierung relativ unkompliziert umfasst. Außerdem wird eine anspruchsvollere Technik betrachtet, die die Testautomatisierung als benutzerdefinierte Windows XP Embedded-Shell erstellt. Zuletzt wird noch kurz darauf eingegangen, wie die hier vorgestellten Ideen an Ihre individuellen Bedürfnisse angepasst und erweitert werden können.
Wenn Sie nicht mit Windows XP Embedded vertraut sind, bietet dieser Artikel eine hervorragende Einführung in eine interessante Technologie. Wenn Sie mit auf Win32 basierender Benutzeroberflächenautomatisierung ebenfalls nicht vertraut sind, die eine .NET Framework-Schnittstelle verwendet, ist dieser Artikel eine gute Einführung in die Technik.

Die getestete Anwendung
Im Folgenden wird der zentrale Code für die zu testende formularbasierte Windows-Anwendung betrachtet – dem Herzstück eines typischen Windows XP Embedded-Softwaresystems. Der Codedownload, der diesen Artikel ergänzt, enthält den gesamten Code für die Anwendung und die Testautomatisierung. Wie in Abbildung 1 dargestellt, besitzt die nachgebildete Anwendung grundlegende Benutzersteuerelemente, einschließlich eines TextBox-Steuerelements, eines ComboBox-Steuerelements, eines Button-Steuerelements, und eines ListBox-Steuerelements. In einem realen Szenario würde eine Windows XP Embedded-Suchanwendung vermutlich Suchergebnisse von einem Datenbankserver oder vielleicht einem Webdienst abrufen. Hier verwendet die Anwendung einen lokalen Datenspeicher in Form einer einfachen Produktklasse:
public class Product
{
    public string id, name, price;

    public Product(string id, string name, string price)
    {
        this.id = id; this.name = name; this.price = price;
    }
}
Die Daten für Produktinstanzen werden in einer ArrayList-Sammlung gespeichert und bereitgestellt, wenn das zentrale Form-Objekt geladen wird:
private ArrayList al = new ArrayList();
private void Form1_Load(object sender, System.EventArgs e)
{
    Product p1 = new Product("111", "Widget", "$11.11");
    Product p2 = new Product("222", "Gadget", "$22.22");
    Product p3 = new Product("333", "Thingy", "$33.33");
    al.Add(p1); al.Add(p2); al.Add(p3);
}
Da eine Benutzeroberflächenautomatisierung durchgeführt werden soll, ist es unwichtig, wo oder wie die Suchanwendung ihre Daten abruft – es spielt keine Rolle, wo die Ergebnisdaten herkommen, sie werden sich in der Benutzeroberfläche der Anwendung widerspiegeln. Diese kann daraufhin untersucht werden, ob das Testszenario erfolgreich abgeschlossen wurde oder fehlgeschlagen ist. Die gesamte Anwendungslogik befindet in der click-Methode des Steuerelements der Suchschaltfläche. Die Anwendung beginnt mit einer groben Überprüfung, ob der Benutzer ein Suchkriterium eingegeben hat, etwa eine Produkt-ID oder eine Produktbeschreibung. Wenn nicht, löst die Anwendung ein MessageBox-Fenster mit einer Fehlermeldung aus:
if (comboBox1.Text == "" || textBox1.Text == "") {
    MessageBox.Show("You must enter search criteria and term",           
                    "Error");
}
listBox1.Items.Clear();
Nach dem Löschen des ListBox-Steuerelements, das die Suchergebnisse enthält, ruft die Anwendung die Suchkriterien/Zielzeichenfolge ab und durchläuft den ArrayList-Datenspeicher, um nach Übereinstimmungen zu suchen:
string filter = textBox1.Text;
if (comboBox1.Text == "Product ID") {
    foreach (Product p in al) {
        if (p.id.IndexOf(filter) >= 0) {
            listBox1.Items.Add(p.id + " " + p.name + " " + p.price);
        }
    }
}
else if (comboBox1.Text == "Product Name") {
    // search by Name similarly
}
Hier wird absichtlich kein guter Programmierstil verwendet, damit der Code kurz und verständlich bleibt und auch, um die relative Ungeschliffenheit einer Anwendung in den frühen Phasen der Entwicklung zu simulieren. In Wirklichkeit enthält das Beispielprogramm mehrere erhebliche Logikfehler, nach denen Sie gerne suchen dürfen.
Wenn Sie noch nicht mit Windows XP Embedded vertraut sind, fragen Sie sich vielleicht, „Was hat diese Anwendung mit Windows XP Embedded zu tun? Sie sieht wie eine ganz gewöhnliche, formularbasierte Windows-Anwendung aus.“ Ihre Beobachtung wäre korrekt, und dies ist ein wichtiger Punkt. Da Windows XP Embedded im Wesentlichen eine in Komponenten gegliederte Version von Windows XP ist, lässt sich das gesamte Entwicklungswissen direkt übertragen. Dadurch erhält Windows XP Embedded einen enormen Vorteil gegenüber alternativen Entwicklungsplattformen für eingebettete Geräte. Sie müssen sich nicht in eine vollständig neue Plattform und in einen Toolsatz einarbeiten, Sie können auf eine große Supportcommunity zugreifen, Sie können die Leistungsfähigkeit der .NET Framework-Bibliothek nutzen und, wie in diesem Artikel erläutert, können Sie leistungsfähige Testautomatisierungsverfahren verwenden.

Die Testautomatisierung
Es gibt mehrere Möglichkeiten, automatische Tests für Benutzeroberflächen zu erstellen. Bei der hier verwendeten Technik wird eine Testumgebung zu einer C#-Konsolenanwendung geschrieben, die die zu testende formularbasierte Anwendung manipuliert, indem sie mithilfe der P/Invoke-Methode systemeigene Win32-API-Funktionen aufruft. Im Testlaufartikel von September 2005 über detaillierte automatische Tests einer Benutzeroberfläche (verfügbar unter msdn.microsoft.com/msdnmag/issues/05/09/testrun), wird dieses Thema ausführlich beschrieben.
Die Testautomatisierung wird begonnen, indem die zu testende Anwendung mithilfe der statischen Start-Methode aus der Process-Klasse im Namespace „System.Diagnostics“ gestartet wird:
Console.WriteLine("\nLaunching Windows application");
Process p = Process.Start(".\\TheAppToTest.exe");
Beachten Sie, dass der Beispielcode davon ausgeht, dass sich die ausführbare Datei der zu testenden Anwendung im gleichen Verzeichnis befindet wie die ausführbare Datei der Testumgebung. Sie werden bald erkennen, dass dieser Entwurf für die Testautomatisierung auf Windows XP Embedded-Systemen besonders geeignet ist. Nachdem die zu testende Anwendung gestartet wurde, wird die Win32-Funktion FindWindow verwendet, um ein Handle zum Form-Objekt der zu testenden Anwendung zu erhalten, wie Abbildung 2 zeigt.
Console.WriteLine("\nLooking for Form1");
IntPtr ptrToForm;
bool formFound = false;
int numTries = 0;
while (!formFound && numTries < 100) {
    ++numTries;
    ptrToForm = FindWindow(null, "Form1");
    if (ptrToForm == IntPtr.Zero) {
        Console.WriteLine("Form1 not found yet. . . ");
        Thread.Sleep(100);
    }
    else {
        formFound = true;
        Console.WriteLine("Form1 found with ptr = " + 
            ptrToForm.ToString());
    }
}
if (numTries >= 100) throw new Exception("Form was not found");
Das Herzstück des P/Invoke-Verfahrens ist das Importieren der Win32-Funktion FindWindow. Dies geschieht, indem ein DllImport-Attribut in der Testumgebung platziert wird:
[DllImport("user32.dll", EntryPoint = "FindWindow", 
           CharSet = CharSet.Auto)]
static extern IntPtr FindWindow(
    string lpClassName, string lpWindowName);
Dieses Attribut lässt sich in etwa wie folgt interpretieren: „Importiere eine Win32-Funktion aus der user32.dll-Bibliothek. Die Win32-Funktion heißt FindWindow (obwohl das System auch die mit gleichem Namen prüfen sollte, die mit einem „A“ oder „W“ enden). Verarbeite ASCII- und Unicode-Zeichencodierungsprobleme automatisch. Der C#-Alias ist eine statische Methode, die einen .NET-Typ IntPtr zurückgibt, der das Handle zu einem Fenster repräsentiert. Der C#-Alias heißt FindWindow und akzeptiert zwei Zeichenfolgenargumente: den Namen der Fenstersteuerelementklasse und den Anzeigenamen des Steuerelements.“
Das Programm in Abbildung 2 sucht nach dem Form-Fenster. Wenn das Form-Fenster nicht gefunden wird (in der Regel da das Form-Objekt noch nicht initialisiert hat), wartet der Code 100 Millisekunden und versucht es dann erneut. Wenn das Form-Objekt nach 100 Versuchen nicht gefunden wurde, löst die Testautomatisierung eine Ausnahme aus. Nachdem die Automatisierungsumgebung die zu testende Anwendung gestartet hat, manipuliert die Umgebung das Form-Objekt, indem das Formular verschoben und dessen Größe geändert wird. Beispiel:
Console.WriteLine("\nMoving Form1 around");
SetWindowPos(ptrToForm, IntPtr.Zero, 100, 200, 336, 404, 0);
Hier wird die Win32-Funktion SetWindowPos verwendet, um die linke obere Ecke des Form-Objekts an den Bildschirmkoordinaten (100,200) zu positionieren und die Breite auf 336 Pixel und die Höhe auf 404 Pixel einzustellen.
Das zugeordnete DllImport-Attribut für den C#-Alias lautet:
[DllImport("user32.dll", EntryPoint = "SetWindowPos")]
static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter,
    int x, int y, int cx, int cy, uint uFlags); 
Nachdem das Form-Objekt manipuliert wurde, erhalten wir Handles für die untergeordneten Fenstersteuerelemente des Formulars. Der Testumgebungscode, mit dem ein Handle für das button1-Steuerelement abgerufen wird, sieht beispielsweise so aus:
Console.WriteLine("Looking for button1");
IntPtr btn = FindWindowEx(ptrToForm, IntPtr.Zero, null, "Search");
if (btn == IntPtr.Zero)
    throw new Exception("Could not find search button");
else
    Console.WriteLine("button1 found with ptr = " + butt.ToString());
Hier wird die Win32-Funktion FindWindowEx verwendet, um ein Handle eines untergeordneten Steuerelements mit dem Name-Attribut „Suche“ zu erhalten.
Der Code, mit dem ein Handle für das TextBox-Steuerelement abgerufen wird, ist etwas kniffliger:
Console.WriteLine("\nLooking for textBox1");
IntPtr tb = FindWindowByIndex(ptrToForm, 3);
if (tb == IntPtr.Zero)
    throw new Exception("Could not find textBox");
else
    Console.WriteLine("textBox1 found with ptr = " + tb.ToString());
Hier wird eine äußerst praktische, im Programm definierte Methode mit dem Namen „FindWindowByIndex“ verwendet.
Obwohl einige Fenstersteuerelemente Name-Attribute haben (wie z. B. Form1), haben viele keines. Wenn Sie ein Handle für ein Fenstersteuerelement erhalten möchten, das nicht benannt wurde, können Sie FindWindowByIndex verwenden, das folgendermaßen definiert ist:
static IntPtr FindWindowByIndex(IntPtr hwndParent, int index)
{
    int ct = 0;
    IntPtr result = IntPtr.Zero;
    do {
        result = FindWindowEx(hwndParent, result, null, null);
        if (result != IntPtr.Zero) ++ct;
    } while (ct < index && result != IntPtr.Zero);
    return result;
}
Denn obwohl einige Fenstersteuerelemente kein Name-Attribut haben, besitzen alle Fenstersteuerelemente eine implizite Indexziffer. Mit der Win32-Funktion FindWindowEx und der impliziten Indexziffer eines Steuerelements kann ein Handle des Steuerelements abgerufen werden. Die implizite Indexziffer eines Fenstersteuerelements stimmt nicht mit der Reihenfolge der Registerkartensteuerelemente überein. Die implizite Indexziffer wird durch die Reihenfolge bestimmt, in der das Fenstersteuerelement einem übergeordneten Fenster hinzugefügt wurde. Deshalb wird in diesem Beispiel FindWindowByIndex (ptrToForm, 3) festgelegt, weil der Code der zu testenden Anwendung folgendes enthält:
this.label1 = new System.Windows.Forms.Label();       // index 0
this.label2 = new System.Windows.Forms.Label();       // 1
this.comboBox1 = new System.Windows.Forms.ComboBox(); // 2
this.textBox1 = new System.Windows.Forms.TextBox();   // 3 <-
this.button1 = new System.Windows.Forms.Button();
// etc. 
Der verbleibende Code in der Testumgebung manipuliert die zu testende Anwendung, indem Zeichen an das TextBox-Steuerelement gesendet werden, indem auf das Button-Steuerelement geklickt wird, indem auf die Anzeige einer MessageBox gewartet wird, die einen Fehler meldet, indem auf die Schaltfläche „OK“ geklickt wird und so weiter. Die Testumgebung schließt ab, indem sie den Inhalt des ListBox-Steuerelements untersucht und entscheidet, ob das Szenario als bestanden oder fehlgeschlagen einzuordnen ist.

Übertragen des automatischen Tests einer Benutzeroberfläche auf ein Windows XP Embedded-System
Ein zentrales Konzept in Windows XP Embedded-Systemen ist der Begriff von der Betriebssystemshell, im Gegensatz zu einer Shellanwendung, die unter einem Betriebssystem ausgeführt wird Jedes auf Windows basierende Betriebssystem darf nur genau eine primäre Shellschnittstelle haben. Auf dem üblichen Windows XP-Betriebssystem zum Beispiel ist die Explorer-Shell in der Regel die primäre Shell, obwohl es auch mehrere Anwendungsshells geben kann, wie z. B. die Befehlsshell „cmd.exe“, die Windows PowerShell®-Shell und so weiter. Da Windows XP Embedded eine konfigurierbare, in Komponenten gegliederte Version von Windows XP ist, sind Sie nicht darauf beschränkt, die Explorer-Shell als primäre Shell zu verwenden. Aus den verschiedenen Shells kann eine beliebige als primäre Shell ausgewählt werden, und es kann sogar eine benutzerdefinierte primäre Shell erstellt werden.
In der Sidebar „Testautomatisierung als benutzerdefinierte Shell“ wird demonstriert, wie der automatische Test einer Benutzeroberfläche auf ein Windows XP Embedded-System übertragen werden kann, wenn Sie sich dafür entschieden haben, eine nicht-benutzerdefinierte primäre Shell zu verwenden. Im nächsten Abschnitt wird ein anspruchsvolleres Verfahren zum Portieren der Testautomatisierung dargestellt, wenn eine benutzerdefinierte primäre Shell verwendet wird.
In der Dokumentationsterminologie bezieht sich „Gerät“ entweder auf die Komponenten, auf denen Windows XP Embedded ausgeführt wird (z. B. einem Informationskiosk) oder auf ein einzelnes Hardwareelement (wie eine Maus, eine Tastatur oder ein Anzeigenadapter). In diesem Beispiel ist das Zielgerät ein Laptop-PC. In einem realistischeren Szenario wäre das Zielgerät wahrscheinlich etwas weniger PC-ähnlich, vielleicht ein Gerät mit einer kleineren Tastatur oder einem kleinen Monitor. Die Entwicklungsprinzipien für Windows XP Embedded sind jedoch identisch.
Das Zielgerät für unser Beispiel hat eine einzelne physische Festplatte mit einer C:-Partition und einer D:-Partition. Das Ziel ist, das Windows XP Embedded-System auf die D:-Partition zu kopieren. Mit Windows Embedded Studio können Sie ein Windows XP Embedded-System erstellen. Das Programm stellt eine Toolsammlung sowie eine Back-End-Datenbank mit Softwarekomponenten bereit. Die Windows XP Embedded-Tools werden in der Regel nicht auf dem Zielgerät installiert. Sie werden auf einem Entwicklungscomputer installiert (auf dem im Allgemeinen Windows XP ausgeführt wird). Dort wird ein Systemabbild für das benutzerdefinierte Windows XP Embedded-Betriebssystem und die Anwendung auf dem Entwicklungscomputer erstellt, und anschließend wird das Abbild dem Zielgerät bereitgestellt.
Zunächst kann es etwas verwirrend sein, ein Abbild von Windows XP Embedded zu erstellen, doch nach einigen Wiederholungen wird das Verfahren verständlich. Bevor die Details anhand eines konkreten Beispiels vorgestellt werden, erhalten Sie einen kurzen Überblick über den Prozess. Der erste Schritt beim Erstellen eines Abbilds ist, die einzelnen Hardwaregeräte auf dem Zielgerät mithilfe eines Dienstprogramms namens „Target Analyzer Probe“ zu analysieren, das im Windows XP Embedded-Toolset enthalten ist Im nächsten Schritt werden die Windows XP Embedded-Komponenten mithilfe eines Tools mit dem Namen „Component Designer“ erstellt (gleich mehr darüber). Im dritten Schritt werden die Komponenten zusammengestellt und in ein Windows XP Embedded-Abbild integriert. Im vierten Schritt wird das Abbild dem Zielgerät bereitgestellt. Wie Sie sehen, ist der Prozess im Prinzip recht einfach.
Nun zu den Details zum Erstellen automatischer Tests für eine Benutzeroberfläche unter Windows XP Embedded. Als Erstes werden die Hardwareelemente auf dem Zielgerät mithilfe von Target Analyzer Probe analysiert (tap.exe, es gibt auch eine ta.exe, die auf 16-Bit Systemen verwendet werden kann). Es genügt, das Dienstprogramm „tap.exe“ auf das Zielgerät zu kopieren. Wie dieser Kopiervorgang durchgeführt wird, hängt davon ab, welche E/A-Geräte auf dem Zielgerät vorhanden sind. (Beachten Sie, dass das Dienstprogramm „tap.exe“ Windows 2000 oder Windows XP erfordert. Alternativ kann der Installationsdatenträger von Windows XP Embedded verwendet werden, der aus diesem Grund startbar ist).
Nachdem tap.exe auf das Zielgerät kopiert wurde, kann es einfach ausgeführt werden. Das Ergebnis ist eine Datei namens „devices.pmq“ (von Insidern oft „Pumpkin-Datei“ genannt, wegen der Dateinamenerweiterung „pmq“), die in dem gleichen Verzeichnis wie tap.exe gespeichert wird. Diese Datei enthält eine Liste aller Hardwareelemente, die auf dem Zielgerät gefunden wurden. Da die Datei im XML-Format vorliegt, kann sie mit jedem Texteditor gelesen und daraufhin überprüft werden, ob alle Hardwaregeräte gefunden wurden. Ferner kann die Datei ggf. manuell erstellt oder bearbeitet werden. Nachdem devices.pmq erstellt wurde, kopieren Sie sie vom Zielgerät auf den Entwicklungscomputer.

Erstellen von Komponenten
Die nächsten paar Schritte umfassen das Erstellen der Komponenten mithilfe eines Tools namens „Component Designer“, das auf einer grafischen Benutzeroberfläche beruht. Eine Windows XP Embedded-Komponente kann als Paket verwandter Software angesehen werden. Beachten Sie, dass in diesem Artikel „Komponente“ (mit großem K) verwendet wird, wenn es um ein Windows XP Embedded-Paket geht und „komponente“ (mit kleinem k), wenn es ganz allgemein um eine Elementsammlung geht.
Windows XP Embedded-Tools arbeiten mit Komponenten anstatt mit einzelnen Dateien, da die Verwaltung der großen Zahl von Dateien, die in einem Windows XP Embedded-Abbild enthalten sind, unhandlich ist. Es müssen zwei benutzerdefinierte Windows XP Embedded-Komponenten erstellt werden: eine kapselt die formularbasierte Anwendung und deren konsolenbasierte Testautomatisierung ein, die andere kapselt die entsprechenden Hardwaregerätetreiber ein.
Bereiten Sie dies vor, indem Sie ein Verzeichnis „C:\Automation“ auf dem Entwicklungscomputer erstellen und TheAppToTest.exe (die Anwendung) und Demo.exe (die Automatisierung) in diesem Verzeichnis platzieren. Dies ist nicht absolut notwendig, doch wie bald gezeigt wird, ist es eine bequeme Herangehensweise zur Erstellung einer Testautomatisierungskomponente.
Als Erstes wird gezeigt, wie die Testautomatisierungskomponente erstellt wird. Danach wird die Erstellung der Gerätetreiberkomponente erklärt. Beginnen Sie damit, das Tool „Component Designer“ über das Startmenü des Desktop zu starten. Wählen Sie dann im Hauptmenü „Datei“ | „Neu“ aus. Die Konfiguration kann als AutoTestAutomationComponent.sld (dies wird in der Regel Foliendatei genannt) in jedem geeigneten Verzeichnis gespeichert werden (über „Datei“ | „Speichern“). Werden jedoch die .sld-Konfigurationsdateien im gleichen Verzeichnis gespeichert wie die Ressourcendateien der Komponente, wird die ganze Komponente übertragbar, da sich alle Dateien in demselben Verzeichnis befinden.
Erweitern Sie das Element Windows XP Embedded Client (x86) im linken Navigationsbereich des Component Designers. Erstellen Sie jetzt das Repository-Objekt für die Testautomatisierungskomponente. Ein Repository ist so etwas wie ein physischer Speicher für die Dateien, die eine Komponente ausmachen. Klicken Sie einfach mit der rechten Maustaste auf das Repository-Element, und wählen die Option zum Hinzufügen des Repository aus. Geben Sie dem Repository im rechten Datenbereich den Namen „AutoTestAutomationRepository“, und ändern Sie die Eigenschaft „Quellpfad“ in C:\Automation, um den Speicherort der Automatisierungsdateien auf dem Entwicklungscomputer (im Gegensatz zum endgültigen Speicherort auf dem Zielgerät) anzugeben. Es gibt viele weitere Repository-Attribute, die jetzt festgelegt werden können. Doch um die Sache nicht unnötig kompliziert zu gestalten, werden diese jetzt außer Acht gelassen.
Begeben Sie sich jetzt wieder in den linken Navigationsbereich des Component Designers, klicken Sie mit der rechten Maustaste auf Komponenten, und wählen Sie „Komponente hinzufügen“ aus. Zu diesem Zeitpunkt sollte der linke Fensterbereich von Component Designer so aussehen wie der Bildschirm in Abbildung 3, und der rechte Fensterbereich so wie der Bildschirm in Abbildung 4. Im rechten Fensterbereich des Bereichs „Komponenteneigenschaften“ können Sie erkennen, dass das Name-Attribut der Komponente auf AutoTestAutomationComponent gesetzt wurde.
Abbildung 3 Der linke Fensterbereich von Component Designer 
Abbildung 4 Der rechte Fensterbereich von Component Designer (Klicken Sie zum Vergrößern auf das Bild)
Klicken Sie als Nächstes auf die Schaltfläche „Repositories“, um das Repository zuzuordnen, das Sie soeben zusammen mit der Komponente erstellt haben. Wählen Sie im Dialogfeld zum Auswählen des Repository den Eintrag „AutoTestAutomationRepository“ aus, und klicken Sie auf „OK“. Die meisten Windows XP Embedded-Objekte, einschließlich Repositories, besitzen eine Revisionsnummer, die automatisch an den Objektnamen angefügt wird. Dies ist sehr hilfreich beim Organisieren der Objekte. Fügen Sie jetzt im linken Fensterbereich Verweise auf die physischen Dateien hinzu, indem Sie mit der rechten Maustaste auf das Element „Dateien“ klicken und dann „Hinzufügen“ | „Mehrere Dateien“ auswählen. Navigieren Sie in dem Dialogfeld zum Hinzufügen von Ressourcen der Komponentendatei zu der Anwendung und den Automatisierungsdateien auf dem Entwicklungscomputer (in diesem Fall zu C:\Automation), wählen Sie mithilfe der <STRG>-Taste die Dateien „TheAppToTest.exe“ und „Demo.exe“ aus, und klicken auf „Öffnen“.
Jetzt wird eine Komponentenabhängigkeit hinzugefügt. Da in diesem Beispiel sowohl die formularbasierte Anwendung als auch die konsolenbasierte Testautomatisierung auf dem .NET Framework 2.0 erstellt wurden, muss das endgültige Windows XP Embedded-Abbild eine .NET Framework 2.0-Komponente enthalten. Indem diese Abhängigkeit explizit angegeben wird, können Sie das Target Designer-Tool (das, wie Sie sich erinnern, alle Komponenten zu einem endgültigen, funktionierenden Windows XP Embedded-Abbild kombiniert) implizit anweisen, die .NET Framework 2.0-Komponente zu integrieren. Klicken Sie mit der rechten Maustaste auf das Element der Komponenten- oder Gruppenabhängigkeit und wählen dann „Hinzufügen“ | „Komponentenabhängigkeit“ aus. (Im nächsten Abschnitt dieses Artikels wird erklärt, was eine Gruppenabhängigkeit ist). Jetzt stellt der Component Designer eine Verbindung mit einer Back-End-Komponentendatenbank her, die als Teil der Windows XP Embedded Studio-Tools installiert wurde.
Navigieren Sie im Dialogfeld zum Hinzufügen der Komponentenabhängigkeit zu „Software“ | „System“ | „Systemdienste“ | „Andere“, wählen Sie die .NET Framework 2.0-Komponente aus (wie in Abbildung 5 gezeigt), und klicken Sie auf „OK“. Je nachdem, welche Version des Windows XP Embedded-Toolsets Sie verwenden, müssen Sie die .NET Framework 2.0-Komponente eventuell separat installieren. Die Liste der Komponenten ist dynamisch und wächst: Windows XP Embedded hat eine große Supportcommunity, in der sich auch Ingenieure von Drittanbietern und -unternehmen engagieren, und natürlich Microsoft selbst.
Abbildung 5 Hinzufügen der Komponentenabhängigkeit (Klicken Sie zum Vergrößern auf das Bild)
Zu diesem Zeitpunkt ist die Testautomatisierungskomponente vollständig. Speichern Sie deshalb die .sld-Konfiguration, und schließen Sie Component Designer. Jetzt muss die angepasste Komponente mithilfe des Tools „Component Database Manager“, das über das Startmenü des Desktop gestartet wird, in die Back-End-Datenbank übertragen werden. Nachdem das Tool eine Verbindung zur Back-End-Datenbank hergestellt hat, klicken Sie auf der Hauptregisterkarte der Datenbank auf die Schaltfläche „Importieren“. Suchen Sie im Dialogfeld zum Importieren der SLD nach der .sld-Datei (in diesem Fall AutoTestAutomationComponent.sld), und klicken Sie dann auf „Importieren“. Das geht sehr schnell, und nachdem Sie die Protokollmeldungen geprüft haben, klicken Sie auf „Schließen“ und noch einmal auf „Schließen“. Die Testautomatisierungskomponente ist jetzt im Tool „Target Designer“ verfügbar.
Jetzt müssen Sie die zweite Komponente erstellen. Diese kapselt alle Gerätetreiber und weitere Software ein, die zur Unterstützung der einzelnen Hardwarekomponenten auf dem Zielgerät erforderlich ist. Dank der Datei „devices.pmq“, in der die gesamte Hardware des Zielgeräts aufgeführt ist, ist dies ein sehr einfacher Vorgang. Starten Sie das Component Designer-Tool erneut, klicken Sie aber diesmal auf „Datei“ | „Importieren“. Navigieren Sie in dem Dialogfeld, in dem Sie die Datei zum Importieren auswählen, zu der Datei „devices.pmq“, und klicken Sie auf „Öffnen“. Ein Dialogfeld „Datei importieren“ wird angezeigt. Klicken Sie einfach auf die Schaltfläche „Starten“. Der Importvorgang dauert mehrere Minuten, da Component Designer nicht nur die XML-Daten aus devices.pmq importiert. Tatsächlich analysiert er die Datei und legt fest, welche Programmdateien notwendig sind, um die Hardwaregeräte zu unterstützen. Aus diesen Informationen erstellt er eine Komponente. Mit anderen Worten, der größte Teil der Arbeit beim Erstellen einer einmaligen Testautomatisierungskomponente, den Sie manuell erledigen müssten, wird für die Hardwarekomponente automatisch erledigt. Es sollte eine Meldung angezeigt werden, dass der Import erfolgreich abgeschlossen wurde. Daraufhin können Sie das Dialogfeld „Datei importieren“ schließen.
Wenn Sie das Element „Komponenten“ erweitern und das Geräteelement auswählen, können Sie die Komponente in AutoHardwareComponent umbenennen. Speichern Sie die Konfiguration jetzt als AutoHardwareComponent.sld, und schließen das Tool „Component Designer“. Danach können Sie das Tool „Component Database Manager“ verwenden, um die Hardwarekomponente in die Back-End-Datenbank zu importieren, wie Sie dies für die Testautomatisierungskomponente durchgeführt haben.

Betriebssystemkomponenten
Nachdem die Testautomatisierungs- und Hardwarekomponenten erstellt wurden, können diese jetzt mit der Betriebssystemkomponente kombiniert werden, um ein Windows XP Embedded-Abbild zu erstellen. An dieser Stelle wird das Tool „Target Designer“ verwendet.
Starten Sie Target Designer über das Startmenü, und klicken Sie auf „Datei“ | „Neu“. Geben Sie der Konfiguration in dem daraufhin angezeigten Dialogfeld „Neue Konfiguration“ einen Namen, in diesem Beispiel AutoTestAutomation, und klicken Sie auf „OK“. Die Benutzeroberfläche von Target Designer besteht aus drei Hauptfensterbereichen. Im linken Fensterbereich werden die Komponenten aufgeführt, die zum Windows XP Embedded-Abbild hinzugefügt werden können. Im mittleren Fensterbereich sind die Komponenten aufgeführt, die derzeit im Abbild vorhanden sind. Im rechten Fensterbereich werden Informationen über alle Element angezeigt, die im linken oder mittleren Fensterbereich ausgewählt wurden.
Der linke Fensterbereich liest automatisch die Back-End-Datenbank aus und führt alle Komponenten auf, die Sie erstellt haben, in diesem Fall AutoHardwareComponent und AutoTestAutomationComponent. Fügen Sie die Hardwarekomponente hinzu, indem Sie mit der rechten Maustaste auf AutoHardwareComponent klicken und „Hinzufügen“ auswählen. Fügen Sie dann AutoTestAutomationComponent auf die gleiche Art und Weise hinzu (die Reihenfolge spielt dabei keine Rolle).
Nachdem Sie die beiden benutzerdefinierten Komponenten hinzugefügt haben, müssen Sie die zentralen Betriebssystemkomponenten hinzufügen. Obwohl Sie Tausende verfügbarer Komponenten (in der Regel mehr als 10.000) untersuchen könnten, ist es erheblich einfacher, eine vorkonfigurierte meta-Komponente zu verwenden. Erweitern Sie das Element „Entwurfsvorlagen“ im linken Fensterbereich von Target Designer, um mehrere Optionen aufzuzeigen. Wählen Sie für dieses Beispiel die Vorlage „Windows-based Terminal Professional“ aus, klicken Sie anschließend mit der rechten Maustaste darauf, und wählen Sie „Hinzufügen“ aus. Dadurch wird eine große Anzahl individueller Softwarekomponenten hinzugefügt, die auf einem PC-ähnlichen Gerät häufig verwendet werden. Es sind mehrere Vorlagen erhältlich, einschließlich Retail Point of Sale Terminal, Home Gateway, Network Attached Storage usw. Der Nachteil bei der Verwendung einer Komponentenvorlage ist, dass Sie sehr wahrscheinlich Komponenten erhalten werden, die Sie nicht wirklich benötigen. Ein guter Ansatz ist, eine Vorlage einfach als Ausgangspunkt zu verwenden und dann alle unnötigen Komponenten zu entfernen.
Klicken Sie im mittleren Fensterbereich auf „Einstellungen“, und klicken Sie dann im rechten Fensterbereich auf „Einstellungen des Zielgeräts“ | „Anzeigen“. Diese Einträge beziehen sich auf das Zielgerät, nicht auf den Entwicklungscomputer. In diesem Fall sollte C: deshalb das Startlaufwerk bleiben, doch ändern Sie C: in den Einträgen des Windows-Ordners, des Ordners „Programme“ und des Ordners „Dokumente und Einstellungen“ in D:. Wie bereits erwähnt, soll das Abbild von Windows XP Embedded auf die D:-Partition der einzigen Festplatte des Geräts kopiert werden.
Ändern Sie den Pfadeintrag Boot ARC von multi(0)disk(0)rdisk(0)partition(1) in multi(0)disk(0)rdisk(0)partition(2). Die rdisk-Komponenten (physische Laufwerke) sind 0-basiert, aber die Partitionselemente sind 1-basiert. Ändern Sie außerdem die Größe der Startpartition in 5.000 (MB). Dies ist ein magischer Wert für jede Startpartition, die 5 GB oder mehr umfasst. Wenn Sie beispielsweise einen Wert von 700 MB festlegen, können Sie potenziell eine startbare CD erstellen. Belassen Sie in diesem Beispiel die Größe des Partitionsclusters bei 4.096 Byte. Jetzt ist ein guter Zeitpunkt, die Konfiguration als AutoTestAutomation.slx zu speichern.

Erstellen des Abbilds
Testautomatisierung als benutzerdefinierte Shell
In einigen Fällen möchten Entwickler, die Windows XP Embedded verwenden, eine benutzerdefinierte primäre Shell implementieren. Stellen Sie sich zum Beispiel vor, die formularbasierte Anwendung in Abbildung 1 stellt die gesamte Benutzeroberfläche dar. Durch diesen Ansatz wird die Benutzeraktivität streng auf die Anwendung fokussiert, und im Allgemeinen wird die Interaktion mit Programmen wie Windows Explorer und Internet Explorer® verhindert. In einem Szenario mit einer benutzerdefinierten Shell funktionieren normale Testautomatisierungsverfahren nicht, da eine Betriebssystemshell nicht genau wie eine Anwendung gestartet werden kann.
Eine Lösung für die Testautomatisierung in einem Szenario mit einer benutzerdefinierten Shell mit Windows XP Embedded ist die Erstellung einer Testautomatisierungskomponente mithilfe der Windows Studio-Tools und die Konfiguration dieser Komponente als primäre Shell. Es folgt ein schneller Überblick über den Prozess. (Eine ausführliche Beschreibung zum Erstellen benutzerdefinierter Windows XP Embedded-Shells finden Sie in dem Artikel von Mike Hall über das Erstellen einer Windows XP Embedded-Shell unter msdn2.microsoft.com/ms 838335.)
Zum Erstellen einer benutzerdefinierten primären Shell für eine Testautomatisierung erstellen Sie zunächst mithilfe des Tools „Component Designer“ eine Testautomatisierungskomponente, und zwar genau so, wie in diesem Artikel beschrieben. Danach müssen im Component Designer vier Einstellungen konfiguriert werden, um die Komponente in eine spezielle primäre Shellkomponente umzuwandeln.
  1. Legen Sie die Eigenschaft Komponentenprototyp unter „Software“ | „System“ | „Benutzeroberfläche“ | „Shells“ | „Windows-Shells“ | „Shellprototypkomponente“ fest.
  2. Fügen Sie eine erweiterte Eigenschaft mit diesen Einstellungen hinzu: Name = cmiShellPath (Groß- und Kleinschreibung beachten), Format = String, und Value = \Automation\Demo.exe (zum Beispiel der Pfad zur Testautomatisierung).
  3. Legen Sie unter „Gruppenmitgliedschaften“ | „Gruppenmitgliedschaft hinzufügen“ | „Abhängigkeiten“ | „Shell“ eine Gruppenmitgliedschaft fest.
  4. Legen Sie unter „Gruppenmitgliedschaften“ | „Gruppenmitgliedschaft hinzufügen“ | „Software“ | „System“ | „Benutzeroberfläche“ | „Shells“ eine zweite Gruppenmitgliedschaft fest.
Nachdem Sie diese vier Einstellungen konfiguriert haben, um Ihre spezielle primäre Shellkomponente zu erstellen, wird die Komponente im Tool „Target Designer“ zusammen mit der Explorer-Shell, der Befehlsshell usw. als Benutzeroberflächenshell aufgeführt. Wenn Sie jetzt die benutzerdefinierte Komponente der Automatisierungsshell dem Abbild von Windows XP Embedded hinzufügen, stellen Sie fest, dass Sie ein Betriebssystem haben, das die Testautomatisierung unmittelbar startet und sich mit der zugeordneten formularbasierten Anwendung beschäftigt.

Sie sind nahezu bereit, die Komponenten in einem Abbild zu kombinieren. Doch bevor Sie sich an einem Build versuchen, sollten Sie die Komponentenabhängigkeiten prüfen und ermitteln, ob Sie unbeabsichtigt irgendeine erforderliche Konfigurationskomponente ausgelassen haben. Dies ist ein wichtiger Schritt. Ein Betriebssystem ist ein komplexes Stück Software, und ohne ein Tool wie Target Designer wäre das manuelle Bestimmen aller Komponentenabhängigkeiten sehr kompliziert.
Klicken Sie auf der Hauptmenüleiste auf „Konfiguration“ | „Abhängigkeiten überprüfen“. Ein Dialogfeld wird geöffnet und zeigt Informationen über den Fortschritt an. Die Abhängigkeitsprüfung importiert automatisch alle erforderlichen Komponenten in die Konfiguration. Nachdem die Abhängigkeitsprüfung abgeschlossen ist, können Sie das Dialogfeld schließen. In den meisten Fällen werden in einer Aufgabenliste im unteren Fensterbereich von Target Designer einige Fehler angezeigt. Wenn Sie mit der rechten Maustaste auf einen Fehler klicken, erhalten Sie eine Aktionsoption, die empfohlene Problembehebungen anbietet. Einer der Fehler in diesem Beispiel lautet „Länder- und Sprachoptionen erfordern wenigstens eine weitere aktivierte Komponente, die nicht in der Konfiguration enthalten ist“. Wenn Sie mit der rechten Maustaste darauf klicken und „Aktion“ auswählen, wird ein Dialogfeld zum Auflösen von Abhängigkeiten angezeigt, in dem Sie aus einer Liste von Sprachen Deutsch auswählen können. Klicken Sie dann auf Hinzufügen. Für dieses Beispiel sollten Sie auch eine NT Loader-Komponente, eine NTFS Format-Komponente und eine Explorer-Shell-Komponente hinzufügen, um die anderen Fehler aufzulösen.
Jetzt können Sie auf „Konfiguration“ | „Zielabbild erstellen“ klicken. Daraufhin wird ein Dialogfeld „Build“ mit dem Namen der Konfiguration (AutoTestAutomation.slx) angezeigt. Klicken Sie dann auf die Schaltfläche „Build“ klicken. Target Designer warnt Sie, dass Sie Änderungen an der Konfiguration vorgenommen haben – da Sie vier neue Komponenten hinzugefügt haben, um die Fehler aufzulösen, die von der Abhängigkeitsprüfung gefunden wurden – und fragt, ob Sie die Abhängigkeitsprüfung wiederholen möchten. Klicken Sie auf „Ja“. Es wird eine zweite Abhängigkeitsprüfung durchgeführt, die jedoch erheblich schneller vonstatten geht. Nachdem die zweite Abhängigkeitsprüfung beendet wurde, voraussichtlich ohne Fehler, kann das Dialogfeld der Abhängigkeitsprüfung geschlossen werden. Der Buildprozess beginnt.
Durch die Auswahl der Optionen „Tools“ | „Optionen“ | „Build“ in Target Designer können Sie den Standardspeicherort konfigurieren, an dem die Windows XP Embedded-Abbilder auf dem System gespeichert werden. Im Dialogfeld „Build“ kann ebenfalls ein Speicherort für einen bestimmten Build angeben werden. Beachten Sie: Wenn bereits ein Abbild von Windows XP Embedded vorhanden ist, werden Sie mit einer Warnung darauf hingewiesen, dass das vorhandene Abbild überschrieben wird. Das geht in der Regel in Ordnung.
Seien Sie nicht überrascht, wenn Sie einige Warnungen erhalten, nachdem der Build abgeschlossen wurde. Sie können diese überprüfen um sicherzustellen, dass es nur geringfügige Probleme sind (z. B. eine Warnung, dass Evaluierungssoftware verwendet wird), die getrost ignoriert werden können.

Bereitstellen des Abbilds
Jetzt kann das Windows XP Embedded-Abbild dem Zielgerät bereitgestellt werden. Das neue Abbild besteht aus vier Dateien und einem Verzeichnis mit vier Unterverzeichnissen. Drei dieser Dateien – boot.ini, ntdetect.com und ntldr – sind die zentralen Dateien, die erforderlich sind, um ein auf Windows XP basierendes Betriebssystem zu starten. Die vierte Datei, weruntime.ini, ist im Wesentlichen ein spezieller Windows XP Embedded-Schlüssel, mit Windows XP Embedded aktiviert wird.
Kopieren Sie diese vier Dateien vom Entwicklungscomputer auf das Startlaufwerk des Zielgeräts. Wie diese Dateien im Einzelnen kopiert werden, hängt davon ab, welche Arten von E/A-Geräten das Zielgerät besitzt. Da es sich bei dem Zielgerät in diesem Fall um ein Laptop mit einer regulären Windows XP-Installation auf dem Laufwerk C: handelt. kann das Zielgerät einfach gestartet werden, und die Dateien werden mithilfe des CD/DVD-Laufwerks kopiert. Das zentrale Windows XP Embedded-Abbild befindet sich in einem Verzeichnis mit dem Namen „DriveD“ (weil das Ziel auf dem Zielgerät das Laufwerk D: ist). Dieses Verzeichnis enthält drei Verzeichnisse: „Dokumente und Einstellungen“, „Programme“ und „Windows“. Außerdem gibt es ein Verzeichnis „Automation“, das die formularbasierte Anwendung (TheAppToTest.exe) und die konsolenbasierte Automatisierung (Demo.exe) enthält. Kopieren Sie diese vier Verzeichnisse auf die D:-Partition des Zielgeräts.
Bevor Sie versuchen, das Zielgerät hochzufahren, sollten Sie eine kleine Änderung vornehmen, um das Gerät mehrfach bootfähig zu machen. Bearbeiten Sie dazu einfach die Datei „boot.ini“ des Windows XP Embedded-Abbilds, indem Sie dem Abschnitt [Betriebssysteme] folgende Zeile hinzufügen:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect 
Dadurch kann auf der C:-Partition auf dem Zielgerät einfach eine reguläre Windows XP-Sitzung gestartet werden, falls mit dem Windows XP Embedded-Abbild auf der D:-Partition etwas schief gehen sollte. Alternativ können Sie eine Startdiskette für die Wiederherstellung erstellen, falls das Zielgerät über ein Diskettenlaufwerk verfügt. Sie können auch die Original-Installations-CD von Windows XP griffbereit halten und diese verwenden, um ggf. den Wiederherstellungsmodus zu starten.
Jetzt kommt der Moment der Wahrheit. Schalten Sie Ihr Zielgerät ein. Wenn das Windows XP Embedded-Abbild korrekt ist, startet das Zielgerät das benutzerdefinierte System. Ein spezieller Satz an Programmen, die zusammen FBA (First Boot Agent) genannt werden, initialisiert das System beim ersten Start (FBA wird bei nachfolgenden Starts nicht ausgeführt).
Jetzt kann die Testautomatisierung ausgeführt werden. Da bei diesem Beispiel eine Explorer-Shell-Komponente verwendet wird, besitzt das System eine grafische Benutzeroberfläche. Mit der Tastenkombination Windows-E können Sie Windows Explorer starten. Navigieren Sie zum Verzeichnis „D:\Automation“, und doppelklicken Sie auf die Datei „Demo.exe“, um die Testautomatisierung zu starten. Das Ergebnis sieht in etwa so aus wie der Screenshot in Abbildung 1. Alternativ können Sie die Komponente CMD – Windows-Befehlsprozessor in Ihr Windows XP Embedded-Abbild integriert werden. Dadurch erhalten Sie eine cmd.exe-Befehlsshell, mit der Sie die Testautomatisierung starten können.

Eine kurze Zusammenfassung
Wir fassen das bisher erkannte zusammen und erklären die Vorteile dieser Technik. Da Windows XP Embedded im Wesentlichen eine Version des Betriebssystems Windows XP ist, können Sie mithilfe bekannter Programmiertechniken leistungsfähige automatische Tests einer Benutzeroberfläche dafür erstellen.
Ein Ansatz zum Erstellen automatischer Tests einer Benutzeroberfläche für Windows XP Embedded-Systeme ist die Erstellung einer Komponente, die die primäre Anwendung und die entsprechende Testautomatisierung in einem Windows XP Embedded-Abbild enthält. Ein anderer Ansatz ist, ein normales Abbild ohne die Testautomatisierungskomponente zu erstellen und dann die Automatisierung separat an das Zielgerät zu übertragen.
Der Ansatz mit der Testautomatisierungskomponente bietet drei erhebliche Vorteile. Erstens: Durch das Erstellen einer Testautomatisierung werden die Tests modularisiert, wodurch sie leichter gewartet und verwaltet werden können. Zweitens: Die Back-End-Datenbank der Windows XP Embedded-Komponente kann sich auf einem Remoteserver befinden, eine Testautomatisierungskomponente kann von einem Team von Entwicklern und Testern einfach gemeinsam genutzt werden. Drittens: Durch das Erstellen einer Testautomatisierungskomponente können die potenziell komplexen Softwarabhängigkeiten einer Komponente automatisch von dem Tool „Target Designer“ geprüft werden.

Senden Sie Ihre Fragen und Kommentare (in englischer Sprache) an testrun@microsoft.com.


Dr. James McCaffrey arbeitet für Volt Information Sciences Inc. und organisiert technische Schulungen für Softwareentwickler auf dem Campus von Microsoft in Redmond, Washington. Er hat an verschiedenen Microsoft Produkten mitgearbeitet, unter anderem Internet Explorer und MSN Search. James McCaffrey ist der Autor von „.NET Test Automation Recipes“ (Apress, 2006). Sie erreichen James unter jmccaffrey@volt.com oder v-jammc@microsoft.com.

Mike Hall ist Senior Technical Product Manager in der Arbeitsgruppe Mobile and Embedded Devices von Microsoft. Mike arbeitet seit mehr als 10 Jahren für Microsoft und arbeitet derzeit mit Windows CE, Windows XP Embedded und Windows Embedded for Point of Service. Mike hält bei vielen Veranstaltungen von Microsoft und Drittanbietern Präsentationen ab und unterhält einen Blog, in dem es um eingebettete Technologien geht.

Page view tracker