automatisiertes Software - Testing

Hallo !

Ich bin auf der Suche nach einem Programm, welches Testabläufe automatisiert. Leider kenn ich mich auf diesem Gebiet nicht wirklich aus. Soweit ich weiß gibts ja u.a Unit-Tests und Fuzzing-Tests, oder ?

Wie nennt man Software, die verschiedene Aktionen auf der GUI speichert und dann für Tests nachvollzieht ?

Welche Software kennt ihr aus dem Bereich des automatiserten Testings ? Bin für jede Hilfe dankbar....

MfG
Impact

P.S:
Mercury Winrunner ist z.b so eine Applikation .... Gibts Alternativen ? Evtl. sogar Open Source ?

Hallo impact,

Wie nennt man Software, die verschiedene Aktionen auf der GUI speichert und dann für Tests nachvollzieht ?

etwas allgemeiner gesehen, nennen man die Dinger einfach macro-recorder (o.ä.).

Ansonsten ist das Testen eines GUI immer einigermaßen problematisch. Deshalb testet man auch oft die Businesslogik separat, wodurch man die Businesslogik nicht mehr durch die Oberfläche hindurch mittesten muss, sondern sich auf die reine Oberflächen-Mimik konzentieren kann.

herbivore

Compuware hat auch ne dicke Test-Suite im Angebot.

Billig ist das aber alles nicht.... pro Client kannst du locker nen Preis im vierstelligen Bereich veranschlagen. Server nochmal extra.

Die "offizielle" Bezeichnung für solche "Makrorecorder" lautet übrigens "Capture & Replay Tools".

Die Dinger sind aber ihr Geld wert, wenn man sich mal die Produktivität im Vergleich zu für UIs aufgebohrte Frameworks wie z.B. NUnit anschaut.

Hallo !

Habe mich weiter informiert und einige Papers durchgelesen, zudem bin ich auf folgende Programme gestoßen:

• Mercury Winrunner
• AudomatedQA Testcomplete4
• Seapine Software QAWizard
• Parasoft .TEST
• Compuware QACenter

Testing scheint ja insgesamt eine verzwickte Angelegenheit zu sein. Noch sind mir die Anwendungsmöglichkeiten der verschiedenen "Testarten" wie "Capture/Replay", "Fuzzing" und "Unit-Tests" nicht ganz klar....

Hab ich das richtig verstanden:

• Unit-Tests ist klassenbasiertes Testen. Es werden alle Methoden über "Testklassen" angesprochen und die jeweiligen Rückgabewerte überprüft. Code-Coverage: hoch

• Fuzzing: Das ganze Programm oder auch einzelne Klassen werden mit randomisierten Input gefüttert. Damit kann überprüft werden ob sich das Programm trotz chaotischer Daten immer im "richtigen" Zustand befindet und nicht abschmiert... Code-Coverage: hoch

• Capture / Replay: Einzelne "Benutzungsstränge" und das gewünschte Ergebnis werden aufgezeichnet. Später werden diese wiederholt und überprüft ob das gewünschte Ergebnis immernoch eintritt. Code-Coverage: niedrig

Vor kurzem hatten wir in der Firma folgendes Problem. Durch eine Änderung im Code funktionierte die Lokalisierung des Programms über Ressourcen nicht mehr richtig, es wurde einfach (unbemerkt) Text in der falschen Sprache angezeigt.

Welche der vorher genannten Testing-Methoden hätte diesen Fehler aufgedeckt ? Keine, oder ?

Gruß
Impact

Ich habe mich bislang nur mit Unit-Tests befasst und die hätten Deinen Fehler gefunden oder auch nicht. Die Qualität solcher Tests hängt hauptsächlich von der Qualität des Test-Autors ab (also Dir). Das Problem ist nämlich, dass die Tests natürlich nur genau das prüfen, was Du Dir auch ausgedacht hast.

Ich sehe die Vorteile zum einen in dem Automatismus, der es Dir eben abnimmt, nach jeder Änderung wieder für alle Methoden zu prüfen, ob sie bei einem null-Parameter nicht abschmieren. Und es stimmt wirklich, was in den Dokumneten zu agiler Softwareentwicklung mit Test-First-Ansatz steht: Es ist sehr motivierend, wenn Du die Tests anschmeißt und sie produzieren am Anfang 80 Fehler, dann nur noch 20 und dann ist alles grün 👍

Der zweite Vorteil ist der, dass Du Dir, während des Formulierens der Testfälle, Gedanken über mögliche, gültige und ungültige Eingaben und Parameter machst und nichts anderes. Denn Hand aufs Herz: Auch der pedantischste Programmierer vergisst bei der zig-sten Methode die Prüfung auf den Leerstring etc., wenn er sich in Wahrheit gerade mit dem Problem befasst, was die Methode eigentlich leisten soll.

Um nochmal auf den von Dir beschriebenen Fehler zurück zu kommen: Den hätten Unit-Tests genau dann gefunden, wenn es eine Methode gibt, die lokalisierten Texte zurückgibt und es einen Unit-Test gegeben hätte, der diese mit den erwarteten vergleicht.

Auch mit einem Capture/Replay hättest du den Fehler finden können - natürlich nicht müssen.

Vermutlich wird man Prüfungen von Oberflächentexten zumeist einem nicht-automatisierten Test überlassen. Der Aufwand für eine Automatisierung liegt hier zu hoch. Fehler in der Datenversorgung (dazu gehören Ressourcen) sind schwer zu finden. Hier kann man nur Stichproben testen oder die Verwaltung von Sub-Mengen (z.B. die Umschaltung von einer Sprache auf die andere).

Niemand würde z.B. auf die Idee kommen, zu prüfen, ob eine Methode den richtigen Städtenamen zu einer PLZ liefert - und zwar für ALLE PLZs.

Also eine gute Möglichkeit finde ich die Kombination aus NUnit.Net und NCover. Letzteres gibt dir vor allem mit aus, ob du alle Code-Stellen in deinem Test-Zyklus auch mal durchkaufen hast, also Messtool für die Code Coverage beim Testen. Vor allem Spezialfälle bei Parameterabprüfungen fallen so schon sehr zeitig auf und du versuchst konsequenter eine Testabdeckung von 100% zu erreichen, vor allem für Bibliotheken.

Das ist jetzt keine komplette Testumgebung und eignet sich auch nicht so sehr für komplette Programme, sondern eher für Funktionen, die öfter gebraucht werden.

Für Formulare gibt es wohl NUnitForms, aber da habe ich noch keine Erfahrungen.

Bei deinem Problem kommt es drauf an, wo der Fehler denn nun lag: im Bereich der Anbindung an die Form oder tiefer? Aber wahrscheinlich wärest du mit UnitTests drauf gekommen.

TeDe

Ist ja interessant. Genau so ein Tool habe ich mir selbst geschrieben. Aber der Status ist noch nicht weit genug fortgeschritten. Aber bei Interesse kann ich hier gerne einen Snapshot veröffentlichen.

Nur leider habe ich den Thread erst jetzt(!) gefunden. Nachdem ich zufällig hier im Forum nach "Fuzzer" gesucht habe.

EDIT: Hab gerade mal nach www.crashtestnet.de gesucht. Da hatte ich wohl die gleiche Idee wie jemand anderes auch. Muss gerade nochmal nachschauen von wann mein "Fuzzer" ist. 01.01.2007

Mein Fuzzer unterstützt bisher .net 1.1 und 2.0...

Falls es jemanden interessiert:

Was gut funktioniert ist das hier:

https://www.nuget.org/packages/WinSharpFuzz/

Es bringt doch so einiges der Funktionalität von AFL-Fuzz (google/AFL: american fuzzy lop - a security-oriented fuzzer) nach .net.

Wichtig ist, die entsprechenden Projekte in die Solution einzufügen (normalerweise 2), also quasi Main und den vom Main aufzurufenden Code.
Dann muss das ganze noch "instrumentiert" werden, wie sich das nennt.

und "schon" könnt ihr Fuzzing in .NET benutzen.

P.S.: Wenn ihr das noch genauer wissen wollt, kann ich das gerne hier zusammentragen, zum Nachmachen.