Softwarequalitätsmanagement: Unterschied zwischen den Versionen

Aus CCWiki
Zur Navigation springen Zur Suche springen
Zeile 73: Zeile 73:
== Teststufen ==
== Teststufen ==
Testing kann in verschiedene Stufen unterteilt werden, die im folgenden Angeführt werden. Im folgenden von '''fein''' bis '''grob''':
Testing kann in verschiedene Stufen unterteilt werden, die im folgenden Angeführt werden. Im folgenden von '''fein''' bis '''grob''':
=== Unit Test ===
==== Unit Test ====
Beschreibt das Testen auf Modul- oder Komponentenebene. Hierbei sollen abgrenzbare Teile eines Programmes getestet werden. Ein einfaches Beispiel dafür wäre das Testen von {{AL|Methode|Methoden}} einer {{AL|Klasse}}.
Beschreibt das Testen auf Modul- oder Komponentenebene. Hierbei sollen abgrenzbare Teile eines Programmes getestet werden. Ein einfaches Beispiel dafür wäre das Testen von {{AL|Methode|Methoden}} einer {{AL|Klasse}}.


=== Integration Test ===
==== Integration Test ====
Beim '''Integrations Test''' wird das zusammenspiel unterschiedlicher Komponenten miteinander getestet.
Beim '''Integrations Test''' wird das zusammenspiel unterschiedlicher Komponenten miteinander getestet.


=== System Test ===
==== System Test ====
Beim '''System Test''' wird das gesamte System gegen alle Anforderungen getestet. Beim Test soll die Produktivumgebung des Kunden simuliert werden.
Beim '''System Test''' wird das gesamte System gegen alle Anforderungen getestet. Beim Test soll die Produktivumgebung des Kunden simuliert werden.


=== Abnahme Test ===
==== Abnahme Test ====
Der '''Abnahme Test''' ist das testen des gesamten Systems durch den Kunden.
Der '''Abnahme Test''' ist das testen des gesamten Systems durch den Kunden.



Version vom 2. Februar 2021, 17:47 Uhr

Testing

Softwaretesting beschreibt den Prozess des verifizierens einer Anwendung, oder Teile davon, gegenüber einer gewissen Spezifikation, oder gegen ein erwartetes Verhalten. Durch Testing kann ein hohes Maß an Softwarequalität gewährleistet werden, natürlich nur wenn Tests gut spezifiert und auch ausgeführt werden. Gerade im Bereich des automatisierten Testens kann durch eine hohe Testabdeckung des Quellcodes, Regression, verhindert werden.

Eine hohe Testabdeckung, beschreibt, wieviel Code durch Testfälle auch wirklich erreicht wird. Werden alle Verzweigungen in Methoden erreicht? Werden überhaubt alle Methoden getestet?
Unter Regression wird eine Verschlechterung des Quellcodes verstanden. Im Laufe des Entwicklungsprozesses funktioniert Code, der zuvor funktionert hat, auf einmal nicht mehr.

Anhand von folgendem Beispiel soll die Testabdeckung einer Java Klasse mit dem Testframework JUnit veranschaulicht werden:

public class DateUtils {
  public String getDayOfWeekName(int month) {
    if(month == 1) {
      return "Montag";
    } else if(month == 2) {
      return "Dienstag";
    } else if(month == 3) {
      return "Mittwoch";
    } else if(month == 4) {
      return "Donnerstag";
    } else if(month == 5) {
      return "Freitag";
    } else if(month == 6) {
      return "Samstag";
    } else if(month == 7) {
      return "Sonntag";
    }
    return "Unbekannt";
  }
}

Das Programm verfügt über eine Methode, welche 8 verschieden Verzweigungen hat.
Testabdeckung von 50%:

@Test
public void testDayOfWeekName() {
  DateUtils utils = new DateUtils();
  assertEquals("Montag", utils.getDayOfWeekName(1));
  assertEquals("Dienstag", utils.getDayOfWeekName(2));
  assertEquals("Mittwoch", utils.getDayOfWeekName(3));
  assertEquals("Donnerstag", utils.getDayOfWeekName(4));
}

Testabdeckung von 100%:

@Test
public void testDayOfWeekName() {
  DateUtils utils = new DateUtils();
  assertEquals("Montag", utils.getDayOfWeekName(1));
  assertEquals("Dienstag", utils.getDayOfWeekName(2));
  assertEquals("Mittwoch", utils.getDayOfWeekName(3));
  assertEquals("Donnerstag", utils.getDayOfWeekName(4));
  assertEquals("Freitag", utils.getDayOfWeekName(5));
  assertEquals("Samstag", utils.getDayOfWeekName(6));
  assertEquals("Sonntag", utils.getDayOfWeekName(7));
  assertEquals("Unbekannt", utils.getDayOfWeekName(8));
}

Testabdeckung von 0%:

@Test
public void testDayOfWeekName() {
  DateUtils utils = new DateUtils();
}

Testansätze

Es gibt verschiedene Ansätze wie Tests entwickelt und ausgeführt werden können. Im folgenden sollen die Box Ansätze kurz erläutert werden.

White Box

Der zu testende Quellcode ist bekannt, das Test Design kann sich am Code orientieren um alle Verzweigungen zu erreichen. Weiters können auch Teile des Codes, welche nicht nach außen hin Sichtbar sind, getestet werden. Unit Tests fallen Normalerweise in diese Kategorie. Durch White Box Tests kann eine hohe Testabdeckung des Codes erreicht werden.

Black Box

Über den Quellcode sind keine Informationen bekannt. Die Tests richten sich lediglich nach den nach außenhin sichtbaren Schnittstellen, die ein Programm bereitstellt. Dieser Ansatz ist für alle Teststufen geeignet.

Grey Box

Informationen über den Quellcode sind vorhanden, beispielsweise über Reverse Engineering. Zum Testen werden jedoch wie bei den Black Box Tests, lediglich die nach außenhin sichtbaren Schnittstellen werden verwendet.

Teststufen

Testing kann in verschiedene Stufen unterteilt werden, die im folgenden Angeführt werden. Im folgenden von fein bis grob:

Unit Test

Beschreibt das Testen auf Modul- oder Komponentenebene. Hierbei sollen abgrenzbare Teile eines Programmes getestet werden. Ein einfaches Beispiel dafür wäre das Testen von einer Klasse.

Integration Test

Beim Integrations Test wird das zusammenspiel unterschiedlicher Komponenten miteinander getestet.

System Test

Beim System Test wird das gesamte System gegen alle Anforderungen getestet. Beim Test soll die Produktivumgebung des Kunden simuliert werden.

Abnahme Test

Der Abnahme Test ist das testen des gesamten Systems durch den Kunden.

Continous Integration

Continous Integration beschreibt einen automatisierten Prozess, der aus dem kontinuierlichen bauens und testen der Software besteht. Das verwenden eines solchen Prozesses

Continous Delivery

Versionskontrolle

Pull/Merge Requests