Software that connects

Software that connects Principper og praktiske forhold omkring automatisk test Præsentation på AAU den 6/5-04 for 4. og 10. semesters studerende

Tester af oplægget Der tænkes i test baner. Og oplægget giver ikke svaret på alt. Spørgsmål tages løbende eller tilsidst. Diskussion tages løbende eller tilsidst. Forsøg at spore de forskellige ind til at under test. Filosofi som ting tages under. Praktisk erfaring fra diverse projekter.

Oversigt Kort om GateHouse Automatiseret test generelt Test arkitektur og plan Automatiseret system test under TestQuest Automatiseret unit test under CPP-unit Automatiseret component test under ITS Niels Andersen, Project Manager, Ålborg www.gatehouse.dk Kort gennemgang af GateHouse, så I får en fornemmelse for hvem vi er Lidt kedelige, generelle betragtninger omkring automatisering af test Lidt sjovere, specifikke erfaringer med et par værktøjer Kommentarer er velkomne, under hele forløbet Vores forhold til test har været igennem et forløb, der sikkert er flere, der kan nikke genkendende til: -Noget man skulle undgå for enhver pris -Et nødvendigt onde, der helst skulle udføres af andre -En hjælp til at undgå evig fejlretning -En disciplin, der er essentiel for firmaets kundeforhold

GateHouse Offices in Aalborg and Copenhagen 50 employees, 39 software-engineers Business areas Satellite Communications BGAN MPDS, UMTS, Consultancy in general Radio Communications Radio Systems, Costal GMDSS systems, Costal AIS systems, Consultancy Contract Engineering Total Project Management, Software Development & Integration, Supplier of Manpower & Services, ITS (Interface Test System) References Sagem, Digianswer (Motorola), Siemens, Nokia, ECI, ChemoMetec, ECI, Inmarsat, Hughes Network Systems, DSpace, SP-Radio, Danphone, McMurdo, etc. Kraftig vækst i de sidste 5 år. Test anvendes inden for alle vores områder. Som konsulentydelse hører test inde under Contract Engineering altså konsulentafdelingen.

Automatiseret test, hvorfor?? Udviklingstid Hurtig og sikker release Iterativ udviking, delleveringer og varianter Test-status Det er sjovt Nogle typiske grunde til at man går igang med automatiseret test Spare udviklingstid Det er svært at have objektive mål for det, men vores erfaring er, at for systemtest tager det 5-10 gange længere tid at automatisere en test end at køre den een gang manuelt (tallet er noget lavere for unittest). Dvs. at den skal køres 5-10 gange før den har betalt sig hjem. Det er et stort tal og man kan med rette påstå, at man aldrig kommer til at køre en test 5-10 gange. Vores postulat er, at det mere skyldes at man ikke har tid/lyst til at køre den, end at den ikke skal køres. Investeringen i automatisk test betyder altså bl. a. at testen udføres når den skal, ikke når der er tid til det. Der kommer vi så videre til øget kvalitet Hurtig og sikker release muligt Fuld test af delleveringer og varianter muligt, understøtter iterativ udvikling Nemmere og mere sikker test-status Kan også rimeligt nemt automatiseres, når selve testen er automatiseret. Det er sjovere Vi er ingeniører. Det er sjovt at sætte et system sammen og trykke start. Men heri ligger også faren for at man opfinder sit eget system, i stedet for at genbruge.

Automatiseret test, fordele? + Sikkerhed og kvalitet Reproducerbar Regressionstest, smoketest Test som aktivitet/disciplin Gør systemet testbart Afdækker dårlige specs Nogle fordele man oplever når man har automatiseret testen Øget sikkerhed og Kvalitet -Alle kender vel til at man har tvivlsomme testresultater, som ryger igennem som godkendt eller tests man er sikker på kører og derfor springer henover. Det sker ikke med automatiseret test. -Det er nemt at køre => det bliver kørt -Det bliver muligt, at køre tests med store datamængder, stor load, boundary scan etc. Mere reproducerbar Det er altid rart at kunne reproducere fejl. Det er meget nemmere ved automatisk test Regressionstest, smoketest Det er nemt / muligt at gennemføre hel eller delvis test ved releastests. (Regressionstest = re-test af at resten virker ved mindre ændringer, smoketest = tage temperaturen på softwaren) Fokus på test som aktivitet/disciplin Det bliver i praksis muligt, at opbygge testen parallelt med system udviklingen. Man kan f. eks. spore progress. Testbarhed Jo tidligere ikke-testbar implementation bliver identificeret jo nemmere er det at få det ændret. Dårlige specs Nogle specs bliver først tænkt igennem under udarbejdelsen af deres test. Spørgsmål: Hvordan overbeviser jeg min chef om at automatiseret test er et plus? Svar: Synliggør cost, både udviklingstid og kundeklager. Når han ser omfanget vil han nok høre på dig. Er der nogen erfaringstal?

Automatiseret test, ulemper? Manglende synlighed Fastlåst specification Spild af tid Dyrt Kvalitetsforøgelsen, test er traditionelt ikke synlig Ledelsen kan ikke se testen. Derfor er det vigtigt at huske rapporteringen, selvom den måske ikke er ønsket. Vigtigt at have metrikker iorden før automatisrede tests introduceres. Specifikationen på den testede enhed bliver hurtigt låst Allerede testet software er svært at ændre fordi det virker. Pointen er, at timingen er rigtig. Det nytter ikke noget at automatisere før specs er nogenlunde klar. Og det er for sent at teste når softwaren er afleveret. Noget test er spild af tid Nogle specs vil blive ændret og nogen tests dermed overflødiggjort Det er dyrt = en investering Det er altid svært at investere uden atkende resultatet.

Test arkitektur, Test plan! Afhængig af projekt, applikation og firma Planlæg testen som en del af projektet Automatisk contra manuel Hvad skal testes, modul for modul? Valg af grænseflader til hhv. unit og integrations test Beslutning om testdybde Planlæg testen Det mislykkes helt sikkert, hvis testen ikke integreres i projektet (men den kan godt køres af en selvstændig gruppe, blot kommunikationen er i orden) Hvad skal automatiseres og hvad skal test manuelt Der er dele der ikke kan betale sig eller hvor det ikke kan lade sig gøre at automatisere og noget der ikke kan betale sig at køre manuelt. Beskriv (måske kun i stikord) hvad der skal testes for alle kendte moduler Når modulerne er kendt, kendes deres funktion og testen kan beskrives Grænseflader: Hold styr på hvad der testes hvor Det er vigtigt med trace af krav og tests. Men det er også vigtigt at undgå at teste det samme på alle niveauer, eller i givet fald genbruge testen. Testdybde Næste slide

Test detajl planlægning Fastlægges for hver komponent ud fra Use Cases prioritet Identifikation af kritiske moduler Code Coverage (Statement, Branch, Condition,...) MMI Input coverage Boundary check Interrupted activity Error conditions Teststrategi F. eks. beslutning om modul test på alle moduler eller sporbarhed på alle krav Ud fra Use Cases, evt. opdelt per state Til moduler, opdel i kritiske (spil/ 112 ), normale, biblioteker, specielle applikationer Coverage: Line, Branch, Condition med mange flere MMI Input coverage (simultaneous keys) Input events coverage (main/secondary) Boundary check Interrupted use cases Errors in use cases

Test implementering TQ Library + bt_locatestringof(color :, position :, font :) : boolean Customer std. library + cust_readtext(color :, position :) : boolean Design skal tages alvorligt Analyse og design Biblioteker, fælles funktioner, keyhandlere osv. Device 'A' library + dev_readheadline() : boolean Application library + app_getappitem() : boolean Application test scripts + app_opennewitem() : boolean boolean app_opennewitem() {...... app_getappitem(string); if( strcmp(string, "Item #1 )!= 0 ) { bt_printtolog(...); return 0; // Stop test case }...... } Dette viser en arkitektur anvendt ved automatisering af system test vha. TestQuest værktøjet. Den viser at det design, der anvendes i implementering af applikations softwaren, reflekteres i test designet. Som det gælder for applikations udviklingen gælder det også for test udviklingen: De mest generelle 2-3 lag kan genbruges. TQ leverer f. eks. det de kalder Test Verbs til mobiltelefoner. Autimatiseret test skal støtte den iterative udvikling. Udviklingen kan med fordel foregå iterativt, parallelt med applikationsudviklingen

Test værktøjer TestQuest ITS CPP Unit CPPUNIT: Frame work til unit test. Gratis. ITS: GateHouses eget tool, til test af grænseflader. TestQuest: Autimatiseret Systemtets på brugerniveau

TestQuest og system test Testquest giver mulighed for at lave system test 3 items involved: 1) Standard PC. Used for test script execution. 2) What TQ calls their TQ HW Integration Platform. This is a box delivered by TQ and interfaces the MMI of the device (keys and displays - sound, leds etc) to TQ workstation. 3) The device under test.

TQ Håndtag Påvirkning af taster. Verificering: Bitmaps Capture af display (Tegneprogram) Genkendelse af tekst (Font editor, sprog db) Audio Lysdioder Optimal brug kræver erfaring. - TQ kan påvirke diverse taster, som er koblet til TQ HW Integration Platform (HIP) - TQ kan: - verificere bitmaps - søge efter bitmaps, evt. med brug af masker - Afgrænsede områder - læse tekst (forudsat at fonten er kendt) - ovennævnte faciliteter kræver nogen erfaring for at få et optimalt resultat

TQ Strukturering Minder om strukturering set i andre test sammenhæng Test Suite køres fra test manager Test Case Scripts, debugger Test Step Intern værdi Opbygning af test hieraki. Muligt at køre i en samlet batch Test Manager, kan vælge specifikt hvilke TC der skal køres, muligt at køre initialisering og oprydning. Test Cases skal helst køre uafhængigt. Test step er med for ens egen skyld, så man kan se mere detaljeret, hvor test fejlede.

TQ implementation Optag/afspil test scripts... Ikke anvendelig i større projekter. Script sprog. Mere fleksibelt og genbrug. Fortolket C, Libraries, DLL support. Brug arkitektur: TQ lib nederst, dernæst common og applikation lib. Øverst er test scripts placeret. Record test script mangler fleksibilitet, forudsætter at system under test kører. Common: Liste box, message box, påvirke med dobbel tryk på taster. Applikationer: - Kalender - Telefon bog - Note bog Nu går jeg over til at snakke om et konkret projekt, til test af mobil telefon.

TQ erfaringer 1 Tag test seriøst. Det er et egentligt projekt. Udvikling af libs er dyrt, derefter opnås god progress. Så fokuser på stabilitet af disse. Stor erfaring krævet ved udvikling af libs, idet bitmaps, fonte, og opsætning kan anvendes på mange forskellige måder. Testplaner til manuelle og automatiserede test bør skelnes. Korte display events kan være problematiske. Test af om noget ser OK, skal specificeres. Vigtigt at anvende strukturering og design principper, da man ellers kommer til at debugge oceaner af kode. Poll af event kan være at vente på at elementer i et skærmbillede dukker op. Når libs er iorden, går det huttigt med at få generet test scripts. Test effort kan bruges bedre.

TQ erfaringer 2 Timing i displays varierer meget. Generelt bør anvendes poll af events. Behov for regression test skal være stort, da TQ er dyrt, og udviklingstid er endnu dyrere. Kørsels tid for tests tager lang tid, men er væsentlig hurtigere end manuelt. Ser rigtigt sejt ud, når det testen køres. Virker overbevisende på en kunde, når man bare kører hele testen igen. Garanteret at der sker nøjagtig det samme hver gang.

TQ yderligere info Hjemmeside: www.testquest.com. GateHouse: 6 mandeårs TQ erfaring. Hvis der er nogen der har behov for praktisk anvendelse, så har vi selv en del erfaring

Regressionstests i GateHouse Interne projekter og konsulent ydelser. Automatiserede test er i fokus. Alle projekter bruger unit og proces test. Mentalitets ændring: systemet er først implementeret, når det er aftestet. BGAN Protocol Stack (BPS). Vigtig når vil vil levere kvalitetes systemer endnu hurtigere Commitment skal gives fra ledelse. Mentalitets ændring: Skal slå igennem lige fra estimering til implementation. Kommende del tager udgangspunkt i et lidt større projekt, BPS projektet.

BGAN Protocol Stack Protocol stack til anvendelse i satellit terminal. 4-lag: UMTS, adaptation lag, connection lag og control lag. Samlet kode 228kloc, hvoraf 54% er automatiserede test og stubbe. Test tid: test/(implementation + test) = 44%. Integration på kunde projekter forløber godt. Fokus på integration aktiviteter, fremfor trivielle fejlkilder. Ændringer kan integreres uden risiko. Test tid, igen vigtig at holde sig for øje, når der estimeres. Kan være problem, at større sikkerhed i nuet koster. Nu går jeg over til at snakke om et konkret projekt, til test af mobil telefon.

Test niveauer System test: BGAN protocol tester og ITS Proces test: ITS Unittest: CppUnit System test er givet fra kunde. Process test laves af os selv. Tester mail udveksling i enkelte processer. Unittest: Typisk nedbrydning af komplekse algoritmer. Encode og dekode af protokol stumper

Planlægning Læg test indsats så tidligt som muligt. Herved findes flest fejl, som løses billigst muligt. Der findes færre fejl senere vha. test, hvorved noget at test effekten mistes. Lad udviklergruppen selv lave flest mulige test, og en testgruppe følge op på mangler. Test først, dernæst kodning. Lyder interessant, og er muligt. Begræns testgruppens arbejde, idet test gruppens arbejde kan være lidt træden i vande, da udviklergruppen ofte mener bedste implementation er opnået. Test først strategien, virker som om den har givet pote. Eksempelvis, når test gruppe og implementation er kørt som det skulle.

Dokumentation Bugs registreres i fejlregistreringssystem. Opstramning igennem projektetsfaser. Alfa, beta og final releases. Bugs eftervises vha. ITS eller CppUnit. Kode coverage, interface/linie, kan anvendes en smule. Requirement tracking er nødvendig. Projekt status mere retvisende. Projekt status efter test gruppens etablering tog et hop i de efterfølgende par måneder. Og det vil nogle måske se som negativt, men det positive ved det var at vi har mulighed for at korrigere.

At komme igang Verificer op imod specifikationer. Interface og value check. Fejlmuligheder og udvikler input. Line coverage. Hvis ingen test erfaring: Kom igang, lav test, og udvid efterhånden som fejl dukker op. Anvendelse af line coverage til opfølgning. Vigtigt at have noget test og udvide det løbende efterhånden som problemer dukker op.

Forløb Der oparbejdes løbende sikkerhed og stabilitet. Ændringer kan udføres, hvor eventuelle side effekter opdages med det samme. Ændringer kan medføre en del re-work af tests. Implementation kan bliver kønnere med UnitTest. Test skal laves simple, da folk ellers ikke gider sætte sig ind i dem. Kørselstid for test kan være lang. Men resultatet af projektet er mere forudsigeligt... Succes Husk mentalitets ændring, estimater glemmer re-work af tests. Meeen gevinst i sidste ende alligevel.

Metrikker Kode, antal linier, ændringer, kompleksitet. Opdelt i test og core kode. Granularitet på uge basis. Antal bugs, og deres tilstand (verified/closed). Antal todo i core kode. Som control af tingenes tilstand er som man forventer er det en god ide at have metrikker, som dokumentere hvad der sker.

UnitTest og ITS yderligere info Download og dokumentation af CppUnit: cppunit.sourceforge.net En del artikler om unit test: www.junit.org ITS: Eget produkt, se nærmere på www.gatehouse.dk. www.junit.org anvender java

CppUnit demo #include <cppunit/extensions/helpermacros.h> #include <unittest/include/bpssuite.h> class TclCounterTest : public CppUnit::TestFixture { public: void testcounterok() { CPPUNIT_ASSERT_EQUAL(0, 0); } void testcounterfailed() { CPPUNIT_ASSERT_EQUAL(0, -1); } CPPUNIT_TEST_SUITE( TclCounterTest ); CPPUNIT_TEST( testcounterok ); CPPUNIT_TEST( testcounterfailed ); CPPUNIT_TEST_SUITE_END(); }; CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TclCounterTest, BPSSuites::Os() ); Der kræver lidt yderligere at få det til at køre, test runner, osv.

CppUnit demo resultat Running unit test... TclCounterTest.testCounterOK.TclCounterTest.testCounterFailed.F c:\user\nan\t\unittest\tests\test\tcounter.cpp(34) : Assertion Test name: TclCounterTest.testCounterFailed - Expected : 0 - Actual : -1 Failures!!! Run: 2 Failure total: 1 Failures: 1 Errors: 0 Unit test finished in 0 seconds. Error executing c:\winnt\system32\cmd.exe. unittest.exe - 1 error(s), 0 warning(s) Efter fejlretning: Running unit test... TclCounterTest.testCounterOK.TclCounterTest.testCounterFailed. OK (2) Unit test finished in 0 seconds. unittest.exe - 0 error(s), 0 warning(s) Fin detalje med MSVC linie nummer, så man kan hoppe til fejl Bemærk at der klart og tydeligt meldes om fejl Og ved OK meldes der også klart og tydeligt om succes.

ITS og demo Konfigurerbart op imod mange systemer. Standard TTCN-3 kode. GUI interface til debug. Trace af messages. Message værdier. Pass/Fail. Kan hente test fra anden side. TTCN-3: Testing and Test Control Notation (version 3)

ITS screen shot #1

ITS screen shot #2

Erfaringer Automatiseret test kan ikke stå alene Exploratory testing Tracking skal planlægges Dokumentation skal planlægges Planlægges som en del af projektet Automatiseret test kan ikke stå alene Manuel test skal altid foretages løbende. Exploratory testing approach er en fordel Det er en form hvor problem områder undersøges vha manuel test og fejl giver anledning til nye TestCases. Tracking skal overvejes nøje. Hvordan trackes til krav? Der er mange, mere eller mindre heldige fremgangsmåder. Fælles er, at selv om det lykkes, kræver det meget arbejde. Requisite Pro Documentation skal overvejes nøje. For nuanceret dokumentation skal undgås i testspecs. Den nuancerede doc stepby-step står i test-koden. Skal tages som et egentligt udviklingsprojekt, med alt hvad der hører til. Vend tingene lidt på hovedet. Applikation tester TQ scripts.

Ingen mirakel kur Automatiserede test er en del af noget større. Krav styring Projekt ledelse Fremdriftsstyring Konfiguration styring Kvalitetssikring Osv. Husk også proces forbedringer. Bare lige for at sige, at automatiserede test ikke kan stå alene, og at det er et værktøj som fungerer i samarbejde med en lang række af andre discipliner

Spørgsmål og diskussion Yderlige spørgsmål? Diskussion: Hvad testes... Hvordan testes... Hvornår testes... Opfølgning på test...