Några grundläggande begrepp Validering bygger vi rätt system? Uppfyller kravspecifikationen de verkliga behoven? Verifiering bygger vi systemet rätt? Uppfyller det färdiga systemet kravspecifikationen? Testning en teknik för att validera och verifiera Syftet med testning är att påvisa fel i systemet. Debugging - lokalisera och rätta fel i systemet.
Testning Målet med testning är att Säkerställa att det levererade systemet fungerar som det tänkt i sin rätta miljö. Finna fel och brister så fort som möjligt samt att försäkra sig om att dessa åtgärdas.
Testning Testning är en vedertagen metod inom all ingenjörsmässig verksamhet för att fastställa om en hypotes, konstruktion eller produkt är korrekt och fungerar som avsett. Till grund för all testning av program ligger programspecifikationen. En dålig eller felaktig specifikation leder till ett undermåligt eller felaktigt program. Testning kan enbart påvisa förekomsten av fel, aldrig frånvaron av fel! Testning syftar till att minimera antalet fel i ett program. Testning är en aktivitet som skall ses som en integrerad del i utvecklingsarbetet. Testning skall göras både under problemlösningsfasen och implementationsfasen. Ju senare i utvecklingsarbetet man upptäcker ett fel ju svårare och dyrare är det att lokalisera och korrigera felet. Testning är en kreaktiv aktivitet.
Testning Enhetstest testning av en enskild programenhet (klass) Integrationstest testning av interaktionen mellan olika enheter. Syftar till att sammanfoga ett antal enheter och testa dess helhetsbeteende. Systemtest testning systemet som helhet. Acceptanstest kundens test för att godkänna systemet för driftsättning. Black box-testning testning utan kännedom om programmets uppbyggnad. White box-testning testning med kännedom om programmets uppbyggnad. Funktionell testning test av funktionella krav. Icke-funktionell testning test av ickefunktionella krav.
Testning Användningstest för att utvärdera systemets användbarhet Konfigurationstest för att utvärdera om systemet fungerar tillsammans med olika konfigurationer av hård- och mjukvara. Prestandatest för att utvärdera att systemet uppfyller uppställda prestandakrav. Skrivbordstest testaren läser kod och exekverar koden för hand. Regressionstest försöker säkerställa att uppdaterad kod inte introducerar nya fel till den tidigare testade koden. Stresstest test för att utröna vad som händer när systemet blir överbelastat. Negativt test test som visar hur systemet fungerar vid felaktig användning.
Testning Olika testfaser Enhetstest Testar en enskild klass (med specialskriven huvudklass för detta ändamål). Integrationstest Testar interaktionen mellan olika enheter. Syftar till att sammanfoga ett antal enheter och testa dess helhetsbeteende. Systemtest Testar systemet som helhet. Acceptanstest Kundens test för att godkänna systemet för driftsättning.
Acceptanstest En testplan, bestående av en uppsättning testfall, skall utvecklas för att testa det färdiga programmet. Alla testfallen måste passera testet för att programmet skall tas i drift. Testplanen ligger till grund för acceptanstestningen, d.v.s. de test som programmet måste genomgå och passera för att tas i drift. Det är beställaren som utarbetar testplanen. Görs lämpligen samtidigt med kravspecifikationen. Planlösa tester leder till att situationer, som borde blivit testade innan i drifttagande, dyker upp under drift och orsakar oväntade fel. Vid acceptanstest testas programmets funktionallitet. Vid acceptanstest används black-box testing, vilket innebär att testningen sätts upp utan kunskaper om hur programmet är implementerat. Om fel upptäcks under testningen, skall felen åtgärdas. Därefter skall alla testfallen i testplanen återupprepas (regressionstest), eftersom korrigeringar av fel kan introducera nya fel.
Val av testdata Det är omöjligt att göra uttömmande testning, dvs testa alla uppsättningar av möjliga indatasekvenser. Man måste ha en uppsättning testfall som är så övertygande att man kan anta att programmet är korrekt. Den metod som används är att indela de möjliga indatasekvenserna i olika ekvivalenskategorier. Ett enkelt exempel: Anta att vi har ett program som skall skriva ut om en person får rösta eller inte. Röståldern är 18 år. Vi får då två ekvivalenskategorier enligt nedanstående figur. 0 17 18 Det finns dock ytterligare en ekvivalenskategori, nämligen den som består av ogiltig data.
Val av testdata I testplanen väljs (minst) ett testfall från varje ekvivalenskategori, samt testfall med värden från övergångarna mellan ekvivalenskategorierna. Vi får således följande testplan: Test nr. Indata Förväntat resultat 1 12 Får inte rösta 2 21 Får rösta 3 17 Får inte rösta 4 18 Får rösta 5-10 Felutskrift 6 0 Får inte rösta 7-1 Felutskrift
Enhetstester Det är mycket lättare att finna fel när man vet vilken klass felet härrör från. Omfattar endast en programenhet (i OOP en klass). Utförs av programmeraren. Programenheten testas utan interaktion med andra programenheter. White box-testing. Kodstrukturen är känd och ligger till grund för att välja testfallen. Uppsättningen testfall skall väljas på så sätt att så stor kodtäckning som möjligt fås (path coverage respektive operation coverage). Det är ert ansvar som implementatör av enheten att ta ansvaret för att eventuella fel i enheten upptäcks under enhetstestningen.
Testpunkter En testpunkt är ett specifikt indatavärde för ett testfall. Val av testpunkter är ofta kritiskt. Ekvivalensklasser är en metod för att välja testpunkter. En annan användbar metod är boundary value analysis (analys av gränsfall). while (x > N) {... } eller skall det vara while (x > N+1) {... } eller while (x > N-1) {... }
Testdriven utveckling På senare tid har man inom systemutveckling börjat tala om testdriven utveckling (Test-driven development, TDD). Testdriven utveckling är en iterativ process i vilken man skriver testfallen i ett enhetstest innan man skriver koden i enheten. Tillvägagångssätt: upprepa till specifikationen är uppfylld skapa ett testfall_n kör alla testfall om testfall_n fallerar implementera om något testfall fallerar refaktorera
JUnit Testning bör om möjligt automatiseras; speciella ramverk för testning finns. JUnit är ett ramverk och interaktivt verktyg för enhetstestning av Javaprogram. JUnit kan gratis laddas ner från www.junit.org.
Integrationstest Hela systemet eller ett delsystem. Enheterna som ingår är beroende av varandra. Fokus på samarbetet mellan enheterna (gränssnitten). Startar tidigare i OOP än då andra programmeringsparadigm används. Top-down test strategy. Använder stubs (programskelett) för att simulera enheter som inte är implementerade. Bottom-up test strategy. Enheterna integreras allteftersom de blivit implementerade.
Systemtest Testet görs på det kompletta systemet. Testet fokuserar på sådana egenskaper som endast finns hos det kompletta systemet. Omfattar både funktionstest och icke-funktionstest. Innefattar prestandatest, konfigurationstest, användningstest, stresstest,
Komplement till testning Formella metoder matematiska metoder för att bevisa korrektheten hos program. Kan verkligen visa avsaknaden av fel. Kräver en formell specifikation av vad programmet skall göra. Kan endast göras för små program. Alternativ endast för mycket kritiska kodsnuttar. Granskning skrivbordstestning. Läs koden och titta efter fel. Mycket effektiv metod om den görs på ett systematiskt sätt.