Verifiering och validering av programvara med automatisk provning på gränssnitt. Håkan Edler

Transkript

1 Verifiering och validering av programvara med automatisk provning på gränssnitt Håkan Edler

2 FoTA P9 Experimentell verifiering av feldetektering och feltolerans En teknik för att automatiskt generera och exekvera provfall för beteendeprovning - blackbox testing En provbänk för provning av robusthet och feltolerans i programvarumoduler Ett projekt för tekniköverföring baserat på vår forskning på Chalmers om pålitlig programvara

3 Mål för vår forskning Metoder att analysera datorbaserade system ur pålitlighetssynvinkel Analytisk modellering för att verifiera pålitlighet och som underlag för felinjicering Utveckling av metoder att bygga feltolerant Utveckling av metoder att experimentellt verifiera pålitlighet

4 Vision Pålitliga datorsystem tack vare programvara

5 Att åstadkomma pålitlighet Pålitliga programvarusystem skall byggas så att Fel undvikes Kvarvarande fel skall tålas Fel i kompilatorer, länkare, laddare, systemprogramvara skall tolereras likaväl som temporära och permanenta maskinvarufel. Pålitliga programvarusystem skall provas så att Fel hittas och rättas Mängden kvarvarande fel skall kunna förutsägas

6 Varför prova? Varför prova program? Att verifiera att en konstruktion stämmer sin specifikation Att validera att ett systems funktioner stämmer med användarnas förväntningar Att finna fel Det senare är ineffektivt, fel skall ha hittas tidigare. Dijkstra 1972: program testing can be used to show the presence of bugs, but is hopelessly inadequate to show their absence

7 Om kvarvarande fel Hur ser fel ut i beprövad programvara? Kör program i automatprovning ett år med slumpvis valda indata ur en given användningsprofil. Sannolikheten för ett fel under en drifttimme är då av storleksordningen 10-4, om provets användningsprofil är relevant för driftsituationen. En undersökning av fältrapporter från tre operativsystem hos IBM 1984 visade att en tredjedel av alla fel hade inträffat en gång hos en kund. Det gav MTTF på 5000 h. Felet som orsakade att Ariane 5 kraschade på sin jungfrutur var ett enkelt programfel, men sex samverkande faktorer bidrog till att det aktiverades.

8 Felinjicering För att prova programvara av hög kvalitet måste man vid provning artificiellt föra in fel i systemet - felinjicering - för att: verifiera felhanteringsmekanismer validera tillförlitligheten Det kräver att man finner : en bra modell för fel på den abstraktionsnivå man arbetar var felen skall injiceras när felen skall injiceras lämplig belastning för systemet vid provning

9 En provningsmiljö User input Campaign specification I/O 3 FIC Readouts Faults or errors I/O Reset Target system Signals Environment simulator Data analyzer Readouts Trigger Error injector

10 Provbänk för felinjicering Styrdator Monitor Felinjicerare Målsystem Datainsamlare Omvärldssimulator Analysator

11 Felinjicering i anrop av program Felinjicering: Anrop med fel parametervärden Felyttring: Crash Omission Timing Value Är feltill stånd i systemet

12 Hur hitta provdata Ekvivalenspartitioner Gränsvärdesanalys Analys av tillståndsmaskin Felträdsanalys Felmodsanalys

13 En generell modell för felbeteende Byzantine Computation Timing Omission Crash

14 Generering av provfall API alloc (OSBUFSIZE size, SIGSELECT signo) TESTING OBJECTS TEST VALUES memory buffer size test object SIZE_1 SIZE_16 SIZE_MAX SIZE_MAXplus1 SIZE_MAXminus1 SIZE_ZERO SIZE_NEG SIZE_MAXINT SIZE_MININT signal number test object NB_ZERO NB_32 NB_MAXINT NB_MININT NB_NEG NB_ALREADYUSED NB_1 TEST CASE { inits } alloc (SIZE_16, NB_ALREADYUSED)

15 Provning av ett RTOS Definition och utförande Definition av systemanrop Definition av provmönster Definition av provfall Definition av prov Loggare Databas Generator Provat system Monitor Felhanterare Injector Reflektor

16 Ett RTOS, resultat 20 systemanrop ingick i provbänken. Omfattande provningsmetodik fanns. För varje systemanrop fanns ett antal program i källtext, som utgjorde separata provfall. Varje provfall kördes för sig. Provfallen hade växt fram organiskt som följd av funna fel i systemet. Metoden med felinjicering på gränssnitt gav mångfalt fler provfall. De kan köras automatiskt. Problemet med att sätta systemet i ett givet tillstånd före ett provfall löstes med en följd av anrop.

17 Ett provfall Ett provfall består av: En följd av inledande systemanrop De sätter systemet i ett givet tillstånd innan det provande anropet görs. T ex måste minne allokeras innan en process kan skapas. Två processer måste skapas om man vill prova kommunikation mellan processer. Returvärden från målsystemet måste kunna användas i såväl inledande som provande anrop. Ett provande anrop Det har parametrar genererade genom cyklisk permutation av alla ingående datatypers värdemängder valda för proven. Ett resultat Systemets svar på det provande anropet. Det skickas till datainsamlaren för loggning och senare analys.

18 Syfte med FoTA P9 Lära oss hur felhanteringsmekanismer i programvara kan klara fel i programvaran, indatafel, temporära maskinvarufel och permanenta maskinvarufel. Etablera ett sätt att analysera, konstruera och bygga programvarusystem med hänsyn till pålitlighet. Etablera för praktisk användning en provningsmiljö för experimentell verifiering av pålitlig programvara. Studera hur generella mekanismer för felupptäckt och felhantering kan byggas in i ett driftsystem. Studera en metod att mäta på gränssnitten i programvara. Detta kan vara av stor framtida betydelse, då det gäller att verifiera COTS.

19 Blueberry Blueberry 3D är ett realtidssystem för visualisering av virtuella utomhusmiljöer. BBDB är det egenutvecklade databassystemet, som lagrar data om terrängen. Blueberry 3D API är ett programmeringsgränssnitt för externa utvecklare. För prov av felhanteringsmekanismerna använde man injicering av felkällor. För BBDB ändrades slumpmässigt tecken i databasen, som sedan lästes in för visualisering. En loggfil skrevs för att underlätta felsökning. I API provades nio funktioner med sammanlagt 16 parameterar. Anropsordning och parametervärden slumpades fram för varje provfall.

20 Blueberry, resultat Ett stort antal provfall kördes: 1445 på BBDB. 513 gav normalt resultat. 886 avbröts av en timer loop eller felmeddelande från Windows, alltså inte nödvändigtvis fel i systemet. 25 gav ohanterat undantag. 21 gav hanterat undantag. 800 på API. 489 gav normalt resultat, systemet kunde hantera felet. 311 gav hanterat undantag, felet blev för stort. Felinjicering av felkällor är en bra metod att eliminera fel i felhanteringen. Man måste ha en bra felmodell. Ett automatiskt verktyg kostar men lönar sig.

21 MACS, Airborne Modular Computer System Prefix Anrop Variabel Generator Programtext Direktiv Kompilator Länkare Laddare Laddmodul Målsystem Logg Värdetabell Suffix

22 MACS, resultat Tre moduler användes vid våra prov. Kopiering av minnesblock 2200 provfall skapades med enbart giltiga parametrar. Alla provfallen fungerade som förväntat provfall skapades, medvetet valda för att provocera programmen. Proceduren gav felbeteende i ett antal fall. Dessa felbeteenden är förväntade, då proceduren inte konstruerats för robusthet utan snabbhet. Flyttalskonvertering mellan MACS och D80E. 22 provfall skapades, alla gav korrekt beteende. Sättning av datum och klocka provfall skapades, alla gav korrekt beteende.

23 Gripen systemdator Starta och initiera test. Gör att testfallen kan köras igenom från början. Sätt tillbaka testfall ett steg Nästa testfall, ett bestämt kodområde. Sätt parametrarna till nästa variant. Gör anrop och logga Avsluta när alla testfall har gåtts igenom

24 Gripen systemdator, resultat Periodisk exekutiv. Den är den aktiva processen och driver systemet. Procedurer kan inte enkelt isoleras och provas separat. Källtestskal byggda för programvaran. Ett antal provfall definierade, som i sekvens provar procedurerna i en tillämpning. Extra programtext genererades, som lades in i k-testskalet och som körde ett stort antal provfall på en procedur. Av utrymmesskäl begränsades antalet till 294. Det viktigt att tänka ut sätt för återstart av systemet eftersom systemet avsiktligt misshandlas med felaktiga och provocerande provvärden. Man kan förvänta sig, att allvarliga fel uppstår. De använda metoderna ersätter inte de nuvarande provfallen men tillför mervärde och kanske kan antalet befintliga provfall reduceras och istället ett stort antal provfall för varje proceduranrop genereras.

25 Tyko 32, planerat Tyko32 WAN Tyko32 LAN LAN Minimal VBS Automatprovare Minimal VBS Provfall med stimulus Respons

26 Tyko 32, genomförande WAN Provfall med stimulus och respons Tyko32 LAN VBS med testfunktionalitet LAN Tyko32 Passiv VBS

27 Tyko 32, resultat Ett stort antal provfall körda genererade fungerade enligt förväntningar gav felbeteende Analys av resultaten gav: En del av felen berodde på felaktig kravbild, systemet var byggt enligt kraven, men kraven var fel. Resterande fel var konstruktionsfel. Inte helt lätt att kontrollera loggar. Ett effektivt sätt att verifiera ett system. Loggen från en körning blir ett bra facit för kommande prov.

28 Generalisering av provbänkarna, blockschema Generell del Definition av systemanrop Definition av provmönster Definition av provfall Definition av prov Loggare Databas Generator Speciell del Monitor Felhanterare Injector Målsystem Omvärldssimulator

29 Några erfarenheter Genom ett genomtänkt val av provdata kan man automatiskt generera och exekvera ett stort antal provfall, som fokuserar på en programenhets funktioner och begränsningar. Självklart kommer man vid tillämpning av metoden att hitta ett antal provfall, där resultatet avviker från det förväntade. Den stora vinsten är dock att: Man får en god täckning av giltiga och ogiltiga anrop till en programenhet. Man får en provbänk, där man kan prova en programenhet med ett stort antal provfall ett stort antal gånger under dess uppbyggnad. Man får en uppsättning referensprov att utnyttjas vid regressionsprov.

30 Sättet att tänka vid utveckling av program förändras. Program byggs provningsbara Man blir klart benägen att tänka på robusthet, vilka fel som kan inträffa vid användning av programmet och hur man skall hantera dem. Man tänker också på provningsbarhet, hur programmet skall kunna verifieras under sin utveckling och sedan det är färdigt. Provning beaktas tidigt. Man ser man systemet ur en annan synvinkel, vilket betyder mycket för att man skall kunna ge det en god arkitektur. Man skapar också provfall på rätt systemnivå innan man trängt för djupt in i detaljerna.

31 Säkerhet i programutveckling Man får en säkerhet i det man gör. Behärskar konstruktionen Får en känsla för var det kan gå snett. Provningssystemet byggs parallellt med programmet Det kan användas kontinuerligt under utvecklingen. Det blir ett kraftfullt komplement till en debugger Loggar från gjorda prov blir referensdata till kommande prov golden run, oracle

32 Hur kan teknik och metod användas Pålitligheten kan kvantifieras En programvarumodul kan provas under oförändrade förutsättningar medan den utvecklas. Repeterbarheten är mycket viktig. Verifiera funktioner och begränsningar. Återanvändning av programdelar förenklas. Provningsprogrammet kan återanvändas. Provresultat kan återanvändas. Kvalitet och produktivitet ökar. Omfattande provning kan göras till acceptabla kostnader. Man får konkreta mätetal för processförbättringar.

33 Provning av objekt Ett objekt är provningsbart om man kan: Sätta provobjektet i godtyckligt tillstånd före ett prov. Stimulera med det provdata. Registrera dess respons och sluttillstånd. Jämföra erhållet respons med förväntat.

34 Fortsatt arbete en provbänk för utvecklare Verifiera pålitlighet. Prova existerande komponenter Lägg in mekanismer för att öka robusthet. Gör om prov och mät förändring. Lägg in mekanismer för feltolerans. Gör om prov och mät förändring. Komplettera med inbyggda mekanismer för provning - Component+. Studera processförbättringar för V&V. Utveckla tekniken och skapa en produkt, som kan användas i vidare sammanhang.