Kapittelnummerering

tkbremnes · May 18, 2012 · 68483de · 68483de
1 parent 4c5f160
commit 68483de
Show file tree

Hide file tree

Showing 23 changed files with 24 additions and 22 deletions.
diff --git a/Forelesning 02/2.1-2.md b/Forelesning 02/2.1-2.md
@@ -1,4 +1,4 @@
-# Intro
+# 2.1 - Intro
 
 ## Traceability
 

diff --git a/Forelesning 02/2.3.md b/Forelesning 02/2.3.md
@@ -1,4 +1,4 @@
-# Guidet naturlig språk (GNL) og Boilerplates (BP)
+# 2.3 - Guidet naturlig språk (GNL) og Boilerplates (BP)
 
 Tre nivåer av krav: 
 

diff --git a/Forelesning 03/3 - Traceability, Testability.md b/Forelesning 03/3 - Traceability, Testability.md
@@ -1,4 +1,4 @@
-# Sporbarhet av krav
+# 3 - Sporbarhet av krav
 Sporbarhet av krav er av Gotel og Finkelstein definert som: 
 
 > "[…] the ability to describe and follow the life of a requirement, _in both a forwards and backwards direction_, i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through periods of on-going refinement and iteration in any of the phases."

diff --git a/Forelesning 05/5 - Test vs Inspection.md b/Forelesning 05/5 - Test vs Inspection.md
@@ -1,4 +1,4 @@
-# Test vs. inspection
+# 5.1 - Test vs. inspection
 
 Noen defekter er viktige ettersom de oppstår ofte. De fleste defekter er derimot mindre viktige, da de oppstår sjeldent. Problemet er å skille disse to tilfellene fra hverandre. Hvordan gjør en det mest effektivt og så nøyaktig som mulig?
 

diff --git a/Forelesning 05/5 2.md b/Forelesning 05/5 2.md
@@ -1,4 +1,4 @@
-# Testing og inspeksjon – en kort dataanalyse
+# 5.2 - Testing og inspeksjon – en kort dataanalyse
 
 ## Testing og inspeksjon - noen termer
 

diff --git a/Forelesning 05/5.3.md b/Forelesning 05/5.3.md
@@ -1,4 +1,4 @@
-# Testing og kost/nytte
+# 5.3 - Testing og kost/nytte
 For de fleste programvaresystemer vil antallet mulige input være store. På et tidspunkt vil en nå et punkt hvor en ny test vil koste så mye å implementere at nytten en får ut av den ikke er stor nok for at den er verd det. En bør med andre ord stoppe når _kostnaden er større enn forventet nytte_ av neste test. Dette er en subjektiv prosess.
 
 Som et minimum må en inkludere kostnader rundt det å utvikle og kjøre tester, samt kostnader tilkoblet til det å korrigere feil basert på resultatene. I tillegg er det mulig å inkludere kostnader rundt det å engasjere mennesker som kunne ha vært engasjert i andre, mer lønnsome aktiviteter. Misfornøyde kunder kunder kan og representere en kostnad.

diff --git a/Forelesning 06/6.1.md b/Forelesning 06/6.1.md
@@ -1,4 +1,4 @@
-# Teststrategi
+# 6.1 - Teststrategi
 En teststrategis formål er å hjelpe system- og programvaretestere, samt "Test-and-Evaluation"-personale med å bestemme overordnet teststrategi når en skal utvikle eller modifisere programvareintensive system. En vil og assistere projektets interessenter – kunder og seniorledelse – med å godkjenne teststrategien. Testere og system- og programvareanalyse vil få hjelp til å fastslå målsetninger med testen, kvalifikasjonskrav, samt verifikasjon- og valideringskriterier.
 
 Nøkkelkonsepter:

diff --git a/Forelesning 06/6.2 - Whitebox & Blackbox.md b/Forelesning 06/6.2 - Whitebox & Blackbox.md
@@ -1,4 +1,4 @@
-# White box Black box Gray box
+# 6.2 - White box Black box Gray box
 
 
 ## White box testing

diff --git a/Forelesning 06/6.3.md b/Forelesning 06/6.3.md
@@ -1,4 +1,4 @@
-# Grey box testing
+# 6.3 - Grey box testing
 Testing med begrenset kunnskap av de interne delene i systemet. Med tilgang til detaljerte designdokumenter ut over kravsspesifikasjoner. Tester genereres basert på informasjon som tilstandsbaserte modeller eller systemets arkitekturdiagrammer.
 
 ## Tilstandsbasert testing

diff --git a/Forelesning 08/8.1.md b/Forelesning 08/8.1.md
@@ -1,4 +1,4 @@
-# Test-prioritering
+# 8.1 - Test-prioritering
 Selv om der er mange måter å prioritere tester på vil dette kurset fokusere mest på _risikobasert prioritering_. Nøkkelord er: _risikovurdering_ (assessment) og _prioriteringsmekanismer_.
 
 Riskikobasert testing er ikke et nytt fenomen, risikovurdering har blitt brukt lenge av selskaper som utvikler programvare. Dette har dog skjedd på en ustrukturert måte, uten nødvendig dokumentasjon. Vi behøver systematiske metoder for å best kunne håndtere denne risikoanalysen og utføre risikobasert testing.

diff --git a/Forelesning 08/8.2.md b/Forelesning 08/8.2.md
@@ -1,4 +1,4 @@
-# Kravshåndtering
+# 8.2 - Kravshåndtering
 
 Egenskaper i en effektiv Requirements Engineering (RE) prosess
 	1. Minimere forekomst av feil i krav

diff --git a/Forelesning 09/9-1 Outsourcing, subcontracting COTS.md b/Forelesning 09/9-1 Outsourcing, subcontracting COTS.md
@@ -1,3 +1,5 @@
+# 9.1 Outsourcing, subcontracting, COTS
+
 ## Ansvar
 Viktig å tenke på:
 

diff --git a/Forelesning 09/9 - COTS.md → Forelesning 09/9-2.md b/Forelesning 09/9 - COTS.md → Forelesning 09/9-2.md
@@ -1,4 +1,4 @@
-# COTS-testing
+# 9.2 - COTS-testing
 
 Ofte brukte tilnærminger til testing av COTS:
 

diff --git a/Forelesning 10/10.1.md b/Forelesning 10/10.1.md
@@ -1,4 +1,4 @@
-# Domenetesting
+# 10.1 - Domenetesting
 Mye feil, må derfor kontrolleres nøye.
 
 ## Predikater

diff --git a/Forelesning 10/10.2.md b/Forelesning 10/10.2.md
@@ -1,4 +1,4 @@
-# Random testing
+# 10.2 - Random testing
 Beskrives som følger:
 1. For hvert input parameter, generer en randomisert, men lovlig verdi.
 2. Anvend hele input-settet til SUT (whaaaat????)

diff --git a/Forelesning 10/10.3.md b/Forelesning 10/10.3.md
@@ -1,4 +1,4 @@
-# Testdekning
+# 10.3 - Testdekning
 
 ## Hva er testdekning?
 La c være enten krav eller statements, da får vi at `C = (enheter testet) / (antall enheter)`. Testdekning er altså andelen testede enheter blandt alle enheter.

diff --git a/Forelesning 11/11.1.md b/Forelesning 11/11.1.md
@@ -1,4 +1,4 @@
-# Smidige krav gjennom brukerhistorier og -scenarioer
+# 11.2 - Smidige krav gjennom brukerhistorier og -scenarioer
 
 
 Hovedprinsippene bak smidige krav er:

diff --git a/Forelesning 11/11.2.md b/Forelesning 11/11.2.md
@@ -1,4 +1,4 @@
-# Advanced Use cases
+# 11.2 - Advanced Use cases
 
 
 Aktør

diff --git a/Forelesning 12/12.1.md b/Forelesning 12/12.1.md
@@ -1,4 +1,4 @@
-# Testdrevet utvikling
+# 12.1 - Testdrevet utvikling
 Fra et TDD-ståsted er det urimelig å separere testing og implementasjon. Når en implementasjonsstrategi er bestemt, har en og indirekte valgt en teststrategi.
 
 TDD oppfordrer til å skrive tydelige krav.

diff --git a/Forelesning 15/15.1.md b/Forelesning 15/15.1.md
@@ -1,4 +1,4 @@
-# Regresjonstesting
+# 15.1 - Regresjonstesting
 Regresjonstesting er testing gjort for å kontrollere at en systemoppdatering ikke reintroduserer feil som har blitt fikset tidligere. Dette gjøres via black-box-testing (for å teste funksjonalitet) og grey-box-testing (for å teste arktitekturen).
 
 Ettersom regresjonstester er ment å teste all funksjonalitet og alle forandringer, vil slike tester være store. Av den grunn må regresjonstesting eksekveres og kontrolleres automatisk.

diff --git a/Forelesning 15/15.2.md b/Forelesning 15/15.2.md
@@ -1,4 +1,4 @@
-# Firewall for regresjonstesting
+# 15.2 - Firewall for regresjonstesting
 Her brukes konseptet om en firewall for å redusere settet klasser eller komponenter som behøves testes. Dette da de fleste regresjonsteseter er store og tidkrevende.
 
 En firewall i denne sammenhengen er en separator mellom de klasser som beror på en klasse som endres fra resten.

diff --git a/Forelesning 15/15.3.md b/Forelesning 15/15.3.md
@@ -1,4 +1,4 @@
-# Ikke-funksjonelle krav
+# 15.3 - Ikke-funksjonelle krav
 
 Standardisert i ISO-9126 (og mange andre steder) – en _faktor-kriterie-metrikk-_modell. Nært koblet til "quality in use" – dvs. brukernes erfaring av systemet i bruk. Brukernes erfaringer er subjektive og derfor vil og kvalitetsfaktorer være subjektive.
 

diff --git a/Forelesning 15/15.4.md b/Forelesning 15/15.4.md
@@ -1,4 +1,4 @@
-# Scenario testing
+# 15.4 - Scenario testing
 
 Der finnes to typer scenariotesting, _type 1_ hvor scenarioer benyttes for å definere input/output-sekvenser, og _type 2_ hvor scenarioer brukes som et skript for sekvenser realistiske handlinger i ekte eller simulerte omgivelser.