plugg Flashcards
(108 cards)
1
Q
Anledningen till varför man utför test
A
Desto högre konsekvenser ett system genererar desto högre blir behovet för att testa.
2
Q
Varför utför man tester?
A
- identifiera fel och åtgärda
- säkerställa kvalitet
- få fram ett användbart system
verifiera samt validera
3
Q
verfiera
A
- Är systemet rätt byggt? Uppfyller systemet kravspecifikationen?
4
Q
Validera
A
- Är det rätt system vi bygger? Uppfyller systemet kravspecifikationen? Kommer beställaren att bli nöjd?
5
Q
7 stycken principer om test
A
- Test upptäcker fel
- omöjligt att testa ett system fullständigt
- Testa tidigt - minimera chanserna för fel
- Fel hopar sig ofta - Fel leder till andra fel
- Anpassa/variera test
- Test är kontextberoende
- “absense of error” - fallacy
6
Q
Olika typer av fel
A
Aritmetiska fel - beräkningsfel
Interfacing fel - gränsnittsfel
7
Q
Ge exempel på anledningar till varför det kan uppstå buggar.
A
- Tidpress
- komplex kod
- komplex infrastruktur
- attityder emot test
- ignorans
8
Q
Vilka problem kan ett ostrukturerat test innebära?
A
- Trots test så upptäcks få fel
- Viktiga och avgörande fel upptäcks sent
- Test blir “hinder” för att bli klar i tid
- Svårt att kontrollera och övervaka test
- lite användare medverkan
9
Q
V-modellen
A
Innehåller Arbetsflöde, detaljeringsgrad och tid.
- V-modellen är ett sätt för att visa hur kravhantering och systemutveckling hänger ihop.
- Går att tillämpa på små och stora projekt
- Hanteras båda iterativt och sekventiellt
10
Q
Arbetsflöde inom V-modellen
A
Arbetsflöde är flödet mellan verksamhetskrav till acceptanstest som finns ligger högst upp av dimensionerna. Fel som hittas här är fel i användarkrav.
Arbetsflödet i v-modellen består av:
- indelade testnivåer, där varje test nivå har ett syfte
- Varje nivå kan ha en testplan, testaktiviteter och testrapport
11
Q
Detaljeringsgrad inom V-modellen
A
Detaljeringsgrad är flödet mellan systemkrav och systemtest. Fel i systemspecifiktation hittas här.
Detaljeringsgranden består av:
- Få detaljer på övergripande nivå
- Detaljerat längst ned i modellen
- Varje nivå ska ha en testplan
12
Q
Tiden inom V-modellen
A
Tiden är flödet mellan design och integrationstest. Här hittas även design fel.
Tid innebär att:
- test förberedes i den vänstra sidan av modellen
- test genomförs i den högra delen av modellen
13
Q
Grundläggande testnivåer
A
Komponenttest - genomförs av utvecklare
Integrationstest (inom systemet) - utförs ofta av utvecklare
Systemtest (helheten) - genomförs av både testare och systemtestare
Acceptanstest - Genomför av användare med uppdrag av beställare
14
Q
Roller inom test
A
- Beställare (kund eller utvecklingföretag)
- Testare
- testledare
- utvecklare
15
Q
Systemutvecklingmetoder
A
Vattenfall, RUP (rational unified process), Scrum, XP (extreme programming)
16
Q
Vattenfallsmodellen
A
- Jobbar sekventiellt
Fördelar: Tydlig struktur för arbetsuppgifter och tid. Bra för stora projekt
Nackdelar: I början på ett stort projekt kan kravspecifikationen vara ofullständig.
Man försöker tidigt gå in på detaljer.
Det går ej att gå tillbaka i processen och göra förändringar.
Hög kostnad!
17
Q
RUP (rational unified process)
A
- Bryter upp större system i delsystem som sen testas.
- Har en statisk del som testar ett system utan att exekvera koden sedan så finns det en dynamisk del där man exekverar för att hitta fel.
18
Q
Testdisciplin inom RUP
A
- Iterativ process
- Skalbar, går att lägga in och ta bort saker (skräddarsy)
- Flexibilitet
- En riskbaserad process
19
Q
Disciplin Test
A
- Fokus på att utvärdera kvalitet genom att:
- Definiera mål
- skapa en generell uppfattning om system
- Visa att antaganden i kravspecifikation håller
- Utvärdera funktionerna
- Säkerställa att kraven att uppnåtts
20
Q
XP (extreme programmering)
A
- Bygger på användarberättelser (user stories) som beskriver kravspecifikationen.
- Refaktuering - rensar koden och tar bort dubbleringar och gör koden mer komplex.
- Par programmering (diskutera lösningar)
21
Q
Vad ingår i ett agilt test?
A
- test utförs tidigt
- Hantering av förändringar, placerar dom i product backlog
- Hantera tunna “krav”, användarberättelser
- testa ofta
- testa snabbt
22
Q
Typiska fel gällande kraven och dess konsekvenser
A
Fel:
- kraven reflekterar ej det riktiga systemet
- krav är inkonsekventa
- missförstånd mellan kund och kravhanterare
- Addering av ej planerade förändringar
Konsekvenser:
- Kunder använder ej programmet
- systemet blir opålitligt
23
Q
Olika typer av krav
A
- Funktionella krav
- Icke funktionella krav, har med prestanda att göra
- Normala krav
- Förväntade krav, gamla krav som kunden tror är självklara
- Sensationella krav, leverantören levererar krav som ej efterfrågas.
24
Q
Vilka delar ingår i kravhanterings processen - Stjärnan?
A
- Samla in krav
- Strukturera
- Prioritera
- Dokumentera
- Kvalitetssäkra
- Förvalta
25
Samla in krav - Stjärnan
Utför intervjuer, krav workshopar, prototypbyggande, scenarier, brainstorming -- Olika insamlingsmetoder hittar olika sorters krav
26
strukturera krav - stjärnan
Ska en tydlig struktur som går enkelt att överblicka och förvalta
27
Prioritera krav - stjärnan
Fokus på de viktigaste kraven så att låg prioriterade krav ej ändrar resultatet i slutändan. ( om man inte skulle hinna med dem)
28
Dokumentera krav - stjärnan
Dokumentera krav med kravspecifikation. Bör innehålla funktionella och icke-funktionella krav och krav på använda gränssnitt.
För lite dokumentation ledder till osäkerhet.
För mycket dokumentation är svårt att förvalta och hitta luckor.
29
Kvalitetssäkra krav - Stjänan
Se till att det finns så få fel som möjligt
30
Förvalta krav - stjärnan
* Konfigurationshantering, Alla inblandade måste veta vilka krav som är aktuella
* Förändringshantering, Rutiner för då kraven ändras
* Påverkansanalys vid förändringar, Spårbarhetsmatris
31
Spårbarhetsmatris
Gör det möjligt att se konsekvenserna av förändringar. (Ett viktigt krav som ändras kan leda till ändrade testfall och flera nya fel)
- Sambandet kan visa om det finns testfall för samtliga krav och kan illustreras med hjälp av exel.
32
Två bent inom kravhantering och test
Att vara två bent innebär att man har kompetens inom bägge områden.
33
Spårbarhet används till att
- kontrollera att systemet uppfyller alla krav
- systemet gör det som ska göras
- Hjälpa till vid förändringshantering
34
Två typer av statisk testning (testa kod utan att exekvera den)
Statisk analys och Granskning
35
Statisk analys
Tittar på koden utan att exekverar. Leta efter död kod vilket är kod som aldrig körs. Man letar även efter kompileringsfel.
36
Granskning
Målet med granskning är att allt ska granskas innan exekvering.
Granskning är:
- Kostnadseffektivt, problemförebyggande
- Involverar projekt medlemmarna tidigt
Målet är: verifiering, validering konsensus (alla får samma förståelse)
37
Informell granskning
- Snabb
- inga fasta rutiner
- odokumenterat
- billigt
och används vid tidbrist eller vid oviktig dokumentation.
38
Formel granskning
Används vid stora projekt och innehåller genomgång, teknisk granskning samt inspektion.
39
Genomgång i Formel granskning
- Författaren förklarar sina tankar om genomgången
| - Gå ut på att ge konsensus, gemensam bild om vad man vill göra.
40
Teknisk granskning i Formel granskning
- Genomförs av experter
| - Hittar tekniska lösningar och fel
41
Inspektion i Formel granskning
- Roller som moderator, författare, granskare, chef (money), inspektionschef
- Man har ett start/slut mål
Falgropar:
- Brist på utbildning --- man vet ej vilka rutiner som finns
- Att vara dålig på att dokumentera
- Brist på stöd från ledningen(tid och resurser)
42
Metoder för att mäta Organisationers testmognad
TPI - Test process improvments
| CMM - Capability Maturity Model
43
Vad ingår i CMM?
1. Initial - oförutsägbar, kostar mycket pengar, försenat
• 2. Repeterbar - Väl planerade projekt
• 3. Definierad - Inger rådgivning för projekt
• 4. Styrd - Mättningar görs för att nå kraven
• 5. Optimerad - Ger förutsättningar för att hantera förändringar.
44
Ansvarsfördelning
Samtliga utvecklare - Komponent test
En utsedd utvecklare - Integrationstest
Testare - Systemtest
Användare - Acceptanstest
45
Komponent test
Testast oftas via kod för test som möjliggör automatisering.
46
Test Driven utveckling
Red - Green - Refactor
47
Red - Green - Refactor
1. Skapa tester som skall misslyckas.
2. Skriver kod till systemet fungerar.
3. Förfinar koden.
48
Integrationstest
Testar integrationen av komponenterna inom ett system.
49
Strategier för integration.
- Big Bang , Bygger systemet till fullo sen testas det.
| - Stegvis, Lättare att avgöra vart felet existerar
50
Systemtest
Testar det kompletta systemet med Funktionella test, icke funktionella test (prestanda test, stresstest), konfigurationstest
51
Acceptanstest
Utförs av användarna i syfta för att se om systemet kan sättas i bruk. Testas i from av scenarior.
52
Testdesigntekniker
Statiska testdesigntekniker - programmet körs ej bara dokumentation och gränssnitt testas.
Dynamiska testdesigntekniker - Systemet är igång under testning, testfall används ofta.
Utforskande testteknik - Testar nya saker för kunna utföra förbättringar.
53
Black Box testing
Görs när de interna strukturerna och processerna är okända.
```
ingår:
positiva tester
negativa tester
extremtester
gränsvärde analys
Flödestester
såpoperatester
säkerhetstester
```
54
Positiva tester
Giltiga värden används som testdata.
| Bedömer om systemet fungerar som det skall vid normal användning
55
Negativa tester
Testar systemet felhantering.
56
Extremtester
Testar för att förstöra systemet.
57
Gränsvärdeanalys
Utförs när testen visar fel värden.
58
Flödes tester på webbaserade system
Tester vanligt flöde, finns inget påtvingat flöde för användarna.
59
Såpoeratester
Syftar till att testa systemet med händelser som inte redan ha testas.
60
White box test
Syftet med White box test är att testa varje enskild aspekt av komponenten.
```
Ingår:
Kodtäckningsanalys
Kodsatstestning
kodgranstestning
Looptestning
Villkortestning
```
61
Kodtäckningsanalys - Whitebox
Säkerställer att så många möjliga kod rader exekveras under körning, datan mäts i procent
62
Kodgrenstesning - Whitebox
Testar alla möjliga beslutsvägar i programmet.
63
Looptestning - Whitebox
Testar systemets loopar. Väljer testdata så att varje loop hoppas över helt.
64
Villkorstestning - Whitebox
Testar så att samtliga kodgrenar och loopar körs som ger olika vägar i programmet.
65
Säkerhetstest - Whitebox
Testar emot kända hot och mot arbetar dem.
| Ställer frågor som vart hotet kan komma ifrån, människa eller teknik?
66
Black Box nackdel
Kan finnas oändligt många testvärden som krävs för att hitta felet.
67
White Box nackdel
Nackdel svår att hitta om kravspecifikation saknas.
68
Vad ingår i Testprocessen?
- Planering
- Genomförande
- Uppföljning
69
Vad gör man i Planering för testprocessen?
* Definierar syftet med testet/testerna
* Identifierar testområden (start/slut kriterier)
* Granskar kravdokument
* Bedömer risker
* Skapar testunderlag (testdokument)
* Säkrar resurser
70
Vad gör man i genomförande i testprocessen?
* Följer testplanen
* Använder underlagen från planeringen
* Rapporterar
* Testar och testar igen
71
Vad gör i uppföljningen av testprocessen?
* Sammanfattar
* Utvärderar
* Samlar erfarenheter
72
Varför skall man planera?
Man planerar för att skapa förståelse och en överblick för det arbete som ska utföras. Det ingår även att man skapar ett underlag för att avsätta resurser och fördela ansvar i arbetet.
73
Aktiviteter under testplaneringen.
* Identifiera avgränsning, risker och mål för test
* Planera roller, ansvar och resurssäkring
* Schemalägg (scheduling)
* Fastställ mätetal, start/stopp kriterier, testnivåer
* Integrera testaktiviteter i utvecklingslivscykeln
74
Aktiviteter i en riskplanering.
- Identifiera risker, Görs bäst i grupp
- Analysera/värdera risker, Sannolikhet att risk inträffar ,Konsekvens om risk inträffar
- Dokumentera resultatet,Risklista
- Planera för åtgärder, Handlingsplan
75
Riskmatris
En visualisering som visar sannolikheten för konsekvensen för att en risk ska inträffa.
76
Olika typer av risker
Tekniska
| Projektorganisatoriska risker
77
Olika tekniker för att uppskatta tid
Lichtenbergmetoden, statisk uppskattning av förväntat värde
| Och användning av MS projekt (Gantt schema)
78
Fyra regler för tidsuppskattning
Tiduppskatta i team
ansvarig ha sista ordet
observera
Mer information
79
Start kriterier
Kriterier som ska vara uppfyllda för att inleda testerna.
80
Slutkriterier
Kriterier som ska vara uppfyllda för att avsluta testerna.
81
Avbrytande kriterier
Kriterier för att avbryta testerna på ett onormalt sätt.
82
Återupptagande kriterier
Kriterier för att börja testa igen.
83
Vad är Testunderlag för något?
Samlig dokument som behövs för själva testutförandet. I testunderlag ingår även testfall.
84
Testfall
Testfall är en uppsättning villkor under vilka en testare kan avgöra om ett systems funktioner fungerar som det är tänkt.
85
Vanliga rubriker för ett testfall
- ID, Identitet som undviker korsreferenser till andra dokument.
- Rubrik, Skall vara beskrivande
- Förbredelser, Aktiviteter som måste utföras innan testerna kan genomföras.
- Teststeg, Beskriver hur ett test skall genomföras
- Förväntat resultat, Används för att bedöma och ett test är lyckat.
- Återställning, Motsatts till förberedelser
- Testdata, Syftar till att göra testerna upprepningsbara
- Prioritet, Anger hur viktigt testet är
- Kravreferens, Refererar till de krav testfallet berör
- Version, 1.0,1.1 osv
- Författare, Han/hon som skrivit testfallet
- Typ av testfall, Beskriver om det är stresstest osv
- Konfiguration, Krav på en speciell konfiguration
86
Testspecifikation
Är ett dokument som håller ihop testfallen med följande rubriker, Inledning, testdata, förberedelser, Testfall
87
Testfall under lupp
Fördelar:
- strukturerat
- Bra grund för felrapporter
- Bra grund för automatisering
Nackdelar:
- Blir snabbt omfattande
- Kan bli svårt att få en överblick om testfallen är många.
88
Alternativ till testfall
Ad-hoc testning, Testar utan stöd av något underlag
| Checklistor, I tabellform och är en bra kompromiss vid tidbrist.
89
När används vilka testunderlag?
- Komponenttester och integrationstester:
Checklistor, ad-hoc tester
- Systemtester och acceptanstester:
Testfall, Utforskande tester
90
Utforskande tester
Testar alla funktioner baserat på testarens kunskap.
Bra vid:
Bristfälliga krav
Tidsbrist
Nackdel:
Svårt att granska testerna i förväg
91
Testschema
Om testerna är beroende av att köras i sekvens används testschema.
92
TestLogg
Anteckningar som för dag för dag under testningen.
93
Typiskt flöde i genomförandet
1. Testare upptäcker fel, skriver felrapport och skickar till testledare.
2. Utvecklare rättar fel
3. Testare genomför omtest som skall genomföras av den person som rapporterat felet.
94
Rubriker i en felrapport
* ID
* Rubrik
* Felbeskrivning
* Systemdel
* Testobjektets version
* Bilagor
* Testfalls-ID
* Prioritet
* Allvarlighetsgrad
95
Fördelar och nackdelar med testverktyg
Fördelar:
Testning av sånt som ej går att testa utan testverktyg.
Testa mer och snabbare
objektiva bedömningar
Nackdelar:
Verktygen är oftast mycket dyra.
Risker att man förlitar sig för mycket på testverktygen.
Automatisering kan inte bringa ordning i kaos.
96
Olika testverktyg
- Kravhanteringsverktyg, Kan vara en databas som lagrar kraven tex visual studios.
- Hantering av testfall, testfall skriv in i verktyget.
- Testdata, Verktyg för att ta fram testdata vilket kan göras med två olika metoder: kopiering av data från driftmiljö till testmiljö eller med användning av metadata som beskriver hur testdata skall se ut.
97
Statisk analys - testverktyg
Används ofta för att underlätta granskning av programkod. Man kan tex hitta Död kod (kod som aldrig körs), Oändliga slingor (villkor som aldrig kan inträffa), Beräkning av komplexitet (komplex kod som kan kommas testas mer).
98
Dynamisk Analys
Utför när programmet körs. Exempel på test som kan genomföras, Se efter minnesläckage, utföra stress eller prestanda test.
99
Detaljerad testfall vs enradstestfall
Detaljerat testfall är till för att noga berätta vad som eftersträvas av systemet. Medans ett enradstestfall kanske är mer till för erfarna testare som redan vet om vad ska eftersträvas av testerna.
100
Vad kännetecknar ett bra testfall?
- Det har en rimlig sannolikhet för att hitta fel.
- Det är inte överflödigt.
- Det är verken för enkelt eller komplext.
101
En testkedja för testfall
En testkedja kan ses som en röd tråd som knyter fast de testfall som kan köras efter varandra.
102
Ett testpaket för testfall
Alla testfall som behövs köras samtidigt läggs i ett paket.
103
Vad innebär tidig testdesign?
Skriv kraven i form av användarberättelser
• Skriv testfallen samtidigt som kraven skrivs
• Skriv teststrategi för att undvika att upprepa testplanen
gång på gång
104
Uppföljning och avslut av testprocessen
När alla test är genomförda skrivs en testrapport med rubriker som Unik identifiering, inledning, sammanfattning, avvikelser och sammanfattning av resultat och av aktiviteter. Erfarenheter och tillsist godkännande.
105
När avslutas testningen?
Testningen avslutas när stoppkriterierna är uppfyllda.
106
IEEE standard 829
Tillhandahåller dokumentationsmallar som ger struktur för hela testprocessen.
107
Projekt risker
Relaterade till ledning och styrning av projekt eller testprojekt.
Brist på test, kompetens, personal, interna stridigheter, svårigheter att
enas om krav i ett avtal. Tekniska risker. Försenade leveranser.
108
Humanriskar
Handlar om människor som är inblandade i arbetet.
Bristande kompetens, tillgång till nyckelpersoner,
kommunikationsförmåga, personliga egenskaper, etc.
