Testmetoder för QoE på plattformar för mediastreaming: Är automatisering lösningen?

I ett tidigare blogginlägg tog jag upp hur de föränderliga paradigmerna inom Quality of Experience (QoE), särskilt när det gäller testning och validering, håller på att omforma OTT-medielandskapet. Med funktioner som tillgång till innehåll på begäran och anpassat innehåll, möjligheter att titta på flera enheter samt överlägsen kvalitet som bidrar till att driva, definiera och omforma ekosystemet är det ingen överraskning att OTT-revolutionen, som drivs av QoE, bara kommer att fortsätta att bli starkare framöver. 

Låt oss fördjupa oss lite mer i detaljerna kring QoE och testningen av den för att förstå dess roll och inverkan på framgången för globala mediastreamingplattformar.

QoE påverkas främst av fyra arbetsflöden:

• Spelararbetsflöden: Där nya applikationsfunktioner läggs till eller uppdateras, nya SDK:er integreras osv.
• Arbetsflöden för innehåll: Där mezzanine-videon transkodas, krypteras, paketeras och skickas till CDN
• Arbetsflöden för kodningsprofiler: Där det sker flera mindre ändringar och optimeringar i transkodningsdelen av innehållsarbetsflödet
• Infrastrukturarbetsflöden: Där olika andra system i OTT-applikationens backend, såsom DRM, protokoll, vattenmärkning och CMS, uppdateras

                                                                                                                      Arbetsflödet för QoE (Quality of Experience)

Dessa nyckelkomponenter i OTT-ekosystemet kräver omfattande testning i förproduktionsmiljön. Och när applikationen väl har släppts (eller skickats) till produktions-/kundfasen, registrerar och rapporterar en spelarbeacon kundens QoE, vilket etablerar ett direkt samband mellan denna viktiga indikator och streamingplattformens framgång.

Det vi måste komma ihåg här är att eftersom varje QoE-enhet som testas är en kombination av olika delar av OTT-ekosystemet, är det viktigt att testa den systematiskt och på ett organiserat sätt – med en tydlig förståelse för tittarnas ekosystem och de förväntade användningsmönstren.

Testning av slutenheter är det bästa sättet att identifiera QoE för en mediastreamingplattform. Ett QoE-test faller underkategorin NFR, vilket genomförs i betydligt färre anläggningar jämfört med funktionstester.

Återigen är QoE-testning idag mestadels manuell eller halvautomatisk (i bästa fall), vilket innebär att det krävs betydande tid och investeringar för att säkerställa och uppfylla de förväntade parametrarna. Eftersom tittarnas efterfrågemönster fortsätter att vara mycket dynamiska finns det ett akut behov av att optimera dessa cykeltider för att säkerställa förbättrade resultat.

Situationen kompliceras ytterligare av att manuella (eller halvautomatiska) QoE-tester inte alltid hjälper till att upptäcka den rätta korrelationen som krävs, inklusive så viktiga aspekter som starttid, buffring över olika bandbreddsströmmar, ABR-prestanda och effekten av andra infrastrukturella förändringar.

Vi måste därför jämföra och ställa förändringarna mot varandra och driva utvecklingen av nya verktyg för strömningsoptimering för att omdefiniera befintliga QoE-testparadigm.

Här kommer automatiseringen in.

Även om automatiseringen av QoE-testning är betydligt mer komplex än vanlig funktionell automatisering – eftersom den kräver en helt annan logik och ett annat tankesätt – är det inte ett ouppnåeligt mål. Resan består inledningsvis av olika funktionella automatiseringsskript och logiker när vi automatiserar en applikation och navigerar genom dess EPG till uppspelningsscenarierna.

Det som är avgörande här är behovet av att utforma API:er och skript som kan hantera QoE-nyckeltal för strömning redan från det att videouppspelningen påbörjas. Kravet är att fokusera på korrekt användning av tekniker för automatiseringsskriptning och på att skapa skript som utnyttjar de API:er som tillhandahålls inom det önskade automatiseringsverktyget eller ramverket.

Vi måste komma ihåg att de vanliga API:erna eller teknikerna för mätning av icke-funktionella krav (NFR) och prestanda kanske inte är direkt användbara i automatiserade testscenarier. Dessutom måste KPI:erna mätas tillsammans med en uppsättning andra parametrar som definierar systemets tillstånd vid mätningstillfället. Att mäta buffringsgraden mot varierande nivåer av Wi-Fi-signalstyrka (mätt vid slutenheten) är ett exempel som kommer att tänka på.

Vårt mål är inte bara att förlita oss på resultaten från QoE-API:erna, utan att sammanställa och jämföra rätt metadata och miljöförhållanden för att dra meningsfulla slutsatser där presentationslagret för dessa test- och benchmarkdata blir viktigt. Ett bra QoE-testsystem tillhandahåller därför inte bara API:er eller funktioner för att mäta relevanta KPI:er, utan kan även hantera nätverket, samla in nätverksförfrågningar, applikations- eller spelarloggar samt enhetsloggar etc.

En sådan automatiserad lösning bör kunna söka automatiskt efter alla datapunkter som behövs för att prioritera och besluta om vilka åtgärder som ska vidtas för förbättring. Denna förmåga utgör en tydlig skiljelinje mellan QoE-verktyg som är specialutvecklade för ändamålet och testautomatiseringsverktyg med NFR-kapacitet.

• Mätning av KPI:er i intervaller om 20 millisekunder eller med noggrannhet på ramnivå
• Krävande GPU-baserad bearbetning
• Sammanställning av all relevant metadata för att korrelera och generera meningsfulla insikter
• Metod för att på ett tillförlitligt sätt hantera nätverksmodeller
• Tillgång till en lämplig uppsättning nätverksmodeller eller mallar att använda för QoE-tester

Bortsett från utmaningarna och hindren ligger framtiden helt klart i ett förnyat fokus på att säkerställa och leverera en förstklassig QoE, en som skulle bidra till att differentiera den aktuella streamingplattformen från sina rivaler och konkurrenter. Och automatiserad testning, driven av djup expertis inom digital teknik, är vägen framåt.

1.Ett QoE-test startas utifrån en CI-utlösare, ett schema eller manuell körning

2.QoE Test Manager startar testet på en specifik enhet

3.QoE -testlösningen automatiserar appen till ett läge där den är redo att spela upp innehåll

4.Cogmation är oberoende av spelaren och simulerar vad kunden skulle se

5.Ett vanligt testmönster utsätter spelaren för påfrestningar i en rad troliga scenarier

6.En nätverksproxy styr den ström som visas, bandbredden den visas med och registrerar den data som utbyts

7.Uppspelningen av innehållet körs och innehåller ett antal stopp- och starthändelser samt reklam

8.Det specialutvecklade Capture API:et för QoE -mätvärden registrerar viktiga aspekter av QoE

9. De insamlade QoE -nyckeltalen rapporteras tillsammans med relevant metadata

10.De rapporterade värdena från videoanalysen valideras

11.Resultaten presenteras i en rapport och skickas tillbaka till den anropande CI-pipeline som godkänd/underkänd där så är lämpligt