Testmanagement: Unterschied zwischen den Versionen
| (6 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt) | |||
| 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. Der Testplan sollte sich an den Meilensteinen im Projekt orientieren, da möglicherweise bei späteren Meilensteine auf vorangegangene Ergebnisse aufgebaut wird. In diesem Kontext wäre es wünschenswert, dass alle dafür genutzten Funktionen ausreichend getestet sind. | |||
== Statische Analyse == | == Statische Analyse == | ||
| Zeile 27: | Zeile 34: | ||
== Integrationstests == | == Integrationstests == | ||
Die Integrationstests dienen dazu sicherzustellen, dass alle zuvor durch Modultests geprüften Funktionalitäten auch zusammen funktionieren. Dabei werden mehrere Komponenten der Software zu Funktionseinheiten zusammengefasst und gemeinsam getestet. Ähnlich wie bei den Modultests lässt sich hierbei anforderungsbasiert vorgehen. Zusätzlich lassen sich auch noch Testfälle aus der Schnittstellenbeschreibung ableiten. Als Dokumentationsgrundlage sollte wie zuvor auch Doors verwendet werden, da die Tests lediglich größere Funktionsumfänge abprüfen, aber das vorgehen identisch ist. | |||
Ein Beispiel für einen Integrationstest ließe sich an der Übertragung des gefundenen Spurpolynoms beschreiben. Die Testdurchführung würde in diesem Fall verlangen, dass ein Spurpolynom, beschrieben durch die Parameter a, b und c, aus den Bilddaten ermittelt, in Weltkoordinaten transformiert und anschließend über die entsprechende Schnittstelle gesendet wird. Der Test wird als erfolgreich definiert, wenn die gesendeten Daten korrekt empfangen worden sind. Um dies zu erreichen müssen die Komponenten Spursuche, Transformation und Kommunikation gemeinsam funktionieren. Das Testen solcher Zusammenhänge ist selbstverständlich nur dann sinnvoll wenn jede einzelne Komponente zuvor den für sie spezifizierten Modultest erfolgreich absolviert hat. | |||
== Systemtests == | == Systemtests == | ||
Systemtests bilden das Ende der Testkette und überprüfen die Gesamtfunktion des Systems. Spätestens in dieser Testphase müssen die Funktionalitäten unter realen Bedingungen ausgeführt werden. Am Beispiel des SDE Praktikums bedeutet dies, dass das Fahrzeug selbst getestet werden muss. Im Gegensatz zum Testen in Testumgebungen, die mit zuvor gespeicherten Messdaten betrieben werden, erhält man durch das Testen direkt am Fahrzeug Informationen über die Performance der Software. Die Anzahl der Frames, die pro Sekunde verarbeitet werden kann, lässt sich beispielsweise nur unter Verwendung der Ziel-Hardware bestimmen. | |||
Die Testfälle, die auf dieser Ebene zu definieren sind, beziehen sich auf die Hauptfunktionen des Fahrzeugs. So wäre ein Testfall beispielsweise, dass das Fahrzeug den Anforderungen entsprechend korrekt einparken muss oder eine gewisse Zeit lang eigenständig in der Spur mit selbstbestimmter Geschwindigkeit fahren kann. | |||
---- | |||
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]] | |||
Aktuelle Version vom 12. Februar 2019, 16:02 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. Der Testplan sollte sich an den Meilensteinen im Projekt orientieren, da möglicherweise bei späteren Meilensteine auf vorangegangene Ergebnisse aufgebaut wird. In diesem Kontext wäre es wünschenswert, dass alle dafür genutzten Funktionen ausreichend getestet 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.
Integrationstests
Die Integrationstests dienen dazu sicherzustellen, dass alle zuvor durch Modultests geprüften Funktionalitäten auch zusammen funktionieren. Dabei werden mehrere Komponenten der Software zu Funktionseinheiten zusammengefasst und gemeinsam getestet. Ähnlich wie bei den Modultests lässt sich hierbei anforderungsbasiert vorgehen. Zusätzlich lassen sich auch noch Testfälle aus der Schnittstellenbeschreibung ableiten. Als Dokumentationsgrundlage sollte wie zuvor auch Doors verwendet werden, da die Tests lediglich größere Funktionsumfänge abprüfen, aber das vorgehen identisch ist.
Ein Beispiel für einen Integrationstest ließe sich an der Übertragung des gefundenen Spurpolynoms beschreiben. Die Testdurchführung würde in diesem Fall verlangen, dass ein Spurpolynom, beschrieben durch die Parameter a, b und c, aus den Bilddaten ermittelt, in Weltkoordinaten transformiert und anschließend über die entsprechende Schnittstelle gesendet wird. Der Test wird als erfolgreich definiert, wenn die gesendeten Daten korrekt empfangen worden sind. Um dies zu erreichen müssen die Komponenten Spursuche, Transformation und Kommunikation gemeinsam funktionieren. Das Testen solcher Zusammenhänge ist selbstverständlich nur dann sinnvoll wenn jede einzelne Komponente zuvor den für sie spezifizierten Modultest erfolgreich absolviert hat.
Systemtests
Systemtests bilden das Ende der Testkette und überprüfen die Gesamtfunktion des Systems. Spätestens in dieser Testphase müssen die Funktionalitäten unter realen Bedingungen ausgeführt werden. Am Beispiel des SDE Praktikums bedeutet dies, dass das Fahrzeug selbst getestet werden muss. Im Gegensatz zum Testen in Testumgebungen, die mit zuvor gespeicherten Messdaten betrieben werden, erhält man durch das Testen direkt am Fahrzeug Informationen über die Performance der Software. Die Anzahl der Frames, die pro Sekunde verarbeitet werden kann, lässt sich beispielsweise nur unter Verwendung der Ziel-Hardware bestimmen.
Die Testfälle, die auf dieser Ebene zu definieren sind, beziehen sich auf die Hauptfunktionen des Fahrzeugs. So wäre ein Testfall beispielsweise, dass das Fahrzeug den Anforderungen entsprechend korrekt einparken muss oder eine gewisse Zeit lang eigenständig in der Spur mit selbstbestimmter Geschwindigkeit fahren kann.
→ zurück zum Hauptartikel: Praktikum SDE