DE112013005799T5

DE112013005799T5 - Vorrichtungen und Verfahren zum Testen

Info

Publication number: DE112013005799T5
Application number: DE112013005799.9T
Authority: DE
Inventors: Colin Hudson; Michael O'Gara
Original assignee: Anite Telecoms Ltd
Current assignee: Keysight Technologies Singapore Sales Pte Ltd
Priority date: 2012-12-04
Filing date: 2013-11-14
Publication date: 2015-08-20
Also published as: US20150318935A1; GB2511027A; US9774407B2; KR102064634B1; KR20150135198A; CN105009500B; CN105009500A; WO2014087130A1; TW201427335A

Abstract

Eine Testvorrichtung wird für das nicht-deterministische Testen von Geräten konfiguriert. Die Testvorrichtung umfasst einen Testcomputer, der angeordnet ist, automatisch ein nicht-deterministisches Testregime unter der Kontrolle einer Testanwendung auszuführen. Ein Netzwerksimulator, der mit dem Testcomputer verbunden ist, wird mit einer Kommunikationsschaltung ausgestattet, die befähigt ist, mit dem zu testenden Gerät zu kommunizieren. Der Netzwerksimulator ist für unterschiedliche Netzwerkzustände gemäß einem nicht-deterministischen Testregime konfigurierbar und die Testanwendung ist befähigt, den Netzwerksimulator so zu steuern, dass er in mehrere verschiedene Netzwerkzustände übergeht. Daten über nichtgescriptete Kommunikationen zwischen dem Netzwerksimulator und dem zu testenden Gerät werden überwacht und können zum Erreichen eines Testurteils analysiert werden.

Description

Gebiet der Erfindung
Die Erfindung bezieht sich auf Vorrichtungen und Verfahren zum Testen und insbesondere auf computerimplementierte Vorrichtungen und Verfahren zum Testen oder das drahtlose Testen von Benutzergeräten, zum Beispiel in Hinsicht auf Leistung, Interoperabilität und Konformität mit drahtlosen Standards.
Beschreibung des Standes der Technik
Es existieren bereits Vorrichtungen und Verfahren zum Testen von Benutzergeräten. Die verfügbaren Vorrichtungen und Verfahrensmethoden leiden aber unter einer Reihe von Problemen.
Bei einer ersten bekannten Art des drahtlosen Testens, die hierin als „scriptbasiertes” Testen bezeichnet wird, steuern Testcomputer Netzwerksimulatoren, die automatisch hochdefinierte Testscripts ausführen, wonach ein Netzwerksimulator eine Serie von Nachrichten an ein Benutzergerät sendet und das Benutzergerät darauf reagiert. Das ist eine Art deterministischen Testens, bei dem das Erfolgsergebnis eine unvermeidliche Folge einer vorhergehenden Ursache ist. Die vorhergehende Ursache kann eine einzelne Nachricht oder eine Serie von Nachrichten sein, aber die unvermeidliche Folge wird entweder durch die Reaktion des getesteten Geräts herbeigeführt oder nicht. Bei dieser Art des scriptbasierten Testens stellt die Herbeiführung der unvermeidlichen Folge einen „Erfolg” dar, während das Ausbleiben der erwarteten unvermeidlichen Folge ein „Versagen” darstellt. Scriptbasiertes Testen ist gut für automatisierte Großversuche von drahtlosen Benutzergeräte geeignet, aber nicht sehr flexibel. Es erfasst häufig auch Arten von Fehlern nicht, die nicht speziell durch das Versagen eines hochdefinierten Testscripts identifiziert werden.
Eine Alternative ist das benutzerbasierte Testen, bei dem Bediener kognitiv Testnachrichten festlegen, die an Benutzergeräte gesendet werden und die Reaktionen überwachen, um festzulegen, was als nächstes getestet werden soll. Dies ist ein manueller Prozess, bei dem der Benutzer jede Testnachricht festlegt und die Reaktion bewertet. Es ist für menschliche Fehler anfällig und verfügt über eine nur beschränkte Skalierbarkeit.
Keine der beiden vorstehenden bekannten Testtechniken ist überhaupt für wiederholbare großflächige Versuche zum Verhalten von Benutzergeräten bei mehreren unterschiedlichen Netzwerkbedingungen geeignet.
Ausführungsformen der vorliegenden Erfindung versuchen verbesserte Vorrichtungen und Verfahren zum Testen von Geräten, insbesondere von drahtlosen Geräten, zu ermöglichen.
Zusammenfassung der Erfindung
Diese Zusammenfassung dient zur Vorstellung einer Auswahl von Konzepten in vereinfachter Form, die nachfolgend in der detaillierten Beschreibung eingehender beschrieben werden. Diese Zusammenfassung soll nicht Schlüsselmerkmale oder wesentliche Merkmale des beanspruchten Gegenstands identifizieren und sie ist auch nicht als Hilfe bei der Bestimmung des Umfangs des beanspruchten Gegenstands gedacht.
Gemäß einem Aspekt der vorliegenden Erfindung wird eine Testvorrichtung bereitgestellt, die für die Durchführung von Gerätetests konfigurierbar ist, wobei die Vorrichtung umfasst: einen Testcomputer, der für die Ausführung eines Tests unter der Kontrolle einer Testanwendung eingerichtet ist; und einen Netzwerksimulator, der mit einer Kommunikationsschaltung ausgestattet ist, die zur Kommunikation mit dem zu testenden Gerät betriebsfähig ist, wobei die Testanwendung zur Steuerung der Netzwerksimulatorübergänge zwischen mehreren verschiedenen Netzwerkzuständen betriebsfähig ist, und wobei Daten über nicht gescriptete Kommunikationen zwischen dem Gerät und dem Netzwerksimulator in mindestens einem der Netzwerkzustände überwacht werden. Die Daten können dann zur Ermittlung eines Testurteils analysiert werden.
Gemäß eines anderen Aspekts der vorliegenden Erfindung wird eine Testvorrichtung bereitgestellt, die für die Durchführung von nicht-deterministischen Gerätetests konfigurierbar ist, wobei die Vorrichtung umfasst: einen Testcomputer, der für die automatische Ausführung eines nicht-deterministischen Testregimes unter der Kontrolle einer Testanwendung eingerichtet ist; und einen Netzwerksimulator, der mit dem Testcomputer verbunden ist und mit einer Kommunikationsschaltung ausgestattet ist, die zur Kommunikation mit dem zu testenden Gerät betriebsfähig ist, wobei der Netzwerksimulator für unterschiedliche Netzwerkzustände gemäß des nicht-deterministischen Testregimes konfigurierbar ist, und wobei die Testanwendung zur Steuerung der Netzwerksimulatorübergänge zwischen mehreren verschiedenen Netzwerkzuständen und zur Überwachung von Daten über nicht gescriptete Kommunikationen zwischen dem Netzwerksimulator und dem Gerät in den Phasen zwischen den Übergangen betriebsfähig ist.
Gemäß eines anderen Aspekts der vorliegenden Erfindung wird eine Testanwendung für Netzwerksimulator-basiertes Testen von Geräten bereitgestellt, die Computerprogrammcode, der zur Ausführung auf einem Computer adaptiert wurde, wobei der Computercode betriebsfähig ist, wenn er auf einem Computer ausgeführt wird, umfasst, der den Computer veranlasst: unter Verwendung von Netzwerkparametern, die gemäß eines nicht-deterministischen Testregimes verwendet werden, einen ersten Netzwerksimulatorzustand herzustellen; eine Phase nicht gescripteter Kommunikation zwischen dem Netzwerksimulator und dem Gerät, während der der Netzwerksimulator sich in diesem ersten Zustand befindet, zu überwachen; den Netzwerksimulator veranlasst zu einem zweiten Netzwerksimulator 5 Zustand auf Basis eines zweiten Sets von Netzwerkparametern gemäß dem Testregime überzugehen, eine Phase nicht gescripteter Kommunikation zwischen dem Netzwerksimulator und dem Gerät, während der der Netzwerksimulator sich in diesem zweiten Zustand befindet, zu überwachen; und veranlasst, dass Protokolldaten zu jedem Netzwerksimulatorzustand und den damit verbundenen Kommunikationen zwischen dem Netzwerksimulator und dem Benutzergerät in einer Logdatei protokolliert werden.
Gemäß eines anderen Aspekts der vorliegenden Erfindung wird ein Netzwerksimulator bereitgestellt, der für das Testen von Geräten konfiguriert ist, wobei der Netzwerksimulator umfasst: ein Protokollstapel-Modul; Sendeschaltung mit mindestens einer Antenne für Kommunikationen mit dem Benutzergerät; und einer Steuerung mit einer Schnittstelle zu einer Testanwendung, wobei die Steuerung für den Empfang von Parametern von der Testanwendung, einschließlich Protokollstapel-Parameter, betriebsfähig ist und den Netzwerksimulator veranlasst sukzessive zwischen mehreren programmierten Netzwerksimulatorzuständen auf Basis dieser Parameter überzugehen, und wobei die Steuerung für die Überwachung der Phasen nicht-gescripteter Kommunikationen zwischen dem zu testenden Gerät und dem Netzwerksimulator während jeder dieser Netzwerkzustände betriebsfähig ist.
Weitere und optionale Merkmale der Testvorrichtungen, Testanwendungen und Netzwerksimulatoren sind in den beigefügten Ansprüchen enthalten.
Die Erfindung offenbart weiterhin Systeme, Vorrichtungen und Herstellungsartikel zur Implementierung der vorgenannten Aspekte der Erfindung.
Die bevorzugten Merkmale können, wie es dem Fachmann offensichtlich wäre, in geeigneter Weise kombiniert werden und lassen sich mit jedem einzelnen der Aspekte der Erfindung kombinieren.
Beschreibung der Figuren
Die Erfindung wird nun unter Bezugnahme auf die folgenden Figuren detailliert beschrieben, wobei:
1 ist ein Diagramm einer drahtlosen Testvorrichtung nach dem Stand der Technik;
2 ist eine schematische Darstellung eines Testscripts gemäß scriptbasierten Testens;
3 ist ein Diagramm einer drahtlosen Testvorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung;
4 ist eine schematische Darstellung nicht-gescriptetens automatischen Testens gemäß einer Ausführungsform der vorliegenden Erfindung; und
5 wird als Teil der Daten aus einer Logdatei gezeigt.
Ausführungsformen gemäß der Erfindung werden nun lediglich beispielhaft beschrieben.
Es versteht sich, dass, obwohl Merkmale von jedem der Ausführungsbeispiele durch Differenzbezugszeichen in den Figuren und in der Beschreibung identifiziert werden können, ähnliche Merkmale, einschließlich der Eigenschaften und Funktionalität, die auf sie zurückzuführen sind, einer Ausführungsform und jene einer anderen Ausführungsform austauschbar sind.
Detaillierte Beschreibung der Erfindung
1 zeigt eine bekannte Art einer drahtlosen Testvorrichtung. Die Vorrichtung verfügt über einen Computer 100, der mit einer Datenbank 102 und mit einem Netzwerksimulator 104 verbunden ist. Der Netzwerksimulator verfügt über einen Protokollstapel, der in diesem Fall dazu in der Lage ist, das Verhalten der Basisstation gemäß eines bekannten drahtlosen Kommunikationsstandards zu emulieren. Der Protokollstapel des Netzwerksimulators ist mit einem drahtlosen Transceiver-Modul verbunden, das wiederum mit einer Antenne 106 gekoppelt ist, die über die Fähigkeit bidirektionaler drahtloser Kommunikation mit dem Benutzergerät 108 verfügt.
In der Anordnung in 1 ist das Benutzergerät 108 das zu testende Gerät. Eine Testanwendung 120, die auf dem Testcomputer 100 ausgeführt wird, ruft Testspezifikationen aus der Datenbank 102 ab und konfiguriert die Testscripts, so dass sie über den Netzwerksimulator 104 ausgeführt werden können. Die Testscripts, die in der Datenbank aufgezeichnet sein könnten, können auf 3GPP technischen Spezifikationen, wie die 24.008, 24.301, 25.331, 36.331 oder 44.018 Serien beruhen.
Bei der Anwendung ermittelt die Testanwendung 120 gemäß dem Testscript Kontrollparameter für den Netzwerksimulator, einschließlich, aber nicht beschränkt auf die Einstellungen für die verschiedenen Schichten des Protokollstapels und andererkonfigurierbarer Netzwerkeinstellungen. Vorzugsweise legt die Testanwendung 120 auch fest und/oder sie steuert das Senden von Nachrichten zwischen der Netzwerksimulator-Transceivereinheit 106 und dem Benutzergerät 108 gemäß dem Testscript.
2 zeigt ein Testscript einer beispielhaften scriptbasierten deterministischen Testtechnik. Zu einem Zeitpunkt T1 wird eine erste Testnachricht 200 gemäß dem Testscript vom Netzwerksimulator (beispielsweise von der Netzwerksimulator-Transceivereinheit 106) an das Benutzergerät 108 gesendet. Zu einem Zeitpunkt R1 wird eine Reaktionsnachricht 220 vom Benutzergerät 108 durch den Netzwerksimulator empfangen. Zu einem Zeitpunkt T2 wird eine zweite Testnachricht 202 vom Netzwerksimulator an das Benutzergerät 108 gesendet und als Reaktion hierauf wird zu einem Zeitpunkt R2 eine weitere Reaktionsnachricht 222 von dem Benutzergerät 108 durch den Netzwerksimulator empfangen. In diesem Beispiel umfasst der veranschaulichte Teil des Testscripts einen dritten aus Textnachricht 204 und Reaktionsnachricht 224 bestehenden Zyklus.
Die Nachrichtenarten können Funkressourcensteuernachrichten (z. B. Radio Bearer Setup-Nachricht und Radio Bearer Setup Complete Antwort), Authentifizierungs- und Sicherheitskontrollnachrichten (z. B. Security Mode Command, Security Mode Complete Reaktion) umfassen, sind hierauf aber nicht beschränkt. Typischerweise umfassen die Scripte Dutzende bis Hunderte von Nachrichten und werden einige Minuten bis mehrere Stunden lang ausgeführt.
Jede Nachricht, die vom Netzwerksimulator gesendet wird, ist genau gemäß dem Testscript vorgeschrieben, selbst dann, wenn bestimmte spätere Testnachrichten im Script vorhergehende Reaktionen des Benutzergeräts 108 berücksichtigen. Solche Testscripts bleiben daher äußerst deterministisch, selbst dann, wenn sie Scriptverzweigungen enthalten, denen je nach Reaktion des Benutzergeräts 108 gefolgt wird oder nicht. Die Reaktionen liefern das Urteil 250, wobei es sich entweder um einen „Erfolg” oder ein „Versagen” handelt. Bei dieser Art des deterministischen Testens ist eine erwartete Reaktion eine unvermeidliche Folge einer vorhergehenden Ursache. Die vorhergehende Ursache kann eine einzelne Testnachricht oder eine Serie von Testnachrichten sein, aber die unvermeidliche Folge wird entweder durch die Reaktion des Benutzergeräts 108 herbeigeführt oder nicht. Die Testsoftware identifiziert bei dieser Art des scriptbasierten Testens die Herbeiführung der unvermeidlichen Folge eines „Erfolgs”, während das Ausbleiben der erwarteten unvermeidlichen Folge ein „Versagen” darstellt.
Das andere Extrem ist das nicht automatisierte, benutzerbetriebene Testen, bei dem ein menschlicher Betreiber einer grafischen Benutzeroberfläche des Netzwerksimulators eine Testnachricht erzeugt, die an das Benutzergerät 108 gesendet wird und die zum Zeitpunkt der Durchführung des Tests vom Benutzergerät 108 zurück empfangene Reaktion analysiert. Der menschliche Betreiber kann dann festlegen, welche Testnachricht als nächstes gesendet werden soll und außerdem entscheiden, ob das Benutzergerät 108 einen Erfolg oder ein Versagen aufwies, normalerweise unter Bezugnahme auf Richtlinienmaterial.
3 zeigt eine drahtlose Testvorrichtung gemäß einer Ausführungsform der Erfindung.
Die Vorrichtung verfügt über einen Computer 300, der mit einer Datenbank 310 und mit einem Netzwerksimulator 328 verbunden ist. Der Netzwerksimulator 328 umfasst eine Steuerung 332, Protokollstapelmodul(e) 330 und einen drahtlosen Transceiver 334. Die Protokollstapelmodule 330 sind mit dem drahtlosen Transceiver 334 verbunden, der wiederum an eine Antenne 336 gekoppelt ist, die über die Fähigkeit bidirektionaler drahtloser Kommunikation mit dem Benutzergerät 340 verfügt. Das zu testende Gerät 340 kann beispielsweise ein Mobiltelefon, PDA, Tablet oder ein anderer mobiler Computer, Dongle, die an einen Computer angeschlossen sind, softwarebasierte Protokollstapel, die auf einem Computer ausgeführt werden, Prototyphardware und/oder eingebettete drahtlose Geräte für Maschine zu Maschine Typ-Anwendungen sein.
Der Testcomputer 300 wird mit einer Suite von Anwendungen ausgestattet, darunter, in diesem Beispiel, eine Testanwendung 302, eine Logger-Anwendung 304 und eine Nachbearbeitungsanwendung 306. Die neue Testanwendung 302, die auf dem Testcomputer 300 ausgeführt wird, ruft Testspezifikationen aus der Datenbank 310 ab und konfiguriert die neuen Arten nicht deterministischer Testregime, so dass diese automatisch über den Netzwerksimulator 328 ausgeführt werden können. Beispiele bestimmter Testspezifikationen, die in der Datenbank erfasst sein könnten, umfassen, sind aber nicht beschränkt auf solche zur Feststellung von Langzeitsignalisierungsoverheads (d. h. Signalvolumen) und/oder zur Feststellung der Signalereignisfrequenz (Signaltiming).
In diesem Beispiel ist das Protokollstapelmodul 330 ein konfigurierbarer Protokollstapel, in dem die verschiedenen Schichten eine Vielzahl bekannter drahtloser Telekommunikations-Funkzugangstechnologien unterstützen kann, darunter beispielsweise 2G, 3G und/oder LTE (auch 4G genannt) Telekommunikationsprotokolle.
In der Anwendung ermittelt die Testanwendung 302 gemäß der Testspezifikation die Kontrollparameter für den Netzwerksimulator 328, darunter die Einstellungen für die verschiedenen Schichten im Protokollstapel 330 und andere konfigurierbare Netzwerkeinstellungen. Die Testanwendung 302 ist konfiguriert, die Kontrollparameter an die Steuerung 332 des Netzwerksimulators 328 zu senden. Die Steuerung 332 legt dann die Kontrollparameter der konfigurierbaren Blöcke innerhalb des Protokollstapels des Netzwerksimulators 328 und vorzugsweise alle anderen Netzwerksimulatoreinstellungen, die gemäß dem anfänglichen Teil des Tests gewünscht werden, fest. Die Steuerung 322 kann beispielsweise gemäß den Anweisungen der Testanwendung 302 konfigurierbare Parameter der verschiedenen Schichten des Protokollstapels, darunter die Parameter in den Schichten 3, 2 oder 1 (Schicht 1 wird auch physikalische Schicht oder PHY Schicht genannt), festlegen. Diese Parameterisierung des Netzwerksimulators 328 zur Erreichung des ersten gemäß dem nicht-deterministischen Testregime gewünschten Netzwerkzustands kann beispielsweise die Einstellung der PDCP Parameter, RLC/MAC Parameter und der PHY Schicht gemäß eines im ersten Teil des Tests gewünschten Netzwerkzustands umfassen. Dies kann insbesondere bei diesen Arten von Tests nützlich sein, um die Fähigkeit zu erlangen, Akzeptieren/Ablehnen/Ignorieren Konfigurationsverfahren, die vom Benutzergerät 340 initiiert werden, festzulegen und für die Werte von Timern und/oder Zähler, die an das Benutzergerät 340 signalisiert werden.
Der anfängliche Netzwerkzustand, der beim Testen des Benutzergeräts 340 verwendet wird, kann eine bestimmte parameterisierte Netzwerkeinstellung sein. Alternativ oder zusätzlich hierzu kann er eine Nachricht oder einen Satz von Nachrichten veranlassen, der bzw. die vom Netzwerksimulator 328 in einem bestimmten parameterisierten Zustand versendet wird bzw. werden. Danach steuert die Testanwendung 302 den Netzwerksimulator 328 so, dass er in einen interaktiven Betriebszustand übergeht, in dem der parameterisierte Netzwerksimulator und das Benutzergerät 340 auf nicht gescriptete Weise kommunizieren. Auf die Übernahme des anfänglichen Netzwerkzustands, der beim Testen verwendet wird, kann beispielsweise die Kommunikation einer oder mehrerer Nachrichten vom Benutzergerät 340 an den Netzwerksimulator 328 folgen und der Netzwerksimulator 328 kann auf Basis seines Zustands darauf reagieren.
Während der Ausführung des Testregimes bleibt der Testcomputer 300 in Kommunikation mit der Steuerung 332 des Netzwerksimulators 328. Die Logger-Software 304 zeichnet Daten über die Serie der Ereignisse und Kommunikationen zwischen dem Netzwerksimulator 328 und dem Benutzergerät 340 in einer Logdatei auf. Solch eine Logdatei kann beispielsweise mit Zeitstempel versehene Einträge der unterschiedlichen Zustände und Bedingungen, die vom Netzwerksimulator und dem Benutzergerät übernommen werden, und/oder Aufzeichnungen über die Nachrichten die zwischen ihnen hin- und hergesendet wurden, enthalten. Die Logdatei kann außerdem Daten im Zusammenhang mit den Nachrichten an sich enthalten, wie beispielsweise Nutzdaten und/oder Größendaten. Nach einem Zeitpunkt kann die Testanwendung 302 veranlassen, dass der Netzwerksimulator 328 in einen zweiten Netzwerkzustand übergeht, so dass in einen zweiten interaktiven Betriebszustand übergegangen wird, derweitere nicht gescriptete Interaktion zwischen dem Benutzergerät 340 und dem Netzwerksimulator 328 in seinem zweiten Zustand ermöglicht. Der Wechsel vom anfänglichen Netzwerkzustand zum zweiten Netzwerkzustand kann automatisch erfolgen oder manuell programmiert werden, beispielsweise, so dass er nach einer bestimmten zeitlichen Verzögerung, zu einem bestimmten Zeitpunkt eintritt, oder er kann programmiert werden, so dass er als Reaktion auf einen Auslöser, der mit dem Benutzergerät 340 oder dem Netzwerksimulator 328 assoziiert ist, eintritt. Der Auslöser könnte beispielsweise ein bestimmtes Ereignis, das mit dem Benutzergerät 340 assoziiert ist, sein oder es könnte ein bestimmtes Ereignis sein, das mit dem Netzwerksimulator 328 assoziiert ist. Bei beiden, dem Netzwerksimulator 328 oder dem Benutzergerät 340, könnte ein Auslöserereignis beispielsweise die Einrichtung eines bestimmten Zustandes oder das Senden einer bestimmten Nachricht sein. Der zweite Netzwerkzustand kann eine Neuparameterisierung des Netzwerks sein. Alternativ oder zusätzlich hierzu kann der zweite Netzwerkzustand das Senden einer bestimmten Nachricht oder eines Sets von Nachrichten von dem parameterisierten (oder neuparameterisierten) Netzwerksimulator 328 an das Benutzergerät 340 sein.
Gemäß dem Testregime, das von der Testanwendung ausgeführt wird, kann es eine beliebige Zahl an programmierten Netzwerksimulatorzustandsänderungen mit nicht gescripteten interaktiven Zeiträumen dazwischen geben. Anhand dieser Beschreibung ist ersichtlich, dass die Testanwendung 302, nach Herstellung des anfänglichen Netzwerkzustands, nicht das Senden hochdefinierter gescripteter Nachrichten zwischen dem drahtlosen Transceiver des Netzwerksimulators 334 und dem Benutzergerät 340 betreibt, wie das bei bekannten Testscripts der Fall ist. Stattdessen stellt der interaktive Betriebszustand eine Art nicht gescripteter Phase der Kommunikation zwischen dem Benutzergerät 340 und dem Netzwerksimulator 328 dar, während der der Netzwerksimulator 328 unter der Kontrolle der Testanwendung 302 die nicht gescripteten Kommunikationen überwacht und aufzeichnet. Dies kann Signalsequenzen, Benutzerdaten, Inaktivitätsphasen oder andere Verhaltensweisen des Systems umfassen. Diese Kommunikationsarten umfassen beispielsweise Versuche des Benutzergeräts 340 sich beim Netzwerk zu registrieren, vom Benutzergerät 340 erzeugte Datenkanalanforderungen für Übertragungen und/oder das Senden von Messungen über Netzwerkbedingungen, die vom Benutzergerät 340 überwacht werden. Wenn der programmierte Auslöser für den nächsten Wechsel des Netzwerksimulatorzustands erkannt wird, bewegt die Steuerung das Verfahren gemäß dem Testregime weiter.
4 veranschaulicht schematisch Kommunikationen zwischen einem Netzwerksimulator 328 und dem Benutzergerät 340 aus, unter anderem, 3 nach einer Ausführungsform der vorliegenden Erfindung, die nicht-deterministische Testregime implementieren. Zum Zeitpunkt TS1 geht der Netzwerksimulator 328 in einen anfänglichen Netzwerkzustand gemäß des Testregimes, der automatisch von der Testsoftware 302 ausgeführt wird. In diesem Beispiel umfasst der anfängliche Netzwerkzustand eine Parameterisierung des Netzwerksimulators 328 sowie das Senden einer Testnachricht 400 vom Netzwerksimulator 328 an das Benutzergerät 340. Danach geht der Netzwerksimulator 328 in einen interaktiven Betriebszustand über, während dem eine Phase nicht gescripteter Kommunikation 402 zwischen dem Netzwerksimulator 328 und dem Benutzergerät 340 existiert. Es ist von den vorhergehenden Erklärungen deutlich, dass „interaktiver Betriebszustand” in diesem Zusammenhang eine Phase der Kommunikation zwischen dem Benutzergerät 340 und dem parameterisierten Netzwerksimulator 328 bezeichnet, die nicht gescriptet ist oder von der Testanwendung 302 direkt gesteuert wird. Stattdessen werden das Benutzergerät 340 und ein Netzwerksimulator 328 befähigt, interaktive Kommunikationen gemäß ihrer normalen Betriebszustände unter den Umständen zu verfolgen. Die Kommunikationen werden von dem Testcomputer 300, der die Testanwendungen 302 und die Logger-Anwendung 307 ausführt, überwacht und protokolliert.
Zu einem späteren Zeitpunkt TSC1 erkennt die Testanwendung 302 den programmierten Auslöser für einen Zustandswechsel des Netzwerksimulators 328 und implementiert den Zustandswechsel so, dass der Netzwerksimulator 328 wie benötigt neu parameterisiert wird und zu einem Zeitpunkt TS2 in den zweiten Netzwerkzustand übergeht. In seinem zweiten Netzwerkzustand geht der Netzwerksimulator 328 in einen Betriebszustand interaktiver Kommunikationen 404 mit dem Benutzergerät 340 über. Der Testcomputer 300 überwacht wie zuvor eine Phase interaktiver, nicht gescripteter Kommunikation zwischen dem Netzwerk, ähnlich seines zweiten Zustands, und dem Benutzergerät 340 und protokolliert relevante Daten in der Logdatei. Die zweite Phase interaktiver Kommunikationen 404 endet am Zeitpunkt TSC2, wenn die Testanwendung 302 Steuerung den Auslöser für einen weiteren Zustandswechsel des Netzwerksimulators 328 ermittelt.
Dieser weitere Zustand des Netzwerksimulators 328 in einen dritten Netzwerkzustand tritt zum Zeitpunkt TS3 ein. In diesem Beispiel wird der dritte Netzwerkzustand des Netzwerksimulators 328 durch Neuparameterisierung ohne Senden einer Testnachricht an das Benutzergerät 340 erreicht. Danach gehen der Netzwerksimulator 328 und das Benutzergerät 340 in eine dritte Phase 404 interaktiver, nicht gescripteter Kommunikationen, die von dem Testcomputer in Logdateien protokolliert werden, über. Wie zuvor endet die Phase interaktiver Kommunikation mit der Feststellung des programmierten Auslösers durch die Steuerung am Zeitpunkt TSC3. Das implementierte Testregime kann eine beliebige, gewünschte Anzahl programmierter Netzwerksimulatorzustandswechsel und interaktiver Kommunikationsphasen umfassen. Die Logdateien können beispielsweise Informationen wie Netzwerksimulatoreinstellungen, Benutzergerätbedingungen oder -einstellungen, Benutzergeräte-IDs, Benutzergerätetyp und/oder Hersteller, Nachrichtenart, Zeitstempel, Nutzdaten, Anwendungscode und/oder beliebige andere Daten, die im Zusammenhang mit dem nicht deterministischen drahtlosen Testregime für das Benutzergerät nützlich ist, enthalten.
Die Nachbearbeitungssoftware 306 wird dazu genutzt, um automatisch Logdateien zur Ermittlung des Testurteils zu analysieren. Die Nachbearbeitungssoftware kann beispielsweise die Logdateien analysieren, um den Datendurchsatz, der bei unterschiedlichen Netzwerkkonfigurationen erreicht wird (beispielsweise bei variierenden Leistungspegeln und/oder Kanalqualitäten des Transceivers), zu ermitteln. Alternativ oder zusätzlich hierzu kann die Nachbearbeitungssoftware automatisch verschiedene Arten von Überkommunikationen zwischen dem Benutzergerät 340 und dem Netzwerksimulator 328 identifizieren, einschließlich bestimmter Benutzergeräte, die zu einem hohen Niveau an unnötigen Kommunikationen mit dem Netzwerk führen. Die Nachbearbeitungssoftware kann vorzugsweise Berichte über Nachrichtenzählungen und/oder Nachrichtenverzögerungen erbringen und/oder automatisch Ergebnisse mit Testspezifikationen vergleichen, um bei bestimmten Problemen zu warnen.
Der Fachmann erkennt, dass der Testcomputer 300 und der Netzwerksimulator 328 mehr als einen Computer umfassen kann und die verschiedenen, hierin beschriebenen Testanwendungs- und Netzwerksimulationsfunktionen unterschiedlich und/oder auf mehreren Computern implementiert werden können. Der Testcomputer 300 kann beispielsweise von einem Automatisierungsrechner, der für die Steuerung von Geräten und/oder die Ausführung von Anwendungsprogrammen konfiguriert ist, unterstützt werden. Testscripte können Befehle enthalten, die über eine vordefinierte Verbindung an einen Automatisierungsrechner gesendet werden. Der Automatisierungsrechner könnte den Befehl in einer benutzerdefinierten Konfigurationsdatei nachschlagen und eine entsprechende Maßnahme ergreifen. Dabei kann es sich beispielsweise um die Steuerung einer Anwendung oder von Hardware außerhalb des Umfangs des Testcomputers handeln und/oder die Anforderung von Statusinformationen von der Anwendung oder Hardware. Der Protokollstapel bzw. die Schichten innerhalb des Protokollstapels oder andere Komponenten des Netzwerksimulators könnten anders als gezeigt implementiert sein, wobei Teile des Netzwerksimulators auf, wie gewünscht, verschiedenen Computern implementiert sind. Alternativ können der Testcomputer und der Netzwerksimulator als ein Gerät bereitgestellt werden.
Es ist möglich, Benutzer- oder andere Geräte zu testen, einschließlich der Protokollstapelfunktionen in einer nur-Software-Umgebung. Bei solch einer Anordnung benötigt das Testgerät nicht die gesamte Standardhardware, die mit drahtlosen Benutzergeräten, wie einem Mobiltelefon, assoziiert wird. Andere Ausführungsformen der Erfindung können daher für die Ausführung von Gerätetests in Softwareumgebungen und ohne Standardhardware wie die Antenne konfiguriert werden.
Die Hardwareelemente, Betriebssysteme und Programmiersprachen solcher Computer können konventioneller Art sein und es wird angenommen, dass der Fachmann hinreichend mit ihnen vertraut ist. Natürlich können die Funktionen, zumindest teilweise, auch in speziell gebauter Hardware oder anwendungsspezifischer Firmware implementiert werden. Alle beschriebenen Komponenten oder Funktionen, von denen einige für die Durchführung der Erfindungen erforderlich sind, können auf geeignete Weise über eine Reihe von Komponenten oder Plattformen zur Verteilung der Verarbeitungslast verteilt sein.
Hier können Aspekte der hierin beschriebenen Verfahren und Vorrichtungen auf einer Recheneinrichtung, wie einem Server, ausgeführt werden. Programmaspekte der Technologie kann man sich als „Produkte” oder „Herstellungsartikel” typischerweise in Form ausführbaren Codes und/oder damit in Verbindung stehender Daten denken, die auf einer Art maschinenlesbaren Medium enthalten sind oder durch dieses verkörpert werden.
„Speicher”-artige Medien umfassen einen Teil oder den gesamten Speicher von Computern, Prozessoren o. ä. oder damit in Verbindung stehende Module, wie diverse Halbleiterspeicher, Bandlaufwerke, Festplattenlaufwerke usw., die jederzeit Speicher für die Softwareprogrammierung bereitstellen. Ein Teil oder die gesamte Software kann bisweilen über das Internet oder diverse andere Telekommunikationsnetzwerke kommuniziert werden. Solche Kommunikationen können zum Beispiel das Laden der Software von einem Computer oder Prozessor in einen anderen Computer oder Prozessor ermöglichen. Eine andere Art Medien, die die Softwareelemente enthalten können, umfassen daher optische, elektrische und elektromagnetische Wellen, wie sie bei physikalischen Schnittstellen zwischen Lokalgeräten über verkabelte und optische Festnetznetzwerke und diverse Air-Links verwendet werden. Die physikalischen Elemente, die solche Wellen befördern, wie verkabelte oder drahtlose Verbindungen, optische Verbindungen usw., können auch als medientragende Software gelten. Wie hierin verwendet, sofern nicht auf materielle nicht vorübergehende „Speicher”-Medien beschränkt, beziehen sich Begriffe wie Computer oder Maschinen-„lesbares Medium” auf jedes beliebige Medium, das an der Bereitstellung von Anweisungen an einen Prozessor zur Ausführung beteiligt ist. Ein maschinenlesbares Medium kann daher vielerlei Formen haben, einschließlich, aber nicht beschränkt auf einen materiellen Speicherträger, ein Trägerwellenmedium oder ein physikalisches Transaktionsmedium. Nichtvolatile Speichermedien umfassen beispielsweise optische oder magnetische Platten, wie Speichervorrichtungen in Computer(n) usw., wie sie, wie in den Zeichnungen gezeigt, zur Implementierung des Encoders, des Decoders usw. verwendet werden. Volatile Speichermedien umfassen dynamische Speicher, wie den Hauptspeicher einer Computerplattform. Materielle Übertragungsmedien umfassen Koaxialkabel, Kupferdrähte und Lichtwellenleiter, einschließlich der Drähte, die den Bus in einem Computersystem umfassen. Trägerwellenübertragungsmedien können die Form elektrischer oder elektromagnetischer Signale oder akustischer Wellen oder von Lichtwellen haben, wie sie während Radiofrequenz (RF) und Infrarot (IR) Datenkommunikationen erzeugt werden. Gebräuchliche Formen von computerlesbaren Medien umfassen daher zum Beispiel: eine Diskette, eine flexible Platte, Festplatte, Magnetband, irgendein anderes magnetisches Medium, eine CD-ROM, DVD oder DVD-ROM, irgendein anderes optisches Medium, Stechkarten, Papierband, irgendein anderes physisches Speichermedium mit Lochmustern, ein RAM, ein PROM und EPROM, ein FLASH-EPROM, irgendeinen anderen Speicherchip oder Speicherkassette, eine Trägerwelle, die Daten oder Anweisungen transportiert, Kabel oder Verbindungen, die solch eine Trägerwelle transportieren oder ein beliebiges anderes Medium von dem ein Computer Programmiercode und/oder Daten lesen kann. Viele dieser Formen von computerlesbaren Medien können daran beteiligt sein, eine oder mehrere Sequenzen von einer oder mehreren Anweisungen einem Prozessor zur Ausführung zuzuführen.
Fachleute werden wissen, dass, obwohl das Vorstehende das beschreibt, was als die beste Art und Weise gilt, und, sofern zutreffend, andere Arten und Weisen der Durchführung der Erfindung beschreibt, darf die Erfindung nicht auf bestimmte Vorrichtungskonfigurationen oder Verfahrensschritte, die in dieser Beschreibung der bevorzugten Ausführungsform offenbart werden, beschränkt werden. Es versteht sich, dass verschiedene Modifikationen vorgenommen werden können, und dass der hierin offenbarte Gegenstand in verschiedenen Formen und Beispielen implementiert werden kann, und dass die Lehre in zahlreichen Anwendungen angewendet werden kann, von denen nur einige hierin beschrieben worden sind. Es ist durch die folgenden Ansprüche beabsichtigt, jede und alle Anwendungen, Modifikationen und Variationen, die in den wahren Umfang der vorliegenden Lehren fallen, zu beanspruchen. Fachleute auf dem Gebiet werden erkennen, dass die Erfindung einen breiten Anwendungsbereich hat, und dass die Ausführungsformen eine Vielzahl von Modifikationen möglich machen, ohne vom erfinderischen Konzept, wie in den beigefügten Ansprüchen definiert, abzuweichen.
Obwohl die vorliegende Erfindung in Bezug auf bestimmte beispielhafte Ausführungsbeispiele beschrieben wurde, versteht es sich, dass verschiedene Modifikationen, Änderungen und/oder Kombinationen von Merkmalen, die hierin offenbart werden, für den Fachmann auf dem Gebiet ersichtlich sind, ohne von dem Geist und Umfang der Erfindung, wie er in den folgenden Ansprüchen dargelegt ist, abzuweichen.

Claims

Ein für die Durchführung nicht deterministischen Testens von Geräten konfigurierbare Testvorrichtung, wobei die Vorrichtung umfasst: einen Testcomputer, der für die automatische Ausführung eines nicht deterministischen Testregimes unter der Kontrolle einer Testanwendung angeordnet ist; und einen Netzwerksimulator, der mit dem Testcomputer verbunden ist und mit einer Kommunikationsschaltung ausgestattet ist, die zur Kommunikation mit dem zu testenden Gerät betriebsfähig ist, wobei der Netzwerksimulator für unterschiedliche Netzwerkzustände gemäß des nicht-deterministischen Testregimes konfigurierbar ist, und wobei die Testanwendung die Testanwendung zur Steuerung der Netzwerksimulatorübergänge zwischen mehreren verschiedenen Netzwerkzuständen und zur Überwachung von Daten über nicht gescriptete Kommunikationen zwischen dem Netzwerksimulator und dem Gerät in den Phasen zwischen den Übergangen betriebsfähig ist.
Eine Testvorrichtung nach Anspruch 1, worin der Netzwerksimulator ein nach der Testanwendung konfigurierbares Protokollstapelmodul umfasst.
Eine Testvorrichtung nach dem vorhergehenden Anspruch, worin der Netzwerksimulator ein über die Testapplikation konfigurierbares Protokollstapelmodul zwischen Netzwerkzuständen, die verschiedene Funkzugangstechnologien annehmen, umfasst.
Eine Testvorrichtung wie im vorstehenden Anspruch beschrieben, wobei die Testanwendung ein Testregime umfasst, das mehrere vorprogrammierte Übergänge zwischen Netzwerkzuständen umfasst.
Eine Testvorrichtung nach dem vorstehenden Anspruch, worin die Testanwendung betriebsfähig ist, den Netzwerksimulator zu veranlassen, neue Netzwerkeinstellungen als Teil eines Übergangs zu einem neuen Netzwerkzustand anzunehmen.
Eine Testvorrichtung nach dem vorstehenden Anspruch, worin die Testanwendung betriebsfähig ist, den Netzwerksimulator zu veranlassen, in einem neuen Netzwerkzustand eine Testnachricht an das Gerät zu senden.
Eine Testvorrichtung nach dem vorstehenden Anspruch, worin der Netzwerksimulator betriebsfähig ist, auf Grundlage eines oder mehrerer bestimmter Zeitpunkt(e) oder einer zeitlichen Verzögerung einen Übergang zwischen verschiedenen Netzwerkzuständen vorzunehmen.
Eine Testvorrichtung nach dem vorstehenden Anspruch, worin der Netzwerksimulator betriebsfähig ist, in Reaktion auf ein Auslöserereignis, das mit einem oder mehreren der Geräte und dem Netzwerksimulator in Verbindung steht, Übergänge zwischen verschiedenen Netzwerkzuständen vorzunehmen.
Eine Testvorrichtung nach dem vorstehenden Anspruch, worin der Netzwerksimulator betriebsfähig ist, als Reaktion auf ein Auslöserereignis Übergänge zwischen verschiedenen Netzwerkzuständen vorzunehmen, und worin das Auslöserereignis eine Bedingung ist, die in dem einen oder mehreren Geräte(n) und dem Netzwerksimulator erfüllt wird.
Eine Testvorrichtung nach dem vorstehenden Anspruch, worin der Netzwerksimulator betriebsfähig ist, in Reaktion auf ein Auslöserereignis Übergänge zwischen verschiedenen Netzwerkzuständen vorzunehmen.
Eine Testvorrichtung nach Anspruch 10, worin das Auslöserereignis eine vorgegebene Nachricht ist, die der Netzwerksimulator von dem Gerät erhält.
Eine Testvorrichtung nach dem vorhergehenden Anspruch, weiterhin umfassend einen Logger, der betriebsfähig ist, Daten im Zusammenhang mit den mehreren Netzwerkzuständen und für die jeweiligen Netzwerkzustände die damit in Verbindung stehenden Daten zu den Kommunikationen zwischen dem Netzwerksimulator und dem Gerät zu protokollieren.
Eine Testvorrichtung nach Anspruch 12, weiterhin umfassend ein Softwaretool, das betriebsfähig ist, um Daten, die vom Logger protokolliert werden, automatisch zu analysieren, um ein Testergebnis festzustellen.
Eine Testanwendung für Netzwerksimulator-basiertes Testen von Geräten, die Computerprogrammcode, der zur Ausführung auf einem Computer adaptiert wurde, umfasst, wobei der Computercode betriebsfähig ist, wenn er auf einem Computer ausgeführt wird, und den Computer veranlasst: unter Verwendung von Netzwerkparametern, die nach einem nicht deterministischen Testregime verwendet werden, einen ersten Netzwerksimulatorzustand herzustellen; eine Phase nicht gescripteter Kommunikation zwischen dem Netzwerksimulator und dem Gerät, während der Netzwerksimulator sich in dem ersten Zustand befindet, zu überwachen; den Netzwerksimulator veranlasst, auf Basis eines zweiten Sets von Netzwerkparametern nach dem Testregime, in einen zweiten Netzwerksimulatorzustand überzugehen, eine Phase nicht gescripteter Kommunikation zwischen dem Netzwerksimulator und dem Gerät, während der der Netzwerksimulator sich in dem zweiten Zustand befindet, zu überwachen; und Protokolldaten im Zusammenhang mit jedem Netzwerksimulatorzustand und den damit in Verbindung stehenden Kommunikationen zwischen dem Netzwerksimulator und dem Gerät in einer Logdatei zu protokollieren.
Ein Netzwerksimulator, der für das Testen von Geräten konfiguriert ist, wobei der Netzwerksimulator umfasst: ein Protokollstapelmodul; Sendeschaltung für Kommunikationen mit dem Gerät; und einer Steuerung mit einer Schnittstelle zu einer Testanwendung, wobei die Steuerung für den Empfang von Parametern von der Testanwendung, einschließlich Protokollstapel-Parameter, betriebsfähig ist und den Netzwerksimulator veranlasst sukzessive zwischen mehreren programmierten Netzwerksimulatorzuständen auf Basis dieser Parameter überzugehen, und worin die Steuerung für die Überwachung der Phasen nicht-gescripteter drahtloser Kommunikationen zwischen dem zu testenden Gerät und dem Netzwerksimulator während jeder dieser Netzwerkzustände betriebsfähig ist.
Ein Netzwerksimulator nach Anspruch 15, worin die Sendeschaltung für Kommunikationen mit dem Gerät mindestens eine Antenne umfasst.