DaRayQC eine checklistenbasierte Anwendung für qualitätssicherungsbezogene Testausführungen ist, dürfte es kaum überraschen, ein Objekt namens „RayQC-Checkliste" zu finden. Die Unterschiede zwischen Checklisten und Vorlagen oder zwischen Checklisten und Projekten zu erkennen, kann jedoch ohne weitere Erklärung etwas schwierig sein. Daher folgt hier ein kurzer Überblick über die Objekte und ihre zugehörigen Dateinamenerweiterungen inRayQC.
RayQC-Checkliste und RayQC-Vorlage (*.rqct)
Die Dateitypen Checkliste und Vorlage existieren aus historischen Gründen. Tatsächlich beziehen sich beide Namen auf denselben Objekttyp RQCT, was die Abkürzung fürRayQC Template ist. Der Gedanke dahinter ist, dassRayQC beim Erstellen einer neuen Checkliste eine Standardvorlage verwendet, um die grundlegende Checklistenstruktur zu generieren. Solange die Checkliste noch nicht inRayQC ausgeführt wurde, ist sie nichts anderes als eine bearbeitete Version auf Basis der ursprünglichen Vorlagendatei. Wenn daher in derRayQC-Benutzeroberfläche oder Dokumentation die Bezeichnungen Checkliste und Vorlage verwendet werden, beziehen sich beide tatsächlich auf denselben Dateityp.
Die inRayQC 2026.3 verwendeten RQCT-Dateien sind ZIP-Container, die die XML-Checklistendatei (checklist.xml) sowie alle anderen zum Ausführen der Checkliste inRayQC erforderlichen Ressourcen enthalten: Plug-ins, Hilfedateien, Bilder usw. werden in dedizierten Verzeichnissen innerhalb des ZIP-Containers gespeichert.
Checklistengruppe
Eine Gruppe ist ein logisches Bündel von Elementen innerhalb einer Checkliste. Die Elemente einer bestimmten Gruppe werden als Einheit behandelt und daher in einem gemeinsamen Containerbereich angezeigt, wenn eine Checkliste (Vorlage oder Projekt) inRayQC geöffnet wird. Jede Gruppe hat einen eigenen Header (einschließlich Indexnummer, Titel und Beschreibung) und einen Inhaltsbereich (einschließlich der Checklistenelemente der Gruppe).
Checklistenelement
Ein Element ist ein einzelnes Objekt innerhalb einer Checklistengruppe. Es gibt vier grundlegende Elementtypen, die in Checklisten verwendet werden können:Information,Data Field,Checkpoint undMulti-Option. Der Elementtyp bestimmt die Eingabe- und Ergebnisoptionen, mit denen Benutzer beim tatsächlichen Ausführen einer Checklisteninstanz (die als Projekt bezeichnet wird, siehe unten) konfrontiert werden. Weitere Details zu den Spezifikationen der Elementtypen finden Sie im Kapitel Elementtypen weiter unten.
|
Achtung: Frühere Versionen verwenden andere Namen für die Checklistenelementtypen. Um Missverständnisse zu vermeiden und klare Bezeichnungen bereitzustellen, wurde folgende Umbenennung vorgenommen: •Comment > Information •User Comment > Data Field •Checkpoint Entry > Checkpoint •Multi-Option Entry > Multi-Option |
RayQC-Projekt (*.rqcp)
EineRayQC-Projektdatei (abgekürzt als RQCP) ist wie RQCTs ein ZIP-Container. Zusätzlich zu den Checklistenressourcen ist sie um den aktuellen Ausführungsstatus für diese spezifische Checklisteninstanz erweitert. Wenn eine Checklistendatei inRayQC geöffnet wird, wird sie daher automatisch in eine temporäre Projektdatei im Sitzungsspeicher konvertiert. Beim Speichern von Änderungen an einer Checkliste wird automatisch der Projektdatentyp RQCP als Dateiendung vorausgewählt. Nur wenn Benutzer die Standardauswahl manuell aufRayQC Template (*.rqct) ändern, wird die ursprüngliche Checklistendatei physisch überschrieben.
Um zu entscheiden, welches Zielformat gewünscht ist, müssen Benutzer genau wissen, was sie speichern möchten: Die statusfreie Checkliste selbst, die später als Ausgangsbasis für mehrere neue Projekte verwendet werden kann, oder den aktuellen Stand eines bestimmten Checklistendurchlaufs, der als Projektdatei vorliegen muss.
|
Achtung: Um Auswertungsstatus und Elementstrukturinformationen aus einer Projektdatei zu unterscheiden, müssen Benutzer die Projektdatei mit einem Tool wie WinZip oder 7ZIP öffnen. Einmal so geöffnet, sind Checklistenstatus und -struktur direkt als XML-Dateien verfügbar. Es wird jedoch nicht empfohlen, die Dateien außerhalb desRayQC-Anwendungsbereichs zu bearbeiten, da das Ergebnis sehr wahrscheinlich nicht mehr mit dem Schema und den Wertebereichsbeschränkungen konform sein wird. |
Plug-ins
Checklisten können verschiedene Plug-ins enthalten, wobei jedes Checklistenelement (siehe Abschnitt oben) mit maximal einem Plug-in ausgestattet werden kann. Plug-ins ermöglichen die automatisierte Checklistenausführung, da sie skriptbasierte Logik bereitstellen, die von derRayQC-Plug-in-Schnittstelle aufgerufen werden kann.
Interne Plug-ins
Interne Plug-ins sind in derRayQC-Anwendung vordefiniert und können in jeder Art von Checkliste verwendet werden. Benutzer fügen das Plug-in einfach einem Element hinzu, wählen die erforderlichen Steueroptionen und Parameterwerte aus, und die skriptbasierte Logik wird beim Ausführen des Checklistenprojekts ausgeführt. In der aktuellen Version vonRayQC stehen folgende interne Plug-ins zur sofortigen Nutzung zur Verfügung:
Externe Plug-ins (PowerShell-Skript und Manifest-XML)
Während interne Plug-ins vomRaynet-Entwicklungsteam für die allgemeine Verwendung inRayQC-Checklisten vordefiniert wurden, können externe Plug-ins vonRayQC-Benutzern selbst erstellt und integriert werden. Sie stellen in der Regel spezifische Logik für ein Testkriterium bereit, das von einer einzelnen Checkliste oder einer ganzen Checklistengruppe benötigt wird. Abhängig von den Test- und Qualitätssicherungsanforderungen des jeweiligen Kunden sind diese externen Plug-ins nur durch die Erfahrung des Erstellers beim Schreiben von PowerShell-Skripten und die gegebenen Einschränkungen der Arbeitsumgebung (z. B. Zugriffsbeschränkungen, Best Practices usw.) begrenzt.
Jedes externe Plug-in muss aus mindestens einer PowerShell-Skriptdatei, die die Plug-in-Logik enthält, und einer XML-Manifestdatei (Manifest.xml) bestehen, die die Plug-in-Schnittstelle für die direkte Interaktion und Kommunikation mitRayQC deklariert. Diese Dateien müssen im selben übergeordneten Verzeichnis gespeichert werden, das nach dem Plug-in-Namen benannt ist. Der Typ der unterstützten PowerShell-Skripte wird nicht vonRayQC selbst bestimmt, sondern vom PowerShell-Interpreter auf dem Computer, auf dem die Plug-ins ausgeführt werden.
RayQC überprüft automatisch das Anwendungsinstallationsverzeichnis (z. B.C:\Program Files (x86)\RayQC\) auf das Vorhandensein eines \plug-ins\-Verzeichnisses. Wenn es vorhanden ist, wird der Inhalt analysiert, um Plug-ins zu finden. Diese globalen externen Plug-ins können von jeder Checkliste aus verwendet werden, die auf dem Computer erstellt und ausgeführt wird, der die aktuelleRayQC-Instanz hostet.
Ein weiterer Typ von externem Plug-in ist das lokale externe Plug-in. Diese haben im Wesentlichen dieselbe Struktur (PowerShell-Skript und Manifest im selben Ordner, der nach dem Plug-in-Namen benannt ist), müssen jedoch im Plug-ins-Verzeichnis residieren, das Teil des RQCT/RQCP-ZIP-Containers ist. Daher werden lokale externe Plug-ins mit ihren übergeordneten Checklisten und Projekten mitgegeben, da sie wesentliche Bestandteile davon sind. Sie sind portabler als globale externe Plug-ins, die auf einem bestimmten QC-Gerät residieren.
Weitere Informationen zur tatsächlichen Verwendung von Plug-ins in Checklisten finden Sie im Abschnitt Plug-ins dieses Dokuments.
|
Hinweis: Bitte beachten Sie, dass die Möglichkeit, externe PowerShell-Plug-ins innerhalb einer Checkliste zu verwenden, nur mit derRayQC Enterprise Edition verfügbar ist. |
Bedingung
Bedingte Anweisungen sind ein wichtiger Aspekt der dynamischen Checklistenauswertung. InRayQC können Benutzer Bedingungen definieren – als Kombination mehrerer bedingter Anweisungen –, die den tatsächlichen Auswertungspfad einer Checkliste bestimmen können. Beispiel: Wenn das Ergebnis vonCheckpoint A wahr ist und das Ergebnis vonMulti-Option B falsch ist, muss Checklistengruppe X ausgewertet werden. Andernfalls ist Checklistengruppe X unsichtbar und beeinflusst das Ergebnis der Checkliste nicht.
Die logische Idee von Bedingungen inRayQC 2026.3 basiert auf der sogenannten „disjunktiven Normalform" (DNF), die es ermöglicht, beliebige Bedingungen als Kombination von ORs zwischen ANDs aufzubauen. Genauer gesagt: Eine DNF ist eine Disjunktion konjunktiver Klauseln. Im Checklisteneditor werden Klauseln als Buckets bezeichnet. Innerhalb jedes Buckets kann es mehrere bedingte Anweisungen geben, die jedoch alle zu wahr ausgewertet werden müssen, damit das Bucket-Auswertungsergebnis wahr wird. Wenn die Bedingung für ein Element mehr als einen dieser Buckets enthält, reicht es aus, dass ein Bucket zu wahr ausgewertet wird, damit die gesamte Bedingung zu wahr ausgewertet wird. Die Buckets werden also durch ANDs gebildet und durch ORs verkettet.
Weitere Informationen zur tatsächlichen Verwendung von Bedingungen in Checklisten finden Sie im Abschnitt Bedingungen dieses Dokuments.
Nächste Schritte
Nachdem die wichtigsten Objekte in derRayQC-Welt nun etwas vertrauter sind, ist es an der Zeit zu sehen, wie sie in produktiven Arbeitsszenarien eingesetzt werden. Lesen Sie weiter, um Details zu typischen Workflows inRayQC zu erhalten.