Introduksjon til Software Testing av Hans Schaefer hans.schaefer@ieee.org Http://home.c2i.net/schaefer/testing.html www.softwaretesting.no Hvorfor skal vi teste Grunnleggende fakta Test modell Terminologi Hvem bør gjøre jobben og når 2000-2008 Hans Schaefer Side 1
Murphy's lov er utgangspunktet i vårt testarbeid. Det er alltid feil (når mennesker gjør noe). Og selv om det ikke alltid går galt, så kan det koste mye hvis det går galt. Testing skal sikre at risikoen for feil er kjent. 2000-2008 Hans Schaefer Side 2
Testmål Finne feil. Reduser risiko ved å få informasjon om produktkvaliteten. Sertifisere software Spare penger Ved å få rettet feil. Ved å forebygge feil. Feil koster mye mer hvis de får lov å leve lenge. 2000-2008 Hans Schaefer Side 3
Fundamental Test Candidates Testing includes checking of: - Environment: Conditions, natural phenomena, physical laws of nature, business rules, and physical properties, and the full ranges of the system operating environment. - Operators/Users: Proper status/condition, correctly processing all operator/user inputs. For incorrect operator/user inputs, system does not enter into a dangerous or uncontrolled state. Validate user documentation elements. - Hardware: Correct interaction with each hardware interface, controlled system response (i.e., graceful degradation) for hardware faults. - Other Software: System interfaces correctly with other software, isolates errors. 2000-2008 Hans Schaefer Side 4
Hva er feil? An error is a human oversight or a wrong decision. Errors lead to defects (or faults or BUGS) in software. (Fault = Manifestation of an error in software). Defects may lead to failures during run time. (Failure = Deviation of software from expected results or service). Testing kan enten konsentrere seg om defects, eller failures, eller begge. Forsiktig ved feilstatistikk! Test mot defects i modultest, mot failures i høyere nivå test! 2000-2008 Hans Schaefer Side 5
Hva er testing? Å utføre programmer og kontrollere om resultat er som spesifisert eller som forventet. Å utføre analyser for å kontrollere software og dokumentasjon mot krav og forventninger. Begge deler! Først analyse av det vi utvikler, så utføring! Tester motivasjon: www.testmanagement.com -> article The Test Team Paradox 2000-2008 Hans Schaefer Side 6
Feilkostnader Fra fase til fase i et prosjekt øker feilkostnadene med en faktor mellom 2 og 10. Økningen er eksponentiell. Det samme gjelder i testfasene: Feil funnet i høyere nivå test koster vesentlig mer å rette enn feil funnet i lavere nivå test. For kunder kan feilkostnader være enorme. (biltilbakekallinger, nettbanken). Testing skal bidra til å finne feil tidligst mulig! 2000-2008 Hans Schaefer Side 7
En nettbankfeil (11 Juni 2007) 2000-2008 Hans Schaefer Side 8
Risikobasert test Du kan ikke teste alt! Vi tester hvor risikoen er: Det som er viktigst (størst kostnad for kunden / brukeren hvis feil) Det som sannsynligvis er verst (full av feil) Hver testplan må inneholde en prioritering basert på risiko! Våre standard testmetoder adresserer typiske risikofaktorer! 2000-2008 Hans Schaefer Side 9
Økonomisk balanse Cost Total Cost Test Cost Cost of Losses (Risk) Effort on optimal Test 2000-2008 Hans Schaefer Side 10
Definisjoner av testnivåer Modul (Unit, Component) test: Test av moduler for å finne detaljdesign og kodefeil. Modulintegrasjonstest: Test av modulinteraksjon. Moduler på samme plattform eller i samme prosess. For å finne grensesnittfeil. Høyere nivå integrasjonstest: Test av interaksjon mellom subsystemer. Moduler på forskjellige plattformer eller i flere prosesser. For å finne grensesnittfeil. Vanligvis på målplattformen. Systemtest: Test mot kravspesifikasjon. funksjonell test: Test av hver funksjon mot dens krav. For å finne høynivå-designfeil og misforståtte krav. Interaksjonstest: Test av funksjoner med en annen. For å finne konflikter mellom funksjoner. Ikke funksjonell test: Test spesielle ting og systemegenskaper. System integrasjonstest: Test av interaksjon mellom systemet og andre eksterne systemer. For å finne grensesnittfeil. Akseptansetest: Kundetest for å se om systemet oppfyller kontraktskrav og forventninger. Er systemet brukbart i praksis? 2000-2008 Hans Schaefer Side 11
V-modellen Review Kundespesifikasjon Prosjekttid Akseptansetesting Plan&Spesifiser Forbered Utfør Avslutt Review Kravspesifikasjon Plan&Spesifiser Systemtesting Forbered Utfør Avslutt Design Review Integrasjonstesting Plan&Spesifiser Forbered Utfør Avslutt Review Modul implementasjonmodultesting + MIT P&S Forbered Utfør Avslutt 2000-2008 Hans Schaefer Side 12
V-modellen (ved flere systemer) Prosjekttid Kundespesifikasjon Akseptansetesting Plan&spesifiser forbered utfør avslutt Løsningsarkitektur Systemintegrasjonstesting Plan&spesifiser forbered utfør avslutt Spes. av hvert system (enkelt)systemtesting Plan&spesifiser forbered utfør avslutt Detaljer i hvert system Lavere nivå test P&S forbered utfør avslutt 2000-2008 Hans Schaefer Side 13
Hvorfor V-modellen Hvert testnivå skal finne feilene fra tilsvarende konstruksjonsnivå. Tidlig testforberedelse! Finn feilene når du forbereder test, ikke når du utfører de! Testforberedelse gir deg en bedre forståelse for oppgaven, en bedre basis å jobbe ut fra! 2000-2008 Hans Schaefer Side 14
Problemer med V-modellen Tidlig testmateriale blir devaluert av endringer som kommer senere. Noen tester er for dyre å kjøre umiddelbart (for mye arbeid å lage testomgivelse). Noen tester burde egentlig bli kjørt umiddelbart (selv om de tilhører et annet, senere testnivå). Mange enheter (moduler etc.) har flere versjoner utover utviklingen, med ulik risiko. Behov for testing om og om igjen. For en diskusjon av grensene til tidlig testforberedelse, se 2000-2008 Hans Schaefer Side 15 http://www.ddj.com/architect/199600262
Hvordan bruke V-modellen Kjør en V for hvert inkrement / release. Lag test-sjekklister (use cases, utkast av testspesifikasjoner) så tidlig som mulig. Lag testdata samtidig med programkoden. Oppbevar testmaterialet og automatiser dets utførelse. Oppdater testmaterialet etter hver release. Regresjonstest!!! Gjerne en liten automatisk regressionstest, i hvert fall før hver release! 2000-2008 Hans Schaefer Side 16
Inkrementell modell: Hvordan arbeidet virkelig går Tid Spes., design, kode Release 1 Release 2 Release 3 Testspes. T. design T. Environment Testspes. T. redesign Testspes. T. redesign T. kjøring T. kjøring T. kjøring 2000-2008 Hans Schaefer Side 17
Målkonflikter - Du og din test Du er blind for dine egne feil. Du er konstruktiv, testing er destruktiv. Du vil bli ferdig. Testing forsinker deg. -> En annen burde teste! Det tar ekstra tid for en annen å lære hva du gjør -> Test selv! En god test kan ikke redde et dårlig program. -> Et ledelsesproblem! 2000-2008 Hans Schaefer Side 18
Hvem gjør vanligvis testarbeidet? Modultest: Du selv (kanskje en kollega bør hjelpe deg med forberedelsen). Modul integrasjonstest: Du selv (kanskje en kollega bør hjelpe deg med forberedelsen). Høyere nivå integrasjonstest: Testere og testspesialister. (fra en egen testgruppe). Systemtest: Testgruppe og supportfolk, eventuelt kunde skal være med. Muligens en egen organisasjon. Akseptansetest: Kunden og testspesialister. Tredje parter. Hvorfor disse folk? Et kompromiss mellom kunnskapen om systemet, nødvendigheten av et uavhengig synspunkt, og nødvendigheten av spesialkunnskap om testing.. 2000-2008 Hans Schaefer Side 19
Akseptansetest (AT) og leverandørens test AT = Sjekke om leverandøren har fortstått rett, sjekke om leverandøren har gjort sin jobb. Minimer arbeidet ved å sjekke opp leverandøren: Konkrete krav til leverandørens test Oppfølging av leverandørens arbeid, spesielt kontrollene og test Oppfølging av systemets pålitelighet under test Input til test design hos leverandøren Info til leverandør om applikasjonens risikofaktorer (i bruk) Din egen AT bør oppdateres med fokus på hvor leverandøren hadde problemer! 2000-2008 Hans Schaefer Side 20
Testprosessen Plan: Prosjektplan for testing. Spesifiser: Analyser spesifikasjon / design og skriv testkrav. Prioriter! Forbered: Utvikle test infrastruktur og testdata. Utfør: Kjør testene. Kontroller resultatene. Rett feil og kjør testene om igjen. Kontroller testdekning og legg til flere testtilfeller. Avslutt: Rapporter og rydd opp testmaterialet for sitt videre liv. 2000-2008 Hans Schaefer Side 21
Testprosessen - utføring Tre faser Pre-test / Smoke test: Utfør noen få testtilfelle, for å se om produktet i det hele tatt virker. Se om test infrastrukturen fungerer. Hovedtest: Utfør alle planlagte testtilfelle. Ettertest: Utfør ekstra testtilfelle. Gjenutfør test etter feilretting (Regressionstest). 2000-2008 Hans Schaefer Side 22
Metoder for feilbekjempelse: Din verktøykasse! Reviews / gjennomganger / inspeksjoner Manuell dokumentsjekk. Finner misforståelser og glemte ting. Billig metode. Gjør dette før testing! Black box test (Funksjonell test eller behavioral test ) Systematisk test basert på spesifikasjoner på alle nivåer. Finner misforståelser, glemte ting, funksjonelle feil. Første valg som testutviklingsmetode. White box test (Strukturell eller glass box test) Systematisk dekning av programdeler (linjer, forgreninger etc.). Lett å måle med automatiske verktøy. Ikke bra som testdesign metode. Men det er viktig å vite at alt er testet. Intet strukturelt kriterium er i prinsipp godt nok. 2000-2008 Hans Schaefer Side 23
Flere metoder Statisk analyse Bruk av automatiske verktøy for å analysere design, spesifikasjoner eller kode. Verktøyet leser gjennom dokumentet og finner en del feiltyper. Mest effektiv mot mange kodefeil. For eksempel initialiseringsfeil, brudd av kodestandard. Et eksempel er også spekllsjeklkeren. BBBruk DENN!. Dynamisk analyse Bruk av automatiske verktøy for å sjekke globale betingelser under testkjøring. Bra mot minneslekkasjer (PURIFY) og korrupsjon av globale data. 2000-2008 Hans Schaefer Side 24
Hva gjør vi hvis vi har dårlige spesifikasjoner? Test går mot en spesifikasjon. Uten god spesifikasjon ingen god test! - Bruk anvendelses-spesialister - Gjenbruk tidligere testmateriale - Bruk produksjonsdata fra tidligere systemer - Test mot konkurrerende systemer - Se Testing in Darkness, www.softwaretesting.no/testing/testindarkness.pdf 2000-2008 Hans Schaefer Side 25
Generell testpolicy Tenk tidlig hva du vil teste. Fra prosjektstart! Feil er naturlig, utfordringen er å finne de så tidlig som mulig! Husk at du er blind for dine egne feil! Oppbevar dine tester, gjør de klare for gjenbruk! Du må vite hva du har testet, hva ikke og hvorfor! 2000-2008 Hans Schaefer Side 26
Literatur 1 - Boris Beizer, Black Box Testing, John Wiley and Sons, New York, 1995. A book about basic methods for test data selection. Useful especially for unit and integration test, and the functional part of system testing. 2 - C. Kaner, J. Falk, H. Q. Nguyen, Testing Computer Software (3nd ed.), John Wiley & Sons, 1999. A good book for beginners, especially in projects under time and market pressure and consumer software production. Contains some good advice for system testing. Good list of possible defects. Very practical. 3 - Lee Copeland, A Practitioner s Guide to Software Test Design, Artech House, 2004. A good introductory test on test design methods. Easy to understand and many examples. 4 - Glenford Myers: The Art of Software Testing, New York, John Wiley, 1979. The classic book about software testing. Still, more than half of it is important knowledge. Some good advice for every test level, and the basic ideology. 5 - Bart Broekman, Edvin Notenbom, Testing embedded software, Addison-Wesley 2003. Test design and management for technical software. 6 - Martin Pol, Ruud Teunissen, Erik van Veenendal, Software Testing, A Guide to the Tmap Approach, Addison Wesley, 2001. This is the standard way to organize testing in the Netherlands. A good guide for managing development of application software. 7 - IEEE Software Magazine, Something about testing, quality management or reviews in nearly every edition. 8 - Better Software Magazine, www.bettersoftware.com. www.stickyminds.com Very practical! 9 - Erik van Veenendal (ed.), The Testing Practitioner, UTN 2003, ISBN 90-72194-65-9 10 - Tilo Linz, Andreas Spillner, Hans Schaefer Software Testing Foundations, dpunkt Verlag 20026, 2nd ed Rocky Nook 2007. 11 - Rex Black, Critical Testing Processes, Addison-Wesley, 2003, Rex Black, Managing the Testing Process. 2000-2008 Hans Schaefer Side 27
Standards IEEE Std. 829: Standard for System and Software Test Documentation (Very useful as a checklist. The only civilian standard of its kind. ISTQB Glossary of testing terms www.istqb.org ISO/IEC Guide 2:1991, General terms and their definitions concerning standardization and related activities. ISO/IEC 2382-1:1993, Data processing - Vocabulary - Part 1: Fundamental terms. ISO/IEC 2382-20:1990, Information processing vocabulary - Part 20: System development. ISO 9000:2000, Quality management systems - Fundamentals and vocabulary. ISO 9001:2000 Quality management systems - Requirements. ISO 9004:2000 Quality management systems - Guidelines for performance improvements. ISO/IEC 9126-1:2001: Software engineering - Product quality - Part 1: Quality model. (Standard will be renamed 25010!) ISO/IEC TR 9126-2:2003: Software engineering - Product quality - Part 2: External metrics. ISO/IEC TR 9126-3:2003: Software engineering - Product quality - Part 3: Internal metrics. ISO/IEC TR 9126-4:2003: Software engineering - Product quality - Part 4: Quality in use metrics. ISO/IEC 25051:2006, Software Engineering - Software Product Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing (older version: ISO 12119, IEEE 1465) ISO/IEC 12207:1995, Information technology - Software life cycle processes. ISO/IEC 14102:1995, Information technology - Guideline for evaluation and selection of CASE tools. ISO/IEC 14598-1:1997, Information technology - Software product evaluation - Part 1: General overview. ISO/IEC 14598-2:, Information technology - Software product evaluation - Part 2: Planning and management. ISO/IEC 14598-3:, Information technology - Software product evaluation - Part 3: Process for developers. ISO/IEC 14598-4:, Information technology - Software product evaluation - Part 4: Process for acquirers. ISO/IEC 14598-5:1997, Information technology - Software product evaluation - Part 5: Process for Evaluators. ISO/IEC 14598-6:, Information technology - Software product evaluation - Part 6: Documentation of evaluation modules. ISO/IEC 15026:, Information technology - Software integrity - System and software integrity levels. ISO/IEC 15504-8:, Information technology - Software process assessment - Guide for use in determining supplier process capability. Radio Technical Commission for Aeronautics (RTCA) DO-178B/ED-12B, Software Considerations in Airborne Systems and Equipment Certification. Ministry of Defence (UK) (MOD), Interim Defence Standard, 00-55 (Parts 1,2)/Issue 1, The Procurement of Safety Critical Software in Defence Equipment. IEC 880-1986, Software for computers in the safety systems of nuclear power stations. IEC 1508 (1995 Draft), Functional Safety: Safety-related systems. Part 3: Software requirements. IEEE Std. 1008: Standard for Software Unit Testing (Testing process) IEEE Std. 1012-1998: Standard for Software Verification and Validation IEEE Std. 1028: Standard for Software Reviews and Audits IEEE Std. 1044: Standard Classification for Software Anomalies IEEE Std. 1059: Guide for Software Verification and Validation Planning IEEE Std. 1062-1993, Recommended Practice for Software Acquisition. MISRA Guidelines for C: Motorvehicle Industry Software Reliability Association FDA: General Principles of Software Validation: Final Guidance for Industry and FDA Staff, 11 January 2002, http://www.fda.gov/cdrh/comp/guidance/938.pdf ISO/IEC JTC1 SC7 WebSite: http://www.jtc1-sc7.org 2000-2008 Hans Schaefer Side 28