SCL-Unit-Tests für TIA Portal & SPS

Ein Unit-Test in TIA Portal prüft einen einzelnen SPS-Baustein (FB/FC) isoliert: definierte Eingänge schreiben (Arrange), die Steuerung einige Zyklen laufen lassen (Act) und die Ausgänge gegen erwartete Werte prüfen (Assert) — gegen PLCSIM Advanced oder eine echte S7-SPS, automatisiert und wiederholbar.

Integriertes Unit-Test-Framework für TIA-Bausteine. Schreiben, ausführen und auswerten von Tests gegen eine laufende PLCSIM Advanced Instanz direkt in der App.

Voraussetzungen:

Pro+-Lizenz oder höher
PLCSIM Advanced V3.0+ installiert (separate Siemens-Lizenz)
Ein TIA-Projekt mit mindestens einer geöffneten SPS

Unit-Testing-Workspace öffnen

Klicken Sie auf das Unit Testing-Symbol (Becherglas) in der Aktivitätsleiste ganz links
Die Seitenleiste zeigt dann die Ansicht Test Suites, den Baum der gefundenen .tia-tests-Suiten. Die Titelleiste zeigt Run All Test Suites / Stop Test Run, Re-run Failed Tests, Show Failed Only und Open Test Bench; New Test Suite, Refresh Test Suites, Choose Test Folder, Clear Test Folder, Generate CI Pipeline und Export Test Report liegen im …-Menü der Titelleiste. Jede Suite- und Case-Zeile hat beim Überfahren eine Inline-Run-Aktion. Die Ergebnisse Ihrer Läufe erscheinen im Reiter Run der Test Bench (siehe Die Test Bench weiter unten).
Ein Klick auf eine Suite im Baum öffnet sie als Test-Suite-Editor im Editorbereich; ein Klick auf einen Testfall öffnet seine Suite mit diesem Fall bereits ausgewählt. Der Editor zeigt dieselbe Suite in drei umschaltbaren Ansichten, Visual, JSON und SCL, gewählt mit dem Umschalter rechts in seiner Kopfzeile; die aktive Ansicht ist in der Farbe Ihres Themes hervorgehoben. Die Kopfzeile zeigt ausserdem Baustein, PLC und Verbindungsart der Suite sowie Validate, Run (der Pfeil daneben öffnet die Laufoptionen, siehe Laufoptionen weiter unten), Save und ein …-Menü mit Generate from Boundaries, Import to TIA (SCL-Ansicht), Open as JSON Text, Connection Settings und den Contract- und Snapshot-Aktionen.
Die Visual-Ansicht ist zweigeteilt: Der obere Teil listet jeden Testfall als eine Zeile (Status, Nummer, Name, Beschreibung, Eingänge, Assertions, Anforderungen, Zyklen, Priorität, Tags und letztes Ergebnis); der untere Teil bearbeitet den ausgewählten Fall. Über der Liste grenzt ein Filterfeld die Fälle nach beliebigem Text ein, die Dropdowns Status, Priority und Requirement filtern weiter; daneben wirken Add (Testfall, Theorie-Fall oder aus Grenzwerten erzeugte Fälle), Duplicate, Move Up, Move Down und Remove auf die ausgewählten Zeilen. Der Trenner zwischen Liste und Editor lässt sich ziehen, und der Fall-Editor lässt sich mit dem Chevron rechts in seiner ersten Zeile zuklappen (auch Ctrl+Shift+J); beide Teile scrollen für sich.
Der Fall-Editor beginnt mit Name, Zyklen, Timeout und Priorität, gefolgt von der Beschreibung und den Abschnitten Inputs, Assertions, Steps, Watch und Metadata (bei einem Theorie-Fall zusätzlich Parameters). Jeder Abschnitt fügt Zeilen über das +-Symbol in seinem Kopf hinzu, jede Zeile zeigt neben dem Namen den Datentyp ihrer Variable, und jede Zeile trägt rechts ihr Entfernen-Symbol. Steps und Watch bleiben zugeklappt, solange sie leer sind, Metadata zeigt seine Werte im Kopf, bis Sie es öffnen. Das Operator-Dropdown einer Assertion ist gruppiert (Comparison, Range, Boolean, Text, Bits, Aggregate, Snapshot); Array Equals und Deep Equals bearbeiten ihren Erwartungswert in einem kleinen JSON-Fenster, eine Snapshot-Assertion bietet ein Excludes-Fenster für die Variablen, die aus der Baseline ausgenommen werden.
Tastatur: In der Fall-Liste fügt Ctrl+Shift+N einen Fall hinzu, Ctrl+D dupliziert, Alt+Up / Alt+Down verschieben, Delete entfernt (mit Rückfrage, wenn der Fall Assertions hat), Ctrl+Enter führt die ausgewählten Fälle aus (die ganze Suite, wenn keiner ausgewählt ist), Enter oder F2 springt ins Namensfeld und Escape zurück in die Liste; Ctrl+1, Ctrl+2 und Ctrl+3 wechseln zwischen Visual, JSON und SCL.

Die Test Bench

Die Test Bench ist der Arbeitsbereich, in dem Sie einen Baustein wählen, sein Interface ansehen, seine Tests ausführen und die Ergebnisse lesen. Sie öffnen sie auf einem dieser Wege:

Befehlspalette: Unit Testing: Open Test Bench
Open Test Bench in der Titelleiste der Test-Suites-Ansicht; die im Baum ausgewählte Suite ist dann bereits gewählt
Klick auf den Unit-Testing-Eintrag in der Statusleiste nach einem Lauf; die Test Bench öffnet sich auf dem Reiter Run

Kopfzeile. Von links nach rechts:

Element	Was es tut
PLC	Wählt die PLC. Das Menü bietet ausserdem Refresh PLC List, solange Sie mit TIA Portal verbunden sind.
Block	Wählt den zu testenden Baustein; zeigt das Siemens-Symbol des Bausteintyps. Mit TIA Portal verbunden, listet es die Bausteine Ihres Projekts; ohne Verbindung die Bausteine, die Ihre Test-Suiten verwenden.
Suite	Wählt die Test-Suite dieses Bausteins; die Zahl in Klammern ist die Anzahl ihrer Testfälle. Hat der Baustein genau eine Suite, wird sie automatisch gewählt.
+ (New Suite for This Block)	Legt ohne Rückfrage eine Test-Suite für den gewählten Baustein an und öffnet sie im Test-Suite-Editor neben der Test Bench. Die Suite beginnt mit einem leeren Testfall, Sie fügen die benötigten Inputs und Assertions selbst hinzu.
Verbindung	Grau Not connected, blau Source folder, wenn Sie offline mit einem Ordner exportierter Bausteine arbeiten, oder grün mit der TIA-Portal-Version und dem Namen des verbundenen Projekts. Ein Klick bietet Connect to TIA Portal oder Disconnect from TIA Portal, Choose Source Folder… (oder Change Source Folder… und Clear Source Folder) und Open PLCSIM Dashboard.
Run	Führt die in der Kopfzeile gewählte Suite aus. Der Pfeil daneben öffnet die Laufoptionen: alle Suiten, die Suite oder ihre fehlgeschlagenen Fälle, mit Coverage, Mutationstest oder Contract-Prüfung, und die Optionen für instabile Fälle und Snapshot-Baselines (siehe Laufoptionen weiter unten). Während eines Laufs erscheint Stop.
…	Open Suite in Editor, Connection Settings, Open Block XML, Show Coverage Heatmap, Show Mutation Markers, Export Test Report… und Generate CI Pipeline (öffnet die Seite CI Pipeline, siehe Eine CI/CD-Pipeline aus der App erzeugen).

Ein schmaler Balken unter der Kopfzeile zeigt den Fortschritt eines Laufs.

Baustein-Spalte (links). Eine Karte zeigt Name, Typ und Sprache des Bausteins und woher er gelesen wird (TIA Portal, Ihr Quellordner oder die exportierten Dateien des Projekts). Darunter liegen die Reiter Interface, Boundaries, Dependencies und Address Space. Sobald Sie einen Baustein wählen, füllen sich Interface und Boundaries von selbst, mit gesetztem Quellordner auch ohne TIA Portal. Solange ein Baustein gelesen wird, läuft oben in der Test Bench ein Fortschrittsbalken, und die Reiter nennen den aktuellen Schritt, zum Beispiel "Schnittstelle von 'FB_Motor' wird geladen …"; lassen sich die Grenzwerte nicht bestimmen, bleibt die Schnittstelle sichtbar und Boundaries nennt den Grund. Dependencies dauern länger und werden erst gelesen, wenn Sie im Kopf der Baustein-Spalte auf Analyze Dependencies klicken; Refresh Analysis daneben liest den Baustein erneut.

Ergebnis-Spalte (rechts). Die Reiter Run, History, Quality und Traceability, beschrieben in den folgenden Abschnitten. History listet Ihre bisherigen Läufe, vergleicht zwei Läufe und zeigt Trends; Quality zeigt die Ergebnisse von Coverage und Mutationstest; Traceability zeigt, welche Testfälle jede Anforderung abdecken und wie ihre letzten Ergebnisse lauten.

Vor einem Lauf. Die Test Bench führt die gespeicherte Suite aus. Ist die Suite im Test-Suite-Editor mit ungespeicherten Änderungen offen, fragt Studio, ob sie zuerst gespeichert werden soll (Save and Run). Zeigt der Editor Probleme, die das Speichern verhindern, startet der Lauf nicht, und eine Meldung nennt die Suite. Dasselbe gilt für jeden Lauf aus dem Test-Suite-Editor sowie für Coverage, Mutationstest und Contract-Prüfung.

Tastatur. Hat die Test Bench den Fokus, führt Ctrl+; und dann S die in der Kopfzeile gewählte Suite aus, Ctrl+; und dann Q stoppt einen laufenden Test.

Nach einem Neustart. Die Test Bench öffnet sich wieder mit derselben PLC, demselben Baustein, derselben Suite und denselben Reitern und zeigt den Lauf, den sie zuvor gezeigt hat.

Test Explorer

Der Test Explorer zeigt die Testsuiten des TIA-Projekts, mit dem Sie gerade verbunden sind — jede .tia-tests/*.json-Datei erscheint als Suite-Knoten mit ihren Test-Cases als Kinder. Solange kein Test-Ordner gewählt und kein Projekt verbunden ist, meldet die Ansicht „Mit einem TIA-Projekt verbinden oder einen Testordner wählen, um Testsuiten zu laden."; sobald ein Ordner gewählt ist, erscheinen dessen Suiten automatisch (ein gewählter Ordner ohne Suiten zeigt „Noch keine Testsuiten."; existiert der gewählte Ordner nicht mehr, zeigt er „Gewählter Testordner nicht gefunden: <Pfad>").

Status-Icons (beim App-Start aus SQLite geladen):

✓ Bestanden — grünes Häkchen, Test erfolgreich im letzten Lauf
✗ Fehlgeschlagen — rotes Kreuz, Test fehlgeschlagen
⚠ Fehler — orange Warnung, Test hatte einen Fehler (Exception, Timeout, S7-Fehler)
⊘ Übersprungen — grauer durchgestrichener Kreis, Test wurde aus dem letzten Lauf herausgefiltert
○ Nicht ausgeführt — grauer leerer Kreis, kein gespeichertes Ergebnis

Interaktionen:

Aktion	Ergebnis
Klick auf Suite (oder auswählen und Enter drücken)	Öffnet die Suite als Test-Suite-Editor im Editorbereich
Klick auf einen Testfall	Öffnet seine Suite im Test-Suite-Editor mit diesem Fall ausgewählt
Auf eine Suite zeigen, dann in ihrer Zeile auf Run Suite klicken	Führt nur diese Suite aus
Auf einen Testfall zeigen, dann in seiner Zeile auf Run Single klicken	Führt nur diesen Testfall aus
Run All Test Suites (Titelleiste der Ansicht)	Führt alle sichtbaren Suites sequentiell aus
Stop Test Run (Titelleiste, während ein Lauf läuft)	Bricht den laufenden Run am nächsten sicheren Punkt ab
New Test Suite / Refresh Test Suites (…-Menü der Titelleiste)	Eine neue Suite anlegen oder den `.tia-tests/`-Ordner neu einlesen
Test-Ordner wählen / Testordner-Auswahl löschen (…-Menü der Titelleiste)	Selbst festlegen, in welchem Ordner Ihre Testsuiten liegen (ist ein Ordner gewählt, folgt die Liste ihm, sonst dem verbundenen Projekt), oder die Auswahl wieder löschen

Ein Filterfeld oben in der Test-Suites-Ansicht grenzt den Baum nach Suite- und Case-Namen ein, ein Show Failed Only-Toggle in der Titelleiste blendet alles aus, was nicht fehlgeschlagen ist, und eine Pro-Case-Run Single-Aktion führt nur einen Case aus.

Geplant für den In-App-Arbeitsbereich. Eine Nur betroffene ausführen-Aktion (nur Suites erneut laufen lassen, deren zugrundeliegender Baustein sich geändert hat) ist geplant. Heute stehen Einzel-Suite-, Einzel-Case- und Alle-Suites-Läufe wie oben zur Verfügung; auf der Kommandozeile führt tia-test-runner run --rerun-affected bereits nur die Suites aus, deren zugrundeliegender Baustein sich geändert hat (siehe CI/CD-Integration).

Geplant — Block-Change-Badge. Ein kleiner oranger Punkt neben einer Suite, deren zugrundeliegender PLC-Baustein sich seit ihrem letzten Lauf geändert hat, mit dem Tooltip „Baustein seit letztem Lauf geändert", ist für die Test-Suites-Ansicht geplant.

Ein Testfall, der über seine letzten Läufe instabil war (mal bestanden, mal fehlgeschlagen), trägt ein Instabil-Abzeichen neben seinem Namen, mit einem Tooltip, der zeigt, wie oft sein Ergebnis gewechselt hat. Das wird aus der Lauf-Historie berechnet und erscheint, sobald ein Fall in den letzten Läufen sowohl bestanden als auch fehlgeschlagen ist. Das Abzeichen verschwindet von selbst, sobald sich der Fall wieder auf ein stabiles Ergebnis einpendelt, sodass ein behobener Test nach einigen gleichbleibenden Läufen nicht mehr markiert wird und ein Fall, der nun jedes Mal fehlschlägt, als echter Fehlschlag statt als instabil angezeigt wird.

Testfall-Metadaten

Der Fall-Editor der Visual-Ansicht endet mit einem Metadata-Abschnitt (standardmässig zugeklappt, unterhalb von Watch; sein Kopf zeigt die aktuellen Werte). Klick auf den Abschnittskopf öffnet ihn und gibt folgende Felder pro Case zur Bearbeitung frei; die Priorität lässt sich auch in der ersten Zeile des Fall-Editors setzen, und Anforderungen, Priorität und Tags erscheinen als Spalten der Fall-Liste:

Feld	Zweck
Reihenfolge	Numerische Lauf-Reihenfolge. Leer lassen, um die natürliche Reihenfolge in der Suite zu behalten
Tags	Labels (z. B. `safety`, `regression`) für Filter in HTML-Reports, als Chips erfasst (siehe unten)
Priorität	Niedrig / Normal / Hoch / Kritisch. Steuert Report-Sortierung
Verantwortlicher	Freitext-Verantwortlicher (Team-Name, E-Mail usw.)
Anforderungen	Anforderungs-IDs (z. B. `REQ-123`, `REQ-456`) für Traceability, als Chips erfasst, mit Vorschlägen aus Ihrem Testordner (siehe unten)

Nach Validate erscheint jedes Problem in einer Leiste unter der Editor-Kopfzeile als N issues; öffnen Sie sie und klicken Sie auf ein Problem, um zum betroffenen Fall und Abschnitt zu springen. Ein Fall mit Problemen trägt zusätzlich ein Warnzeichen in der Statusspalte der Fall-Liste, und Save und Run bleiben gesperrt, bis blockierende Fehler behoben sind. Alle Änderungen werden zusammen mit der Suite automatisch gespeichert. Suites aus früheren Versionen laden mit leeren Metadaten-Defaults — keine Migration nötig.

Anforderungs-IDs und Tags

Tags und Requirements zeigen jeden Eintrag als Chip. Tippen Sie in das Feld hinter den Chips und drücken Sie Enter oder ein Komma, um einen Eintrag hinzuzufügen. Fügen Sie eine durch Kommas oder Zeilenumbrüche getrennte Liste ein, entsteht pro Eintrag ein Chip. Einen Chip entfernen Sie mit einem Klick auf sein x. Mit der Tastatur springt Backspace im leeren Feld zum letzten Chip, die Pfeiltasten wechseln zwischen den Chips, und Backspace oder Delete entfernt den Chip mit dem Fokus.

Während Sie eine Anforderungs-ID tippen, schlägt eine Liste die IDs vor, die die gespeicherten Testsuiten Ihres Testordners bereits verwenden, jeweils mit der Anzahl Testfälle und den Suiten, die sie nennen, dazu die IDs, die Sie in dieser Suite hinzugefügt, aber noch nicht gespeichert haben. So bleibt eine Anforderung in jeder Suite gleich geschrieben. Ungespeicherte Änderungen in anderen offenen Suiten erscheinen nicht in den Vorschlägen.

Eine Anforderungs-ID wird mit dem Grund unter dem Feld abgelehnt, wenn sie leer ist, Steuerzeichen oder unsichtbare Formatierungszeichen enthält, länger als 256 Zeichen ist, wenn der Testfall damit mehr als 50 IDs nennen würde oder wenn er sie bereits nennt. Eine Suite, die bereits eine solche ID enthält, öffnet trotzdem: Das Problem erscheint in der Problemleiste, und Save und Run bleiben gesperrt, bis Sie es behoben haben.

Unterscheiden sich zwei IDs nur in Gross- und Kleinschreibung, Leerzeichen oder der Art des Bindestrichs (zum Beispiel REQ-1 und req-1), erscheint eine Warnung unter den Chips und in der Problemleiste. Wird die andere Schreibweise anderswo in Ihrem Testordner verwendet, ersetzt Use REQ-1 Ihren Chip durch sie. Studio führt die beiden nie selbst zusammen: Abdeckung und Berichte zählen sie als verschiedene Anforderungen, bis Sie sich für eine Schreibweise entscheiden.

Tags werden aus der aktuellen Suite vorgeschlagen. Ein Tag mit mehr als 64 Zeichen oder mehr als 50 Tags an einem Testfall zeigen einen Hinweis, weil Berichte sie kürzen.

Das Dropdown Requirement des Filters über der Fall-Liste zeigt die IDs dieser Suite mit der Anzahl Testfälle je ID, danach unter Other suites in the folder die IDs, die nur andere Suiten verwenden. Wählen Sie eine davon, erscheint "No case of this suite covers ..." mit Clear Filter.

Im AI Chat können Sie fragen "Welche Anforderungs-IDs gibt es in meinem Testordner?"; der Assistent listet sie auf, und wenn er Testfällen Anforderungen hinzufügt, hält er sich an dieselben Regeln und weist auf abweichende Schreibweisen hin.

Live-Progress während eines Laufs

Einen laufenden Test verfolgen Sie an mehreren Stellen:

Statusleiste: Der Unit-Testing-Eintrag zeigt den Fortschritt, zum Beispiel „Testing 4/36". Nach dem Lauf zeigt er das Ergebnis, zum Beispiel „36 passed" oder „35 passed, 1 failed". Beim Überfahren erscheint die vollständige Aufschlüsselung, ein Klick öffnet den Reiter Run der Test Bench.
Test Bench: Unter der Kopfzeile läuft ein schmaler Fortschrittsbalken, und der Reiter Run füllt sich mit jedem abgeschlossenen Testfall. Der erste Lauf nach dem Start von Studio öffnet die Test Bench auf dem Reiter Run; haben Sie den Lauf im Test-Suite-Editor gestartet, öffnet sie sich als Reiter im Hintergrund, damit Ihr Editor vorne bleibt.
Test-Suites-Ansicht: Status-Icons werden live pro Testfall aktualisiert.
Stop Test Run: Bricht den laufenden Run am nächsten sicheren Punkt ab (S7-Verbindung und PLCSIM-Instanz werden immer aufgeräumt).

Ergebnisse im Reiter Run lesen

Der Reiter Run der Test Bench zeigt den letzten Lauf, egal wo Sie ihn gestartet haben (Test Bench, Test-Suites-Ansicht, Test-Suite-Editor, die CodeLens über einem Baustein oder der KI-Assistent). Ein Run All zeigt alle Suiten des Laufs zusammen.

Kopfzeile: der Suite-Name (oder zum Beispiel „Run All, 7 suites"), Startzeit, Dauer, PLC, TIA-Portal-Version, Verbindungsart und Rechnername. Die Liste rechts wechselt zwischen den Läufen dieser Sitzung; ein aus dem Reiter History geöffneter Lauf ist mit „(history)" markiert.
Zähler: Gesamt, bestanden, fehlgeschlagen, Fehler und übersprungen (mit der Anzahl zurückgestellter instabiler Fälle); ein Zähler mit null erscheint ohne Farbe. Daneben wiederholt Rerun denselben Lauf, Re-run Failed Tests nur seine fehlgeschlagenen Fälle, Export Report… öffnet das Exportformular für diesen Lauf (siehe Bericht exportieren), und Compare To… führt Sie zum Reiter History, wo Sie den Lauf wählen, mit dem er verglichen wird.
Filter: Failed only, die Listen Suite, Block, Tag und Requirement sowie ein Textfeld, das Fall, Suite, Baustein und Meldung durchsucht.
Fall-Liste: Status, Fallname (mit den Markierungen Flaky und Quarantined), die Suite (wenn der Lauf mehrere Suiten umfasste), Dauer und Meldung. Ein Doppelklick auf einen Fall öffnet ihn im Test-Suite-Editor. Eingestellte Spaltenbreiten werden gemerkt.
Assertions: jede Assertion des ausgewählten Falls mit Variable, Operator, Erwartet, Tatsächlich und Status. Stimmt ein Snapshot nicht mehr mit seiner Baseline überein, übernimmt Approve Baseline in dieser Zeile das neue Ergebnis, und Approve Baselines (N) über dem Raster übernimmt nach einer Rückfrage alle. Beides wirkt auf den neuesten Lauf der Sitzung.
Timeline: ein Diagramm, wie sich jede Watch-Variable Zyklus für Zyklus verändert hat, während des Laufs live aktualisiert. Den Abschnitt können Sie zuklappen, wenn Sie ihn nicht brauchen.
Freigabe-Zeile: unter der Kopfzeile, sobald der Lauf gespeichert ist: ob der Lauf freigegeben ist, von wem und wann, mit Sign Off… oder Revoke… (siehe Testlauf freigeben). Bei einem Run All steht dort zum Beispiel „3 of 7 runs signed off".

Läufe aus der Historie. Ein aus dem Reiter History geöffneter Lauf zeigt die Werte, die während dieses Laufs gelesen wurden. Die Erwartungswerte stammen aus der Suite, wie sie jetzt ist; die Kopfzeile vermerkt das mit „Expected values from the current suite". Werte, die ältere Läufe nicht lesbar speichern konnten, erscheinen als „not recorded".

Um Watch-Daten zu erfassen, fügen Sie einem Testfall in der Suite-JSON ein "watch": ["Var1", "Var2"]-Array hinzu und setzen "cycles" grösser als 1. Das Sampling ist pro Testfall auf 100.000 Zyklen gedeckelt. Dieselben Daten werden zusätzlich als Zeitreihen-Chart in den HTML-Berichten des Kommandozeilen-Werkzeugs tia-test-runner gerendert (siehe CI/CD-Integration).

Test-Ergebnisse werden in %LocalAppData%\AnyAutomation Studio\db\test_results.db gespeichert: Sie überleben App-Neustarts und erscheinen automatisch wieder in der Test-Suites-Ansicht.

History

Der Reiter History der Test Bench listet jeden gespeicherten Testlauf, der neueste zuoberst (bis zu den letzten 200), egal welche Suite er ausgeführt hat. Er hat drei Modi, zwischen denen Sie mit Runs, Compare und Trend in seiner obersten Zeile wechseln. Das Kommandozeilen-Werkzeug tia-test-runner erzeugt dieselben Informationen als HTML- und CSV-Berichte (siehe CI/CD-Integration).

Runs

Spalten: standardmässig Started, Duration, Result, Sign-off, Suite, Block, PLC, Host und TIA, nach einem Statuspunkt. Der Punkt zeigt das Ergebnis des Laufs: Passed, Failed (auch wenn nur ein Testfall fehlgeschlagen ist oder einen Fehler hatte), Error (der Lauf brach vorzeitig ab, zum Beispiel weil die Verbindung verloren ging) oder Cancelled; zeigen Sie darauf, um das Ergebnis zu lesen. Sign-off zeigt, ob der Lauf freigegeben ist (mit der Maus darüber sehen Sie, von wem und wann). Die Spalte Result zeigt kleine farbige Zähler: bestanden immer, fehlgeschlagen, Fehler und übersprungen nur, wenn es welche gibt. Wurden instabile Fehlschläge zurückgestellt, lautet der Zähler für übersprungen zum Beispiel „2 (1 flaky)" und hat einen gestrichelten Rand.
Spalten wählen: Klicken Sie in der obersten Zeile auf Columns und haken Sie die gewünschten Spalten an. Total, Passed, Failed, Errors, Skipped, Suite File und Run Id lassen sich hinzufügen; Reset Columns stellt die Standardspalten wieder her. Mindestens eine Spalte bleibt immer sichtbar. Ihre Auswahl und die Spaltenbreiten werden gemerkt, auch für Spalten, die Sie aus- und wieder einblenden.
Filterfeld: schränkt die Liste nach Suite, Baustein, PLC oder Host ein.
Aktualisieren: Das Aktualisieren-Symbol oder F5 lädt die Liste neu; nach jedem Lauf lädt sie sich auch von selbst neu.
Lauf öffnen: Ein Doppelklick auf eine Zeile oder Enter zeigt diesen Lauf im Reiter Run.
Mehrere Läufe wählen: mit Ctrl oder Shift wie in jeder Liste, zum Beispiel um zwei Läufe zu vergleichen oder mehrere Berichte auf einmal zu exportieren.

Rechtsklick auf einen Lauf (oder Shift+F10):

Aktion	Ergebnis
Open Results	Zeigt den Lauf im Reiter Run
Compare To…	Lässt Sie den Lauf wählen, mit dem er verglichen wird (siehe Compare weiter unten)
Export Report…	Öffnet das Exportformular für diesen Lauf oder für alle ausgewählten Läufe (siehe Bericht exportieren)
Sign Off…	Gibt diesen Lauf frei, oder die ausgewählten Läufe, die sich freigeben lassen (siehe Testlauf freigeben)
Revoke Sign-off…	Widerruft die Freigabe dieses Laufs mit einer Begründung
Delete Run…	Entfernt den Lauf nach einer Rückfrage dauerhaft aus der Historie. Wirkt jeweils auf einen Lauf; sind mehrere Zeilen ausgewählt, ist die Aktion nicht verfügbar. Ein freigegebener Lauf lässt sich erst löschen, wenn seine Freigabe widerrufen ist. Zeigte der Reiter Run oder ein Vergleich diesen Lauf, werden sie geleert

Delete bei einer einzelnen ausgewählten Zeile wirkt wie Delete Run….

Der Projektpfad eines Laufs wird nie im Klartext gespeichert, sondern nur als nicht umkehrbarer Fingerabdruck, sodass sich Läufe über Rechner hinweg zuordnen lassen, ohne Arbeitsbereichspfade offenzulegen.

Compare

Compare zeigt, was sich zwischen zwei Läufen geändert hat.

Zwei ausgewählte Läufe: Wählen Sie zwei Zeilen und klicken Sie auf Compare. Der ältere Lauf wird zur Baseline, der neuere zum aktuellen Lauf. Compare bleibt nicht verfügbar, bis zwei Läufe ausgewählt sind.
Compare To…: im Reiter Run oder im Zeilenmenü eines Laufs. Der Reiter History öffnet sich mit diesem Lauf ausgewählt und der Zeile „Choose the run to compare with …". Klicken, doppelklicken oder drücken Sie Enter auf dem Lauf, den Sie als Baseline wollen, und der Vergleich öffnet sich. Studio wartet immer auf den Lauf, den Sie als Nächstes wählen, auch wenn vorher ein anderer Vergleich offen war, und Cancel in dieser Zeile führt ohne Vergleich zur Liste der Läufe zurück.

Der Vergleich zeigt:

Baseline und Current nebeneinander, jeweils mit Startzeit, Anzahl bestandener und fehlgeschlagener Fälle und Dauer, sowie Swap, um sie zu tauschen.
Zusammenfassung: Regressions, Fixed, New, Removed und Stable.
Filter: All, Regressions, Fixed, New oder Removed schränkt die Fall-Liste ein.
Fall-Liste: jeder Fall mit seiner Änderung (zum Beispiel Regression, Fixed oder Still Failing), seiner Meldung und der Änderung der Dauer, darunter „N of M cases".

Trend

Trend zeigt, wie sich eine Suite über die Zeit entwickelt.

Suite und Case: Die Suite-Liste wird aus Ihrer Lauf-Historie gebildet und ist deshalb auch gefüllt, wenn Sie die Test-Suites-Ansicht nie geöffnet haben. Haben zwei PLCs eine Suite mit demselben Namen, steht die PLC in Klammern dahinter. Die Fall-Liste stammt aus der gewählten Suite.
Zeitraum: Last 30 Days, Last 90 Days oder eigene Daten unter From und To.
Das Diagramm Pass Rate für die PLC der gewählten Suite, das Diagramm Duration für die Suite und die Heatmap Case History für den gewählten Fall, eine Zelle pro Lauf, nach Ergebnis eingefärbt und mit einem Symbol markiert. Beim Überfahren einer Zelle sehen Sie, wann der Lauf gestartet wurde.
Das Aktualisieren-Symbol in der obersten Zeile lädt die Diagramme neu.

Beim Öffnen beginnt Trend mit der Suite des ausgewählten Laufs, sonst mit der in der Kopfzeile der Test Bench gewählten Suite, sonst mit der Suite des neuesten Laufs.

Share rechts in der obersten Zeile bietet je nach Modus:

Modus	Share bietet
Runs	Export Report… für die ausgewählten Läufe (oder den neuesten Lauf) und Export CSV… mit den Zeilen und Spalten, die Sie gerade sehen, einschliesslich der Freigabe jedes Laufs
Compare	Export Report… für den Vergleich
Trend	Export CSV… mit den Punkten des Trends

CSV-Dateien werden so geschrieben, dass ein Tabellenprogramm keine Zelle als Formel ausführt.

Bericht exportieren

Export Report… öffnet ein kleines Formular neben der Schaltfläche, auf die Sie geklickt haben. Sie erreichen es über Share im Reiter History, über das Zeilenmenü eines Laufs, über das Export-Symbol im Reiter Run, über Export Test Report… im …-Menü der Test Bench und über die Befehlspalette mit Unit Testing: Export Test Report (das den Reiter History mit dem neuesten Lauf ausgewählt öffnet).

Formats: HTML report und JUnit XML. Ein Vergleich wird nur als HTML exportiert.
Scope: This Run, Selected Runs (mit der Anzahl ausgewählter Läufe) oder Comparison (verfügbar, nachdem Sie zwei Läufe verglichen haben). Ein Umfang, der nicht zu Ihrer Auswahl passt, ist ausgegraut und nennt den Grund.
Output: der Output folder, relativ zum Berichtsordner Ihres TIA-Projekts (standardmässig report). Der Ordner muss innerhalb dieses Berichtsordners liegen; sonst meldet das Feld „Wählen Sie einen Ordner innerhalb des Berichtsordners des Projekts.“ und Export bleibt nicht verfügbar. Exportieren Sie mehrere Läufe, erhält jeder Lauf einen eigenen Unterordner, benannt nach seiner Startzeit, sodass kein Bericht einen anderen überschreibt. Der neueste Export liegt immer zuoberst in seinem Ordner: Enthält der Ordner bereits den Bericht eines anderen Laufs, wandert dieser frühere Bericht in einen eigenen Unterordner unter runs und bleibt dort prüfbar; exportieren Sie denselben Lauf erneut, wird sein Bericht einfach ersetzt. Schlägt ein Export fehl, bleibt der Ordner unverändert.
Branding: Öffnen Sie diesen Abschnitt, um Title, Footer und Accent color (eine Hex-Farbe wie #2563eb) festzulegen.

Klicken Sie auf Export (oder Export 3 Reports und so weiter) oder drücken Sie Ctrl+Enter; Escape schliesst das Formular. Solange Sie nicht mit einem TIA-Projekt verbunden sind, ist Export nicht verfügbar und das Formular sagt das, weil Berichte ins Projekt geschrieben werden. Der HTML-Bericht des neuesten exportierten Laufs öffnet sich in Studio als Seite, sobald er fertig ist, und eine Meldung nennt den Ordner, in den die Dateien geschrieben wurden, und, falls ein früherer Bericht verschoben wurde, wohin er kam. Mit Open Folder in dieser Meldung sehen Sie die Dateien im Datei-Explorer. Das Formular merkt sich Formate, Ordner und Branding für den nächsten Export.

Quality: Coverage und Mutation

Der Reiter Quality der Test Bench zeigt, wie gründlich die Tests einer Suite ihren Baustein prüfen. Er gehört zur in der Kopfzeile der Test Bench gewählten Suite; ist dort keine gewählt, zeigt er die Suite Ihres neuesten Laufs. Er hat zwei Abschnitte, die Sie auf- und zuklappen können; Studio merkt sich, welche zugeklappt sind.

Coverage. Die Zeile unter der Überschrift nennt den Lauf, zu dem die Werte gehören, und ob dieser Lauf die Abdeckung Zeile für Zeile gemessen hat. Bis zu fünf Balken zeigen, was die Tests erreicht haben: Requirement, Interface, Called Blocks und nach einem Lauf mit Coverage-Instrumentierung auch Statement und Branch. Jeder Balken zeigt abgedeckt von gesamt und einen Prozentwert, oder n/a, wenn der Baustein nichts dieser Art hat. Öffnen Sie einen Balken, um zu sehen, was nicht erreicht wurde; bei Anweisungen und Verzweigungen öffnet ein Klick auf eine Zeile den Baustein an dieser Zeile. Die Symbole in der Abschnittsüberschrift sind Refresh, Export Coverage… (schreibt eine Cobertura-Datei in den Berichtsordner Ihres TIA-Projekts; die Meldung nennt den Ordner, sagt, wohin ein früherer Bericht darin verschoben wurde, und bietet Open Folder an) und Run with Coverage Instrumentation.

Mutation. Zeigt das neueste Mutationstest-Ergebnis der Suite (siehe Mutationstest weiter unten), auch wenn Sie die Suite nach dem Mutationslauf normal ausgeführt haben. Die Symbole in der Abschnittsüberschrift sind Refresh, Toggle Mutation Markers (angehakt, solange die Markierungen im Editor angezeigt werden, dieselbe Einstellung wie Show Mutation Markers im …-Menü der Test Bench) und Run Mutation Testing.

Lauf von hier starten. Run with Coverage Instrumentation und Run Mutation Testing führen die Suite des Abschnitts aus. Wie jeder Lauf aus der Test Bench fragen sie zuerst, ob ungespeicherte Änderungen der Suite gespeichert werden sollen. Sie sind ausgegraut und nennen den Grund, wenn die Suite nicht auf PLCSIM Advanced läuft oder Sie nicht mit TIA Portal verbunden sind. Während und nach einem solchen Lauf bleibt die Test Bench auf dem Reiter Quality, und beide Abschnitte aktualisieren sich, sobald der Lauf endet.

Mutationstest

Der Mutationstest beantwortet eine Frage, die die Abdeckung nicht beantworten kann: Fangen Ihre Tests einen Fehler tatsächlich ab? Er nimmt an einer Kopie Ihres Bausteins eine Reihe winziger Änderungen vor (zum Beispiel ein > zu einem >= kippen, ein AND durch ein OR ersetzen oder eine Ausgangszuweisung entfernen), führt Ihre vorhandene Test-Suite gegen jede geänderte Kopie aus und meldet die Änderungen, die Ihre Tests nicht bemerkt haben. Eine Änderung, die Ihre Suite erkannt hat, ist eine „getötete" Mutation; eine Änderung, die mit lauter grünen Tests durchgerutscht ist, ist eine „überlebende" Mutation, und das ist eine Lücke in Ihren Tests.

Ihr ursprünglicher Baustein wird nie verändert. Jede Änderung erfolgt an einer Wegwerf-Kopie, die Studio nach jedem Lauf wieder aufräumt.

Mutationstest ausführen

Wählen Sie eine Test-Suite in der Ansicht Test-Suiten.
Stellen Sie sicher, dass Sie mit TIA Portal verbunden sind und Ihr Lauf eine PLCSIM-Instanz anspricht. Der Mutationstest benötigt ein PLCSIM-Ziel, deshalb lässt sich eine Suite mit direkter S7-Verbindung hier nicht verwenden.
Führen Sie Mutationstest ausführen über die Befehlspalette aus.
Studio führt die Suite zuerst einmal gegen den unveränderten Baustein aus. Die Suite muss zuerst bestehen (der Mutationstest misst, wie gründlich Ihre bestehenden Tests sind, deshalb fordert er Sie auf, fehlschlagende Fälle zuerst zu beheben, bevor er fortfährt). Anschliessend erzeugt er die Mutationen und führt die Suite gegen jede einzelne aus.

Sie können ihn auch mit Run Mutation Testing im Abschnitt Mutation des Reiters Quality starten oder in den Laufoptionen der Test Bench Mutation Testing wählen; die Test Bench bleibt dann auf dem Reiter Quality.

Der Lauf kann eine Weile dauern, weil jede Mutation der Reihe nach kompiliert, geladen und getestet wird. Sie können ihn jederzeit anhalten, und Studio räumt die erzeugten temporären Kopien trotzdem auf.

Ergebnisse lesen

Der Abschnitt Mutation des Reiters Quality der Test Bench zeigt:

Einen Mutationsscore (den Anteil der Mutationen, die Ihre Tests abgefangen haben, ohne die nicht lauffähigen), mit den Zählungen für getötet, überlebt und nicht lauffähig.
Eine Liste Überlebende Mutationen, eine Zeile pro Lücke: die Zeile, die Art der Änderung und was geändert wurde. Klicken Sie auf eine Zeile, um direkt zu dieser Zeile im Baustein-Quelltext zu springen.
Aufklappbare Listen der getöteten und der nicht lauffähigen Mutationen.

Überlebende Mutationen werden zudem im Editor hervorgehoben: Die betroffenen Zeilen erhalten eine rote Tönung und eine rote Markierung am Zeilenrand, mit einem Tooltip, der die von keinem Test abgefangene Änderung beschreibt. Mit Show Mutation Markers im …-Menü der Test Bench, Mutationsmarkierungen umschalten in der Befehlspalette oder Toggle Mutation Markers im Abschnitt Mutation des Reiters Quality blenden Sie sie ein oder aus.

Ein hoher Score bedeutet, dass Ihre Tests fast jeden Fehler abgefangen haben. Ein niedriger Score oder eine lange Überlebenden-Liste zeigt Ihnen genau, wo Sie Testfälle ergänzen oder verstärken sollten.

Einstellungen

Maximale Mutationen pro Lauf legt fest, wie viele Änderungen Studio in einem Lauf ausprobiert. Eine höhere Zahl findet mehr Lücken, dauert aber länger.
Mutationsoperatoren lässt Sie wählen, welche Arten von Änderung angewendet werden: Vergleiche, logische Operatoren, Konstanten und Arithmetik sowie Anweisungslöschung. Alle sind standardmässig aktiv.

Rückverfolgbarkeit der Anforderungen

Der Reiter Traceability der Test Bench zeigt für jede Anforderungs-ID Ihres Testordners, welche Testfälle sie abdecken und wie deren letzte Ergebnisse lauten. Er umfasst den ganzen Testordner, unabhängig davon, welche PLC, welcher Baustein oder welche Suite im Kopf der Test Bench gewählt ist. Öffnen Sie ihn über seinen Reiter neben Quality oder in der Befehlspalette mit Unit Testing: Show Requirement Traceability. Ist im Filter Requirement des Test Suite Editors eine Anforderung gewählt, öffnet Show in Traceability den Reiter mit dieser Anforderung.

Die Anforderungsliste. Die obere Tabelle zeigt pro Anforderung eine Zeile mit Status, Anzahl Testfälle, einem Chip pro Ergebnis (zum Beispiel 2 Passed, 1 Failed), den Suiten und dem Zeitpunkt des letzten Nachweises. Die Zeilen sind nach Status sortiert, die dringendsten zuerst:

Status	Bedeutung
Failed	Mindestens ein Testfall der Anforderung ist im letzten Lauf fehlgeschlagen oder mit einem Fehler abgebrochen
Uncovered	Ihre importierte Anforderungsliste nennt die Anforderung, aber noch kein Testfall
Not Run	Ein Testfall der Anforderung ist in den letzten Läufen seiner Suite nicht gelaufen
Outdated	Ein Testfall wurde nach seinem letzten Lauf geändert, oder für seine Suite wurde eine neue Snapshot-Baseline übernommen; führen Sie ihn erneut aus
Unknown	Der letzte Lauf wurde aufgezeichnet, bevor Studio Änderungen erkennen konnte; führen Sie ihn erneut aus
Incomplete	Ein Testfall wurde übersprungen oder als instabil in Quarantäne gestellt
Passed	Alle Testfälle der Anforderung haben im letzten Lauf bestanden

Studio betrachtet die letzten 20 Läufe jeder Suite. Führen Sie nur einen Testfall oder eine Auswahl aus, zählt dieser Lauf nur für diese Fälle; die übrigen Fälle behalten das Ergebnis ihres letzten vollständigen Laufs. Eine geänderte Verbindung einer Suite (PLCSIM-Instanz, IP-Adresse, Passwörter) macht Ergebnisse nicht veraltet.

Die Testfälle einer Anforderung. Wählen Sie eine Anforderung, um ihre Testfälle im Abschnitt Cases darunter zu sehen: Suite, Fall, Zustand, Startzeit des Laufs, der das Ergebnis geliefert hat (mit dem Hinweis "partial run", wenn nur ein Teil der Fälle lief), ob dieser Lauf freigegeben ist, und Meldung. Ein Doppelklick auf einen Fall oder Enter öffnet diesen Lauf im Reiter Run mit dem Fall ausgewählt. Ein Rechtsklick auf einen Fall bietet Show Run, Open in Suite Editor und Copy Requirement Id. Ziehen Sie die Trennlinie, um die Bereiche anzupassen, oder setzen Sie mit Tab den Fokus auf die Trennlinie und verschieben Sie sie mit den Pfeiltasten nach oben und unten (mit Shift in grösseren Schritten, mit Pos1 und Ende ganz an ein Ende). Den Abschnitt Cases klappen Sie über seine Kopfzeile ein.

Filter. Geben Sie im Filterfeld einen Text ein, um Anforderungs-IDs, Titel, Suiten, Fälle und Bausteine zu durchsuchen. Status grenzt die Liste auf einen Status ein. Untraced cases listet die Testfälle, die gar keine Anforderung nennen, damit Sie Tests finden, denen noch eine Anforderungs-ID fehlt. Die Zählung rechts in der oberen Zeile fasst die Liste zusammen, zum Beispiel "12 requirements, 1 failed, 2 uncovered". Refresh (F5) lädt den Reiter neu; er aktualisiert sich auch selbst nach einem Lauf und wenn Sie eine Suite speichern.

Share. Share rechts in der oberen Zeile bietet:

Export CSV… schreibt die aktuell sichtbaren Zeilen (eine Zeile pro Anforderung und Testfall, mit der Freigabe des Laufs, der das Ergebnis geliefert hat) in eine CSV-Datei für Ihre Qualitätsdokumentation. Zellen, die ein Tabellenkalkulationsprogramm als Formel ausführen würde, werden als reiner Text geschrieben.
Export HTML Report schreibt einen Traceability-Bericht in den Berichtsordner Ihres TIA-Projekts (Unterordner traceability des Ausgabeordners, den Sie zuletzt in Export Report gewählt haben, oder report/traceability, wenn Sie keinen gewählt haben) und öffnet ihn als Seite. Er zeigt jede Anforderung mit Status und Testfällen, die Testfälle ohne Anforderung, die Probleme Ihrer Anforderungsliste und eine Legende der Zustände, mit Titel, Fusszeile und Akzentfarbe Ihres letzten Berichts. Mit tia-test-runner verify können Sie später prüfen, dass niemand die Dateien verändert hat. Der Eintrag ist verfügbar, solange Sie mit dem TIA-Projekt verbunden sind.

Reiter, gewählte Anforderung, Statusfilter und der Schalter Untraced cases bleiben über einen Neustart von Studio erhalten.

Anforderungsliste importieren

Importieren Sie die Anforderungsliste Ihres Projekts (zum Beispiel einen Export aus Ihrem ALM- oder Anforderungswerkzeug oder eine als CSV gespeicherte Tabelle), um zu sehen, welche Anforderungen noch keinen Test haben. Öffnen Sie Requirement List in der oberen Zeile des Reiters Traceability und wählen Sie Import Requirement List…, oder führen Sie in der Befehlspalette Unit Testing: Import Requirement List... aus, und wählen Sie die Datei.

Dateien: CSV- oder Textdateien bis 10 MB und 20'000 Zeilen. UTF-8, UTF-16 (der "Unicode-Text" von Tabellenkalkulationen) und ANSI werden gelesen; die Spalten dürfen durch Komma, Semikolon oder Tabulator getrennt sein. Speichern Sie die Liste als UTF-8, damit Sonderzeichen exakt erhalten bleiben.
Spalten: Die erste Zeile benennt die Spalten. Die Spalte mit der Anforderungs-ID darf id, requirement, requirement id, req id oder req heissen; eine optionale Titelspalte title, name oder summary; eine optionale Beschreibungsspalte description, text oder details. Andere Spalten werden ignoriert. Eine Datei mit nur einer Spalte von IDs ohne Überschrift funktioniert ebenfalls.
Bevor etwas geschrieben wird, prüft Studio die Datei, zeigt, was es gefunden hat, zum Beispiel "124 requirements found. 1 row is skipped.", zusammen mit allfälligen Problemen, und fragt mit Import nach. Zeilen mit leerer oder ungültiger ID werden übersprungen, bei doppelten IDs zählt die erste Zeile, zu lange Titel oder Beschreibungen werden gekürzt. Eine Datei, die sich gar nicht importieren lässt (zu gross, keine ID-Spalte, ein nicht geschlossenes Anführungszeichen), wird mit dem Grund abgelehnt.
Die Liste wird im Testordner neben Ihren Suiten gespeichert (.tia-tests/requirements.csv), reist also mit ihnen in der Versionsverwaltung mit, und auch der Kommandozeilen-Runner findet sie. Ein erneuter Import ersetzt sie; Ihre Originaldatei wird nie verändert.

Mit einer Liste zeigt der Reiter Traceability eine Spalte Title, führt aufgeführte Anforderungen ohne Testfall als Uncovered und markiert Anforderungs-IDs Ihrer Suiten, die nicht in der Liste stehen, mit "Not in requirement list". Ist eine ID in der Liste und in den Suiten unterschiedlich geschrieben (zum Beispiel REQ-1 und req-1), weist ein Hinweis über der Tabelle darauf hin. Probleme der Liste werden über der Tabelle zusammengefasst, und die IDs der Liste werden vorgeschlagen, wenn Sie in einem Testfall eine Anforderungs-ID eingeben.

Open Requirement List öffnet die gespeicherte Liste in einem Texteditor. Öffnen Sie sie stattdessen in einem Tabellenkalkulationsprogramm, werden Zellen, die mit =, +, - oder @ beginnen, als Formeln berechnet; Studio behält solche IDs, Titel und Beschreibungen genau so, wie sie geschrieben sind, und warnt davor. Remove Requirement List… verschiebt die Liste nach einer Bestätigung in den Papierkorb; Anforderungen, die kein Testfall nennt, verschwinden dann aus dem Reiter.

Im AI Chat können Sie fragen "Welche Anforderungen schlagen fehl?" oder "Welche Anforderungen haben noch keinen Test?"; der Assistent liest dieselben Zustände wie der Reiter. Er kann auch eine Anforderungsliste für Sie prüfen und importieren; bevor er die Liste ersetzt und bevor er eine Datei ausserhalb Ihres Workspace prüft, fragt er nach Ihrer Zustimmung. Das Entfernen der Liste bleibt Ihnen überlassen.

Testlauf freigeben

Mit einem Pro+- oder Enterprise-Plan (auch in der Testphase) geben Sie einen Testlauf frei und halten damit fest, dass Sie sein Ergebnis geprüft und akzeptiert haben, zum Beispiel vor einer Werksabnahme. Die Freigabe nennt Ihr Konto und den Zeitpunkt und kann einen Kommentar enthalten. Eigene Läufe dürfen Sie selbst freigeben. Jeder Lauf kann einmal freigegeben werden; um eine Freigabe zu ändern, widerrufen Sie sie und geben den Lauf erneut frei.

Welche Läufe sich freigeben lassen. Ein abgeschlossener Lauf einer ganzen Suite. Ein abgebrochener Lauf, ein Lauf nur einzelner Testfälle und ein Lauf, dessen Suite danach geändert wurde, lassen sich nicht freigeben; führen Sie die Suite erneut aus und geben Sie den neuen Lauf frei. Auch Läufe, die aufgezeichnet wurden, bevor es die Freigabe gab, brauchen einen neuen Lauf. Hat ein Lauf fehlgeschlagene, abgebrochene oder in Quarantäne gestellte Testfälle, ist ein Kommentar Pflicht, der begründet, warum das Ergebnis akzeptiert wird.

Freigeben.

Öffnen Sie den Lauf im Reiter Run und klicken Sie in seiner Freigabe-Zeile auf Sign Off…, oder klicken Sie im Reiter History mit der rechten Maustaste auf den Lauf und wählen Sie Sign Off…. In der Befehlspalette öffnet Unit Testing: Sign Off Test Run… den Reiter History mit dem ausgewählten oder dem neuesten Lauf.
Ein kleines Formular zeigt die Läufe mit ihren Ergebnissen und das Konto, mit dem Sie freigeben („Signing as …"). Geben Sie bei Bedarf einen Kommentar ein (bis 1000 Zeichen, Zeilenumbrüche erlaubt).
Klicken Sie auf Sign Off oder drücken Sie Ctrl+Enter.

Um mehrere Läufe auf einmal freizugeben, wählen Sie sie in History aus (bis 50) und wählen bei einem davon Sign Off…, oder klicken Sie nach einem Run All im Reiter Run auf Sign Off…. Es werden entweder alle Läufe freigegeben oder keiner: Lässt sich ein Lauf nicht freigeben, nennt das Formular den Grund neben diesem Lauf, und es wird nichts festgehalten.

Widerrufen. Klicken Sie im Reiter Run auf Revoke…, wählen Sie beim Lauf in History Revoke Sign-off… oder führen Sie Unit Testing: Revoke Test Run Sign-off… aus. Nur das Konto, das den Lauf freigegeben hat, kann die Freigabe widerrufen. Geben Sie die Begründung ein (Pflicht) und klicken Sie auf Revoke Sign-off. Die Freigabe und die Begründung bleiben in der Historie des Laufs erhalten, und der Lauf kann erneut freigegeben werden.

Was die Zustände bedeuten.

Zustand	Bedeutung
Signed off	Lauf und Suite sind seit der Freigabe unverändert
Outdated	Die Suite wurde nach der Freigabe geändert; führen Sie sie erneut aus und geben Sie den neuen Lauf frei
Signed off, suite deleted	Die Suite-Datei wurde nach der Freigabe gelöscht
Broken	Der gespeicherte Lauf stimmt nicht mehr mit dem überein, was freigegeben wurde
Revoked	Die Freigabe wurde widerrufen; der Lauf kann erneut freigegeben werden
Not signed off	Niemand hat den Lauf freigegeben

Mit der Anzeigesprache Deutsch heissen die Zustände Freigegeben, Veraltet, Freigegeben, Suite gelöscht, Beschädigt, Widerrufen und Nicht freigegeben. Fahren Sie im Reiter Run mit der Maus über den Zustand, um zu sehen, wer wann freigegeben hat, mit allen früheren Freigaben und Widerrufen des Laufs.

Freigegebene Läufe bleiben erhalten. Ein freigegebener Lauf lässt sich in History erst löschen, wenn Sie seine Freigabe widerrufen haben. Das Löschen einer Suite löscht nie ihre Läufe; die Rückfrage nennt, wie viele freigegebene Läufe der Suite in History bleiben. Werden alte Läufe aus der Ergebnisdatenbank entfernt, bleiben freigegebene Läufe erhalten.

In Berichten. Der HTML-Bericht eines Laufs zeigt den Freigabe-Zustand zum Zeitpunkt des Exports, mit Konto, Zeitpunkt, Kommentar und bei einer widerrufenen Freigabe der Begründung. Der JUnit-XML-Bericht enthält dieselben Angaben, sodass Ihr CI-System sie anzeigen kann. tia-test-runner verify zeigt die Freigabe eines Berichts und schlägt fehl, wenn ihre Angaben nach dem Export verändert wurden.

Gut zu wissen. Die Freigabe wird auf dem Rechner festgehalten, der den Lauf gespeichert hat, in seiner lokalen Ergebnisdatenbank, für das Konto, mit dem Sie angemeldet sind. Sie erkennt spätere Änderungen am Lauf, an der Suite und an der Freigabe selbst, ist aber keine elektronische Signatur. Sie müssen mit Ihrem Konto angemeldet sein; wurde Ihre Lizenz zuletzt vor mehr als 90 Tagen geprüft, melden Sie sich erneut an. Zeigt die Uhr Ihres Rechners eine Zeit vor dem Ende des Laufs oder vor seiner letzten Freigabe, lehnt Studio Freigabe und Widerruf ab; prüfen Sie dann die Systemzeit. Der KI-Assistent kann Ihnen sagen, ob Läufe freigegeben sind, aber freigeben und widerrufen können nur Sie.

Baustein-Analyse (vor dem Testen)

Beim Öffnen einer Suite liest AnyAutomation Studio das Baustein-Interface aus dem TIA-Projekt, damit der Editor die echten Parameternamen und -typen kennt und die Inputs- und Assertions-Grids dagegen validieren können.

Dafür muss TIA Portal nicht geöffnet sein. Wenn Sie nicht mit TIA Portal verbunden sind, liest Studio den Baustein aus einer zuvor exportierten Kopie (exportieren Sie ihn im Projekt-Explorer). Ist der Baustein noch nicht exportiert, zeigt Studio eine Meldung, die Sie auffordert, ihn zuerst zu exportieren oder sich mit TIA Portal zu verbinden, statt das Interface leer zu lassen.

Quellordner wählen. Mit Choose Source Folder… im Verbindungsmenü der Kopfzeile der Test Bench legen Sie selbst fest, in welchem Ordner Ihre exportierten Bausteine liegen. Wählen Sie den Ordner mit Ihren Export-Dateien, und die Ordnerstruktur darin spielt keine Rolle mehr: Egal ob die Dateien flach im Ordner oder in Unterordnern liegen, Studio findet die passende Datei zum Baustein. So können Sie ohne geöffnetes TIA Portal analysieren und Tests ausführen. Ein einmal gewählter Quellordner wird gemerkt und steht nach einem Neustart sofort wieder bereit. Dasselbe Menü bietet danach Change Source Folder… und Clear Source Folder. Wählen Sie am besten den Ordner, in den Sie exportiert haben, und nicht einen übergeordneten Ordner mehrerer Projekte.

Die Baustein-Spalte der Test Bench hat die Reiter Interface, Boundaries und Dependencies. Wählen Sie in der Kopfzeile einen Baustein, und Interface und Boundaries füllen sich sofort; Dependencies werden gelesen, wenn Sie auf Analyze Dependencies klicken. Sie fassen zusammen:

Interface: Alle Baustein-Parameter (Input, Output, InOut, Static, Temp) mit ihren Typen; zeigen Sie auf einen Typ, um seinen Defaultwert zu sehen. Strukturen, PLC-Datentypen und Multiinstanzen sind zuerst zugeklappt: Klicken Sie darauf, um sie aufzuklappen, oder nutzen Sie Expand All und Collapse All oben im Reiter.
Boundaries: Automatisch generierte Min/Max/Null/Eins-Werte pro Parametertyp (mit einer Generate Boundary Cases-Aktion, die einen parametrisierten Case als neue Suite speichert)
Dependencies: Aufgerufene Bausteine, referenzierte DBs, referenzierte UDTs

Neue Test-Suite erstellen

Klicken Sie in der Titelleiste der Test-Suites-Ansicht auf New Test Suite (oder starten Sie den Befehl über die Befehlspalette)
Wenn Sie mit einem TIA-Projekt mit SPSen verbunden sind, wählen Sie die SPS, dann den getesteten Baustein — der Suite-Name wird automatisch als <Baustein>_Tests abgeleitet. (Nur wenn keine SPSen verfügbar sind, beantworten Sie stattdessen drei nacheinander erscheinende Freitext-Eingaben: den Suite-Namen, den getesteten Baustein und den PLC-Namen.)
Die neue Suite wird als <projectDir>/.tia-tests/{name}.json geschrieben und erscheint in der Test-Suites-Ansicht
Der Test-Suite-Editor öffnet sich mit einem leeren Testfall, Case_1. Fügen Sie die benötigten Variablen mit Add Input und Add Assertion hinzu: Das Feld Variable schlägt beim Tippen jedes Mitglied des Baustein-Interfaces vor, auch Mitglieder von Strukturen, PLC-Datentypen und Multiinstanzen. Das Baustein-Interface wird aus dem TIA-Projekt gelesen, sodass die Inputs- und Assertions-Grids gegen die echten Parameternamen validieren. Ein Input, den der Testfall nicht setzt, behält den Wert, den er beim Start des Testfalls in der SPS hat; setzen Sie deshalb jeden Input, von dem Ihr Test abhängt. Wenn Sie stattdessen mit Testfällen voller Grenzwerte beginnen möchten, nutzen Sie Generate from Boundaries im …-Menü.
Nutzen Sie den Visual-Modus (Form-basiert, Master-Detail) um Test-Cases via Felder und Grids hinzuzufügen / löschen / duplizieren — Name, Beschreibung, Zyklen, Tags, Priorität + Arrange-Inputs-Grid + Assertions-Grid + Watch-Liste. Über Open as JSON Text können Sie jederzeit das rohe JSON bearbeiten. Die SCL-Ansicht zeigt den generierten SCL-Testcode und ist ebenfalls bearbeitbar (siehe Suites und Testfälle verwalten)
Save (Strg+S) klicken um Ihre Änderungen zu speichern

Suite über das JSON-`name`-Feld umbenennen

Wenn Sie das name-Feld oben in der Suite-JSON ändern und Save drücken, wird die Datei auf der Disk passend umbenannt — {neuerName}.json — und der Editor-Titel aktualisiert sich im selben Schritt. Existiert bereits eine Suite mit dem neuen Namen im gleichen Ordner, bricht Save mit einer Fehlermeldung ab und lässt beide Dateien unverändert, damit Sie einen anderen Namen wählen können.

Das blockName-Feld ist davon unabhängig und identifiziert weiterhin den getesteten TIA-Baustein; ein Namens-Rename verändert es nicht.

Test-Suite-JSON-Schema

Jede .tia-tests/*.json-Datei folgt der gleichen Struktur. Top-Level-Felder:

Feld	Typ	Pflicht	Zweck
`name`	string	ja	Suite-Identifier (muss zum Dateinamen ohne `.json` passen)
`blockName`	string	ja	Exakter TIA-Bausteinname (case-sensitive)
`plcName`	string	ja	SPS-/CPU-Name im TIA-Projekt (z.B. `PLC_1`)
`config`	object	ja	Verbindungs- + Transport-Einstellungen (siehe unten)
`testCases`	array	ja	Ein Eintrag pro Test-Case (siehe unten)
`wiring`	object	nein	Welche Datenbaustein-Variable das aufrufende Programm an jeden Eingang übergibt; der Test schreibt dorthin (siehe Eingänge an das aufrufende Programm anbinden)

config (alle Felder optional, Defaults gezeigt):

Feld	Default	Zweck
`cycles`	`1`	Default-PLC-Zyklen pro Test-Case (überschreibbar pro Case via `act.cycles`)
`cycleWaitMs`	`100`	Wartezeit zwischen Sample-Reads bei `cycles > 1`
`timeoutMs`	`5000`	Hard-Timeout pro Test-Case
`instanceDbName`	`""`	Instance-DB für Lese-/Schreibzugriff; leer → `<blockName>_DB` (Siemens-Konvention)
`preferFc`	`false`	FC-Bausteine (ohne Instance-DB) tolerieren; setzen wenn das Ziel eine Function statt Function-Block ist
`transport`	`"plcSimApi"`	`"plcSimApi"` für direkte PLCSIM-Tag-API (Default); `"s7CommPlus"` verbindet direkt mit einer realen S7-Steuerung (siehe Verbindung über S7 Nativ)
`s7IpAddress`	`192.168.0.1`	S7-Verbindungsziel — wird nur verwendet wenn `preparationMode = "external"` (echte SPS). Bei PLCSIM-basierten Modi (`userPreloaded`, `tiaTcpDownload`) verbindet sich der Runner mit `plcSimIp`, unabhängig vom Transport
`s7Port`	`102`	S7-ISO-on-TCP-Port. Der Standard `102` passt zu allen Siemens-Defaults — nur ändern, wenn die SPS auf einen abweichenden TCP-Port umkonfiguriert wurde
`s7User`, `s7PasswordKeyId`	`""` / null	Anmeldedaten-Referenz (Passwort liegt im Windows Credential Manager). Nur erforderlich wenn die SPS Benutzer-Authentifizierung erzwingt — die meisten Projekte lassen das leer
`plcSimInstanceName`	`"TiaUnitTest"`	PLCSIM-Advanced-Instanzname. Wird von beiden Transports genutzt sobald `preparationMode != "external"`
`plcSimIp`	`"192.168.0.100"`	PLCSIM-Virtual-Adapter-IP. Das ist das tatsächliche S7-Verbindungsziel bei `s7CommPlus + userPreloaded/tiaTcpDownload` — auf die IP setzen, die dem Siemens PLCSIM Virtual Ethernet Adapter zugewiesen wurde, nicht auf die Projekt-IP der SPS
`preparationMode`	`"userPreloaded"`	`userPreloaded` (Default; setzt voraus dass die PLCSIM-Instanz bereits mit dem Projekt geladen läuft), `tiaTcpDownload` (compiliert + lädt herunter aus dem offenen TIA-Projekt — siehe Voraussetzungen unten), oder `external` (echte SPS; nutzt `s7IpAddress`)
`masterSecretPasswordKeyId`	null	Projekt-Master-Secret-Passwort-Referenz. Nur bei `tiaTcpDownload` erforderlich wenn das TIA-Projekt vertraulichen Konfig-Schutz nutzt. Passwort liegt im Windows Credential Manager
`autoConnectS7`	`true`	S7 vor Run-Start automatisch verbinden. Nur in fortgeschrittenen Setups auf `false` setzen, in denen ein anderer Client (WinCC, custom HMI) die Session bereits hält und der Runner durch diese Session lesen/schreiben soll
`keepInstanceAfterRun`	`false`	PLCSIM-Instanz nach dem Run weiterlaufen lassen. Wirkt ausschliesslich in `tiaTcpDownload`-Modus — `userPreloaded` und `external` verwalten die Instanz nie

Jeder Eintrag in testCases:

Feld	Typ	Pflicht	Zweck
`name`	string	ja	PascalCase-Szenario-Name (z.B. `Start_FromIdle_Runs`)
`description`	string	nein	Ein-Satz-Was-und-Warum
`arrange.inputs`	object	ja	`{ "MemberName": value, … }` — wird vor Act in die DB geschrieben
`act.cycles`	int	nein (Default `config.cycles`)	PLC-Zyklen zwischen Arrange und Assert; muss > 1 sein, damit `watch[]` feuert. Schließt sich gegenseitig mit `act.steps` aus (das `oneOf` im Schema lehnt beides am selben `act` ab)
`act.timeoutMs`	int	nein (Default `config.timeoutMs`)	Per-Case-Timeout. Deckt die gesamte `steps`-Sequenz ab, wenn `steps` gesetzt ist
`act.steps`	array	nein	Optionale geordnete Sequenz aus `write` / `wait` / `assert`-Schritten, die zwischen Arrange und den Top-Level-`assertions` läuft. Siehe Mehrstufige Schritte unten. Schließt sich gegenseitig mit `act.cycles` aus
`assertions`	array	ja	`[ { "variable": "X", "operator": "equal", "expected": v, "tolerance": t? }, … ]`
`watch`	string[]	nein	Variablen die einmal pro Zyklus während Act gesampled werden → Zeitreihen-Chart in den HTML-Berichten
`tags`	string[]	nein	Frei wählbare Labels
`priority`	string	nein	`"low"` / `"normal"` (Default) / `"high"` / `"critical"`
`requirements`	string[]	nein	Traceability-Links
`order`	int	nein	Stabile Sortier-Reihenfolge in der UI

Unterstützte operator-Werte: equal, notEqual, greaterThan, lessThan, greaterThanOrEqual, lessThanOrEqual, inRange (erwartet expected: [min, max]), inRangeExclusive, approximately, isTrue, isFalse, contains, startsWith, endsWith, matches, bitsSet, bitsClear, arrayEquals, allEqual, anyEqual, noneEqual, deepEquals. tolerance greift bei inRange, approximately, arrayEquals, allEqual, anyEqual, noneEqual und deepEquals (Default 0.0001) — nicht bei equal/notEqual; für unscharfe Real/LReal-Gleichheit approximately verwenden. expected ist vom Schema für jede Assertion erforderlich (für isTrue/isFalse einen beliebigen Wert setzen — false, true, 0 — der Runner ignoriert ihn dort).

Sicherheit — Beispielwerte sind Platzhalter. Wenn der Editor keine echten Input-/Output-Namen aus dem Baustein-Interface ableiten kann, nutzt das Beispiel sichere Defaults (Enable: false, Running: false), damit ein Klick auf Run keine Motoren, Ventile oder andere Outputs auf realer Hardware aktivieren kann. Vor jedem Lauf gegen eine reale SPS jeden arrange.inputs-Wert und jede Assertion prüfen.

Wichtig — watch[] ist das Diagnose-Array des Test-Cases, NICHT die TIA-Beobachtungstabelle. Variablen in watch werden einmal pro PLC-Zyklus während der Act-Phase gesampled (sofern act.cycles > 1) und in den HTML-Berichten als Zeitreihen-Chart gerendert. Das ist unabhängig von TIA Portals externer Beobachtungstabelle oder einer OPC-UA-Subscription.

Vollständiges Beispiel

Eine vollständige minimale Suite mit einem Test-Case der jeden Block nutzt und watch[] verwendet:

{
  "name": "FB_Motor_Tests",
  "blockName": "FB_Motor",
  "plcName": "PLC_1",
  "config": {
    "cycles": 1,
    "timeoutMs": 5000,
    "instanceDbName": "FB_Motor_DB",
    "transport": "plcSimApi",
    "autoConnectS7": true,
    "preparationMode": "userPreloaded"
  },
  "testCases": [
    {
      "name": "Start_FromIdle_RunsWithinThreeCycles",
      "description": "Prüft dass Run nach gesetztem StartCmd hochgeht; watch zeigt Verlauf.",
      "arrange": {
        "inputs": {
          "StartCmd": true,
          "Reset":    false,
          "Speed":    50.0
        }
      },
      "act": { "cycles": 5 },
      "assertions": [
        { "variable": "Run",       "operator": "equal",     "expected": true },
        { "variable": "Speed_Act", "operator": "inRange",   "expected": [49.5, 50.5] },
        { "variable": "Error",     "operator": "isFalse", "expected": false }
      ],
      "watch": ["Run", "Speed_Act", "StartCmd"],
      "tags": ["happy-path", "smoke"],
      "priority": "normal"
    }
  ]
}

Nach dem Run zeigt der Reiter Run der Test Bench pass/fail pro Assertion, und der HTML-Bericht rendert ein Zeitreihen-Chart für die drei watch-Variablen über die 5 Zyklen. Um weitere Variablen zu einem bestehenden Case hinzuzufügen: Variablennamen ans watch-Array anhängen und act.cycles auf eine sinnvolle Zahl erhöhen (3-10 ist typisch).

Mehrstufige Schritte (`act.steps`)

Wenn ein einzelnes Arrange-dann-Assert nicht ausreicht — z.B. Reset → warten → Start → warten → prüfen — act.steps statt act.cycles verwenden. Drei Step-Typen:

`type`	Pflichtfelder	Effekt
`"write"`	`inputs` (Object, gleiche Form wie `arrange.inputs`)	Schreibt die gelisteten Members additiv auf den aktuellen DB-Zustand. Nicht gelistete Members behalten ihren Wert.
`"wait"`	`ms` (int, `0`..`3 600 000`)	Async-Delay. Die SPS zykelt weiter. Wenn `watch[]` nicht leer ist und `config.cycleWaitMs > 0`, werden beobachtete Variablen alle `config.cycleWaitMs` ms während des Wait-Fensters gesampled.
`"assert"`	`assertions` (Array, gleiche Form wie Top-Level-`assertions`)	Per-Step-Checkpoint. Ein Fehler bricht den Case sofort ab und meldet `Step <N> (assert): <Grund>` (1-basiert).

Reihenfolge der Operationen:

arrange.inputs wird einmal am Case-Start geschrieben (nicht zwischen Steps wiederholt).
Jeder Eintrag in steps läuft in Deklarationsreihenfolge.
Nach dem letzten Step läuft das Top-Level-assertions[] als Final-Gate. Per-Step-Asserts und Top-Level-Asserts sind unabhängig — beide müssen passen. Das Schema verlangt minItems: 1 auf Top-Level-assertions, also mindestens eine triviale Top-Level-Assertion authoren auch wenn man primär per-Step-Asserts nutzt.
watch[] sampled durchgehend während jedem wait-Step (unter den oben genannten Bedingungen); das Time-Series-Chart annotiert Step-Grenzen.

Caps (vom Runner erzwungen):

Limit	Wert
Steps pro Case	`1024`
Inputs pro `write`-Step	`256`
Assertions pro `assert`-Step	`256`
`wait.ms`	`0`..`3 600 000` (1 Stunde)

Visual-Editor: Die Case-Detail-Ansicht zeigt einen Steps (optional)-Bereich mit + Write, + Wait, + Assert-Buttons zum Anhängen, per-Step ↑ / ↓-Buttons zum Umsortieren, und − zum Entfernen. Der Editor lässt cycles automatisch im serialisierten JSON weg, sobald der Steps-Bereich nicht leer ist (das Schema lehnt die cycles + steps-Kombination ab, der Editor produziert sie also nie).

Backwards-Kompatibilität: Ein Case ohne steps läuft den bestehenden Single-Phase-cycles-Pfad ohne Verhaltensänderung. Ältere Suites brauchen keine Migration.

Vollständiges Beispiel — getakteter Motor-Start

StartCmd wird nach einem 500 ms langen Reset-Fenster gesetzt, dann warten wir 2 s bis der FB Run erreicht, plus eine abschließende Speed-Prüfung.

{
  "name": "MotorStart_ReachesRun",
  "description": "Reset, warten, Start, warten, Run prüfen.",
  "arrange": { "inputs": { "Enable": true } },
  "act": {
    "timeoutMs": 10000,
    "steps": [
      { "type": "write", "inputs": { "Reset": true } },
      { "type": "wait",  "ms": 500 },
      { "type": "write", "inputs": { "Reset": false, "StartCmd": true } },
      { "type": "wait",  "ms": 2000 },
      { "type": "assert", "assertions": [
          { "variable": "Run", "operator": "isTrue", "expected": true }
        ]
      }
    ]
  },
  "assertions": [
    { "variable": "Speed_Act", "operator": "greaterThan", "expected": 1000 }
  ],
  "watch": ["Run", "Speed_Act"]
}

Wenn der Per-Step-assert fehlschlägt (z.B. Run ist nicht innerhalb von 2 s true geworden), gibt der Runner Step 5 (assert): variable Run is not true aus und bricht den Case ab. Wenn die Per-Step-Asserts alle passen aber das Top-Level-Speed_Act > 1000 fehlschlägt, scheitert der Case mit der Top-Level-Assertion-Message.

Im Zweifel: zuerst einen einfachen Arrange + cycles ≥ N + Assert-Case schreiben. Erst in eine steps-Sequenz konvertieren wenn die einfache Form das Timing nicht ausdrücken kann, von dem der Test wirklich abhängt.

Vorhandene Suite öffnen

Aus der Test-Suites-Ansicht: Klick auf die Suite im Baum (sie öffnet sich im Test-Suite-Editor); ein Klick auf einen ihrer Testfälle öffnet die Suite mit diesem Fall ausgewählt
Aus Schnell öffnen: Strg+P drücken und den Suite-Dateinamen unter .tia-tests/ eingeben

Wo werden Test-Suiten gespeichert?

Test-Suiten liegen in einem versteckten Ordner namens .tia-tests direkt neben Ihrer TIA-Projektdatei (*.ap21, *.ap20, …). Der AI-Assistent schreibt in denselben Ordner. Wenn noch kein Test-Ordner gewählt ist, zeigt die Test-Suites-Ansicht „Wählen Sie einen Test-Ordner, um Ihre Testsuiten zu laden." — bitte erst einen Ordner wählen.

Sie legen den Ordner selbst fest: Klicken Sie in der Titelleiste der Test-Suites-Ansicht auf Test-Ordner wählen und wählen Sie den Ordner, in dem Ihre Tests liegen. Ist ein Ordner gewählt, folgt die Test-Suites-Liste diesem Ordner — ein Projektwechsel ändert sie dann nicht; ohne gewählten Ordner folgt sie dem verbundenen TIA-Projekt. Die Wahl wird gemerkt, sodass Ihre Tests beim nächsten Start der App sofort wieder erscheinen, auch ohne TIA-Verbindung. Das hilft auch, wenn Sie Tests aus einem früheren Stand wiederfinden möchten: Wählen Sie einfach den Ordner, in dem sie liegen. Testordner-Auswahl löschen (erscheint nur, solange ein Ordner gewählt ist) leert die Auswahl wieder; zeigt der gewählte Ordner ins Leere, meldet die Ansicht "Gewählter Testordner nicht gefunden".

Die KI kann diese Test-Suite-Dateien direkt aus dem Chat heraus lesen, auflisten und bearbeiten.

Tests ausführen

Sicherstellen dass PLCSIM Advanced V3.0+ installiert ist
Die Test Bench öffnen und in ihrer Kopfzeile PLC, Baustein und Suite wählen (oder die Suite in der Test-Suites-Ansicht auswählen)
Ausführen: Run in der Kopfzeile der Test Bench klicken, in der Test-Suites-Ansicht in der Zeile einer Suite auf Run Suite klicken, Run All Test Suites aus der Titelleiste der Ansicht, oder eine Rechtsklick-Kontextmenü-Aktion
Den Live-Progress in der Statusleiste und im Reiter Run der Test Bench verfolgen
Nach dem Lauf aktualisieren sich die Status-Icons in der Test-Suites-Ansicht und Ergebnisse werden in SQLite gespeichert

Der Runner erledigt automatisch:

Erstellt eine PLCSIM Advanced Instanz (Name konfigurierbar in der Suite-JSON)
Schaltet sie ein und kompiliert das aktuelle SPS-Projekt
Verbindet einen S7-Client mit der Instanz
Schreibt die Test-Inputs, wartet die konfigurierten Zyklen, liest die Outputs, evaluiert die Assertions
Räumt die S7-Verbindung auf und deregistriert die Instanz

Laufoptionen

Der Pfeil neben Run, in der Kopfzeile der Test Bench und in der Kopfzeile des Test-Suite-Editors, öffnet die Laufoptionen. Sie sind in vier Teile gegliedert:

Scope: was ausgeführt wird. In der Test Bench: All Suites (alle Suiten im Testordner des Projekts), Suite (die in der Kopfzeile gewählte Suite) oder Failed Cases (die im letzten Lauf fehlgeschlagenen Fälle). Im Test-Suite-Editor: Suite, Failed Cases oder Selected Cases (die in der Fall-Liste ausgewählten Zeilen; bereits gewählt, wenn Zeilen ausgewählt sind). Jeder Eintrag zeigt, wie viele Suiten oder Fälle er ausführt.
Mode: Standard, Coverage, Mutation Testing oder Interface Contracts. Coverage und Mutationstest brauchen ein PLCSIM-Advanced-Ziel und eine Verbindung zu TIA Portal, die Contract-Prüfung eine Verbindung zu TIA Portal. Diese drei Modi führen eine Suite aus.
Options (nur bei Standard-Läufen):
- Flaky confirm re-run: Ein Fall, der fehlschlägt, in den letzten Läufen aber mal bestanden hat und mal nicht, wird noch einmal ausgeführt; besteht er dann, zählt er als bestanden.
- Quarantine flaky cases: Ein Fall, der fehlschlägt und in den letzten Läufen instabil war, wird als übersprungen (Quarantäne) gemeldet statt als fehlgeschlagen.
- Update snapshot baselines: Ersetzt die gespeicherten Snapshot-Baselines durch die Werte dieses Laufs. Studio fragt vorher nach. Nicht verfügbar für Suiten, die über S7 Nativ verbinden.
- Keep PLCSim instance after run: Lässt die PLCSIM-Advanced-Instanz nach dem Lauf weiterlaufen. Nur für Suiten, die das Projekt über TCP laden.
Target: wo die Suite läuft, zum Beispiel „PLCSim Advanced, PLC_SIM1 (192.168.0.5)". Change öffnet die Verbindungseinstellungen der Suite.

Ein nicht verfügbarer Eintrag ist ausgegraut; fahren Sie mit der Maus darüber, um den Grund zu sehen. Starten Sie mit der Schaltfläche unten (zum Beispiel Run Suite oder Run 2 Cases) oder mit Ctrl+Enter; Escape schliesst, ohne auszuführen. Tab wechselt zwischen den Teilen, die Pfeiltasten zwischen den Einträgen eines Teils.

Was Run sich merkt. Ein einfacher Klick auf Run führt die Suite mit Ihrer letzten Wahl von Flaky confirm re-run und Quarantine flaky cases aus; dieselbe Wahl gilt für Läufe aus der Test-Suites-Ansicht, der Befehlspalette und dem Reiter Run. Update snapshot baselines und Keep PLCSim instance after run gelten nur für den Lauf, den Sie aus den Laufoptionen starten. Haben Sie zuletzt mit Coverage oder Mutation Testing aus den Laufoptionen ausgeführt, heisst diese Schaltfläche Run (Coverage) oder Run (Mutation Testing) und wiederholt den Modus; wählen Sie einmal Standard, um wieder normal auszuführen. Der Hinweis über Run zeigt die aktuelle Wahl.

Transport auswählen

Der Transport entscheidet, wie Test-Reads und -Writes zwischen AnyAutomation Studio und der PLC übertragen werden. Sie setzen ihn in der Suite-JSON über config.transport (siehe Schema oben):

PLCSim Advanced (plcSimApi): Direkter Zugriff über die Siemens-PLCSim-API, schneller und ohne aktive S7-Session. Das ist der Default.
OPC UA: verbindet sich mit dem OPC-UA-Server einer PLC, real oder simuliert. Siehe Verbindung über OPC UA.
S7 Nativ: Verbindet sich direkt mit einer realen S7-Steuerung, die gleiche Art Verbindung wie in der PLC-Online-Ansicht. Wählen Sie dies, wenn Sie eine Suite gegen echte S7-1200/S7-1500-Hardware laufen lassen wollen. Welche Felder Sie ausfüllen und welche Rückfrage vor einem Lauf auf echte Hardware erscheint, steht unter Verbindung über S7 Nativ. In Unit Testing (Pro+-Plan) enthalten, auch in der kostenlosen Testphase.

Jede Suite wird unabhängig konfiguriert. Bei S7 Nativ hat die Suite eigene IP-Adresse, Port, Benutzernamen und Passwort, es gibt keinen geteilten Abgleich aus der PLC-Online-Ansicht.

Den Transport und alles Weitere zur Verbindung wählen Sie auf der Seite Connection Settings der Suite, beschrieben im nächsten Abschnitt. Sie können die Werte weiterhin direkt in der Suite-JSON über Open as JSON Text im Test-Suite-Editor bearbeiten.

Verbindungseinstellungen

Jede Suite hat eine eigene Seite mit ihren Verbindungseinstellungen. Sie öffnen sie auf einem dieser Wege:

Klick auf die Verbindungsart in der Kopfzeile des Test-Suite-Editors, oder Connection Settings in dessen …-Menü;
Connection Settings im …-Menü der Test Bench, für die in ihrer Kopfzeile gewählte Suite;
Rechtsklick auf eine Suite in der Test-Suites-Ansicht und Connection Settings;
Klick auf Change neben dem Ziel in den Laufoptionen;
Unit Testing: Connection Settings in der Befehlspalette, dann die Suite wählen.

Die Seite öffnet sich als Reiter mit dem Namen Connection: und dem Namen der Suite. Sie hat vier Teile:

Transport: PLCSim Advanced, OPC UA oder S7 Native. Bei PLCSim Advanced zusätzlich der Preparation Mode: User Preloaded oder TCP Download (siehe PLCSIM-Vorbereitungsmodus); External (Real PLC) ist noch nicht verfügbar.
Das Ziel des gewählten Transports:
- PLCSim Advanced: Instance (schlägt die Instanzen vor, die PLCSIM Advanced kennt), IP Address, Network Mode, Cycle Wait (ms), Auto-Connect und Keep Instance After Run. Wählen Sie einen Network Mode (TCPIPSingleAdapter, TCPIPMultipleAdapter oder Softbus), wenn PLCSim auf einem Rechner mit mehr als einer Netzwerkkarte Probleme beim Start hat; (leave unchanged) behält Ihre aktuelle PLCSim-Einstellung.
- OPC UA: siehe Verbindung über OPC UA.
- S7 Nativ: siehe Verbindung über S7 Nativ.
Master Secret (TCP Download): nur bei TCP Download, siehe Test-Läufe gegen geschützte Projekte.
Isolation: Mode ist Time-Based (Standard) oder Isolated (jeder Testfall startet aus einem bekannten Zustand). Der Reset Mode (None, Defaults oder Memory Reset) gilt für isolierte Läufe; Memory Reset braucht PLCSim Advanced. Enthält die Suite etwas, das ein isolierter Lauf noch nicht unterstützt (Stubs, mehrstufige Testfälle, Timeline-Beobachtungen, Snapshot-Assertions), listet die Seite es unter Isolation auf.

Solange die Seite offen ist, behält ein Wechsel des Transports, was Sie für die anderen Transporte eingetragen haben, sodass Sie ohne erneutes Eintippen zurückwechseln können. Beim Speichern landen nur die Einstellungen des gewählten Transports in der Suite.

Passwörter. Die Seite zeigt nie ein Passwort, nur ob eines gespeichert ist: Set (remembered), Set (this session only), Not available, enter it again oder (not set). Mit Change geben Sie ein neues Passwort ein und wählen dann Remember (OS secret store), um es auf diesem Rechner für spätere Läufe zu behalten, oder This session only, um es bis zum Schliessen von Studio zu behalten. Clear entfernt das Passwort beim Speichern; Undo nimmt Change oder Clear zurück. Ein Passwort, das Sie nicht ändern, bleibt beim Speichern erhalten. Ändern Sie die Serveradresse, den Port oder den Benutzer einer Verbindung, fragt Studio erneut nach dem Passwort. Verwendet der gewählte Transport ein gespeichertes Passwort nicht mehr, zeigt die Seite Removed on save because the transport does not use it, und beim Speichern wird es von diesem Rechner entfernt. Passwörter werden nie in die Suite-Datei geschrieben, sodass Sie eine Suite weitergeben oder einchecken können, ohne sie offenzulegen.

Test Connection prüft die Einstellungen auf der Seite, bevor Sie sie speichern. Das Ergebnis erscheint neben der Schaltfläche:

PLCSim Advanced braucht eine Verbindung zu TIA Portal. Die Prüfung zeigt, ob der PLCSIM Advanced Runtime Manager läuft und ob die Instanz existiert. The run powers the instance on. heisst, die Instanz ist vorhanden, aber ausgeschaltet; der Lauf startet sie. Bei TCP Download ist eine noch nicht vorhandene Instanz in Ordnung (The run creates the instance.); bei User Preloaded wird sie als Problem gemeldet, weil der Lauf eine leere Instanz starten würde.
OPC UA verbindet sich einmal mit dem Server und meldet Reachable (the server certificate is not checked). zusammen mit dem erkannten Namespace-Index. Eine offene Verbindung im Reiter Address Space bleibt bestehen. Wie ein Testlauf akzeptiert die Prüfung das Serverzertifikat ohne Rückfrage.
S7 Native hat keine Prüfung; jeder Lauf fragt vor dem Verbinden mit der Steuerung nach Ihrer Bestätigung.

Speichern. Save (oder Ctrl+S) schreibt die Einstellungen in die Suite. Save as Default behält sie zusätzlich, ohne Passwörter, als Ausgangspunkt für neue Suiten: Jede Suite, die Sie danach erstellen, aus der Test Bench, der Befehlspalette oder mit dem Assistenten, startet mit dieser Verbindung. Cancel verwirft Ihre Änderungen und schliesst die Seite. Ein Feld mit einem Problem wird mit dem Grund markiert, und Save bleibt gesperrt, bis es behoben ist.

Ist die Suite zugleich mit ungespeicherten Änderungen im Test-Suite-Editor offen, behält der Editor diese und speichert sie beim nächsten Speichern zusammen mit der neuen Verbindung. Ändert sich die Suite-Datei auf der Festplatte, während die Seite ungespeicherte Änderungen hat, bietet eine Leiste Reload (Einstellungen aus der Datei übernehmen) oder Keep My Changes an.

Verbindung über OPC UA

Eine Test-Suite kann neben PLCSim Advanced auch über OPC UA gegen eine PLC laufen. Öffnen Sie die Connection Settings der Suite (siehe Verbindungseinstellungen) und wählen Sie unter Transport den Eintrag OPC UA.

Für eine OPC-UA-Verbindung geben Sie an:

Endpoint URL: die Adresse des OPC-UA-Servers der PLC, zum Beispiel opc.tcp://192.168.0.5:4840.
Security Mode: None, Sign oder Sign & Encrypt. Wählen Sie den Modus, den Ihr Server akzeptiert; Sign & Encrypt bietet den höchsten Schutz.
Authentication: entweder Anonymous oder User Name & Password. Bei User Name & Password tragen Sie die Anmeldedaten ein, die Ihre PLC erwartet. Das Passwort wird sicher auf Ihrem Rechner abgelegt und nie in die Testdatei geschrieben, sodass Sie eine Suite weitergeben oder einchecken können, ohne es offenzulegen.
Namespace Index: Lassen Sie das Feld leer, dann erkennt Studio den richtigen Namespace auf der Steuerung automatisch; das ist der Normalfall. Geben Sie nur bei einem ungewöhnlichen Server eine Zahl an, bei dem die automatische Erkennung ihn nicht findet.

Wenn Sie sich zum ersten Mal mit einem Server verbinden, dessen Zertifikat AnyAutomation Studio noch nicht vertraut, erscheint eine Rückfrage zur Bestätigung der Verbindung. Wählen Sie Connect Anyway, um diesem Server zu vertrauen und fortzufahren; beim nächsten Lauf erscheint die Rückfrage für diesen Server nicht erneut.

Variablen der PLC über OPC UA erreichbar machen. Damit Tests Ihre Variablen lesen und schreiben können, müssen die betroffenen Datenbausteine über den OPC-UA-Server der PLC zugänglich sein. Aktivieren Sie in Ihrem TIA-Portal-Projekt den OPC-UA-Zugriff für die betreffenden Datenbausteine und laden Sie es in die PLC, bevor Sie die Suite ausführen. Variablen, die nicht freigegeben sind, können nicht gelesen oder geschrieben werden, und die betroffenen Testfälle schlagen fehl.

Adressraum durchsuchen

Im Reiter Address Space der Baustein-Spalte der Test Bench können Sie erkunden, was ein OPC-UA-Server anbietet, bevor Sie Tests schreiben oder ausführen. Die erste Zeile des Reiters enthält die Serveradresse. Läuft die in der Kopfzeile gewählte Suite über OPC UA, ist deren Adresse bereits eingetragen; sonst die zuletzt verwendete.

Beliebiger Server: Tippen Sie eine Adresse wie opc.tcp://192.168.0.5:4840. In der zweiten Zeile wählen Sie Message Security Mode (None, Sign, Sign and Encrypt) und Authentication (Anonymous oder Username and Password mit User Name und Password). Ein hier eingetipptes Passwort gilt nur für diese Verbindung und wird nicht gespeichert.
Der Server Ihrer OPC-UA-Suite: Ist die Adresse die der Suite in der Kopfzeile, zeigt die zweite Zeile stattdessen Suite settings; beim Überfahren sehen Sie Sicherheit und Anmeldung, die die Suite verwendet. Studio verbindet sich damit und mit dem für diese Suite gespeicherten Passwort, ohne nachzufragen. Ist dafür kein Passwort gespeichert oder lehnt der Server Benutzernamen oder Passwort ab, fragt Studio direkt in dieser Zeile nach dem Passwort; es gilt nur für diese Sitzung und wird nie gespeichert.

Klicken Sie auf Connect oder drücken Sie in einem beliebigen Feld Enter; Disconnect beendet die Verbindung. Der Adressraum wird als Baum dargestellt, den Sie aufklappen können, um durch die verfügbaren Knoten zu navigieren und zu sehen, welche Variablen erreichbar sind. Nutzen Sie ihn, um den Namen einer Variablen zu bestätigen und sicherzustellen, dass sie über OPC UA freigegeben ist, damit Ihre Testfälle die richtigen Elemente ansprechen. Strukturierte Variablen (PLC-Datentypen, Structs und Arrays) zeigen den Namen ihres Datentyps, zum Beispiel typMotor oder Array of Bool, und lassen sich bis zu ihren Elementen aufklappen, sodass Sie zu dem Element gelangen, das ein Testfall liest oder schreibt. Im Testfall sprechen Sie ein solches Element über seinen Pfad an, zum Beispiel DB_Motor.Setpoints[3] oder DB_Motor.StartTimer.Q.

Schreiben und Ausführen über OPC UA

Sobald die Verbindung eingerichtet ist, verhalten sich OPC-UA-Suiten genau wie PLCSim-Suiten. Sie schreiben Testfälle auf dieselbe Weise, führen sie mit denselben Aktionen Run Test Suite / Run All Test Suites aus, verfolgen denselben Live-Progress und erhalten dieselben Ergebnisse und dieselbe Lauf-Historie. Der einzige Unterschied liegt darin, wohin sich die Tests verbinden — und Sie brauchen TIA Portal nicht geöffnet, um sie zu schreiben oder auszuführen.

Für Pipelines und CI läuft eine für OPC UA konfigurierte Suite auch in der erzeugten Pipeline. Da das OPC-UA-Passwort nicht in der Testdatei gespeichert ist, übergeben Sie das OPC-UA-Passwort an den Pipeline-Lauf, damit der Build-Server sich ohne anwesende Person verbinden kann.

Verbindung über S7 Nativ

Eine Test-Suite kann auch über S7 Nativ direkt gegen eine reale S7-Steuerung laufen. Öffnen Sie die Connection Settings der Suite (siehe Verbindungseinstellungen) und wählen Sie unter Transport den Eintrag S7 Native. Dieser Verbindungstyp ist in Unit Testing (Pro+-Plan) enthalten, auch in der kostenlosen Testphase.

Für eine S7-Nativ-Verbindung geben Sie an:

IP-Adresse: die Adresse der Steuerung, zum Beispiel 192.168.0.10.
Port: der TCP-Port der Steuerung. Voreingestellt ist 102, was zu den meisten Steuerungen passt. Ändern Sie ihn nur, wenn Ihre Steuerung auf einen abweichenden Port eingestellt wurde.
Benutzername (optional): nur nötig, wenn Ihre Steuerung eine Benutzer-Anmeldung verlangt. Die meisten Projekte lassen das Feld leer.
Passwort: das Passwort, das Ihre Steuerung erwartet. Es wird sicher auf Ihrem Rechner abgelegt und nie in die Testdatei geschrieben, sodass Sie eine Suite weitergeben oder einchecken können, ohne es offenzulegen.

Mit Save as Default auf der Seite werden diese Werte, ohne das Passwort, zum Ausgangspunkt für neue Suiten, sodass Sie sie nicht jedes Mal erneut eintragen müssen.

Schreiben und Ausführen über S7 Nativ

Sobald die Verbindung eingerichtet ist, schreiben Sie Testfälle auf dieselbe Weise wie bei einer PLCSim-Suite und führen sie mit denselben Aktionen Run Test Suite / Run All Test Suites aus. Der einzige Unterschied liegt darin, wohin sich die Tests verbinden: Eine S7-Nativ-Suite verbindet sich direkt mit der angegebenen Steuerung, schreibt die Test-Inputs auf die laufende Steuerung und prüft die Ergebnisse dort.

Weil ein Lauf auf echte Hardware schreibt, erscheint vor dem Start eine Rückfrage zur Bestätigung. Bestätigen Sie sie erst, wenn die Anlage in einem sicheren Testzustand ist, dann startet der Lauf. Brechen Sie die Rückfrage ab, geschieht nichts.

Sie können auch gegen eine Sicherheitssteuerung (F-CPU) laufen. Die Rückfrage warnt Sie, dass das Ziel eine Sicherheitssteuerung sein könnte und dass Sie vor dem Fortfahren sicherstellen müssen, dass die Steuerung gefahrlos manipuliert werden kann und die Anlage in einem sicheren Testzustand ist. Es gibt keine automatische Sperre: Sie entscheiden, ob Sie bestätigen oder abbrechen.

Simulation-Arbeitsbereich

Geplant für den In-App-Arbeitsbereich. Eine eigene Simulation-Ansicht zur Verwaltung von PLCSim-Advanced-Instanzen direkt in AnyAutomation Studio ist geplant. Die Fähigkeiten, die sie bereitstellen würde, sind unten beschrieben.

Eine Simulation-Ansicht zur Verwaltung von PLCSim-Advanced-Instanzen würde zeigen:

API-Version, Online-Zugriffsmodus (PLCSim / TCP/IP einzeln / TCP/IP mehrfach), Strict-Motion-Timing-Toggle und Runtime-Manager-Port.
Eine Virtueller Adapter-Zeile mit dauerhaftem Status des Siemens PLCSIM Virtual Ethernet Adapters (Bereit / APIPA / Deaktiviert / Nicht installiert / Keine IPv4), seiner IPv4-Adresse und einem Refresh-Button. Wenn der Adapter im 169.254.x.y-APIPA-Bereich hängt, werden Downloads unzuverlässig — weisen Sie ihm in den Windows-Netzwerkeinstellungen eine statische IPv4-Adresse zu.
Jede registrierte PLCSim-Instanz mit Inline-Buttons: Einschalten, Run, Stop, Memory-Reset, Ausschalten, Einstellungen, Netzwerk, Löschen. Jede Zeile zeigt die konfigurierte IP-Adresse; hat die Instanz mehrere Schnittstellen mit einer IP, werden diese als X1: 192.168.0.1, X2: 10.0.0.5 aufgelistet.
Eine TIA-PLC-ComboBox pro Instanz-Card: Wählen Sie die TIA-Portal-PLC, die der Instanz zugrunde liegt. Nötig, sobald die PLCSim-Instanz mit einem Snapshot beladen wurde, der aus einer anderen TIA-PLC kompiliert wurde als unter der die Instanz registriert ist (Beispiel: eine Instanz mit Namen PLC_2, die aber das Programm aus PLC_1 enthält). Ohne explizite Wahl gleicht die App per Name ab und greift auf die einzige PLC im Projekt zurück, wenn nur eine vorhanden ist — ausreichend für die meisten Setups, liefert aber einen leeren Tag-Baum, wenn die Namen nicht übereinstimmen. Die Auswahl wird pro Instanz gemerkt.
Einen Neue Instanz-Button, der nach Name und CPU-Typ fragt.
Ein Tag-Browser-Panel, das sich mit jeder Instanz verbinden und alle Tags des laufenden Programms anzeigen kann — filterbar nach Namensuche, Bereich (Eingang / Ausgang / Merker / Datenbaustein) und Datentyp. Auto-Refresh kann für Live-Wertebeobachtung aktiviert werden. Jeder schreibbare Tag hat einen Bleistift-Button, der einen typ-spezifischen Write-Dialog öffnet (Schalter für Bool, numerische Eingabe mit passendem Bereich für Ganzzahlen und Gleitkomma, Ein-Zeichen-Feld für Char/WChar). String-Tags sind read-only. Struct-Tags und Array-Tags werden mit ihren inneren Membern und Elementen als ausklappbare Zeilen aufgelistet, sodass einzelne Felder wie OUT[5] oder DI10.Channel direkt durchsucht, beobachtet und geschrieben werden können; die Toolbar-Buttons Alle ausklappen und Alle einklappen schalten den gesamten Baum auf einmal um. Strukturierte Eingangs-/Ausgangs-Tags, deren Layout aus einer Projekt-Typdefinition stammt (zum Beispiel ein PNPN-Block an %I0.0, deklariert als Array[0..63] of Byte), klappen in benannte Member-Zeilen auf, sobald die App mit dem TIA-Portal-Projekt verbunden ist, das sie definiert — sodass IN.PNPN[12] aus demselben Dialog beschrieben werden kann, der auch den Rest des Baums verarbeitet.
Eine Gespeicherte Instanzen-Sektion am unteren Rand, die jede PLCSim-Advanced-Instanz auflistet, die auf der virtuellen SIMATIC Memory Card persistiert ist. Neben der Überschrift zeigt ein Zähler die Gesamtzahl gespeicherter Instanzen; die Liste zeigt maximal drei Zeilen gleichzeitig und scrollt bei mehr, damit der Simulationsbereich darüber sichtbar bleibt. Klicken Sie Laden, um eine solche Instanz erneut zu registrieren und fortzuführen — PLCSim übernimmt automatisch den gespeicherten CPU-Typ, das E/A-Abbild und das Programm. Klicken Sie Löschen (mit Bestätigung), um den persistierten Ordner zu entfernen.

Die Ansichts-Auswahl würde zwischen Sitzungen gemerkt, und der Wechsel behält alle geöffneten Suite-Editoren.

PLCSIM-Vorbereitungsmodus

Der Vorbereitungsmodus steuert, wie der Runner das Projekt vor dem Testlauf bereitstellt. Sie wählen ihn auf der Seite Connection Settings der Suite oder in der Suite-JSON über config.preparationMode:

Ich lade selbst (userPreloaded, empfohlen) — Der Runner erwartet, dass Sie die PLCSIM-Instanz bereits manuell via TIA Portal gestartet und das Projekt geladen haben. Compile und Download werden übersprungen, der Runner verbindet sich direkt und führt die Tests aus. Schnellste Option für wiederholte Läufe am selben Projekt.
Automatischer TCP-Download (tiaTcpDownload) — Der Runner kompiliert das Projekt, startet eine frische PLCSIM-Instanz und lädt es via TCP über den PLCSIM Virtual Adapter. Keine manuelle TIA-Portal-Interaktion nötig — einfach ausführen.
Reale PLC (kein PLCSim) (external) — Überspringt den PLCSim-Lebenszyklus komplett und würde einen Lauf gegen echte S7-Hardware ganz ohne PLCSim-Instanz vorbereiten. Dieser Vorbereitungsmodus ist in der App noch nicht verfügbar. Er ist eine eigene, geplante Option und nicht dasselbe wie die S7-Nativ-Verbindung: Um heute gegen eine reale Steuerung zu laufen, wählen Sie stattdessen den Verbindungstyp S7 Nativ (siehe Verbindung über S7 Nativ und Tests gegen reale PLC ausführen).

Vor der Verwendung von Automatischem TCP-Download: Vier Voraussetzungen müssen erfüllt sein, sonst schlägt der Run mit einem generischen Transport-Fehler fehl: (1) der PLCSIM Virtual Adapter muss installiert sein und eine statische IPv4-Adresse haben, die zur plcSimIp der Suite passt; (2) das TIA-Portal-Projekt muss in TIA Portal geöffnet sein — der Runner stösst vor dem Download eine Compile-Aktion gegen das offene Projekt an; (3) bei aktiviertem Vertraulichen Konfig-Schutz muss das Master-Secret-Passwort bereitgestellt werden (liegt im Vault); (4) eine bestehende PLCSIM-Instanz mit demselben Namen wird bei jedem Run zerstört und neu angelegt, sodass andere Anwendungen, die mit dieser Instanz verbunden sind, ihre Session verlieren.

Tests gegen reale PLC ausführen

Sie können Tests direkt gegen echte S7-1200/S7-1500-Hardware ausführen, über eine S7-Nativ-Verbindung und ganz ohne PLCSim:

Stellen Sie sicher, dass die Anlage im sicheren Testzustand ist: Aktoren freigeschaltet oder verriegelt, keine Produktionslast auf der PLC, Bediener informiert.
Wählen Sie auf der Seite Connection Settings der Suite unter Transport den Eintrag S7 Native und tragen Sie IP-Adresse, Port sowie (nur falls die Steuerung das verlangt) Benutzernamen und Passwort ein. Die Details stehen unter Verbindung über S7 Nativ.
Führen Sie die Suite aus der Test-Suites-Ansicht aus.
Bevor die Tests die Steuerung erreichen, erscheint eine Rückfrage zur Bestätigung des Laufs auf echter Hardware. Bestätigen Sie sie, sobald die Anlage im sicheren Testzustand ist, dann startet der Lauf.

Einige Punkte zu Läufen gegen eine echte Steuerung:

Falsche Anmeldedaten: Nimmt die Steuerung die Verbindung an, lehnt aber Ihre Anmeldung ab, stoppt der Lauf sofort mit einem Hinweis, Benutzernamen und Passwort zu prüfen, statt später mit einem verwirrenden „Variable nicht gefunden" zu scheitern.
Batch-Läufe: Eine auf eine S7-Nativ-Verbindung gestellte Suite wird bei Run All Test Suites übersprungen (die Pro-Suite-Rückfrage lässt sich aus einem Batch-Lauf nicht anzeigen) und in einem schliessbaren Banner namentlich aufgeführt, sodass Sie jede einzeln ausführen.
Steuerung muss laufen: Ein Lauf gegen eine echte Steuerung prüft zuerst deren Betriebszustand und stoppt, wenn sie nicht in RUN ist, sodass nichts geschrieben wird, solange das Programm nicht läuft.

Sicherheitssteuerungen (F-CPU). Wenn Sie interaktiv ausführen, können Sie eine Sicherheitssteuerung (F-CPU) ansprechen: Die Rückfrage warnt Sie, dass das Ziel eine Sicherheitssteuerung sein könnte und dass Sie sicherstellen müssen, dass die Steuerung gefahrlos manipuliert werden kann und die Anlage in einem sicheren Testzustand ist, und Sie entscheiden, ob Sie bestätigen oder abbrechen. Bei KI-gestützten Läufen ist es anders: Der Assistent führt von sich aus keine Tests gegen Safety-Logik aus, einen Lauf gegen eine Sicherheitssteuerung starten Sie also immer selbst.

Test-Läufe gegen geschützte Projekte

Wenn Ihr TIA-Projekt „Schutz vertraulicher PLC-Konfigurationsdaten" aktiviert hat, erfordert der Automatischer-TCP-Download-Modus das Master-Secret-Passwort des Projekts:

Auf der Seite Connection Settings der Suite PLCSim Advanced und den Vorbereitungsmodus TCP Download wählen
Unter Master Secret (TCP Download) auf Change klicken und das Master-Secret-Passwort des Projekts eingeben
Remember (OS secret store) wählen, damit jeder spätere Lauf es ohne Nachfrage verwendet, oder This session only, um es bis zum Schliessen von Studio zu behalten, dann Save klicken
Die Suite ausführen

Die Seite zeigt danach Set (remembered) oder Set (this session only). Lassen Sie es so, um das gespeicherte Passwort zu behalten; Clear entfernt es beim Speichern. Ist beim Start eines Laufs kein Passwort verfügbar, fragt Studio danach und behält es für die laufende Sitzung.

Das Passwort wird nie in die Suite-Datei, in Logs oder Einstellungs-Dateien geschrieben. Es lebt ausschliesslich im Windows Credential Manager unter dem Servicenamen com.anyautomationstudio und wird vom Dialog zum Runner über einen benutzergebundenen DPAPI-Kanal übertragen, sodass ein anderer Windows-Benutzer es nicht lesen kann.

Eingänge an das aufrufende Programm anbinden (Beschaltung)

Viele Bausteine werden nicht mit festen Werten aufgerufen, sondern mit Variablen eines Datenbausteins, zum Beispiel "idb_FB_MotorControl"(bStart := "dbMotorControl".Control.Start, ...). Das aufrufende Programm übergibt diese Variablen dem Baustein in jedem Zyklus. Ein Wert, den ein Test direkt in die eigenen Daten des Bausteins schreibt, würde im nächsten Zyklus wieder überschrieben, und der Test meldet einen Fehler oder ein falsches Ergebnis. Die Beschaltung sagt dem Test, woher das Programm jeden Eingang nimmt: der Test schreibt seine Werte dorthin, und der Baustein erhält sie genauso wie im Betrieb.

Beschaltung festlegen

Öffnen Sie die Suite im Test-Suite-Editor und wählen Sie einen Testfall. Im unteren Teil hat die Tabelle INPUTS des Falls neben dem Wert jedes Eingangs die Spalte Written to. Die Kopfzeile der Tabelle nennt den Instanz-DB des Bausteins und wie viele Eingänge beschaltet sind.
Prüfen Sie den Instanz-DB mit Choose Instance DB... in der Kopfzeile der Tabelle. Er nennt den Datenbaustein, den das Programm für diese Bausteininstanz verwendet; Sie können den Namen auch eintippen.
Klicken Sie für jeden Eingang, den das Programm übergibt, in seiner Zeile auf Choose from DB..., wählen Sie den Datenbaustein und dann die Variable darin. Variablen mit dem Typ des Eingangs stehen zuoberst. Sie können die Variable auch in das Feld Written to tippen, zum Beispiel "dbControl".Setpoints.rSpeedSetpoint; ein Element eines Arrays wie "UI_MSG".Messages[3].diMsgID funktioniert genauso. Clear wiring entfernt sie wieder; ein Eingang ohne Beschaltung wird wie bisher in den Instanz-DB geschrieben.
Speichern Sie die Suite. Die Beschaltung gehört zur Suite: derselbe Eingang wird in jedem Testfall in dieselbe Variable geschrieben, Sie legen sie also einmal fest und sehen sie in jedem Fall.

Das sollten Sie wissen

Eingänge, die das Programm mit einem festen Wert, einer Berechnung oder einer temporären Variable versorgt, kann ein Test nicht setzen. Lassen Sie sie unbeschaltet und aus Ihren Testfällen weg; der Wert des Programms bleibt wirksam.
Sobald der Baustein beschaltet ist, erreichen ihn seine deklarierten Startwerte nicht mehr. Schreiben Sie in jedem Testfall alle Eingänge, von denen der Fall abhängt.
Beschaltete Werte bleiben von einem Testfall zum nächsten im Datenbaustein stehen. Eingänge, die auf eine steigende Flanke reagieren, etwa ein Startbefehl, brauchen eine ausdrückliche Abfolge in Mehrphasen-Schritten: FALSE schreiben, warten, TRUE schreiben.
Vor dem Lauf liest Studio die aktuellen Werte aller beschalteten Variablen und schreibt sie nach dem Lauf zurück, damit das Programm mit den Werten weiterläuft, die es vor dem Test hatte.
Wird eine beschaltete Variable auf der Steuerung nicht gefunden, bricht der Lauf vor dem ersten Testfall ab und nennt die Variable. Prüfen Sie den Namen des Datenbausteins, den Pfad der Variable und bei OPC UA, ob der Datenbaustein für OPC UA zugänglich ist.
Nur Ausgänge werden weiterhin aus dem Instanz-DB gelesen. Eine Beschaltung eines Ausgangs hat keine Wirkung auf den Lauf.
Der Assistent kann die Beschaltung für Sie setzen: er schlägt im Projekt nach, wie der Baustein aufgerufen wird, beschaltet jeden Eingang entsprechend und nennt Ihnen die Eingänge, die das Programm fest vorgibt (siehe KI-erstellte Test-Suiten).

Klicken Sie im Test-Suite-Editor auf Validieren, um jeden Variablennamen und jede Beschaltung gegen den Baustein zu prüfen, Gross- und Kleinschreibung eingeschlossen. Probleme erscheinen über der Fall-Liste, und Speichern und Ausführen bleiben gesperrt, bis sie behoben sind. Eine Suite mit ungültiger Beschaltung startet nicht.

Suites und Testfälle verwalten

Eine Suite umbenennen, indem Sie das JSON-name-Feld oben in der Suite ändern und Save drücken — die Datei wird auf der Disk passend umbenannt (siehe Suite über das JSON-name-Feld umbenennen). Zum Löschen einer Suite die zugehörige .json-Datei aus dem .tia-tests/-Ordner entfernen.
Einen Testfall bearbeiten im Visual-Modus des Test-Suite-Editors: Jede Case-Zeile erlaubt Umbenennen, Beschreibung ändern, Duplicate, Entfernen sowie das Umsortieren der mehrstufigen Schritte über Move Up / Move Down.
Den generierten SCL-Testcode bearbeiten in der SCL-Ansicht des Test-Suite-Editors: Testfälle umbenennen, Eingangswerte ändern, Assertions bearbeiten, ergänzen oder entfernen sowie ganze Testfall-Blöcke hinzufügen oder löschen. Änderungen fliessen automatisch in die Testfälle zurück, die Visual- und JSON-Ansicht zeigen sie sofort. Angaben, die im SCL-Text nicht vorkommen (Beschreibung, Zyklen, mehrstufige Schritte, Toleranz, Watch-Liste, Tags, Priorität, Verantwortlicher, Anforderungen), bleiben erhalten. Der Runner-Baustein am Ende wird automatisch nachgeführt, Änderungen daran haben keine Wirkung. Passt der Text nicht mehr zur Struktur der Testbausteine, erscheint eine Fehlermeldung mit Zeilennummer; Save und Import to TIA bleiben blockiert, bis sie behoben ist. Beim Wechsel zu einem anderen Editor-Tab wird noch nicht übernommener SCL-Text verworfen, bereits übernommene Änderungen bleiben erhalten.
Verbindungseinstellungen gelten pro Suite. Transport, PLCSim-Instanzname, IP-Adresse, Zyklus-Wartezeit, S7-Comm+-Ziel (IP, TCP-Port, Benutzer, Passwort) und Auto-Connect liegen alle im config-Block der Suite-Datei. Sie werden mit der Suite gespeichert, sodass beim nächsten Öffnen dieselben Werte wirken. Passwörter bleiben weiterhin im Windows Credential Manager; die Suite-Datei speichert nur eine Referenz, nie ein Klartext-Passwort. (Die Seite Connection Settings der Suite setzt diese ohne JSON-Bearbeitung, siehe Verbindungseinstellungen.)
Klicken Sie im Test-Suite-Editor auf Validieren, um jeden Variablennamen und jede Beschaltung gegen den Baustein zu prüfen, Gross- und Kleinschreibung eingeschlossen. Probleme erscheinen über der Fall-Liste, und Speichern und Ausführen bleiben gesperrt, bis sie behoben sind.
Schlägt ein Testfall fehl, erscheint seine Meldung in der Spalte Message des Reiters Run, und der Abschnitt Assertions markiert die fehlgeschlagene Assertion neben Erwartet- und Tatsächlich-Wert. Ein Doppelklick auf den Fall öffnet ihn im Test-Suite-Editor.
Wird eine Suite-Datei extern geändert — oder über das JSON-name-Feld oben umbenannt — lädt der offene Editor sie automatisch neu. Sind jedoch noch ungespeicherte Änderungen vorhanden, bleiben diese erhalten.

Fehlerbehebung

Status-Icons aktualisieren sich nicht nach einem Lauf: Prüfen ob der Suite-Dateipfad korrekt ist (absoluter Pfad unter .tia-tests/). Neue ungespeicherte Suites bekommen pro Klick einen eindeutigen Pfad.
Run-Aktion nicht verfügbar: Ein TIA-Projekt muss geöffnet sein, und das aktive Suite-Dokument muss valides JSON sein.
Test Explorer ist leer: Das Arbeitsverzeichnis hat noch keinen .tia-tests/ Ordner. New Test Suite klicken um die erste Suite zu erstellen — der Ordner wird automatisch angelegt.
PLCSIM-Fehler: Prüfen ob PLCSIM Advanced V3.0+ installiert und lizenziert ist. Die genaue Version wird zur Laufzeit automatisch erkannt.
TLS-Verkehr für den Support aufzeichnen (fortgeschritten): Wenn der Support einen Wireshark-Mitschnitt des S7-Comm+-Handshakes braucht, die Umgebungsvariable SSLKEYLOGFILE vor dem Start der App auf einen absoluten Dateipfad setzen — z.B. setx SSLKEYLOGFILE "C:\Temp\s7-keys.log" — und anschliessend neu starten. In Wireshark die TLS-Einstellung (Pre)-Master-Secret log filename auf dieselbe Datei zeigen lassen. Solange die Variable gesetzt ist, wird bei jeder Verbindung eine Warnung ins App-Log geschrieben, damit sie nicht vergessen wird. Im Normalbetrieb die Variable leer lassen.

KI-geschriebene Test-Suites (Pro+)

Der AI-Chat kann komplette SCL-Unit-Test-Suites für Sie entwerfen, verfeinern und (optional) ausführen. Benötigt eine Pro+-Lizenz oder höher.

Skill „Write Unit Tests" (Hauptchat)

AI Chat öffnen und im Skill-Picker den Skill Write Unit Tests auswählen (🧪-Icon) — oder einfach fragen: „schreib Unit-Tests für FB_MotorControl"
Der Assistent liest das Baustein-Interface, berechnet Grenzwerte, plant Testfälle und fasst den Plan im Chat zusammen — ohne riesige JSON-Blöcke
Wenn er die Suite schreiben möchte, erscheint im Chat eine Bestätigungskarte. Allow lässt den Assistenten die Suite nach .tia-tests/ speichern; mit Allow in this Session auf der Karte fragt er für den Rest der Chat-Sitzung nicht mehr nach
Wenn Sie den Assistenten gebeten haben, die Suite auch auszuführen, fragt eine zweite Karte vor dem Lauf selbst. Die Ergebnisse kommen als Pass/Fail-Zusammenfassung zurück in den Chat, und der Assistent bietet an, fehlgeschlagene Testfälle nachzubessern
Die Test-Suites-Ansicht übernimmt die neue Suite automatisch — öffnen, im Visual-Modus oder als JSON-Text prüfen und nach Wunsch selbst laufen lassen
Nach dem Anlegen können Sie auch direkt „öffne die Suite" schreiben — die Suite wird im Test-Suite-Editor geöffnet, ohne dass Sie zur Test-Suites-Ansicht wechseln müssen

Den Assistenten eine geöffnete Suite bearbeiten lassen

Ist eine Suite im Test-Suite-Editor geöffnet, können Sie den Assistenten im AI Chat bitten, sie zu ändern, zum Beispiel „füg einen Overflow-Test für Counter_Value hinzu" oder „setz die Toleranz aller REAL-Assertions auf 0.01".

Der Assistent liest die geöffnete Suite und legt seine Änderung zur Prüfung bereit. Der Editor zeigt eine Leiste: „AI edits are staged for review. Keep them to apply, or Undo to discard."
Klicken Sie im Editor auf JSON, um die Suite vor und nach der Änderung zu vergleichen; der Vergleich öffnet sich bei der ersten Änderung.
Macht der Assistent mehrere Änderungen nacheinander, summieren sie sich und erscheinen alle im selben Vergleich.
Keep übernimmt alle bereitgelegten Änderungen (speichern Sie die Suite danach wie gewohnt), Undo verwirft sie alle.

Der Assistent prüft Variablennamen und Typen gegen den echten Baustein, sodass Abweichungen auffallen, bevor Sie eine Änderung übernehmen. Tippen Sie nicht in der Suite, solange eine Änderung bereitliegt: Keep übernimmt die Fassung des Assistenten.

Festlegen, welche Werkzeuge des Assistenten handeln dürfen. Im AI Chat listet Open Customizations, Tool Approvals die Unit-Test-Werkzeuge als Gruppe unit-tests. Für jedes Werkzeug, das schreibt oder ausführt (zum Beispiel eine Suite anlegen oder löschen, eine geöffnete Suite bearbeiten oder eine Suite ausführen), wählen Sie, ob jedes Mal gefragt wird, ob es immer erlaubt oder immer abgelehnt ist; ein abgelehntes Werkzeug bleibt gesperrt, auch wenn der Chat Werkzeuge automatisch bestätigt. Werkzeuge, die nur lesen, fragen nie.

KI-geschriebene Testfälle prüfen

Die App vermerkt bei selbst erstellten Testfällen die KI-Herkunft (intern gespeichert), zeigt aber heute kein sichtbares AI-Abzeichen im Test-Explorer-Baum oder im Visual-Editor — nur ein Theory (N rows)-Abzeichen erscheint bei parametrisierten Fällen.

Überprüfen Sie KI-geschriebene Testfälle wie einen Pull Request von einer Kollegin — jede Assertion lesen, erwartete Werte plausibilisieren, erst am Simulator laufen lassen und dann auf echter Hardware.

Safety-Schutz (F-CPU)

Das KI-gestützte Schreiben von Tests ist für Safety-Bausteine abgesichert:

Tests erstellen — Der Assistent verweigert das Schreiben von Tests für einen F-CPU-Baustein ohne eine explizite Bestätigung im Gespräch. Auch die darunterliegenden Tools lehnen den Schreibvorgang ohne diese Bestätigung ab
Tests ausführen — Der Assistent kann keine Tests gegen Safety-Bausteine laufen lassen. Punkt. Kein Override. Safety-Baustein-Verifikation erfordert eine zertifizierte Methodik (TÜV/CE), keinen KI-Run. Wenn Sie einen Test gegen einen Safety-Baustein laufen lassen wollen, starten Sie den Run selbst aus dem Test Explorer

Lizenzierung

Der Skill „Write Unit Tests" und die Unit-Test-Tools im KI-Chat erfordern Pro+ oder höher. Auf einem niedrigeren Plan zeigt der Skill vor jedem KI-Call eine Lizenz-Meldung.

CI/CD-Integration

Das Kommandozeilen-Werkzeug tia-test-runner führt Ihre SCL-Unit-Test-Suiten auf einem Build-Server aus — ohne Oberfläche, ohne manuelle Klicks. Sie zeigen darauf auf ein TIA-Portal-Projekt; das Werkzeug findet die Suiten in .tia-tests/, führt sie aus, schreibt maschinenlesbare Berichte und liefert einen Exit-Code zurück, auf den Ihre Pipeline reagieren kann. Es öffnet TIA Portal im Hintergrund (ohne Fenster), damit es sauber auf einem Build-Agenten läuft; mit --show-ui wird das Fenster sichtbar, etwa zum Debuggen. Es handelt sich um eine Pro+-Funktion (Pro+ und höher); der Agent benötigt eine CI-Lizenzdatei, die Sie in Studio speichern (siehe Lizenzierung für CI weiter unten).

Das Kommandozeilen-Werkzeug `tia-test-runner`

Das Werkzeug wird als tia-test-runner.exe ausgeliefert und stellt diese Verben bereit:

Verb	Zweck
`run`	Einen Unit-Test-Lauf gegen ein TIA-Portal-Projekt ausführen und Berichte schreiben
`compare`	Zwei frühere Läufe vergleichen und einen Diff-Bericht erzeugen
`trend`	Historische Pass/Fail-Trends als CSV exportieren
`flaky`	Die instabilen Fälle einer Suite (über die letzten Läufe schwankend) als Tabelle oder CSV auflisten
`validate`	Test-Suite-Definitionen auf Schema-Fehler prüfen, ohne sie auszuführen
`verify`	Das Integritäts-Manifest eines früheren Laufs prüfen (manipulierte oder fehlende Bericht-Dateien erkennen); zeigt auch die Freigabe des Laufs und meldet, wenn ihre Angaben verändert wurden
`traceability`	Die Rückverfolgbarkeit der Anforderungen prüfen und den Build bei fehlgeschlagenen oder ungetesteten Anforderungen fehlschlagen lassen (siehe Anforderungs-Gate (Traceability) unten)
`version`	Versionen von Runner, Bridge, Engine, Build, .NET und Betriebssystem ausgeben

Optionen für jedes Verb:

Option	Bedeutung
`--log-level <STUFE>`	Wie viel der Runner protokolliert: Verbose, Debug, Information, Warning (Standard), Error oder Fatal. Protokollzeilen gehen auf die Fehlerausgabe, die normale Ausgabe enthält nur die Ergebnisse.
`--log-file <PFAD>`	Die Protokolldatei unter diesem Pfad schreiben statt in die tägliche Protokolldatei unter `%LocalAppData%\AnyAutomation\Logs`.
`--lang <SPRACHE>`	Sprache der Hilfe-Überschriften: `en` (Standard), `de` oder `fr`. Die Ergebnisse sind immer englisch.
`--ansi`, `--no-ansi`	Farbige Ausgabe erzwingen oder ausschalten.

Ein typischer Lauf:

tia-test-runner run ^
  --project "C:\Projects\Plant.ap20" ^
  --plc PLC_1 ^
  --suite-filter * ^
  --out-dir reports

Wichtige Flags für run:

Flag	Bedeutung
`--project <PFAD>`	TIA-Portal-Projektdatei (`.ap20`, `.ap21`, …). Erforderlich.
`--out-dir <PFAD>`	Verzeichnis für Berichte und Logs. Erforderlich.
`--plc <NAME>`	Den Lauf auf eine einzelne PLC-Station begrenzen.
`--suite-filter <MUSTER>`	Glob-Filter auf Suite-Namen (`*`, `?`, literal).
`--tag <TAG>`	Nur Fälle mit diesem Tag ausführen (wiederholbar).
`--priority-min <STUFE>`	Mindestpriorität (Low / Normal / High / Critical).
`--report-format <FORMAT>`	`junit`, `html` oder `cobertura` (wiederholbar). Standard: JUnit + HTML.
`--rerun-affected`	Nur Suiten ausführen, deren zugrunde liegender Baustein sich seit dem letzten Lauf geändert hat (benötigt `--plc`).
`--fail-fast`	Beim ersten fehlgeschlagenen Fall abbrechen.
`--timeout-minutes <N>`	Zeitlimit pro Lauf. Standard: 60.
`--attach`	An ein bereits laufendes TIA Portal anhängen, statt die Projektdatei zu öffnen.
`--show-ui`	TIA Portal mit sichtbarem Fenster statt im Hintergrund öffnen. Praktisch, um einen Lauf beim lokalen Debuggen zu beobachten.
`--quarantine`	Einen fehlschlagenden Fall zu einem nicht blockierenden Übersprung herabstufen, wenn er in den letzten Läufen instabil war, damit ein instabiler Fehlschlag den Build nicht bricht.
`--quarantine-window <N>`	Wie viele der letzten Läufe auf Instabilität geprüft werden (Standard 10).
`--quarantine-min-flips <N>`	Mindestanzahl an Pass/Fail-Wechseln in diesem Fenster, bevor ein Fall als instabil gilt (Standard 1).
`--retry-max <N>`	Wie oft eine Suite nach einem Infrastrukturfehler wie einem Verbindungsabbruch wiederholt wird (`0` deaktiviert; Standard 3).
`--retry-delay-ms <MS>`	Wartezeit zwischen diesen Wiederholungen.
`--config <PFAD>`	Standardwerte aus einer YAML-Konfigurationsdatei lesen (siehe unten).

Der Lauf gibt eine Zusammenfassungszeile mit den Zählern bestanden / fehlgeschlagen / Fehler / übersprungen / unter Quarantäne aus; wenn ein Lauf instabile Fälle unter Quarantäne stellt, wird jeder herabgestufte Fall direkt vor der Zusammenfassung aufgelistet, sodass er nie verborgen bleibt.

Exit-Codes (der Pipeline-Vertrag):

Code	Bedeutung
`0`	Alle Tests bestanden
`1`	Ein oder mehrere Tests fehlgeschlagen
`2`	Lauffehler (Start nicht möglich, PLC-Verbindung verloren, Lizenz nicht berechtigt, …)
`3`	Argument- oder Konfigurationsfehler
`4`	Zeitüberschreitung
`5`	Vom Benutzer abgebrochen (Strg+C)

Nach einem Lauf enthält --out-dir eine JUnit-XML-Datei, die Ihr CI-Test-Reporter veröffentlichen kann, einen eigenständigen, gebrandeten HTML-Bericht und ein Integritäts-Manifest. Berichte sind append-only: Der neueste Lauf liegt immer zuoberst in --out-dir, die JUnit-Datei, der HTML-Bericht und das Manifest dort gehören also zu ihm (bei mehreren Suiten in einem Aufruf zur letzten Suite). Jeder frühere Lauf wandert mit seinem eigenen Manifest in einen eigenen Unterordner unter runs, und sobald das Verzeichnis mehr als einen Lauf enthält, zählt eine aggregierte Zusammenfassung alle zusammen.

Anforderungs-Gate (Traceability)

tia-test-runner traceability prüft die Rückverfolgbarkeit der Anforderungen auf dem Build-Agenten und lässt die Pipeline fehlschlagen, wenn Anforderungen fehlschlagen oder keinen Test haben. Es liest die Testergebnisse, die das Verb run auf demselben Agenten aufgezeichnet hat, und die Anforderungsliste des Testordners, sofern vorhanden.

tia-test-runner traceability ^
  --project "C:\Projects\Plant.ap20" ^
  --runs-from reports ^
  --out-dir reports\traceability ^
  --fail-on failed,uncovered

Flag	Bedeutung
`--project <PATH>`	TIA-Portal-Projektdatei oder ihr Ordner. Pflicht.
`--runs-from <DIR>`	Nur die Läufe verwenden, deren Berichte in diesem Ordner liegen, normalerweise das `--out-dir` des vorangehenden `run`-Schritts. Empfohlen: Ohne diese Angabe könnte ein Ergebnis zählen, das eine andere Pipeline oder ein anderer Branch auf demselben Agenten aufgezeichnet hat.
`--fail-on <LIST>`	Welche Anforderungszustände den Build fehlschlagen lassen: beliebige von `failed`, `uncovered`, `notRun`, `outdated`, `incomplete` oder `none`. Standard `failed,uncovered`. `outdated` umfasst auch Anforderungen, deren letzter Lauf aufgezeichnet wurde, bevor Änderungen erkannt werden konnten.
`--requirements <PATH>`	Eine Anforderungsliste anstelle derjenigen im Testordner, zum Beispiel eine während des Builds aus Ihrem ALM-Werkzeug exportierte Liste.
`--suite-filter <PATTERN>`	Nur die Suites prüfen, deren Dateiname zum Muster passt, also dieselben Suites, die `run --suite-filter` ausführt (zum Beispiel `Conveyor*`). Anforderungen, die nur die übrigen Suites nennen, bleiben aussen vor; Anforderungen Ihrer Liste, die keine Suite nennt, gelten weiterhin als ungetestet.
`--run-window <N>`	Wie viele der letzten Läufe jeder Suite berücksichtigt werden (1 bis 100, Standard 20).
`--format <text\|json>`	Ausgabe als Tabelle (Standard) oder als JSON. Mit `json` enthält die Standardausgabe nur das JSON-Dokument, sodass ein Skript es direkt lesen kann.
`--json-file <PATH>`	Das JSON-Dokument zusätzlich in eine Datei schreiben.
`--out-dir <DIR>`	Den HTML-Traceability-Bericht und sein Integritäts-Manifest in diesen Ordner schreiben. Verwenden Sie einen eigenen Ordner wie `reports\traceability`, nicht den Ordner eines Laufberichts.
`--brand-title`, `--brand-footer`, `--brand-color`, `--brand-logo`	Branding des HTML-Berichts, wie bei `run`.

Die Tabelle zeigt jede Anforderung mit Status, Anzahl Testfälle, letztem Nachweis und Titel, gefolgt von einer Zusammenfassung wie "12 requirements: 1 failed, 2 uncovered, 0 not verified". Neben den Exit-Codes von run liefert das Verb:

Code	Bedeutung
`1`	Eine Anforderung ist fehlgeschlagen (wenn `failed` in `--fail-on` steht)
`3`	Eingabeproblem: zum Beispiel ein Fehler in der Anforderungsliste, eine nicht lesbare Suite-Datei, ein `--suite-filter`, zu dem keine Suite passt, oder keine Laufberichte im Ordner von `--runs-from`
`9`	Eine Anforderung hat keinen Testfall (wenn `uncovered` in `--fail-on` steht)
`10`	Eine Anforderung ist nicht verifiziert: nicht gelaufen, veraltet oder unvollständig (wenn in `--fail-on` gewählt)

Warnungen zur Anforderungsliste werden ausgegeben, lassen den Build aber nie fehlschlagen. Wie run benötigt das Verb die CI-Lizenzdatei.

Instabile Tests und Quarantäne

Ein instabiler (flaky) Test ist einer, der in manchen Läufen besteht und in anderen fehlschlägt, ohne dass sich der getestete Baustein tatsächlich geändert hat — meist ein Timing- oder Umgebungseffekt. Um zu sehen, welche Fälle einer Suite über ihre letzten Läufe instabil sind:

tia-test-runner flaky --suite-file "C:\Projects\Plant\.tia-tests\FB_Motor.json"

Es gibt eine Tabelle jedes instabilen Falls aus, mit der Anzahl der Wechsel zwischen Bestanden und Fehlgeschlagen und seiner jüngsten Ergebnisfolge. Mit --window <N> ändern Sie, wie viele der letzten Läufe geprüft werden (Standard 10), und mit --out-file <CSV> schreiben Sie die Liste zusätzlich als CSV.

Fügen Sie einem run --quarantine hinzu, damit instabile Fehlschläge den Build nicht brechen: Ein Fall, der den aktuellen Lauf nicht besteht, aber in der jüngsten Historie instabil war, wird zu einem nicht blockierenden Übersprung herabgestuft und in der JUnit-Ausgabe sowie der Zusammenfassung als unter Quarantäne (instabil) ausgewiesen, während echte, stabile Fehlschläge den Build weiterhin scheitern lassen. Feinabstimmung über --quarantine-window und --quarantine-min-flips. In Studio ist die Quarantäne die Option Quarantine flaky cases von Run (siehe Laufoptionen). Die Quarantäne verbirgt einen herabgestuften Fall nie: Jeder wird vor der Lauf-Zusammenfassung aufgelistet.

Bericht-Klassennamen

Standardmäßig folgen die JUnit-classname-Werte dem Muster {PlcName}.{BlockName}, das die meisten CI-Test-Ansichten zu einem lesbaren Baum gruppieren. Überschreiben Sie es mit --report-classname-pattern und einer beliebigen Kombination dieser Platzhalter:

{PlcName} — der PLC-/CPU-Name
{BlockName} — der getestete Baustein
{SuiteName} — der Name der Test-Suite
{ProjectName} — der Projektname

Beispiel: --report-classname-pattern "{ProjectName}/{PlcName}/{SuiteName}".

CI-Umgebungsdaten erfassen

Mit --ci-env-capture wird eine kleine, feste Auswahl von CI-Variablen in die Herkunftsdaten des Laufs aufgenommen, damit die Berichte zeigen, welche Pipeline, welcher Commit und welcher Agent den Lauf erzeugt hat. Die Erfassung ist opt-in — ohne ausdrückliche Angabe wird nichts erfasst. Das Werkzeug erkennt GitHub Actions, Jenkins, Azure DevOps und GitLab CI (sowie einen generischen CI-Marker); gelesen wird nur eine erlaubte Auswahl an Bezeichnern (Lauf-/Build-IDs, Commit-SHA, Branch/Ref, Workflow-/Job-Name, Agent-/Runner-Name), jeweils auf eine sichere Länge gekürzt.

YAML-Konfigurationsdatei

Damit lange Befehlszeilen aus Ihrer Pipeline verschwinden, legen Sie die Standardwerte in einer YAML-Datei ab und übergeben --config <PFAD>. Befehlszeilen-Flags überschreiben die Datei. Beispiel tia-tests.yml:

project: C:\Projects\Plant.ap20
plc: PLC_1
out_dir: reports
report_format:
  - junit
  - html
timeout_minutes: 45
ci_env_capture: true

Jenkins (Declarative Pipeline)

pipeline {
  agent { label 'tia-windows' }
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Unit Tests') {
      steps {
        bat 'tia-test-runner run --project "%WORKSPACE%\\Plant.ap20" --plc PLC_1 --out-dir reports --ci-env-capture'
      }
    }
  }
  post {
    always {
      junit 'reports/**/junit.xml'
      archiveArtifacts artifacts: 'reports/**/*.html', allowEmptyArchive: true
    }
  }
}

GitHub Actions

name: TIA Unit Tests
on: [push]
jobs:
  unit-tests:
    runs-on: [self-hosted, windows, tia]
    steps:
      - uses: actions/checkout@v4
      - name: Run SCL unit tests
        run: tia-test-runner run --project "${{ github.workspace }}\Plant.ap20" --plc PLC_1 --out-dir reports --ci-env-capture
      - name: Publish test report
        if: always()
        uses: dorny/test-reporter@v1
        with:
          name: TIA Unit Tests
          path: reports/**/junit.xml
          reporter: java-junit
      - name: Upload HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: tia-html-report
          path: reports/**/*.html

Azure DevOps

pool:
  name: tia-windows
steps:
  - checkout: self
  - script: tia-test-runner run --project "$(Build.SourcesDirectory)\Plant.ap20" --plc PLC_1 --out-dir $(Build.ArtifactStagingDirectory)\reports --ci-env-capture
    displayName: Run SCL unit tests
  - task: PublishTestResults@2
    condition: always()
    inputs:
      testResultsFormat: JUnit
      testResultsFiles: '$(Build.ArtifactStagingDirectory)/reports/**/junit.xml'
      testRunTitle: TIA Unit Tests
  - publish: $(Build.ArtifactStagingDirectory)\reports
    artifact: tia-html-report
    condition: always()

GitLab CI

unit-tests:
  tags: [tia-windows]
  script:
    - tia-test-runner run --project "$CI_PROJECT_DIR\Plant.ap20" --plc PLC_1 --out-dir reports --ci-env-capture
  artifacts:
    when: always
    paths:
      - reports/
    reports:
      junit: reports/**/junit.xml

Eine CI/CD-Pipeline aus der App erzeugen

Statt die Konfigurationsdateien von Hand zu schreiben, lassen Sie sie von AnyAutomation Studio erzeugen. Studio erstellt für ein TIA-Projekt zwei direkt eincheckbare Dateien: eine runner.yaml mit den Kommandozeilen-Vorgaben und eine Pipeline-Datei für das von Ihnen gewählte CI-System. Sie richten beides auf der Seite CI Pipeline ein, die die fertigen Dateien anzeigt, während Sie das Formular ausfüllen.

Seite öffnen. Starten Sie Generate CI Pipeline aus der Befehlspalette, aus dem …-Menü der Ansicht Test Suites oder aus dem …-Menü der Test Bench. Die Seite öffnet sich für das TIA-Projekt, mit dem Sie verbunden sind. Ohne Verbindung fragt Studio zuerst nach der Projektdatei. Jedes Projekt hat seine eigene Seite mit dem Titel CI Pipeline: <Projekt>; ein erneuter Aufruf des Befehls bringt Sie dorthin zurück.

Formular ausfüllen. Die linke Seite hat diese Abschnitte:

Abschnitt	Was Sie festlegen
Project	Die Projektdatei (angezeigt, nicht änderbar), den PLC name (solange Sie mit dem Projekt verbunden sind, schlägt das Feld dessen PLCs vor und trägt die erste ein, wenn es leer ist), einen optionalen Suite filter, Cycle wait (ms) und Capture CI environment.
Reports	HTML report und JUnit XML (mindestens eines), den Report output folder innerhalb des Projektordners (leer bedeutet `tia-test-results`), das Classname pattern und unter Branding Title, Footer und Accent color des HTML-Berichts.
CI Target	Das CI-System: GitHub Actions, GitLab CI, Azure DevOps oder Jenkins, und ein optionales Agent label, das den Build-Agenten wählt (siehe den Hinweis zu Build-Agenten unten).
Triggers	Optionale Push branches, Pull request branches (durch Kommas getrennt) und einen Schedule (cron). Lassen Sie alle drei leer, um die Pipeline von Hand zu starten.
Build Matrix	Optionale parallele Zellen, siehe Build-Matrix unten.
Coverage	Publish coverage und drei optionale Mindestprozentsätze, die Sie ausfüllen können, solange Publish coverage eingeschaltet ist. Fail on failed or uncovered requirements ergänzt nach dem Testlauf einen Schritt, der die Rückverfolgbarkeit der Anforderungen gegen diesen Lauf prüft, den Traceability-Bericht bei den übrigen Berichten ablegt und den Build fehlschlagen lässt; unter Fail on wählen Sie, welche Anforderungszustände dazu führen (standardmässig Failed und Uncovered). Mit einem Suite-Filter prüft der Schritt dieselben Suites wie der Testlauf.
CI Runner	Ob der Kommandozeilen-Runner auf diesem Computer installiert ist, und Save CI Licence File (siehe Lizenzierung für CI).

Ein Feld mit einem Problem wird markiert und sagt, was zu ändern ist, zum Beispiel „Enter the PLC name.“ oder „A cell with this name already exists.“; die Zeile unten auf der Seite wiederholt das erste Problem.

Dateien mitverfolgen. Die rechte Seite zeigt die erzeugten Dateien. Klicken Sie auf einen Dateinamen über dem Text oder verwenden Sie die Pfeiltasten links und rechts, um zwischen runner.yaml und der Pipeline-Datei zu wechseln. Die Dateien werden etwa eine halbe Sekunde nach Ihrer letzten Eingabe aktualisiert. Solange ein Feld ein Problem hat, zeigt die Vorschau stattdessen „Complete the highlighted fields to preview the files.“ Ziehen Sie den Trenner zwischen Formular und Vorschau, um einer Seite mehr Platz zu geben.

Dateien schreiben.

Preview as Untitled Files öffnet beide Dateien als ungespeicherte Editoren, damit Sie sie kopieren oder an einem anderen Ort speichern können.
Write Files speichert beide Dateien im Projektordner. Falls eine davon bereits existiert, listet eine einzige Rückfrage alles auf, was ersetzt würde; bei Cancel wird nichts geschrieben.

Beide Schaltflächen sind nur verfügbar, solange das Formular kein Problem hat. Ein Feld darf weder ${{ noch $( enthalten, weil Ihr CI-System diese Zeichen auswerten würde, und der Schedule (cron) braucht fünf Felder (Minute, Stunde, Tag im Monat, Monat, Wochentag); die Meldung unter dem Feld sagt Ihnen, was zu ändern ist. Die runner.yaml wird in den Projektordner geschrieben, die Pipeline-Datei an den vom CI-System erwarteten Pfad: .github/workflows/tia-tests.yml für GitHub Actions, Jenkinsfile für Jenkins, azure-pipelines.yml für Azure DevOps und .gitlab-ci.yml für GitLab CI. Checken Sie beide Dateien ein.

Ihre Eingaben bleiben erhalten. Sie können die Seite jederzeit schliessen, ohne etwas zu verlieren: Studio merkt sich das Formular für jedes Projekt und zeigt es beim nächsten Öffnen der Seite wieder an, auch nach einem Neustart. Eine Seite, die beim Schliessen von Studio offen war, öffnet sich mit Studio wieder. Sind Sie mit einem anderen Projekt verbunden als dem der Seite, erscheint oben die Zeile „This page belongs to <Projektdatei>.“; die Seite schreibt weiterhin in ihren eigenen Projektordner.

Wann die Pipeline läuft. Standardmässig läuft die erzeugte Pipeline auf Abruf: Starten Sie sie manuell in Ihrem CI-System, wann immer Sie testen möchten. Füllen Sie Triggers aus, damit sie auch automatisch bei jedem Push oder Pull Request auf die angegebenen Branches oder nach einem Cron-Zeitplan für nächtliche Läufe startet. (Bei GitLab wird der Zeitplan selbst im GitLab-Bildschirm für Pipeline-Zeitpläne gesetzt; bei Jenkins kommen Push- und Pull-Request-Läufe aus dem Webhook Ihres Repositorys.)

Die Pipeline muss auf einem selbstgehosteten Windows-Build-Agenten laufen. Die Tests steuern TIA Portal und PLCSIM, daher benötigt die ausführende Maschine ein installiertes TIA Portal, ein verfügbares PLCSIM und eine aktive Pro+-Lizenz oder höher. Cloud-gehostete Runner können die Tests nicht ausführen. Die erzeugte Pipeline verlangt deshalb einen selbstgehosteten Windows-Agenten: bei GitHub Actions einen Runner mit den Labels self-hosted und Windows, bei Azure DevOps einen Windows-Agenten des Pools Default, bei GitLab CI einen Runner mit dem Tag windows, bei Jenkins einen Agenten mit dem Label windows. Tragen Sie auf der Seite ein Agent label ein, um stattdessen Ihr eigenes Label, Ihren Pool oder Ihr Tag zu verwenden.

Der Agent braucht bash. Der Testschritt der erzeugten Pipelines für GitHub Actions, GitLab CI, Azure DevOps und Jenkins läuft in bash. Ein Windows-Build-Agent braucht deshalb ein installiertes Git Bash im PATH; ein GitLab-Runner kann seine PowerShell-Shell behalten. Eine Pipeline-Datei, die Sie mit einer früheren Version erzeugt haben, funktioniert unverändert weiter, bis Sie sie neu erzeugen.

Build-Matrix

Fügen Sie mit Add Cell im Kopf des Abschnitts Build Matrix eine oder mehrere Zellen hinzu, dann führt jede Zelle Ihre Test-Suiten als eigenen, parallelen Job in der erzeugten Pipeline aus. Nutzen Sie das, um dieselben Suiten über mehrere Projekte zu testen oder eine grosse Menge an Suiten in parallele Teile aufzuteilen, sodass der gesamte CI-Lauf schneller fertig wird und jede Zelle für sich berichtet.

Jede Zelle ist eine Zeile der Tabelle:

Name (Pflicht) – eine kurze Bezeichnung aus Buchstaben, Ziffern, _ oder -, eindeutig innerhalb der Matrix. Eine neue Zelle beginnt mit einem freien Namen wie cell1.
Project file (optional) – leer lassen, um das Projekt der Seite zu verwenden, oder die Zelle auf eine andere Projektdatei richten.
Suite filter (optional) – nur einen Teil der Suiten in dieser Zelle ausführen. Leer lassen, um alle auszuführen.

Entfernen Sie eine Zelle mit dem Entfernen-Symbol am Ende ihrer Zeile. Jede Zelle schreibt ihre Ergebnisse in einen eigenen Berichtsordner, sodass sich Zellen nie gegenseitig überschreiben und Sie sie nebeneinander vergleichen können. Die Build-Matrix steht für alle vier CI-Systeme zur Verfügung. Eine leere Build-Matrix erzeugt die normale Einzellauf-Pipeline.

Lizenzierung für CI

Unit Testing ist eine Pro+-Funktion (Pro+ und höher), daher prüft der Runner Ihre Lizenz, bevor er arbeitet. Ein Build-Agent wird über eine CI-Lizenzdatei lizenziert, die Sie in Studio speichern und dem Agenten mitgeben.

Datei speichern. Starten Sie in Studio Generate CI Pipeline, klicken Sie auf der Seite CI Pipeline im Abschnitt CI Runner auf Save CI Licence File und legen Sie einen Speicherort fest. Sie müssen angemeldet sein und eine aktive Pro+-Lizenz haben.

Datei dem Agenten mitgeben. Entweder legen Sie die Datei auf den Agenten und zeigen den Runner darauf:

tia-test-runner run --license-offline "C:\agent\anyautomation-ci.json" --project "C:\Projects\Plant.ap20" --out-dir reports

oder Sie hinterlegen den Inhalt der Datei als maskierte Pipeline-Variable mit dem Namen ANYAUTOMATION_CI_ENTITLEMENT, entweder unverändert oder base64-kodiert (manche CI-Systeme maskieren nur einzeilige base64-Werte). Ohne Pfadangabe liest der Runner diese Variable.

Der Pfad hinter --license-offline muss auf ein lokales Laufwerk des Agenten zeigen; ein Netzwerkfreigabe-Pfad (\server...) wird abgelehnt. Liegt die Datei auf einer Freigabe, kopieren Sie sie auf den Agenten oder verwenden Sie die Variable.

Behandeln Sie die Datei vertraulich. Sie trägt Ihre Berechtigung, wer sie erhält, kann die lizenzierten Verben ausführen. Hinterlegen Sie sie als maskierte Variable oder als Geheimnis, geben Sie sie nie in ein Build-Log aus und checken Sie sie nicht ins Repository ein.

Die Datei verliert ihre Gültigkeit mit dem Ende Ihres Abonnements, spätestens jedoch 90 Tage nach dem Speichern. Speichern Sie in Studio eine neue, sobald eine Pipeline eine abgelaufene Lizenz meldet.

--license-key wird nicht mehr angenommen und endet mit Exit-Code 3. Verwenden Sie stattdessen die Lizenzdatei.

Diese Verben brauchen keine Lizenzdatei: version, verify und validate. verify bleibt bewusst offen, damit Sie die Unversehrtheit eines archivierten Abnahmeprotokolls auch Jahre später und nach dem Ende eines Abonnements noch prüfen können, und validate ist eine reine Schemaprüfung für einen Pre-Commit-Hook.

Proxy-Konfiguration

Der Runner berücksichtigt standardmäßig die üblichen Proxy-Umgebungsvariablen — setzen Sie HTTPS_PROXY, HTTP_PROXY und NO_PROXY auf dem Build-Agenten, dann läuft die Online-Lizenzprüfung über Ihren Proxy. Zusätzliche Flags sind nicht nötig.

Unterstützte Umgebungen

Umgebung	Unterstützt?	Hinweise
Windows 11 (Desktop)	Ja	Referenzumgebung.
Windows Server 2022 mit Desktopdarstellung	Ja	TIA Portal und PLCSIM Advanced benötigen eine interaktive Desktop-Sitzung.
Windows Server Core	Nein	TIA Portal Openness benötigt die vollständige Desktop-Shell, die die Server-Core-Installation nicht bereitstellt.
Docker / Windows-Container	Nein	TIA Portal und PLCSIM Advanced werden in Containern nicht unterstützt.

Fehlerbehebung bei CI-Läufen

Symptom	Ursache und Behebung
Exit-Code `3`, „`--project` is required"	Ein erforderliches Argument fehlt oder die YAML-Konfiguration konnte nicht gelesen werden. Prüfen Sie die Pfade von `--project`, `--out-dir` und `--config`.
Exit-Code `2`, Lizenzmeldung	Der Agent hat keine gültige CI-Lizenzdatei. Speichern Sie in Studio eine neue und zeigen Sie den Runner darauf, oder setzen Sie die maskierte Variable `ANYAUTOMATION_CI_ENTITLEMENT`.
Exit-Code `2`, „Ausgabeverzeichnis kann nicht beschrieben werden"	`--out-dir` zeigt auf einen geschützten Systemort. Verwenden Sie einen Pfad unterhalb des Projektverzeichnisses oder im lokalen App-Daten-Bereich des Agenten.
Exit-Code `4`, Zeitüberschreitung	Der Lauf überschritt `--timeout-minutes`. Erhöhen Sie das Limit oder teilen Sie große Suiten auf; prüfen Sie, ob die PLC vom Agenten erreichbar ist.
Kein Testbericht in CI sichtbar	Der Test-Reporter-Schritt zeigt nicht auf `junit.xml` oder läuft nur bei Erfolg. Veröffentlichen Sie Berichte mit einer `always()`/`when: always`-Bedingung und zeigen Sie auf `reports/**/junit.xml`.
Online-Prüfung hängt hinter einem Unternehmens-Proxy	Setzen Sie `HTTPS_PROXY` / `HTTP_PROXY` (und `NO_PROXY` für interne Hosts) auf dem Agenten.

Datenschutz

Es werden keine Telemetriedaten durch die CLI oder die Oberfläche erhoben. Die in Berichten sichtbaren CI-Variablen werden nur erfasst, wenn Sie dies mit --ci-env-capture ausdrücklich aktivieren, und der Projektpfad wird als nicht umkehrbarer Hash gespeichert, niemals im Klartext. HTML-Berichte erfüllen WCAG 2.1 AA, geprüft durch automatisierte Checks; eine manuelle Screenreader-Abnahme (NVDA) ist Teil des Release-End-to-End-Durchlaufs.

← Zurück

CODESYS

Weiter →

Bibliotheksverwaltung