Software Engineering I

Größe: px
Ab Seite anzeigen:

Download "Software Engineering I"

Transkript

1 Vorlesung Analytische Qualitätssicherung: Von der Anforderung zum Testfall VE: Von der Anforderung zum Testfall 1

2 Software-Qualitätssicherung (SW-QS) Qualitätssicherung Analytische QS Konstruktive QS Artefakte prüfen: Software Ergebnisse Dokumente Reviews,... Prozesse Audits Normen, Standards, Prozessmodelle, Projektleitung, Software-Technik, Software-Architektur, Erfahrungsaustausch, Ausbildungsmaßnahmen... Testen 2

3 Analytische QS: Testen Debugging Debugging: Funktion im Laufversuch überprüfen (unsystematischer Ad-hoc-Test). Fehlerursache lokalisieren, analysieren und beheben. Konstruktiver Ansatz Testen: Fehlverhalten provozieren, reproduzieren und dokumentieren. Destruktiver Ansatz Wenn Entwickler von Testen sprechen, meinen sie oft Debugging. Problem: Gleichzeitig konstruktiv und destruktiv zu denken, ist schwierig! Testen sollte grundsätzlich systematisch erfolgen! 3

4 Fragestellungen bei der analytischen SW-QS Validation: Ist es die richtige Software? Verifikation: Die Software ist richtig! Test: Ist die Software richtig? Debugging: Wie geht man systematisch Warum ist die Software nicht richtig? und professionell vor? 4

5 Qualität: Fehler vs. Mangel Eine Situation kann nur dann als fehlerhaft eingestuft werden, wenn vorab festgelegt wurde, wie die erwartete, korrekte, also nicht fehlerhafte Situation aussehen soll. Ein Fehler ist die Nichterfüllung einer festgelegten Anforderung, eine Abweichung zwischen dem Ist-Verhalten (während der Ausführung der Tests oder des Betriebs festgestellt) und dem Soll-Verhalten (in der Spezifikation oder den Anforderungen festgelegt). Angelehnt an: DIN EN ISO 9000:2005 Qualitätsmanagementsysteme Grundlagen und Begriffe. Beuth Verlag, Berlin, 2005 Ein Mangel liegt vor, wenn eine gestellte Anforderung oder eine berechtigte Erwartung in Bezug auf einen beabsichtigten Gebrauch nicht angemessen erfüllt wird. Ein Mangel ist z.b. die Beeinträchtigung der Verwendbarkeit bei gleichzeitiger Erfüllung der Funktionalität oder die Nichterfüllung einer angemessenen Erwartung (z.b. Benutzerfreundlichkeit). 5

6 Definition: Validierung und Verifikation Validierung Prüfung, ob ein Entwicklungsergebnis die individuellen Anforderungen bezüglich einer speziellen beabsichtigten Nutzung erfüllt. Haben wir das richtige System realisiert? Wenn nicht Mangel Verifikation Prüfung, ob die Ergebnisse einer Entwicklungsphase die Vorgaben der Phaseneingangs-Dokumente erfüllen. Haben wir das System richtig realisiert? Wenn nicht Fehler 6

7 Ursachenkette für Fehler Jeder Fehler oder Mangel ist seit dem Zeitpunkt der Fertigstellung in der Software vorhanden. Er kommt jedoch erst bei der Ausführung der Software zum Tragen. Dieser Sachverhalts wird als Fehlerwirkung (failure) bezeichnet (auch Fehlfunktion, äußerer Fehler, Ausfall). Mögliche Ursachen einer Fehlerwirkung: Fehlerzustand (fault) in der Software (oder Hardware) (auch als Defekt, innerer Fehler bezeichnet) Fehlhandlung (error) einer Person Angelehnt an: DIN 66271:1995 Informationstechnik - Software-Fehler und ihre Beurteilung durch Lieferanten und Kunden, Beuth Verlag, Berlin,

8 Fehlhandlung - Definition Fehlhandlung (error) 1. Die menschliche Handlung (des Entwicklers), die zu einem Fehlerzustand in der Software führt. 2. Eine menschliche Handlung (des Anwenders), die ein unerwünschtes Ergebnis (im Sinne von Fehlerwirkung) zur Folge hat (Fehlbedienung). Problem (issue, incident) Verhalten anders als erwartet, aber Ursache noch unklar Fehlermaskierung Ist die Kompensierung eines Fehlerzustands durch andere, so dass keine Fehlerwirkung erkennbar ist. Ein Fehler wird also durch einen anderen Fehler verdeckt. 8

9 Zusammenhang Fehlerwirkung Fehlerzustand bzw. Defekt 1. Testen Fehlhandlung einer Person 2. Debugging 3. Standards, Normen, Ausbildung... in einem Programm die zum Tragen kommt 9

10 Motivation Fehler in einer Software müssen gefunden werden, ehe diese an die Anwender oder Kunden ausgeliefert wird. Um diesem Ziel nahe zu kommen, muss ein effektiver und effizienter Testprozess vorhanden sein. Hierzu müssen geeignete Methoden und Werkzeuge ausgewählt und angewendet werden. 10

11 Austesten? Ein einfaches Programm soll getestet werden, das drei ganzzahlige Eingabewerte hat. Übrige Randbedingungen haben keinen Einfluss auf das Testobjekt. Jeder Eingabewert kann bei 16 Bit Integerzahlen 2 16 unterschiedliche Werte annehmen. Bei drei unabhängigen Eingabewerten ergeben sich 2 16 * 2 16 * 2 16 = 2 48 Kombinationen. Jede dieser Kombinationen ist zu testen. Wie lange dauert es bei Tests pro Sekunde? Es sind Testfälle Dauer: ca. 90 Jahre 11

12 Austesten? Ein einfaches Programm soll getestet werden, das aus vier Verzweigungen (IF-Anweisungen) und einer umfassenden Schleife besteht und somit fünf mögliche Wege im Schleifenrumpf enthält. Unter der Annahme, dass die Verzweigungen voneinander unabhängig sind und bei einer Beschränkung der Schleifendurchläufe auf maximal 20, ergibt sich folgende Rechnung: Wie lange dauert das Austesten bei Tests pro Sekunde? A Es sind Testfälle Dauer: ca. 38 Jahre B 12

13 Erste Übung zur Testfallanalyse Ein Programm ist zu testen, das 3 ganzzahlige positive Werte einliest und als Längen eines Dreiecks interpretiert. Das Programm gibt eine Meldung aus, ob es sich um ein ungleichseitiges, gleichschenkliges oder gleichseitiges Dreieck handelt. a b a b a b c a b c c a = b c a b = c a = c b c a = b = c Welche Testfälle werden benötigt? Welche Testdaten sind sinnvoll? 13

14 Mögliche Testfälle (1) Testfälle bestehen aus Testdaten und dem Soll-Ergebnis 1. 2,3,4 - zulässiges ungleichseitiges Dreieck 2. 2,2,2 - zulässiges gleichseitiges Dreieck 3. 2,2,1 - zulässiges gleichschenkliges Dreieck 4./5. 1,2,2 / 2,1,2 - Testfälle mit Permutationen für gleichschenklige Dreiecke 6. 1,0,3 - kein Dreieck, eine Seitenangabe = 0 7./8. 0,1,3 / 1,3,0 - Permutationen 9. 5,-5,9 - kein Dreieck, eine Seitenangabe < 0 10./11. -5,5,9 / 5,9,-5 - Permutationen 14

15 Mögliche Testfälle (2) 12. 1,2,3 - kein Dreieck Summe der beiden kürzeren Seiten = 3. Seitenlänge 13./14. 2,3,1 / 3,1,2 - Permutationen 15. 1,2,4 - kein Dreieck Summe der beiden kürzeren Seiten < 3. Seitenlänge 16./17. 2,4,1 / 4,1,2 - Permutationen 18./19. 0,0,0 - kein Dreieck oder Fehlermeldung alle Seiten = 0, zusätzlich 2 Seiten = 0 - Permutationen? Max_int, Max_int, Max_int - zulässiges gleichseitiges Dreieck korrekte Dreiecksbestimmung beim Test mit maximalen Werten, zusätzliche Tests mit 2 oder 1 maximalem Wert 15

16 Mögliche Testfälle (3) ,1, Fehlermeldung»nicht ganzzahlige Werte«Permutationen? - zusätzlich mit 2 oder 3 Werten ,1,& - Fehlermeldung»Eingabe von Buchstaben oder Sonderzeichen«Permutationen? - zusätzlich mit 2 oder 3 Werten 29./30. 1,2,3,4 / 2,3 - Fehlermeldung»falsche Anzahl von Werten«(wenn Eingabe möglich) 31. Max_int/2 + 1, Max_int/2 + 1, Max_int/ zulässiges gleichschenkliges Dreieck (Überlauf oder richtige Berechnung? Bei a<=b<=c; Prüfung der Dreiecksbedingung mit a+b>c, führt a+b zum Überlauf, s.a. Testfall 20) Wie viele Tests hatten Sie überlegt? in Anlehnung an Glenford J. Myers: Methodisches Testen von Programmen. 7. Auflage

17 Spitz-, stumpf- und rechtwinklige Dreiecke Werden spitz-, stumpf- und rechtwinklige Dreiecke zusätzlich berücksichtigt, ergeben sich insgesamt 47 Testfälle. Fazit: Einfaches Problem, aber aufwendiger Test! E. H. Riedemann: Testmethoden für sequentielle und nebenläufige Software-Systeme. Teubner Verlag, Stuttgart

18 Was ist eigentlich Testen? Testen ist ein Verfahren, um Vertrauen in die Realisierung eines Systems zu schaffen Aussagen über die Qualität des Systems zu machen Aber zuerst und vor allem, Fehler zu finden. Diese Aufgabe soll der Test So früh wie möglich So kostengünstig wie möglich Für die wichtigsten Fehler zuerst leisten Testarten werden unterschieden in Statisch (Reviews, Codeanalyse) Dynamisch (stichprobenhafte Ausführung des Testobjekts) 18

19 Ziele des dynamischen Tests Nachweis der Erfüllung der festgelegten Anforderungen durch das Testobjekt Aufdeckung von eventuellen Abweichungen und Fehlerwirkungen Mit möglichst wenig Aufwand (Testfällen) möglichst viele Anforderungen überprüfen bzw. Fehler nachweisen Dynamische Tests sind immer nur Stichproben! 19

20 Was braucht der Tester? Gutes methodisches Wissen - Empfehlung: ISTQB Certified Tester Planungsdaten - Wann sind Anforderungen spezifiziert? - Wann sind sie implementiert? - Wann soll der Kunde sie zur Verfügung haben? Testbare Anforderungen - identifizierbar - Klar formuliert - verfolgbar - nachweisbar gut beschriebene Anforderungen sind unverzichtbar! 20

21 Lehrbuch zum Certified Tester - Foundation Level Andreas Spillner, Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 4. überarbeitete Auflage dpunkt.verlag, Seiten, Gebunden 39,90 Euro (D) ISBN Leseproben etc. unter: 21

22 Der Testprozess Testplanung und Steuerung Testanalyse und Testdesign Testrealisierung und Testdurchführung Testauswertung und Bericht Abschluss der Testaktivitäten Beginn Planung und Analyse und Design Diese Aktivitäten werden z.t. zeitlich überlappend oder parallel ausgeführt. Der fundamentale Testprozess ist für jede Teststufe geeignet zu gestalten. Realisierung und Durchführung Auswertung und Bericht Abschluss Ende Steuerung 22

23 Entwicklungsprozess und Testprozess Teststufen im Entwicklungsprozess nach V-Modell 23

24 Analytische Qualitätssicherung Statischer Test 24

25 Statischer Test vs. dynamischer Test Im Entwicklungsprozess werden unterschiedliche Produkte (Artefakte) erstellt Informelle Texte Modelle Formale Texte Programmcode Maschinencode Programme sind statische Beschreibungen von dynamischen Prozessen. Dynamische Tests prüfen die durch»interpretation«(ausführung) der Beschreibung resultierenden Prozesse. Statische Tests untersuchen die Beschreibung»als solche«, sie wird nicht»ausgeführt«. 25

26 Statischer Test Analyse des Testobjekts (meist ein Dokument) durch intensive Betrachtung Ziel: Finden von Fehlerzuständen (Defekten) im Dokument Verstöße gegen Spezifikationen oder einzuhaltende Standards, Fehler in Anforderungen, Fehler im Design, unzureichende Wartbarkeit und falsche Schnittstellenspezifikationen Nachweis der Verletzung von Projektplänen Ergebnisse der Untersuchungen werden darüber hinaus dazu benutzt, den Entwicklungsprozess zu optimieren Grundidee: Prävention! Fehlerzustände und Abweichungen sollen so früh wie möglich erkannt werden, noch bevor sie im weiteren Verlauf der Softwareentwicklung zum Tragen kommen und aufwändige Nach- oder Verbesserungen nach sich ziehen 26

27 Prüfende Verfahren Reviews überprüfen am Ende jeder Entwicklungsphase Umfang und Qualität der Zwischenprodukte. Projektpersonal, Auftragnehmer-management und Auftraggeber entscheiden gemeinsam, ob die nächste Phase angegangen werden kann Audits sind offizielle Reviews zur Verifikation besonders kritischer Teile durch das QS-Personal Peer Review oder Walk-Through. Es geht dabei um eine methodische Examinierung der Zwischenprodukte durch sachkundige Kollegen (Peers). Ziel ist, Fehler zu finden und Bereiche, in denen Änderungen erforderlich sind Inspection ist eine sehr formale Gruppensitzung, in der die zu inspizierende Unterlage vom Autor vorgelesen und sequentiell Wort für Wort durchgearbeitet wird 27

28 Ein Selbsttest Wie viele "F" kommen im folgenden Text vor? FINISHED FILES ARE THE RE- SULT OF YEARS OF SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE OF YEARS 28

29 Selbsttest Es sind sechs! Wie viele hatten Sie gezählt? Drei zu finden ist normal - sechs wirklich gut! Irren ist menschlich FINISHED FILES ARE THE RE- SULT OF YEARS OF SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE OF YEARS 29

30 Die magische Zahl Sieben Problem: Begrenzte menschliche Wahrnehmungsfähigkeit Die Millersche Zahl bezeichnet die von George A. Miller festgestellte Tatsache, dass ein Mensch gleichzeitig nur 7±2 Informationseinheiten (Chunks) im Kurzzeitgedächtnis präsent halten kann. Die Größe des Kurzzeitgedächtnisses ist genetisch determiniert und kann auch durch "Training" nicht gesteigert werden. Der diesbezüglich von Miller verfasste Artikel "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" ist einer der meistzitierten Artikel im Bereich der Psychologie. (Quelle: 30

31 Manuelle vs. automatisierte Prüfung Betrachtung des Prüfobjekts durch Mensch oder Werkzeug Reviews Manuelle Prüfungen durch eine oder mehrere Personen Menschliche Analyse- und Denkfähigkeit wird genutzt, um komplexe Sachverhalte zu prüfen und zu bewerten Kann bei allen Dokumenten durchgeführt werden, die während des Softwareentwicklungsprozesses erstellt oder verwendet werden (z. B. Vertrag, Anforderungsspezifikation, Designspezifikation, Quelltext, Testkonzepte, Testspezifikationen, Testfälle, Testskripte oder Anwenderhandbücher) Statische Analyse Automatisierte Prüfungen durch entsprechende Werkzeuge Nur bei Dokumenten mit formaler Struktur möglich (z.b. Programmtext, UML-Diagramme) 31

32 Statische Analyse und Reviews Stehen in einem engen Zusammenhang Wird vor dem Review eine statische Analyse durchgeführt, können bereits eine Anzahl von Fehlern und Unstimmigkeiten nachgewiesen werden und die Menge der im Review zu berücksichtigenden Aspekte ist erheblich geringer Da statische Analysen werkzeuggestützt durchgeführt werden, ist der Aufwand wesentlich niedriger als beim Review Also: 1. Statische Analyse und 2. Review 32

33 Statische Analyse von Programmcode Fehler(zustände) bzw. fehlerträchtige Situationen, die mit der statischen Analyse von Programmcode nachgewiesen werden können, sind beispielsweise Verletzung der Syntax Abweichungen von Konventionen und Standards Kontrollflussanomalien Datenflussanomalien Alle Compiler führen eine statische Analyse des Programmtextes durch, indem sie die Einhaltung der Syntax der jeweiligen Programmiersprache prüfen Die meisten modernen Compiler bieten darüber hinaus noch zusätzliche statische Analysen Neben den Compilern gibt es spezielle Werkzeuge, sogenannte Analysatoren, die zur Durchführung bestimmter Analysen eingesetzt werden 33

34 Statische Analysewerkzeuge Einige freie Werkzeuge zur statischen Codeanalyse CCCC ( JUtils ( PyChecker ( Einige kommerzielle Werkzeuge zur statischen Codeanalyse PC-Lint Klocwork Coverity Polyspace 34

35 Analytische Qualitätssicherung Dynamischer Test 35

36 Statischer Test vs. dynamischer Test Programme sind statische Beschreibungen von dynamischen Prozessen Statische Tests untersuchen die Beschreibung»als solche«, sie wird nicht»ausgeführt«artefakte des Entwicklungsprozesses, z.b informelle Texte, Modelle, formale Texte, Programmcode,... Dynamische Tests prüfen die durch»interpretation«(ausführung) der Beschreibung resultierenden Prozesse. Das Testobjekt wird im dynamischen Test auf einem Prozessor ausgeführt Bereitstellen von Eingangsdaten Beobachten der Ausgangsdaten Eingangsdaten Randbedingungen Vorbedingungen Nachbedingungen Testobjekt Prozessor Ausgangsdaten 36

37 Dynamischer Test in»unteren«teststufen Die Ausführung dynamischer Tests erfordert ein ablauffähiges Programm Einzelne Klassen, Module/Komponenten und Teilsysteme sind jedoch in der Regel für sich alleine nicht lauffähig, da sie oft nur Operationen/Dienste für andere Softwareeinheiten anbieten kein Hauptprogramm zur Koordination des Ablaufes haben sich oft auf Operationen/Diensten anderer Softwareeinheiten abstützen In den unteren Teststufen Klassen-/Modultest, Komponententest und Integrationstest muss das Testobjekt also in einen entsprechenden Testrahmen eingebettet werden Randbedingungen Vorbedingungen Nachbedingungen Oft als Unit-Test bezeichnet Eingangsdaten Testobjekt Ausgangsdaten Prozessor 37

38 Aufbau eines Testrahmens Point of Control: Schnittstelle, über die das Testobjekt mit Testdaten versorgt wird Testfall 1 Testfall 2... Testfall m Testtreiber Stub 1 PoC Testausgaben Stub 2... Testobjekt PoO Vergleich & Protokoll Stub n Platzhalter Laufzeitumgebung, Analysewerkzeuge, Simulatoren, Monitore Prozessor Point of Observation: Schnittstelle, an der die Reaktionen und Ausgaben des Testobjekts beobachtet und aufgezeichnet werden 38

39 Unit Test Begriffe Testrahmen (test bed) Sammlung aller Programme (u. a. Testtreiber und Platzhalter), die notwendig sind, um Testfälle auszuführen, auszuwerten und Testprotokolle aufzuzeichnen Platzhalter (stub) Platzhalter werden beim dynamischen Komponenten- und Integrationstest benötigt, um noch nicht implementierte Komponenten für die Testdurchführung zu ersetzen bzw. zu simulieren Dummy Platzhalter mit rudimentärer Funktionalität Mock Platzhalter mit erweiterter Funktionalität für Testzwecke (Logging, Plausibilitätsprüfung) 39

40 Fragestellungen beim Entwurf von Testfällen Wie viele Tests sind notwendig? Welche Testdaten sollen verwendet werden? Wie können fehler-sensitive Tests gefunden werden? Wie vermeidet man redundante Test? Wurden Testfälle übersehen? Wann kann man mit Testen aufhören? Testentwurfsverfahren! 40

41 Dynamischer Test Testentwurfsverfahren Testentwurfsverfahren (synonym: Testfallentwurfsverfahren) Eine Vorgehensweise, nach der Testfälle abgeleitet oder ausgewählt werden Black-Box (Spezifikationsorientierte) Testentwurfsverfahren Systematische Herleitung und Auswahl von Testfällen basierend auf einer Analyse der funktionalen oder nichtfunktionalen Spezifikation einer Komponente oder Systems ohne Berücksichtigung der internen Struktur. Also keine Informationen über den Programmtext und den inneren Aufbau Beobachtet wird nur das Verhalten des Testobjekts von außen (PoO - Point of Observation liegt außerhalb des Testobjekts) Steuerung des Ablaufs des Testobjektes nur durch die Wahl der Eingabetestdaten (PoC - Point of Control liegt außerhalb des Testobjektes) White-Box (Strukturorientierte) Testentwurfsverfahren Systematische Herleitung und Auswahl von Testfällen basierend auf Informationen über die interne Struktur einer Komponente oder Systems 41

42 Übersicht Testentwurfsverfahren Black-box Test Eingangsdaten Ohne Kenntnis der Programmlogik abgeleitet Testobjekt Ausgangsdaten White-box Test Eingangsdaten Ausgangsdaten Mit Kenntnis der Programmlogik abgeleitet 42

43 Testfallentwurf (1) Beginn Planung und Analyse und Design Anforderungs- Definition Test Realisierung und Durchführung Auswertung und Bericht Steuerung Abschluss Aus den Anforderungen müssen Testfälle abgeleitet werden! Alle Anforderungen müssen durch Testfälle ausreichend abgedeckt werden! Ende Wie soll man vorgehen? Prozess und Methodik werden benötigt! 43

44 Testfallentwurf (2) Beginn Planung und Teststrategie Analyse und Design Realisierung und Durchführung Auswertung und Bericht Steuerung Abschluss Anforderungs- Definition Testentwurfstechniken Test Ende Review Teststrategie bestimmt die Wahl der Testentwurfstechniken! 44

45 Bekannte Teststrategien Anforderungsbasiert Anwendungsfallbasiert 45

46 Bekannte Testfallentwurfsmethoden Äquivalenzklassenanalyse Klassifikationsbaummethode Grenzwertanalyse 46

47 Testdatenbestimmung Äquivalenzklassenmethode - Klassen von gleichartigen Eingabewerten anhand der Spezifikation => Ein Wert pro Klasse ( Repräsentant ) genügt. - Gültige und ungültige Äquivalenzklassen unterscheiden: Minimierung der Testfälle für gültige Äquivalenzklassen Ein Testdatum aus einer ungültigen Äquivalenzklasse nur in Kombination mit Werten aus gültigen Äquivalenzklassen anderer Parameter! Grenzwertanalyse - Klassengrenzen werden als Testdaten verwendet - Fehlerorientierte Erweiterung der Äquivalenzklassenbildung min_int-1 min_int+1 max_int-1 max_int+1 min_int max_int 47

48 Äquivalenzklassenbildung......in der Schlangenschule 48

49 Äquivalenzklassen und Grenzwerte... 49

50 Systemtest Grundsätzliche Methodik Testfallentwurf ist grundsätzlich anforderungsbasiert! Anforderungen müssen identifizierbar sein Jede Anforderung in mindestens einem Testfall abdecken! Traceability sicherstellen! So wenig Testfälle wie möglich spezifizieren Ein Testfall kann auch mehrere Anforderungen abdecken! Systematische, nachvollziehbare Methodik anwenden! Geeignete Methoden zur Testfallreduktion sind: Äquivalenzklassenanalyse Grenzwertanalyse Paarweise Kombination Testfälle generisch spezifizieren Testdaten und Testanweisung separieren! Dann sind sie wartbarer und übertragbar 50

51 Requirements Traceability SRS STP [SRS.FEATURE.ID] Feature Name Description Limitations Interfaces Default Settings [TS.FEATURE] Testsuite Name [TC.FEATURE.001] Testcase Name [TC.FEATURE.002] Testcase Name [TC.FEATURE.003] Testcase Name [TC.FEATURE.004] Testcase Name [TC.FEATURE.005] Testcase Name Traceability OK! 51

52 Testfallentwurfs-Prozess SRS Identifikation eines Testfalls ( STP) Testfall entwerfen und optimieren (TCS) Alle Anforderungen abgedeckt? STP 52

53 1. Anforderungen in SRS reviewen Qualitätsansprüche an Anforderungen: Vollständigkeit Korrektheit Verfolgbarkeit Gewichtbarkeit Verständlichkeit (für alle Stakeholder) Eindeutigkeit Testbarkeit Aktualität Feedback an Requirements Engineer - wenn Nachbesserung erforderlich Anforderungs- Definition Anforderungsreview Feedback 53

54 2. Testfälle ableiten im STP 54

55 3. Testfallverwaltung Namenskonvention für Testfälle notwendig bei einer großen Anzahl von Testfällen! TCT.FUNC.REQID.SQNR.TT (Short Description of Test Objective) TCT = Testcase Type (TS = Test Suite TC = Testcase FUNC = Abbreviation for the related requirement functionality REQID = sequential numbering of testcase, related to requirement numbering (123) SEQNR = sequential numbering of testcase, not related to requirement numbering (001) TT = Test type (C = Conformance, F = Functional, L = Load/Stress, combined with A = Automated and/or S = Smoke/Regression, ) Short Description with less than 50 characters Korrekte Testfallbeschreibung beachten This testcase verifies The system supports (Requirements-Beschreibung!) TCS enthält Testfallbeschreibungen Alternativ: Testfallmanagementsystem 55

56 4. Testfälle anlegen in TCS Test case ID: Name: <TC.CONF.001.F> Device parameter configuration Req.-ID: HID.GUI.001 (TBL); HID.GUI.006 (ERR); HID.DEVCONF.001; HID.DEVCONF.002; HID.DEVCONF.003; HID.DEVCONF.004 Description: The test case verifies the correct functionality of the device configuration of the IP address, net mask, default gateway and name. It verifies the display of the error message due to the input boundaries. The test case uses the test data from table TD.001 and TD.002. The test set up consists of a computer, with at least 2 devices connected to, and the software. Test Steps Step Action Expected result 1 Click on first line First line is selected 2 Click on the properties symbol in the toolbar and fill in the following data: IP= ,GW= , NM= , Name = Device_1 Properties dialog is opened. Valid parameters can be set; invalid parameters produce the display of an error message. 3 Click on the properties symbol in the toolbar and fill in the following data: IP= ,GW= , NM= , Name = Device_1 Properties dialog is opened. Valid parameters can be set; invalid parameters produce the display of an error message. 56

57 5. Testfälle entwerfen und optimieren Testfälle inhaltlich im Detail spezifizieren ( TCS) Anwendung von Äquivalenzklassenbildung (gültige und ungültige!) Grenzwertanalyse Paarbildung. Testfälle inhaltlich optimieren z.b. Datengetriebenen Ansatz anwenden Testfälle zusammenfassen Zum abdecken mehrerer Anforderungen Zum abdecken von Use-Case Szenarien 57

58 6. Optimierter Testfall z.b. Testfallbeschreibung mit separierten Testdaten ID: Name: Req.-ID: Description: <TC.CONF.001.F> Test case Device parameter configuration HID.GUI.001 (TBL); HID.GUI.006 (ERR); HID.DEVCONF.001; HID.DEVCONF.002; HID.DEVCONF.003; HID.DEVCONF.004 The test case verifies the correct functionality of the device configuration of the IP address, net mask, default gateway and name. It verifies the display of the error message due to the input boundaries. The test case uses the test data from table TD.001 and TD.002. The test set up consists of a computer, with at least 2 devices connected to, and the software. Test Steps Step Action Expected result 1 Click on a line x in device list Line x is selected 2 Click on the properties symbol in the toolbar and fill in dataset of TD.001 Properties dialog is opened. Valid parameters can be set; invalid parameters produce the display of an error message. Test data: TD.001 Dataset IP address Default gateway Net mask Name X_%&/()=? Device_ XDeviceY 58

59 7. Automatisierung von Testfällen Separation von Testcode und Testdaten führt zu Besserer Wartbarkeit Testdaten und Testcode können unabhängig voneinander geändert werden Besserer Optimierbarkeit der Testdaten In Tabellenform Einfacher Automatisierbarkeit Testcode ist praktisch schon Pseudocode Testdaten-Tabelle kann vom Automatisierungsskript eingelesen und abgearbeitet werden Voraussetzung für Automatisierbarkeit: System muss automatisierbare PoC und PoO für die zu testende Funktionalität bereitstellen! 59

60 Ergebnis Resultierende Tests sind: Effizient und Effektiv Strukturiert Nachvollziehbar Übersichtlich Übertragbar und Wartbar 60

61 Fazit Anforderungsbasierung ist IMMER die minimale Teststrategie Gut beschriebene Anforderungen sind Voraussetzung Systematische Methodik macht Testfallentwurf und Testautomatisierung effizient Teststrategie Anforderungs- Definition Testentwurfstechniken Test Review 61

62 Vorlesung SWE I Testfall-Managementsystem VE 20: Von der Anforderung zum Testfall 62

63 Traceability Matrix 63

64 Requirements Coverage & Traceability 64

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit

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

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

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

Validierung und Verifikation

Validierung und Verifikation Martin Glinz Harald Gall Software Engineering Kapitel 7 Validierung und Verifikation Universität Zürich Institut für Informatik 2005, 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe

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

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

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

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

Software - Testung ETIS SS05

Software - Testung ETIS SS05 Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks

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

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

,$ -. "+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

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

SEP 114. Design by Contract

SEP 114. Design by Contract Design by Contract SEP 114 Design by Contract Teile das zu entwickelnde Programm in kleine Einheiten (Klassen, Methoden), die unabhängig voneinander entwickelt und überprüft werden können. Einheiten mit

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

Fragebogen ISONORM 9241/110-S

Fragebogen ISONORM 9241/110-S Fragebogen ISONORM 9241/110-S Beurteilung von Software auf Grundlage der Internationalen Ergonomie-Norm DIN EN ISO 9241-110 von Prof. Dr. Jochen Prümper www.seikumu.de Fragebogen ISONORM 9241/110-S Seite

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

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 9. Vorlesung 1 Pläne Kein Plan überlebt die erste Feindberührung - Feldmarschall Helmuth von Moltke Prognosen sind schwierig, besonders wenn sie die Zukunft

Mehr

Software-Entwicklungsprozesse zertifizieren

Software-Entwicklungsprozesse zertifizieren VDE-MedTech Tutorial Software-Entwicklungsprozesse zertifizieren Dipl.-Ing. Michael Bothe, MBA VDE Prüf- und Zertifizierungsinstitut GmbH BMT 2013 im Grazer Kongress 19.09.2013, 10:00-10:30 Uhr, Konferenzraum

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

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

Qualitätssicherung. Was ist Qualität?

Qualitätssicherung. Was ist Qualität? Ein Überblick Methoden und Werkzeuge zur Softwareproduktion Was ist Qualität? "Als Qualität eines Gegenstandes bezeichnen wir die Gesamtheit seiner charakteristischen Eigenschaften" Hesse et al. 2 Was

Mehr

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin Fragestellungen: Warum reicht das Lastenheft nicht aus? Was kann ich mit dem Lastenheft machen? Was unterscheidet das Pflichtenheft vom Lastenheft? Was gehört zum Auftragsumfang einer Individualsoftware?

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

«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»

«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.» «PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.» www.pse-solutions.ch ANTOINE DE SAINT-EXUPÉRY 1 PROJECT SYSTEM ENGINEERING

Mehr

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 QUALITÄT FÜR SIE Qualität zeigt sich in Ergebnissen und Erfolgen. Sie hängt von der jeweiligen Problemstellung ab, deshalb sehen wir

Mehr

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING 18/11/13 Requirements Engineering 21 November 2013 DIE GRUNDFRAGEN Wie erhält der Kunde den größten Nutzen? Wie kann der Kunde am besten spezifizieren, was er haben will? Welchen Detailierungsgrad braucht

Mehr

PRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr -

PRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr - PRÜFUNG FÜR ELEKTROINGENIEURE Softwaretechnik I Musterlösung SS 12 - Ohne Gewähr - LfdNr. Thema Punkte Zeitbedarf in min 1 Analyse und Entwurf 15 30 2 Basistechniken und Test 15 30 3 Projektmanagement

Mehr

SWE12 Übungen Software-Engineering

SWE12 Übungen Software-Engineering 1 Übungen Software-Engineering Software-Qualitätssicherung / Software-Qualitätsmanagement 2 Aufgabe 1 Ordnen Sie die folgenden Zitate dem entsprechenden Ansatz zum Qualitätsbegriff zu und begründen Sie

Mehr

GPP Projekte gemeinsam zum Erfolg führen

GPP Projekte gemeinsam zum Erfolg führen GPP Projekte gemeinsam zum Erfolg führen IT-Sicherheit Schaffen Sie dauerhaft wirksame IT-Sicherheit nach zivilen oder militärischen Standards wie der ISO 27001, dem BSI Grundschutz oder der ZDv 54/100.

Mehr

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08 Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer

Mehr

Automatic Generation of Testcases for System Level Tests. Dr. Martin Beißer, sepp.med gmbh

Automatic Generation of Testcases for System Level Tests. Dr. Martin Beißer, sepp.med gmbh Automatic Generation of Testcases for System Level Tests Dr. Martin Beißer, sepp.med gmbh Systemtest Der Systemtest ist die Teststufe, bei der das gesamte System gegen die gesamten Anforderungen (funktionale

Mehr

Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop

Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop Christoph Niedermayr 20.01.2005 Überblick 1 2 X in the loop Rapid Prototyping Begriffe Was versteht man unter statischem

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

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

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

Mehr

Requirements Engineering Die Dinge von Anfang an richtig machen

Requirements Engineering Die Dinge von Anfang an richtig machen Requirements Engineering Die Dinge von Anfang an richtig machen Martin Glinz www.ifi.uzh.ch/~glinz Erstes Requirements Engineering Forum Zürich, 13. November 2008 Universität Zürich Institut für Informatik

Mehr

2. Psychologische Fragen. Nicht genannt.

2. Psychologische Fragen. Nicht genannt. Checkliste für die Beurteilung psychologischer Gutachten durch Fachfremde Gliederung eines Gutachtens 1. Nennung des Auftraggebers und Fragestellung des Auftraggebers. 2. Psychologische Fragen. Nicht genannt.

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

Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist

Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan

Mehr

Bei der Focus Methode handelt es sich um eine Analyse-Methode die der Erkennung und Abstellung von Fehlerzuständen dient.

Bei der Focus Methode handelt es sich um eine Analyse-Methode die der Erkennung und Abstellung von Fehlerzuständen dient. Beschreibung der Focus Methode Bei der Focus Methode handelt es sich um eine Analyse-Methode die der Erkennung und Abstellung von Fehlerzuständen dient. 1. F = Failure / Finding An dieser Stelle wird der

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als

Mehr

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen

Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Westfälische Provinzial Versicherung AG Provinzial-Allee 1 48131 Münster für die Anwendung ProSa, Stand 19.04.2008

Mehr

Ein Testprozess für Modellbasiertes Testen

Ein Testprozess für Modellbasiertes Testen Ein Testprozess für Modellbasiertes Testen Seminar: Software-Qualitätssicherung Tobias Eckardt 8. Juli 2008 Testen von Softwaresystemen Fehler in einer adaptiven Geschwindigkeitsregelung (engl. adaptive

Mehr

Fragebogen: Abschlussbefragung

Fragebogen: Abschlussbefragung Fragebogen: Abschlussbefragung Vielen Dank, dass Sie die Ameise - Schulung durchgeführt haben. Abschließend möchten wir Ihnen noch einige Fragen zu Ihrer subjektiven Einschätzung unseres Simulationssystems,

Mehr

Ohne Fehler geht es nicht Doch wie viele Fehler sind erlaubt?

Ohne Fehler geht es nicht Doch wie viele Fehler sind erlaubt? Ohne Fehler geht es nicht Doch wie viele Fehler sind erlaubt? Behandelte Fragestellungen Was besagt eine Fehlerquote? Welche Bezugsgröße ist geeignet? Welche Fehlerquote ist gerade noch zulässig? Wie stellt

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

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

Whitebox-Tests: Allgemeines

Whitebox-Tests: Allgemeines -Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv

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

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät

Mehr

Komponententest. Testen von Software Systemen. Übung 02 SS 2009 Version: 1.0 09.06.2009

Komponententest. Testen von Software Systemen. Übung 02 SS 2009 Version: 1.0 09.06.2009 Testen von Software Systemen Übung 02 SS 2009 Version: 1.0 09.06.2009 Komponententest Kunde: Dr. Reinhold Plösch Dr. Johannes Sametinger Kundenreferenz: 259.019 Team 19 Mitarbeiter: Christian Märzinger

Mehr

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen Alexander Schunk Henry Trobisch Inhalt 1. Vergleich der Unit-Tests... 2 2. Vergleich der Codeabdeckungs-Tests... 2 3. Vergleich

Mehr

Testen mit JUnit. Motivation

Testen mit JUnit. Motivation Test First Design for Test in Eclipse (eigentlich: ) zu einer Klasse Beispiel zur Demonstration Ergänzungen Test First "Immer dann, wenn Du in Versuchung kommst, etwas wie eine print- Anweisung oder einen

Mehr

Switching. Übung 7 Spanning Tree. 7.1 Szenario

Switching. Übung 7 Spanning Tree. 7.1 Szenario Übung 7 Spanning Tree 7.1 Szenario In der folgenden Übung konfigurieren Sie Spanning Tree. An jeweils einem Switch schließen Sie Ihre Rechner über Port 24 an. Beide Switche sind direkt über 2 Patchkabel

Mehr

4. AUSSAGENLOGIK: SYNTAX. Der Unterschied zwischen Objektsprache und Metasprache lässt sich folgendermaßen charakterisieren:

4. AUSSAGENLOGIK: SYNTAX. Der Unterschied zwischen Objektsprache und Metasprache lässt sich folgendermaßen charakterisieren: 4. AUSSAGENLOGIK: SYNTAX 4.1 Objektsprache und Metasprache 4.2 Gebrauch und Erwähnung 4.3 Metavariablen: Verallgemeinerndes Sprechen über Ausdrücke von AL 4.4 Die Sprache der Aussagenlogik 4.5 Terminologie

Mehr

Agiles Design. Dr.-Ing. Uwe Doetzkies Gesellschaft für Informatik mail: gi@uwe.doetzkies.de

Agiles Design. Dr.-Ing. Uwe Doetzkies Gesellschaft für Informatik mail: gi@uwe.doetzkies.de Agiles Design Dr.-Ing. Uwe Doetzkies Dr.-Ing. Uwe Doetzkies Gesellschaft für Informatik mail: gi@uwe.doetzkies.de startupcamp berlin 15.3.2013 Regionalgruppe Berlin/Brandenburg Arbeitskreis Freiberufler

Mehr

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit 1 DYNAMISCHER TEST Whitebox Testen mit JUnit Übersicht 2 1. Grundlagen des Unittests 1. Units 2. Unit Testing 2. Testverfahren 1. Blackbox 2. Whitebox 3. Unit Testing mit Eclipse 4. Besprechung der Übungsaufgabe

Mehr

Übungsblatt 4: Requirements Engineering (2) (für die Übungswoche 14.11. 18.11.2011)

Übungsblatt 4: Requirements Engineering (2) (für die Übungswoche 14.11. 18.11.2011) Übungsblatt 4: Requirements Engineering (2) (für die Übungswoche 14.11. 18.11.2011) Daueraufgabe: Fünf in Fünf Präsentationsaufgabe. Bereiten Sie eine fünfminütige Präsentation vor, in der Sie die fünf

Mehr

Wirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung

Wirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung Wirtschaftsinformatik I Teil 2 Sommersemester 2008 1. Übung Sarah Mund, Kirstin Simon, Markus Trierweiler, Christian Molitor, Jonathan Jäger, Björn Kirsten Aufgabenstellung Diskutieren Sie die Vor- und

Mehr

1. Einführung. 2. Weitere Konten anlegen

1. Einführung. 2. Weitere Konten anlegen 1. Einführung In orgamax stehen Ihnen die gängigsten Konten des Kontenrahmens SKR03 und SKR04 zur Verfügung. Damit sind im Normalfall alle Konten abgedeckt, die Sie zur Verbuchung benötigen. Eine ausführliche

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

Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken?

Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? UErörterung zu dem Thema Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? 2000 by christoph hoffmann Seite I Gliederung 1. In zu großen Mengen ist alles schädlich. 2.

Mehr

«Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen

«Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen 18 «Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen teilnimmt und teilhat.» 3Das Konzept der Funktionalen

Mehr

Java Entwicklung für Embedded Devices Best & Worst Practices!

Java Entwicklung für Embedded Devices Best & Worst Practices! Java Entwicklung für Embedded Devices! George Mesesan Microdoc GmbH Natürlich können wir dieses neue log4j Bundle auch auf dem Device verwenden. Ist doch alles Java. Java Micro Edition (ME) Java Standard

Mehr

Unsere Produkte. Wir automatisieren Ihren Waren- und Informationsfluss. Wir unterstützen Ihren Verkaufsaußendienst.

Unsere Produkte. Wir automatisieren Ihren Waren- und Informationsfluss. Wir unterstützen Ihren Verkaufsaußendienst. Die clevere Auftragserfassung Unsere Produkte Das smarte Lagerverwaltungssystem Die Warenwirtschaft für den Handel Wir unterstützen Ihren Verkaufsaußendienst. Wir automatisieren Ihren Waren- und Informationsfluss.

Mehr

Erstellen einer digitalen Signatur für Adobe-Formulare

Erstellen einer digitalen Signatur für Adobe-Formulare Erstellen einer digitalen Signatur für Adobe-Formulare (Hubert Straub 24.07.13) Die beiden Probleme beim Versenden digitaler Dokumente sind einmal die Prüfung der Authentizität des Absenders (was meist

Mehr

Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler

Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungen zur Vorlesung Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungsblatt 4 Lösungshilfe. Aufgabe 1. Zustandsdiagramm (8 Punkte) Geben Sie ein Zustandsdiagramm für

Mehr

Informationen zur Erstellung des Projektantrags in den IT-Berufen und zum AbschlussPrüfungOnlineSystem (CIC-APrOS)

Informationen zur Erstellung des Projektantrags in den IT-Berufen und zum AbschlussPrüfungOnlineSystem (CIC-APrOS) Informationen zur Erstellung des Projektantrags in den IT-Berufen und zum AbschlussPrüfungOnlineSystem (CIC-APrOS) Allgemeine Hinweise zum Projektantrag Den Prüferinnen und Prüfern der Industrie- und Handelskammer

Mehr

2. Einrichtung der ODBC-Schnittstelle aus orgamax (für 32-bit-Anwendungen)

2. Einrichtung der ODBC-Schnittstelle aus orgamax (für 32-bit-Anwendungen) 1. Einführung: Über den ODBC-Zugriff können Sie bestimmte Daten aus Ihren orgamax-mandanten in anderen Anwendungen (beispielsweise Microsoft Excel oder Microsoft Access) einlesen. Dies bietet sich beispielsweise

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen

Mehr

Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten

Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten Das große x -4 Alles über das Wer kann beantragen? Generell kann jeder beantragen! Eltern (Mütter UND Väter), die schon während ihrer Elternzeit wieder in Teilzeit arbeiten möchten. Eltern, die während

Mehr

6. Programmentwicklung

6. Programmentwicklung 6. Programmentwicklung Fertigungsprozess Qualitativ hochwertige Software ist ein Industrieprodukt -> Methoden der Industrie übertragen auf der Herstellprozess -> Herstellprozess gliedert sich in Phasen

Mehr

Überprüfung der digital signierten E-Rechnung

Überprüfung der digital signierten E-Rechnung Überprüfung der digital signierten E-Rechnung Aufgrund des BMF-Erlasses vom Juli 2005 (BMF-010219/0183-IV/9/2005) gelten ab 01.01.2006 nur noch jene elektronischen Rechnungen als vorsteuerabzugspflichtig,

Mehr

Some Software Engineering Principles

Some Software Engineering Principles David L. Parnas: Some Software Engineering Principles Marco Oppel 30.06.2004 Seminar Software-Architektur Institut für Informatik Humboldt Universität zu Berlin 1 Problemstellung Software Engineering Multi-Personen

Mehr

Zimmertypen. Zimmertypen anlegen

Zimmertypen. Zimmertypen anlegen Zimmertypen anlegen Hier legen Sie Ihre Zimmer an, damit sie auf der Homepage dargestellt werden und online buchbar gemacht werden können. Wobei wir ausdrücklich darauf hinweisen möchten, dass es ganz

Mehr

Einsatz von xalerator. bei den. Ergo Direkt Versicherungen. Bereich Versicherungstechnik/Leben

Einsatz von xalerator. bei den. Ergo Direkt Versicherungen. Bereich Versicherungstechnik/Leben Einsatz von xalerator bei den Ergo Direkt Versicherungen Bereich Versicherungstechnik/Leben Einführung Die Ergo Direkt Versicherungen wurden 1984 als Finanzdienstleistungs-Segment des Quelle Versandhandels

Mehr

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen

Mehr

Task: Nmap Skripte ausführen

Task: Nmap Skripte ausführen Task: Nmap Skripte ausführen Inhalt Einfache Netzwerkscans mit NSE Ausführen des Scans Anpassung der Parameter Einleitung Copyright 2009-2015 Greenbone Networks GmbH Herkunft und aktuellste Version dieses

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf 2 Nach derbefragung aller Stakeholder und der Dokumentation

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1.

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1. Leitfaden API Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza Dokumentenstatus Freigegeben at work Version 1.0 Verteiler Fachgruppe API Änderungen Datum Version Autor Inhaltsverzeichnis 1 Beschreibung

Mehr

trivum Multiroom System Konfigurations- Anleitung Erstellen eines RS232 Protokolls am Bespiel eines Marantz SR7005

trivum Multiroom System Konfigurations- Anleitung Erstellen eines RS232 Protokolls am Bespiel eines Marantz SR7005 trivum Multiroom System Konfigurations- Anleitung Erstellen eines RS232 Protokolls am Bespiel eines Marantz SR7005 2 Inhalt 1. Anleitung zum Einbinden eines über RS232 zu steuernden Devices...3 1.2 Konfiguration

Mehr

Abschnitt 2 Vier Fragen, jeweils 5 Punkte pro Frage erreichbar (Maximal 20 Punkte)

Abschnitt 2 Vier Fragen, jeweils 5 Punkte pro Frage erreichbar (Maximal 20 Punkte) Abschnitt 1 2. Listen Sie zwei Abschnitte von ISO 9001 (Nummer und Titel) auf. die das Qualitätsmanagementprinzip Systemorientierter Ansatz unterstützen. (2 Punkte) Abschnitt 2 Vier Fragen, jeweils 5 Punkte

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

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle

Mehr

Leseprobe. Thomas Konert, Achim Schmidt. Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9. Weitere Informationen oder Bestellungen unter

Leseprobe. Thomas Konert, Achim Schmidt. Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9. Weitere Informationen oder Bestellungen unter Leseprobe Thomas Konert, Achim Schmidt Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41230-9 sowie im Buchhandel. Carl

Mehr

Moderne Behandlung des Grauen Stars

Moderne Behandlung des Grauen Stars Katarakt Moderne Behandlung des Grauen Stars Sehr geehrte Patientin, sehr geehrter Patient, Bei Ihnen wurde eine Trübung der Augenlinse festgestellt, die umgangssprachlich auch Grauer Star genannt wird.

Mehr

Version smarter mobile(zu finden unter Einstellungen, Siehe Bild) : Gerät/Typ(z.B. Panasonic Toughbook, Ipad Air, Handy Samsung S1):

Version smarter mobile(zu finden unter Einstellungen, Siehe Bild) : Gerät/Typ(z.B. Panasonic Toughbook, Ipad Air, Handy Samsung S1): Supportanfrage ESN Bitte füllen Sie zu jeder Supportanfrage diese Vorlage aus. Sie helfen uns damit, Ihre Anfrage kompetent und schnell beantworten zu können. Verwenden Sie für jedes einzelne Thema jeweils

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Tester als Coach ein Erfolgsmodell

Tester als Coach ein Erfolgsmodell Tester als Coach ein Erfolgsmodell Ein Praxisbericht aus dem Leben eines Testers in Scrum-Projekten - Michael Egli bbv Software Services AG www.bbv.ch 03.09.2015 Q-Event 2015 Erfolgsfaktor Testing 1 Inhaltsverzeichnis

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

Grundlagen der Theoretischen Informatik, SoSe 2008

Grundlagen der Theoretischen Informatik, SoSe 2008 1. Aufgabenblatt zur Vorlesung Grundlagen der Theoretischen Informatik, SoSe 2008 (Dr. Frank Hoffmann) Lösung von Manuel Jain und Benjamin Bortfeldt Aufgabe 2 Zustandsdiagramme (6 Punkte, wird korrigiert)

Mehr

Wann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt?

Wann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt? DGSV-Kongress 2009 Wann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt? Sybille Andrée Betriebswirtin für und Sozialmanagement (FH-SRH) Prokuristin HSD Händschke Software

Mehr