Empfohlenes Webinar: KI-gestütztes API-Testing: Ein No-Code-Ansatz zum Testen | Zum Video

Lesezeit: 4 Minuten

Übersicht

Vor der Servicevirtualisierung geriet das Performance-Testing-Team von Comcast häufig in Planungskonflikte bei der gemeinsamen Nutzung der Testinfrastruktur. Manchmal waren nachgelagerte Systeme nicht verfügbar. In anderen Fällen versuchten Testingenieure, gleichzeitig Tests durchzuführen, was sich auf die Testergebnisse auswirken könnte. Dies führte zu Variabilität zwischen den Tests, was es schwierig machte, bestimmte Probleme zu isolieren.

Erfahren Sie mehr über die Ergebnisse, die Comcast nach erfolgreicher Implementierung der Service-Virtualisierung erzielt hat – und warum Service-Virtualisierung eine Schlüsselkomponente unserer DevOps-Initiative ist.

Die Herausforderungen

Von Frank Jennings, Director TQM Performance Testing bei Comcast

Mein Team bei Comcast führt Leistungstests in einer Reihe von Branchen im Unternehmen durch – von Geschäftsservices über unsere Enterprise-Services-Plattform bis hin zu kundenorientierten Benutzeroberflächen und Backend-Systemen, die die Bereitstellung und Aktivierung der Geräte für die Abonnenten auf dem Comcast-Netzwerk. Während unsere Testziele (AUTs) in der Regel über Staging-Umgebungen verfügen, die die Leistung der Produktionssysteme genau darstellen, ist dies bei den Staging-Systemen für die Abhängigkeiten der AUT nicht der Fall.

Erschwerend kam hinzu, dass diese Umgebungen schwer zugänglich waren. Wenn wir Zugriff hatten, haben wir manchmal die unteren Umgebungen (die QA- oder Integrationstestumgebungen) heruntergefahren, weil sie nicht angemessen skaliert waren und die Last einfach nicht bewältigen konnten. Auch wenn die Systeme der Belastung standhalten konnten, haben wir von diesen Systemen sehr schlechte Reaktionszeiten erhalten. Dies bedeutete, dass unsere Leistungstestergebnisse die reale Leistung nicht wirklich vorhersagen konnten.

Ein weiteres Problem ist, dass wir häufige und lange Ausfallzeiten in den Staging-Umgebungen umgehen mussten. Die Staging-Umgebung war während der häufigen Upgrades oder Software-Updates nicht verfügbar. Infolgedessen konnten wir unsere vollständigen Leistungstests nicht durchführen. Leistungstestteams mussten wichtige Projekte zu kritischen Zeiten abschalten, um beschäftigt zu bleiben – sie wussten, dass sie ihrer Hauptverantwortung nicht nachkommen konnten, weil die Systeme, auf die sie zugreifen mussten, einfach nicht verfügbar waren.

Diese Herausforderungen trieben die Kosten in die Höhe, verringerten die Effizienz des Teams und wirkten sich auf die Zuverlässigkeit und Vorhersagbarkeit unserer Leistungstests aus. Wir wussten, dass wir handeln mussten – und deshalb begannen wir, uns mit der Service-Virtualisierung zu befassen. Letztendlich stellten wir fest, dass der Zeit- und Kostenaufwand für die Implementierung der Service-Virtualisierung weit geringer war als der Zeit- und Kostenaufwand für die Implementierung all der verschiedenen Systeme in all diesen Staging-Umgebungen – oder für den Aufbau der Konnektivität zwischen den verschiedenen Staging-Umgebungen.

Die Ergebnisse

Wir haben uns aus zwei Hauptgründen der Service-Virtualisierung zugewandt. Zunächst wollten wir die Genauigkeit der Leistungstestergebnisse erhöhen. Zweitens haben wir in den gestuften Testumgebungen ständig mit häufigen und langen Ausfallzeiten gearbeitet.

Unser anfänglicher Fokus lag auf den größten Schwachstellen in Bezug auf Terminkonflikte innerhalb der Leistungstestteams, nicht verfügbare Systeme und Systeme, bei denen sich unsere Tests auf andere Entwicklungs- oder Testgruppen auswirken würden. Seit unserer Gründung konnten wir etwa 98 % der an unseren Tests beteiligten Schnittstellen virtualisieren und konnten den Zeitaufwand für die Erstellung und Pflege von Testdaten um 65 % pro Jahr reduzieren (unter Berücksichtigung der Zeit, die wir benötigen). Ausgaben für die Erstellung und Aktualisierung virtueller Assets). Außerdem haben wir die Ausfallzeiten der Staging-Umgebung um 60 % reduziert.

Da wir mit der Arbeit an unseren Skripten im Vergleich zu virtuellen Assets in der Entwicklungsumgebung beginnen können, haben wir in der Regel alles recht früh in jedem Sprint bereit. Früher brauchten wir zwei Wochen, um den Code zu testen, sobald wir ihn in unseren Staging-Umgebungen hatten (z. B. mit durchschnittlichen Lasttests, Spitzenlasttests, Dauertests usw.). Das haben wir auf zwei oder drei Tage geschrumpft.

Lösungsvorteile

Unsere Tests sind jetzt vorhersehbarer, konsistenter und repräsentativer für das, was in der Produktion zu sehen wäre. Darüber hinaus können wir in vielen Fällen auch den Testumfang erhöhen. Wir können beispielsweise bestimmte tatsächliche Dienste nicht mit der Produktionslast belasten, aber wenn wir mit virtuellen Diensten arbeiten, können wir sie mit Lasten auf Produktionsebene hochfahren und realistische Antworten erhalten, sowohl in Bezug auf Daten als auch auf Leistung. Wir können die AUT wirklich isolieren, nicht nur aus der Perspektive des Leistungstests, sondern auch aus der Perspektive des Leistungsprofils. Anstatt der Entwicklung nur zu sagen: „Das ist die Leistung Ihres Systems“, können wir auch sagen: „Hier sehen wir die Engpässe und hier denken wir, dass Änderungen den Durchsatz der Anwendung verbessern könnten.“

Der Hauptvorteil für das Leistungstestteam ist die erhöhte Betriebszeit und Verfügbarkeit der Testumgebungen. Die Servicevirtualisierung hat es uns ermöglicht, von unseren Testmitarbeitern eine hervorragende Auslastung zu erzielen, mehr Projekte zeitgerecht abzuschließen und außerdem Geld zu sparen, indem die Gesamtkosten für die Durchführung der für eine bestimmte Version erforderlichen Tests gesenkt wurden.

Service-Virtualisierung und DevOps

Leistungstest In unseren Staging-Umgebungen konnten wir die Service-Virtualisierung auch für alles nutzen, von Unit-Tests und Regressionstests in der Entwicklungsumgebung über Baseline-Performance-Tests in frühen Downstream-Umgebungen bis hin zu Funktions- und Regressionstests in der QA/integrierten Umgebung bis hin zu manuelles/exploratives Testen in einer Umgebung, die der Produktion ziemlich nahe kommt (aber in einigen Fällen virtuelle Assets verwendet).

Die gesamte Konfiguration und Bereitstellung virtueller Assets für die verschiedenen Umgebungen wird als Teil unserer DevOps-Infrastruktur automatisiert. Umgebungen wechseln automatisch zwischen virtuellen Assets und tatsächlichen Assets gemäß den von uns definierten Geschäftsregeln – zum Beispiel basierend darauf, von welchem ​​Endpunkt der Datenverkehr kommt, welche Daten in den Testpaketen enthalten sind und so weiter. Dies Service-Virtualisierungslösung hat es uns ermöglicht, kontinuierliche Tests als integralen Bestandteil unseres DevOps-Prozesses zu erreichen.

Erfahren Sie, wie Sie die richtige Service-Virtualisierungslösung für Ihr Unternehmen auswählen.

  • Industrie: Philadelphia, Pennsylvania
  • Firmengröße: 190,000
  • Standort: Telekommunikation
  • Lösung: Virtualisieren