Testplanering, test-first, testverktyg Mats Skoglund Department of Computer and Systems Sciences Stockholm University/Royal Institute of Technology Stockholm, Sweden 12 mars 2007 Mats Skoglund Page 1(33)
Projektplanering <-> testplanering Vad Hur Vem När Uppföljning Dokumentation Testplanering Mats Skoglund Page 2(33)
Figur 1: IEEE Standard for Sofware Test Documentation IEEE Std 829-1998
Test plan [IEEE (Std. 1012-1986 and 829-1998)] 1. Test plan identifier 2. Introduction 3. Items to be tested 4. Features to be tested 5. Approach 6. Pass/fail criteria 7. Suspension and resumption criteria 8. Test deliverables 9. Testing tasks 10. Test environment Mats Skoglund Page 4(33)
11. Responsibilities 12. Staffing and training needs 13. Scheduling 14. Risk and contingencies Mats Skoglund Page 5(33)
Test plan identifier En unik identifierare för att kunna koppla ihop planen med sitt projekt Formatet på identifieraren bestäms av organisationen exempel: CCS-WCD-2004-1 Mats Skoglund Page 6(33)
Introduktion Översiktlig beskrivning av projektet och av det som ska testas. Referenser till andra viktiga dokument, t.ex. kvalitetsdokument, konfigurationsstyrningsplaner, standarder mm. Mats Skoglund Page 7(33)
Items to be tested En lista på det som ska testas, namn, identifierare och version, referenser till deras dokument En lista på vad som inte ska testas Spårbarhet till krav exempel: Name ID Version main CCS-1 2.3 validate_file CCS-2 1.3 Mats Skoglund Page 8(33)
Features to be tested En annorlunda vy Vad som inte testas Feature Scheduling Help Design spec ID CCS-DS-1 CCS-DS-5 Performance tests will not be performed since these items are not time critical Mats Skoglund Page 9(33)
Approach Vilken ansats man har för testningen Hur man testar Hur man mäter Hur man tar fram indata Hur spårbarhet ska uppnås Personal Hur man dokumenterar Hur man monitorerar Vilka verktyg man använder Mats Skoglund Page 10(33)
Pass fail criteria Generell beskrivning av hur man avgör att något klarat testet T.ex. när förväntat utdata ej överenstämmer med verkligt utdata Hur allvarlig eller stor avvikelsen är Mats Skoglund Page 11(33)
Suspension and resumption criteria När ska man avbryta testerna, exempel: för dålig kvalitet från tidigare testfaser ett allvarligt fel har hittats det går inte att logga in När ska man återuppta testerna efter att de avbrytits Mats Skoglund Page 12(33)
Test deliverables Vad levereras av testarna, t.ex. Själva testplanen Testfallsspecifikationer Testprocedurspecifkationer Testloggar Testrapporter Testdata Testkoden... Mats Skoglund Page 13(33)
Testing tasks De aktiviteter som skall utföras m.a.p. testning Testplanskonstruktion Specificering av testfall Uppsättande av testmiljö Utbildning Exekvera testfall Skriva testrapport... Mats Skoglund Page 14(33)
Test environment Hårdvara och mjukvara som behövs för att testa 1 PC med Linux xxxm, med DB YY installerad 1 PC med Linux xxxn, där serverprogramvaran körs 2 PC med WinXX som klienter, samt Coverageverktyget installerat JUnit, Emma och Structural Analysis for Java... Mats Skoglund Page 15(33)
Responsibilities Vem som ansvarar för vad Lisa Lisen, testledare, ansvarar för testplanen och schemat Per Persson, testare, konstruerar och exekverar testfall Anna Eriksson, testare, konstruerar och exekverar testfall Hans Hansson, testassistent, ansvarig för testrapportering... Mats Skoglund Page 16(33)
Personal och utbildning Vilken kompetens behövs Vilka utbildningsinsatser krävs Mats Skoglund Page 17(33)
Schemaläggning Hur lång tid tar de olika aktiviteterna Vilka aktiviteter beror av varandra När måste aktiviteterna påbörjas och avslutas Ganntscheman Mats Skoglund Page 18(33)
Risk and Contigencies Riskerna måste Identifieras Utvärderas för att bedömma sannolikheten för att de inträffar Prioriteras Kostnad om de inträffar Kostnad för att förhindra att de inträffar Mats Skoglund Page 19(33)
Test case specification Test case specification identifier Test items Input specifications Output specifications Special environment needs Special procedure requirements Intercase dependencies Mats Skoglund Page 20(33)
Test items Vilka komponenter som täckas av testfallet Eventuellt referenser till specifikationer Mats Skoglund Page 21(33)
Input specifications Exakt vilka värden som ska anges, eventuellt med toleranser Namn på filer etc som ska användas Relationer mellan indata, t.ex. timing Output specifications Exakt vilka resultat som förväntas, eventuellt med toleranser Relationer mellan indata, t.ex. timing Mats Skoglund Page 22(33)
Special environment needs Vilken hårdvara och mjukvara och annat som krävs för att exekvera testfallet Special procedure requirements Beskriv eventuella krav på hur genomförandet ska ske, t.ex. vilken set-up eller manuella åtgärder som krävs Intercase dependencies Lista vilka testfall som måste körs före detta testfall Summera beroendenas natur Mats Skoglund Page 23(33)
Test-first Test-driven development Använt begrepp inom extreme Programming Man skriver testfallen innan man skriver koden Vissa hävdar att det är utvecklingsmetod, ej en testmetod Mats Skoglund Page 24(33)
Procedur för test-driven utveckling 1. Skapa ett test 2. Kör alla testerna och se hur de misslyckas 3. Skriv koden som implementerar den nya funktionaliteten 4. Kör alla test och se hur de lyckas 5. Refactor för att ta bort redundanta delar 6. Starta om från början Mats Skoglund Page 25(33)
Fördelar 1. Testerna utvecklas i takt med programvaran 2. Testbarheten ökar 3. Utvecklarna blir mer och mer säkra på programvaran 4. Testerna kan användas som specifikation och dokumentation Nackdelar 1. Testerna riskerar att hålla låg kvalitet 2. Man skriver testfall som testar vanlig användning, ej extremfallen Mats Skoglund Page 26(33)
Vad säger forskningen? TDD gav lägre coverage (92,6% jämfört med 95,1%) [M. Pancur, m.fl] TDD hade högre kvalitet på koden (dock ej signifikant) [M. Pancur, m.fl] Lösningen produceras inte snabbare med TDD [M. Muller och O. Hagner] TDD klarade 18% fler acceptanstester [B. George och L. Williams] TDD tog 16% längre tid [B. George och L. Williams] TDD tog ungefär lika lång tid [L. Williams m.fl] TDD gav inte lägre coverage [A. Geras m.fl] TDD gjorde att testerna blev av [M. Maximilien och L. Williams] Mats Skoglund Page 27(33)
Testautomation och verktyg för test Verktyg för att exekvera testfall Generera indata Jämförelseverktyg Planeringsverktyg Verktyg för att hålla ordning på testfall och konfigurationer Defektrapporteringsverktyg Coverageverktyg och complexitetsanalysverktyg Prestandatestverktyg Simulatorer Ändringsanalysverktyg Mats Skoglund Page 28(33)
Testautomation En dedikerad organisation med tillräckliga resurser krävs Ledningen måste vara inblandad och motiverad Man bör (självklart) inte automatisera en dålig manuell testprocess Testautomatisering måste planeras in tidigt Realistiska mål och förväntningar, testautomation är inte någon silverkula Mats Skoglund Page 29(33)
Exekveringsverktyg Exekverar snabbare, mer systematiskt och med högre precision Gör att testare slipper tråkiga upprepande aktiviteter Man kan snabbt köra om testerna efter buggrättning Enkelt att köra om testerna med olika konfigurationer En del av det man sparar in på manuell testning går åt till att hantera den automatiska testningen, speciellt på instabil mjukvara En bra testare hittar fel som inte de automatiska testerna hittar I vissa fall kan testkoden bli mer komplicerad än det som testas men manuellt enkel att genomföra Testerna bör upprepas för att vara värda att automatiseras Mats Skoglund Page 30(33)
Verktyg för att generera indata White-boxtestning Från mer formella specifikationer (UML-modeller, tillståndsdiagram mm) Grafiska gränssnitt och multimedia ställer till det Mats Skoglund Page 31(33)
Administrationsverktyg Planeringsverktyg (projektplanering) Hålla ordning på vilka testfall som finns och när de körts och hur de ändrats Problemhanteringsverktyg för att registrera avvikelser och problem Mats Skoglund Page 32(33)
Summering Planera för testning Testa först eller sist Använd testverktyg, med måtta Mats Skoglund Page 33(33)