DE102006032108A1

DE102006032108A1 - System und Verfahren für eine Mehr-Ort-Testausführung

Info

Publication number: DE102006032108A1
Application number: DE102006032108A
Authority: DE
Inventors: Abhay Loveland Sathe; Thomas G. Loveland Bartz; Nimal Loveland Gamage; David E. Loveland Bingham; Carolyn Loveland Darbie; Stephen C. Loveland Booth
Original assignee: Agilent Technologies Inc
Current assignee: Viavi Solutions Inc
Priority date: 2005-08-03
Filing date: 2006-07-11
Publication date: 2007-02-15
Anticipated expiration: 2026-07-12
Also published as: US20070033441A1; US7437275B2; DE102006032108B4

Abstract

Verfahren, Systeme und Computerprogrammprodukte zum Ausführen einer Mehr-Ort-Ausführung von Tests zwischen oder unter mehrseitigen Testkomponenten in einer drahtlosen Umgebung sind beschrieben. Mehrere Flüsse werden im Wesentlichen gleichzeitig initiiert und gleichzeitig ablaufend ausgeführt. Eine graphische Darstellung eines Mehr-Fluss-Tests wird erzeugt, die eine Synchronisation der Flüsse zwischen Agenten an mehreren entfernten Orten ermöglicht. Die graphische Darstellung wird in eine Textdarstellung in einem Format eines offenen Kommunikationsstandards umgewandelt, und Informationen im Hinblick auf jeden Fluss, der in dem Test umfasst ist, werden ermittelt. Die Flüsse werden im Wesentlichen gleichzeitig initiiert und gleichzeitig ablaufend mit Synchronisations- und Dynamische-Daten-Austauschkomponenten ausgeführt.

Description

Querverweis auf verwandte Anmeldungen
Diese Anmeldung ist eine Teilfortsetzung von und beansprucht den Vorteil von der Priorität an der U.S.-Patentanmeldung Serien-Nr. 11/195,978, eingereicht am 03. August 2005 mit dem Titel „Multisided Synchronization of Execution in a Wireless Test Environment" (Mehrseitige Synchronisation einer Ausführung in einer drahtlosen Testumgebung), und Serien-Nr. 11/195,979, eingereicht am 03. August 2005 unter dem Titel "Multisided Sharing of Dynamic Data in a Wireless Test Environment" (Mehrseitiges, gemeinschaftliches Verwenden von dynamischen Daten in einer drahtlosen Testumgebung), deren Inhalte hierin durch Bezugnahme aufgenommen sind.
Beschreibung
Die vorliegende Erfindung bezieht sich auf ein Verfahren, ein System und ein Computerprogrammprodukt für ein komponentenbezogenes Mehr-Ort-Softwaretesten, und insbesondere auf eine Vorrichtung, ein System und ein Verfahren zum Synchronisieren und Verwalten dynamischer Daten zwischen mehrseitigen Testflüssen von Komponenten an entfernten Orten, die üblicherweise separate Teilnehmer oder Klienten in einer Transaktion, einer Konversation oder einer gemeinsamen Sitzung darstellen, die durch einen Kommunikationsdienst angeboten wird.

Der Ausdruck „Testsoftware" wird verwendet, um ein Softwareprodukt zu beschreiben, dessen primäre Funktion es ist, zu untersuchen, wie ein System funktioniert. Die Testsoftware sammelt ihre Eingabe von Agenten, die individuelle Bauglieder eines Systems sind, das getestet wird.

Einige Beispiele, wo eine Testsoftware eingesetzt wird, umfassen mobile oder drahtlose Telefonnetzwerke und andere Typen von Telekommunikations-Netzwerken oder -Systemen, Flusswasserqualitätsüberwachungseinrichtungen und Automobilverhaltentestsysteme. Netzwerke oder Systeme sind häufig geographisch und/oder zeitlich verteilt. Die Testsoftware für solche Systeme muss Daten aus unterschiedlichen Orten oder zu unterschiedlichen Zeiten sammeln, um ein solches System zu testen.

Trotz der vielen Fortschritte, die auf dem Gebiet des Testens drahtloser Netzwerke gemacht wurden, bestehen weiterhin bestimmte Probleme. Diese Probleme umfassen eine Unfähigkeit, die Ausführung von Testflüssen zwischen oder unter Flüssen oder Seiten auf offene Weise zu synchronisieren, die allgemeine Standards einsetzt, eine Unfähigkeit, eine Ausführung zwischen Flüssen zu synchronisieren (oder virtuellen Teilprozessen bzw. Threads einer Ausführung), außer wenn eine proprietäre Schnittstelle verwendet wird, und eine Unfähigkeit, drahtlose Dienste zu testen, die von Ausführungsreihenfolgen zwischen Flüssen abhängen, außer eine proprietäre Schnittstelle ist in der Systemarchitektur umfasst.

Test- und Mess-Softwareprodukte, wie z. B. der OSS Wireless QOS Manager (WQM) von Agilent werden zum Testen drahtloser (mobil/zellulär/WiFi) Kommunikationsnetzwerke und die Anwendungen, die die Netzwerke den Benutzern solcher Netzwerke bieten, verwendet. Beispiele solcher Anwendungen sind: 1) Senden und Empfangen von Kurzmitteilungen (SMS), was einen Meldungs-„Sender" und einen Meldungs-„Empfänger" umfasst, die irgendwo in der Welt sein können; und 2) eine „Sprech"-Anwendung (Push-to-talk), die einen „Sender" umfasst (eine drahtlose Vorrichtung), die zum Senden einer Stimm-Meldung zu einer Gruppe von „Zuhörern" verwendet wird. Die Zuhörer sind eine Gruppe von drahtlosen Vorrichtungen, die registriert sind, um der Meldung zuzuhören, die die Meldung oder eine Benachrichtigung über die Meldung in einer Form empfangen (einer Kurzmitteilung oder einer E-Mail). Die nachfolgende Veröffentlichung und Patentanmeldung, die hierin jeweils durch Bezugnahme in ihrer entsprechenden Gesamtheit aufgenommen sind, umfassen verschiedene Lehren gemäß dem Stand der Technik im Hinblick auf WQMs:
Agilent Technologies, Inc., Information Sheet mit dem Titel „Agilent QSS QoS Manager", zu sehen unter http://we.home.agilent.com/cgi-bin/bvpub/agilent/Product/cp Product.jsp?OID=536882909&NAV ID=-536885380.536882909.00&LANGUAGE CODE=eng&COUNTRY CODE=ZZ&CT=PRODUCT&JPID=/comms/firehunter
U.S.-Patentanmeldung Seriennummer 10/736,835 mit dem Titel „Sequential Coordination of Test Execution and Dynamic Data" an Bingham.

Das Testen von heterogenen (Mehr-Netzwerk- und Mehr-Protokoll-) Anwendungen wird erreicht durch Ausführen vieler Testsoftwareprogramme, gleichzeitig, an entfernten Orten. Jedes der gleichzeitig ablaufenden Softwareprogramme testet einen Aspekt der drahtlosen Anwendung, die getestet wird. Zum Beispiel wird bei der „Push-to-Talk"-Anwendung, die oben beschrieben wurde, ein Softwaretestprogramm verwendet, um die Meldung zu senden und unterschiedliche Qualitätsaspekte der drahtlosen Anwendungen zu messen, die ersichtlich sind, wenn die Meldung gesendet wird. Auf der Empfängerseite werden viele Testprogramme, die an unterschiedlichen Orten angeordnet sind, eingesetzt, um die Meldung zu empfangen, und die Qualitätsaspekte des drahtlosen Netzwerks beim Empfangen der Meldung zu messen. Bezug nehmend auf 1 ermöglicht WQM die Erzeugung von Softwaretestprogrammen mit Komponenten, die in Sequenz laufen. Diese Sequenzen aus Softwaretestkomponenten können an jeglichem entfernten Ort unter Verwendung von Steuerprogrammen betrieben werden, die „Agenten" genannt werden. Früher haben Agenten keine Fähigkeit bereitgestellt, mehrere Sequen zen gleichzeitig zu betreiben, oder die Fähigkeit, solche Sequenzen zu synchronisieren.

Existierende Testsysteme, die in der Lage sind, solche Softwaretests gleichzeitig ablaufend zu betreiben, hängen von einer proprietären Software ab, die in einer speziell erzeugten Sprache geschrieben ist. Einige Systeme verwenden proprietäre Protokolle, die auf Offener-Standard-Protokollen aufgebaut sind. Solange die Implementierungsdetails (z. B. spezialisierte Software-„Bibliothek" für Gleichzeitigkeit und Synchronisation) solcher Protokolle nicht frei verfügbar sind, können solche Protokolle nicht als plattform-unabhängig oder als solche mit mehreren Teilprozessen betrachtet werden. Bei Systemen, die eine zentralisierte Implementierung aufweisen, kann ein einzelner Ausfallpunkt, d. h. Ausfall einer einzelnen Komponente, verursachen, dass das gesamte Testsystem zu funktionieren aufhört.

Somit besteht ein Bedarf nach einem drahtlosen QOS-Testsystemverwalter, der nicht von proprietärer Hardware abhängig ist und Offene-Software-Protokolle verwendet, um eine Gleichzeitigkeit und Synchronisation zu erreichen.

Wie Fachleute auf dem Gebiet erkennen werden, nachdem sie die nachfolgende, nicht einschränkende Beschreibung gelesen und verstanden haben, können zumindest einige der Systeme, Verfahren und Computerprogrammprodukte, die offenbart werden, vorteilhaft gemäß den Lehren der vorliegenden Erfindung modifiziert werden.

Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zum Ausführen eines Mehr-Positions-Testens und ein prozessorlesbares Computerprogrammprodukt mit verbesserten Charakteristika zu schaffen.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1, ein System gemäß Anspruch 8 und ein prozessorlesbares Computerprogrammprodukt gemäß Anspruch 15 gelöst.

Verfahren, Systeme und Computerprogrammprodukte, die eine Mehr-Ort-Ausführung von mehrseitigen Tests zwischen oder unter mehrseitigen Testkomponenten bilden, die in einer Kommunikations- oder Test-Umgebung testen, mit zumindest einem ersten Fluss an einem ersten entfernten Ort und einem zweiten Fluss an einem zweiten entfernten Ort, wie z. B. einer drahtlosen Telekommunikationsumgebung, sind offenbart. Die mehreren, entfernten Flüsse in einem System, wie z. B. einer drahtlosen Testkonfiguration, werden im Wesentlichen gleichzeitig initiiert. Eine graphische Darstellung wird von einem Mehr-Fluss-Test erzeugt, die die mehreren Flüsse zwischen Agenten an mehreren entfernten Orten synchronisiert, die dann in eine Text-Darstellung in einem Format eines offenen Kommunikationsstandards umgewandelt wird. Die Textdarstellung wird gelesen, um die Flüsse und ihre zugeordneten Orte, die Ressourcen, die zum Ausführen der Flüsse erforderlich sind, und die entfernten Orte der Agenten, die die Ressourcen steuern, die zum Ausführen der Flüsse erforderlich sind, zu identifizieren. Eine Teststeuerung sendet, zu Testsitzungsservern, die bei einem bevorzugten Ausführungsbeispiel Java-Servlets umfassen, an den entsprechenden Orten, Beschreibungen der Testsequenzen, die die entsprechenden Flüsse aufweisen, in einem Format eines offenen Kommunikationsstandards, und initiiert, synchronisiert und bringt Testergebnisse zurück, im Wesentlichen gleichzeitig, die aus der gleichzeitigen Ausführung der mehreren Flüsse hergeleitet sind.

Bei einem Ausführungsbeispiel wird eine Synchronisation erreicht durch Senden von Steuermeldungen zwischen oder unter mehrseitigen Testkomponenten, die die Flüsse aufweisen, die erlauben, dass die Flüsse implizit Zeitgebungssynchronisationsinformationen und dynamisch erzeugte Daten austauschen. Zum Beispiel wird bei einem Verfahren die Ausführung bei zumindest einem der Flüsse unterbrochen. Von dem Fluss, der nicht unterbrochen ist, wird ein Synchronisationssignal zu einem Sync-Server in der Teststeuerung gesendet. Der un terbrochene Fluss fordert und erwartet eine Erlaubnis von dem Sync-Server, um den Fluss wieder aufzunehmen. Der unterbrochene Fluss wird nach dem Empfangen eines Synchronisationssignals von dem Sync-Server wieder aufgenommen.

Bei einem anderen Ausführungsbeispiel werden dynamisch erzeugte Daten gemeinschaftlich verwendet oder übertragen zwischen oder unter Agenten, die Dynamischer-Dateninhalt-Server verwenden, die offene Kommunikationsstandards oder Protokolle einsetzen, wie z. B. HTTP oder HTTPS. Die vorliegende Erfindung umfasst innerhalb ihres Schutzbereichs die Verfahren zum gemeinschaftlichen Verwenden oder Übertragen dynamisch erzeugter Daten, die oben und unten beschrieben sind, sowie Systeme und Testagenten, die in der Lage sind, solche Verfahren auszuführen. Dynamische Daten werden gemeinschaftlich verwendet oder übertragen zwischen oder unter mehrseitigen Testkomponenten in einer drahtlosen Umgebung mit zumindest einem ersten Fluss auf einer ersten Seite und einem zweiten Fluss auf einer zweiten Seite. Das Verfahren weist das Erzeugen dynamischer Daten in zumindest entweder dem ersten Fluss oder dem zweiten Fluss; das Absenden der dynamischen Daten zu einem Dynamischer-Inhalt-Server, um abgeschickte dynamische Daten zu erzeugen, unter Verwendung von zumindest einem offenen, allgemeinen Kommunikationsstandard; das Anfordern der abgeschickten, dynamischen Daten von zumindest entweder dem ersten Fluss oder dem zweiten Fluss zu dem Dynamischer-Inhalt-Server; das Senden der abgeschickten, dynamischen Daten zu dem Fluss, der die abgeschickten, dynamischen Daten anfordert, von dem Dynamischer-Inhalt-Server, auf. Die abgeschickten, dynamischen Daten, die in dem Dynamischer-Inhalt-Server gespeichert sind, können „Enter"- (Eingabe-), „Get"- (Erhalten-), „Remove"- (Entfernen-) und/oder „Replace"- (Ersetzen-) Anweisungen unterzogen werden, die mit Hilfe des zuvor erwähnten, offenen, allgemeinen Kommunikationsstandards bewirkt werden.

Bei einem bevorzugten Ausführungsbeispiel wird eine oder mehrere Verhaltensmaßnahmen eines zu testenden Dienstes aus den Mehr-Ort-Testergebnissen erzeugt.

Verschiedene Ausführungsbeispiele der vorliegenden Erfindung können durch einen oder mehrere der nachfolgenden Aspekte gekennzeichnet sein:

(a) Software, die ausführbar ist, um die Verfahren gemäß der Erfindung auszuführen, erfordert nicht das Zuordnen spezieller Hardware vor einer Testausführung, d. h. ist in der Lage, getrennt von der Schelf-Software zu laufen;
(b) Eine solche Software ist locker gekoppelt, was bedeutet, dass jedes Teil des Softwaresystems von unterschiedlichen Softwaresystemen geliefert werden kann;
(c) Systeme gemäß der Erfindung können in verschiedenen Sprachen geschrieben sein, auf offenen, allgemeinen Kommunikationsstandardprotokollen aufgebaut sein, wie z. B. HTTP, HTTPS, FTP und Webservern, um eine separate Testausführung und gemeinschaftliche Datenverwendung zwischen oder unter Flüssen (oder virtuellen Teilprozessen einer Ausführung) und/oder zwischen mehreren Drittparteianwendungen zu synchronisieren und können auf heterogenen Betriebssystemen laufen;
(d) Softwareelemente der erfindungsgemäßen Systeme können irgendwo im Internet angeordnet sein und können ohne weiteres angepasst werden, um Sicherheit, Zuverlässigkeit und die Fähigkeit zum Skalieren zu liefern, um eine große Anzahl von gleichzeitig ablaufenden, synchronisierten Softwareprogrammen zu handhaben;
(e) Ressourcen-Zuordnung kann vor dem Planen von Tests ausgeführt werden, ist aber optional;
(f) Die Mehrfach-Teilprozess-Fähigkeiten von Hostbetriebssystemen werden verwendet, um eine dynamische, gemeinschaftliche Verwendung von Daten zwischen Testflüssen zu ermöglichen, sogar während eine Testfunktion möglicherweise blockiert ist, die andere Aufgaben ausführt oder auf diese Informationen wartet;
(g) Eine Synchronisation oder ein Austausch dynamischer Daten zwischen oder unter mehreren Flüssen bei einem drahtlosen Diensttest ist zulässig, sogar wenn eine proprietäre Schnittstelle nicht in dem System eingesetzt wird, das getestet wird;
(h) Dynamische Daten können sicher übertragen oder gemeinschaftlich verwendet werden, unter Verwendung eines HTTPS-Protokolls;
(i) Zeitbegrenzungen können nach Bedarf konfiguriert sein;
(j) Der Ort eines Sync-Servers kann verändert werden, was nützlich ist für Konfigurationen mit Firewalls;
(k) Sync-Server können auf jeglichem Wireless-QOS-Agenten (wirelsess = drahtlos) oder auf jeglichem Web-Servern betrieben werden, der Server unterstützt;
(l) Wenn ein Synchronisationsereignis über eine konfigurierbare Zeit hinaus gelebt hat, wird es automatisch gelöscht.
(m) Zentralisieren von dynamischem Inhalt, was ermöglicht, dass alle Flüsse auf dynamische Daten zugreifen, immer wenn es von einem bestimmten Fluss gefordert wird;
(n) Ändern des Orts von einem oder mehreren Dynamischer-Inhalt-Server, was besonders nützlich für Konfigurationen mit Firewalls ist;
(o) Betreiben Dynamischer-Inhalt-Server auf jeglichem Wireless-QOS-Agenten oder auf jeglichem Web-Server;
(p) automatisches Löschen abgeschickter, dynamischer Daten, die über eine konfigurierbare Zeit hinaus gelebt haben; und
(q) Mehrere Tests, die auf spezifische, dynamische Daten gleichzeitig zugreifen, zeitbasiert auf einer eindeutigen Identifikation, die für jeden angeforderten Test bereitgestellt ist.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
1 eine graphische Darstellung von zwei Testsequenzen, die an entfernten Orten laufen, erzeugt durch ein existierendes WQM-System;
2 ein Blockdiagramm eines Testsystems gemäß der vorliegenden Erfindung;
3 ein Blockdiagramm, das eine herkömmliche Beziehung zwischen einem Klienten, einem Web-Server und einem Testsitzungsserver gemäß dem Stand der Technik darstellt;
4 ein Flussdiagramm, das ein Ausführungsbeispiel eines Verfahrens zum Ausführen eines Mehr-Ort-Testens gemäß der vorliegenden Erfindung darstellt;
5 eine graphische Darstellung eines Einzelsoftwaretests gemäß dem Stand der Technik;
6 eine graphische Darstellung einer Sequenz aus Softwaretests gemäß dem Stand der Technik;
7 eine graphische Darstellung einer Sequenz eines Mehr-Fluss-Tests gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
8 eine andere graphische Darstellung eines zweiseitigen Mehr-Fluss-Tests gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
9 eine graphische Darstellung eines Mehr-Fluss-Tests gemäß einem Ausführungsbeispiel der vorliegenden Erfindung, die eine Synchronisation zwischen Flüssen darstellt;
10 ein Blockdiagramm, das einen Abschnitt eines Systems darstellt, das eine Synchronisation gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausführt;
11 ein anderes Blockdiagramm, das einen Abschnitt eines Systems darstellt, das eine Synchronisation gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausführt;
12 ein wiederum anderes Blockdiagramm, das einen Abschnitt eines Systems darstellt, das eine Synchronisation gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausführt;
13 ein Blockdiagramm, das einen Abschnitt eines Systems darstellt, das einen Austausch dynamischer Daten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausführt;
14 ein anderes Blockdiagramm, das einen Abschnitt eines Systems darstellt, das einen Austausch dynamischer Daten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausführt; und
15 ein wiederum anderen Blockdiagramm, das einen Abschnitt eines Systems darstellt, das einen Austausch dynamischer Daten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausführt.
Systemarchitektur
2 stellt ein verteiltes Mehr-Ort-Testsystem 10 dar, das einem Systemadministrator erlaubt, von einem entfernten Browser 12, ein automatisiertes Mehr-Ort-Testen über eine aktive Teststeuerung 14 an entfernten Computerprozessoren 16, 18 zu verwalten, die irgendwo im Internet angeordnet sind. Das System weist verteilte Softwarekomponenten auf, die unter Verwendung einer Mitteilungs-Übermittlung eines offenen Kommunikationsstandard-IPs (Internetprotokoll-) koordiniert werden, wie z. B. HTTP-Meldungen (HTTP = Hypertext Transport Protocol) (angezeigt durch durchgezogene und gestrichelte Zeigerlinien). Operationen des Mehr-Ort-Tests sind erkennbar und eingerichtet unter Verwendung des Web-Browsers, der bei einem Ausführungsbeispiel eine WQM-Anzeige aufweist. In den nachfolgenden Beschreibungen werden die Ausdrücke „Server" und „Servlet" austauschbar verwendet, eine solche Verwendung soll jedoch die Erfindung nicht auf Java-basierte Implementierungen einschränken, da der Ausdruck Servlet eine andere Bedeutung haben kann. Tatsächlich ist es ein Vorteil der vorliegenden Erfindung, dass sie in einer Vielzahl von Computersprachen implementiert sein kann.
Gemäß einer Implementierung umfasst das System 10 Softwarekomponenten, die an der aktiven Teststeuerung 14 angeordnet sind, die den Mehr-Ort-Test (MLT; Multi-Location Test 30) einen Dynamischer-Inhalt-Server (DCS; Dynamic Content Server 28), der einen Datenaustauschserver und einen Sync-Server umfasst, und einen optionalen Ressourcen-Verwalter 32 umfasst. Der DCS 28 und ein optionaler Ressourcenverwal ter 32 sind potentiell entfernt von dem MLT 30 angeordnet. Das System 10 umfasst ferner Softwarekomponenten, die auf entfernten Prozessoren 16, 18 laufen (die bei dem WQM-Beispiel aktive Testsonden darstellen), die DCS-Komponenten (nicht gezeigt in 2) und Testsitzungsserver (TSS; Test Session Server 20, 22) umfassen, was bei einem bevorzugten Ausführungsbeispiel ein Java-Servlet ist. Bezug nehmend auf 3 ist ein Testsitzungs-Servlet 34 eine Spezialzweck-Softwareanwendung, die in einem Web-Server 36 residiert (z. B. auf Testsonden 16, 18 läuft), die mit einem Klientenprogramm 40 unter Verwendung des HTTP-Protokolls kommunizieren, und die Softwareprogramme betreiben können, wie z. B. Tests 38, in Folge. Zum Beispiel kann der Klient 40 eine Liste der Testsoftwareprogramme zusammen mit den Parametern übermitteln, die erforderlich sind, um sie zu betreiben. Das Testsitzungs-Servlet bringt das Testergebnis zurück zu dem Klienten 40.
Eine Datenbank (nicht gezeigt) residiert an der aktiven Teststeuerung 14, um die Testergebnisse zu speichern, die von den Test-Diensten empfangen werden. Mit einer ausreichenden Menge an Testergebnisdaten kann das System 10 Änderungen und/oder Muster in der QOS eines zu testenden Dienstes (SUT; Service Under Test) präsentieren und die Stabilität eines bestimmten Systems überwachen. Die Tests selbst können solche historische Daten aus dem Speicher aufrufen. Zum Beispiel kann das System Charakteristika (z. B. Bewegungszeit einer SMS-Meldung) von historischen Testergebnissen mit neuen Testergebnissen vergleichen, um zu bestimmen, ob Nachfolgeaktionen notwendig sind (z. B. wiederholte oder zusätzliche Tests, Auslösen von Alarmen), wenn eine voreingestellte Abweichungsschwelle überschritten wird.
Bei einem Aspekt, der ohne weiteres für Fachleute auf dem Gebiet offensichtlich ist, liefert die vorliegende Erfindung ein Computerprogrammprodukt, das auf einer oder mehreren programmierbaren Speichervorrichtungen codiert ist. Das Computerprogrammprodukt ist durch den einen oder die mehre ren Prozessoren ausführbar, die oben beschrieben sind, um ein Mehr-Ort-Testen in dem System auszuführen. Jeder Prozessor und die Teststeuerung sind vorzugsweise Allzweckcomputer in der Form von herkömmlichen Personalcomputern, die konfiguriert sind, um als Server oder als Klienten zu arbeiten. Die Computer weisen vorzugsweise eines oder mehrere der nachfolgenden Leifwerke auf: ein Festplattenlaufwerktreiber zum Lesen aus und Schreiben auf eine Festplatte, ein Magnetplattenlaufwerktreiber zum Lesen aus oder Schreiben auf eine entfernbare Magnetplatte, und ein Optikplattenlaufwerk zum Lesen aus oder Schreiben auf eine entfernbare Optikplatte, wie z. B. eine CD-ROM. Die Laufwerke und ihre zugeordneten, computerlesbaren Medien liefern einen nichtflüchtigen Speicher für computerlesbare Anweisungen, Datenstrukturen, Programmmodule, Testergebnisse und andere Daten für die Prozessoren.
Mehr-Ort-Testverfahren
Bezug nehmend auf 4 kann ein Verfahren 400 zum Verwenden des Testsystems 10, um ein automatisiertes Mehr-Ort-Testen auszuführen, einen Web-Browser verwenden, um im Wesentlichen gleichzeitig zumindest einen ersten Fluss A 24 und einen zweiten Fluss N 26 zu initiieren. Bei Schritten, die nachfolgend detaillierter beschrieben werden, wird eine graphische Beschreibung des Mehr-Ort-Tests erzeugt (Schritt 410), dann liest der MLT die Beschreibung aller Testflüsse, die an unterschiedlichen Testorten ausgeführt werden sollen, und tätigt einen Ruf zu den TSSs an den entsprechenden Orten (Schritt 420). Bei Schritt 430 wird eine Synchronisation der Flüsse für eine gleichzeitig ablaufende Ausführung erreicht, zwischen und unter den entfernten Orten unter Verwendung von offenen Kommunikationsprotokollen. Es wird darauf hingewiesen, dass das System 10 nicht notwendigerweise für eine „Master"- und „Slave"-Steuerung konfiguriert ist, was bedeutet, dass das DCS 28, nachdem es im Wesentlichen gleichzeitig die Flüsse initiiert, keine unidirektio nale Steuerung über die Flüsse besitzt. Dies ist eine wichtige Unterscheidung von herkömmlichen Systemen, bei denen ein einzelnes Programm das gesamte Mehr-Ort-Testen steuert. Bei Systemen gemäß der Erfindung existieren zwei Kategorien von Testkomponenten, nämlich funktionale Komponenten, die nützliche Informationen zu einem Benutzer liefern, und Infrastrukturkomponenten, die die Softwarekomponenten umfassen, die für eine Synchronisation und Datenaustausch verantwortlich sind. Die Unabhängigkeit der verteilten Komponenten ermöglicht eine effizientere Verwendung von Ressourcen durch Übermitteln von Mitteilungen zu einem Ressourcenmanager, dass die Verwendung einer Ressource von einem Fluss abgeschlossen ist, und der Ressourcenverwalter kann dann die Ressource zur Verwendung durch andere Flüsse freigeben, bevor der gesamte Test abgeschlossen ist. Abschließend werden bei Schritt 440 Testergebnisse nach einer Beendigung der Flüsse berichtet.
Graphische Darstellung des Mehr-Ort-Tests
Bei Schritt 410 arbeiten der MLT 30 und der Browser 12, um zu ermöglichen, dass die Erzeugung einer graphischen Darstellung eines Mehr-Ort-Tests ausgeführt wird. Existierende, graphische Testbeschreibungstools, wie z. B. der Agilent WQM, liefern eine Möglichkeit, ein einzelnes, entferntes Softwareartefakt zu beschreiben. In der WQM-Terminologie wird dies als ein „Test" bezeichnet, da diese Software zum Testen eines Aspekts eines zu testenden Dienstes (SUT; Service Unter Test) verwendet wird. 5 stellt eine bekannte, graphische Darstellung 42 eines einzelnen Softwaretests dar, der eine spezifizierte Webseite liest und nützliche Informationen erzeugt, genannt „Messungen". Messtestergebniswerte ermöglichen die Quantisierung des Verhaltens eines zu testenden Webdienstes, wie durch einen Benutzer einer Webseite des Webdienstes erfahren werden würde, der versucht, zu der Webseite zu „surfen". Zum Bei spiel berichtet der Test eine „Gesamtantwortzeit" zum Herunterladen der Webseite.
Der WQM ermöglicht ferner das Platzieren solcher „Tests" auf entfernten Computerprozessoren (wie z. B. jenen der Testsonden 16, 18) unter der Steuerung anderer Programme, genannt „Agenten", die Tests betreiben ähnlich zu jenen auf einem regelmäßigen Intervall, um „Verhaltensdiagramme" für jeden SUT zu erzeugen. Der WQM liefert ferner ein anderes graphisches Tool, um eine Anzahl solcher Tests in einer Sequenz auf jeglichem entfernten „Agenten" auszuführen. 6 stellt eine hierarchische, graphische Darstellung 44 einer Testsequenz dar, die in einer strikten, sequenziellen Weise ausgeführt werden soll.
Einer der Aspekte der Erfindung ist eine graphische Darstellung eines gleichzeitig ablaufenden, entfernten und synchronisierten Mehr-Ort-Tests als mehrere Testflüsse, unter der Steuerung des MLT 30. 7 stellt eine graphische Darstellung 46 eines Mehr-Ort-Tests dar, die zwei entfernte, drahtlose Vorrichtungs- (z. B. Zellulartelefon-) Benutzer simuliert. Testfluss 1 stellt das Senden einer Bildmitteilung von einer drahtlosen Vorrichtung (Telefon) dar. Testfluss 2 stellt eine andere drahtlose Vorrichtung dar, die die Meldung empfängt. Die graphische Darstellung 46 wurde erzeugt unter Verwendung existierender Tools in dem QOS-Verwalter. Es wird darauf hingewiesen, dass die Flüsse nun als Teile eines einzelnen „Tests" gezeigt sind, den der QOS-Verwalter an einem Agenten an einem entfernten Ort anwenden kann. Jeder Fluss ist jedoch eine selbsttragende Einheit unter dem Mehr-Fluss-Test.
Ausführung des Mehr-Ort-Tests
Bezug nehmend wiederum auf das Verfahren, das in 4 dargestellt ist, und die Architektur, die in 2 gezeigt ist, wandelt bei Schritt 420 der MLT 30 dann die grafische Darstellung des Mehr-Ort-Tests in eine Textdarstellung zur Übertragung zu dem entfernten Agenten um. Der Agilent WQM liefert eine solche Textdarstellung in einer Sprache, genannt „SmartFrog", die Erfindung soll jedoch in keinster Weise auf jegliches bestimmte Format beschränkt sein. Jegliches hierarchische Datendarstellungsformat des öffentlichen Bereichs, wie z. B. XML, kann auch verwendet werden, um die Testflüsse darzustellen, und zu dem Mehr-Ort-Test übertragen werden. Ein Beispiel einer graphischen Darstellung 48 eines zweiseitigen Mehr-Fluss-Tests ist in 8 gegeben, und eine entsprechende Textdarstellung ist in Beispiel 1 umfasst.
Beispiel 1
Der MLT liest die Textdarstellung und identifiziert die Anzahl von Flüssen (z. B. Flüsse 24, 26) in dem Test, der ausgeführt werden soll, jegliche Vorrichtungen (16, 18 z. B.), an denen die Tests ausgeführt werden müssen, und die entfernten Orte der Agenten, die die Vorrichtungen steuern. Der MLT kontaktiert den TSS 20, 22, der an jedem entfernten Ort läuft, der den Flüssen zugeordnet ist, und liefert die Beschreibung der Testsequenz, die ausgeführt werden soll. Wiederum verwenden die TSS ein standardmäßiges Hypertext Transfer Protocol (HTTP), ein offenes Netzwerkprotokoll, das für das World Wide Web verwendet wird. Der MLT kontaktiert den TSS an der Position jedes Flusses im Wesentlichen gleichzeitig, nach dem Identifizieren der Anzahl von Flüssen in dem Text, und übermittelt eine Anforderung zum Betreiben der Sequenztests gleichzeitig ablaufend unter jedem Fluss.
Synchronisierung und Dynamische-Daten-Austausch zwischen Testflüssen
Bei Schritt 430 des Verfahrens, das in 4 dargestellt ist, verwendet das drahtlose Testsystem 10 den DCS 28, um eine Testausführung zu synchronisieren und einen Datenaustausch zwischen oder unter entfernten Tests zu steuern. Bei der WQM-Implementierung verwendet der DCS 28 das HTTP-Protokoll und erfordert, dass Daten unter Verwendung von XML spezifiziert werden, einer Textmarkierungssprache wie HTML (Hyper Text Markup Language), die verwendet wird, um Webseiten zu erzeugen. Der DCS erfordert ferner, dass jede Dateneinheit unter Verwendung eines Eindeutiger-Identifizierer-Schlüssels identifiziert ist, so dass Datenelemente mit demselben Namen oder ältere Datenelemente aus einem früheren Durchlauf desselben Tests nicht mit neuen Datenelementen verwechselt werden.
Eine explizite Zeitsynchronisation wird durch Verwendung spezieller Tests erreicht, genannt „Sync-Send-" (Synch senden) und „Sync- Receive" (Synch empfangen) Tests, die spezielle Datenzeichenfolgen einsetzen, die einem Empfängertest erlauben oder ihn auffordern, auf einen Sendertest zu warten, um einen bestimmten Punkt in der Testausführung zu erreichen, bevor fortgefahren wird. 9 stellt eine graphische Darstellung 50 dar, die einen Test „Send-Sync" (Sync senden) und einen Test „Await-Sync" (Sync abwarten) umfasst, die eine Zeitsynchronisation zwischen Testflüssen erreichen. Testfluss 1 führt Test-1 und Test-2 aus, vor dem Senden eines Datenelements „Sync" zu dem DCS 28. Testfluss-2 führt den Test „Await-Sync" aus, der periodisch Daten aus dem DCS liest, um zu bestimmen, ob das Datenelement „Sync" von Testfluss-1 angekommen ist. Der Netto-Effekt ist, dass Test-1 und Test-2 von Testfluss-1 garantiert betrieben werden, bevor Test A von Testfluss B betrieben wird.
Gemäß einem alternativen Ausführungsbeispiel der Erfindung wird das XML-Datenformat, das durch den DCS 28 geliefert wird, ausgedehnt, um eine „Steuer"-Mitteilung zu spezifizieren. Eine Hinzufügung des Steuermitteilungsmodus über das vordefinierte Nur-Daten-Format hinaus ermöglicht, dass die Testflüsse implizit Zeitgebung und andere Informationen austauschen, ohne spezielle Testkomponenten einbringen zu müssen. Die „Steuermitteilungs-Übermittlungs"-Fähigkeit ermöglicht, dass die Testflüsse Notfall-Mitteilungen zu anderen Testflüssen rundsenden, um die Testausführung zu beenden und/oder Metadaten der Testausführung (z. B. Anzahl von durchgeführten Tests, Start- und End-Zeit für jeden Test in jedem Fluss und Ergebnis des Ausführens jedes Tests, etc.) zu der Entität zurückzubringen, die den MLT startet.
Testausführungsinformationen und Testdaten werden über das Internet über normale HTTP-Anforderungen ausgetauscht, so dass die Plattform eines Klienten oder Servers für die aktive Teststeuerung 14 unbekannt sein kann. Die Architektur ist unabhängig von den Tests, die gegen den SUT ausgeführt werden, da sie im Wesentlichen die Ausführung jeglicher Tests für jegliches Produkt ermöglicht.
Ausführungsbeispiel einer exemplarischen Synchronisationsarchitektur
10 zeigt einen Abschnitt 10' einer Implementierung der vorliegenden Erfindung, wo Flüsse A und B in dem mehrseitigen Testsystem unter Verwendung von Sync-Servlets 52, 54 bzw. 56 synchronisiert werden, die jeweils in der aktiven Testsonde 58, die Fluss A entspricht, der aktiven Teststeuerung 60 bzw. der aktiven Testsonde 62, die Fluss B entspricht, angeordnet sind.
Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist jede der aktiven Testsonde 58, der aktiven Teststeuerung 62 und der aktiven Testsonde 70 ein individueller Agent in dem System 10', obwohl andere Konfigurationen möglich sind und in den Schutzbereich der vorliegenden Erfindung fallen. Es wird darauf hingewiesen, dass Sync-Servlets 52 und 56 in 10 nicht bei dem nachfolgend gegebenen Beispiel eingesetzt, aber bei anderen Konfigurationen oder Flüssen eingesetzt werden können, die hierin nicht ausdrücklich offenbart sind. Abhängig von der vorliegenden Systemkonfiguration kann der entsprechende Zielort für ein bestimmtes Signal oder eine Meldung, wie z. B. ein Signal „Await Sync" (Sync abwarten) oder „Send Sync" (Sync senden) spezifiziert werden müssen oder nicht, obwohl bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ein solcher Zielort spezifiziert sein muss, wie bei dem Schema angezeigt ist, das nachfolgend ausgeführt wird. Zum Beispiel kann das „Send Sync"-Signal, das von Fluss B (Flow B) in 10 ausgeht, derart spezifiziert sein, dass es einen letztendlichen Zielort in Fluss B hat, und dass „A wait Sync"-Signal, das aus Fluss A (Flow A) stammt, kann spezifiziert sein, dass es einen letztendlichen Zielort in dem Sync-Servlet 54 hat.
In 10 ist Fluss A durch Testkomponente 1, Testkomponente 2 („Await Sync") und Testkomponente 3 in der aktiven Testsonde 58 dargestellt. Fluss B ist dargestellt durch Testkomponente 1, Testkomponente 2 („Send Sync") und Testkomponente 3 in der aktiven Testsonde 62. Ein erster und zweiter Fluss A und B werden im Wesentlichen gleichzeitig initiiert. Die Ausführung von Fluss A wird unterbrochen, nachdem Fluss A zu der zweiten Testkomponente oder dem Ereignis „Await Sync" fortgeschritten ist. Eine Ausführung der Testkomponente „Await Sync" in Fluss A verursacht, dass eine Meldung oder Anweisung zu dem Sync-Servlet 54 gesendet oder abgeschickt wird, die angibt, dass Fluss A auf den Empfang eines „Send Sync"-Signals oder einer -Meldung von Fluss B wartet. Der Zeitbetrag, den die Testkomponente „Await Sync" in Fluss A auf den Empfang eines „Send Sync"-Signals wartet, kann eine konfigurierbare Zeitbegrenzung sein. Wenn Fluss B zu der Testkomponente „Send Sync" fortgeschritten ist, wird ein „Send Sync"-Signal zu dem Sync-Servlet 54 abgeschickt. Das nächste mal, wenn Fluss A eine Erlaubnis anfordert, die Ausführung wieder aufzunehmen (d. h. „Wurde ein „Send Sync"-Signal von Fluss B empfangen?"), wurde das „Send Sync"-Signal bereits von dem Sync-Servlet 54 empfangen, und Fluss A empfängt eine Erlaubnis, die Ausführung durch Ausführen des nächsten Schrittes wieder aufzunehmen (d. h. jetzt tritt die Ausführung von Testkomponente 3 auf).
Ausschließlich als darstellendes Beispiel und ohne Absicht, den Schutzbereich der vorliegenden Erfindung einzuschränken, kann FlowA:test1 (Flow = Fluss) in 10 ein Test sein, der zu einer Webseite navigiert und Authentifizierungsinformationen zum Einloggen in ein 802.11 wifi-Netzwerk anfordert und die Rechnungs- und Login-Informationen zu einem Zellulartelefonkonto senden lässt. F1owB:test1 empfängt dann die Bestätigungsmeldung auf dem Zellulartelefon mit dem Benutzernamen und Passwort. FlowA:test3 verwendet als Nächstes den Benutzernamen und das Passwort, um sich in dem wifi-Netzwerk zu registrieren. FlowA:test3 kann sich nicht einloggen (bzw. registrieren) bevor FlowB:test1 ordnungsgemäße Authentifizierungsinformationen empfangen hat. FlowA:await sync verursacht, dass eine Ausführung unterbrochen wird, bis FlowB:send sync gesendet wurde, wobei an diesem Punkt die Ausführung fortgesetzt wird. Wie nun erkannt wird, können send sync- und await sync-Funktionalitäten in mehreren Flüssen implementiert sein, um zu ermöglichen, dass kompliziertere, mehrseitige und Mehrfluss-Netzwerke oder -Systeme getestet werden.
Es wird darauf hingewiesen, dass das Ausführungsbeispiel der vorliegenden Erfindung, das in 10 gezeigt ist, speziell angepasst ist für eine Verwendung bei einer drahtlosen Diensttesteinstellung, wie z. B. einer wifi-Login-Anwendung bzw. -Registrier-Anwendung, obwohl zahlreiche andere Anwendungen denkbar sind und trotzdem in den Schutzbereich der vorliegenden Erfindung fallen.
Weiterhin Bezug nehmend auf 10 kann jedes der Sync-Servlets 52, 54 und 56 ein Programm mit mehreren Teilprozessen sein, das auf jeglichem der Agenten 58, 60 und 62 in dem System 10' läuft. Jeder Agent sollte eine Sync-Servlet-Funktionalität besitzen, obwohl eine solche Funktionalität nicht im Hinblick auf ein gegebenes Servlet gemäß einer bestimmten Systemkonfiguration verwendet werden kann. Zum Beispiel kann eine solche Sync-Servlet-Funktionalität auf Agenten 60 und 62 und nicht 58 ausgeübt werden, während weiterhin erlaubt wird, dass die oben beschriebenen Testprozeduren auftreten. Bei einer optimalen Systemkonfiguration jedoch besitzt jeder Agent eine Dynamischer-Inhalt-Servlet-Funktionalität.
Tests können durch einen Anrufer aufgerufen werden, der entfernt von jeglichem der Agenten des Systems 10' ist, wenn der Anrufer mit einem Netzwerk verbunden ist, mit dem solche Agenten verbunden sind, oder mit dem einer solcher Agenten verbunden ist. Ein solches Netzwerk kann jegliches Netzwerk sein, wie z. B. das Internet. Bei einem Ausführungsbeispiel der vorliegenden Erfindung können die Agenten 58, 60 und 62 Computer und/oder Server sein.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird eine Dynamischer-Inhalt-Servlet-Funktionalität zu einem Syc-Servlet hinzugefügt. Während sich eine Dynamischer-Inhalt-Servlet-Funktionalität von der eines Sync-Servlets unterscheidet, kann eine Dynamischer-Inhalt-Servlet-Funktionalität allgemein auf ein Sync-Servlet im Huckepackverfahren aufgenommen sein, um das Betreiben mehrerer Servlets zu vermeiden, wie in 10 gezeigt ist.
Bei einem Ausführungsbeispiel der vorliegenden Erfindung können Testbeschreibungen oder Anforderungen zum Synchronisieren in ein vordefiniertes XML-Schema (oder sogar Klartext) entweder in einer HTTP-Post oder einer HTTPS-Post eingelagert sein. HTTP (Hyper Text Transfer Protocol) ist ein generischer Meldungstransportstandard oder eine standardisierte Weise, über das Internet zu kommunizieren. Ein HTTP-Get (Get = Erhalten), ist das, was ein Web-Browser ausführt; er empfängt Daten nur. Aber eine HTTP-Post (Post = abschicken) ermöglicht das Senden eines Datenkörpers und auch den Empfang einer Antwort.
Der Datenkörper, der durch eine HTTP-Post gesendet wird, ist über das XML-Schema organisiert. XML (Extensible Markup Language; erweiterbare Markup-Sprache) ist eine standardisierte Möglichkeit zum Codieren von Daten, oder anders ausgedrückt zum Generisieren der Daten, Freigeben einer Definition, Übertragung, Validierung und Interpretation der Daten zwischen Anwendungen.
Schnittstellenentwurfsdetails, die ein Ausführungsbeispiel der Erfindung implementiert, das in 10 dargestellt ist, werden nachfolgend in Beispiel 2 aufgeführt, wo Textdarstellungen eines Sync-Servlet-Eingangsschemas gezeigt sind. Während die Sync-Servlet-Implementierung, die hierin nachfolgend aufgeführt wird, in Java geschrieben ist, kann eine solche Funktionalität in jeder geeigneten Programmiersprache implementiert sein oder unter jeglichem Web-Server laufen, der Servlets unterstützt. Andere auf Standards basierende Server und Protokolle können ebenfalls verwendet werden, um Sync-Servlets zu implementieren. Sync-Servlets können HTTP-Posts mit einem definierten XML-codierten Körper akzeptieren, nur um Daten einzugeben oder zu erhalten. Durch Verwenden einer solchen Funktionalität kann ein Sync-Objekt, das in jedem Test enthalten ist, der in einem gegebenen Fluss läuft, dann Daten abschicken oder Daten von dem Sync-Servlet erhalten. Das Sync-Servlet kann abgeschickt werden, um HTTP oder HTTPS (secure socket layer; Sicherheitssockelschicht) zu verwenden, um eine Sicherheit zu gewährleisten.
Beispiel 1: Wqm-Sync-Servlet-Schnittstellenentwurf
(A) Eingabe- und Ausgabe-Schnittstelle zu dem Sync-/Dynamischer-Inhalt-Servlet
(1) Kurze Beschreibung
Das Dynamische-Daten-Servlet läuft auf jeglichem QoSM-WQM-Agenten. Es liefert einen Datenspeicher für dynamische Daten zum Betreiben von Tests und verarbeitet Anforderungen zum „Hinzufügen (add)", „Entfernen (remove)" oder „Erhalten (get)" dynamischer Daten für eine spezifizierte Uniqueid (eindeutige ID), oder zum „Löschen (delete)" aller Daten für diese Uniqueid.
(2) Vorraussetzungen, die sich auf einen Dynamische-Daten- Entwurf beziehen

– Die nachfolgenden Attribute finden sich in dem Abschnitt Drahtlos (Wireless) von fh.conf. Sie können überschrieben werden durch verdeckte (Präfix fh) Attribute in dem Wireless Chain Text (Drahtlos-Kette-Test) selbst. • DcsLocation – (Zeichenfolge) Voreinstellung ist dieselbe wie das Attribut Host (ATC). • DcsPort – (ganze Zahl) Voreinstellung ist 16716 • DcsTimeout – (ganze Zahl) Voreinstellung 0 (einmal Nachsehen, kein Warten) • DcsLookup – (Boolscher Wert) Voreinstellung wahr (prüfe DCS, wenn nicht in lokalem Speicher)
– Das Nachfolgende muss in den Flussebenendatenspeichern verfügbar sein: • DcsLocation • DcsPort • DcsTimeout • DcsLookup • ChaindId – (Zeichenfolge) eine eindeutige ID für diese Testausführung • FlowId – (Zeichenfolge) der Name des aktuellen Flusses
– Eine DcsControl-Testkomponente ist verfügbar, um die Werte der Dcs*-Attribute zu ändern, die oben beschrieben sind.
– Die DcsPurgeTime-Eingabe in den Drahtlos-Abschnitt von fh.conf definiert das Alter, bei dem alte Daten im DCS (in Stunden) abgeführt werden sollen.

(3) Technische Anforderungen

– Fähigkeit zum Betreiben eines Servlets auf dem QOSM-Agenten.
– Definierte XML-Schnittstelle für die HTTP-Anforderungen und -Antwort.

(4) Definition oder Entwurfsbeschreibung

– Die Schnittstelle zum Servlet ist eine HTTP-Post.
– Beispiel url! http://<DcsLocation>:<DcsPort>/DynamicContentServlet
– Der Körper der Post ist XML. Die XML-Schnittstelle ist hierin definiert.
– Das Verhalten des DCS imitiert eine Hash-Tabelle: • Es ist nicht legal, einen Null-Schlüssel oder -Wert zu speichern, eine NullPointerException (Null-Zeiger-Ausnahme) resultiert. • Ein „put" (Setzen) bringt den vorangehend gespeicherten Wert zurück (oder Null, wenn kein Wert gefunden wurde) • Ein „get" (Erhalten) bringt den gespeicherten Wert zurück (oder Null, wenn kein Wert gefunden wurde) • Ein „remove" (Entfernen) bringt den vorangehend gespeicherten Wert zurück (oder Null, wenn kein Wert gefunden wurde)
– Ein „delete" (Löschen) entfernt alle Daten für einen eindeutige Id und bringt alle vorangehend gespeicherten Werte zurück.
– Das DCS weist ein spezielles Verhalten auf, wenn ein „Sync"-Datum bzw. eine gegebene Größe gespeichert ist. • Der Name des Sync-Datums ist „dcs sync<fromFlow>: <toFlow>" • Der Wert, der für ein Sync-Typ-Datum gespeichert ist, ist eine ganze Zahl. • Wenn bereits ein Wert für dieses Datum existiert, wird er um ein weiteres „put" inkrementiert. • Der Wert für dieses Datum wird um ein „get" dekrementiert, wenn der resultierende Wert 0 ist, wird das Datum entfernt.
– Das Abführen alter Daten, die nicht ordnungsgemäß am Ende einer Testausführung entfernt wurden, wird ausgeführt. • Der Wert DcsPurgeTime (DCS-Abführzeit), der in fh.conf enthalten ist, wird als das Alter verwendet, um alte Testdaten zu löschen, mit einer Voreinstellung von 24 Stunden. • Die Frequenz des Prüfens zum Abführen von alten Daten basiert auf dem Alterungswert (1/10tel des Werts).

(5) SITE-Abhängigkeiten (Site = Ort)

– TDL-Code, der das
aufrufen, auf die Antwort warten und die Ausgabe akzeptieren kann.

(6) Erzeugen und Parsen der XML in Tcl und Java

- Beschreibung: • Lernkurve beim Parsen von XML
– Auflösung/Fortschritt: • Erlernen des Dokumentobjektmodells in jdk1.4.1 zum Parsen von XML • Verwenden von Prozeduren, die bereits in Tdl zum Handhaben von XML vorhanden sind.

(7) Aufbauen der ausgehenden XML in Java

– Beschreibung: • Lernkurve beim Parsen von XML
– Auflösung/Fortschritt: • Erlernen des Dokumentobjektmodells in jdk1.4.l zum Parsen von XML

Voraussetzungen

– Die gesendete XML muss in der korrekten Form sein oder wird nicht validiert.

Technische Anforderungen

– Die Schnittstelle ist eine HTTP-Post, die einen XML-Körper als Eingabe zu dem Servlet enthält.
– Die Ausgabe ist die Post-Antwort, ebenfalls im XML-Format.

(B) Definition oder Entwurfsbeschreibung
(1) „put"-Anforderungs-Syntax (Request Syntax) eingeben

– <DcsRequest> • <UniqueId>chainId</UniqueId> • <Action>put</Action> • <DynamicData> (kann mehrere Datum-Etiketten enthalten) • <Datum> • <Name>datumName</Name> • <Type>datumType</Type> • <Value>datumValue</Value> • </Datum> • </DynamicData>
– </DcsRequest>

(2) „put"-Sync-Anforderungs-Syntax eingeben

– <DcsRequest> • <UniqueId>chainId</UniqueId> • <Action>put</Action> • <DynamicData> • <Datum> • <Name>dcs sync:<fromFlow>:<toFlow></Name> • <Type>Integer</Type> • <Value>1</Value> • </Datum> • </DynamicData>
– </DcsRequest>

(3) „get"-Anforderungs-Syntax eingeben

– <DcsRequest> • <UniqueId>chainId</UniqueId> • <Action> get </Action> • <Timeout> 60 </Timeout> • <DynamicData> (kann mehrere Datum-Etiketten enthalten) • <Datum> • <Name>datumName</Name> • </Datum> • </DynamicData>
– </DcsRequest>

(4) „get"-Sync-Anforderungs-Syntax eingeben

– <DcsRequest> • <UniqueId>chainId</UniqueId> • <Action> get </Action> • </DynamicData> • </Datum> • <Name>dcs sync:<fromFlow>:<toFlow></Name> • </Datum> • </DynamicData>
– </DcsRequest>

(5) „remove"-Anforderungs-Syntax eingeben

– <DcsRequest> • <UniqueId>chainId</UniqueId> • <Action> remove <Action> • <Timeout> 60 </Timeout> • <DynamicData> (kann mehrere Datum-Etiketten enthalten) • </Datum> • <Name>datumName</Name> • </Datum> • </DynamicData>
– </DcsRequest>

(6) „delete"-Anforderungs-Syntax eingeben – löscht alle Daten für eine bestimmte chain id (Ketten-ID)

– <DcsRequest> • <UniqueId>chainId</UniqueId> • <Action> delete </Action>
– </DcsRequest>

(7) Antwort-Syntax ausgeben, wenn keine Ausnahme

– </DcsResponse> • <UniqueId>chainId</UniqueId> • <Action> (Aktion von Anforderung) </Action> • <DynamicData> (kann mehrere Datum-Etiketten enthalten) • </Datum> • <Name>datumName</Name> • <Type>datumType</Type> • <Value>datumValue</Value> • </Datum> • </DynamicData>
– </DcsResponse>

(8) Antwort-Syntax ausgeben, wenn Ausnahme

– <DcsResponse> • <UniqueID>chainID</UniqueID> • <Action> (Aktion von Anforderung) </Action> • <Exception> • <Type>exception type</Type> • <Message>exception message</Message> • <StackTrace>exception stack trace</Stack-Trace> • </Exception>
– </DcsResponse>

(9) SQM- (Firehunter-) Abhängigkeiten

– Keine

(10) SITE-Abhängigkeiten

– Fähigkeit zum Ausführen einer HTTP-Post an dem Servlet mit dem korrekten XML-Körper.
– Fähigkeit zum Empfangen der Post- Antwort-XML.

(11) JUnit Teststrategie

– Testen durch betreiben von Einheitstests an der tatsächlichen Schnittstelle.

Die Sync-Servlet-Schemata, die oben ausgeführt und in den Figuren dargestellt sind, sind nur Beispiele. Die vorliegende Erfindung ist nicht auf solche Schemata beschränkt; Andere Schemata können verwendet werden und fallen trotzdem in den Schutzbereich der vorliegenden Erfindung; vorausgesetzt jedoch, dass entsprechende Änderungen an den Sync-Servlets und ihren entsprechenden Testkomponenten ausgeführt werden. Ferner sind Schemata der vorliegenden Erfindung nicht auf XML beschränkt; Andere Markup- („Etiket ten"-) Sprachen oder sogar Klartext und ihre entsprechenden Testkomponenten können ebenfalls eingesetzt werden.
11 zeigt ein anderes Ausführungsbeispiel der vorliegenden Erfindung, wo drei Flüsse A, B und C gleichzeitig ablaufend initiiert werden. Jeder Fluss betreibt seine erste Testkomponente. Wenn Fluss A die Testkomponente „Await Sync" betreibt, wird verursacht, dass Fluss A die Ausführung unterbricht, bis ein Signal oder eine Meldung „Send Sync" über das Sync-Servlet 54 von Fluss B empfangen wird. Der Zeitbetrag, den die Testkomponente „Await Sync" in Fluss A auf einen Empfang des Signals „Send Sync" wartet, kann eine konfigurierbare Zeitbegrenzung sein. Wenn Fluss B zu der Testkomponente „Send Sync" fortgeschritten ist, wird ein Signal „Send Sync" zu dem Sync-Servlet 54 abgeschickt. Das nächste Mal, wenn Fluss A eine Erlaubnis anfordert, die Ausführung wieder aufzunehmen (d. h. „Wurde ein Signal „Send Sync" von Fluss B empfangen?"), wurde das Signal „Send Sync" bereits von dem Sync-Servlet 54 empfangen und Fluss A empfängt eine Erlaubnis, die Ausführung durch Betreiben des nächsten Schrittes wieder aufzunehmen (d. h. Ausführung von Testkomponente 3 tritt nun auf). Wenn Fluss C seine Testkomponente „Send Sync" erreicht, wird ein Signal oder eine Meldung „Send Sync" zu Fluss B über das Sync-Servlet 54 gesendet. Sobald das Signal oder die Meldung „Send Sync", die aus Fluss C stammt, von der Testkomponente „Await Sync" bei Fluss B empfangen wird, nimmt Fluss B die Ausführung zu der Testkomponente 4 wieder auf.
12 zeigt ein anderes Ausführungsbeispiel der vorliegenden Erfindung, wo die Firewall 68 zwischen der aktiven Teststeuerung 60 und Flüssen A, B und C angeordnet ist. Flüsse A, B und C werden gleichzeitig ablaufend initiiert. Jeder Fluss betreibt seine erste Testkomponente. Da die Firewall 68 zwischen der aktiven Teststeuerung 60 und den aktiven Testsonden 58, 62 und 64 angeordnet ist, kann das Sync-Servlet 54 vielleicht nicht verwendet werden. Trotzdem kann bei dem Ausführungsbeispiel der vorliegenden Erfindung, das in 12 gezeigt ist, auf jegliches Sync-Servlet durch jegliche der aktiven Testsonden 58, 62 oder 64 zugegriffen werden, wodurch das System 10' betriebsfähig gemacht wird. In 12 wird das Sync-Servlet 52 der aktiven Testsonde 58 eingesetzt, um eine solche Funktion zu erfüllen.
Wenn Fluss A zu der Testkomponente „Await Sync" fortgeschritten ist, wird die Ausführung von Fluss A unterbrochen, während auf den Empfang eines Signals oder einer Meldung „Send Sync" von Fluss B gewartet wird. Wenn Fluss B die zweite Testkomponente „Send Sync" zu einer späteren Zeit erreicht, wird ein Signal oder eine Meldung „Send Sync" zu dem Sync-Servlet 52 von Fluss B abgeschickt. Die Testkomponente „Await Sync" in Fluss A empfängt das Signal „Send Sync" von Fluss B über das Sync-Servlet 52, das die Wiederaufnahme von Fluss A auslöst. Fluss B setzt die Ausführung des Tests „Await Sync" fort und wird unterbrochen, während er auf einen Empfang eines Signals oder einer Meldung „Send Sync" von Fluss C wartet. Wenn Fluss C seine Testkomponente „Send Sync" erreicht, wird ein Signal oder eine Meldung „Send Sync" zu Fluss B über das Sync-Servlet 52 gesendet. Sobald das Signal oder die Meldung „Send Sync", das aus Fluss C stammt, durch die Testkomponente „Await Sync" in Fluss B empfangen wird, nimmt Fluss B die Ausführung zu der Testkomponente 4 wieder auf.
Verschiedene Protokolle sind hierin beschrieben, wie z. B. HTTP und HTTPS. Die vorliegende Erfindung ist nicht auf solche Protokolle beschränkt und erachtet explizit die Verwendung anderer Protokolle, wie z. B. FTP („File Transfer Protokoll"), SCP („Secure Copy Protocol") und SFTP („Secure File Transfer Protocol"). Auf ähnliche Weise werden hierin verschiedene Netzwerke beschrieben, wie z. B. ein LAN, ein drahtloses Netzwerk, ein Drahtleitungsnetzwerk und das Internet. Die vorliegende Erfindung ist nicht auf solche Netzwerke beschränkt; andere Netzwerke können eingesetzt werden, und fallen in den Schutzbereich der vorliegenden Erfindung.
Die vorliegende Erfindung kann erfolgreich über einen breiten Bereich von drahtlosen Netzwerktypen und Standards eingesetzt werden, der folgendes umfasst, aber nicht beschränkt ist auf wifi 802.11a wifi 802.11b, wifi 802,11g wimax, GSM/GPRS und CDMA, sowie andere Standards, die noch erfunden oder implementiert werden. Ferner ist die vorliegende Erfindung in ihrem Schutzbereich nicht auf drahtlose Testanwendungen beschränkt und umfasst innerhalb ihres Schutzbereichs Drahtleitungstestanwendungen, wie z. B. Ethernet/LAN- und Einwahl-Netzwerke.
Bei einem bevorzugten Ausführungsbeispiel werden die Synchronisationsverfahren der vorliegenden Erfindung ausgeführt unter Verwendung eines Agilent-WQM-Agenten, wobei viele Aspekte desselben beschrieben sind unter:
http://we.home.agilent.com/cgibin/bvpub/agilent/Product/cp Product.jsp?OID=536882909&NAV ID=-536885380.536882909.00&LANGUAGE CODE=eng&COUNTRY CODE=-ZZ&CT=PRODUCT&JPID=/comms/firehunter.
Exemplarisches Ausführungsbeispiel einer Dynamische-Daten-Austausch-Architektur
13 zeigt einen Abschnitt 10'' eines Ausführungsbeispiels der vorliegenden Erfindung, wo ein erster und zweiter Fluss A und B in einem mehrseitigen Testsystem dynamisch erzeugte Daten gemeinschaftlich verwenden und/oder übertragen, mit Hilfe von offenen Kommunikationsstandards unter Verwendung von Sync-Servlets 52, 54 und 56, die jeweils in der aktiven Testsonde 58, die Fluss A entspricht, der aktiven Teststeuerung 60 bzw. der aktiven Testsonde 62, die Fluss B entspricht, angeordnet sind.
Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist jede der aktiven Testsonde 58, der aktiven Teststeuerung 60 und der aktiven Testsonde 62 ein individueller Agent in dem System 10'', obwohl andere Konfigurationen möglich sind und in den Schutzbereich der vorliegenden Erfindung fallen. Es wird darauf hingewiesen, dass Dynamischer-Inhalt-Servlets 52 und 56 in 13 nicht bei dem nachfolgend gegebenen Beispiel eingesetzt werden, aber bei anderen Konfigurationen oder Flüssen eingesetzt werden können, die hierin nicht ausdrücklich offenbart sind.
In 13 ist Fluss A durch Testkomponente 1 (Test Component; TC), Testkomponente 2 und Testkomponente 3 in der aktiven Testsonde 58 dargestellt. Fluss B ist durch Testkomponente 1, Testkomponente 2 und Testkomponente 3 in der aktiven Testsonde 62 dargestellt. Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung sind Testkomponenten innerhalb jedem gegebenen Fluss in der Lage, dynamische Daten zwischen oder unter einander gemeinschaftlich zu verwenden.
Weiterhin Bezug nehmend auf 13 werden Flüsse A und B im Wesentlichen gleichzeitig initiiert. Die Ausführung der Testkomponente 2 in Fluss A verursacht, dass Testkomponente 2 in Fluss B dynamische Daten erzeugt, die erforderlich sind, damit Testkomponente 3 in Fluss A erfolgreich ausgeführt wird. Sobald sie in Testkomponente 2 von Fluss B erzeugt sind, werden solche dynamischen Daten von Fluss B zu dem Dynamische-Daten-Inhalt-Servlet 54 abgeschickt. Wenn Fluss A zu Testkomponente 3 fortgeschritten ist, wird der Dynamische-Daten-Inhalt, der auf dem Sync-Servlet 54 vorliegt, durch Testkomponente 3 wiedergewonnen. Flüsse A und B können nun fortschreiten, die Ausführung abzuschließen, wobei der notwendige Dynamische-Daten-Inhalt zwischen oder unter den Flüssen A und B gemeinschaftlich verwendet oder übertragen wurde.
Ausschließlich als darstellendes Beispiel und ohne Absicht, den Schutzbereich der vorliegenden Erfindung einzuschränken, kann FlowA:test2 (Flow = Fluss) in 13 ein Test sein, der zu einer Webseite navigiert und Authentifizierungsinformationen zum Einloggen in ein 802.11 wifi-Netzwerk anfordert und die Rechnungs- und Login-Informationen zu einem Zellulartelefonkonto senden lässt. FlowB:test2 empfängt dann die Bestätigungsmeldung auf den Zellulartelefon mit dem Benutzernamen und Passwort. FlowB:test2 schickt dann den Benutzernamen und Passwort zu dem Dynamischer-Inhalt-Servlet 54 ab. FlowA:test3 erhält dann den Benutzernamen und das Passwort von dem Dynamischer-Inhalt-Servlet 54 und verwendet den Benutzernamen und das Passwort zum Einloggen in das wifi-Netzwerk.
Es wird darauf hingewiesen, dass das Ausführungsbeispiel der vorliegenden Erfindung, das in 13 gezeigt ist, speziell angepasst ist für eine Verwendung bei einer drahtlosen Diensttesteinstellung, wie z. B. einer wifi-Login-Anwendung bzw. -Registrier-Anwendung, obwohl zahlreiche andere Anwendungen denkbar sind und trotzdem in den Schutzbereich der vorliegenden Erfindung fallen.
Weiterhin Bezug nehmend auf 13 kann jedes der Dynamische-Daten-Inhalt-Servlets 52, 54 und 56 ein Programm mit mehreren Teilprozessen bzw. ein verkettetes Programm sein, das auf jeglichem der Agenten 58, 60 und 62 in dem System 10'' läuft. Jeder Agent kann ein Dynamische-Daten-Inhalt-Servlet betreiben, das in der Lage ist, mehrere Testsitzungen parallel zu verketten; nicht alle Agenten müssen eine Dynamische-Daten-Inhalt-Funktionalität aufweisen. Zum Beispiel kann die Dynamische-Daten-Inhalt-Servlet-Funktionalität den Agenten 60 und 62 und nicht 58 gegeben sein, während weiterhin erlaubt ist, dass zumindest einige der Dynamische-Daten-Gemeinschaftsverwendungs-Prozeduren, die oben beschrieben sind, auftreten. Bei einer optimalen Systemkonfiguration besitzt jeder Agent jedoch eine Dynamischer-Inhalt-Servlet-Funktionalität.
Eine Dynamische-Daten-Gemeinschaftsverwendung kann durch einen Anrufer aufgerufen werden, der entfernt von jeglichem der Agenten des Systems 10'' ist, wenn der Anrufer mit einem Netzwerk verbunden ist, mit dem solche Agenten verbunden sind, oder mit dem einer solcher Agenten verbunden ist. Ein solches Netzwerk kann jegliches Netzwerk sein, wie z. B. das Internet. Bei einem Ausführungsbeispiel der vorliegenden Erfindung können die Agenten 58, 60 und 62 Computer und/oder Server sein.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird eine Sync-Servlet-Funktionalität zu einem Dynamischer-Inhalt-Servlet hinzugefügt. Während sich eine Sync-Servlet-Funktionalität von der eines dynamischen Inhalts unterscheidet, kann eine Sync-Servlet-Funktionalität allgemein auf ein Dynamischer-Inhalt-Servlet im Huckepackverfahren aufgenommen sein, um das Betreiben mehrerer Servlets zu vermeiden, wie in 13 gezeigt ist.
Bei einem Ausführungsbeispiel der vorliegenden Erfindung können Anforderungen zum dynamischen, gemeinschaftlichen Verwenden von Daten oder andere verwandte Anweisungen in ein vordefiniertes XML-Schema entweder in eine HTTP-Post oder eine HTTPS-Post eingelagert sein. HTTP (Hyper Text Transfer Protocol) ist ein generischer Meldungstransportstandard oder eine standardisierte Weise, über das Internet zu kommunizieren. Ein HTTP-Get (Get = Erhalten), ist das, was ein Web-Browser ausführt; er empfängt Daten nur. Aber eine HTTP-Post (Post = abschicken) ermöglicht das Senden eines Datenkörpers und auch den Empfang einer Antwort.
Der Datenkörper, der durch eine HTTP-Post gesendet wird, ist über das XML-Schema organisiert. XML (Extensible Markup Language; erweiterbare Markup-Sprache) ist eine standardisierte Möglichkeit zum Codieren von Daten, oder anders ausgedrückt zum Generisieren der Daten, Freigeben einer Definition, Übertragung, Validierung und Interpretation der Daten zwischen Anwendungen.
Schnittstellenentwurfsdetails, die ein Ausführungsbeispiel der Erfindung implementiert, das in 13 dargestellt ist, sind oben in Beispiel 2 aufgeführt, wo Textdarstellungen eines Dynamische-Daten-Inhalt-Servlet-Eingangsschemas gezeigt sind. Während die Dynamische-Daten-Inhalt-Servlet-Implementierung, die hierin vorangehend ausgeführt ist, in Java geschrieben ist, kann eine solche Funktionalität in jeder geeigneten Programmiersprache implementiert sein oder unter jeglichem Web-Server laufen. Andere auf Standards basierende Server und Protokolle können ebenfalls verwendet werden, um Dynamische-Daten-Inhalt-Servlets zu implementieren. Dynamische-Daten-Inhalt-Servlets können HTTP-Posts mit einem definierten XML-codierten Körper akzeptieren, um Daten einzugeben, zu erhalten, zu entfernen oder zu ersetzen. Durch Verwenden einer solchen Funktionalität kann ein Dynamische-Daten-Inhalt-Objekt, das in jedem Test enthalten ist, der in einem gegebenen Fluss läuft, dann Daten abschicken an, Daten erhalten von, Daten modifizieren oder Daten entfernen aus dem Dynamische-Daten-Inhalt-Servlet. Das Dynamische-Daten-Inhalt-Servlet kann abgeschickt werden, um HTTP oder HTTPS (secure socket layer; Sicherheitssockelschicht) zu verwenden, um eine Sicherheit zu gewährleisten.
14 zeigt einen anderen Abschnitt der vorliegenden Erfindung, wo drei Flüsse A, B und C gleichzeitig initiiert werden. Die Ausführung von Testkomponente 2 in Fluss B verursacht, dass Fluss B dynamische Daten erzeugt, die erforderlich sind, damit Testkomponente 2 in Fluss A erfolgreich ausgeführt wird. Sobald sie in Testkomponente 2 von Fluss B erzeugt sind, werden solche dynamischen Daten von Fluss B zu dem Dynamische-Daten-Inhalt-Servlet 54 abgeschickt. Wenn Fluss A zu der Testkomponente 2 fortgeschritten ist, wird der dynamische Dateninhalt, der auf dem Sync-Servlet 54 vorliegt, durch Testkomponente 2 in Fluss A wiedergewonnen. Dynamische Daten, die in Testkomponente 2 von Fluss C erzeugt werden, werden von Fluss C zu dem Dynamische-Daten-Inhalt-Servlet 54 abgeschickt. Wenn Fluss B zu Testkomponente 3 fortgeschritten ist, wird der dynamische Dateninhalt, der auf dem Sync-Servlet 54 vorliegt, durch Testkomponente 3 in Fluss B wiedergewonnen. Flüsse A, B und C können nun fortschreiten, die Ausführung abzuschließen, wobei der notwendige dynamische Dateninhalt zwischen oder unter den Flüssen A, B und C gemeinschaftlich verwendet oder übertragen wurde.
15 zeigt einen anderen Abschnitt eines Ausführungsbeispiels der vorliegenden Erfindung, wo eine Firewall 68 zwischen der aktiven Teststeuerung 60 und den Flüssen A, B und C angeordnet ist. Flüsse A, B und C werden gleichzeitig ablaufend initiiert. Jeder Fluss betreibt seine erste Testkomponente. Da die Firewall 68 zwischen der aktiven Teststeuerung 60 und den aktiven Testsonden 58, 62 und 64 angeordnet ist, kann jedoch das Dynamische-Daten-Inhalt-Servlet 54 nicht verwendet werden. Trotzdem kann bei dem Ausführungsbeispiel der vorliegenden Erfindung, das in 15 gezeigt ist, auf jegliches Dynamische-Daten-Inhalt-Servlet durch jegliche der aktiven Testsonden 58, 62 und 64 zugegriffen werden, wodurch das System 10'' wirksam gemacht wird. In 15 wird das Dynamische-Daten-Inhalt-Servlet 52 der aktiven Testsonde 58 eingesetzt, um eine solche Funktion zu erfüllen.
In 15 verursacht die Ausführung der Testkomponente 2 in Fluss B, dass Fluss B dynamische Daten erzeugt, die erforderlich sind, damit Testkomponente 2 in Fluss A erfolgreich ausgeführt wird. Sobald sie in Testkomponente 2 von Fluss B erzeugt sind, werden solche dynamischen Daten von Fluss B zu dem Dynamische-Daten-Inhalt-Servlet 52 abgeschickt. Wenn Fluss A zu Testkomponente 2 fortgeschritten ist, wird der dynamische Dateninhalt, der auf Sync-Servlet 52 vorliegt, durch Fluss A wiedergewonnen: Die Ausführung von Testkomponente 2 in Fluss C verursacht, dass Fluss C dynamische Daten erzeugt, die erforderlich sind, damit Testkomponente 3 in Fluss B erfolgreich ausgeführt wird. Sobald sie in Testkomponente 3 aus Fluss C erzeugt sind, werden solche dynamischen Daten von Fluss C zu dem Dynamische-Daten-Inhalt-Servlet 52 abgeschickt. Wenn Fluss B zu Testkomponente 3 fortgeschritten ist, wird der dynamische Dateninhalt, der auf Sync-Servlet 52 vorliegt, durch Testkomponente 3 in Fluss B wiedergewonnen. Flüsse A, B und C können nun mit dem Fertigstellen der Ausführung fortschreiten, wobei der notwendige dynamische Dateninhalt zwischen oder unter Flüssen A, B und C gemeinschaftlich verwendet oder übertragen wurde.
Schlussfolgerung
Die verteilte und automatisierte Testverwaltungsarchitektur hat viele Vorteile. Das System wird nahtlos in graphische Umgebungen integriert, die die Fähigkeit liefern, Testsequenzen zu erzeugen, wie z. B. WQM. Fachkenntnis, die erforderlich ist, um Systeme basierend auf solchen Systemen zu installieren und beizubehalten, ist einfacher verfügbar als für proprietäre Systeme. Das System reduziert Installationszeit, da die Plattformen, auf denen Software läuft, wie z. B. Web-Server und Java-Servlet-Behälter, bereits in den drahtlosen Netzwerken der Anwendungsanbieter installiert sind. Das System kann ohne weiteres konfiguriert werden, um eine Ressourcenverwaltung auszuführen, unter Verwendung offener, standardisierter Protokolle für eine Kommunikation. Zum Beispiel können die separaten aber koordinierten Flüsse, die einen Test formulieren, zugeordnete und reservierbare Ressourcen erfordern, die ausschließlich Testausführungsläufen zugeordnet sein müssen. Beispiele solcher Ressourcen umfassen mobile Schnittstellen für eine drahtlose Kommunikation oder zweckgebundene, serielle Verknüpfungen. Die Zuordnung solcher Ressourcen wird vorzugsweise durch das erfindungsgemäße System vor einer Testausführung durch die zentralisierte, aktive Teststeuerung erreicht, auch durch standardmäßige, offene Protokolle. Dies gilt für eine Vorrichtungsverwaltung für Kommunikationszugriff, Benutzerprofilzuordnung oder jegliche andere Ressourcen, die erforderlich sein könnten. Wenn der Test, der ausgeführt wird, keine Ressourcenzuordnung erfordert, benötigt die Erfindung keine direkte Ressourcenverwaltung. Die Erfindung zieht ferner einen Vorteil aus einer Ausführung mit mehreren Teilprozessen und/oder Mehrfachprozessfähigkeiten der Host-Systeme, um einen Austausch dynamischer Daten zwischen Flüssen zu ermöglichen, während andere Testausführungsschritte stattfinden, die die Fähigkeit bieten, höher entwickelte Testszenarien auszuführen (oder dieselben einfacher auszuführen) als existierende Testsysteme.
Obwohl die Erfindung Bezug nehmend auf verschiedene Ausführungsbeispiele beschrieben wurde, sollte darauf hingewiesen werden, dass diese Erfindung auch zu einer großen Vielzahl von weiteren und anderen Ausführungsbeispielen innerhalb des Schutzbereichs der Erfindung in der Lage ist.

Claims

Verfahren zum Ausführen eines Mehr-Ort-Testens in einem System (10) mit einer Teststeuerung (14) und zumindest einem ersten Fluss (24) an einem ersten entfernten Ort und einem zweiten Fluss (26) an einem zweiten entfernten Ort, das folgende Schritte aufweist: Erzeugen einer graphischen Darstellung (44, 46, 48, 50) eines Mehr-Fluss-Tests, der zumindest den ersten Fluss (24) und den zweiten Fluss (26) -zwischen Agenten (58, 50, 62) an mehreren entfernten Orten synchronisiert; Umwandeln der graphischen Darstellung (44, 46, 48, 50) in eine Text-Darstellung in einem Format eines offenen Kommunikationsstandards; Lesen der Textdarstellung, um zumindest den ersten Fluss (24) und einen zugeordneten ersten entfernten Ort, den zweiten Fluss (26) und einen zugeordneten zweiten entfernten Ort, Ressourcen, die zum Ausführen der Flüsse erforderlich sind, und die entfernten Orte der Agenten (58, 50, 62), die die Ressourcen steuern, die zum Ausführen der Flüsse erforderlich sind, zu identifizieren; Senden von Beschreibungen der entsprechenden Testsequenzen, die den ersten Fluss (24) und den zweiten Fluss (26) in einem Format eines offenen Kommunikationsstandards aufweisen, zu zumindest einem ersten Testsitzungsserver (20) an dem ersten entfernten Ort und einem zweiten Testsitzungsserver (22) an dem zweiten entfernten Ort; im Wesentlichen gleichzeitiges Initiieren von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26); Synchronisieren von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26) für eine gleichzeitig ablaufende Ausführung; und Zurückbringen der Testergebnisse nach Fertigstellung von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26).
Verfahren gemäß Anspruch 1, bei dem der Synchronisierschritt ferner das Senden von Steuermitteilungen zwischen oder unter mehrseitigen Testkomponenten aufweist, die zumindest den ersten Fluss (24) bzw. den zweiten Fluss (26) aufweisen, wobei die Steuermitteilungen ermöglichen, dass die Flüsse implizit Zeitgebungssynchronisationsinformationen und dynamisch erzeugte Daten austauschen.
Verfahren gemäß Anspruch 1 oder 2, bei dem zumindest der erste Fluss (24) und der zweite Fluss (26) unabhängig von einem Haupt-Fluss laufen.
Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem der Synchronisierschritt ferner folgende Schritte aufweist: Unterbrechen der Ausführung bei zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26); Senden eines Synchronisationssignals zu einem Sync-Server (54) von dem nichtunterbrochenen Fluss; Anfordern einer Erlaubnis zum Wiederaufnehmen der Ausführung von dem unterbrochenen Fluss zu dem Sync-Server; nach dem Empfang des Synchronisationssignals durch den Sync-Server (54), Gewähren der Erlaubnis für den unterbrochenen Fluss, die Ausführung wieder aufzunehmen; und Wiederaufnehmen der Ausführung des unterbrochenen Flusses.
Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem das System keine proprietäre Schnittstelle umfasst.
Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem ein offener, allgemeiner Kommunikationsstandard für eine Datenübertragung zum Bewirken einer Synchronisation von Flüssen eingesetzt wird.
Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem der Synchronisierschritt ferner folgende Schritte aufweist: Erzeugen von dynamischen Daten bei zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26); Abschicken der dynamischen Daten zu einem Dynamischer-Inhalt-Server (54), um abgeschickte, dynamische Daten zu erzeugen, unter Verwendung von zumindest einem offenen, allgemeinem Kommunikationsstandard; Anfordern der abgeschickten, dynamischen Daten von zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26) zu dem Dynamischer-Inhalt-Server (54); und Senden der abgeschickten, dynamischen Daten zu dem Fluss, der die abgeschickten, dynamischen Daten anfordert, von dem Dynamischer-Inhalt-Server (54).
System zum Ausführen eines Mehr-Ort-Testens, das zumindest einen ersten Fluss an einem ersten entfernten Ort und einen zweiten Fluss an einem zweiten entfernten Ort umfasst, das folgende Merkmale aufweist: eine Einrichtung zum Erzeugen einer graphischen Darstellung (44, 46, 48, 50) eines Mehr-Fluss-Tests, der zumindest den ersten Fluss (24) und den zweiten Fluss (26) zwischen Agenten (58, 50, 62) an mehreren entfernten Orten synchronisiert; eine Einrichtung zum Umwandeln der graphischen Darstellung (44, 46, 48, 50) in eine Text-Darstellung in einem Format eines offenen Kommunikationsstandards; eine Einrichtung zum Lesen der Textdarstellung, um zumindest den ersten Fluss (24) und einen zugeordneten ersten entfernten Ort, den zweiten Fluss (26) und einen zugeordneten zweiten entfernten Ort, Ressourcen, die zum Ausführen der Flüsse erforderlich sind, und die entfernten Orte der Agenten (58, 50, 62), die die Ressourcen steuern, die zum Ausführen der Flüsse erforderlich sind, zu identifizieren; eine Einrichtung zum Senden von Beschreibungen der entsprechenden Testsequenzen, die den ersten Fluss (24) und den zweiten Fluss (26) in einem Format eines offenen Kommunikationsstandards aufweisen, zu zumindest einem ersten Testsitzungsserver (20) an dem ersten entfernten Ort und einem zweiten Testsitzungsserver (22) an dem zweiten entfernten Ort; eine Einrichtung für ein im Wesentlichen gleichzeitiges Initiieren von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26); eine Einrichtung zum Synchronisieren von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26) für eine gleichzeitig ablaufende Ausführung; und eine Einrichtung zum Zurückbringen der Testergebnisse nach Fertigstellung von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26).
System gemäß Anspruch 8, bei dem die Synchronisiereinrichtung ferner eine Einrichtung aufweist zum Senden von Steuermeldungen zwischen oder unter mehrseitigen Testkomponenten, die zumindest den ersten Fluss (24) bzw. den zweiten Fluss (26) aufweisen, wobei die Steuermeldungen ermöglichen, dass die Flüsse implizit Zeitgebungssynchronisationsinformationen und dynamisch erzeugte Daten austauschen.
System gemäß einem der Ansprüche 1 bis 9, bei dem zumindest der erste Fluss und der zweite Fluss unabhängig von einem Haupt-Fluss laufen.
System gemäß einem der Ansprüche 8 bis 10, bei dem die Synchronisiereinrichtung ferner folgende Einrichtungen aufweist: eine Einrichtung zum Unterbrechen der Ausführung bei zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26); eine Einrichtung zum Senden eines Synchronisationssignals zu einem Sync-Server (54) von dem Fluss, der nicht unterbrochen ist; eine Einrichtung zum Anfordern einer Erlaubnis, die Ausführung wieder aufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Server (54); Gewähren der Erlaubnis für den unterbrochenen Fluss, die Ausführung wieder aufzunehmen, nach dem Empfang des Synchronisationssignals durch den Sync-Server (54); und eine Einrichtung zum Wiederaufnehmen der Ausführung des unterbrochenen Flusses.
System gemäß einem der Ansprüche 8 bis 11, wobei das System keine proprietäre Schnittstelle umfasst.
System gemäß einem der Ansprüche 8 bis 12, bei dem ein offener, allgemeiner Kommunikationsstandard für eine Datenübertragung eingesetzt wird, um eine Synchronisation von Flüssen zu bewirken.
System gemäß einem der Ansprüche 8 bis 13, bei dem die Synchronisiereinrichtung ferner folgend Einrichtungen aufweist: eine Einrichtung zum Erzeugen dynamischer Daten bei zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26); eine Einrichtung zum Abschicken der dynamischen Daten zu einem Dynamischer-Inhalt-Server (54), um abgeschickte, dynamische Daten zu erzeugen, unter Verwendung von zumindest einem offenen, allgemeinen Kommunikationsstandard; eine Einrichtung zum Anfordern der abgeschickten, dynamischen Daten von zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26) zu dem Dynamischer-Inhalt-Server (54); und eine Einrichtung zum Senden der abgeschickten, dynamischen Daten zu dem Fluss, der die abgeschickten, dyna mischen Daten anfordert, von dem Dynamischer-Inhalt-Server (54).
Prozessorlesbares Computerprogrammprodukt, das auf einer oder mehreren programmierbaren Speichervorrichtungen codiert ist, wobei das Computerprogrammprodukt durch einen oder mehrere Prozessoren ausführbar ist, um Verfahrensschritte auszuführen zum Ausführen eines Mehr-Ort-Testens in einem System (10) mit einer Teststeuerung (14) und zumindest einem ersten Fluss (24) an einem ersten entfernten Ort und einem zweiten Fluss (26) an einem zweiten entfernten Ort, das Anweisungen aufweist zum: Erzeugen einer graphischen Darstellung (44, 46, 48, 50) eines Mehr-Fluss-Tests, der zumindest den ersten Fluss (24) und den zweiten Fluss (26) zwischen Agenten (58, 50, 62) an mehreren entfernten Orten synchronisiert; Umwandeln der graphischen Darstellung (44, 46, 48, 50) in eine Text-Darstellung in einem Format eines offenen Kommunikationsstandards; Lesen der Textdarstellung, um zumindest den ersten Fluss (24) und einen zugeordneten ersten entfernten Ort, den zweiten Fluss (26) und einen zugeordneten zweiten entfernten Ort, Ressourcen, die zum Ausführen der Flüsse erforderlich sind, und die entfernten Orte der Agenten (58, 50, 62), die die Ressourcen steuern, die zum Ausführen der Flüsse erforderlich sind, zu identifizieren; Senden von Beschreibungen der entsprechenden Testsequenzen, die den ersten Fluss (24) und den zweiten Fluss (26) in einem Format eines offenen Kommunikationsstandards aufweisen, zu zumindest einem ersten Testsitzungsserver (20) an dem ersten entfernten Ort und einem zweiten Testsitzungsserver (22) an dem zweiten entfernten Ort; im Wesentlichen gleichzeitiges Initiieren von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26); Synchronisieren von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26) für eine gleichzeitig ablaufende Ausführung; und Zurückbringen der Testergebnisse nach Fertigstellung von zumindest dem ersten Fluss (24) und dem zweiten Fluss (26).
Computerprogrammprodukt gemäß Anspruch 15, bei dem die Anweisungen zum Ausführen des Synchronisierschritts ferner Anweisungen aufweisen zum Senden von Steuermeldungen zwischen oder unter mehrseitigen Testkomponenten, die zumindest den ersten Fluss (24) bzw. den zweiten Fluss (26) aufweisen, wobei die Steuermeldungen ermöglichen, dass die Flüsse implizit Zeitgebungssynchronisationsinformationen und dynamisch erzeugte Daten austauschen.
Computerprogrammprodukt gemäß Anspruch 15 oder 16, bei dem zumindest der erste Fluss und der zweite Fluss unabhängig von einem Haupt-Fluss laufen.
Computerprogrammprodukt gemäß einem der Ansprüche 15 bis 17, bei dem die Anweisungen zum Ausführen des Synchronisierschritts ferner Anweisungen aufweisen zum: Unterbrechen der Ausführung bei zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26); Senden eines Synchronisationssignals zu einem Sync-Server (54) von dem Fluss, der nicht unterbrochen ist; Anfordern einer Erlaubnis, die Ausführung wieder aufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Server (54); Gewähren der Erlaubnis für den unterbrochenen Fluss, die Ausführung wieder aufzunehmen, nach dem Empfang des Synchronisationssignals durch den Sync-Server (54); und Wiederaufnehmen der Ausführung des unterbrochenen Flusses.
Computerprogrammprodukt gemäß einem der Ansprüche 15 bis 18, wobei das System keine proprietäre Schnittstelle umfasst.
Computerprogrammprodukt gemäß einem der Ansprüche 15 bis 19, bei dem die Anweisungen zum Ausführen des Synchronisierschrittes ferner Anweisungen aufweisen zum: Erzeugen dynamischer Daten bei zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26); Abschicken der dynamischen Daten zu einem Dynamischer-Inhalt-Server (54), um abgeschickte, dynamische Daten zu erzeugen, unter Verwendung von zumindest einem offenen, allgemeinen Kommunikationsstandard; Anfordern der abgeschickten, dynamischen Daten von zumindest entweder dem ersten Fluss (24) oder dem zweiten Fluss (26) zu dem Dynamischer-Inhalt-Server (54); und Senden der abgeschickten, dynamischen Daten zu dem Fluss, der die abgeschickten, dynamischen Daten anfordert, von dem Dynamischer-Inhalt-Server (54).