Nulägesanalys & Kravspecifikation

Nulägesanalys & Kravspecifikation Thord Schibler/Johan André Examensarbetare vid AU-System Mobile 1999 3 augusti 1999

Innehåll Ordlista & Förkortningar 1 1 Bakgrund 2 1.1 Inledning... 2 1.2 Avgränsningar... 2 1.3 Testning... 2 1.4 SIM-kortstester... 3 1.5 Automatisering... 3 1.5.1 Autmatiserad testmiljö... 4 2 Krav 4 2.1 Övergripande systemkrav... 4 2.1.1 Helheten JT... 4 2.1.2 Automatisering JT... 4 2.1.3 Transportservern JT... 4 2.1.4 Terminering S... 4 2.1.5 Expanderbar S... 4 2.1.6 Testfall JT... 5 2.1.7 Applikationer JT... 5 2.2 Kommunikationsspecifika krav... 5 2.2.1 SFM A... 5 2.2.2 Protokoll för SMS-C A... 5 2.2.3 Terminal Response A,F... 5 2.2.4 SEND-SM F... 5 2.2.5 SAP F... 6 2.3 Testspecifika krav... 6 2.3.1 Verifiering S... 6 2.3.2 Loggar JT,F... 6 2.3.3 Testverktyg S... 6 2.3.4 TP-OA H... 6 Referenser 6 Dokument: JTXM01.doc

Ordlista & Förkortningar AviSIM Klientapplikationer Administrator & Service Assistant som hanterar nedladdningar och uppdateringar till SIM-kort GSM Global System Mobile GSM 11.xx Specifikationer som innehåller kommunikationsprotokoll för kommunikation mellan ME och SIM-kort och STK överföringar ME Mobile Equipment Mobil enhet/telefonen Komponent Systemkomponent De systemdelar som möjliggör uppdatering och hantering av SIM-kort och dess data, enligt figur 1. OTA Over-The-Air Samlingsnamn för de funktioner som kan ändra datat på ett SIM-kort genom att skicka SMS SAP SIM Application Platform Internt kommunikationsverktyg som förenklar kodning av bl a trådning SEND-SM Meddelandetyp som genereras av SIMkortet SFM SIM FileManagement Klientapplikation SIM Subscriber IdentityModule SMS Short Message Service SMS-C Short Message Service Centre Server SMS-Gateway Sköter kopplingen mellan TS och SMS- C STK SIM ToolKit Funktioner som stödjer nedladding av applikationer, menyer mm. på enme och SIM-kort STM SIM Toolkit Messaging Simpos AviSIMPOS Mjukvara som via en kortläsare kan arrangera datat på ett SIM-kort genom diverse olika funktioner System Alla delar och komponenter som finns mellan ett SIM-kort och en klientapplikation, se figur 1 TP-OA Transfer Protocol Originating Address Den adress som utfärdar ett SMS, och som då skall ta emot ett eventuellt svar TS Transportserver Består av tre delar SFM, SMS-Gatewayoch OTA-Server Toolbox Mjukvara som via en kortläsare läser och visar filer (filstrukturbaserat) på ett SIM-kort och som kan uppdatera och ändra dessa TR Terminal Response Svar som ME kan skicka till SIM-kortet som bekräftelse Dokument: JTXM01.doc 1(6)

1 Bakgrund 1.1 Inledning Vid testning av SIM-kort och stöd för dessa är man oftast tvungen att (skarpt) använda sig av GSMnätet. Speciellt då man vill testa nyfunktionalitet såsom applikationer, nya funktioner eller allmänna nedladdningar på kortet. Då GSM-nätet och dess inverkan på överföringen inte tillför något för testningen av SIM-kortet önskar man elimiera detta i kedjan, se figur 1, av systemkomponenter vid testförfarandet. Klient OTA-Server DB GSM SIM Klient STM-Server SMS-Gateway SMS-C Figur 1: Kedjan av systemkomponenter. 1.2 Avgränsningar Målet är att lyfta ut de komponenter som inte påverkar resultatet av SIM-kortsnedladdningar utan att påverka någon funktionalitet i systemet. Efter ett möte 990628, [1], beslutades det att allt mellan Transportservern (TS) och SIM-kortet, d.v.s. SMS-C, GSM-nätet och telefonen (ME), inte skall vara med vid testningarna och istället skall en nysystemkomponent ta över och emulera kommunikationen mellan TS och SIM-kort. Den grafiska representationen av ME och SIM-kortets innehåll kommer inte att emuleras. 1.3 Testning Testning kan delas in i tre olika grupper som markant skiljer sig från varandra vad det gäller både förväntningar på resultat och vilka skäl som ligger bakom en testning. Tillfällig testning Tester som utförs då ochdå (ad-hoc-karaktär) och som inte är nämnvärt stora i omfång och tid. Parametrisk testning När en produkt är i slutfasen och det skall verifieras att den dels har den förväntade funktionaliteten och ett därtill hörande korrekt uppträdande. Dessa tester är, mer eller mindre, av iterativ karaktär och de tar mycket tid och är väldigt omfattande. De kan dock delas in i s.k. canned transactions som består av i förväg noga programmerade standardmässiga 1 scenarior. Sofistikerad testning Tester som utförs av ingenjörer, forskare, utvecklare o.s.v. Dessa tester har en väldigt komplex karaktär och är stundom tidskrävande. 1.4 SIM-kortstester På AU-System finns de tre testprinciperna enligt 1.3 representerade och de följer i stort sett förfarandet som illustreras i figur 2. Klientapplikationer används för att mata in data och SMS som skall ned på kortet. 1 Med standardmässiga avses de för produkten vanliga scenarier, procedurer, förlopp m.m. Dokument: JTXM01.doc 2(6)

AviSIM OTA Service Assistant Administrator Inmatning Transportserver Klient DB SMS-C MS GSM-Nät Verifiering Överföring Applikation Toolbox Simpos ME Nedladdning Figur 2: Testningsförlopp vid test av SIM-kort. 1. Överföring Informationen går igenom TS som kommunicerar med DB och vidarebefodrar informationen vidare till SMS-C. SMS-C lägger på en header innan det skickas via GSM-nätet till ME. 2. Nedladdning ME tar emot och laddar ned datat (filer, applikationer o.s.v.) på kortet enligt GSM 11.11. 3. Verifiering Detta går till på olika sätt beroende på vilken typ av nedladdning det är, exempelvis OTA, SMS eller STK. (a) Via telefonens menyer direkt verifiera resultatet. (b) Genom att låta SIMPos läsa på kortet via en kortläsare och visa vad som finns på kortet. (c) Genom att låta SIM Toolkit läsa in filstrukturen från kortet via en kortläsare och visa filer och dess innehåll. 1.5 Automatisering När man väljer att automatisera ett test måste man göra en avvägning inför hur man tror framtiden kommer att påverka testet. Det är oftast mindre kostsamt att en gång göra ett manuellt test än att ta fram en automatisk testmetod för ett test. På samma vis är det mindre kostsamt att utveckla en automatisk testmetod där många testomgångar skall genomföras jämfört mot att göra det manuellt varje omgång. För att få en effektiv automatiserad testning av SIM-kortsnedladdningar ska vi utveckla denna nya systemkomponent, nämd under 1.2. Det blir en applikation med arbetsnamnet SIM-ShortCut som kommer att utföra dessa emuleringar. Därefter kommer ett testverktyg styra klientapplikationerna för nedladdningar och verifieringar. På så sätt kommer det bli möjligt att utveckla effektiva testmiljöer för olika kortstöd. 1.5.1 Autmatiserad testmiljö Det som följer efter användandet av ett testverktyg och SIM-ShortCut är att skapa sig en bank av olika tester. Till en början bör man utveckla generiska tester för de kort som man vill stödja och sedan med dessa som grund ta fram specifika tester som subgrupper för de respektive korten. En faktor som gör att det blir Dokument: JTXM01.doc 3(6)

mindre kostsamt är att alltid spara de tester-miljöer som görs för respektive kort för att på sätt bygga upp sin bank av färdiga tester. Sedan bör det också finnas väl dokumenterade besrkivningar av vad testerna gör och förväntas resultera i. Det sistnämnda innefattas dock inte inom ramarna för examensarbetet. 2 Krav De krav som vi, JA och TS, har tagit fram härur främst ifrån de möten som varit, [1, 2]. I kommande avsnitt, 2.2-2.3, finns kraven uppställda och indelade tre huvudgrupper enligt kommunikationsoch testkrav samt övergripande systemkrav. För varje krav finns en notering som indikerar vem som har ställt kravet enligt: Allmänt/Övergripande A Fredrik Broman F Hilde Digernes H Johan & Thord JT Staffan Lindgren S 2.1 Övergripande systemkrav 2.1.1 Helheten JT Systemet som helhet med dess komponenter skall ej påverkas. Samtliga systemkomponenter skall kunna fungera och operera på samma sätt som om SIM-ShortCut inte var inkopplad. Detta är viktigt då man vill behålla systemets normala uppträdande vid testerna. 2.1.2 Automatisering JT Testförfarandet skall automatiseras. För att kunna automatisera testerna behövs en effektiv testplattform som fås genom att nyttja ett testverktyg (Visual Test), SIM-ShortCut och en kortläsare och sätta upp det enligt figur 3 och sedan ta fram olika testscenarior. 2.1.3 Transportservern JT Allt som kommer från TS, Transportservern, skall laddas ned på kortet. Eftersom SMS-C och telefonen ersätts av SIM-ShortCut skall således allt som är kommer från TS transformeras, formateras och laddas ned på kortet. 2.1.4 Terminering S Tester skall kunna terminera mot ett SIM-kort. 2.1.5 Expanderbar S Det skall vara en expanderbar applikation. SIM-ShortCut skall implementeras på sådant sätt att - det är enkelt att lägga till nya funktioner - det inte krävs några större eller omfattande ändringar av SIM-ShortCut då närliggande systemkomponenter genomgår mindre ändringar. 2.1.6 Testfall JT De testfall som skall tas om hand om är endast de grundfall 4-5 stycken till dags datum. För att det ska vara möjligt för JA och TS att göra färdigt SIM-ShortCut inom tidsramarana för examensarbetet avgränsas antalet testfall. Dokument: JTXM01.doc 4(6)

Klient Transportserver Applikation SIM-ShortCut Testverktyg Visual Test DLL SIM Verifiering Toolbox Kortläsare Figur 3: SIM-ShortCut insatt i systemkedjan. 2.1.7 Applikationer JT De applikationer som behöver skall kunna få ta emot bekräftelser (ackar). Enligt 2.1.1-1 skall de klientapplikationer som vanligtvis får bekräftelser (acknowledgement) från exempelvis SMS-C även då SIM-ShortCut används fortfarande få dessa 2.2 Kommunikationsspecifika krav 2.2.1 SFM A Samtliga SMS-typer skall stödjas: 1. 7-bitars 2. 8-bitars 3. Unicode (16-bitars) Dessa är de tre nuvarande standardiserade SMS-formaten och dessa måste därför stödjas helt. 2.2.2 Protokoll för SMS-C A Endast ett protokoll i SMS-C bör användas det skall vara UCP som använder sig av TCP/IP. UCP stödjer två kanaler så att det blir kommunikation med full duplex mot SIM-kortet. 2.2.3 Terminal Response A,F Vid STK-meddelande skall det alltid skickas ett terminal-response till kortet. 2.2.4 SEND-SM F Alla send-sm skall skickas vidare till Transportservern. 2.2.5 SAP F Det internt utvecklade kommunikationsverktyget SAP bör användas för att förenkla kodingen och slippa programmeringstrådning. Dokument: JTXM01.doc 5(6)

2.3 Testspecifika krav 2.3.1 Verifiering S Det skall gå att verifiera resultatet av en nedladdning. Efter en nedladding vill man kunna kontrollera vad som blev nedladdat och även hur det gick. 2.3.2 Loggar JT,F Alla operationer, transaktioner och bekräftelser (ackar) skall loggas i fil. En typisk rad i loggen kan innehålla: 1. datum 2. tid 3. debugnivå 4. status 5. vilket kommando som utfört vad. 2.3.3 Testverktyg S Visual Test bör användas för att kunna verifiera resutatet av en nedladdning. Visual Test bör användas för att den har möjligheter att kommunicera med och styra Toolboxen. På såsätt kan nya tester läggas till med ett script som då relativt enkelt kan verifieras. 2.3.4 TP-OA H Det skall vara möjligt att konfigurera tp-oa, Transfer Protocol Originating Address, i en ini-fil 2 som läses av SIM-ShortCut. Referenser [1] //FRMNTW/DOCS/Kravdiskussion990628 v2.doc, sammanställning av mötesanteckningar från 990628. [2] //FRMNTW/DOCS/Krav990706.doc, sammanställning av anteckningar från JA och TS modellering. 2 En fil med liknande syntax och semantik som Windows initieringsfiler (.ini) har. Dokument: JTXM01.doc 6(6)