Die nächste Generation des Unit Testing

© Automated Software Testing GmbH www.devmate.software
Daniel Lehner
Researcher
- 1 -

Inhalt
▪ Wo liegen die Pain Points im Unit Testing?
▪ Wie können wir diese reduzieren?
▪ Wie können wir diese NICHT reduzieren?
- 2 -

Wie entstehen Unit Tests?
- 3 -
Next-Generation Unit Testing
Code
Unit-Test
Code
Anforderungen
Test-Erstellung
Test-Erstellung
Code-Erstellung

Unit Test Erstellung
▪ Welche Tests sollten erstellt werden,
um dies funktional voll zu testen?
▪ Jede (Einzel-)Bedingung muss für sich
getestet werden (4 Normal-Testfälle)
▪ Grenzwerte (oben/unten) der beiden
Bedingungen (weitere 4 Testfälle)
▪ Fehlertests außerhalb der Grenzen oben
und unten sowie innerhalb der Grenzen
mit Fehlerwerten (weitere 6 Testfälle)
→ mind. 14 Unit-Tests erforderlich für gute funktionale Testabdeckung!
- 4 -
A > 10
& B < 5
T1 T2 T3 T4
A > 10 1 1 0 0
B < 5 1 0 1 0

Manueller
Aufwand
Pain Point Test-Erstellung
- 5 -
Code
Unit-Test
Code
Anforderungen
Test-Erstellung
Test-Erstellung
Code-Erstellung
Manueller
Aufwand

Was ist eigentlich ein Unit Test?
Input
{a=1, b=1}
{a=100, b=1}
{a=1, b=100}
…
Output
0.0
0.5
10.3
…
double doSomething(int a, int b)
Welche Inputs sind noch nötig? Welcher Output soll für geg.
Input erwartet werden?

Automatisierte Input-Generierung
▪ Zufällige Wahl von Inputs auf Basis der Datentypen
▪ Funktioniert gut für Booleans
▪ Große Menge an Inputs für Zahlen und Texte
▪ Unmöglich für Fließzahlen
▪ Inputs auf Basis von Code(-Verzweigungen)

Ein Beispiel
Unit under test contains many bugs:
no input checks, division by 0, …
/**
* Calculates the average speed.
*/
public static double getAvgSpeed(LocalDateTime start, LocalDateTime end, double distance) {
Duration duration = Duration.between(start, end);
double hours = duration.getSeconds() / 60 / 60;
return distance / hours;
}

KI-basierte Erstellung in der Praxis
AI erstellt nur 1 Testfall, der
überhaupt keinen Fehler findet
aber 100% des Codes abdeckt
Die erstellten Testdaten haben überhaupt keine
fachliche Relevanz, sondern verwirren den Leser eher
(Warum wurden genau dieser Wert gewählt?)

Conclusio
▪ Test-Generierung erfordert Datenbasis
▪ Muss händisch definiert warden
▪ Tradeoff Aufwand VS Qualität
▪ Lösung: Low-Code Definition von Testfällen

Low-Code Input-Definition
Source: https://www.automated-software-testing.com/
Händische Definition
sinnvoller Input-Daten
Äquivalenz
Klasse

Tool combines equivalence
classes and representatives to
test cases.
Parameter
Test

Collapsed view
looks like test table
in Excel.

Vorschlag von Inputs
Source: https://www.devmate.software/
Equivlaence-Class & Data
Prediction Module

Was ist eigentlich ein Unit Test?
Input
{a=1, b=1}
{a=100, b=1}
{a=1, b=100}
…
Output
0.0
0.5
10.3
…
double doSomething(int a, int b)
Welche Inputs sind noch nötig? Welcher Output soll für geg.
Input erwartet werden?
Lösung:
Low-Code

KI-Basierte Output-Generierung
▪ How it works
▪ Systeme lernen anhand vorgegebener Tests
▪ Wissen wird für Generieung der Tests verwendet
▪ Beispiel Neuronale Netze
▪ Neuronales Netz auf Basis bekannter Input->Output-Kombinationen
▪ Neue Inputs -> Vorhersage von entsprechendem Output
▪ Input = Methoden-Input
▪ Output = Methoden-Output

Beispiel „Lernen von Test-Outputs“
Neuronales Netz für testSomething(a, b)
Wie groß ist hier der Mehrwert auf Methoden-Ebene?
Woher kommen die Test-Daten?
Garbage In -> Garbage Out
Kann man Methoden-übergreifend verallgemeinern?
Input
{a=1, b=1}
{a=100, b=1}
{a=1, b=100}
…
Output
0.0
0.5
10.3
…
New Input
{a=5, b=5}
Calculated
Output
0.3

Conclusio
▪ Lernbasierte Methoden liefern wenig sinnvolle Ergebnisse
▪ Output muss selbst definiert werden
▪ Reduktion des Aufwands durch Low-Code Tooling

Low-Code Output-Definition
Developer defines “Test Oracle”
(expected Values):
- Values
- Exceptions
- Expected Side-Effects

Generierter Test-Code
Tool generates readable and
maintainable unit test code.
Test data set for
positive tests
Test data set for
negative tests
Parameterized test

Manueller
Aufwand
Lösung Test-Erstellung
- 21 -
Code
Unit-Test
Code
Anforderungen
Low-Code
Automatisierung

Validierung von Unit Tests
- 22 -
Code
Unit-Test
Code
Anforderungen
Validierung

Unit Test Ausführung
▪ Viele Testfälle nötig, um sinnvolle Abdeckung von Anforderungen zu erreichen
▪ Rechenbeispiel
▪ Ausführung 1.000 TF, 1 TF = 3 s, 3 commits/tag
▪ Kosten: >5 Stunden = 5.500 € pro Monat
▪ In der Praxis durchaus mehr
▪ #Commits bei agiler Software Entwicklung
▪ Ausführungszeit bei Frontend- oder Hardware-Tests
- 23 -
Test-Validierung

Pain Point Validierung
- 24 -
Code
Unit-Test
Code
Anforderungen
Validierung
Lange
Ausführungszeit

Reduktion und Priorisierung von Testfällen
▪ Erster Ansatz
▪ Ermittlung aller Kombinationen von Testfällen
▪ Berechnung von Ausführungszeit + Coverage pro Kombination
▪ Test-Set mit maximaler Coverage bei minimaler Ausführungszeit
Ausgeführte Testfälle Ausführungszeit Coverage
TF 1 10 s 20 %
TF 2 15 s 20 %
TF 3 5 s 20 %
TF 1 + TF 2 22 s 40 %
TF 1 + TF 3 12 s 20 %
TF 2 + TF 3 17 s 40 %
TF 1 + TF 2 + TF 3 27 s 45 %
Problem 1:
Was ist die beste
Kombination?
Problem 2:
#Kombinationen

Reduktion und Priorisierung von Testfällen
▪ Lösung: Meta-Heuristische Sucherverfahren
(z.B. Genetischer Algorithmus)
▪ Intelligente Kombination von Möglichkeiten
▪ Einführung von Zufall zum Finden globaler Maxima
▪ Mehrere Iterationen
▪ Ausgabe bestes Ergebnis pro Iteration auf Basis vorgegebener
Optimierungskriterien

Beispiel Reduktion/Priorisierung Test-Set
Urspr. Kombinationen
1, 0, 0, 0, 0
0, 1, 0, 0, 0
0, 0, 0, 1, 1
1, 1, 0, 0, 0
0, 1, 0, 1, 1
0, 0, 0, 1, 1
1, 1, 0, 1, 1
0, 1, 0, 1, 1
1, 0, 0, 1, 1
1. Iteration 2. Iteration
5 Testfälle. [1, 0, 0, 0, 0] => nur der erste Testfall wird ausgeführt

Erste Ergebnisse
▪ Testfälle können reduziert werden, bei gleichbleibender Code
Coverage, aber reduzierter Mutation Coverage
▪ Ergebnisse variieren stark pro Package
▪ Abhängig von der Code-Komplexität
▪ Optimierung von Mutation Score aktuell nicht möglich
▪ Keine Test-Basierte Auswertung von Mutation Tools (open-source)
Metrik Initiales
Set
Reduziertes
Set
Unterschied
# Testfälle 246 178 - 28 %
Coverage 57 % 57 % 0 %
Mutation Score - 1 %

Lösung Validierung
- 29 -
Code
Unit-Test
Code
Anforderungen
Genetische
Algorithmen
Validierung

Wie gut sind meine Unit Tests?
- 30 -
Code
Unit-Test
Code
Anforderungen
Abdeckung

Das Problem mit Code Coverage
▪ Welche Unit-Tests werden typischerweise erstellt?
▪ Unit-Test, der einmal links geht und
▪ Unit-Test, der einmal rechts geht
→ 100% Code-Abdeckung ist mit 2 Tests erreicht
und im CI-System ist alles „grün“
▪ Recap: mind. 14 Unit-Tests für gute funktionale Testabdeckung!
▪ Was tun bei Fehlern im Code?
▪ Ist das nicht der Grund, warum wir Tests erstellen?
- 31 -
A > 10
& B < 5

Mutation Scores als Lösung?
▪ Mutation Score
▪ Einfügen von Fehlern in bestehenden Testcode
▪ Wird Fehler von Test Suite erkannt?
▪ % gefundener Fehler = Mutation Score
▪ Aber: Einfügen von Mutanten dauert sehr lange
▪ Gesamte Test Suite muss für jeden Mutanten neu ausgeführt werden
▪ Conclusion
▪ Code Coverage schnell, aber ungenau
▪ Mutation Score genauer, aber langsam
- 32 -

Pain Point Test-Abdeckung
- 33 -
Code
Unit-Test
Code
Anforderungen
Abdeckung
Genauigkeit VS
Zeit

„Billiger“ Nachbau von Mutation Score
▪ Verschiedene Metriken
▪ Jede einzelne Metrik „schlechte“ Repräsentation
▪ Aber was, wenn wir die Metriken kombinieren?
▪ Neuronales Netz zur Errechnung eines kombinierten Metrik-Wertes
▪ Korreliert zu 99 % mit Mutation Score
- 34 -
0
10
20
30
40
50
60
Coverage Metrics Mutation Testing Test Smells

Lösung Test-Abdeckung
- 35 -
Code
Unit-Test
Code
Anforderungen
Abdeckung
Maschinelles Lernen
(Neuronale Netze)

Genauigkeit VS
Zeit
Lange
Ausführungszeit
Manueller
Aufwand
Manueller
Aufwand
Takeaway
- 36 -
Code
Unit-Test
Code
Anforderungen
Abdeckung
Maschinelles Lernen
(Neuronale Netze)
Genetische
Algorithmen
Validierung
Low-Code
Automatisierung
Low-Code
Automatisierung
Test-Erstellung
Test-Erstellung
Code-Erstellung

▪ Kontaktieren Sie uns
▪ JKU: daniel.lehner@jku.at
▪ Devmate: johannes.bergsmann@automated-software-testing.com
▪ Lesen Sie unseren Blog
▪ devmate.software/blog
▪ Weiteres Forschungsprojekt
▪ 3-Jähriges Projekt, 32 Partner aus 7 Ländern
▪ Verbindung KI, Digitale Zwillinge, und Software Testing
Interessiert?
- 37 -

Fragen / Diskussion
- 38 -
Daniel Lehner
daniel.lehner@jku.at
http://derlehner.at/

Die nächste Generation des Unit Testing

Recommended

Recommended

More Related Content

Similar to Die nächste Generation des Unit Testing

Similar to Die nächste Generation des Unit Testing (20)

More from Daniel Lehner

More from Daniel Lehner (15)

Die nächste Generation des Unit Testing