Geschriebene SW testen



  • Hallo!

    Ich arbeite seit ein paar Monaten als C++ Entwickler in einer Firma, welche für ihre eigene Hardwareplattform auch SW entwickelt.
    Ein Gebiet, in dem ich noch Verbesserungspotential habe, ist das Testen meiner geschriebenen Programme.
    Ich habe das Gefühl, dass ich viel zu lange an Dingen rumteste, die interne Dinge repräsentieren, also z.B. ob der an std::sort übergebene Funktor richtig funktioniert und ähnliches. Diese Dinge funktionieren eigentlich danach immer einwandfrei.
    Aber jetzt kommts: Der Kunde oder Projektleiter drückt ein paar Mal rum und findet dann etwas, was nicht so ist wie gewünscht (offensichtliche Dinge), die mir nicht aufgefallen sind. Es handelt sich dabei eher um "logische" Dinge, also z.B. habe ich falsche Werte aus einer Liste ausgelesen.

    In der Theorie (Uni) ist das Testen ja recht einfach, Testunit erstellen und vergleichen ob der Output passt.
    Leider hängt der Output der riesigen Klassen in der Firma aber von verschiedensten Inputs ab, nämlich verschiedenen Dateien, Kommunikation übers Netzwerk, usw...
    Es ist also schwierig zu sagen: bei Input x kommt Output y raus.

    Wie geht ihr beim Testen vor?
    Könnt ihr Bücher empfehlen?

    Vielen Dank!



  • sdf_fds schrieb:

    Leider hängt der Output der riesigen Klassen in der Firma aber von verschiedensten Inputs ab, nämlich verschiedenen Dateien, Kommunikation übers Netzwerk, usw...

    Das ist jetzt kein Grund zu sagen, dass Unit Tests hier keine gute Idee wären. Aber gute Unit Tests zu schreiben ist schon auch eine Kunst für sich.
    Ich versuche meist, die internen Komponenten soweit wie möglich durch Unit Tests abzudecken. Das funktioniert meist auch recht gut.
    Natürlich gibts noch genug andere Bugs, die erst in der QA auffallen, weil man nicht gleich alles berücksichtigen kann und ein DAU einfach anders rumklickt und auf Ideen kommt, auf die man selber als Entwickler nicht unbedingt kommen würde.



  • Dann brauchst du einen weiteren Tester, der weder mit dir noch mit dem Kunden identisch ist. Wenn dein Projektleiter Lust auf den Job hat, warum nicht 😉 aber normalerweise hat man dafür seine Leute.





  • Testen komplexer SW-Systeme ist und bleibt eine schwierige und aufwendige Angelegenheit. Zu den Unit-Tests kommen noch andere Dinge hinzu wie die gesicherte Verfügbarkeit von Ressourcen (Netzwerke, Datenbanken, Internet, ...) und die unplanbare Arbeitsweise der Anwender. Die Menge möglicher Fehler ist groß. Je nach Aufgabe kann eine SW mit 90% Fehlerfreiheit schon als gut gelten. Bei anderen Aufgaben wären 98% dagegen schlecht.

    Die Frage führt schnell zu einem Spezialgebiet der IT-Branche, dem Systemtest. Hierzu findest du hier im Forum unter [Bücher] eine Rezension zum Buch ´Der Systemtest´. Nicht leicht zu lesen, aber die Problematik wird klar! Der Aufwand solcher Tests kann schnell den Entwicklungsaufwand übersteigen und jeden Kostenrahmen rapide erhöhen oder sprengen. Auch gilt, ein fremder Tester ist besser als der Entwickler.

    Wahrscheinlich bist du damit bei deiner Firma überfordert. Das lernt man nicht an der Uni, sondern nur in der Praxis.



  • Warum schreibt ihr nicht gleich fehlerfreie Software?



  • HighendCoder schrieb:

    Warum schreibt ihr nicht gleich fehlerfreie Software?

    Wenn so so leicht wäre ... :p Ist es aber leider nicht, weil im realen Leben vorhandenes benutzt werden muss - und das ist auch nicht völlig fehlerfrei!

    Analogon: Kein Autohersteller kann fehlerfreie Autos bauen, weil irgendein Zuliefer eine Macke in seiner gelieferten Komponente haben kann. Bei SW kann das auch der vor mehreren Jahren ausgeschiedene Mitarbeiter verbockt haben.



  • Gut beschrieben und je mehr man sich fremde Komponenten über Libs etc. reinholt desto mehr ist auf deren fehlerfreie Funktionsweise abhängig. Keine Software, egal ob Lib, OS, Treiber etc. ist frei von Fehlern. Solange man selbst nicht die Hardware baut und selbst nicht das OS und die Bibliotheken schreibt, solange wird man keine fehlerfreie Software produzieren, auch nicht mit dem 100fachen Budget.

    Stellt sich nur noch die Frage wie weit ist der Kunde bereit über den normalen Preis drüber zu gehen um noch ein Prozentpünktchen mehr an die nie erreichbaren 100% zu kommen? Ich vermute mal dass hier auch der Preis exponentiell steigen wird und ein kleines Projekt was normal 20.000 EUR kostet dann selbst mit 1Mio nicht fehlerfrei zu kriegen ist.

    Ich arbeite in unserer Firma nur mit PHP und wir bauen fertige Linux-Aplliance für Kunden, aber ich kann auch hier sagen dass Projektmanagment und Unitest extrem heruntergeschraubt wurden, weil kein Kunde die Arbeitszeit mehr bezahlen will, diese übersteigt die eigentliche Programmierung bei weitem.

    Managment und Test ist keine Aufgabe für mal nebenher während man entwickelt, das ist mindestens Fulltime wenn nicht sogar Fulltime für zwei Leute.



  • Danke für die Antworten.

    Ich teste meine SW meist so, wie es vom Kunden gewünscht ist. Klickt er Taste x, so wird y dargestellt. Das klappt dann auch immer.
    Aber Kunden schaffen es, die SW dann komplett anders zu bedienen, so dass letztlich ein Fehler auftritt. Ich finde es echt schwierig, als Entwickler überhaupt auf solche Ideen zu kommen, wie dämlich man die SW bedienen kann.

    Gut, konkret kann ich also folgendes tun:
    +Unit Test wenn möglich immer machen, also neue Klassen und Funktionen testen
    +Danach schauen ob das ganze sich so verhält wie vom Kunden gewünscht
    +Dann von jemand drittem testen lassen (sofern ein Tester vorhanden ist...)
    +Nebenher mal ein Buch zum Thema Testen lesen



  • Du musst die psyhologische Schwelle überwinden, deine eigene SW fehlerhaft aussehen zu lassen.



  • zykosomatik schrieb:

    Du musst die psyhologische Schwelle überwinden, deine eigene SW fehlerhaft aussehen zu lassen.

    Drauf scheißen dass Fehler in der von mir geschriebenen SW sind?



  • Vielleicht meint er auch aus dem Fehler ein Feature zu machen?



  • sdf_fds schrieb:

    +Dann von jemand drittem testen lassen (sofern ein Tester vorhanden ist...)

    Du hast doch geschrieben, dass du in einer Firma als Entwickler arbeitest. Also gibt es auch Tester. Oder ist das eine Einmannfirma?



  • Bashar schrieb:

    sdf_fds schrieb:

    +Dann von jemand drittem testen lassen (sofern ein Tester vorhanden ist...)

    Du hast doch geschrieben, dass du in einer Firma als Entwickler arbeitest. Also gibt es auch Tester. Oder ist das eine Einmannfirma?

    Wir sind ca. 10 Entwickler, leider viel zu wenig Tester.
    Einer der Entwickler arbeitet etwa 50% der Zeit als Tester, und ein Projektleiter testet auch etwa 50% von seiner Zeit. Die anderen Projektleiter testen nur ganz am Ende, vor der Auslieferung, wo es dann meist schon etwas gar spät ist.

    Fein wäre natürlich ein Tester, dem nach der Entwicklung und den eigenen Tests die SW übergibt, der dann drauf los testet, aber das gibts in der Form leider nicht.
    Daher eben mein Wunsch, bereits selber möglichst viele der logischen Fehler zu eliminieren.



  • berniebutt schrieb:

    HighendCoder schrieb:

    Warum schreibt ihr nicht gleich fehlerfreie Software?

    Wenn so so leicht wäre ... :p Ist es aber leider nicht, weil im realen Leben vorhandenes benutzt werden muss - und das ist auch nicht völlig fehlerfrei!

    Eben, schreibt gleich fehlerfreie Software.



  • sdf_fds schrieb:

    Danke für die Antworten.

    Ich teste meine SW meist so, wie es vom Kunden gewünscht ist. Klickt er Taste x, so wird y dargestellt. Das klappt dann auch immer.
    Aber Kunden schaffen es, die SW dann komplett anders zu bedienen, so dass letztlich ein Fehler auftritt. Ich finde es echt schwierig, als Entwickler überhaupt auf solche Ideen zu kommen, wie dämlich man die SW bedienen kann.

    Dann liegt es am falschen Design eurer Software. Software sollte intuitiv zu bedienen sein, damit die Kunden erst gar nicht auf die Idee kommen, sie falsch zu bedienen.



  • sdf_fds schrieb:

    Fein wäre natürlich ein Tester, dem nach der Entwicklung und den eigenen Tests die SW übergibt, der dann drauf los testet, aber das gibts in der Form leider nicht. Daher eben mein Wunsch, bereits selber möglichst viele der logischen Fehler zu eliminieren.

    Richtig, der Entwickler kann vieles und muss alles tun, um höchstmögliche Fehlerfreiheit zu erzielen! Aber wie hier mehrfach gesagt, bleiben immer irgendwelche Fehlerquellen, vor allem in komplexen Systemen (Software, Hardware und Anwender). Fatal, wenn der Entwickler darauf keinen Einfluss hat oder die Fehler selten auftreten.

    Ein Beispiel: Software für eine Walzstrasse im Stahlwerk. Der Entwickler hat seine Programme fehlerfrei geliefert. In den Steuersystemen der Walzen tritt ein Aussetzer oder eine Verzögerung ein. Ergebnis: die Bleche sind 0.1 mm zu dünn oder zu dick. Ein riesiger Schaden, die gewalzten Bleche sind Schrott und der Kunde nimmt diese nicht ab.



  • Na ja, Fehlerfreiheit ist eine Frage der Wirtschaftlichkeit und der Branche. Im Industriebereich ist Fehlerfreiheit extrem wichtig, weil der Schaden sonst riesig wäre. Endkunden verzeihen hingegen deutlich mehr, wenn z.B. bei iTunes der Import nicht klappt, wenn man vorher dies und das gemacht hat oder nach Ausschneiden einer Zeile in Visualstudio diese im Nirvana verschwunden ist, wenn man in der Nähe eine Zeile mit Strg+L löscht...



  • sdf_fds schrieb:

    Ich finde es echt schwierig, als Entwickler überhaupt auf solche Ideen zu kommen, wie dämlich man die SW bedienen kann.

    Wenn man mal von den handwerklichen Umsetzungsmängeln absieht, lassen sich fast alle Softwarefehler darauf zurückführen, dass die SW Situationen ausgesetzt war, an die der Entwickler nicht gedacht hat:

    Unübliche Eingaben,

    Probleme bei Arbeiten mit Massenspeichern,

    Durchschnittswert von 0 Messwerten,

    2 Feiertage, die auf den gleichen Tag fallen,

    zwei Kunden mit gleichem Namen,

    ...

    Gerade hier habe ich meine Zweifel, dass hier Test-Tools helfen. So etwas lässt sich eigentlich nur im Code-Review oder schon bei Requirement Management bekämpfen. Und hier kommt es stark auf das fachliche Know-How und die handwerklichen Fähigkeiten der Beteiligten an.

    Ciao, Allesquatsch



  • Imo kann man auf Fehlerfreiheit sowieso nicht testen. Das einzige was man mit einem Test abbilden kann ist die funktionale Korrektheit für die gegebenen Eingabewerte. So haben mir das jedenfalls die Tester bei uns hier im Haus erklärt. Erscheint mir aber auch logisch. Wenn ein Anwender Murks bei der Bedienung macht, unwissentlich oder wissentlich, oder sich irgendwelche Daten wegen Laufzeiten in Maschinen (sehr schönes Beispiel von oben) verzögern, erweitert sich natürlich der Eingaberaum bis ins unendliche. Das kann dann keiner mehr in einer Zeit x testen ohne das Budget zu sprengen.

    Was jedenfalls derber Mist ist ist wenn ein Programmierer seinen eigenen Module testen soll. Da wird automatisch schon einiges an "Betriebsblindheit" erreicht.
    Code - Reviews sollten sowieso Pflischt sein.

    Wenn man natürlich das Glück hat ein super Spezifikation zu haben, die wirklich 99% der Fehlerfälle von vorne herein abdeckt, ist man natürlich fein raus. Aber die Dinger sind doch eher selten anzutreffen.


Log in to reply