Testdateien Schnelleinstieg - iqb-berlin/iqb-berlin.github.io GitHub Wiki

ℹ️ Im Schnelleinstig zum Studio wurde die Aufgabe MEA01 angelegt. Nachfolgend wird die Aufgabe aber als nur MEA benannt, lassen Sie sich davon nicht verwirren.

ℹ️ An dieser Stelle wird nicht auf die VOCS-Datei eingegangen. Diese Datei enthält die Kodieranweisung und wird im Schnelleinstieg: Auswertung verwendet.

Um eine Testung mit dem Testcenter durchführen zu können, müssen vorab die Testdateien für die Testung in das Testcenter geladen werden. Wie im Schnelleinstieg zum Studio bereits beschrieben wurde, gibt das Studio nach dem Aufgabenentwurf die zugehörigen Testdateien aus. Werden vom Studio nicht nur die Dateien zur Aufgabe ausgegeben, sondern auch noch die optionalen Dateien Booklet-Xml und Testtakers-Xml, werden automatisch Abhängigkeiten zwischen den Testdateien beim Export hergestellt.

Nachfolgend sind die Abhängigkeiten der Testdateien und die Einbindungspunkte dargestellt.

Mithilfe von spezifischen Werte in den beiden Dateien: Testtaker-Xml und Booklet-Xml können Aussehen und Ablauf der Testung festgelegt werden. Einige dieser Werte werden bereits beim Export durch das Studio diesen beiden Dateien hinzugefügt. Bspw. wurden in der Testtaker-Xml 6 Logins mit einem Passwort und einem Review-Modus angelegt. Um eine Testung den individuellen Bedürfnissen anzupassen, reichen die Automatismen des Studios eventuell nicht aus. Es gibt da einfach zu viele mögliche Werte und Kombinationen. Daher gibt es die Möglichkeit die Dateien manuell anzupassen und um entsprechende Werte zu erweitern. Nachfolgend wird anhand von kurzen Beispiele aufgezeigt, wie die Dateien angepasst werden können, aber auch wie die Inhalte zu verstehen sind.

ℹ️ Wollen Sie noch etwas mehr zu den Funktionen der Testdateien erfahren? Schauen Sie sich gerne das Video zu diesem Thema an.

ℹ️ Mehr Informationen zu den einzelnen Testdateien finden Sie auch im Abschnitt "Direkt zu anderen Seiten".

Studio und Testcenter tauschen Informationen mittels der Testdateien aus. Damit dieser Austausch funktioniert, müssen beide Anwendung eine gemeinsame Sprache sprechen. In diesem Fall ist die gemeinsame Sprache XML. XML ist eine Möglichkeit textbasiert Daten und Werte zu transportieren. Das heißt: Sie können eine XML mit einem einfachen Texteditor öffnen und sehen die enthalten Werte und Daten und können diese manipulieren. Die Daten und Werte werden dabei in Elementen (tags) in Form von Attributen hinterlegt. Hier mal ein kurzes Beispiel:

Beim Export wurden 6 Logins in der Testtaker.xml angelegt. Ein Login ist dabei ein Element. Dieses Element verfügt über definierte Attribute mit entsprechenden Werten. Attribute sind in diesem Fall mode und pw. Die zugehörigen Werte werden mittels Gleichheitszeichen zugewiesen. Pure Daten gibt es innerhalb dieses Elements hier nicht. Aber im Element: Booklet sind nur Daten zu finden, nämlich der Name des Booklets.

<Login mode="run-hot-return" name="q2d6b" pw="e4y7">
      <Booklet>booklet1</Booklet>
</Login>

Damit das Testcenter alle Werte und Daten auch finden kann, dürfen nur festgelegte Elemente mit zulässigen Werten in der XML angelegt sein. Es ist also nicht möglich ein frei erfundenes Element der XML hinzuzufügen. Das Testcenter kennt dieses Element nicht und wird daher auch keine Werte und Daten dieses Elements auswerten können. Um nicht erlaubte Elemente einer XML bereits beim Laden in das Testcenter zu erkennen, muss eine Vorabprüfung stattfinden. Diese Prüfung kann mittels so genannter Schema-Definition erfolgen. Hierbei handelt es sich grob gesagt um eine Vorlage wie die entsprechende XML auszusehen hat und welche Elemente enthalten sein dürfen. Spezielle Editoren gleichen bereits bei der manuellen Bearbeitung einer XML auf Wunsch den aktuellen Inhalt mit der Schema-Definition ab und melden eventuelle fehlerhafte Inhalte. Diese können dann bereits während der Bearbeitung behoben werden.Spätestens beim Laden in das Testcenter erfolgt ein Abgleich der zu ladenden XML mit der deklarierten Vorlage der Schema-Definition. Wo diese Definition zu finden ist, wird in der jeweiligen Xml-Datei direkt am Anfang angegeben. Der Verweis auf diese Schema-Definition beginnt dann mit xmlns:xsi.

Während der Aufgabenerstellung im Studio wird festgelegt mit welchem Editor die Aufgaben erstellt werden soll. Außerdem wird angegeben mit welchem Player die Aufgabeninhalte später wiedergegeben werden. Dabei ist zu beachten, dass Editor und Player immer zueinander passen müssen. Wird bspw. der Aspect-Editor verwendet, muss auch der Aspect-Player verwendet werden. Gewählter Player und Editor werden beim Export durch das Studio in der Aufgaben-Xml hinterlegt. Sobald Aufgaben in das Testcenter geladen werden, prüft das Testcenter, ob der in der Aufgaben-Xml angegebene Player in das Testcenter geladen wurde. Das Testcenter hat nicht jeden Programmcode zu jedem Player hinterlegt, daher muss der Programmcode des jeweiligen Players mit in das Testcenter geladen werden. Dies geschieht mittels Ressourcendatei zum Player. In diesem Fall trägt diese Datei den Namen: [email protected].

Zu jeder im Studio erzeugten Aufgabe werden je 3 Dateien erstellt. Eine XML-Datei, eine VOUD-Datei und eine VOCS-Datei. Allen wird der Aufgabenname vorangestellt. In der VOUD befinden sich alle Aufgabeninhalte, sprich alle über den Editor angelegten Aufgabenelemente. In der XML sind zugehörige Metadaten wie bspw. der Aufgabenname und Kurzbeschreibung der Aufgabe angelegt. Außerdem wird hier angegeben, welcher Editor und Player bei der Aufgabenerstellung verwendet wurde. Es findet weiterhin ein Verweis auf die zugehörige Aufgabenressource VOUD statt. In der VOCS befinden sich die angelegten Kodieranweisungen zu einer Aufgabe. Diese Datei wird natürlich nur erzeugt, wenn eine Kodieranweisung zur Aufgabe angelegt wurde.

Metadaten der Aufgabe können in der XML auch außerhalb des Studio-Editors geändert werden. Die XML-Struktur ist leicht verständlich und überschaubar. Es ist prinzipiell auch möglich die Aufgabeninhalte in der VOUD außerhalb des Studio-Editors zu bearbeiten. Dieses Format ist aber deutlich schwieriger zu lesen und zu überschauen. Möchten Sie nachträglich in einer Aufgabe Inhalte ändern, wird daher empfohlen dies ausschließlich im Studio-Editor zu tun. Nachfolgend ist einmal die XML dargestellt, die durch das Studio ausgegeben wurde.

Hier können Sie den Code kopieren.

ℹ️ Übrigens wird eine Aufgabe am IQB auch als Unit bezeichnet.

In einem Booklet können Aufgaben zusammengefasst und sortiert werden.

ℹ️ Ein Booklet wird auch als Testheft bezeichnet.

Die Aufgaben können hier zu so genannten Testlets zusammengefasst werden. Testlets können mit bestimmten Beschränkungen versehen werden. Hierzu gehören bspw. eine zeitliche Beschränkung für die Bearbeitung des Testlets und eine Zugangsbeschränkung mittels Freigabewort.

ℹ️ Ein Testlet wird übrigens auch als Block bezeichnet.

Aufgaben können auch "lose" im Booklet vorliegen und werden dann von oben nach unten bei der Testdurchführung im Testcenter angezeigt.

Weiterhin kann in der Booklet-Xml mittels spezifischer Elemente, Attribute und Werte eine Booklet-Konfiguration (BookletConfig) angelegt sein. Aussehen und Verhalten der Testung können dann mittels dieser festgelegt werden. Hierfür stehen eine Vielzahl möglicher Elemente, Attribute und Werte zur Verfügung. Mehr Informationen zur Booklet-Konfiguration sind hier zu finden.

Nachfolgend werden die Strukturen der Booklet-xml einmal kurz aufgezeigt.

ℹ️ Die hier gezeigte Booklet-Xml ist beim Export durch das Studio automatisch erzeugt wurden. Hier werden nur grundsätzliche Strukturen erzeugt. Es fehlen bspw. Testlets und spezifische Booklet Konfigurationen.

Hier können Sie den Code kopieren.

Bei der automatischen Generierung durch das Studio ist in der Booklet-Xml noch kein Testlet angelegt, sondern nur die erstellte Aufgabe "MEA". Fügen Sie nun einmal zum besseren Verständnis ein Testlet hinzu. Anschließend verschieben Sie die Aufgabe "MEA" in dieses Testlet. Das Testlet soll dann noch eine Zeitbeschränkung TimeMax und eine Zugangsbeschränkung CodeToEnter erhalten. Testpersonen können dann bei einer finalen Testung erst nach Eingabe des Freigabewortes die Aufgabe innerhalb des Testlets bearbeiten. Die Testperson hat dann für die eingestellte Zeit die Möglichkeit die enthaltenen Aufgaben zu bearbeiten.

Hier können Sie den Code kopieren.

In der Testtakers können Logins (Login) für die Testpersonen angelegt werden. Dabei stehen verschiedene Anmeldemöglichkeiten zur Verfügung. Mit Passwort, ohne Passwort, als Link usw.. Mehr dazu finden Sie auch hier.

Die Logins mit den Anmeldedaten werden dabei immer einer entsprechenden Gruppe (Group) mit eindeutiger ID zugewiesen. Zusätzlich zu den Anmeldedaten wird angegeben, welches Booklet der jeweiligen Testperson nach Anmeldung präsentiert werden soll. Außerdem wird hier der Modus (mode) der Testung festgelegt. Mit diesem Modus wird festgelegt wie der Test ablaufen soll (Probelauf, finale Testung). Mehr Informationen finden Sie dazu auch hier.

Es ist auch möglich einzelne Texte individuell für die Anwendung Testcenter anzupassen. Die Texte können dann in der Custom-Text-Konfiguration geändert werden. In der automatisch erzeugten Testtaker-Xml durch das Studio sind nur einzelne Elemente, Attribute und Werte von vielen in der Custom-Text-Konfiguration angegeben. Welche es noch gibt finden Sie hier unter Custom-Text-Konfiguration.

Nachfolgend ist die generierte Testtaker-Xml durch das Studio zu sehen. Hier wurde bereits der Name der automatisch generierten Gruppen-ID in einen eindeutigen kürzeren Namen geändert.

Hier können Sie den Code kopieren.

❗ Gruppen-ID und Name der Testperson dürfen im Testcenter nur einmal vorkommen. Befindet sich in einem anderen Arbeitsbereich ein Duplikat, ist das Laden der Testtaker-Xml in das Testcenter nicht möglich und wird mit einer entsprechenden Fehlermeldung abgelehnt. Daher sollten auch keine "Klarbezeichner" gewählt werden, sondern immer eine Kombination aus Buchstaben und Zahlen. Dies verringert die Wahrscheinlichkeit von Duplikaten.

Jeder Testmodus weist spezifische Eigenschaften auf. So werden bspw. Anworten einer Testung im Modus: run-review nicht gespeichert, im Modus: run-hot-return oder run-hot-restart aber schon. Eine Übersicht der verfügbaren Modi und deren Funktionen finden Sie hier.

Da mit den hier verwendeten Dateien später im Testcenter eine Testung gestartet werden soll und abschließend auch eine Auswertung der gegebenen Antworten erfolgen soll, sollten Sie für eine der Testpersonen den Modus: von run-review auf run-hot-return ändern und die Änderung anschließend speichern. Die Testung läuft dann wie eine "heiße" Testung ab. Zur Erinnerung: Im Review-Modus werden keine Antworten gespeichert und es könnte daher auch keine Auswertung erfolgen.

ℹ️ An dieser Stelle werden erst einmal die Änderungen an den Testdateien beendet. Führen Sie gerne einmal weitere Änderungen an den Dateien durch und schauen Sie sich im Testcenter die Auswirkungen auf die Testdurchführung an. Beispiele für Konfigurationen sind hier zu finden.