Introduktion TILL TEST

Transkript

1 Introduktion TILL TEST

2 Innehåll Allmänt om test Definitioner Test principer Myter om test Test process 2

3 Standards FDD IEEE ISO ISTQB RUP SSTB TDD Agile V 3

4 Varför är test nödvändigt?! Programvarusystem är en integrerad del av livet, från verksamhetstillämpningar (t.ex. bankverksamhet) till konsumentprodukter (t.ex. bilar). De flesta har upplevt att programvaran inte fungerar som man förväntat sig. Programvara som inte fungerar korrekt kan leda till många problem, t.ex. förlust av pengar, tid eller affärsmässigt rykte och kan till och med orsaka skada eller dödsfall. 4

5 Tänk om bilar var som applikationer Man beställer. Release 0.1 Release 0.2 Release 0.3 Release 1.0 5

6 Orsak till fel Kod exekveras Orsakar (3)Felsymptom (2)Defekt/Bug (1)Misstag Fel uppstår därför att människor gör misstag på grund av: tidspress, komplex kod, komplexitet i infrastrukturen, förändrad teknologi och/eller att många system interagerar. Felsymptom kan även orsakas av miljömässiga förhållanden t.ex: strålning, magnetism, elektriska fält eller föroreningar. De kan orsaka fel i inbyggda program eller påverka exekveringen av program genom att förändra hårdvarans förutsättningar. 6

7 Testningens roll Testning av system och dokumentation kan hjälpa till att reducera risken fo r att problem uppsta r under drift men ocksa bidra till programvarusystemets kvalitet om fel rättas innan systemet frisläpps fo r användning i drift. Det kan ocksa krävas test av programvara fo r att uppna kontraktsma ssiga eller legala krav eller fo r att uppfylla industrispecifika standarder. 7

8 Test & Kvalité Med hjälp av test är det mo jligt att mäta kvaliteten pa programvaran i termer av hittade fel fo r ba de funktionella och icke-funktionella programvarukrav. Kvalitetssäkring förebygger fel Test visar om kvalitetssäkringen varit effektiv Erfarenheter fra n tidigare projekt bo r tas tillvara. Genom att fo rsta de grundorsakerna till de hittade felen i andra projekt kan processerna fo rbättras vilket i sin tur bo r fo rhindra att dessa fel dyker upp igen och, som en konsekvens, fo rbättra kvaliteten hos framtida system. Test bo r vara en del av de kvalitetssäkrande aktiviteterna, tillsammans med utvecklingsstandarder, utbildning och felanalys. Software Engineering Software Product Quality (ISO 9126) 8

9 Kvalité hur? 1. Gå igenom det du har, behåll bara det du behöver 2. En plats för allt och allt är på sin plats 3. Synliggör problem som kan orsaka kvalitetsbrister 4. Metoder för att upprätthålla och övervaka steg Ordning, en löpande process av ständig förbättring Referens: The Toyota way 9

10 Kostnaden för incidenter i produktion Studier [1] har visat att det introduceras 60 fel (defekter) per tusen rader kod från och med kravfasen i projektets start till och med implementationsfasen. Enligt beräkningar [2] är kostnaden för att rätta till en defekt i produktion 30 gånger så hög som för att göra motsvarande ändring i krav- eller designfasen Studier [3] har visat att en bug som upptäcks i produktion i snitt tar 17 timmar att åtgärda. I denna tid inkluderas: Analys av defekten, Kodrättning, Regressionstest, Uppdatering av dokumentation, Förberedelse för release till produktion, Information till berörda parter om produktionssättningen, Produktionssättningen, där ett antal personer blir berörda [1] IBM [2] Forrester 2009 [3] Eriksson, U., Test och kvalitetssäkring av IT-system, Studentlitteratur

11 Vad är test? Q: Är det bara att exekvera testfall, exekvera programvaran?. A: En del av testningen, men fler aktiviteter ingår också. Test innefattar aktiviteter, såsom: planering och styrning val av testvillkor design och exekvering av testfall kontroll av resultat utvärdering av avslutskriterier rapportering om testprocessen och systemet som testas avslutning eller stängning granskning av dokument (även källkod) 11

12 Myter om Test Vi go r va l lite tester i slutet.eller Test a r det man go r sist av allt. Test handlar bara om att hitta fel. Test är dyrt! Tänk test tidigt! Test kan innebära möjligheter Att testa kostar att inte testa kostar MER. 12

13 Grundläggande testprinciper 1 Test visar att det finns fel 2 Uttömmande testning är omöjlig 3 Tidig testning 4 Ansamlingar av fel 5 Immunitets- paradoxen 6 Test beror på sammanhang 7 Frånvaro-av-fel-fallgropen 13

14 Testprocess Testplanering Testanalys Testdesign Testexekvering Utvärdera/ Rapportera Testavslut 14

15 Utvecklingsmetoder V-modellen (sekventiell utvecklingsmodell) Komponent- (enhets-) testning Integrationstestning Systemtestning Acceptanstestning Iterativ-inkrementell utvecklingsmodell Process, med upprättande av krav, konstruktion, byggande och testning av ett system, som sker i många små utvecklingssteg. Ex: Prototyp Rapid application development, RAD) Rationals utvecklingsprocess (RUP) Agila utvecklingsmodell Grundtankarna bakom agile bygger på att göra kunden/användaren nöjd med det som utvecklas genom ett mycket nära samarbete under hela utvecklingstiden med täta och regelbundna möten mellan utvecklare ochbeställare/mottagare.e x: Scrum XP (extreme Programming) FDD(Feature Driven Development) 15

16 MEN... Oavsett metod så skall ALLA nivåer av test planeras, följas, exekveras, utvärderas 16

17 Testnivå 1: Komponenttest /Unit test Testobjekt: Komponenter, program, datakonverterings-/migreringsprogram, databasmoduler. Testbas: Komponentkrav, detaljerad design, kod. Utvecklarens ansvar Automatiserade tester Test på minsta möjliga komponent Testa sa oberoende av omva rlden som mo jligt Test driven utveckling Kod granskning Statiska och dynamiska tester Test sker i utvecklingsmiljön 17

18 Testnivå 2: Integrationstest Testobjekt: Delsystem, databasimplementation, infrastruktur, systemkonfiguration, gränssnitt och konfigurationsdata. Testbas: Programvaru- och systemdesign, arkitektur, arbetsflo den, anva ndningsfall. Integrationstestning testar gra nssnitt mellan komponenter, samspelet mellan olika delar i ett system, t.ex. operativsystem, filsystem, maskinvaraeller gränssnittet mellan system. Test av icke-funktionella egenskaper (t.ex. prestanda) kan inkluderas Iintegrationstestningen. Vid varje integrationssteg skall testarna koncentrera sig enbart pa sja lva integrationen dvs. gra nssnitten. Vid till exempel integration av modul A med modul B skall de fokusera pa kommunika- tionen mellan modulerna och inte funktionaliteten i de individuella modulerna, som gjordes i komponenttest. 18

19 Testnivå 3: Systemtest Testobjekt: Systemet, manualer, systemkonfiguration och konfigurationsdata. Testbas: Kravspecifikation fo r system och programvara, funktionsspecifikation, riskanalys. Systemtestning täcker hela systemets/produktens beteende. Testningens omfattning skall vara tydligt beskriven i den o vergripande testplanen (master test plan) eller i testplanen fo r aktuell niva. Testmiljo n skall, fo r systemtest, efterlikna den slutliga ma l- eller produktionsmiljo n sa mycket som mo jligt fo r att minimera risken fo r att fel kopplade till miljo n inte hittas under testningen. Systemtest kan omfatta testning baserat pa risker och/eller kravspecifikationer, verksamhetsprocesser eller användningsfall. Systemtest kan underso ka funktionella och icke-funktionella krav pa systemet samt datakvalitetsegenskaper. Systemtestning av funktionella krav startar med att använda mest lämpliga specifikationsbaserade (black-box) tekniker fo r att testa den funktionella aspekten pa systemet. En beslutstabell kan till exempel skapas, inneha llande kombinationer av effekter som beskrivs i verksamhetsreglerna. Strukturbaserade tekniker (white-box) kan sedan användas fo r att utvärdera grundligheten i testningen med avseende pa ett strukturellt element som t.ex. strukturen hos en meny eller navigeringen av en websida 19

20 Testnivå 4: Acceptanstest Testobjekt: Affärsprocesser fo r helt integrerade system, drift- och underha llsprocesser, användarfo rfaranden, formulär, rapporter, konfigurationer och konfigurationsdata. Testbas: Användarkrav, systemkrav, användningsfall, affärsprocesser, riskanalys. Oftast är det kunderna eller andvändarna som har ansvar fo r acceptanstestning, men även andra intressenter kan vara inblandade. Ma let fo r acceptanstestning är att skapa en tilltro till systemet, till delar av det, eller till specifika icke- funktionella egenskaper av systemet. Att hitta fel är inte det viktigaste ma let i acceptanstestning. Acceptanstestning kan utvärdera systemets status info r driftsättning och användning. 20

21 Testtyper 1. Test av en funktion hos programvaran 2. Test av en icke-funktionell kvalitetsegenskap som prestanda eller användbarhet 3. Struktur eller arkitektur hos komponent, programvara eller system. 4. Test kopplad till a ndringar, dvs. bekräfta att ett fel har a tgärdats (omtestning) och visar om oavsiktliga fo rändringar har uppsta tt (regressionstestning). 21

22 Funktionell testning De funktioner som ett system, delsystem eller komponent skall utfo ra kan beskrivas i arbetsprodukter sa som kravspecifikation, användningsfall, en funktionsspecifikation, eller de kan vara odokumenterade. Funktioner visar vad systemet go r. Funktionella tester är baserade pa funktioner och finesser (beskrivna i dokument eller fo rsta dda av testarna) och kan utfo ras pa alla testniva er (t.ex. kan testning av komponenter vara baserade pa en komponentspecifikation) Specifikationsbaserade tekniker kan användas fo r att ta fram testvillkor och testfall fo r programvarans eller systemets funktionalitet. Testning av funktionalitet behandlar det externa beteendet hos programvaran (black-box testing). 22

23 Icke-funktionell testning Icke-funktionell testning inkluderar, men är inte begränsat till testning av prestanda, last, användbarhet, underha llbarhet, tillfo rlitlighet och portabilitet. Det kan ses som testning av hur systemet fungerar. Icke-funktionell testning kan fo rekomma pa alla testniva er. Termen ickefunktionell testning beskriver de tester som krävs fo r att mäta egenskaperna hos ett system eller en programvara och som kan kvantifieras pa en varierande skala, t.ex. svarstider vid prestandatestning. Software Engineering Software Product Quality (ISO 9126) 23

24 FURPS+ 24

25 Omtest och regressionstestning Vad är skillnaden mellan regressionstest och omtest? Regressionstest innebär att man testar orörd kod som kan ha påverkats av ändrad kod. Koden är testad tidigare. Omtest innebär att man testar ändring av kod. Kan ha ändrats p g a bugg i systemet.. 25

26 Del 3 : Statisk testning Till skillnad mot dynamisk testning, som kräver att programvaran exekveras, sa fo rlitar sig statiska testtekniker pa manuell kontroll (granskning) och automatiserad analys (statisk analys) av källkoden eller andra producerade dokument utan att programvaran exekveras. Granskningar är ett sätt att testa arbetsprodukter (inklusive koden) och kan med fo rdel utfo ras fo re dynamisk testning. Defekter som upptäcks genom granskningar i ett tidigt skede (t ex granskningar av krav) är oftast mycket billigare att rätta än de defekter som hittas när man utfo r dynamisk testning av redan utvecklad kod. Granskningar, statisk analys och dynamisk testning har samma o vergripande ma l pa visa fel. Typiska defekter som är lättare att hitta med granskningar än med dynamisk testning innefattar: avvikelser fra n standard, kravdefekter, designdefekter, otillräcklig underha llbarhet och felaktigt specificerade gränssnitt. 26

27 Granskningstyper Informell granskning -ingen formell process; -kan ske genom parprogrammering eller att en teknisk ledare leder design- och kod-granskningen -frivilligt dokumenterad- -nyttan av granskningen kan variera beroende på granskaren Genomgång - mötet leds av författaren -kan ske med hjälp av scenarion, grupp med kolleger -ej tidsbegränsade sammanträden -granskarna är förberedda, granskningsrapport skrivs, avvikelselista tas fram och sekreterare utses -kan variera i utförande från ganska informellt till mycket formellt; Teknisk granskning -dokumenterad, definierad defektutpekningsprocess som inkluderar kolleger och tekniska experter, ledningens deltagande är valfritt; -kan utföras som en granskning med kolleger utan ledarens/chefens deltagande; -önskvärt att granskningen leds av en utbildad moderator Förberedelse innan mötet: -valfritt användande av checklistor Inspektion -granskningsrapport som inkluderar defektlista, beslut om -leds av en utbildad moderator programvaran lever upp till kraven -vanligtvis genomförd av jämlika kolleger -där det är möjligt, rekommenderade åtgärder för defekterna -definierade roller -inkluderar mätetal -formell process som är baserad på regler och checklistor -definierade start- och avslutskriterier för att acceptera programvaran Förberedelser innan mötet: -inspektionsrapport, lista över iakttagelser; -formell uppföljningsprocess(valfritt med processförbättringsprocess) 27

28 Testdesign 28

29 Testdesign 1(3) (1) Ekvivalensklassindelning (2) Gränsvärdesanalys Nummer mellan ) Testfall med test data exakt mellan ) Test data med värden under gränser: 0 och ) Test data med värden just över gränser: 2 och Parameter= månad Giltiga värden=1-12 Ogiltiga värden=0, -1 & 13-n (3) Beslutstabeller Uttag är mo jligt om kunden o nskar ta ut ett belopp som inte o verskrider kontots saldo. Om kunden önskar göra ett uttag som överskrider saldot är uttag endast mo jligt om kunden har en beviljad kredit.. Gränsvärdeanalys används som en del av stress och negativ testing (4)Tillståndsbaserad testning Ett system kan visa olika svar eller resultat beroende på vilka villkor och vilket tidigare händelseförlopp (dess olika tillstånd) som skett. I dessa fall kan systemet visas som ett tillståndsdiagram. Det tillåter testare att se programmet eller systemet i termer av tillstånd, övergångar mellan tillstånden, invärden eller händelser som gör att tillstånden ändras, dvs. en tillståndsövergång sker och de händelser som sker som resultat av dessa tillståndsövergångar. Tillstånden i systemet eller objektet som testas är separerade, identifierade och är av ändligt antal. En tillståndstabell visar förhållandet mellan tillstånd, indata och kan synliggöra övergångar som är ogiltiga. Tabellens övre halva innehåller olika villkor som ska testas. Den nedre halvan beskriver de olika händelser som sker baserat på valen i den övre halvan. Av tabellen framgår att det finns fyra möjliga scenarion som behöver testas. Genom att göra ett test per kolumn, kommer alla kombinationer av utlösande villkor att testas. 29

30 Testdesign 2(3) (5) Användningsfallsbaserad testning Tester kan härledas från användningsfall. Ett användningsfall beskriver interaktionen mellan aktörer, användare eller system, vilket producerar ett resultat av värde för en systemanvändare eller en kund. Användningsfall kan beskrivas på en abstrakt nivå (teknikoberoende affärsflöden på affärsprocessnivå), eller på systemnivå (systemanvändningsfall på funktionalitetsnivå). Varje användningsfall har förvillkor som måste vara uppfyllda för att användningsfallet skall fungera. Varje användningsfall avslutas med ett antal slutvillkor, vilka utgörs av observerbara resultat och systemets sluttillstånd när användningsfallet genomförts. Det krävs också att systemet har ett avsett sluttillstånd när användarscenariot är avslutat. Ett användningsfall har ett huvudflöde, dvs. det mest troliga scenariot, men kan även ha alternativa scenarion. 30

31 Testdesign 3(3) (6)Erfarenhetsbaserad testning Tester skapas baserat på testarens skicklighet och intuition och hans/hennes erfarenhet av liknande applikationer och teknologier. Som komplement till mer systematiska testtekniker, kan dessa tekniker vara mycket värdefulla genom att testfall identifieras, vilka annars inte skulle hittas via de mer formella teknikerna. Dock varierar effektiviteten hos denna typ av testning med erfarenheten hos testaren. En vanligt förekommande erfarenhetsbaserad teknik är felgissning, i vilken testare förutspår potentiella defekter utifrån sin tidigare erfarenhet. Ett strukturerat sätt att arbeta med felgissning är att göra en lista av möjliga defekter och därefter skriva tester som blottar dessa defekter. Detta systematiska angreppssätt kallas för felattack. MEN det räcker inte att tänka kreativt eller att försöka knäcka programmet Erfarenhetsbaserad testning är vad det heter! (James Bach) 31

32 Testroller Roll Utför Ansvarar för (dokument) Testare Exekverar tester Defekt rapport Testanalytiker Utvecklar testfall Planerar test exekvering Verifierar ändringar Testfall Testprotokoll Testledare Skapar testplan Skapar Iteration testplan Skapar teststrategi Administrerar test Defekt rapport Testrapport Testplan Teststrategi Status rapport 32

33 Mätetal & Mätning En mängd mätetal (typ av mätning, sort, enhet) med associerade mätvärden (faktiska värden) bör användas under hela livscykeln för programvaruutveckling för att hålla koll på olika aspekter av utvecklingen. Exempel på mätetal är planerade aktiviteter, täckningsgrad,arbetsbelastning, osv. För många mätetal är det fördelaktigt att fastsälla en uppskattad utveckling och sen jämföra den aktiska utvecklingen hos det aktuella mätetalet mot uppskattningen. Förankra mätetalen innan testerna startar. Sätt upp en enkel dashboard 33

34 Utvärdera test/defekter med KPI KPI (Key Performance Indicator) Mått för effektivitet hos en verksamhet. På svenska kallar man detta ofta nyckeltal för verksamheten. Vilka faktorer som mäts varierar från fall till fall, exempelvis: Kostnadsreduktion Maximal väntetid för en kund För att kunna identifiera nyckeltal måste man ha: en fördefinierad affärsprocess. tydliga mål / krav på affärsprocesser. kvantitativ / kvalitativ mätning av resultat och jämförelse med uppsatta mål. Undersöka skillnader och processer eller resurser för att uppnå kortsiktiga mål. När man identifierar nyckeltal tillämpas ofta förkortningen S.M.A.R.T. Nyckeltalen skall vara: (Specific, Measurable, Achievable, Result-oriented or Relevant, Time-bound) 34

35 Exempel KPI Namn Beskrivning Mättal Test: Pass/Fail/Block Uppgift om programvarans kvalitet (efter enhetstestning). Antal genomförda tester som godkänts dividerat med totalt antal tester som har genomförts. Antal kända defekter i produktion Mätning av den övergripande kvaliteten på systemet i produktion, i termer av antalet utestående defekter som accepteras med tillräckligt låg risk. Totalt antal defekter (klassificeras efter svårighetsgrad) dividerat med antalet defekter (klassificeras efter svårighetsgrad) i exit kriterier. 35

36 Verktyg Testmanagement: Quality Center, Test Manager (TFS), Rational TestManager, QuickTestPro, SilkCentral Test Manager, Fitnesse Prestanda: Load Runner Configuration Management: Rational ClearQuest, JIRA Krav: Rational Requirements Composer, DOORS, Enterprise Architect, ReQtest Process: ARIS 36

37 Men, de bästa testverktyg är. 37

38 Exempel på vanliga misstag vid test 38

39 (1) Test = Kvalité Inte bara testarens uppgift! 39

40 (2) Teststatus Testing går bra", ja vi har testat detta" testing skall vara klar' tills på tisdag" utan givet sammanhang. Att rapportera teststatus kräver att man tar upp risker, täckning, arbetsinsats, och hur det relaterar till nuvarande version och potentialen för den framtida utveckling. Vi borde rapportera utifrån affärsnyttan. Det är som när en man frågade stenhuggaren vad arbetar du med? Hugger sten svarade en medan na sta svarade Jag hja lper till att bygga en katedral! 40

41 (3) Testning är en färdighet 41

42 (4)Symptom/grundorsak Behandla inte symptomen! Sök och hitta grundorsaken! #1: Brist på systemtänkande #2: Översättnings/tolknings problem #3: Bristfällig process kunskap #4: Bristfällig teknologi kunskap 42

43 Standarder/Länkar/Litteratur [IEEE ] IEEE Std 829TM (1998) IEEE Standard for Software Test Documentation [IEEE 1028] IEEE Std 1028TM (2008) IEEE Standard for Software Reviews and Audits [IEEE 12207] IEEE 12207/ISO/IEC , Software life cycle processes [ISO 9126] ISO/IEC :2001, Software Engineering Software Product Quality ISTQB ( SSTB ( CMMI ( TMMi ( Six Sigma ( [Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing [Beizer, 1990] Beizer, B. (1990) Software Testing Techniques [Black, 2001] Black, R. (2001) Managing the Testing Process [Copeland, 2004] Copeland, L. (2004) A Practitioner s Guide to Software Test Design [Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing 43

44 44