Hallo,
ich habe hier mal eine allgemeine Frage stellen:
Wie testet Ihr Eure Software?
Eine einzelne Software zu testen ist ja ned so schwer. Aber wie testen man Software, wenn man mehrere erstellt?? Gibt es sowas wie ein allgemeines Testprotokoll??
Wie machen das große Firmen??
Axl
Auch hallo.
Hallo,
ich habe hier mal eine allgemeine Frage stellen:
Wie testet Ihr Eure Software?
Stichworte: Softwaremetriken, Kennzahlen, JUnit (Java), NUnit (.NET), Refactoring,…
Eine einzelne Software zu testen ist ja ned so schwer. Aber
wie testen man Software, wenn man mehrere erstellt?? Gibt es
sowas wie ein allgemeines Testprotokoll??
Also es kommt auf die Sprache(n) sowie das Ziel des Programms an. Programme mit z.B. (langsamen) Datenbankzugriff sollten diese Aktion besser in einem eigenen Thread ausführen 
Wenn man nicht gerade ein Programm verwendet, dass einem diese Arbeit auf Knopfdruck abnimmt.
:Wie machen das große Firmen??
Genauso. Allerdings ist das Testen von Software noch nicht überall gleichermassen beliebt…
HTH
mfg M.L.
Hi,
wie Markus schon geschrieben hat: Ein Teil der Tests ist abhängig von der Programmiersprache. JUnit oder andere Testframeworks dienen auf der untersten Ebene zum Testen, ob Beispielsweise Methoden einer Klasse das tun, was erwartet wird.
Desweiteren schreibt man sich eigene Testtreiber, die Teilbereiche der zu entwickelnden Software simulieren, um die selbst entwickelten Teile im Zusammenspiel mit den Schnittstellen anderer zu testen (solange da noch nichts geliefert wurde).
Zentrale Codebereiche werden in einem Review mit anderen Entwicklern besprochen, wobei der Ersteller begründet warum er seinen Code so gestaltet hat.
Wenn irgendwann mal alles in einer ersten Form da ist und zusammengestöpselt werden kann, dann testet der Entwickler seine Sachen im Live System.
Nebenbei werden Testfälle geschrieben, die alle Anwendungsfälle abdecken sollen. Richtig, das ist äusserst Umfangreich Vor allem, weil diese Testfälle dann von Personen, die mit der Entwicklung nichts zu tun haben, abgearbeitet werden.
Diese Leute notieren alle Fehler, und zwar mit genauen Angaben wann, wo und bei welcher Aktion der Fehler aufgetreten ist.
Die Entwickler suchen die Fehler und bauen sie aus. Wenn diese Testphase mehrfach durchgelaufen ist, dann wird das Programm auf den Markt losgelassen.
In der Realität werden die Testphasen aus (markt)politischen Gründen äusserst knapp gehalten (wenn sie überhaupt stattfinden). Unittests finden in der Praxis nur statt, wenn der Projektleiter Wert darauf legt oder der Entwickler selber so schlau ist, sich die Zeit zu nehmen (wenn er kann). Der Zeitdruck in der professionellen Softwareentwicklung ist enorm, Time to Market ist scheinbar alles, und solange der Kunde die nachträgliche Patcherei mitmacht ist alles in Ordnung…
Den Vorlauf der Entwicklung, nämlich die Spezifikation und die Designphase mit ihren einzelnen Reviews und Korrekturphasen hab ich mal weggelassen.
Grüsse,
Herb
Hallo,
darauf gibt es so viele Antworten, dass man darüber Bücher schreiben kann, eine der wichtigsten: nimm Idioten.
Wenn du die Software von jemand bedienen lässt, der keine Ahnung hat oder zumindest nicht deine Fachkenntnisse, tauchen meistens ganz unerwartete Fehler auf. Merke: die Software darf sich niemals aufhängen, auch nicht bei der absurdesten Eingabe. Von einem anderen Standpunkt aus ist sie oft garnicht absurd, aber selbst ein hackender Affe darf die Maschine nicht blockieren oder zum Absturz bringen.
Branchenspruch: Software kann nie sicher sein, dafür sind die Idioten viel zu einfallsreich.
Eine mögliche Organisationsform ist ein Usability-Labor.
Das ist nur ein Aspekt unter vielen, es muss natürlich u.a. auch geprüft werden, ob die Software ihren Zweck immer und überall erfüllt.
Gruss Reinhard
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo,
wie Herb geschrieben hat, ist das ganze, falls es denn wirklich so durchgefuehrt wird enorm aufwendig und die Anbieter von Bananen-Software werden immer mehr ( Bananen-Software = Software reift beim Kunden). Denn die Kunden sind das billigst Testszenario das es gibt.
Zufuegen moecht ich noch, das waehrend der Tests die Fehler kategorisiert werden, d.h. in Klassen der Dringlichkeit eingeteilt werden; von kostmetischen Fehler bis ReleaseStopper. Und dann wird auch u.U. hingenommen, das ein Produkt mit bekannten Fehlern ausgeliefert wird. Je nach Terminlage wird entschieden ob der Bug gefixt wird oder nicht. Die Entscheidung kann dann so aussehen, das ein Programm einen Fehler produziert, falls jemand eine bestimmte Hardwarekonstellation besitzt, sind dies aber nur ca. 5% der potenziellen Kunden, dann wird das Produkt ausgeliefert.
Ich habe schon bei Entwicklungen von namhaften Herstellern mitgewirkt, das sind schon Programme ausgeliefert worden mit mehr als 300 „known Bugs“
Tschau
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]