• Like
Softwaretests: CrefoTeam Consumer - Teststrategie aus Entwicklersicht
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Softwaretests: CrefoTeam Consumer - Teststrategie aus Entwicklersicht

  • 1,548 views
Published

Häufig kommt in der Anwendungsentwicklung das Testen zu kurz. Dabei bietet sich ein enormes Einsparpotenzial, wenn Fehler bereits während der Entwicklungsphase und nicht erst nach Inbetriebnahme …

Häufig kommt in der Anwendungsentwicklung das Testen zu kurz. Dabei bietet sich ein enormes Einsparpotenzial, wenn Fehler bereits während der Entwicklungsphase und nicht erst nach Inbetriebnahme erkannt und behoben werden.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,548
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Fallstudie „CrefoTEAM Consumer“ – Teststrategie aus Entwicklersicht für Thementag „Wer testet, ist feige“ 24.06.2009 Autor: Mathias WürthleSeite 2
  • 2. Agenda Eckdaten zum Projekt Projektstruktur Continuous Integration (CI) Weitere Maßnahmen zur Fehlervermeidung Auswirkungen des Prozesses auf den EntwicklerSeite 3
  • 3. Eckdaten zum Projekt Projektname CrefoTEAM Consumer (CTC) Projektauftrag Privatpersonenauskunft Ziel Ablösung der bisherigen Anwendung Beteiligte Systeme Oracle-Datenbank WebLogic Application Server Web-GUI für Kunden Swing-Client für Administratoren Batch-Server für autom. Abläufe (Flux) Suchengine (Fuzzy Double, Fuzzy Post) Telefondatendienst (ABIS) Nutzerverwaltung (LDAP)Seite 4
  • 4. Eckdaten zum Projekt Anzahl Entwickler 6 bis 11 Größe des Source-Codes ca. 4000 Klassen Unit-Tests ca. 1000 Anzahl der Module 65Seite 5
  • 5. ProjektstrukturRollen im Projekt Produktentwicklung (PE) Fachliche Tests Testabteilung (TCC) Entwicklung (SCC) Automatisierte Tests Releasemanagement Tests OK? Systembetrieb (Ecofis) Tests, ob Systeme laufen? (Monitoring mit Nagios)Seite 6
  • 6. Projektstruktur Fehler bei fachlichen Tests führen zu neuen automatisierten Tests 1. Test gegen Anforderungen der PE PE TCC 2. Problem Call erstellen 3. Problem Call priorisieren (PE) 8. Retest bzw. Regressionstests4. Problem Call zuweisen 7. Problem Call dem Initiator zuweisen Entwicklung (SCC) 5. Fehler beheben und Test schreiben Test-Repository 6. Testklasse in Defect-Tracking- System eintragen Seite 7
  • 7. Was ist Continuous Integration (CI)? Entwickler integrieren regelmäßig ihre Änderungen Jede Integration wird geprüft durch einen automatischen Build-Prozess • Stufe 1 ohne externe Systembestandteile • Stufe 2 mit externen Systembestandteilen Schnelle Rückmeldung bei Integrations-ProblemenSeite 8
  • 8. Rahmenbedingungen CIWichtige Tools Tools Im Projekt eingesetzt Versionsverwaltung CVS Build Tool Maven 2 IDE Eclipse und IntelliJ IDEA Build Management und TeamCity Continuous Integration-ToolSeite 9
  • 9. Rahmenbedingungen CIEmpfohlene Test-Frameworks /-Tools Frameworks/Tools Im Projekt eingesetzt Unit-Test-Framework JUnit Mock-Framework EasyMock Test-Datenbank HSQL-DB um Oracle-DB zu simulieren Web-Test-Framework Selenium GUI-Test-Framework Jemmy, MarathonSeite 10
  • 10. Rahmenbedingungen CIEinfacher und übersichtlicher Build-Prozess Nur ein Befehl um alle Module aus der Versionsverwaltung zu erhalten. Nur ein Maven 2-Aufruf (Goal) um alle Module anzusprechen.Ein HauptordnerEin Unterordner pro ModulMaven 2 Master-POM im HauptordnerSeite 11
  • 11. Continuous Integration (CI) – Erste StufeAblauf1. Ein Entwickler ändert bzw. erweitert den Source-Code.2. Der Entwickler testet die Änderungen auf seinem eigenen Rechner.3. Der Entwickler überträgt die Änderung in die Versionsverwaltung.4. TeamCity erkennt die Änderung und beginnt sofort einen neuen Build.5. TeamCity führt die Tests mit dem neuen Build aus.6. Im Fehlerfalle benachrichtigt TeamCity den oder die verantwortlichen Entwickler.Seite 12
  • 12. Continuous Integration (CI) – Erste StufeSeite 13
  • 13. Continuous Integration (CI) – Erste StufeVorteile von CI Automatisierter Build inkl. Tests Build auf einem zentralen Server mit einer definierten Umgebung Gesamte Codebasis wird gebaut und getestet • Integrationsprobleme zwischen abhängigen Modulen werden gefunden Die verantwortlichen Entwickler werden umgehend benachrichtigt • Per E-Mail und über die EntwicklungsumgebungSeite 14
  • 14. Continuous Integration (CI) – Erste StufeZu beachten Schnelle Rückmeldung wichtig • Build-Dauer unter 20 Minuten Build-Dauer ggf. reduzieren • Durch Optimierung der Tests • Durch Aufspalten des Build-Prozesses Verteiltes Bauen mit Build-Agents möglich • Im Projekt waren 2 Build-Agents aktiv Häufige Integration von Änderungen • Jeder Entwickler mindestens einmal täglichSeite 15
  • 15. Continuous Integration (CI) – Erste StufeGebrochener Build Pro Tag liefen viele erfolgreiche Builds • Gebrochene Builds kamen trotzdem vor • Diese wurden schnell beseitigt Zeitnahe Rückmeldung von TeamCity • Die verantwortlichen Entwickler sind noch im Bilde Wenige Änderungen wurden oft integriert • Nur ein oder wenige Fehler müssen beseitigt werden „Pre-tested Commit“-Feature genutzt • TeamCity testet die Änderungen vor dem Commit • Erfolgreiche Änderungen werden in das Versionskontrollsystem eingefügtSeite 16
  • 16. Continuous Integration (CI) – Zweite StufeWarum eine zweite Stufe? Erste Stufe: Schnelle Rückmeldung • Aktuelle Stand baubar? • Funktioniert alles grundsätzlich? Externe Systembestandteile noch nicht mit getestet Systemtests dauern tendenziell länger • Würden die schnelle Rückmeldung der ersten Stufe behindernSeite 17
  • 17. Continuous Integration (CI) – Zweite StufeÜbersicht Wichtige externe Systembestandteile werden einbezogen • Application Server BEA WebLogic, Oracle-Datenbank, Suchengine Fuzzy (Double und Post), Web-Server, LDAP TeamCity initialisiert/aktualisiert diese automatisch mit dem neuesten Stand • Auf dem Application Server wird der neueste gebaute Stand deployed • Die Test-Datenbank wird neu aufgebaut und mit Testdaten gefüllt, etc. Auch in dieser Stufe wurden nicht alle Systembestandteile eingebunden • Für lokal nicht vorhandene Systembestandteile wurden Mocks/Stubs geschrieben (Telefondatendienst ABIS, Batchserver Flux, etc.) Durchführung von Tests, welche das Gesamtsystem inkl. der integrierten Systembestandteile betreffen (Systemtests, Funktionstests).Seite 18
  • 18. Continuous Integration (CI) – Zweite Stufe Weitere Stufen: Alle Systembestandteile integriert Stufe 2: Wichtige Systembestandteile integriert Stufe 1: ohne Systembestandteile JUnit, HSQL, EasyMock, etc. LDAP etc. Application Server Web-Server Oracle-DB Abis etc. CEG-SchnittstelleSeite 19
  • 19. Continuous Integration (CI) – Zweite StufeZu beachten Tests in dieser Stufe dauern länger Die Gesamtlaufzeit der Tests sollte max. zwei bis drei Stunden betragen • Im Projekt waren es ein bis zwei Stunden Analyse der Fehler dauert länger Tests auf wichtige Funktions- und Akzeptanztests beschränken • Tests, die nicht auf externe Systembestandteile zugreifen, in der ersten Stufe unterbringen Mehrere Builds täglich durchführen • Im Projekt waren es 4 bis 5 Läufe täglichSeite 20
  • 20. Continuous Integration (CI) – Zweite StufeErgebnis und weitere Schritte TeamCity gibt erzeugte Artefakte erfolgreicher Builds frei • Java JAR-, WAR- und EAR-Dateien, SQL-Skripte, etc. • Permanente URLs (z.B. auf last-successful-build, feste Versionsnummer) Ausgewählte erfolgreiche Builds an den Systembetrieb ausliefern Erfolgreiche Builds auf andere Umgebungen aufspielen • Performance-Tests, manuelle Akzeptanztests usw. auszuführen Erzeugte Artefakte nicht in ein Versionskontrollsystem einfügen • Werden von TeamCity verwaltetSeite 21
  • 21. Zusammenfassung von Continuous Integration (CI)Stufe 1 Commit Automatisierter Build und Test Compile Schnelle Rückmeldung Unit TestStufe 2 Systembestandteile vorbereiten Autom. End-to-End-Test Systemtests durchführen Zeitnahe Rückmeldung Artefakte zur Verfügung stellen Aktuelle Version vorhanden Erfahrung bei Produktionsprobl.weitere Stufen Performance Tests Manuelle Akzeptanztests ProduktionseinführungSeite 22
  • 22. Weitere Maßnahmen zur Fehlervermeidung Code Review → statische Testmethode • Der zu „testende“ Code wird nicht ausgeführt • Änderungen werden durch einen weiteren Entwickler geprüft • Fehler und ‚Unsauberkeiten‘ werden frühzeitig erkannt • Kann Schulungseffekt haben Coding Conventions / Programmierrichtlinien • Erhöht Lesbarkeit, Verständlichkeit und Wartbarkeit des Codes • Vermeidet Merge-Konflikte und damit potentielle Fehler Pair-Programming • Fehlererkennung schon während der Entwicklung möglich, verständlicherer Code • Unterstützt die Reduzierung von WissensmonopolenSeite 23
  • 23. Auswirkungen des Prozesses auf den Entwickler Setzt Flexibilität / Offenheit voraus • Tests schreiben • Fehler werden schnell entdeckt → Schnelle Reaktion erforderlich → Sorgsamer Umgang mit dem Code • Große Änderungen aufteilen und oft integrieren • Rechtzeitiger Commit vor dem Feierabend Gewinn von Sicherheit • Änderungen werden risikoärmer und dadurch überschaubar • Sicheres Gefühl bei Änderungen • Beruhigt in den Feierabend oder in den Urlaub nach einem Integrationslauf Sehr hohe Akzeptanz: Die Entwickler ‚leben den Prozess‘Seite 24
  • 24. Referenzen Continuous Integration, Martin Fowler, http://martinfowler.com/articles/continuousIntegration.html Pending Head, Martin Fowler, http://martinfowler.com/bliki/PendingHead.html The Deployment Pipeline, Dave Farley, http://studios.thoughtworks.com/assets/2007/5/11/The-Deployment-Pipeline- by-Dave-Farley-2007.pdfSeite 25
  • 25. www.iks-gmbh.comSeite 26