PowerShell: Testautomatisierung von MS Office

Testautomatisierung: Wir kennen das Problem

Man stelle sich das vor: Ein unbezahlter und dementsprechend unmotivierter Praktikant sitzt schweigend vor seinem Rechner und verzieht keine Miene. Sein Chef hat ihm vor fünf Minuten die Aufgabe gegeben, 45 Word-Vorlagen des Kunden „durchzuklicken“. Und er langweilt sich jetzt schon. Klick, klick. Einen Praktikanten fragt man natürlich nicht, ob ihm das eventuell zu einem unbekannten und weit entfernten Zeitpunkt Spaß machen würde, stundenlang irgendwelche Knöpfe zu drücken. Und seine Motivation ist sozusagen direkt proportional zum Testergebnis: Es fehlen Screenshots, die Tests an sich sind lückenhaft und er hat ein Template vergessen zu testen. Klick, klick, klick. Eine Stunde für ein Dokument mal 45 Versionen ergibt über eine Woche Arbeitszeit – die unvermeidlichen Schlafpausen nicht mit eingerechnet. Das macht selbst dem hartgesottensten Praktikanten keinen Spaß mehr. Aber der Chef kommt selbst nicht im Traum auf die Idee, die Tests zu reduzieren. „Qualitätssicherung!“ ist das Stichwort, das dem Prakti ins Auge piekt. Wenn der Praktikant aber ein bisschen Programmierkenntnisse besitzt, kann er durchaus eine entspanntere Woche vor sich sehen.

Scripting mit Windows PowerShell

Windows – wie macht man da nochmal einfache Scripts? Ja, logisch: Mit Batchdateien! Aber diese Technologie scheint wohl doch mittlerweile etwas in die Jahre gekommen zu sein. Gut, Versuch Nummer zwei: Windows Scripting Host gibt es in den Sprachen JScript und VBScript. Und damit kann man schon einiges mehr anstellen. Zusätzlich zu den aus diesen Sprachen bekannten Programmierkonstrukten kann man über die COM-Schnittstellen Objekte initiieren und hat somit einen weit größeren Horizont. Aber ist das im Jahr 2016 der neueste Stand der Dinge? Lassen Sie es mich mal so sagen: Nein. Windows Scripting mit PowerShell ist das, was Microsoft zur Verfügung gestellt hat. Und das gibt es nicht erst seit dem letzten Jahr, sondern seit 2006. Und das beste daran ist, dass die PowerShell mit Windows 7 bereits ausgeliefert wird. Bedeutet auch für den Praktikanten: Junge, du kannst mit dem Scripten sofort loslegen und damit nicht nur mit der Win32 API spielen sondern auch. NET-Objekte wie Legosteinchen zusammenbauen, bis etwas Brauchbares dabei herauskommt. Und in diesem Fall am besten eine Testautomatisierung.

UI Automation: Elemente finden

Na dann mal los! Der Praktikant – geben wir ihm doch bitte endlich den Namen Patrick – ist kein unbeschriebenes Blatt. Er hat schon einmal mit Visual Studio programmiert und kennt WinSpy. Seine Augen beginnen zu leuchten: Entweder 45 Stunden stumpfes Herumgeklicke oder fröhliches Coden beim gemütlichen Tässchen Kaffee. Patrick macht Word auf und inspiziert mit WinSpy die Elemente des Word-Fensters. Wie jetzt?! Da WinSpy die Attribute der visuellen Elemente nur über die Win32-API auslesen kann, erkennt er nur ganz wenige, unbrauchbare. Damit geht es also schon mal nicht.

Glücklicherweise hat Microsoft die UI Automation Library veröffentlicht. Diese ermöglicht es einem Programm, nicht nur auf die WinSpy-Art nach Objekten in Fenstern zu suchen, sondern kann noch eine Reihe anderer Schnittstellen bedienen und damit auch diese neumodischen Ribbons in Word ansprechen. So weit, so gut. Wir haben also eine Skriptumgebung mit der PowerShell und eine API zum Arbeiten mit Elementen in allen möglichen und vor allem unmöglichen Windows-Applikationen. Jetzt muss man die zwei Kerlchen nur noch miteinander verheiraten. Das UIAutomation-Paket auf Codeplex ist die Verbindung der beiden, bis der Stromausfall sie scheidet.

Patricks Hände werden schon ganz schwitzig, während er die Zip-Datei herunterlädt und entpackt. Er macht ein PowerShell-Fenster auf und tippt den Befehl zum Importieren des UIAutomation-Moduls:

ipmo C:\Users\swuser\Desktop\UIAutomation.0.8.7B3.NET35\UIAutomation.dll

Es scheint so, als ob die Windows-PowerShell auch ehrfürchtig verstummt: Keine Fehler, der Import hat also geklappt. Jetzt erwarten unseren Praktikanten eine Reihe von Befehlen. Probieren geht über Studieren – das hat er ja bereits in seiner Laufbahn gelernt. Deswegen tippt er ein …

Get-Uia

und drückt ein paar mal die Tabulator-Taste. Befehle wie Get-UiaWindow, Get-UiaButton und Get-UiaCustom sind in der langen Liste der UIAutomation-Bibliothek dabei. Damit kann er Fenster und Elemente herausfiltern, sich im Elementbaum bewegen um dann bestimmte Actions auszuführen. Lass mal sehen … vielleicht irgendwas mit Invoke-:

Invoke-UiaButtonClick

Ja, das muss es sein! Einen Button anklicken! Das soll bloß der dumme Computer machen und nicht der unbezahlte Praktikant. Also gut, kurz nachgelesen, wie man die Objekte von A nach B übergibt und Actions auslöst und schon hat man sein erstes kleines Script geschrieben, welches einen Button im Menü in Word anklickt. Und dadurch, dass die Windows PowerShell von Microsoft nur Objekte kennt, kann man so einen Button nicht nur drücken, sondern ihn auch fragen, wie er heißt, wo er lebt und wo seine Eltern sind. Man kann sich also von Objekt zu Objekt hangeln und kann somit genau das Element heraussuchen, welches man mit WinSpy schmerzlich vermisst hat!

Praktikant Patrick ist begeistert! Er erhebt sich von dem Bürostuhl, der ihm vor einer halben Stunde fast als fahrbares Bett gedient hat und geht diesmal energiegeladen zum Chef. „Herr Chef, es gibt da etwas, was uns eine Menge Zeit sparen würde …“

PowerShell Scripting und die UI Automation Library von Microsoft machen aber nicht nur Patrick Spaß, sondern auch mir. Und nicht nur sein Vorgesetzter ist von seiner Idee begeistert, sondern auch mein Chef. Deswegen freue ich mich, Ihr Automatisierungskonzept mit Ihnen zusammen durch zusprechen und Ihnen einiges an langweiligen Testzeiten zu ersparen.