Bei dieser Frage geht es nicht um Komponententests. Und es ist für ein Desktop-Produkt.
Hier geht es darum, das GUI zu testen und zu testen, ob das richtige Material zum richtigen Zeitpunkt in das richtige Textfeld eingegeben wird.
Eine Firma, die ich früher bei WinRunner benutzt habe (andere Abteilung, also weiß ich nicht viel mehr), aber das ist jetzt von HP heruntergefahren worden, aber sie scheinen sich nicht darum zu kümmern, ob Sie bei HP bleiben oder gehen anderswo. Sie können nicht über das Produkt lesen, bis Sie sich angemeldet haben, was lästig ist.
Das Werkzeug muss mit MFC arbeiten (nicht verhandelbar) und das ideale Werkzeug wird auch ...
Was machen andere SO-Benutzer für automatisierte GUI-Tests?
Wir verwenden das SAFS-Framework für Rational Robot (RRAFS). Es gibt auch SAFS-Implementierungen für WinRunner (WRAFS) und es sieht so aus, als hätten sie eine neue "Image-Based Testing" -Implementierung, mit der ich nicht vertraut bin.
Dieses Framework macht es gut, die UI-Implementierung von den Testskripten zu trennen. Ich habe vier Versionen einer Webanwendung getestet, die von zwei verschiedenen Teams entwickelt wurde (ein Team verwendet einen klassischen ASP, einer ASP.NET), und ich musste nur die Anwendungszuordnung meiner Benutzeroberflächenobjekte ändern, was die Tests selbst nicht erforderlich machten ändern.
Das heißt, die Sprache des Frameworks ist umständlich und gewöhnungsbedürftig. Es ist nicht sehr robust in Bezug auf Sprachkonstrukte, aber mit etwas Aufwand können Sie alles tun, was Sie brauchen. Es ist so etwas wie "Programmierung" in Windows Batch-Sprache, aber für Tests;)
Um Ihre individuellen Anforderungen oben zu adressieren:
1) Das Tool muss mit MFC (nicht verhandelbar) funktionieren. Das SAFS-Framework verwendet ein "record-playback" -Tool von Drittanbietern, um die Tests wie Rational Robot oder Mercury WinRunner zu steuern. Wenn dieses Tool mit MFC-Apps interagieren kann, dann kann das Framework. Ich weiß nicht, wie die "Image-Based Testing" -Implementierung die Tests steuert, aber ich denke, es kann auch mit MFC funktionieren.
2) automatisiert werden. Das SAFS-Framework integriert sich in das STAF-Framework , mit dem Sie die Ausführung Ihrer Tests automatisieren können. Ich habe einen Proof-of-Concept-Test, der STAF verwendet, um ein VM-Image aus einem Bilderpool zu starten, die zu testende Anwendung zu installieren, den RRAFS-Test auszuführen und die Ergebnisse auf einem Webserver für andere bereitzustellen.
3) skriptfähig sein. Ja, aber wie gesagt, es ist nicht die robusteste Programmiersprache. Ich schrieb ein Excel-Add-In, das unsere Tester verwenden, um ihre Tests zu schreiben, die die Dinge ein wenig vereinfachen.
4) arbeitet automatisch mit verschiedenen Bildschirmauflösungen. Ja, da es auf den UI-Objekten und nicht auf dem Bildschirm "unter der Decke" aussieht. Bis auf die Option "Bildbasiertes Testen" ...
5) kann einzelne statische Textfelder usw. "ausspionieren". Ja, Sie können darauf warten, dass ein UI-Objekt angezeigt wird, nicht mehr angezeigt wird, einen Wert hat, ein Wert geändert wird usw.
6) intuitiv genug, damit Nicht-Programmierer Skripte erstellen können. Mit etwas Training. Wir hatten begrenzten Erfolg. Einige QA-Leute können die Tests schreiben, einige kämpfen.
7) Reporting-Tools, einschließlich E-Mails einzelner Benutzer. Ja, mit dem STAF-Framework können Sie Ergebnisse auf einem Webserver veröffentlichen, E-Mails versenden usw.
Hier gibt es viele gute Antworten, aber ich wollte diese Zielstellung ansprechen, insbesondere:
Ich kann verstehen, warum Sie das wollen, aber es ist viel schwieriger als Sie vielleicht denken. Sie können zwar eine beliebige Anzahl von Tools finden, die beanspruchen , um das Schreiben von Skripten zu vereinfachen. In der Praxis benötigen Sie jedoch mindestens einige Leute in Ihrem Automatisierungsteam, die das Programmieren verstehen. Das Schreiben von Skripten, die einigermaßen robust sind, wird eine oder mehrere Schleifen-, If / then / Else- und Subroutinenaufrufe umfassen. Nicht das, was Nicht-Programmierer intuitiv finden werden.
Seien Sie besonders vorsichtig bei der Idee, dass Sie eine Person mit einem Werkzeug "aufnehmen" können, und spielen Sie sie dann zum Testen ab. Diese Art von "Automatisierung" ist oft so spröde, dass Sie das Skript für fast jede Änderung in der Software ändern oder neu aufzeichnen.
Da ich von einem starken Mercury / HP-Hintergrund komme, empfehle ich dringend, QuickTest Professional für Ihre GUI-Tests zu verwenden. Es hat die gleiche Funktionalität wie WinRunner, aber ohne viel Code. Einfache GUI-Prüfungen können über die QTP-Schnittstelle mit einem minimalen benutzerdefinierten VB-Code durchgeführt werden. Checks für Text neben Boxen können mit einfachen Vergleichen mit dem Datenblatt in QTP durchgeführt werden.
Wenn Sie mit WinRunner vertraut sind und VBScript (nicht so sehr TSL) kennen, dann würde ich QTP definitiv betrachten.
Soweit es Ihre anderen Anforderungen erfordern, verfügt QTP auch über die Spy-Funktion, z. B. WinRunner, die alle Eigenschaften und Aktionen auflistet, die Sie an Objekten ausführen können. Und was die Einfachheit der Benutzung anbelangt, so mussten wir bei meinem alten Job von Business- oder System-Testern einfache Smoke-Skripte erstellen, die ich dann nehmen und für tiefergehende Tests codieren würde (mehrere Datenwerte, Fehlerprüfung usw.). Und was das Reporting betrifft, wird QTP einfache Berichte über Pass / Fail / Warning für Tags, die Sie einfügen, sowie benutzerdefinierte Daten, die Sie eingeben können, erstellen. Sie können also eine case-Anweisung verwenden, um Ihre Ausgabewerte basierend auf Ihren Ergebnissen aufzufüllen. Es wird nicht per E-Mail versendet, aber wenn Sie sich in TestDirector / QualityCenter integrieren, können Sie sich dort einrichten, den Start Ihrer Skripte automatisieren und die Daten direkt von dort aus parametrisieren (was Sie gerne zurücksenden) Tester haben Daten zu füllen, ohne in das Skript involviert zu sein.)
Pat
Desktop- oder Web-Apps haben hier dasselbe Testmuster (ich habe in beiden gearbeitet).
Platzieren Sie so wenig Logik wie möglich in der Benutzeroberfläche und testen Sie alles darunter. Also sagst du, aber was, wenn ich testen möchte, ob das und das passiert, wenn eine Schaltfläche angeklickt wird? Die Methode, die aufgerufen wird, wenn diese Schaltfläche geklickt wird, sollte zu einer anderen Klasse aufrufen, die das Denken tatsächlich ausführt.
Sie könnten sagen, aber ich verwende einige statische Klassen / Methoden, die nur in meiner UI existieren können, wickle diese mit einem Adapter ein und benutze diese Schnittstelle, um deinen Code testbar zu machen.
Die Teile Ihrer GUI-Tests, die Sie automatisieren möchten, sollten unterhalb der Benutzeroberfläche automatisiert werden. Es gibt Teile Ihrer GUI, die Sie nicht automatisieren können. Überprüfung, um sicherzustellen, dass die Dinge "richtig aussehen" oder testen, dass Sie bestimmte Elemente usw. sehen können. All das sollten Ihre Menschen tun. Stellen Sie sicher, dass Ereignisse ordnungsgemäß ausgelöst werden und dass Werte ordnungsgemäß von Ihren Geschäftsobjekten zurückgegeben werden. Dies sind alles Komponententests.
Ich kann aus Ihrer Frage sehen, dass Sie sich bereits ziemlich entschieden haben, dass Sie einen automatisierten GUI-Tester benötigen, aber das ist nicht das richtige Werkzeug für diesen Job. Wenn Sie sich dafür entscheiden, dass Sie versuchen, den besten Weg zu finden, das Falsche zu tun.
Wenn Sie der Meinung sind, dass es sich nicht um Unit-Tests handelt, weil Sie GUI-Interaktionen testen, kann ich Ihnen garantieren, dass Sie nicht Unit-Tests nahe genug an Ihrer Benutzeroberfläche testen. Wenn Sie das täten, hätten Sie das Gefühl, dass das meiste von dem, was Sie testen würden, überflüssig wäre.
Wenn Sie mit mir nicht einverstanden sind, schreiben Sie bitte einige Gründe und wir werden das heraushacken.
Es gibt viel mehr (Open Source) Alternativen, wenn Sie ein Web-Produkt testen. Für ein Desktop-Produkt untenstehend einige allgemeine Desktop-GUI-Automatisierungswerkzeuge für allgemeine Zwecke (in keiner bestimmten Reihenfolge). Ich habe mit all diesen Leuten persönlich gearbeitet, und alle haben ihre Arbeit erledigt. Wenn Sie sich für ein Vendor-Tool entscheiden, erhalten Sie POCs für diejenigen, die Sie in Betracht ziehen, und entscheiden Sie, welches Tool am besten für das Unternehmen im Allgemeinen geeignet ist. Ein Werkzeug kann für eine bestimmte Anwendung besser geeignet sein, aber es können andere Projekte / Anwendungen in Betracht gezogen werden.
Tags und Links user-interface testing automation