UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler /

Transkript

1 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler /

2 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft Word, Excel, etc. 0% 1 Quelle: Brian Keller, Microsoft TechEd 2012

3 Manuelles Testen von Software (1) Typischerweise wird beim manuellen Testen direkt mit der Benutzeroberfläche der Software interagiert Häufig wird manuell getestet weil keine passende Toolunterstützung vorhanden ist Mögliche Reduktion der manuellen Testfälle durch den Einsatz von Microsoft Coded User Interface Tests

4 Manuelles Testen von Software (2) Es ist nicht immer sinnvoll alle manuellen Tests zu automatisieren In einer frühen Entwicklungsphase macht es evt. noch keinen Sinn in Automatisierung zu investieren da der Wartungsaufwand dafür zu gross sein kann Menschen eignen sich für manche Tests besser, z.b. Look & Feel einer Applikation, Überprüfung von Übersetzungen Gewisse Tests werden manuell durchgeführt Wie sollen solche Tests verwaltet werden?

5 Microsoft Test Manager (MTM) Microsoft Test Manager ist das von Microsoft verfügbare Testing Tool für manuelle Tests Ermöglicht die Erstellung, Verwaltung und Ausführung von Test Cases Basiert auf dem Microsoft Team Foundation Server (TFS) und kann nicht ohne TFS betrieben werden Ist für den Tester was Visual Studio für den Entwickler darstellt

6 Microsoft Test Manager (MTM) MTM ist ein Bestandteil von: Visual Studio 2012 Premium Visual Studio 2012 Ultimate Visual Studio Test Professional 2012

7 Test Cases und Bugs Test Cases und Bugs welche von MTM bearbeitet werden sind Work Items welche auf dem Team Foundation Server gespeichert werden Work Items sind generische, von TFS zur Verfügung gestellte Objekte um die Arbeit zu organisieren und den Projektstand zu überwachen Vollständige Bearbeitung und Ausführung von Test Cases wird nur in MTM unterstützt, Visual Studio bietet diese Funktionalität nicht

8 Verbinden von MTM mit TFS Angabe Team Gewünschten Project eines 1 Team Test muss Plan Foundation ausgewählt Servers werden auswählen ist Pflicht oder neuen Test Plan anlegen 1 Team Projects beinhalten den Quellcode und alle Work Items einer Applikation

9 Test Plan Ein Test Plan definiert was getestet werden und beinhaltet die dafür notwendigen Test Cases und deren Resultate Ein Test Plan ist zeitlich begrenzt, d.h. hat ein definiertes Anfangsund Enddatum In der Regel wird ein Test Plan für einen Release angelegt Bespiel: Ein Test Plan für MyApp 2.1 Wenn Team Foundation Build verwendet wird, kann einem Test Plan direkt ein von Team Foundation Build erzeugter Build zugewiesen werden ( MyApp , MyApp , etc.)

10 Test Plan Tests können auf einem via Name Area des Path Test zur Plans Lab Management Test Identifikation Start- Setting und definieren welcher Enddatum verwalteten Computer welche Bereich Informationen getestet wird automatisch ausgeführt während ein Test werden sofern die Tests ausgeführt Iteration zur wird automatisiert wurden Dem Test zeitlichen Plan Coded UI Tests Einordnung zugewiesener Build der Applikation welche mit diesem Plan getestet wird

11 Test Case Ein Test Case besteht immer aus einer Reihe von Schritten welche ausgeführt werden müssen und einem oder mehreren zugehörigen Resultaten Der Tester entscheidet ob ein Test Case erfolgreich oder fehlgeschlagen ist Sind auf dem Team Foundation Server gespeicherte Work Items

12 Test Case Tester Derjenige Product Tester Backlog der den Associated Items Automation Test Case welche ausführen durch den soll Test Test Cases können Dateien welche an den Test getestet werden Erwartetes automatisiert Resultat werden Case angehängt wurden Stimmt (Coded das UI erwartete Tests) Resultat Test Steps nicht mit dem tatsächlichen Die auszuführenden Resultat Schritte überein, ist der Test fehlgeschlagen

13 Test Suite Test Plans und Test Cases lassen sich mit Hilfe von Test Suites hierarchisch organisieren Typen 1. Static Test Suite Beliebige Test Cases und Test Suites lassen sich hinzufügen Static Test Suites können andere Test Suites und Test Cases beinhalten 2. Query based Test Suite Test Cases werden aufgrund einer Query automatisch hinzugefügt 3. Requirement Verlinkt Test Cases direkt mit Requirements (Scrum: Product Backlog Items)

14 Test Configuration Beschreibt die Umgebung die für das Ausführen von Test Cases benötigt wird, bzw. verwendet wurde Beispiele: Betriebssystem Browser (für Web Applikationen) Einstellungen einer Applikation

15 Test Configuration Einzelne Test Configurations werden aus Test Configuration Variables zusammengebaut

16 Test Point Jede Kombination eines Test Cases mit einer Test Configuration ergibt einen sogenannten Test Point Aus einem Test Case kann somit eine ganze Reihe von Test Points entstehen Sinnvoll wenn z.b. derselbe Test Case auf verschiedenen Betriebssystemen ausgeführt werden muss Test Points können ausgeführt werden

17 Ausführen von Tests Test Result speichern Fehlgeschlagener Test Step mit der Möglichkeit eine Fehlerbeschreibung anzugeben Status Test Configuration des gesamten mit Tests Test Steps welcher mit der Test Snapshot zugehörigem durchgeführt Kommentar Datei generieren an den zum aktiven Status wird aktiven Test Neuen Run Screenshot stoppen (vom Bug (Lab Test Tester anlegen Test Management) / pausieren generieren Step hinzufügen anhängen gesetzt) Test Run beenden Für die Ausführung des Tests benötigte Zeit

18 Action Recording Die vom Benutzer ausgeführten Schritte können vom Test Manager aufgezeichnet werden Mittels Wiedergabe kann der Test erneut abgespielt werden

19 Test Result Test Steps mit zugehörigen Resultaten Weitere Bugs können erfasst werden Bugs die mit dem Test Case Alle assoziiert Test Results sind die durch das Ausführen des Test Cases entstanden sind

20 Bugs erfassen Bugs können direkt mit Test Cases verknüpft werden. Um einen Bug zu reproduzieren bzw. einen Retest auszuführen kann direkt der Test Case ausgeführt werden. Präzise formulierte Test Cases vereinfachen die Reproduktion von Bugs. Der Ablauf zur Reproduktion ist bereits durch die Test Steps gegeben.

21 Bugs erfassen Die Test Steps und ihr Zustand wird automatisch Der erzeugte Bug ist in den Bug eingefügt direkt verknüpft mit dem Test Case mit dem er gefunden wurde

22 Demo

23 Reporting Jeder Test Plan hat eine integrierte Übersichtsseite

24 Parametrierte Test Cases (1) Derselbe Test soll mit mehreren, verschiedenen Datensätzen durchgeführt werden. Beispiel: Ein Bestellungs-Dialog soll getestet werden. Basierend auf der bestellten Menge wird automatisch der Preis berechnet. Je nach Menge soll Rabatt gewährt werden können. Der automatisch gerechnete Preis muss deshalb manuell angepasst werden können. Produkt bestellen Test Parameter: Quantität Preis Korrigierter Preis Produkt Äpfel Quantität Preis in CHF 48 Preis überschreiben

25 Parametrierte Test Cases (2) Parameter werden mit einem angelegt Eine Iteration pro Zeile, d.h. der Test Point wird für jede Zeile ausgeführt

26 Parametrierte Test Cases (3) Der Test Point verfügt über 3 Iterationen die der Reihe nach ausgeführt werden Die Werte der einzelnen Parameter werden für jede Iteration angezeigt Es wird nur die Iteration beendet. Der Test endet automatisch nach dem Ende der letzten Iteration oder wenn er manuell beendet wird

27 Parametrierte Test Cases (4) Ein Test Result eines parametrierten Test Cases verfügt über Details jeder einzelnen Iteration

28 Exploratives Testen Test Case kann aus der Aufzeichnung automatisch generiert werden

29 Test Impact Analysis (TIA) Mittels Test Impact Analysis kann automatisch ermittelt werden, welche Test Cases erneut ausgeführt werden sollten, basierend den getätigten Änderungen am Quellcode TIA ist nur nutzbar wenn Team Foundation Build genutzt wird um automatische Builds zu erzeugen TIA funktioniert nur für managed Code (.NET) Für obuscated binaries funktioniert TIA nicht

30 Test Impact Analysis Funktionsweise 1. Wenn ein Test in Microsoft Test Manager ausgeführt wird, merkt sich das System welche Codezeilen durchlaufen werden 2. Team Foundation Build ermittelt automatisch welche Änderungen am Code seit dem letzten Build hinzugekommen sind 3. Aufgrund dieser hinzugekommenen Änderungen wird ermittelt welche Test Cases betroffen sind 4. Wird im Test Manager auf einen neuen Build gewechselt, werden die betroffenen Test Cases automatisch zur erneuten Durchführung empfohlen

31 Fragen

32