8
Funktionstest einer selbst programmierten Webseite mit IMacro
wie ich meine oder eine andere Webseite am effizientesten teste
Aufgabenstellung: Test eines Eingabeformulars in einer Webseite
eine größere Formularseite hat oftmals eine Reihe von unterschiedlichen Eingabefeldern. Die durch das Formular entgegengenommenen Daten werden oft in einer Datenbank gespeichert. Dabei können eine Reihe von Problemen auftreten und um diese schon vor der Veröfffentlichung der Webseite zu erkennen, müssen diese Seiten getestet werden.
Ablauf eines solchen Tests
die Webseite wird immer und immer wieder aufgerufen und mit Daten gefüllt. Diese Geschichte kann man auch automatisieren. Ich benutze dafür IMacro von IOpus.
Dieses Programm kann man als Browsererweiterung für IE und Firefox installieren. Es zeichnet alle Aktionen, vom Aufrufen der Webseite über die Eingabe in die einzelnen Datenfelder in einem Macro auf. Das Macro wird in einer Datei gespeichert und kann somit im Nachhinein bearbeitet werden.
Die so erzeugten Macro's können dann immer wieder im Browser gestartet werden und schaut sich den Ablauf dann an.
IMacro erkennt bei der Aufnahme die unterschiedlichen Arten und Typen von Datenfeldern in der Webseite und bietet sehr vielfältige Möglichkeiten zusätzliche Funktionen in die Macro's einzubauen.
##red | Wenn Sie ein Web-Entwickler sind, kann iMacros das Folgende für Sie erledigen::##
- Testen komplexer Websites indem Sie auf einen Knopf drücken: Bevor Sie Ihre Seite ändern, nehmen Sie ein Makro auf, das das typische Verhalten eines Benutzers simuliert, also etwa die Aufnahme einiger Produkte in einen Warenkorb. Nach den Änderungen an der Site spielen Sie die Makros einfach ab, um sicher zu gehen, dass Elemente, die zuvor funktioniert haben, auch nach den Änderungen an der Seite oder am Server keine Probleme bereiten.
- Automatisieren der Anmeldung bei Suchmaschinen: Verwalten Ihrer Google und Overture "Pay per Click" Einstellungen, Informationsextraktion, Automatisierte Abfrage von Online-Datenbanken mit Herunterladen der Ergebnisse, ...
- Internet Monitoring: iMacros kann Ihre Website beobachten, und Sie informieren, wenn Probleme auftauchen. Gegenüber reinen Monitoringdiensten kann iMacros Webseiten beliebiger Komplexität testen (z.B.: Testeinkäufe tätigen), auch wenn diese auf Java und Macromedia Flash aufsetzen.
- Messen der Reaktionszeit mit den STOPWATCH-Befehlen können Sie permanent aktualisierte Leistungsstatistiken erzeugen.
- Verzichten Sie auf komplizierte Lösungen mit Cron jobs, grep, sed, awk, lwp oder anderen aufwändigen Unix-Tools. Keines davon leistet das, was iMacros kann!
- iMacros kann so eingestellt werden, daß es den Internet Explorer (IE) vollständig simuliert. In diesem Modus kann kein Web-Server zwischen einem normalen (menschlichen) und der iMacros-Software unterscheiden.
- Extrahieren Sie beliebige TABELLEN direkt in CSV-Dateien, die von nahezu jeder Tabellenkalkulation (inkklusive Excel) importiert werden können.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 151027
Url: https://administrator.de/knowledge/funktionstest-einer-selbst-programmierten-webseite-mit-imacro-151027.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
8 Kommentare
Neuester Kommentar
Moin,
ggf. gut um EINE Test-Art für eine Webseite zu machen. Allerdings würde ich mich nicht darauf verlassen - denn zu einem Test gehört einfach noch etwas mehr:
a) Man kann keine eigene Software testen!
Das ist schonmal ein Grundsatz. Denn zum einen wird niemand sich gern selbst einen Fehler nachweisen (insbesondere bei kommerziellen Produkten wo man dann ggf. vorm Chef sogar ncoh sagen muss das man nen Fehler gemacht hat). Weiterhin KANN man sich einen eigenen Fehler oftmals nicht nachweisen -> weil man die Aufgabe schlicht anders verstanden hat oder weil man eben SEIN Vorgehen hat. Nehmen wir mal den Warenkorb an: Ich als Entwickler setze ggf. vorraus das man sich was aus der Webseite raussucht, dort in eine Box z.B. eine 2 (für 2 Artikel dieses Typs) einträgt und auf "In den Warenkorb legen" klickt. Damit hat man dann 2 Artikel des Typs im Warenkorb gekauft. Das testet das Script dann zig mal - und alles ist gut. Jetzt kommt der reale Kunde und möchte 2 Artikel des Typs kaufen. Dieser trägst aber nur die 1 bei Anzahl an - und klickt eben 2x auf "In den Warenkorb legen". Dummerweise rechnet die SW die Preise nicht mehr zusammen - was mir bei meinen 5000 Tests nie aufgefallen ist weil mir DIESER weg einfach nie eingefallen ist!
b) Grenzwerte &/ falsche Werte
Hier ist jetzt die Sache das man bei Anzahl z.B. einfach mal folgende Werte eingibt:
-1 (erfolgt jetzt eine Gutschrift weil ich -1 Auto gekauft habe?)
3.1415926 (es dürfte schwer werden 0,1415926 Festplatten zu kaufen, oder?)
3,1415926 (selbst wenn es teilmengen gibt - ist das KOMMA auch ok oder gibt das Rechenfehler?)
0 -> was macht der Warenkorb jetzt?
999999999 / -999999999 (je nachdem welche Sprache man hat mal den Randwert und Randwert +/-1)
a -> wieviel sind "a" autos?
c) Unlogische Werte
Nehmen wir mal ein simples Tippspiel für Fussballwetten an. Was ist wenn ich als Ergebnis "Werder Bremen vs Bayern München" folgenes eingebe:
5 : -1? Ich glaube kaum das jemand -1 tore schiessen kann (ok, Eigentor ggf...)
x : y? Mit dieser Eingabe (so das System die akzeptiert) habe ich immer gewonnen - solang ich eben nicht gesagt habe was x & y für einen Wert darstellen
999 : 999? Wäre zwar sicher ein gültiger Wert - aber einer der eher unmöglich zu erreichen sein wird.
d) Sonderfälle
Grad im Bereich "Web-Anwendung" (ggf. mit ner DB dahinter) muss man extrem vorsichtig sein. Denn: Der Kunde hat ggf. nicht immer das beste im Sinn. Nehmen wir mal an das die Webanwendung zwar immer richtig rechnet aber einfach nichts prüft. Jetzt gibt der Kunde etwa folgendes ein:
1); show tables; select (1
und die DB bekommt jetzt folgendes:
insert into... values ( ... 1); show tables; select (1); (das letzte ); wäre der Abschluss den man eigentlich für SEIN statement vorgesehen hat)
-> Jetzt weiss ich welche Tabellen man hat.
In einer zweiten Zeile sage ich einfach select * from <tabelle in der mein warenkorb liegt>
-> Jetzt weiss ich wie die Spalten heissen
In einer dritten Zeile sage ich jetzt also nur noch
update <tabelle der rechnung> set gesamtsumme=0 where ....
-> so, dein System sagt mir jetzt (wenn dieser wirklich simple Versuch klappt - wobei der hier auch absichtlich so steht das man den SO simpel garantiert nirgends durchbekommt!) das ich 20 Audi R8 zum Gesamtpreis von 0 Euro gekauft habe... Danke schön
e) weitere Tests
Es gibt jetzt noch eine ganze Reihe von Tests die man nebenbei durchführen sollte (z.B. bei Web-Anwendungen: Was passiert wenn der Browser nen ganz anderen Zeichensatz sendet als ich erwarte? Was passiert wenn in der Post-Variable o. whatever nur Müll steht? Was ist mit extrem langen Zeichenketten?)
Von daher finde ich einen Test nur mit solchen Makros immer extrem dürftig. Klar - sieht lustig aus, der Kunde freut sich das er nen 2m-dickes Testprotokoll bekommt - aber OHNE genaue Analyse welche Werte man da nimmt und andere Tests ist das reines Klopapier-Drucken. Denn damit hat man absolut keine Sicherheit gewonnen - die Anwendung kann immernoch schlimmer als nen schweizer Käse aussehen - und der Test würde sagen: Joar, alles super!
ggf. gut um EINE Test-Art für eine Webseite zu machen. Allerdings würde ich mich nicht darauf verlassen - denn zu einem Test gehört einfach noch etwas mehr:
a) Man kann keine eigene Software testen!
Das ist schonmal ein Grundsatz. Denn zum einen wird niemand sich gern selbst einen Fehler nachweisen (insbesondere bei kommerziellen Produkten wo man dann ggf. vorm Chef sogar ncoh sagen muss das man nen Fehler gemacht hat). Weiterhin KANN man sich einen eigenen Fehler oftmals nicht nachweisen -> weil man die Aufgabe schlicht anders verstanden hat oder weil man eben SEIN Vorgehen hat. Nehmen wir mal den Warenkorb an: Ich als Entwickler setze ggf. vorraus das man sich was aus der Webseite raussucht, dort in eine Box z.B. eine 2 (für 2 Artikel dieses Typs) einträgt und auf "In den Warenkorb legen" klickt. Damit hat man dann 2 Artikel des Typs im Warenkorb gekauft. Das testet das Script dann zig mal - und alles ist gut. Jetzt kommt der reale Kunde und möchte 2 Artikel des Typs kaufen. Dieser trägst aber nur die 1 bei Anzahl an - und klickt eben 2x auf "In den Warenkorb legen". Dummerweise rechnet die SW die Preise nicht mehr zusammen - was mir bei meinen 5000 Tests nie aufgefallen ist weil mir DIESER weg einfach nie eingefallen ist!
b) Grenzwerte &/ falsche Werte
Hier ist jetzt die Sache das man bei Anzahl z.B. einfach mal folgende Werte eingibt:
-1 (erfolgt jetzt eine Gutschrift weil ich -1 Auto gekauft habe?)
3.1415926 (es dürfte schwer werden 0,1415926 Festplatten zu kaufen, oder?)
3,1415926 (selbst wenn es teilmengen gibt - ist das KOMMA auch ok oder gibt das Rechenfehler?)
0 -> was macht der Warenkorb jetzt?
999999999 / -999999999 (je nachdem welche Sprache man hat mal den Randwert und Randwert +/-1)
a -> wieviel sind "a" autos?
c) Unlogische Werte
Nehmen wir mal ein simples Tippspiel für Fussballwetten an. Was ist wenn ich als Ergebnis "Werder Bremen vs Bayern München" folgenes eingebe:
5 : -1? Ich glaube kaum das jemand -1 tore schiessen kann (ok, Eigentor ggf...)
x : y? Mit dieser Eingabe (so das System die akzeptiert) habe ich immer gewonnen - solang ich eben nicht gesagt habe was x & y für einen Wert darstellen
999 : 999? Wäre zwar sicher ein gültiger Wert - aber einer der eher unmöglich zu erreichen sein wird.
d) Sonderfälle
Grad im Bereich "Web-Anwendung" (ggf. mit ner DB dahinter) muss man extrem vorsichtig sein. Denn: Der Kunde hat ggf. nicht immer das beste im Sinn. Nehmen wir mal an das die Webanwendung zwar immer richtig rechnet aber einfach nichts prüft. Jetzt gibt der Kunde etwa folgendes ein:
1); show tables; select (1
und die DB bekommt jetzt folgendes:
insert into... values ( ... 1); show tables; select (1); (das letzte ); wäre der Abschluss den man eigentlich für SEIN statement vorgesehen hat)
-> Jetzt weiss ich welche Tabellen man hat.
In einer zweiten Zeile sage ich einfach select * from <tabelle in der mein warenkorb liegt>
-> Jetzt weiss ich wie die Spalten heissen
In einer dritten Zeile sage ich jetzt also nur noch
update <tabelle der rechnung> set gesamtsumme=0 where ....
-> so, dein System sagt mir jetzt (wenn dieser wirklich simple Versuch klappt - wobei der hier auch absichtlich so steht das man den SO simpel garantiert nirgends durchbekommt!) das ich 20 Audi R8 zum Gesamtpreis von 0 Euro gekauft habe... Danke schön
e) weitere Tests
Es gibt jetzt noch eine ganze Reihe von Tests die man nebenbei durchführen sollte (z.B. bei Web-Anwendungen: Was passiert wenn der Browser nen ganz anderen Zeichensatz sendet als ich erwarte? Was passiert wenn in der Post-Variable o. whatever nur Müll steht? Was ist mit extrem langen Zeichenketten?)
Von daher finde ich einen Test nur mit solchen Makros immer extrem dürftig. Klar - sieht lustig aus, der Kunde freut sich das er nen 2m-dickes Testprotokoll bekommt - aber OHNE genaue Analyse welche Werte man da nimmt und andere Tests ist das reines Klopapier-Drucken. Denn damit hat man absolut keine Sicherheit gewonnen - die Anwendung kann immernoch schlimmer als nen schweizer Käse aussehen - und der Test würde sagen: Joar, alles super!
Hi Leute,
zu nächst bin ich einmal erfreut, dass sich jemand die Mühe gemacht hat auf meinen Tipp zu antworten
nachdem ich mir diese langen Kommentar durchgelesen habe, war ich leider nicht mehr so erfreut, da unser Kommentarschreiber @maretz den Sinn dieses Beitrages verkannt hat.
hierauf möchte ich Dir sagen, ich habe das ganze als Tipp reingestellt. Ich wollte hier keineswegs eine vollständige Abhandlung über Softwaretests veröffentlichen. Wie Du weiter unten selbst sagst ghöhrt da etwas mehr dazu, in dem Punkt stimme ich Dir auch zu.
ich habe Deine Argumentationen zunächst nicht so richtig verstanden.
Zum Glück hast Du ja alles über Dich im Netz zu stehen. Nachdem ich mir Deinen Werdegang mal reingezogen habe, bin ich zur Erkentnis gekommen, dass Du offensichtlich keine Schimmer davon hast wie die Entwicklung von Software von Statten geht.
Wenn ein Chef eines Softwarehauses so denken würde wie Du es hier darstellst würde diese Fima mit der ersten Version seiner Software die Sie auf den Markt bringt pleite gehen.
Wenn die Fehler in der Software erst durch die Kunden gefunden werden, würde diese Software beim Kunden niemals in den Echtbetrieb gehen.
Hinzufügen möchte ich, ich rede hier nicht von einem kleinen Online-Shop der vieleicht wenn's hochkommt 1000,- € Umsatz im Jahr macht, sondern von der Entwicklung von Software für Großunternehmen oder Behörden.
b) Grenzwerte &/ falsche Werte
c) Unlogische Werte
d) Sonderfälle
e) weitere Tests
Zumindest kennst Du die möglichen Fehlerquellen, diese aber von vorn herein nicht zuzulassen gehört zu einer guten Software. Weiterhin unterscheiden sich darin auch die Entwickler von Software, ein guter Programmierer berücksichtigt schon bei der entwicklung der SW solche Dinge.
Und dann gibt es noch die Qualitätssicherung, ja die gibt es nicht nur in der Autofabrik, auch in einer Softwarefirma. Die ist dafür da, die Entwicklungen auf Herz und Nieren bis zum Erbrechen zu testen.
über diese Tests bekommt mit Sicherheit kein Kunde ein Protokoll, weil die der eigenen Sicherheit dienen und der Softwarefirma das gute Gefühl geben sollen ein gutes Produkt zu verkaufen.
Leider sieht man immer wieder mal, dass Administratoren der Bezug zum realen Leben oder zum Kunden fehlt. Das scheint bei Dir der Fall zu sein.
Greetings
zu nächst bin ich einmal erfreut, dass sich jemand die Mühe gemacht hat auf meinen Tipp zu antworten
nachdem ich mir diese langen Kommentar durchgelesen habe, war ich leider nicht mehr so erfreut, da unser Kommentarschreiber @maretz den Sinn dieses Beitrages verkannt hat.
Zitat von @maretz:
ggf. gut um EINE Test-Art für eine Webseite zu machen. Allerdings würde ich mich nicht darauf verlassen - denn zu einem
Test gehört einfach noch etwas mehr:
ggf. gut um EINE Test-Art für eine Webseite zu machen. Allerdings würde ich mich nicht darauf verlassen - denn zu einem
Test gehört einfach noch etwas mehr:
hierauf möchte ich Dir sagen, ich habe das ganze als Tipp reingestellt. Ich wollte hier keineswegs eine vollständige Abhandlung über Softwaretests veröffentlichen. Wie Du weiter unten selbst sagst ghöhrt da etwas mehr dazu, in dem Punkt stimme ich Dir auch zu.
Zitat von @maretz:
a) Man kann keine eigene Software testen!
Das ist schonmal ein Grundsatz. Denn zum einen wird niemand sich gern selbst einen Fehler nachweisen (insbesondere bei
kommerziellen Produkten wo man dann ggf. vorm Chef sogar ncoh sagen muss das man nen Fehler gemacht hat). Weiterhin KANN man sich
einen eigenen Fehler oftmals nicht nachweisen -> weil man die Aufgabe schlicht anders verstanden hat oder weil man eben SEIN
Vorgehen hat.
a) Man kann keine eigene Software testen!
Das ist schonmal ein Grundsatz. Denn zum einen wird niemand sich gern selbst einen Fehler nachweisen (insbesondere bei
kommerziellen Produkten wo man dann ggf. vorm Chef sogar ncoh sagen muss das man nen Fehler gemacht hat). Weiterhin KANN man sich
einen eigenen Fehler oftmals nicht nachweisen -> weil man die Aufgabe schlicht anders verstanden hat oder weil man eben SEIN
Vorgehen hat.
ich habe Deine Argumentationen zunächst nicht so richtig verstanden.
Zum Glück hast Du ja alles über Dich im Netz zu stehen. Nachdem ich mir Deinen Werdegang mal reingezogen habe, bin ich zur Erkentnis gekommen, dass Du offensichtlich keine Schimmer davon hast wie die Entwicklung von Software von Statten geht.
Wenn ein Chef eines Softwarehauses so denken würde wie Du es hier darstellst würde diese Fima mit der ersten Version seiner Software die Sie auf den Markt bringt pleite gehen.
Wenn die Fehler in der Software erst durch die Kunden gefunden werden, würde diese Software beim Kunden niemals in den Echtbetrieb gehen.
Hinzufügen möchte ich, ich rede hier nicht von einem kleinen Online-Shop der vieleicht wenn's hochkommt 1000,- € Umsatz im Jahr macht, sondern von der Entwicklung von Software für Großunternehmen oder Behörden.
b) Grenzwerte &/ falsche Werte
c) Unlogische Werte
d) Sonderfälle
e) weitere Tests
Zumindest kennst Du die möglichen Fehlerquellen, diese aber von vorn herein nicht zuzulassen gehört zu einer guten Software. Weiterhin unterscheiden sich darin auch die Entwickler von Software, ein guter Programmierer berücksichtigt schon bei der entwicklung der SW solche Dinge.
Und dann gibt es noch die Qualitätssicherung, ja die gibt es nicht nur in der Autofabrik, auch in einer Softwarefirma. Die ist dafür da, die Entwicklungen auf Herz und Nieren bis zum Erbrechen zu testen.
Von daher finde ich einen Test nur mit solchen Makros immer extrem dürftig. Klar - sieht lustig aus, der Kunde freut sich das
er nen 2m-dickes Testprotokoll bekommt - aber OHNE genaue Analyse welche Werte man da nimmt und andere Tests ist das reines
Klopapier-Drucken. Denn damit hat man absolut keine Sicherheit gewonnen - die Anwendung kann immernoch schlimmer als nen schweizer
Käse aussehen - und der Test würde sagen: Joar, alles super!
er nen 2m-dickes Testprotokoll bekommt - aber OHNE genaue Analyse welche Werte man da nimmt und andere Tests ist das reines
Klopapier-Drucken. Denn damit hat man absolut keine Sicherheit gewonnen - die Anwendung kann immernoch schlimmer als nen schweizer
Käse aussehen - und der Test würde sagen: Joar, alles super!
über diese Tests bekommt mit Sicherheit kein Kunde ein Protokoll, weil die der eigenen Sicherheit dienen und der Softwarefirma das gute Gefühl geben sollen ein gutes Produkt zu verkaufen.
Leider sieht man immer wieder mal, dass Administratoren der Bezug zum realen Leben oder zum Kunden fehlt. Das scheint bei Dir der Fall zu sein.
Greetings
Nun - das sollte eigentlich nur eine Ergänzung sein... Denn EIN Test allein ist nunmal zimlich dürftig. Oder ist es deiner Meinung nach Sinnvoll nur einen automatisierten Test zu nutzen?
Hi @maretz
Du warst leider schneller mit Deinem Beitrag da ich meine noch mal bearbeitet und erweitert hatte. lies also meine Kommentar zu Deiner ersten Antwort.
Greetings
Du warst leider schneller mit Deinem Beitrag da ich meine noch mal bearbeitet und erweitert hatte. lies also meine Kommentar zu Deiner ersten Antwort.
Greetings
Moin,
[quote]
Zum Glück hast Du ja alles über Dich im Netz zu stehen. Nachdem ich mir Deinen Werdegang mal reingezogen habe, bin ich zur Erkentnis gekommen, dass Du offensichtlich keine Schimmer davon hast wie die Entwicklung von Software von Statten geht.
[/quote]
Nun - wenn du dir diese Mühe wirklich gemacht hast dann hättest du ohne große Probleme rausfinden können das ich u.A. Informatik studiert habe. Da bekommt man auch einiges mit... und zwar unter anderem auch wie Software entwickelt wird....
[quote]
Wenn ein Chef eines Softwarehauses so denken würde wie Du es hier darstellst würde diese Fima mit der ersten Version seiner Software die Sie auf den Markt bringt pleite gehen.
[/quote]
Es ging in dem von dir zitierten Teil darum das sich niemand gerne selbst Fehler nachweist. D.h. es bringt nichts die eigene Software zu testen. Dieses findest du u.a. auch im Buch "Basiswissen Software-Test". Und das hat auch einfache Gründe - nämlich das jeder gerne glaubt das er alles richtig macht. Das macht man ganz unbewusst - und niemand hört gerne wenn man ihm sagt das er grad alles völlig falsch gemacht hat.
Die zweite Aussage war das man auch eine Aufgabe falsch verstehen kann. Nun - nehmen wir mal ein simples Beispiel: Ich gehe davon aus das 3*3+2=10 ergibt. Denn ich habe leider vergessen das es ne Regel "Punkt vor Strich" gibt. Nun - ich kann mein Programm jetzt auch 1000 mal testen - ich werde jedesmal abhaken "joar, is richtig" wenn mir das Programm 10 rauswirft. Ist mein Programm jetzt also gut getestet?
Und somit steht meine Aussage auch weiterhin. Niemand sollte eigenen Programmcode testen - da dieser Test ganz einfach nicht sicher ist.
[quote]
Wenn die Fehler in der Software erst durch die Kunden gefunden werden, würde diese Software beim Kunden niemals in den Echtbetrieb gehen.
[/quote]
Wer spricht davon die Software erst beim Kunden zu testen (nicht das sowas nicht oft genug vorgemacht wird)? ICH sprach davon das man nicht seine eigene Software testen sollte. Das bedeutet NICHT das der Kunde das macht - sondern z.B. eine andere Abteilung oder zumindest ein anderer Programmierer...
[quote]
Hinzufügen möchte ich, ich rede hier nicht von einem kleinen Online-Shop der vieleicht wenn's hochkommt 1000,- € Umsatz im Jahr macht, sondern von der Entwicklung von Software für Großunternehmen oder Behörden.
[/quote]
Und GRADE da sollte man das nochmal überlegen. Denn grade da hat man üblicherweise mehr als einen Programmierer. Da hat man ggf. sogar ne Abteilung für Qualitätssicherung - die z.T. explizit NICHT den Quellcode kennt. Also sollte grade dort immer die Grundregel gelten: Niemand testet seinen eigenen Code! (Damit meine ich wirkliche Tests - und nicht ob der Compiler das grad mal durchlässt....)
[quote]
Zumindest kennst Du die möglichen Fehlerquellen, diese aber von vorn herein nicht zuzulassen gehört zu einer guten Software. Weiterhin unterscheiden sich darin auch die Entwickler von Software, ein guter Programmierer berücksichtigt schon bei der entwicklung der SW solche Dinge.
[/quote]
Sorry - mein Dozent hätte an dieser Stelle wörtlich gesagt: Du Klug###er! Du bist so intelligent - bitte, lasse mich an deiner Weisheit teilhaben. Ich sage jetzt mal so: Ok, schenken wir uns den ganzen Test - es gehört zu einer guten Software und einem guten Programmierer das er keine Fehler macht. Keine Fehler -> Kein Test nötig... Dummerweise passieren Fehler - und somit macht man auch solche Tests. DAS ist der Hintergrund. Aber mit dieser Aussage bestätigst du meine erste Aussage: Niemand gibt gern zu das er fehler macht - also braucht man das auch nicht zu testen...
Und ganz nebenbei: Ein guter Programmierer berücksichtigt das schon bei der Entwicklung? Gut - dann kann dein guter Programmierer also aus dem Kopf sämtliche Compiler aufzählen? Denn der Zahlenbereich ist idR. durch den Compiler vorgegeben. Und er kennt auch alle Bugs die ein OS und ggf. sogar die Hardware (P4-Div/0-Bug!) mitbringt - und umschifft die ganz automatisch, ja? Achso - und Rundungsfehler gibts auch nicht (nimm dir mal nen billigen Taschenrechner und rechne die 2 Millionste Wurzel aus 0,2 hoch 2 Millionen... Oft bekommst du hier z.B. das Ergebnis "0". Dummerweise ist die richtige Lösung 0,2 - schade eigentlich... Naja, deinen Taschenrechner haben eben nicht so perfekte Entwickler wie du gebaut...
[quote]
Und dann gibt es noch die Qualitätssicherung, ja die gibt es nicht nur in der Autofabrik, auch in einer Softwarefirma. Die ist dafür da, die Entwicklungen auf Herz und Nieren bis zum Erbrechen zu testen.
[/Quote]
Kluges Kerlchen! Und - was war meine ERSTE Aussage: Man testet keine eigene Software. Na - dämmert dir was? Ob es jetzt die Abteilung QS ist - oder der Programmierer aus dem anderem Team ist dann ne Frage wie groß die Firma ist...
[quote]
über diese Tests bekommt mit Sicherheit kein Kunde ein Protokoll, weil die der eigenen Sicherheit dienen und der Softwarefirma das gute Gefühl geben sollen ein gutes Produkt zu verkaufen.
[/quote]
Ah ja - damit der Geschäftsführer ruhig schläft packt man diese Doku also schön in den Safe? Hmm - ok, sicherlich gibt es das auch. Aber moment - wir reden doch "von der Entwicklung von Software für Großunternehmen oder Behörden.". Nun - das ist dann mit großer Sicherheit keine Software von der Stange - sondern Software für einen speziellen Kunden. Und da gibst du dem Kunden KEINE Doku welche Fälle du getestet hast? Kluge Idee - nur das du diese Software nicht durch die Abnahme durch den Kunden bekommen wirst. Siehe z.B. V-Modell (XT) - hier findest du bereits bei der Anforderungsdefinition auch gleichzeitig gewisse Testfälle spezifiziert. Dasselbe findest du auf den Stufen darunter - und all das möchtest du den Kunden nicht geben? Ganz klasse - dann setzt der sich also hin und testet das nochmal? Oder wie stellst du dir das vor? Und was glaubst du wie du das Abnahme-Protokoll (grad bei Software für Großunternehmen und Behörden) dann Unterschrieben bekommst? Meinst du wirklich du gehst zu Daimler in die EDV: Leute, ihr wolltet nen Programm X haben... Hier, geh mal auf euren Zentral-Server und führe die Setup aus - wir testen denn mal wie das hier läuft.... Mag sein das ich da etwas pessimistisch bin - und ggf. mögen die Admins hier im Forum das jetzt auch gerne Korregieren - aber ich glaube nicht das ein großunternehmen das so locker macht... Da findest du dann nämlich Test-Netze in denen die erst rumprobieren - und selbst da ist idR. dann schon erforderlich das der Programmierer bzw. die Entwicklungsfirma denen was gibt das die sicher sein können das es nicht gleich deren ganzes System abschießt...
[quote]
Leider sieht man immer wieder mal, dass Administratoren der Bezug zum realen Leben oder zum Kunden fehlt. Das scheint bei Dir der Fall zu sein.
[/quote]
Nun - wenn du das sagst... Ich denke ich konnte dir auch ausführliche Begründungen für meine Aussagen geben.
[quote]
Zum Glück hast Du ja alles über Dich im Netz zu stehen. Nachdem ich mir Deinen Werdegang mal reingezogen habe, bin ich zur Erkentnis gekommen, dass Du offensichtlich keine Schimmer davon hast wie die Entwicklung von Software von Statten geht.
[/quote]
Nun - wenn du dir diese Mühe wirklich gemacht hast dann hättest du ohne große Probleme rausfinden können das ich u.A. Informatik studiert habe. Da bekommt man auch einiges mit... und zwar unter anderem auch wie Software entwickelt wird....
[quote]
Wenn ein Chef eines Softwarehauses so denken würde wie Du es hier darstellst würde diese Fima mit der ersten Version seiner Software die Sie auf den Markt bringt pleite gehen.
[/quote]
Es ging in dem von dir zitierten Teil darum das sich niemand gerne selbst Fehler nachweist. D.h. es bringt nichts die eigene Software zu testen. Dieses findest du u.a. auch im Buch "Basiswissen Software-Test". Und das hat auch einfache Gründe - nämlich das jeder gerne glaubt das er alles richtig macht. Das macht man ganz unbewusst - und niemand hört gerne wenn man ihm sagt das er grad alles völlig falsch gemacht hat.
Die zweite Aussage war das man auch eine Aufgabe falsch verstehen kann. Nun - nehmen wir mal ein simples Beispiel: Ich gehe davon aus das 3*3+2=10 ergibt. Denn ich habe leider vergessen das es ne Regel "Punkt vor Strich" gibt. Nun - ich kann mein Programm jetzt auch 1000 mal testen - ich werde jedesmal abhaken "joar, is richtig" wenn mir das Programm 10 rauswirft. Ist mein Programm jetzt also gut getestet?
Und somit steht meine Aussage auch weiterhin. Niemand sollte eigenen Programmcode testen - da dieser Test ganz einfach nicht sicher ist.
[quote]
Wenn die Fehler in der Software erst durch die Kunden gefunden werden, würde diese Software beim Kunden niemals in den Echtbetrieb gehen.
[/quote]
Wer spricht davon die Software erst beim Kunden zu testen (nicht das sowas nicht oft genug vorgemacht wird)? ICH sprach davon das man nicht seine eigene Software testen sollte. Das bedeutet NICHT das der Kunde das macht - sondern z.B. eine andere Abteilung oder zumindest ein anderer Programmierer...
[quote]
Hinzufügen möchte ich, ich rede hier nicht von einem kleinen Online-Shop der vieleicht wenn's hochkommt 1000,- € Umsatz im Jahr macht, sondern von der Entwicklung von Software für Großunternehmen oder Behörden.
[/quote]
Und GRADE da sollte man das nochmal überlegen. Denn grade da hat man üblicherweise mehr als einen Programmierer. Da hat man ggf. sogar ne Abteilung für Qualitätssicherung - die z.T. explizit NICHT den Quellcode kennt. Also sollte grade dort immer die Grundregel gelten: Niemand testet seinen eigenen Code! (Damit meine ich wirkliche Tests - und nicht ob der Compiler das grad mal durchlässt....)
[quote]
Zumindest kennst Du die möglichen Fehlerquellen, diese aber von vorn herein nicht zuzulassen gehört zu einer guten Software. Weiterhin unterscheiden sich darin auch die Entwickler von Software, ein guter Programmierer berücksichtigt schon bei der entwicklung der SW solche Dinge.
[/quote]
Sorry - mein Dozent hätte an dieser Stelle wörtlich gesagt: Du Klug###er! Du bist so intelligent - bitte, lasse mich an deiner Weisheit teilhaben. Ich sage jetzt mal so: Ok, schenken wir uns den ganzen Test - es gehört zu einer guten Software und einem guten Programmierer das er keine Fehler macht. Keine Fehler -> Kein Test nötig... Dummerweise passieren Fehler - und somit macht man auch solche Tests. DAS ist der Hintergrund. Aber mit dieser Aussage bestätigst du meine erste Aussage: Niemand gibt gern zu das er fehler macht - also braucht man das auch nicht zu testen...
Und ganz nebenbei: Ein guter Programmierer berücksichtigt das schon bei der Entwicklung? Gut - dann kann dein guter Programmierer also aus dem Kopf sämtliche Compiler aufzählen? Denn der Zahlenbereich ist idR. durch den Compiler vorgegeben. Und er kennt auch alle Bugs die ein OS und ggf. sogar die Hardware (P4-Div/0-Bug!) mitbringt - und umschifft die ganz automatisch, ja? Achso - und Rundungsfehler gibts auch nicht (nimm dir mal nen billigen Taschenrechner und rechne die 2 Millionste Wurzel aus 0,2 hoch 2 Millionen... Oft bekommst du hier z.B. das Ergebnis "0". Dummerweise ist die richtige Lösung 0,2 - schade eigentlich... Naja, deinen Taschenrechner haben eben nicht so perfekte Entwickler wie du gebaut...
[quote]
Und dann gibt es noch die Qualitätssicherung, ja die gibt es nicht nur in der Autofabrik, auch in einer Softwarefirma. Die ist dafür da, die Entwicklungen auf Herz und Nieren bis zum Erbrechen zu testen.
[/Quote]
Kluges Kerlchen! Und - was war meine ERSTE Aussage: Man testet keine eigene Software. Na - dämmert dir was? Ob es jetzt die Abteilung QS ist - oder der Programmierer aus dem anderem Team ist dann ne Frage wie groß die Firma ist...
[quote]
über diese Tests bekommt mit Sicherheit kein Kunde ein Protokoll, weil die der eigenen Sicherheit dienen und der Softwarefirma das gute Gefühl geben sollen ein gutes Produkt zu verkaufen.
[/quote]
Ah ja - damit der Geschäftsführer ruhig schläft packt man diese Doku also schön in den Safe? Hmm - ok, sicherlich gibt es das auch. Aber moment - wir reden doch "von der Entwicklung von Software für Großunternehmen oder Behörden.". Nun - das ist dann mit großer Sicherheit keine Software von der Stange - sondern Software für einen speziellen Kunden. Und da gibst du dem Kunden KEINE Doku welche Fälle du getestet hast? Kluge Idee - nur das du diese Software nicht durch die Abnahme durch den Kunden bekommen wirst. Siehe z.B. V-Modell (XT) - hier findest du bereits bei der Anforderungsdefinition auch gleichzeitig gewisse Testfälle spezifiziert. Dasselbe findest du auf den Stufen darunter - und all das möchtest du den Kunden nicht geben? Ganz klasse - dann setzt der sich also hin und testet das nochmal? Oder wie stellst du dir das vor? Und was glaubst du wie du das Abnahme-Protokoll (grad bei Software für Großunternehmen und Behörden) dann Unterschrieben bekommst? Meinst du wirklich du gehst zu Daimler in die EDV: Leute, ihr wolltet nen Programm X haben... Hier, geh mal auf euren Zentral-Server und führe die Setup aus - wir testen denn mal wie das hier läuft.... Mag sein das ich da etwas pessimistisch bin - und ggf. mögen die Admins hier im Forum das jetzt auch gerne Korregieren - aber ich glaube nicht das ein großunternehmen das so locker macht... Da findest du dann nämlich Test-Netze in denen die erst rumprobieren - und selbst da ist idR. dann schon erforderlich das der Programmierer bzw. die Entwicklungsfirma denen was gibt das die sicher sein können das es nicht gleich deren ganzes System abschießt...
[quote]
Leider sieht man immer wieder mal, dass Administratoren der Bezug zum realen Leben oder zum Kunden fehlt. Das scheint bei Dir der Fall zu sein.
[/quote]
Nun - wenn du das sagst... Ich denke ich konnte dir auch ausführliche Begründungen für meine Aussagen geben.
nun, ich habe keinen Bock auf jede einzelne aussage von dir zu antworten, aber du scheinst es nicht verstehen zu wollen.
selbst wenn du auf deiner uni mal was von softwareentwicklung gehört hast, ist das nur die theorie und bedeutet auch nicht, dass man was davon versteht und mitdiskutieren sollte. deine argumente sind leider falsch, da du die falschen schlüsse ziehst.
bleib du am besten bei deinen adminthemen und diskutiere da mit.
nur noch mal zum abschluss.
das testen von software fängt beim testen des eigenen quellcode an. hier gibt es in abhängigkeit von der entwicklungsumgebung unterschiedliche möglichkeiten das schon zu automatisieren. danach wird das programm an die qs zum testen gegeben
selbst wenn du auf deiner uni mal was von softwareentwicklung gehört hast, ist das nur die theorie und bedeutet auch nicht, dass man was davon versteht und mitdiskutieren sollte. deine argumente sind leider falsch, da du die falschen schlüsse ziehst.
bleib du am besten bei deinen adminthemen und diskutiere da mit.
nur noch mal zum abschluss.
das testen von software fängt beim testen des eigenen quellcode an. hier gibt es in abhängigkeit von der entwicklungsumgebung unterschiedliche möglichkeiten das schon zu automatisieren. danach wird das programm an die qs zum testen gegeben
Nunja - dann gehe ich mal davon aus das du deine Weisheit nicht teilen willst und/oder kannst. Nur solltest du dann das Wort "diskutieren" nochmal im Lexikon nachschlagen - und gleich danach das Wort "Argument"... Falls dann noch etwas Zeit ist dann lies dir meine Aussagen nochmal genau durch -> und überlege mal was die ggf. bedeuten könnten.
Achso - und nur nebenbei: Kritikfähigkeit ist ebenfalls eine Stärke - nur scheinbar nicht deine...
Achso - und nur nebenbei: Kritikfähigkeit ist ebenfalls eine Stärke - nur scheinbar nicht deine...
Zitat von @maretz:
Nun - wenn du das sagst... Ich denke ich konnte dir auch ausführliche Begründungen für meine Aussagen geben.
Nun - wenn du das sagst... Ich denke ich konnte dir auch ausführliche Begründungen für meine Aussagen geben.
*Usprüngliches Posting gelöscht* nachdem ich fertig gelesen habe.
Im Großen und Ganzen zutreffend. Tests die man selbst macht sind aber trotzdem möglich. Du musst nur ein Rollenverständnis haben. Dann geht das.
Programmieren: 4 Monate. 1 Woche Pause. Code darf nicht mehr angesehen werden. Es wird jetzt versucht, das Programm BEWUSST zu sabotieren und jede Sabotage reproduzierbar zu machen.
Nicht optimal, aber auch nicht unmöglich. Selbst anlügen ist halt nicht drinnen.
