---
# System prepended metadata

title: ITST

---

# ITST

## College 9 - Black box testing I

### Decision tables

Een decision table is een precieze en compacte manier om moeilijke logica te modelleren. Talen maken hier (meestal) gebruik van met if statements:
```javascript=
if (condition){}
else if (condition){}
else{}
```

Standaard decision table
![](https://i.imgur.com/gRUebDm.png)

Onderstaand kunnen worden samengevoegd, mits deze dezelfde output hebben, waarbij de variable (in dit geval de bovenste) een `-` krijgt.
![](https://i.imgur.com/DAGoYfh.png)

### Equivalence class Partitioning

#### Boundary testing
Grenstesten is het proces van testen tussen extreme uiteinden of grenzen tussen partities van de invoerwaarden.

Dus deze extreme uiteinden zoals Start-End, Lower-Upper, Maximum-Minimum, Just Inside-Just Outside-waarden worden grenswaarden genoemd en het testen wordt "grenstesten" genoemd. Het basisidee bij het testen van grenswaarden is het selecteren van waarden voor invoervariabelen op hun:
* Minimum
* Net boven het minimum
* Een nominale waarde
* Net onder het maximum
* Maximaal
![](https://i.imgur.com/Xa7H87n.png)

#### Equivalence class Partitioning

Equivalent Class Partitioning is een black-boxtechniek (code is niet zichtbaar voor tester) die kan worden toegepast op alle testniveaus, zoals unit, integratie, systeem, enz. In deze techniek verdeelt u de set testvoorwaarde in een partitie die hetzelfde worden beschouwd.

* Het verdeelt de invoergegevens van software in verschillende klassen van equivalentie data.
* U kunt deze techniek toepassen, waarbij er een bereik in het invoerveld is.

##### Voorbeeld:

* Laten we het gedrag van Bestel Pizza Tekstvak hieronder eens bekijken
* Pizza-waarden 1 tot 10 worden als geldig beschouwd. Een succesbericht wordt getoond.
* Terwijl de waarde 11 tot 99 als ongeldig wordt beschouwd voor de bestelling en een foutmelding verschijnt, kan "slechts 10 pizza's worden besteld"


Hier zijn de testvoorwaarde

1. Elk getal groter dan 10 dat is ingevoerd in het veld Pizza bestellen (zeg 11), wordt als ongeldig beschouwd.
2. Elk getal kleiner dan 1 dat 0 of lager is, wordt vervolgens als ongeldig beschouwd.
3. Nummers 1 tot 10 worden als geldig beschouwd
4. Elk 3-cijferig getal bijv. -100 is ongeldig


We kunnen niet alle mogelijke waarden testen, want als dit is gebeurd, is het aantal testgevallen meer dan 100. Om dit probleem aan te pakken, gebruiken we Equivalence artitioning hypothese waarbij we de mogelijke waarden van tickets in groepen of sets verdelen zoals hieronder wordt getoond, waar het systeem gedrag kan als hetzelfde worden beschouwd.

![](https://i.imgur.com/eKwiFVi.png)


De verdeelde sets worden **Equivalence Partitions** of **Equivalence Classes** genoemd. Vervolgens kiezen we slechts één waarde uit elke partitie om te testen. **De hypothese achter deze techniek is dat als een voorwaarde / waarde in een partitie slaagt, alle andere ook zullen passeren. Evenzo, als een voorwaarde in een partitie mislukt, mislukken alle andere voorwaarden in die partitie.**

![](https://i.imgur.com/AEUvrRI.png)

#### Voorbeeld 2:

Het volgende wachtwoordveld accepteert minimum 6 tekens en maximaal 10 tekens.

Dat betekent dat resultaten voor waarden in partities 0-5, 6-10, 11-14 gelijkwaardig moeten zijn.

| Test Scenario # | Test Scenario Beschrijving | Verwachte output |
| -------- | -------- | -------- |
| 1    | Voer 0 tot 5 characters in het wachtwoord veld in   | Systeem accepteert het **niet**     |
| 2     | Voer 6 tot 10 characters in het wachtwoord veld in     | Systeem accepteert **wel**     |
| 3    | Voer 11 tot 14 characters in het wachtwoord veld in     | Systeem accepteert **niet**     |

**Boundary test waardes bij een input die 1 tot 10 accepteerd**:



| Test scenario beschrijving | Verwachte output |
| -------- | -------- |
| Boundary value = 0    | **niet**     |
| Boundary value = 1      | **wel**     |
| Boundary value = 2     | **wel**     |
| Boundary value = 9     | **wel**     |
| Boundary value = 10      | **wel**    |
| Boundary value = 11     | **niet**     |



### Boundary Value Analyses

Wordt ookwel **range checking** genoemd.
![](https://i.imgur.com/6QOIH35.png)

### State transition

Hieronder een basic state transition diagram (**State chart** of **State graph**):

![](https://i.imgur.com/GIwNwBY.png)

Bij zo een soort diagram is het goed te kijken naar wat de 'belangrijke routes' zijn van je applicatie. Dit omdat je deze goed moet testen, en zijn belangrijker dan de andere routes. De belangrijke routes zijn hier weergegeven in het rood.

In de hierboven weergegeven chart zijn er **vier componenten** mogelijk:

1. De state van de software (bijv. Start)
2. DE transitie van de ene naar de andere state (de pijlen)
3. Events die de transitie triggeren (bijv. de tekst boven de Start state)
4. Acties van events (bijv. Close Application)

Een **state table** wordt gebruikt om valide en invalide transities weer te geven.



| State | Correct Password | Incorrect password |
| -------- | -------- | -------- |
| 1. Start    | 6     | 2     |
| 2. 1st try    | 6     | 3     |
| 3. 2nd try    | 6     | 4     |
| 4. 3rd try    | 6     | 5     |
| 5. 4th try    | 6     | 7     |
| 6. Access    | ?     | ?     |
| 7. Close Application    | -     | -     |

Wat gebeurd er als er al iemand is ingelogd en die probeert het in een andere tab nogmaals? Dit kan getest worden en is een 'invalde transitie'.

## College 10 - Black box testing II

Zie DLO opdrachten

## College 11 - Static testing

???

## College 12 - White box testing

### Video: https://www.youtube.com/watch?v=wLINA-Gj7eA
Als je de structuur van het programma weet, kan je verzekeren dat er een bepaalde coverage is van;

* Statements
* Branches
* Paths
* Conditions

White box testing geeft niet weer of het programma doet wat het moet doen volgens de project requirements, maar wat het programma moet doen volgens de programmeur.

![](https://i.imgur.com/3X6sUXc.png)

* Statement coverage
    * De ruitjes in diagram hierboven
    * Hoeveel van de statements doorloop ik? (%)
    * Goed kijken naar branch coverage
* Branch coverage
    * Lijnen in diagram hierboven
    * Hoeveel van de branches doorloop ik? (%) 
* Condition coverage
    * Hoeveel verschillende condities doorloop ik? (%)

![](https://i.imgur.com/OZZt7Pc.png)
*:thumbsdown:*

![](https://i.imgur.com/xaHmOn9.png)
*:thumbsup:*

^^ Beiden hebben een condition coverage van 100%?

### Video condition: https://www.youtube.com/watch?v=ZnPmJd5aqyw

Hoeveel conditions doorloop ik 
**Test requirements**: De individuele condities van het programma
**Coverage measure**: number of conditions both T and F / total number of conditions (predicate != condition)

![](https://i.imgur.com/zCnRni4.png)

### Video statement: https://www.youtube.com/watch?v=9PSrhH2gtkU

**Test requirements**: Statements in het programma (aka regels)
**Coverage measure**: number of executed statements / total number of statements

![](https://i.imgur.com/EC16UZr.png)

### Video branch: https://www.youtube.com/watch?v=JkJFxPy08rk

**Test requirements**: Branches in het programma (uitgaande edges van een desicision punt)
**Coverage measure**: number of branches executed / total number of branches 

![](https://i.imgur.com/fOv6p2n.png)

Er geldt ook; **Branch coverage > statement coverage**. Het is ook meer 'kostbaar' om branch coverage te bereiken dan statement coverage.