Diskussion:Softwaretest/Archiv
Deutliche Überarbeitung erforderlich
Der Artikel stellt gängige Testbegriffe vor. Allerdings fehlt ein geordneter Zusammenhang des allgemeinen Testbegriffs. Nachdem dies geschehen ist, sollten die einzelnen Begriffe weiter geschärft und mit Leben gefüllt werden. Hier ein erster Vorschlag von mir:
Der Software-Test ist eine analytische, dynamische Maßnahme zur Qualitätssicherung von Software.
Qualitätsmaßnahmen
Die gängige Einteilung Qualitätsmaßnahmen erfolgt nach
- analytischen Maßnahmen, die erst nach Erstellung des Prüfgegenstandes durchgeführt werden können, und
- konstruktiven Maßnahmen, die bereits bei der Erstellung vorliegen bzw. die Erstellung begleiten.
Die analytische Maßnahmen unterteilen sich weiter in
- dynamische Maßnahmen, die eine Ausführung der Software erfordern (Bsp. CodeCoverage, Test) und
- statische Maßnahmen, die auf eine Ausführung der Software verzichten können (Bsp. Verifikation, CodeReviews).
Definition Test
Die konkrete Abgrenzungen von Test zu anderen Qualitätsmaßnahmen fällt schwer. Aus diesem Grund gibt es mehrere - glücklicherweise ähnliche - Definitionen für Test:
Nach ANSI/IEEE Std. 610.12-1990 ist Test "the process of operating a system or component under specified conditions, observing or recording the results and making an evaluation of some aspects of the system or component."
Eine praxistaugliche Definition liefert E.Denert, Software-Engineering, Springer, 1991, wonach der "Test [..] der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen" ist.
Schwierigkeit beim Test
Da sehr einfache Programme für einen vollständigen bzw. erschöpfenden Test bereits eine immens hohe Anzahl von Testfällen benötigen, ist ein angemesser Test immer nur eine Stichprobe. Aus diesem Grund kann man durch einen Test nur die Anwesenheit nicht aber die Abwesenheit von Fehler nachweisen (E.W.Dijkstra).
Beispiel: Ein Programm soll prüfen, ob eine Benutzereingabe durch 2 teilbar ist. Ein erschöpfender Test muss alle Eingaben und die erzeugten Ausgaben prüfen. Angenommen nur gültige numerische Werte sind zugelassen bzw. werden verlässlich(!) zugesichert, so sind dennoch alle Zahlen zu prüfen. Wird weiter angenommen, daß nur natürliche Zahlen bis 65535 verlässlich als Eingabe zugesichert werden, so müssen mindestens diese Eingaben geprüft werden.
Aus diesem Grund beschäftigen sich verschiedene Teststrategien/-konzepte, wie mit einer sinnvollen Anzahl von Test Fehlerarmut nachgewiesen werden kann.
--62.134.108.1 23:50. 24. Mär 2005
Eingearbeitet! --DJ 16:20, 31. Mär. 2007 (CEST)
Klassifikation nach Informationsstand
Die Zuordnung der Programmierer zu den Black- und White-Box-Test ist meines Wissens falsch. Keine Technik schreibt explizit vor, dass der Programmierer auch gleichzeitig Tester sein muß. Das es natürlich Probleme, bzw. Vor- und Nachteile, gibt, wenn man seinen eigenes Produkt testet steht außer Frage, gehört aber nicht zu dieser Klassifikation.
"White-Box-Tests sind kurzfristig kostengünstiger, zeigen in der Praxis allerdings eine äußerst hohe Durchlässigkeit für Fehler." Das ist ebenfalls inhaltlich falsch ! Damit werden alle Strukturorientierten Tests völlig zu unrecht "diskriminiert".
"Black-Box-Tests decken besonders viele Fehler auf, .." viel zu ungenau und verallgemeinernt. "... manchmal auch als sozial unverträglich..." - das gehört in ein eigenes Kapitel über die Psychologie(?) des Testens und ist viel differenzierter zu formulieren--Taschenrechner 13:49, 27. Apr 2005 (CEST).
- Die letzten beiden oben erwähnten Punkte sind immer noch nicht berücksichtigt, obwohl die Kommentare berechtigt sind. Bitte abändern! --DJ 19:47, 31. Dez. 2006 (CET)
Eingearbeitet! --DJ 16:20, 31. Mär. 2007 (CEST)
Rechtschreibung
Die Artikelbezeichnung ist Softwaretest, im Artikel ist aber von Software-Test die Rede - gibt es da entweder eine verbindliche, richtige Schreibweise oder zumindest eine Mehrheitsmeinung, welche Schreibweise richtig ist? --WebWombat 18:24, 19. Sep 2005.
BIST und Boundary Scan Test
Ich habe den folgenden Absatz aus dem Abschnitt "Automatisierte Tests" entfernt, weil mittels der dort erwähnten Verfahren offensichtlich nur elektronische Schaltungen getestet werden. Diese Verfahren haben darum m.E. keine Relevanz beim Testen von Software und deren Verlinkung in diesem Artikel schafft nur Verwirrung (und keine Hinweise auf weitere relevante _Software_-Testverfahren)
"Heutzutage geht der Trend zu integrierten Selbsttesteinheiten (sprich automatisiertem Testen). Dabei wird oft Boundary Scan Test nach dem JTAG Standard implementiert."
Ollerich, 2006-05-11, 14:56
Abgrenzung Abnahmetest versus Akzeptanztest
Hi, sind die Begriffe Abnahmetest und Akzeptanztest synonym? Falls nicht, worin besteht der Unterschied? Kennt jemand online verfügbare Quellen zum Thema? --jpp ?! 16:09, 2. Jun 2006 (CEST) Eingearbeitet! --DJ 16:20, 31. Mär. 2007 (CEST)
Hi, also da das Auflisten von nicht-open source Werkzeugen ein Vorteil für die jeweilige Firma ist, sollte die Liste entweder verkleinert oder eine andere Maßnahme (z.B. das Werkzeug ist DER Standard,...) diesbezüglich entschieden werden. --Erkan Yilmaz 18:14, 18. Dez. 2006 (CET) Bewerte mich
Klassifikation nach der Systemstruktur - mehrere Fehler
Der Abschnitt "Klassifikation nach der Systemstruktur" enthält mehrere Fehler:
- Modul- Unit- und Komponententest ist das Gleiche.
- Das Zusammenspiel mehrerer Module wird im Integrationstest getestet nicht im Komponententest. Der Begriff ist schon belegt (s.o.). In einigen Firmen benutzt man diese Begriffe mit einer abweichenden Bedeutung. Man tut sich aber keinen Gefallen damit.
- Der Systemtest ist kein Integrationstest. Ein Systemtest kann (sinnvoller Weise) erst nach dem Integrationstest erfolgen (siehe V-Modell).
--DJ 17:56, 31. Dez. 2006 (CET) Eingearbeitet! --DJ 16:20, 31. Mär. 2007 (CEST)
Einbau redundanter Artikel
Ich habe heute aufgrund der Redundanzmeldung die Inhalte der beteiligten Artikel ins hiesige Kapitel Definition verpflanzt und die redunt. Artikel in redirects verwandelt - weil beide Interwikilinks trugen. --SonniWP2 11:40, 22. Aug. 2007 (CEST)
- Ich kann die beteiligten asiatischen Sprachversionen in keiner Weise bearbeiten. --SonniWP2 12:05, 22. Aug. 2007 (CEST)
Die Geschichte von Akzeptanztest (Softwaretechnik)
show 100 / 250 / 500 / 1000 | (no more results)
Date ↑ User Comment
- 2007-08-22 07:12 (diff) Avron (fix)
- 2007-08-22 00:03 (diff) 84.160.34.177 (anon)
- 2007-08-17 07:51 (diff) ViktorLaszlo (Synonyme ergänzt)
- 2007-02-20 08:14 (diff) Bkmzde (Auch UAT (User Acceptance Test) genannt)
- 2006-06-02 14:37 (diff) Jpp (Kategorie präzisiert)
- 2006-06-02 14:25 (diff) Jpp (ausgelagert aus Begriffsklärung Akzeptanztest, Autoren siehe [1])
Geschichte aus Systemtest
show 100 / 250 / 500 / 1000 | (no more results)
Date ↑ User Comment
- 2007-08-22 00:03 (diff) 84.160.34.177 (anon)
- 2007-07-18 21:40 (diff) 91.13.168.241 (anon) (/* Siehe auch */)
- 2007-01-04 20:16 (diff) Thomas wiese
- 2006-12-15 14:18 (diff) ManWing2 (letzte Änderung rückgängig gemacht)
- 2006-11-23 08:32 (diff) 87.161.201.118 (anon)
- 2006-11-03 12:13 (diff) 217.247.214.95 (anon) (/* Funktionaler Systemtest */)
- 2006-07-27 13:54 (diff) Abdull (Interlanguage en)
- 2006-03-17 13:11 (diff) 84.182.110.177 (anon)
- 2005-10-13 10:10 (diff) Abubiju (/* Nicht funktionaler Systemtest */ kat.)
- 2005-08-26 13:52 (diff) Sterling (Wer)
- 2004-12-24 18:19 (diff) Media lib
- 2004-12-24 18:19 (diff) Media lib
- 2004-06-12 22:54 (diff) 217.238.22.129 (anon)
- 2004-02-24 14:21 (diff) Tsor (Titel bold)
- 2004-02-24 14:12 (diff) 213.217.99.129 (anon)
- 2004-02-24 14:11 (diff) 213.217.99.129 (anon)
--SonniWP2 13:26, 22. Aug. 2007 (CEST)
Die Diskussion:Systemtest enthielt noch:
Hallo zusammen,
gem. Autor sollte der Systemtest durch die realisierende Organisationseinheit durchgeführt werden. Gegenstand des Tests sollte hier die Spezifikation sein. In der Spezifikation ist i.d.R. das Projektzeil definiert und eignet sich somit als Gegenstand für einen solchen Test, der in der Regel als Abnahmetest für ein Softwareprojekt fungiert. Die Spüezifiaktion kann auch als Vertrag zwischen der beauftragenden und der realisierenden Organisationseinheit verstanden werden. Vertragsgegenstand ist eine Software inkl sonstiger Dinge wie Dokumentation usw. Letzendlich zeichnet sich ein Softwareprojekt aber durch seinen Dienstleistungscharakter aus. Die exakte und vollständige Definition dessen, was gewollt ist, ist somit äussertst schwer. Ein Grund hierfür ist z.B. die Beschränkung der Sprache mit deren Hilfe i.d.R. eine Spezifikation durchgeführt wird. Typisch für ein Dienstleistungsprojekt ist aber auch, dass nur der Aufttraggeber entscheiden kann, ob die erbrachte Dienstleistung der gewünschten entspricht. Deshalb ist es aus meiner Sicht sinnvoller, wenn der Aufttraggeber einen solchen Systemtest druchführt. Dies bedingt natürlich, dass auf Seiten des Aufttraggebers das entsprechende Wissen vorhanden ist.
LG thomas-wiese