DE102005028926B4

DE102005028926B4 - Fehlertolerantes Modulartesten von Diensten

Info

Publication number: DE102005028926B4
Application number: DE102005028926A
Authority: DE
Inventors: Thomas G. Loveland Bartz; Abhay Fort Collins Sathe
Original assignee: Agilent Technologies Inc
Current assignee: Viavi Solutions Inc
Priority date: 2004-10-04
Filing date: 2005-06-22
Publication date: 2011-06-01
Anticipated expiration: 2025-06-23
Also published as: US7246276B2; DE102005028926A1; US20060085723A1; GB2418755A; GB0519978D0

Abstract

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.

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 Netz 100 bereitgestellten Dienstes zu testen. Bediener in einem Dienstoperationszentrum (SOC) oder Netzoperationszentrum (NOC) 102, die in Kommunikation mit einem drahtlosen QoS-Verwalter 104 stehen, wie z. B. dem drahtlosen QoS-Verwalter von Agilent Technologies^TM, erzeugen strukturierte Netz-QoS-Tests. Die QoS wird oft mit einem aktiven Testen gekennzeichnet, bei dem eine oder mehrere Testsonden 106 eine Benutzeroperation einer Vorrichtung simulieren und dabei versuchen, mit dem Dienst in Wechselwirkung zu stehen (als durch Server 101 durch ein Gateway 103 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 Verwalter 104 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 Sequenz 110 von Testmodulen 112 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 bis 5G 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 Netz 100 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 Testsonden 106 werden verwendet, um Endbenutzer zu simulieren, die versuchen, auf einen durch das Netz 100 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 NOC 102, 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 (in 2 als „drahtlose Testkette” bezeichnet) von Testmodulen 112 durch Wechselwirkungen mit einer graphischen Benutzerschnittstelle eines diagnostischen Verwaltungssystems (DMS) 104, wie z. B. des drahtlosen Dienstgüte-Verwalters (WQM) von Agilent Technologies^TM, 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 Testsequenz 110 oder „Kette”) und Messergebnisse. Tests und ihre zugeordneten Testmodule 112 werden an der ATC 108 und den ATPs 106 gespeichert. Das DMS 104 bestimmt, welche Testkette (identifiziert, was „fließt”, oder Sequenzen und Teilsequenzen von Tests) die Aktivteststeuerung (ATC) 108 bei den Testsonden 106 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 ATPs 106 herunterlädt. Eine Steuersoftware auf jeder ALP 106 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 ATC 108 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 ATPs 106 befinden. Jede ATP 106 umfasst eine zentrale Verarbeitungseinheit 114 zur Ausführung einer Steuerprozesssoftware 116, die die Test- bzw. Prüfsonden steuert. Vorzugsweise ist die Steuerprozesssoftware 116 in einem Speicher 118 gespeichert, der dem Computer zugeordnet ist. Bei einem bevorzugten Ausführungsbeispiel ist der Quellencode der Steuerprozesssoftware 116 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 Testmodulsequenz 110 aus und erzeugt zusätzlich einen Fehlerstapel 120 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 Fehlerstapel 120 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 Testmodule 112 sowie die Steuerprozesssoftware 116 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 Testsequenz 110, der Fehlerstapel 120 und die Steuersoftware 116 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) Testmodule 112 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 Testmodulen 112, einschließlich Vorrichtung-Initialisieren 112-1, Gprs-Verbinden 112-2, WapGW-Verbinden 112-4, Nachrichten-Senden 112-5, WapGW-Trennen 112-6, Gprs-Trennen 112-7, Push-Nachricht-Empfangen 112-8 und Vorrichtung-Freigeben 112-9, wird durch die Steuertestsoftware 116 der vorliegenden Erfindung ausgeführt. Jedes der Testmodule könnte einen internen Code oder einen externen Code 126 aufweisen, der dynamisch Daten 122 erzeugt, die durch die ATPs 106 erfasst werden könnten. Diese Daten könnten in einem Testsitzungsdatenspeicher 124 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 ATC 108 (oder anderen ATPs) verwendet und durch dieselben gespeichert werden. Die ATPs 106 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 Steuersoftware 116 auslösen könnte, wie z. B. Drauflegen/Abheben bei dem Fehlerstapel 120, Übertragung von Nachrichten an das DMS 104 und Ferndienstüberwachungsvorrichtungen an dem SOC oder Netzüberwachungsvorrichtungen an dem NOC 102 und/oder lokale oder entfernte Warnindikatoren.
Algorithmus eines strukturierten Abbaus
Die Funktionsweise der Steuersoftware 116 wird nun Bezug nehmend auf 4, die ein Verfahren eines umkehrbaren Zustandsaufbaus und -abbaus gemäß der vorliegenden Erfindung darstellt, sowie Bezug nehmend auf die 5A–5G, die durch ein Beispiel die Kettenverarbeitung der Testmodule 112 und die Wirkung von Drauflegen-/Abheben-Operationen, die der Verarbeitung und der Systemfehlerhandhabung zugeordneten sind, auf den Fehlerstapel 120 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 Testmodulen 112 auf, die durch Verwalter oder hochentwickelte Dienstbediener bei dem SOC oder NOC 102 durch eine Wechselwirkung mit Graphikeinrichtungen eines diagnostischen Verwaltungssystems 104, wie z. B. des WQM-Systems, erzeugt werden könnten.
Bei Schritt 202 wird die Beschreibung der Testsequenzen durch die ATC 108 in die ATP 106 geladen. Wie oben angemerkt wurde, geschieht das Laden vorzugsweise durch eine Übertragung von dem DMS 104. 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 ATP 106 eine Ausführung der Steuersoftware 116, die den Fehlerstapel 120 initialisiert.
Bei Schritt 206 lässt die Steuersoftware 116 das erste (oder nächste) Testmodul 112 auf der ATP 106 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 Schritt 206 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 (Schritt 212). 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 Schritt 210 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 Schritt 206. 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 Schritt 212 die ATP einen strukturierten Abbau von Zustand/Verbindung der einen oder der mehreren Sonden. Zusätzlich berichtet die Testsequenz 110 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 Fehlerstapel 120 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 Schritt 212 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 Testkette 110 aus 2 und die zugeordneten Informationen, die bei dem Fehlerstapel 120 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 Testsonde 106 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 Testmodulidentifizierers 128 für den Fehlerhandhaber des Moduls auf den Fehlerstapel 120 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 Kette 110 den Identifizierer 128 des Testmoduls (durch den Fehlerhandhaber gegeben) auf den Fehlerstapel 120 drauf, bevor das Modul M eine Ausführung abgeschlossen hat (bedeutet, dass Zustand/Verbindung eingerichtet wurde). Die 5A–5D stellen die drauflegenden Fehlerhandhaber-Testmodulnamen Vorrichtung-Freigeben 128-1, Gprs-Trennen 128-2 und WapGW-Trennen 128-4 auf den Fehlerstapel 120 nach einem erfolgreichen Abschluss der entsprechenden Testmodule Vorrichtung-Initialisieren 112-1, Gprs-Verbinden 112-2 und WapGW-Verbinden 112-4 dar. Es wird angemerkt, dass Nachrichten-Senden 112-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 (Modulidentifizierer 128) von dem Fehlerstapel 120 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 Fehlerstapel 120 übereinstimmt. Wenn eine Übereinstimmung vorliegt, hebt die Kette A von dem Fehlerstapel 120 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

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.