k6-Skripterstellung

Was macht k6-Skripterstellung?

Diese Skill generiert Leistungstests mit k6, die jedes Teammitglied ausführen, verstehen und korrigieren kann, auch ohne k6-Kenntnisse. Dazu hat jedes Skript die gleiche Struktur, Namen, die aussagekräftig sind, Anmeldeinformationen außerhalb des Codes und eine .md-Datei, die es Schritt für Schritt erklärt.

Team-Prioritäten: Load und Stress, sowohl HTTP als auch k6 Browser. Der Smoke ist immer der vorausgehende Schritt.

Quelle der Wahrheit: die offizielle Dokumentation

Alles, was geschrieben wird, muss mit https://grafana.com/docs/k6/latest/ (k6 v2.x) übereinstimmen. Die Referenzen dieser Skill fassen diese Dokumentation zusammen. Wenn etwas nicht abgedeckt ist oder Sie den geringsten Zweifel an einer API, einer Option oder einer Metrik haben, konsultieren Sie die offizielle Seite (Karte in references/official-docs.md), anstatt sich auf Ihr Gedächtnis zu verlassen. Viele Beispiele im Internet verwenden alte APIs (k6/experimental/browser, synchroner Browser, browser_web_vital_fid), die in v2 nicht mehr funktionieren.

Referenzdateien (lesen Sie nur, was Sie brauchen)

Datei	Wann lesen
references/test-types.md	Immer: Testtyp, Stage-Profil und Executor auswählen
references/thresholds-checks.md	Immer: Standardschwellwerte und Schreiben von Checks
references/http-patterns.md	API-Tests: Lebenszyklus, Authentifizierung, Secrets, Korrelation, Daten
references/browser-patterns.md	Tests mit k6 Browser oder Hybrid
references/doc-template.md	Beim Schreiben der erklärenden .md
references/official-docs.md	Zum Nachschlagen der offiziellen Seite zu einem Thema
assets/lib/config.js	Direkt nach k6/lib/config.js kopieren
assets/templates/*	Vorlage für Abläufe, Tests, README, .secrets.example

Standardverzeichnisstruktur im Projekt

k6/
├── tests/
│   ├── api/        <typ>-<ablauf>.js            z.B. load-checkout.js, stress-search-products.js
│   └── browser/    <typ>-<ablauf>-browser.js    z.B. load-login-browser.js
├── lib/
│   ├── config.js   (kopiert von assets/lib/config.js)
│   ├── flows/      <ablauf>.js — die Benutzerschritte, von allen Typen wiederverwendet
│   └── pages/      <seite>-page.js — Page Objects (nur Browser, wenn der Ablauf mehrere Seiten hat)
├── data/           Testdaten JSON/CSV (niemals Anmeldeinformationen)
├── docs/           <gleicher-name-wie-das-skript>.md
├── .secrets.example
└── README.md       (von assets/templates/k6-README.md, mit dem Skriptindex)

Namen: kebab-case, Typ-Präfix (smoke-, load-, stress-, spike-, soak-, breakpoint-) + beschreibender Geschäftsablauf (checkout, search-products, nicht test1 oder api). Browser-Skripte haben das Suffix -browser. Die .md-Datei hat genau denselben Namen wie das Skript.

Sprache: Kommentare und Dokumentation auf Deutsch; Code-Bezeichner auf Englisch.

Wenn das Projekt bereits einen Ordner k6/ hat, verwenden Sie config.js, Abläufe und vorhandene Page Objects wieder, anstatt sie zu duplizieren, und respektieren Sie, was bereits vorhanden ist.

Arbeitsablauf

1. Die Anfrage verstehen

Extrahieren Sie aus dem, was der Benutzer gesagt hat:

• Testtyp: Load, Stress oder andere. Wenn der Benutzer „sehen, wie viel es aushält“ oder „bis an die Grenze gehen“ sagt, ist es Stress (oder Breakpoint, wenn er den genauen Bruchpunkt möchte). Wenn der Benutzer „normale Last“ oder „einen typischen Tag“ sagt, ist es Load.
• API, Browser oder Hybrid.
• Endpunkte oder Bildschirme und Reihenfolge des Ablaufs, wie authentifiziert wird und was jeder Schritt validiert.
• Last (gleichzeitige Benutzer oder req/s), Dauer und SLA (z. B. p95 < 500 ms).
• Zielumgebung.

Fragen Sie nur nach dem, was wirklich blockiert und nicht vernünftigerweise angenommen werden kann: die URL oder die Endpunkte, wenn der Benutzer sie nicht angegeben hat, und immer, wenn das Ziel die Produktion ist, wenn es nicht klar ist. Alles andere wird mit den Standardwerten aus den Referenzen angenommen (SLA 500 ms, Think Time 1–3 s, Stress = 2× der Load-Last). Jede Annahme wird im Abschnitt „Annahmen“ der .md-Datei festgehalten. Wenn der Benutzer seine Lastzahlen nicht kennt, sagen Sie es ihm: Ohne sie beantwortet der Test eine andere Frage als die, die ihn interessiert.

2. Die Struktur vorbereiten

Erstellen Sie, was in k6/ fehlt: lib/config.js (exakte Kopie von assets/lib/config.js), .secrets.example mit den vom Skript verwendeten Schlüsseln, README.md aus der Vorlage, und fügen Sie zum .gitignore des Projekts hinzu:

k6/.secrets
k6/screenshots/

3. Den Ablauf und die Tests schreiben

• Ablauf in k6/lib/flows/<ablauf>.js (Basis: assets/templates/flow-api.js). Enthält die Requests, Checks, nummerierte Groups, Tags name und Think Time. Wenn der Ablauf einen Login benötigt, exportieren Sie eine Funktion login(), die von setup() aufgerufen wird.
• Test in k6/tests/api/<typ>-<ablauf>.js (Basis: assets/templates/test-api.js). Definiert nur options (Szenario + Thresholds), setup() und default(), die den Ablauf aufruft. Die Stages und Thresholds werden explizit in die Datei geschrieben, mit einem Kommentar pro Zeile.
• Browser in k6/tests/browser/<typ>-<ablauf>-browser.js (Basis: assets/templates/test-browser.js). Standardmäßig hybrid: HTTP-Last plus wenige Browser-VUs. Lesen Sie references/browser-patterns.md.
• Erstellen Sie immer auch smoke-<ablauf>.js, wenn es noch nicht existiert. Es ist günstig (verwendet den Ablauf wieder) und ist der erste obligatorische Schritt vor Load oder Stress.
• Wenn Stress angefordert wird und der Load desselben Ablaufs nicht existiert, erstellen Sie beide: Die offizielle Dokumentation besagt, dass der Stress nach dem Load ausgeführt wird und dessen Skript wiederverwendet.

Regeln, die nicht verhandelbar sind, weil sie das Team und die Systeme schützen:

• Anmeldeinformationen, Tokens und API-Schlüssel nur über k6/secrets (await secrets.get('NAME')) mit --secret-source=file=k6/.secrets. Niemals im Code, in data/, in Standardwerten von __ENV oder in console.log.
• Die URL und die Umgebung über -e BASE_URL / -e TARGET_ENV, gelesen aus lib/config.js. Niemals fest codiert.
• Entfernen oder schwächen Sie den Produktionsschutz von config.js nicht.
• Imports von jslib mit genauer Version (siehe official-docs.md).
• Browser: k6/browser, async-Funktionen, options.browser.type: 'chromium' im Szenario, page.close() in finally, check von k6-utils für asynchrone Checks, page.waitForTimeout() anstelle von sleep().
• Jeder Request mit stabilem Tag name ('GET /items/:id'), damit URLs mit IDs nicht die Anzahl der Metriken explodieren lassen.

4. Die erklärende .md-Datei schreiben

Eine pro Skript in k6/docs/<name>.md, die allen Abschnitten von references/doc-template.md folgt. Der Leser ist kein Experte: Erklären Sie jeden Begriff beim ersten Mal (VU, Iteration, p95, Threshold), erklären Sie das Warum hinter jeder Zahl und verwenden Sie die tatsächlichen Werte aus dem Skript. Fügen Sie das ASCII-Diagramm des Lastprofils, die Tabelle der Checks und Thresholds „in Worten“, die genauen Befehle zum Ausführen (zuerst Smoke) und die häufigsten Fehler hinzu. Fügen Sie das Skript anschließend zum Index von k6/README.md hinzu.

5. Validieren

• Führen Sie k6 inspect -e BASE_URL=https://example.test -e TARGET_ENV=staging <skript> für jedes neue Skript aus. Es erkennt Syntaxfehler, defekte Imports und ungültige Optionen, ohne Last zu erzeugen. Wenn k6 nicht installiert ist, sagen Sie es und hinterlassen Sie den Befehl, damit er ausgeführt werden kann.
• Eine tatsächliche Ausführung nur mit ausdrücklicher Genehmigung des Benutzers und als Smoke (wenige VUs und wenige Sekunden) gegen eine Umgebung, die nicht die Produktion ist. Starten Sie niemals eigenständig Load, Stress, Spike, Soak oder Breakpoint: Sie erzeugen echte Last auf gemeinsam genutzten Systemen.

6. Antworten

Kurze Antwort:

• Liste der erstellten oder geänderten Dateien.
• Der Befehl zum Ausführen des Smoke und dann des angeforderten Tests.
• Wichtigste Annahmen (dieselben wie in der .md).
• Was Sie validiert haben und was nicht (z. B. „k6 inspect bestanden; nicht gegen die API ausgeführt“).

Vorhandenes Skript überprüfen oder korrigieren

Wenn die Anfrage darin besteht, ein Skript zu verstehen, zu korrigieren oder zu verbessern:

1. Lesen Sie es vollständig und gleichen Sie es mit dem Standard und der offiziellen Dokumentation ab (alte APIs, Browser ohne await, fehlendes page.close, Anmeldeinformationen im Code, keine Thresholds, keine Tags name, keine Think Time, Profile wie „Achterbahn“).
2. Erklären Sie die Probleme in einfacher Sprache, geordnet nach Schweregrad, und schlagen Sie die Änderung vor.
3. Aktualisieren (oder erstellen) Sie beim Korrigieren die zugehörige .md-Datei, sodass die Dokumentation weiterhin mit dem Code übereinstimmt.
4. Wenn der Name nicht dem Standard entspricht, schlagen Sie die Umbenennung vor, aber führen Sie sie nicht ohne Bestätigung durch, da dies Pipelines beschädigen könnte, die das Skript aufrufen.