en
de

Automatisierung von Systemtests

6 Juni 2013
| |
Lesezeit: 2 Minutes

Um ein System automatisiert zu testen benötigt man Wege zur automatisierten Steuerung des Systems und Wege, um das Verhalten des Systems zu überwachen. Man spricht auch von PoCs (point of control) und PoOs (point of observation). An den PoCs werden Signale und Daten in den Testling injiziert. An den PoOs werden die Ausgaben des Testlings registriert.

Die Festlegung der PoCs und PoOs ist mit der wichtigste Schritt auf dem Weg zu automatisierten Systemtests. Für Tastendrücke auf einem Touchscreen sind beispielsweise folgende PoCs denkbar:

  • mechanisch auf dem Touchscreen
  • elektrisch auf den Leitungen im Touchscreen
  • via Protokoll auf dem Bus zwischen Touchscreen Controller und Mikrocontroller
  • über eine Erweiterung des Treibers auf dem Mikrocontroller, die über eine zusätzliche Kommunikationsschnittstelle angesprochen wird
  • via Eingriff in die Kommunikation zwischen Treiber und Applikationsschicht

Von oben nach unten wird der PoC immer weiter ins Innere des Systems verschoben. Je weiter außen wir am System  ansetzen, desto mehr Komponenten werden mitgetestet und desto robuster sind die Tests gegen interne Änderungen des Testlings, die keine Außenwirkung haben (Refaktorisierung).

Werden PoC und PoO weiter ins System hinein bewegt, werden die Tests schneller und es ergeben sich neue Möglichkeiten – zum Beispiel die Simulation von Ausnahmesituation, die sonst schwer herbeizuführen wären. Die Aussagekraft so abkürzender automatisierter Systemtests muss allerdings plausibilisiert werden, zum Beispiel durch ergänzende manuelle Systemtests.

PoCs und PoOs können wir uns aber nur innerhalb der Möglichkeiten, die uns die Software-Architektur und die System-Architektur bieten, aussuchen. Die Überwachung oder Manipulation einer Bus-Kommunikation wird erleichtert oder erschwert durch das Design der Elektronik. Ein Abhören der Kommunikation zwischen Treiber und Applikationsschicht in der Software ist nur möglich, wenn uns die Software- und System-Architektur entsprechende Schnittstellen zur Verfügung stellen.

Deswegen sollte die Strategie zur Automatisierung von Systemtests Hand in Hand mit der System- und Software-Architektur entwickelt werden. System und Software müssen also von Anfang an auf Testbarkeit hin entwickelt werden. Die Elektronikentwicklung hat dafür den Begriff  Design for Testability (DFT) geprägt und meint damit, bereits beim Design des PCB an die Tests am Ende der Produktionslinie zu denken.

Mein Kollege Daniel Mölle hat zu diesem Thema einen Vortrag auf der MedConf 2012 gehalten. Die Folien vermitteln ein tieferes Verständnis  zu diesem Konzept.

 

Kommentare (1)

[…] muss, haben Daniel Mölle und Matthias Kraatz in ihren beiden Blog-Artikeln zu Unit-Testing und zu automatisierten Systemtests […]

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »