Softwaretests bei RTI

RTI-Software ist das Herz vieler geschäftskritischer Systeme. Unsere Kunden legen selbstverständlich großen Wert auf die Zuverlässigkeit und Qualität ihrer Systeme. Wenn ich mich mit Kunden treffe und den RTI-Entwicklungsprozess vorstelle, diskutieren wir die Entwicklungspraktiken, die von uns verwendeten Tools und das RTI IIoT-Labor. Viele sind besonders neugierig auf die Softwaretests, die wir bei RTI durchführen und die Testframeworks, die wir verwenden. Ich genieße diese Gespräche immer; Wir sind stolz auf unsere Aufmerksamkeit beim Testen. Dieser Blogpost fasst die von uns durchgeführten Tests zusammen.

Unser Entwicklungsprozess und unsere Tests gelten für die gesamte RTI Connext-Produktsuite. Die Ausnahme bildet RTI Connext DDS CERT, das auf Anwendungen abzielt, die eine Sicherheitszertifizierung erfordern und einem anderen Entwicklungsprozess folgen. Während der Entwicklung und bevor RTI neue Software veröffentlicht, führen wir eine Vielzahl von Tests durch, um die korrekte Funktionalität zu validieren und sicherzustellen, dass die Software gut funktioniert und skaliert.

Einheitentests Überprüfen Sie, ob die einzelnen Funktionen wie erwartet funktionieren. Unit-Tests werden bei jedem Produktrelease als wichtigster Regressionstestmechanismus verwendet. Das Unit-Test-Framework kann mehr als nur einzelne Funktionen testen. Es ermöglicht auch eine Ebene von Single-Node-Feature-Tests. In neueren Versionen haben wir sogar vom Kunden bereitgestellte Quality of Service (QoS)-Einstellungen als Teil unserer Testkonfiguration integriert. Unsere Prozesse sind darauf ausgelegt, die korrekte Funktion in möglichst realistischen Umgebungen sicherzustellen.

Im Rahmen der Entwicklung neuer Funktionen erstellen wir einen Funktionstestplan und implementieren eine Reihe von End-to-End-Funktionstests . Diese Tests werden über einen maßgeschneiderten Testsatz oder im Fall von Connext DDS Micro in einem neuen verteilten Test-Framework implementiert. Diese Testumgebung verwendet eine Reihe von „Testläufern“, die Tests auf verschiedenen Computern ausführen, und einen „Testmanager“, der die Testausführung zwischen den Testläufern synchronisiert. Zur Beschreibung der Tests wurde eine einfache DDS-Testsprache entwickelt, und jeder Testläufer führt ein Skript aus, veröffentlicht die Ergebnisse (PASS/FAIL) und wartet auf die Ausführung des nächsten Skripts. Der Hauptfokus der Funktionstests liegt auf:

• Testen Sie APIs auf Anwendungsebene und DDS-QoS-Richtlinien (Frist, Lebendigkeit usw.)
• Ressourcenlimits testen
• Cross Endianness testen
• Testerkennung
• Testleistung
• Stabilität sicherstellen

Wir führen verschiedene Interoperabilitätstests durch:

• Wir testen die Interoperabilität mit anderen RTI-Produkten während der Entwicklung und während des Installationstests. Wir haben eine Reihe von automatisierten Interoperabilitätstests entwickelt. Connext 6 hat beispielsweise eine Reihe neuer Funktionen eingeführt, die die Bibliotheken von Connext DDS Micro 3.0 und Connext DDS Core 6.0 gemeinsam haben. Wir haben automatisch Tausende von Konfigurationskombinationen generiert und das korrekte Verhalten validiert. Die Interoperabilität mit älteren RTI-Versionen wird getestet, wenn wir nach der Analyse feststellen, dass die Gefahr besteht, die Interoperabilität zu beeinträchtigen.
• Sprachinteroperabilität erfolgt indirekt, da einige unserer Tools in Java oder anderen Sprachen geschrieben sind. Wir testen beispielsweise die Interoperabilität mit einer Java-basierten Anwendung, wenn wir die Java-basierten Tools von RTI wie die RTI Admin Console in Kombination mit Anwendungen in anderen Sprachen verwenden.
• Ein grundlegendes Maß an Interoperabilität mit anderen DDS-Anbietern wird regelmäßig bei DDS-Meetings der Object Management Group (OMG) durchgeführt. Anbieter koordinieren eine eingehendere Reihe von Tests, um DDS-Sicherheit, erweiterbare Typen und das DDS-RTPS-Drahtprotokoll zu validieren (https://github.com/omg-dds).

Tests installieren Integrations- und Interoperabilitätstests zwischen mehreren Produkten erfassen. Diese Tests werden sowohl manuell als auch über eine automatisierte Testsuite zur Installation ausgeführt. Installationstests deckt eine Vielzahl von Integrations- und Interoperabilitätsproblemen ab:

• Installation - Sind alle Dateien richtig installiert?
• Grafische Benutzeroberfläche (GUI) - Derzeit gibt es keine automatisierten GUI-Tests. Während des manuellen Installationstests überprüfen wir, ob die Integrationen ordnungsgemäß funktionieren:z. B. zwischen RTI Launcher und rtiddsgen , oder rtiprototyper .
• Dokumentation - Wird die richtige Dokumentation geliefert?
• Grundlegende Funktionstests für alle Produkte anhand der ausgelieferten Beispiele. Für einige Produkte gehen wir das gesamte Handbuch "Erste Schritte" durch. Dieser Test wird auf einer Vielzahl von Plattformen wiederholt.
• Grundlegende Produkt- und Sprachinteroperabilitätstests .

Um diese Tests zu beschleunigen und zu erweitern, haben wir automatische Installationstests für viele Funktionen. Aktuelle Tests umfassen:

• Installation - Dateiprüfung, um sicherzustellen, dass die Dateien richtig installiert sind.
• Ausführen der Dienstprogramme, einschließlich rtiddsping , rtiddsspy und rtiprototyper.
• Ausführen von rtiddsgen-generierten Beispielen in C, C++, C++03, C++11, C++ CLI, C# und Java unter Verwendung einer Kombination aus statischen/dynamischen und Release/Debug-DDS-Bibliotheken.
• Ausgeführte Beispiele mit einer Kombination aus statischen/dynamischen und Release/Debugging-DDS-Bibliotheken ausführen.
• Leistungsbeispiele in C++ und Java.
• TCP-versandte Beispiele in C.

Diese Tests werden auf 80 verschiedenen Architekturen ausgeführt, darunter Windows-, Linux-, Solaris-, Lynx-, QNX-, Darwin- und VxWorks-Plattformen.

Wir haben verschiedene Leistungs- und Speicherprofiltests. Die Erstellung eines validen und aussagekräftigen verteilten Leistungstests ist äußerst anspruchsvoll. Einfache Ansätze können Kompromisse in Bezug auf Puffer, Durchsatz, Latenz, Echtzeitbereitstellung, Stacks und Betriebssystem nicht handhaben oder auch nur grob messen. RTI verfügt über umfangreiche Erfahrung bei der Bewertung der Leistungskennzahlen, die für reale Systeme am wichtigsten sind.

• Einheitentests erfassen Leistungs- und Speicherinformationen für bestimmte Funktionen.
• Wir verwenden unseren Leistungstest (perfTest) um die Leistung von Connext DDS zu charakterisieren. Wir haben viel in perfTest investiert, damit es realistische Messungen durchführen kann. Es kann in Verbindung mit anderen Produkten wie Routing Service verwendet werden. Wir verwenden PerfTest, um unsere öffentlichen Latenz- und Durchsatzdaten zu sammeln. Leistungsergebnisse sind unter https://www.rti.com/products/dds/benchmarks.html verfügbar.
• memTest wurde erstellt, um den Speicherbedarf von Connext DDS Core zu überwachen. Connext DDS Micro sammelt im Rahmen der Komponententests detaillierte Informationen zum Speicherbedarf.
• Andere Anwendungen wie die RTI Admin Console und der RTI Recording Service verfügen über integrierte Leistungsüberwachungsfunktionen.

Die kontinuierliche Integration von PerfTest und MemTest stellt sicher, dass wir keine Rückschritte machen (über einen voreingestellten Prozentsatz hinaus), wenn dem Connext DDS-Produkt neue Funktionen hinzugefügt werden.

Ausdauertests emulieren Langzeitszenarien. Dauertests überwachen den Heap-Speicher in verschiedenen dynamischen Anwendungsfällen, z. B. beim Erstellen und Löschen von Remote-Teilnehmern oder Erstellen und Löschen von Remote-Endpunkten. Das Dauertest-Framework läuft auch mit RTI Security Plugins in einem Fuzz-Test-Anwendungsfall, bei dem die RTPS-Pakete zufällig geändert werden. Die Tests werden mit der neuesten allgemein verfügbaren Version (GAR) ausgeführt.

Groß angelegte und Stresstests wird gezielt im Rahmen der Entwicklung neuer Funktionen erstellt. Als wir beispielsweise Transport Mobility (auch bekannt als IP-Mobilität) einführten, haben wir eine Reihe von Tests erstellt, um das Verbinden und Trennen von verschiedenen drahtlosen Zugangspunkten zu emulieren. Als wir die Discovery-Implementierung verbessert haben, haben wir ein spezielles Test-Framework erstellt, um Tausende von Endpunkten zu simulieren und automatisch zu überprüfen, ob sie von jeder Anwendung erkannt wurden. Typischerweise werden diese Tests nicht bei jedem Release erneut durchgeführt, teilweise aufgrund der Geräte- und Netzwerkanforderungen. Einige Tests (z. B. ein umfangreicher Erkennungstest) werden erneut ausgeführt, wenn wir Änderungen an der Erkennungsimplementierung vornehmen.

Unser Produkt ist leistungsstark und komplex und muss in einer erstaunlichen Viel

[1] [2] 下一页