Styrande faktorer och övergripande systemkrav vid av Examensarbete utfört vid, KTH & Utvecklings ochforskningsavdelningen vid AU-System Mobile Mh.Th. 99-10 Industrial Control Systems School of Electrical Engineering and Information Technology KTH, Royal Institute of Technology Stockholm, SWEDEN
Abstract Leading aspects and overall systems requirements in testing SIM card communication As the development of new services for mobile phones, Over-The-Air functions and applications with SIM Application Toolkit, new demands on comprehensive test procedures arise. The objective with this Master Thesis has been to map the overall aspects on developing and testing these services, and, to evaluate and improve the existing test process, and, if possible, also then automate the test procedure. Measurements showed that the most time consuming parts where latencies in the GSM network and the tedious manual test labour. An evaluation indicated that an application that bypassed the GSM network and the mobile phone would make the test procedure more efficient, thus enabling Short Messages to be transferred directly to the SIM card. A literature study on requirements engineering and automated tests was performed, enabling a requirements capture on the test environment where the application was to operate in. To get the overall picture, an investigation of technologies was performed in the field of mobile telecommunications and especially related to SIM cards and Short Message Service, SMS. Following the implementation and introduction of the application into the test environment there were an improvement of, as much as, 65%. The automation of the test procedure was not as successful and the improvement was negligible compared to the bare introduction of the application in the test environment. Keywords: GSM network, OTA - Over-The-Air, SAT - SIM Application Toolkit, SIM cards, SMS, automating tests, automated test tools, mobile communication, requirements engineering, testing. i ABSTRACT
Sammanfattning Vid utvecklingen av nya tjänster till mobiltelefoner, Over-The-Air-funktioner och SIM Application Toolkitprogram, krävs en omfattande testprocedur för att verifiera resultaten. Målet med detta examensarbetet har varit att kartlägga de bakomliggande faktorerna vid utvecklandet och testandet av dessa tjänstesystem, och även förbättra den befintliga testproceduren, och eventuellt automatisera testförfarandet. Det visade sig att den mest ineffektiva delen i testmiljön var relaterad till fördröjningar i GSM-nätet samt det enahanda manuella testarbetet. Efter en utvärdering ansågs att en applikation som emulerade GSM-nätet samt mobiltelefonen skulle kunna effektivisera testprocessen för att på så sätt kunna skicka SMS, Short Message Service, direkt till SIM-kortet. För att ta fram kraven, på testmiljön som applikation skulle operera i, utfördes en grundlig studie i kravhantering och autotester. För att få med helheten kring testprocedurerna sammanställdes även en nulägesanalys av mobiltelefoni med inriktning på SIM-kort och SMS. Efter att ha implementerat och infört applikationen i testmiljön blev resultatet att tiden för att utföra ett test förkortades med hela 65%. Dock så blev automatiseringen ej lika lyckad då tidsfaktorn vid automatiseringen endast förbättrades marginellt i jämförelse med den icke automatiserade lösningen. Nyckelord: GSM, OTA - Over-The-Air, SAT- SIM Application Toolkit, SIM-kort, SMS, autotester, autotestverktyg, kravhantering, mobiltelefoni, requirements engineering, testning. ii SAMMANFATTNING
Förord Detta examensarbete genomfördes under sommaren samt hösten 1999 på dåvarande AU-System Mobile av vid, KTH tillsammans med Johan André, vid Institutionen för Teleinformatik, KTH. Efter att ha arbetat närmare 21 veckor på Utvecklings och Forskningsavdelningen på AU-System Mobile kan jag se tillbaka på en mycket givande och rolig tid. Dessa veckor har gett mig nya erfarenheter, ett stort antal nya förkortningar, ny kunskap samt nya vänner. Jag vill tacka alla på Mobile för deras hjälp och tid, speciellt Hilde Digernes och Fredrik Broman för deras svar på frågor om SIM-kort och SMS, Simon Wallén, Fredrik Almgren, Filip Rosenbaum och Kenneth Johansson för deras programmeringskunskaper, Jörgen Hult, Anki Andersson och Anders Månsson för deras ovärderliga kunskaper om transportservern. Jag vill även passa på att tacka Per Lundh för det mycket intressanta samtalet som vi hade. Sedan vill jag även tacka mina handledare, Erik Johansson,, KTH och Staffan Lindgren Testansvarig, AU-System Mobile. Dessa två skall ha ett stort tack för de kommentarer och hjälp som de bidragit med under arbetets gång. De mötena som jag och Erik hade innebar oftast att jag lämnade mötena med fler frågor än jag hade när vi började mötena, med de var alla väldigt givande och nyttiga för mig och min rapportering. Till sist vill jag även tacka Johan André som jag utförde examensarbetet tillsammans med. Utan honom hade arbetet inte förlupit så smidigt som det gjorde och examensarbetet hade inte varit så givande och trevligt som det faktiskt blev. Stort tack ska ni alla ha!, november 1999 iii FÖRORD
Innehåll I Introduktion 1 1 Inledning 1 1.1 Presentation av AU-System... 1 1.1.1 Verksamheten tillämpad tele- och datakommunikation... 1 1.1.2 Kompetensen... 1 1.1.3 AU-System Mobile... 2 1.2 Bakgrund... 2 1.2.1 Nya tjänster... 2 1.2.2 Den befintliga testproceduren... 3 1.2.3 Kommande tester... 3 1.3 Mål och syfte... 5 1.3.1 Problemformulering... 5 1.3.2 Avgränsningar... 5 1.4 Rapportdisposition... 6 II Teorier 7 2 Kravhantering 7 2.1 Inledning... 7 2.2 Ett systems användarcykel... 7 2.3 Krav... 8 2.3.1 Aktiviteter under kravhanteringsfasen... 8 2.4 Utmaningar i kravprocessen... 9 2.4.1 Specifikationsarbetet... 9 2.4.2 Problematiken... 10 2.5 Fel i kravhanteringsprocessen... 11 2.6 Dokumentering... 11 2.6.1 Helheten formulerad... 12 2.6.2 Kravhanteringen i utvecklingsprocessen...... 13 3Automatiserad testning 14 3.1 In- och uppspelningsverktyg... 14 3.1.1 Testning av användargränssnitt... 14 3.1.2 Regressionstest... 14 3.2 Problematiken... 15 3.2.1 Myterna... 15 3.2.2 Paradigmen... 16 3.2.3 Strategi... 16 3.3 Klassiska misstag och problem... 18 3.3.1 Rollen... 18 3.3.2 Planering... 18 3.3.3 Personal... 19 3.3.4 Arbetet... 19 3.3.5 Teknologins framfart ställd mot det ekonomiska faktorerna... 21 3.4 Vilka tester kan automatiseras?... 21 3.4.1 Autotestets livslängd... 22 3.4.2 Värdet av ett autotest... 23 III Nulägesanalys 26 INNEHÅLLSFÖRTECKNING
4 Utredning av teknologier 26 4.1 Telekom... 26 4.2 Mobiltelefoni... 26 4.2.1 GSM Historia(Global System Mobile)... 26 4.2.2 Standarder... 26 4.3 SIM-kort, Subscriber Identity Module... 27 4.3.1 Kort historia... 27 4.3.2 Modul för en abonnents identitet... 27 4.3.3 Teknisk beskrivning... 27 4.3.4 Den elektriska karakteristiken... 28 4.3.5 Kortkonfiguration... 28 4.3.6 Arkitekturen hos ett SIM-kort... 29 4.3.7 Funktionalitet... 31 4.3.8 SIM Application Toolkit... 32 4.4 Short Message Service, SMS... 34 4.4.1 Strukturen hos ett SM... 34 4.4.2 Användardatat i ett SM... 36 4.4.3 OTA-SM... 36 4.5 Nätverksuppbyggnad... 36 4.5.1 SMS-överföringens primitiver... 36 4.5.2 Protokollagren i SMS-miljön... 39 4.6 AviSIM OTA Service center... 40 4.6.1 Systemarkitekturen hos AviSIM OTA-SC... 40 4.6.2 Klienttjänster Applikationer... 41 4.7 Framtiden... 42 4.7.1 Standarder... 42 4.7.2 GPRS... 42 4.7.3 Marknaden styr... 43 4.7.4 Historien innehåller inte hela sanningen... 43 4.7.5 IP - ärettkrav... 43 4.7.6 Uppdelning av mobiltelefon... 43 4.7.7 WAP - Wireless Application Protocol... 44 4.7.8 WIG.... 44 4.7.9 Framtidens aktörer... 44 IVGenomförande 45 5 Metod 45 5.1 Mätningar på dagens tester... 45 5.2 Skall testerna automatiseras?... 46 5.2.1 Är en applikationsprototyp lämplig?... 47 5.2.2 Tillvägagångssätt... 48 5.2.3 Krav... 48 5.2.4 Begränsningar... 50 5.2.5 Arkitektur... 50 6 Implementation 52 6.1 Utgångsläget... 52 6.1.1 Språket... 52 6.2 Design... 52 6.2.1 Kommunikation... 53 6.2.2 Loggning..... 56 6.2.3 Användarkonfigurationer... 56 6.2.4 Iaktagelser under utvecklingen... 57 INNEHÅLLSFÖRTECKNING
6.2.5 Verifiering...... 57 7 Resultat 58 7.1 Autotestets prestanda... 58 7.2 Slutsatser... 58 7.2.1 De bakomliggande faktorerna... 59 7.2.2 De övergripande aspekterna... 59 7.3 Fortsatt arbete... 60 INNEHÅLLSFÖRTECKNING
Figurer 1 Den övergripande systemmiljön i OTA-plattformen.... 2 2 Testförfarandet vid test av stöd för SIM-kort [B1].... 3 3 Miljön för Wireless Internet Gateway och dess komponenter.... 4 4 Systemmiljön, där molnet innesluter de komponenter som skulle modelleras för att eventuellt kunna elimineras...... 5 5 Ett godtyckligt systems användarcykel [21].... 7 6 En process för kravhantering [21].... 9 7 Betydelsen för ett formulerat krav... 12 8 Skriptkod, med och utan användandet av ett API [23].... 15 9 Schematisk grovfördelning av en applikations innehåll [23].... 19 10 Schematisk grovfördelning av en applikation med testpunkter [23].... 20 11 Autotestets liv och faser [26].... 22 12 Koden i en applikation; kod under test, mellanliggande kod och testets kodpropagering [26]. 22 13 Koden i en applikation samt testpunkter och ramverk [26].... 23 14 Området under det horisontella strecket är stödkoden och området ovan illustrerar funktionskoden, här med fem specifika funktioner [26].... 23 15 En ändring i en funktion har gjorts i kod under test (den mörkare delen) [26].... 24 16 Här har två funktionsdelar ändrats och en ytterligare har lagts till. För att dessa nya koddelar skall fungera har även en viss del av stödkoden ändrats/påverkats [26].... 24 17 Tre tester, med olika indata och resultat, men som alla använder sig av samma stödkod [26]. 24 18 Kod under test uppdelat i mindre delar med block av stödkod [26].... 25 19 Ett SIM-korts tre olika användarfaser [11].... 28 20 Den övergripande strukturen hos ett SIM-kort [11].... 29 21 Exempel på filstrukturen hos ett SIM-kort.... 30 22 Händelseförloppet för ett SMS för SIM-uppdatering. Env. = envelope, XX indikerar längden på kommandot som skall hämtas. ETSI[18].... 33 23 Uppbyggnaden hos ett SM... 35 24 Den generella strukturen på SMS-enheter. SMS-GMSCanvänds vid MT-meddelanden (SMS- C mobiltelefon) och SMS-IWMSCanvänds vid MO-meddelanden (mobiltelefon SMS-C) ETSI[18].... 36 25 MWD: De intressanta delarna i HLR ur ett SMS-perspektiv.... 37 26 Protokollagren för Short Message Services. Bilden kommer från ETSI[17].... 39 27 Systemarkitekturen hos AviSIM OTA-SC [3].... 40 28 AviSIM OTA Service Centre med samtliga klienttjänster [3].... 41 29 Testmiljön vid OTA-uppdateringar..... 45 30 Fördelningen av tiden mellan GSM-nätverksfördröjningar och det manuella arbetet.... 46 31 Figuren illustrerar den övergripande arkitekturen vid användandet av den nya testproceduren med en applikation. Den lilla gubben motsvaras av en testare vid sin dator som kör alla applikationer [B1].... 47 32 Arkitekturen med implementationsfaserna [B2].... 53 33 Programarkitekturen för applikationen [B2]... 54 34 Flödet mellan Transportservern, applikationen och SIM-kortet.... 54 35 De interna flödesdesignen hos applikationen. De delar med dubbelram exekverar som en tråd [34].... 55 36 Fördelningen av tiden i de tre fallen.... 58 FIGURER
Tabeller 1 Fel och dess orsaker som kan uppstå i en kravprocess... 11 2 Innehållsförteckning för ett allmänt kravdokument [21].... 11 3 SMS-typer.... 34 4 Protokoll för kommunikation med ett SMS-C och respektive tillverkare.... 38 5 Intressenter och aktörer inom telekombranchen. Tabellen illustrerar att det är många inblandade med ibland olika positioner (leverantör, tillverkare, kund etc.) och att gränserna inte är helt uppenbara.... 44 6 De närmast involverade personerna i kravprocessen.... 48 TABELLER
Ordlista & Förkortningar ADN Abbreviated Dialling Numbers MT Mobile Terminated API Application Programming Interface, Meddelanden till mobiltelefonen programmeringsgränssnitt för en applikation Addressen på den enhet som utfärdat OA Originating Address CDMA Code Division Multiple Access ett visst meddelande. CPHS Common PCN Handset Specification OS operativsystem CR-verktyg Capture-and-Replay tools OTA-SC OTA Service Centre in- och uppspelningsverktyg OTA Over-The-Air DCS Digital Cellular System Samlingsnamn för de funktioner som kan ändra datat på ett SIM-kort genom att skicka SMS DF Dedicated File filtyp på ett SIM-kort PCN Personal Communications Network EDGE Enhanced Data rate for GSM Evolution PIN Personal Identification Number EF Elementary File PLMN Public Land Mobile Network filtyp på ett SIM-kort PUK Personal Unblocking Key ETSI European Telecommunications Standards Institute AU-Systems interna ramverk SAP SIM Application Platform GPRS General Packet Radio Service SAT SIM Application ToolKit GSM Global System Mobile Funktioner som stödjer nedladding av applikationer, menyer mm. på enmo- biltelefon och SIM-kort HLR Home Location Register HMI Human Machine Interface SC Service Centre ICC Integrated circuit Chip Card, smartcard SEND-SM Meddelandetyp som genereras av SIMkortet IMSI International Mobile Subscriber Identity SFM SIM File Management Klientapplikation IP Interaktions punkter SIM Subscriber Identity Module i ett grafiskt användargränssnitt SME Short Message Entity ISDN Integrated Services Digital Network SMS-C Short Message Service Centre LND Last Number Dialled SMS-GMSC SMS Gateway MSC MAP Mobile Application Part SMS-IWMSC SMS InternetWorking MSC MCEF Mobile-station-Capacity-Exceeded-Flag SMS Short Message Service ME Mobile Equipment Mobilentelefonen SM Short Message MF Master File SS7 Signalling System 7 Huvudfilen på ett SIM-kort STM SIM Toolkit Messaging MNRF Mobile-station-Not-Reachable-Flag TDMA Time Division Multiple Access MNRR Mobile-station-Not-Reachable-Reason TP-OA Transfer Protocol OA MO Mobile Originated Den adress som utfärdar ett SMS, och Meddelanden från mobiltelefonen som då skall ta emot ett eventuellt svar MSC Mobile Switching Centre TR Terminal Response MSISDN Mobile Station international ISDN Number Svar som en mobiltelefon kan skicka till SIM-kortet som bekräftelse MS Mobile Station TS Transportserver Mobilentelefonen och SIM-kortet sett Består av två delar STM och SMSsom en entitet ORDLISTA & FÖRKORTNINGAR
Gateway. UMTS Universal Mobile Telecommunication System VLR Visitor Location Register W-CDMA Wideband-CDMA WAP Wireless Application Protocol WIG Wireless Internet Gateway WML Wireless Markup Language ORDLISTA & FÖRKORTNINGAR
Del I Introduktion 1 Inledning En övergripande bild av ett systems utgångspunkt, med förståelse för varje systemkomponents roll, är ett krav för att kunna specificera och leverera ett fullskaligt utbud av tjänster och applikationer. Utvecklingen av GSM är en evolutionär process, system, funktioner och applikationer utvecklas i olika hastighet och i varierande grad, där den systemdel (av nätverk/sim-kort/mobiltelefon) som har den lägsta funktionaliteten bestämmer vad systemet kan erbjuda. I dagsläget finns det ett stort antal teleoperatörer världen över med olika tjänsteutbud. Det som de har gemensamt är möjligheten att erbjuda sina kunder, abonnenterna, nya tjänster i form av olika mervärdesfunktioner t.ex. biljettbeställning, banktransaktioner, bokningar, väderprognoser mm. Vid testning av dessa olika tjänster i form av applikationer, nedladdningar och uppdateringar från olika klienter mot ett SIM-kort, går dessa datameddelanden igenom hela GSM-systemet. Då GSM-nätet ej garanterar direkt leverans vid en överföring introduceras fördröjningar. Detta utgör således ett hinder för att kunna utföra automatiska tester vilket gör att testprocessen är både tidskonsumerande och ineffektiv. De tester som utförs i dagsläget har visserligen en positiv egenskap då en nedladdad testapplikation direkt kan interagera mellan SIM-kort och mobiltelefonen. Denna testmiljö, där meddelanden och applikationer överförs mellan SIM-kort och exempelvis en klient, ligger som grund för detta examensarbete 1 och det som skall modelleras är bl.a. hur GSM-nätet kan lyftas ut ur överföringskedjan. SIM-kort och övriga systemkomponenter skall inte märka att överföringar inte går via GSM-nätet, d.v.s. systemets överföringskarakteristik skall inte påverkas av den lösning som tas fram. 1.1 Presentation av AU-System AU-System[1] grundades 1974 och blev Sveriges första programvaruspecialist inom datakommunikation. AU-System är ett av landets största konsult- och programvaruföretag inom tele- och datakommunikation. Under våren 1999 omstrukturerades AU-System till ett mer renodlat konsultbolag. Sedan april 1999 är Schroder Ventures ägare till 75% och de skall tillsammans med Ericsson, den näst största ägaren, stärka AU-System i den fortsatta planerade internationella expansionen. 1.1.1 Verksamheten tillämpad tele- och datakommunikation AU-System är ett välkänt namn bland de stora aktörerna inom tele-, mobil- och datakommunikation. De har en stor andel av landets största telekomföretag som kunder. Cirka 60% av verksamheten vänder sig till operatörer och leverantörer inom telekommunikation medan 40% avser projekt och lösningar för slutkunder som banker, industriföretag och myndigheter. 1.1.2 Kompetensen Genom att lära sig ny kommunikationsteknik i projekt för stora IT-leverantörer för att därefter tillämpa tekniken i integrationsuppdrag för banker och stora industriföretag kan man på ett effektivt sätt att bygga upp företagets och de anställdas kompetens. Ett av de mest kraftfulla sätten att bygga och överföra AU-System inriktar sig på hur tekniken kan integreras och tillämpas för att bli till mest nytta för användarna. kunskap och erfarenhet är att jobba i projekt tillsammans med kollegor i egna lokaler. Till skillnad från andra mer renodlade konsultföretag arbetar därför 60-75% av personalen i de egna lokalerna med tillgång till kompetenta och erfarna kollegor. Detta medför att en kund som betalar för en konsulttjänst får mer 1 examensarbetet är även benämnt projektet i rapporten 1(62) DEL I: 1. Inledning
än den enskilde konsultens kompetens, då de även får tillgång till den kunskap som konsultens kollegor har. 1.1.3AU-System Mobile AU-System Mobile 2 arbetar framförallt med systemlösningar mot SIM-kort för framförallt mobiltelefonoperatörer. De utvecklar olika s.k. Over-The-Air system, OTA, t.ex: OTA-Server, figur 1, är en plattform för alla tjänster baserade på OTA-SIM-kortshantering som stödjer metoder för fjärrhantering av applikationer i en mobiltelefons SIM-kort, lägga till och uppdatera data. Personaliseringssystem för SIM-kort, nedladdning av rådata på SIM-kortet (det innehåll som ett kort har när det kommer i handen på en slutkund). SIM Application Toolkit, tillhandahåller funktioner som möjliggör SIM-kortbaserade applikationer att interagera med en mobiltelefon. Figur 1: Den övergripande systemmiljön i OTA-plattformen. 1.2 Bakgrund 1.2.1 Nya tjänster Möjligheten att administrera SIM-kort över luften öppnar nya dörrar för tjänsteutbudet till användarna. Ett exempel på dessa nya tjänster är mobil e-handel där abonnenterna använder sin mobiltelefon för betala och beställa produkter. Biljettbokning till bio eller en konsert kan snart genomföras med en mobiltelefon: biljetten bokas via Internet betalningen sker genom att kunden med hjälp av mobiltelefonen godkänner köpet Säkerhetsfunktionerna på SIM-kortet kan utnyttjas för att t.ex. innehålla pengar, på samma sätt som cash-kort. Ett ytterligare exempel är då en försäljare vill säkerställa en kunds identitet, vilket kan ske genom att kunden konfirmerar ett meddelande som försäljaren skickat till kundens mobiltelefon. I Grekland har föräldrarna idag möjligheten att programmera deras barns mobiltelefoner så att de endast kan ringa de telefonnummer som föräldrarna godkänt. Detta görs via en Internetapplikation som använder sig av OTA. Ett annat affärsområde som är mycket intresserade av dessa nya tjänster är aktiehandeln. I Singapore har mobiloperatören Singtel redan börjat använda ett system som gör det möjligt för abonnenterna att köpa och sälja aktier med mobiltelefonen och i dagsläget är det runt 400 kunder som utnyttjar dessa tjänster. Tekniken som används i detta system är SIM Application Toolkit, SAT (se avsnitt 4.3.8). 2 Sedan oktober 1999 heter nu företaget Across Wireless[2] 2(62) DEL I: 1. Inledning 1.2 Bakgrund
OTA-meddelanden, (Over-The-Air), ger operatörerna nya möjligheter, t.ex. kan de enkelt fjärruppdatera abonnenternas telefoner med exempelvis ett nytt nummer till deras kundtjänst och lägga in det i telefonboken på SIM-kortet. 1.2.2 Den befintliga testproceduren För att kunna verifiera att OTA Service Centre (OTA-SC), se avsnitt 4.6, stödjer de kort som operatörerna erbjuder sina kunder, måste dessa testas. Detta görs manuellt, se figur 2, genom att samtidigt använda tre olika applikationer. Testförloppet genomförs på följande sätt: 1. Välj lämpliga uppdateringskommandon i OTA Service Assistant 3, t.ex. uppdatera telefonboken. Sedan skickas dessa kommandon till SIM-kortet via GSM-nätverket och mobiltelefonen. Figur 2: Testförfarandet vid test av stöd för SIM-kort [B1]. 2. Beroende på vilken fil som uppdaterades på SIM-kortet finns det två olika applikationer som kan användas för att verifiera resultatet. Den ena visar filernas innehåll i hexadecimalkod och den andra visar klartext. I de fall som det inte går att verifiera resultatet med mobiltelefonen så används någon av dessa två applikationer. Vid genomförandet av detta test måste SIM-kortet flyttas mellan mobiltelefonen och en kortläsare och dessa frekventa operationer tar mycket tid. Testet är också resurskrävande då det överförs via GSMnätet, och (om det inte framgått) så är det ett mycket enahanda arbete. I dagsläget är detta det enda verifieringssättet som dessa kortstöd kan testas på. Ett annat scenario är när olika SIM-kort testas för att undersöka hur de stöder OTA-meddelanden. I dessa fall är intresset fokuserat på hur SIM-kortet agerar efter en nedladdning. Det är på uppdrag av mobiloperatörerna som vill försäkra sig om att deras nya kort stöder OTA-meddelanden innan de massproduceras och distribueras till kunderna. Dessa tester utförs på samma sätt som vid verifieringen av OTA-meddelanden. 1.2.3Kommande tester Mobilt Internet[5] är det område som nu verkar vara det enda som är av intresse inom telekomvärlden. Alla människor utrustade med en mobiltelefon skall snart kunna surfa på nätet. Ett sätt som möjliggör 3 Service Assistant är en applikation som används för att administrera filerna på SIM-kort. 3(62) DEL I: 1. Inledning 1.2 Bakgrund
detta är att använda applikationer på kortet med SAT, SIM Application Toolkit. För kunna stödja SATmeddelanden uppkommer vissa nya krav på Transportservern (en central del i överföringen av meddelanden) och därmed nya testfall. De nya testfallen ämnar testa stödet för SAT i Transportservern och kan delas in i två stycken grundfall (figur 3). Mellan Internet finns en gateway, Wireless Internet Gateway, Figur 3: Miljön för Wireless Internet Gateway och dess komponenter. WIG, som är uppkopplad mot en Transportserver. WIGen består av en Push- och en Requestserver. Det första testfallet utförs enligt: 1. Användaren skickar en begäran (request) via mobiltelefonen genom GSM-nätet till en Transportserver. Det kan exempelvis vara begäran om en specifik websida. 2. Requestet skickas vidare till en Requestserver i en gateway (Wireless Internet Gateway, WIG, se 4.7.8). 3. Requestservern kommunicerar med den webbservern som har den aktuella webbsidan. 4. Den begärda sidan överförs sedan till Transportservern som vidareförmedlar den till mobiltelefonen via GSM-nätet. I det andra fallet vill Transportserverns beteende också undersökas, fast nu initierar Pushservern trafiken. Pushservern används för att överföra requests från Internet till mobiltelefonen. Till exempel kan det vara då en person vill köpa en produkt via Internet. Personen kan då konfirmera betalningen samt sin identitet genom att acceptera ett nedladdat acceptansrequest som leverantören skickat via Internet. Testförfarandet för detta utförs enligt: 1. En acceptansbegäran skickas till Pushservern från Internet. 2. Det överförs till Transportservern som skickar det vidare till mobiltelefonen via GSM-nätet. 3. Mobiltelefonanvändaren accepterar eller nekar förfrågan och svaret skickas tillbaka till GSM-nätet. 4. Transportservern vidareförmedlar svaret till Pushservern som skickar det till utfärdaren. Dessa testfall är av intresse vid utvecklingen av automationstester, därför att dessa tester också påverkas av GSM-nätets fördröjningar, vilket speciellt märks i det andra fallet. 4(62) DEL I: 1. Inledning 1.2 Bakgrund
1.3 Mål och syfte Syftet med detta projekt var att undersöka möjligheterna för automatiserade tester integrerade med vissa av AU-System Mobiles nuvarande testmetoder. Dessa metoder används för att testa systemkomponenterna i figur 1. 1.3.1 Problemformulering För mig, som student vid, var projektets övergripande mål att: Kartlägga de olika faktorer (strategiska, taktiska och operativa) som påverkar de framtida behoven inom SIM-kortskommunikation, samt belysa de olika trender för att ta fram övergripande systemkrav. Ta fram en rapport som behandlar viktiga aspekter för testning samt de grundläggande delarna för kommunikationen mellan ett SIM-kort och en server ansluten till olika klienter. Slutligen, med beaktande av ovannämnda kartläggning samt aktuella trender inom området, tillsammans med Johan André utveckla en prototyp (applikation) som möjliggör testning av SIMkortskommunikation utan att använda sig av GSM-nätet. Kartläggningen behandlar även aspekter rörande tester som utförs i dagsläget med målsättningen att ta fram de delar som är mest tidskonsumerande och enahanda och att eventuellt eliminera dem. 1.3.2 Avgränsningar Utöver den direkta kommunikationen med ett SIM-kort var det, enligt figur 4, endast de delar inom det skuggade området som skulle utredas; Short Message Service Centre, SMS-C, mobiltelefonen och delar av Transportservern. Denna begränsning gjordes initialt av AU-System Mobile som ansåg att en utredning av dessa delar skulle kunna leda till en förbättring i deras testprocedurer. Figur 4: Systemmiljön, där molnet innesluter de komponenter som skulle modelleras för att eventuellt kunna elimineras. Litteraturstudien valdes att endast inkludera kravhantering, autotester, GSM-systemet med fokus på SIMkort och Short Message Service (SMS) samt AU-System Mobiles egna system. Utöver detta fanns givetvis en tidsbegränsning på 20 veckor, inom vilken arbetet skulle slutföras med en skriftlig rapport. De avgränsningar som påverkat projektet mest har uppkommit vid framtagningen och implementationen av den nya applikation som utvecklats, se under avsnitt 5.2.4. 5(62) DEL I: 1. Inledning 1.3 Mål och syfte
1.4 Rapportdisposition Inledningsvis i Del I presenteras AU-System Mobile och bakgrunden till projektet. Därefter följer mål, syfte och avgränsningar. En litteraturstudie inom kravhantering med relaterade problem och vissa lösningar belyses i den första delen av Del II. Den andra halvan av Del II behandlar autotester, hur man bör gå tillväga och tar upp ett flertal olika aspekter kring utvecklandet av autotester. I Del III presenteras en nulägesanalys av telekom, mobiltelefoni och hela SMS-överföringskedjan presenteras där innehållet koncentrerats till de delar som är närmast i testprocessen. Utredningen avslutas med en beskrivning av AU-System Mobiles system och sammanställningen av ett öppet samtal om framtiden med marknadschefen för AU-System Mobile. Del IV, behandlar genomförandet av projektet och inleds med en metodförklaring och mätningar på dagens tester. Sedan följer en beskrivning av hur testerna kan effektiviseras via en applikation. Därefter presenteras tillvägagångssättet med kravidentifiering och arkitekturen hos applikationen. I avsnitt 6 illustreras hur applikationen implementerades och designades samt vilka problem som där uppstod. Avslutningsvis kommer resultatet där prestanda av autotestet diskuteras tillsammans med slutsatserna av införandet av en applikation i testprocessen på AU-System Mobile. 6(62) DEL I: 1. Inledning 1.4 Rapportdisposition
Del II Teorier Följande del behandlar de teoretiska aspekterna av kravhantering och automatisering av tester. 2 Kravhantering 2.1 Inledning Kravhantering inriktar sig på vad (och vilka krav som finns på det) som skall designas snarare än hur det designas samt framtagningen av framtidens möjligheter för systemet som skall utvecklas. 2.2 Ett systems användarcykel Enligt Linda Macaulay[21] kan ett systems användarcykel se ut som figur 5. Först identifieras behovet av ett nytt system (eller produkt), därefter införskaffas systemet, installeras och användare tränas för att bruka systemet. Detta resulterar i en viss förändring i företagets arbetssätt och vissa fall blir det även omstruktureringar inom företaget då nya komplexa och omfattande produkter oftast medför nya Figur 5: Ett godtyckligt systems användarcykel [21]. arbetsmetoder. Förändringarna inom ett företag som sker vid integreringen av en ny produkt i det dagliga arbetslivet kan t.ex. vara en ny utvecklingsmetodik eller ett arbetssätt som tillåter att fler medarbetare arbetar i de egna lokalerna. Sedan, när allt gått bra, blir systemet helt integrerat och kan användas fullt ut och runt denna tidpunkt har hela företaget anpassat sig till det nya metoderna. Till slut inträffar den tidpunkt då systemets gränser är 7(62) DEL II: 2. Kravhantering
nådda. Det kan vara påverkan från omvärlden, t.ex. nya standarder, statliga lagar etc., eller intern påverkan (större inköp av utrustning till andra avdelningar) som får systemet att nå sin gräns. Då utvärderar företaget ånyo sin situation och beslutar sig för att det finns nya behov som inte är uppfyllda inom företaget och på såsätt är användarcykeln sluten. De behov som ej är uppfyllda kan tas om hand på olika sätt, man behöver inte alltid köpa ett nytt system - det kan ofta räcka med en uppgradering - eller att införa en ny arbetsmetod - eller effektivisera användandet av resurser och personal. Således är kravhantering en lika viktig del för kunder (användarna), då den ger insikt i vad och vilka nya behov som finns (och i viss mån vad som kommer) samt att identifiera hur man kan uppfylla dessa krav. 2.3 Krav Ett krav kan ses ha två grundperspektiv; någonting som en kund behöver och någonting som en utvecklare ser behöver utvecklas - dessa olika sidor betyder sällan samma sak, anser jag. Detta stödjer även Eason[21] då han anser att perspektivet som en intressent har på ett krav är belagd med en barriär gentemot perspektivet en annan intressent har. Enligt IEEE[30] 610 (1990) är ett krav (fritt översatt): 1. Ett tillstånd eller operation som en användare behöver för att lösa ett problem eller nå ett uppsatt mål. 2. Ett tillstånd eller möjlighet som ett system, eller systemkomponent, måste kunna nå eller klara av för att satisfiera ett kontrakt, en standard, en specifikation eller annat formellt uppställt dokument. 3. En dokumenterad representation av villkor enligt 1 och 2. 2.3.1 Aktiviteter under kravhanteringsfasen I sin bok om mjukvarukrav från 1993 beskriver Davis[21] två olika aktivitetstyper som uppkommer under kravhanteringsfasen i ett projekt. Den första är problemanalysen, där analytiker brainstormar, intervjuar de människor med störst kunskap om problematiken och identifierar alla möjliga begränsningar i problemets lösningar. Denna aktivitet karakteriseras enligt Macaulay av osäkerhet samtidigt som det sker en ökning av information och kunskap. Den andra aktiviteten är produktbeskrivningen, när det är dags att sammanställa en del svåra beslut samt att på papper beskriva produktens förväntade uppförande och beteende. Denna aktivitet karakteriseras av strukturering av idéer, lösning av olika synsätt och eliminering av konflikter och tvetydigheter. Vidare anser Davis att dessa aktiviteter ej nödvändigtvis behöver vara gemensamt uteslutande eller sekventiella, samt att de olika tekniker som används inom aktiviteterna också kommer att ha skilda karaktärer. I figur 6 introduceras en generell modell av processen för kravinhämtning. Grundidén (Koncept) är den initiala faktorn som startar hela kravhanteringsprocessen och kan till exempel vara en serviceförbättring, ett framtida behov, en mindre systemförbättring (av ett redan existerande system) eller ett behov av att använda en ny tillgänglig teknik. Problemanalysen inriktar sig på att utveckla en förståelse för de olika problem associerade med grundtanken och konceptet. När sedan detta är klart och man erhållit full förståelse för problematiken tas ett antal olika lösningar fram för ytterligare utvärdering i en förstudiefas. Förstudien rekommenderar en lösning som mer i detalj analyseras och modelleras. Varje aktivitet bör avslutas med en kontroll av vad som sammanställts i informationsväg samt vilken ytterligare kunskap som tillkommit. Till slut kan således ett kravdokument, den så kallade kravspecifikationen, sättas samman. En av Macaulays, [21], slutsatser är att kravinsamling är en process mycket hårt knuten till relationen mellan kund och leverantör, vilket inte borde förvåna någon. Eftersom varje skapande av en ny entitet (det kan vara precis vad som helst) inleds med ett behov hos ena sidan som den andra skall uppfylla - och den enkla lösningen är att ha en relation mellan leverantör och kund (tillverkare - köpare) för att kunna utröna vad som kan tillfredställa behovet. Dessutom är processen kring skapandet av en ny produkt inte av konstant eller generell karaktär, utan i de flesta fall beroende på vilken situation som föreligger. Det modellen i figur 6 belyser de stora delar som kravinhämtningen består av och får då anses vara av en generell karaktär. 8(62) DEL II: 2. Kravhantering 2.3 Krav
Figur 6: En process för kravhantering [21]. 2.4 Utmaningar i kravprocessen Bubenko[22] lägger i sin Challenges in Requirements Engineering, 1995, fram en del intressanta aspekter kring svårigheterna med kravhantering. Bland annat diskuteras de grundläggande problemen vid kravhantering relaterade till företagsledningar, organisationer, användare, övriga intressenter, metodik, verktyg och utbildning. Bubenko ser kravhantering som det tvärkunskapsområdet av kommunikationen mellan organisationella aktörer och deras visioner, intentioner och aktiviteter vad gäller deras behov av support samt att utveckla och vidmakthålla en adekvat kravspecifikation för ett informationssystem. 2.4.1 Specifikationsarbetet En kravspecifikation spelar många olika roller vid utveckling och upphandling av ett system. Dels är det ett kontrakt mellan olika intressenter, samtidigt som det är en arkitektur som är en implementationsoberoende bild av det framtida systemet. När sedan systemet är implementerat bör kravspecifikationen brukas som ett kontrollprotokoll för att jämföra det färdiga systemet med det som beställdes. I det ideala fallet skulle en kravspecifikation innehålla delar som beskriver vilka basantaganden som är gjorda, bakomliggande behov, vilken kunskap det finns inom den aktuella problemdomänen - allt detta för att understryka och stödja designen och implementationen av ett informationssystem. En ideal specifikation bör kunna besvara frågor och behandla ämnen som: Varför behövs systemet? Vilka är (de bakomliggande) målen för omgivningen/applikationen? Vilka prioriteringar finns (finns det delar som är viktigare än andra)? Vilka är företagets verksamhetsområden (mål, affärsregler, aktiviteter)? Hur och av vem genomförs de olika delarna? Vilka är de funktionella respektive icke- systemkraven? Utöver den beskrivande delen behövs även metoder i de inledande faserna för att på ett konstruktivt, samarbetsmässigt och effektivt sätt få med användarna. 9(62) DEL II: 2. Kravhantering 2.4 Utmaningar i kravprocessen
Vidga begreppen Den ständigt ökande vikten av informationssystem, för att kunna klara av att vara verksam i ett affärsområde, pekar på att förståelsen, för dels själva affärsområdet samt att detektera nya behov och krav, måste ökas. Ett väl fungerande system kan vara en (konkurrensmässig) tillgång medan ett system som ej är anpassat till affärsområdet kan utgöra ett hinder. Det som jag ser som här är att det är en skiftning i hur krav skall beaktas; från det mer tekniskt orienterade aspekterna mot ramverk som modellerar företaget (affärsområdet och affärsmetoder, affärsmål och affärsregler) samt de tekniska aspekterna. 2.4.2 Problematiken Företagsledningen är oftast inte medveten om den strategiska rollen som kravidentifieringsarbetet spelar och därför får detta arbete inte de resurser och det kapital som behövs. Vidare är ledningens involvering och åtagande i kravhanteringen generellt sett låg och detta implicerar att arbetet med kravhantering normalt inte förknippas med affärsvisioner, affärsmål, förändringar i affärsprocesser eller andra organisatoriska förändringar. Allmänt gäller att organisationer inte tycks lära sig från tidigare erfarenheter av kravhantering[21] - speciellt brukar inte kravspecifikationer användas som kunskapskällor för framtida kravhanteringsprojekt. Organisationer anser sig oftast ligga på en ganska hög mognadsnivå inom informationssystem och kravhantering. Därför anses det oftast inte vara nödvändigt att vidareutveckla metoder och öka kunskapen inom kravhantering hos användare och övriga intressenter vilket medför problem i kommunikationen mellan inblandade parter (utvecklare och användare) och en låg validitet hos kravspecifikationerna. Användarna, å sin sida, antar även de att systemutvecklare kan sin kravhantering och godkänner gladeligen krav utan att till fullo förstå dess innebörd. Detta är grunden till att användare och systemutvecklare är aktiva deltagare i kravidentifieringsprocessen - trots att de inte har full förståelse för vad den andra parten egentligen menar och ej heller har tillräcklig kunskap om hur denna förståelse gemensamt kan (och skall/bör) höjas. Verktyg och metoder Det finns idag ett stort antal kommersiella systemutvecklingsmetoder och CASE-verktyg 4, de flesta är dock inriktade mot de sista faserna i ett systems livscykel. De saknar en strukturerad hantering av de initiala stegen i analysen av affärsmål och kravgenereringsstegen samt att kunna gå mellan en svag informationsdomän till en formell sådan. Macaulay anser att dagens tillgängliga metoder är inte lämpliga att explicit ta hand om en strukturerad insamling och representation av organisatorisk och affärsrelaterad kunskap. De metoder som finns, kommersiella och teoretiska, innebär ett hinder för utvecklarna, anser Macaulay, då de ej helt kan analysera kvalitén på en kravspecifikation. T.ex. är det inte sant att en kravspecifikation alltid i alla situationer måste vara 100% komplett, otvetydig etc. Det finns en mängd olika faktorer och situationer som påverkar och styr den nivån av detaljer och fullständighet som en specifikation har. De ändringar som görs i designstegen dokumenteras sällan i den ursprungliga kravspecifikationen. De CASE-verktyg som idag finns tillgängliga är inte anpassade till kravhantering, då deär ämnade för mjukvaruutveckling och möjligheten att kunna spåra beslut inte stöds. Vidare så finns det heller inga verktyg som klarar av att hantera alla de olika dokumenttyper som ett kravarbete genererar, såsom rapporter, memos, e-post, video etc. Dock så tror jag att ett effektivt e-postprogram klarar av stora delar av det dokumentverktyg som Macaulay saknar. Dagens e-postprogram är utformade för att just visa och hantera en stort antal olika dokumenttyper och filformat. Grundläggande frågeställningar Ett av de mest grundläggande problemen är att det finns för få praktiska undersökningar av kravhantering. Detta innebär att det uppkommer att antal frågeställningar relaterade till hur och varför ett visst verktyg 4 Ericssons PROPS, Rationals ROP [28] 10(62) DEL II: 2. Kravhantering 2.4 Utmaningar i kravprocessen
används; Vad finns? Vilka relevanta problemerfarenheter finns? Varför används metod A framför metod B? Blir det färre fel med vissa analyser än med andra? och i så fall varför? Den akademiska utbildningen i mjukvaruutveckling och kravhantering är enligt min uppfattning inte inriktade på praktiskt arbete och därför finns det ett behov av att se över dessa utbildningar med fokus på att ta fram ingenjörer och inte programmerare. 2.5 Fel i kravhanteringsprocessen Enligt Lyytinen och Hirchheim (1987)[21] kan ett misslyckande av ett (informations)system delas in i fyra klasser. Dock så anser Macaulay att endast tre av dessa är intressanta: 1. Processfel, relaterat till den utvecklingsprocess, där budget, tid eller någon annan typ av resursallokation har passerat gränsen där förväntningarna på det föreslagna systemet negligerats eller där de allokerade resurserna resulterar i ett oanvändbart system. 2. Samspelsfel/Interaktionsfel, argumentationen att en lägre utnyttjandegrad av systemet än förväntats kan tolkas som ett misslyckande 3. Felaktiga förväntningar, systemet möter ej de förväntningarna som ställts upp av de involverade grupperna (intressenterna). Tabell 1 illustrerar exempel på orsaker som genererar de olika felen. Värt att notera är att kommunikationen mellan inblandade parter slår hårdast och ger mest konsekvenser när det inträffar. Typ av fel Process Interaktion Förväntan Brist på processystematik Dålig kommunikation mellan människor Bristande kunskap eller gemensam förståelse Otillfredsställande dokumentation Dålig resurserhantering Tabell 1: Fel och dess orsaker som kan uppstå i en kravprocess 2.6 Dokumentering Enligt IEEE 830-1984, IEEE Guide to Software Requirements Specifications [21, 30], kan en innehållsförteckning över ett kravdokument ha följande struktur: 1 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2 General Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and Dependencies 3 Specific Requirements 3.1 Functional Requirements 3.1.1 Functional Requirement 1 3.1.1.1 Introduction 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.2 Functional Requirement 2... 3.1.n Functional Requirement n 3.2 External Interface Requirements 3.2.1 User Interfaces 3.2.2 Hardware Interfaces 3.2.3 Software Interfaces 3.2.4 Communication Interfaces 3.3 Performance Requirements 3.4 Design Constraints 3.4.1 Standard Compliance 3.4.2 Harware Limitations... 3.5 Attributes 3.5.1 Security 3.5.2 Maintainability 3.6 Other Requirements 3.6.1 Database 3.6.2 Operations 3.6.3 Site Adaptation... Appendices Index Tabell 2: Innehållsförteckning för ett allmänt kravdokument [21]. 11(62) DEL II: 2. Kravhantering 2.5 Fel i kravhanteringsprocessen
2.6.1 Helheten formulerad Denna uppbyggnad, enligt tabell 2, möjliggör ett enkelt sätt att få med de delar och aspekter som ett välskrivet kravdokument bör innehålla, utöver de olika och styrande satskriterierna (figur 7): Figur 7: Betydelsen för ett formulerat krav a) Entydigt/Korrekt: Krav skrivs oftast i vanliga språk där satser kan ha olika betydelser. Där det är tillämpbart bör man använda formella språk som kan detektera lexikala, semantiska och syntaktiska oegentligheter. b) Komplett: Ett kravdokument är komplett om det innehåller samtliga signifikanta krav (funktionella, prestanda, designbegränsningar etc.). c) Testbar och Verifierbar: Ett krav skall vara av sådan art att det är möjligt att verifiera kravet, d.v.s. kravet skall vara mätbart. d) Konsistent: Ett krav skall endast ha ett namn och beskrivas med samma termer (vid alla refereringar till det). e) Spårbart: Härkomsten av krav bör alltid klart framgå för att på så sätt möjliggöra spårbarhet bakåt för att se vilket eventuellt beslut som föreligger, samt spårbarhet framåt för att möjliggöra en översikt av de dokument som härrör från ett visst kravdokument. Man bör även ta med motivet bakom ett krav för att ytterligare belysa vilka faktorer som ligger till grund för kravet (m.a.o. ett sätt att öka att förståelsen av kravets ursprungliga betydelse). Detta kan vara till hjälp när utvecklingen av ett system och dess miljö genomgår förändringar 5. Återkoppling till de efterkommande faserna Utöver att kraven skall vara väl beskrivna bör ett kravdokument vara modifierbart, d.v.s. skriven på ett enhetligt sätt, t.ex. enligt IEEE-guiden i tabell 2. En enhetlig struktur förenklar både framtida modifieringar och läsbarheten vilket gör dokumentet mer användbart (m.a.o. så att det även kan vara till användning i drift och underhållsfaserna). 5 Intressant aspekt som min handledare vid, Erik Johansson, påpekade 12(62) DEL II: 2. Kravhantering 2.6 Dokumentering
Macaulay understryker även att det skall vara en distinkt skillnad mellan utvecklingsmodellen och den modell som beskriver mjukvaruimplementationen. Utvecklingsmodellen bör, enligt Verheijen och Van Bekkum, 1982[21], också innehålla följande delar: 1. En hög abstraktionsnivå, från användarnas perspektiv, och den bör innefatta och integrera användarnas koncept på ett tidigt stadium. 2. Mänsklig läsbarhet. Det använda språket bör vara av enkel natur, vilket i sin tur innebär problem vid användningen av kravdokument skrivna med ett formellt språk. Det viktiga är att det inte finns svårigheter att förstå den beskrivna modellen. 3. Precision, ett högnivåspråk bör användas för att definiera tillämpningsområde, systemgränser, namngivning av objekt, regler, processer mm. 4. Specifikationens helhet. Den använda modellen skall på ett klart och tydligt innefatta alla aspekter. 5. Överföring till efterföljande faser, detta med anledning att de faser som följer kravdefinitionsfasen skall kunna få en konstruktiv input, så måste modellen ha en sådan struktur att det lämpar sig att överföra den information som behövs till de efterkommande faserna. Läsbarhet ställt emot formalism I de två senaste uppräkningarna, 2 respektive a), introduceras en tvetydighet. I det ena fallet menar man på att formella språk som kan detektera lexikala, semantiska och syntaktiska oegentligheter bör användas för att beskriva krav. I det andra fallet föredras att språket bör vara av enkel natur för att öka förståelsen. Vad som är bäst avgör situationen; om det är en intern förstudie tror jag att språket är mer åt det läsbara, dåläsaren kan fråga författaren, som en kollega, vad en formulering syftar till. Men om det är en offert anser jag att det lönar sig att använda ett mer strikt och formellt språk. En allmänt bra metod är att definiera terminologin (ord, formuleringar, förkortningar, namnkonventioner etc.) som en del i kravdokumenten. 2.6.2 Kravhanteringen i utvecklingsprocessen Utöver ett välformulerat kravdokument behöver processen för kravhanteringen fogas samman med utvecklingsprocessen. Hur detta görs på bästa sätt finns det nog ingen som vet - det är därför det finns så många olika utvecklingsmetoder och tillhörande verktyg 6. Det som kravprocessen tillför utvecklingsprocessen är: 1. en överenskommelse - vad som gäller för de inblandade intressenterna 2. en beskrivning av kraven för utvecklarna - de får en (helhets)bild av vad som skall utvecklas 3. begränsningarna - inom vilka gränser som kraven gäller och håller, samt 4. en informationsbas - bakgrund (motiven), vilka faktorer som är intressanta. Min uppfattning är att resultaten ifrån processen av kravhantering, krav och kravdokument, måste förmedlas vidare till de följande utvecklingsfaserna. Jag tror att detta leder till en bättre hantering och krav - kraven kan på så sätt bli lättare att uppfylla och genomföra om de iblandade personerna har tillgång till kravdokumenten. Detta förutsätter visserligen att de inblandade personerna aktivt tar del av materialet. 6 Bakom referensen Tero Ahtee[28] döljer sig mer än 60 olika CASE-tools och utvecklingsmodeller 13(62) DEL II: 2. Kravhantering 2.6 Dokumentering
3 Automatiserad testning Dagens mjukvarusystem är oftast utrustade med grafiska användargränssnitt (Graphical User Interfaces). Med alla olika möjligheter som finns att interagera med användarna och det stora antalet kontrollelement (knappar, rullgardinmenyer, toolbars) som användargränssnitten har, blir testningen av dessa extremt tidskrävande och kostsamma. Att utföra dessa tester manuellt är arbetsamt, monotont och ouppskattat av de flesta utvecklare och testare. Det finns dock möjligheter att automatisera dessa tester med kommersiella mjukvarubaserade verktyg. 3.1 In- och uppspelningsverktyg In- och uppspelningsverktyg, Capture-and-Replay tools (CR-verktyg), är oftast objektorienterade och uppfattar alla delar i ett grafiskt användargränssnitt som objekt och registrerar de olika delarnas innehåll (namn, färg, värde) och inte bara dess X/Y-koordinater vid ett musklick. Vid en inspelning spelas all manuell användarinteraktion på testobjektet in och stegen sparas i ett skriptspråk med liknande syntax och semantik som C eller Basic. Ett inspelat skript kan sedan spelas upp hur många gånger som helst. Om testobjektet under en uppspelning uppträder annorlunda än det gjorde vid inspelningen registreras detta som ett fel av CR-verktyget. 3.1.1 Testning av användargränssnitt I ett system med ett grafiskt användargränssnitt är alla funktioner i gränssnittet representerade via interaktions punkter (IP) och dessa aktiveras genom att markera dom, t.ex. med musen. Att identifiera samtliga IP är inte något större problem för en människa även om, eller när, det sker förändringar i gränssnittet. Denna identifiering skall även CR-verktygen klara av, vilket av förklarliga skäl inte är det lättaste att implementera. CR-verktygen känner igen delarna i det grafiska gränssnittet via deras objektidentifierare och är därför känsliga för ändringar av värdet på dessa. Till detta tillkommer även att vissa mjukvaruutvecklingsmiljöer ibland ändrar identifierarna på grafiska gränssnittsobjekt, utan att underrätta utvecklaren (därför att utvecklaren inte skall behöva ha ansvar för tilldelningen av de individuella identifierarna). Så situationen vid användandet av CR-verktyg och förändringar i det grafiska användargränssnittet gör dessa testfall ganska problematiska. För att ge mjukvaruapplikationer ett enhetligt användarintryck, har utvecklare försökt ta fram layoutregler, Style Guides, där det exempelvis finns beskrivningar som: OK och Cancel är alltid placerade vid botten eller till höger och aldrig till vänster eller högst upp. Alla fält måste vara nåbara via tabbar i samma ordning 3.1.2 Regressionstest Ett regressionstest är ett test som programrelease N passerat och som release N + 1 testas med för att se hur N + 1 versionen uppträder. Regressionstestverktyg för grafiska användargränssnitt finns i två varianter: 1. Första generationens inspelningsverktyg. Dessa spelar in musrörelser eller tangentnedtryckningar och tar ögonblicksbilder av pixlarna på skärmen. Dessa verktyg genererar tester som inte går att underhålla, för när det sker en minsta ändring på skärmen 7 så slutar testet fungera. Skärmbildens utseende och layout ändras vanligtvis så pass ofta att supporten (de manuella uppdateringarna) för dessa tester blir testpersonalen övermäktig och därmed blir testerna oanvändbara och dyra. 2. Andra generationens verktyg liknar de första men har även möjligheter för att använda testskript. Dessa är användbara då man kan kapsla in skriptkod med ett eget utvecklat API (Application Programing Interface). Ett inspelat skript kan ha liknande innehåll som figur 8-a illustrerar, medans ett skript, med ett API, kan ha strukturen som i figur 8-b. 7 klockan, e-post indikation etc. är förödande vid inspelningen av ett test. 14(62) DEL II: 3. Automatiserad testning