some changes

tkbremnes · May 18, 2012 · 0a52b6a · 0a52b6a
1 parent a06b2fc
commit 0a52b6a
Show file tree

Hide file tree

Showing 8 changed files with 5,923 additions and 27 deletions.
diff --git a/Forelesning 03/3 - Traceability, Testability.md b/Forelesning 03/3 - Traceability, Testability.md
@@ -193,7 +193,7 @@ Der eksisterer flere automatiserte tilnærminger for sporing av krav. Da de ulik
 
 
 
-# Kravsspesifikasjon og testing
+# 3 - Kravsspesifikasjon og testing
 
 
 

diff --git a/Forelesning 05/5 - Test vs Inspection.md b/Forelesning 05/5 - Test vs Inspection.md
@@ -128,7 +128,7 @@ Det er inspeksjonsleders ansvar at samtlige saker i loggen avhendes på en tilfr
 * Behøver ekstensiv planlegging for å være vellykket
 
 
-# Testprosesser
+# 5.1 - Testprosesser
 
 ## Enhetstester
 Målet med enhetstester er å verifisere at koden fungerer som foreskrevet. Dette gjøres av utvikler én eller flere ganger i løpet av utviklingen. Enhetstesting er en uformell testmetode som utføres ved at en først implementerer (en del av) en komponent. En definerer så en eller flere tester som aktiviserer denne koden. Til sist vil en kontollere resultatet mot de forventninger og nåværende forståelse av komponenten.

diff --git a/Forelesning 06/6.3.md b/Forelesning 06/6.3.md
@@ -60,7 +60,7 @@ Se foiler forelesning 6 for mer eksempler
 
 ![Sensor round-trip path tre](Forelesning 06/img/5.png)
 
-# Mutation testing
+# 6.3 - Mutation testing
 
 ## Type 1
 1. Skriv en kodesnutt

diff --git a/Forelesning 09/9-2.md b/Forelesning 09/9-2.md
@@ -135,7 +135,7 @@ Se foil 9-1 for eksempel på en slik reduksjon.
 
 
 
-# Outsourcing, subcontracting and COTS
+# 9.2 - Outsourcing, subcontracting and COTS
 
 ## Ansvar
 Det er utviklers hele og fulle ansvar for at det produktet som leveres er av en gitt kvalitet. Det er videre kun mulig å få godtgjørelse fra et selskap om en kan bevise kontraktbrudd fra leverandør sin side. Det er derfor viktig å kunne bygge opp tillit ved å teste tilstrekkelig. Dette er selvfølgelig svært viktig ved bruk av COTS.

diff --git a/Forelesning 10/10.1.md b/Forelesning 10/10.1.md
@@ -1,5 +1,5 @@
 # 10.1 - Domenetesting
-Mye feil, må derfor kontrolleres nøye.
+Domenetesting er en simpel strategi for å velge testcaser. Av erfaring ser tester at det er grenseverdier som bidrar til mye feil, å bør Derfor kontrolleres nøye.
 
 ## Predikater
 Antar at alle predikater er enkle. Dette innebærer at de bare inneholder en relasjonsoperator. Tillate operatorer er =, <>, >=, <=, < og >.

diff --git a/Forelesning 10/10.2.md b/Forelesning 10/10.2.md
@@ -1,7 +1,8 @@
 # 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????)
+2. Anvend hele input-settet til System Usebility Testing
 
 ## Chens observasjon
 * Input som ligger nær hverandre i inputdomenet har en tendens til å gå gjennom den samme stien. For å finne de fleste feil, bør man derfor spre test casene så mye som mulig.