Jira Performance Tests mit dem DC App Performance Toolkit

Kurt Klinner

Egal ob eine neue 3rd Party Anwendung installiert werden oder die Anzahl der Jira User erhöht werden soll, immer wieder werden Administratoren mit der Frage konfrontiert ...

Um eine Antwort zu geben, die nicht auf "wir haben zu dritt mal manuell getestet und es läuft" basiert, wird der geneigte Admin relativ schnell nach Testtools Ausschau halten, die ihn dabei unterstützen automatisiert Testreihen zu erzeugen.

Eine Möglichkeit, die ich ein wenig genauer beleuchten möchte ist hierbei das Data Center App Performance Toolkit von Atlassian.

APT erweitert Taurus, ein Open Source Performance Framework welches JMeter and Selenium Tests ausführt.

Abhängigkeiten & Installation

Um das Toolkit zum Laufen zu bringen, muss man ein paar Abhängigkeiten vor der Installation berücksichtigen (Details hierzu finden sich unter https://github.com/atlassian/dc-app-performance-toolkit)

  • Python 3.7, 3.8 or 3.9 / pip
  • JDK 11 (wichtig ist das JRE_HOME/JDK_HOME korrekt gesetzt sind)
  • Google Chrome Browser

Nachdem man das Repo mittels

git clone https://github.com/atlassian/dc-app-performance-toolkit.git

als lokale Kopie erzeugt hat, installiert man die Abhängigkeiten mittels pip (idealerweise unter Verwendung von virtualenv)

cd dc-app-performance-toolkit/

#Erzeugen und Aktivieren der virtualenv Umgebung
virtualenv venv -p full_path_to_python 
source venv/bin/activate

#Installation der benötigten Module
pip install -r requirements.txt

Nachdem die Vorarbeiten abgeschlossen sind, machen wir uns ans Anpassen der Konfiguration für den Testlauf. Die relevanten Informationen finden sich in der Datei namens jira.yml im dc-app-performance-toolkit/app Verzeichnis.

  • application_hostname:  jira hostname (ohne Angabe des Protokolls, sprich nur jira.mydomain.com).
  • application_protocol: http oder https.
  • application_port: 80 (http), 443 (https),  oder z.B. 8080 bei direktem Zugriff ohne Proxy
  • secure: True oder False. Sollte man ein self-signed SSL Zertifikat nutzen welches unter Umständen nicht validiert werden kann, dann setzt man diesen Wert auf False
  • application_postfix: Der verwendete Kontext ala /jira
  • admin_login: Benutzername des Admin Kontos
  • admin_password: Password des Admin Benutzers
  • concurrency: Anzahl der Benutzer für JMeter Tests.
  • test_duration: Dauer des Testlaufes
  • ramp-up: Zeit um alle Testbenutzer zum Testlauf hinzuzufügen.
  • total_actions_per_hour: Anzahl der Testaktionen pro Stunde

In der gleichen Sektion gibt man dann noch den prozentualen Anteil von diversen Aktionen ala "create issue", "search jql" oder "view dashboard"

An sich ist es jetzt Zeit für den ersten Versuch, nachdem dieser aber bei mir gleich mal fehl schlug noch ein Hinweis. Die verwendete Version des Chromedriver muss der Version des installierten Chrome Browser entsprechen.

Von daher muss man via http://chromedriver.chromium.org/downloads die korrekte Version herunterladen und installieren. Wichtig ist, dass die ausführbare Datei an einer Stelle platziert werden muss, die im PATH referenziert ist.

In der jira.yml selbst wird in der Sektion modules, dann die Version noch angepasst

  selenium:
    chromedriver:
      version: " "107.0.5304.87"

Testlauf

Damit ist es Zeit den ersten Lauf zu wagen, also .....

Den Test selbst starten wir durch Aufruf von bzt (Taurus CLI) und der entsprechenden Konfiguration.

bzt jira.yml

Während des Laufes wird in der Taurus Konsole in Echtzeit angezeigt, wie die JMeter und Selenium verlaufen.

0:00
/

Idealerweise sollten wir eine Erfolgsquote von mehr als 95 Prozent haben. Liegen wir unterhalb dieses Wertes, liefern uns die Logfiles unter dc-app-performance-toolkit/app/results/jira/YY-MM-DD-hh-mm-ss weitere Details, die uns bei der Analyse helfen.

  • bzt.log - log des bzt Laufes
  • error_artifacts - Verzeichnis mit Screenshots and HTML Snippets der fehlgeschlagenen Selenium Tests
  • jmeter.err - JMeter Error Log
  • kpi.jtl - JMeter Raw Data
  • pytest.out - Detailierte Logfiles der Selenium Tests inklusive Stacktraces
  • selenium.jtl - Selenium Raw Data
  • results.csv - Konsolidiertes Ergebnis des Testlaufes
  • results_summary.log -  Detailliertes Ergebnis des Test Laufes

Reports

Nach einigen Testläufen kann man sich daran machen, die Daten graphisch aufzubereiten. Im reports_generation Verzeichnis finden sich mit
csv_chart_generator.py  ein Python Programm, welches die vorhanden Testdaten in Form von Bar Charts visualisiert.

Das Programm erwartet eine Konfigurationsdateien. performance_profile.yml oder scale_profile.yml sind hierbei zwei Vorlagen, die man erweitern bzw. als Template verwenden kann.  

Um beispielsweise 2 Testläufe zu vergleichen, kann man die performance_profile.yml wie im angefügten Beispiel erweitern, wichtig ist hierbei das die Variable fullPath einen gültigen Pfad zu einem Results Verzeichnis enthalten muss.

# Defines which column from test runs is used for aggregated report. Default is "90% Line"
column_name: "90% Line"
runs:
  # fullPath should contain a full path to the directory with run results. E.g. /home/$USER/dc-app-performance-toolkit/app/results/jira/2019-08-06_17-41-08
  - runName: "Run1"
    runType: "baseline"
    fullPath: "/Users/kurt/Development/atlassian/dc-app-performance-toolkit/app/results/jira/2022-10-31_20-46-42"
  - runName: "Run2"
    runType: "experiment"
    fullPath: "/Users/kurt/Development/atlassian/dc-app-performance-toolkit/app/results/jira/2022-10-31_20-44-40"

# Chart generation config
index_col: "Action"
title: "DCAPT Performance Testing"
image_height_px: 1000
image_width_px: 1600
judge: false

Die wichtigsten Optionen kurz erläutert.

  • column_name - Spaltenname aus der results.csv, der für die Aggregation genutzt wurde
  • runName - Label für den spezifischen Lauf
  • runType - Label für die Art des Laufes ala baseline, experiment
  • fullPath - Der vollständige Pfad zum result Verzeichnes des Testlaufs
  • index_col - Index Spalte
  • title - Titles der Visualisierung (und zugleich des Ausgabedateinamen=
  • image_height_px - Charthöhe in Pixel
  • image_width_px - Chartbreite in Pixel
python csv_chart_generator.py performance_profile.yml

erzeugt im Verzeichnis dc-app-performance-toolkit/app/results/reports/YYYY-MM-DD_HH-MM-SS eine png Datei, welche die verschiedenen Aktionen graphisch gegenüberstellt, ebenso wie eine CSV mit den verwendeten Daten und eine Zusammenfassung der beiden Datenreihen

Wie aus der Grafik bzw. dem Beobachten der Testläufe ersichtlich, gibt es eine ganze Reihe an Standardaktionen, die von Haus aus über das Toolkit abgedeckt werden.

In der Regel hat man 3rd Party Apps installiert oder ggf. selbst Erweiterungen entwickelt, die man bei der Performancebetrachtung mit inkludieren will.

Erweiterungen

Um weitere Methoden mit einzubauen (die man z.B. über einen Seleniumtest abdecken will), erweitert man die dc-app-performance-toolkit/app/extension/jira/extension_ui.py Datei.

Folgendes Beispiel würde einen spezifischen Filter aufrufen (id 10105) in dem wir die entsprechen URL der go_to_url Methode übergeben und dann warten bis ein spezielles DOM Element (jira_request_timing_info) geladen wurde (in der Methode wait_until_visible)

def app_specific_action(webdriver, datasets):
	@print_timing("selenium_app_custom_action")
	    def measure():
 	       @print_timing("selenium_app_custom_action:view_filter")
 	       def sub_measure():
  	          page.go_to_url(f"{JIRA_SETTINGS.server_url}/issues/?filter=10105")
  	          page.wait_until_visible((By.ID, "jira_request_timing_info")) 
    	    sub_measure()
   	 measure()

Neben des Hinzunehmen der verschiedenen Testmethoden, muss man noch in der Datei dc-app-performance-toolkit/app/selenium_ui/jira_ui.py,  folgende Zeilen einkommentieren, um die neuen Tests auszuführen.

def test_1_selenium_custom_action(jira_webdriver, jira_datasets, jira_screen_shots):
     extension_ui.app_specific_action(jira_webdriver, jira_datasets)

Beim nächsten Testlauf sollten dann die weiteren Tests mit ausgeführt und gemessen werden.

In diesem Sinne

Ressourcen

Atlassian stellt einige sehr hilfreiche Ressourcen bereit, die genauer beleuchten wie man Custom Data Sets verwenden oder spezifische User für Tests (reguläre User vs. Admin) nutzen kann aber auch mehr Details wie man das Framework erweitert.

https://github.com/atlassian/dc-app-performance-toolkit

https://developer.atlassian.com/platform/marketplace/dc-apps-performance-toolkit-user-guide-jira/