Testen von Produkten und Softwareproduktlinien

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "Testen von Produkten und Softwareproduktlinien"

Transkript

1 Testen von Produkten und Softwareproduktlinien Jan-David Hof Universität Siegen

2 1 Allgemein 2 Testen von Software Testartefakte Domain und Application Testing 3 Testverfahren Test-Level Kriterien für SPL-Teststrategien Teststrategien 4 Test Activities 5 Unterschied zu Einzelsystemen

3 Allgemein SPL bilden Programme/Komponenten, die sich stark ähneln bzw. entsprechende Eigenschaften teilen wesentlich einfacher und protabler eine Softwareproduktlinie zu entwerfen als jedes Produkt einzeln zu entwickeln Folge: Es muss nicht mehr jede Software einzeln getestet werden. Sehr aufwendig Produkte einzeln zu testen Grundmodell wird an Anforderungen angepasst/ergänzt Aufwand für die Entwicklung und Wartung erheblich gesenkt Beispiele: Mikrochips, Linux/Android Wegen zu hoher Anzahl an Produktvariationen sind Einzeltests zu aufwendig Deshalb werden Testverfahren benötigt

4 Testartefakte I Testplan Produkte, die während des Testens entstehen Z.B. Testergebnisse, Pläne(Vorgehen, Struktur,...), genauere Beschreibungen Ein Test wird nach einem Testplan durchgeführt Legt Fälle/Schritte fest, die durchgeführt werden sollen Fällen werden Prioritäten zugeteilt die zu verwendeten Tools, Programme und Werkzeuge werden bestimmt

5 Testartefakte II Test-Case Bedingungen und die zu erwartenden Eingabe- und Ausgabedaten werden festgelegt Ziel und Testszenarios Fällen werden Prioritäten zugeteilt Testumgebung, die Anforderungen/ Bedingungen, die erfüllt werden müssen werden bestimmt Test-Case Szenario Beschreibt Abfolge der Aktionen, was schlussendlich zum Erreichen des Testziels führt Aktion = Szenario-Step

6 Testartefakte III Test-Case Szenario-Step Enthält Informationen wie genau der entsprechende Schritt ausgeführt werden soll Deniert das zu erwartende Ergebnis des Schrittes Test summary report Hier wird eine Übersicht über die Ergebnisse der Testausführung gegeben

7 Domain und Application Testing I Durch Variabilität ist es möglich verschiedene Produkte aus einer Produktlinie abzuleiten Basis wird im Domain-Engineering erstellt Im Application-Engineering können weitere Funktionalitäten zum einzelnen Produkt hinzugefügt werden Domain-Testing befasst sich mit lose gekoppelten und wiederverwendbaren Komponenten des Programms Application-Testing mit kompletten Programmen

8 Domain und Application Testing II Beide Testverfahren wirken zusammen und bilden Abhängigkeiten Domain-Testing Domain-Testing soll die Fehlerursachen in den Domainartefakten aufdecken Erzeugt wiederverwendbare Artefakte für das Application-Testing Muss gleichzeitig Variabilität berücksichtigen und besitzt kein ausführbares System Einzelne Funktionen werden getestet

9 Domain und Application Testing III Application-Testing verwendet Domain-Test Artefakte um die Fehler in der Produktinstanz aufzudecken Jede Programminstanz muss einzeln getestet werden Zusammenwirken wird getestet Eine Instanz der Produktlinie wird auf ihre anfangs festgelegten Spezikationen überprüft

10 Domain und Application Testing IV Abbildung: Problemdenition für das Testen von Software-Produktlinien

11 Test-Level I Getestet wird um Fehler aufzudecken und, um zu überprüfen, ob das Programm zuverlässig ist und die Anforderungen erfüllt Dazu gibt es drei Testebenen die durchlaufen werden (Modultest, Integrationstest, Systemtest) Die Variabilität und das Fehlen vollständiger Applikationen erfordert deshalb spezielle Teststrategien, die sich von den Einzeltests unterscheiden Jede Testebene muss abgeschlossen sein, damit das Testen in der nächsten Ebene fortgeführt werden kann

12 Test-Level II Modultest/Unit-Test 1 Verhalten der einzelnen Komponenten, Methoden oder Klassen wird geprüft Validiert das Verhalten des implementierten Codes gegen seine Spezikation Aufgeteilt in Black-Box und White-Box-Tests Black-Box-Test: das Testprogramm erzeugt eine Umgebung(setzt Variablen) und ruft die zu testenden Funktionen mit entsprechenden Parametern auf. Im Anschluss prüft das Testprogramm die Rückgabewerte der Funktionen und die Umgebung auf Änderungen

13 Test-Level III Modultest/Unit-Test 2 Spezikationen/Dokumentationen werden benötigt, um die Funktionsweise abzuleiten Nicht dazu geeignet Fehler in bestimmten Komponenten aufzudecken Deckt Fehler gegenüber der Spezikation auf White-Box-Test: Wenn keine Dokumentation verfügbar ist (Extreme Programming) oder man Fehler in bestimmten Komponenten aufdecken will hält sich an interne Struktur, nicht an Spezikation

14 Test-Level IV Integrationstests 1 Validiert das Verhalten von mehreren Komponenten, die miteinander die Konguration bilden Wird an Komponenten angewendet, die den Modultest bestanden haben Soll überprüfen, ob die Komponenten untereinander fehlerfrei ablaufen, die Kommunikation zwischen diesen funktioniert

15 Test-Level V Integrationstests 2 Zwei Verfahren: Top-Down, Bottom-Up Top-Down: In den höchsten Abstraktionsschichten wird begonnen die verschiedenen Komponenten zu testen Darunterliegende werden simuliert und schrittweise durch reale Teilsysteme ersetzt Bottom-Up: Streng hintereinander werden die fertigen Komponenten verknüpft und getestet, so dass am Ende das komplette System abgebildet wurde

16 Test-Level VI Systemtests Überprüft das Verhalten des ganzen Systems gegenüber seiner Systemanforderungsspezikationen Systemtest ist der letzte Abschnitt einer ganzen Folge von Integrationstests von zunehmend gröÿeren Teilsystemen Gesamtsystem mit der Interaktion seiner Komponenten und Abhängigkeiten Systemanforderungen denieren das gesamte Verhalten des Systems

17 Test-Level VII

18 Kriterien für SPL-Teststrategien I Essentielle Kriterien zur Entwicklung/Auswahl der Teststrategien für SPL Zeit um Testartefakte zu erstellen Zeit, die benötigt wird, um Testartefakte zu erstellen Dabei wird berücksichtigt, in wie weit die Teststrategie die Wiederverwendung der Artefakte unterstützt

19 Kriterien für SPL-Teststrategien II Absent Variants/ Abwesende Varianten Abwesende Varianten sind Varianten, die im Domain-Engineering noch nicht realisiert wurden, sondern erst im Application-Engineering Es wird ausgewertet, wie gut eine Teststrategie mit absent variants zurecht kommen

20 Kriterien für SPL-Teststrategien III Early Validation Sehr wichtig die Entwicklungsartefakte so früh wie möglich zu überprüfen um eine gute Qualität der Produktlinie zu gewährleisten Je später Fehler festgestellt werden, desto schwerer sind diese zu beseitigen Indikator für die benötigte Zeit zwischen Fertigstellung und Überprüfung des Artefakts Learning Efort Zeit, die benötigt wird, um die Testaktivitäten zu bewerkstelligen

21 Kriterien für SPL-Teststrategien IV Overhead/ Überlauf Es wird überprüft, ob die Anzahl der ausgeführten Aktivitäten und die Anzahl der Artefakte, auch mit weniger Aufwand hätten erstellt werden können Überlauf resultiert daraus, dass ein Artefakt mehrere Male produziert wurde und nicht erforderliche Aktivitäten ausgeführt wurden

22 Inkrementelles Testen Subsysteme werden in der Regel inkrementell getestet Zwei zueinander von der Funktionalität ähnliche Produkte nach speziellen Kriterien ausgewählt Ein Produkt wird ausführlich getestet, nach der Grundidee dieses Verfahrens müssen nur die veränderten Komponenten des zweiten Produkts nochmal getestet werden Die gemeinsamen Komponenten wurden somit schon mit dem ersten Produkt getestet Es muss entschieden werden, welches Produkt ausführlich getestet wird und bei welchen Komponenten kein Test mehr notwendig ist

23 Brute-Force-Strategie (BFS) I Grundidee hierbei ist, die Qualität so früh und so komplett wie möglich zu prüfen Ziel ist es die Qualität des Produkts durch einen umfangreichen Domain-Test für alle möglichen Programme zu gewährleisten Auf den Testebenen wird dann für alle möglichen Kongurationen getestet Da die BFS-Methode alle Anwendungen berücksichtigt, wird hier nicht auf der Anwendungsebene getestet(application-testing) Dadurch, dass Komponenten fehlen dauert der domain realisation process länger, welcher die Implementation aller Komponenten beinhaltet

24 Brute-Force-Strategie (BFS) II Problem: jede Kombination der Eingabewerte/Kongurationen muss getestet werden, um die Korrektheit des Programms zu gewährleisten Durch die Komplexität der meisten Programme ist dies nicht machbar, da die Kombinationsmöglichkeiten viel zu hoch sind Beispiel: Software mit zum Beispiel 10 Eingabefeldern und 3 Möglichkeiten gäbe es schon 3 10 = verschiedene Testfälle

25 Kombinatorisches Testen Ein Ansatz mit dem die Anzahl der Testfälle minimiert wird, die Testabdeckung aber möglichst groÿ bleibt Dabei müssen besonders die Abhängigkeiten zwischen Parametern und Parameterwerten beachtet werden Anwendung: das paarweise Testen Dabei wird die Erkenntnis genutzt, dass der Groÿteil der Softwarefehler aus einzelnen Datenwerten oder der Interaktion zweier Datenwerte entsteht Deshalb werden die Eingabefelder paarweise mit jedem weiteren Eingabefeld getestet Dabei werden zwischen beiden Eingabefeldern trotzdem alle möglichen Kongurationen gebildet

26 Pure-Application-Strategie (PAS) I Gegenteil von der "Brute-Force-Strategie, es wird nur auf Anwendungsebene und nicht auf Domainebene getestet PAS betrachtet dabei nur die Artefakte, welche auch in der aktuellen Anwendung Verwendung nden Überlauf unverhältnismäÿig hoch, jedes Testartefakt für die Anwendungen wird immer wieder neu für jede Anwendung entwickelt kein Mehrwert gegenüber normalen Einzelsystem-Tests Tests fangen für jede Anwendung immer wieder von vorne an Folge: Flaschenhals im Softwareproduktlinien-Entwicklungsprozess Testen beginnt hier erst, wenn die erste Anwendung komplett fertiggestellt ist, also kein Early Validation

27 Pure-Application-Strategie (PAS) II Kosten an Aufwand und Geld sind groÿ, um die Fehler zu beseitigen

28 Product-by-product-testing/Sample- Appllication-Strategie (SAS) Bei Product-by-product-testing wird jede einzelne Produktinstanz individuell getestet Aufgrund der Menge der Produkte ist es in vielen Fällen nicht möglich jedes Produkt einzeln zu testen Deshalb werden bei der Sample-Application-Strategie nicht alle Anwendungen getestet, sondern nur eine einzige oder einige wenige Anwendungen Mit den ausgewählten Anwendungen wird sozusagen ein repräsentatives System gebildet Problem: gröÿerer Überlauf, da meist nicht die minimale Menge von Produkten bestimmt wird, stattdessen erzeugt man zu viele sich äquivalent zueinander verhaltende Produkte

29 Commonality and Reuse Strategy (CRS)/ Wiederverwendung von Test Assets I Das Testen wird gleichermaÿen auf Domain- und Application-Testing, durch Erzeugung von wiederverwendbaren Testartefakten aufgeteilt Grundidee: im Domain-Engineering wiederverwendbare Testartefakte entwickeln, die dann für das Testen von Produkten verwendet werden können, welche im Application-Engineering an das jeweilige Produkt angepasst werden Demnach werden beim Domain-Testing überwiegend Domain-Artefakte getestet Gleichzeitig werden Tests vorbereitet werden, welche das Testen von variablen Artefakten im Application-Testing ermöglichen

30 Commonality and Reuse Strategy (CRS)/ Wiederverwendung von Test Assets II Time to createkriterium sehr gut, die Einbeziehung der Variabilität in die Testartefakte reduziert die Anzahl an Testfällen erheblich Domaintest-Artefakt deniert, wie die Varianten später getestet werden sollen Im Application-Test können diese Artefakte dann wiederverwendet werden Die vorher denierten Varianten können in Gruppen(je nach Gemeinsamkeiten) zusammen getestet werden, wobei diese dann als Application-Artefakt bezeichnet werden Dadurch, das die Variabilitäten in die Testartefakte gebunden/zusammengefasst werden, wird die Wiederverwendbarkeit erhöht (kein Overhead)

31 Commonality and Reuse Strategy (CRS)/ Wiederverwendung von Test Assets III lässt sich mit SRS kombinieren, SAS ermöglicht zum einen eine frühe Verizierung und CRS zum anderen die Verwendung von Testartefakten

32 Übersicht Time to create Tabelle: Strategieübersicht Absent variants Early validation Learning eort BFS PAS SAS CRS SAS/ CRS nicht besser als beim Einzeltest + Kriterium wird erfüllt - Kriterium unzureichend erfüllt Overhead

33 Test Activities I Das Testen von Software ist in die folgenden Schritte/Aktivitäten unterteilt: Domain Test Planning Entsprechenden Referenzen, Spezikationen und Anforderungen müssen vollständig vorliegen Als erstes muss die Teststrategie ausgewählt werden, anhand derer werden dann die benötigten Ressourcen ermittelt und die zu verwendeten Testfälle ausgewählt und priorisiert Die zur Verfügung stehenden Werkzeuge/Tools müssen bestimmt werden Allgemein soll der Testplan den gesamten Testprozess denieren (auch Termine, Rollen, Risikomanagement)

34 Test Activities II Domain Test Specication 1 Ziel ist es, wiederverwendbare Testfälle zu erstellen Als erstes werden die Logik-Testfälle, in welchen aber die konkreten Details und GUI-Elemente fehlen, erstellt Als zweites werden die Testfälle mit den beim ersten Schritt fehlenden Informationen verfeinert Detaillierte Testfälle werden ausschlieÿlich für gemeinsame Artefakte erzeugt, ansonsten hoher Überlauf

35 Test Activities III Domain Test Specication 2 Für jedes Testartefakt wird eine Abhängigkeitsreferenz zu der zugehörigen Testreferenz gebildet Diese Referenzen werden benötigt, um die Wiederverwendbarkeit von Testartefakten im Application-Testing zu unterstützen So können die Tester mit wenig Aufwand die zugehörigen Testfälle identizieren, indem sie den Abhängigkeitsreferenzen zwischen Anforderungen und Testartefakten folgen

36 Test Activities IV Domain Test Execution, Recording, and Completion Beim Anwenden der Testfälle werden Testprotokolle erzeugt, welche die Testfälle, die Versionsnummer des Testobjekts und das Testergebnis enthält Während der Fertigstellung des Tests wird das Testprotokoll analysiert und die Fehler eliminiert

37 Unterschied zu Einzelsystemen I SPL in Prozesse: Domain-Testing und Application-Testing unterteilt Variabilität im Gegensatz zu Einzelsystemtests eine groÿer Aspekt der Entwicklung/des Testens Schwierigkeit beim Domain-Testing: keine einzelne Konguration der Komponenten, die getestet werden könnte Deshalb Teststrategien notwendig, um eine frühe Validation der Softwareproduktlinie und die Wiederverwendung von Testartefakten durch Application-Engineering sicherzustellen. Testartefakte müssen nicht für jede Produktinstanz gebildet werden, sondern sind wiederverwendbar Bei Testen von Einzelsystemen bildet man bei jedem Programm neue Artefakte und Variabilität wird auch nicht berücksichtigt

38 Unterschied zu Einzelsystemen II Ziel von Application-Testing und der Einzelsystemtests ist es, eine hinreichende Qualität des Programms zu gewährleisten Bei SPL muss berücksichtigt werden, dass die Anforderungen/Spezikationen bzw. die Programminstanz, die getestet werden soll schrittweise im Domain-Engineering und Application-Engineering erstellt werden

39 Ende Danke für die Aufmerksamkeit

Testen von Produkten und Softwareproduktlinien

Testen von Produkten und Softwareproduktlinien Testen von Produkten und Softwareproduktlinien Jan-David Hof Universität Siegen jan-david.hof@student.uni-siegen.de ABSTRACT Viele Produkte können aus einer Produktlinie abgeleitet werden, deshalb ist

Mehr

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

Mehr

Testen im Software- Entwicklungsprozess

Testen im Software- Entwicklungsprozess Technologie-Event 2006 Testen im Software- Entwicklungsprozess W.Lukas, INGTES AG Was nicht getestet wurde, funktioniert nicht. -- R.Güdel (ca. 1998) Seite 2 Was sollen wir tun? Anomalien & Defekte von

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Unit Testing, SUnit & You

Unit Testing, SUnit & You HUMBOLDT-UNIVERSITÄT ZU BERLIN MENSCH-TECHNIK-INTERAKTION ARBEITSGRUPPE SOFTWARETECHNIK (INSTITUT FÜR INFORMATIK) ARBEITSGRUPPE INGENEURPSYCHOLOGIE (INSTITUT FÜR PSYCHOLOGIE) Unit Testing, SUnit & You

Mehr

Software Produktlinien: Einführung und Überblick

Software Produktlinien: Einführung und Überblick C A R L V O N O S S I E T Z K Y Software Produktlinien: Einführung und Überblick Johannes Diemke Vortrag im Rahmen des Seminars Software System Engineering im Wintersemester 2007/2008 Übersicht 1 Motivation

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] 1 Software-Qualitätssicherung 2 Integrationsstrategien big bang 6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] nicht-inkrementell geschäftsprozeßorientiert Prof. Dr. Helmut Balzert Lehrstuhl

Mehr

1. Zweckdes Dokuments

1. Zweckdes Dokuments Testplanung Testplanung 1.Zweck des Dokuments 2.Testziele 3.Teststrategie 4. Inkrementeller Test 5. Dokumentation der Tests 6. Performance Test 7. Literaturreferenzen 1. Zweckdes Dokuments Dokumentation

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011 Programmieren I Martin Schultheiß Hochschule Darmstadt Wintersemester 2010/2011 1 2 Übersicht Testen ist eine der wichtigsten, aber auch eine der Zeitaufwändigsten Arbeitsschritte der Softwareentwicklung.

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

,$ -. "+0 *+*+ ! / -#$%$. #$%'' $ () 1 2$ #$%$! 1 2$3 )!

,$ -. +0 *+*+ ! / -#$%$. #$%'' $ () 1 2$ #$%$! 1 2$3 )! *+*+ *,$ -.! / -#$%$. #$%'' $ () "+0 *+*+ 4 *+*+ 1 2$ #$%$! 1 2$3 )! 1 *+*+ $& #$%'!' '!' 5 1! 1 4$5%! 1 63$ 1 $7$! 1 3! 1 77 8'7 1 /!$' 1 83% *+*+ 0 #$%'' '' #$%'' ''$' )%! $' #$% 5 87 $ 8$! 7$+ 1 #$%9$

Mehr

Einsatz automatischer Testdatengenerierung im modellbasierten Test

Einsatz automatischer Testdatengenerierung im modellbasierten Test Einsatz automatischer Testdatengenerierung im modellbasierten Test Sadegh Sadeghipour sadegh.sadeghipour@itpower.de Gustav-Meyer-Allee 25 / Gebäude 12 13355 Berlin www.itpower.de Modellbasierte Software-Entwicklung

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Blumatix EoL-Testautomation

Blumatix EoL-Testautomation Blumatix EoL-Testautomation Qualitätsverbesserung und Produktivitätssteigerung durch Automation von Inbetriebnahme-Prozessen DI Hans-Peter Haberlandner Blumatix GmbH Blumatix EoL-Testautomation Qualitätsverbesserung

Mehr

Prozess-Modelle für die Softwareentwicklung

Prozess-Modelle für die Softwareentwicklung Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 10. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 10. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 10. Vorlesung 1 Test...(4) Oberflächentests testen die Benutzerschnittstelle des Systems, nicht nur auf Fehlerfreiheit sondern z.b. auch auf Konformität mit

Mehr

Einführung von Test-Prozessen laut TMMi. Egon Valentini 1. März 2010

Einführung von Test-Prozessen laut TMMi. Egon Valentini 1. März 2010 Einführung von Test-Prozessen laut TMMi Egon Valentini 1. März 2010 Agenda NXP Testumfeld CMMi, TMMi TMMi QualityPolicy, TestPolicy, TestStrategy, TestPlan Lessons Learned 2 Warum brauchen wir Testmethoden

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien

Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien Sebastian Oster, Philipp Ritter, Andy Schürr Sebastian Oster oster@es.tu-darmstadt.de Tel.+49 6151/16-3776 ES Real-Time Systems

Mehr

Praxisgerechte Validierung von Sicherheitsapplikationen

Praxisgerechte Validierung von Sicherheitsapplikationen Praxisgerechte Validierung von Sicherheitsapplikationen Dr. Michael Huelke, FB Unfallverhütung Produktsicherheit, BGIA Institut für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung, Sankt Augustin

Mehr

Testen von Software. Erfahrungsbericht des INGTES Testcenters. von Ueli Tribelhorn

Testen von Software. Erfahrungsbericht des INGTES Testcenters. von Ueli Tribelhorn Testen von Software Erfahrungsbericht des INGTES Testcenters von Ueli Tribelhorn Testen von Software Testziele Aus der Praxis Fundamentale Qualitätskriterien tskriterien Ausbildung zum Tester Erfahrungsbericht

Mehr

Product Line Engineering (PLE)

Product Line Engineering (PLE) Product Line Engineering (PLE) Produktlinienentwicklung Von Christoph Kuberczyk Christoph Kuberczyk, SE in der Wissenschaft 2015, Product Line Engineering 1 Gliederung 1. Was ist PLE? 2. Motivation 3.

Mehr

Effizienzsteigerung von Softwaretests durch Automatisierung

Effizienzsteigerung von Softwaretests durch Automatisierung Bachelorarbeit am Institut für Informatik der Freien Universität Berlin, Arbeitsgruppe Programmiersprachen Effizienzsteigerung von Softwaretests durch Automatisierung David Emanuel Diestel 04.02.2016 Übersicht

Mehr

Modellbasierte Teststrategie in der Fahrzeugerprobung am Beispiel der car2go

Modellbasierte Teststrategie in der Fahrzeugerprobung am Beispiel der car2go Daimler Mobility Services 09.10.2013 Modellbasierte Teststrategie in der Fahrzeugerprobung am Beispiel der car2go Aachener Kolloquium Fahrzeug- und Motorentechnik 2013 Slavko Bevanda (Daimler Mobility

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

Motivation und Überblick

Motivation und Überblick Motivation und Überblick iks-thementag : Wer testet, ist feige 24.06.2009 Autor: Christoph Schmidt-Casdorff Carsten Schädel Seite 2 Agenda Einführung Auf welcher Ebene wird getestet testing level Was wird

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth

Mehr

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

Verknüpfung von kombinatorischem Plattformund individuellem Produkttest für Software-Produktlinien

Verknüpfung von kombinatorischem Plattformund individuellem Produkttest für Software-Produktlinien Verknüpfung von kombinatorischem Plattformund individuellem Produkttest für Software-Produktlinien Andreas Wübbeke Sebastian Oster 23.02.2010 ES Real-Time Systems Lab Dept. of Electrical Engineering and

Mehr

Automatische Testfallgenerierung aus Modellen. 8. Neu-Ulmer Test-Engineering-Day 2013 06.06.2013 Martin Miethe

Automatische Testfallgenerierung aus Modellen. 8. Neu-Ulmer Test-Engineering-Day 2013 06.06.2013 Martin Miethe Automatische Testfallgenerierung aus Modellen 8. Neu-Ulmer Test-Engineering-Day 2013 06.06.2013 Martin Miethe Über sepp.med Über 30 Jahre Erfahrung im industriellen Umfeld Medizintechnik Pharmazie Automotive

Mehr

Real-Time Collaboration Eine Kostprobe Workshop

Real-Time Collaboration Eine Kostprobe Workshop Real-Time Collaboration Eine Kostprobe Workshop Helge Nowak hnowak@cincom.com Twitter: @nowagil Softwareentwicklung heute Softwareentwicklung ist Teamarbeit Die Kerntätigkeiten sind asynchron Jeder arbeitet

Mehr

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Dr. Bernd Hedenetz, Markus Conrath Daimler AG Prof. Dr. Klaus D. Müller-Glaser

Mehr

Vector Software W H I T E P A P E R. Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen

Vector Software W H I T E P A P E R. Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen Vector Software W H I T E P A P E R Mit VectorCAST die FDA-Anforderungen an Softwaretests erfüllen Einführung Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den gesamten Software Entwicklungszyklus.

Mehr

Testmanagement. Full-Service

Testmanagement. Full-Service Testmanagement Full-Service Industrie 4.0 und das Internet der Dinge sind nur zwei Beispiele für die zunehmende Bedeutung von Software und die Vernetzung von Software-Systemen. Fehler in diesen Systemen

Mehr

Programmiertechnik II

Programmiertechnik II Modultests Ziele Überprüfung der Korrektheit eines Moduls Korrektheit: Übereinstimmung mit (informaler) Spezifikation Modul: kleine testbare Einheit (Funktion, Klasse) Engl.: unit test White box testing

Mehr

Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving)

Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving) Universität Paderborn Die Universität der Informationsgesellschaft Analyse, Entwurf und Implementierung zuverlässiger Software und (inkl., Model-Checking, Theorem Proving) Torsten Bresser torbre@uni-paderborn.de

Mehr

Funktionale Sicherheit Testing unter

Funktionale Sicherheit Testing unter Funktionale Sicherheit Testing unter den Bedingungen der Safety Integrity Levels Präsentation auf dem Neu-Ulmer Test-Engineering Day Sebastian Stiemke, MissingLinkElectronics, Neu-Ulm 1 Inhalt Idee hinter

Mehr

Tutorial. Bibliothek AutoGUITest V1.0. Windows-Benutzeroberflächen automatisiert testen. Ausgabe: 6.6.02. 06.06.02 / 13:51 Seite 1

Tutorial. Bibliothek AutoGUITest V1.0. Windows-Benutzeroberflächen automatisiert testen. Ausgabe: 6.6.02. 06.06.02 / 13:51 Seite 1 Bibliothek AutoGUITest V1.0 Windows-Benutzeroberflächen automatisiert testen Tutorial Ausgabe: 6.6.02 06.06.02 / 13:51 Seite 1 Inhalt 1 Übersicht...3 2 Funktionsweise...3 3 Funktionsumfang...3 4 Einsatz

Mehr

Testen von graphischen Benutzeroberflächen. 26. Juni 2013

Testen von graphischen Benutzeroberflächen. 26. Juni 2013 Testen von graphischen Benutzeroberflächen 26. Juni 2013 Überblick Testarten Methoden-, Klassen-, Komponenten-, Systemtests Motivation für automatisches Testen von graphischen Benutzeroberflächen Entwicklungsprinzipien

Mehr

Software Product Line Engineering

Software Product Line Engineering Software Product Line Engineering Grundlagen, Variabilität, Organisation Sebastian Steger steger@cs.tu-berlin.de WS 2005/2006 SWT: Entwicklung verteilter eingebetteter Systeme Software Product Line Engineering

Mehr

Unit Testing mit JUnit. Dr. Andreas Schroeder

Unit Testing mit JUnit. Dr. Andreas Schroeder Unit Testing mit JUnit Dr. Andreas Schroeder Überblick Was dieses Video behandelt Warum Testen? Was sind Unit Tests? Der Teufelskreis des Nicht-Testens JUnit Unit Test Vorteile Test-Inspiration Wann aufhören?

Mehr

Testmanagement bei SAP-Projekten

Testmanagement bei SAP-Projekten Testmanagement bei SAP-Projekten Erfolgreich Planen Steuern Reporten bei der Einführung von SAP-Banking von Alberto Vivenzio, Domenico Vivenzio 1. Auflage Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

Testkonzept. Tipp-Star

Testkonzept. Tipp-Star Tipp-Star Version: V1.0-27.09.2015 Ablageort: Tipp-Star/01_Projektmanagement/03_Test Status: Fertig gestellt (In Bearbeitung / fertig gestellt / geprüft / freigegeben) Anzahl Seiten: 9 Autoren: tse Sergeyeva

Mehr

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Testen. SEPR Referat: Testen - Oliver Herbst

Testen. SEPR Referat: Testen - Oliver Herbst Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Qualitätssicherungskonzept Web Annotation mit Fragment Ids Gruppe: swp12-9 Inhaltsverzeichnis 1. Dokumentationskonzept...2 1.1. Quelltexte...2 1.2. Änderungsdokumentation...4 1.3. Modellierungsdokumentation...4

Mehr

T2 Fundamentaler Testprozess

T2 Fundamentaler Testprozess T2 Fundamentaler Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Overview der Software- Entwicklung 2 1 Wasserfall-Modell Analyse

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

TESTPLAN

TESTPLAN <Projektname> Firma TESTPLAN ID Version Ersteller: ------------------- Vorgesetzter des Erstellers:

Mehr

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

Mehr

Testen von SOA-Anwendungen mit dem BPEL Testframework

Testen von SOA-Anwendungen mit dem BPEL Testframework Testen von SOA-Anwendungen mit dem BPEL Testframework Stefan Kühnlein IBM Deutschland Enterprise Application Solution GmbH Hollerithstr. 1 81829 München 0160/8848611 Stefan.Kuehnlein@de.ibm.com IBM Deutschland

Mehr

EINE STRATEGIE FÜR OBJEKTORIENTIERTE SOFTWARE TESTEN- OMEN

EINE STRATEGIE FÜR OBJEKTORIENTIERTE SOFTWARE TESTEN- OMEN EINE STRATEGIE FÜR OBJEKTORIENTIERTE SOFTWARE TESTEN- OMEN Wissenschaftliches Arbeiten Recep IBILOGLU 0027849 534 Technische Universitaet Wien 1.Abstract Das Testen ist der kosten und zeitaufwendigste

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

Projektmanagement-Plan

Projektmanagement-Plan Applikationsentwicklung FS14 Gruppe 20 Horw, 29.05.2014 Bontekoe Christian Estermann Michael Rohrer Felix Autoren Bontekoe Christian Studiengang Informatik - Software Systems (Berufsbegleitend) Adresse

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

Service Virtualisierung

Service Virtualisierung Service Virtualisierung So bekommen Sie Ihre Testumgebung in den Griff! Thomas Bucsics ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

Testen mit JUnit. Apcon Workplace Solutions Member of itelligence. Testen von Java-Code mit JUnit. ÿstruktur eines Testfalls

Testen mit JUnit. Apcon Workplace Solutions Member of itelligence. Testen von Java-Code mit JUnit. ÿstruktur eines Testfalls Testen von Java-Code mit JUnit ÿmotivation ÿjunit-testklassen ÿjunit-testfälle ÿstruktur eines Testfalls Henning Wolf APCON Workplace Solutions GmbH wolf@jwam.de Motivation: Werkzeugunterstützung für Tests

Mehr

Qualitätsmanagement. Grundlagen

Qualitätsmanagement. Grundlagen Grundlagen Historie: Mit industriellen Massenproduktion erforderlich geworden (Automobilindustrie, Anfang des letzten Jahrhunderts); Qualitätsmanagement zunächst nur in der Fertigung Mitte des letzten

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Modellierung von Echtzeitsystemen mit dem UML CASE Tool Telelogic Tau G2 Developer

Modellierung von Echtzeitsystemen mit dem UML CASE Tool Telelogic Tau G2 Developer Modellierung von Echtzeitsystemen mit dem UML CASE Tool Telelogic Tau G2 Developer Holger Sinnerbrink Einführung Firmenentwicklung Gründung von Telelogic 1983 als Forschungs- und Entwicklungsabteilung

Mehr

Flexibilität im Prozess mit Oracle Business Rules 11g

Flexibilität im Prozess mit Oracle Business Rules 11g Flexibilität im Prozess mit Oracle Business Rules 11g Michael Stapf ORACLE Deutschland GmbH Frankfurt Schlüsselworte: Geschäftsregeln, Business Rules, Rules Engine, BPEL Process Manager, SOA Suite 11g,

Mehr

EoL-Testautomation 2.0. Technische Beschreibung. DI Hans-Peter Haberlandner. Blumatix GmbH

EoL-Testautomation 2.0. Technische Beschreibung. DI Hans-Peter Haberlandner. Blumatix GmbH EoL-Testautomation 2.0 Technische Beschreibung DI Hans-Peter Haberlandner Blumatix GmbH EoL-Testautomation 2.0 Technische Beschreibung Die Herausforderung Die Software spielt im Bereich der Testautomation

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung 2007 Dr. Klaudia Dussa-Zieger P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung

Mehr

T3 Testen im Software- Lebenszyklus

T3 Testen im Software- Lebenszyklus T3 Testen im Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test AK- 2 1 AK- Definition Test der einzelnen implementierten Komponenten

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung Testberichterstattung Lehrplan

Mehr

Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer

Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer Inhalt Top Themen Requirements Testen Testautomatisierung Change-Management Risiko-Management Agile Methoden Traceability

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Praxiswissen Softwaretest - Testmanagement

Praxiswissen Softwaretest - Testmanagement Praxiswissen Softwaretest - Testmanagement Aus- und Weiterbildung zum Certified Tester Advanced Level nach ISTQB-Standard dpunkt.verlag 1 Einleitung 1 1.1 Basiswissen - komprimiert 4 1.2 Praxiswissen Testmanagement

Mehr

GEVITAS Farben-Reaktionstest

GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest Inhalt 1. Allgemeines... 1 2. Funktionsweise der Tests... 2 3. Die Ruhetaste und die Auslösetaste... 2 4. Starten der App Hauptmenü... 3 5. Auswahl

Mehr

Quality Point München. Testtools

Quality Point München. Testtools Quality Point München Testtools 1 1 Testtools - ein Blick in die Landschaft reine Testtools unterstützen direkt Testaufgaben bzw. versprechen, diese zu automatisieren (statische Analyse, GUI-Funktionstest,

Mehr

CBIS - CARE BED INFORMATION SYSTEM

CBIS - CARE BED INFORMATION SYSTEM CBIS - CARE BED INFORMATION SYSTEM Test Plan Dokumentänderungen Version # Datum Ersteller Beschreibung V1.0 18.04.2010 Anna Bruseva Erste Version Inhaltsverzeichnis 1 INTRODUCTION...2 2 TESTKOMPONENTEN...2

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Stuttgarter Test-Tage 2011 Der Fluch des grünen Balkens in sehr großen Projekten

Stuttgarter Test-Tage 2011 Der Fluch des grünen Balkens in sehr großen Projekten main {GRUPPE} Seite 1 Jürgen Nicolai Geschäftsführender Gesellschafter Liebknechtstrasse 33 70178 Stuttgart Tel : 0711 2270225 Fax : 0711 2270497 Mail : j.nicolai@main-gruppe.de Web: www.health4j.de Stuttgarter

Mehr

Requirements Engineering im SPL-Umfeld

Requirements Engineering im SPL-Umfeld Requirements Engineering im SPL-Umfeld Manuel Wörmann 16.02.2015 Requirements Engineering im SPL-Umfeld Inhalt 1. Definition 2. Ziele 3. Domain Requirements Engineering 4. Application Requirements Engineering

Mehr

Standard Inhaltsverzeichnis für Testvorschrift

Standard Inhaltsverzeichnis für Testvorschrift Standard Inhaltsverzeichnis für Testvorschrift Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Testvorschrift... 1 2.2 Freigabe und Änderungen... 1 2.3 Prinzipien... 2

Mehr

-Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Seite 1 DI Christian Eggbauer mobilkom austria

-Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Seite 1 DI Christian Eggbauer mobilkom austria Diese Diese Kommentarfelder Kommentarfelder können können Sie Sie über über das das Menü Menü Ansicht Ansicht -Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Dies Dies ist ist die die

Mehr

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien

Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien Arbeitsberichte des Instituts für Informatik Friedrich-Alexander-Universität Erlangen Nürnberg Band 40 Nummer 4 Juli 2007 Stefan Kubica Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien

Mehr

Entwicklungswerkzeuge

Entwicklungswerkzeuge Entwicklungswerkzeuge Werner Struckmann & Tim Winkelmann 10. Oktober 2012 Gliederung Anforderungen Projekte Debugging Versionsverwaltung Frameworks Pattern Integrated development environment (IDE) Werner

Mehr

Produktskizze. 28. November 2005 Projektgruppe Syspect

Produktskizze. 28. November 2005 Projektgruppe Syspect 28. November 2005 Carl von Ossietzky Universität Oldenburg Fakultät II Department für Informatik Abteilung Entwicklung korrekter Systeme Inhaltsverzeichnis 1 Einleitung 3 2 Die graphische Oberfläche der

Mehr

Technologiepark 8 33100 Paderborn Telefon: 05251 / XX XX XX Mobil: 01XX / XX XX XX XX E-Mail: XXXXXXX@mail.upb.de

Technologiepark 8 33100 Paderborn Telefon: 05251 / XX XX XX Mobil: 01XX / XX XX XX XX E-Mail: XXXXXXX@mail.upb.de Technologiepark 8 33100 Paderborn Telefon: 05251 / XX XX XX Mobil: 01XX / XX XX XX XX E-Mail: XXXXXXX@mail.upb.de PIRAT Software Technologiepark 8 33100 Paderborn Universität Paderborn Institut für Informatik

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

Performance Analyse in einem komplexen Softwaresystem. 18.09.2013 Gebhard Ebeling

Performance Analyse in einem komplexen Softwaresystem. 18.09.2013 Gebhard Ebeling Performance Analyse in einem komplexen Softwaresystem 18.09.2013 Gebhard Ebeling Problemstellung Systemkomplexität Bei der Performance Analyse komplexer Softwaresystemen gibt es viele Einflussfaktoren,

Mehr

Notwendigkeit der Testautomatisierung? Neue Ideen, Konzepte & Werkzeuge

Notwendigkeit der Testautomatisierung? Neue Ideen, Konzepte & Werkzeuge i.s.x. Software GmbH & Co. KG Notwendigkeit der Testautomatisierung? Neue Ideen, Konzepte & Werkzeuge i.s.x. Software GmbH & Co. KG Dresden, 19. Februar 2013 Karin Eisenblätter Die i.s.x. Software GmbH

Mehr

Risiken auf Prozessebene

Risiken auf Prozessebene Risiken auf Prozessebene Ein Neuer Ansatz Armin Hepe Credit Suisse AG - IT Strategy Enabeling, Practices & Tools armin.hepe@credit-suisse.com Persönliche Vorstellung, kurz 1 Angestellter bei Credit Suisse

Mehr

Man schaut in den Kasten hinein Die innere Struktur (das "Wie") des Programms wird zur Überprüfung hinzugezogen

Man schaut in den Kasten hinein Die innere Struktur (das Wie) des Programms wird zur Überprüfung hinzugezogen 6. Test und Integration White-Box-Test Alternative Begriffe: Glas-Box-Test, Strukturtest Man schaut in den Kasten hinein Die innere Struktur (das "Wie") des Programms wird zur Überprüfung hinzugezogen

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Basiswissen Softwaretest Vergleich der Vorlesung Software-Engineering Wartung und Qualitätssicherung (Stand WS13/14) mit der 4. überarbeiteten und aktualisierten Auflage von Spillner&Linz: Basiswissen

Mehr

Manuelles Testmanagement. Einfach testen.

Manuelles Testmanagement. Einfach testen. Manuelles Testmanagement. Einfach testen. Testmanagement als Erfolgsfaktor. Ziel des Testprozesses ist die Minimierung des Restrisikos verbleibender Fehler und somit eine Bewertung der realen Qualität

Mehr

Software- und Systementwicklung

Software- und Systementwicklung Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm

Mehr