Codierte, TFS-verknüpfte, automatisierte UI-Tests in allen Browsern

Ich suche ein Web-UI-Testtool, das:

A. Kann mindestens IE, Firefox, Chrome und Safari testen;

B. nicht auf "recording" angewiesen ist und rein codiert werden kann;

C. Kann Datentabellen aus TFS-Testfällen für Eingaben ziehen;

D. Kann Testschritte per Code nicht bestehen (oder kann ich die TFS-API aufrufen, um dies selbst zu tun)

Ein Problem besteht darin, dass viele Suiten in Safari nicht funktionieren, und eine unserer wichtigsten Demografien ist ein Kiosk-iPad mit Safari.

Andere Suiten sind nur aufgezeichnete Aktionen oder ihre "Konvertierung in Code". Ich kann nicht herausfinden, wie man einfach überspringt und nur reinen Code macht.

Ich kann nichts finden, was einen Testschritt nicht bestehen könnte. Möglicherweise muss ich diesen Teil selbst mit der TFS-API codieren.

Antworten (1)

Sikuli ist ein plattformübergreifendes, Python-basiertes Testtool, das die visuelle Erkennung von UI-Elementen verwenden kann, um zu entscheiden, a) was angeklickt werden soll und b) was die Ergebnisse sind. Es kann Pass & Fail-Ergebnisse generieren und Sie können in jedem Testschritt nahezu jeden Python-Code hinzufügen.

Da es nach visuellen Komponenten sucht, sollte es für fast jeden Browser funktionieren.

Toller Vorschlag. Aber ich hasse es zu sagen, dass das Punkt B nicht trifft. Es basiert auf Screenshots und Präsentationen. Ich suche nach einem Produkt, das reine Codierung ist, was per Proxy bedeutet, dass es das DOM verwenden muss. Obwohl ich von der Nützlichkeit von Sikuli etwas beeindruckt bin.
@Suamere basiert auf der Erkennung von Bildschirmelementen (keine Screenshots). Die gute Nachricht bei diesem Ansatz ist, dass Sie keinen Zugriff auf den Quell-, Dom- oder anderen Low-Level-Code wie Element-IDs benötigen - wenn Sie Zugriff auf haben Schaltflächensymbole usw., dann können Sie aus reinem Code generieren - Sie können Ihre Tests auch auf einem Browser generieren und sie dann auf mehreren anderen ausführen. NB Ich habe Webseiten gesehen, auf denen die Schaltflächen Kennungen hatten, aber nicht sichtbar waren - der DOM-Ansatz würde sie nicht versagen, obwohl sie unbrauchbar waren.