Testmanagement: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 8: | Zeile 8: | ||
- Systemtests | - Systemtests | ||
In jeder dieser Phasen muss spezifiziert was genau getestet werden soll, wie diese Tests durchgeführt werden und welche Kriterien darüber bestimmen, ob ein Testfall positiv oder negativ zu bewerten ist. Wie die einzelnen Testphasen durchgeführt werden können, wird fortführend am Beispiel des SDE Praktikums beschrieben. | In jeder dieser Phasen muss spezifiziert was genau getestet werden soll, wie diese Tests durchgeführt werden und welche Kriterien darüber bestimmen, ob ein Testfall positiv oder negativ zu bewerten ist. Wie die einzelnen Testphasen durchgeführt werden können, wird fortführend am Beispiel des SDE Praktikums beschrieben. | ||
== Testkonzept == | |||
Alle im Rahmen des SDE Praktikums erarbeiten Softwarekomponenten müssen prinzipiell die gesamte Testkette durchlaufen, da mindestens einer der folgenden Punkte auf sie zutrifft: | |||
- Die Komponente ist eine Neuentwicklung | |||
- Die Komponente wurde übernommen, ist aber ungetestet | |||
- Es existieren keine dokumentierten Test zu dieser Komponente | |||
Dabei ist zu beachten, dass die folgenden Testphasen aufeinander aufbauen und daher erst mit der nächsthöheren Phase begonnen werden kann, nachdem alle Tests der untergeordneten Phase erfolgreich abgeschlossen sind. | |||
== Statische Analyse == | == Statische Analyse == |
Version vom 9. Januar 2015, 20:55 Uhr
Teststufen
Das Testen ist ein wichtiger Bestandteil der Softwareentwicklung, da nur durch umfangreiches Testen sichergestellt werden kann, dass alle spezifizierten Anforderungen an das Produkt auch erfüllt wurden. Das Testen findet i.d.R. in mehreren aufeinander aufbauenden Phasen statt, die das System zu einem stetig wachsenden Grad betrachten.
Ein Testkonzept lässt sich aus dem in der Entwicklung häufig genutzten V-Modell ableiten und beinhaltet die folgenden Testphasen:
- Statische Analyse - Modultests - Integrationstests - Systemtests
In jeder dieser Phasen muss spezifiziert was genau getestet werden soll, wie diese Tests durchgeführt werden und welche Kriterien darüber bestimmen, ob ein Testfall positiv oder negativ zu bewerten ist. Wie die einzelnen Testphasen durchgeführt werden können, wird fortführend am Beispiel des SDE Praktikums beschrieben.
Testkonzept
Alle im Rahmen des SDE Praktikums erarbeiten Softwarekomponenten müssen prinzipiell die gesamte Testkette durchlaufen, da mindestens einer der folgenden Punkte auf sie zutrifft:
- Die Komponente ist eine Neuentwicklung - Die Komponente wurde übernommen, ist aber ungetestet - Es existieren keine dokumentierten Test zu dieser Komponente
Dabei ist zu beachten, dass die folgenden Testphasen aufeinander aufbauen und daher erst mit der nächsthöheren Phase begonnen werden kann, nachdem alle Tests der untergeordneten Phase erfolgreich abgeschlossen sind.
Statische Analyse
Die statische Analyse ist eine sehr formale Teststufe und sollte immer dann angewendet werden, wenn ein Teil der Software fertig implementiert wurde. Die dabei entstandenen Quellcodedateien sind in diesem Fall Gegenstand der Überprüfung. Im Gegensatz zu anderen Testphasen müssen hierbei keine Testfälle oder Pass/Fail-Kriterien definiert werden, da statische Analysen toolgestützt durchgeführt werden können und diese solche Informationen selbst genieren und die Tests anschließend durchführen. Als Beispiele für solche Tools können Polyspace und QA-C genannt werden.
Da bei statischen Analysen der Code nicht ausgeführt, sondern lediglich formal überprüft wird, können in diesem Schritt noch keine Funktionalitäten getestet werden. Allerdings lassen sich Codierrichtlinien wie z.B. Misra-C damit überprüfen. Außerdem werden bei einer statischen Analyse klassische Programmierfehler entdeckt, die zu Laufzeitfehlern führen können. Dazu zählen u.A. :
- Speicherüberläufe - Nicht-Initialisierte Variabeln - Ungültige Pointer-Zugriffe - Endlosschleifen
Nach der Durchführung einer statischen Analyse können die gefundenen Fehler im Code behoben werden, sodass für die folgenden Testphasen ein formal korrekter Code gegeben ist.
Dynamische Modultests
Um in späteren Phasen testen zu können ob die Gesamtfunktion gegeben ist, müssen zunächst die einzelnen Elemente des Codes als Teilfunktionen getestet werden. Diese Testphase wird anforderungsbasiert durchgeführt. Daher ist es sinnvoll zur Dokumentation dieser Phase Doors zu verwenden, da dieses zuvor auch für das Anforderungsmanagement genutzt wurden.
In einem zusätzlichen Doors-Dokument können dann Testfälle definiert werden, die jeweils über die Attribute Testdurchführung, erwarteter Testverlauf und Testergebnis verfügen. Diese Testfälle werden anschließend im Pflichtenheft auf das Requirement verlinkt, das sie abtesten. Nur wenn auf diese Weise jede Anforderung mindestens einen Link erhält, sind die Modultests vollständig. Andernfalls sind weitere Testfälle zu erzeugen, da ungetestete Anforderungen stets ein Risiko beherbergen.
Anschließend werden die Testfälle gemäßg der beschriebenen Testdurchführung durchgeführt. Existiert beispielsweise die Anforderung, dass eine Transformation von Bild- zu Weltkoordinaten durchgeführt werden muss, und diese durch die Implementierung einer C-Funktion umgesetzt wurde, könnte der Testfall darin bestehen diese Funktion mit festgelegten Werten, in diesem Fall Bildkoordinaten, aufzurufen. Für diese Werte muss dabei bekannt sein welchen Weltkoordinaten sie entsprechenden. Diese Werte wären als erwartetes Testergebnis zu dokumentieren. Liefert die Funktion die richtigen Rückgabewerte, ist die Anforderung erfüllt und der Test erfolgreich. In jedem anderem Fall ist die Implementierung zu überarbeiten.