Editing
Informatiker FA M227 Zusammenfassung
(section)
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Dynamische Prüfverfahren == *Tests im eigentliche Sinne *Lauffähige Systeme werden gegenüber den Erwartungen validiert. *Je nach Phase werden steten andere Testarten zur Verfügung [[Image:V-Modell.gif]] === Testarten, die statische Prüfverfahren unterstützen === *jede Testart lässt sich einer Teststufe zuordnen *Die Planung des durchzuführenden Testarten wird deshalb '''Teststufenplan''' genannt. *'''Testaktivitäten''' unterstützen die statischen Prüfverfahren *In der Analyse- und Entwurfsphase werden '''Prototypen''' entwickelt. *Der '''Prototyptest''' erfolgt in einem '''Review'''. *Wird SW nicht selber entwickelt, wird dies über einen Evaluationsprozess. Während der Auswahl erfolgt ein '''Proof-of-Concept'''. Dabei führt der Lieferant eine Testinstallation beim Kunden durch. === Unit-Tests === *Während der Implementation testen Entwickler fortlaufend. Diese Tests sind Bestandteil des SW-Entwicklungsprozesses. *Der Unit-Test ist jedoch Bestandteil, des Testprozesses *Hier werden Bestandteile als separate "Units" getestet (Funktionalität, Schnittstellen) *Mit Negativtests (Eingaben welche fehler verursachen müssen) wird Robustheit getestet. *Zeitverhalten wird geprüft. *Überprüfung der Wartbarkeit mittels Review oder Inspektion. *Unit-Tests können mit der White- oder Blackboxmethode durchgeführt werden. *Testtreiber und Analysatoren unterstützen den Tester bei der Automatisierung und der Auswertung. Bezeichnungen für Unit-Test (je nach Prüfobjekt) *Modultest *Programmtest *Klassentest *Komponententest *Datenbanktest === Integrationstest === *Das Zusammenspiel der einzelnen Komponenten und die Schnittstellen zu dem Umsystemen wird geprüft. *Die einzelnen Schichten (n-tier) werden geprüft. *Danach dir Schnittstellen zu den anderen Schichten. *Hardwarekompatiblität und Betriebssystemkompatibilität wird geprüft. *Auch das Netzwerk ergibt eine breite Palette an Testfällen Mit dem Integrationstest soll nicht gewartet werden bis alle Unit-tests abgeschlossen sind. === Systemtest === *Nach dem Integrationstest folgt der Systemtest. *Hier wird das ganze System getestet. *Ziel ist es, die geforderte Systemqualität nachzuweisen [[Image:Systemtest.gif] Neben den eigentlichen Testspezialisten können auch andere Fachbereiche vertreten sein (Netzwerkspezialist, Systemspezialist, Andwende etc.) '''Funktionstest''' *sämtliche Anwendungsfälle (Use Cases) werden getestet. *Vollständigkeit und Richtigkeit steht im Vordergrund '''Benutzerbarkeitstest''' *GUI-regeln werden geprüft *sachlich logische und intuitive Benutzerführung *einfache Erlernbarkeit *Dokumentation *kontextsensitive Hilfe '''Installationstest''' *verschiedene Betriebssystemvarianten *Sprachen *Installation muss automatisch ablaufen *saubere Deinstallation *Upgradeinstallationen '''Zertifizierungstest / Kompatiblitätstest''' Die Kompatiblität muss auf drei Ebenen sichergestellt werden *Hardware und Netzwerk *Betriebssoftware *Andere veknüpfte Anwendungssoftware Folgede Zertifizierungen sind denkbar: *Hardware-Anbieter *OS Anbieter *Amtliche Stellen (z.B. SUVA) '''Perfomancetest''' *Beim '''Lasttest''' wird die Effizienz und Zuverlässigkeit geprüft. Systemlast wird simuliert. Antwortzeiten interessieren. *Beim '''Stresstest''' wird die Systemlast bis zum Zusammenbruch erhöht. System muss wie erwartet reagieren (z.B. Meldungen auslösen und regulierende Massnahmen auslösen). Darf nicht kommentarlos zusammenbrechen. '''Benchmark-Test''' *genormte Messverfahren *Kriterien werden miteinander verglichen '''Katastrophentest''' *Extremsituationen werden simuliert (Stromausfall, Disk-Crash, netzwerkausfall) *Im Idealfall soll System automatisch wieder im letzten konsistenten Zustand anlaufen. *Auch organisatorische und bauliche Massnahmen werden mit einbezogen (z.B. Feuerschutz) '''Sicherheitstest''' *Datensicherheit (keine Daten dürfen verloren gehen) *Datenschutz *Penterationtests *Ethical Hacking (von innen, von aussen, angekündet, nicht angekündet, physischer Zugang, remote Zugang, Tarnen als Mitarbeiter) === Abnahmetest === *Beim Abnahmetest geht es um die Beurteilung aus Sicht es Kunden *Ein erfolgreicher Abnahmetest entlastet das Entwicklungsteam und bestätigt, dass alle Anforderungen vollumfänglich erfüllt sind. Varianten Abnahmetest: *Test der vertraglichen vereinbarten Akzeptanz *Test der Benutzerakzeptanz *Test der Akzeptanz durch den Systembetreiber *Verknüpfung des Abnahmetests mit einem Livetest. Probleme bereiten iommer wieder nicht explizit erwähnte Anforderungen die sich aus Industriestandards oder Usanzen ergeben. Empfehlung: Solche Anforderungen immer explizit in den Vertrag nehmen. === Live-Test === *findet in der produktiven Umgebung statt *erhöht die Sicherheit, dass die Anforderungen im produktiven Umfeld erfüllt werden. *Live-test ist oft Abnahmetest. *begrenzter Zeitrahmen [[Image:Live-Test.gif]] '''Parallebetrieb''' *altes und neues System laufen eine bestimmte Zeit lang parallel *resultate werden laufen verglichen *aufwändiges System *kann nur für kritische Projekte eingesetzt werden. '''Pilotbetrieb''' *ein Teilbereich eines Unternehmens arbeitet eine bestimmte Zeit lang auf dem neuen System. Die anderen auf dem alten *Wenn Mängel auftreten wird nicht das komplette Unternehmen beeinträchtigt. *Wenn sich das neues System bewährt, kann dieses für das ganze Unternehmen freigegeben werden. *Dieses Verfahren kann nur eingesetzt werden wenn keine Integrationsschwierigkeiten mit den bestehenden Systen der anderen OE auftreten '''Beta-Test-Phase''' *hat sich bei Standardsoftware eingebürgert welche an ein breites Publikum verkauft wird. *Benutzer melden sich meist freiwillig *Das Risiko ist beim Tester *Die Fehler werden beim SW-Hersteller gesammelt und jenachdem wird ein zweiter Beta oder Finalrelease herausgegeben. === Regressionstest === *Bei jeder Änderung des Systems besteht das Risiko von Sideeffects. *Das Configmanagement regelt den Änderungs- und releaseprozess *bevor ein neues Release freigegeben wird, mus sein Set von Tests durchgeführt werden. *Diese Testwiederholung wird Regressionstest genannt. *Diese sind i.d.R. risikoorientiert. *hoher Automatisationsgrad *Ein Subset der wichtigsten Tests wird '''Smoke-Test''' genannt und sollte vollautomatisch ablaufen.
Summary:
Please note that all contributions to HallerWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
HallerWiki:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Page
Discussion
English
Views
Read
Edit
View history
More
Search
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Tools
What links here
Related changes
Special pages
Page information