Testen einer GUI Applikaiton

[MarcelF (Gast)]

Guten morgen,

ich habe da mal eine Frage, die in Richtung Test geht. Wie testet ihr 
eure GUI Anwendungen?
Klar, dass einfachste und der erste Test ist das Bedienen der GUI. Gibt 
es hier denn auch automatische Tests? Ich habe mal gesehen, dass Firmen 
ihre GUIs mittels einer Kamera testen. Das ist natürlich ein gewaltiger 
Aufriss und soweit will und kann ich das nicht treiben.
Die GUI wird mit Qt entwickelt und läuft auf einem Linux-basierten 
Industriedisplay.

Gruß Marcel

[Kaj (Gast)]

Was genau willst du testen, die GUI oder die Applikation dahinter?

Wenn du die GUI und die Applikation trennst und ueber z.B. Sockets 
kommunizieren laesst, dann kannst du den Test fuer die Applikation 
scripten und automatisieren.

Fuer die GUI,... naja, da musst du dir halt was einfallen lassen. Statt 
einer Kamera koennte man auch Screenshots machen, kommt am ende aber 
aufs selbe raus.

[Oliver S. (oliverso)]

http://doc.qt.io/qt-5/qttestlib-tutorial3-example.html

Oliver

[aGast (Gast)]

Gib es ganz einfach jemanden, der mit der Materie gar nichts zu tun hat 
und lass ihn damit rumspielen. Da kommen dann die tollsten Fehler raus.

[Michael B. (laberkopp)]

MarcelF schrieb:
> Die GUI wird mit Qt entwickelt und läuft auf einem Linux-basierten
> Industriedisplay.

Für Windows: WinRunner bzw. der aktuelle Nachfolger von HP UFT.
Ob das auch unter Linux läuft ? Keine Ahnung, durch den ALM Software 
Verhau von HP blickt man nicht durch.

[Borislav B. (boris_b)]

Der Richtige (TM) Ansatz wäre in diesem Fall:

Wähle eine geeignete Architektur (z.B. MVVM). Dann ist die GUI im 
Idealfall vollständig logikfrei. Damit muss sie auch nicht getestet 
werden (*).
Der Rest der Applikation (insbesondere das ViewModel) kann dann sehr 
einfach automatisiert per UnitTests abgetestet werden.

*) Unter der Annahme, dass das verwendete GUI Framework ausreichend 
getestet ist. Das dürfte bei den meisten gängigen (WPF, WinForms, QT, 
Swing etc.) der fall sein.

[Mike (Gast)]

aGast schrieb:
> Gib es ganz einfach jemanden, der mit der Materie gar nichts zu tun hat
> und lass ihn damit rumspielen. Da kommen dann die tollsten Fehler raus.

Das mache ich schon, ich zeige das immer mal wieder Kommilitonen.


Kaj schrieb:
> Was genau willst du testen, die GUI oder die Applikation dahinter?

Sowohl als auch. Das Display kommuniziert mit verschiedenen Steuerung 
über CAN, es laufen auch mehrere Protokolle. Daher möchte ich testen, ob 
die richtigen Bilder gezeichnet werden und ob die Daten valide sind, die 
gesendet werden. Denn gerade kommt es immer mal wieder vor, dass wenn 
nicht valide Daten gesendet werden das Protokoll auf Steuerungsseite 
abgebrochen wird.

[Dimi (Gast)]

Borislav B. schrieb:
> Dann ist die GUI im
> Idealfall vollständig logikfrei.
Selbst wenn gibt es jede Menge Fehlerquellen - z.B. Data Binding im WPF. 
ViewModel OK, UI OK und die Applikation läuft trotzdem nicht.

Für WinForms und WPF habe ich Ranorex schon in Aktion gesehen. Der soll 
auch QT unterstützen...

[Pandur S. (jetztnicht)]

>> Kaj schrieb:
>> Was genau willst du testen, die GUI oder die Applikation dahinter?
>
>Sowohl als auch.

Bedeutet auftrenne und aufzeichnen/viusalisieren was das GUI and die 
Aussenwelt sendet. Dann die Aussenwelt simulieren und schauen, was das 
GUI damit macht.

Dann jedes Device einzeln vornehmen, und per anderer vereinfacher 
Software anstueren und visualisieren, aufzeichnen.

[Testosteronomat (Gast)]

>. Wie testet ihr
> eure GUI Anwendungen?
> Klar, dass einfachste und der erste Test ist das Bedienen der GUI. Gibt
> es hier denn auch automatische Tests?

Ich sorge dafür dass die Architektur des "GUI"-Teils folgende Merkmale 
hat:
- ausnahmslos alle UI-Elemente sind per eindeutige ID inventarisiert;
- ein Traceing/Logging-Framework/Lib nimmt zentral auf, was jedes 
Element (nicht nur vom UI!) nach optionalem einschalten erzählen will 
(immer mit Absendezeitstempel);
- alle (relevanten) UI-Elemente können zusätzlich eine Meldung 
empfangen, welche dasselbe bewirkt wie eine Betätigung durch den Mensch;
- ich implementieren eine (vereinfachte, textuelle) Schnittstelle um 
solche "synthetische Betätigungsnachrichten" einspeisen zu können.

Nun ist es möglich "Betätigungsabläufe" zu Scripten und deren 
Auswirkungen (auch im Log) zu bewerten.

[Ordner (Gast)]

MarcelF schrieb:
>  Wie testet ihr
> eure GUI Anwendungen?

Mouserecorder für Regression tests bspw: 
http://www.chip.de/downloads/Mouse-Recorder-Premium_77202175.html

[MarcelF (Gast)]

ok, umso mehr ich hier lese, umso mehr befürchte ich, dass das komplette 
Projekt nicht wirkklich gut aufgebaut ist. Ich habe schon versucht 
Datenverwaltung und UI zu trennen. Das ist mir aber nicht immer 
gelungen.
Könnt ihr mir Bücher empfehlen, die sich auf diese Thematik beziehen? 
Also wie man ein UI aufbaut, worauf man achten sollte, damit man z.B. 
Tests einfach durchführen kann.

[MarcelF (Gast)]

Oliver S. schrieb:
> http://doc.qt.io/qt-5/qttestlib-tutorial3-example.html
>
> Oliver

So ich habe mir nun mal Qtest angeschaut, aber da fehlt mir noch ein 
Gedankenschritt.

Folgende Pseudoklasse

class Foo : public QWidget
{
Q_OBJECT

private:
quint16 u16_Add( quint16 u16_Number1, quint16 u16_Number2 );

};

In der foo.cpp steht dann folgendes:

quint16 Foo::u16_Add( quint16 u16_Number1, quint16 u16_Number2 )
{
return u16_Number1 + u16_Number2;
}

Nur wie kann ich diese Memberfuntktion testen? Ich verstehe den Aufbau 
bzw das Handling nicht so ganz

[D. I. (Gast)]

Ranorex ist eins der verbreitesten Tools dafür. Nicht ganz billig, aber 
dafür erfüllt es den Zweck. Ist hier auch im Einsatz.

https://www.ranorex.de/technologie-support.html

[MarcelF (Gast)]

D. I. schrieb:
> Ranorex ist eins der verbreitesten Tools dafür. Nicht ganz billig, aber
> dafür erfüllt es den Zweck. Ist hier auch im Einsatz.

Danke für den Hinweis, aber das sprengt etwas unseren Preisrahmen.
Daher werde ich mich mal nächer mit QTest beschäftigen

[Dumdi D. (dumdidum)]

MarcelF schrieb:
> Danke für den Hinweis, aber das sprengt etwas unseren Preisrahmen.

QT kostet doch 12000eur pro Jahr und Entwickler? Da scheint mir die 
Software aus dem Hinweis doch um Laengen guenstiger.
(es ist uebrigens nicht zuaessig erst unter lgpl zu entwickeln und dann 
eine Lizenz zu mieten)

[physiker (Gast)]

Dumdi D. schrieb:
> QT kostet doch 12000eur pro Jahr und Entwickler? Da scheint mir die
> Software aus dem Hinweis doch um Laengen guenstiger.
> (es ist uebrigens nicht zuaessig erst unter lgpl zu entwickeln und dann
> eine Lizenz zu mieten)

Vielleicht erfüllen sie auch einfach die LPGL Bedingungen? Kein Ändern 
der Library oder mitliefern des entsprechenden Quellcodes, dynamisches 
linken und bei einem embedded Device wie einem Display die Möglichkeit 
die Libraries auszutauschen. Die Anforderungen sind doch überschaubar.

[hink (Gast)]

Dumdi D. schrieb:
> MarcelF schrieb:
>> Danke für den Hinweis, aber das sprengt etwas unseren Preisrahmen.
> QT kostet doch 12000eur pro Jahr und Entwickler?
Nicht wirklich.

https://www.qt.io/licensing-comparison/
https://www.qt.io/buy-product/

@TO
Evtl (für ganz einfache Tests) wäre auch xdotool etwas für dich. Hier 
kannst du Mausklicks und Tasten-Events auslösen (allerdings nicht 
aufnehmen).

Dumdi D. schrieb:
> (es ist uebrigens nicht zuaessig erst unter lgpl zu entwickeln und dann
> eine Lizenz zu mieten)
Ob das so rechtlich in Ordnung ist... vielleicht bei 
Business-to-Business oder in den USA.
Wobei Qt auch sein Geld wert ist.

[StinkyWinky (Gast)]

MarcelF schrieb:
> Nur wie kann ich diese Memberfuntktion testen?

Wir hatten das damals ganz simpel mit

#define private public

im Test-Code gelöst.

[Mark B. (markbrandis)]

MarcelF schrieb:
> In der foo.cpp steht dann folgendes:
>

> quint16 Foo::u16_Add( quint16 u16_Number1, quint16 u16_Number2 )
> {
> return u16_Number1 + u16_Number2;
> }
>

>
> Nur wie kann ich diese Memberfuntktion testen? Ich verstehe den Aufbau
> bzw das Handling nicht so ganz

Indem Du diese Methode mit verschiedenen Werten aufrufst und Dir den 
Rückgabewert anschaust. Für Letzteres ist eventuell zusätzlicher 
Debug-Code nötig. Ohnehin wäre das auf der Ebene der Unit-Tests.

[MarcelF (Gast)]

Mark B. schrieb:
> Indem Du diese Methode mit verschiedenen Werten aufrufst und Dir den
> Rückgabewert anschaust. Für Letzteres ist eventuell zusätzlicher
> Debug-Code nötig. Ohnehin wäre das auf der Ebene der Unit-Tests.

Das ist mir schon klar. Es ging halt darum, wie man Memberfunktionen 
testet.
Generell weiss ich nicht genau, wie man Tests aufbaut. Jetzt mal ganz 
unabhängig von Qt.

Ich habe ein Projekt, dort ist ein Modul Filter vorhanden ( filter.cpp 
und filter.h ). Jetzt schreibe ich mit ein Testmodul test_filter.cpp. 
Ist es sinnvoll dieses Testmodul in mein Projekt zu integrieren ( genau 
wie man Testframework ) und dann beispielsweise über Debug den Test 
laufen zu lassen und über Release erstelle ich dann mein Hex und 
sonstige Sachen. Oder packt man das alles in ein Dummy Projekt?

[Mark B. (markbrandis)]

In C und C++ hält Dich niemand davon ab, zusätzlichen Testcode mittels

#ifdef DEBUG_CODE 

/* Test code here */ 

#endif

(oder so ähnlich, der Name ist nur ein Beispiel) einzubinden. Eventuell 
stellt sich die Frage, wie unübersichtlich das Ganze dadurch wird.

Aber eigentlich solltest Du das nicht uns fragen, sondern es sollte bei 
Deinem Arbeitgeber Richtlinien dafür geben, wie zu testen ist. Oder ist 
das ein privates Projekt?

[MarcelF (Gast)]

Mark B. schrieb:
> Aber eigentlich solltest Du das nicht uns fragen, sondern es sollte bei
> Deinem Arbeitgeber Richtlinien dafür geben, wie zu testen ist. Oder ist
> das ein privates Projekt?

Es ist ein Projekt an der Hochschule. Daher wäre es für mich sehr 
einfach, alles in ein Projekt zu hauen. Ist natürlich nicht wirkich 
"schön". Daher die Frage, wie man es "schön" macht bzw wie das im 
professionellen Umfeld gemacht wird.