Code-Recycling leicht gemacht

Laura Johnson, Agilent, Böblingen

Ein Test-Executive stellt eine Reihe von vielseitig nutzbaren Basisfunktionen bereit, die während des ganzen Testentwicklungs-Prozesses Einsatz finden (Bild 1). Er beinhaltet die Software zum Management der Testumgebung und bietet zugleich eine Grundstruktur zum Erstellen sämtlicher benötigter Testpläne. Ein Test-Executive ist wie ein Betriebssystem für die Teststation, das aber auch die Schnittstellen des Testsystems zur Außenwelt umfasst. Mit ihm lassen sich die Tests für viele Schritte des Herstellungszyklusses eines beliebigen Produkts automatisieren: vom Designverifikations-Test in der Forschungs- und Entwicklungs-Phase über die Fertigung von Mustern bis hin zum Funktions- und dem abschließenden Test auf Boardebene. Zu den Anwendungsbereichen von Test-Executives zählen:

• der Funktionstest in der Massenfertigung (zum Beispiel von Handys), bei der die Test-Performance und die -reproduzierbarkeit von entscheidender Bedeutung sind,

• die Herstellung eines umfangreichen Produktspektrums, bei der die Fertigungsanlagen in kürzester Zeit zur Herstellung eines anderen Produkts umgestellt werden müssen sowie

• der Test von Produkten, bei denen die Qualität sowie deren Verifizierbarkeit von größter Bedeutung sind (wie beispielsweise bei der Herstellung von elektronischen Luftfahrt- und medizinischen Produkten).

In Bild 2 sind einige der Anwender eines Test-Executives sowie die damit ausgeführten Arbeitsschritte dargestellt. Die verschiedenen Fachleute, die am Testprozess beteiligt sind, benötigen unterschiedliche Arten von Testdaten, und jeder von ihnen erzeugt wiederum unterschiedliche „Produkte“. So bestimmen einige Fachleute die Teststrategien, wählen Hard- und Softwarekomponenten aus oder entwickeln Programme, um diese Komponenten zu integrieren und sie in den gesamten Arbeitsfluss des Unternehmens einzubinden sowie das ganze Testsystem mit anderen Unternehmenssystemen, wie Datenbanken, zu verbinden. Andere implementieren gezielte Testpläne für die gegebenen Prüflinge (Unit Under Test, UUT): Dies erfordert das Deuten der Produktspezifikationen, das Realisieren der Testadapter und -ver-drahtung, das Erstellen von Treibern und Testcode, die Konzeption der Testablaufs, das Generieren der Testpläne sowie das System-Debugging.

Selbst wenn die Beteiligten ein gut eingespieltes Team bilden, bleibt die Notwendigkeit bestehen, über ein genau definiertes Verfahren zum Überwachen und Steuern von Daten und Informationen zu verfügen, denn nur so sind eine effiziente Zusammenarbeit, das Erstellen einer guten Dokumentation sowie ein Rückverfolgen der Messwerte möglich. Ein Test-Executive kann die Tools bieten, mit denen sich ein reibungsloser, gut dokumentierter Fluss von Prozeduren und Daten realisieren lässt.

Eine der wichtigsten Anwendungen für ein TE ist das Entwickeln des Testplanes. Üblicherweise basiert ein Testplan auf Testspezifikationen, die die Messparameter und deren Toleranzbereiche definieren; von letzteren hängt dann der Auschuss ab (Pass/Fail-Kriterien). Der Testplan kann iterativ erstellt werden, da sowohl die Spezifikationen des Tests als auch die des zu testenden Produkts während des gesamten Designzyklusses fluktuieren. Um den Testplan mit Hilfe eines Executives zu entwerfen, werden Routinen aus einer Bibliothek ausgewählt, mit denen sich dann Test-Setups, Messungen sowie andere notwendige Arbeitsschritte ausführen lassen. Dazu gehört auch das Festlegen der Pass/Fail-Kriterien für den Test, die durch die Definition von Grenzwerten stattfindet. Der Test-Executive speichert die Ergebnisse dieser Arbeitsschritte (Messwerte und Pass/Fail-Kriterien) und bewahrt sie zum weiteren Verarbeiten auf.

Diese Routinen werden entweder in der TE-Bibliothek oder in anderen dafür erstellten Librarys gespeichert. Wenn sich Routinen aus den Bibliotheken wiederverwenden lassen (oder wenn sie als Option erhältlich sind), oder wenn es dem Anwender möglich ist, seine eigenen Testroutinen problemlos zu speichern, dann lässt sich jeder neue Testplan mit ständig abnehmendem Aufwand erstellen, da jedes Mal weniger Code neu generiert werden muss. Aber dadurch wird auch das Warten der Testsysteme einfacher, weil der Testcode widerspruchsfrei und in der Praxis verifiziert ist.

Einige Test-Executives verfügen über Suchfunktionen, sodass es mit ihnen einfach ist, Routinen aufzufinden, um sie erneut zu verwenden (zum Beispiel Instrumenten-Setup- und Messroutinen). Manche lassen das Wiederverwenden von ganzen Testplänen zu, bei denen dann nur Parameter und Grenzwerte neu zu definieren sind. Dank dieser Features wird es für den Anwender einfacher, seine Testpläne so zu modifizieren, dass er damit eine neue UUT testen kann; außerdem steigt dadurch die Zuverlässigkeit des Testsystems, während zugleich die Wartung einfacher wird. Dabei ist das Wiederverwenden von Code von besonders großer Bedeutung beim Erstellen von Testanwendungen für den weltweiten Einsatz in einem globalen Fertigungsnetz.

Wenn eine benötigte Testroutine nicht auffindbar ist, muss sie neu entwickelt und in der Bibliothek abgespeichert werden. Es kann vorkommen, dass der Test-Executive die freie Wahl einer Programmiersprache dadurch einschränkt, dass er nur eine oder wenige Programmiersprachen unterstützt. Es kommt aber auch vor, dass er das Implementieren einer bestimmten Schnittstelle zu einem DLL- oder COM-Interface erfordert. Falls der TE über eine eigene Sprache zum Generieren von Testroutinen verfügt, dann stellt er vermutlich auch die dazugehörige Entwicklungsumgebung zur Verfügung. Wenn er mehrere Sprachen unterstützt, dann stellen üblicherweise diese Sprachen auch ihre eigenen Entwicklungs- und Debugging-Umgebungen bereit.

Der Anwender sollte sich genau überlegen, wie viele Programmiersprachen und -stile er in seiner Testumgebung verwenden möchte. Es könnte durchaus nützlich sein, wenn der verwendete Test-Executive mehrere Sprachen unterstützt, weil sich so der Code von älteren Testsystemen, der Code von der Forschungs- und Entwicklungs-Abteilung sowie der von früheren Herstellern des Produkts (wie dies zum Beispiel bei einer Firmen-übernahme oder bei ausgelagerter Fertigung der Fall ist) wiederverwenden lassen. Es ist andererseits empfehlenswert, dem Gesamtsystem eine bestimmte Homogenität aufzuerlegen, denn das erleichtert das Warten und ermöglicht eine reibungslose Zusammenarbeit zwischen den beteiligten Testfachleuten. Denn selbst wenn zwei Entwickler dieselbe Sprache benutzen, können deren Programmierstile sehr unterschiedlich sein. Einige Executives verfügen über optionale Tools wie beispielsweise Codegeneratoren, mit denen es möglich ist, besagte Homogenität beim Programmierstil zu erreichen, ohne jedoch dadurch ein Wiederverwenden existierender Codes auszuschließen. Selbstverständlich kann sich der Anwender dafür entscheiden, mehrere Programmiersprachen zuzulassen, weil sie sich jeweils optimal für bestimmte Anwendungen eignen: zum Beispiel Visual Basic für Benutzer-Schnittstellen und C zum Erstellen von Hochleistungscode, bei dem die Performance von primärer Bedeutung ist.

Test-Executives ermöglichen auch das Steuern von Testvorgängen wie das Sequenzieren. Letztere impliziert mehr als das simple Ausführen einer vorgegebenen Testreihe. So kann beispielsweise das Ergebnis eines bestimmten Tests bestimmen, welchem Test der Prüfling anschließend unterzogen wird. In anderen, komplexeren Fällen muss das Programm durch Verzweigungsbefehle in der Lage sein, zu verschiedenen Stellen der Testreihe zu wechseln oder sogar das Testsetup zu modifizieren, je nach Ergebnis des durchlaufenen Tests. Eine weitere Prüftechnik ist das Looping, bei dem der Prüfling, auch wenn er den Test nicht bestanden hat, mehrmals durchfallen muss, bevor er vom Executive als untauglich abgestempelt wird.

Fast alle Testsysteme verfügen über Schaltelemente, um die Ports des Testadapters mit den Messgeräten zu verbinden. Einige TEs weisen Features auf, mit denen das Implementieren dieser Schaltfunktionen erleichtert wird (Bild 3). Dazu gehören Werkzeuge zum Erstellen von Schaltpfaden mit sinnvollen Namen, die dann von den Setup- und Messroutinen verwendbar sind, ohne dass dafür spezifische Schaltbefehle vom Anwender zu erteilen wären.

Mit einem Test-Executive lässt sich die Debugging-Zeit reduzieren, indem der Anwender den Testplan schrittweise verifiziert und Unterbrechungspunkte in den Setup- und Messroutinen setzt. Stoppt er dann während des Ausführens das Programm bei einem dieser Punkte, ist er in der Lage, die von den Messgeräten gelieferten Messwerte selbst zu überprüfen. Außerdem kann der Anwender bei Bedarf auch eine Messschleife mehrfach durchlaufen, um festzustellen, wie sich seine Änderungen auf die Testergebnisse auswirken und wie genau die Wiederholbarkeit der Messungen ist. Es ist auch möglich, den Verlauf von Variablen zurückzuverfolgen, um so Probleme wie fehlerhafte Berechnungen lokalisieren zu können. Und auch das Rückverfolgen der E/A-Aktivität dient dazu, logische Fehler bei den Befehlen zu entdecken, die an ein Messgerät oder an eine UUT erteilt werden. Manche Executives stellen auch Tools zur Verfügung, mit denen das Messen und Optimieren der Testplan-Performance möglich sind. Dank dieser Funktionen helfen sie, eine Feineinstellung der Mess- und Testläufe durchzuführen.

Um die Testergebnisse zu verarbeiten, werden oft externe Hilfsprogramme verwendet; dazu zählen solche zum Zugriff auf Datenbanken, zur Tabellenkalkulation, zur statistischen Qualitätskontrolle sowie zur Textverarbeitung. Der Executive verfügt über Schnittstellen für diese Applikationen, die häufig auf Industriestandards basieren: So zu Beispiel COM für Programmier- oder XML für Daten-Schnittstellen.

Der Test-Executive muss fähig sein, mit einer Reihe von hierarchisch strukturierten Instrumenten-Steuerungsprogrammen umzugehen. Auf der höchsten Abstraktionsebene kann zum Beispiel das Testprogramm für eine bestimmte UUT den Befehl erlassen, einen gegebenen Parameter zu messen. Dieser Befehl wird der Mess-Software erteilt, die ihrerseits die entsprechenden Quell-, Mess- und Schalttreiber anweist, die gewünschten Funktionen von den dazugehörigen Geräten ausführen zu lassen.

Auf der niedrigsten Abstraktionsebene sendet die Software-Schnittstelle eines jeden Messgeräts ihre Befehle im eigenen Datenformat – wie GPIB oder SCPI (Standard Commands for Programmable Instruments). Oft stellt der Executive ein Messmodule-Menü oder ein einfaches Werkzeug zur Verfügung, um die Auswahl des Instruments und der Messroutine zu erleichtern. Einige Executives ermöglichen es dem Anwender, Befehle an die Messgeräte zu senden, ohne dafür Code schreiben zu müssen.

Ein Test-Executive bietet die Möglichkeit, viel Zeit zu sparen und Ärger zu vermeiden, indem er den Anwender bei der Entwicklung und dem Management von Testplänen und Tests, bei der Kommunikation mit den Messgeräten sowie bei der Integration des Tests mit externen Anwendungen unterstützt. Daher ist es wichtig, dass er flexibel und leistungsfähig genug ist, um sämtliche besprochenen Aufgaben optimal zu erledigen. Allerdings besteht hierbei die Gefahr, dass diese Funktionen zu einem Softwarepaket führen, das sehr kompliziert und für den Benutzer sogar verwirrend ist. Es ist daher wichtig, dass besagte Funktionen gut organisiert sind und der Executive Tools und Kurzbefehle bietet, mit denen wenigstens die häufigsten Aufgaben leicht auszuführen sind. So sollte es dem Anwender möglich sein, die benötigten Informationen abzulesen, ohne dafür lange suchen oder Fenster öffnen und verschieben zu müssen. Außerdem sollte der normale Kontrollfluss einer Testsequenz durch einfaches Lesen der Sequenz leicht verständlich sein, während dabei Probleme und Fehler schnell erkennbar sein sollten. Bild 4 verdeutlicht dies anhand eines Bildschirminhalts, der eine große, aber typische Informationsmenge darstellt, die in verschiedenen Fenstern enthalten ist.

Der Executive muss das Ausführen mehrerer Tasks ermöglichen; allerdings sollten die am häufigsten vorkommenden Aufgaben möglichst einfach durchführbar sein. Dies gilt insbesondere für das Generieren, Modifizieren und Debugging von Testplänen, da diese Vorgänge sehr oft vorkommen. Hierfür stellt ein guter Executive Tools bereit, die das Ausführen dieser Aufgaben unterstützen und erleichtern. Da es üblich ist, mehrere UUTs gleichzeitig zu testen, ist es wünschenswert, dass der TE über Werkzeuge verfügt, mit denen es einfach ist, die Anzahl der UUTs zu bestimmen, die nach einem bestimmten Testplan zu prüfen sind. Es kommt zudem oft vor, dass in einem Testsystem ein Messgerät hinzugefügt oder rekonfiguriert werden muss: Deswegen sollte der Test-Executive den Anwender dabei unterstützen, ohne dass letzterer zu diesem Zweck Code modifizieren und rekompilieren muss.

Wie es bei jedem Tool der Fall ist, bietet auch der Einsatz eines Test-Executives Vor- und Nachteile. Zu den Vorteilen gehören:

• eine schnellere Testsystem-Entwicklung, da sich ein Großteil des benötigten Materials in den Testroutine-Bibliotheken und in den mitgelieferten Werkzeugen befindet,

• ein einziges, gemeinsames System und eine einheitliche Vorgehensweise für sämtliche Anwender, weil sie alle mit demselben System arbeiten und über die gleichen Ressourcen verfügen,

• eine leichtere Wartung, da es dabei um eine einzige, gemeinsame Struktur und um gemeinsamen Code geht und

• das Optimiernen der Systemperformance, die der Executive durch entsprechende Tools in den meisten Fällen ermöglicht.

Zu den Nachteilen zählen:

• eine schlechtere Performance in einigen Fällen, bei denen die vom TE auferlegte Struktur nicht so schnell ist wie Code, der für eine spezielle, gegebene Anwendung per Hand maßgeschneidert wird,

• Einschränkungen hinsichtlich Programmiersprache und/oder Betriebssystem, weil es unter Umständen schwer sein kann, einen Test-Executive zu finden, der mit der bereits vorhandenen Software kompatibel ist sowie

• Schwierigkeiten bei kundenspezifischen Anpassungen, auch wenn diese meistens nicht technischer Natur sind; oft verlangt nämlich der Anwender, dass er auch weiterhin seine gewohnten Bildschirm-Layouts, seine Piktogramme, Formate sowie Berichtsinhalte benutzen kann, und dies ist nicht immer leicht realisierbar.

Kommt man jedoch zum Schluss, dass die Vorteile die Nachteile überwiegen, dann stellt sich die Frage nach der Auswahl des am besten geeigneten Executives. Um diese richtig zu beantworten, muss die künftige Betriebsumgebung des TEs exakt spezifiziert werden. Oft hat allerdings hier der Anwender keine Wahlfreiheit, weil die Umgebung von der unternehmenseigenen Test- oder IT-Strategie bestimmt wird. Zur Betriebsumgebung gehören das Betriebssystem, die Schnittstellen zu den anderen Applikationen (wie zum Beispiel Fertigungs-Datenbaken zum zurückverfolgen von Fehlern oder zur Fabrikautomatisierung), die Benutzer der Testsoftware (Testingenieure, Techniker und Bediener) sowie die verwendeten Tools (wie Compiler und Strichcode-Lesegeräte). Es ist an dieser Stelle besonders wichtig, zwischen vorgegebenen (unveränderlichen) und frei bestimmbaren Umgebungselementen zu unterscheiden.

Anschließend ist zu klären, ob die in Frage kommenden Executives weitverbreitete, standardisierte Programmiersprachen wie Visual Basic und C/C++ unterstützen. Verwendet ein bestimmter TE eine firmeneigene Programmiersprache oder eine solche, die den eigenen Fachleuten weitgehend unbekannt ist, dann sollte man sich genau überlegen, ob der damit verbundene Aufwand begründet ist. Ferner sind noch folgende Fragen zu beantworten:

• unterstützt der Executive die Sprache(n), in denen bereits vorliegender Testcode geschrieben wurde,

• wird es notwendig sein, einen kleinen oder großen Anteil des existierenden Codes umzuschreiben, um ihn dem TE anzupassen und

• setzt der TE voraus, dass bei jeder erwünschten Testplan-Änderung neuer Code zu schreiben ist?

Bei wiederverwendbaren Bibliotheken minimiert sich der Programmieraufwand. Es lässt sich auch viel Programmierzeit einsparen, wenn es möglich ist, auf häufig benötigte, menügesteuerte Funktionen, wie beispielsweise das Schalter-Handling, das Multiple-UUT-Testen und das Steuern von Messagebasierten Messgeräten, zurückzugreifen.

Der ausgewählte Executive sollte sich reibungslos in die bestehende Testumgebung integrieren lassen, ohne sie dabei „auf den Kopf“ zu stellen. Um ein übergangsloses Einbinden zu erleichtern, kann es wünschenswert sein, einige der bereits existierenden Funktionen und Anwendungen, die sich in der vorherigen Testumgebung bewährt haben, beizubehalten. Das kann der Fall sein, wenn Applikationen für ganz besondere Anforderungen entwickelt wurden oder wenn viele Benutzer eine bestehende Anwendung ganz besonders „mögen“, sodass diesbezüglich keine Notwendigkeit besteht, sie zu ersetzen. Nicht jeder TE lässt sich aber leicht und ohne großen Kostenaufwand entsprechend modifizieren. Es lohnt sich daher bei der Auswahl des Test-Executives darauf zu achten, ob er direkt mit besagten Anwendungen arbeiten kann oder wenigstens, ob er über standardisierte Datenaustausch-Formate wie XML verfügt. Es empfiehlt sich aber auch, darüber nachzudenken, ob er mit den bestehenden Datenbank-Applikationen arbeiten können soll, weil beispielsweise dadurch eine Testgeschichte-Datenbank beibehalten werden kann. Die Nützlichkeit einer solchen Datenbank zeigt sich bei statistischen Analysen und bei Garantie-Reparaturfällen.

Es ist empfehlenswert, auf die vom Executive unterstützten Messgeräte-E/As zu achten. Er sollte unbedingt die standardisierten Messgeräte-E/A-Bibliotheken und -Treiber (wie VISA, SCPI und VXIplug&play) unterstützen, die der Anwender bereits verwendet oder verwenden möchte. Ist das nicht der Fall, dann müssen die benötigten Messgerätetreiber neu entwickelt werden.

Ein weiterer, wichtiger Aspekt ist die Flexibilität der Benutzeroberfläche: Letztere sollte sämt-liche Forderungen aller Anwender erfüllen. Die Ingenieure, die Testsysteme integrieren und Test-pläne entwerfen, benötigen eine leistungsfähige Benutzeroberfläche, die ihnen andererseits auch das Ausführen der am häufigsten vorkommenden Aufgaben erleichtert. Die Bediener brauchen wiederum eine ganz andere Art von Benutzeroberfläche; in der Regel ist das ein einfaches Bildschirmmenü, das die Dateneingabe mit Hilfe eines Strichcode-Lesegeräts oder per Knopfdruck zulässt, ohne dafür wegen unnötiger Daten verwirrend zu wirken (Bild 5). Es sollte möglich sein, die Benutzeroberfläche des ausgewählten Executives problemlos auf die unterschiedlichen Bedürfnisse der Bediener zuzuschneiden. Das geht am einfachsten, wenn zu diesem Zweck eine einfache Programmiersprache wie Visual Basic verwendbar ist, mit der sich auch später notwendig gewordene Anpassungen leicht durchführen lassen.

Aber auch Aspekte, die von sekundärer Bedeutung zu sein scheinen, können wichtig sein. Einer davon ist die Fähigkeit eines Executives, Bestehendes wiederverwenden zu können. Die sich dadurch ergebenden Vorteile zeigen sich insbesondere beim Erstellen neuer Testpläne, bei der das Wiederverwenden von häufig vorkommenden Testfunktionen viel Zeit spart. Daher sollte es möglich sein, Testroutine-Libraries nach benötigten Codesegmenten leicht durchsuchen zu können, um auch die kleinsten brauchbaren Code-Abschnitte zu finden. Die Nützlichkeit dieses Features scheint zwar anfänglich gering zu sein, gewinnt aber im Laufe der Zeit ständig an Bedeutung, da naturgemäß die Menge vorhandener Software mit der Zeit zunimmt. Deshalb ist das Wiederverwenden von Code keine Kleinigkeit.

Last but not least sollte der Executive problemlos aktualisierbar und ausbaufähig sein. So empfiehlt es sich, zu verifizieren, ob der Anbieter beweisen kann, dass sein TE (inklusive Libraries) im Laufe der Zeit ständig aktualisiert und verbessert wurde. Außerdem sollte man noch folgende Punkte klären:

• kennt der Anbieter die Bedürfnisse des Anwenders genau, und sind die bisher implementierten Verbesserungen solche gewesen, die die Arbeit des Testingenieurs erleichtern?

• ist die Dokumentation leicht verständlich, übersichtlich und nützlich,

• werden Einführungskurse angeboten, die einen raschen Einstieg in die Materie und ein möglichst schnelles Umsetzen in die berufliche Praxis ermöglichen?

• unterstützt der TE den Anwender beim Dokumentieren der Testpläne und der Messungen auf solche Art und Weise, dass auch andere diese Informationen ohne fremde Hilfe verwenden können und

• bietet der Hersteller auch den benötigten Support, und zwar an allen Orte, für die der Einsatz des Executives vorgesehen ist?

Aus dem Besprochenen ergibt sich, dass es sich durchaus auszahlt, die eigenen Anforderungen an einen Test-Executive genau unter die Lupe zu nehmen, denn nur so lässt sich die richtige Entscheidung treffen: Sie führt zu einer schnelleren Testsystem-Entwicklung und zu geringeren Kosten, weil sich so die Testingenieure auf das Erstellen der benötigten Testroutinen für neue UUTs konzentrieren können, ohne Zeit damit verschwenden zu müssen, immer wieder die gleiche Software erneut entwickeln zu müssen. Der Test-Executive von Agilent wird von Meilhaus als Bestandteil einer breiten Produktpalette von Mess- und Testkomponenten angeboten.