Posts mit dem Label Testen werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Testen werden angezeigt. Alle Posts anzeigen

Mittwoch, 13. September 2023

JMeter never gets old


 

 Now it's much simpler to run system test or load and performance test. You can integrate the good old JMeter into Maven and run the test in the build pipeline. Great.

Biggest advantage: You don't a JMeter installation. JMeter is loaded and run as Maven plugin.

 

Look at the https://github.com/jmeter-maven-plugin/jmeter-maven-plugin




Freitag, 11. Januar 2019


  1. Integrate Jacoco into your Maven pom.xml.
  2. Add into your file .gitlab-ci.ymlecho -n "Total:" ; cat target/site/jacoco/index.html | grep -o 'Total[^%]*%' | grep -o -E '[0-9]+%$
  3. Add Badge in Gitlab under Setting.
  4. Gitlab scann the console for the Regex you given in Point 3.

Then you you've got this nice Gitlab Test coverage Badge.

Mittwoch, 29. November 2017

Warum wir Robustness Test brauchen.

Es gibt einen sehr einfachen Grund für Robustness Tests, Robustness Tests helfen dabei die Verfügbarkeit von Softwaresystemen zu steigern. Es gibt drei wesentliche Einflussfaktoren die zu einer Reduzierung der Softwarezuverlässigkeit führen:

  1. Anzahl bzw. Frequenz von Störfällen (Incidents)
  2. Dauer von Störfällen (Duration of Incidents)
  3. Auswirkung oder Umfang von Störfällen (Impact of Incidents)
Robustness Test wirken sich positiv auf alle drei Faktoren aus.
  1. Robustness Test ermöglichen es ein Softwarearchitektur zu wählen bei denen ein Störfall auf das betroffene System beschränkt bleibt und es zu keiner Fehlerkaskade kommt. So wird im Falle eines Störfalls der Umfang begrenzt.
  2. Durch die Reduktion des Umfangs des Störfalls auf eine Einzelsystem wird für die Wiederherstellung des Betriebs weniger Zeit benötigt. Es sind keine Aufwendigen Startprozeduren notwendig wie z.B. starte als erstes Db Server, dann die App Server, warte auf App Server für 3 Minuten bis sie voll funktionsfähig sind, 3. wäre Cache vor, ...
  3. Und als drittes führen Robustness Test zum frühzeitigen Aufdecken von noch unbekannten Problemen die in der Zukunft zu Störfällen geworden wären.
  4. Und als letztes verhindern Robustness Test das Wiederauftreten bekannter Störfälle in dem man bekannt Störfallszenarien als Robustness Test umsetzt und regelmässig testet. Auch so wird die Anzahl der Störfälle reduziert. Für diesen Fall kann man auch eine Testabdeckung berechnen, d.h. wieviele bekannt Störfälle werden regelmässig durch Robustness Test abgedeckt, bzw. simuliert.

Zusammenfassend kann man festhalten Robustness Test sind sie Art von Test die man zum prüfen von nicht-funktionalen Anforderungen (NFA) benötigt.

Mittwoch, 13. Juli 2016

Run All Test on File Change

Eines der besten Instrumente um Code zu verbessern sind Test, speziell Unit Tests. Unit Test sind für alle erdenklichen Programmiersprachen verfügbar und wenn nicht, dann schreibt man sich den Test selbst, ohne Frame Work. Mit Hilfe der Unit Test können Fehler einfach aufgedeckt werden dazu muss man nicht nur die Test haben, sondern sie auch permanent ausführen. Dieses permanente Ausführen ist die Aufgabe des Continouse Integration Servers, z.B. Jenkins. Alternativ gibt es auch die Unit Integration in die IDE. Wem selbst der Jenkins oder die IDE zu langsam ist, schnelle Roundtripzeiten bedeuten effizientes Entwickeln, der kann sich mit Hilfe eines einfachen Scripts seine Test ausführen, wenn sich etwas am Quellcode der Software oder der Test geändert hat (File save).

Hier ein Beispiel für den Mac, dass Unit Test für R ausführt und den Entwickler per Notification auf Fehler bei der Testdurchführung hinweist. Zuerst muss per Homebrew fswatch installiert werden. Dann muss dieses Script ins Root Verzeichnis deines Projektes abgelegt werden. Dann muss es starten. Es läuft ohne Unterbrechung solange, bis man via CRTL + C abbricht. Alternativ kann man das Script für andere Umgebungen anpassen.


#!/usr/bin/env bash

runX=true

finish (){
    runX=false
}
trap finish SIGINT


runTests(){
    for SCRIPT in src/test/*
    do
        if [ -f $SCRIPT -a -x $SCRIPT ]
        then
            $SCRIPT
            if [[ $? -ne 0 ]] 
            then
                FAILEDTESTS=${FAILEDTESTS}"\n"$SCRIPT
            fi
        fi                                                      
    done
    if [ ${#FAILEDTESTS} -ge 1 ]
    then
        osascript -e 'display notification  "'"$FAILEDTESTS"'" with title "R Test failed"'
        FAILEDTESTS=""
    fi
}

while $runX; do
    fswatch src/main/*.R src/test/*.R | runTests 
done



Donnerstag, 29. Januar 2015

Vortrag auf der Konferenz Developer World 2015

Wer möchte kann mich auf der Developer World Konferenz (Link) am 17.4.2015 in Hannover erleben. Zusammen mit Uwe Beßle halte ich den Vortrag: Erfahrungsbericht: Testen von nichtfunktionalen Anforderungen im E-Commerce bei OTTO Hamburg
Das Testen funktionaler Anforderungen ist heute Standard in der Softwareentwicklung und wird gut durch Software unterstützt. Nichtfunktionale Anforderungen werden dagegen derzeit oft nicht ausreichend getestet. Am Beispiel von OTTO.de wird gezeigt, wie verschiedene nichtfunktionale Anforderungen, wie Performance, Lastverhalten sowie Robustheit systematisch als Qualitätskriterien getestet werden können. Es werden Vorgehen, Tests, Tools und Integration in den Entwicklungsprozess beschrieben.

Link zum Konferenzprogramm.

Donnerstag, 19. Juni 2014

Unit Test mit R, ganz einfach

Auch wenn R oft nicht als richtige Programmiersprache gilt, so gibt es auch in R die Möglichkeit Unit Test zu schreiben. Dafür stehen verschiedene Packages zur Verfügung:

  • RUnit
  • testthat
Hier ein minimales Einsteigerbeispiel mit testthat:


source("main/analyzeXltReport.R")
library(testthat)


test_that("Error Rates", {
  xltreport = loadXltXmlReport("test/testreport.xml")
  expect_that( getTranscationErrorCount(xltreport), equals(24) )
  expect_that( getAtionErrorCount(xltreport), equals(24) )
})

Zuerst wird die zu testende Datei geladen und dann das Testframework. Danach ruft man die Testmethode test_that auf mit einem guten Namen und dem eigentlichen Testcode.

Wenn man jetzt den Test ausführt liefert er beim Erfolg kein Ergebnis:
> source('~/git/lhotse-nfa/loadtest/analysis/test/analyzeXltReportTest.R')
> 
Bei Fehlern sieht es dann z.B. wie folgt aus:
> source('~/git/lhotse-nfa/loadtest/analysis/test/analyzeXltReportTest.R')
Fehler: Test failed: 'Error Rates'
Not expected: getTranscationErrorCount(xltreport) not equal to 20
Mean relative difference: 0.2.

Eine kleine Anmerkung, die Pfade in den R Scripten auch im Unit Test beziehen sich auf das aktuelle Directory!

Weitere Informationen zum Unit Testing mit R findet Ihr hier: