DE102006047762A1 - System for testing function of computer network, has test data base, where number of test scenarios are stored or discarded, and diagnosis framework that has run time environment, where every test scenario is executed - Google Patents

Abstract

The system (10) has a test data base (14), where a number of test scenarios are stored or discarded. A diagnosis framework (11) has a run time environment, where every test scenario is executed. An evaluating processor unit that controlled the execution of every test scenario and a test report that is prepared for display for an operator. The test scenarios are provided by a test editor, for executing the run time environment. The test scenario is deposited in a form corresponds Petri net or an activity diagram according to an Unified Modeling Language 2 standard.

Description

The The invention relates to a system for testing the function of a Computer network. As a computer network becomes a locally limited structure of interconnected computers for data exchange, in particular called a LAN (Local Area Network). A computer network In this sense, a so-called PACS (Picture Archiving and Communication System), as it is in the clinical field for the division of labor, processing and evaluation of medical Image data is used.

One such computer network typically includes a variety of data transmission technology interconnected network nodes, each node through a computer is realized. The term "computer" is to be understood generally and includes servers for Data and data processing services, diagnostic stations or other Workstations in particular computer-aided medical examination devices (modalities) such as e.g. Computed tomography (CT) scanners, ultrasound scanners, x-ray image recorders, magnetic resonance tomographs, Etc.

One Such computer networks are becoming increasingly prone to instabilities and increases in size and complexity System failures, the function of the entire network or individual network areas sometimes significantly restrict or even bring it to a standstill. Such malfunctions can diverse Have causes. In addition to hardware defects comes in particular one Misconfiguration of connection parameters, software errors or an incompatibility the hardware and / or software components that interact in the network in question.

A such incompatibility occurs especially often on, if not matched, hardware or software components different manufacturers or different versions in combination be used together.

The Cause for such a malfunction is often difficult to find, especially especially cause and symptoms of malfunction often in no obvious Related to each other. For example, a misconfiguration of a any workstation of a hospital under unfavorable circumstances cause that the data throughput of a central server drastically reduced is or the server goes down completely. A comparable effect could but also be caused by, for example, that an crucial point arranged network node too little memory has, etc.

Of the The invention is based on the object, a system for testing the To specify the function of a computer network based on effective and easily manageable way error detection and error analysis in a computer network.

These The object is achieved by the features of claim 1.

After that are in the context of the system a test database and a diagnostic framework intended. The test database can be part of the diagnostic framework or a separate system component. In the test database are a number of test scenarios, i. at least one test scenario, but prefers a variety of test scenarios, storable or stored. The diagnostic framework includes a runtime environment on which the or any test scenario executable is. Furthermore, the diagnostic framework comprises an evaluation unit and a test editor. The evaluation unit is designed here to execution of the or each test scenario and based on this monitoring a review in one for one Create user-viewable form, especially as XML text. The test editor in turn is trained to create newer, for execution on the runtime environment of appropriate test scenarios by a user to support.

The Diagnostic framework and its components are preferred as software modules trained on one or more nodes of a computer network can be installed or installed. Deviating from this, the Diagnosis framework and its components but also in the form of a Hardware with preinstalled software, e.g. a plug-in card, be educated.

A "test scenario" is a software routine, which checks a specific function of the computer network and a output value depending on the result of this check returns it can be seen from this, if and to what extent the test successfully performed or if an error has occurred. Optional specified the output value in the event of an error also the type of error that has occurred closer. The output value can optionally be a text message (e.g., "Test successful performed ") or a code character contain.

A "framework" generally refers to an arrangement of software modules that supports the creation and execution of concrete application software - in this case the test scenarios - and thus forms a "framework software" for the application software. The framework provides the software architecture for the application soft ware and controls their control flow.

A runtime environment is a software layer referred to an application software - so here to be performed Test scenario - and is stored in the operating system of a network node. The Runtime environment provides basic functionality needed by the application software e.g. Reading and writing files, controlling input and output Output devices, etc. to disposal and translate that often a so-called intermediate code application software in the immediately executable Machine code.

By doing as part of the diagnostic framework a special test editor with combined with a customized runtime environment, it is possible to Create and manage test scenarios in a particularly easy way and execute. Promotes this purpose also the evaluation unit still assigned to the diagnostic framework, by having one for All test scenarios unified platform for the preparation of the represents output values returned by each test scenario during execution. The test scenarios themselves can Therefore, be relatively simple and therefore are can be set up quickly and flexibly. On the basis of the evaluation unit in the form of the test report, the unified test result is also a simple and easy to handle troubleshooting and analysis allows.

A particularly simple and intuitive handling of the system is thereby allows that the or each test scenario in an at least substantially a Petri net or an activity diagram according to the UML2 standard corresponding form is deposited. As "Petri net" is a known mathematical Model for modeling systems and transformation processes designated.

One Petri net generally consists of so-called places (places / places) and so-called transitions (resp. Transitions / transitions). By convention, positions are represented as circles, transitions as rectangular bars. Positions and transitions are connected by directed "edges", wherein there are no direct connections between two places or two transitions.

each Job has a so-called "capacity" and can accordingly many so-called "brands" (tokens) included. Is a capacity not stated, this is - ever by convention - for an infinite capacity or a capacity of value one. Each edge has a weight assigned to it so-called "cost" of this edge sets. A transition is considered "ready to switch" if in all entry points at least as many brands as the transition costs, and all exit points still have enough capacity to handle the new brands receive. When switching a transition will be out of the starting points according to the edge weights marks removed, and at the exit points added marks according to the edge weights.

For more details on the properties of a Petri net will be on http://de.wikipedia.org/wiki/Petri-Netz in the version of 29 August 2006 - 11:44 clock Referenced.

One so-called activity diagram according to the UML2 standard (Unified Modeling Language Version 2.x) is similar to a Petri net Properties on. Instead of places or squares has an activity diagram Actions based on conventionally called rectangles be represented with rounded corners. Instead of the transitions are as part of an activity diagram so-called synchronization bar provided. The notation of a activity diagram according to UML2 compared to the abstract mathematical model of a Petri net flexibilizes. So can in Frame of an activity diagram - different as with a classic Petri net - two actions also directly without intermediate transition be joined together by a directed edge.

When a "Petri net or an activity diagram according to UML2 Form "will be any Data format, which is a unique representation of the components a test scenario on a Petri net or an activity diagram according to UML2. In particular, a test scenario is then in a Petri net or an activity diagram appropriate form if it is in a number of components (Actions or bodies) is divided, if between these components directed data transfer rules (edges) and possibly branching or transition points (transitions, synchronization bars) are defined, and if these components, data transfer rules and branching points the for a Petri net or an activity diagram according to UML2 Properties are enough. A form corresponding to a Petri net or an activity diagram may also be present, especially if one of the for a Petri net or an activity diagram according to UML2 Conventions different nomenclature or representation is chosen.

In an expedient embodiment of the invention, the system here comprises a display unit which is preferably designed as a software module and which is designed to display the or each test scenario in the form of a Petri net or an activity diagram graphically according to UML2. In order to allow a particularly simple and intuitive creation of test scenarios, the display unit with the test editor expediently cooperates in such a way that the or each test scenario can be generated graphically, ie directly in the form of a graphic. Additionally or alternatively, the display unit cooperates with the evaluation unit to the effect that the test result resulting from the execution of any test scenario can be represented on the basis of the graphical representation of this test scenario, which in particular makes it possible for the test result for a user to be detected at a glance. In order to simplify the error analysis, it is provided that any test errors are displayed in a position-resolved or action-resolved manner. This is understood to mean that the or each test error in the graphical representation of the associated test scenario is graphically assigned to the point or action that caused the test error. Such an assignment takes place in a suitable manner by test result-dependent coloring of the points or actions in the graphical representation of the test scenario. For example, instances of a test scenario that have been successfully executed are displayed in green, while bodies or actions that have produced a test error are highlighted in red.

In An advantageous embodiment of the invention is the runtime environment configured to operate in a simulation mode is. The simulation mode is characterized by the fact that the parameters the computer network are only temporarily changed. In the simulation mode will for this purpose be a copy of the parameter configuration of the computer network or one for create a particular test scenario relevant part of it the changes can be made without the actual Parameter configuration of the computer network is affected. This copy of the parameter configuration can then be used in the simulation mode Test scenarios are applied. The simulation mode allows the Effect of changes in the Parameter configuration without risk to the integrity of the existing Compromise network configuration. At the end of the simulation mode is expediently provided that after Desire of the user's simulated parameter configuration, i. the copy stored in the simulation mode, either on taken over the real computer network or can be discarded. In the latter case, the pre-entry in the simulation mode existing configuration state of the computer network restored.

In An advantageous development is the runtime environment trained that in the simulation mode not only the parameter configuration the real node of the computer network is changeable, but that in addition new Network node simulated, i. are virtually generated. To this In particular, a planned network extension can be tested be without the for This network expansion actually required hardware disposal would have to stand. In the extreme case, this can be done on a single physical Calculator an entire computer network can be simulated.

The Diagnosis framework is appropriate scalable designed in the sense that it is in any scope is expandable by new test scenarios. Besides the possibility create new test scenarios using the test editor yourself, is for this preferably the possibility provided new test scenarios from a global test database to import. The term "global" is initially general in the sense of "cross-network". A Test database is global in this sense, if they are multiple computer networks, for example, several independent PACS systems, together to disposal stands. In a preferred embodiment, however, is the diagnostic framework with a network external database in the original Word meaning "global", namely worldwide accessible is. In this way, a rapid dissemination of suitable test scenarios allows the separate self-developments for common problems largely redundant.

in the Sense of a possible flexible development of the existing test scenario pool - thus in the sense of the above introduced Scalability - is preferably besides the possibility to create new test scenarios from scratch, also the possibility provided already existing test scenarios as part of, in particular as the point or action of a new test scenario can. That way you can in particular different existing test scenarios to a parent Test scenario are grouped. Such a higher-level test scenario can then in turn be part of a higher-level test scenario be. Optionally it is provided that a test scenario recursively as well can contain itself as an ingredient.

In a preferred variant of the system, as described above, the diagnostic framework is installed or installable only on a node of the computer network. This diagnostic framework represents a master framework from which the monitoring of the computer network is controlled. On the other nodes of the computer network, however, so-called agent frameworks are installed, which compared to the master framework, a reduced radio have to start. Each of the agent frameworks contains, in particular, a runtime environment for executing local test scenarios-that is, only relevant for the respective network node-as well as an evaluation unit for monitoring the execution of such local test scenarios. The evaluation unit assigned to each agent framework is similar to the evaluation unit of the master framework in that it generates a test result in the course of this monitoring. This test result is returned by the agent framework to the master framework where it is displayed or offered for display, along with the test results provided by other agent frameworks, if applicable.

From the master framework, the or each agent framework is controllable, by running local test scenarios from the master framework of the associated Agent Framework executable is.

The above-described division of the system into a master framework and one or more agent frameworks has proven to be a good compromise between a purely central, i. only outgoing from a node Software architecture, and a purely decentralized software architecture with equal system components exposed on each node. In particular, this is limited decentralized distribution of Systems the advantages of a central and a decentralized software architecture achieved synergistically, namely a comparatively low installation and synchronization effort, as he for a central architecture is typical, as well as an effective and fast test procedure, as he for a decentralized architecture is typical.

in the The purpose of a further simplified handling of the system is the Runtime environment designed such that the or each test scenario in accordance with a configurable trigger condition either manually or automatically at predetermined time intervals or automatically upon occurrence of a default system state, e.g. on occurrence a specific network error.

For a simplified Cause research with regard to a specific malfunction is Optionally, the or each test scenario, a Problemlösungs- (or Trouble shooting) information assigned or assignable. In this Case, the evaluation unit is expediently designed to display the problem solution information associated with a test scenario, if the execution this test scenario leads to a test error. Alternatively to the direct Display of problem solving information can the display of this information to the user in the event of an error also initially only offered, e.g. by giving the user a dialog box or link is displayed, in which the user can specify whether he is the Troubleshooting Information want to see. Are the test scenarios in a Petri net or activity diagram according to UML2 Form, the assigned problem solving information is preferred Positioned or action-oriented. This is understood to mean that for each point or action of the test scenario a separate Section of Problem Solving Information is deposited. The user is expediently in case of error only the problem solving information is displayed, that is assigned to the job or action of the test scenario, which caused the test error.

In preferred embodiment the system comprises at least one (first) support device, the a malfunction, which can not be eliminated by a user, a solution to eliminate the malfunction examined. The evaluation unit of the diagnostic framework is included trained, in the case of a negative test course the associated test report automatically or on confirmation of a user to send to the first support device. Becomes through the support facility a solution for the elimination of the reported dysfunction found, so transmitted the first support this solution to the diagnostic framework, and thus back to the user. additionally or alternatively, it is provided that the support device the malfunction according to the solution found by her on the way of a remote maintenance independently fixes. The support facility can be an automated, computerized Expert system, a human expert panel or a mix to act on both.

In an advantageous embodiment, the system comprises a multistage support concept, in which, in addition to the first support device, one or more mutually superordinate support devices are provided. Here, if the first or a subordinate support device can not provide a solution for the elimination of a negative test result, respectively, the test result is sent to a higher-level support device, which in turn seeks a solution for the elimination of the malfunction. In this case, the superordinate support device is optionally called by the directly subordinate support device or directly by the evaluation unit. Expediently, the support devices are increasingly centralized in accordance with their hierarchical rank, so that a plurality of subordinate support devices are each assigned to a superordinate support device. This tree-like relational network of the different-ranking support facilities ensures a particularly effective problem management, in the context of which the majority the simple or common malfunction is processed by the comparatively high number of subordinate support facilities, while only more complex problems whose experience has been shown to cost comparatively much experience and time, but experience that occur only in low frequency, reach the specialized for this purpose superordinate support facilities.

fitting becomes an embodiment of the invention explained in more detail with reference to a drawing. Show:

1 a computer network connected to a higher-level network, eg the Internet, with a number of network nodes, with a system for testing the function of the computer network, comprising a diagnostic framework installed on a network node as the master framework and one on each other Network node installed agent framework,

2 in a schematic block diagram according to the diagnostic framework 1 , with a test database with test scenarios stored therein, a runtime environment, an evaluation unit and a test editor,

3 in illustration according to 2 an agent framework according to 1 , with a test database, a runtime environment and an evaluation unit,

4 in the form of an activity diagram according to UML2, an example of a test scenario,

5 in illustration according to 4 another example of a test scenario,

6 in a schematic flowchart a executed by the diagnostic framework method for testing the function of the computer network under execution of a test scenario, and

7 a schematic representation of a global database for the worldwide deposit and provision of test scenarios, as well as the functional interaction of this global database with several computer networks according to 1 ,

each other corresponding parts and sizes are always provided with the same reference numerals in all figures.

In 1 is a computer network 1 shown schematically how it is used in the medical field in a modern clinic. On the computer network 1 It is a so-called PACS, which serves the networked archiving and processing and evaluation of medical image data, such as X-ray images.

The computer network 1 includes as a network node several server computers and client computers. As a server computer includes the computer network 1 in particular a so-called Operations Manager server 2 which provides centralized functions and network services such as Domain Name System (DNS) or Dynamic Host Configuration Protocol (DHCP) across the network.

The Operations Management Server 2 is a data transmission technology with a data management server 3 which provides functions for archiving medical image data. The data management server 3 corresponds to a memory 4 for storing the image and text data. The memory 4 is (in a manner not shown) structured in a short-term memory, an archive memory and a backup memory, the latter is used for redundant backup of image and text data against data loss. The latter can also be realized by an exchangeable storage medium, for example a tape storage.

The Operations Management Server 2 corresponds with a so-called radiology information system 5 (short: RIS). The radiology information system 5 includes in a conventional manner in particular functions for the management of patient master data, for the scheduling of radiological examinations, for the documentation of medical data according to the requirements of the X-ray Ordinance and for the documentation of billing-relevant services. The radiology information system 5 furthermore provides an interface to digital examination equipment (eg a computed tomography scanner or a magnetic resonance tomograph) and supports the creation of radiological findings.

As a client computer includes the computer network 1 a variety of workstations 6 each of which has a network bus 7 with the Operations Management Server 2 Data transmission technology is connected.

The computer network 1 is also via the operations management server 2 Data transmission technology with the Internet 8th connected as a parent network.

To test the function of the computer network 1 and if necessary for a simple and effective error analysis and - elimination is now a system 10 intended. This system includes a network diagnostic framework 11 in the form of a Software on the Operations Management Server 2 is installed. The system 10 continues to include a number of agent frameworks within the network 12 , one of which in each case also in the form of software on each further network node, ie in particular the data management server 3 , the radiology system 5 and every workstation 6 is installed. The diagnostic framework 11 Here is the agent frameworks 12 and controls centrally from the operations management server 2 from their operation. The diagnostic framework 11 In functional terms, it therefore functions as a master framework in the sense of this superordination 13 for the child agent frameworks 12 ,

The system 10 also includes a global database as network external components 14 , on whose - described in detail below content - the diagnostic framework 11 over the internet 8th especially worldwide access. As a further network external component, the system includes 10 at least one, preferably several support devices 15 with which the diagnostic framework 11 also via the internet 8th in data transmission connection.

The inner structure of the diagnostic framework 11 is in 2 shown in more detail.

After that, the diagnostic framework includes 11 in particular a local test database 20 , a test editor 21 , a runtime environment 22 , an evaluation unit 23 and a display unit 24 ,

In the local test database 20 are - local as part of the Operations Management Server 2 - a number of test scenarios T deposited. The or each test scenario T is a software routine that can be used to test one or more functions of the computer network or one or more particular network nodes.

• – Funktionen zum Testen der Datenverbindung zu einem Netzwerkknoten oder zum Testen der Datenübertragungsgeschwindigkeit,
• – Funktionen zum Testen der ordnungsgemäßen Funktion eines Netzwerkknotens oder einer auf diesem installierten Software,
• – Funktionen zum Überprüfen der Installationspfade von Softwarekomponenten und Konfigurationsdateien,
• – Funktionen zur Ermittlung der Version eines in dem Computer-Netzwerk 1 installierten Softwarebestandteils,
• – Funktionen zum Testen verschiedener Hardware- oder Softwarebestandteile oder verschieden versionierter Softwarebestandteile auf Kompatibilität,
• – Funktionen zur Überprüfung von Lizenzen auf Gültigkeit,
• – Funktionen zur Überprüfung des Zustandes des Arbeitsspeichers oder Festspeichers eines Netzwerkknotens,
• – Funktionen zur Überprüfung der Arbeitsgeschwindigkeit eines Softwarebestandteils, etc.

The stored test scenarios T include in particular

• Functions for testing the data connection to a network node or for testing the data transmission speed,
• Functions to test the proper functioning of a network node or software installed on it,
• - functions for checking the installation paths of software components and configuration files,
• - Functions to detect the version of one in the computer network 1 installed software component,
• - Functions for testing different hardware or software components or different versioned software components for compatibility,
• - functions for checking licenses for validity,
• Functions for checking the state of the main memory or permanent memory of a network node,
• - Functions for checking the working speed of a software component, etc.

The local test database 20 is in bidirectional data exchange with the global test database 14 , in which further test scenarios T are stored. In the course of this data exchange, on the one hand, test scenarios T generated by the diagnostic framework 11 needed, but in the local test database 20 are not included from the global test database 14 be downloaded. On the other hand, test scenarios T, which are recreated at the local level, are passed through the diagnostic framework 11 to the global test database 14 uploaded.

To the local test database 20 not overloaded with information and so a quick and easy work with the diagnostic framework 11 to enable is the local test database 20 designed in particular in the manner of a so-called cache memory to buffer the test scenarios T only, for example, for a certain period of time. This has the effect that only the frequently used or last used test scenarios T are stored locally, while rarely or only once used test scenarios T are returned to the local test database after a certain time 20 to be deleted. In another variant of the diagnostic framework 11 can be the local test database 20 also completely omitted. In this case, the components of the diagnostic framework correspond 11 directly with the global test database 14 ,

The test editor 21 supports the creation of new test scenarios T by a user. The test editor 21 in particular provides functions by means of which objects or components of a new test scenario T - hereinafter referred to as action A of the test scenario T (see FIG. 4 and 5 ) - generated and can be linked together in terms of process and data transmission technology. The test editor 21 allows in particular, test scenarios T, in one of the databases 14 or 20 are deposited as action A of a new, higher-level test scenario T use. The test editor 21 To do this, access the local database 20 as well as on the global database 14 to (relationship 25 ). In return, the test editor offers 21 the ability to create newly created test scenarios in the local test database 20 to dismiss (relationship 26 ).

For execution, those in the test databases 20 and 14 stored test scenarios of the runtime environment 23 be fed (relationship 27 ). The execution of the or each test scenario T is doing it (according to relationship 28 ) monitored by the evaluation unit 23 , which collects output values of the respectively executed test scenario T, analyzes and uses this information to create a test report R, in particular in an XML format. The test reports are R (according to relationship 29 ) from the evaluation unit 23 a report database 30 for archiving. The evaluation unit 23 also notes changes made in the context of the diagnostic framework 11 on the configuration of the computer network 1 be made. The processor performs these changes in the report database 30 deposited history archive, by means of which the configuration of the computer network 1 changes made at a later date.

• – in Zusammenwirkung mit dem Testeditor 21 ein im Rahmen des Testeditors 21 zu erstellendes Testszenario T anzuzeigen und Steuerbefehle eines Benutzers zur Erstellung oder Sicherung des erstellten Testszenarios T an diesen zu übertragen (Beziehung 32),
• – in Zusammenwirkung mit der Laufzeitumgebung 22 ein Testszenario aus einer der Datenbanken 20 oder 14 zur Ausführung auszuwählen und sonstige Steuerbefehle zu der Ausführung des Testszenarios T an die Laufzeitumgebung 22 zu übertragen (Beziehung 33),
• – in Zusammenwirkung mit der Auswerteeinheit 23 den von Letzterer erstellten Testbericht R anzuzeigen (Beziehung 33). Die Anzeigeeinheit 24 ist gleichermaßen geeignet, auch die in dem Berichtspeicher 30 archivierten Testberichte R zu laden und anzuzeigen (Beziehung 34).

To interact with a user act the test editor 21 , the runtime environment 22 and the evaluation unit 23 with the display unit 24 together, the one on a screen 31 displayable graphical user interface (GUI) provides. The display unit 24 is specially designed to

• - in cooperation with the test editor 21 one as part of the test editor 21 To display test scenario to create T and control commands issued by a user to create or save the created test scenario T to this (relationship 32 )
• - in cooperation with the runtime environment 22 a test scenario from one of the databases 20 or 14 to select for execution and other control commands for the execution of the test scenario T to the runtime environment 22 to transfer (relationship 33 )
• - in cooperation with the evaluation unit 23 to display the test report R created by the latter (Relationship 33 ). The display unit 24 is equally suitable, even in the repository 30 archived test reports R to load and display (relationship 34 ).

The test editor 21 , the runtime environment 22 , the evaluation unit 23 and the display unit 24 can be implemented in separate software modules as shown. However, one or more of the associated functionalities can also be combined in a common software tool.

The runtime environment 22 is optionally in a real mode and a simulation mode 34 operated. In real mode, this is done within the runtime environment 22 executed test scenario T on the real network nodes of the computer network 1 and their real parameter settings applied. Changes to the parameter settings affect the real configuration of the computer network 1 ,

In contrast, in the simulation mode 34 a copy K of the configuration parameters of the computer network 1 , or at least a relevant selection of these configuration parameters, created, and that in the simulation mode 34 executed test scenario T applied to this copy K. The copy K of the configuration parameter is in one of the runtime environment 22 coordinated simulation database 35 temporarily stored and from this simulation database 35 provided (relationship 36 ) as long as the runtime environment 22 in the simulation mode 34 is operated. The creation of the copy K and the application of the executed test scenarios T on this copy K has the advantage that changes to the parameter configuration of the computer network 1 in simulation mode 34 can be safely tested. An accidental misconfiguration of the computer network 1 can due to the only temporary storage of the copy K by exiting the simulation mode 34 simply discarded without the original parameter configuration and thus the integrity of the computer network 1 to endanger. On the other hand, introduces in simulation mode 34 performed test scenario T to a positive result in terms of a changed in the copy K parameter configuration, so the copy K on appropriate confirmation of the user when leaving the simulation mode 34 instead of the original parameter configuration of the computer network 1 be taken over.

Each of the agent frameworks 12 is - like out 3 recognizable - a "slimmed down" version of the diagnostic framework 11 with respect to this reduced functionality. Every gent framework 12 includes - like the diagnostic framework 11 - a local test database 20 ' , which is intended to store local test scenarios T. The local test scenarios T test the function of the respectively associated network node. Each agent framework 12 also includes a runtime environment 22 ' and an evaluation unit 23 ' , The runtime environment 22 ' and the evaluation unit 23 ' essentially correspond to the corresponding components of the diagnostic framework 11 and are too (according to the relationships 27 and 28 in basically the same way with each other and with the local test database 20 ' - interconnected. In particular, the runtime environment is also 22 ' in the simulation mode 34 operable and acts with a corresponding simulation database 35 ' together.

The diagnostic framework 11 and each of the agent frameworks 12 correspond via a (respectively master and agent side provided) data interface 37 respectively. 37 ' together. About this Da tenschnittstelle 37 . 37 ' especially in the test editor 21 new test scenarios T for an agent framework 12 created and in the local test database 20 ' of the agent framework 12 be deposited (relationship 38 ). Similarly, based on the runtime environment 22 the execution of a test scenario T within the runtime environment 22 ' be controlled (relationship 39 ). In particular, this can be one within the runtime environment 22 running test scenario T the execution of a local test scenario T in the runtime environment 22 ' trigger. The one from the evaluation unit 23 ' On the other hand, created test report R is via the data interface 37 ' . 37 to the evaluation unit 23 reported back (relationship 40 ) and there - if necessary, with the test reports R of other agent frameworks 12 combined - via the display unit 24 displayed and / or in the report memory 30 archived.

Each of the test scenarios T is in the test databases 20 . 20 ' and 14 stored in a form corresponding to an activity diagram according to UML2. A simple example of such a representation of a test scenario T is in 4 displayed.

The test scenario T shown here (referred to below as the test scenario T1) comprises two actions A, which are designated below as A1 or A2 for the purpose of further distinguishing. The actions A1 and A2 are between a so-called start node 41 that marks a starting point for the execution of test scenario T1 and a stop node 42 , which marks the end of the program, arranged. The actions A and Nodes 41 . 42 are by directed edges 43 which determine the processing order within test scenario T1. The concurrent program threads of test scenario T1 are identified by the synchronization bar 44 summarized.

Each action A contains a self-contained program part, which - as exemplified by the example of the action A1 - can again be a separate test scenario T. For example, the action A1 contains according to 4 this in 5 illustrated test scenario T2.

each Action A is designed to at least after completion to return an output value, indicating whether the action was successful or an execution error occurred is. For example, each action returns A in case they succeed accomplished was returned, the value zero, while it returns an error code in case of error.

The output value is determined by the edge or edges originating from action A. 43 to the or each subsequent action A or the or each subsequent synchronization bar 44 transfer. Every edge 43 is a deviating execution rule assignable E, with the behavior of this edge 43 modifiable over the standard behavior. For example, the edge connecting the action A1 with the action A2 43 configured by assigning the execution rule E so that it activates the action A2 only if the along the edge 43 passed output value indicates a successful execution of the action A1, that is, for example, has the value zero. As a result, the action A2 is activated only if previously the action A1 was successfully completed.

The synchronization bar 44 by default it waits until every incoming edge 43 an input value is present, and in this case gives a corresponding output value over one or more edges 43 to one or more subsequent actions A or node, in the present case to the stop node 42 out. Also the synchronization bar 44 but can be modified by an execution rule E. For example, the in 4 illustrated synchronization bar 44 modified by execution rule E such that it is ready to be switched when either at each incoming edge 43 an initial value indicating the successful execution of the preceding action A, or if at least one incoming edge 43 an error signal is present.

The execution of in 4 test scenarios T1 thus begins in the start node 41 that activates action A1. After execution of the action A1, output values are output via the edges 43 at the synchronization bar 44 and - if the action A1 was successfully performed - passed to the action A2, which in turn is thereby activated. After the execution of the action A2, its output value is also transmitted via the outgoing edge 43 at the synchronization bar 44 which, when both actions A1 and A2 have been carried out successfully or as soon as an error signal has been transmitted by action A1 or action A2, switches and sends a corresponding output value to the stop node 42 which completes the execution of test scenario T1.

This in 5 illustrated test scenario T2, which - as mentioned above - the action A1 of the test scenario T1 forms, in turn, seven actions A3 to A9, which in turn can each stand again for a test scenario T. The execution of test scenario T2, and thus action A1, again starts in the start node 41 activating the actions A3 and A4. The output value of these actions A3 and A4 is then the following synchronization bar 44 to hand over. Its outgoing edges 43 is assigned an execution rule E, depending on which in dependent ability of the synchronization bar 44 value of one of the actions A5, A6 or A7 is activated. For example, action A6 is activated when the output value of the synchronization bar 44 is greater than or equal to 0.9, while action A7 is activated when the output value of the synchronization bar is less than 0.9. Contains the output value of the synchronization bar 44 on the other hand an error code, the action A5 is activated. Action A6 activates a downstream decision field 45 , which compares the output value of the action A6 with a stored condition and activates one of the actions A8 and A9 according to the result of the comparison ("true" or "false").

The display unit 24 is now designed such that it the stored test scenarios T in graphical form as an activity diagram according to UML2, ie in a representation analog 4 or 5 can show. The display unit 24 acts in this way with the test editor 21 such that new test scenarios T from a user by generating graphical action icons and by graphically connecting these action icons with the edges 43 can be created using drag-and-drop methods. The evaluation unit 23 in turn acts with the display unit 24 together that the successive processing of a test scenario is graphically represented. In particular, it is provided that a test scenario T during execution in the runtime environment 22 on the screen 31 A actions that have already been successfully executed, actions A that have caused an error, and actions A that have not yet been executed, are color-coded (for example, green for A actions performed successfully, red for A actions performed incorrectly) and yellow for unexecuted actions A). The evaluation unit 23 is further adapted, in the event of an error to an action A2, which has caused an error, the associated test report R with a description of the error in the form of text information on the display unit 24 display. In addition, each test scenario T, and in particular action-resolved, of each action A of a test scenario T is assigned problem-solving information (trouble shooting information) which is output by the evaluation unit 23 in case of error always or on request of the user with the error description is displayed, and provides the user with information for troubleshooting.

The system suspends malfunctions that the user can not remedy on the basis of the test report R and, if necessary, the problem solving information 10 a support concept with several hierarchically staggered support facilities 15 to disposal.

• – eine manuelle Auslösung durch einen Benutzer,
• – eine Auslösung durch Ablauf eines Zeitintervalls, z.B. zwei Wochen nach der Installation einer Softwarekomponente oder turnusmäßig in regelmäßigen Zeitabständen,
• – eine Auslösung durch den Eintritt eines bestimmten Netzwerkstatus, z.B. dem Ausfall eines Geräts oder einer Datenübertragungsverbindung, ein bestimmter Auslastungsgrad eines Speichers etc. – in diesem Fall werden ein oder mehrere Testszenarien beispielsweise von einer entsprechenden Status- oder Fehlermeldung des Computernetzwerkes 1 angestoßen.

In 6 is the expiration of one with the system 10 carried out test procedure with the involvement of these support facilities 15 shown schematically. Thereafter, the method according to step 50 triggered by a predetermined trigger condition C. The system 10 provides various variants for defining the triggering condition C, in particular

• A manual triggering by a user,
• Triggering by expiration of a time interval, eg two weeks after the installation of a software component or regularly at regular intervals,
• A triggering by the entry of a specific network status, for example the failure of a device or a data transmission connection, a certain degree of utilization of a memory, etc. In this case, one or more test scenarios become, for example, a corresponding status or error message of the computer network 1 initiated.

After the procedure has been started by the occurrence of the trigger condition C (step 51 ), in step 52 through the diagnostic framework 11 , possibly in conjunction with one or more of the agent frameworks 12 , one or more test scenarios T performed for this purpose from one of the test databases 20 . 14 . 20 ' in the runtime environment 22 . 22 ' getting charged. After completion of this actual diagnostic step by the evaluation unit 23 in step 53 Determines whether the diagnosis has been successfully completed. If this is the case, the procedure is terminated (step 54 ).

Otherwise, the evaluation unit creates 23 on the test report R in the form of an XML text, and first displays this test report R together with the relevant problem-solving information to the user (step 55 ). If the user can not solve the problem himself using this information, then the user's approval test report will become a first of three staggered support facilities 15 (see. 1 ) (step 56 ), which in turn seeks a solution to the problem (step 57 ). Find the first support device 15 a solution, it eliminates the error within the computer network by means of remote maintenance 1 (Step 58 ), whereupon the diagnostic procedure is restarted to check if the error is actually eliminated. Find the first support device 15 however, no solution, so it passes the test report R in step 58 to a parent, second support device 15 who, in turn, seeks to find a solution to the error (step 59 ). Find the second support device 15 a solution, it proceeds according to step 58 , Otherwise, it will forward the test report R to a higher-level third-party support facility 15 continue (step 60 ), in step 61 developed a solution for troubleshooting and the problem according to step 58 fixes.

The support facilities 15 are staggered in the manner of a tree structure. So is the third support facility 15 in particular arranged on the manufacturer side and corresponds to a plurality of directly subordinate second-level support devices, each of which in turn having a plurality of support devices 15 first rank corresponds.

In 7 is the interaction of multiple local computer networks 1 according to 1 with the global test database 14 shown in more detail. Every computer network 1 is limited to, for example, the area of a hospital, being within each computer network 1 a diagnostic framework 11 - and possibly one or more agent frameworks 12 - are installed. Every computer network 1 refers to test scenarios T from the global test database 14 and supplies test scenarios T, which are part of the respective computer network 1 be recreated to the global test database 14 back. This ensures an effective distribution of test scenarios for testing common network functions and locating known sources of errors. The part of any computer network 1 however, test reports R become network-local in the report database associated with each diagnostic framework 30 archived.

To effectively search for suitable test scenarios T in the global test database 14 to allow each test scenario T meta-information is assigned, which specifies the scope of the respective test scenario T according to several criteria. In particular, the meta-information associated with a test scenario T contains information about which component (eg server, printer, network, etc.) and which network node (eg operation management server, data management server, workstation, etc.) of the computer network 1 the test scenario T is assigned for which problem to be tested (connection test, license test, path control, etc.) the test scenario is designed and for which application version the test scenario is designed. The global test database 14 provides a search form in which suitable test scenarios T can be selected by specifying the above criteria.

Claims (13)

System ( 10 ) for testing the function of a computer network ( 1 ), with a test database ( 14 . 20 ), in which a number of test scenarios (T) can be stored or stored, and a diagnostic framework ( 11 ), comprising - a runtime environment ( 22 ) on which the or each test scenario (T) is executable, - an evaluation unit ( 23 ) that monitors the execution of the or each test scenario (T) and generates a test report (R) for display to a user, and - a test editor ( 21 ), by means of which for execution on the runtime environment ( 22 ) suitable test scenarios (T) can be created. System ( 10 ) according to claim 1, wherein the or each test scenario (T) is deposited in a form corresponding to a Petri net or an activity diagram according to the UML2 standard. System ( 10 ) according to claim 2, comprising a display unit ( 24 ) designed to graph the or each test scenario (T) in the form of a Petri net or an activity diagram according to the UML2 standard. System ( 10 ) according to claim 3, wherein the test editor ( 21 ) with the display unit ( 24 ) cooperates to form the or each test scenario (T) graphically in the form of a Petri net or an activity diagram according to the UML2 standard. System ( 10 ) according to claim 3 or 4, wherein the evaluation unit ( 23 ) with the display unit ( 24 ) cooperates in such a way that the test report (R) can be represented on the basis of the graphical representation of the or each test scenario (T), whereby any test errors are presented in a position-resolved or action-resolved manner. System ( 10 ) according to one of claims 1 to 5, wherein the runtime environment ( 22 ) in a simulation mode ( 34 ) is operable in the parameter of the computer network ( 1 ) are only temporarily changed. System ( 10 ) according to claim 6, wherein in the simulation mode ( 34 ) one or more network nodes ( 2 . 3 . 5 . 6 ) of the computer network ( 1 ) are virtually generated. System ( 10 ) according to one of claims 1 to 7, wherein a test database is a network-external, globally accessible test database ( 14 ), from the test scenarios (T) into the diagnostic framework ( 11 ) are downloadable. System ( 10 ) according to one of claims 1 to 8, wherein a test scenario (T, T1) can contain one or more further test scenarios (T, T2) as constituents. System ( 10 ) according to one of claims 1 to 9, with a diagnostic framework ( 11 ) as a master framework ( 13 ) as well as with at least one Agent framework ( 12 ), comprising - a runtime environment ( 22 ' ), on which at least one test scenario (T) relevant locally for a network node is executable, - an evaluation unit ( 23 ' ), which is adapted to monitor the execution of the or each local test scenario (T) and a test report (R) for transmission to the master framework ( 13 ), the master framework ( 13 ) on a network node ( 2 ) of the computer network ( 1 ), and an agent framework ( 12 ) on at least one further network node ( 3 . 5 . 6 ) of the computer network ( 1 ) is installed or installable, and where by the master framework ( 13 ) from the or each local test scenario (T) within the associated agent framework ( 12 ) is executable. System ( 10 ) according to one of claims 1 to 10, wherein the or each test scenario (T) is assigned or assignable a problem solution information, and wherein the evaluation unit ( 23 ) is adapted, in the case of a negative test result, to display the associated problem-solving information or to offer it for display. System ( 10 ) according to one of claims 1 to 11, wherein the evaluation unit ( 23 ) is adapted, in the case of a negative test result, automatically or upon confirmation of a user, to send the test report (R) to a first support device ( 15 ) to send. System ( 10 ) according to claim 12, comprising a plurality of hierarchically staggered support devices ( 15 ), whereby the evaluation unit ( 23 ) or the first or a subordinate support device ( 15 ) are adapted, automatically or on confirmation of a user out the test report (R) to a parent support device ( 15 ) when the first or subordinate support device ( 15 ) can not provide a solution to fix the negative test result.