QoS Regression Tests sind der pragmatischste Weg, um QoS-Änderungen objektiv zu beweisen, bevor Kunden oder interne Nutzer es merken. In vielen Netzwerken wird QoS zwar standardisiert und in Templates gegossen, aber jede Veränderung – neues SD-WAN-Release, Firewall-Update, Providerwechsel, neue UCaaS-Routen, Anpassung an Codecs oder neue Recording-/Transcoding-Flows – kann die Wirksamkeit still und leise verschieben. Das Ergebnis sind typische „schleichende“ Incidents: Voice wird zu Stoßzeiten kratzig, Video friert sporadisch ein, WebRTC fällt häufiger auf TCP/TLS zurück, oder plötzlich steigt der Default/Unmatched-Anteil, weil ein neues Traffic-Profil nicht mehr matcht. QoS Regression Tests setzen genau hier an: Sie definieren eine wiederholbare Test-Suite aus realistischen Traffic-Profilen, klaren Erfolgsmetriken (Jitter, Loss, Queue Delay, Per-Class Drops) und einer strikten Vorher-Nachher-Vergleichslogik. So können Sie nachweisen, dass eine Änderung keine Verschlechterung verursacht (Non-Regression) oder sogar messbar verbessert. Im Idealfall laufen diese Tests wie in der Software-Welt als fester Bestandteil des Change-Prozesses: automatisiert, versioniert und mit klaren Pass/Fail-Kriterien. Dieser Artikel zeigt, wie Sie QoS Regression Tests aufbauen, welche Testarten sich bewährt haben und wie Sie Ergebnisse so interpretieren, dass sie im NOC, im Engineering und im Management gleichermaßen belastbar sind.
Warum QoS besonders regressionsanfällig ist
QoS ist end-to-end und besteht aus vielen Kettengliedern: Markierung, Trust Boundary, Klassifizierung, DSCP->Queue Mapping, Scheduling, Shaping, Overlay-Encapsulation, Security-Handling und Provider-Policies. Ein einzelnes Kettenglied kann sich durch eine scheinbar harmlose Änderung verändern. Außerdem sind Echtzeitprobleme oft peak-basiert: Microbursts, kurze Congestion-Phasen und WLAN-Retries werden in klassischen 5-Minuten-Durchschnittswerten geglättet. Regressionen bleiben dadurch lange unbemerkt, bis Nutzer in Meetings oder Calls sie „laut“ machen.
- Template-Drift: neue Geräte/Standorte erhalten leicht abweichende QoS-Profile.
- Mapping-Änderungen: DSCP->Queue Tabellen oder Default-Profile ändern sich nach Upgrades.
- Overlay-Effekte: DSCP wird nicht mehr auf den Outer Header kopiert; QoS wirkt im Underlay nicht.
- Shaping-Realität: neue Linkraten oder Provider-Overhead verändern die effektive Realrate.
- Workload-Wandel: mehr Video/Sharing, neue WebRTC-Fallbacks, neue Media-Knoten.
Was ein QoS Regression Test leisten muss
Ein Regression Test ist kein generischer „Netztest“, sondern ein gezielter Nachweis, dass QoS weiterhin greift und unter Last das gewünschte Verhalten zeigt. Dafür braucht es drei Beweise: (1) Policy greift (Classifier-Hits, Marking, Mapping), (2) QoS schützt (Queue Delay/Depth, Per-Class Drops unter Congestion), (3) Servicequalität bleibt stabil (RTP/RTC-Jitter, Loss, MOS-Trends oder video-nahe Indikatoren). Ohne diese drei Ebenen können Sie zwar Metriken sammeln, aber keine belastbare Aussage treffen.
- Mechanik-Nachweis: Klassifizierung und Queue-Mapping stimmen.
- Verhaltens-Nachweis: unter Congestion schützt QoS die Echtzeitklassen.
- QoE-Nachweis: Jitter/Loss/Delay bleiben innerhalb definierter SLOs.
Testarten: Active Probing, Passive Daten und Lab-/Staging-Tests
QoS Regression Tests können je nach Umgebung unterschiedlich umgesetzt werden. Active Probing (synthetische RTP-Tests) ist ideal für reproduzierbare Vorher-Nachher-Vergleiche, auch wenn gerade keine echten Calls laufen. Passive Daten (RTP/RTCP-Stats realer Calls) sind sehr realitätsnah, benötigen aber genügend Callvolumen und sind stärker von Nutzerverhalten abhängig. Lab-/Staging-Tests sind hervorragend für kontrollierte Congestion-Szenarien, bilden aber nicht immer Providerpfade oder echte WLAN-Realität ab. In der Praxis ist eine Kombination am robustesten: Lab für mechanische und verhaltensbasierte Basistests, Active Probing für kontinuierliche Regression im Feld und passive Daten als zusätzliche Validierung.
- Lab Regression: kontrollierte Engpässe, reproduzierbare Profile, klare Pass/Fail.
- Field Probing: synthetische RTP-Streams über produktive Pfade, kontinuierlich messbar.
- Passive Validation: echte Nutzerqualität, Trends und „Bad-Call-Rate“ als Realitätscheck.
Die Regression-Suite: Welche Profile in keinem Set fehlen dürfen
Damit Regressionen sichtbar werden, braucht es Profile, die QoS wirklich fordern. Das bedeutet: Echtzeitprofile plus „Störprofile“, die Congestion erzeugen. Ein reiner Voice-Test bei leerem Link beweist wenig. Ein gutes Set enthält mindestens Voice-like (konstant, klein, jitterkritisch), Media-like (Video), Sharing-like (burstig), Signalisierung/Control und einen Best-Effort/Bulk-Störer, der den Engpass füllt. Entscheidend ist, dass jedes Profil klar dokumentiert ist: Paketgrößen, Intervalle, DSCP, Zielraten, Burstmuster und Testdauer.
- Voice-like RTP: kleines UDP, konstantes Intervall (z. B. 20 ms), DSCP Voice.
- Media-like: höhere Rate, größere Pakete, DSCP Media/Video, moderate Variabilität.
- Sharing-like: burstige Ratewechsel, separate Klasse oder kontrolliertes Media-Profil.
- Signal/Control: geringe Rate, aber priorisiert, um Setup- und Control-Stabilität zu prüfen.
- Best Effort/Bulk: TCP-lastig oder gemischter Datenverkehr, der den Engpass bewusst saturiert.
Erfolgsmetriken: Pass/Fail muss messbar und robust sein
Regression Tests scheitern häufig daran, dass sie zu schwammige Kriterien verwenden. „Fühlt sich gut an“ ist keine Abnahme. Für Echtzeit sind Perzentile oft SLA-tauglicher als Mittelwerte, weil Peaks entscheidend sind. Zusätzlich sollten Sie nicht nur QoE (Jitter/Loss) betrachten, sondern auch QoS-Mechanik: Queue Delay/Depth, Per-Class Drops und Drop Reasons. So erkennen Sie auch „stille“ Regressionen, bei denen QoE noch knapp gut ist, aber die Queue bereits dauerhaft näher an der Kante läuft.
- Jitter 95p/99p: pro Profil und Pfad; zeigt Peak-Verhalten.
- Paketverlust: Prozent + Burst-Loss-Indikator; wichtig für Hörbarkeit und Videoartefakte.
- Delay/RTT: besonders relevant bei Bufferbloat; Anstieg ohne Drops ist ein Warnsignal.
- Queue Delay/Depth: pro Echtzeitklasse; Frühindikator für Degradation.
- Per-Class Drops: Voice/Media idealerweise 0; Best Effort kann Dropping tragen.
- Drop Reasons: Policer Drops in Echtzeit sind nahezu immer „Fail“.
Vorher-Nachher-Logik: So beweisen Sie Regression oder Verbesserung
Ein Regression Test ist immer ein Vergleich. Der wichtigste Schritt ist daher die Baseline: Sie müssen wissen, wie „gut“ der Pfad vor der Änderung war. Baselines sollten zeitlich vergleichbar sein (gleiche Tageszeit/Peak), und idealerweise gibt es eine Control Group (unveränderte Standorte/Links), um externe Effekte wie Provider-Schwankungen zu filtern. Der Vergleich erfolgt dann nicht nur auf einem Wert, sondern auf einer Metrikmenge: QoE-KPIs plus QoS-Mechanik-KPIs. So entsteht ein belastbarer Nachweis.
- Baseline Window: definierter Zeitraum vor dem Change, gleiche Lastbedingungen.
- Control Group: ähnliche Standorte/Links ohne Change als Referenz.
- Change Marker: Change-Zeitpunkt in Zeitreihen sichtbar machen.
- Delta-Analyse: Perzentile und Quoten vergleichen, nicht nur Mittelwerte.
Regressionen sichtbar machen: Typische „Failure Patterns“
QoS Regressionen zeigen oft wiederkehrende Muster. Wenn Voice plötzlich in Best Effort landet, sehen Sie Classifier-Drift: Default/Unmatched wächst, Voice-Klasse zählt weniger. Wenn Shaping fehlt oder falsch ist, sehen Sie Queue Delay nicht im Router, sondern QoE verschlechtert sich ohne klare Drops im Gerät, weil Congestion im Modem/Provider-Puffer passiert. Wenn Policers zu aggressiv sind, sehen Sie Policer Drops und Loss-Spikes ohne vorheriges Queue-Wachstum. Diese Muster sollten Teil der Regression-Auswertung sein, weil sie direkt zur Ursache führen.
- Mis-Marking Regression: Voice/Media Classifier-Hits sinken, Default/Unmatched steigt.
- Mapping Regression: DSCP ist da, aber Queue-Mapping anders; Drops/Delay in falscher Queue.
- Shaping Regression: QoE kippt bei Upload-Last, Queue-Telemetry bleibt „zu sauber“.
- Policer Regression: Policer Drops in Echtzeit, Burst-Loss, plötzliche Aussetzer.
- Bufferbloat Regression: Delay/Jitter 99p steigt, Drops bleiben niedrig.
Regressions-Set für QoS-Mechanik: Checks, die immer laufen sollten
Neben Traffic-Profiles brauchen Sie mechanische Checks, die unabhängig von Last funktionieren. Diese Checks sind besonders wertvoll in CI-/Change-Prozessen, weil sie schnell laufen und viele Fehler früh entdecken. Dazu gehören Policy Attachments (richtige Policy am richtigen Interface, richtige Richtung), DSCP->Queue Mapping Konsistenz, Trust Boundary Regeln und „No Never Events“ wie WRED in Voice oder Policers auf Voice.
- Attachment Check: QoS-Policy ist am WAN-Egress gebunden, nicht nur irgendwo im LAN.
- Mapping Check: DSCP->Queue konsistent über Geräte und Rollen.
- Trust Boundary Check: Markierungen werden an den richtigen Punkten trusted oder normalisiert.
- Guardrail Check: keine Policers auf Voice, keine WRED Drops in Echtzeitklassen.
- Classifier Drift Watch: Default/Unmatched-Anteil im Normalbetrieb nicht ansteigend.
Integration in den Change-Prozess: Wann Regression Tests laufen sollten
Damit Kunden Änderungen nicht „als Erste testen“, müssen Regression Tests in den Change-Prozess eingebaut werden. Ein bewährtes Modell ist: Vor dem Change eine Baseline (kurz, aber hochauflösend), direkt nach dem Change ein kurzer „Smoke Test“ (Policy greift, keine Guardrail-Verletzungen), und in den folgenden Peak-Phasen ein erweitertes Regression-Fenster (QoE und Queue-Perzentile). Bei riskanten Änderungen (SD-WAN/Firewall/Provider) empfiehlt sich zusätzlich ein Canary Rollout mit Regression-Checks pro Stufe.
- Pre-Change Baseline: kurze, definierte Messung als Referenz.
- Post-Change Smoke: Classifier-Hits, DSCP, Queue-Mapping, keine Policer Drops.
- Peak Validation: während typischer Lastfenster prüfen (Meetings, Contact Center Busy Hour).
- Canary Stufen: Regression Tests pro Welle, mit Stop-/Rollback-Guardrails.
Automatisierung und Reporting: Regression als „Pass/Fail“ statt Chart-Wand
Regression Tests werden erst dann operativ, wenn sie eine klare Entscheidung liefern. Das bedeutet nicht, dass Sie Details wegwerfen, sondern dass Sie eine aggregierte Pass/Fail-Logik definieren: „Non-Regression erfüllt“ wenn alle SLOs innerhalb Toleranz sind und keine Guardrails verletzt wurden. Dazu gehört auch ein kurzer Executive Report: Was wurde getestet, welche Pfade, welche Profile, welche Ergebnisse. Für Engineering muss ein Drilldown verfügbar sein: welche Klasse, welcher Engpass, welche Drop Reasons.
- Scorecard: pro Pfad/Profile ein Status (Pass/Warn/Fail) basierend auf SLOs und Guardrails.
- Evidence Bundle: Links/Exports zu Queue Delay/Depth, Per-Class Drops, Classifier-Hits, QoE-Metriken.
- Trendvergleich: Baseline vs. Post-Change (Perzentile) plus Control Group.
Typische Stolperfallen bei QoS Regression Tests
Viele Regression-Programme scheitern an Details, die die Aussagekraft verwässern. Wenn Sie zu selten testen, verpassen Sie Peaks. Wenn Sie nur Mittelwerte nutzen, übersehen Sie Microbursts. Wenn Sie keine Control Group haben, verwechseln Sie Provider-Schwankungen mit Regression. Wenn Ihre synthetischen Tests den falschen Pfad nehmen (z. B. anderes Internet-Breakout), testen Sie am Problem vorbei. Und wenn Sie nur QoE messen, aber nicht die QoS-Mechanik, sehen Sie nicht, dass das System bereits am Limit läuft.
- Falscher Pfad: Tests müssen denselben Exit/Overlay nutzen wie produktiver Verkehr.
- Zu grobe Auflösung: Sekundenereignisse in Minutenmitteln sind unsichtbar.
- Keine Mechanikdaten: ohne Queue/Drop/Classifier fehlt Root Cause Fähigkeit.
- Keine Baseline/Control: externe Einflüsse verfälschen Entscheidungen.
- Unrealistische Profile: Tests ohne Congestion beweisen QoS kaum.
Pragmatische Regression-Suite: Ein Set, das in den meisten Umgebungen funktioniert
- Mechanik Smoke Test: Classifier-Hits pro Klasse, DSCP Preservation, DSCP->Queue Mapping, Policy Attachment am WAN-Egress.
- Voice Non-Regression: Voice-like RTP-Probe, Jitter 95p/99p, Loss, Queue Delay Voice; Guardrail „Voice Drops = 0“.
- Media Non-Regression: Media-like Profil, Queue Delay Media, Drops in Media; Sharing optional separat.
- Congestion Proof: Bulk/BE saturiert Engpass, Echtzeit bleibt stabil, Best Effort trägt Delay/Drops.
- Guardrail Checks: Policer Drops in Echtzeit = Fail, Default/Unmatched Drift = Warn/Fail je nach Schwelle.
- Post-Change Peak Window: Tests während echter Stoßzeiten zur Realitätsvalidierung.
