DE102005028926B4 - Fehlertolerantes Modulartesten von Diensten - Google Patents
Fehlertolerantes Modulartesten von Diensten Download PDFInfo
- Publication number
- DE102005028926B4 DE102005028926B4 DE102005028926A DE102005028926A DE102005028926B4 DE 102005028926 B4 DE102005028926 B4 DE 102005028926B4 DE 102005028926 A DE102005028926 A DE 102005028926A DE 102005028926 A DE102005028926 A DE 102005028926A DE 102005028926 B4 DE102005028926 B4 DE 102005028926B4
- Authority
- DE
- Germany
- Prior art keywords
- test
- error
- sequence
- service
- stack
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012360 testing method Methods 0.000 claims abstract description 208
- 238000000034 method Methods 0.000 claims abstract description 33
- 230000015556 catabolic process Effects 0.000 claims abstract description 17
- 238000006731 degradation reaction Methods 0.000 claims abstract description 17
- 230000002441 reversible effect Effects 0.000 claims abstract description 9
- 230000000694 effects Effects 0.000 claims abstract description 5
- 239000000523 sample Substances 0.000 claims description 16
- 238000004891 communication Methods 0.000 claims description 9
- 230000006870 function Effects 0.000 claims description 7
- 230000007547 defect Effects 0.000 claims 1
- 230000008569 process Effects 0.000 description 10
- 101100202428 Neopyropia yezoensis atps gene Proteins 0.000 description 7
- 230000008859 change Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 230000009471 action Effects 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 238000005065 mining Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 230000003542 behavioural effect Effects 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010304 firing Methods 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012806 monitoring device Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000001558 permutation test Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
- Computer And Data Communications (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
sequentielles Bestücken eines Fehlerstapels (120) mit einem Testmodulidentifizierer (128), der einem Testmodul einer Sequenz (110) ausgeführter zustandsverändernder Testmodule (112) zugeordnet ist, die auf eine Vorrichtung (106) wirken, die mit einem Dienst in Wechselwirkung steht;
auf das Auftreten eines Auslösefehlers während einer Ausführung der Sequenz zustandsverändernder Testmodule hin, Laufen lassen der Testmodule, die in dem Fehlerstapel (120) identifiziert sind, in einer umgekehrten Reihenfolge, um so einen strukturierten Abbau der Testsequenz zu bewirken; und
Wiederholen der vorherigen Schritte, bis die sequentielle Ausführung von Testmodulen abgeschlossen ist oder auf einen Auslösefehler getroffen wird.
Description
- Die Integration von Internet-Diensten und mobilen Kommunikationen war ein wichtiger Entwicklungsschritt in der Geschichte der Kommunikationsdienste. Mit zunehmendem Bedarf nach mobilen Netzdiensten (einschließlich sprach- und paketbasierten IP-Daten) steigt auch der Bedarf, die Dienstgüte (QoS = Quality of Service), die durch 2G-, 2,5G- und 3G-Netzdienste bereitgestellt wird, zu charakterisieren (nach Durchsatz, Verzögerung, Verzögerungsvariation, Dienstverfügbarkeit, Paketverlustraten, Zuverlässigkeits- und Prioritätsmessungen). Derartige Netze verwenden eine breite Vielzahl heterogener Protokolle (z. B. WAP, GSM, UMTS, Hypertext-Transferprotokoll/HTTP, Kurznachrichtendienst/SMS, Generalpaketfunkdienste/GPRS, usw.), um eine Konnektivität zwischen einem Endbenutzer und den erwünschten Diensten zu schaffen.
-
1 stellt den physischen Entwurf eines Systemrahmens dar, der verwendet werden kann, um die QoS eines auf einem Netz100 bereitgestellten Dienstes zu testen. Bediener in einem Dienstoperationszentrum (SOC) oder Netzoperationszentrum (NOC)102 , die in Kommunikation mit einem drahtlosen QoS-Verwalter104 stehen, wie z. B. dem drahtlosen QoS-Verwalter von Agilent TechnologiesTM, erzeugen strukturierte Netz-QoS-Tests. Die QoS wird oft mit einem aktiven Testen gekennzeichnet, bei dem eine oder mehrere Testsonden106 eine Benutzeroperation einer Vorrichtung simulieren und dabei versuchen, mit dem Dienst in Wechselwirkung zu stehen (als durch Server101 durch ein Gateway103 bereitgestellt gezeigt) und währenddessen Messungen zu nehmen. Die aktiven Testsonden (ATP = Active Test Probe) werden durch eine Aktivteststeuerung (ATC = Active Test Controller)108 gesteuert, die in Kommunikation mit dem Verwalter104 steht. -
2 spiegelt eine graphische Darstellung eines QoS-Modells wider, das überwachte Dienste beschreibt und zeigt, wie dieselben organisiert sind. Wie durch die hierarchische Anordnung nahegelegt ist, muss der Testcode zur Durchführung des QoS-Testens, das zur Charakterisierung eines oder mehrerer Netzdienste benötigt wird, oft in einer strukturierten Sequenz110 von Testmodulen112 ausgeführt werden, da eine Wechselwirkung mit dem Netzdienst ein Einrichten bestimmter „Zustände” erfordert, wie z. B. ein Initialisieren einer Vorrichtung, ein Einrichten einer Verbindung, ein Anmelden bei einem Server. - Fehler, die auftreten, während eine Client-Vorrichtung (durch eine Testsonde
106 simuliert) sich in einem bestimmten Zustand befindet, können zu einer Anzahl unerwünschter Ereignisse führen. Wenn sich z. B. ein Client nicht bei einem Sitzungs-Account „abmeldet”, bevor er seinen Test beendet, könnte dem nächsten Test ein Zugriff auf dasselbe Account verwehrt werden. Mehrere unterschiedliche Ansätze zur Handhabung des Auftretens von Fehlern während der Ausführung eines Netzdienstetestens wurden unternommen. Einige verlassen einfach einen Test, bei dem ein Fehler auftritt, was den Dienst (oder Server) in einem unbekannten Zustand hinterlässt, der Fehler für nachfolgende Tests, die den Dienst verwenden, einführen kann. Einige Verfahren führen Tests unter Verwendung eines „Testschritt”-Ansatzes aus, überlassen eine Fehlerhandhabung jedoch den einzelnen Testschritten, was in einigen Umständen erfolgreich sein könnte, sobald jedoch ein Zustand durch einen Testschritt eingerichtet wurde, besitzt ein nachfolgender Testschritt keinen klaren und einfachen Mechanismus zum Rückruf in den früheren Zustandserzeugungsschritt zum Rücksetzen des Zustands. Komplexere Fehlerhandhabungsroutinen wurden ebenso geschrieben und kundenspezifisch eingerichtet, erfordern jedoch eine Kenntnis der genauen auszuführenden Testsequenz, um in der Lage zu sein, den Zustand von jedem beliebigen Punkt während des Tests, an dem der Fehler auftritt, wiederherzustellen. - Eine Netzverwaltung beinhaltet oft ein Überwachen verschiedener Netz-Teilsysteme (z. B. GPRS) durch Netzbediener. Wenn ein Zusammenbruch in dem Netz auftritt, bestehen viele herkömmliche ATCs
108 keinen Test, der zur Ausführung geplant ist, nach dem Test, bei dem der Fehler aufgetreten ist, da die ATC der vorgeschriebenen Testsequenz, durch den Fehler nicht abgeschreckt, folgt. So könnte eine Menge von Fehlernachrichten an Überwachungsvorrichtungen verschiedener Aspekte des Netzes gesendet werden, die tatsächlich vielleicht korrekt arbeiten. Selbst potentiell transiente Fehlernachrichten können negative Wirkungen auf eine Netz-QoS-Überwachung besitzen, was den Fehleridentifizierungsvorgang durcheinanderbringt und möglicherweise zu einem Abschalten ordnungsgemäß funktionierender Netzelemente führt. - Trotz der Vorteile der Fehlerhandhabungsansätze und Testsysteme, die oben erläutert wurden, bleibt eine Wiedergewinnung aus Fehlern, auf die während eines Netztestens getroffen wird, zerrüttend und da derartige Systeme keinen automatisierten Einfluss auf existierende Testoperationsmodule, können sie in Bezug auf die Ressourcen, die benötigt werden, um Quellen der aufgefundenen Fehler genauer zu identifizieren, kostspielig sein.
- Aus der
EP 1401147 A1 ist ein Verfahren zum Messen von Netzwerkbetriebsparametern in einem Internet-Netzwerk. Ein Paket, das einen ersten Überwachungspunkt in einem Netzwerk passiert, wird ausgewählt, entsprechend einer Fähigkeit einer Datenstrukturdefinition des Pakets, zusätzliche Informationen in das Paket zu packen. Gemäß der Datenstrukturdefinition werden dann zusätzliche Informationen in das Paket gepackt und das Paket verschickt. Beim Passieren eines zweiten Überwachungspunkts wird das Paket gemäß dem Vorliegen der Informationen wieder ausgewählt, die Informationen werden beobachtet und verwendet, um ein Mß für den Netzwerkbetriebsparameter zu implementieren. - Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren zum fehlertoleranten Modulartesten von Diensten oder ein computerlesbares Medium mit verbesserten Charakteristika zu schaffen.
- Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 oder ein computerlesbares Medium gemäß Anspruch 11 gelöst.
- Die vorliegende Erfindung schafft ein Verfahren zum Ausführen einer strukturierten Sequenz von Abbauoperationen, die automatisch kompiliert werden, während eine entsprechende Sequenz von Zustandsveränderungs-Testschritten ausgeführt wird. Das Verfahren ist auf jede Sequenz von Testschritten anwendbar, die ein Aufbauen und Abbauen von Zuständen beinhaltet, wie z. B. Kommunikationsverbindungen zwischen Client-Vorrichtungen und Servern. Die vorliegende Erfindung schafft ein Verfahren zum automatischen Verwalten derartiger Zustände in der Testsequenz, so dass der ordnungsgemäße „Abbau” in dem Fall eines Fehlers erzielt werden kann. Das Verfahren erzeugt automatisch die korrekte Abbausequenz mit fortschreitender Testsequenz, so dass eine geeignete Fehlerbehebung bzw. -wiedergewinnung unabhängig davon, wann ein Fehler auftritt, erzielt werden kann. Ferner ist der Abbaumechanismus implizit in die Testmodule, die die Testsequenz aufweisen, eingebaut. So muss ein Testentwickler sich nicht mit der Fehlerhandhabung befassen, die implizit durch die Testsequenzierung und die Ausführungsumgebung gehandhabt wird, d. h. die Erfindung arbeitet automatisch für neue Testfallsequenzen, die durch den Testentwickler erzeugt werden, unter Verwendung wiederverwendbarer Testmodule bei der Testerzeugung.
- Der geordnete Abbau stellt ein ordnungsgemäßes Rücksetzen des Zustandes und Freigeben aller Ressourcen in den Zustand vor dem Auftreten eines anderweitig nicht behebbaren Systemfehlers durch eine Sequenz mehrerer Inkrementalaktionen sicher, was den Bedarf der Ausführung eines Gesamttestneustarts überflüssig macht. Die vorliegende Erfindung erlaubt es, dass jedes Testmodul inhärent die korrekte Fehleraktion definieren kann, die unternommen werden soll, um die durch das Testmodul bewirkte Zustandsänderung umzukehren.
- Die vorliegende Erfindung erlaubt Konsistenzprüfungen bei der Testsequenz, um sicherzustellen, dass die Fehlerhandhabermodule vorhanden sind und in der korrekten Reihenfolge platziert sind, was einen Benutzerfehler reduziert, während Testsequenzen Von Modulen aufgebaut werden.
- Die vorliegende Erfindung schafft einen Datenaufbau, der im Folgenden als ein Fehlerstapel bezeichnet wird, der automatisch mit Testmodulidentifizierern bestückt wird, die jeweils einem einer Sequenz ausgeführter Zustandsveränderungs-Testmodule entsprechen, die auf eine Vorrichtung wirken, die in Wechselwirkung mit dem zu testenden Dienst (SUT) steht. Die Testmodule könnten Fehler spezifizieren, auf die unter Umständen getroffen wird, deren Auftreten eine Ausführung der Sequenz von Tests nicht anhalten soll. Wenn die Vorrichtung auf einen Fehler trifft, der nicht unter diesen aufgelisteten „annehmbaren” Fehlern ist, wird eine Ausführung der Testsequenz angehalten und der strukturierte Abbauvorgang beginnt. Der Abbauvorgang hebt in einer Zuletzt-Hinein-Zuerst-Hinaus-(LIFO-)Reihenfolge die Namen von Testmodulen, die laufen gelassen werden sollen, von dem Fehlerstapel ab, um den Aufbauzustand steuerbar umzukehren.
- Bei unten beschriebenen bevorzugten Ausführungsbeispielen werden das erfindungsgemäße Verfahren und ein Softwaresteuervorgang beim Testen der QoS eines oder mehrerer Dienste eingesetzt, die durch ein drahtloses Kommunikationsnetz bereitgestellt werden, was eine Fehlertoleranz und eine genauere Fehleridentifizierung schafft und ein Senden fremder Fehlernachrichten an Überwachungsvorrichtungen von Netzdiensten reduziert oder beseitigt.
- Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert, wobei gleiche Bezugszeichen sich in allen Zeichnungen auf gleiche Elemente beziehen. Es zeigen:
-
1 eine Darstellung eines Netzdienst-QoS-Testsystems, bei dem ein Ausführungsbeispiel der vorliegenden Erfindung eingesetzt werden könnte; -
2 eine Darstellung einer geordneten Testmodulsequenz und eines möglichen Datenflusses in einem QoS-Testsystem, in dem die vorliegende Erfindung eingesetzt werden könnte; -
3 eine Darstellung der Testumgebung, die die Datenstrukturen und Computermerkmale einer Teststeuerung in der Umgebung detaillierter zeigt; -
4 ein Flussdiagramm eines strukturierten Abbauverfahrens gemäß der vorliegenden Erfindung; und -
5A bis5G Darstellungen einer exemplarischen Testmodulsequenzausführung und von Drauflegen- und Abheben-Operationen (Push- und Pop-Operationen) bei einem Fehlerstapel, der Zustandsveränderungen zugeordnet ist, die durch die Testmodulausführungen bewirkt werden. - Die vorliegende Erfindung schafft ein Verfahren und eine Vorrichtung zum fehlertoleranten Modulartesten von Diensten. Wie der Ausdruck „Dienste” hierin verwendet wird, bedeutet er Anwendungen, die durch eine oder mehrere Kommunikationen oder inhaltsbereitstellende Computer, die durch ein Netz zugänglich sind, bereitgestellt werden. Der Ausdruck „Zustand”, wie er hierin definiert ist, bedeutet eine Bedingung der Testsonde oder des zu testenden Dienstes, die erzielt wird, nachdem ein zustandsbildendes oder zustandsveränderndes Test-„Modul” laufen gelassen wird, was z. B. zu einer Veränderung der Vorrichtung von einem ausgeschalteten in einen angeschalteten Zustand führt, oder zu einem Wechseln von einem unterbrochenen in einen verbundenen Zustand, einem Initialisieren der Vorrichtung, einem Anmelden bei einem Server und/oder anderen zustandsabhängigen Anforderungen (Stateful Requests). Wie der Ausdruck „Modul” hierin verwendet wird, bedeutet er eine Serie einer Operation computerausführbarer Instruktionen, um einen bestimmten Zweck zu erzielen, der Ausdruck „Stapel” bedeutet ein Array oder einen anderen Datenaufbau, das/der in der Lage ist, eine Sequenz von Daten zu speichern und dynamisch zu erhalten. Die Beschreibung bevorzugter drahtloser Netz-QoS-Testausführungsbeispiele unten soll keinesfalls einschränkend sein, da das Konzept eines strukturierten Abbaus von Zuständen/Verbindungen auf das Auftreten eines nicht behebbaren Fehlers hin auf eine breite Vielzahl von Betriebsumgebungen angewendet werden könnte, einschließlich Drahtleitungs- und Datenverarbeitungs-Netze, die mehrere heterogene Protokolle verwenden (z. B. PSTN oder ISDN, WiFi-Netzzugang, CDMA oder GSM-Internet-Zugang, usw.), und/oder andere verbindungsorientierte Anwendungen.
- Architektur der Betriebsumgebung
- Bezug nehmend auf
1 ist eine Umgebung, in der die vorliegende Erfindung eingesetzt werden könnte, beim Testen von Diensten, die durch ein Netz100 bereitgestellt werden. Das Netz könnte jeder Typ von Netz sein, wird hierin jedoch als ein drahtloses Netz beschrieben, das GPRS- und WAP-Protokoll verwendet. Eine oder mehrere Testsonden106 werden verwendet, um Endbenutzer zu simulieren, die versuchen, auf einen durch das Netz100 bereitgestellten Dienst zuzugreifen und/oder mit demselben in Wechselwirkung zu stehen, wobei hierbei Informationen über den relativen Erfolg des Testens und Netzdienstverhaltensmetriken (wie z. B. Zeitgebungsverzögerung, usw.) erfasst werden. Diese Informationen könnten aufgezeichnet und/oder zur Anzeige an einen oder mehrere Bediener eines SOC oder NOC102 , die das Netz-QoS-Testen überwachen, übertragen werden, und/oder verwendet werden, um eine bestimmte Form von Korrekturaktion zum Angehen von Netzüberlastbedingungen oder Netzausrüstungsfehlfunktionen auszulösen. - Die Bediener eines derartigen Testsystems könnten eine geordnete Testsequenz
110 (in2 als „drahtlose Testkette” bezeichnet) von Testmodulen112 durch Wechselwirkungen mit einer graphischen Benutzerschnittstelle eines diagnostischen Verwaltungssystems (DMS)104 , wie z. B. des drahtlosen Dienstgüte-Verwalters (WQM) von Agilent TechnologiesTM, oder durch weniger automatisierte alternative Verfahren eines Aufbauens strukturierter Sequenzen von Testfällen entwickeln. - Das DMS
104 dient als das Depot für die Konfigurationsdaten der einen oder der mehreren Testsequenzen (es gibt üblicherweise mehr als eine geordnete Testsequenz110 oder „Kette”) und Messergebnisse. Tests und ihre zugeordneten Testmodule112 werden an der ATC108 und den ATPs106 gespeichert. Das DMS104 bestimmt, welche Testkette (identifiziert, was „fließt”, oder Sequenzen und Teilsequenzen von Tests) die Aktivteststeuerung (ATC)108 bei den Testsonden106 ausführen soll, und befördert die Testkette während eines Testens durch eine Schnittstelle (wie z. B. ein Internet-Netz) zu der ATC, wobei die Schnittstelle wiederum jeden Fluss in der Kett an die ATPs106 herunterlädt. Eine Steuersoftware auf jeder ALP106 führt die geeigneten Testmodule aus und erzeugt und verwaltet dabei einen Fehlerstapel für jeden Fluss in der Kette. - Unter Bezugnahme auf
3 ist die ATC108 vorzugsweise als ein Computer, ein Arbeitsplatzrechner, ein Minicomputer, ein Hauptrechner oder ein anderes System zur Ausführung einer Software implementiert und kann sich lokal oder entfernt in Bezug auf die ATPs106 befinden. Jede ATP106 umfasst eine zentrale Verarbeitungseinheit114 zur Ausführung einer Steuerprozesssoftware116 , die die Test- bzw. Prüfsonden steuert. Vorzugsweise ist die Steuerprozesssoftware116 in einem Speicher118 gespeichert, der dem Computer zugeordnet ist. Bei einem bevorzugten Ausführungsbeispiel ist der Quellencode der Steuerprozesssoftware116 in der Java-Programmiersprache geschrieben und wird auf den Betriebssystemen (OS) Linux oder Windows/2000 ausgeführt, die vorliegende Erfindung ist jedoch keineswegs auf derartige Implementierungen beschränkt. Die Steuerprozesssoftware führt die geordnete Testmodulsequenz110 aus und erzeugt zusätzlich einen Fehlerstapel120 für jeden Fluss in der Kette und führt ein Drauflegen bzw. Abheben von Informationen zu/von dem Fehlerstapel, der auf die ausführenden Testmodule bezogen ist, durch, wie unten noch detaillierter beschrieben wird. Die Testkette und der Fehlerstapel120 sind vorzugsweise als Instanzen von Objekten in einem Array implementiert, die geeignetste Datenstruktur jedoch hängt von der verwendeten Sprache ab. Es wird darauf verwiesen, dass jedes der Testmodule112 sowie die Steuerprozesssoftware116 eine geordnete Auflistung ausführbarer Instruktionen zum Implementieren von Logikfunktionen aufweisen und über eine Kommunikationsverbindung verteilt sein können oder in einem computerlesbaren Medium zur Verwendung, zum Transport und lokalen Beladen ausgeführt sein können. In dem Zusammenhang der vorliegenden Erfindung kann ein „computerlesbares Medium” jedes Mittel sein, das das Programm zur Verwendung durch oder in Verbindung mit dem Instruktionsausführungssystem, dem -gerät oder der -vorrichtung enthalten, speichern, kommunizieren, weiterleiten oder transportieren kann. Das computerlesbare Medium kann z. B., jedoch nicht ausschließlich, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, ein -gerät, eine -vorrichtung oder ein Ausbreitungsmedium sein. Spezifischere Beispiele (eine nicht ausschließliche Liste) des computerlesbaren Mediums würden folgendes umfassen: eine elektrische Verbindung (elektronisch) mit einem oder mehreren Drähten, eine tragbare Computerdiskette (magnetisch), einen Direktzugriffsspeicher (RAM) (magnetisch), einen Nur-Lese-Speicher (ROM) (magnetisch), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM oder Flash-Speicher) (magnetisch), eine optische Faser (optisch) und einen tragbaren Kompaktplatten-Nur-Lese-Speicher (CDROM)(optisch). Es wird ferner angemerkt, dass, obwohl die geordnete Testsequenz110 , der Fehlerstapel120 und die Steuersoftware116 als sich auf der ALP befindlich dargestellt sind, Fachleute auf diesem Gebiet ohne weiteres erkennen werden, dass andere Konfigurationen klar möglich sind. - Wie durch die Testmodulnamen (z. B. Vorrichtung-Initialisieren, Gprs-Verbinden, WapGW-Verbinden, Nachrichten-Senden, usw.), die in der in
2 dargestellten Testsequenzhierarchie widergespiegelt werden, nahegelegt wird, sind die meisten (jedoch nicht notwendigerweise alle) Testmodule112 wiederverwendbar und führen Operationen durch, die auf verschiedene Komponenten bezogen sind, die den gegenwärtigen „Zustand” der Sonde oder des zu testenden Diensts in Bezug auf den Client verändern, wie z. B. in dem Zusammenhang des beschriebenen Ausführungsbeispiels, Tests, die eine Verbindung einrichten, Tests, die eine Verbindung zu WAP-Sites herstellen können und Daten „holen” oder „aufgeben”, und Tests, die Nachrichten senden oder empfangen können. Eine breite Vielzahl von Protokollen könnte in dem Dienstetestsystem der vorliegenden Erfindung eingesetzt werden, einschließlich, jedoch nicht ausschließlich, WAP, HTTP, E-Mail, SMS, GPRS, MMS, usw. -
2 stellt lediglich ein Beispiel für Funktionskomponenten und einen Datenaustausch in dem QoS-Testsystem dar. Die Sequenz von Testmodulen112 , einschließlich Vorrichtung-Initialisieren112-1 , Gprs-Verbinden112-2 , WapGW-Verbinden112-4 , Nachrichten-Senden112-5 , WapGW-Trennen112-6 , Gprs-Trennen112-7 , Push-Nachricht-Empfangen112-8 und Vorrichtung-Freigeben112-9 , wird durch die Steuertestsoftware116 der vorliegenden Erfindung ausgeführt. Jedes der Testmodule könnte einen internen Code oder einen externen Code126 aufweisen, der dynamisch Daten122 erzeugt, die durch die ATPs106 erfasst werden könnten. Diese Daten könnten in einem Testsitzungsdatenspeicher124 gespeichert und von demselben durch dieses und nachfolgende Testmodule in der hierarchischen Testsequenz wiedergewonnen werden (vorzugsweise Speicher der ATP) und könnten durch die Operationen der Testmodule dynamisch verändert werden. Die Daten können analysiert werden, um Fehlernachrichten zu erzeugen, oder könnten die Form von Netzdienst-QoS-Metriken (z. B. Verhaltensdaten, wie z. B. Verzögerung, Zuverlässigkeit und andere Parameter) annehmen. Die erfassten Daten könnten auch gemeinschaftlich mit der ATC108 (oder anderen ATPs) verwendet und durch dieselben gespeichert werden. Die ATPs106 könnten Erfolg-/Fehler-Informationen erzeugen, einschließlich Daten, wie z. B. Anzeigen dafür, wann Fehler während des Testens aufgetreten sind, sowie erfasste Metriken in der Form regulärer Ausdrücke (Name-Wert-Paare, wie z. B. Nachrichtensendezeit.Wert, Nachrichtenpasswort.Wert, Bestätigungszeit.Wert, usw.) oder ein anderes geeignetes Datenformat, das wiederum geeignete Aktionen durch die Steuersoftware116 auslösen könnte, wie z. B. Drauflegen/Abheben bei dem Fehlerstapel120 , Übertragung von Nachrichten an das DMS104 und Ferndienstüberwachungsvorrichtungen an dem SOC oder Netzüberwachungsvorrichtungen an dem NOC102 und/oder lokale oder entfernte Warnindikatoren. - Algorithmus eines strukturierten Abbaus
- Die Funktionsweise der Steuersoftware
116 wird nun Bezug nehmend auf4 , die ein Verfahren eines umkehrbaren Zustandsaufbaus und -abbaus gemäß der vorliegenden Erfindung darstellt, sowie Bezug nehmend auf die5A –5G , die durch ein Beispiel die Kettenverarbeitung der Testmodule112 und die Wirkung von Drauflegen-/Abheben-Operationen, die der Verarbeitung und der Systemfehlerhandhabung zugeordneten sind, auf den Fehlerstapel120 darstellen, beschrieben. - Bei Schritt
200 wird die Testkette, die geordnete Sequenzen (oder Flüsse) von Testmodulnamen spezifiziert, erzeugt. Wie oben angemerkt wurde, weist die Testkette vorzugsweise eine objektausgerichtete Liste von Namen von Testmodulen112 auf, die durch Verwalter oder hochentwickelte Dienstbediener bei dem SOC oder NOC102 durch eine Wechselwirkung mit Graphikeinrichtungen eines diagnostischen Verwaltungssystems104 , wie z. B. des WQM-Systems, erzeugt werden könnten. - Bei Schritt
202 wird die Beschreibung der Testsequenzen durch die ATC108 in die ATP106 geladen. Wie oben angemerkt wurde, geschieht das Laden vorzugsweise durch eine Übertragung von dem DMS104 . Die Kette verarbeitet eine Ausführung der Testmodule mit einem oder mehreren Flüssen und führt jedes Modul sequentiell innerhalb eines Flusses aus. - Bei Schritt
204 beginnt die ATP106 eine Ausführung der Steuersoftware116 , die den Fehlerstapel120 initialisiert. - Bei Schritt
206 lässt die Steuersoftware116 das erste (oder nächste) Testmodul112 auf der ATP106 in der in der Testkette spezifizierten Sequenz laufen. Bei diesem Ausführungsbeispiel legt die ATC alle Testeigenschaften, die zum Laufen lassen eines Tests erforderlich sind, wie z. B. die Testbeschreibung, den Namen, Anmelde-/Netzinformationen und andere Informationen, auf die eine oder die mehreren ATPs. - Bei Schritt
208 wird eine Bestimmung durchgeführt, ob das gerade ausgeführte Testmodul zu einem erfolgreichen Test geführt hat. Die Kette prüft einen „Status”-Wert, der durch jedes Testmodul zurückgegeben wird. Wenn der Test erfolgreich war, d. h. wenn Status.Erfolg=„wahr”, kehrt die Verarbeitung zu Schritt206 zurück und das nächste Testmodul in der Testkette wird laufen gelassen. Das Auftreten eines „Auslöse”-Fehlers während der Ausführung des Testmoduls startet den Abbauvorgang (Schritt212 ). Bei bestimmten Ausführungsbeispielen ist der „Auslöse”-Fehler ein beliebiger Fehler, der während der Ausführung des Testmoduls auftritt, optional jedoch könnten einige Fehler spezifiziert sein, die den Abbau nicht auslösen. Bei derartigen Ausführungsbeispielen, wie durch einen optionalen Schritt210 dargestellt wird, könnte eine weitere Bestimmung durchgeführt werden, ob der angetroffene Fehler ein Auslösefehler ist, der weitere Versuche, auf den zu testenden Dienst zuzugreifen oder mit demselben in Wechselwirkung zu stehen, anhalten soll. Jedes Testmodul enthält eine Liste „annehmbarer” Fehler, die angetroffen werden könnten, die weitere Diensttests nicht anhalten und keinen Abbau auslösen sollen. Bei dem durch die Anmelder implementierten System sind derartige Fehler für jedes Testmodul in einem modulspezifischen Modulparameter FortfahrenbeiFehler aufgelistet. Wenn ein derartiger Nichtauslösefehler während der Ausführung eines Testmoduls angetroffen wird, d. h. wenn Status.Erfolg=„falsch”, und der angetroffene Fehler mit einem der Fehler übereinstimmt, die durch den Parameter FortfahrenbeiFehler aufgelistet sind, kehrt die Verarbeitung für die Ausführung des nächsten sequentiellen Testmoduls zurück zu Schritt206 . Wenn ein Fehler während des Testens auftritt, sollen alle Testsondenmessungen, die vor dem Fehler durchgeführt wurden, aufgezeichnet werden. In jedem Fall wird eine Beschreibung des aufgetretenen Fehlers von den Sonden an die ATC geleitet. - Wenn der durch die ATP
106 angetroffene Fehler ein Auslösefehler ist, d. h. keiner, der mit den aufgelisteten FortfahrenbeiFehler-Fehlern übereinstimmt, die eine weitere sequentielle Testmodulausführung und einen Aufbau von Zustand/Verbindung erlauben, beginnt bei Schritt212 die ATP einen strukturierten Abbau von Zustand/Verbindung der einen oder der mehreren Sonden. Zusätzlich berichtet die Testsequenz110 eine Nachricht eines nicht behebbaren Fehlers (an das DMS). Der strukturierte Abbau wird durch die ATP durch ein Ausführen der Testmodule, die in dem Fehlerstapel120 identifiziert sind, in einer Zuletzt-Hinein-Zuerst-Hinaus(LIFO-)Reihenfolge durchgeführt. Wenn z. B. eine Verbindung mit einem WAP-Gateway-Server aufgebaut wurde, sollte die Testsonde die Verbindung ordnungsgemäß abbauen, bevor der Test endet. Ähnlich sollte der Benutzer sich, wenn er sich bei einem Dienst angemeldet hat und dann auf einen Fehler trifft, der den Test beenden sollte, vor dem Verlassen abmelden. Ein derartiger strukturierter Abbau ermöglicht es dem nächsten Test in einer Textfolge, unbelastet durch Fehler, die durch den vorherigen Test angetroffen werden, fortzufahren. Die Kette steuert den strukturierten Abbau und könnte ein erforderliches „Schluß-Aufräumen” basierend auf Testergebnissen durchführen, die durch ausgeführte Testmodule auf „falsch” gesetzt sind. - Bei Schritt
214 wird der Fehlerstapel geprüft, um zu bestimmen, ob zusätzliche Testmodulidentifizierer in dem Fehlerstapel verbleiben, wobei, wenn zusätzliche Identifizierer verbleiben, der nächste Testmodulidentifizierer in der LIFO-Reihenfolge aus dem Fehlerstapel abgehoben wird und eine Verarbeitung zu Schritt212 zurückkehrt, um das identifizierte Testmodul auszuführen. - Das erfindungsgemäße Verbindungs-/Zustands-Abbau-Verfahren ermöglicht eine genauere Fehleridentifizierung gegenüber SOC- oder NOC-Überwachungsvorrichtungen, was die Anzahl fremder und/oder transienter Fehlersignale, die von Tests nach einem fehlgeschlagenen Test empfangen werden, reduziert. Die ATP bei der vorliegenden Erfindung überspringt im Grunde eine Ausführung der nachfolgenden Testmodule, die andernfalls nach nicht erfolgreichen Versuchen, auf den gerade diagnostizierten Netzdienst zuzugreifen oder mit demselben in Wechselwirkung zu stehen, Fehlernachrichten senden würden, und führt stattdessen in der LIFO-Reihenfolge Testmodule aus, die in dem Fehlerstapel identifiziert sind, die den aufgebauten Zustand abbauen.
- Die
5A –5G stellen eine exemplarische Ausführung der einfachen Testkette110 aus2 und die zugeordneten Informationen, die bei dem Fehlerstapel120 während der Sequenztestmodulausführungen durchgeführt werden, dar. Dieser bestimmte Testplan würde, wenn er erfolgreich ohne Fehler ausgeführt würde oder nur auf FortfahrenbeiFehler-Fehler treffen würde, eine entfernte (Mobilfunk-)Vorrichtung anweisen, eine Nachricht zurück an die Testsonde106 zu senden, die die Testmodulsequenz durchführt. - Während der Zustand/Verbindung-Aufbauschritte (
206 –210 ) des oben beschriebenen Verfahrens führt die Steuersoftware in der ATP, wenn die Module sequentiell ausgeführt werden, vor einem Starten der Ausführung eines Moduls ein „Drauflegen” eines zugeordneten Testmodulidentifizierers128 für den Fehlerhandhaber des Moduls auf den Fehlerstapel120 durch. Nur Zustand-Erzeugen/-Modifizieren-Module spezifizieren Fehlerhandhaber. Bei der vorliegenden Implementierung umfasst jedes Testmodul M, das in der Lage ist, eine Zustands- oder Verbindungsveränderung zu bewirken, einen Fehlerhandhaber-Parameter, der das entsprechende Testmodul identifiziert, das den Zustand oder die Verbindung, der/die durch M eingerichtet wurde, umkehrt. Jedes Mal, wenn ein Fehlerhandhaber-Parameter für ein bestimmtes Modul „m” vorliegt (oder nicht leer ist), legt die Kette110 den Identifizierer128 des Testmoduls (durch den Fehlerhandhaber gegeben) auf den Fehlerstapel120 drauf, bevor das Modul M eine Ausführung abgeschlossen hat (bedeutet, dass Zustand/Verbindung eingerichtet wurde). Die5A –5D stellen die drauflegenden Fehlerhandhaber-Testmodulnamen Vorrichtung-Freigeben128-1 , Gprs-Trennen128-2 und WapGW-Trennen128-4 auf den Fehlerstapel120 nach einem erfolgreichen Abschluss der entsprechenden Testmodule Vorrichtung-Initialisieren112-1 , Gprs-Verbinden112-2 und WapGW-Verbinden112-4 dar. Es wird angemerkt, dass Nachrichten-Senden112-5 eine einfache Nachricht ist und kein zustandveränderndes Testmodul und so keinen Fehlerhandhaber auf den Stapel drauflegt. - Wenn ein Fehler gefunden wurde, der nicht mit einem FortfahrenbeiFehler für dieses Modul übereinstimmt (oder ein beliebiger Fehler bei alternativen Ausführungsbeispielen), würde ein strukturierter Abbau eingeleitet werden (Schritten
212 –214 bei dem oben beschriebenen Verfahren entsprechend). Wie oben beschrieben ist, wird dies durch ein Abheben der Namen (Modulidentifizierer128 ) von dem Fehlerstapel120 und ein Ausführen derselben in einer LIFO-Reihenfolge erzielt. Jedes Mal, wenn ein Modul A die Ausführung abschließt, führt die Kette eine Prüfung durch, um zu sehen, ob A mit dem Namen des Testmoduls oben auf dem Fehlerstapel120 übereinstimmt. Wenn eine Übereinstimmung vorliegt, hebt die Kette A von dem Fehlerstapel120 ab. Auf diese Weise wird der Fehlerstapel in einer umgekehrten Reihenfolge entleert, um denselben mit dem Zustand des Testflusses konsistent zu halten. - Obwohl die Erfindung Bezug nehmend auf verschiedene Ausführungsbeispiele beschrieben wurde, sollte zu erkennen sein, dass diese Erfindung auch zu einer breiten Vielzahl weiterer und anderer Ausführungsbeispiele innerhalb der Wesensart und des Schutzbereichs der beigefügten Ansprüche in der Lage ist.
Claims (20)
- Verfahren zum fehlertoleranten modularen Testen von Diensten, mit folgenden Schritten: sequentielles Bestücken eines Fehlerstapels (
120 ) mit einem Testmodulidentifizierer (128 ), der einem Testmodul einer Sequenz (110 ) ausgeführter zustandsverändernder Testmodule (112 ) zugeordnet ist, die auf eine Vorrichtung (106 ) wirken, die mit einem Dienst in Wechselwirkung steht; auf das Auftreten eines Auslösefehlers während einer Ausführung der Sequenz zustandsverändernder Testmodule hin, Laufen lassen der Testmodule, die in dem Fehlerstapel (120 ) identifiziert sind, in einer umgekehrten Reihenfolge, um so einen strukturierten Abbau der Testsequenz zu bewirken; und Wiederholen der vorherigen Schritte, bis die sequentielle Ausführung von Testmodulen abgeschlossen ist oder auf einen Auslösefehler getroffen wird. - Verfahren gemäß Anspruch 1, bei dem: der Auslösefehler sich nicht unter annehmbaren Fehlern in einer Liste annehmbarer Fehler befindet.
- Verfahren gemäß Anspruch 1 oder 2, bei dem die Vorrichtung eine aktive Netzsonde ist, die in Kommunikation mit einem Netz steht, der Dienst ein Netzdienst ist und die Sequenz zustandsverändernder Tests wirkt, um die Dienstgüte des Netzdienstes zu testen.
- Verfahren gemäß einem der Ansprüche 1 bis 3, das ferner den Schritt eines Erzeugens des Fehlerstapels aufweist.
- Verfahren gemäß einem der Ansprüche 1 bis 4, das ferner den Schritt eines Ausführens eines oder mehrerer nicht zustandsverändernder Tests, die unter die Sequenz ausgeführter zustandsverändernder Tests gestreut sind, ohne Veränderung des Fehlerstapels (
120 ) aufweist. - Verfahren gemäß einem der Ansprüche 1 bis 5, das ferner den Schritt eines Erfassens von Daten, die für die Ausführung jedes Testmoduls relevant sind, aufweist.
- Verfahren gemäß einem der Ansprüche 1 bis 6, das ferner des Schritt eines Aufzeichnens der erfassten Daten vor dem Auftreten des Auslösefehlers aufweist.
- Verfahren gemäß Anspruch 7, bei dem die Daten eine Bestanden/Fehlgeschlagen-Nachricht, die den Erfolg/Fehlschlag dieses Tests anzeigt, Anzeigen, wann während der Testsequenz ein Fehler aufgetreten ist, und/oder Metriken, die auf das Verhalten des Dienstes bezogen sind, aufweisen.
- Verfahren gemäß einem der Ansprüche 1 bis 8, bei dem der Schritt des sequentiellen Bestückens ferner ein Drauflegen der Testidentifizierungsinformationen jedes Tests auf den Fehlerstapel (
120 ) vor einem Starten dieses Tests aufweist. - Verfahren gemäß einem der Ansprüche 1 bis 9, bei dem der Schritt des Laufen lassens in umgekehrter Reihenfolge ferner ein Abheben des Testmodulidentifizierers jedes erfolgreich ausgeführten Testmoduls von dem Fehlerstapel (
120 ) aufweist. - Computerlesbares Medium, das ein Programm speichert, das, wenn es durch einen Computer ausgeführt wird, bewirkt, dass der Computer die Funktionen ausführt, die folgendes aufweisen: sequentielles Bestücken eines Fehlerstapels (
120 ) mit einem Testmodulidentifizierer (128 ), der einem Testmodul einer Sequenz (110 ) ausgeführter zustandsverändernder Testmodule (112 ) zugeordnet ist, die auf eine Vorrichtung (106 ) wirken, die mit einem Dienst in Wechselwirkung steht; auf das Auftreten eines Auslösefehlers während einer Ausführung der Sequenz zustandsverändernder Testmodule hin, Laufen lassen der Testmodule (112 ), die in dem Fehlerstapel (120 ) identifiziert sind, in einer umgekehrten Reihenfolge, um so einen strukturierten Abbau der Testsequenz zu bewirken; und Wiederholen der vorherigen Schritte, bis die sequentielle Ausführung von Testmodulen abgeschlossen ist oder ein Auslösefehler angetroffen wird. - Medium gemäß Anspruch 11, bei dem: jedes der Testmodule eine Anzeige annehmbarer Fehler enthält; und der Auslösefehler einen Fehler aufweist, der sich nicht unter den annehmbaren Fehlern befindet.
- Medium gemäß Anspruch 11 oder 12, bei dem die Vorrichtung eine aktive Netzsonde ist, die in Kommunikation mit einem Netz steht, der Dienst ein Netzdienst ist und die Sequenz zustandsverändernder Tests wirkt, um die Dienstgüte des Netzdienstes zu testen.
- Medium gemäß einem der Ansprüche 11 bis 13, das ferner den Schritt eines Erzeugens des Fehlerstapels (
120 ) aufweist. - Medium gemäß einem der Ansprüche 11 bis 14, bei dem die Funktionen ferner ein Ausführen eines oder mehrerer nicht zustandsverändernder Tests, die unter die Sequenz ausgeführter zustandsverändernder Tests gestreut sind, ohne Veränderung des Fehlerstapels aufweisen.
- Medium gemäß einem der Ansprüche 11 bis 15, bei dem die Funktionen ferner ein Erfassen von Daten, die für die Ausführung jedes Testmoduls relevant sind, aufweisen.
- Medium gemäß Anspruch 16, bei dem die Daten eine Bestanden/Fehlgeschlagen-Nachricht, die den Erfolg/Fehlschlag dieses Tests anzeigt, Anzeigen, wann während der Testsequenz ein Fehler aufgetreten ist, und/oder Metriken, die auf das Verhalten des Dienstes bezogen sind, aufweisen.
- Medium gemäß einem der Ansprüche 11 bis 17, bei dem die Funktionen ferner ein Aufzeichnen der erfassten Daten vor dem Auftreten des Auslösefehlers aufweisen.
- Medium gemäß einem der Ansprüche 11 bis 18, bei dem die Funktion des sequentiellen Bestückens ferner ein Drauflegen der Testidentifizierungsinformationen jedes Tests auf den Fehlerstapel (
120 ), bevor dieser Test beginnt, aufweist. - Medium gemäß einem der Ansprüche 11 bis 19, bei dem die Funktion des Laufen lassens in umgekehrter Reihenfolge ferner ein Abheben des Testmodulidentifizierers jedes erfolgreich ausgeführten Testmoduls von dem Fehlerstapel (
120 ) aufweist.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/958,049 | 2004-10-04 | ||
US10/958,049 US7246276B2 (en) | 2004-10-04 | 2004-10-04 | Error tolerant modular testing of services |
Publications (2)
Publication Number | Publication Date |
---|---|
DE102005028926A1 DE102005028926A1 (de) | 2006-04-13 |
DE102005028926B4 true DE102005028926B4 (de) | 2011-06-01 |
Family
ID=35395086
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE102005028926A Active DE102005028926B4 (de) | 2004-10-04 | 2005-06-22 | Fehlertolerantes Modulartesten von Diensten |
Country Status (3)
Country | Link |
---|---|
US (1) | US7246276B2 (de) |
DE (1) | DE102005028926B4 (de) |
GB (1) | GB2418755A (de) |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7502965B2 (en) * | 2005-02-07 | 2009-03-10 | Broadcom Corporation | Computer chip set having on board wireless interfaces to support test operations |
US8095982B1 (en) | 2005-03-15 | 2012-01-10 | Mu Dynamics, Inc. | Analyzing the security of communication protocols and channels for a pass-through device |
US8095983B2 (en) * | 2005-03-15 | 2012-01-10 | Mu Dynamics, Inc. | Platform for analyzing the security of communication protocols and channels |
US9172611B2 (en) * | 2006-09-01 | 2015-10-27 | Spirent Communications, Inc. | System and method for discovering assets and functional relationships in a network |
US7958230B2 (en) | 2008-09-19 | 2011-06-07 | Mu Dynamics, Inc. | Test driven deployment and monitoring of heterogeneous network systems |
US8316447B2 (en) | 2006-09-01 | 2012-11-20 | Mu Dynamics, Inc. | Reconfigurable message-delivery preconditions for delivering attacks to analyze the security of networked systems |
US7774637B1 (en) * | 2007-09-05 | 2010-08-10 | Mu Dynamics, Inc. | Meta-instrumentation for security analysis |
DE102007054648B4 (de) * | 2007-11-15 | 2010-07-29 | Siemens Ag | Fehler-Identifikation in einem rechner-basierten Netzwerk |
US8547974B1 (en) | 2010-05-05 | 2013-10-01 | Mu Dynamics | Generating communication protocol test cases based on network traffic |
US8463860B1 (en) | 2010-05-05 | 2013-06-11 | Spirent Communications, Inc. | Scenario based scale testing |
US9106514B1 (en) | 2010-12-30 | 2015-08-11 | Spirent Communications, Inc. | Hybrid network software provision |
US8464219B1 (en) | 2011-04-27 | 2013-06-11 | Spirent Communications, Inc. | Scalable control system for test execution and monitoring utilizing multiple processors |
US8972543B1 (en) | 2012-04-11 | 2015-03-03 | Spirent Communications, Inc. | Managing clients utilizing reverse transactions |
DE102012211902B4 (de) * | 2012-07-09 | 2021-04-29 | Rohde & Schwarz GmbH & Co. Kommanditgesellschaft | Testgerät und Verfahren zum Protokoll-Testen mit einer Spielkartenmetapher |
US11567846B2 (en) | 2019-10-17 | 2023-01-31 | Cyara Solutions Pty Ltd | System and method for contact center fault diagnostics |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1401147A1 (de) * | 2002-09-16 | 2004-03-24 | Agilent Technologies, Inc. - a Delaware corporation - | Messung operationeller Netzwerkparameter wie sie von operationellem Netzwerkverkehr wahrgenommen werden |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5170464A (en) | 1990-01-26 | 1992-12-08 | International Business Machines Corporation | Method for rolling back an expert system |
JPH0772866B2 (ja) | 1990-01-26 | 1995-08-02 | インターナショナル・ビジネス・マシーンズ・コーポレイション | エキスパート・システムの状態を巻戻す方法及びシステム |
US5838899A (en) * | 1994-09-20 | 1998-11-17 | Stratus Computer | Digital data processing methods and apparatus for fault isolation |
US5864657A (en) | 1995-11-29 | 1999-01-26 | Texas Micro, Inc. | Main memory system and checkpointing protocol for fault-tolerant computer system |
US6247118B1 (en) | 1998-06-05 | 2001-06-12 | Mcdonnell Douglas Corporation | Systems and methods for transient error recovery in reduced instruction set computer processors via instruction retry |
US6317788B1 (en) | 1998-10-30 | 2001-11-13 | Hewlett-Packard Company | Robot policies for monitoring availability and response of network performance as seen from user perspective |
FI108599B (fi) | 1999-04-14 | 2002-02-15 | Ericsson Telefon Ab L M | Toipuminen matkaviestinjärjestelmissä |
US6453440B1 (en) * | 1999-08-04 | 2002-09-17 | Sun Microsystems, Inc. | System and method for detecting double-bit errors and for correcting errors due to component failures |
US6701342B1 (en) | 1999-12-21 | 2004-03-02 | Agilent Technologies, Inc. | Method and apparatus for processing quality of service measurement data to assess a degree of compliance of internet services with service level agreements |
US6587973B1 (en) * | 2000-02-22 | 2003-07-01 | Oak Technology, Inc. | Method and apparatus for implementing fault tolerant logic in a storage system |
US20030236826A1 (en) | 2002-06-24 | 2003-12-25 | Nayeem Islam | System and method for making mobile applications fault tolerant |
US7209851B2 (en) * | 2003-02-14 | 2007-04-24 | Advantest America R&D Center, Inc. | Method and structure to develop a test program for semiconductor integrated circuits |
-
2004
- 2004-10-04 US US10/958,049 patent/US7246276B2/en active Active
-
2005
- 2005-06-22 DE DE102005028926A patent/DE102005028926B4/de active Active
- 2005-09-30 GB GB0519978A patent/GB2418755A/en not_active Withdrawn
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1401147A1 (de) * | 2002-09-16 | 2004-03-24 | Agilent Technologies, Inc. - a Delaware corporation - | Messung operationeller Netzwerkparameter wie sie von operationellem Netzwerkverkehr wahrgenommen werden |
Also Published As
Publication number | Publication date |
---|---|
US7246276B2 (en) | 2007-07-17 |
DE102005028926A1 (de) | 2006-04-13 |
US20060085723A1 (en) | 2006-04-20 |
GB2418755A (en) | 2006-04-05 |
GB0519978D0 (en) | 2005-11-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE102005028926B4 (de) | Fehlertolerantes Modulartesten von Diensten | |
DE69825571T2 (de) | System und verfahren zur überwachung verteilter anwendungen | |
CN104731580B (zh) | 基于Karaf与ActiveMQ的自动化运维***及其实现方法 | |
DE3879071T2 (de) | Verwaltung einer defekten Hilfsquelle in einem Multiplex-Kommunikationssystem. | |
DE3879069T2 (de) | Schwellenalarme zur Verarbeitung von Fehlern in einem Multiplex-Kommunikationssystem. | |
DE3879072T2 (de) | Expertsystem zur Verarbeitung von Fehlern in einem Multiplex-Kommunikationssystem. | |
DE60017457T2 (de) | Verfahren zur isolierung eines fehlers in fehlernachrichten | |
DE102018113625A1 (de) | Fehlerinjektionstestvorrichtung und -verfahren | |
CN110046073B (zh) | 一种日志采集方法及装置、设备、存储介质 | |
WO2004079553A2 (en) | System, method and model for autonomic management of enterprise applications | |
CN111881014B (zh) | 一种***测试方法、装置、存储介质及电子设备 | |
CN113760704A (zh) | Web UI的测试方法、装置、设备以及存储介质 | |
CN111026602A (zh) | 一种云平台的健康巡检调度管理方法、装置及电子设备 | |
CN111813671A (zh) | 一种ima软件仿真测试*** | |
CN112134754A (zh) | 压力测试方法、装置、网络设备及存储介质 | |
CN110990289B (zh) | 一种自动提交bug的方法、装置、电子设备及存储介质 | |
CN110609761B (zh) | 确定故障源的方法、装置、存储介质和电子设备 | |
CN111639022A (zh) | 交易测试方法及装置、存储介质、电子装置 | |
CN116467188A (zh) | 一种多环境场景下的通用本地复现***和方法 | |
CN110069382A (zh) | 软件监控方法、服务器、终端设备、计算机设备及介质 | |
CN115759518A (zh) | 基于混沌工程的可用性治理*** | |
CN113495750B (zh) | 一种设备的升级检测方法、装置及服务器 | |
CN114385498A (zh) | 性能测试方法、***、计算机设备及可读存储介质 | |
CN115543491A (zh) | 微服务处理方法和装置 | |
DE69808734T2 (de) | Vorrichtung und Verfahren für die Ferndiagnose von Datenverarbeitungseinheiten |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8127 | New person/name/address of the applicant |
Owner name: AGILENT TECHNOLOGIES, INC. (N.D.GES.D. STAATES, US |
|
8128 | New person/name/address of the agent |
Representative=s name: BARTH, D., DIPL.-ING., PAT.-ANW., 71083 HERRENBERG |
|
R020 | Patent grant now final |
Effective date: 20110902 |
|
R081 | Change of applicant/patentee |
Owner name: VIAVI SOLUTIONS INC. (N. D. GES. D. STAATES DE, US Free format text: FORMER OWNER: AGILENT TECHNOLOGIES, INC. (N.D.GES.D. STAATES DELAWARE), SANTA CLARA, CALIF., US Effective date: 20130620 Owner name: JDS UNIPHASE CORP. (N. D. GES. D. STAATES DELA, US Free format text: FORMER OWNER: AGILENT TECHNOLOGIES, INC. (N.D.GES.D. STAATES DELAWARE), SANTA CLARA, CALIF., US Effective date: 20130620 Owner name: JDS UNIPHASE CORP. (N. D. GES. D. STAATES DELA, US Free format text: FORMER OWNER: AGILENT TECHNOLOGIES, INC. (N.D.GES.D. STAATES DELAWARE), SANTA CLARA, US Effective date: 20130620 |
|
R082 | Change of representative |
Representative=s name: MURGITROYD & COMPANY, DE Effective date: 20130620 Representative=s name: SCHOPPE, ZIMMERMANN, STOECKELER, ZINKLER, SCHE, DE Effective date: 20130620 Representative=s name: SCHOPPE, ZIMMERMANN, STOECKELER, ZINKLER & PAR, DE Effective date: 20130620 |
|
R082 | Change of representative |
Representative=s name: MURGITROYD & COMPANY, DE |
|
R081 | Change of applicant/patentee |
Owner name: VIAVI SOLUTIONS INC. (N. D. GES. D. STAATES DE, US Free format text: FORMER OWNER: JDS UNIPHASE CORP. (N. D. GES. D. STAATES DELAWARE), MILPITAS, CALIF., US |
|
R082 | Change of representative |
Representative=s name: MURGITROYD & COMPANY, DE |
|
R079 | Amendment of ipc main class |
Free format text: PREVIOUS MAIN CLASS: H04L0012260000 Ipc: H04L0043000000 |