Software Testing #IRL

Transkript

1 Software Testing #IRL

2 Litt om oss

3 Agenda Software testing: Hvorfor?.. og de 7 magiske prinsipper Smidig testing - testing i team Ytelsestesting: Betyr ingen feil at systemet er OK?

4 Why So'ware Tes.ng? So'ware Tes.ng Principles Exhaus.ve tes.ng is impossible Early Tes.ng Tes.ng shows the Presence of Bugs Defect Clustering The Pes.cide Paradox Tes.ng is Context Dependent Absence of errors fallacy Summary

6 How Other professions in Computer Science sees test Project Lead Developer Customer Architect IT Ops

7

9 Exhaustive testing is impossible

11 Early Testing - Cost of Defect

12 Early Testing: V-Model Requirements Specifica.on Architecture Design Acceptance Test System Test Integra.on Test Unit Test Code

14 Testing shows the presence of bugs, but can not show that there are no defects 1986: Programming Pearls, binarysearch() bevist og testet i et kapittel 1997: Implementert i Sun java.util.arrays.binarysearch() 2006: Feil funnet og fikset i Javabiblioteket

16 Defect Clustering hdp:// in- so'ware- engineering

18 Pesticide Paradox Bugs found per day by a test Age of test

20 Testing is Context Dependent Cost Cost of tes.ng 80-85%? Cost of defects 0% 50% 100% Coverage

21 Quality Attributes: ISO/IEC :2001 Func.onality - sa#sfies needs. Suitability Accuracy Interoperability Security Func.onality Compliance Reliability - maintains opera#on Maturity Fault Tolerance Recoverability Reliability Compliance Usability - effort needed for use Understandability Learnability Operability ADrac.veness Usability Compliance Efficiency - performance given resources Time Behaviour Resource U.lisa.on Efficiency Compliance Maintainability - make modifica#ons Analyzability Changeability Stability Testability Maintainability Compliance Portability - change environment Adaptability Installability Co- Existence Replaceability Portability Compliance

23 Absence of Errors does not mean the System is OK Acceptance Test System Test Performance/Stability Integra.on Test Unit Test 100% hdp://blogg.kantega.no/kodedekningsgrad/

25 Så husk Testing #FTW #YOLO You can t test everything! Testing is Context Dependent! Get involved early! Testing doesn t prove software is without bugs Absence of errors does not prove the system is ok Defects cluster Old tests find fewer bugs

26 Testing i smidige prosjekter En hverdagsbetraktning :30

27 :30 Vannfall

28 Smidig prosjekt Whole team approach Aktiv kundedeltakelse Korte iterasjoner, hyppig leveranse av forretningsverdi Kontinuerlig testing og integrasjon Kontinuerlig forbedring :30

29 Hva er et effektivt team? :30

30 ( Scrum 13:30.me by DamjanBNZ, licenced under CC BY- NC- SA- 2.0)

31 Teamarbeid :30

32 Hva er et effektivt team? A good team will sa#sfy its internal or external clients, become stronger as a unit as #me passes, and foster the learning and growth of its individual members. (J. Richard Hackman) :30

33 Hvordan gjennomføres testing i et smidig prosjekt? :30

34 Testing i et smidig prosjekt MÅL: lage kvalitet, og.l enhver.d ha mest mulig kunnskap om produktet vårt Samarbeid Kontinuerlig og rask feedbackloop fra test Automatisering Vi tester ikke bare sjekker :30

35 En testers «mindset» Hva kan vi gjøre for å bidra til å levere god programvare? Fokus på å forebygge feil. Den tydeligste forskjellen på smidig og tradisjonell testing er rask feedback fra testing. Test driver smidige prosjekter :30

36 Hvordan oppleves det å være tester? :30

37 ( The road to nowhere by sbisson, licenced under CC BY- NC- ND 2.0) :30

38 Playground (with a twist) by Fulla T, licenced under CC BY- NC :30

39 Hva gjør vi, egentlig? :30

40 :30

41 Prototyping Specifica.on by example Sta.sk analyse Kravhåndtering BDD Funksjonell test Integrasjonstest Brukbarhetstes.ng Ikke- funksjonelle tester :30 Kodegjennomgang Exploratory test Automa.sering

42 Funksjonell test Bekrefte forventet oppførsel (basert på spesifikasjonen av produktet) Ulike plattformer, nettlesere, mobile enheter. Test-design teknikker Boundary value analysis Equivalence partitioning Cause - effect graphing Branch testing Decision tables :30

43 Eksempel, equivalence partitioning A bank has different charges depending on the transaction done. 1. 5% of the amount for transaction less than or equal to 1000 bucks 2. 6% of the amount for transaction more than 1000 and less than or equal to 2000 bucks 3. 7% of the amount for transaction more than 2000 bucks (hdp:// Par..oning- And- BVA.php) 13:30

44 Kravhåndtering - kunsten å lage riktig ting BDD, ATDD, Specification by example, Impact mapping (hdp://impactmapping.org/index.php) :30

45 User stories, akseptansekriterier As a <type of user>, I want <some goal> so that <some reason>. User story: As a customer, I want to withdraw cash from an ATM So that I don't have to wait in line at the bank. Akseptansekriteria: Given that the account is creditworthy And the card is valid And the dispenser contains cash, When the customer requests the cash Then ensure the account is debited And ensure cash is dispensed And ensure the card is returned :30

46 Brukbarhetstesting På konsept, prototype eller produkt :30

47 Brukbarhetstesting :30

48 Devicelab (hdp:// :30

49 Automatisering Enhets- og komponenttester Integrasjonstester Business (service)-logikk GUI Tekniske tester (last, stabilitet..) User acceptance test/bdd :30

50 Eksempel, soapui for WS-tester :30

51 Eksempel, Selenium for GUI-tester :30

52 Må vedlikeholdes! :30

53 Exploratory testing simultaneous learning, test design and test execution :30

54 Ikke-funksjonell testing Avbrudd Ytelse Stabilitet Last Sikkerhet :30

55 :30 Holmes! by dynamosquito licenced under CC BY-SA 2.0

56 Ytelsestesting Betyr ingen feil at systemet er OK?

57 Kvalitetsattributter - ISO/IEC :2001 Func.onality - sa#sfies needs. Suitability Accuracy Interoperability Security Func.onality Compliance Reliability - maintains opera#on Maturity Fault Tolerance Recoverability Reliability Compliance Usability - effort needed for use Understandability Learnability Operability ADrac.veness Usability Compliance Efficiency - performance given resources Time Behaviour Resource U.lisa.on Efficiency Compliance Maintainability - make modifica#ons Analyzability Changeability Stability Testability Maintainability Compliance Portability - change environment Adaptability Installability Co- Existence Replaceability Portability Compliance

58

59 Hva er ytelsestesting reliability tes.ng fail over tes.ng scalability tes.ng performance tes.ng load tes.ng stress tes.ng fault tolerance tes.ng efficiency tes.ng capacity tes.ng stability tes.ng peak tes.ng endurance tes.ng benchmark tes.ng volume tes.ng

60 Hva er ytelsestesting reliability tes.ng fail over Vår tes.ng definisjon scalability tes.ng En test der man påfører systemet en viss belastning og ser hva som skjer i gide situasjoner, og da gjerne i forhold.l sludbrukere og i forhold fault tolerance.l ressursbruk tes.ng load tes.ng efficiency tes.ng performance tes.ng stress tes.ng ISTQB capacity tes.ng stability tes.ng The process of tes.ng to determine the performance of a so'ware product peak tes.ng endurance tes.ng benchmark tes.ng volume tes.ng

61 Hvorfor ytelsesteste Gi trygghet for systemeiere og prosjektledere Nedetid koster penger og gir dårlig omtale Typiske spørsmål Er systemet klart for å gå i produksjon Vil oppgradering til ny versjon påvirke ytelsen Hvor mange samtidige brukere kan systemet håndtere? Hvor mange transaksjoner kan systemet håndtere i løpet av en time? Hvor er flaskehalsen i systemet? Hvor mye maskinvare trenger vi? Hva om databasen kræsjer eller en router faller ut? Hvis tjeneste X blir utilgjengelig, påvirker det tjeneste Y?

62 Prosess Få oversikt over testmiljøet: Hva skal testes, hva med eksterne systemer og simulatorer,... Bruksmønster og scenario: Hva er de mest brukte og viktigste funksjonene, hvor ofte brukes de (se prod.data), hvilke funksjoner påvirker ytelsen mest,... Krav og forventninger: Er kravene godt nok spesifisert, hva er ikke definert, når avslutte testing,... Hvilke tester skal kjøres: Håndteres estimert lastpåtrykk, hva er knekkpunkt, håndteres brudd, hva skjer over lengre tid,... Testdata: Finnes det gyldig data å teste med, ingen reelle kunder, datamengde,...

63 Prosess: bruksmønster - finne datagrunnlag Viktige metrikker: Mest brukte funksjonalitet Fordelingen på stiene Tid på hver side 4 min. 55% 25% 6 min. 3 min. 35% 10% 8 min. 3 min.

64 Prosess: bruksmønster - definere script 20% 35% 10% 10% 25% Brukerfordeling: 4 skript representerer 80% Skal flere med? 4 min. 55% 25% 6 min. 3 min. 35% 10% 8 min. 3 min.

65 Prosess: bruksmønster - tekniske risikoer Arkitekturmessige hensyn: 3% fyller inn spørreskjema. Bruk av database og e-post Ønskes med fordi: Påvirker ytelse Får konsekvens ved stress 17% 35% 10% 10% 25% 3%

66 Prosess: simulator iden.fiser HVA som skal testes og hva som IKKE skal testes Like viktig å vite hva som IKKE skal testes Isoler system under test Bedre kontroll Variere responstider fra avhengige baksystemet Eksempel: Nettbanken Hva: selve nettbanken, inkludert «interne» databaser Ikke: Tjenestebussen, Evry, NETS, sikkerhetskjerne (autent./autor.)

67 Prosess: simulator Testdriver / klient System under test Simulator Baksystem Opptak 1. Request til baksystem fanges opp og lagres 2. Respons fra baksystem fanges opp og lagres 3. Endre request-opptak for senere treff

68 Prosess: simulator Testdriver / klient System under test Simulator Avspilling 1. Request som matcher opptak gir tilsvarende respons tilbake 2. Kan legge elementer fra request inn i respons 3. Legge til forsinkelse på respons (fast, fordelinger)

69 Prosess: testdata Data må være gyldig i alle delene av systemet Kan samme testbrukere ha flere parallelle sesjoner Ta hensyn til datagenerering Er testmiljøet produksjonslikt ift datamengde Pass på i forhold til e-post, sms, etc.

70 Hva skal måles Antall feil brukerne opplevde Responstid Hits per sekund og throughput CPU-forbruk Minneforbruk Nettverkstrafikk Håndtering av sockets Diskforbruk Applikasjonskøer Feil i applikasjonslogger

71 Hvordan tolke resultatene Hvorfor er det et knekkpunkt? Hvorfor er knekkpunktet der? Er ressursbruken kontrollert? Hvorfor brukes det så lang tid på en GC? Er det transaksjoner som avviker? Hvorfor? Dårlig ytelse men lav ressursbruk god ytelse men for høy ressursbruk? Er testen produksjonslik? Også mht. bruk av baksystemer? Hvorfor er det forskjellige resultat på to like tester? Avbrudd mot baksystem hvorfor feiler «uavhengige» transaksjoner? 12:01: ,002 12:01: ,018 12:01: ,009 12:01: ,01 12:01: ,02 12:01: ,021 12:01: ,026 12:01: ,02 12:01: ,017 12:01: ,019 12:01: ,021 12:01: ,026 12:01: ,027 12:01: ,023 12:01: ,022 12:01: ,023

72 Vanlige tester Vi bruker normalt de samme script i alle typer tester. Hva som er målet med testen bestemmer type test Kapasitetstest / Knekkpunkts test Gjerne første ordentlige test Avdekker åpenbare feil Lærer systemets oppførsel Stabilitetstest Ca 80% av knekkpunkt Hvordan oppfører systemet seg over tid Ha kontroll med testmiljøet (restarter, disker) Avbruddstest Minst to typer avbrudd (reject, drop) Andre vanlige stresstester Skalering, øke datavolum, fjerne ledig diskplass, lengre responstider fra baksystem

73 Knekkpunktstest Øker antallet brukere for å finne knekkpunkt Respons.d [ms] 1s Throughput [tps] Sam.dige brukere

74 Stabilitetstest - responstid

75 Stabilitetstest - minne

76 Stabilitetstest - programming effects import javax.xml.xpath.*;!! XPathFactory xpfact = XPathFactory.newInstance();! Xpath xp = xpfact.newxpath();!! Node mynode = (Node) xp.evaluate(...);!

77 Stabilitetstest - programming effects import org.w3c.dom.*;!! SoapMessage soapmsg = new SoapMessage();! Element soapel = soapmsg.getsoapheader();!! Node mynode = soapheader.getelementsbytagnamens(...).item(0);!

78 Avbruddstest Som stabilitetstest, men kobler ned og opp baksystemer DROP og REJECT

79 Avbruddstest DROP: ingen svar REJECT: svar

80 Avbruddstest Køing er et avbruddsproblem OSB Proxy Business Baksystem Tjeneste Tradex Nets Evry

81 Lastdriver: JMeter Apache Jmeter en bruker = en Java tråd sette måltall for antall lastpåtrykk open-source grafer scripts