DE102006028309A1

DE102006028309A1 - Mehrseitiges, gemeinschaftliches Verwenden von dynamischen Daten in einer drahtlosen Testumgebung

Info

Publication number: DE102006028309A1
Application number: DE102006028309A
Authority: DE
Inventors: David E. Loveland Bingham; Carolyn Loveland Darbie; Stephen Craig Loveland Booth
Original assignee: Agilent Technologies Inc
Current assignee: Viavi Solutions Inc
Priority date: 2005-08-03
Filing date: 2006-06-20
Publication date: 2007-02-15
Anticipated expiration: 2026-06-21
Also published as: GB0613590D0; DE102006028309B4; GB2428837A; US7203625B2; US20070032991A1

Abstract

Ein Verfahren zum gemeinschaftlichen Verwenden oder Übertragen dynamisch erzeugter Daten (75) zwischen oder unter mehrseitigen Testkomponenten in einer drahtlosen Umgebung wird beschrieben. Mehrere Flüsse (50, 70) werden im Wesentlichen gleichzeitig initiiert. Dynamisch erzeugte Datzen (75) werden zwischen oder unter Agenten gemeinschaftlich verwendet unter Verwendung Dynamischer-Dateninhalt-Servlets (30), die offene Kommunikationsstandards oder Protokolle verwendet, wie z. B. HTTP oder HTTPS.

Description

Die U.S.-Patentanmeldung, Seriennummer 11/195,978, eingereicht am gleichen Datum mit der Vorliegenden an Bingham u. a. mit dem Titel „Mehrseitige Synchronisation einer Ausführung in einer drahtlosen Testumgebung" mit der Agilent-Erfindungsoffenbarungsnummer 10051090, die Agilent Technologies zugewiesen ist, ist hierin durch Bezugnahme in ihrer Gesamtheit aufgenommen.
Beschreibung
Die vorliegende Erfindung bezieht sich auf eine Vorrichtung, ein System und ein Verfahren zum gemeinschaftlichen Verwenden dynamischer Daten zwischen oder unter mehrseitigen Tests und insbesondere auf eine Vorrichtung, ein System und ein Verfahren zum Testen von einem oder mehreren Netzwerken und zum gemeinschaftlichen Verwenden dynamischer Daten zwischen oder unter mehreren Flüssen in mehrseitigen Tests.
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 seine Eingabe aus 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 Telefonnetzwerken oder Systemen, Flusswasserqualitätsüberwachungseinrichtungen und Automobilverhaltenstestsysteme. Einige Netzwerke oder Systeme können geografisch und/oder zeitlich verteilt sein. 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 von drahtlosen Netzwerken gemacht wurden, bestehen bestimmte Probleme weiter. Diese umfassen eine Unfähigkeit, dynamische Daten gemeinschaftlich zwischen oder unter Flüssen oder Seiten auf offene Weise zu verwenden, die gemeinsame Standards verwendet, eine Unfähigkeit zum gemeinschaftlichen Verwenden dynamischer Daten zwischen Flüssen (oder virtuellen Teilprozessen einer Ausführung), außer wenn eine proprietäre Schnittstelle verwendet wird, und eine Unfähigkeit, drahtlose Dienste zu testen, die von der Reihenfolge der Ausführung zwischen Flüssen abhängen, außer eine proprietäre Schnittstelle ist in der Systemarchitektur umfasst.

Der drahtlose QOS-Verwalter von Agilent (WQM; Wireless QOS Manager) ist in der Lage, mehrseitige Mehrschritttests auszuführen. Die SIGOS-Ort- bzw. SIGOS-Site-Anwendung jedoch, bei der WQM gegenwärtig integriert ist, ist eine proprietäre Schnittstelle. Folglich müssen Daten, die zwischen einem Fluss und einem anderen (von einer Seite zu einer anderen) hin- und herbewegt werden, zuerst durch die proprietäre SIGOS-Ort-Infrastruktur fließen. Ein System, das getestet wird, das keine SIGOS-Ort-Infrastruktur enthält, ermöglicht das gemeinschaftliche Verwenden von dynamischen Daten zwischen oder unter Flüssen oder Seiten nicht.

Was erwünscht ist, ist ein drahtloser QOS-Verwalter mit der Fähigkeit, dynamische Daten zwischen oder unter Seiten und/oder Flüssen gemeinschaftlich zu verwenden, egal ob eine SIGOS- oder eine andere proprietäre Orts-Infrastruktur verwendet wird oder nicht.

Die nachfolgende Veröffentlichung und Patentanmeldung, die hierin durch Bezugnahme in ihrer entsprechenden Gesamtheit aufgenommen sind, offenbaren 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/cgibin/bvpub/agilent/Product/cp Product.jsp?OID=536882909&NAV ID=-536885380.536882909.00 &LANGUAGE CODE=eng&COUNTRY CODE=ZZ&CT=PRODUCT&JPID=/co mms/firehunter
U.S.-Patentveröffentlichung Seriennummer 10/736,835 mit dem Titel „Sequential Coordination of Test Execution and Dynamic Data" an Bingham.

Wie Fachleute auf dem Gebiet erkennen werden, nachdem sie die vorliegende Zusammenfassung, Figuren, detaillierte Beschreibung und Ansprüche gelesen haben, kann zumindest ein Teil der Vorrichtungen, Systeme und Verfahren, die in der vorangehenden Veröffentlichung und Patentanmeldung offenbart sind, vorteilhaft gemäß den Lehren der vorliegenden Erfindung modifiziert werden.

Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren und System zum gemeinschaftlichen Verwenden oder Übertragen dynamisch erzeugter Daten, einen Testagenten und ein Verfahren zum Herstellen desselben mit verbesserten Charakteristika zu schaffen.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1, ein System gemäß Anspruch 26, einen Testagenten gemäß Anspruch 35 und ein Verfahren zum Herstellen desselben gemäß Anspruch 38 gelöst.

Verfahren, Vorrichtungen und Systeme zum gemeinschaftlichen Verwenden oder Übertragen dynamisch erzeugter Daten zwischen oder unter mehrseitigen Testkomponenten in einer drahtlosen Umgebung werden beschrieben. Mehrere Flüsse werden im Wesentlichen gleichzeitig initiiert. Dynamisch erzeugte Daten werden gemeinschaftlich verwendet oder übertragen zwischen oder unter Agenten unter Verwendung Dynamischer-Dateninhalt-Servlets, 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, wie oben, hierin nachfolgend und in den Figuren beschrieben ist, sowie Systeme und Testagenten, die in der Lage sind, solche Verfahren zu tragen.

Bei einem Ausführungsbeispiel der vorliegenden Erfindung werden dynamische Daten 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 folgende Schritte auf: Erzeugen dynamischer Daten in zumindest entweder dem ersten Fluss oder dem zweiten Fluss; Abschicken der dynamischen Daten zu einem Dynamischer-Inhalt-Servlet, um abgeschickte, dynamische Daten zu bilden, unter Verwendung von zumindest einem offenen gemeinsamen Kommunikationsstandard; Anfordern der abgeschickten, dynamischen Daten von zumindest entweder dem ersten Fluss oder dem zweiten Fluss zu dem Dynamischer-Inhalt-Servlet; Senden der abgeschickten, dynamischen Daten zu dem Fluss, der die abgeschickten, dynamischen Daten anfordert, von dem Dynamischer-Inhalt-Servlet.

Die abgeschickten, dynamischen Daten, die in den Dynamischer-Inhalt-Servlet gespeichert sind, können ferner den Anweisungen „enter" (Eingeben), „get" (Erhalten), „remove" (Entfernen) und/oder „replace" (Ersetzen) unterzogen werden, die mit Hilfe des zuvor erwähnten, offenen, gemeinsamen Kommunikationsstandards bewirkt werden.

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

(a) Gemeinschaftliches Verwenden von dynamischen Daten zwischen oder unter mehreren Flüssen und/oder mehreren Drittparteianwendungen in einem drahtlosen Diensttest ist erlaubt unter Verwendung offener, gemeinsamer Kommunikationsstandards, wie z. B. HTTP oder XML, sogar wenn eine proprietäre Schnittstelle nicht in dem System eingesetzt wird, das getestet wird;
(b) Sicheres Übertragen oder gemeinschaftliches Verwenden dynamischer Daten unter Verwendung eines HTTPS-Protokolls;
(c) Zentralisieren von dynamischem Inhalt, was erlaubt, dass alle Flüsse auf dynamische Daten zugreifen, immer wenn es von einem bestimmten Fluss benötigt wird;
(d) Konfigurieren von Zeitbegrenzungen nach Bedarf;
(e) Ändern der Position von einem oder mehreren Dynamischer-Inhalt-Servlets, was besonders nützlich für Konfigurationen mit Firewalls ist;
(f) Betreiben Dynamischer-Inhalt-Servlets an jeglichem drahtlosen QOS-Agenten oder jeglichem Web-Server;
(g) Automatisches Löschen abgeschickter dynamischer Daten, die über eine konfigurierbare Zeit hinaus gelebt haben;
(h) Mehrere Tests, die auf spezifische dynamische Daten gleichzeitig zugreifen, zeitbasierend auf einer eindeutigen Identifikation, die für jeden angeforderten Test vorgesehen ist.

Die vorangehenden und andere Aspekte und Vorteile von verschiedenen Ausführungsbeispielen der vorliegenden Erfindung werden offensichtlich und besser verständlich, nachdem die detaillierte Beschreibung der bevorzugten Ausführungsbeispiele, die Zeichnungen und Ansprüche gelesen und verstanden wurde.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
1 ein Ausführungsbeispiel der vorliegenden Erfindung;
2 ein anderes Ausführungsbeispiel der vorliegenden Erfindung; und
3 ein wiederum anderes Ausführungsbeispiel der vorliegenden Erfindung.
1 zeigt ein Ausführungsbeispiel der vorliegenden Erfindung, wo der erste und zweite Fluss A und B in einem mehrseitigen Testsystem dynamisch erzeugte Daten mit Hilfe von offenen Kommunikationsstandards gemeinschaftlich verwenden und/oder übertragen, unter Verwendung von Sync-Servlets 20, 30 und 40, die jeweils in der aktiven Testsonde 50, die Fluss A entspricht, der aktiven Teststeuerung 60 bzw. der aktiven Testsonde 70, die Fluss B entspricht, angeordnet sind.
Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist jede der aktiven Testsonde 50, der aktiven Teststeuerung 60 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 Dynamischer-Inhalt-Servlets 20 und 40 in 1 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 1 ist Fluss A durch Testkomponente 1 (Test Component; TC), Testkomponente 2 und Testkomponente 3 in der aktiven Testsonde 50 dargestellt. Fluss B ist durch Testkomponente 1, Testkomponente 2 und Testkomponente 3 in der aktiven Testsonde 70 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 1 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 30 abgeschickt. Wenn Fluss A zu Testkomponente 3 fortgeschritten ist, wird der Dynamische-Daten-Inhalt, der auf dem Sync-Servlet 30 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:test1 (Flow = Fluss) in 1 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 30 ab. FlowA:test3 erhält dann den Benutzernamen und das Passwort von dem Dynamischer-Inhalt-Servlet 30 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 1 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 1 kann jedes der Dynamische-Daten-Inhalt-Servlets 20, 30 und 40 ein Programm mit mehreren Teilprozessen bzw. ein verkettetes Programm sein, das auf jeglichem der Agenten 50, 60 und 70 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 70 und nicht 50 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 vorliegen den Erfindung können die Agenten 50, 60 und 70 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 werden, um das Betreiben mehrerer Servlets zu vermeiden, wie in 1 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 ein HTTP-Post oder ein 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 ein HTTP-Post (Post = abschicken) ermöglicht das Senden eines Datenkörpers und auch den Empfang einer Antwort.
Der Datenkörper, der durch ein 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 1 dargestellt ist, werden nachfolgend in Beispiel 1 aufgeführt, wo Textdarstellungen eines Dynamische-Daten-Inhalt-Servlet-Eingangsschemas gezeigt sind. Während die Dynamische-Daten-Inhalt-Servlet-Implementierung, die hierin nachfolgend ausgeführt wird, 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-Servlet 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.
Beispiel 1: Wqm-Sync-Servlet-Schnittstellenentwurf
(A) Eingabe- und Ausgabe-Schnittstelle zu dem Dynamischer-Inhalt-Servlet
(1) Beschreibung
Das Dynamischer-Inhalt-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. –
– (Zeichenfolge) Voreinstellung ist dieselbe wie das Attribut Host (ATC). –
– (ganze Zahl) Voreinstellung ist 16716 –
– (ganze Zahl) Voreinstellung 0 (einmal Nachsehen, kein Warten) –
– (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.
–
– 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 jdkl.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"-Anforderungssyntax 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 </Aktion>
– </DcsRequest>

(7) Antwort-Syntax ausgeben, wenn keine Ausnahme

– </DcsResponse> – <UniqueId>chainId</UniqueId> – <Action> (Aktion von Anforderung) </Aktion> – <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 Ausführen von Einheitstests an der tatsächlichen Schnittstelle.

Die Dynamischer-Inhalt-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 Dynamischer-Inhalt-Servlets und ihren entsprechenden Testkomponenten ausgeführt werden. Ferner sind Schemata der vorliegenden Erfindung nicht auf XML beschränkt; andere Markup- („Etiketten"-) Sprachen und entsprechende Testkomponenten können ebenfalls eingesetzt werden.
2 zeigt ein anderes Ausführungsbeispiel 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 30 abgeschickt. Wenn Fluss A zu der Testkomponente 2 fortgeschritten ist, wird der dynamische Dateninhalt, der auf dem Sync-Servlet 30 vorliegt, durch Testkomponente 2 in Fluss A wieder genommen. Dynamische Daten, die in Testkomponente 2 von Fluss C erzeugt werden, werden von Fluss C zu dem Dynamische-Daten-Inhalt-Servlet 30 abgeschickt. Wenn Fluss B zu Testkomponente 3 fortgeschritten ist, wird der dynamische Dateninhalt, der auf dem Sync-Servlet 30 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.
3 zeigt ein anderes Ausführungsbeispiel der vorliegenden Erfindung, wo eine Firewall 100 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 100 zwischen der aktiven Teststeuerung 60 und den aktiven Testsonden 50, 70 und 80 angeordnet ist, kann jedoch das Dynamische-Daten-Inhalt-Servlet 30 nicht verwendet werden. Trotzdem kann bei dem Ausführungsbeispiel der vorliegenden Erfindung, das in 3 gezeigt ist, auf jegliches Dynamische-Daten-Inhalt-Servlet durch jegliche der aktiven Testsonden 50, 70 oder 80 zugegriffen werden, wodurch das System 10 wirksam gemacht wird. In 3 wird das Dynamische-Daten-Inhalt-Servlet 20 der aktiven Testsonde 50 eingesetzt, um eine solche Funktion zu erfüllen.
In 3 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 20 abgeschickt. Wenn Fluss A zu Testkomponente 2 fortgeschritten ist, wird der dynamische Dateninhalt, der auf Sync-Servlet 20 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 20 abgeschickt. Wenn Fluss B zu Testkomponente 3 fortgeschritten ist, wird der dynamische Dateninhalt, der auf Sync-Servlet 20 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.
Verschiedene Protokolle werden hierin beschrieben, wie z. B. XML, HTTP und HTTPS. Die vorliegende Erfindung ist jedoch nicht auf solche Protokolle beschränkt und berücksichtigt ausdrücklich die Verwendung anderer Protokolle, wie z. B. FTP („File Transfer Protocol"), 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.118, 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 Gemeinschaftsverwendungs- oder Übertragungs-Verfahren für dynamische Daten der vorliegenden Erfindung ausgeführt unter Verwendung eines Agilent QoS (QoS = „Quality of Service") Manager Agent (Verwaltungsagent), wobei viele Aspekte desselben beschrieben sind unter:
http://we.home.agilent.com/cgibin/bvpub/agilent/Product/cp_Product.jsp?OID=536882909&NAV_ID=-36885380.536882909.00&LANGUAGE_CODE=eng&COUNTRY_CODE=ZZ &CT=PRODUCT&JPID=/comms/firehunter.
Es wird darauf hingewiesen, dass bestimmte Aspekte und Anwendungen verschiedener Ausführungsbeispiele der vorliegenden Erfindung in den Vorrichtungen, Systemen und Verfahren eingesetzt werden können, die in der U.S.-Patenanmeldung Seriennummer 10/736,835 mit dem Titel „Sequential Coordination of Test Execution and Dynamic Data" an Bingham offenbart sind, die hierin durch Bezugnahme in ihrer Gesamtheit aufgenommen ist.
Obwohl einige Ausführungsbeispiele der vorliegenden Erfindung gezeigt und beschrieben wurden, werden Fachleute auf dem Gebiet erkennen, dass Änderungen an solchen Ausführungsbeispielen ausgeführt werden können, ohne von dem Schutzbereich und Wesen der Erfindung abzuweichen, deren Schutzbereich in den beiliegenden Ansprüchen und ihren Entsprechungen definiert ist. Zum Beispiel fällt ein System oder Agent, der ein oder mehrere Gemeinschaftsverwendungs- oder Übertragungs-Verfahren für dynamische Daten der vorliegenden Erfindung mit Hilfe von einem oder mehreren Stellvertretern ausführt, in den Schutzbereich der vorliegenden Erfindung.

Claims

Verfahren zum gemeinschaftlichen Verwenden oder Übertragen dynamisch erzeugter Daten zwischen oder unter mehrseitigen Testkomponenten in einem System mit zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), das folgende Schritte aufweist: Erzeugen dynamischer Daten (75) in zumindest entweder dem ersten Fluss oder dem zweiten Fluss (70); Abschicken der dynamischen Daten (75) zu einem Dynamischer-Inhalt-Servlet (30), um abgeschickte, dynamische Daten zu bilden, unter Verwendung von zumindest einem offenen gemeinsamen Kommunikationsstandard; Anfordern der abgeschickten, dynamischen Daten (75) von zumindest entweder dem ersten Fluss oder dem zweiten Fluss zu dem Dynamischer-Inhalt-Servlet (30); Senden der abgeschickten, dynamischen Daten (75) zu dem Fluss, der die abgeschickten, dynamischen Daten (75) anfordert, von dem Dynamischer-Inhalt-Servlet (30).
Verfahren gemäß Anspruch 1, das ferner das Eingeben der dynamischen Daten (75) in das Dynamischer-Inhalt-Servlet (30) aufweist.
Verfahren gemäß Anspruch 1 oder 2, das ferner das Erhalten der dynamischen Daten (75) von dem Dynamischer-Inhalt-Servlet (30) aufweist.
Verfahren gemäß einem der Ansprüche 1 bis 3, das ferner das Entfernen der dynamischen Daten (75) aus dem Dynamischer-Inhalt-Servlet (30) aufweist.
Verfahren gemäß einem der Ansprüche 1 bis 4, das ferner das Ersetzen der dynamischen Daten (75) in dem Dynamischer-Inhalt-Servlet (30) aufweist.
Verfahren gemäß einem der Ansprüche 1 bis 5, das ferner das im Wesentlichen gleichzeitige Initiieren des ersten Flusses (50) und des zweiten Flusses (70) aufweist.
Verfahren gemäß Anspruch 6, das ferner das Unterbrechen der Ausführung bei zumindest entweder dem ersten Fluss (50) oder dem zweiten Fluss (70) aufweist.
Verfahren gemäß Anspruch 7, das ferner das Senden eines Synchronisationssignals zu einem Sync-Servlet (30) von dem Fluss, der nicht unterbrochen ist, aufweist.
Verfahren gemäß Anspruch 8, das ferner das Anfordern einer Erlaubnis, um die Ausführung wiederaufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Servlet (30), aufweist.
Verfahren gemäß Anspruch 9, das ferner das Gewähren der Erlaubnis für den unterbrochenen Fluss, die Ausführung wieder aufzunehmen, auf einen Empfang des Synchronisationssignals durch das Sync-Servlet (30) hin, aufweist.
Verfahren gemäß Anspruch 10, das ferner das Wiederaufnehmen der Ausführung des unterbrochenen Flusses aufweist.
Verfahren gemäß Anspruch 11, bei dem das Sync-Servlet (30) ein Signal „Await Sync" von dem unterbrochenen Fluss empfängt.
Verfahren gemäß Anspruch 11 oder 12, bei dem das Synchronisationssignal, das von dem Sync-Servlet (30) empfangen wird, ein Signal „Send Sync" ist.
Verfahren gemäß einem der Ansprüche 1 bis 13, bei dem das System ein drahtloses System ist.
Verfahren gemäß einem der Ansprüche 1 bis 14, das ferner aufweist, das System einer Mehrzahl von Funktionstests zu unterziehen.
Verfahren gemäß einem der Ansprüche 1 bis 15, bei dem das System keine proprietäre Schnittstelle umfasst.
Verfahren gemäß einem der Ansprüche 1 bis 16, bei dem ein offener, allgemeiner Kommunikationsstandard aus der Gruppe ausgewählt ist, die aus HTTP, HTTPS, FTP, SCP und SFTP besteht.
Verfahren gemäß einem der Ansprüche 1 bis 17, bei dem Schemata, ausgewählt aus der Gruppe bestehend aus XML, einer Markup-Sprache und einem Klartext eingesetzt werden, um das gemeinschaftliche Verwenden oder Übertragen von dynamisch erzeugten Daten zu bewirken.
Verfahren gemäß einem der Ansprüche 1 bis 18, bei dem eine Stelle des Dynamischer-Inhalt-Servlets (30) spezifiziert wird.
Verfahren gemäß Anspruch 19, bei dem die Stelle des Dynamischer-Inhalt-Servlets verändert wird.
Verfahren gemäß einem der Ansprüche 1 bis 20, bei dem das Dynamischer-Inhalt-Servlet (30) auf einem drahtlosen QOS-Agenten betrieben wird.
Verfahren gemäß einem der Ansprüche 1 bis 21, bei dem das Dynamischer-Inhalt-Servlet (30) auf einem Webserver betrieben wird.
Verfahren gemäß einem der Ansprüche 1 bis 22, bei dem das Dynamischer-Inhalt-Servlet (30) konfiguriert ist, um zumindest eines aus einer HTTP-Post, einer HTTPS-Post, einer FTP-Post und einer SCP-Post und einer SFTP-Post zu akzeptieren.
Verfahren gemäß einem der Ansprüche 1 bis 23, bei dem das Dynamischer-Inhalt-Servlet (30) XML-codierte Post akzeptiert, um Daten einzugeben, zu erhalten, zu entfernen, zu modifizieren oder zu ersetzen.
Verfahren gemäß einem der Ansprüche 1 bis 24, bei dem das Dynamischer-Inhalt-Servlet (30) ferner eine Sync-Servlet-Inhalt-Funktionalität aufweist.
System zum gemeinschaftlichen Verwenden oder Übertragen dynamisch erzeugter Daten zwischen oder unter mehrseitigen Testkomponenten in einem System mit zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), das folgende Merkmale aufweist: eine Einrichtung zum Erzeugen dynamischer Daten (75) in zumindest entweder dem ersten Fluss oder dem zweiten Fluss (70); eine Einrichtung zum Abschicken der dynamischen Daten (75) zu einem Dynamischer-Inhalt-Servlet (30), um abgeschickte, dynamische Daten zu bilden, unter Verwendung von zumindest einem offenen gemeinsamen Kommunikationsstandard; eine Einrichtung zum Anfordern der abgeschickten, dynamischen Daten (75) von zumindest entweder dem ersten Fluss oder dem zweiten Fluss zu dem Dynamischer-Inhalt-Servlet (30); eine Einrichtung zum Senden der abgeschickten, dynamischen Daten (75) zu dem Fluss, der die abgeschickten, dynamischen Daten (75) anfordert, von dem Dynamischer-Inhalt-Servlet (30).
System gemäß Anspruch 26, das ferner eine Einrichtung zum im Wesentlichen gleichzeitigen Initiieren von zumindest dem ersten Fluss (50) und dem zweiten Fluss (70) aufweist.
System gemäß Anspruch 27, das ferner eine Einrichtung zum Unterbrechen der Ausführung bei zumindest entweder dem ersten Fluss (50) oder dem zweiten Fluss (70) aufweist.
System gemäß Anspruch 28, das ferner eine Einrichtung zum Senden eines Synchronisationssignals zu einem Sync-Servlet (30) von dem Fluss, der nicht unterbrochen ist, aufweist.
System gemäß Anspruch 29, das ferner eine Einrichtung zum Anfordern einer Erlaubnis, um die Ausführung wiederaufzunehmen, von dem unterbrochenen Fluss zu dem Sync-Servlet (30), aufweist.
System gemäß Anspruch 30, das ferner eine Einrichtung zum Gewähren der Erlaubnis für den unterbrochenen Fluss, die Ausführung wieder aufzunehmen, auf einen Empfang des Synchronisationssignals durch das Sync-Servlet (30) hin, aufweist.
System gemäß Anspruch 31, das ferner eine Einrichtung zum Wiederaufnehmen der Ausführung des unterbrochenen Flusses aufweist.
System gemäß einem der Ansprüche 26 bis 32, wobei das System konfiguriert ist, um drahtlose Systeme zu testen, die unter zumindest entweder dem Standard wifi 802.11a, dem Standard wifi 802.11b, dem Standard wifi 802.11g, dem wimax-Standard, dem GSM/GPRS-Standard oder dem CDMA-Standard arbeiten.
System gemäß einem der Ansprüche 26 bis 33, wobei das System konfiguriert ist, um ein Drahtleitungssystem zu testen, das aus der Gruppe ausgewählt ist, die aus einem LAN-Netzwerk und einem Einwählnetzwerk besteht.
Testagent zum Verursachen der entfernten gemeinschaftlichen Verwendung oder Übertragung dynamisch erzeugter Daten zwischen oder unter mehrseitigen Testkomponenten in einem System mit zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), der folgende Schritte aufweist: eine Einrichtung zum Verursachen, dass dynamische Daten (75) in zumindest entweder dem ersten Fluss oder dem zweiten Fluss (70) erzeugt werden; eine Einrichtung zum Verursachen, dass dynamische Daten (75) zu einem Dynamischer-Inhalt-Servlet (30) abgeschickt werden, um abgeschickte, dynamische Daten zu bilden, unter Verwendung von zumindest einem offenen gemeinsamen Kommunikationsstandard; eine Einrichtung zum Verursachen, dass eine Anforderung, die in zumindest entweder dem ersten Fluss oder dem zweiten Fluss (70) erzeugt wird, die abgeschickten, dynamischen Daten (75) wiedergewinnt, die erzeugt und zu dem Dynamischer-Inhalt-Servlet (30) gesendet werden sollen; eine Einrichtung zum Verursachen, dass die abgeschickten, dynamischen Daten (75) zu dem Fluss gesendet wer den, der die abgeschickten, dynamischen Daten (75) anfordert.
Testagent gemäß Anspruch 35, wobei der Testagent konfiguriert ist, um drahtlose Systeme zu testen, die unter zumindest entweder dem Standard wifi 802.11a, dem Standard wifi 802.11b, dem Standard wifi 802.11g, dem wimax-Standard, dem GSM/GPRS-Standard oder dem CDMA-Standard arbeiten.
Testagent gemäß Anspruch 35 oder 36, wobei der Testagent konfiguriert ist, um ein Drahtleitungssystem zu testen, das aus der Gruppe ausgewählt ist, die aus einem LAN-Netzwerk und einem Einwählnetzwerk besteht.
Verfahren zum Herstellen eines Testagenten zum Verursachen der entfernten gemeinschaftlichen Verwendung oder Übertragung dynamisch erzeugter Daten zwischen oder unter mehrseitigen Testkomponenten in einem System mit zumindest einem ersten Fluss (50) und einem zweiten Fluss (70), wobei der Testagent eine Einrichtung zum Verursachen, dass dynamische Daten (75) in zumindest entweder dem ersten Fluss oder dem zweiten Fluss (70) erzeugt werden, eine Einrichtung zum Verursachen, dass dynamische Daten (75) zu einem Dynamischer-Inhalt-Servlet (30) abgeschickt werden, um abgeschickte, dynamische Daten zu bilden, unter Verwendung von zumindest einem offenen gemeinsamen Kommunikationsstandard, eine Einrichtung zum Verursachen, dass eine Anforderung, die in zumindest entweder dem ersten Fluss oder dem zweiten Fluss (70) erzeugt wird, die abgeschickten, dynamischen Daten (75) wiedergewinnt, die erzeugt und zu dem Dynamischer-Inhalt-Servlet (30) gesendet werden sollen, und eine Einrichtung zum Verursachen, dass die abgeschickten, dynamischen Daten (75) zu dem Fluss gesendet werden, der die abgeschickten, dynamischen Daten (75) anfordert, aufweist, wobei das Verfahren folgende Merkmale aufweist: Bereitstellen der Einrichtung zum Verursachen, dass dynamische Daten (75) in zumindest entweder dem ersten Fluss oder dem zweiten Fluss (70) erzeugt werden; Bereitstellen der Einrichtung zum Verursachen, dass dynamische Daten (75) zu einem Dynamischer-Inhalt-Servlet (30) abgeschickt werden, um abgeschickte, dynamische Daten zu bilden; Bereitstellen der Einrichtung zum Verursachen, dass die Anforderung, die in zumindest entweder dem ersten Fluss oder dem zweiten Fluss (70) erzeugt wird, die abgeschickten, dynamischen Daten (75) wiedergewinnt, die erzeugt und zu dem Dynamischer-Inhalt-Servlet (30) gesendet werden sollen; Bereitstellen der Einrichtung zum Verursachen, dass die abgeschickten, dynamischen Daten (75) zu dem Fluss gesendet werden, der die abgeschickten, dynamischen Daten (75) anfordert; wirksames Anordnen und Verbinden der vorangehenden Einrichtungen zum Erzeugen des Testagenten.
Verfahren gemäß Anspruch 38, bei dem der Testagent konfiguriert ist, um den Fluss aus dynamisch erzeugten Daten zwischen oder unter mehrseitigen Testkomponenten entfernt zu synchronisieren.
Verfahren gemäß Anspruch 39, bei dem der Testagent konfiguriert ist, um drahtlose Systeme zu testen, die unter zumindest entweder dem Standard wifi 802.11a, dem Standard wifi 802.11b, dem Standard wifi 802.11g, dem wimax-Standard, dem GSM/GPRS-Standard oder dem CDMA-Standard arbeiten.
Verfahren gemäß Anspruch 39 oder 40, bei dem der Testagent konfiguriert ist, um ein Drahtleitungssystem zu testen, das aus der Gruppe ausgewählt ist, die aus einem LAN-Netzwerk und einem Einwählnetzwerk besteht.