Wie kann ein neuer Code effizient behoben oder getestet werden, wenn das Hardware-Setup zum Reproduzieren von Fehlern schwierig oder unmöglich ist?

Ich arbeite in einem mittelständischen Unternehmen (150 Mitarbeiter, ca. 10 Ingenieurteams) und die meisten meiner Projekte umfassen die Anbindung von Laborgeräten (Oszilloskope, optische Spektrumanalysatoren usw.) für halbautomatische Testanwendungen. Ich habe einige verschiedene Szenarien erlebt, in denen ich neuen Code nicht effizient beheben oder testen kann, weil mir das Hardware-Setup nicht mehr oder nie zur Verfügung stand.

Beispiel 1: Ein Aufbau, bei dem 10-20 "Einbrenn" -Prozesse unabhängig voneinander mit einem Tischsensor ausgeführt werden. Ich konnte einen solchen Sensor zum Testen beschaffen und gelegentlich einen zweiten stehlen, um alle Facetten der Schnittstelle zu simulieren mehrere Geräte (suchen, verbinden, streamen usw.).

Schließlich trat ein Fehler auf (der letztendlich in der Gerätefirmware und den Treibern auftrat), der mit nur einem Gerät nur sehr schwer genau reproduzierbar war, aber in der Nähe der "Show Stopper" -Pegel auftrat, wenn 10 bis 20 dieser Geräte gleichzeitig verwendet wurden. Dies ist immer noch ungelöst und dauert noch an.

Beispiel 2: Ein Test, der einen teuren optischen Spektrumanalysator als Kernkomponente erfordert. Das Gerät ist ziemlich alt, nach Angaben des Herstellers, der von einem größeren Unternehmen erworben und im Grunde genommen aufgelöst wurde, und seine einzige Dokumentation war ein langwieriges (und nicht informatives) Dokument, das schlecht übersetzt zu sein scheint. Während der anfänglichen Entwicklung konnte ich das Gerät an meinem Schreibtisch belassen, aber jetzt ist es während der mehrwöchigen Tests, die rund um die Uhr durchgeführt werden, physisch und termingerecht gebunden.

Wenn Fehler auftreten, die sich auf das Gerät beziehen oder nicht mit dem Gerät zusammenhängen, muss ich oft die Mühe haben, Code außerhalb der Anwendung zu testen und einzupassen, oder Code blind zu schreiben und zu versuchen, zwischen den Durchläufen eine gewisse Testzeit einzukalkulieren Die Programmlogik setzt voraus, dass das OSA und der Rest der Testhardware vorhanden sind.

Ich denke, meine Frage ist, wie ich das angehen soll. Ich könnte möglicherweise Zeit damit verbringen, Gerätesimulatoren zu entwickeln, aber wenn ich das in die Entwicklungsschätzung mit einbeziehe, wird es mehr aufblähen, als die meisten wahrscheinlich zu schätzen wissen. Möglicherweise werden auch nicht alle Probleme exakt reproduziert, und es kommt ziemlich selten vor, dass die gleiche Ausrüstung hier zweimal verwendet wird. Ich könnte beim Testen von Einheiten besser werden ... etc ... Ich könnte auch laut über das Problem sprechen und anderen klar machen, dass vorübergehende Verzögerungen erforderlich sind, die nicht viel mehr als Kopfschmerzen für Forschung und Entwicklung sind, sondern in der Regel als Scherz empfunden werden bei der Herstellung aufgeschlagen.

Das Management weiß, dass die Entwicklung und Wartung von Software länger dauern wird, wenn Sie keinen vollständigen Zugriff auf die Testhardware haben. Dies müssen Sie bei Ihren Schätzungen berücksichtigen. Ein Teil der Akzeptanzkriterien für die Inbetriebnahme Ihrer Software sollte sein, dass Sie die Software unter den meisten Umständen warten können, ohne die Produktion zu stoppen. Wenn Sie TDD praktizieren, sollte dies ziemlich natürlich vorkommen.

Früher habe ich Software für 60 Millionen Dollar Flugzeuge geschrieben. Offensichtlich ist ein hohes Maß an Zuverlässigkeit erforderlich, und sie zögern, jedem Entwickler eines für ihren Schreibtisch zu geben. Grundsätzlich hatten wir 5 Ebenen von Testumgebungen mit mehr realer Hardware auf jeder Ebene bis zu einem vollen Flugzeug. Ich schätze, 95% unserer Software könnten nur mit Emulatoren und Unit-Tests entwickelt und getestet werden. 95% der verbleibenden Funktionen konnten auf der nächsten Ebene bearbeitet werden und so weiter.

Versuchen Sie, ähnliche Testumgebungen für sich selbst einzurichten. Sie können nicht erwarten, dass Sie niemals Zugriff auf die echte Hardware benötigen, aber wenn Sie diese so eingerichtet haben, dass Sie ohne die verfügbare Hardware nicht an der GUI Ihrer Software arbeiten können, verschwenden Sie wertvolle Zeit mit einer teuren Ressource (nicht mit Erwähnen Sie, dass Sie Kopplungsprobleme mit Ihrer Architektur haben. Bedenken Sie, dass andere Entwickler wahrscheinlich dieselben Probleme haben wie Sie. Ich würde den Hardwarehersteller fragen, ob er bereits Emulatoren oder andere Testressourcen zur Verfügung hat.

Sie müssen auch Ihre Einstellung etwas ändern, wenn Sie nur eingeschränkten Zugriff auf Hardware haben. Anstatt zu versuchen, Ihre Anwendung auf die normale serielle Weise zu debuggen, müssen Sie häufig Code speziell schreiben, um Informationen so schnell wie möglich zu sammeln.

Zum Beispiel haben Sie vielleicht einen Fehler und können sich 10 mögliche Ursachen vorstellen. Wenn die einzige Zeit, die Sie auf eine Maschine setzen können, die 15 Minuten sind, während der Bediener in der Pause ist, schreiben Sie ein kurzes, eigenständiges, korrektes (kompilierbares) Beispiel , das den Fehler auslöst, und schreiben Sie 10 automatisierte Tests mit dieser SSCCE, um Ihre Theorien zu testen und eine Reihe von Daten protokollieren. Zurück an Ihrem Schreibtisch können Sie so lange brauchen, bis Sie die Daten für Ihren nächsten Versuch gesichtet haben. Die Idee ist, den Nutzen Ihrer begrenzten Zeit mit der Hardware zu maximieren.

Sie versuchen ein Problem zu lösen, das Sie nicht lösen können.

Das Management muss den Zugriff auf die Geräte priorisieren. Das kann bedeuten, dass Sie einen größeren Zugang haben, aber es kann auch bedeuten, dass Sie weniger haben.

Präsentieren Sie die Herausforderungen, die Sie haben, in einem objektiven Format Ihrem Management-Team und bitten Sie es um Anleitung. Ihre Präsentation wäre viel stärker, wenn Sie mit den anderen zusammenarbeiten würden, die ebenfalls Zugriff benötigen, sodass Sie alle Ihren Fall gleichzeitig präsentieren können.

Von dort aus muss das Unternehmen (Management) priorisieren, wer wann Zugriff erhält. Dies ist eine Geschäftsentscheidung, die sie treffen müssen, da die (fehlende) Verfügbarkeit der Ressourcen die Geschäftsentwicklung beeinflusst.

Sie codieren effektiv blind.

Wenn das Management die Kosten für Testgeräte nicht trägt, besteht eine hohe Wahrscheinlichkeit, dass Fehler auftreten oder die Entwicklung sogar länger dauert als bei Verwendung von realen Geräten.

Die Kosten für die Geräte müssen nicht vollständig dem Entwicklungszyklus zugeordnet werden. Vielleicht können sie in die Produktion oder als Backup übernommen werden. Könnten sie sogar woanders gebraucht weiterverkauft werden?

Probieren und kosten Sie die Fehlerbehebungsphasen in Zeit und Geld und zeigen Sie die Gesamtkosten Ihrem Team / Unternehmen an.

Mit Ihren Vorgesetzten zu streiten ist viel einfacher, wenn Sie einige Zahlen oder zumindest einige Vor- und Nachteile zur Hand haben. Mein Vorschlag ist daher, eine Kosten-Nutzen-Analyse durchzuführen. Die grobe Idee lautet wie folgt:

• Wie viel Entwicklungsaufwand erwarten Sie für das Schreiben eines Gerätesimulators? (Beachten Sie, dass ein Gerätesimulator die ursprüngliche Hardware nicht zu 100% ersetzen kann, insbesondere wenn die Hardware unerwartete Probleme aufweist.)

• Wie viel Aufwand beim Testen / Debuggen erwarten Sie ohne ein solches Tool? Schließen Sie die Kosten für Ihre Laborarbeiter ein, da Sie die Hardware zu Testzwecken blockieren müssen. Berücksichtigen Sie auch die Kosten für die Zeit, in der das System aufgrund von Fehlern nicht verwendet werden kann und Sie Probleme haben, die Ursache zu finden.

• Wie viel kostet zusätzliche Hardware zum Testen?

• Wie viel Zeit benötigen Sie voraussichtlich, um die Hardware zu Testzwecken zu blockieren?

Natürlich mag die Realität nicht so einfach sein und es gibt eine Menge unbekannter Variablen in dieser Gleichung, aber versuchen Sie, einige Schätzungen vorzunehmen und fragen Sie, wo Sie unsicher sind, andere Menschen aus Ihrer Umgebung.

Präsentieren Sie die Ergebnisse Ihrem Management, besprechen Sie die Alternativen und lassen Sie sie dann entscheiden.