DE102006047979A1

DE102006047979A1 - Datenverarbeitungssystem und Verfahren zum Ausführen einer Testroutine in Verbindung mit einem Betriebssystem

Info

Publication number: DE102006047979A1
Application number: DE102006047979A
Authority: DE
Inventors: Reinhard Dipl.-Ing. Lekel
Original assignee: Oce Printing Systems GmbH and Co KG
Current assignee: Canon Production Printing Germany GmbH and Co KG
Priority date: 2006-10-10
Filing date: 2006-10-10
Publication date: 2008-04-17
Anticipated expiration: 2026-10-11
Also published as: DE102006047979B4; US8146060B2; US20080086720A1

Abstract

Die Erfindung betrifft ein Datenverarbeitungssystem und ein Verfahren zum Ausführen einer Testroutine in Verbindung mit einem Testbetriebssystem. Es werden Programmdaten zum Bereitstellen eines Verwaltungsbetriebssystems abgearbeitet. Mit Hilfe einer Liste mit nacheinander automatisch bereitzustellenden Testbetriebssystemen und/oder nacheinander automatisch bereitzustellenden Testbetriebssystemkonfigurationen wird ein durch einen Listeneintrag spezifiziertes Testbetriebssystem und/oder eine spezifizierte Testbetriebskonfiguration unter dem bereitgestellten Verwaltungsbetriebssystem ermittelt, während dessen das Verwaltungsbetriebssystem bereitgestellt wird. Es werden Programmdaten zum Bereitstellen des ermittelten Testbetriebssystems oder der ermittelten Testbetriebssystemkonfiguration abgearbeitet. Es wird mindestens eine Testroutine ausgeführt, die unter dem bereitgestellten Testbetriebssystem automatisch ausgeführt wird.

Description

Die Erfindung betrifft ein Datenverarbeitungssystem sowie ein Verfahren zum Ausführen einer Testroutine in Verbindung mit einem Betriebssystem. Die Programmdaten zum Bereitstellen des Betriebssystems werden abgearbeitet und die Testroutine wird ausgeführt. Dadurch kann insbesondere überprüft werden, ob ein Anwendungsprogramm fehlerfrei mit dem Betriebssystem zusammenarbeitet.
Moderne Betriebssysteme, wie z.B. das Betriebssystem Microsoft Windows XP sowie verschiedene Linuxdistributionen, z.B. die von der Firma Novell herausgegebene Linuxdistribution SUSE, haben eine integrierte Funktion zum Aktualisieren des jeweiligen Betriebssystems sowie von mit dem Betriebssystem ausgelieferten Anwendungsprogrammen. Beispiele für solche Anwendungsprogramme sind Webbrowser, Dateiverwaltungsprogramme und Systemprogramme. Je nach Konfiguration des Betriebssystems umfasst dies auch Netzwerkverwaltungsprogramme, Video- und Audioaufnahme- und Abspielprogramme, Programme zum Speichern von Daten auf Datenträgern usw. Eine Aktualisierung des erwähnten Betriebssystems Microsoft Windows XP ist beispielsweise über die Internetseite http://update.microsoft.com/windowsupdate möglich. Über diese Internetseite, die über ein Browserprogramm aufrufbar ist, können wichtige Updates abgerufen werden. Moderne Betriebssysteme, wie Microsoft Windows XP, haben bei einer entsprechenden Voreinstellung zusätzlich noch die Möglichkeit, automatisch Aktualisierungen des Betriebssystems zu installieren. Bei einer Aktivierung dieser automatischen Aktualisierungsfunktion besteht jedoch die Gefahr, dass Anwendungsprogramme nach einer Aktualisierung des Betriebssystems nicht mehr oder nicht mehr fehlerfrei funktionieren. Aus diesem Grund geben verschiedene Hersteller die von Ihnen vertriebenen Anwendungsprogramme nur für bestimmte Betriebssystemaktualisierungen bzw. Betriebssystemsversionsstände frei. Insbesondere beim Einsatz von Datenverarbeitungsanlagen in einem Produktionsprozess ist eine fehlerfreie Funktion der unter einem Betriebssystem auszuführenden Anwendungsprogramme für einen reibungslosen Produktionsablauf unabdingbar. Beispiele für solche Produktionsabläufe sind beispielsweise die Verwaltung von Druckaufträgen in einem Druckzentrum sowie das Steuern von Druck- und Verarbeitungsprozessen einer Druckstraße.
Aus dem Dokument EP 0093242 A ist ferner bekannt, verschiedene Tests zur Kontrolle von Maschinenfunktionen einer elektrofotografischen Kopiermaschine durchzuführen.
Aufgabe der Erfindung ist es, ein Datenverarbeitungssystem und ein Verfahren anzugeben, durch die auf einfache Art und Weise überprüft werden kann, ob ein Anwendungsprogramm unter einem bestimmten Betriebssystem oder einer Betriebssystemkonfiguration fehlerfrei ausgeführt werden kann. Diese Aufgabe wird durch ein Datenverarbeitungssystem mit den Merkmalen des Patentanspruchs 1 sowie durch ein Verfahren zum Ausführen einer Testroutine in Verbindung mit einem Testbetriebssystem mit den Merkmalen des Patentanspruchs 17 gelöst. Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Durch das Datenverarbeitungssystem mit den Merkmalen des Patentanspruchs 1 ist es möglich, in einer Liste angeführte Testbetriebssysteme oder Testbetriebssystemkonfigurationen nacheinander automatisch bereitzustellen, wobei mindestens eine Testroutine unter dem bereitgestellten Testbetriebssystem automatisch ausführbar ist. Dadurch können Funktionsfehler beim Zusammenspiel zwischen dem Testbetriebssystem und einem Anwendungsprogramm bzw. einer Anwendungssoftware sowie von mit dem Datenverarbeitungssystem verbundenen Peripheriegeräten ermittelt werden. Mit geeigneten Testfunktionen kann somit die fehlerfreie Funktionsfähigkeit einer Anwendungssoftware in Verbindung mit einem Testbetriebssystem auf einfache Art und Weise ermittelt werden. Besondere Vorteile bietet die Erfindung, wenn nacheinander automatisch mehrere verschiedene Testbetriebssysteme und/oder Testbetriebssystemkonfigurationen mit jeweils einem Anwendungsprogramm, vorzugsweise demselben Anwendungsprogramm oder mit jeweils mehreren verschiedenen Anwendungsprogrammen, bereitgestellt werden, wobei jeweils eine, vorzugsweise dieselbe, Testroutine ausgeführt wird.
Die Testroutine kann beispielsweise als Anwendungsprogramm ein Programm aufrufen, durch das das Datenverarbeitungssystem eine Druckserverfunktion bereitstellt. Ferner kann die Testroutine Druckdaten zu einem Druckdatenstrom verarbeiten und zu einem mit dem Datenverarbeitungssystem verbundenen Testsystem übertragen. Das Testsystem erzeugt mit Hilfe der übertragenen Druckdaten mindestens ein Rasterbild und vergleicht dieses vorzugsweise mit einem gespeicherten Rasterbild. Dabei kann das Vergleichsergebnis zur Testroutine übertragen werden, die dadurch Informationen über das Vergleichsergebnis bzw. über einen erfolgreichen Test erhält.
Bei einer Weiterbildung der Erfindung kann mindestens ein Testbetriebssystem in einer ersten und in mindestens einer zweiten Konfiguration nacheinander durch das Verwaltungsbe triebssystem gesteuert und bereitgestellt werden. Die Konfiguration wird dabei vorzugsweise mit Hilfe mindestens eines Konfigurationsparameters festgelegt. Beispielsweise kann ein Datenverarbeitungssystem als 32-Bit und als 64-Bit Datenverarbeitungssystem konfiguriert werden, sowie für den Einprozessorbetrieb oder für einen Zweiprozessorbetrieb. Ferner sind weitere Konfigurationsmöglichkeiten mit aktivierten und deaktivierten Hardwarekomponenten des Datenverarbeitungssystems als Konfiguration voreinstellbar. Weiterhin können mindestens zwei Testbetriebssysteme vorgesehen sein, die durch das Verwaltungsbetriebssystem gesteuert entsprechend ihren Listeneinträgen in der Liste nacheinander bereitgestellt werden. Somit kann die Liste sowohl Listeneinträge zum Bereitstellen verschiedener Testbetriebssysteme als auch verschiedener Konfigurationen eines Testbetriebssystems enthalten.
Ferner ist es vorteilhaft, wenn das Verwaltungsbetriebssystem die Testergebnisse der mindestens einen Testroutine und/oder des Vergleichs als verarbeitbare Information ermittelt und gegebenenfalls in aufbereiteter Form ausgibt. Die ausgegebenen Informationen werden vorzugsweise in einer Datei gespeichert, als Nachricht an einen Empfänger übertragen und/oder mit Hilfe einer Ausgabeeinheit ausgegeben. Die Nachricht ist insbesondere eine Email-Nachricht oder eine SMS-Nachricht. Ferner ist es möglich, nur dann Testergebnisse auszugeben, wenn ein Fehler aufgetreten ist. Dadurch ist eine einfache Information einer Bedienperson über die Testergebnisse der durchgeführten Testroutine, insbesondere nur bei einem negativem Testergebnis, auf einfache Art und Weise möglich.
Bei einer vorteilhaften Weiterbildung der Erfindung wird das Testbetriebssystem nach dem Ausführen der Testroutine automatisch beendet. Das Verwaltungsbetriebssystem überprüft anschließend automatisch, ob ein weiteres Testbetriebssystem und/oder ob eine weitere Testbetriebssystemkonfiguration zu starten ist. Dadurch kann ein vorteilhafter automatischer Ablauf von Tests mit mehreren Testbetriebssystemen sowie mit verschiedenen Testbetriebssystemkonfigurationen durchgeführt werden, ohne dass dazu Benutzereingriffe erforderlich sind.
Ferner ist es vorteilhaft, wenn unter dem Verwaltungsbetriebssystem überprüft wird, ob ein in der Liste enthaltenes Testbetriebssystem und/oder eine in der Liste enthaltene Testbetriebssystemkonfiguration noch nicht bereitgestellt worden ist. Wird ein solches Testbetriebssystem oder eine solche Testbetriebssystemkonfiguration ermittelt, so wird das Datenverarbeitungssystem unter dem Verwaltungsbetriebssystem so konfiguriert, dass nach einem automatischen Neustart des Datenverarbeitungssystems ein noch nicht bereitgestelltes Testbetriebssystem oder eine noch nicht bereitgestellte Testbetriebssystemkonfiguration automatisch gestartet wird. Dabei kann das Testbetriebssystem selbst oder ein unter dem Testbetriebssystem ausgeführtes Anwendungsprogramm das Datenverarbeitungssystem konfigurieren. Durch das Konfigurieren des Datenverarbeitungssystems kann der automatische Ablauf von Tests mehrerer Testbetriebssysteme und/oder Testbetriebssystemkonfigurationen nacheinander entsprechend den Listeneinträgen einfach durchgeführt werden.
Ferner ist es möglich, dass ein Neustart des Datenverarbeitungssystems initiiert wird, währenddessen das Verwaltungs betriebssystem bereitgestellt bzw. ausgeführt wird. Der Neustart wird vorzugsweise erst dann initiiert, nachdem das Datenverarbeitungssystem derart neu konfiguriert worden ist, dass es nach dem Neustart des Datenverarbeitungssystems ein in der Liste spezifiziertes Testbetriebssystem oder eine in der Liste spezifizierte Testbetriebssystemkonfiguration bereitstellt. Weiterhin ist es vorteilhaft, einen Neustart des Datenverarbeitungssystems während des Ausführens eines Testbetriebssystems und/oder einer Testbetriebssystemkonfiguration erst dann zu initiieren, nachdem die Testroutine beendet oder abgebrochen worden ist. Das Testbetriebssystem oder ein unter dem Testbetriebssystem ausgeführtes Anwendungsprogramm speichert Informationen über mindestens einen durchgeführten Test vorzugsweise in einer Datei, auf die auch das Verwaltungsbetriebssystem Zugriff hat, wenn dieses nachfolgend ausgeführt wird. Das Testbetriebssystem konfiguriert dabei das Datenverarbeitungssystem so, dass nach einem durch das Testbetriebssystem initiierten Neustart das Verwaltungsbetriebssystem bereitgestellt wird. Dadurch kann auf einfache Art und Weise abwechselnd das Verwaltungsbetriebssystem und ein Testbetriebssystem bzw. eine Testbetriebssystemkonfiguration bereitgestellt werden.
Das Testbetriebssystem und/oder die Testbetriebssystemkonfiguration sind vorzugsweise so konfiguriert, dass eine Aktualisierung des jeweiligen Testbetriebssystems automatisch nach ihrem Start durchgeführt wird, wenn Aktualisierungsdaten zum Aktualisieren der Programmdaten des Testbetriebssystems verfügbar sind. Die Testroutine wird vorzugsweise nur dann automatisch gestartet, wenn die Programmdaten des Testbetriebssystems aktualisiert oder Programmdaten eines unter dem Testbetriebssystem abzuarbeitenden Anwendungspro gramms geändert worden sind, auf dessen Funktionen die Testroutine zugreift. Dadurch kann auf einfache Art und Weise getestet werden, ob Programmelemente, insbesondere Anwendungsprogramme, auch nach einer durchgeführten Aktualisierung des Testbetriebssystems fehlerfrei funktionieren. Dies ist insbesondere dann erforderlich, wenn ein Anwendungsprogramm für eine aktualisierte Version eines Betriebssystems freigegeben werden soll. Das Verwaltungsbetriebssystem sichert die Programmdaten des aktualisierten Testbetriebssystems vorzugsweise nachdem das Testbetriebssystem beendet worden ist. Dadurch steht die aktualisierte Version des Testbetriebssystems für weitere Tests zur Verfügung. Insbesondere kann das aktualisierte Testbetriebssystem zu einem späteren Zeitpunkt mit weiteren Aktualisierungsdaten aktualisiert werden, wobei die Testroutine dann wiederholt abzuarbeiten ist. Insbesondere kann täglich überprüft werden, ob für ein Testbetriebssystem und/oder eine Testbetriebssystemkonfiguration Aktualisierungsdaten vorliegen. Dann kann sichergestellt werden, dass immer die aktuellste Version eines Testbetriebssystems bereitgestellt wird, so dass die Testroutine dann unter der aktuellsten Version des Testbetriebssystems ausgeführt wird. Dies ermöglicht, dass eine Fehlfunktion von Anwendungsprogrammen und Programmelementen aufgrund einer Aktualisierung des Betriebssystems schnell bemerkt wird. Wird eine Fehlfunktion festgestellt, so wird eine Aktualisierung des Betriebssystems von Datenverarbeitungssystemen beim Kunden vorzugsweise verhindert. Dies kann beispielsweise dadurch erfolgen, dass das Datenverarbeitungssystem des Kunden so konfiguriert ist, dass auch Aktualisierungsdaten des Betriebssystems nur auf einem Server des Herstellers der Anwendungssoftware gesucht werden. Bei einer festgestellten Fehlfunktion werden diese Aktualisierungsdaten dann nicht auf die sem Server bereitgestellt. Die Aktualisierungsdaten zum automatischen Aktualisieren des Betriebssystems eines Datenverarbeitungssystems beim Kunden werden erst bereitgestellt, wenn aktualisierte Versionen eines Anwendungsprogramms und/oder eines Programmelements bereitgestellt werden können, die unter der aktualisierten Version des Betriebssystems fehlerfrei ausgeführt werden können.
Das Testbetriebssystem konfiguriert das Datenverarbeitungssystem nach dem Ausführen der Testroutine, nach einem erfolglosen Aufruf der Testroutine oder nach einem Abbruch der Testroutine so, dass bei einem Neustart des Datenverarbeitungssystems das Verwaltungsbetriebssystem wieder bereitgestellt wird. Dadurch kann das Verwaltungsbetriebssystem nachfolgend die Testergebnisse der unter dem Testbetriebssystem ausgeführten Testroutine weiter verarbeiten sowie überprüfen, ob ein weiteres Testbetriebssystem oder eine weitere Testbetriebssystemkonfiguration nachfolgend bereitgestellt werden soll.
Zur Verwaltung der in der Liste spezifizierten Testbetriebssysteme und Testbetriebkonfigurationen kann das Datenverarbeitungssystem den Listeneintrag eines bereitzustellenden Testbetriebssystems, eines bereitgestellten Testbetriebssystems, einer bereitzustellenden Testbetriebssystemkonfiguration oder einer bereitgestellten Testbetriebssystemkonfiguration in der Liste als abgearbeitet markieren oder aus der Liste entfernen. Dies kann insbesondere unter dem aktuell bereitgestellten Betriebssystem ausgeführt werden. Dadurch ist eine einfache Verwaltung der abzuarbeitenden und abgearbeiteten Testbetriebssysteme und/oder Testbetriebssystemkonfigurationen möglich.
Die Konfiguration des Datenverarbeitungssystems zum Ausführen eines Testbetriebssystems oder des Verwaltungsbetriebssystems nach dem Neustart wird vorzugsweise mit Hilfe eines Boot-Managers festgelegt. Dadurch ist eine einfache Konfiguration zur Auswahl des nach dem Neustart auszuführenden Betriebssystems möglich. Dabei kann insbesondere die Konfigurations-Datei des Boot-Managers geändert und/oder ausgetauscht werden.
Ferner ist es vorteilhaft, wenn das Verwaltungsbetriebssystem oder ein unter dem Verwaltungsbetriebssystem ausgeführtes Anwendungsprogramm bzw. Anwendungsprogrammelement das Abarbeiten der Liste zu einer voreingestellten Zeit startet. Dadurch ist zum Start der durchzuführenden Tests kein Eingriff durch eine Bedienperson erforderlich. Die Tests können dadurch in Zeiträume verlagert werden, in denen das Datenverarbeitungssystem nicht oder nur wenig anderweitig genutzt wird.
Ferner ist es vorteilhaft, wenn das Datenverarbeitungssystem mindestens drei Speicherbereiche aufweist. Diese Speicherbereiche sind vorzugsweise Partitionen. Im ersten Speicherbereich sind vorzugsweise zumindest Programmdaten und/oder Anwendungsdaten zum Bereitstellen eines zum Testen erforderlichen Betriebssystems (Testbetriebssystems) enthalten. Ferner können im ersten Speicherbereich die Programmdaten mindestens eines Anwendungsprogramms gespeichert sein, dessen Funktionen unter dem Testbetriebssystem mit Hilfe der Testroutine zu testen sind. Im zweiten Speicherbereich sind zumindest Programmdaten und/oder Anwendungsdaten zum Bereitstellen des Verwaltungsbetriebssystems gespeichert. Im dritten Speicherbereich sind vorzugsweise zumindest Programmdaten und/oder Anwendungsdaten zum Bereit stellen mindestes eines Testbetriebssystems gespeichert, mit denen die im ersten Speicherbereich zum Bereitstellen des Testbetriebssystems erforderlichen Programmdaten und/oder Anwendungsdaten erzeugt werden können. Mit Hilfe der im dritten Speicherbereich gespeicherten Daten können insbesondere die zum Bereitstellen des Testbetriebssystems im ersten Speicherbereich erforderlichen Programmdaten und/oder Anwendungsdaten erzeugt werden. Diese Daten sind im dritten Speicherbereich vorzugsweise als Abbild bzw. als Image gespeichert. Für unterschiedliche Testbetriebssysteme wird vorzugsweise jeweils ein Image erzeugt. Weiterhin kann je ein Abbild für eine Kombination des Testbetriebssystems und einer in Verbindung mit diesem Testbetriebssystem zu testenden Anwendungssoftware im dritten Speicherbereich gespeichert sein, wodurch mit Hilfe dieser Abbilddaten im ersten Speicherbereich Programmdaten und/oder Anwendungsdaten als Testbetriebssystem und des Anwendungsprogramms in ausführbarer Form erzeugbar sind. Die Anwendungssoftware kann dabei ein oder mehrere Programmelemente und/oder Anwendungsprogramme umfassen. Ein Image ist dabei ein Abbild eines Speicherbereichs, mit dem sich die Daten des Speicherbereichs wiederherstellen lassen, wenn dies gewünscht und/oder erforderlich ist.
Ein Verfahren zum Ausführen einer Testroutine in Verbindung mit einem Testbetriebssystem ermöglicht einen einfachen automatisierten Testablauf. Ein solches Verfahren kann auf die gleiche Art und Weise weitergebildet werden, wie das Datenverarbeitungssystem nach Anspruch 1. Insbesondere können einzelne Merkmale oder Merkmalskombinationen der vom Patentanspruch 1 abhängigen Patentansprüchen zur Weiterbildung des Verfahrens zum Ausführen einer Testroutine in Ver bindung mit einem Testbetriebssystem genutzt werden, wobei gleiche Vorteile erreicht werden.
Die Testbetriebssysteme und das Verwaltungsbetriebssystem sind übliche bei Datenverarbeitungssystemen verwendete Betriebssysteme. Solche Betriebssysteme sind die Software, die die Verwendung und den Betrieb eines Datenverarbeitungssystems, insbesondere das Abarbeiten von Anwendungssoftware, ermöglicht. Sie verwalten Betriebsmittel, wie Speicher, Ein- und Ausgabegeräte, und steuern die Ausführung von Programmen. Die Betriebssysteme umfassen üblicherweise einen Kern (englisch: kernel), der die Hardware des Datenverarbeitungssystems verwaltet. Ferner umfassen die Betriebssysteme grundlegende Systemprogramme, die Funktionen zum Betrieb des Datenverarbeitungssystems bereitstellen. Aktuelle in Verbindung mit Computern eingesetzte Betriebssysteme sind Windows XP, Windows 2000, Windows Server 2003 der Firma Microsoft Corporation, das Betriebssystem Mac-OS der Firma Apple Corporation, das Betriebssystem Unix sowie das Betriebssystem Linux, beispielsweise in der Distribution SUSE Linux Enterprise Server 9, SUSE Linux Enterprise Server 10 oder SUSE Linux Professional 10 der Firma Novell.
Zum besseren Verständnis der vorliegenden Erfindung wird im Folgenden auf die in den Zeichnungen dargestellten bevorzugten Ausführungsbeispiele Bezug genommen, die anhand spezifischer Terminologie beschrieben sind. Es sei jedoch darauf hingewiesen, dass der Schutzumfang der Erfindung dadurch nicht eingeschränkt werden soll, da derartige Veränderungen und weitere Modifizierungen an den gezeigten Vorrichtungen und/oder den beschriebenen Verfahren sowie derartige weitere Anwendungen der Erfindung, wie sie darin aufgezeigt sind, als übliches derzeitiges oder künftiges Fachwissen eines zuständigen Fachmanns angesehen werden.
Die Figuren zeigen Ausführungsbeispiele der Erfindung, nämlich:
1 ein Blockschaltbild eines Gesamtsystems zum Testen der Druckserverfunktion eines Datenverarbeitungssystems in Verbindung mit einem Drucksimulationssystem;
2 ein Blockschaltbild des Datenverarbeitungssystems nach 1 mit Elementen zum Durchführen der erforderlichen Tests;
3 eine Liste mit nacheinander auszuführenden Testbetriebssystemen und nacheinander auszuführenden Testbetriebssystemkonfigurationen; und
4 einen Ablaufplan zum Ausführen einer Testroutine in Verbindung mit einer Liste mit mehreren Testbetriebssystemen und Testbetriebssystemkonfigurationen.
In 1 ist das Blockschaltbild eines Gesamtsystems 10 zum Test von Druckserverfunktionen eines Datenverarbeitungssystems 12 in Verbindung mit einem Drucksimulationssystem 14 dargestellt. Das Datenverarbeitungssystem 12 ist so konfiguriert, dass alternativ das Verwaltungsbetriebssytem 16 und ein Testbetriebssystem 18 ausgeführt werden kann. Das Verwaltungsbetriebssystem 16 ist im vorliegenden Ausführungsbeispiel SUSE Linux Enterprise Server Version 9. In einem Speicherbereich 20 des Datenverarbeitungssystems 12 sind die Abbilder 22 mehrerer Testbetriebssysteme ge speichert. Ferner sind im Speicherbereich 20 Grundeinstellungen 24 eines Boot-Laders gespeichert. Im vorliegenden Ausführungsbeispiel wird der Grub-Boot-Lader des Betriebssystems SUSE Linux Enterprise Server 9 eingesetzt.
Ferner sind im Speicherbereich 20 verschiedene Initialisierungs-Skripte 26 gespeichert, von denen zumindest ein Teil mit Hilfe einer zeitlichen Ablaufsteuerung ausgeführt wird. Eine zeitliche Ablaufsteuerung ist bei dem Betriebssystem SUSE Linux Enterprise Server 9 mit Hilfe des CRON-Dienstes einfach möglich. In eine Liste werden dann die Zeitpunkte eingetragen, zu denen ein Skript oder ein Programm vom CRON-Dienst aufgerufen werden soll. Diese Liste ist bei dem Betriebssystem SUSE Linux Enterprise Server 9 in den Dateien CRON.TAB bzw. in den Dateien CRON.HOURLY; CRON.DAILY; CRON.WEEKLY; oder CRON.MONTHLY gespeichert.
Weiterhin ist im Speicherbereich 20 eine Testablaufliste 28 gespeichert, die nacheinander auszuführende Testbetriebssysteme 18 sowie die nacheinander auszuführenden Konfigurationen dieser Testbetriebssysteme und die ggf. unter diesen Testbetriebssystemen/Testsystemkonfigurationen auszuführende, für die durchzuführenden Tests erforderliche Anwendungssoftware enthält. Während das Verwaltungsbetriebssystem 16 aktiviert ist, wird mit Hilfe der Skripte 26 und des CRON-Dienstes das Datenverarbeitungssystem 12 so konfiguriert, dass nach mindestens einem Neustart des Datenverarbeitungssystems 12 jeweils das nächste in der Testablaufliste 28 angeführte Testbetriebssystem 18 der dort spezifizierten Konfiguration geladen und so bereitgestellt wird. Nach dem Start des Testbetriebssystems 18 wird jeweils eine Testroutine gestartet.
Die Testroutine startet eine Druckserver-Anwendungssoftware, die dadurch unter dem Testbetriebssystem 18 ausgeführt wird, sodass das Datenverarbeitungssystem 12 eine Druckserverfunktion bereitstellt. Die Testroutine führt der Druckserver-Anwendungssoftware dann Druckdaten zu, die der Druckserver-Anwendungssoftware über eine durch die Testroutine spezifizierte Schnittstelle 30, 32, 34 zu dem Drucksimulationssystem 14 überträgt. Die Schnittstellen des Datenverarbeitungssystems 12 sind eine TCP/IP-Schnittstelle 30, eine SCSI-Schnittstelle 32 und eine/370-Schnittstelle 34, die auch als IBM-Kanal bezeichnet wird. Das Drucksimulationssystem 14 weist eine TCP/IP-Schnittstelle 36 auf, die über eine Datenleitung, vorzugsweise eine Ethernetverbindung, mit der TCP/IP-Schnittstelle 30 des Datenverarbeitungssystems 12 verbunden ist, wodurch über die TCP/IP-Schnittstellen 30, 36 Daten zwischen dem Datenverarbeitungssystem 12 und dem Drucksimulationssystem 14 übertragbar sind. Das Drucksimulationssystem 14 weist ferner eine SCSI-Schnittstelle 38 auf, die über eine Datenleitung mit der SCSI-Schnittstelle 32 des Datenverarbeitungssystems 12 verbunden ist, wodurch über diese SCSI-Schnittstellen 30, 38 Daten zwischen dem Datenverarbeitungssystem 12 und dem Drucksimulationssystem 14 übertragbar sind. Weiterhin weist das Drucksimulationssystem 14 eine/370-Schnittstelle 40 auf, die über eine geeignete Datenleitung mit der/370-Schnittstelle 34 des Datenverarbeitungssystems 12 verbunden ist.
Das Drucksimulationssystem 14 ist eine Datenverarbeitungseinheit, die mindestens den Funktionsumfang eines Druckcontrollers eines Hochleistungsdruckers aufweist. Der Druckcontroller erzeugt insbesondere auf der Basis der zugeführten Druckdaten Rasterbilder, mit deren Hilfe einer Bilderzeugungseinheit bildpunktweise Bildinformationen zur Verfügung gestellt werden können. Das Drucksimulationssystem 14 kann dadurch Druckdaten, die dem Drucksimulationssystem 14 vorzugsweise als Druckdatenstrom zugeführt werden, in gleicher Weise wie ein Druckcontroller eines Hochleistungsdruckers verarbeiten. Insbesondere erzeugt das Drucksimulationssystem 14 aus den zugeführten Druckdaten Rasterbilder und speichert diese vorzugsweise in einem geeigneten Dateiformat, wie dem Tagged Image File Format (TIFF/TIF). Die erzeugten Bilddaten werden mit gespeicherten Bilddaten 42 verglichen. Dieser Vergleich wird durch ein Anwendungsprogramm 44 durchgeführt. Bei Abweichungen der erzeugten Bilddaten von den gespeicherten Bilddaten wird dies durch das Anwendungsprogramm 44 festgestellt, wobei entsprechende Informationen über das Testergebnis zum Datenverarbeitungssystem 12 übertragen werden.
Wie bereits erwähnt, umfasst das Drucksimulationssystem 14 eine Datenverarbeitungsanlage, vorzugsweise einen Personalcomputer. Das Datenverarbeitungssystem des Drucksimulationssystems 14 umfasst dabei vorzugsweise Steckkarten, die in einen Baugruppenträger eingesetzt sind, wobei dieses Datenverarbeitungssystem mindestens eine Prozessorsteckkarte mit mindestens einem Hauptprozessor (CPU) hat. Falls erforderlich kann die Rechenleistung der Datenverarbeitungsanlage durch das Vorsehen mehrerer Prozessorkarten falls erforderlich einfach erhöht werden. Als Betriebssystem des Drucksimulationssystems 14 wird im vorliegenden Ausführungsbeispiel Windows NT 4 der Firma Microsoft Corporation genutzt. Unter dem Betriebssystem Windows NT 4 wird ein Anwendungsprogramm 46 gestartet, durch das eine Unix Betriebssystemumgebung unter dem Betriebssystem Windows NT 4 bereitgestellt wird. Unter dieser Unix Betriebssystemumge bung wird das Anwendungsprogramm 48 abgearbeitet, das mit einem vom Datenverarbeitungssystem 12 abgearbeiteten Anwendungsprogramm 50 eine gesicherte Datenverbindung über eine der Schnittstellen 30, 36 aufbaut, um den Testablauf im Drucksimulationssystem 14 zu steuern und die Testergebnisse vom Drucksimulationssystem 14 zum Datenverarbeitungssystem 12 zu übertragen.
Mit Hilfe der in 1 gezeigten Testanordnung kann insbesondere eine Anwendungssoftware, wie sie unter der Bezeichnung Océ PRISMAproduction vertriebene Softwarelösung für die Abwicklung komplexer Druckaufträge in Verbindung mit verschiedenen Betriebssystemen und Betriebssystemkonfigurationen umfassend getestet werden. Die Softwarelösung PRISMAproduction ermöglicht eine verbesserte Anbindung und Kompatibilität bei Drucksystemen mit hohem Druckvolumen. Dadurch wird eine maximale Produktionssicherheit für diese Drucksysteme bei hoher Prozessgeschwindigkeit sichergestellt. Die Océ PRISMAproduction-Softwarelösung kann auch für die Gesamtverwaltung und gemeinsame Steuerungsfunktion von Dokumenten-Produktionsanlagen an einem oder mehreren Standorten sowie zur zentralen Kontrolle von Druckzentren eingesetzt werden. In gleicher Weise können weitere Softwareprodukte, wie Océ Prisma Satelite, Océ Document Manager, Océ Document Designer, Océ Copy Maker, Océ Doc Setter, Océ Professional Document Composer, Océ True Proof, Océ Prisma Net, Océ Prisma Audit und Océ Doc Works sowie beliebige andere Softwareprodukte beliebiger Hersteller in Verbindung mit einem Betriebssystem und/oder einer Betriebssystemkonfiguration (Testbetriebssystem/Testbetriebssystemkonfiguration) getestet werden. Dabei kann sowohl die Funktion und der Aufruf des jeweiligen Softwareprodukts an sich, das Zusammenwirken mehrerer Softwareprodukte sowie einzelne Funktionen der Softwareprodukte getestet werden.
Zum Ausführen eines solchen Tests wird das Softwareprodukt bzw. werden die Softwareprodukte gestartet, so dass die für die Softwareprodukte erforderlichen Programme und Programmelemente abgearbeitet werden. Zum Ausführen von verschiedenen Funktionstests wird ein weiteres Anwendungsprogramm gestartet, das überprüft, ob die einzelnen Programmelemente der Softwarekomponenten korrekt gestartet worden sind. Anschließend werden verschiedene Funktionstests durch das Anwendungsprogramm initiiert und die Reaktionen der Softwareelemente erfasst, wobei überprüft wird, ob die Reaktionen auf die entsprechenden Anforderungen korrekt sind. Insbesondere wird vom Anwendungsprogramm ein Druckauftrag erzeugt, der der aktivierten PRISMAproduction-Anwendungssoftware zugeführt wird. Mit Hilfe des Druckauftrags erzeugt die PRISMAproduction-Anwendungssoftware einen Druckdatenstrom, der über eine durch das Anwendungsprogramm spezifizierte Datenverbindung über die Schnittstellen 30, 36; 32, 38; 34, 40 vom Datenverarbeitungssystem 12 zum Drucksimulationssystem 14 übertragen wird.
Bei korrekter Verarbeitung des Druckauftrags durch die PRISMAproduction-Anwendungssoftware und korrekter Datenübertragung zum Drucksimulationssystem 14 werden mit Hilfe der Druckdaten des Druckauftrags Bilddaten gerasterter Druckbilder erzeugt, die, wie bereits beschrieben, mit Hilfe der im Drucksimulationssystem 14 gespeicherten Bilddaten 42 verglichen werden.
Liegen Abweichungen zwischen den erzeugten Bilddaten und den gespeicherten Bilddaten 42 vor, so funktioniert mindes tens eine vom Datenverarbeitungssystem 12 abgearbeitete Softwarekomponente nicht korrekt. Insbesondere deuten Abweichungen der Bilddaten auf ein fehlerhaftes Softwareelement eines Anwendungsprogramms oder auf einen Fehler eines Softwareelements in Verbindung mit dem bereitgestellten Testbetriebssystem hin.
Vor dem Durchführen der Tests wird das Testbetriebssystem 18 vorzugsweise mit Hilfe von Aktualisierungsdaten aktualisiert. Die Aktualisierungsdaten werden vom Testbetriebssystem 18 vorzugsweise über ein Netzwerk von einem Server des Herstellers oder Distributors des Testbetriebssystems abgerufen. Ist bereits durch vorangegangene Test sichergestellt, dass das Testbetriebssystem 18 an sich fehlerfrei mit den Anwendungsprogrammen des Softwareprodukts zusammenarbeitet, so dass das Drucksimulationssystem 14 keine Abweichungen der erzeugten Bilddaten festgestellt hat, so wird das Anwendungsprogramm zum Testen der Softwarekomponenten nur dann ausgeführt, wenn das Testbetriebssystem 18 mit Hilfe von Aktualisierungsdaten aktualisiert worden ist. Anderenfalls wird das Testbetriebssystem ohne Funktionstest einzelner Softwareelemente beendet. Vor dem Beenden konfiguriert das Testbetriebssystem das Datenverarbeitungssystem 12 automatisch so, dass nach einem Neustart des Datenverarbeitungssystems 12 das Verwaltungsbetriebssytem 16 gestartet wird, das dadurch bereitgestellt wird.
Beim Durchführen der Funktionstests des Softwareprodukts werden die Testergebnisse in einer Datei in einem Speicherbereich des Datenverarbeitungssystems 12 gespeichert, auf die bei einem nachfolgenden Neustart auch das Verwaltungsbetriebssytem 16 Zugriff hat. Wird, wie beschrieben, kein Funktionstest durchgeführt, da insbesondere keine Aktuali sierung des Testbetriebssystems erfolgt ist oder das zu testende Softwareelement nicht gestartet werden konnte, so wird diese Information ebenfalls in einer Datei gespeichert, auf die auch das Verwaltungsbetriebssytem 16 Zugriff hat.
In 2 ist ein Blockschaltbild des Datenverarbeitungssystems 12 nach 1 mit Elementen zum Testen der Funktion mindestens einer Anwendungssoftware in Verbindung mit einem Testbetriebssystem detailliert dargestellt. Ein nichtflüchtiger Speicher des Datenverarbeitungssystems 12, insbesondere ein Festplattenspeicher, hat mindestens drei Partitionen 52, 54 und 56. In der ersten Partition 52 sind Programmdaten zum Bereitstellen des Testbetriebssystems 18 sowie Programmdaten 58 einer in Verbindung mit dem Testbetriebssystem zu testenden Anwendungssoftware gespeichert. Die erste Partition 52 enthält weiterhin eine OS-ID-Datei 60, die eine Information über die Version des bereitgestellten Testbetriebssystems 18 enthält. Das Testbetriebssystem 18 umfasst einen Boot-Manager 62, der jedoch deaktiviert ist oder alternativ das in der ersten Partition 52 gespeicherte Testbetriebssystem automatisch startet. Ferner ist in der ersten Partition 52 ein Programmelement, ein sogenanntes Init-Skript 64 gespeichert, mit dessen Hilfe das Steuerprogramm 76 und das zu testende Programmelement 58 nach dem Bereitstellen des Testbetriebssystems 18 automatisch gestartet wird.
Die zweite Partition 54 enthält Programmdaten des Verwaltungsbetriebssystems 16, eine OS-ID-Datei 66 mit Informationen über die Betriebssystemversion des Verwaltungsbetriebssystems 16, Programmdaten eines Boot-Managers 68, eine Boot-Config-Datei 70 mit Konfigurationsdaten zum Konfi gurieren des Boot-Managers 68, ein Init-Skript 72 mit nach dem Bereitstellen des Verwaltungsbetriebssystems 18 automatisch abzuarbeitenden Anweisungen sowie Programmdaten eines CRON-Dienstes 74 zum zeitgesteuerten Aufruf von Anweisungen sowie von weiteren Programmelementen.
Die dritte Partition 56 umfasst Daten mit Abbildern mehrerer Testbetriebssysteme 18 und mehrerer voneinander verschiedener Konfigurationen dieser Testbetriebssysteme 18. Ferner sind in der dritten Partition 56 Programmdaten eines Steuerprogramms 76, Programmdaten eines Test-Automat-Anwendungsprogramms 78 sowie Steuerdateien 80 und Stapelverarbeitungsdateien 82 (Batch-Dateien) gespeichert. Ferner sind in der dritten Partition 56 mehrere Dateien 81 mit verschiedenen Konfigurationsdaten zum Konfigurieren des Boot-Managers 68, d. h. mehrere sogenannte Boot Config Files, gespeichert, die vom Verwaltungsbetriebssystem 16 und dem Testbetriebssystem 18 genutzt werden, um die zur Konfiguration des Boot-Managers 68 genutzte Boot-Config-Datei 70 zu ersetzen.
Der Festplattenspeicher des Datenverarbeitungssystems 12 oder ein geeigneter anderer nichtflüchtiger Speicher umfasst ferner einen Speicherbereich, der als Master Boot Record 84 bezeichnet wird. In diesem Master Boot Record 84 ist zumindest eine Speicheradresse angegeben, die von einer Verarbeitungseinheit des Datenverarbeitungssystems 12 ausgelesen wird. Mit Hilfe der ausgelesenen Speicheradresse werden die an dieser Speicheradresse gespeicherten Programmdaten von der Datenverwaltungseinheit 12 ausgelesen und abgearbeitet. Im vorliegenden Fall sind das Programmdaten des Boot-Managers 68 des Verwaltungsbetriebssystems 16, wodurch der Boot-Manager 68 aufgerufen und ausgeführt wird.
Abhängig von den Konfigurationsdaten der Boot-config-Datei 70 führt der Boot-Manager 68 nach einem Start des Datenverarbeitungssystems 12 automatisch das in der ersten Partition 52 gespeicherte Testbetriebssystem 18 oder das in der zweiten Partition 54 gespeicherte Verwaltungsbetriebssytem 16 aus. Im Ausgangszustand wird das Verwaltungsbetriebssystem 16 ausgeführt.
Mit Hilfe des CRON-Dienstes 74 wird das Abarbeiten der in einer Stapelverarbeitungsdatei 82 enthaltenen Liste (Testablaufliste) mit nacheinander bereitzustellenden Testbetriebssystemen und Testbetriebssystemkonfigurationen gestartet. Das Verwaltungsbetriebssystem 16 überprüft, ob in dieser Liste ein bereitzustellendes Testbetriebssystem bzw. eine bereitzustellende Testbetriebssystemkonfiguration spezifiziert ist. Ist das der Fall, so ermittelt das Verwaltungsbetriebssystem 16 das zu diesem Testbetriebssystem oder zu dieser Testbetriebssystemkonfiguration in der dritten Partition 56 gespeicherte Abbild und überschreibt mit den in dem Abbild enthaltenen Programmdaten und/oder Anwendungsdaten die erste Partition 52 vollständig. Mit Hilfe dieser Abbilder können in die erste Partition 52 auf einfache Art und Weise Programmdaten von zu testenden Betriebssystemen einschließlich weiterer Anwendungsprogramme und gegebenenfalls einer erforderlichen Testroutine eingebracht werden, wobei durch das Ersetzen der gesamten ersten Partition 52 durch Programmdaten des Abbilds eine definierte Programmumgebung und ein ausführbares Betriebssystem einfach bereitgestellt werden kann.
Ferner können in der Boot-Config-Datei 70 Informationen enthalten sein, in welche Konfiguration das in der ersten Partition 52 gespeicherte Testbetriebssystem 18 gestartet wird. Insbesondere umfassen diese Informationen die Angabe, ob das Testbetriebssystem 18 mit einem Prozessor oder mit zwei Prozessoren gestartet wird. Weitere Boot Optionen können mit Hilfe der Boot-Config-Datei 70 festgelegt werden.
Mit Hilfe des OS-ID-Files 60, 66 kann ein unter dem jeweiligen bereitgestellten Betriebssystem (Verwaltungsbetriebssystem oder Testbetriebssystem) ausgeführtes Anwendungsprogramm eine Information über das aktuell bereitgestellte Betriebssystem ermitteln. Somit kann das Steuerprogramm 76 die Identität des aktuell gebooteten Betriebssystems erkennen. Der CRON-Dienst 74 des Verwaltungsbetriebssystems 16 startet einen abzuarbeitenden Testzyklus, vorzugsweise einmal pro Tag. Nach dem Start des Testzyklus ermittelt das Verwaltungsbe-triebssystem 16 die in der Liste enthaltene nächste Kombination eines Testbetriebssystems und eines zu testenden Softwareprodukts. Dieses Softwareprodukt wird auch als Produkt an Test bezeichnet. Für jede Kombination eines Testbetriebssystems und eines zu testenden Softwareprodukts ist in der dritten Partition ein Abbild gespeichert. Das in Verbindung mit dem Testbetriebssystem 18 zu testende Softwareprodukt 58 wird nach dem Start des Testbetriebssystems 18 von diesem automatisch gestartet und abgearbeitet. Anschließend können weitere Funktionstests des Softwareprodukts 58 durchgeführt werden, wie bereits in Zusammenhang mit 1 ausführlich beschrieben. Mit Hilfe der Stapelverarbeitungsdateien 82 kann der Testablauf gesteuert werden. In den Steuerdateien 80 können Informationen über die durchgeführten Tests zwischengespeichert werden.
Nachfolgend wird ein möglicher beispielhafter Testablauf beschrieben. Nach dem Start des Datenverarbeitungssystems 12 wird mit Hilfe des Boot-Managers 68 das Verwaltungsbetriebssystem 16 gestartet und bereitgestellt. Wie bereits ausgeführt, ist das Verwaltungsbetriebssystem 16 eine SUSE Linux Enterprise Server Distribution der Version 9, in der der CRON-Dienst 74 zur Zeitablaufsteuerung gestartet und aktiv ist. Zu einer festen im CRON-Dienst voreingestellten Zeit, beispielsweise um 1.00 Uhr früh, wird durch den CRON-Dienst automatisch ein Programm gestartet, das eine Stapelverarbeitungsdatei 82 mit einer Liste nacheinander für den Testablauf auszuführenden Anweisungen und mindestens eine Steuerdatei 80 anlegt. Ferner wird das Steuerprogramm 76 gestartet, das den weiteren Ablauf steuert. Das Steuerprogramm 76 liest eine Zeile der Stapelverarbeitungsdatei 82 und führt die durch diese Zeile spezifizierten Anweisungen aus. Beispielsweise ist durch diese Zeile spezifiziert, dass die Daten eines in der dritten Partition 56 gespeicherten Abbildes eines Betriebssystems und eines zu testenden Softwareprodukts in die erste Partition 52 geladen werden sollen, sodass in der ersten Partition ein zu testendes Softwaresystem bereitgestellt wird. Ferner wird die Boot-Config-Datei 70 durch eine gespeicherte Boot-Config-Datei 81 ersetzt, wodurch der Boot-Manager 68 bei einem nachfolgenden Start des Datenverarbeitungssystems 12 das in der ersten Partition 52 enthaltene Betriebssystem startet und bereitstellt. Nachdem das Steuerungsprogramm 76 das ausgewählte Abbild in der ersten Partition 52 wieder hergestellt und dem Boot-Manager 68 eine geeignete Boot-Config-Datei 70 zur Verfügung gestellt hat, löscht es die aktuelle Zeile der Stapelverarbeitungsdatei 82 und führt einen automatischen Neustart des Datenverarbeitungssystems 12 durch.
Nach dem Neustart des Datenverarbeitungssystems 12 wird durch einen entsprechenden Eintrag im Master Boot Record 84 der Boot-Manager 68 des Verwaltungsbetriebssystems 16 aufgerufen. Anschließend wird automatisch das in der ersten Partition 52 enthaltene Testbetriebssystem 18 gestartet, da dieses Testbetriebssystem 18 als Default-Betriebssystem in der Boot-Config-Datei 70 angegeben ist, das dann gestartet wird, wenn keine weiteren Bedieneingriffe erfolgen. Nach dem Start des Testbetriebssystems 18 wird das Init-Skript 64 automatisch ausgeführt. Mit Hilfe des Init-Skripts 64 wird das Steuerprogramm 76 automatisch gestartet. Das Steuerprogramm 76 greift auf die zuvor angelegte Steuerdatei 80 zu und erhält durch die in der Steuerdatei 80 gespeicherten Informationen, dass sich das Datenverarbeitungssystem 12 in einem automatischen Testlauf befindet und die Stapelverarbeitungsdatei 82 abzuarbeiten ist. Daraufhin wird die aktuell erste Zeile der Stapelverarbeitungsdatei 82 abgearbeitet. Diese Zeile kann z.B. die Anweisung enthalten, dass eine Aktualisierung des Testbetriebssystems 18 durchzuführen ist. Dazu kann, wie bereits beschrieben, das Testbetriebssystem 18 über ein Netzwerk, wie dem Internet, auf einen Server zugreifen und dort nach geeigneten Aktualisierungsdaten suchen. Enthält der Server Aktualisierungsdaten, so werden diese zum Testbetriebssystem 18 übertragen, und das Testbetriebssystem 18 wird mit Hilfe dieser Aktualisierungsdaten aktualisiert. Sowohl nach einer erfolgreichen Aktualisierung als auch dann, wenn keine Aktualisierungsdaten auf dem Server vorhanden sind, wird die erste Zeile der Stapelver-arbeitungsdatei 82 gelöscht. Anschließend wird, falls erforderlich, ein Neustart des Datenverarbeitungssystems 12 durchgeführt, um die Aktualisierung des Testbetriebssystems 18 abzuschließen. Nach diesem Neustart wird das Testbetriebssystem 18 wieder automatisch gestartet und bereitgestellt, wobei in gleicher Weise das Init-Skript 64 und das Steuerprogramm 76 gestartet werden. In der ersten Zeile des Batch Files 82 ist nunmehr die Information enthalten, dass ein Test durchgeführt werden soll. Der Testablauf wird vom Steuerprogramm 76 gesteuert. Nachdem der Test durchgeführt worden ist, wird mit Hilfe des Steuerprogramms 76 anschließend ein Abbild der ersten Partition 52 erzeugt, wobei die Daten des Abbilds in der dritten Partition 56 gespeichert werden.
Dieses Abbild wird dann am nächsten Tag als Abbild zum Testen des Softwareprodukts 58 zusammen mit dem Testbetriebssystem 18 geladen. Am nächsten Tag wird erneut überprüft, ob neue Aktualisierungsdaten zum Aktualisieren des Testbetriebssystems 18 vorliegen. Zum Durchführen der Tests des Softwareprodukts 58 in Verbindung mit dem Testbetriebssystem 18 ruft das Steuerprogramm 76 das Testautomat-Anwendungsprogramm 78 auf, bei dessen Abarbeitung vorbestimmte Test des Softwareprodukts 58 durchgeführt werden. Mit Hilfe des Testautomat-Softwareprodukts können auch verschiedene zu testende Softwareprodukte 58 nacheinander geladen und abgearbeitet werden, wobei dann jeweils geeignete Tests des Softwareprodukts durchgeführt werden. Zu jedem Test werden sogenannte Log-Daten vom Testautomat-Anwendungsprogramm 78 erzeugt und in einer entsprechenden Log-Datei gespeichert. Das Steuerprogramm 76 führt die erzeugten Log-Daten zu einer gemeinsamen Log-Datei zusammen, so dass für jeden Testlauf nur eine Log-Datei erzeugt wird. Das Steuerprogramm 76 ersetzt die Boot-Config-Datei 70 durch eine geeignete gespeicherte Boot-Config-Datei 81, so dass beim nachfolgenden Neustart des Datenverarbeitungssystems 12 das Verwaltungsbetriebssystem 16 durch den Boot-Manager 68 gestartet und somit automatisch bereitgestellt wird.
Nach einem Neustart des Datenverarbeitungssystems 12 wird das Verwaltungsbetriebssystem 16 neu gestartet und das Init-Skript 72, wie bereits beschrieben, abgearbeitet, sowie das Steuerprogramm 76 gestartet. Das Steuerprogramm 76 liest die nunmehr erste Zeile der Stapelverarbeitungsdatei 82 aus und arbeitet die darin enthaltenen Anweisungen ab. Mit Hilfe dieser Anweisungen kann ein weiteres Abbild aus der dritten Partition 56 ausgelesen und in der ersten Partition 52 gespeichert werden. Dadurch werden alle in der ersten Partition 52 gespeicherten Betriebssystem- und Anwendungsdaten durch die im Image enthaltenen Daten überschrieben. Nach einer weiteren Änderung der Boot-Config-Datei 70 und einem nachfolgendem Neustart des Datenverarbeitungssystems 12 wird das nunmehr in der ersten Partition 52 gespeicherte Testbetriebssystem gestartet und die Anweisungen des Init-Skripts 64 werden abgearbeitet. Dabei werden Aktualisierungsdaten für das Testbetriebssystem 18 ermittelt und, wenn diese ermittelt werden konnten, wird das Testbetriebssystem 18 aktualisiert. Dieses Aktualisieren und das nachfolgende Testen des Softwareprogramms 58 bzw. verschiedener Softwareprodukte 58 in Verbindung mit dem Testbetriebssystem 18 mit Hilfe von Tests erfolgt in gleicher Weise, wie bereits für das erste Testbetriebssystem des ersten geladenen Abbildes beschrieben. Nach dem Ausführen der Tests oder nach einem Abbruch der Tests wird durch eine entsprechende Manipulation der Boot-Config-Datei 70 wieder das Verwaltungsbetriebssystem 16 gestartet. Nachfolgend werden wiederum das Init-Skript 72 und das Steuerprogramm 76 gestartet. Ermittelt das Steuerprogramm 76, dass die Stapelverarbeitungsdatei 82 keine weitere Anweisungszeile enthält, ist der Testablauf beendet. Daraufhin erzeugt das Verwaltungsbetriebssystem 16 eine Nachricht, vorzugsweise eine Email-Nachricht, mit den Testergebnissen und überträgt diese an einen voreingestellten Empfänger. Das Verwaltungsbetriebssystem 16 bleibt aktiv, bis die Zeitsteuerung 74 vorzugsweise am nächsten Morgen um 1.00 Uhr den Gesamtablauf erneut startet. Daraufhin wird eine neue Stapelverarbeitungsdatei 82 mit Anweisungen über durchzuführende Tests automatisch erzeugt und der Ablauf wird wiederholt automatisch ausgeführt.
In 3 ist der Inhalt der Stapelverarbeitungsdatei 82 nach deren Erzeugung beispielhaft dargestellt. Zum Erzeugen der Stapelverarbeitungsdatei 82 wird eine entsprechende Datei an den vorbestimmten Speicherort 50 mit einem voreingestellten Dateinamen gespeichert. Vorzugsweise wird zumindest der Inhalt der Stapelverarbeitungsdatei 82 aus einer Datenquelle, wie z.B. einer anderen Datei oder einem anderen Verzeichnis, kopiert.
Die Kopfzeile der Stapelverarbeitungsdatei 82 ist in der tatsächlichen Stapelverarbeitungsdatei 82 nicht enthalten oder wird als Kommentarzeile gekennzeichnet, sodass sie für den Ablauf nicht als erste Zeile betrachtet wird. In der ersten Spalte ist jeweils die Kombination des jeweils zu ladenden Testbetriebssystems 18 und des zu testenden Softwareprodukts 58 sowie eine auszuführende Boot-Konfiguration angegeben. In der zweiten Spalte ist angegeben, welches Betriebssystem bzw. welche Kombination aus Testbetriebssystem 18 und zu testendem Softwareprodukt 58 in welcher Boot Konfiguration nachfolgend zu laden ist. In der dritten Spalte ist die durchzuführende Aktion und in der vierten Spalte ein Parameter angegeben. Ferner ist zusätzlich zu jeder Zeile ein Kommentar angegeben, durch den die vom Steuerprogramm 76 aufgrund der in der jeweiligen Zeile enthaltenen Information durchzuführenden Aktionen angegeben sind. Falls die in der ersten Spalte angegebene Betriebssystemkombination derzeit nicht ausgeführt wird, so wird mit Hilfe des Steuerprogramms 76 die Boot-Config-Datei 70 so manipuliert, dass nach einem nachfolgenden Neustart das in der ersten Spalte der ersten Zeile angegebene Betriebssystem bzw. die angegebene Kombination aus Betriebssystem und Softwareprodukt gestartet und aktiviert wird. Die in den ersten Spalten enthaltenen Bezeichnungen des aktuellen Betriebssystems und des nächsten zu ladenden Betriebssystems stimmen mit der Bezeichnung der zum Ausführen erforderlichen Boot-Config-Datei 70, die im Speicherbereich 81 gespeichert sind, überein. Die jeweils in der zweiten Spalte (hext OS) enthaltene Bezeichnung gibt an, welches Betriebssystem nach Abarbeitung der Zeile gebootet, d. h. gestartet werden soll. Vor dem Neubooten (Neustart des Datenverarbeitungssystems) wird die aktuelle Zeile gelöscht. Die Bezeichnung CONTINUE bedeutet, dass nicht umgebootet wird, d. h., dass kein anderes Betriebssystem bzw. keine andere Kombination für die im nachfolgenden Listeneintrag in der nächsten Zeile spezifizierten Aktionen zu laden ist. Auch dann wird die aktuelle Zeile gelöscht. Die Namen der zu ladenden Abbilder sind im beschriebenen Ausführungsbeispiel wie folgt definiert:
32_304 32 Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.04;
32_310 32 Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.10;
64_304 64 Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.04;
64_310 64 Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.10.
Ferner sind folgende Namenskonventionen für die Boot-Config-Dateien 81 im vorliegenden Ausführungsbeispiel festgelegt:
32_304_1 32-Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.04 mit einer CPU;
32_304_2 32-Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.04 mit zwei CPU;
32_310_1 32-Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.10 mit einer CPU;
32_310_2 32-Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.10 mit zwei CPU;
64_304_1 64-Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.04 mit einer CPU;
64_304_2 64-Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.04 mit zwei CPU;
64_310_1 64-Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.10 mit einer CPU;
64_310_2 64-Bit SUSE Linux Enterprise Server 9 mit PRISMAproduction V 3.10 mit zwei CPU.
Die erste Zeile der in 3 gezeigten Stapelverarbeitungsdatei 82 gibt somit an, dass das Verwaltungsbetriebssystem 16 (COS) ausgeführt wird, dass als nächstes das Abbild 32_304 zu laden und die Boot-Config-Datei 70 durch die Boot-Config-Datei mit der Bezeichnung 32_304_1 zu ersetzen ist. Dadurch wird nachfolgend das in die erste Partition 52 geladene Testbetriebssystem 18 SUSE Linux Enterprise Server 9 als 32 Bit Betriebssystem mit einem Prozessor gestartet und das Softwareprodukt 58 PRISMAproduction 3.04 wird abgearbeitet.
Die zweite Zeile der Stapelverarbeitungsdatei 82 gibt an, dass alle neuen 32 Bit Aktualisierungen zu ermitteln und zu laden sind, und dass nach der Aktualisierung oder dann, wenn keine Aktualisierungsdaten ermittelt werden konnten, das gleiche Betriebssystem in der gleichen Konfiguration gestartet werden soll.
Die dritte Zeile gibt an, dass das 32 Bit-Betriebssystem SUSE Linux Enterprise Server 9 in Verbindung mit dem Softwareprodukt 58 PRISMAproduction V 3.04 in der Einprozessorkonfiguration ausgeführt wird, dass die unter der Bezeichnung apa-Tests durchgeführt werden und dass nach diesen Tests kein Neustart erfolgt sondern das Testbetriebssystem weiter bereitgestellt wird.
Die vierte Zeile gibt an, dass das aktuell auszuführende Betriebssystem das 32 Bit SUSE Linux Enterprise Server 9 Betriebssystem in der Einprozessorkonfiguration und das Softwareprodukt 58 PRISMAproduction V 3.04 ist. Dabei sind die pod-Tests durchzuführen und anschließend ist nach einem Neustart die Boot-Config-Datei 32_304_2 auszuführen, wodurch das in der ersten Partition 52 enthaltene Testbetriebssystem 18 in einer Zweiprozessorkonfiguration zusammen mit dem Softwareprodukt 58 PRISMAproduction V 3.04 gestartet wird.
Die Zeile 5 gibt an, dass das 32 Bit-Betriebssystem SUSE Linux Enterprise Server 9 in einer Zweiprozessorkonfiguration zusammen mit dem Softwareprodukt 58 PRISMAproduction V 3.04 ausgeführt wird. Ferner soll das Testautomat-Anwendungsprogramm 78 die apa-Tests durchführen und anschließend das Verwaltungsbetriebssystem 16 durch eine entsprechende Manipulation der Boot-Config-Datei 70 starten.
Die sechste Zeile gibt an, dass aktuell das Verwaltungsbetriebssystem 16 ausgeführt wird und dass ein Abbild der ersten Partition erzeugt und unter der Bezeichnung 32_304 als Image Datei in der dritten Partition 56 gespeichert wird. Anschließend wird bei einem Neustart das Verwaltungsbetriebssystem 16 beibehalten.
Die siebte Zeile gibt an, dass aktuell das Verwaltungsbetriebssystem 16 ausgeführt wird und dass das Abbild mit der Bezeichnung 32_310 in die erste Partition 52 geladen wird, so dass die erste Partition 52 dann Programmdaten des 32 Bit SUSE Linux Enterprise Server 9 Betriebssystems in einer 32 Bit-Version sowie die Programmdaten des Softwareprodukts 58 PRISMAproduction V 3.10 enthält. Anschließend soll dieses Betriebssystem in einer Einprozessorkonfiguration gestartet werden.
Die achte Zeile gibt an, dass das 32 Bit Betriebssystem SU-SE Linux Enterprise Server 9 zusammen mit dem Softwareprodukt 58 PRISMAproduction V 3.10 in einer Einprozessorkonfiguration ausgeführt wird und Aktualisierungsdaten ermittelt werden, mit denen dieses Betriebssystem aktualisiert wird. Nachfolgend wird das Betriebssystem SUSE Linux Enterprise Server 9 als 32 Bit-Betriebssystem mit einem Prozessor gestartet und alle Test durchgeführt. Nach einem Neustart wird das 32 Bit-Betriebssystem SUSE Linux Enterprise Server in einer Zweiprozessorkonfiguration gestartet und es werden alle Test durchgeführt. Nachfolgend wird das Verwaltungsbetriebssystem gestartet.
Die elfte Zeile gibt an, dass das Verwaltungsbetriebssystem 16 aktuell ausgeführt wird und als nachfolgendes Betriebs system wiederum das Verwaltungsbetriebssystem 16 ausgeführt werden soll. Ferner soll ein Abbild der ersten Partition 52 erzeugt und als Image Datei unter der Bezeichnung 32_310 im in der dritten Partition 56 gespeichert werden.
Die zwölfte Zeile gibt an, dass aktuell das Verwaltungsbetriebssystem 16 ausgeführt wird und dass der Ablauf nicht fortgesetzt wird. Ferner wird die Anweisung gegeben, dass ein Testbericht erstellt wird.
In 4 ist ein Ablaufdiagramm des vom Steuerprogramm 76 gesteuerten Ablaufs dargestellt. Dieses Ablaufprogramm wird auch als SUSE-Update-Initiation-Inspector bezeichnet und ist in 1 mit den Buchstaben supii abgekürzt. Der Ablauf wird im Schritt S10 gestartet. Anschließend wird im Schritt 12 überprüft, ob bei einer vorangegangenen Aktualisierung des in der ersten Partition 52 gespeicherten Betriebssystems eine Aktualisierung des Boot-Managers 62 installiert worden ist, durch die in den Master Boot Record 84 ein Verweis auf den Boot-Manager 62 des Testbetriebssystems 18 eingetragen worden ist. Der Boot-Manager 62 bei dem im vorherigen Ausführungsbeispiel verwendeten Testbetriebssystem SUSE Linux Enterprise Server 9 hat ein solcher Boot-Manager 62 die Bezeichnung Grub. Ist das der Fall, so wird der Eintrag im Master Boot Record 84 geändert, sodass nach einem nachfolgenden Neustart der Boot-Manager 68 des Verwaltungsbetriebssystems 16 aktiv ist.
Anschließend wird überprüft, ob eine Steuerdatei 80 vorhanden ist, durch die angegeben ist, dass sich das Datenverarbeitungssystem in einem Testablauf zum Testen mindestens eines Testbetriebssystems 18 in Verbindung mit einem Softwareprodukt 58 befindet. Nach dem Start des Testablaufs durch den CRON-Dienst 74 wird diese auch als supii_active bezeichnete Datei als Steuerdatei 80 angelegt. Beispielsweise kann diese Steuerdatei 80 auch durch ein Benutzereingriff entfernt werden, wodurch der Testablauf abgebrochen werden kann. Alternativ kann der Testablauf nicht vom CRON-Dienst 74 gestartet werden sondern manuell durch einen Benutzereingriff. Auch dann ist die Steuerdatei supii_active nicht vorhanden. Wird im Schritt S14 festgestellt, dass die Steuerdatei 80 supii_active nicht vorhanden ist, so wird nachfolgend im Schritt S16 überprüft, ob Testparameter in einer weiteren Steuerdatei 80 oder in einer Stapelverarbeitungsdatei 82 verfügbar sind. Ist das nicht der Fall, so ist der Ablauf im Schritt S18 beendet. Sind Parameter zum Spezifizieren der durchzuführenden Tests in einer Steuerdatei 80 oder in einer Stapelverarbeitungsdatei 82 vorhanden, so werden die so spezifizierten Aktionen in Schritt S20 durchgeführt, wobei der Ablauf im nachfolgenden Schritt S18 beendet ist.
Wird im Schritt S14 jedoch festgestellt, dass die Steuerdatei 80 supii_active vorhanden ist, so wird nachfolgend im Schritt S22 überprüft, ob ein supii_logfile vorhanden ist. In diesem Log-File wird der gesamte durch das Steuerprogramm 76 gesteuerte Testablauf protokolliert. Wird im Schritt S22 festgestellt, dass ein solches supii_logfile nicht vorhanden ist, so wird anschließend im Schritt S24 ein solches Log-File erzeugt und in der dritten Partition 56 gespeichert. Nach dem Abspeichern des supii_logfiles oder wenn im Schritt S22 festgestellt wird, dass ein solches supii_logfile bereits vorhanden ist, wird anschließend im Schritt S26 die erste Zeile der Stapelverarbeitungsdatei 82 mit dem Namen todo.bat eingelesen. Anschließend wird im Schritt S28 überprüft, ob die Zeile eine Kommentarzeile o der eine leere Zeile ist. Ist dies der Fall, so wird anschließend im Schritt S30 die Kommentarzeile oder die leere Zeile gelöscht und der Ablauf im Schritt S26 fortgesetzt, bis im Schritt S28 ermittelt wird, dass die eingelesene erste Zeile weder eine Kommentarzeile noch eine leere Zeile ist. Dann wird der Ablauf im Schritt S32 fortgesetzt.
Im Schritt S32 wird überprüft, ob das aktuell durch das Datenverarbeitungssystem 12 bereitgestellte Betriebssystem mit dem in der ersten Spalte der ersten Zeile angegebenen Betriebssystem übereinstimmt. Dazu wird insbesondere die OS-ID-Datei 60 bzw. 66 des aktuell abgearbeiteten Betriebssystems 18 bzw. 16 ausgelesen und diese Information mit der Betriebssystemangabe der ersten Spalte verglichen. Stimmt das aktuell bereitgestellte Betriebssystem nicht mit dem durch den Listeneintrag in der ersten Spalte der ersten Zeile überein, so wird anschließend im Schritt S34 überprüft, ob eine Datei supii_booting als Steuerdatei 80 in der dritten Partition 56 gespeichert ist. Ist das der Fall, so ist der Ablauf im Schritt S34 beendet, da dann bereits wiederholt neu gestartet, d. h. gebootet worden ist, ohne dass das korrekte Betriebssystem gestartet und bereitgestellt worden ist. Wird im Schritt S34 festgestellt, dass die Datei supii_booting nicht vorhanden ist, so wird anschließend im Schritt S38 eine Datei supii_booting erzeugt und es wird eine für das in der ersten Spalte der ersten Zeile spezifizierte Betriebssystem zugeordnete Boot-Config-Datei aus den Boot-Config-Dateien 81 ausgewählt und als Boot-Config-Datei 70 gespeichert, sodass der Boot-Manager 68 bei einem nachfolgenden Neustart des Datenverarbeitungssystems 12 das gewünschte Betriebssystem startet und bereitstellt. Anschließend wird ein Neustart des Datenverarbeitungssystems 12 durchgeführt, und der Ablauf wird nach dem Neustart im Schritt S10 fortgesetzt. Wird im Schritt S32 jedoch festgestellt, dass das aktuell bereitgestellte Betriebssystem mit dem in der ersten Spalte der ersten Zeile der Datei todo.bat spezifizierten Betriebssystem übereinstimmt, so wird die Datei supii_boot im Schritt S42 gelöscht. Anschließend wird im Schritt S44 überprüft, ob in der ersten Zeile als Aktion ein Test, insbesondere ein Funktionstest von durch die Anwendungssoftware 58 bereitgestellten Funktionen, auszuführen ist. Ist das der Fall, so wird anschließend im Schritt S46 gewartet, bis das zu testende Anwendungsprogramm PRISMAproduction als zu testendes Softwareprodukt 58 gestartet worden ist und dessen Funktion zur Verfügung gestellt wird.
Anschließend wird im Schritt S48 überprüft, ob das Softwareprodukt 58 PRISMAproduction betriebsbereit ist. Ist das der Fall oder wird im Schritt S44 festgestellt, dass die auszuführende Aktion kein Test ist, so wird anschließend im Schritt S50 die in der ersten Zeile spezifizierte Aktion durchgeführt. Anschließend oder wenn im Schritt S48 festge stellt wird, dass das Softwareprodukt 58 PRISMAproduction nicht bereit ist, wird im Schritt S52 die erste Zeile gelöscht. Nachfolgend wird im Schritt S54 überprüft, ob als nächstes auszuführendes Betriebssystem CONTINUE angegeben ist, wodurch das derzeit bereitgestellte Betriebssystem ohne Neustart beibehalten wird. Ist das der Fall, so wird der Ablauf im Schritt S26 fortgesetzt.
Wird im Schritt S54 jedoch festgestellt, dass das derzeit bereitgestellte Betriebssystem nicht beibehalten werden soll, wird der Ablauf im Schritt S56 fortgesetzt.
Im Schritt S56 wird dann überprüft, ob in der zweiten Spalte der aktuellen Zeile die Bezeichnung Stopp enthalten ist. Ist das der Fall, so ist der Testablauf beendet und es wird nachfolgend im Schritt S60 das Batch File todo.bat sowie die Steuerdateien supii_active und supii_logfile gelöscht. Anschließend ist der Ablauf im Schritt S62 beendet. Wird im Schritt S56 festgestellt, dass in der zweiten Spalte NEXT-OS eine andere Bezeichnung als Stopp enthalten ist, so wird anschließend eine dem Eintrag in der zweiten Spalte zugeordnete Boot-Config-Datei aus den Boot-Config-Dateien 81 ausgewählt und als Boot-Config-Datei 70 gespeichert, sodass der Boot-Manager 68 bei einem nachfolgenden Neustart des Datenverarbeitungssystems 12 im Schritt S58 das gewünschte Betriebssystem in der angegebenen Konfiguration startet.
Somit wird, wenn die Datei supii_active vorhanden ist durch das Vorhandensein der Datei angegeben, dass der automatische Testlauf, d. h. ein Testlauf im Stapelverarbeitungs-Modus läuft, bei dem die Listeneinträge der Datei todo.bat nacheinander abgearbeitet werden. Durch das Erzeugen der Datei supii_booting wird ein endloses Neustarten des Datenverarbeitungssystems 12 verhindert, ohne dass der Testablauf abgearbeitet wird. Dies ist insbesondere bei einer fehlerhaften Stapelverarbeitungsliste sinnvoll, um das Datenverarbeitungssystem nicht unnötig oft zu Booten, d. h. nicht unnötig oft zu starten. Mit Hilfe der Datei supii_grubrepair kann der Boot-Manager 68 des Verwaltungsbetriebssystems 16 neu installiert und ein entsprechender Eintrag im Master Boot Record 84 erzeugt werden. Die Datei supii_logfile enthält den Namen eines aktuell angelegten Log-Files. Die Datei supii_protfile enthält den Dateinamen einer zu erzeugenden Protokolldatei.
Wie bereits in Verbindung mit 3 erwähnt, wird nach einer durchgeführten Aktualisierung des Testbetriebssystems ein Abbild der gesamten ersten Partition 52 einschließlich der Programmdaten des Testbetriebssystems und des jeweiligen Softwareprodukts 58 sowie weiteren Anwendungs und Programmdaten erzeugt und als Abbild bzw. Image in der dritten Partition 56 gespeichert. Dieses Abbild kann unter dem Betriebssystem Linux beispielsweise mit der Funktion CPIO ausgeführt werden. Ein solches Abbild kann beispielsweise als Backup durch folgende Befehle erzeugt werden:
Ein solches erzeugtes Abbild kann wie bereits erwähnt in der dritten Partition 56 gespeichert und für nachfolgende Tests wieder in die erste Partition 52 eingespielt, d. h. in die erste Partition 52 zurückgespeichert, werden, wodurch in der ersten Partition 52 Daten derselben Programme und Anwendungsdaten vorhanden sind, wie beim vorhergehenden Sichern dieser Daten. Das Abbild kann beispielsweise mit folgenden Anweisungen von der dritten Partition 56 in die erste Partition 52 übertragen werden:
Die Erfindung wurde beispielhaft mit den Betriebssystemen SUSE Linux Enterprise Server 9 als Verwaltungsbetriebssystem und als Testbetriebssystem in verschiedenen Varianten beschrieben. Jedoch kann sowohl das Verwaltungsbetriebssystem 16 als auch die Testbetriebssysteme 18 durch andere Be triebssysteme, wie beispielsweise Microsoft Windows Betriebssysteme in verschiedenen Versionen, Unix Betriebssystemen, Mac-OS oder anderen bekannten oder zukünftigen Betriebssystemen genutzt werden. Insbesondere können verschiedene Testbetriebssysteme nacheinander mit verschiedenen Softwareprodukten getestet werden. Dabei können mit einem Testbetriebssystem auch mehrere Softwareprodukte 58 gleichzeitig oder nacheinander getestet werden.
Ferner ist es möglich die Testbetriebssyteme nacheinander oder parallel auf verschiedenen virtuellen Maschinen in einer virtuellen Umgebung zu starten, wobei das Verwaltungsbetriebssystem vorzugsweise das Grundbetriebssystem ist, das mit Hilfe eines Anwendungsprogramms eine virtuelle Umgebung zum Bereitstellen mehrerer virtueller Maschinen ermöglicht. Ein solches Anwendungsprogramm ist beispielsweise unter der Bezeichnung VMware der Firma VMware Corporation oder unter der Bezeichnung XEN bekannt, die aktuellen SUSE Linux Distribation beigefügt ist. Jede andere virtuelle Umgebung ist auch in gleicher Weise einsetzbar.
Es ist besonders vorteilhaft, wenn ein automatisiertes Testverfahren einen Teil der folgenden Verfahrensschritte aufweist, die automatisch ausgeführt werden:

– Überprüfen, ob Aktualisierungsdaten zum Aktualisieren des Betriebssystems (Updatedaten oder Patchdaten) verfügbar sind
– Herunterladen der Aktualisierungsdaten, vorzugsweise von einem Server
– Neustart des Betriebssystems, um sicherzustellen, dass alle Aktualisierungen aktiviert sind
– Umfangreiche Tests einer Anwendungssoftware (beispielsweise PRISMAproduction) mit dem aktualisierten Betriebssystem
– Wiederholen der vorhergehenden Schritte für verschiedene Betriebssysteme oder Betriebssystemversionen

Werden bei den Tests Druckdaten oder Druckdatenströme erzeugt, können diese über verschiedene Schnittstellen ausgegeben werden, die auch als Software realisiert sein können. Diese Schnittstellen können direkte Schnittstellen, Océ SPS CIS, Océ SPS, IBM ACIF oder IBM PSF-Schnittstellen sein.
Für einige Ablaufschritte zum Durchführen des Testablaufs können Time-out Überwachungen vorgesehen sein, durch die der Testablauf bei einer Zeitüberschreitung einer vorgegebenen Zeit abgebrochen wird. Ferner kann eine zentrale Abbruchsfunktion (Central Exit Code) ausgewertet werden. Ferner kann zusätzlich oder alternativ eine zentrale Fehlerbehandlung vorgesehen werden, durch die beispielsweise Ablaufschritte wiederholt werden, bei denen ein Fehler aufgetreten ist.
Die Erfindung ist insbesondere dazu geeignet, als Computerprogramm (Software) realisiert zu werden. Sie kann damit als Computerprogramm-Modul als Datei auf einem Datenträger, wie einer Diskette, DVD- oder CD-ROM, oder als Datei über ein Daten- bzw. Kommunikationsnetz verbreitet werden. Derartige und vergleichbare Computerprogramm-Produkte oder Computerprogramm-Elemente sind Ausgestaltungen der Erfin dung. Der erfindungsgemäße Ablauf kann in einem Computer, in einem Druckgerät oder in einem Drucksystem mit vorgeschalteten oder nachgeschalteten Datenverarbeitungsgeräten Anwendung finden. Dabei ist klar, dass entsprechende Computer, auf denen die Erfindung angewandt wird, weitere, an sich bekannte technische Einrichtungen, wie Eingabemittel (Tastatur, Mouse, Touchscreen), einen Mikroprozessor, einen Daten- bzw. Steuerungsbus, eine Anzeigeeinrichtung (Monitor, Display) sowie einen Arbeitsspeicher, einen Festplattenspeicher und eine Netzwerkkarte enthalten können.
Obgleich in den Zeichnungen und in der vorhergehenden Beschreibung bevorzugte Ausführungsbeispiele aufgezeigt und detailliert beschrieben worden sind, sollte dies als rein beispielhaft und die Erfindung nicht einschränkend angesehen werden. Es sei darauf hingewiesen, dass nur die bevorzugten Ausführungsbeispiele dargestellt und beschrieben sind und sämtliche Veränderungen und Modifizierungen, die derzeit und künftig im Schutzumfang der Erfindung liegen, geschützt werden sollen.

10: Gesamtsystem
12: Datenverarbeitungssystem
14: Drucksimulationssystem
16: Verwaltungssystem
18: Testbetriebssystem
20: Speicherbereich
22: Abbilder mehrerer Testbetriebssysteme
24: Grundeinstellungen eines Boot-Laders
26: Skript
28: Testablaufliste
30, 36: TCP/IP-Schnittstelle
32, 38: SCSI-Schnittstelle
34, 40: /370-Schnittstelle (IBM-Kanal)
42: Bilddaten
44, 46, 48, 50: Anwendungsprogramm
52: erste Partition
54: zweite Partition
56: dritte Partition
58: zu testendes Softwareprodukt
60: OS-ID-Datei
62: Boot-Manager
64: Skript
66: OS-ID-Datei
68: Boot-Manager
70: Boot-Config-Datei
72: Skript
74: Zeitablaufsteuerung
76: Steuerprogramm
78: Test-Automat-Anwendungsprogramm
80: Steuerdateien
81: Boot-Config-Dateien
82: Stapelverarbeitungsdatei
84: Mater Boot Record
S10-S62: Ablaufschritte

Claims

Datenverarbeitungssystem mit einem Verwaltungsbetriebssystem (16), mit mindestens einem Testbetriebssystem (18), mit einer Liste (28, 82) mit nacheinander automatisch bereitzustellender Testbetriebssysteme (18) und/oder nacheinander automatisch bereitzustellender Testbetriebssystemkonfigurationen, und mit mindestens einer Testroutine (78), die unter dem bereitgestellten Testbetriebssystem (18) automatisch ausführbar ist.
Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, dass die Testroutine (78) ein Anwendungsprogramm (58) aufruft, durch das das Datenverarbeitungssystem (12) eine Druckserverfunktion bereitstellt, und/oder dass die Testroutine (78) Druckdaten zu einem Druckdatenstrom verarbeitet und zu einem mit dem Datenverarbeitungssystem (12) verbundenen Testsystem (14) überträgt, wobei das Testsystem (14) mit Hilfe der übertragenen Druckdaten mindestens ein Rasterbild erzeugt und vorzugsweise mit einem gespeicherten Rasterbild (42) vergleicht.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens ein Testbetriebssystem (18) in einer ersten und in mindestens einer zweiten Konfiguration nacheinander durch das Verwaltungsbetriebssystem (16) gesteuert bereitgestellt wird, wobei die Konfiguration vorzugsweise mit Hilfe mindestens eines Konfigurationsparameters festgelegt ist.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens zwei Testbetriebssysteme (18) vorgesehen sind, die durch das Verwaltungsbetriebssystem (16) gesteuert entsprechend ihren Listeneinträgen in der Liste (28, 82) nacheinander bereitgestellt werden.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verwaltungsbetriebssystem (16) die Testergebnisse der mindestens einen Testroutine (78) und/oder des Vergleichs ermittelt und als Testergebnis ausgibt, vorzugsweise in einer Datei speichert, als Nachricht an einen Empfänger überträgt und/oder mit Hilfe einer Ausgabeeinheit ausgibt.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Testbetriebssystem (18) nach dem Ausführen der Testroutine (78) automatisch beendet wird, und dass das Verwaltungsbetriebssystem (16) anschließend automatisch überprüft, ob ein weiteres Testbetriebssystem (18) und/oder eine weitere Testbetriebssystemkonfiguration zu starten ist.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass, währenddessen das Verwaltungsbetriebssystems bereitgestellt wird, überprüft wird, ob ein in der Liste (28, 82) enthaltenes Testbetriebssystem (18) und/oder eine in der Liste (28, 82) enthaltene Testbetriebssystemkonfiguration noch nicht bereitgestellt worden ist, und dass das Verwaltungsbetriebssystem (16) das Datenverarbeitungssystem (12) so konfiguriert, dass nach einem automatischen Neustart des Datenverarbeitungssystems (12) ein noch nicht bereitgestelltes Testbetriebssystem (18) oder eine noch nicht bereitgestellte Testbetriebssystemkonfiguration automatisch gestartet wird.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass, währenddessen das Verwaltungsbetriebssystem (16) bereitgestellt wird, ein Neustart des Datenverarbeitungssystems (12) initiiert wird, nachdem das Datenverarbeitungssystem (12) derart neu konfiguriert worden ist, dass es nach dem Neustart des Datenverarbeitungssystems (12) ein in der Liste (28, 82) spezifiziertes Testbetriebssystem (18) oder eine in der Liste spezifizierte Testbetriebssystemkonfiguration bereitstellt, und dass, währenddessen ein Testbetriebssystem (18) und/oder eine Testbetriebssystemkonfiguration bereitgestellt wird, ein Neustart des Datenverarbeitungssystems (12) initiiert wird, nachdem die Testroutine (58, 78) beendet oder abgebrochen worden ist.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Testbetriebssystem (18) und/oder die Testbetriebssystemkonfiguration so konfiguriert sind, dass eine Aktualisierung des Testbetriebssystems (18) durchgeführt wird, wenn Aktualisierungsdaten zum Aktualisieren der Programmdaten des Testbetriebssystems (18) verfügbar sind, und/oder dass die Testroutine (58, 78) nur dann automatisch gestartet wird, wenn die Programmdaten des Testbetriebssystems (18) aktualisiert oder Programmdaten eines unter dem Testbetriebssystem (18) abzuarbeitenden Anwendungsprogramms (58) geändert worden sind.
Datenverarbeitungssystem nach Anspruch 9, dadurch gekennzeichnet, dass das Verwaltungsbetriebssystem (16) die Programmdaten des aktualisierten Testbetriebssystems (18) sichert, vorzugsweise nachdem das Testbetriebssystem (18) beendet worden ist.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Testbetriebssystem (18) nach dem Ausführen der Testroutine (58, 78), nach einem erfolglosen Aufruf der Testroutine oder nach einem Abbruch der Testroutine (58, 78) das Datenverarbeitungssystem (12) so konfiguriert, dass nach einem Neustart des Datenverarbeitungssystems (12) das Verwaltungsbetriebssystem (16) wieder bereitgestellt wird.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Datenverarbeitungssystem (12) den Listeneintrag eines bereitzustellenden Testbetriebssystems (18), eines bereit gestellten Testbetriebssystems (18), einer bereitzustellenden Testbetriebssystemkonfiguration oder einer bereitgestellten Testbetriebssystemkonfiguration in der Liste (28, 82) als abgearbeitet markiert oder aus der Liste (28, 82) entfernt.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche 8 bis 12, dadurch gekennzeichnet, dass das Testbetriebssystem (18) das Datenverarbeitungssystem (17) mit Hilfe eines Boot-Managers (68) so konfiguriert, dass nachfolgend das Verwaltungsbetriebssystem (16) bereitgestellt wird, und/oder dass das Verwaltungsbetriebssystem (16) das Datenverarbeitungssystem (16) mit Hilfe eines Boot-Managers (68) so konfiguriert, dass nachfolgend das Testbetriebssystem (18) bereitgestellt wird.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verwaltungsbetriebssystem (16) oder ein unter dem Verwaltungsbetriebssystem (16) ausgeführtes Anwendungsprogramm (74) das Abarbeiten der Liste (28, 82) zu einer voreingesteliten Zeit automatisch startet.
Datenverarbeitungssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Datenverarbeitungssystem (12) mindestens drei Speicherbereiche, vorzugsweise mindestens drei Partitionen (52, 54, 56), aufweist, wobei vorzugsweise im ersten Speicherbereich (52) zumindest Programmdaten und/oder Anwendungsdaten zum Bereitstellen eines Testbetriebssystems (18), im zweiten Speicherbereich zumindest Programmdaten und/oder Anwendungsdaten zum Bereitstellen des Verwaltungsbetriebssystems (16) und/oder im dritten Speicherbereich zumindest Programmdaten und/oder Anwendungsdaten zum Bereitstellen mindestens eines Testbetriebssystems (18) gespeichert sind, mit denen die im ersten Speicherbereich (52) zum Bereitstellen des Testbetriebssystems (18) erforderlichen Programmdaten und/oder Anwendungsdaten erzeugt werden können.
Datenverarbeitungssystem nach Anspruch 15, dadurch gekennzeichnet, dass die im dritten Speicherbereich (56) gespeicherten Daten zum Erzeugen der im ersten Speicherbereich (52) zum Bereitstellen des Testbetriebssystems (18) zu speichernden Programmdaten und/oder Anwendungsdaten dienen, wobei die im dritten Speicherbereich (56) gespeicherten Daten vorzugsweise mindestens ein Abbild des ersten Speicherbereichs (52) umfassen.
Verfahren zum Ausführen einer Testroutine in Verbindung mit einem Testbetriebssystem, bei dem Programmdaten zum Bereitstellen eines Verwaltungsbetriebssystems (16) abgearbeitet werden, mit Hilfe einer Liste (28, 82) mit nacheinander automatisch bereitzustellenden Testbetriebssystemen (18) und/oder nacheinander automatisch bereitzustellenden Testbetriebssystemkonfigurationen ein durch einen Listeneintrag spezifiziertes Testbetriebssystem (18) und/oder eine spezifizierte Testbetriebskonfiguration unter dem bereitgestellten Verwaltungsbetriebssystem (16) ermittelt wird, währenddessen das Verwaltungsbetriebssystem (16) bereitgestellt wird, Programmdaten zum Breitstellen des ermittelten Testbetriebssystems (18) oder der ermittelten Testbetriebssystemkonfiguration abgearbeitet werden, und bei dem mindestens eine Testroutine (58, 78) ausgeführt wird, die unter dem bereitgestellten Testbetriebssystem (18) automatisch ausgeführt wird.
Computerprogrammprodukt, umfassend Befehle und Daten in codierter Form, die nach dem Laden der Programmdaten ein Datenverarbeitungssystem veranlassen, die Verfahrensschritte des Verfahrens nach Anspruch 17 auszuführen.
Datenträger mit Programmdaten eines Computerprogrammprodukts nach Anspruch 18.