Software Engineering I
|
|
- Nikolas Meyer
- vor 8 Jahren
- Abrufe
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!
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
MehrBasiswissen 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
MehrT1 - 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
MehrQualitä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
MehrTesten - 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
MehrValidierung 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
MehrTestphase. 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
MehrTesten. 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
MehrDiplomarbeit. 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
MehrTestplan. 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
MehrSoftware - 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
MehrTesten 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
MehrTestautomatisierung. 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 *+*+ 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$
MehrSoftwaretechnik. 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
MehrSEP 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
MehrEinfü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.
MehrFragebogen 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
MehrT2 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
MehrUse 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
MehrProjektmanagement. 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
MehrSoftware-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
MehrVector 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
MehrEffizienzsteigerung 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
MehrQualitä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
MehrDas 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?
MehrEinsatz 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.» www.pse-solutions.ch ANTOINE DE SAINT-EXUPÉRY 1 PROJECT SYSTEM ENGINEERING
MehrREQUIREMENTS 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
MehrFUTURE 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
MehrPRÜ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
MehrSWE12 Ü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
MehrGPP 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.
MehrProzessbewertung 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
MehrAutomatic 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
MehrHauptseminar 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
MehrAutomatische 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
MehrTeststrategie 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
MehrAgile 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
MehrRequirements 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
Mehr2. 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.
MehrSystematisches 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
MehrTypisierung des Replikationsplan Wirries, Denis Datenbankspezialist
Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan
MehrBei 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
MehrAgile 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
MehrSDD 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
MehrLineargleichungssysteme: Additions-/ Subtraktionsverfahren
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als
MehrDie 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
MehrEin 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
MehrFragebogen: 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,
MehrOhne 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
MehrSenior 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
Mehr6 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
MehrWhitebox-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
MehrProgrammiertechnik 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
MehrInformationssystemanalyse 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
MehrKomponententest. 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
MehrSoftwaretests 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
MehrTesten 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
MehrSwitching. Ü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
Mehr4. 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
MehrAgiles 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
MehrQualitä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) Daueraufgabe: Fünf in Fünf Präsentationsaufgabe. Bereiten Sie eine fünfminütige Präsentation vor, in der Sie die fünf
MehrWirtschaftsinformatik 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
Mehr1. 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
MehrStandard 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
MehrIst 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
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
MehrJava 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
MehrUnsere 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.
MehrErstellen 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
MehrSoftwaretechnologie 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
MehrInformationen 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
Mehr2. 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
MehrSoftwareanforderungsanalyse
Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen
MehrDas 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
Mehr6. 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 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,
MehrSome 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
MehrZimmertypen. 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
MehrEinsatz 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
MehrAgiles 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
MehrTask: 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
Mehretutor 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:
MehrVgl. 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
MehrWir 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
MehrLeitfaden 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
Mehrtrivum 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
MehrAbschnitt 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
MehrProzess-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
MehrSoftware 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
MehrLeseprobe. 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
MehrModerne 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.
MehrVersion 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
MehrSuche 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
MehrTester 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
MehrEinfü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
MehrGrundlagen 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)
MehrWann 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