Diese Optionen erlauben es dem Benutzer Testfälle zu filtern bevor sie angezeigt werden. Wird das Häkchen gesetzt, werden die Daten angezeigt. Um die angezeigten Daten zu verändern, de-/aktiveren Sie das Feld, klicken Sie den Filter an und selektieren die gewünschte Datenstufe des Baums.
Dokument Header: Benutzer können Dokument-Header-Informationen filtern. Dokument-Header-Informationen umfassen: Einleitungen, Inhalte, Referenzen, Test Methodologien und Test Einschränkungen.
Testfall-Inhalt: Benutzer können den Testfall-Inhalt-Informationen filtern. Testfall-Inhalt-Informationen umfassen: Zusammenfassungen, Testschritten, erwartete Ergebnisse und Schlüsselwörter.
Testfall Zusammenfassung: Benutzer können Informationen der Testfall-Zusammenfassung aus dem Testfall-Titel filtern, jedoch nicht aus dem Testfall-Inhalt. Für eine kurze Zusammenfassung mit Titel (ohne Testschritte, erwartete Ergebnisse und Schlüsselwörter) ist die Testfall-Zusammenfassung nur Teilweise vom Testfall-Inhalt getrennt. Wenn der Benutzer sich entscheidet den Testfall-Inhalt anzuschauen, wird die Testfall-Zusammenfassung mit angezeigt.
Inhaltsverzeichnis: TestLink fügt eine Liste aller Titel mit internen Hypertext-Links hinzu, wenn diese Option aktiviert ist.
Ausgabeformat: Es gibt zwei Möglichkeiten: HTML und MS Word. Der Browser ruft MS Word im zweiten Fall auf.
"; // testPlan.html $TLS_hlp_testPlan = "Ein Test Plan ist ein systematischer Ansatz Software zu prüfen. Sie können Testaktivitäten von Builds verwalten und Ergebnisse verfolgen.
In diesem Abschnitt können Benutzer Testfälle ausführen, Test Ergebnisse erzeugen und die Test-Suite des Test Plans drucken. Ebenfalls können Sie die Ergebnisse ihrer Testausführung verfolgen.
In diesem Abschnitt, der nur gesondert zugänglich ist, können Test Pläne administriert werden.
Test Plan Administratoren können Test Pläne erzeugen, bearbeiten und löschen sowie Testfälle
hinzufügen, bearbeiten, löschen und aktualisieren. Außerdem können Builds erzeugt werden und
Benutzern den Zugriff auf ausgewählte Test Pläne ermöglichen.
Benutzer mit entsprechender Berechtigung können Priorität und Risiko bestimmen, den Besitz
an Test-Suiten (Kategorien) erwerben und Testmeilensteine erstellen.
Hinweis: Es ist möglich, dass ein leeres Dropdown ohne Test Plan erscheint. In diesem Fall werden alle Verknüpfungen (außer die freigegebenen) getrennt. Wenn das der Fall ist, setzen Sie sich bitte mit einem Admin in Verbindung. Dieser kann Ihnen die nötigen Zugriffsrechte gewähren oder einen Test Plan für Sie erstellen.
"; // custom_fields.html $TLS_hlp_customFields = "Einige Fakten über die Implementierung von benutzerdefinierten Feldern:
Benutzerdefinierten Felder haben die folgenden logischen Attribute:
Erlaubt es Nutzern Testfälle auszuführen. Die Ausführung selbst ist lediglich das Zuweisen eines Ergebnisses (OK, Fehlgeschlagen, Blockiert) an einen Testfall im ausgewählten Build.
Zugang zu einem Bug Tracking System kann konfiguriert werden. Nutzer kann neue BUGs hinzufügen und existierende durchsuchen. Der Installationsanleitung können weitere Informationen entnommen werden.
"; //bug_add.html $TLS_hlp_btsIntegration = "(falls konfiguriert) TestLink hat nur eine einfache Integration in ein Bug Tracking Systems (BTS), es ist nicht möglich eine Anfrage zum Erstellen eines BUGs an das BTs zu schicken. Ebenfalls ist es nicht möglich die BUG ID zu bekommen. Die Integration wird durch Verknüpfungen der BTS-Webseiten ermöglicht. Die folgenden Funktionen können aufgerufen werden:
Die Einstellungen erlauben es einen Test Plan, Build oder eine Plattform (falls vorhanden) auszuwählen um sie auszuführen.
Der geforderte Test Plan kann ausgewählt werden. Nach Auswahl des Test Plans werden die entsprechenden Builds angezeigt und die Filter zurückgesetzt.
Wenn die Plattform-Funktion genutzt wird, muss die entsprechende Plattform vor der Ausführung ausgewählt werden.
Das gewünschte Build, auf dem die Testfälle ausgeführt werden sollen, kann ausgewählt werden.
Filter bieten die Möglichkeit die Testfälle nach eigenen Wünschen anzuzeigen bevor sie ausgeführt werden. Mit bestimmten Filtern bzw. drücken der Schaltfläche 'Anwenden' kann die Anzahl der Testfall-Sätze reduziert werden.
Erweiterte Filter erlauben es schon angewandte Filter mit einer Reihe von Werten zu spezifizieren. Das wird mit einem STRG-Klick in der Multi-Select ListBox erreicht.
Nach Stichworten von Testfällen kann gefiltert werden. Mutliple Stichwörte " . "können über den STRG-Klick ausgewählt werden " . "Bei mehrfach ausgewählten Stichworten können die Testfälle angezeigt werden, ". "die alle (Optionsfeld \"UND\") oder mindestens eins (Optionsfeld \"ODER\") ". "dieser Stichworte beinhalten.
Testfälle können nach Test Prioritäten gefiltert werden. Die Test Prioritäten lauten \"Testfall Wichtung\" " . "und \"Test Dringlichkeit\" in dem aktuellen Test Plan.
Es kann nach Testfällen gefiltert werden, die zugewiesen an \"jemand\" oder nicht " . "zugewiesen an \"niemand\" sind. Es kann auch nach bestimmten Testern gefiltert werden. ". "Falls nach einem Tester gefiltert wird, können zusätzlich auch die Testfälle angezeigt werden, ". "die nicht zugewiesen sind (erweiterte Filter sind anwählbar).
Testfälle können nach ihren Ergebnissen gefiltert werden (erweiterte Filter sind anwählbar). Es kann gefiltert werden nach dem Ergebnis \"des ausgewählten Builds für die Ausführung\", ". " \"der letzten Ausführung\", \"ALLER Builds\", " . "\"BELIEBIGES Build\" und \"eines bestimmten Builds\". Falls ein \"bestimmtes Build\" ausgewählt wurde" . "muss das Build bestimmt werden.
"; // newest_tcversions.html $TLS_hlp_planTcModified = "Alle, dem Test Plan verknüpfte Testfälle, werden analysiert und gelistet, die die neuesten Versionen der Testfälle anzeigt (im Vergleich zum aktuellen Satz des Test Plans).
"; // requirementsCoverage.html $TLS_hlp_requirementsCoverage = "Diese Funktion erlaubt das Aufstellen einer Abdeckung von Benutzer- oder Systemanforderungen mit Testfällen. Auf der Hauptseite kann über \"Anforderungsspezifikation\" navigiert werden.
Anforderungen sind nach dem Dokument 'Anforderung Spezifikation', welches mit dem Test Plan
verbunden ist, gruppiert.
TestLink unterstützt nicht beide Versionen für die Anf.Spezifikation und
der Anforderung selbst. Also sollte die Version des Dokuments erst nach der Spezifikation eingefügt werden.
Titel.
Der Nutzer kann dem Feld Inhalt eine kurze Beschreibung oder Notiz hinzufügen.
Überschrieben Anzahl von Anf. Dient der Evaluation der Anf. Abdeckung, falls nicht alle Anforderungen importiert wurden. Der Wert 0 bedeutet, dass die aktuelle Anzahl der Anf. für Metriken genutzt wird.
Beispielsweise SRS beinhaltet 200 Anforderungen aber nur 50 sind in TestLink hinzugefügt worden. Die Test Abdeckung ist 25% (falls alle importierten Anforderungen getestet werden).
Mit einem Klick auf den Titel der erstellten Anf. Spezifikation kann für das Dokument Anforderungen erstellt, bearbeitet, gelöscht oder importiert werden. Jede Anforderung hat einen Titel, Inhalt und Status. Der Status sollte \"Normal\" oder \"Nicht testbar\" sein. Nicht testbare Anforderungen gehen in die Metriken nicht ein. Dieser Parameter kann für noch nicht implementierte Funktionen und falsch entworfenen Anforderungen genutzt werden.
Mit der Nutzung von Multi Aktionen mit abgehakten Anforderungen auf der Spezifikations Umgebung, können neue Testfälle für Anforderungen erstellt werden. Diese Testfälle werden der Test Suite mit dem konfigurierten Namen (Standard ist: $tlCfg->req_cfg->default_testsuite_name = \"Test Suite erstellt über Anforderung - Auto\";). hinzugefügt. Titel und Inhalt werden in die Testfälle kopiert.
"; $TLS_hlp_req_coverage_table = "Interne Links können genutzt werden um Links zu anderen Anforderungen/Anforderungsspezifikation
mit einer speziellen Syntax zu erstellen.
Das Verhalten der internen Links kann über die Konfigurationsdatei angepasst werden.
Benutzung:
Link zu einer Anforderung: [req]Anf_Dokument_ID[/req]
Link zu einer Anforderungsspezifikation: [req_spec]Anf_Spez_Dokument_ID[/req_spec]
Das Testprojekt und ein Anker der zu verlinkenden Anforderung kann ebenfalls angegeben werden:
[req tproj=<tproj_prefix> anchor=<anker_name>]Anf _Dokument_ID[/req]
Diese Syntax funktioniert auch für Anforderungsspezifikationen.
Immer wenn eine Änderung an einer Anforderung vorgenommen wird fragt Testlink nach einer Protokollierung der Änderung. Das Änderungsprotokoll dient der Rückverfolgbarkeit (Traceability).
Wenn sich nur der Inhalt der Anforderung ändert, steht es dem Autor frei, ob er eine neue Revision erstellen möchte oder nicht. Sollte sich etwas außer dem Inhalt ändern ist der Autor gezwungen, eine neue Revision zu erstellen.
"; // req_view $TLS_hlp_req_view = "Um Anforderungsdokumente so leicht wie möglich mit anderen teilen zu können bietet TestLink die Möglichkeit einen direkten Link zu diesem Dokument zu erzeugen. Klicken Sie dazu das Globus Icon an.
Dieses Feature erlaubt es Revisionen/Versionen von Anforderungen zu vergleichen, sofern mehr als eine Revision/Version der Anforderung existiert. Die Übersicht zeigt das Änderungsprotokoll, das Datum und den Autor der letzten Änderung für jede Revision/Version.
Zeigt alle Testfälle, die mit der Anforderung verknüpft wurden.
Beziehungen werden benutzt um Beziehungen zwischen Anforderungen zu modellieren. Benutzerdefinierte Beziehungen und die Möglichkeit Beziehungen zwischen Anforderungen in verschiedenen Projekten herstellen zu können, werden in der Konfigurationsdatei konfiguriert.
Setzt man die Beziehung \"Anforderung A ist Vater von Anforderung B\", wird Testlink die Beziehung \"Anforderung B ist Kind von Anforderung A\" implizit setzen.
"; // req_spec_edit $TLS_hlp_req_spec_edit = "Interne Links können genutzt werden um Links zu anderen Anforderungen/Anforderungsspezifikation
mit einer speziellen Syntax zu erstellen.
Das Verhalten der internen Links kann über die Konfigurationsdatei angepasst werden.
Benutzung:
Link zu einer Anforderung: [req]Anf_Dokument_ID[/req]
Link zu einer Anforderungsspezifikation: [req_spec]Anf_Spez_Dokument_ID[/req_spec]
Das Testprojekt und ein Anker der zu verlinkenden Anforderung kann ebenfalls angegeben werden:
[req tproj=<tproj_prefix> anchor=<anker_name>]Anf _Dokument_ID[/req]
Diese Syntax funktioniert auch für Anforderungsspezifikationen.