Sammanfattning Detta dokument presenterar en ny metod för att testa prestanda av protokoll, tjänster, eller tillämpning implementationer (IUT) under normala och överbelastning situationer, för att identifiera prestandanivåer för IUT för intervall av parameterinställningar och för att bedöma den uppmätta prestandan. En prestandaprovning beskriver exakt konfigurationen av IUT, nätverkets konfiguration och belastningsegenskaperna (den så kallade prestandatestkonfigurationen). PerfTTCN - en förlängning av TTCN med begrepp om tid, mätningar och prestanda - är en formalism för att beskriva prestandatester på ett begripligt, otvetydigt och återanvändbart sätt med fördelen att göra testresultaten jämförbara. Olika metoder för att garantera slutanvändaren vissa nivåer av QoS utvecklades, eftersom de icke-funktionella aspekterna, särskilt kvalitetsaspekter (QoS) av distribuerade telekommunikationstjänster (t.ex. multimediasamarbete, distansundervisning m.m.) är lika viktiga som funktionella aspekter. De omfattar metoder för QoS-förhandling mellan peer-användare och tjänste- och nätverksleverantör, QoS-garantier för kommunikationstjänster, QoS-övervakning och -hantering, inklusive självanpassningstillämpningar. I detta förslag behandlas QoS när det gäller testning. I allmänhet är testning en metod för att kontrollera om ett genomförande uppfyller vissa krav som beskrivs i en specifikation. QoS-testning kontrollerar end-to-end-kvalitet för en tjänsts genomförande i enlighet med QoS-kraven. En specifik klass av QoS är prestandaorienterad QoS inklusive förseningar (t.ex. av ett svar), genomgångar (t.ex. För bulkuppgifter) och skattesatser (t.ex. för fel). Vi koncentrerar oss uteslutande på prestandaorienterad QoS, andra klasser av QoS är utom räckhåll. Därefter använder vi termen prestanda istället för QoS och därmed prestandatester istället för QoS-testning. En av de väletablerade metoderna vid testning är överensstämmelseprovning, som används för att kontrollera att en tillämpning uppfyller dess funktionskrav. Eftersom konformitetstester syftar till att kontrollera rent funktionsbeteendet hos systemimplementeringar saknar de begrepp om tid och prestanda. Timers är det enda sättet att kräva vissa tidsperioder för att testhändelser ska inträffa. De används för att avgöra om testhändelser inträffar för tidigt, för sent eller inte alls. Traditionellt sett har tidsbeställningen och typen av PDU/ASP varit huvudmålet för överensstämmelseprovningen, men här försöker vi införa prestandamätningar och kvalitetskrav för tjänsten (QoS) i överensstämmelseprovningen. Prestandamätningar i a 1. Gästforskare från University of Ottawa, Kanada 2 nätverket består traditionellt i att skicka tidsstämplade paket genom ett nätverk och rekordförseningar och dataflöde. När sådana uppgifter har samlats in kan ett antal statistiska uppgifter beräknas och visas. Denna statistik kan dock någon gång vara meningslös när de faktiska förhållanden under vilka dessa mätningar har utförts är okända. Olika strategier kan användas för att studera driftsförhållandena i ett nätverk. Den ena består i att försöka analysera verklig nättrafikbelastning och korrelera den med testresultaten och den andra metoden består i att skapa artificiellt specifik nättrafikbelastning och korrelera den direkt med specifika beteenden som observeras i prestandatestet. Den första metoden gör det möjligt att studera prestanda under verkliga trafikförhållanden och konfrontera oväntade beteenden medan den andra metoden möjliggör mer exakta vetenskapliga mätningar eftersom förhållandena för ett experiment är fullt kända och kontrollerbara och korrelationer med observerade prestanda är mindre suddiga som med verklig trafik. Båda metoderna är faktiskt användbara och något kompletterande och en testcykel med båda metoderna kan övervägas genom att utforska nya beteenden med verklig trafikbelastning och sedan försöka reproducera dem artificiellt för att ytterligare förfina deras förståelse med hjälp av den andra metoden. Det framlagda tillvägagångssättet för prestandatester försöker ta itu med båda metoderna. Även om denna metod är ganska allmän, är ett av dess främsta mål för studien av ATM-nätverk prestanda på applikationsskiktet. Det tillvägagångssätt som används i detta arbete är i linje med ATM Forums prestandabenchmarkingspecifikationer [ATM96] som också är intresserade av att mäta prestanda inte på ATM-cellnivå utan av prestanda på ramnivå och prestanda som uppfattas på högre nivåer. Målen för prestandatester kan uppnås med en mängd olika befintliga språk och verktyg. TTCN [CMTF, TTCN] är den enda standardiserade, välkända och allmänt använda noteringen för beskrivningen av överensstämmelsetester, för vilka ett antal verktyg finns tillgängliga. Vi bestämde oss för att basera vårt arbete på TTCN på grund av dess breda acceptans. Vi definierar en utvidgning av TTCN-språket för att hantera prestandatester och utforska integreringen av trafikbelastningsmodeller i TTCN-språket. I båda fallen finns det begränsade kompletterande deklarationskonstruktioner som krävs för att uppnå detta mål. Vårt förslag inför ett nytt övervägande av tiden inom TTCN-språket. Hittills har den nuvarande standarden endast betraktat tid i timers där genomförandet av ett test kan förgrenas ut till en alternativ väg om en given timer går ut. Nya förslag från [KIV97] inför begrepp om lokala och globala tidsbegränsningar under genomförandet av ett dynamiskt beteende. Vårt förslag består i att samla in omfattande prover av tidsmätningar mellan utvalda testhändelser och beräkna olika statistiska uppgifter om fastställda urvalsstorlekar som ska användas vid utvärderingen av prestandaegenskaper. Dessa egenskaper används sedan för att kontrollera deras överensstämmelse med prestandabegränsningar baserade på QoS-kriterier. I motsats till nuvarande TTCN baseras en utvärdering av prestandabegränsningarna på upprepade händelser snarare än på en utvärdering av en enda händelse. I detta dokument introducerar vi först målen, huvudkoncepten och arkitekturen för prestandatestning, därefter presenterar vi språkfunktionerna för att beskriva de nya koncepten i TTCN, och slutligen presenterar vi några resultat av experiment på ett exempelhanteringsförfrågningar till en HTTP-server med hjälp av en modifierad testgenerator av några välkända TTCN-designverktyg.  Introduktion till prestandatestning Det primära målet med prestandatestning är att testa prestandan hos en implementering under normala och överbelastningssituationer. De normala och överbelastningssituationerna beskrivs med en prestandaprovningskonfiguration som identifierar IUT:s konfiguration, nätverkets konfiguration och belastningsegenskaperna. En notation för beskrivningen av prestandatester behövs, som bör ha en väldefinierad syntax och en operationell semantik för att minska möjligheterna till feltolkningar. Att notation för prestandatester är en förutsättning för att prestandatester ska vara begripliga, entydiga och återanvändbara. Den främsta fördelen med vår metod är att göra testresultaten jämförbara.Detta är i motsats till informella metoder där testmätningsresultaten endast ges med en vag beskrivning av mätkonfigurationen, så att det är svårt att återdemonstrera och jämföra resultaten exakt. Ännu en gång måste det noteras att enbart det faktum att dessa tester beskrivs formellt garanterar tvetydighet och återanvändbarhet. Ett annat mål med prestandatester är att identifiera IUT:s prestandanivåer för parameterinställningar. Flera prestandatester kommer att utföras med olika parameterinställningar. Provningsresultaten interpoleras sedan för att justera det område av parametervärde där IUT visar en viss prestandanivå. För prestandaprovning antas IUT:s överensstämmelse. Eftersom överbelastning kan försämra IUT:s funktionsbeteende för att vara felaktigt, måste man dock vara noga med att fånga upp felaktigt funktionsbeteende under prestandaprovningen på samma sätt som vid överensstämmelseprovning. Slutligen, om prestandakrav för IUT anges, bör prestandatester resultera i en bedömning av den uppmätta prestandan, dvs. uppfyller genomförandet under provningen prestandakraven eller inte. I detta avsnitt diskuteras de grundläggande begreppen i prestandatestmetoden. Begreppen är åtskilda v.r.t. Provningskonfiguration, mätningar och analys samt testbeteende. Ett prestandaprov består av flera, eventuellt fördelade förgrunds- och bakgrundsprovkomponenter. De samordnas av en huvudtestare (kontrollkomponent). En testkomponent i förgrunden inser kommunikationen med IUT. Det påverkar direkt IUT. Förgrundsprovaren använder diskreta testhändelser, som är samma testhändelser som används vid överensstämmelseprovning, för att driva IUT i specifika tillstånd där prestandamätningarna utförs. När IUT är i ett tillstånd som är under övervägande för prestandatestning, utfärdar förgrundstestaren en kontinuerlig ström av datapaket för att efterlikna förgrundsbelastningen för IUT. Förgrundsbelastningen kallas också för förgrundstrafik. Den beskrivs med hjälp av trafikmodeller. 4 En bakgrundsprovningskomponent genererar kontinuerliga dataströmmar för att emulera IUT-belastningen. En bakgrundstestare kommunicerar inte direkt med IUT. Det påverkar bara implicit IUT som det för IUT i minimala, normala, eller överbelastning situationer. Bakgrundstrafiken beskrivs också med hjälp av trafikmodeller. Trafikmodeller beskriver kommunikationsdata som en stokastisk ström av datapaket med varierande interarrivaltider och varierande paketlängd. En ofta använd modell för beskrivningen av trafiken är Markov Modulated Poison Processes (MMPP[ONV94] ). Vi valde denna modell för trafikbeskrivning på grund av dess generositet (t.ex. Ett antal olika multimediaströmmar såsom ljud och video har beskrivits som MMPP) och effektivitet (t.ex. effektiv slumptalsgenerator och en effektiv ändlig tillstånd maskin logik behövs endast). Icke desto mindre är prestandatestningsmetoden öppen för andra typer av trafikmodeller. Kontroll- och observationspunkter (PCO) är åtkomstpunkterna för förgrunds- och bakgrundsprovningskomponenterna till IUT:s gränssnitt. De erbjuder metoder för utbyte av SDU eller PDU med IUT och för övervakning av förekomsten av testhändelser (dvs. för att samla in tidsstämplar för testevenemang). En särskild användning av långlivade organiska föroreningar är att de endast används för övervakningsändamål. Övervakning krävs endast för att observera t.ex. den artificiella belastningen av bakgrundsprovkomponenterna, belastningen på verkliga nätverkskomponenter som inte styrs av prestandaprovningen eller för att observera provhändelserna i förgrundsprovkomponenten. Sammanfattningsvis använder en prestandatest en ensemble av förgrunds- och bakgrundsprovare med de använda trafikmodellerna och kontroll- och observationspunkterna samt mätpunkter. I konfigurationen för prestandaprovning beskrivs otvetydigt de förhållanden under vilka mätningarna utförs. Det är beskrivningen av prestandatestkonfigurationen som gör prestandatestexperiment återanvändbara och prestandatestmätningar jämförbara. Provningskomponenterna i ett prestandaprov får distribueras i kommunikationsnätet och får använda lastgeneratorer för att generera bakgrundstrafik och övervakare för att samla in tidsstämplar och utföra mätningar. En huvudtestare används för att samordna testarens testaktiviteter. Man kan identifiera olika klasser av prestandatestkonfigurationer beroende på vilken typ av genomförande som provas. Till exempel när det gäller prestandatestning i kommunikationsnät skiljer vi mellan prestandatestning av implementeringen (antingen i hårdvara, programvara eller båda) av • en applikation, • en end-to-end överföringstjänst, och • ett protokoll. Provningskonfigurationerna för dessa tre typer av prestandatester anges i figur 1, 2 och 3. Begreppet system under provning (SUT) omfattar alla IUT- och nätverkskomponenter. För enkelhetens skull utelämnar vi införandet av en huvudtestare i figurerna.Testkonfigurationerna skiljer sig endast i användningen av förgrundstestare. Användningen av bakgrundstestare för att generera artificiell belastning till nätverket, dvs. för att föra in nätet i normala belastnings- eller överbelastningssituationer, och mätningar av den faktiska verkliga belastningen i nätet, dvs. för att övervaka belastningen på verkliga nätverks 5-applikationer (i motsats till den artificiella bakgrundstestaren), är densamma i var och en av testkonfigurationerna. Vid prestandatestning av en server (Fig. 1), förgrundstestare efterlikna kunderna. Den provningskonfigurationen för en end-to-end-tjänst (Fig. 2) omfattar förgrundstestare i båda ändarna av end-to-end-tjänsten, som efterliknar tjänsteanvändaren. Prestandatest av ett protokoll (Fig. 3) med en distribuerad provningsmetod (se [CTMF] för andra provningsmetoder) omfattar förgrundsprovare vid den övre tillträdespunkten till det protokoll som är under provning och vid den nedre tillträdespunkten för service. Tjänsteåtkomstpunkterna reflekteras av kontroll- och observationspunkter. En mätning baseras på insamling av tidsstämplar av händelser. Man måste beskriva exakt formatet för varje händelse som hör till en mätning, så att tidsstämpeln kan samlas in när en händelse vid en viss PCO matchar det formatet. En mätning påbörjas en gång och fortsätter tills den uttryckligen annulleras eller når tidsperioden. Baserat på mätningarna kan mer utvecklade prestandaegenskaper såsom medelvärde, standardavvikelse, maximum och minimum samt distributionsfunktioner utvärderas. Dessa stöds av så kallade mått. Utvärderingen av prestandaegenskaper stöds antingen av en on-line-analys (dvs. under provningsarbetet) eller i en off-line-analys (dvs. Efter testets slut och alla prover har samlats in). On-line-analys behövs särskilt för prestandabegränsningar som gör det möjligt att beskriva kraven på den observerade prestandan så att antingen ett godkännande eller en underkännande dom kan tilldelas. En förgrundsprovningskomponent måste erbjuda funktioner för att starta och avbryta bakgrundsprovningskomponenter, för att starta och avbryta mätningar, för att generera kontrollerad belastning till IUT och för att få tillgång till de senaste mätningarna via prestandabegränsningar. Slutligen bör resultatbedömningar tilldelas så att de inte bara bedömer IUT:s observerade beteende och prestanda som sanna eller falska, utan också ger tillbaka de uppmätta prestandaegenskaperna som är av betydelse för provningsrapporten.  PerfTTCN - en prestandaförlängning av TTCN Eftersom bakgrundsprovningstrafiken är beroende av en viss testkonfiguration ska dess lokalisering och orientering läggas till i en provningskomponentkonfigurationsdeklaration (tabell 1). För varje test av bakgrundstrafik bör PCO definieras för att identifiera var testgenerationen (vänster sida) och dess destination (höger sida) befinner sig. Dessutom planeras PCO-listor för att integrera multipunktsöverföringar. De tillhörande samordningspunkterna är nödvändiga för kontroll av trafikgeneratorn och eventuella trafikövervakare. Dessa komponenter styrs av samordningsmeddelanden inom det dynamiska testbeteendet. Bakgrundstrafikens egenskaper definieras av trafikmodeller som anges i bakgrundsdeklarationer om trafikström (se nästa avsnitt). Särskilda uppgifter om t.ex. Information om anslutning såsom VPI/VCI för en ATM-anslutning omfattas av PCO PIXIT-dokumentinformationen. Syftet med bakgrundstrafiken är att skapa belastning på ett nät som kommer att passeras av kommunikationslänkarna till det system som testas. Bakgrundstrafiken är en konstant oavbruten och förutsägbar ström av paket som följer ett givet stokastiskt mönster av överföringstider. En av de viktigaste egenskaperna hos bakgrundstrafiken är att följa specifika hastighetsmönster som följer stokastiska lagar. Syftet med dessa mönster är att simulera trafiken i samband med olika typer av applikationer. De två väsentliga komponenterna i en trafikbelastning är dataflödeskonfigurationen och de stokastiska modelldeklarationerna. Dessa två komponenter kombineras sedan i deklarationerna om bakgrundstrafikström med hjälp av så många fall av kombinationer av dataflöde/stokastiska modeller som krävs för att producera betydande belastning. Detta består i att välja ut antalet fall av varje dataflöde/modellkombination. Var och en av dessa trafikflöden identifieras med ett namn som kan användas i den dynamiska beteendedelen för att starta lämplig trafikbelastning. Trafikmodellens deklaration används för att välja stokastiska modeller och ställa in deras motsvarande
-PerfTTCN (Performance TTCN ) REF utökar TTCN med koncept för prestandaprovning, såsom: prestandatestscenarier för beskrivning av testkonfigurationer, trafikmodeller för beskrivning av diskreta och kontinuerliga dataströmmar, mätpunkter som särskilda observationspunkter, mätdeklarationer för definitionen av mätvärden som ska observeras vid mätpunkter, prestandabegränsningar för att beskriva de prestandavillkor som ska uppfyllas, prestandabedömningar för bedömning av testresultat.
PerfTTCN, a TTCN language extension for performance testing
{'venue': 'Testing of Communicating Systems', 'journal': 'Testing of Communicating Systems', 'mag_field_of_study': ['Computer Science']}