Wie testet ihr?

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
12 Beiträge • Seite 1 von 1
12 Beiträge Seite 1 von 1

Wie testet ihr?

Beitrag von SaskuAc (Specialist / 321 / 37 / 43 ) »
Hi,

einfach mal eine Allgemeine Fragen an euch, wie testet ihr eigentlich?
Nutzt ihr SAP Testmanagement? Nutzt ihr ABAP Unit Tests oder macht ihr "nur" ( denn selbst das machen einige nicht .. ) manuelle integrationstests? Automatisiert ihr tests mit ECATT, CBTA, o. ä. ?

Ich persönlich bin ein absoluter Fan von ABAP Unit Tests, einfach weil sich diese super einfach zu implementieren sind und ich dadurch eine sehr schnelle Übersicht bekomme ob meine Methode, mein FuBa, mein was weiß ich funktioniert. Manuelle Tests gehen mir nämlich seit einiger Zeit gegen den Strich, weshalb ich dazu übergegangen bin alles was möglich ist mit Unit Tests zu implementieren. Außerdem kann man diese dann super einfach verwenden um auf Fehlersuche zu gehen.

Und ich empfinde, dass man Unit Tests ebenfalls zur Dokumentation verwenden kann ohne sich große Gedanken zu machen.

Naja, wie gesagt, wie testet ihr eigentlich?
Grüße

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Wie testet ihr?

Beitrag von jocoder (Specialist / 338 / 3 / 101 ) »
Unit-Tests verwenden wir zum testen bei allen Neuentwicklungen und wenn möglich bei Reparaturen.
Wenn man testbaren Code schreibt, auf eine entsprechende Test-Abdeckung und eine ausreichende Prüfung achtet, können hier 99% aller Bugs vor dem GoLive gefunden werden.

Testbaren Code sollte man meiner Meinung nach in 3 Schichten trennen:
1. Datenbankschicht (Abfragen, änderte Zugriffe)
2. eigentliche Logik
3. User-Interface

Methoden, Funktionsbausteine noch kurz halten dann hat ein Unit-Test auch eine hohe Aussagefähigkeit.

Um Abfragen in der Datenbankschicht zu testen, verwende ich immer ein Testdatencontainer.
http://www.tricktresor.de/blog/auf-ecat ... -zugreifen
https://github.com/sbcgua/mockup_loader
Dann brauchen große Tabellen, die von einer Datenbankabfrage erwartet werden, nicht mehr hart codiert werden.

Re: Wie testet ihr?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Hach, wenn ich das Posting von jocoder lese, geht mir einer ab, ehrlich. Sowas gibt es viel zu selten.

Standarddialog:
Ralf: "Haben Sie das getestet?"
X: "Klar!"
Ralf: "Das glaube ich Ihnen nicht - Sie haben es ausprobiert, ein Test ist etwas anderes" ;)


Zum Glück arbeite ich derzeit in einem Projekt, das der Validierungspflicht unterliegt (Arzneimittelindustrie), so dass der Kunde verpflichtet ist, jeden einzelnen Prozess nach einer Testmatrix zu testen und schriftlich abzunehmen, sonst dürfen sie ihn nicht verwenden.

Wir unterstützen den Kunden hierbei, indem wir die üblichen Geschäftsprozesse mit erweiterten Geschäftsobjekten durchlaufen, um diese Tests zu automatisieren (es handelt sich um eine komplette Eigenentwicklung, darum geht das und darum brauchen wir ECATT & Co nicht). Damit machen wir alle Integrationstests. Zum Beispiel testen wir das BRF+ Regelwerk mit einer Excel-Testmatrix, die jede mögliche Variation von Eingabewerten enthält und dem erwarteten Ergebnis gegenüberstellt. Das lesen wir in ein Testprogramm ein, das alle diese Inputs durch das Regelwerk jagt und Soll und Ist miteinander vergleicht. Also Test des gesamten Regelwerks mit drei Mausklicks. Macht das jemand kaputt, weiß man das sofort bzw. weiß zudem, in welcher Ecke man suchen soll. So müssen die das BRF+ nicht händisch durchtesten, was ein irrer Aufwand wäre, und das ist ja nur ein ganz kleiner Teil der Applikation. Und so kann man dann jederzeit nachsehen "wie lief denn der Testlauf vom 5.1.18 um 18 Uhr?".

Einen Unit Test mache ich in aller Regel schon für den Entwicklertest, um also überhaupt exemplarisch die Funktion ermitteln zu können. Der ist dann kein Unit Test der reinen Lehre nach. Aber die mache ich eben auch, wenn der Kunde sagt "keine Unit-Tests, dafür haben wir kein Geld / keine Zeit / ...."

Darüber hinaus schreibe ich dann auch "richtige" Unit-Tests, die etwas aufwendiger sind, aber dann eben auch richtig testen. Teilweise schreibe ich auch erweiterte Unit-Test, um das Zusammenspiel von Objekten zu testen (was dann auch wieder der reinen Lehre widerspricht). Im Grunde genommen muss man jede Anwendung ohne Zuhilfenahme der GUI automatisiert testen können.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Wie testet ihr?

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
ralf.wenzel hat geschrieben:Im Grunde genommen muss man jede Anwendung ohne Zuhilfenahme der GUI automatisiert testen können.
Die GUI gehört meiner Meinung zur Anwendung.

Wie willst du sicherstellen, dass bestimmte Objekte/ Daten, die in einer Funktion als richtig geunittestet wurden, auch richtig angezeigt werden?
- Tree-Darstellung (Knoten, Items, Farbgebung, Interaktive Objekte [Links, Buttons, Checkboxes])
- Grid (Farbdarstellung, Sortierung, Filter, etc)
- HTML-Control
- Splitter-Container
Wie willst du Drag-and-Drop testen?
Wie willst du das Verhalten der Controls nach Interaktionen testen (Funktionscode, Doppelklick, Linkclick)?

Re: Wie testet ihr?

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Das sind übrigens die Gründe, weswegen ich tatsächlich sehr wenig unitteste.
Die Unit-Tests machen nur einen Bruchteil der Anwendung aus.

Der größte Teil, und auch der Teil, in dem die meisten Fehler auftauchen können, ist die GUI-Programmierung:
- Erstellung Container
- Instanziierung Controls
- Interaktionen
- Ein-/ ausblenden von Elementen
- Bildsteuerung
- Auswirkungen Feldkatalog

Re: Wie testet ihr?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
ewx hat geschrieben:
ralf.wenzel hat geschrieben:Im Grunde genommen muss man jede Anwendung ohne Zuhilfenahme der GUI automatisiert testen können.
Die GUI gehört meiner Meinung zur Anwendung.
Jein. Die GUI selbst hat (im Idealfall) keine wirklichen Funktionen. Leider vermischt sich das im SAP schnell, wenn man nicht aufpasst. Wie man das sauber trennt, wird Leuten oft erst dann klar, wenn sie UI5-Anwendungen schreiben, weil die GUI eben außerhalb des SAP liegt. Und wir schreiben unsere SAPGUI-Sachen so, als wären sie außerhalb des SAP, um sie jederzeit tauschen zu können.

Wenn man das richtig designt, dann kann man durchaus alle Funktionen testen, weil die eben in der Applikationsschicht liegen. Und wenn ich die Applikationsschicht komplett testen kann, habe ich 80% der Anwendung getestet (wenn man von meiner Warte - der Modulentwicklung - ausgeht). Natürlich kann ich nicht unit-testen, was angezeigt wird, aber ich kann unit-testen, was der Anzeigeroutine übergeben wird. Dazu muss man die natürlich gescheit kapseln. So wie die Datenbankschicht: Die kann ich schlecht Unit-testen, weil ich dazu Datenbankänderungen vornehmen muss. Aber ich kann testen, was der Methode übergeben wird. Wenn das stimmt, fehlt nur noch der Datenbankzugriff an sich.

Klar ist: Wenn ich einen Report schreibe, der 300 Sätze aus der DB liest und anzeigt, dann komme ich mit Unit-Tests nicht weit. Wenn ich aber eine komplexe Anwendung habe, die ganze Geschäftsprozesse unter der GUI abbildet, gewinne ich eine ganze Menge, wenn ich die Funktion an sich prüfen kann.

Was du meinst, sind Applikationstests / Integrationstests, die man übrigens auch automatisiert machen kann (dazu gibt es andere Tools).

Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Wie testet ihr?

Beitrag von SaskuAc (Specialist / 321 / 37 / 43 ) »
Da muss ich Ralf recht geben. Es ist einfach eine Frage des Designs.

Wenn man die Anwendung so konzipiert, dass die Logik, Datenbankzugriffe und Oberfläche ordentlich von einander getrennt sind, dann sind Unit Tests die erste Wahl.

Unit tests sind ja überhaupt nicht dazu gedacht komplett die Anwendung zu testen, sondern die einzelnen Einheiten einer Anwendung. Es geht tatsächlich um die einzelnen Parameter, was kommt unter bestimmten eingaben aus der Methode raus.

Was ich aktuell ganz spannend finde - für ABAP 7.5. gibt es die Änderung bei Unit Tests, dass man Injections schreiben kann, heißt der Quelltext Part wird für Unit tests durch einen anderen ersetzt. Ob sich das in der Praxis bewährt muss ich mir erst anschauen, sitze hier leider aktuell auf nem 7.4 System, wobei wir dieses Jahr noch auf 7.5 gehen wollen ^-^

Durch diese Änderungen kann das Verhalten einer Methode dennoch gut getestet werden, selbst wenn der DB-Zugriff nicht ordentlich gekapselt wurde.

Re: Wie testet ihr?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
SaskuAc hat geschrieben:Was ich aktuell ganz spannend finde - für ABAP 7.5. gibt es die Änderung bei Unit Tests, dass man Injections schreiben kann, heißt der Quelltext Part wird für Unit tests durch einen anderen ersetzt. (...) Durch diese Änderungen kann das Verhalten einer Methode dennoch gut getestet werden, selbst wenn der DB-Zugriff nicht ordentlich gekapselt wurde.
Das finde ich sehr kritisch, weil das die Lesbarkeit des Originalcodings negativ beeinflusst und die "Schlamperei" beim Kapseln unterstützt.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Wie testet ihr?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Da hier die Test-Experten ja anwesend zu sein scheinen: Wie testet ihr denn z.B. folgende Klasse:
Klasse: zcl_longtexts
Nur statische Methoden und evtl. ein paar statische Buffertabellen.
Die Methoden sind alle nach dem selben Schema aufgebaut: Man gebe einen Input - z.B. VKORG, Materialnummer, (Kostenrechnungskreis+Profitcenter), Partnerrollenkürzel (so was wie AG, RE etc ), und heraus kommt als Returningparameter der Langtext. Pro Input gibt es eine zugehörige Methode z.B. Longtext_matnr, Longtext_prctr, longtext_parvw, .... wobei - wenn ich nett bin - ich bei fehlendem Langtext in der Anmeldesprache irgendwelche Fallbacks verwende.

Wie gesagt - die Methoden sind alle recht einfach gestrickt. Greifen alle auf die DB zu um die Daten zu lesen. Wenn's nicht klappt ist es eigentlich nicht schimm - dann gibt es halt eine leere Rückgabe.
Getestet habe ich das zwar ( Ralf würde sagen "ausprobiert" ) und es ist natürlich auch schon seit Jahren live.
Würdet ihr hierfür tatsächlich Unit-Tests schreiben. Immer in Hinblick darauf, dass die Wahrscheinlichkeit, dass sich an dem jeweiligen Coding in Zukunft noch groß was ändern wird eher gering ist und es sowieso eine ständige Qualitätskontrolle gibt getreu nach dem Motto:
8054.image_thumb_35C6E986.jpg
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wie testet ihr?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Da ist schon das Konzept falsch ;)

Eine Methode in der Applikationsschicht, die auf die DB zugreift, macht einen Fehler. Sie fordert von der Persistenz die Daten an (damit egal ist, welche Art von Persistenz dahinter steht). Für den Unit-Test schreibt man ein Mockup für die Persistenzklasse, so kann man wunderbar Rückgaben der DB simulieren.

Natürlich ist die Frage berechtigt, ob man so einen Kleinkram unit-testen soll, aber gerade weil die Methode so klein ist, ist auch ein Test schnell gebaut.

Mein Ausweg:

Ehe ich mit F8 ausprobiere, schreibe ich lieber schnell zumindest einen Entwicklertest, in dem hart Eingabewerte stehen und hart abgefragt wird, ob das Ergebnis stimmt (hart = per Literal), ohne Mockup und alles Gedöns. Das dauert nicht länger als ein F8-Test (wo man ja jedesmal Daten eingeben muss) und ich erhalte die Gewissheit, dass ich immer wieder denselben Test mache und immer wieder dasselbe Ergebnis erhalte. Auch wenn der Test maschinenabhängig ist (weil ich auf Daten der konkreten Maschine referenziere). So habe ich zumindest mehr als nichts.

Ich habe sehr oft erlebt, dass ehemals kleine Programme sich erweitern auf eine x-fache Größe mit x-fachem Funktionsumfang. Und auch bei kleinen Änderungen hat man schnell einen Fehler eingebaut, da hilft es, wenn man die Klasse per Knopfdruck testen kann.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Wie testet ihr?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
ralf.wenzel hat geschrieben:Ehe ich mit F8 ausprobiere,
Genau das ist die Crux - ich schreibe die Methode ja, weil ich einen Anwendungsfall habe - und da sehe ich genau, ob es klappt oder nicht bzw. die Anwender sehen es beim Test vor dem Go-Live. Und meine Frage ist ja: Ein Unit-Test macht m.E. nur Sinn, wenn ich glaube, dass jemand anderes an der Methode rumfummeln wird und sie kaputt machen könnte, oder wenn ich glaube, dass SAP intern etwas dermaßen umstellt, dass der grundsätzliche Ansatz der Methode versagt.
ralf.wenzel hat geschrieben:Eine Methode in der Applikationsschicht, die auf die DB zugreift, macht einen Fehler.
Aufwand/Nutzen! Und wenn deine Aussage eine grundsätzliche Wahrheit wäre, wären >90% der SAP-Programme, die ich kenne fehlerhaft...
Andererseits...*grübel*... Wenn ich den DB-Zugriff in einen FuBa verlagere und aus der Methode den FuBa aufrufe, dann greift nicht mehr die Methode auf die DB zu sondern der FB. Und für FB gibt es ja vielleicht nicht solche Aussagen *lach*
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wie testet ihr?

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Ja, was die Regeln der Softwareentwicklung angeht, ist ein großer Teil der SAP-Programme „falsch“, das weiß man dort auch. Darum ist es auch so schwierig, von der SAPGUI runterzukommen, weil es solche Anweisungen wie „MESSAGE“ gibt, die aus den Tiefen der Applikation etwas tut, was nur die SAPGUI kann. Keine SAPGUI, kein „MESSAGE“. Eigentlich gehört der Fehler Schicht für Schicht „hochgemeldet“, damit die GUI-Schicht entscheidet, was sie mit dem Fehler macht bzw. wie sie ihn darstellt.

Das ist mehr Aufwand, aber der Austausch der GUI wird ja so erst möglich! In anderen Bereichen der Industrie auch viel Aufwand erzeugt, aber nicht in Frage gestellt. Da muss man sich nur mal Bauvorschriften ansehen.

Bei uns im Projekt ist es VERBOTEN, die Schichten zu durchbrechen (so ist MESSAGE nur in der UI-Schicht erlaubt). Stell dir eine Firma vor, die Kühlschränke oder Heizungen baut. Wenn Vorgabe ist „leg ein rotes Kabel von da nach da mit stets rechtwinkligem Verlauf“, wird man kein blaues nehmen, weil rot gerade aus ist oder es diagonal verlegen, weil es zu kurz ist. Auch wenn er ins Lager laufen und neues holen muss.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Seite 1 von 1

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140