{"id":1004,"date":"2012-10-09T08:00:00","date_gmt":"2012-10-09T06:00:00","guid":{"rendered":"https:\/\/www.formalmind.com\/blog\/manual-testing-pror\/"},"modified":"2022-04-11T18:58:55","modified_gmt":"2022-04-11T16:58:55","slug":"manual-testing-pror","status":"publish","type":"post","link":"https:\/\/www.formalmind.com\/de\/blog\/manual-testing-pror\/","title":{"rendered":"Manuelles Testen mit ProR"},"content":{"rendered":"

Automatisierte Tests sind gro\u00dfartig (wir nutzen sie \u2013 das RMF-Projekt derzeit l\u00e4uft \u00fcber 200 automatisierte Tests, alle erfolgreich<\/a>). Aber es gibt einige Situationen, in denen die Automatisierung von Tests einfach nicht lohnenswert ist \u2013 GUI-Tests sind ein Beispiel daf\u00fcr. Daher m\u00fcssen die manuellen Tests und ihre Ergebnisse irgendwo aufgezeichnet werden. Ein offensichtlicher, schneller Ansatz w\u00e4re die Verwendung einer Tabellenkalkulation. Aber es gibt Vorteile bei der Verwendung eines ausgefeilteren Werkzeugs wie ProR. Wir werden hier zeigen, wie dies realisiert werden k\u00f6nnte.<\/p>\n

\"\"

Testaufzeichnungen<\/h2>\n

Ein einfacher erster Ansatz w\u00e4re, eine Liste von Testbeschreibungen zu erstellen, mit einer Spalte f\u00fcr jeden Testlauf. Der folgende Screenshot zeigt, wie dies in ProR realisiert werden kann:<\/p>\n

\"\"

Die obere Leiste zeigt eine Tabelle mit drei Spalten: \u201cBeschreibung\u201d, \u201cErwartet\u201d und \u201c0.4.0\u201d. Die erste Spalte beschreibt kurz den Test, die zweite beschreibt das erwartete Ergebnis. Die Spalte \u201c0.4.0\u201d zeigt die Ergebnisse des Testlaufs f\u00fcr Version 0.4.0 (in der letzten Zeile wird gezeigt, wie der Wert aus einer Dropdown-Liste ausgew\u00e4hlt und nicht eingetippt wird).<\/p>\n

Wenn Sie die Eigenschaftenansicht (unterer Bereich) betrachten, sehen Sie, dass der Eintrag viele weitere Attribute hat, die nicht in der Tabellenansicht angezeigt werden. Dazu geh\u00f6ren fr\u00fchere Testl\u00e4ufe (0.1.0 bis 0.3.0). Diese werden f\u00fcr Audits aufbewahrt, w\u00fcrden aber nur die Tabellenansicht un\u00fcbersichtlich machen. Wenn eine neue Version f\u00fcr die Ver\u00f6ffentlichung vorbereitet wird, wird ein neues Attribut (0.5.0) erstellt und in der Tabellenansicht angezeigt. 0.4.0 w\u00fcrde aus der Tabellenansicht entfernt, k\u00f6nnte aber nat\u00fcrlich jederzeit \u00fcber die Eigenschaftenansicht aufgerufen werden. Die Eigenschaftenansicht enth\u00e4lt auch ein Notizfeld f\u00fcr zus\u00e4tzliche Informationen.<\/p>\n

R\u00fcckverfolgbarkeitsspuren zwischen Anforderungen und Tests<\/h2>\n

All das k\u00f6nnte auch irgendwie in einer Tabelle realisiert werden. Aber die wahre St\u00e4rke eines Werkzeugs wie ProR entfaltet sich, wenn R\u00fcckverfolgbarkeit genutzt wird. R\u00fcckverfolgbarkeit k\u00f6nnte zum Nachverfolgen von Anforderungen oder Spezifikationselementen zu ihren Tests verwendet werden, wie hier gezeigt:<\/p>\n

\"\"

Sie sehen, dass aus Zeile 1.1 ein ausgehender Link besteht. Das Linkziel (die Anforderung) wurde in der rechten Spalte ausgew\u00e4hlt, wodurch der vollst\u00e4ndige Anforderungstext in der Eigenschaftenansicht sichtbar ist. Zus\u00e4tzlich hat der Link eine Anmerkung in der Spalte \u201cBeschreibung\u201d: \"Unter Linux, halten Sie Strg+Umschalttaste gedr\u00fcckt\".<\/p>\n

Weitere M\u00f6glichkeiten<\/h2>\n

Was hier gezeigt wurde, kann mit dem Standardwerkzeug ProR realisiert werden und kratzt nur an der Oberfl\u00e4che dessen, was realisierbar w\u00e4re. Mit wenig Aufwand k\u00f6nnte dieser Ansatz erheblich erweitert werden, zum Beispiel:<\/p>\n