MEconsult

Enhver produktudviklende virksomhed har behov for at etablere et system, som kan sikre at nye og opdaterede produkter bliver testet, inden de slippes løs på markedet.

Denne artikel søger at give et overblik over muligheder og problemstillinger ved at benytte Python til at skrive sådanne automatiserede tests. Artiklen giver også et overblik over anvendelige værktøjer, udover selve Python-sproget.

Motivation

Traditionelt har produkttest været en manuel opgave. Der er dog store begrænsninger ved denne fremgangsmåde når testene skal gentages ved nye releases og/eller opdateringer til eksisterende produkter. Der er simpelthen for store muligheder for menneskelige fejl ved manuelle tests, og det relativt store tidsforbrug der medgår til manuelle tests kan også ofte være årsag til at man mere eller mindre bevidst vælger ikke at udføre testene.

Det er derfor interessant at søge at automatisere disse tests i så høj grad som muligt, dels for at spare tid på længere sigt, dels for at sikre at testene overhovedet bliver udført. Når ændringer indføres i et eksisterende produkt er det også af meget stor værdi at have en automatiseret regressionstest, så man hurtigt kan sikre sig at den nye funktionalitet ikke har ødelagt eller ændret eksisterende funktioner. Man skal dog gøre sig klart, at det at opbygge en automatiseret testsuite fra grunden er rimeligt tidskrævende. Man får således ikke en tidsmæssig gevinst første gang testen køres, men må betragte det som en investering i fremtiden.

Hvad kan man teste

Man kan i princippet teste ethvert embedded computing produkt, hvor man har mulighed for både at påtrykke stimuli og opsamle status for påvirkningen med en anden computerplatform. Dette kan derfor kræve at man har bygget nødvendig I/O funktionalitet ind i apparatet fra starten. Betjenes apparatet f.eks. via en terminal eller en touchscreen, skal man således kunne føde simulerede taste- eller skærm-tryk ind i systemet via en debugport eller lignende.

Strukturering af tests

Typisk vil man strukturere sine tests i et antal testsuiter, som  hver især retter sig mod en specifik produktrelease. Hver testsuite kan indeholde en antal testgrupper,som hver især omhandler en bestemt funktionalitet i produktet. Hver testgruppe kan underopdeles i flere grupper afhængigt af produktets kompleksitet, men slutteligt består hver testgruppe af et antal testcases.

En testcase er den mindste enhed i en testsuite, og kan med fordel opbygges som en unit test. Python indeholder et unittest framework, som er en implementation af JUnit, af Kent Beck og Erich Gamma. JUnit er en de facto standard unit testing framework for Java sproget. Bemærk at i unittest terminologi findes begrebet "testgruppe" ikke. Man kan i stedet for operere med nestede testsuiter, dvs. at en testsuite kan indeholde andre testsuiter.

Logning af testresultater

Resultatet af testkørslen bør skrives til en logfil, som dermed er dokumentationen for at testen er kørt, og hvad resultatet var af kørselen. Log-filen bør indeholde følgende information:

• Dato og tid for kørslen, samt initialer for den test-ansvarlige.
• Type og versionsinformation for det testede udstyr.
• Øvrig information omkring testopstillingen.
• Hvor mange testcases der passerede uden fejl og hvor mange der fejlede.
• Detaljer omkring evt. fejlmeddelelser.

Logfilerne bør gemmes et sikkert sted, gerne under versionskontrol, og kan også med fordel publiceres på firmaets intranet.

Testdokumentation

Traditionelt vil man dokumentere et testforløb i en eller flere testspecifikationer, som typisk skrives i en normal tekstbehandler, såsom Microsoft Word. Med et Python-baseret automatiseret testsystem er der imidlertid mulighed for at integrere testdokumentation og testkode, så sandsynligheden for diskrepans mellem dokumentation og test mindskes.

Python har en såkaldt docstring funktion, som tilbyder en nem måde at associere dokumentation med funktioner, moduler og klasser skrevet i Python. På denne måde kan dokumentationen for et testscenarie placeres direkte i koden, og udtrækkes automatisk til testloggen, når testen køres.

Styring af måleudstyr

I forbindelse med automatiserede tests kan det være interessant at kunne styre eksternt test- og måleudstyr, enten for at kunne påtrykke systemet nødvendige stimuli eller for at logge testresultater. Man kan til flere typer udstyr få libraries til f.eks. Windows, som tilbyder et API, som typisk kan benyttes fra C eller C++ programmer.

Python tilbyder en extension metode, hvorpå man kan tilgå sådanne C/C++ libraries fra Python kode. Dette kan kodes manuelt, men man kan også benytte værktøjet SWIG (Simplified Wrapper and Interface Generator), som tilbyder automatisk at generere interfaces tll C/C++ libraries, som så kan anvendes fra høj-niveau sprog som Python. Dette giver mulighed for at styre sine instrumenter direkte fra Python testscripts.

Kodegenerering

Nogen gange er man ude for at skulle skrive den samme testkode igen og igen, typisk ud fra en skabelon eller en formaliseret  interfacebeskrivelse. Det kan derfor være interessant at generere denne kode automatisk. Der findes flere frameworks som tilbyder automatisk kodegenerering. Min personlige favorit er værktøjet Cheetah , som jeg har anvendt med stor success. Cheetah er primært rettet mod webudvikling, hvor man genererer HTML ud fra forskellige skabeloner, men det kan også sagtens generere f.eks. Python eller anden form for kode.

Brugerinterfaces

Ofte kan det være interessant at opbygge en lille brugergrænseflade til styring og/eller monitorering af testforløbet. Der findes jo et hav af forskellige værktøjer til GUI-udvikling, og hvis man allerede anvender sådan et, bør man nok fortsætte med det. Men ellers tilbyder Python-verdenen også et ganske godt alternativ her.

Python kommer med indbygget support for GUI-udvikling i form af modulet TKinter, som er et wrapper-lag der tilbyder Tcl/Tk GUI-funktioner til Python kode. Hvorvidt man kan lide GUIs bygget v.hj.a. Tcl/Tk eller ej er en smagssag. Personligt synes jeg at resultatet typisk ligner noget der er kastet sammen med en skovl. Hvis man hellere vil have et native Windows-look når koden kører på Windows og et native GNOME-look når koden kører på Linux, så bør man checke GUI-toolkittet wxPython , som er bygget ovenpå det C++-baserede wxWidgets toolkit.

Man kan bygge sine dialoger op manuelt med wxPython, men det er klart anbefalelsesværdigt at benytte en GUI-designer til større dialoger. Der findes et antal GUI designers til wxWidgets/wxPython på markedet, hvoraf et par er kommercielle produkter. Men er man på et skrabet budget, kan man benytte værktøjet wxGlade, som er gratis og har en ganske høj kvalitet.