Introduksjon til Software Testing

Transkript

1 Introduksjon til Software Testing av Hans Schaefer Hvorfor skal vi teste Grunnleggende fakta Test modell Terminologi Hvem bør gjøre jobben og når Hans Schaefer Side 1

2 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 Hans Schaefer Side 2

3 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 Hans Schaefer Side 3

4 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 Hans Schaefer Side 4

5 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! Hans Schaefer Side 5

6 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: -> article The Test Team Paradox Hans Schaefer Side 6

7 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! Hans Schaefer Side 7

8 En nettbankfeil (11 Juni 2007) Hans Schaefer Side 8

9 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! Hans Schaefer Side 9

10 Økonomisk balanse Cost Total Cost Test Cost Cost of Losses (Risk) Effort on optimal Test Hans Schaefer Side 10

11 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? Hans Schaefer Side 11

12 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 Hans Schaefer Side 12

13 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 Hans Schaefer Side 13

14 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! Hans Schaefer Side 14

15 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 Hans Schaefer Side 15

16 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! Hans Schaefer Side 16

17 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 Hans Schaefer Side 17

18 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! Hans Schaefer Side 18

19 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 Hans Schaefer Side 19

20 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! Hans Schaefer Side 20

21 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 Hans Schaefer Side 21

22 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) Hans Schaefer Side 22

23 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 Hans Schaefer Side 23

24 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 Hans Schaefer Side 24

25 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, Hans Schaefer Side 25

26 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! Hans Schaefer Side 26

27 Literatur 1 - Boris Beizer, Black Box Testing, John Wiley and Sons, New York, 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, 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, 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, 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 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, 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, Very practical! 9 - Erik van Veenendal (ed.), The Testing Practitioner, UTN 2003, ISBN Tilo Linz, Andreas Spillner, Hans Schaefer Software Testing Foundations, dpunkt Verlag 20026, 2nd ed Rocky Nook Rex Black, Critical Testing Processes, Addison-Wesley, 2003, Rex Black, Managing the Testing Process Hans Schaefer Side 27

28 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 ISO/IEC Guide 2:1991, General terms and their definitions concerning standardization and related activities. ISO/IEC :1993, Data processing - Vocabulary - Part 1: Fundamental terms. ISO/IEC :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 :2001: Software engineering - Product quality - Part 1: Quality model. (Standard will be renamed 25010!) ISO/IEC TR :2003: Software engineering - Product quality - Part 2: External metrics. ISO/IEC TR :2003: Software engineering - Product quality - Part 3: Internal metrics. ISO/IEC TR :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 :1997, Information technology - Software product evaluation - Part 1: General overview. ISO/IEC :, Information technology - Software product evaluation - Part 2: Planning and management. ISO/IEC :, Information technology - Software product evaluation - Part 3: Process for developers. ISO/IEC :, Information technology - Software product evaluation - Part 4: Process for acquirers. ISO/IEC :1997, Information technology - Software product evaluation - Part 5: Process for Evaluators. ISO/IEC :, 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 :, 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, (Parts 1,2)/Issue 1, The Procurement of Safety Critical Software in Defence Equipment. IEC , 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 : 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 , 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, ISO/IEC JTC1 SC7 WebSite: Hans Schaefer Side 28