Read Microsoft Word - Testkonzept v1-1.doc text version

Testkonzept

Verfasser: Version: Status:

Rüdiger Muschner 1.1 freigegeben durch den Fachausschuss sh21 BASIS am 8. Februar 2006 Das vorliegende Konzept stellt den Status quo der bisherigen Erkenntnisse des Projektes dar. Erfahrungen und weitere Anforderungen, die sich aus der Stufe 2 ergeben, werden in die nächste Version des Konzeptes einfließen.

Testkonzept

I N H A L T S V E R Z E I C H N I S:

1

ZIEL

4

2

ZWECKORIENTIERTE TESTARTEN

6

3

KONFIGURATION

7

4

TEST VON KOMPONENTEN

9 9 10 10 11 11 11 12 12 12 13 14 14 15 17 17 18 18 19 19 19 20 20 20 21 21 22 22 23

4.1 PC (MIT BETRIEBSSYSTEM) 4.1.1 EXISTENZ 4.1.2 AKTIVIERUNG 4.1.3 SCHNITTSTELLEN 4.1.4 HINWEISE 4.2 PERIPHERE GERÄTE 4.2.1 EXISTENZ 4.2.2 AKTIVIERUNG 4.2.3 SCHNITTSTELLEN 4.3 APPLIKATION 4.3.1 EXISTENZ 4.3.2 AKTIVIERUNG 4.3.3 SCHNITTSTELLEN 5 VERBINDUNGSTEST (GESAMTINSTALLATION)

5.1 NETZ 5.1.1 PEER-TO-PEER 5.1.2 NETZ MIT SH21-SERVER 5.1.3 ASP 5.2 KOMMUNIKATION ZWISCHEN KOMPONENTEN 5.2.1 FERNBEDIENUNG - SCHULINTERN 5.2.2 SOFTWAREVERTEILUNG - SCHULINTERN 5.2.3 WEITERE SOFTWARE 5.3 KOMMUNIKATION NACH AUßEN 5.3.1 INTERNET 5.3.2 DIENSTLEISTER 6 6.1 6.2 TESTPLAN UMFANG DES TESTPLANES ZUSAMMENSTELLUNG DER AKTIVITÄTEN

Seite 2 /37

Testkonzept

6.3 7 7.1 7.2 7.3 7.4 8 8.1 8.2 8.3 8.4 9

FESTLEGUNG DER REIHENFOLGE TESTFALLBESCHREIBUNG VORBEMERKUNGEN EXISTENZNACHWEIS FORMULAR BESCHREIBUNG VERANTWORTLICHKEITEN ALLGEMEINES TEST DER TESTKONFIGURATION TEST NACH ÄNDERUNG DES KUNDENWARENKORBS ABNAHMETEST NACH INSTALLATION IN EINER SCHULE VORGEHEN IM FEHLERFALL

23 25 25 25 26 27 28 28 28 29 29 30 30 30 30 31 31 31 32 32 32 33 33 33 34 35 35 36 36 36 37

9.1 PRIORISIERUNG DES FEHLERS 9.2 VORGEHENSWEISE NACH PRIORITÄT DER FEHLER 9.2.1 PRIORITÄT 1 9.2.2 PRIORITÄT 2 9.2.3 PRIORITÄT 3 9.2.4 PRIORITÄT 4 9.3 ANLAGE: ZUSAMMENSTELLUNG DER TESTAKTIVITÄTEN A1 HARDWARE A1.1 PC MIT BETRIEBSSYSTEM A1.2 DRUCKER A2 STANDARDSOFTWARE A2.1 WORD A2.2 EXCEL A3 KUNDENWARENKORB A4 NETZ A5 KOMMUNIKATION ZWISCHEN KOMPONENTEN A6 KOMMUNIKATION NACH AUßEN A6.1 INTERNET A6.2 DIENSTLEISTER

Abbildungsverzeichnis:

ABBILDUNG 1: SCHEMATISCHE DARSTELLUNG DER KONFIGURATION DES TESTZENTRUMS 7

Seite 3 /37

Testkonzept

1 Ziel

Die Erarbeitung eines Testkonzeptes bedeutet, sich in dem Spannungsfeld zwischen möglichst vollständiger, alle Kombinationen berücksichtigender Testabdeckung einerseits und dem sachlich wirklich Erforderlichen sowie wirtschaftlich Vertretbaren andererseits zu bewegen. Für dieses Testkonzept folgt daraus: Es kann davon ausgegangen werden, dass fertige Komponenten in den Schulen bzw. in den Supporteinheiten, insbesondere im User Help Desk installiert werden. Die im Bereich der Serverlösung (Teilprojekt 3) oder sh21-Box erforderlichen Entwicklungsarbeiten werden hier nicht betrachtet, da davon ausgegangen werden kann, dass in den Entwicklungsbereichen angemessene Testkonzepte vorliegen und befolgt werden. Diese Prämisse bedeutet, dass die Funktionalität der einzelnen Komponenten nicht betrachtet zu werden braucht. Es kommt also nicht darauf an, dass die Funktionalität den Anforderungen (Spezifikationen) entspricht, die Anforderungen vollständig sind, eine ausreichende Akzeptanz findet oder anderen eher inhaltlichen Kriterien genügt. Diese Punkte müssen im Testkonzept für die Entwicklung berücksichtigt sein oder von Lieferanten (bei Hard- oder Standardsoftware einschließlich Betriebssysteme und Treiber) garantiert werden. In dem hier vorliegenden Kontext sind zu überprüfen: Einzelne Komponenten: o sind sie vorhanden, o lassen sie sich aktivieren (einschalten / starten) o werden die Schnittstellen richtig bedient: Input / Eingabe ggf. Zwischenspeicherung Output / Ausgabe Gesamtinstallation: o Netz o Kommunikation zwischen den Komponenten o Kommunikation nach außen Internet Dienstleister Ergebnis der Testdurchführung (Durchführung des ,,Vitalitätstests") ist:

Seite 4 /37

Testkonzept

In jeder Schule ist eine funktionsfähige Computerversorgung für Lehrzwecke nach den Projektvorgaben installierbar. Ziel dieses Testkonzeptes ist es, das genannte Ergebnis geplant und nachvollziehbar zu erreichen und nach der Installation zu verifizieren.

Seite 5 /37

Testkonzept

2 Zweckorientierte Testarten

Im Kapitel Ziel des Testkonzeptes wurde festgestellt, dass die Komponenten des Gesamtsystems als ,,Black Box" betrachtet werden, deren Funktionalität also als gegeben vorausgesetzt wird. Auch die im Test zu berücksichtigenden Aspekte sind aufgezählt worden. Um so wichtiger ist es nun, aufzuzählen, welche Anlässe es zum Test gibt, ausgedrückt durch Testarten: Gesamtsystemtest: Nachweis der Funktionsfähigkeit des im Projekt sh21 BASIS konzipierten Gesamtsystems und Nachweis der Eignung des Projektergebnisses für den pädagogischen Bereich innerhalb der Schulen. Dabei sind alle einzelnen Komponenten und die Gesamtinstallation zu berücksichtigen. Update-Test: Nachweis der Eignung neuer oder geänderter Komponenten einschließlich neuer ,,Gerätetypen", wie sie im Technischen Konzept erwähnt wurden. Allerdings ist nicht der ,,Eignungstest" von ,,Fremdhardware" abgedeckt. Es sind die neue / geänderte Komponente und aus dem Test der Gesamtinstallation nur die Punkte ,,Kommunikation zwischen den Komponenten" (soweit die neue Komponente betroffen) und ggf. ,,Netz" zu überprüfen. Abnahmetest: Nach der Installation in einer Schule ist das System von der Schule abzunehmen. Das kann nur durch einen Test geschehen. Dazu kann der Gesamtsystemtest herangezogen und auf die Testanforderungen der Schule zugeschnitten werden. Mit der Aufzählung der Testarten ist auch gleichzeitig der Geltungsbereich dieses Konzeptes festgelegt. Wegen der im Detail doch recht unterschiedlichen Vorgehensweisen bzw. Anforderungen wird folgendermaßen vorgegangen: Beschreibung der Konfiguration eines Testzentrums (Kapitel 3) Ermittlung der (theoretisch) erforderlichen Testaktivitäten in den Kapiteln 4 (Komponenten) und 5 (Gesamtsystem) Entwicklung eines Testplanes ­ Beschreibung der generellen Vorgehensweise. Die unterschiedlichen Testarten führen zu voneinander abweichenden Testplänen (Kapitel 6) Ermittlung von Testfällen: An Hand des geplanten Test-Prozesses werden die Testaktivitäten zu Fällen zusammengefasst (Kapitel 7) Das vorgeschlagene Vorgehen wird in den restlichen Kapiteln noch durch die Diskussion von Verantwortlichkeiten und dem Vorgehen im Fehlerfall abgerundet.

Seite 6 /37

Testkonzept

3 Konfiguration

Um die (zentralen) Testarten durchführen zu können, ist eine Art Testzentrum aufzubauen. Es liegt nahe, dieses auch zu anderen Zwecken zu nutzen: Fehlerklärung im User-Help-Desk oder von anderen Supportgebern, Funktionsfähigkeit von neuer für den Unterricht vorgeschlagener Software und als Demonstrationsanlage. Bei der Konfigurierung des Testzentrums sollte kein Unterschied zwischen den Netztopologien gemacht werden: Eine Konfiguration für das Netz mit einem sh21-Server, das nach Ausschalten des Servers als Peer-to-Peer-Netz betrieben wird. Das Thema ,,ASP" muss noch außerhalb der Betrachtung bleiben. Folgende Konfiguration wird vorgeschlagen:

Schüler-PC

Ggf. weitere Gerätetypen Switch

Lehrer-PC

Server

sh21-Box inkl. Router / Firewall

Peripherie wie Drucker, CD/DVD-Brenner ...

Internet

Dienstleister-PC z.B. zur Fernbedienung, Versenden MSI-Pakete

Abbildung 1: Schematische Darstellung der Konfiguration des Testzentrums Seite 7 /37

Testkonzept

Die Konfiguration ähnelt der schematischen Darstellung des ,,serverbasierten Netzes" aus dem Technischen Konzept. Dabei gibt es folgende Abweichungen: Im Prinzip reicht ein einziger Schüler-Arbeitsplatz. Bei Bedarf können weitere PC´s angeschlossen werden. Dies ist der Fall, wenn es mehrere Gerätetypen gibt, z.B. durch Wechsel des Herstellers oder Einbindung von ,,Fremd-PC´s". An den Lehrer-Arbeitsplatz ist Peripherie angeschlossen. Das ist erforderlich, um auch Treiber zu testen und Testergebnisse dokumentieren zu können. Zudem ist davon auszugehen, dass es Multimediaeinheiten gibt, deren Ansprechbarkeit auch nachgewiesen werden muss, wie z.B. Externe DVDGeräte oder Beamer. Es ist Vorsorge zu tragen, dass der sh21-Server möglichst einfach und schnell vom Netz zu nehmen ist. Denn nur so kann in das Peer-to-Peer-Netz gewechselt werden. Dabei ist zu beachten, dass das Depot für MSI-Pakete doppelt zu füllen ist: o auf dem sh21-Server und o auf der sh21-Box oder dem Lehrer-PC für das Peer-to-Peer-Netz. Der Internet-Anschluss darf nicht über das ,,Hausnetz" des Dienstleisters gehen, um zusätzliche Sicherheitsfunktionen durch Filter oder Firewall als Störungsquelle auszuschließen. Die Sicherheit muss allein durch die sh21-Box gewährleistet und nachgewiesen werden. Der Dienstleister ist in dieser Konfiguration durch einen einzelnen PC ersetzt, von dem aus die notwendigen Aktivitäten durchgeführt werden können. Es ist noch zu prüfen, in wie weit auch für diesen PC der spätere Übertragungsweg nachgeahmt werden muss. Über die Ausstattung dieses PC´s, auch hinsichtlich peripherer Geräte kann erst nach Festlegung des Testplanes / der Testpläne und Definition der Testfälle etwas ausgesagt werden. Diese Testkonfiguration muss vollkommen abgeschottet gegen andere Netze, also vollkommen isoliert installiert werden, da auch Netz-Aspekte betrachtet werden müssen, die teilweise eine recht hohe Sensibilität haben. Als Beispiel sei der Jugendschutz im Internet angeführt. Die endgültige Konfiguration einschließlich der zu berücksichtigenden peripheren Geräte muss gemeinsam mit dem Teilprojekt 3 festgelegt werden. Wünschenswert wäre es, wenn auch erste Erkenntnisse aus dem Teilprojekt 2 (ASP) berücksichtigt werden könnten.

Seite 8 /37

Testkonzept

4 Test von Komponenten

Bereits bei der Zieldefinition für dieses Konzept wurde klar herausgestellt, dass es nicht um den Test der Funktionalität der einzelnen Komponenten geht. Diese wird vorausgesetzt, da es vorwiegend um das Zusammensetzen einer Konfiguration aus Einzelkomponenten geht. Für den Test der Komponenten wurde aufgezählt: sind sie vorhanden (Existenz), lassen sie sich aktivieren (einschalten / starten), werden die Schnittstellen richtig bedient: o Input / Eingabe, o ggf. Zwischenspeicherung, o Output / Ausgabe. Zur weiteren Konkretisierung ist die Unterscheidung nach Komponententyp erforderlich: PC (mit Betriebssystem), Weitere periphere Geräte, Applikation (Software) . Die im folgenden aufgezählten Prüfungen beziehen sich nur auf Peer-to-Peer-Netze und sind aus dem Teilprojekt 3 um Aspekte zu ergänzen.

4.1 PC (mit Betriebssystem)

Es wird davon ausgegangen, dass der PC den Mindestanforderungen (Standardwarenkorb im Technischen Konzept) entspricht und ein im Warenkorb zugelassenes Betriebssystem installiert ist. Die Netzkarte zählt zum PC und entspricht den Anforderungen.

Seite 9 /37

Testkonzept

4.1.1 Existenz

Die Existenzprüfung ist in diesem Fall trivial. Sie wird durch einen Gerätepass nachgewiesen. Prüfung hier: Testobjekt: Voraussetzung 1. PC 1.1 Existenz Bestätigung des Herstellers, dass die Mindestanforderungen des Projektes eingehalten sind. Ergebnis Ja / nein Ja / Nein

Nummer Kriterium 1.1-1 Gerätepass vorhanden? 1.1-2 Identität (z.B. MACAdresse) gleich (Gerät / Pass)?

4.1.2 Aktivierung

Auch die Aktivierung des PC ist trivial, vor allem, da hier das Gerät einschließlich Betriebssystem isoliert, also noch nicht im Netz, betrachtet wird. Testobjekt: Voraussetzung 1.2 Aktivierung 1.1 erfolgreich abgeschlossen, PC an die Stromversorgung angeschlossen Nummer Aktivität Erwartetes Ergebnis (Soll) 1.2-1 Der PC wird einDer PC fährt hoch und es erscheint das geschaltet vom IQSH definierte Startmenü 1.2-2 Anmeldung als Passwort-Abfrage und anschließend ArAdministrator beit im Admin.-Status möglich 1.2-3 Überprüfen der Die Parameter des Betriebssystems entParameter sprechen den Vorgaben des IQSH 1.2-4 Lokale Anmeldung Keine Administratorrechte (Schüler)

Ist

Seite 10 /37

Testkonzept

4.1.3 Schnittstellen

Auf dieser ,,niedrigen" Ebene sind kaum Schnittstellen zu beachten und damit zu prüfen: Testobjekt: Voraussetzung Nummer Aktivität 1.3-1 Netzanschluss 1.3-2 Weitere Geräte wie Drucker, Brenner oder Beamer. Hier ist entweder eine Unterteilung oder der Konfi.Plan als Anlage erforderlich 1.3 Schnittstellen 1.2 erfolgreich abgeschlossen Erwartetes Ergebnis (Soll) Netzanschluss vorhanden Alle Geräte sind gemäß dem Konfigurationsplan für diesen PC angeschlossen. Das gilt auch für die Tastatur und die Maus, die bereits in 1.2 genutzt wurden

Ist

4.1.4 Hinweise

Vergleichbare Prüflisten sind auch für andere Computer erforderlich: sh21-Server: Die Vorgaben müssen im Teilprojekt 3 erstellt werden. sh21-Box: Die Vorgaben können erst nach Vorliegen des Gesamtkonzeptes erstellt werden. Diese Prüflisten für die einzelnen Punkte sind, wie auch die folgenden, so aufgebaut, dass relativ einfach daraus das Prüfprotokoll, d.h. der Nachweis der durchgeführten Testaktivitäten mit dem Ergebnis, in Form einer Tabelle abgeleitet werden kann.

4.2 Periphere Geräte

Je Gerätetyp ist ein individueller Prüfplan aufzustellen. Dies ist nicht Aufgabe dieses Konzeptes, da hier nur die ,,Prinzipien" festgelegt werden können. Wie die Prüfung aussehen könnte, wird am Beispiel eines Druckers gezeigt.

Seite 11 /37

Testkonzept

4.2.1 Existenz

Die Existenzprüfung des Druckers bezieht sich nicht nur auf die reine Hardware, fester Bestandteil der Druckerinstallation ist auch der Treiber. Testobjekt: 2. Drucker 2.1 Existenz Voraussetzung Bestätigung des Herstellers, dass die Mindestanforderungen des Projektes eingehalten sind. Nummer Kriterium Ergebnis 2.1-1 Gerätepass vorhanden? Ja / nein 2.1-2 Gerätetypischer Treiber auf Ja / Nein dem zugehörigen PC vorhanden und zugeordnet?

4.2.2 Aktivierung

Bei der Überprüfung der Aktivierung werden die physikalischen Schnittstellen (Stromanschluss und Anschluss an einen PC) vorausgesetzt. Der Stromanschluss ist eine selbstverständliche Betriebsvoraussetzung, der PC-Anschluss wurde im Punkt 4.1.3 überprüft. Testobjekt: Voraussetzung 2.2 Aktivierung 2.1 erfolgreich abgeschlossen, Drucker an die Stromversorgung und an einen PC angeschlossen Erwartetes Ergebnis (Soll) Ist Der Drucker ist in betriebsbereitem Zustand Die ,,Hilfsmittel", hier Papier und Tinte oder Toner sind vorhanden. Sollte das nicht der Fall sein, wird nachgebessert (kein Fehler, da Verbrauchsmaterial)

Nummer Aktivität 2.2-1 Der Drucker wird eingeschaltet 2.2-2 Kontrolle der ,,Hilfsmittel"

4.2.3 Schnittstellen

Die Schnittstellenprüfung ist in diesem Fall durchaus sinnvoll und erforderlich, gilt es doch den Weg von einem Programm über den Treiber bis zum Ergebnis auf dem Papier zu verfolgen. Dabei geht es nicht um den Test aller Möglichkeiten vom Formular bis zur Bildwiedergabe mit dem Nachweis der zugesicherten Anzahl von Graustufen oder Farben, es geht hier allein um die ,,Physik", wie sie durch den Treiber und die Hardware gegeben ist.

Seite 12 /37

Testkonzept

Ein Beispiel für eine nicht ausgetestete Schnittstelle: Das Kontoauszugsprogramm einer Sparkasse nutzt den vorhandenen Platz vollständig aus, um kurz vor dem Seitenumbruch noch eine Information zu platzieren. Beim Druck der Auszüge in einer anderen Sparkasse (mit anderen Druckern und Treibern) führt das zum Seitenüberlauf, so dass je Auszugsseite zwei Blätter bedruckt werden. Testobjekt: Voraussetzung Nummer Aktivität 2.3-1 Erzeugung und Ausdruck eines Dokumentes mit Maximalumfang an Daten auf einer Seite 2.3 Schnittstellen 2.2 erfolgreich abgeschlossen Erwartetes Ergebnis (Soll) Die Seite wird ausgedruckt, alle Zeichen einer Zeile und alle Zeilen auf der Seite sind sichtbar. Es wird kein Folgeblatt erzeugt, auch nicht ohne Bedruckung

Ist

4.3 Applikation

Bei der Erarbeitung von Testplänen oder ­konzepten besteht die Gefahr, sich an der Funktionalität der Programme und der Komplexität der Kombinatorik von Daten und Funktionen zu orientieren. Es sei noch einmal erwähnt: Das kann nicht Gegenstand dieses Konzeptes sein! Dazu ist ein anderer Ansatz erforderlich, der entwicklungsorientiert in mehreren Schichten vorgeht und unterstützende Tools zur Kombination sowie der Automation der Datengenerierung und Testdurchführung untersucht. Es wird vorausgesetzt, dass die Entwicklungstests zu einer ordnungsgemäßen Abnahme (Freigabe) des Softwareproduktes geführt hat.

Seite 13 /37

Testkonzept

4.3.1 Existenz

Die Existenzprüfung von Software bezieht sich nur auf die ordnungsgemäße Installation und ggf. Lizenzierung. Testobjekt: 3. Applikation ... (Name) 3.1 Existenz Voraussetzung Bestätigung des IQSH, dass diese Applikation im pädagogischen Bereich der Schule (eines Schultyps) eingesetzt werden darf. Nummer Kriterium Ergebnis 3.1-1 Installation auf Laufwerk C: Ja / Nein ordnungsgemäß? Ggf. Nachweis durch Installationsprotokoll 3.1-2 Ggf.: Lizenz vorhanden? Ja / Nein Ggf. Lizenzkey in den Installationsunterlagen 3.1-3 Ggf. Passwortschutz einge- Ja / Nein richtet? Ggf. Nachweis durch BerechtigungsProfil

4.3.2 Aktivierung

Die Überprüfung der Aktivierung bezieht sich in erster Linie auf die Fragen: Lässt sich die Software aufrufen, kann sie gestartet werden, ist ggf. der Lizenzkey eingegeben und funktioniert ggf. der Passwortschutz? Testobjekt: Voraussetzung Nummer Aktivität 3.2-1 Aufruf der Software 3.2 Aktivierung 3.1 erfolgreich abgeschlossen, Erwartetes Ergebnis (Soll) Ist Die Software wird geladen und meldet sich mit der ersten Eingabeaufforderung, je nach Software: Passworteingabe Erstes Auswahlmenü Beginn der Bearbeitung Sonderfall: Lizenz- Endet die Aktion 3.2-1 mit der Auffordekey-Eingabe rung, einen Lizenzkey einzugeben, ist das zu tun, zu speichern und die Anwendung zu schließen. Bei einem erneuten Aufruf darf die Anforderung nicht kommen Sonderfall: Passworteingabe:

Seite 14 /37

3.2-2

3.2-3

Testkonzept

3.2-3.1 3.2-3.2 3.2-3.3

Erstmalige Eingabe Passworteingabe Eingabe eines falschen Passwortes

3.2-4

Passwort wird akzeptiert und aufgefordert, das Standardpasswort zu ändern Passwort wird akzeptiert Anmeldung wird zurückgewiesen und zur nochmaligen Eingabe aufgefordert. Ggf. nach mehrmaliger Falscheingabe: Abbruch des Anmeldeverfahrens Aufrufen und Das Ergebnis ist von dem Programm und Durchführen einer der Funktion abhängig. Es wird in einer typischen Funktion sog. Testfallbeschreibung präzisiert

Sinn der Aktivität 3.2-4 ist es zu gewährleisten, dass nicht nur ein ,,Rahmen" installiert wurde, sondern auch die erforderlichen Bearbeitungsmodule. Um das nachzuweisen, reicht bei Microsoft Word z.B. die Erfassung eines kurzen Textes, bei Microsoft Excel die Erstellung einer kurzen Tabelle mit mindestens einer einfachen Formel. Die Definition dieses einen ,,typischen" Anwendungsfalles ist Applikationsindividuell vorzunehmen. Eine Testfallbeschreibung sieht so ähnlich aus wie die obige Tabelle. Ein vereinfachtes Beispiel wird unter 4.3.3 gegeben.

4.3.3 Schnittstellen

Zu den in diesem Umfeld zu testenden Schnittstellen gehören: Tastatur (bereits in 4.3.1 oder 4.3.2 genutzt) Maus (bereits in 4.3.1 oder 4.3.2 genutzt) Zwischenspeicher Periphere Geräte wie z.B. Drucker Andere Programme Datenspeichersysteme Die Schnittstellen zu Komponenten, die nur über das Netz erreichbar sind, werden im Kapitel 5 (Gesamtinstallation) überprüft. Die in diesem Kontext erforderlichen Testaktivitäten sind abhängig von dem Programm und den Schnittstellen. Als Beispiel sei das Programm ,,Microsoft Word" genommen, bei dem die Schnittstellen zur Datenspeicherung und Drucker getestet werden sollen: Testobjekt: Voraussetzung Nummer Aktivität 3.3-1 Durchführen Testfall ,,Word x.y" 3.3 Schnittstellen 3.2 erfolgreich abgeschlossen Erwartetes Ergebnis (Soll) Ist Die in der Testfallbeschreibung definierten Ergebnisse

Seite 15 /37

Testkonzept

Die Testfallbeschreibung könnte etwa folgendermaßen aussehen: Testfall: Voraussetzung Verantwortung / Durchführung Nr. Aktivität 1 Word Starten Word x.y Word installiert Name(n), ggf. Kurzzeichen

Erwartetes Ergebnis (Soll) Ist Word zeigt das Eingabefenster für die Eingabe eines neuen Dokuments an 2 Eingabe eines Textes ggf. Der eingegebene Text wird vollstännach Vorgabe dig angezeigt 3 Speichern auf Laufwerk D: Die Speicherung wird durchgeführt, im Pfad ,,Userdata" unter die Textanzeige bleibt erhalten, der dem Namen ,,Testxy" Dokumentenname hat sich geändert 4 Beenden der Anwendung Word wird beendet, das ursprüngliWord che Auswahlmenü erscheint 5 Starten Word Wie bei Aktivität 1 6 Öffnen Dokument ,,Testxy" Das Dokument wird vollständig angezeigt 7 Drucken Das Dokument wird vollständig auf dem Drucker ausgegeben 8 Beenden der Anwendung Word wird beendet, das ursprüngliWord che Auswahlmenü erscheint Testergebnis: Testfall erfolgreich abgeschlossen / Testfall mit Fehlern abgeschlossen Datum Name Hinweise zur Fehlerbereini- ........ gung: Zur Dokumentation: Aufbewahrungs- / Archivierungsstelle Es ist zu vermeiden, dass bei der Formulierung der Aktivitäten die Bedienungsanleitung nachempfunden wird, d.h. es wird nur beschrieben, was zu tun ist (Speichern), und nicht, wie es erfolgen muss. Auf das Wort ,,Unterschrift" im obigen Testfallbeispiel wurde bewusst verzichtet, da es bei genauer Befolgung eine Papierversion erzwingt, eine ausschließlich elektronisch verwaltete Testdokumentation also ausschließt. Das Beispiel macht auch deutlich, dass es sinnvoll ist, mehrere formal erforderliche Testaktivitäten in einem Testfall zusammenzufassen. So ist z.B. die Aktivität 3.2-4 ebenfalls vollständig abgedeckt.

Seite 16 /37

Testkonzept

5 Verbindungstest (Gesamtinstallation)

Wie bereits im Kapitel 4 (Test von Komponenten) werden zunächst themenorientiert die Testaktivitäten ermittelt. Es ist deutlich geworden, dass diese Aufzählung nicht in jedem Fall eine Reihenfolge erzwingt und in einen eigenständigen Testfall münden muss, wie die Testfallbeschreibung in 4.3.3 gezeigt hat. Was in welcher Reihenfolge tatsächlich getestet werden muss, wird an späterer Stelle (Testplan) erläutert. Auch das ,,Wie", dokumentiert in Testfällen, wird an späterer Stelle noch einmal aufgegriffen. Für den Verbindungstest wurden im Kapitel 1 (Ziel) folgende Aspekte aufgezählt: Netz Kommunikation zwischen den Komponenten Kommunikation nach außen o Internet o Dienstleister Unter dem Thema Netz (5.1) ist in erster Linie die Erreichbarkeit / die gegenseitige Ansprechbarkeit zu betrachten. Der Informationsaustausch oder die gegenseitige Beeinflussung z.B. durch Fernbedienung wird im Kapitel 5.2 untersucht. Das Kapitel 5.3, die Öffnung nach außen, setzt die Funktionalität der sh21-Box voraus, so dass die gesamte Thematik der Filterung oder Absicherung der Übertragungswege wie z.B. Verschlüsselung hier unberücksichtigt bleiben kann. Für alle weiteren Betrachtungen ist selbstverständliche Voraussetzung, dass das Netz mindestens ähnlich der schematischen Darstellung in Kapitel 3 installiert ist und dabei mindestens zwei PC´s angeschlossen sind, wobei einer den Status ,,LehrerPC" annehmen kann, und das lokale Netz durch die sh21-Box nach außen abgeschottet ist. Lediglich der sh21-Server hat eine Sonderstellung: Er ist Voraussetzung für serverbasierte Netze und spielt eine wichtige Rolle in dem dafür geeigneten Testkonzept. Hier wird er nur gebraucht um nachzuweisen, dass ein derartiges Netz auch bei Serverausfall lokal als Peer-to-Peer läuft.

5.1 Netz

Der Aspekt Netz ist mit den Unterscheidungen Peer-to-Peer, Netz mit sh21-Server (Teilprojekt 3) und ASP (Teilprojekt 2) im schulinternen Bereich (lokales Netz) zu betrachten. Die Öffnung nach außen ist Gegenstand des Kapitels 5.3. In wie weit ASP einer eigenständigen Betrachtung beSeite 17 /37

Testkonzept

darf, kann erst nach Vorliegen des ASP-Konzeptes entschieden werden. Es ist jedoch zu vermuten, da der ASP-Server wahrscheinlich nicht in der Schule steht, also jede Verbindung zwischen Netzkomponenten das schulinterne Netz verlässt.

5.1.1 Peer-to-Peer

Unter dem Aspekt Netz soll lediglich die Erreichbarkeit nachgewiesen werden: Testobjekt: Voraussetzung 5.1.1 Netz ­ Peer-to-Peer Netz mit allen Komponenten (Hard- und Software) installiert, Komponententest erfolgreich abgeschlossen Nummer Aktivität Erwartetes Ergebnis (Soll) Ist 5.1.1-1 Freigabe von Res- Die Ressourcen können von anderen sourcen für andere PC´s genutzt werden (z.B. eine Datei). PC´s Bezug zu Aktivität 5.1.1-2 5.1.1-2 Lesen von Daten Bezug: Aktivität 5.1.1-1 eines anderen PC´s 5.1.1-3 Nutzen von Netz- Nur über das Netz erreichbare periphere ressourcen Geräte können genutzt werden, z.B. Erzeugen eines Ausdrucks auf einem Netzdrucker 5.1.1-4 Lehrer-PC: Alle Durchführung von Aktivität 5.1.1-2 auf alSchüler-PC´s wer- len Schüler-PC´s bringt positive Ergebnisden angesprochen se (Dateien werden angezeigt)

5.1.2 Netz mit sh21-Server

Die Erreichbarkeit aller an das Netz angeschlossener Komponenten wird hier nicht beschrieben, eine Vervollständigung durch das Teilprojekt 3 ist erforderlich. Wegen der Anforderung, dass derartige Netze bei Serverausfall wie Peer-to-Peer betrieben werden sollen, ist erforderlich: Testobjekt: Voraussetzung 5.1.2 Netz ­ sh21-Server Netz mit allen Komponenten (Hard- und Software) installiert, Komponententest erfolgreich abgeschlossen Erwartetes Ergebnis (Soll) An den Arbeitsplätzen ist eine ,,lokale" Anmeldung erforderlich, das Netz ist betreibbar, die Aktivitäten 5.1.1-1 bis 5.1.1-4 können durchgeführt werden

Nummer Aktivität 5.1.2-1 Abschalten des Servers

Ist

Seite 18 /37

Testkonzept

5.1.3 ASP

Dieser Punkt wird nach Vorliegen des ASP-Konzeptes betrachtet.

5.2 Kommunikation zwischen Komponenten

In der generellen Betrachtung sind die Punkte Fernbedienung und SoftwareVerteilung, beides beschränkt auf das schulinterne Netz, zu überprüfen. Es gibt im ,,Kundenwarenkorb" Software, die im Zusammenspiel mit mehreren Netzkomponenten (Arbeitsplätzen) eingesetzt werden soll. Für diese Programme sind an dieser Stelle nach Vorgaben des IQSH weitere Aktivitäten einzuplanen.

5.2.1 Fernbedienung - schulintern

Testobjekt: Voraussetzung Nummer Aktivität 5.2.1-1 Lehrer-PC: Beobachten eines Schüler-PC 5.2.1-2 Fernbedienung 5.2.1 Fernbedienung Testaktivitäten zu 5.1 erfolgreich abgeschlossen Erwartetes Ergebnis (Soll) Auf dem Lehrer-PC kann die Aktivität an einem Schüler-PC beobachtet werden Auf dem Lehrer-PC kann ein Schüler-PC fernbedient werden, der Schüler sieht die Aktivitäten des Lehrers Die Aktivitäten des Lehrers können auf allen PC´s einer (Arbeits-)Gruppe verfolgt werden Ein vorher im Stand-by-Modus befindlicher Schüler-PC wird hochgefahren Der Schüler-PC bzw. alle PC´s der Gruppe werden ausgeschaltet, d.h. gehen in den Stand-by-Modus

Ist

5.2.1-3

Lehrer-PC: Demonstration Lehrer-PC: Einschalten eines Schüler-PC Lehrer-PC: Ausschalten eines Schüler-PC´s und einer Gruppe

5.2.1-4

5.2.1-5

Diese Aktivitäten klingen fast wie ein Funktionstest der Fernbedienungssoftware, sind hier aber trotzdem erforderlich, da viele Aspekte der konkreten Konfiguration die Ergebnisse beeinflussen können. Deswegen wurden die Aktivitäten auch auf ein Mindestmaß beschränkt mit dem Ziel, das Zusammenspiel der Komponenten zu überprüfen.

Seite 19 /37

Testkonzept

5.2.2 Softwareverteilung - schulintern

Testobjekt: Voraussetzung Nummer Aktivität 5.2.2-1 Start der MSIEngine auf einem PC 5.2.2-2 Start der neuen SW 5.2.2 Softwareverteilung Testaktivitäten zu 5.2.1 erfolgreich abgeschlossen Erwartetes Ergebnis (Soll) Ist Die für den PC vorgesehene, neue oder geänderte Software wird auf das Laufwerk C: geladen, die Verteilung wird in der Zuordnungstabelle vermerkt Ein neu geladenes Programm wird geladen und lässt sich erwartungsgemäß bedienen

5.2.3 Weitere Software

Nach Vorgabe des IQSH kann weitere Software in die Testaktivitäten zum Verbindungstest eingebunden werden.

5.3 Kommunikation nach außen

Über die sh21-Box (deren Funktionalität hier nicht getestet werden soll ­ das ist ein getrenntes Testkonzept) führen die Kommunikationswege in das Internet und zum Dienstleister zur Fernbedienung / -wartung sowie zur Softwareverteilung. Sollten weitere direkte Verbindungen aufgenommen werden, z.B. zu einem dedizierten Lernsystem, sind entsprechende Testaktivitäten zum Nachweis der Existenz des Anschlusses aufzunehmen.

Seite 20 /37

Testkonzept

5.3.1 Internet

Testobjekt: Voraussetzung 5.3.1 Internet Testaktivitäten zu 5.2 erfolgreich abgeschlossen Nummer Aktivität Erwartetes Ergebnis (Soll) 5.3.1-1 Aufruf einer vorge- Die aufgerufene Internetseite wird vollgebenen Internet- ständig angezeigt. seite

Ist

Weitere Tests sind nicht erforderlich, denn sie wurden Im Rahmen des sh21-BoxTests durchgeführt. Dies betrifft auch (und gerade) das ausgewählte und installierte Filterprinzip.

5.3.2 Dienstleister

Testobjekt: Voraussetzung 5.3.2 Dienstleistung Testaktivitäten zu 5.2.1 erfolgreich abgeschlossen Nummer Aktivität Erwartetes Ergebnis (Soll) Ist 5.3.2-1 Dienstleister: Her- Der Dienstleister sieht nach Herstellen der stellen der Verbin- Verbindung das Bild des ausgewählten dung Schul-PC´s (Lehrkraft oder Schüler) 5.3.2-2 Dienstleister: Auf- Auf dem Arbeitsplatz-PC des ruf eines ProDienstleisters ist das Startmenü sichtbar, grammes das auf dem Schul-PC ebenfalls gesehen wird. Die Bedienungsfolge kann am SchulPC mit verfolgt werden. 5.3.2-3 Dienstleister: Ab- Das Übertragungsprotokoll ist fehlerfrei. senden eines MSI- Das Paket (inklusive Zuordnungstabelle) Paketes kann auf dem Depot-Server des Schulnetzes gefunden und eingesehen werden. An dieser Stelle wird wieder einmal deutlich, dass die Funktionalität der beteiligten Prozeduren / Komponenten vorausgesetzt wird. Deswegen braucht nur die ,,Vitalität" nachgewiesen zu werden, deswegen reichen diese wenigen Arbeitsschritte. Es bleibt dem für den Test Verantwortlichen unbenommen, zur eigenen ,,Sicherheit" beliebig viele weitere Tests durchzuführen.

Seite 21 /37

Testkonzept

6 Testplan

In den Kapiteln 4 und 5 wurden Testaktivitäten identifiziert, die unabhängig von der Testart, die mit dem Testkonzept abgedeckt werden soll, allein aus den Komponenten bzw. deren Verbindung abgeleitet wurden. Obwohl diese Aktivitäten allein aus dem Blickwinkel der Vitalität (Existenz und Nutzbarkeit) unter Vermeidung inhaltlicher Aspekte (Funktionalität) zusammengestellt wurden, ergibt sich eine Fülle von Aktivitäten, die erst erahnbar sind, da an vielen Stellen nur beispielhaft die Komponenten aufgeführt sind. Hier bedarf es sogar noch einer Vervollständigung. In der vorliegenden und im Anhang vervollständigten Version ergibt sich noch kein praktikables Vorgehen, weitere Aktivitäten sind erforderlich: Erstellen eines Testplanes und Erarbeiten von Testfällen aus den Testaktivitäten.

6.1 Umfang des Testplanes

Im ersten Schritt ist festzuhalten, welche Komponenten sind neu, welche Verbindungen innerhalb des Schulnetzes oder nach außen sind neu, welche Komponenten haben sich geändert und welche Verbindungen wurden geändert? Mit diesen Fragestellungen soll deutlich gemacht werden, dass der Geltungsbereich dieses Konzeptes recht generell angelegt ist. Es bietet somit die Möglichkeit, durch Auswahl der betroffenen Komponenten und Verbindungen auf konkrete Bedürfnisse zurechtgeschneidert zu werden: es kann genutzt werden, um die neu eingerichtete Testumgebung abzusichern, bei Änderungen der Hard- und / oder Software (Update-Testkonzept) und Abnahmetest von Installationen in Schulen, auch hier unterteilt in o Neuinstallation und o Änderung der Installation. An dieser Stelle muss zum wiederholten Male erinnert werden, dass dieses Konzept davon ausgeht, dass die Funktionalität der einzelnen Komponenten bereits vorher abgesichert ist, dass jede Komponente also vom Hersteller, Lieferanten oder dem IQSH bzw. dem Dienstleister zur Nutzung im schulischen Bereich freigegeben wurde. Das bedeutet z.B. bei einer neuen Betriebssystemversion: Die Version ist ablauffähig unter den Mindestanforderungen des StandardWarenkorbs. Die neue Version ist für alle auf dem Betriebssystem laufenden Applikationen freigegeben (Angabe des Herstellers der Applikationen), ggf. muss der Warenkorb geändert werden.

Seite 22 /37

Testkonzept

Ggf. durch Test wurde nachgewiesen, dass es keine Verbindungseinschränkungen (z.B.: Treiberprogramme) gibt oder es zu sonstigen gegenseitigen Beeinflussungen kommt. Dieser Freigabetest neuer Programmversionen wird durch dieses Konzept ebenso wenig abgedeckt wie der ,,Eignungstest" von Fremdhardware. Denn dazu sind spezielle Testkonzepte, zugeschnitten auf die Komponente, erforderlich. Im ersten Schritt wird also der Umfang des zu Testenden, die Testobjekte (Komponenten und Verbindungen) festgestellt. Hilfreich dabei sind Konfigurationspläne (vorhandene / Ziel-Konfiguration) und Aufträge für Applikationen aus dem Kundenwarenkorb (Lernprogramme, fakultative Programme). Als Ergebnis wird eine Aufzählung der zu testenden Komponenten und Verbindungen erwartet (oder Verweis auf eine Liste mit einer derartigen Zusammenstellung). Bei Änderungen, die eine Vielzahl von Komponenten und Verbindungen betreffen, ist ggf. der Test des Gesamtsystems sinnvoll und zeitsparender.

6.2 Zusammenstellung der Aktivitäten

Nach der Identifizierung der Komponenten und Verbindungen können die formal erforderlichen Testaktivitäten zusammengestellt werden, wie sie zum Teil nur exemplarisch in den Kapiteln 4 und 5 aufgeführt sind. Zur Vereinfachung wird in der Anlage, wie bereits angedeutet, eine vervollständigte Aufzählung zusammengestellt. Das Wort ,,formal" wurde absichtlich gewählt, um anzudeuten, dass es keinen Sinn macht, jede dieser Aktivitäten isoliert in der aufgeführten Reihenfolge durchzuführen (Zusammenfassung zu Testfällen). Erwartetes Ergebnis: Liste der erforderlichen Testaktivitäten mit Vorgabe der Reihenfolge, soweit fachlich erforderlich oder arbeitsökonomisch sinnvoll.

6.3 Festlegung der Reihenfolge

Die Aufzählung der Testaktivitäten erfolgte in erster Stufe immer nach rein technischen Gesichtspunkten, die einfachste Art, zumindest nahezu Vollständigkeit zu erreichen. Die so gegebene Reihenfolge kann weder logische Gesichtspunkte noch Aspekte der Effektivität berücksichtigen. Es bietet sich z.B. an, die Existenzprüfung von Software (Speicherung auf dem Laufwerk C: und ggf. Lizenzierung) in einem Arbeitsgang für alle Produkte durchzuführen. Testaktivitäten zur Aktivierung können in weiten Teilen gemeinsam mit den Schnittstellentests durchgeführt werden, wie auch das Beispiel in Kapitel 4.3.3 zeigt. Das gilt sogar Komponenten übergreifend.

Seite 23 /37

Testkonzept

Nach der Zusammenstellung der Aktivitäten können diese in einem zweiten Arbeitsschritt zu ,,Testprozessen" oder besser: Testfällen zusammengefasst werden. Dabei können die logischen Abhängigkeiten und die Effektivität berücksichtigt werden. Ein erster Anhaltspunkt für die Reihenfolge ist zwar die Gliederung dieses Konzeptes (erst Komponenten dann Verbindungen), diese Reihenfolge ist aber nicht zwingend! Erwartetes Ergebnis: Vervollständigung der Liste der Testaktivitäten mit Hinweisen zur Zusammenfassung zu Testprozessen.

Seite 24 /37

Testkonzept

7 Testfallbeschreibung

7.1 Vorbemerkungen

Bei der Beschreibung der Testaktivitäten in den Kapiteln 4 und 5 ist deutlich geworden, dass es im Prinzip zwei Typen von Aktivitäten gibt: Kontrollabfragen bei den Existenznachweisen und echte Testaktivitäten. Diese beiden Typen sollen auch getrennt behandelt werden, wobei die Bezeichnung der Vollständigkeitsprüfung als ,,Testfall" diskussionswürdig ist. Sie wird trotzdem hier benutzt. Für die Beschreibung der Testfälle wird ein Formular vorgeschlagen, das es ermöglicht, die bereits vorliegende Beschreibung der Testaktivitäten, wie sie in den Kapiteln 4 und 5 exemplarisch und im Anhang vollständig aufgeführt ist, als Einzelaktivität zu kopieren.

7.2 Existenznachweis

Bei den Kontrollfragen zum Existenznachweis geht es im Prinzip nur um die Antworten ,,Ja" oder ,,Nein", ggf. mit Verweis auf weitergehende Unterlagen wie z.B. Lizenzen. Das kann für die Gesamtkonfiguration in einer Tabelle zusammengefasst werden wie z.B. in folgender Form: Nr. H1 Komponente L-AP S-AP1 S-AP2 PC: Gerätepass vorhanden? Identität übereinstimmend? H2 Drucker: Im Gerätepass? Treiber vorhanden? H... Weitere Periphere Geräte ..... Sn Software (Applikation) n auf Laufwerk C: installiert? ggf. Lizenz vorhanden? Ggf. Passwortschutz eingerichtet? Testergebnis: Testfall erfolgreich abgeschlossen / Testfall mit Fehlern abgeschlossen Datum Name Hinweise zur Fehlerbereini- ........ gung: Zur Dokumentation: Aufbewahrungs- / Archivierungsstelle

Seite 25 /37

usw.

Testkonzept

Legende:

Nr.:

H... = Hardware S... = Software L-AP: Lehrer-Arbeitsplatz S-AP: Schülerarbeitsplatz

Ab Spalte 3 ist für den jeweiligen Arbeitsplatz bei der Komponente mit den Unterpunkten nur ,,Ja", ,,Nein" oder ,,-,, (für den Arbeitsplatz nicht beauftragt / entfällt) einzutragen und ggf. ein Verweis auf weitergehende Unterlagen aufzunehmen. Geräte, die direkt am Schulnetz hängen (z.B. Netzdrucker), können beim Arbeitsplatz des Lehrers oder in einer eigenen Spalte (,,Netz") berücksichtigt werden. Ein ,,Nein" in einer Zelle bedeutet: Unvollständige Installation / Implementierung, Fehlerfall.

7.3 Formular

Um keine Angaben zu vergessen und die Testaktivitäten nachvollziehbar zu machen, wird vorgeschlagen, ein Formular zu nutzen. Es könnte wir folgt aussehen: Testfall: Voraussetzung Genaue Bezeichnung des Testfalles Benennung der Voraussetzungen, ggf. Bezug auf vorangehende Testfälle. Die dort genannten Voraussetzungen gelten weiter Verantwortung / Durchfüh- Name(n), ggf. Kurzzeichen rung Datum Nr. Aktivität Erwartetes Ergebnis (Soll) Ist 1 Bezeichnung der Aktivität Beschreibung des erwarteten Ergebnisses ... dto. dto.

Testergebnis:

Testfall erfolgreich abgeschlossen / Testfall mit Fehlern abgeschlossen

Datum Name Hinweise zur Fehlerbereini- Vorgehen im Fehlerfall mit gung: Priorisierung (verhindert produktiven Einsatz / wird in OP-Liste aufgenommen, ...) Weiterleitung an ... Zur Dokumentation: Aufbewahrungs- / Archivierungsstelle Ein Muster ist in Kapitel 4.3.3 angegeben. Das Formular kann individuell angepasst oder erweitert werden.

Seite 26 /37

Testkonzept

7.4 Beschreibung

Im Kapitel 6.3 wurden die Testaktivitäten zu Testprozessen zusammengefasst. Ein Testprozess entspricht nun einem Testfall. Nicht in einem Prozess aufgeführte Aktivitäten bilden eigene (kurze) Testfälle. Wichtig ist lediglich, dass alle Aktivitäten in mindestens einem Testfall vorkommen. Die einem Testfall zugeordneten Aktivitäten können aus der Anlage zu diesem Konzept direkt in das Formular für die Testfallbeschreibung, wie es in Kapitel 7.2 vorgeschlagen wurde, kopiert werden. Dabei ist ggf. eine Konkretisierung erforderlich. Die Angabe einer Internet-Adresse oder einer Formel sind Beispiele für die Konkretisierung.

Seite 27 /37

Testkonzept

8 Verantwortlichkeiten

8.1 Allgemeines

Neben der Klärung des ,,Was" und ,,Wie" in den vorangehenden Kapiteln ist auch die Diskussion des verantwortlichen ,,Wer" erforderlich. Ideal wäre es, wenn es ein eigenständiges Testzentrum gäbe, in dem nach Vorgabe der Testobjekte eigenständig (in eigener Verantwortung) der Test durchgeführt werden könnte. Das Projekt sh21 BASIS ist weder während der eigentlichen Projektlaufzeit noch in der darauf folgenden Produktivphase arbeitsintensiv genug, um ein Testzentrum als eigenständige Organisationseinheit auszulasten. Das war mit ein Grund, bei der Darstellung der (Test-)Konfiguration auf weitere Verwendungsmöglichkeiten hinzuweisen. Bevor ,,Ersatz"-Maßnahmen vorgeschlagen werden, soll ein selbstverständlicher Grundsatz vorangestellt werden: Es gilt das Vieraugenprinzip! Wer tut (installiert / implementiert / parametriert), führt keinen Freigabe- oder Abnahmetest seiner eigenen Arbeit durch.

8.2 Test der Testkonfiguration

Die im Kapitel 3 schematisch dargestellte Testkonfiguration unterliegt einem Abnahmetest. Die Konfiguration wird von der ,,Installationseinheit" zusammengestellt und implementiert. Da diese Arbeiten während der Projektphase stattfinden, ist für die Erstellung des Testplanes und die Zusammenstellung und Beschreibung das Projekt, genauer jedes Teilprojekt für seinen Bereich verantwortlich. Es kann sich dabei der Installationseinheit bedienen indem sie sie beauftragt, die Gesamtverantwortung, d.h. Kontrolle der durchzuführenden Arbeitsschritte, Einhaltung des Vieraugenprinzips und Würdigung der Testergebnisse verbleibt aber bei dem Teilprojekt. Der Teilprojektleiter kann zu diesem Zweck eine Person benennen. Diese Aussagen gelten auch bei der Erweiterung der Konfiguration, z.B. Einbindung von ,,Fremd-PC´s" zur Erzeugung von Images für neue Gerätetypen (vgl. Ressourcenmanagement im technischen Konzept). Nach Beendigung des Projektes sh21 BASIS gehen die Projektergebnisse in die normale Produktion über. In derartigen Fällen ernennen Dienstleister, so auch Dataport, sogenannte Produktverantwortliche, die dann die Verantwortung übernehmen.

Seite 28 /37

Testkonzept

8.3 Test nach Änderung des Kundenwarenkorbs

Der Kundenwarenkorb (die Lehrprogramme) wird vom IQSH zusammengestellt und weiterentwickelt. Deswegen liegt die Verantwortung für den Test dieser Programme (Test nach pädagogischen und funktionalen Gesichtspunkten, nicht Gegenstand dieses Konzeptes) und vor allem für die Einbindung dieser Programme in das sh21System und dessen Absicherung durch einen Test (Gegenstand dieses Konzeptes) beim IQSH. Es kann den Dienstleister mit der Durchführung beauftragen, die Gesamtverantwortung ist jedoch nicht delegierbar im Sinne der unter 8.2 aufgeführten drei Punkte.

8.4 Abnahmetest nach Installation in einer Schule

Nach der Installation eines Systems in einer Schule und nach Änderungen der Konfiguration (Hard- und / oder Software) sind Abnahmetests erforderlich. Da die Schule bzw. der Schulträger auftraggebende Stelle ist, muss sie auch die Abnahme erklären ­ nach einem Abnahmetest. Die Verantwortung liegt eindeutig bei der Schule bzw. dem Schulträger. Sie kann den Dienstleister mit der Durchführung beauftragen, die Gesamtverantwortung ist jedoch nicht delegierbar im Sinne der unter 8.2 aufgeführten drei Punkte.

Seite 29 /37

Testkonzept

9 Vorgehen im Fehlerfall

Bei der Durchführung der Tests kann sich zeigen, dass die eine oder andere Testaktivität nicht das erwartete Ergebnis zeigt. Tritt ein derartiges Ereignis ein, ist folgendermaßen vorzugehen:

9.1 Priorisierung des Fehlers

Die hier definierten Test-Fehler-Prioritäten haben nichts mit den Prioritäten zu tun, die im Rahmen des Incident-Managements im User-Help-Desk-Konzept definiert sind, da diese ausschließlich für Produktiv-Systeme gelten. Priorität 1: Die Weiterführung des Tests ist nicht möglich oder sinnlos, der aufgetretene Fehler führt zum Abbruch des Tests. Priorität 2: Die Fortführung des Tests ist möglich und sinnvoll (z.B. um möglichst viele Fehler im ersten Durchlauf zu entdecken), das System kann aber nicht in die Produktion übergeben werden. Priorität 3: Der Fehler macht die Produktion zwar nicht unmöglich, deutlich spürbare Beeinträchtigungen des Betriebes sind aber zu erwarten. Priorität 4: Es sind nur leichtere Beeinträchtigungen des Produktionsbetriebs zu erwarten.

9.2 Vorgehensweise nach Priorität der Fehler

9.2.1 Priorität 1

Der Test wird abgebrochen. Der Verantwortliche wird informiert. Die Testunterlagen (Testfallbeschreibung und Ergebnisdokumentation) wird der durchführenden Stelle, deren Arbeitsqualität durch den Test abzusichern war, übergeben. Der Verantwortliche setzt Nachbesserungstermine in Abstimmung mit der durchführenden Stelle und controlled diese Termine. Der Verantwortliche entscheidet über eine Information an den Auftraggeber.

Seite 30 /37

Testkonzept

9.2.2 Priorität 2

Der Test wird weiter durchgeführt. Der Verantwortliche wird informiert. Die Testunterlagen (Testfallbeschreibung und Ergebnisdokumentation) wird der durchführenden Stelle, deren Arbeitsqualität durch den Test abzusichern war, übergeben. Der Verantwortliche setzt Nachbesserungstermine in Abstimmung mit der durchführenden Stelle und controlled diese Termine. Der Verantwortliche entscheidet über eine Information an den Auftraggeber.

9.2.3 Priorität 3

Der Test wird weiter durchgeführt. Der Verantwortliche wird informiert. Die Testunterlagen (Testfallbeschreibung und Ergebnisdokumentation) wird der durchführenden Stelle, deren Arbeitsqualität durch den Test abzusichern war, übergeben. Der Verantwortliche setzt Nachbesserungstermine in Abstimmung mit der durchführenden Stelle und controlled diese Termine. Nach Beendigung des Testlaufes entscheidet der Verantwortliche gemeinsam mit dem Auftraggeber darüber, ob das System trotz der Beeinträchtigung in den produktiven Betrieb übergehen kann. Lehnt der Auftraggeber ab, ist der Fehler wie Priorität 2 zu behandeln.

9.2.4 Priorität 4

Der Test wird weiter durchgeführt. Der Verantwortliche wird informiert. Der Fehler wird in die Liste der offenen Punkte übernommen, die Testunterlagen (Testfallbeschreibung und Ergebnisdokumentation) werden als Anlage beigefügt. Die Reihenfolge der Abarbeitung der offenen Punkte wird vom Verantwortlichen in Abstimmung mit der durchführenden Stelle und dem Auftraggeber bestimmt.

Seite 31 /37

Testkonzept

9.3 Anlage: Zusammenstellung der Testaktivitäten A1 Hardware

A1.1 PC mit Betriebssystem

Testobjekt: Nummer Kriterium Gerätepass vorhanden? Identität (z.B. MACAdresse) gleich (Gerät / Pass)? Testobjekt: Nr. Aktivität Der PC wird eingeschaltet PC Existenz Ergebnis Ja / nein Ja / Nein

Aktivierung Erwartetes Ergebnis (Soll) Ist Der PC fährt hoch und es erscheint das vom IQSH definierte Startmenü Anmeldung als Administrator Passwort-Abfrage und anschließend Arbeit im Admin.-Status möglich Überprüfen der Parameter Die Parameter des Betriebssystems entsprechen den Vorgaben des IQSH Lokale Anmeldung (Schüler) Keine Administratorrechte Schnittstellen Erwartetes Ergebnis (Soll) Ist Netzanschluss vorhanden Alle Geräte sind gemäß dem Konfigurationsplan für diesen PC angeschlossen. Das gilt auch für die Tastatur und die Maus, die bereits in 1.2 genutzt wurden

Testobjekt: Nr. Aktivität Netzanschluss Weitere Geräte wie Drucker, Brenner oder Beamer. Hier ist entweder eine Unterteilung oder der Konfi.-Plan als Anlage erforderlich

Seite 32 /37

Testkonzept

A1.2 Drucker

Testobjekt: Drucker Existenz Nummer Kriterium Ergebnis Gerätepass vorhanden? Ja / nein Gerätetypischer Treiber auf Ja / Nein dem zugehörigen PC vorhanden und zugeordnet?

Testobjekt: Nr. Aktivität Der Drucker wird eingeschaltet Kontrolle der ,,Hilfsmittel"

Aktivierung Erwartetes Ergebnis (Soll) Ist Der Drucker ist in betriebsbereitem Zustand Die ,,Hilfsmittel", hier Papier und Tinte oder Toner sind vorhanden. Sollte das nicht der Fall sein, wird nachgebessert (kein Fehler, da Verbrauchsmaterial) Schnittstellen Erwartetes Ergebnis (Soll) Die Seite wird ausgedruckt, alle Zeichen einer Zeile und alle Zeilen auf der Seite sind sichtbar. Es wird kein Folgeblatt erzeugt, auch nicht ohne Bedruckung

Testobjekt: Nr. Aktivität Erzeugung und Ausdruck eines Dokumentes mit Maximalumfang an Daten auf einer Seite

Ist

A2

Standardsoftware

A2.1 Word

Testobjekt: Word Existenz Nummer Kriterium Ergebnis Installation auf Laufwerk C: Ja / Nein ordnungsgemäß? Ggf. Nachweis durch Installationsprotokoll Ggf.: Lizenz vorhanden? Ja / Nein Ggf. Lizenzkey in den Installationsunterlagen Ggf. Passwortschutz einge- Ja / Nein richtet? Ggf. Nachweis durch BerechtigungsProfil

Seite 33 /37

Testkonzept

Testobjekt: Nr. Aktivität Aufruf von Word

Erfassen eines (vorgegebenen) Dokuments und Speicherung unter vorgegebenem Namen Testobjekt: Erfassen eines Dokuments, Speichern unter ,,Testxy", beenden von Word Starten Word Öffnen Dokument ,,Testxy" Drucken Beenden der Anwendung Word

Aktivierung Erwartetes Ergebnis (Soll) Die Software wird geladen und meldet sich mit der ersten Eingabeaufforderung, Beginn der Bearbeitung Das erfasste Dokument ist am Bildschirm sichtbar, nach der Speicherung ändert sich sichtbar der Name Schnittstellen Word wird beendet, das ursprüngliche Auswahlmenü erscheint Wie oben Das Dokument wird vollständig angezeigt Das Dokument wird vollständig auf dem Drucker ausgegeben Word wird beendet, das ursprüngliche Auswahlmenü erscheint

Ist

A2.2 EXCEL

Testobjekt: EXCEL Existenz Nummer Kriterium Ergebnis Installation auf Laufwerk C: Ja / Nein ordnungsgemäß? Ggf. Nachweis durch Installationsprotokoll Ggf.: Lizenz vorhanden? Ja / Nein Ggf. Lizenzkey in den Installationsunterlagen Ggf. Passwortschutz einge- Ja / Nein richtet? Ggf. Nachweis durch BerechtigungsProfil Testobjekt: Nr. Aktivität Aufruf von Excel Aktivierung Erwartetes Ergebnis (Soll) Ist Die Software wird geladen und meldet sich mit der ersten Eingabeaufforderung, Beginn der Bearbeitung Die erfasste Tabelle ist auf dem Bildschirm sichtbar, die Rechenergebnisse (Formel) sind richtig.

Seite 34 /37

Erzeugen einer vorgegebenen Tabelle mit einer einfachen Formel

Testkonzept

Testobjekt: Nr. Aktivität Erfassen einer Tabelle wie oben, Speichern unter ,,Testyz", beenden von EXCEL Starten EXCEL Öffnen Dokument ,,Testyz" Drucken Beenden der Anwendung EXCEL

Schnittstellen Erwartetes Ergebnis (Soll) Ist Durch die Speicherung ändert sich der Name. EXCEL wird beendet, das ursprüngliche Auswahlmenü erscheint Wie oben Die Tabelle wird vollständig angezeigt Die Tabelle wird vollständig auf dem Drucker ausgegeben EXCEL wird beendet, das ursprüngliche Auswahlmenü erscheint

A3

Kundenwarenkorb

Rückmeldung vom IQSH.

A4

Netz

Netz ­ Peer-to-Peer Erwartetes Ergebnis (Soll) Ist Die Ressourcen können von anderen PC´s genutzt werden (z.B. eine Datei). Bezug zu folgender Aktivität Bezug: vorangehende Aktivität Nur über das Netz erreichbare periphere Geräte können genutzt werden, z.B. Erzeugen eines Ausdrucks auf einem Netzdrucker Durchführung der ersten beiden Aktivitäten auf allen Schüler-PC´s bringt positive Ergebnisse (Dateien werden angezeigt) Netz ­ Serverbasiert Erwartetes Ergebnis (Soll) Ist An den Arbeitsplätzen ist eine ,,lokale" Anmeldung erforderlich, das Netz ist betreibbar, die Aktivitäten zum Peer-to-Peer-Netz können durchgeführt werden

Testobjekt: Nr. Aktivität Freigabe von Ressourcen für andere PC´s Lesen von Daten eines anderen PC´s Nutzen von Netzressourcen

Lehrer-PC: Alle SchülerPC´s werden angesprochen

Testobjekt: Nr. Aktivität Abschalten des Servers

Seite 35 /37

Testkonzept

A5

Kommunikation zwischen Komponenten

Fernbedienung Erwartetes Ergebnis (Soll) Ist Auf dem Lehrer-PC kann die Aktivität an einem Schüler-PC beobachtet werden Auf dem Lehrer-PC kann ein Schüler-PC fernbedient werden, der Schüler sieht die Aktivitäten des Lehrers Die Aktivitäten des Lehrers können auf allen PC´s einer (Arbeits-)Gruppe verfolgt werden Ein vorher im Stand-by-Modus befindlicher Schüler-PC wird hochgefahren Der Schüler-PC bzw. alle PC´s der Gruppe werden ausgeschaltet, d.h. gehen in den Stand-by-Modus Softwareverteilung Erwartetes Ergebnis (Soll) Ist Die für den PC vorgesehene, neue oder geänderte Software wird auf das Laufwerk C: geladen, die Verteilung wird in der Zuordnungstabelle vermerkt Ein neu geladenes Programm wird geladen und läßt sich erwartungsgemäß bedienen

Testobjekt: Nr. Aktivität Lehrer-PC: Beobachten eines Schüler-PC Fernbedienung

Lehrer-PC: Demonstration

Lehrer-PC: Einschalten eines Schüler-PC Lehrer-PC: Ausschalten eines Schüler-PC´s und einer Gruppe Testobjekt: Nr. Aktivität Start der MSI-Engine auf einem PC

Start der neuen SW

A6

Kommunikation nach außen

A6.1 Internet

Testobjekt: Nr. Aktivität Aufruf einer vorgegebenen Internetseite Internet Erwartetes Ergebnis (Soll) Die aufgerufene Internetseite wird vollständig angezeigt.

Ist

Seite 36 /37

Testkonzept

A6.2 Dienstleister

Testobjekt: Nr. Aktivität Dienstleister: Herstellen der Verbindung Dienstleistung Erwartetes Ergebnis (Soll) Ist Der Dienstleister sieht nach Herstellen der Verbindung das Bild des ausgewählten Schul-PC´s (Lehrkraft oder Schüler) Auf dem Arbeitsplatz-PC des Dienstleisters ist das Startmenü sichtbar, das auf dem Schul-PC ebenfalls gesehen wird. Die Bedienungsfolge kann am Schul-PC mit verfolgt werden. Das Übertragungsprotokoll ist fehlerfrei. Das Paket (inklusive Zuordnungstabelle) kann auf dem DepotServer des Schulnetzes gefunden und eingesehen werden.

Dienstleister: Aufruf eines Programmes

Dienstleister: Absenden eines MSI-Paketes

Seite 37 /37

Information

Microsoft Word - Testkonzept v1-1.doc

37 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

805890