Software Engineering. 9. Testen
|
|
- Fanny Diefenbach
- vor 8 Jahren
- Abrufe
Transkript
1 Software Engineering 9. Testen
2 Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Testen Konfigurationsmanagement Abnahme, Einführung, Wartung und Pflege Vorlesung basiert auf: Spillner/Linz: Basiswissen Softwaretest
3 Fehlerbegriff Fehler Nichterfüllung einer festgelegten Anforderung Abweichung zwischen Ist-Verhalten und Soll-Verhalten Fehlerwirkung (failure) Fehler wird sichtbar beim Testen oder Anwenden Fehlerursache (Defekt, fault) Entstehung während der Software-Entwicklung Z. B. falsch programmierte Anweisung Ursache für Defekt Fehlerhandlung einer Person (Error) Fehlermaskierung Ein Defekt wird durch einen oder mehrere andere Defekte kompensiert. Fehlerwirkung tritt erst zutage, wenn der andere Defekt behoben ist
4 Testen vs. Debugging Debugging Lokalisieren und Beheben von Defekten Testen Ziel: Fehlerwirkungen gezielt und systematisch aufdecken. Ausführung eines Testobjekts zur Überprüfung i. A. stichprobenartig Festgelegte Randbedingungen Vergleich zwischen Soll- und Ist-Verhalten
5 Eine kleine Funktion public void funktion(double a, double b, double c, double d, double e, double f, double g){ for(int i=0;!fertig && i<20; i++){ if(a>b){ //... Anweisungen } else { if (c<d){ if(d==e){ //... Anweisungen } else { //... Anweisungen } } else { if(g>f){ //... Anweisungen } else { //... Anweisungen } } } } }
6 Testplanung Ressourcen bereitstellen Mitarbeiter, Schulungen Testwerkzeuge Testrahmen (engl. test bed): Benötigte Software, in der die zu testende Software zur Ausführung gebracht wird Teststrategie festlegen Prioritäten festlegen (aufgrund Risiken) Testmethoden festlegen Geforderter Überdeckungsgrad Endekriterien
7 Gliederung für ein Testkonzept nach IEEE Testkonzeptbezeichnung (engl. test plan) 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testumgebung 12. Verantwortlichkeiten/Zuständigkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan/Arbeitsplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung/Freigabe
8 Testspezifikation Spezifikation Testfälle Logische Testfälle Konkrete Testfälle: mit tatsächlichen Eingabewerten Für jeden Testfall: Ausgangssituation (Vorbedingungen) Zu erwartende Ergebnisse / Verhalten Zwei Arten von Testfällen Prüfung der gewünschten Ergebnisse und Reaktionen Inkl. Behandlung von Ausnahmen und Fehlersituationen Prüfung der Reaktion auf ungültige und unerwartete Eingaben und Randbedingungen, für die keine Ausnahmebehandlungen spezifiziert wurden
9 Testdurchführung Prüfung auf Vollständigkeit Installation des Testobjekts in Testumgebung Überprüfung auf Start- und Ablauffähigkeit Prüfung der Hauptfunktionen Falls bereits zu Beginn grundlegende Probleme auftreten, ist ein detaillierteres Testen zunächst nicht sinnvoll, da erst diese Fehler behoben werden müssen. Weitere Prüfungen
10 Testprotokollierung Exakte und vollständige Protokollierung der Testdurchführung Nachvollziehbarkeit Auch für nicht direkt beteiligte, z. B. Kunden und Entwickler Der Test muss später mit den gleichen Rahmenbedingungen und Eingabedaten wiederholbar sein Nachweis Verwaltung der relevanten Informationen (Konfigurationsmanagement) Testrahmen Eingabedateien Testprotokoll usw.
11 Testauswertung Überprüfung der Testergebnisse Prüfen, ob Abweichung tatsächlich eine Fehlerwirkung darstellt (und nicht z. B. durch fehlerhaften Testfall ausgelöst) Entscheidung über Fehlerbehebung Priorisierung anhand Fehlerklasse Erneutes Testen Überprüfen: Fehler behoben? Kein neuer Fehler entstanden? I. d. R. wird eine neue Version getestet, bei der mehrere Fehler behoben sind Entscheidung über Test-Ende Anhand Ende-Kriterien Z. B. 100% aller Anweisungen müssen mindestens einmal ausgeführt worden sein. Fehlerfindungsrate
12 Fehlerfindungsrate Quelle: Spillner/Linz: Basiswissen Softwaretest
13 Priorisierung der Tests Man kann nicht alles testen Kriterien für die Priorisierung: Eintrittswahrscheinlichkeit von Fehlern im Betrieb stark genutzte Funktionen werden stärker getestet Mit dem Fehler verbundenes Risiko Wahrnehmung durch Endanwender Was stört ihn besonders? Priorisierung der Anforderungen und Qualitätsmerkmale durch den Kunden Priorisierung aus Entwicklungssicht Von welchen Komponenten sind andere besonders abhängig? Komplexe Komponenten sind fehleranfällig Fehlerwirkungen mit hohem Projektrisiko (hoher Behebungsaufwand)
14 Teststufen im Softwareprojekt Komponententest Integrationstest Systemtest Abnahmetest
15 Komponententest Testen der kleinsten Software-Einheiten, z. B. Klassen Direkt im Anschluss an die Erstellung Isoliertes Testen der Komponente Hierdurch wird sichergestellt, dass gefundene Fehler tatsächlich in dieser Komponente liegen Testtreiber Ein Programm, das das Testobjekt aufruft, mit Eingabeparametern versorgt und das Ergebnis entgegennimmt Einsatz von Testwerkzeugen reduziert den Aufwand zur Programmierung der Testtreiber Auch Testen unzulässiger Eingaben (Negativtests) Sinnvolle Reaktionen und Ausnahebehandlungen
16 Integrationstest Integration von Komponenten zu Teilsystemen Komponenten sollten bereits getestet sein Testen des Zusammenspiels aller Komponenten Fehler in Schnittstellen und im Zusammenspiel der Komponenten finden Schrittweises Zusammenfügen der Komponenten, wobei nach jedem Schritt Integrationstests durchgeführt werden. Ggf. Integration mit existierenden Drittsystemen (z. B. Standardsoftware) Ggf. weitere Diagnoseinstrumente, z. B. Monitore zur Überwachung und Protokollierung der ausgetauschten Daten Typen von Fehlern Eine Komponente übermittelt keine oder syntaktisch falsche Daten Übergebene Daten werden durch die Komponenten unterschiedlich interpretiert Zu späte Übergabe oder zu kurze Zeitintervalle (Timing, Lastprobleme)
17 Integrationsstrategien Top-down-Integration Test beginnt mit der "obersten" Komponente, die selbst nicht von anderen Komponenten aufgerufen wird. Untergeordnete Komponenten werden zunächst durch Platzhalter ersetzt und später nach und nach gegen die richtigen Komponenten ausgetauscht Wenige verschiedene Testtreiber, aber Platzhalter programmieren Bottom-up-Integration Beginn mit elementaren Komponenten, nach und nach Zusammensetzen zu größeren Komponenten Keine Platzhalter, aber viele Testtreiber Ad-hoc-Integration Integration in der (zufälligen) Reihenfolge der Fertigstellung Zeitgewinn, aber sowohl Platzhalter als auch Treiber benötigt Big bang-integration Vermeiden, da großer Testaufwand am Ende, Fehler treten geballt auf und sind schwer zu lokalisieren.
18 Systemtest Test des vollständig integrierten Gesamtsystems Insbesondere aus Kunden- und Anwenderperspektive Testumgebung endspricht möglichst der späteren Produktivumgebung Möglichst nicht direkt in der Produktivumgebung Fehler wirken sich auf Produktivsysteme des Kunden aus Keine Kontrolle über Parameter und Konfiguration Statt Testtreibern und Platzhaltern: tatsächliche Systeme und Komponenten Testen funktionaler Anforderungen Feldtest Auf Basis der dokumentierten Anforderungen, z. B. Use Cases Abwicklung kompletter Geschäftsprozesse Überprüfung sämtlicher unterschiedlicher Produktivumgebungen oft nicht möglich Beta-Tests durch Kunden
19 Systemtest: Nicht-funktionale Anforderungen Lasttest Performanztest Volumen-/Massentest Stresstest Was passiert bei Überlastung? Test der Sicherheit Z. B. gegen unberechtigten Systemzugang Test der Stabilität/Zuverlässigkeit Im Dauerbetrieb Test auf Robustheit Gegenüber Fehlbedienung, Hardwareausfall, Wiederanlauf, Test auf Kompabilität/Datenkonversion Test unterschiedlicher Konfigurationen Z. B. Sprachen, Betriebssysteme Test auf Benutzungfreundlichkeit Prüfung der Dokumentation Prüfung auf Änderbarkeit/Wartbarkeit
20 Abnahmetest Test auf vertragliche Akzeptanz Grundlage: Abnahmekriterien des Vertrags
21 Regressionstest Nach Fehlerbehebung, Wartung, Weiterentwicklung muss die Software erneut getestet werden Nachweis, dass keine neuen Fehler eingebaut wurden Notwendiger Umfang? Fehlernachtest: Wiederholung aller Tests, die die Fehlerwirkung erzeugt hatten. Test geänderter Funktionalität Test neuer Funktionalität Das komplette System (vollständiger Regressionstest) Eigentlich wäre ein vollständiger Regressionstest erforderlich In der Praxis wägt man ab, welche Tests sinnvoll wiederholt werden können und sollen Automatisierte Tests lassen sich leichter wiederholen
22 Statischer Test Reviews Statische Analyse Compiler, Analysatoren Syntaxverletzungen, Inkonsistenzen, Abweichungen v. Standard, Einhaltung von Konventionen und Standards Datenflussanomalien Untersuchung der Daten auf Pfaden durch Programmcode Z. B. Eine Variable erhält zweimal einen Wert zugewiesen, ohne dass dieser inzwischen gelesen wird. Kontrollflussanomalien Z. B. Nicht erreichbare Anweisungen Metriken Z. B. Zyklomatische Zahl zur Bestimmung der Komplexität von Kontrollflussgraphen, sollte kleiner als 10 sein v(g) = e n + 2p wobei e: Zahl der Kanten, n: Zahl der Knoten, p: Zahl der verbundenen Komponenten (einzelne Kontrollflussgraphen)
23 Dynamischer Test PoC: Point of Control, PoO: Point of Observation Quelle: Spillner/Linz: Basiswissen Softwaretest
24 Dynamische Testverfahren Black-box-Verfahren Programmtext und innerer Aufbau des Testobjekts nicht berücksichtigt Nur äußeres Verhalten des Testobjekts untersucht Insbesondere Systemtests i.d.r. nur als Black-box-Test durchgeführt White-box-Verfahren Verwendung des Programmtexts Analyse des inneren Ablaufs (Point of Observation im Testobjekt) Evtl. Eingriffe in das Testobjekt Erstellung von Testfällen aufgrund innerer Programmstruktur (strukturelle Testverfahren) Eignet sich insbesondere für Komponententests
25 Black-box-Verfahren: Äquivalenzklassenbildung Äquivalenzklasse Die Menge aller möglichen Eingabewerte wird in Äquivalenzklassen unterteilt Für Eingabewerte, die sich in einer Äquivalenzklasse befinden, müsste sich das Testobjekt gleich verhalten Es müssen daher nur einige Repräsentanten aus jeder Äquivalenzklasse getestet werden Auch Äquivalenzklassen für ungültige Eingaben Interessant: Prüfung der Grenzen von Äquivalenzklassen Weitere Black-box-Verfahren Zustandsbezogene Tests Berücksichtigung der Historie Z. B. Erreichen aller möglichen Zustände durch Testfälle Zufallstest Ursache-Wirkungs-Graph-Analyse Smoke-Test Versuch, das System zum Absturz zu bringen
26 Beispiel für Äquivalenzklassenbildung Programm zur Berechnung von Weihnachtsgratifikationen Firmenzugehörigkeit (Jahre) Gratifikation x <= 3 0% 3 < x <= 5 50% 5 < x <= 8 75% x > 8 100%
27 White-box-Verfahren Berücksichtigung des Programmtexts Alle Codeteile sollen mindestens einmal zur Ausführung gebracht werden Verfahren zum Testfallentwurf: Anweisungsüberdeckung Zweigüberdeckung Test der Bedingungen Einfache Bedingungsüberdeckung Mehrfachbedingungsüberdeckung Minimale Mehrfachbedingungsüberdeckung Pfadüberdeckung
28 Anweisungsüberdeckung Durch die spezifizierten Testfälle sind x% aller Anweisungen des Programms zur Ausführung zu bringen Am besten 100% Gelegentlich gibt es Anweisungen zur Ausnahmebehandlung, die nur schwer erreichbar sind. Anweisungsüberdeckung = Zahl durchlaufener Anweisungen / Gesamtzahl Anweisungen Bewertung Nicht erreichbarer Code wird gefunden Leere "else"-teile werden nicht erkannt Wenn nur im if-teil Anweisungen vorkommen, im else-teil Anweisungen fehlen, werden diese nicht gefunden, da der else-teil mangels enthaltener Anweisung gar nicht durchlaufen wird
29 Zweigüberdeckung Es sollen möglichst alle Zweige im Kontrollflussgraphen erreicht werden Bei Verzweigungen (if, case) soll jeder ausgehende Zweig mindestens einmal durchlaufen werden. Bei einer Schleife soll ein Pfad ohne Rücksprung sowie ein Rücksprung zum Anfang durchlaufen werden Zweigüberdeckung = Anzahl durchlaufener Zweige / Gesamtzahl Zweige Bewertung Es werden Fehler gefunden, die nur mit Anweisungsüberdeckung nicht gefunden werden Bei objektorientierten Systemen sind die Methoden meist wenig komplex, die Überdeckungen lassen sich leicht erreichen. Die Komplexität steckt in den Beziehungen zwischen Klassen, die bei den bisherigen Tests nicht berücksichtigt wird.
30 Test der Bedingungen Einfache Bedingungsüberdeckung Jede atomare Teilbedingung muss im Test sowohl den Wert wahr als auch falsch angenommen haben Bewertung Atomare Teilbedingung: Bedingung, die keine logischen Operatoren wie AND, OR, NOT enthält, höchstens Relationssymbole (>, =) Schwächer als Anweisungs- oder Zweigüberdeckung, da keine unterschiedlichen Wahrheitswerte der Gesamtbedingung verlangt sind
31 Mehrfachbedingungsüberdeckung Möglichst alle Kombinationen der Wahrheitswerte der atomaren Teilbedingungen Erfüllt auch die Kriterien der Anweisungs- und Zweigüberdeckung Aufwändig 2 n Kombinationen bei n atomaren Bedingungen Es lassen sich nicht alle Kombinationen realisieren Bedingungen sind nicht immer unabhängig
32 Minimale Mehrfachbedingungsüberdeckung Unterschied zur Mehrfachbedingungsüberdeckung: Es müssen nur die Kombinationen betrachtet werden, bei denen die Änderung des Wertes einer atomaren Bedingung den Wert der zusammengesetzten Bedingung verändern kann Weniger Aufwändig Nur bis zu 2n Kombinationen bei n atomaren Bedingungen Evtl. schwierig, die Eingabedaten so zu wählen, dass eine bestimmte Teilbedingung den gewünschten Wert annimmt
33 Pfadüberdeckung Jeder mögliche Pfad muss durchlaufen werden D. h. nicht nur jeder mögliche Zweig, sondern auch jede Kombination von Zweigen Jeder Schleifendurchlauf ergibt mindestens einen neuen Pfad In der Praxis lässt sich keine 100%-Pfadüberdeckung erreichen. Meist legt man eine bestimmte Schleifendurchlaufzahl fest (z. B. 2), die getestet werden soll.
34 Beispiel für Pfadüberdeckung Komplette Zweigüberdeckung: a, b, c, j, k, l, n a, d, e, f, i, j, m, n a, d, g, h, i, j, m, n Nicht durchlaufene Pfade: a, b, c, j, m, n a, d, e, f, i, j, k, l, n a, d, g, h, i, j, k, l, n Quelle: Spillner/Linz: Basiswissen Softwaretest
35 Testmanagement Verwaltung von Fehlern in Fehlerdatenbank Aufbau Fehlermeldung: Quelle: Spillner/Linz: Basiswissen Softwaretest
36 Fehlerklassifikation Quelle: Spillner/Linz: Basiswissen Softwaretest
37 Priorität Fehlerbehebung Quelle: Spillner/Linz: Basiswissen Softwaretest
38 Fehlerstatusmodell Quelle: Spillner/Linz: Basiswissen Softwaretest
39 Fehlerstatus Quelle: Spillner/Linz: 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
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
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
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
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
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
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
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
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
MehrSoftwaretechnik 1 Tutorium
Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Softwaretechnik 1 Tutorium 06. Juli 2009 Matthias Thoma (s_thoma@ira.uka.de) Heute Übungsblatt Nr. 4 + Übungsblatt Nr. 5 Softwarequalität
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
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
MehrTesten Prinzipien und Methoden
Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,
MehrBasiswissen Softwaretest
Basiswissen Softwaretest Vergleich der Vorlesung Software-Engineering Wartung und Qualitätssicherung (Stand WS13/14) mit der 4. überarbeiteten und aktualisierten Auflage von Spillner&Linz: Basiswissen
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
MehrTestmanagement in IT-Projekten
Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:
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
MehrProbeklausur Softwareengineering SS 15
Probeklausur Softwareengineering SS 15 Hinweis: Die Bearbeitungsdauer entspricht dem Punktewert. Aufgabe 1 (10 min) Beschreiben Sie das Vorgehensmodell Test-Driven-Development (TDD) a) Erläutern Sie das
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
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
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
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
MehrErster Bug: eine Motte
SOFTWAREFEHLER Der erste Bug Erster Bug: eine Motte Der Begriff Bug (deutsch: Motte) stammt aus dem Jahre 1945, als Ingenieure in einem Schaltrelais eines Computers (Harvard Mark II-System) eine Motte
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
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
MehrDie Softwareentwicklungsphasen!
Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.
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
MehrTestkonzept. Tipp-Star
Tipp-Star Version: V1.0-27.09.2015 Ablageort: Tipp-Star/01_Projektmanagement/03_Test Status: Fertig gestellt (In Bearbeitung / fertig gestellt / geprüft / freigegeben) Anzahl Seiten: 9 Autoren: tse Sergeyeva
Mehr6. Programmentwicklung
6. Programmentwicklung Fertigungsprozess Qualitativ hochwertige Software ist ein Industrieprodukt -> Methoden der Industrie übertragen auf der Herstellprozess -> Herstellprozess gliedert sich in Phasen
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
MehrValidierung 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
MehrWas versteht man unter Softwaredokumentation?
Was versteht man unter? Mit bezeichnet man die Dokumentation von Computer-Software. Sie erklärt für Anwender, Benutzer und Entwickler in unterschiedlichen Rollen, wie die Software funktioniert, was sie
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
MehrABB i-bus KNX. Software-Information. Melde- und Bedientableau. Typ: MT 701.2
Produkt: Melde- und Bedientableau Typ: MT 701.2 Aktuelles Anwendungsprogramm Plug-In für ETS 2 MT_701_2_ETS2_SOW_xx_V1-12a_de_en.exe Plug-In für ETS 3 MT_701_2_ETS3_SOW_xx_V1-12a_de_en.exe EIBTAB: MT_701_2_EIBTAB_SOW_de_V2-08-00A_EibTab+Firmware.EXE
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
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
MehrSoftware- Qualitätsmanagement
Software- Qualitätsmanagement Thomas Kugel Brandenburg, den 10.12.2002 Agenda Einleitung Was heißt Softwarequalitätssicherung und Test Die Rolle von Test und QS in Softwareprojekten Wie wird getestet Statische
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
MehrSoftware Engineering. 3. Analyse und Anforderungsmanagement
Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz
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$
MehrVBA-Programmierung: Zusammenfassung
VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung
Mehrextreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?
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
MehrTest-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim
Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,
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
MehrZusammenfassung der Testarten
oftware-test Zusammenfassung der Testarten Komponententest Integrationstest Systemtest Grenztest Black Box Test zustands basierter Test White Box Test Pfadtest Strategie: Urknall Top Down Bottom Up Sandwich
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
MehrTypisierung des Replikationsplan Wirries, Denis Datenbankspezialist
Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan
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
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,
MehrBinäre Bäume. 1. Allgemeines. 2. Funktionsweise. 2.1 Eintragen
Binäre Bäume 1. Allgemeines Binäre Bäume werden grundsätzlich verwendet, um Zahlen der Größe nach, oder Wörter dem Alphabet nach zu sortieren. Dem einfacheren Verständnis zu Liebe werde ich mich hier besonders
MehrISTQB Certified Tester Foundation Level Exam Übungsprüfung
BEMERKUG: Bitte nur eine Antwort auf jede Frage 1. Die statische Analyse kann höchstwahrscheinlich ICHT finden: (A) Die Verwendung einer Variablen bevor diese definiert wurde. (B) Unerreichbaren ( toten
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
MehrQualitätssicherungskonzept
Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth
MehrT3 Testen im Software- Lebenszyklus
T3 Testen im Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test AK- 2 1 AK- Definition Test der einzelnen implementierten Komponenten
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.
MehrErweiterung der Aufgabe. Die Notenberechnung soll nicht nur für einen Schüler, sondern für bis zu 35 Schüler gehen:
VBA Programmierung mit Excel Schleifen 1/6 Erweiterung der Aufgabe Die Notenberechnung soll nicht nur für einen Schüler, sondern für bis zu 35 Schüler gehen: Es müssen also 11 (B L) x 35 = 385 Zellen berücksichtigt
MehrBFE Studio und Medien Systeme GmbH. www.bfe.tv
1 eine in Broadcast-IT-Projekten oft vernachlässigte Aufgabe 23. Fachtagung der FKTG (2008) 2 Problemstellung (I) Moderne Broadcast-Lösungen bestehen zunehmend aus Software. BFE eine Firma, die in Großprojekten
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
MehrSoftwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal
Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann
MehrVgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.
Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,
MehrSoftware Engineering. Dokumentation! Kapitel 21
Martin Glinz Thomas Fritz Software Engineering Kapitel 21 Dokumentation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch gestattet;
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?
MehrFunktion Erläuterung Beispiel
WESTFÄLISCHE WILHELMS-UNIVERSITÄT WIRTSCHAFTSWISSENSCHAFTLICHE FAKULTÄT BETRIEBLICHE DATENVERARBEITUNG Folgende Befehle werden typischerweise im Excel-Testat benötigt. Die Beispiele in diesem Dokument
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
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
MehrAbschnitt 16: Objektorientiertes Design
Abschnitt 16: Objektorientiertes Design 16. Objektorientiertes Design 16 Objektorientiertes Design Informatik 2 (SS 07) 610 Software-Entwicklung Zur Software-Entwicklung existiert eine Vielfalt von Vorgehensweisen
MehrInternet Explorer Version 6
Internet Explorer Version 6 Java Runtime Ist Java Runtime nicht installiert, öffnet sich ein PopUp-Fenster, welches auf das benötigte Plugin aufmerksam macht. Nach Klicken auf die OK-Taste im PopUp-Fenster
MehrMaintenance & Re-Zertifizierung
Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0
MehrÜbungen 19.01.2012 Programmieren 1 Felix Rohrer. Übungen
Übungen if / else / else if... 2... 2 Aufgabe 2:... 2 Aufgabe 3:... 2 Aufgabe 4:... 2 Aufgabe 5:... 2 Aufgabe 6:... 2 Aufgabe 7:... 3 Aufgabe 8:... 3 Aufgabe 9:... 3 Aufgabe 10:... 3 switch... 4... 4 Aufgabe
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
MehrKlausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement
Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. K.-P. Fähnrich, Prof. H.-G. Gräbe, T. Riechert Institut für Informatik Sommersemester 2012 Allgemeine Bemerkungen
MehrAngepasste Software Standards für DLR- Eigenentwicklungen - Die DLR Software Basisstandards -
Angepasste Software Standards für DLR- Eigenentwicklungen - Die DLR Software Basisstandards - Anita Herrmann Braunschweig, 10. Nov 2004 Ausgangspunkte Im DLR werden nach vorsichtigen
MehrQM: Prüfen -1- KN16.08.2010
QM: Prüfen -1- KN16.08.2010 2.4 Prüfen 2.4.1 Begriffe, Definitionen Ein wesentlicher Bestandteil der Qualitätssicherung ist das Prüfen. Sie wird aber nicht wie früher nach der Fertigung durch einen Prüfer,
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
MehrSoftware Engineering. 11. Einführung und Wartung
Software Engineering 11. Einführung und Wartung Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Testen
MehrSoftwareentwicklungsprozess im Praktikum. 23. April 2015
Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit
MehrAbacus Formula Compiler (AFC)
Abacus Formula Compiler (AFC) Alle kennen Excel - jetzt sogar Ihre Java- Applikation! Bringt Tabellenkalkulationen auf die JVM http://formulacompiler.org/ Peter Arrenbrecht für Abacus Research AG http://abacus.ch/
MehrAblaufbeschreibung für das neu Aufsetzen von Firebird und Interbase Datenbanken mit der IBOConsole
Lavid-F.I.S. Ablaufbeschreibung für das neu Aufsetzen von Firebird und Interbase Datenbanken mit der Lavid Software GmbH Dauner Straße 12, D-41236 Mönchengladbach http://www.lavid-software.net Support:
MehrSoftware Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Dirk Wischermann Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg 18. Dezember 2006 Inhalt Nachlese
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
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
MehrProjektmanagement. Vorlesung von Thomas Patzelt 10. Vorlesung
Projektmanagement Vorlesung von Thomas Patzelt 10. Vorlesung 1 Test...(4) Oberflächentests testen die Benutzerschnittstelle des Systems, nicht nur auf Fehlerfreiheit sondern z.b. auch auf Konformität mit
Mehr6 Systematisches Testen von Programmen
6 Systematisches Testen von Programmen Testen Untersuchung des Source-Codes nach Fehlern und Anomalien Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 6 p.1/24 Untersuchung des Source-Codes
MehrJava Kurs für Anfänger Einheit 5 Methoden
Java Kurs für Anfänger Einheit 5 Methoden Ludwig-Maximilians-Universität München (Institut für Informatik: Programmierung und Softwaretechnik von Prof.Wirsing) 22. Juni 2009 Inhaltsverzeichnis Methoden
MehrErfahrungen mit Hartz IV- Empfängern
Erfahrungen mit Hartz IV- Empfängern Ausgewählte Ergebnisse einer Befragung von Unternehmen aus den Branchen Gastronomie, Pflege und Handwerk Pressegespräch der Bundesagentur für Arbeit am 12. November
MehrBELIEBIG GROßE TAPETEN
MODERNERES DESIGN 2 HTML-AUSGABEN 3 GESCHWINDIGKEIT 3 BELIEBIG GROßE TAPETEN 3 MULTIGRAMME 3 AUSGABEPFADE 3 INTEGRIERTER FORMELEDITOR 4 FEHLERBEREINIGUNGEN 5 ARBEITSVERZEICHNISSE 5 POWERPOINT 5 HINWEIS
Mehritestra Software Tuning Mehr Leistung. Weniger Kosten. Software Productivity
itestra Software Productivity Software Tuning Mehr Leistung. Weniger Kosten. Fit für die Zukunft Performance-Defizite in Software-Systemen verursachen jedes Jahr Mehrausgaben für Betrieb und Nutzung in
MehrQuality Point München. Testtools
Quality Point München Testtools 1 1 Testtools - ein Blick in die Landschaft reine Testtools unterstützen direkt Testaufgaben bzw. versprechen, diese zu automatisieren (statische Analyse, GUI-Funktionstest,
MehrAnti-Botnet-Beratungszentrum. Windows XP in fünf Schritten absichern
Windows XP in fünf Schritten absichern Inhalt: 1. Firewall Aktivierung 2. Anwendung eines Anti-Virus Scanner 3. Aktivierung der automatischen Updates 4. Erstellen eines Backup 5. Setzen von sicheren Passwörtern
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
MehrBSV Ludwigsburg Erstellung einer neuen Internetseite
BSV Ludwigsburg Erstellung einer neuen Internetseite Änderungshistorie Version Datum Bearbeiter Änderung 0.1 02.06.2012 A. Lorenz Neuanlage Seite 1/9 1 Inhaltsverzeichnis: 1 Inhaltsverzeichnis:... 2 2
MehrEinkaufsführer Hausverwaltung Was Sie bei Suche und Auswahl Ihres passenden Verwalters beachten sollten
Sie suchen einen Verwalter für Ihre Immobilie: Egal ob Eigentümergemeinschaft einzelne Eigentumswohnung Miet- oder Gewerbeobjekt oder vielleicht nur eine einzelne Dienstleistung Was Sie dabei wissen und
MehrDatenübernahme easyjob 3.0 zu easyjob 4.0
Datenübernahme easyjob 3.0 zu easyjob 4.0 Einführung...3 Systemanforderung easyjob 4.0...3 Vorgehensweise zur Umstellung zu easyjob 4.0...4 Installation easyjob 4.0 auf dem Server und Arbeitsstationen...4
MehrRegistrierungsanleitung ecom-system DARC e.v. OV Velbert
Willkommen zur Registrierung im ecom-system des OV Velbert! Dies ist eine kurze Einführung in die grundlegende Registrierung und Nutzung des ecom-systems des OV Velbert. Zu Beginn sollte man die Webseite
MehrSystemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung
2007 Dr. Klaudia Dussa-Zieger P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung
MehrFassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing
Fassade Objektbasiertes Strukturmuster C. Restorff & M. Rohlfing Übersicht Motivation Anwendbarkeit Struktur Teilnehmer Interaktion Konsequenz Implementierung Beispiel Bekannte Verwendung Verwandte Muster
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
MehrSystemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung
P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung Testberichterstattung Lehrplan
Mehr