Mit Robot Framework für ATDD

Ich würde gerne hören, andere Leute Erfahrung mit Robot Framework für automatisierte Akzeptanztests.

Was sind Ihre wichtigsten stärken und Schwächen sowie einen Vergleich mit anderen frameworks (vor allem Fitnesse und Selenium)?

Den code getestet wird, ist real-time, legacy-code, hauptsächlich in C++.

  • Was hast du am Ende?
InformationsquelleAutor ratkok | 2010-05-18
  1. 22

    Habe ich verwendet, Robot Framework wird in drei verschiedenen Unternehmen spanning über sechs Jahren an der Zeit, dass ich dies Schreibe, und alle wurden erfolgreich in eine oder andere Weise.

    Meine Erfahrungen

    Unternehmen 1

    Der erste Ort, den ich verwendete Roboter war eine Java-basierte web-Anwendung für ein top-tier-Internet-Reise-Unternehmen. Wir verwendeten Roboter mit Jython, die wir erstellen keywords, die in Java und handeln Sie direkt mit dem system unter test. Wir verwendeten Selen zu fahren, web-browser, mit dem die meisten unserer Tests auf Firefox. Während der Prüfung Aufwand war weitgehend erfolgreich mit der QS-Organisation, der Organisation für die Entwicklung versäumt, Sie zu umarmen, Sie -- Sie bevorzugt verwenden, JUnit, anstatt Roboter.

    Company 2

    Meiner zweiten Firma, die ich fühle war ein voller Erfolg. Wir verwendeten Roboter in einer Vielzahl von Möglichkeiten. Die primäre Nutzung zu fahren war Internet Explorer für Abnahme-und Regressionstests von einer sehr erfolgreichen Werbespot .NET web-Anwendung.

    Wir verwenden ihn auch zum testen eines iPad-app durch die Kombination von Selen mit Appium. Wir verwendeten Roboter test-die RESTful-Dienste, die gelieferten Daten an die app. Wir schrieben spezielle Schlüsselwörter, die uns Bild-Analyse, und die wir auch Roboter-tests zu tun, die die schnelle Analyse der Trainings-Ausrüstung vor jeder Trainingseinheit. Wir hatten Stichworte, mit denen uns snapshot einer Datenbank vor einem test, und zum wiederherstellen der Datenbank nach einem test.

    Wir auch begonnen, Roboter zu helfen, mit manuellen Tests. Wir setzen die manuelle Testfälle, die Roboter, die uns Roboter nutzen die reporting-und tagging-Funktionen. Wenn diese tests laufen würde, Sie würde der Benutzer aufgefordert, führen Sie die manuelle Schritte, die erwies sich als viel effizienter, als wenn wir Tester Lesen manuelle Schritte eines test case management tool oder ein Word-Dokument.

    Unternehmen 3

    Das Dritte Unternehmen war eine große Firma ($1B Umsatz) mit einem ziemlich großen IT-Mitarbeiter. Sie hatte Tester mit sehr geringen technischen Fähigkeiten (ich erinnere mich an eine, die hatte keine Ahnung, was eine Kommandozeile war). Wir hatten ein team, schreiben einen Kern festlegen der keywords und der Bereitstellung von Ausbildung und Beratung, um die anderen teams. Ich denke, die Verwendung von Robot-war instrumental im bekommen etwas Gebrauch aus den am wenigsten erfahrenen Prüfern, aber auch mit high-level-keywords es war ein Kampf mit Ihnen.

    Unternehmen 4

    Meisten vor kurzem zog ich in ein sehr kleines Unternehmen mit nur einer Handvoll von Entwicklern und keine dedizierten Tester. Wir umarmten die Verwendung von Seite Objekte mit Robot Framework, und jetzt haben wir eine außergewöhnlich stabile suite von leicht lesbaren hohe Akzeptanz-tests. Der Einsatz der Roboter bei dieser Firma wurde ein voller Erfolg.

    Stärken

    Die größte Stärke der Roboter liegt in Ihrer Flexibilität. Wir habe verwendet, Roboter zur Unterstützung von manuellen Tests, testen von SOAP-und REST-services, web-basierte UI-testing -, Datenbank-Prüfung, Prüfung von Bildern und das testen von mobilen apps. Denn der Roboter ist so einfach zu verlängern, mit zusätzlichen Bibliotheken, es gibt fast nichts, was man nicht testen, ob Sie bereit sind, die ärmel hochkrempeln und schreiben Sie einige Schlüsselwörter. Je nach Einrichtung, können Sie Schlüsselwörter in Python, Java, .NET, oder wirklich nur jede Sprache, die durch die Roboter-remote-API.

    Weil Roboter Testfälle und Schlüsselwörter geschrieben werden, im Klartext, du bist nicht gesperrt mit einem proprietären tool zum erstellen oder anzeigen-tests. Benutzer können wählen Sie das Werkzeug Ihrer Wahl-Visual Studio, Eclipse, Emacs, Notepad, etc. Es ist auch ein Roboter-spezifische IDE (RIDE), obwohl ich es nicht empfehlen. Auch, denn die Dateien sind Klartext, Sie integrieren sich gut mit anderen software-tools-Sie sind einfach zu diff-und merge, Suche, etc.

    Schwächen

    Roboter macht es einfach zu schreiben ist low-quality-tests. Zwar gibt es Einrichtungen, um Dokument-Schlüsselwörter und Testfälle, und verwenden Sie lesbare Namen für keywords, test, Fällen und Variablen, es gibt keinen guten Weg, um die Durchsetzung von best practices. Schreiben eine große Anzahl von tests und Stichwörter erfordert Disziplin. Wie das Sprichwort sagt, der Robot gibt dir genügend Seil zu hängen, selbst mit.

    Andere Schwäche ist, dass das Tempo des Fortschritts über Roboter ist ziemlich langsam. Auf der plus-Seite, der Roboter ist robust und relativ bug-frei, so gibt es keine große Notwendigkeit für häufige patches. Es gibt jedoch Wünsche, die schmachten in deren issue tracker für Jahre keine Bewegung, das kann entmutigend sein.

    Zusammenfassung

    In allen Gesellschaften haben wir es genossen, in der Lage zu nutzen die Flexibilität von Roboter-syntax zum erstellen von data-driven tests, BDD-style tests, als auch einfache prozedurale tests. Und in allen Fällen, denn die tests sind Klartext-Dateien, die test-assets wurden einfach zu verwalten mit unserer SCM-tools (Mercurial, Subversion und Git)

    Für mich, Roboter bewährt hat, um einfach zu bedienen, sehr einfach zu erweitern, und nützlich für eine Breite Palette von Test-Aufgaben, von unit-Tests in der Python-Funktionen, zum testen von web-services, browser-basierte und tablet-UI-Tests, die Prüfung von Bildern, Prüfung von Datenbanken, und sogar verbessern die Effizienz der manuellen Tests.

    • Danke für die info. Haben Sie alle vorhandenen Test-Infrastruktur, Sie wollte/musste, zu integrieren und zu nutzen zusammen mit RF?
    • Nein, wir haben nicht über eine bestehende Infrastruktur.
    • etwas von einer Auferstehung aber ich verstehe nicht, Ihren Kommentar über die Unternehmen zu einem Entwicklungs-team, die lieber verwenden Junit. Junit und Roboter verweisen auf völlig verschiedene Arten von Tests, es klingt wie Unternehmen, die eine war ein großer Erfolg wie der Entwickler konzentriert sich auf unit-testing-und QA-team befasste sich mit funktionalen tests
    • Firma 1 war nicht ein großer Erfolg, so weit an die Abnahme geht. Sie bevorzugt unit-Tests, und Sie wollten mit einem unit-Test-framework für Akzeptanz-Tests. Denn letzteres ist schwieriger (Akzeptanz-Tests mit unit-Test-framework), Sie hätte es auch nicht viel. Noch, wie Sie sagen, die Tatsache, dass Sie sich umarmten unit-testing ist eine Gute Sache.
    • tolle Antwort @BryanOakley. Ich würde gerne mehr darüber wissen, wie zu verwenden fixture Daten im Rahmen eines Data-Driven Web-Anwendung. Ich denke, ich werde haben, zu implementieren, das Auffüllen/clear DB in einer Bibliothek. Ist das richtig?
    InformationsquelleAutor Bryan Oakley
  2. 15

    Haben wir bereits mit Robot Framework an meinem Arbeitsplatz für mehrere über ein Jahr jetzt mit mäßigem Erfolg. Wie die poster, die wir auch mit C++ arbeiten. Wir nahmen uns die Zeit, um zu bewerten Roboter gegen Fitnesse/Schlank und an der Zeit, beide Lösungen waren gut, aber die entscheidenden Faktoren waren (ab ~2009):

    • War es deutlicher, wie Roboter und seine Berichte würden Skalierung auf große Projekte
    • Es war nicht klar, wie version control Fitnesse Artefakte

    Aus technischer Sicht haben wir SCHLUCK Brücke zwischen Roboter und C++. Wir wickeln unsere Testgruppen in SCHLUCK, und verbinden Sie es mit der production code unter test - was uns ein python-Modul importiert werden können durch Roboter.

    Verwenden wir die .txt-format für die Roboter-input fast ausschließlich - wir haben festgestellt, dass diese version steuert sich besser, es ist leichter zu Lesen, und wir waren einfach nicht mit den erweiterten Funktionen von HTML (das ist, wo wir begonnen haben). Darüber hinaus sind wir mit der "BDD" Roboter-syntax auch. Wir verwenden GoogleMock mit einige Wrapper, die uns helfen, Erwartungen, mit denen überprüft werden, die während der ZERLEGUNG der einzelnen Roboter zu testen.

    Soweit die Organisation der tests, die wir haben, ließ sich auf den folgenden Ansatz (mit inspiration von Dale Emery ' s Ansatz, die hier gegeben werden):

    • Wichtigsten funktionalen Hierarchie wird dargestellt durch eine Ordner-Struktur.
    • Ein feature-ish große Sache beschrieben wird, die in einem Roboter-test Datei-name.
    • Eine Beschreibung von jedem Teil, dass die Funktion verwendet wird, bei der Roboter test-case-name.
    • Ein Beispiel gegeben, wie die Schritte in der test-Fall.
    • Der Beispiel-text ist aufgeteilt in die Schritte mit Roboter "keywords".
    • Die test-Vorrichtung steuert die Produktions-code.

    Beispielsweise ein Handy haben könnte, so etwas wie dieses:

    // PhoneProject/MakingCalls/DialAPhoneNumber.txt

*** Test Case ***
A user can dial a US number with an area code, up to 10 digits
   Given a phone without any numbers dialed
   Expect the attempted phone number to be 123-456-7890
   When a user enters the numbers 1234567890


//A separate MakingCallsKeywords.txt or something similar
*** Keyword ***
Given a phone without any numbers dialed                CreateNewDialer
Expect the attempted phone number to be ${phoneNumber}  ExpectDialedNumber  ${phoneNumber}
When a user enters the numbers ${numbersEntered}        DialNumbers ${numbersEntered}

//MakingCallsFixture.cpp  (which gets wrapped by SWIG)

std::wstring MakingCallsFixture::DialNumbers(const std::wstring& numbersEntered)
{
   ... Drive production code ...
}

//CreateNewDialer, ExpectDialedNumber also go here

    Dann würden wir koppeln dies mit unit-tests abdecken-die-Ecke-Bedingungen (z.B. sicher nicht mehr als 10 Ziffern sind erlaubt) - oder vielleicht wäre eine andere Annahme-test (ausführbare Spezifikation), je nachdem, wer das Lesen der tests und Ihre Vertrautheit mit der Domäne.

    Wir einen Entwurf erstellen dieser Spezifikationen und der Beurteilung mit domain-Experten und das team vor Beginn der arbeiten. Dies hat dazu beigetragen, flush ist eine Reihe von Missverständnissen frühzeitig zu erkennen.

    • Tolle info. Wusste nicht, über SCHLUCK, große Möglichkeit für die Integration von low-level-code in C/C++ Gefahren werden mit Robot Framework. Abgesehen davon, dass mein anderer Gedanke wäre die Umsetzung in eine C/C++ - basierten XML-RPC-server als remote-Bibliothek, dass die Gespräche der Roboter zum Aufruf von C/C++ - code.
    InformationsquelleAutor Joe Schneider
  3. 1

    Ich verwendet, Robot framework für die folgenden Szenarien.

    UI Tests

    1. Das Robot framework ist wirklich gut für das testen von user interface
    2. Der Rahmen kommt mit dem FAHREN-editor, die verwendet werden können für das schreiben der Testfälle.
    3. Sie müssen nicht ein Experte auf Selen und Selen-Befehle
      suchbar sind die in der FAHRT-editor.
    4. Können Sie den gemeinsamen code durch die Verwendung von Schlüsselwörtern und geteilt
      Ressourcen. Es ermöglicht Ihnen die einfache Wiederverwendung von test Fällen und test
      library-code.
    5. Aufrufen können Sie leicht rufen Sie eine Python-library-Funktion zu tun, mehr Aufgaben abgenommen werden.

    Für service-Tests, ich fand das Robot framework ein wenig schwierig zu verwenden, für die Art von test automation war ich Unternehmen.

    Application service layer ist vollständig geschrieben in C/C++ . Ich persönlich arbeite auf einem Windows-laptop und unsere Anwendung befindet sich auf einem Linux-server.

    Fand ich die *Fitnesse-framework** viel hilfreicher und einfacher zu tun, automation mit. Fitnesse hatte die unten genannten zusätzlichen Funktionen, die erlaubt zu schreiben, die Testfälle einfach. Konnte ich nicht finden, ähnliche Funktionen in der Robot.

    Entscheidung Tabelle - schreiben Sie Testfälle in Microsoft .xls Art von format. Jede Zeile in der data-grid repräsentiert einen Testfall. Jede Zeile wird über einen Satz von Eingängen und Ausgängen. Die Ausgänge werden mit vorangestelltem Fragezeichen in der überschrift.

    Query-Tabelle - Ausgabe von test wird eine Liste der Daten, die Sie überprüfen möchten.

    Auch Fitnesse erlaubt einfache integration mit anderen Sprachen wie C (mit Slim-Dienst). Dies erfordert keine integration der Codierung. Fitnesse die Testfälle direkt ausführen von test-fixtures, Getter und setter.

    Zusammenfassung meiner Erfahrung:

    • Fand ich ein einfach zu bedienendes tool für UI-Automatisierung.

    • Fand ich es ein wenig schwierig zu verwenden, für die service-Automatisierung.

    InformationsquelleAutor Tanmay Patil
Schreibe einen Kommentar