Hallo guten Tag, ich frage mich wie man den Vorgang nennt, wenn man einen Programmteil hat und diesen überprüft. Also angenommen meine Funktion f(int x) soll immer int 2 ausgeben. Ich gebe alle Werte ein die ich als relevant "empfinde" und vergleiche dann die Ausgabe mit 2. Wie nennt man diesen Vorgang. Also im Bereich der Informatik. Wäre das eine Verifizierung? Validierung ist ja eher die Überprüfung der Kundenanforderungen(?) Ich habe diese Begriffe nie korrekt gelernt, deswegen frage ich jetzt. Vielen Dank :)
Straßenbauer schrieb: > Wäre das eine Verifizierung? Nö, das ist ein Test. Einer, der auch nur so gut ist wie Deine Einschätzung, welche Werte "relevant" sind.
Straßenbauer schrieb: > Ich habe diese Begriffe nie korrekt gelernt, deswegen frage ich jetzt. Dann wird es Zeit das Du dir mal die kostenlose Begriffserklärung als PDF runterziehst. Ist auf deutsch und Englisch. https://www.german-testing-board.info/wp-content/uploads/2018/09/ISTQB_GTB-Standardglossar-der-Testbegriffe-in-CTFL-2018-Englisch-Deutsch.pdf
(Unit) Test, im weiteren Sinne Validierung. Straßenbauer schrieb: > Wäre das eine Verifizierung? Nein. Straßenbauer schrieb: > Validierung ist ja eher die Überprüfung der Kundenanforderungen(?) Nein, Validierung ist generell die Prüfung gegen eine Anforderung. Beziehungsweise umgekehrt ist ja jede Softwareanforderung irgendwo von einer Kundenanforderung abgeleitet, so ein solcher existiert.
Das nennt man Unittest. Verifizierung: Ich prüfe ob richtig entwickelt wurde (z.B. ob Richtlinien eingehalten wurden) Validierung: Ich prüfe, dass das richtige gebaut wurde (gegen Anforderungen)
Straßenbauer schrieb: > einen Programmteil hat und diesen überprüft Zeitverschwendung. Also in den Augen des Managements. Ansonsten schreibt man einen Test, baut diesen ins CI und implementiert dagegen.
Testen wird generell völlig überbewertet! Dafür gibt es doch Kunden die bei Problemen ein Formular ausfüllen... Gruss Chregu
Computer sind quasi-chaotische Gebilde, da kann man nichts zuverlässig testen. Eigentlich determinert, aber viel zu komplex um sagen zu können, dass man eine Software 100%ig getestet habe.
Ich werfe noch break point in die Runde. Kann man für das laufende Programm einfügen, wenn man z. b. Zwischenergebnisse überprüfen will.
Straßenbauer schrieb: > Ich gebe alle Werte ein die ich als relevant "empfinde Je nach Einsatzgebiet müssen die Werte so gewählt werden, dass jede Zeile mindestens einmal durchlaufen wird oder jeder Pfad (also dass ein if auch nicht durchlaufen wird) Tools geben das als test-coverage aus
https://de.wikipedia.org/wiki/Validität https://de.wikipedia.org/wiki/Reliabilitäts-Validitäts-Dilemma Validität ginge beim Code ein wenig in die Richtung, dass man schon vorher sehen könnte, was rauskommt. Objektiv wäre dann auch die Wiederholbarkeit. So grob fällt mir noch der Begriff Ökonomie ein. Beispielsweise, wenn man mehrere Compiler diesbezüglich durchprobiert, - dann den Eindruck gewinnt, dass man beim gcc mittlerweile vor lauter peniblen Fehlermeldungen kaum noch auf einen grünen Zweig kommt. Man muss ja mit dem Kram arbeiten können. Bewährt haben sich gute Zusatzprogramme, gute Bibliotheken, oder wirklich fundierte, Spaß machende Hilfen bzw. Tutorials. Recht beliebt beim Testen ist z.B. ein Zufallsgenerator, der immer die gleiche Zahl herausgibt ;)
Christoph db1uq K. schrieb: > Computer sind quasi-chaotische Gebilde, da kann man nichts zuverlässig > testen. Eigentlich determinert, aber viel zu komplex um sagen zu können, > dass man eine Software 100%ig getestet habe. 100% testen kann man eh nicht, da selbst bei recht trivialen Dingen der Testaufwand explodieren würde. Das ist die Crux beim Testen. rbx schrieb: > Recht beliebt beim Testen ist z.B. ein Zufallsgenerator, der immer die > gleiche Zahl herausgibt ;) Also so eine Funktion? https://xkcd.com/221/
Rolf M. schrieb: > 100% testen kann man eh nicht, da selbst bei recht trivialen Dingen der > Testaufwand explodieren würde. Das ist die Crux beim Testen. Nicht zu verwechseln mit 100% Testcoverage, welche durchaus erreicht werden kann, ohne dass der Aufwand explodiert. Meine Erfahrung nach hilft es ungemein, die Tests parallel zum Code zu entwickeln, das hat den Vorteil, dass schon bei der Implementierung ein Design gewählt wird, welches das Testen vereinfacht.
Purzel H. schrieb: > Das Ueberpruefen von Code heisst Review Wenn es jemand anders macht. Seinen eigenen Code zu "reviewen" ist wenig sinnvoll, da fällt einem ein Fehler, den man gemacht hat, beim 2. Hinschauen auch nicht auf. Das grösste Hindernis ist eh die Überzeugung der meisten Entwickler keine Fehler zu machen. Georg
Georg schrieb: > Seinen eigenen Code zu "reviewen" ist wenig > sinnvoll, da fällt einem ein Fehler, den man gemacht hat, beim 2. > Hinschauen auch nicht auf. https://www.nerdwallet.com/blog/engineering/why-you-should-be-doing-self-reviews/
Imonbln schrieb: > das hat den Vorteil, dass schon bei der Implementierung ein Design > gewählt wird, welches das Testen vereinfacht. Was zugleich auch dessen Nachteil ist: Funktionen haben dann einstellige McCabes.
A. S. schrieb: > Was zugleich auch dessen Nachteil ist: Funktionen haben dann einstellige > McCabes. Inwiefern ist das ein Nachteil? McCabe hat selbst <10 angestrebt wenn möglich.
Georg schrieb: > Wenn es jemand anders macht. Seinen eigenen Code zu "reviewen" ist wenig > sinnvoll, da fällt einem ein Fehler, den man gemacht hat, beim 2. > Hinschauen auch nicht auf. Der Punkt ist interessant, so wurden früher beim Diktat-Korrigieren immer die Hefte mit dem Nachbarn getauscht. Nicht unbedingt ein Qualitätsgarant (war Comic-Freak, sehr gut in Rechtschreibung, was die Einschätzung diesbezüglich einfach machte) - aber trotzdem eine wirksame Maßnahme. Man hat selber auch immer so "blinde Flecken" oder sieht manchmal den Wald vor lauter Bäumen nicht. Ziemliches Highlight ist es ja sowieso, wenn mehrere gute Leute an einem Stück Code zum Optimieren zusammenfinden - und das ist bei anderen Beziehungen wie Witze konstruieren, Tischerücken oder Computerdesign ganz ähnlich. Oder umgekehrt: Manchmal kann eine Gruppe sehr gut sein - zusammen. Und dann nur noch Hamsterhusten, wenn einer aussteigt: http://www.katzenjammer.com/story/ (hätte man jetzt bei dem Video https://www.youtube.com/watch?v=3KOvbx9Ivjk nicht gedacht - ist für mich aber wieder ein gutes Beispiel dass das Ganze doch mehr ist als die Summe seiner Teile) Grundsätzlich beschreibt die Frage oben auch eher eine Art "Hausarbeit" (einzelne Funktionen werden sowieso meist gut durchgetestet) - und weniger ein Prinzip der Informatik.
rbx schrieb: > Georg schrieb: >> Wenn es jemand anders macht. Seinen eigenen Code zu "reviewen" ist wenig >> sinnvoll, da fällt einem ein Fehler, den man gemacht hat, beim 2. >> Hinschauen auch nicht auf. "Source-Review" ist ohnehin kein Test, sondern man verschafft sich lediglich durch den Review einen Überblick/Zusammenfassung über das Ge-code. Zum etwas Test-ähnlichen wird es erst, wenn man es neben den Review aka Zusammenfassung des Anforderungsdokument tut und versucht die Anforderungen in der Implementierung wiederzufinden. Review dient lediglich der Austauschbarkeit des Coders: Kann das, was Coder A geschrieben hat von Coder B nach dem möglichen Ausscheiden von Coder A gewartet werden? Diese Austauschbarkeit versucht man dadurch zu erreichen, das sich alle dem Company-Code-Style unterwerfen. Auch die Linux-Entwicklung ist einem Code-Style verpflichtet: https://slurm.schedmd.com/coding_style.pdf
vn nn schrieb: > Inwiefern ist das ein Nachteil? McCabe hat selbst <10 angestrebt wenn > möglich. Es gibt viele gute wichtige kleine Funktionen. Ein Bit zu setzen oder ob eine Zahl in einem Bereich ist. Es gibt aber auch große komplexe Funktionen, die man nicht wirklich gut zerlegen kann. Genau das passiert dann trotzdem, um die Test einfacher zu halten.
A. S. schrieb: > Es gibt aber auch große komplexe Funktionen, die man nicht wirklich gut > zerlegen kann. > > Genau das passiert dann trotzdem, um die Test einfacher zu halten. Wenn zerlegen den Test einfach hält, ist die Funktion offensichtlich sehr wohl gut zu zerlegen. Und A. S. schrieb: > Es gibt viele gute wichtige kleine Funktionen. Ein Bit zu setzen oder ob > eine Zahl in einem Bereich ist. Wer mit einem McCabe < 10 (von mir aus auch < 20) lediglich ein Bit setzen oder eine Zahl auf größer/kleiner testen kann, sollte vermutlich keine professionelle Software entwickeln. Folgende Bubblesort-Implementierung geht sich mit 5 aus:
1 | def bubblesort(array): |
2 | length = len(array) |
3 | for i in range(length - 1): |
4 | swapped = False |
5 | for j in range(length - i - 1): |
6 | if array[j] > array[j + 1]: |
7 | swapped = True |
8 | array[j], array[j + 1] = array[j + 1], array[j] |
9 | if not swapped: |
10 | break |
vn n schrieb: > Wer mit einem McCabe < 10 (von mir aus auch < 20) lediglich ein Bit > setzen oder eine Zahl auf größer/kleiner testen kann, sollte vermutlich > keine professionelle Software entwickeln. Da stimme ich Dir zu. Es gibt trotzdem hilfreiche Funktionen mit McCabe <=2. Es ist jedoch ein Trugschluss, dass komplexe Funktionen (z.B. McCabe >100) durch zerlegen (in Summe) einfacher werden. Auch wenn es oft Arten von Table-Driven-Design gibt, sowas einfacher zu machen, bleiben viele Fälle, wo es nicht geht. Manchmal macht ein switch mit 100 cases Sinn. Und manchmal ein geschlossener Ablauf statt 30 kleinst-Funktionen mit je McCabe von 5 oder so.
Straßenbauer schrieb: > Hallo guten Tag, > > ich frage mich wie man den Vorgang nennt, wenn man einen Programmteil > hat und diesen überprüft. > Also angenommen meine Funktion f(int x) soll immer int 2 ausgeben. > Ich gebe alle Werte ein die ich als relevant "empfinde" und vergleiche > dann die Ausgabe mit 2. > Wie nennt man diesen Vorgang. Also im Bereich der Informatik. > > Wäre das eine Verifizierung? > > Validierung ist ja eher die Überprüfung der Kundenanforderungen(?) > > Ich habe diese Begriffe nie korrekt gelernt, deswegen frage ich jetzt. > > Vielen Dank :) Dibagging
A. S. schrieb: > Es ist jedoch ein Trugschluss, dass komplexe Funktionen (z.B. McCabe > >100) durch zerlegen (in Summe) einfacher werden. Auch wenn es oft Arten > von Table-Driven-Design gibt, sowas einfacher zu machen, bleiben viele > Fälle, wo es nicht geht. Mir würde kaum eine sinnvolle Anwendung einfallen. Ein derartiges Monster wäre ja auch kaum sinnvoll testbar. A. S. schrieb: > Manchmal macht ein switch mit 100 cases Sinn. Nein, einfach nur nein. Sowas ist zu 99,9% einfach nur ein Zeichen für mieses Design. Die arme Seele die die Tests dafür schreiben muss wäre ja echt zu bemitleiden.
:
Bearbeitet durch User
Vn N. schrieb: > Die arme Seele die die Tests dafür schreiben muss wäre ja > echt zu bemitleiden. Damit haben wir uns jetzt einmal im Kreis gedreht.
A. S. schrieb: > Vn N. schrieb: >> Die arme Seele die die Tests dafür schreiben muss wäre ja >> echt zu bemitleiden. > > Damit haben wir uns jetzt einmal im Kreis gedreht Inwiefern? Dass du gerne untestbare Software schriebst? Wie validierst du dann, dass die tut was sie soll?
Wie im Märchen: "Heute debug ich, morgen browse ich, übermorgen caste ich die Königin zu int;" ... (unbekanntes Rumpelcodchen)
vn n. schrieb: > Inwiefern? Dass du gerne untestbare Software schriebst? Als ich mich mit den Anfängen der Programmierung beschäftigt habe war die Einstellung verbreitet: "Auf keinen Fall darf mein Chef oder sonstjemand in der Firma verstehen, was ich programmiere. Dann bin ich praktisch unkündbar." Heute sind solche Programmierer gottseidank fast ausgestorben, besonders in Firmen, die mehr als einen Softwarespezialisten beschäftigen. Dass die Zusammenarbeit ihre eigenen Probleme hat sieht man an dem Spruch, dass die Softwareerstellung im Team dem Versuch gleichkommt, eine Schwangerschaft durch den Einsatz von 9 Frauen auf einen Monat zu begrenzen. Georg
Vn N. schrieb: > A. S. schrieb: >> Manchmal macht ein switch mit 100 cases Sinn. > > Nein, einfach nur nein. Sowas ist zu 99,9% einfach nur ein Zeichen für > mieses Design. Die arme Seele die die Tests dafür schreiben muss wäre ja > echt zu bemitleiden. Na ja, macht 100 Testfälle ;) Solchen Code mit xxx cases schreib man natürlich nicht von Hand, der purzelt automatisiert aus irgend einem Script. Oliver
Oliver S. schrieb: > Solchen Code mit xxx cases schreib man natürlich nicht von Hand, der > purzelt automatisiert aus irgend einem Script. Womit sich das ganze ziemlich sicher auch ohne Swich-Monster lösen liese. Oliver S. schrieb: > Vn N. schrieb: >> A. S. schrieb: >>> Manchmal macht ein switch mit 100 cases Sinn. >> >> Nein, einfach nur nein. Sowas ist zu 99,9% einfach nur ein Zeichen für >> mieses Design. Die arme Seele die die Tests dafür schreiben muss wäre ja >> echt zu bemitleiden. > > Na ja, macht 100 Testfälle ;) Und dass keiner übersehen wurde prüfst du einfach mal schnell durch drüberlesen?
:
Bearbeitet durch User
vn n. schrieb: > Inwiefern? Dass du gerne untestbare Software schriebst? Wie validierst > du dann, dass die tut was sie soll? Der Kreis zum Ausgangsstatement: Man designt so, dass das Testen vereinfacht wird. A. S. schrieb: > Imonbln schrieb: >> das hat den Vorteil, dass schon bei der Implementierung ein Design >> gewählt wird, welches das Testen vereinfacht. > > Was zugleich auch dessen Nachteil ist: Funktionen haben dann einstellige > McCabes. Beispiel: embedded Tastatur mit 10 Tasten und McCabe 10.
1 | void KeyCheck(struct KeyType k) |
2 | {
|
3 | if(k.key0) {EnableXY();} |
4 | if(k.key1) {SwitchMenu();} |
5 | if(k.key2) {...;} |
6 | ...
|
7 | if(k.key9) {...;} |
8 | }
|
Und das gleiche ohne jede Verzweigung
1 | void KeyCheck(struct KeyType k) |
2 | {
|
3 | KeyCheck0(k.key0); |
4 | KeyCheck1(k.key1); |
5 | KeyCheck2(k.key2); |
6 | ...
|
7 | KeyCheck9(k.key9); |
8 | }
|
McCabe gering, einfacher zu testen, aber nicht einfacher zu lesen oder zu warten (+10 Funktionen) Zudem steigt die Chance, dass der Test geschlampt wird: Im ersten Beispiel testest Du, ob ein Aufruf mit k.key0 EnableXY aufruft. Im zweiten erstellst Du 2 unabhängige Tests: a) ob KeyCheck0 bei k.key0 aufgerufen wird b) ob KeyCheck0 EnableXY aufruft. Die Frage, ob k.key wirklich EnableXY aufruft, wird in den "Regressionstest" verschoben und nur noch halbherzig, stichpunktartig oder gar nicht verfolgt. Man hat ja 100% TestCoverage.
A. S. schrieb: > Der Kreis zum Ausgangsstatement: Man designt so, dass das Testen > vereinfacht wird. Gerade eben hast du noch erklärt dass dabei zu kleine Funktionen rausfallen. A. S. schrieb: > Beispiel: embedded Tastatur mit 10 Tasten und McCabe 10. > void KeyCheck(struct KeyType k) > { > if(k.key0) {EnableXY();} > if(k.key1) {SwitchMenu();} > if(k.key2) {...;} > ... > if(k.key9) {...;} > } > > Und das gleiche ohne jede Verzweigungvoid KeyCheck(struct KeyType k) > { > KeyCheck0(k.key0); > KeyCheck1(k.key1); > KeyCheck2(k.key2); > ... > KeyCheck9(k.key9); > } > > McCabe gering, einfacher zu testen, aber nicht einfache zu lesen oder zu > warten, weil die Anzahl der Funktionen (+10) nicht eingeht. Sorry, das Beispiel ist absoluter Bullshit, da ist gar nix einfach zu testen. Warum, hast du unmittelbar darunter ja schon selbst erklärt. Abgesehen davon ist ja selbst der erste Codeblock noch einem akzeptablen McCabe-Bereich, es würde also kein Bedarf bestehen in zu ändern. Und wenn du jetzt mit "aber ist gibt key1 bis key999" ankommst, sorry, dann ist eine endlose Reihe an if-Statements einfach die falsche Herangehensweise. Verkacktes Softwaredesign wird halt auch durch Kosmetik nicht besser.
A. S. schrieb: > Die Frage, ob k.key wirklich EnableXY aufruft, wird in den > "Regressionstest" verschoben Du meinst vermutlich "Integrationstest".
Volkslehrer schrieb: > Straßenbauer schrieb: >> Ich habe diese Begriffe nie korrekt gelernt, deswegen frage ich jetzt. > > Dann wird es Zeit das Du dir mal die kostenlose Begriffserklärung als > PDF runterziehst. Ist auf deutsch und Englisch. > > https://www.german-testing-board.info/wp-content/uploads/2018/09/ISTQB_GTB-Standardglossar-der-Testbegriffe-in-CTFL-2018-Englisch-Deutsch.pdf Ein Plus von mir und nochmal extra Dank. Toller Fund. Welche Lernbefreite geben bei sowas lehrreichem ein Minus? Schopfkuettel, nicht verstehen, Brr.
Joachim L. schrieb: >> > https://www.german-testing-board.info/wp-content/uploads/2018/09/ISTQB_GTB-Standardglossar-der-Testbegriffe-in-CTFL-2018-Englisch-Deutsch.pdf > > Ein Plus von mir und nochmal extra Dank. Toller Fund. Gerne. Generell der Hinweis sich mal zu schauen was "User-Groups"/Zertifizierer und ähnliches so an öffentlichen Dokumenten publizieren. https://www.istqb.org/certifications/certification-list Und man kann ja auch mal das ein oder andere Fachbuch erwerben wie ISBN: 978-3-89864-638-3 (https://www.vigenschow.com/softwaretest-qualitaet/ ) > Welche Lernbefreite geben bei sowas lehrreichem ein Minus? Hier wird halt oft danach bewertet was im Feld "name" steht, und der eigentliche Beitrag wird komplett ignoriert. Ist halt zu "social media" verkümmert, vielleicht war es nie ein Fachforum.
Georg schrieb: > Dass > die Zusammenarbeit ihre eigenen Probleme hat sieht man an dem Spruch, > dass die Softwareerstellung im Team dem Versuch gleichkommt, eine > Schwangerschaft durch den Einsatz von 9 Frauen auf einen Monat zu > begrenzen. Und das Managen einer Softwareentwicklertruppe ist wie Katzen hüten :) Mein Lieblingsvideo dazu: https://youtu.be/hx1jdgTs03U?t=5
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.